Blog Archives

Resumo: BGP – Router Reflector em Roteadores HP

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.

iBGP rule HP

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.

iBGP rule and RR HP

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:

Router Reflector cluster id HP

[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

Roteamento entre VRFs com MP-BGP em Roteadores HP / H3C

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.

VRFs Comware

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
!

Inter VRF Routing

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 ;)

Dicionário de Comandos BGP: Comware vs Cisco

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

Comandos comparativos para Troubleshooting, Reset e Refresh do BGP : Comware v5 x IOS Cisco

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

Video: Roteamento entre VLANs e configuração de rota estática para Switches HPN, 3Com e H3C

Fala Galera, tudo bom!?

Segue mais uma vídeo-aula produzida por nós, contendo dessa vez o assunto Roteamento entre VLANs utilizando Switches ou Roteadores, além de falarmos também sobre roteamento estático, Topologia, etc.. para equipamentos baseados no Comware (HP , 3Com e H3C) .

Ainda estou apanhando um pouco no formado das vídeo-aulas, mas espero que o vídeo seja útil. ;)




Abração

Roteadores HP 6600 – MPLS L2VPN com Martini através de um Túnel GRE

O script abaixo permite a extensão de um domínio de Broadcast através de uma rede IP utilizando o protocolo MPLS sobre um Túnel GRE sem a utilização de BGP em um roteador HP 6600.

Utilizei o cenário durante uma demanda para a extensão de um domínio de Broadcast entre 2 Data Centers Pares em quem o link dedicado para o Serviços de Computação em Nuvem sofreu atraso. O sincronismo dos Serviços  utilizando a camada de enlace (camada 2 do modelo OSI) foi estabelecido com a solução abaixo, visto que haviam restrições para configurar o mesmo serviço com MP-BGP por políticas de roteamento.

A solução permite o trânsito de quadros tagueados com 802.1q.

Obs: Antes de estabelecer o túnel GRE, certifique que as interfaces Loopback estejam acessíveis via Roteamento.

MPLS L2VPN Martini atraves de GRE

Espero ter sido útil. :)

Roteador HP 6600 – Configurando MPLS L2VPN com Kompella para conexões locais

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 .Kompella local connection fisico
Kompella local connection

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!

Roteadores HP 6600 – Protocolo de Tunelamento GRE

O GRE (Generic Routing Encapsulation) é um protocolo de tunelamento que pode encapsular diversos protocolos dentro de túneis IP, criando links ponto-a-ponto virtuais entre roteadores remotos.

O protocolo é extremamente funcional em diversos cenários, pois foi desenvolvido para permitir que redes remotas pareçam estar diretamente conectadas. Como GRE não criptografa as informações que são transmitidas através do túnel, podemos utilizar o GRE em conjunto com IPsec para garantir a integridade das informações.

Abaixo podemos observar a representação de encapsulamento  de um pacote IP pelo GRE e a  inclusão de um novo cabeçalho.

GRE header

O interessante é que o protocolo de transporte poderia ser o IPv6 e o protocolo encapsulado  poderia ser o IPX, tráfego Multicast, etc; E ao ser entregue ao roteador de destino, o novo cabeçalho é removido e o pacote é entregue intacto.

Agora você deve estar se perguntando. Em quais situações podemos usar o GRE ? Veja  o cenário:

GRE HPN cenario

Você em um dia normal como analista de redes e seu gerente de TI te informa que  sua   empresa acaba de adquirir uma nova filial e eles precisam ter acesso a alguns servidores que   estão na rede local do ambiente que você administra.  Depois de concluir todo processo de contratação do link e a conectividade com a filial estar finalizada, seu gerente de TI lhe informa   que na nova filial utilizará OSPF para declarar as redes locais.

Agora você pensa: como podemos configurar o OSPF nesses roteadores se eles não estão diretamente conectados? Como administrar o processo de roteamento via uma rede gerenciada pela Operadora como por exemplo, com MPLS,  que não está emulando um Lan-to-Lan ? É ai que entra o Túnel GRE.

