MP-BGP

Comware 7: Configuração de VXLAN com BGP EVPN

Diego DiasLeave a comment

O Ethernet Virtual Private Network (EVPN) é uma tecnologia VPN de Camada 2 VPN que fornece conectividade entre dispositivos tanto em Camada 2 como para Camada 3 através de uma rede IP. A tecnologia EVPN utiliza o MP-BGP como plano de controle (control plane) e o VXLAN como plano de dados/encaminhamento (data plane) de um switch/roteador. A tecnologia é geralmente utilizada em data centers em ambiente multitenant ( com múltiplos clientes e serviços) com grande tráfego leste-oeste.

A configuração do EVPN permite ao MP-BGP automatizar a descoberta de VTEPs, assim como o estabelecimento de tuneis VXLAN de forma dinâmica, a utilização de IRB (Integrated Routing and Bridging) anuncia tanto as informações  de Camada 2 e 3 para acesso ao host, fornecendo a utilização do melhor caminho através do ECMP e minimizando flood do trafego multidestination (BUM: broadcast,unicast unknown e multicast)  .

Em resumo o EVPN possui um address Family que permite que as informações de MAC, IP, VRF e VTEP sejam transportadas sobre o MP-BGP, que assim permitem aos VTEPs aprender informações sobre os hosts (via ARP/ND/DHCP etc.).

O BGP EVPN distribui e fornece essa informação para todos os outros pares BGP-EVPN dentro da rede.

Relembrando o VXLAN

O VXLAN prove uma rede de camada 2 sobreposta (overlay) em uma rede de camada 3 (underlay). Cada rede sobreposta é chamada de segmento VXLAN e é identificada por um ID único de 24 bits chamado VNI – VXLAN Network Identifier ou VXLAN ID.

A identificação de um host vem da combinação do endereço MAC e o VNI.  Os hosts situados em VXLANs diferentes não podem comunicar entre si (sem a utilização de um roteador). O pacote original enviado por um host na camada 2 é encapsulado em um cabeçalho VXLAN que inclui o VNI associado ao segmento VXLAN que aquele host pertence.

Os equipamentos que transportam os tuneis VXLAN são chamados de VTEP (VXLAN tunnel endpoints).

Quando um VXLAN VTEP ou tunnel endpoint comunica-se com outros VXLAN VTEP, um túnel VXLAN é estabelecido. Um túnel é meramente um mecanismo de transporte através de uma rede IP.

Todo o processamento VXLAN é executado nos VTEPs. O VTEP de entrada encapsula o tráfego com cabeçalho VXLAN, mais um cabeçalho UDP externo , mais um cabeçalhos IP externo, e então encaminha o tráfego por meio de túneis VXLAN. O VTEP do destino remove o encapsulamento VXLAN e encaminha o tráfego para o destino.

Os dispositivos da rede IP de transporte encaminham o tráfego VXLAN apenas com base no cabeçalho IP externo dos pacotes VXLAN (eles não precisam ter suporte à tecnologia VXLAN).

Uma imagem contendo screenshot, texto Descrição gerada automaticamente

Um outro ponto importante é que a tecnologia VXLAN supera as limitações de apenas 4 mil domínios de broadcast fornecido por VLANs para até 16 milhões de domínios de broadcast com VNIs. Já para as limitações do Spanning-Tree que coloca os caminhos redundantes em estado de bloqueio, a tecnologia VXLAN permite a construção de todos os uplinks como parte de um backbone IP (rede underlay), utilizando protocolos de roteamento dinâmico para escolha do melhor caminho ao destino, assim fazendo uso do ECMP (Equal Cost Multipath) em uma topologia Spine-Leaf, por exemplo.

BGP EVPN

O BGP EVPN difere do comportamento “Flood and Learn” executado por tuneis VXLANs em diversas maneiras. Enquanto o tráfego multidestination (BUM: broadcast,unicast unknown e multicast) encaminhado pelo VXLAN sem o BGP EVPN necessita de utilizar grupos multicast, o EVPN permite a replicação da identificação dos dispositivos finais com o MP-BGP , assim como as informações do VTEP que ele está associado. As comunicações ARP para IPv4 também pode ser suprimida, aprimorando assim a eficiência do transporte dos dados.

LAB

No laboratório abaixo utilizamos os roteadores HP VSR no release R0621P18-X64, no EVE-NG.

