O PPP over Ethernet (RFC 2516) é uma especificação que  permite a conexão de hosts à Rede do Provedor para acesso a Internet, providenciando conexões ponto-a-ponto, utilizando a Pilha do protocolo PPP sobre o protocolo Ethernet.

O protocolo PPP trabalha com a tecnologia Ethernet para ligar a placa de rede dos usuários ao modem.  Desta forma é possível agregarmos a autenticação para a conexão e aquisição de um endereço IP fixo ou dinâmico à máquina do usuário.

Modems DSL são essencialmente simples Bridges Ethernet para conexão com Multiplexadores de Acesso (DSLAMs) da Operadora, oferecendo um túnel PPP sobre Ethernet.

PPPoE em Roteadores MSR

Existem diversas maneiras para a configuração em Roteadores MSR como clientes PPPoE. No exemplo abaixo efetuaremos a configuração básica para simulação do Roteador R1 como cliente PPPoE e R2 como um servidor PPPoE para autenticação utilizando PAP e o fornecimento de endereços por DHCP.

Configuração

R1:
#
interface Dialer1
! Criando a Interface Dialer0
 link-protocol ppp
! Habilitando o protocolo PPP
 ppp pap local-user diego password simple 12345
! Configurando a autenticação com pap
! usuario "diego" com a senha "12345"
 ip address ppp-negotiate
! Configurando a negociação IP dinâmica
 dialer user diego
 dialer-group 1
 dialer bundle 1
! Configurando o dialer-group 1 e o dialer bundle 1
#
interface Ethernet0/1/0
 port link-mode route
 pppoe-client dial-bundle-number 1
! Vinculando o dialer bundle na interface e0/1/0
#
 ip route-static 0.0.0.0 0.0.0.0 Dialer1
! Configurando a rota estática para o Dialer1
#

Comandos Display e Debug

<R1>display pppoe-client session  summary
PPPoE Client Session:
ID   Bundle  Dialer  Intf             RemMAC        LocMAC        State
1    1       1       Eth0/1/0         000fea031100  000feb030f00  PPPUP

<R1>display ip interface brief
*down: administratively down
(s): spoofing
Interface                     Physical Protocol IP Address      Description
Dialer1                       up       up       192.168.1.3     Dialer1 I...
Ethernet0/1/0                 up       up       unassigned      Ethernet0...

! O commando display  pppoe-client  session mostrará as conexões PPPoE ativas no Roteador incluindo o endereço MAC da outra ponta.

<R1> debugging  pppoe-client packet
*Sep 25 11:15:31:359 2013 SW1 PPPOEC/7/debugging: Ethernet0/1/0: PPPoE Client OUT Discovery packet (PADI), Len = 30
*Sep 25 11:15:31:374 2013 SW1 PPPOEC/7/debugging: Ethernet0/1/0: PPPoE Client IN Discovery packet (PADO), Len = 49
*Sep 25 11:15:31:390 2013 SW1 PPPOEC/7/debugging: Ethernet0/1/0: PPPoE Client OUT Discovery packet (PADR), Len = 49
%Sep 25 11:15:31:405 2013 SW1 IFNET/3/LINK_UPDOWN: Dialer1:0 link status is UP.
*Sep 25 11:15:31:405 2013 SW1 PPPOEC/7/debugging: Ethernet0/1/0: PPPoE Client IN
 Discovery packet (PADS), Len = 49, Session ID = 1%Sep 25 11:15:33:605 2013 SW1 IFNET/5/LINEPROTO_UPDOWN: Line protocol on the interface Dialer1:0 is UP.
%Sep 25 11:15:33:621 2013 SW1 IFNET/5/PROTOCOL_UPDOWN: Protocol PPP IPCP on theinterface Dialer1:0 is UP.
%Sep 25 11:15:33:636 2013 SW1 PPPOEC/6/PPPOEC_LOG_ON: PPPoE user diego logged on successfully.

O Debug acima é bastante interessante para entendermos as mensagens de negociação PPPoE .

Durante iniciação da negociação PPPoE o host encaminha uma mensagem PADI (PPPoE Active Discovery Initiation )em Broadcast, quando o Servidor PPPoE ou Concentrador de acesso recebe essa mensagem, ela é respondida com uma mensagem PADO (The PPPoE Active Discovery Offer) contendo informações do Servidor.

Muito similiar as solicitações DHCP, o host poderá receber mais de uma mensagem PADO ( de diversos concentradores). O host responde na seqüência com uma mensagem PADR (PPPoE Active Discovery Request  ) em unicast para o Servidor PPPoE  escolhido. Se a mensagem PADR for valida, é encaminhada para o host uma mensagem PADS (PPPoE Active Discovery Session-confirmation) para iniciar a sessão PPP.

Obs: Se  desejado  o fim da sessão PPP é gerado uma mensagem PADT (PPPoE Active Discovery Terminate).

Mais…

Segue abaixo a configuração do Roteador R2, responsável por aceitar e autenticar a conexão de R1.

#
local-user diego
 password simple 12345
 service-type ppp
! Configurando o usuario e senha para autenticação
#
interface Ethernet0/0/0
 port link-mode route
 pppoe-server bind Virtual-Template 1
! Vinculando a interface virtual-template 1 
#
interface Virtual-Template1
 ppp authentication-mode pap
 remote address 192.168.1.3
 ip address 192.168.1.1 255.255.255.0
! Habilitando o serviço de autenticação PAP na interface Virtual-Template 1
! incluindo o IP remoto (nesse caso, poderia ser configurado um servidor DHCP)

Referencias:

http://tools.ietf.org/html/rfc2516
http://babarata.blogspot.com/2010/03/inicio.html
http://fengnet.com/book/VPNs%20Illustrated%20Tunnels%20%20VPNsand%20IPsec/ch04lev1sec3.html
http://blog.ine.com/2010/03/18/bba-group-and-dialer-profiles-with-pppoe/
http://www.rotadefault.com.br/2013/06/26/introducao-ao-pppoe-e-configuracao-basica-em-roteadores-cisco/

Com as novas necessidades de serviços para Data Center, Provedores de Serviços e negócios, há cenários em que se faz necessário a conexão entre 2 segmentos de rede (dois pontos de uma mesma empresa separados em diferentes cidades, por exemplo) de forma que compartilhem o mesmo domínio de broadcast . Neste caso o Roteador simulará a função de um Switch Ethernet.

Os documentos  disponíveis no site da HP demonstram algumas tecnologias que permitem atingirmos  os objetivos acima. Em nosso exemplo utilizaremos a feature chamada de “Kompella local Connection” que funciona dentro de um processo MPLS para fornecer a conectividade L2 .

Configuração

#
mpls lsr-id 172.16.1.1
! Configurando o LSR ID no Roteador
mpls
! Habilitando o processo MPLS
#
l2vpn
 mpls l2vpn
! Habilite o serviço MPLS L2VPN
quit
#
mpls l2vpn vpnteste encapsulation vlan
 route-distinguisher 100:1
 vpn-target 111:1 import-extcommunity
 vpn-target 111:1 export-extcommunity
! Configure o vpn-target para o processo  e defina o modo de encapsulamento
 ce ce1 id 1 
  connection ce-offset 2 interface GigabitEthernet3/0/0
 ce ce2 id 2 
  connection ce-offset 1 interface GigabitEthernet5/0/0
! Faça o mapeamento l2vpn das 2 interfaces
quit
#

Comandos Display

[PE1]display mpls l2vpn connection
2 total connections,
connections: 2 up, 0 down, 2 local, 0 remote, 0 unknown