Configuração

Antes de criar o tunnel, certifique-se que a origem e o destino mapeados na Interface Tunnel estejam acessíveis via roteamento. No nosso exemplo, usaremos  a Loopback.

Como os roteadores simularão uma conexão ponto-a-ponto, eles irão trocar informações  de  roteamento através do túnel como se estivessem diretamente conectados.

GRE HPN configuração v2

Por padrão o Comware habilita o protocolo GRE em túneis sem a necessidade de configuração adicional. Caso você precise utilizar uma Interface Tunnel para alguma outra função, segue abaixo algumas possibilidades:

 

[RA-Tunnel10]tunnel-protocol ?
  dvpn       Dynamic Virtual Private Network
  gre        Generic Routing Encapsulation
  ipsec      IPsec tunnel encapsulation
  ipv4-ipv4  tunnel mode ipv4 over ipv4
  ipv4-ipv6  tunnel mode ipv4 over ipv6
  ipv6-ipv4  tunnel mode ipv6 over(to) ipv4
  ipv6-ipv6  tunnel mode ipv6 over ipv6
  mpls       Multiprotocol Label Switching

Considerações para a utilização de Tunnel em Switches HP baseados no Comware

A utilização de interface Tunnel em Switches HP baseados no Comware pode ser um pouco mais complicada que em roteadores. Antes de utilizarmos o processo acima  é necessário criar uma configuração de “Service Loopback” (em alguns modelos de Switches), vincular à uma porta não utilizada (vazia) e também vincular o serviço ao Tunnel. Segue abaixo os passos:

• Crie um “tunnel-type service loopback group’.

• Adicione uma porta não utilizada ao “Service loopback group”.

# Criando o “Service-loopback” group 1 e especificando o tipo como tunnel.
[SwitchA] service-loopback group 1 type tunnel

# Vinculando a porta Giga 1/0/3 para o “Service-loopback” group 1. 
#Desabilite o STP e o LLDP da interface.
[SwitchA] interface GigabitEthernet 1/0/3
[SwitchA-GigabitEthernet1/0/3] undo stp enable
[SwitchA-GigabitEthernet1/0/3] undo lldp enable
[SwitchA-GigabitEthernet1/0/3] port service-loopback group 1
[SwitchA-GigabitEthernet1/0/3] quit

# Aplique  o “Service-loopback” group 1 à interface tunnel.
[SwitchA] interface tunnel 0
[SwitchA-Tunnel0] service-loopback-group 1
[SwitchA-Tunnel0] quit
# O tunnel ficará up mesmo que a outra ponta não esteja configurada

Até a próxima 

Referência

http://www.rotadefault.com.br/protocolo-de-tunelamento-gre/

VRF em Switches e Roteadores HPN – (VPN-Instance)

A utilização de VRF (Virtual Routing and Forwarding) permite a criação de tabelas de roteamentos virtuais em Switches e Roteadores; independentes da tabela de roteamento “normal”(geralmente chamada de tabela de roteamento global [Global Routing Table]).

VRF Comware

Da mesma forma como a utilização de VLANs em Switches Ethernet permitem a divisão de dominios de broadcasts e mapeamentos da tabela MAC, a utilização de VRF permite a virtualização da tabela de roteamento. Nos Switches e Roteadores utilizando o Sistema Operacional Comware (3Com, H3C e HPN) a feature é chamada de “vpn-instance“.

Apesar da tecnologia VRF ter a sua função vinculada às redes MPLS (por ser largamente utilizado em Provedores e Data Centers) há a possibilidade de criar tabelas de roteamento apenas para funções locais do Roteador, chamado de VRF-lite ou também Multi-VRF.