Ambos os Spines estão configurados como VTEP e encaminharão o tráfego do VXLAN VNI 10. A instancia criada para esse cliente, chamamos de ‘clientea’.

O Spine está configurado como BGP Router Reflector fechando peerring com ambos Leafs. Nenhum Leaf fecha peering BGP entre si, somente como Spine.

Texto preto sobre fundo branco Descrição gerada automaticamente

Configuração SPINE 1

#
 sysname Spine-01
#
interface LoopBack0
description OSPF_UNDERLAY
 ip address 192.168.0.1 255.255.255.255
#
interface LoopBack1
description BGP_EVPN_UNDERLAY
 ip address 192.168.0.11 255.255.255.255
#
interface GigabitEthernet1/0
description CONEXAO_LEAF3
 ip address 192.168.13.1  255.255.255.0
#
interface GigabitEthernet2/0
description CONEXAO_LEAF4
 ip address 192.168.14.1 255.255.255.0
#
ospf 1 router-id 192.168.0.1
 description UNDERLAY_OSPF
 area 0.0.0.0
  network 192.168.0.1 0.0.0.0
  network 192.168.0.11 0.0.0.0
  network 192.168.14.0 0.0.0.255
  network 192.168.13.0 0.0.0.255
#
bgp 65001
 group evpn internal
 peer evpn connect-interface LoopBack1
 peer 192.168.0.33 group evpn
 peer 192.168.0.44 group evpn
 #
 address-family l2vpn evpn
  undo policy vpn-target
  peer evpn enable
  peer evpn reflect-client
#

Configuração LEAF 3

#
 sysname Leaf-03
#
interface LoopBack0
description OSPF_UNDERLAY
 ip address 192.168.0.3 255.255.255.255
#
interface LoopBack1
description BGP_EVPN_UNDERLAY
 ip address 192.168.0.33 255.255.255.255
#
interface GigabitEthernet1/0
description CONEXAO_SPINE1
 ip address 192.168.13.3 255.255.255.0
 ospf network-type p2p
#
ospf 1 router-id 192.168.0.3
 description UNDERLAY_OSPF
 area 0.0.0.0
  network 192.168.0.3 0.0.0.0
  network 192.168.0.33 0.0.0.0
  network 192.168.13.0 0.0.0.255
#
bgp 65001
 peer 192.168.0.11 as-number 65001
 peer 192.168.0.11 connect-interface LoopBack1
 #
 address-family l2vpn evpn
  peer 192.168.0.11 enable
#
 vxlan tunnel mac-learning disable
#
 l2vpn enable
#
vsi clientea
 arp suppression enable
 vxlan 10
 evpn encapsulation vxlan
  route-distinguisher auto
  vpn-target auto export-extcommunity
  vpn-target auto import-extcommunity
  quit
#
interface GigabitEthernet3/0
 xconnect vsi clientea
#

Configuração LEAF 4

#
 sysname Leaf-04
#
interface LoopBack0
description OSPF_UNDERLAY
 ip address 192.168.0.4 255.255.255.255
#
interface LoopBack1
description BGP_EVPN_UNDERLAY
 ip address 192.168.0.44 255.255.255.255
#
interface GigabitEthernet2/0
description CONEXAO_SPINE2
 ip address 192.168.14.4 255.255.255.0
  ospf network-type p2p
#
ospf 1 router-id 192.168.0.4
 area 0.0.0.0
  network 192.168.0.4 0.0.0.0
  network 192.168.0.44 0.0.0.0
  network 192.168.14.0 0.0.0.255
#
bgp 65001
 peer 192.168.0.11 as-number 65001
 peer 192.168.0.11 connect-interface LoopBack1
 #
 address-family l2vpn evpn
  peer 192.168.0.11 enable
#
 vxlan tunnel mac-learning disable
#
 l2vpn enable
#
vsi clientea
 arp suppression enable
 evpn encapsulation vxlan
  route-distinguisher auto
  vpn-target auto export-extcommunity
  vpn-target auto import-extcommunity
  quit
  vxlan 10
  quit
#
interface GigabitEthernet3/0
 xconnect vsi clientea
#

Comandos Display bgp l2vpn evpn

Tela de computador com texto preto sobre fundo branco Descrição gerada automaticamente

Comando display vxlan tunnel

Uma imagem contendo desenho Descrição gerada automaticamente