VPN name: vpnteste,
2 total connections,
connections: 2 up, 0 down, 2 local, 0 remote, 0 unknown

  CE name: ce1, id: 1,
  Rid type status peer-id         route-distinguisher   intf
  2   loc  up     ---             ---                   GE3/0/0

  CE name: ce2, id: 2,
  Rid type status peer-id         route-distinguisher   intf
  1   loc  up     ---             ---                   GE5/0/0

[PE1]display mpls l2vpn vpn-name vpnteste
 ***VPN name               : vpnteste
    Encap type             : vlan
    Local ce number(s)     : 2
    Remote ce number(s)    : 0
    Route distinguisher    : 100:1
    MTU                    : 1500
    Import vpn target      : 111:1
    Export vpn target      : 111:1

Até a próxima!

Segue uma lista para rápida comparação de comandos para troubleshooting, reset e refresh para o processo BGP comparando os comandos entre equipamentos 3Com,H3C e HP baseados no Comware e Cisco IOS.

Troubleshooting

Comware                                           IOS

display ip routing-table                          show ip route
display ip routing-table x.x.x.x                  show ip route x.x.x.x
display ip routing-table x.x.x.x longer-match     show ip route x.x.x.x longer-prefixes
display ip routing-table protocol bgp             show ip route bgp
display bgp routing-table                         show ip bgp
display bgp routing-table x.x.x.x                 show ip bgp x.x.x.x
display bgp routing peer                          show ip bgp summary
display bgp routing regular-expression AS-number  show ip bgp regexp AS-number

Reset e Refresh

Comware                                           IOS

reset bgp x.x.x.x            (modo user-view)     clear ip bgp x.x.x.x
refresh bgp x.x.x.x import   (modo user-view)     clear ip bgp x.x.x.x in
                                                  clear ip bgp x.x.x.x soft in

refresh bgp x.x.x.x export                        clear ip bgp x.x.x.x out
                                                  clear ip bgp x.x.x.x soft out

Pessoal, segue abaixo a lista de alguns comandos para BGP quando há a necessidade de traduzir de Cisco IOS para HP Comware.

Comware                                                      Cisco IOS
------------                                                 --------------
bgp xxxxx                                                   router bgp xxxxx
router-id x.x.x.x                                           bgp router-id x.x.x.x 
preference 200 200 200 (valor recomendado, não é default)   distance 20 200 200 (default)
undo synchronization                                        no synchronization (not default)
v5: recomendado (não é default)
v7: default
undo summary automatic (default)                            no auto-summary (not default)
log-peer-change                                             bgp log-neighbor-changes
graceful-restart                                            bgp graceful-restart
bgp graceful-restart restart-time 120 (default)             bgp graceful-restart stalepath-time 360 (default)
balance n (default=1)                                       maximum-path (dependente do contexto, default=1)
v5: global BGP config
v7: in ipv4 address family
maximum-path n (n=numero de rotas paralelas)                 maximum-path ibgp m 
ebgp-interface-sensitive (default)                           bgp fast-external-fallover (default)
network x.x.x.x y.y.y.y                                      network x.x.x.x mask y.y.y.y
aggregate x.x.x.x y.y.y.y                                    aggregate-addresss x.x.x.x y.y.y.y
aggregate x.x.x.x y.y.y.y detail-suppressed                  aggregate-addresss x.x.x.x y.y.y.y summary-only
import-route static [route-policy name]                      redistribute static [route-map name]
import-route direct [route-policy name]                      redistribute connected [route-map name]
import-route ospf process_id [route-policy name]             redistribute ospf process_id [route-map name]
default-information originate                                 
reflector cluster-id x.x.x.x                                 bgp cluster-id x.x.x.x
dampening                                                    bgp dampening
peer x.x.x.x as-number AS-number                             neighbor x.x.x.x remote-as AS-number
peer x.x.x.x description blabla                              neighbor x.x.x.x description blabla
peer x.x.x.x connect-interface LoopBack0                     neighbor x.x.x.x update-source Loopback0
peer x.x.x.x next-hop-local                                  neighbor x.x.x.x next-hop-self
peer x.x.x.x advertise-community                             neighbor x.x.x.x send-community
peer x.x.x.x password simple|cipher string                   neighbor x.x.x.x password 7 string
(default)                                                    neighbor x.x.x.x version 4 (no negotiation)
peer x.x.x.x ebgp-max-hop                                    neighbor x.x.x.x ebgp-multihop hop_count
peer x.x.x.x preferred-value default_prefval                 neighbor x.x.x.x weight default_weight
peer x.x.x.x default-route-advertise route-policy name       neighbor x.x.x.x default-originate route-map name
peer x.x.x.x timer keepalive keepalive hold holdtime         neighbor x.x.x.x timers keepalive holdtime minholdtime
peer x.x.x.x route-policy name import | export               neighbor x.x.x.x route-map name in | out
peer x.x.x.x public-as-only                                  neighbor x.x.x.x remove-private-as
peer x.x.x.x fake-as AS-number                               neighbor x.x.x.x local-as no-prepend AS-number replace-as
peer x.x.x.x substitute-as                                  
peer x.x.x.x allow-as-loop AS_occurances                     neighbor x.x.x.x allowas-in AS_occurances  
peer x.x.x.x route-limit prefix_number % reconnect restart_interval 
                                              neighbor x.x.x.x maximum-prefix prefix_number % restart restart_interval
peer x.x.x.x reflect-client                                  neighbor x.x.x.x route-reflector-client
peer x.x.x.x ignore                                          neighbor x.x.x.x shutdown
group group_name internal | external                         neighbor group_name peer-group
peer x.x.x.x group group_name                                neighbor x.x.x.x peer-group group_name

compare-different-as-med                                     bgp always-compare-med
bestroute compare-med                                        bgp deterministic-med
bestroute as-path-neglect                                    bgp bestpath as-path ignore

undo default ipv4-unicast                                    no bgp default ipv4-unicast
(Default)                                                    bgp suppress-inactive
peer x.x.x.x capability-advertise orf ip-prefix both         neighbor x.x.x.x capability orf prefix-list both
peer x.x.x.x capability-advertise route-refresh (default)    neighbor x.x.x.x soft-reconfiguration inbound
peer x.x.x.x bfd                                             neighbor x.x.x.x fall-over bfd
peer x.x.x.x route-update-interval timer                     neighbor x.x.x.x advertisement-interval seconds
(iBGP default=5s, eBGP default=30s)                          iBGP default=0s, eBGP (na VRF) default=0s, eBGP default=0s)
peer x.x.x.x next-hop-local                                  neighbor x.x.x.x next-hop-self
peer x.x.x.x capability-advertise orf ip-prefix both         neighbor x.x.x.x capability orf prefix-list both
Deve ser usado no vpnv4 address-family.                      Deve ser usado no vpnv4 address-family.
peer x.x.x.x advertise-ext-community                         neighbor x.x.x.x send-community extended | both
undo peer x.x.x.x enable                                     no neighbor x.x.x.x activate

Verificando a troca de prefixos												
display bgp routing-table peer x.x.x.x received-routes      show ip bgp neighbors x.x.x.x received-routes
display bgp routing-table peer x.x.x.x advertised-routes    show ip bgp neighbors x.x.x.x advertised-routes

MPBGP
display bgp vpnv4 vpn-instance vpn-instance-name routing-table peer x.x.x.x received-routes
show ip bgp vpnv4 vrf vrf-instance-name neighbors x.x.x.x received-routes
display bgp vpnv4 all routing-table peer x.x.x.x received-routes
v5
show ip bgp vpnv4 all neighbors x.x.x.x received-routes