Você pode ser perguntar: “Mas por qual razão eu precisaria configurar outra tabela de roteamento em meu roteador?” Geralmente as empresas que prestam serviços de TI, monitoração de redes e serviços, “operadoras de links”, etc; precisam lidar com clientes que usam em sua maioria endereços da RFC1918 (endereços IPv4 privados) o que aumenta a probabilidade de mais de um cliente possuir endereços de rede IPv4 iguais (além do fator de segurança ) e a complexidade da divisão das redes usando NAT e ACL; a utilização de VRFs possibilita a independência das tabelas de roteamento, permitindo que uma tabela de rotas não possua roteamento com as outras (por padrão).

Segue abaixo o exemplo da configuração do cenário acima:

# Criando as VRFs (vpn-instance)
ip vpn-instance ABC
! criando a VRF chamada “ABC”
 route-distinguisher 1:1
! configurando o RD
#
ip vpn-instance XYZ
 route-distinguisher 2:2
#

Obs: a configuração do Route-distinguisher (RD) permite a extensão do endereço IPv4 para diferenciação, chamado de VPNv4. Os endereços VPNv4 são a combinação de endereços IPv4(32 bit) e o valor Route-distinguiser (64 bit).

# Com as VLANs criadas atribua a vpn-instance a interface VLAN
vlan 1
#
vlan 2 to 5
#
interface Vlan-interface2
 ip binding vpn-instance ABC
! vinculando a VRF à interface VLAN
 ip address 192.168.1.1 255.255.255.0
#
interface Vlan-interface3
 ip binding vpn-instance ABC
 ip address 192.168.2.1 255.255.255.0
#
interface Vlan-interface4
 ip binding vpn-instance XYZ
 ip address 192.168.1.1 255.255.255.0
#
interface Vlan-interface5
 ip binding vpn-instance XYZ
 ip address 192.168.2.1 255.255.255.0
#
#  A configuração poderá ser atribuída a Switches e Roteadores, 
#  inclusive em interfaces em modo Routed.

Validando as vpn-instance criadas…

  display ip vpn-instance
  Total VPN-Instances configured : 2
  VPN-Instance Name               RD                     Create time
  ABC                             1:1                    2013/10/20 18:35:42
  XYZ                             2:2                    2013/10/20 18:36:04

Verificando as tabelas de roteamento da VRF e a tabela de roteamento global.

[SW1]display ip routing-table
Routing Tables: Public
        Destinations : 2        Routes : 2
Destination/Mask    Proto  Pre  Cost         NextHop         Interface
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
! Na tabela global há somente o endereço de loopback 127.0.0.1
!
[SW1]display ip routing-table vpn-instance ABC
Routing Tables: ABC
        Destinations : 6        Routes : 6
Destination/Mask    Proto  Pre  Cost         NextHop         Interface
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
192.168.1.0/24      Direct 0    0            192.168.1.1     Vlan2
192.168.1.1/32      Direct 0    0            127.0.0.1       InLoop0
192.168.2.0/24      Direct 0    0            192.168.2.1     Vlan3
192.168.2.1/32      Direct 0    0            127.0.0.1       InLoop0
! Rotas da VRF ABC
!
[SW1]display  ip routing-table  vpn-instance XYZ
Routing Tables: XYZ
        Destinations : 6        Routes : 6

Destination/Mask    Proto  Pre  Cost         NextHop         Interface
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
192.168.1.0/24      Direct 0    0            192.168.1.1     Vlan4
192.168.1.1/32      Direct 0    0            127.0.0.1       InLoop0
192.168.2.0/24      Direct 0    0            192.168.2.1     Vlan5
192.168.2.1/32      Direct 0    0            127.0.0.1       InLoop0
! Rotas da VRF XYZ

Além do Roteamento para as interfaces diretamente conectadas é possível tambem separa as rotas estaticas e protocolos de Roteamento em processos independente para cada vpn-instance