Referências

R2702-HPE FlexFabric 5940 & 5930 Switch Series EVPN Configuration Guide

KRATTIGER, Lukas; KAPADIA, Shyam; JANSEN, David; Building Data Centers with VXLAN BGP EVPN – A Cisco NX-OS Perspective – 2017 CiscoPress

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

Diego Dias1 Comment

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 😉

Alterando a distancia administrativa para os protocolos de Roteamento em Switches e Roteadores HPN (Comware)

Diego Dias2 Comments

Há alguns posts atrás comentamos sobre a diferença da Distância Administrativa para as rotas aprendidas dinâmicamente em Switches e Roteadores dos fabricantes Cisco e HPN (H3C/3Com) e a atenção que deve ser dada em ambientes com Protocolos de Roteamento que possuem Switches e Roteadores  de ambos fabricantes

http://www.comutadores.com.br/distancia-administrativa-em-switches-l3-e-roteadores-h3c3comhp-serie-a/

A Distância Administrativa possui apenas função local e não é compartilhada pelo protocolo de roteamento.

Como por exemplo, em um Roteador utilizando o OSPF (como IGP) e o BGP para aprender as “rotas externas”, se uma mesma rota fosse aprendida via OSPF e BGP, o comportamento para escolha do melhor caminho seria diferente em Rotadores Cisco (a distancia administrativa para o OSPF é 110 e o  eBGP é 20) e HPN ( o OSPF é 10 e o eBGP é 255). Lembrando que para prefixos iguais aprendido por diferentes protocolos o Roteador escolhe a rota com menor distância administrativa.

Uma coisa bacana do Comware é poder alterar o valor da distância administrativa  baseado no processo de Roteamento, por exemplo, se tivermos 2 processos OSPF rodando no Router/Switch é possível alterar a distancia administrativa em um dos processos sem afetar o outro ( muito útil quando se utiliza VRFs [ vpn-instance] em um mesmo roteador) .

Para redes que utilizam MP-BGP, tambem é possível alterar a distância administrativa no address-family do cliente.

Veja o exemplo abaixo para a tabela de roteamento Global (eBGP e iBGP com a distância adminstrativa em 255) e a tabela de roteamento da vpn-instance cliente-A (com o eBGP como 7 e o iBGP como 100).

<Router>display ip routing-table
Routing Tables: Public
Destinations : 18177     Routes : 18177

Destination/Mask    Proto  Pre  Cost         NextHop         Interface
0.0.0.0/0           BGP    255  0            10.180.226.197  GE3/1/6.100
192.168.9.0/24      BGP    255  0            10.180.226.197  GE3/1/6.100
192.168.10.0/24     BGP    255  0            10.180.226.197  GE3/1/6.100
192.168.11.0/24     BGP    255  0            10.180.226.197  GE3/1/6.100
<saída omitida>

<Router>display ip routing-table vpn-instance cliente-A
Routing Tables: cliente-A
Destinations : 1789      Routes : 1789
Destination/Mask    Proto  Pre  Cost         NextHop         Interface
1.1.1.1/32          BGP    7    0            192.168.176.217  GE9/1/7
2.2.2.0/29          BGP    7    0            192.168.176.217  GE9/1/7
192.168.80.0/30     BGP    100  0            192.168.229.193  NULL0
10.1.1.1/32         BGP    7    0            192.168.176.217  GE9/1/7
<saída omitida>

Para configurar a distancia administrativa dentro processo BGP ou dentro do processo “ipv4-family vpn-instance [nome da vrf]” no BGP use a sintaxe:

[Router-bgp]preference ?
INTEGER<1-255>  External preference
!Distancia administrativa para rotas aprendidas via eBGP

[Router-bgp]preference 7 ?
INTEGER<1-255>  Internal preference
!Distancia administrativa para rotas aprendidas via iBGP

[Router-bgp]preference 7 100 ?
INTEGER<1-255>  Local preference
!Distancia administrativa para rotas aprendidas via iBGP (locais)

[Router-bgp]preference 7 100 9

Para o OSPF  utilize o commando preference para alterar a distância administrativa de rotas OSPF e OSPF ASE:

[Router-ospf-1]preference ?
INTEGER<1-255>  Preference value
ase             AS external link states

[Router-ospf-1]preference ase ?
INTEGER<1-255>  Preference value

Até logo!