display bgp vpnv4 vpn-instance vpn-instance-name routing-table peer x.x.x.x advertised-routes
show ip bgp neighbors x.x.x.x advertised-routes
display bgp vpnv4 all routing-table peer x.x.x.x advertised-routes
show ip bgp

A utilização de VRFs (Virtual Routing and Forwarding) em Roteadores permite a criação de tabelas de roteamentos virtuais que trabalham de forma independente da tabela de roteamento “normal”, protegendo os processos de roteamento de cada cliente de forma individual.

Empresas que prestam serviços de gerenciamento de rede ou monitoração, empresas que vendem serviços em Data Center e provedores de serviço utilizam largamente VRFs, otimizando assim a administração e o retorno financeiro no total do custo de um projeto.

A configuração de VRFs é bem simples e há um artigo aqui do blog que pode ser consultado no link [http://www.comutadores.com.br/vrf-em-switches-e-roteadores-hpn-vpn-instance/].

Já o Roteamento entre VRFs ocorre quando há a necessidade de comunicarmos diferentes tabelas de roteamento que estão segregadas por VRF, para compartilharem alguns ou todos os prefixos. Há diversas formas de configurarmos o roteamento entre VRFs, como por exemplo com a utilização de um cabo virado para o próprio roteador com as portas em diferente VRFs [apontando assim uma rota para  nexthop da proxima VRF; ou com algum IGP] e também com a utilização de um outro roteador, etc; nesse post explicaremos o roteamento interVRF com o processo MPBGP que é a maneira mais escalável… preparados? Então vamos lá…

Habilitando o import e export das VRFs

Ao configurarmos o processo de roteamento entre VRFs em um mesmo roteador , dois valores de extrema importancia devem ser configurados na VRF: o RD (route distinguisher) e o RT (route target)

RD – Route Distinguisher

Como explicado anteriormente,  as VRFs permitem a reutilização de endereços IP em diferentes tabelas de roteamento. Por exemplo, suponha que você tenha que conectar a três diferentes clientes , os quais estão usando 192.168.1.0/24 em sua rede local. Podemos designar a cada cliente a sua própria VRF de modo que as redes sobrepostas são mantidas isoladas em suas VRFs .

O RD funciona mantendo o controle de quais rotas 192.168.1.0/24 pertencem a cada cliente  como um diferenciador de rota (RD) para cada VRF. O route distinguisher é um número único adiciondo para cada rota dentro de uma VRF para identificá-lo como pertencente a essa VRF ou cliente particular. O valor do RD é carregado juntamente com uma rota através do processo MP- BGP quando o roteador troca rotas VPN com outros Roteadores PE.

O valor RD é de 64 bits e é sugerido a configuração do valor do RD como ASN::nn ou endereçoIP:nn. Mas apesar das sugestões, o valor é apenas representativo.

[R1-vpn-instance-Cliente_A]route-distinguisher ?
  STRING  ASN:nn or IP_address:nn  VPN Route Distinguisher
!
! Configurando a VRF para os clientes A B e C 
ip vpn-instance Cliente_A
 route-distinguisher 65000:1
!
ip vpn-instance Cliente_B
 route-distinguisher 65000:2
!
ip vpn-instance Cliente_C
route-distinguisher 65000:3

Quando rotas VPN são anunciados entre os roteadores PE via MP-BGP, o RD é incluído como parte da rota, juntamente com o prefixo IP. Por exemplo, uma via para 192.0.2.0/24 na VRF Cliente_B é anunciado como 65000:2:192.0.1.0 / 24.

RT – Route-Target ou VPN-target

Considerando que o valor do RD é utilizado para manter a exclusividade entre rotas idênticas em diferentes VRFs, o RT (route target)é utilizado para compartilhar rotas entre eles. Podemos aplicar o RT para uma VRF com o objetivo de controlar a importação e exportação de rotas entre ela e outras VRFs.

O route target assume a forma de uma comunidade BGP estendida com uma estrutura semelhante à de um RD (que é, provavelmente, porque os dois são tão facilmente confundidos).

Segue abaixo um exemplo de configuração, onde o Cliente_A fará o roteamento entre VRFs com o Cliente_B, já o Cliente_C continuará com a sua VRF isolada dos outros clientes.

!
!
ip vpn-instance Cliente_A
 route-distinguisher 65000:1
 vpn-target 65000:1 export-extcommunity
 vpn-target 65000:1 import-extcommunity
 vpn-target 65000:2 import-extcommunity 
!
ip vpn-instance Cliente_B
 route-distinguisher 65000:2
 vpn-target 65000:2 export-extcommunity
 vpn-target 65000:2 import-extcommunity
 vpn-target 65000:1 import-extcommunity  
!
ip vpn-instance Cliente_C
 route-distinguisher 65000:3
 vpn-target 65000:3 export-extcommunity
 vpn-target 65000:3 import-extcommunity
!

Segue abaixo a configuração das interfaces de cada VRF , e o processo MP-BGP responsável por funcionar o import/export de prefixos das VRFs.

!
!
interface Loopback0
 ip address 192.168.1.1 255.255.255.0
!
interface Loopback1
 ip binding vpn-instance Cliente_A
 ip address 1.1.1.1 255.255.255.0
!
interface Loopback2
 ip binding vpn-instance Cliente_B
 ip address 2.2.2.2 255.255.255.0
!
interface Loopback3
 ip binding vpn-instance Cliente_C
 ip address 3.3.3.3 255.255.255.0
!
#
bgp 6500
 undo synchronization
#
 ipv4-family vpn-instance Cliente_A
  import-route direct
#
 ipv4-family vpn-instance Cliente_B
  import-route direct
#
 ipv4-family vpn-instance Cliente_C
  import-route direct
#
!

Segue abaixo os outputs das rotas aprendidas para o roteamento entre VRFs(vpn-instances) e o teste de ICMP

[R1]display ip routing-table vpn-instance Cliente_A
Routing Tables: Cliente_A
        Destinations : 4        Routes : 4
Destination/Mask    Proto  Pre  Cost         NextHop         Interface
1.1.1.1/32          Direct 0    0            127.0.0.1       InLoop0
2.2.2.2/32          BGP    130  0            127.0.0.1       InLoop0
127.0.0.0/8         Direct 0    0            127.0.0.1       InLoop0
127.0.0.1/32        Direct 0    0            127.0.0.1       InLoop0

[R1]ping -vpn-instance Cliente_A 2.2.2.2
  PING 2.2.2.2: 56  data bytes, press CTRL_C to break
    Reply from 2.2.2.2: bytes=56 Sequence=1 ttl=255 time=4 ms
    Reply from 2.2.2.2: bytes=56 Sequence=2 ttl=255 time=10 ms
    Reply from 2.2.2.2: bytes=56 Sequence=3 ttl=255 time=10 ms
    Reply from 2.2.2.2: bytes=56 Sequence=4 ttl=255 time=5 ms
    Reply from 2.2.2.2: bytes=56 Sequence=5 ttl=255 time=4 ms
 --- 2.2.2.2 ping statistics ---
    5 packet(s) transmitted
    5 packet(s) received
    0.00% packet loss
    round-trip min/avg/max = 4/5/10 ms

Segue abaixo a configuração completa do R1

Para dúvidas em sugestões deixe um comentário. Até logo

O algoritmo do BGP não permite que rotas aprendidas via iBGP sejam anunciadas para roteadores vizinhos. Lembrando que uma rota aprendida via eBGP deve ser ensinada para um vizinho iBGP, mas uma rota aprendida via iBGP não deve ser anunciada para roteadores vizinhos.

Quando BGP foi projetado originalmente, não havia nenhuma provisão para a prevenção de loop dentro de um Sistema Autônomo (AS ou ASN). Em vez disso, a regra de prefixos iBGP proíbe o anuncio de rotas aprendidas via iBGP para outro peer BGP interno.

Esta é a razão principal pela qual a inteligência do  BGP necessita de conexões full mesh entre roteadores iBGP, isto é, todos roteadores devem estar conectados entre si. Mas a topologia iBGP com  full mesh, traz  problemas de escalabilidade na configuração, uma vez que o número de sessões para troca de tráfego irá ser N (N-1) / 2, onde N é o número de roteadores internos BGP

Perceba no diagrama abaixo que o prefixo aprendido por R3 via iBGP não é encaminhado para o roteador R4 devido a regra de prefixos aprendidos via iBGP citado acima.

Utilizando Roteadores Refletores (Router Reflectors ou RRs) em uma topologia iBGP, permitirá ao protocolo BGP quebrar a regra de proibição ao ensinar rotas aprendidas via iBGP para vizinhos internos.

Os roteadores configurados como Router Reflector dividem os seus vizinhos iBGP em duas classes: clientes e não-clientes.

As rotas aprendidas por roteadores iBGP clientes serão anunciadas para roteadores clientes e não-clientes. No, entanto as rotas aprendidas a partir de não-clientes serão anunciadas apenas para clientes.

Perceba no diagrama abaixo o prefixo anunciado para o Roteador R4 pelo Roteador R3 configurado como RR.

A configuração do Router Reflector só é necessária no roteador RR “servidor”, nenhuma configuração é necessária nos equipamentos clientes. Segue abaixo a configuração de R3.

! Configuração R3
!
bgp 234
 peer 2.2.2.2 as-number 234
 peer 2.2.2.2 description R2
 peer 2.2.2.2 reflect-client
 peer 2.2.2.2 connect-interface LoopBack1
!

Cluster_List e Originator_ID

A configuração de Route Reflector é geralmente a atribuída a ambientes bem complexos. O BGP utiliza-se de alguns mecanismos para prevenção de loops como Cluster List e Originator ID:

- Cluster ID: O RR adiciona seu cluster ID ao encaminhar o update. Quando recebe um update BGP que contem o seu próprio Cluster ID os prefixos recebidos são descartados, evitando assim o gerar loop  de roteamento pelos anuncios entre clusters.

- Originator ID: Uma lista de clusters (cluster-list) é uma seqüência de cluster-IDs que a rota atravessou. Quando um RR reflete uma rota de seus clientes para non-clients fora do cluster, ele adiciona o cluster-id local no final da cluster-list. Usando este atributo, um RR pode identificar se uma informação de roteamento fez um loop e voltou ao mesmo cluster que a originou (por alguma falha de configuração). Se o cluster-id local é encontrado na cluster-list, o anúncio da rota será descartado.

Conforme diagrama abaixo, segue um exemplo do output com a lista do Cluster list:

[R1]display bgp routing-table 55.55.55.0
 BGP local router ID : 1.1.1.1
 Local AS number : 234
 Paths:   1 available, 1 best
BGP routing table entry information of 55.55.55.0/24:
 RR-client route.
 From            : 4.4.4.4 (4.4.4.4)
 Relay Nexthop   : 192.168.45.5
 Original nexthop: 2.2.2.2
 AS-path          : 5
 Origin          : igp
 Attribute value : MED 0, localpref 100, pref-val 0, pre 255
 State           : valid, internal,
 Originator      : 2.2.2.2
 Cluster list    : 0.0.0.2, 0.0.0.1

Segue abaixo a configuração de R3 e R4 (lembrando que nenhuma configuração BGP adicional é necessária para o Roteador cliente Router Reflector

#
! Configuração R3
router bgp 234
 bgp cluster-id 1
 neighbor 2.2.2.2 remote-as 234
 neighbor 2.2.2.2 description R2
 neighbor 2.2.2.2 update-source Loopback1
 neighbor 2.2.2.2 route-reflector-client
!
 neighbor 4.4.4.4 remote-as 234
 neighbor 4.4.4.4 description R4
 neighbor 4.4.4.4 update-source Loopback1
!

#
! Configuração R4
router bgp 234
 bgp cluster-id 2
 neighbor 1.1.1.1 remote-as 234
 neighbor 1.1.1.1 description R1
 neighbor 1.1.1.1 update-source Loopback1
 neighbor 1.1.1.1 route-reflector-client
!
 neighbor 3.3.3.3 remote-as 234
 neighbor 3.3.3.3 description R3
 neighbor 3.3.3.3 update-source Loopback1
!

Até logo

Referências

http://blog.ipexpert.com/2012/02/20/understanding-bgp-originator-id-and-cluster-id/#top

http://www.rnp.br/newsgen/0109/bgp4_dicas2.html#ng-6

http://www.rotadefault.com.br/teste-mesa-para-router-reflectors/

http://www.rotadefault.com.br/resumo-bgp-router-reflectors/

CCIE Routing and Switching Certification Guide, 4th Edition, Cisco Press, Wendell Odom, Rus Healy, Denise Donohue

O protocolo OSPF permite a todos roteadores em uma área a visão completa da topologia. O protocolo possibilita assim a decisão do caminho mais curto baseado no custo que é atribuído a cada interface, com o algoritmo Dijkstra. O custo de uma rota é a soma do custos de todas as interfaces de saída para um destino. Por padrão, os roteadores calculam o custo OSPF baseado na fórmula Cost =Reference bandwidth value / Link bandwidth.

Caso o valor da “largura de banda de referência” não seja configurado os roteadores usarão o valor de 100Mb para cálculo. Por exemplo, se a interface for 10Mb, calcularemos 100Mb dividido por 10Mb, então o custo da interface será 10. Já os valores fracionados, serão arredondados para valor inteiro mais próximo e toda velocidade maior que 100Mb será atribuido o custo 1.

Veja no exemplo abaixo:

O custo do Roteador R1 para os Roteadores vizinho é 1.

O mesmo para a interface loopback de R2 (o comware não adiciona o custo para as interfaces loopback)

Se por algum motive houver a necessidade de manipulação do roteamento para a interface Ge0/0/3(Roteador R3) basta aumentar o custo do OSPF na interface Ge0/0/2 para que a interface Ge0/0/3 tenha o menor custo para a rede 2.2.2.2.

Interface GigabitEthernet0/0/2
ospf cost 20
! Alterando o custo da interface para 20

Caso seja necessário alterar a referência para largura de banda utilize o seguinte comando em um roteador HP Comware.

O “bandwidth- reference 100″ é o default para 100Mb, onde 100Mb na topologia tem o custo = 1 .

Assim, para ter links 1G com o custo = 1 , o “auto-cost…” deve ser configurado como 1000. Se a referência for links 10G , “auto-cost…” seria 10000 , para 100G, seria 100000 .

Obs: Lembre-se de sempre manter o bandwidth- reference consistente em todos os roteadores para evitar comportamentos inesperados no roteamento.

Até logo

A utilização de VRFs (Virtual Routing and Forwarding ou vpn-instance na linguagem HP) em Roteadores permite a criação de tabelas de roteamentos virtuais que trabalham de forma independente da tabela de roteamento “normal”, protegendo os processos de roteamento de cada cliente de forma individual.

Como nós explicamos anteriormente no post http://www.comutadores.com.br/roteamento-entre-vrfs-com-mp-bgp-em-roteadores-hp-h3c/ o rotemento entre VRFs (quando necessário) pode ser efetuado com a manipulação do  route-targets (RT) com o processo MP-BGP ativo no Roteador.

Há também cenários em que é necessário a troca seletiva de prefixos de rede entre as tabelas de roteamento virtuais, escolhendo quais redes devem ser exportardas ou não entre as VRFs. Lembrando que os valores vpn-target (route-target) trabalham com as Extended community do BGP para troca de prefixos entre VRFs,  é possível manipular o processo via route-policy (route-map), configurando a “comunidade estendida” para o prefixo e utilizando o comando export dentro da VRF.

Relembrando…

No diagrama abaixo há 2 VRFs já configuradas (com o processo MP-BGP ativo) e com seus respectivos prefixos.

Como os valores para import/export das VRFs não são os mesmos, não há roteamento entre as VRFs (cada VRF tem o seu roteamento isolado). Configuração do 1º exemplo

No exemplo abaixo, caso manipulassemos o import/export, teríamos as 2 tabelas de roteamento compartilhadas… Configuração do 2º exemplo

Mas imaginem que a VRF Client_B, por questões de segurança no roteamento, não precissasse ensinar os prefixos 172.16.2.0/24 e 172.16.3.0/24 para a VRF Client_A mas somente o prefixo 172.16.1.0/24…. Nesse caso precisaríamos configurar o roteamento seletivo para que a VRF Client_A aprenda somente os prefixos necessários.

Ja a VRF Client_A exportará todos os prefixos sem filtros para a Client_B

Utilizaremos no exemplo o valor da Extended Community 65000:12 para exportar o prefixo 172.16.1.0/24.

ip ip-prefix Client_B_prefixo index 5 permit 172.16.1.0 24
! Selecionando o prefixo via prefix-list
!
route-policy Client_B_export permit node 10
 if-match ip-prefix Client_B_prefixo
 apply extcommunity rt 65000:12  additive
#
! Configurando a community estendida via Route-map
!
ip vpn-instance Client_B
 export route-policy Client_B_export
 quit
! Configurando o export seletivo de prefixo
end
!

A configuração dos 3º cenário pode ser encontrada aqui

Obs: O mesmo controle pode ser feito para os prefixos de entrada, utilizando o “import map”

Dúvidas , deixe um comentario

Referência: http://www.rotadefault.com.br/roteamento-seletivo-entre-vrfs-com-export-map/

Para aqueles que estão sofrendo um pouco com a mudança de alguns comandos entre o Comware 7 e o Comware 5, a HP disponibilizou um documento chamado “HP Comware 5 to Comware 7 – CLI migration guide”. O Documento prioriza a configuração de features para BGP, interfaces CT1/PRI, T1-F, protocolo PPP, configurações de AAA, RADIUS e TACACS.

http://www8.hp.com/h20195/v2/GetDocument.aspx?docname=4AA5-5812ENW

Se o link estiver quebrado, deixe um comentário d.

O HP VSR1000 é um roteador desenvolvido para rodar em VM, provendo as mesmas funções de um roteador físico com o Comware 7.  O VSR (Virtual Service Router) funciona nas plataformas VMWare ESXi ou Linux KVM no servidor físico e dependendo da licença permite a utilização de 1 a 8 CPUs.

Por algumas limitações de cenários dos emuladores de Comware, tenho utilizado o HP VSR1000 também em diversos testes de ambientes de laboratório.

O Link para download do VSR1000 (obs: estou utilizando o release VSR1000_7.10.R0204P01)

https://h10145.www1.hp.com/Downloads/SoftwareReleases.aspx?ProductNumber=JG813AAE&lang=en&cc=us&prodSeriesId=5443163

O software do HP VSR1000 pode ser baixado gratuitamente com liberdade para uso de todas as features com a performance limitada a 5Kpps. O período trial dura 60 dias (para utilização de 1 CPU).

A página do fabricante sobre VSR100 é http://www8.hp.com/us/en/products/networking-routers/product-detail.html?oid=5443163#!tab=features

Se o link estiver quebrado, deixe um comentário.

Abraços

As configurações do BGP via CLI para os equipamentos baseados no Comware 7 diferem um pouco em relação aos Switches e Roteadores baseados no Comware 5.

Se você quiser saber um pouco mais sobre como funciona  o BGP, temos alguns artigos no blog. Os principais são:
http://www.comutadores.com.br/switches-3com-4800g-configuracao-basica-do-bgp/
http://www.comutadores.com.br/resumo-sobre-border-gateway-protocol-bgp-mase-parte1/

Basicamente para o Comware 7, uma vez dentro do processo BGP, basta habilitar o ‘peering’ com o roteador vizinho normalmente, mas a grande diferença está no anuncio de prefixos, pois uma vez que você necessite anunciar prefixos IPv4 ou IPv6, será necessário entrar no address-family, ativar o peering e aplicar o comando network, import (redistribute) etc.

Para ficar mais fácil, veja o exemplo abaixo o peering eBGP entre o Roteador R1 (AS 100) e R4 (AS 400):

<R1> display current-configuration configuration bgp
bgp 100
peer 10.0.0.2 as-number 400
#
 address-family ipv4 unicast
    network 192.168.1.0 255.255.255.0
    peer 10.0.0.2 enable 
   
<R4> display current-configuration configuration bgp
bgp 400
peer 10.0.0.1 as-number 100
#
 address-family ipv4 unicast
  network 192.168.2.0 255.255.255.0
  peer 10.0.0.1 enable  

O ponto mais importante dessa configuração é definir o IPv4 unicast address family e ativar o peer. Perceba que as redes deverão ser anunciadas dentro do address family correto.
Para validar o peering:

<R1>display bgp peer ipv4 unicast
BGP local router ID: 192.168.1.1
Local AS number: 100
Total number of peers: 1 Peers in established state: 1
* - Dynamically created peer
Peer     AS   MsgRcvd MsgSent OutQ PrefRcv Up/Down State
10.0.0.2 400   125     118     0    2       01:47:39 Established

IPv6
O mesmo vale se o peering e/ou prefixos for para endereços IPV6

<R4>display current-configuration configuration bgp
#
bgp 400
 peer 2001:DB8:14::1 as-number 100
 #
  address-family ipv6 unicast
   network 2001:DB8:4:: 64
   network 2001:DB8:44:: 64
   peer 2001:DB8:14::1 enable

Para validar o peering BGP com endereço IPv6:

 <R4>display bgp peer ipv6 unicast
 BGP local router ID: 192.168.44.4
 Local AS number: 400
 Total number of peers: 1          Peers in established state: 1
  * - Dynamically created peer
Peer             AS  MsgRcvd  MsgSent OutQ PrefRcv Up/Down  State

2001:DB8:14::1   100 60       60      0     2 00:47:40 Established

Para validar a tabela BGP basta preencher conforme o output abaixo: IPv4, IPv6, vpnv4, vpnv6, etc..

<R4>display bgp routing-table ?
  dampened   Display dampened BGP routes
  flap-info  Display BGP route flap information
  ipv4       Specify the IPv4 address Family
  ipv6       Specify the IPv6 address Family
  vpnv4      Specify the VPNv4 address family
  vpnv6      Specify the VPNv6 address family

Até logo.

Galera segue um passo-a-passo para a instalação do roteador HP VSR1000 no VMWare Workstation versão 9. Para mais informações sobre o HP VSR 1000 acesse: http://www.comutadores.com.br/hp-vsr1000-virtual-service-router/

O download do VSR100 pode ser feito no site https://h10145.www1.hp.com/Downloads/SoftwareReleases.aspx?ProductNumber=JG813AAE&lang=en&cc=us&prodSeriesId=5443163

1. No VMWare Workstation clique em “File” e “New virtual Machine…“. Depois escolha a opção “Custom (Advanced)”, clique em next e next.
2. Escolha o diretório que para instalar a imagem ‘.iso’ e avance.

3. Em ‘Select a Guest Operating Sytem” Escolha a opção “Other”, “FreeBSD” e avance.

4. Escolha o nome da sua máquina virtual, depois escolha o diretório para salvar e avance.
5. Escolha a quantidade de processadores.

Obs: O software do HP VSR1000 pode ser baixado gratuitamente com liberdade para uso de todas as features com a performance limitada a 5Kpps. O período trial dura 60 dias (para utilização de 1 CPU).

6. Para a quantidade de memória escolhi 1024 para fazer o lab. Defina e clique em “Next”.
7. Em “Network type”, utilizei “bridged networking”
8. Em “Select I/O Controller Types”, selecione “LSI Logic”

9. Em “Select a Disk type” escolha “SCSI”.
10. Em “Select a Disk”, escolha “Create a New Virtual Disk”.
11. Em “Specify Disk Capaciy”, escolhi 8Gb de memória e “Split virtual disk into multiple files”.

12. …clique em Next..

13. Antes de finalizar, vá para “Customize Hardware” para adicionar as interfaces GigabitEthernet.

Repita o processo para quantas interfaces você desejar.

obs:Tenho utilizado 4 interfaces para Lab.

14. Clique em Finish..

15. Após iniciar a VM.. escolha Fresh Install, yes e yes.

Após finalizar o processo inicial de instalação já é possível utilizar o HP VSR 1000

Comunicação com a LAN

Se estiver com problemas de comunicação com a rede local abra o “Virtual Network Editor” e escolha a interface para saída. No meu caso para o Lab eu escolhi a minha interface Wireless.

Espero ter ajudado.

Abração

Os novos Roteadores MSR da HP possuem suporte para a configuração em IRF. O IRF é uma tecnologia que permite transformarmos diversos Switches ou Roteadores físicos em um único equipamento lógico. Todos os equipamentos serão visualizados como uma única “caixa”, aumentando a disponibilidade da rede.

A recomendação é efetuar o IRF com equipamentos da mesma família e modelo, mas há dispositivos que suportam equipamento da mesma família, mas com diferentes modelos. É bom pesquisar caso a caso.

O cenário abaixo foi construído utilizando o simulador HCL utilizando 2 Roteadores em IRF conectando um Router-Aggregation com um Switch 5820.

Configurando o IRF

Segue abaixo o passo-a-passo da configuração:

1º altere o irf-member ID do segundo Roteador (por padrão o member ID é 1) e o priority de cada equipamento para eleição do Master (vence o maior valor).

R1
<ROUTER>system
[ROUTER]irf priority 31

R2
<ROUTER>system
[ROUTER]irf member 2
[ROUTER]irf priority 30

Configurando as IRF-port

R1
[ROUTER]irf-port 1
[ROUTER-irf-port1]port group interface GigabitEthernet 0/0
[ROUTER-irf-port1]quit

R2
[ROUTER]irf-port 2
[ROUTER-irf-port2]port group interface GigabitEthernet 0/0
[ROUTER-irf-port2]quit

Habilitando o IRF

R1
[ROUTER]chassis convert mode irf
The device will switch to IRF mode and reboot.
You are recommended to save the current running configuration and specify the configuration file for the next startup. Continue? [Y/N]:y
Do you want to convert the content of the next startup configuration file flash:/startup.cfg to make it available in IRF mode? [Y/N]:y
Now rebooting, please wait...

R2
[ROUTER]chassis convert mode irf
....

Comandos display

[ROUTER]display irf

MemberID   Role   Priority CPU-Mac       Description
*+1       Master 31       90eb-4082-0100 ---
2       Standby 30       94cc-d87d-0200 ---
--------------------------------------------------
* indicates the device is the master.
+ indicates the device through which the user logs in.
The Bridge MAC of the IRF is: 90eb-4082-0100
Auto upgrade               : yes
Mac persistent             : 6 min
Domain ID                   : 0
Auto merge                 : yes

 

[ROUTER]display irf configuration
MemberID NewID   IRF-Port1                    IRF-Port2
1       1       GigabitEthernet1/0/0         disable
2       2       disable                       GigabitEthernet2/0/0

 

Configurando o Router-Aggregation nos MSRs em IRF

[ROUTER]interface Route-Aggregation 1
[ROUTER-Route-Aggregation1]link-aggregation mode dynamic
[ROUTER-Route-Aggregation1]ipv6 address 2001:db8:1234::a 64
[ROUTER-Route-Aggregation1]disp this

#
interface Route-Aggregation1
link-aggregation mode dynamic
ipv6 address 2001:DB8:1234::A/64
#
return
[ROUTER-Route-Aggregation1]quit

[ROUTER]interface GigabitEthernet 1/0/1
[ROUTER-GigabitEthernet1/0/1]port link-aggregation group 1
[ROUTER-GigabitEthernet1/0/1]interface GigabitEthernet 2/0/1
[ROUTER-GigabitEthernet2/0/1]port link-aggregation group 1
[ROUTER-GigabitEthernet2/0/1]end

Configuração do Switch

#
interface Bridge-Aggregation1
link-aggregation mode dynamic
#
#
interface GigabitEthernet1/0/1
port link-mode bridge
combo enable fiber
port link-aggregation group 1
#
interface GigabitEthernet1/0/2
port link-mode bridge
combo enable fiber
port link-aggregation group 1
#
interface Vlan-interface1
ipv6 address 2001:DB8:1234::B/64
#
[Router]disp link-aggregation verbose
Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing
Port Status: S -- Selected, U -- Unselected, I – Individual
Flags: A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,
D -- Synchronization, E -- Collecting, F -- Distributing,
G -- Defaulted, H -- Expired

Aggregate Interface: Route-Aggregation1
Aggregation Mode: Dynamic
Loadsharing Type: Shar
System ID: 0x8000, 90eb-4082-0100

Local:
Port             Status Priority Oper-Key Flag
--------------------------------------------------------------------------------
GE1/0/1         S       32768   1        {ACDEF}
GE2/0/1         S       32768   1         {ACDEF}
Remote:
Actor           Partner Priority Oper-Key SystemID               Flag
--------------------------------------------------------------------------------
GE1/0/1         3       32768   1         0x8000, 94de-65c3-0300 {ACDEF}
GE2/0/1         2       32768   1         0x8000, 94de-65c3-0300 {ACDEF}

 

[Router]ping ipv6 2001:db8:1234::b
Ping6(56 data bytes) 2001:DB8:1234::A --> 2001:DB8:1234::B, press CTRL_C to break
56 bytes from 2001:DB8:1234::B, icmp_seq=0 hlim=64 time=2.000 ms
56 bytes from 2001:DB8:1234::B, icmp_seq=1 hlim=64 time=1.000 ms
56 bytes from 2001:DB8:1234::B, icmp_seq=2 hlim=64 time=0.000 ms
56 bytes from 2001:DB8:1234::B, icmp_seq=3 hlim=64 time=1.000 ms
56 bytes from 2001:DB8:1234::B, icmp_seq=4 hlim=64 time=1.000 ms

--- Ping6 statistics for 2001:db8:1234::b ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.000/1.000/2.000/0.632 ms
[Router]%Jan 26 13:40:07:783 2016 Router PING/6/PING_STATISTICS: Ping6 statistics for
2001:db8:1234::b: 5 packets transmitted, 5 packets received, 0.0% packet loss, round-trip
min/avg/max/std-dev = 0.000/1.000/2.000/0.632 ms.

Até logo

O Fax (abreviação de fac-símile) é a transmissão telefônica de material impresso digitalizado (texto e imagens), normalmente para um número de telefone conectado a uma impressora ou outro dispositivo de saída.

O protocolo T.38 permite transmitir mensagens de fax através de uma rede IP em tempo real (na velocidade da transmissão). Os aparelhos de FAX não necessariamente precisam obter informações sobre a rede e podem continuar a enviar as suas mensanges no padrão T.30.

O padrão T.38 Fax Relay foi concebido em 1998 como uma maneira de permitir que a mensagem via fax a seja transportadas através de redes IP entre terminais de fax existentes no padrão do Grupo 3.

Existem outros protocolos de envio de FAX sobre IP mas o padrão do ITU é o T.38.

Como T.38 Fax Relay funciona?

Os dados modulados pelo fax analógico são digitalizados pelo DSP (Digital Signal Processor) no gateway e as informações são geradas em binário.

A informações em binário são encapsuladas no pacote T.38 e então transportada pela rede IP.

O DSP no gateway de destino extrai a informação transportada pelo pacote T.38 e modula dentro do sinal de fax analógico tradicional.

Configuração

No exemplo abaixo utilizaremos o mesmo exemplo do Configuration Guide do MSR 3012 para Voz, utilizando SIP entre duas localidades.

<RouterA> system-view
[RouterA] voice-setup
[RouterA-voice] dial-program
[RouterA-voice-dial] entity 2000 voip
[RouterA-voice-dial-entity2000] match-template 2000
[RouterA-voice-dial-entity2000] address sip ip 10.2.2.2
[RouterA-voice-dial-entity2000] fax protocol standard-t38 ls-redundancy 4
[RouterA-voice-dial-entity2000] quit
[RouterA-voice-dial] entity 1000 pots
[RouterA-voice-dial-entity1000] match-template 1000
[RouterA-voice-dial-entity1000] line 2/1/1
[RouterA-voice-dial-entity1000] fax protocol standard-t38 ls-redundancy 4
####
<RouterB> system-view
[RouterB] voice-setup
[RouterB-voice] dial-program
[RouterB-voice-dial] entity 1000 voip
[RouterB-voice-dial-entity1000] match-template 1000
[RouterB-voice-dial-entity1000] address sip ip 10.1.1.1
[RouterB-voice-dial-entity1000] fax protocol standard-t38 ls-redundancy 4
[RouterB-voice-dial-entity1000] quit
[RouterB-voice-dial] entity 2000 pots
[RouterB-voice-dial-entity2000] match-template 2000
[RouterB-voice-dial-entity2000] line 2/1/1
[RouterB-voice-dial-entity2000] fax protocol standard-t38 ls-redundancy 4

Para visualizar as estatísticas utilize os comandos:

display voice fax statistics
reset voice fax statistics

Até logo

Referências

https://www.youtube.com/watch?v=GkVUGeaIXjg

HPE FlexNetwork MSR Router Series – Voice – Configuration Guide Document version: 6PW104-20151118

https://en.wikipedia.org/wiki/T.38

O atributo BGP Preferred_value permite ao roteador examinar internamente as atualizações BGP decidir a rota preferêncial.

O atributo não é encaminhado nas mensagens BGP e possui apenas função local em um roteador. Para aqueles que estão acostumados a configuração do protocolo BGP em roteadores Cisco com IOS, a funcionalidade é idêntica a configuração BGP weight, que é proprietária.

O Preferred_value é eficiente quando há a necessidade de manipular um destino na saída de um AS, em meio múltiplas rotas.

Vence a rota com maior valor do Preferred_value e é possível configurar valores entre 0 e 65535.

Por padrão os prefixos aprendidos via eBGP possuem o valor como 0 e o Preferred_Value é o parâmetro preferencial para escolha da melhor rota.

Seleção de rotas BGP

Segue abaixo a lista com a ordem para escolha da melhor rota na tabela BGP:

1. Seleciona a rota com maior preferred_value (similar ao weight da Cisco).
2. Seleciona a rota com maior Local_Pref.
3. Seleciona a rota originada pelo roteador local.
4. Seleciona a rota com menor AS-Path.
5. ….

Exemplo de Configuração

No exemplo abaixo iremos manipular o roteamento do AS 64507 para o prefixo 2001:db8:3::/64 anunciado pelo AS 64500, para o roteador RA escolher o caminho via RC (next-hop 2001:db8:13::3). O exemplo de configuração é o mesmo para os prefixos IPv4.

Script de configuração de um roteador MSR com o Comware 7

ipv6 prefix-list abc index 10 permit 2001:DB8:3:: 64
! Configurando a prefix-list da rede 2001:db8::3/64
#
route-policy SET_PV permit node 10
 if-match ipv6 address prefix-list abc
 apply preferred-value 200
! Criando a route-map para aplicar o Preferred_value 200 a prefix-list abc
#
bgp 64507
 peer 2001:DB8:12::2 as-number 64500
 peer 2001:DB8:13::3 as-number 64500
 #
 address-family ipv6 unicast
  network 2001:DB8:1:: 64
  peer 2001:DB8:12::2 enable
  peer 2001:DB8:13::3 enable
  peer 2001:DB8:13::3 route-policy SET_PV import
! Aplicando a route-policy SET_PV para os prefixos aprendidos pelo peer
#

Verificando a tabela de roteamento

[RA]display bgp routing-table ipv6
 Total number of routes: 3

 BGP local router ID is 192.168.11.1
 Status codes: * - valid, > - best, d - dampened, h - history,
               s - suppressed, S - stale, i - internal, e – external
               Origin: i - IGP, e - EGP, ? - incomplete
* >e Network : 2001:DB8:2::                            PrefixLen : 64
     NextHop : 2001:DB8:12::2                          LocPrf    :
     PrefVal : 0                                       OutLabel  : NULL
     MED     : 0
     Path/Ogn: 64500i
* >e Network : 2001:DB8:3::                             PrefixLen : 64
     NextHop : 2001:DB8:13::3                           LocPrf    :
     PrefVal : 200                                      OutLabel  : NULL
     MED     : 0                                     
     Path/Ogn: 64500i
*  e Network : 2001:DB8:3::                             PrefixLen : 64
     NextHop : 2001:DB8:12::2                           LocPrf    :
     PrefVal : 0                                        OutLabel  : NULL
     MED     :
     Path/Ogn: 64500i

Veja que a rota “best” para o prefixo 2001:db8:3::/64 está com o Preferred_value como 200.

Até logo

O atributo do BGP community é utilizado como para marcação para um determinado grupo de rotas. Provedores de Serviço utilizam essas marcações para aplicar políticas de roteamento específicas em suas redes, como por exemplo, alterando o Local Preference, MED, etc. O atributo simplifica a configuração das políticas de roteamento, gerenciamento e manutenção.

Os ISP’s podem também estabelecem um mapeamento de community com o cliente ou com outro provedor para que sejam aplicadas regras de roteamento.

O recebimento e envio de communities BGP em Roteadores HP necessitam da configuração explicita do comando advertise-community. No exemplo abaixo, segue a configuração de um peer BGP em um roteador com o Comware 7:

bgp 65500
 group AS65500 internal
 peer AS65500 connect-interface LoopBack1
 peer 192.168.2.2 group AS65500
 #
 address-family ipv4 unicast
  peer AS65500 enable
  peer AS65500 advertise-community
#

O atributo community é opcional e transitivo (optional transitive) de tamanho variável. O atributo consiste em um conjunto de 4 octetos ou um número de 32 bits que específica uma community. A representação de uma community BGP é geralmente feita no formato AA:NN onde o AA é o Autonomous System (AS) e o NN é o número da community.

Algumas communities tem significados pré-definidos como:

• NO_EXPORT (0xFFFFFF01)
• NO_ADVERTISE (0xFFFFFF02)
• NO_EXPORT_SUBCONFED (0xFFFFFF03)

-A community  NO_EXPORT  diz ao roteador que ele deve  propagar os prefixos somente dentro de peers iBGP e que não deve propagar esses prefixos para roteadores pares eBGP.

-A community NO_EXPORT_SUBCONFED possui as mesmas funcionalidades do NO_EXPORT dentro de cenários com confederation.

-A community NO_ADVERTISE  diz ao roteador que ele não deve anunciar o prefixo para nenhum peer BGP.

Abaixo, deixamos um exemplo de configuração utilizando a community NO_EXPORT e o output:

R1	
#
 ip prefix-list COMM_iBGP index 10 permit 192.168.11.0 24
#
route-policy SET_COMM permit node 5
 if-match ip address prefix-list COMM_iBGP
 apply community no-export
#
route-policy SET_COMM permit node 65535
#
#
bgp 65500
 group AS65500 internal
 peer AS65500 connect-interface LoopBack1
 peer 192.168.2.2 group AS65500
 #
 address-family ipv4 unicast
  network 192.168.11.0 255.255.255.0
  network 192.168.111.0 255.255.255.0
  peer AS65500 enable
  peer AS65500 route-policy SET_COMM export
  peer AS65500 advertise-community
#

Verificando no Roteador R2 a marcação enviada por R1 para o prefixo 192.168.11.0/24 :

[R2]display bgp routing-table ipv4 192.168.11.0
 BGP local router ID: 192.168.22.2
 Local AS number: 65500
 Paths:   1 available, 1 best
 BGP routing table information of 192.168.11.0/24:
 From            : 192.168.1.1 (192.168.11.1)
 Rely nexthop    : 192.168.12.1
 Original nexthop: 192.168.1.1
 OutLabel        : NULL
 Community       : No-Export
 AS-path         : (null)
 Origin          : igp
 Attribute value : MED 0, localpref 100, pref-val 0
 State           : valid, internal, best
 IP precedence   : N/A
 QoS local ID    : N/A
 Traffic index   : N/A

Configurando os valores manualmente…

Um prefixo pode também participar de mais de uma community e com isso um roteador pode tomar uma ação em relação ao prefixo baseado em uma (algumas) ou todas as communities associadas ao prefixo. O roteador tem a opção de manter, adicionar ou modificar o atributo antes de passar para os outros roteadores.

#
 ip prefix-list COMM_eBGP index 10 permit 192.168.111.0 24
 ip prefix-list COMM_iBGP index 10 permit 192.168.11.0 24
#
route-policy SET_COMM permit node 5
 if-match ip address prefix-list COMM_iBGP
 apply community no-export
#
route-policy SET_COMM permit node 10
 if-match ip address prefix-list COMM_eBGP
 apply community 65500:90
#
route-policy SET_COMM permit node 65535
#
bgp 65500
 group AS65500 internal
 peer AS65500 connect-interface LoopBack1
 peer 192.168.2.2 group AS65500
 #
 address-family ipv4 unicast
  network 192.168.11.0 255.255.255.0
  network 192.168.111.0 255.255.255.0
  peer AS65500 enable
  peer AS65500 route-policy SET_COMM export
  peer AS65500 advertise-community
#

Verificando a marcação enviada por R1 do prefixo 192.168.111.0/24:

[R4] display bgp routing-table ipv4 192.168.111.0
 BGP local router ID: 192.168.44.4
 Local AS number: 65507
 Paths:   1 available, 1 best
 BGP routing table information of 192.168.111.0/24:
 From            : 192.168.24.2 (192.168.22.2)
 Rely nexthop    : 192.168.24.2
 Original nexthop: 192.168.24.2
 OutLabel        : NULL
 Community       : <65500:90>
 AS-path         : 65500
 Origin          : igp
 Attribute value : pref-val 0
 State           : valid, external, best
 IP precedence   : N/A
 QoS local ID    : N/A
 Traffic index   : N/A

Em resumo, as operadoras utilizam communities BGP para manipulação de grande quantidade de prefixos para fins de políticas de roteamento, blackhole, etc. Grandes corporações também as utilizam para identificação de rotas de empresas filiais, rotas aprendidas em fusões com outras empresas,  políticas de roteamento, redes de serviço e mais.

Referências

http://babarata.blogspot.com.br/2010/05/bgp-atributo-community.html

http://www.noction.com/blog/understanding_bgp_communities

O desenho de uma rede OSPF requer que todas as áreas estejam diretamente conectadas à Area Backbone (Area 0 [zero]) e que os roteadores da Area 0 estejam sempre conectados com roteadores da mesma área.

Para conexão entre roteadores de diferentes áreas, o tráfego deve passar sempre pela Area 0.

Um virtual link é um link lógico que permite a conexão entre equipamentos da Area 0 que estão separados logicamente mas podem utilizar uma outra Area OSPF como trânsito, ou entre áreas não-Backbone que precisam utilizar outra área como transito:

O OSPF virtual link deve ser usado somente em casos específicos, conexões temporárias ou cenários de backup em caso de falha.

Configurando OSPF Virtual link

No exemplo abaixo, o virtual link servirá na conexão entre dois roteadores da Area 0 que estão separados por uma falha no link.

R1
#
ospf 1
  area 0.0.0.0
  network 192.168.1.0 0.0.0.255
  network 192.168.11.0 0.0.0.255
 area 0.0.0.1
  network 192.168.12.0 0.0.0.255
  vlink-peer 192.168.3.3
#
R3
#
ospf 1
 area 0.0.0.0
  network 192.168.3.0 0.0.0.255
  network 192.168.33.0 0.0.0.255
 area 0.0.0.1
  network 192.168.23.0 0.0.0.255
  vlink-peer 192.168.1.1
#

Comandos display

[R1]display  ospf vlink
         OSPF Process 1 with Router ID 192.168.1.1
                 Virtual Links
 Virtual-link Neighbor-ID  -> 192.168.3.3, Neighbor-State: Full
 Interface: 192.168.12.1 (GigabitEthernet0/0)
 Cost: 2  State: P-2-P  Type: Virtual
 Transit Area: 0.0.0.1
 Timers: Hello 10, Dead 40, Retransmit 5, Transmit Delay 1

#
 [R1]display ospf peer
         OSPF Process 1 with Router ID 192.168.1.1
               Neighbor Brief Information
 Area: 0.0.0.1
 Router ID       Address         Pri Dead-Time  State             Interface
 192.168.12.2    192.168.12.2    1   35         Full/DR           GE0/0
 Virtual link:
 Router ID       Address         Pri Dead-Time  State             Interface
 192.168.3.3     192.168.23.3    1   36         Full              GE0/0

Até breve