# Exemplo de configuração de rota estatica por VRF
ip route-static vpn-instance ABC 0.0.0.0 0.0.0.0  192.168.1.254
ip route-static vpn-instance XYZ 0.0.0.0 0.0.0.0  192.168.1.100
# Criação de processos individuais do OSPF por VRF
[SW1]ospf 10 vpn-instance ?
  STRING  VPN Routing/Forwarding Instance (VRF) Name

Dica : Sempre configure o endereço IP após atribuir uma vpn-instance à uma interface, pois o dispositivo irá remover a configuração IP da interface.

[Router-LoopBack0]ip binding vpn-instance TESTE
 All IP related configurations on this interface are removed!

Nos equipamentos HPN a configuração do RD é obrigatória na criação da VRF! ;)

Resumo sobre Border Gateway Protocol (BGP) – MASE Network Infrastructure – parte 1 de 2

Galera, esses dias participei de um treinamento para a certficação MASE Network Infrastructure voltado para a prova HP0-Y36.Fiz algumas anotações e conforme for organizando os “.txts” dos rascunhos, compartilharei aqui no blog para quem precisar da revisão para a prova. Espero que seja útil.

O Protocolo BGP é considerado o mais robusto Protocolo de  Roteamento para redes IP. Sua complexidade permite a conexão de múltiplos Sistemas Autônomos, chamados de AS (Autonomous systems), permitindo o roteamento dinâmico na Internet.

Um Sistema Autônomo é uma coleção de prefixos (rotas) sobre uma mesma política de roteamento e sobre o controle administrativo de uma mesma entidade (empresas, provedores de Internet [ISP’s]).

A Internet consiste em redes Comerciais conectadas por Provedores (ISP’s) como Telefônica,Embratel, Oi, CTBC e etc. Cada rede comercial ou Provedor deve ser identificado pelo Número do seu Sistema Autônomo (ASN) sobre controle do IANA .

O range disponível para o BGP é de 1 até 65635. Os ASN públicos disponíveis vão de 1 até 64511, já a utilização dentro de uma empresa do BGP, sem a comunicação com a Internet, poderá utilizar os valores de 64512 até 65535, chamados de uso privado.

A função primária de um sistema BGP é trocar informação de acesso à rede, inclusive informações sobre a lista das trajetórias dos ASes, com outros sistemas BGP. Esta informação pode ser usada para construir uma rede de conectividade dos ASes livre de loops de roteamento.

O BGP é considerado um Protocolo de Vetor de Distância avançado utilizando-se de vetores para contagem de saltos para cada destino. A contagem de saltos para o BGP é baseada em ASes.

  • O BGP é considerado um protocolo de roteamento externo usado para transmitir informações de roteamento entre ASes e como ponto de troca entre organizações.
  • Desenhado para grandes redes com necessidade complexas para políticas de roteamento.
  • O BGP roda sobre  TCP (porta 179) e requer a configuração manual  para conexão com o vizinho (peering).
  • BGP versão 4
  • Providencia uma série de atributos (métricas) para os prefixos anunciados, além de suportar CIDR. Também suporta diversas estratégias de filtro para o roteamento
  • Não gera informações periódicas de roteamento e sim atualizações engatilhadas (* triggered updates para os peers) além de mandar as atualizações em lote para os seus vizinhos  (* “batch” route updates).

Protocolos de roteamento interior (IGP) vs exterior (EGP)

  • Interior (RIP, OSPF, EIGRP, ISIS,etc)
    • descobrimento automático de vizinhos
    • os roteadores internos possuem informação completa da tabela de rotas
  • Exterior (BGP)
    •  os vizinhos são configurados estaticamente (não há um sub-processo como o Hello do OSPF para descoberta de vizinhos)
    • conexão com redes externas
    • demarcação clara de limites administrativos

Operação Geral

Roteadores BGP aprendem multiplos caminhos via BGP internos e externos.  Eles escolhem SOMENTE o melhor caminho e instala na tabela de roteamento IP. O Roteador BGP anuncia apenas as rotas que este utiliza (apesar da possibilidade de aprender sobre multiplos caminhos).

BGP peer

- A comunicação BGP entre roteadores é sobre uma conexão TCP.

- Roteadores são pares (peer) são classificados em:

  • … eBGP peer (external BGP)  se os roteadores estão em um Sistema Autonomo diferente
  • … iBGP peer (internal BGP)  se os roteadores estão em um  mesmo Sistema Autonomo.

- eBGP peer devem ter um link direto entre eles.

- iBGP peer não necessitam ter um link direto.

Obs: dentro de um AS os roteadores trocam roteamento interno via IGP, já os roteadores eBGP geralmente não trocam roteamento via IGP.

Configuração eBGP

Resumo BGP

As mensagens eBGP são encapsuladas no pacote IP com o TTL=1 por padrão. Caso seja necessário a conexão entre vizinhos eBGP por uma interface Loopback, o TTL deve ser alterado para 2: adicione o comando peer ebgpmax-hop 2

bgp 10
  peer <endereço da loopback do vizinho> as-number 20
  peer <endereço da loopback do vizinho> ebgp-max-hop 2
  peer <endereço da loopback do vizinho> connect-interface loopback0

Obs: Geralmente utilizado em cenários com redundância de Link. Certifique-se que o roteamento da interface Loopback do vizinho seja acessível pelos links redundantes.

Configuração iBGP

Devido ao fato de uma interface looopback estar sempre UP, ela é utilizada para configurar uma conexão TCP estável entre 2 vizinhos iBGP (geralmente a conexão é estabelecida via IGP).

Resumo iBGP

Observações

- Uma rota aprendida via iBGP não é ensinada para outros vizinhos iBGP como forma de prevenção de loop de roteamento

- Os roteadores iBGP de um AS devem formar uma conexão “full mesh” entre si ou utilizar outros mecanismos como Route Reflector e Confederation.

- Roteadores conectados via iBGP não necessitam estar diretamente conectado e sim acessivel via IGP (static, RIP, OSPF, etc.)

- Um Roteador iBGP não altera o next-hop de um prefixo aprendido via eBGP e que é ensinado na atualização para um vizinho iBGP. Certifique-se que o next-hop (endereço IP do próximo salto) seja acessível via IGP em todos roteadores do AS ou altere o next-hop para o vizinho das rotas aprendidas por eBGP com o comando “peer <endereço IP do peer iBGP> next-hop-local

Quando configurar um peer iBGP, lembre-se:

* Utilize o endereço da interface loopback do vizinho

* Utilize a sua interface loopback para conexão com o comando “connect interface
* Se o numero de vizinhos é grande, utilize a configuração de “groups

# Peer group Configuration
 bgp 10
 group as20 internal
 peer as20 as-number 20
 peer as20 connect-interface loopback0
 peer 192.1.254.2 group as20
 peer 192.1.254.3 group as20
 peer 192.1.254.4 group as20
 peer 192.1.254.5 group as20

Dica: O status correto para o “peering” entre 2 Roteadores iBGP e eBGP é Established

 Rotas BGP

Para uma rota ser anunciada no BGP, ela deve existir no Roteador (como estática, IGP, BGP)

1. redistribuição dinamica do IGP

- nem sempre a melhor opção
- requer configuração cuidadosas de filtragem de rotas
- caso um prefixo não esteja na tabela do IGP este deixa de ser anunciado
- mais utilizados em cenarios PE-CE

2. Redistribuição de rotas estáticas apontando para Null0 – mesmo que os prefixos estejam fora do IGP as redes são anunciadas

bgp 30
import-route static
quit
!
ip route 198.10.0.0 255.255.0.0 null 0

3. Comando network

- redes origininadas pelo roteador local
- rota deve existir no IGP

router bgp 30
network 192.168.0.0 255.255.0.0

Até logo! :)

No próximo post o resumo abordará algumas questões a manipulação e a escolha do melhor caminho para o BGP.