Olá, Habr. Atualmente sou o líder do curso de "Engenheiro de Redes" na OTUS.
Com a proximidade do início de um novo ciclo de inscrições para o curso , preparei uma série de artigos sobre a tecnologia VxLAN EVPN.
Existem imensos materiais sobre como trabalhar com VxLAN EVPN, por isso quero reunir diversas tarefas e práticas de resolução de problemas em um moderno Data Center.
Na primeira parte da série sobre a tecnologia VxLAN EVPN, quero abordar a forma de organizar a conectividade L2 entre hosts sobre a infraestrutura de rede.
Todos os exemplos serão realizados em Cisco Nexus 9000v, organizados em uma topologia Spine-Leaf. Não vamos nos deter na configuração da rede Underlay neste artigo.
- Rede Underlay
- Piring BGP para address-family l2vpn evpn
- Configuração NVE
- Supress-arp
Rede Underlay
A topologia utilizada é a seguinte:
Vamos definir os endereços em todos os dispositivos:
Spine-1 - 10.255.1.101
Spine-2 - 10.255.1.102
Leaf-11 - 10.255.1.11
Leaf-12 - 10.255.1.12
Leaf-21 - 10.255.1.21
Host-1 - 192.168.10.10
Host-2 - 192.168.10.20Vamos verificar se há conectividade IP entre todos os dispositivos:
Leaf21# sh ip route
10.255.1.11/32, ubest/mbest: 2/0 ! Leaf-11 acessível através de dois Spines
*via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
*via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.12/32, ubest/mbest: 2/0 ! Leaf-12 acessível através de dois Spines
*via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
*via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.21/32, ubest/mbest: 2/0, attached
*via 10.255.1.22, Lo0, [0/0], 00:02:20, local
*via 10.255.1.22, Lo0, [0/0], 00:02:20, direct
10.255.1.101/32, ubest/mbest: 1/0
*via 10.255.1.101, Eth1/4, [110/41], 00:00:06, ospf-UNDERLAY, intra
10.255.1.102/32, ubest/mbest: 1/0
*via 10.255.1.102, Eth1/3, [110/41], 00:00:03, ospf-UNDERLAY, intraVamos verificar se o domínio VPC foi criado e se ambos os switches passaram pela verificação de consistência, garantindo que a configuração em ambas as nódos seja idêntica:
Leaf11# show vpc
vPC domain id : 1
Status do peer : adjacência formada corretamente
Status de keep-alive vPC : peer está ativo
Status de consistência da configuração: sucesso
Status de consistência por VLAN : sucesso
Status de consistência Type-2 : sucesso
Papel vPC : primário
Número de vPCs configuradas : 0
Gateway do peer : Desabilitado
VLANs excluídas de dual-active : -
Verificação de consistência gradual : Habilitada
Status de recuperação automática : Desabilitada
Status de restauração com atraso : Temporizador desligado.(timeout = 30s)
Status de SVI com restauração com atraso: Temporizador desligado.(timeout = 10s)
Peer-router Layer3 operacional : Desabilitado
Status do vPC
----------------------------------------------------------------------------
Id Porta Status Consistência Motivo VLANs ativas
-- ------------ ------ ----------- ------ --------------
5 Po5 up sucesso sucesso 1Piring BGP
Finalmente, podemos passar para a configuração da rede Overlay.
No decorrer do artigo, é necessário organizar a rede entre os hosts, conforme mostrado no esquema abaixo:
Para configurar a rede Overlay, é necessário ativar o BGP nos switches Spine e Leaf com suporte para a família l2vpn evpn:
feature bgp
nv overlay evpnEm seguida, é necessário configurar o emparelhamento BGP entre Leaf e Spine. Para simplificar a configuração e otimizar a disseminação das informações de rota, configuramos o Spine como Route-Reflector server. Todos os Leaf serão inseridos na configuração por meio de templates, para otimizar a configuração.
Assim, a configuração no Spine fica assim:
router bgp 65001
template peer LEAF
remote-as 65001
update-source loopback0
address-family l2vpn evpn
send-community
send-community extended
route-reflector-client
neighbor 10.255.1.11
inherit peer LEAF
neighbor 10.255.1.12
inherit peer LEAF
neighbor 10.255.1.21
inherit peer LEAFA configuração no switch Leaf é semelhante:
router bgp 65001
template peer SPINE
remote-as 65001
update-source loopback0
address-family l2vpn evpn
send-community
send-community extended
neighbor 10.255.1.101
inherit peer SPINE
neighbor 10.255.1.102
inherit peer SPINENo Spine, vamos verificar o emparelhamento com todos os switches Leaf:
Spine1# sh bgp l2vpn evpn summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.255.1.11 4 65001 7 8 6 0 0 00:01:45 0
10.255.1.12 4 65001 7 7 6 0 0 00:01:16 0
10.255.1.21 4 65001 7 7 6 0 0 00:01:01 0Como vemos, não houve problemas com o BGP. Vamos passar para a configuração do VxLAN. A configuração subsequente será realizada apenas no lado dos switches Leaf. O Spine atua apenas como o núcleo da rede e se dedica apenas ao tráfego. Todo o trabalho de encapsulamento e definição de caminho ocorre apenas nos switches Leaf.
Configuração NVE
NVE — interface virtual de rede
Antes de iniciar a configuração, vamos introduzir um pouco de terminologia:
VTEP — Virtual Tunnel End Point, dispositivo onde o túnel VxLAN começa ou termina. O VTEP não precisa ser obrigatoriamente um dispositivo de rede. Também pode ser um servidor com suporte à tecnologia VxLAN. Em nossa topologia, todos os switches Leaf são VTEPs.
VNI — Virtual Network Index — identificador de rede no contexto do VxLAN. Pode ser comparado ao VLAN. No entanto, existem algumas diferenças. Ao usar uma fábrica, os VLANs tornam-se únicos apenas dentro de um switch Leaf e não são transmitidos pela rede. Mas a cada VLAN pode ser associado um número VNI, que já é transmitido pela rede. Como isso funciona e como pode ser utilizado será abordado a seguir.
Ativaremos a feature para o funcionamento da tecnologia VxLAN e a possibilidade de associar números VLAN ao número VNI:
feature nv overlay
feature vn-segment-vlan-basedVamos configurar a interface NVE, que é responsável pelo funcionamento do VxLAN. Essa interface é a que efetua a encapsulação dos quadros em cabeçalhos VxLAN. Podemos fazer uma analogia com a interface Tunnel utilizada para GRE:
interface nve1
no shutdown
host-reachability protocol bgp ! utilizamos BGP para a transmissão de informações de roteamento
source-interface loopback0 ! interface pela qual enviamos pacotes loopback0No comutador Leaf-21, tudo é criado sem problemas. No entanto, se verificarmos a saída do comando show nve peers, ela estará vazia. Aqui, precisamos voltar para a configuração do VPC. Vemos que Leaf-11 e Leaf-12 estão funcionando em par e estão unidos pelo domínio VPC. A partir disso, temos a seguinte situação:
O Host-2 envia um quadro em direção ao Leaf-21, para que ele o transfira pela rede em direção ao Host-1. No entanto, o Leaf-21 percebe que o endereço MAC do Host-1 está disponível através de dois VTEPs. Como deve agir o Leaf-21 nesse caso? Isso significa que uma tempestade de broadcast pode ter surgido na rede.
Para resolver essa situação, precisamos que o Leaf-11 e o Leaf-12 atuem como um único dispositivo dentro da fábrica. Isso é resolvido de maneira bastante simples. Na interface Loopback através da qual construímos o túnel, adicionamos um endereço secundário. O endereço secundário deve ser o mesmo em ambos os VTEPs.
interface loopback0
ip add 10.255.1.10/32 secondaryAssim, do ponto de vista dos outros VTEPs, obtemos a seguinte topologia:
Ou seja, agora o túnel será estabelecido entre o endereço IP do Leaf-21 e o IP virtual entre os dois, Leaf-11 e Leaf-12. Agora não haverá problemas na obtenção do endereço MAC de dois dispositivos, permitindo que o tráfego flua de um VTEP para o outro. Qual dos dois VTEPs processará o tráfego é decidido pela tabela de roteamento no Spine:
Spine1# sh ip route
10.255.1.10/32, ubest/mbest: 2/0
*via 10.255.1.11, Eth1/1, [110/41], 1d01h, ospf-UNDERLAY, intra
*via 10.255.1.12, Eth1/2, [110/41], 1d01h, ospf-UNDERLAY, intra
10.255.1.11/32, ubest/mbest: 1/0
*via 10.255.1.11, Eth1/1, [110/41], 1d22h, ospf-UNDERLAY, intra
10.255.1.12/32, ubest/mbest: 1/0
*via 10.255.1.12, Eth1/2, [110/41], 1d01h, ospf-UNDERLAY, intraComo pode ser visto acima, o endereço 10.255.1.10 está disponível através de dois Next-hop.
Nesta etapa, entendemos a conectividade básica. Vamos passar para a configuração da interface NVE:
Ativaremos imediatamente a VLAN 10 e a associaremos ao VNI 10000 em cada Leaf para os hosts. Vamos configurar um túnel L2 entre os hosts.
vlan 10 ! Ativamos o VLAN em todos os VTEPs conectados aos hosts necessários
vn-segment 10000 ! Associamos o VLAN ao número VNI
interface nve1
member vni 10000 ! Adicionamos o VNI 10000 para trabalhar através da interface NVE, para encapsulamento em VxLAN
ingress-replication protocol bgp ! Especificamos que usamos o BGP para disseminar informações sobre o hostAgora vamos verificar os peers nve e a tabela para BGP EVPN:
Leaf21# sh nve peers
Interface Peer-IP State LearnType Uptime Router-Mac
--------- --------------- ----- --------- -------- -----------------
nve1 10.255.1.10 Up CP 00:00:41 n/a ! Vemos que o peer está disponível no endereço secundário
Leaf11# sh bgp l2vpn evpn
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000) ! De quem exatamente veio este l2VNI
*>l[3]:[0]:[32]:[10.255.1.10]\/88 ! Rota EVPN type 3 - mostra nosso vizinho, que também sabe sobre o l2VNI10000
10.255.1.10 100 32768 i
*>i[3]:[0]:[32]:[10.255.1.20]\/88
10.255.1.20 100 0 i
* i 10.255.1.20 100 0 i
Route Distinguisher: 10.255.1.21:32777
* i[3]:[0]:[32]:[10.255.1.20]\/88
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iAcima, vemos apenas rotas do tipo EVPN type 3. Este tipo de rota informa sobre o peer (Leaf), mas onde estão nossos hosts?
O fato é que a informação sobre os endereços MAC dos hosts é transmitida através do EVPN type 2
Para poder ver nossos hosts, é necessário configurar o EVPN type 2:
evpn
vni 10000 l2
route-target import auto ! No âmbito deste artigo, usamos um número automático para o route-target
route-target export autoVamos fazer um ping de Host-2 para Host-1:
Firewall2# ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1): 56 data bytes
36 bytes from 192.168.10.2: Destination Host Unreachable
Request 0 timed out
64 bytes from 192.168.10.1: icmp_seq=1 ttl=254 time=215.555 ms
64 bytes from 192.168.10.1: icmp_seq=2 ttl=254 time=38.756 ms
64 bytes from 192.168.10.1: icmp_seq=3 ttl=254 time=42.484 ms
64 bytes from 192.168.10.1: icmp_seq=4 ttl=254 time=40.983 msE abaixo podemos ver que a tabela BGP agora contém rotas do tipo 2 com os endereços MAC dos hosts — 5001.0007.0007 e 5001.0008.0007
Leaf11# sh bgp l2vpn evpn
Rede Próximo Salto Métrica LocPrf Peso Caminho
Distintor de Rotas: 10.255.1.11:32777 (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]\/216 ! rota evpn tipo 2 e mac endereço do host 1
10.255.1.10 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]\/216 ! rota evpn tipo 2 e mac endereço do host 2
* i 10.255.1.20 100 0 i
*>l[3]:[0]:[32]:[10.255.1.10]\/88
10.255.1.10 100 32768 i
Distintor de Rotas: 10.255.1.21:32777
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]\/216
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iA seguir, você pode ver informações detalhadas sobre a Atualização, em que obtivemos informações sobre o MAC Host. Abaixo está apresentado nem todo o output do comando
Leaf21# sh bgp l2vpn evpn 5001.0007.0007
Informações da tabela de roteamento BGP para VRF padrão, família de endereços L2VPN EVPN
Distintor de Rotas: 10.255.1.11:32777 ! enviou Atualização com MAC Host. Não é um endereço VPC virtual, mas o endereço Leaf
Entrada da tabela de roteamento BGP para [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]\/216,
versão 1507
Caminhos: (2 disponíveis, melhor #2)
Flags: (0x000202) (high32 00000000) na lista de transmissão, não está no l2rib\/evpn, não está em HW
Tipo de caminho: interno, caminho é válido, não melhor razão: Endereço do Vizinhos, nenhum próximo salto rotulado
AS-Path: NENHUM, caminho originado internamente ao AS
10.255.1.10 (métrica 81) de 10.255.1.102 (10.255.1.102) ! com quem estamos construindo o túnel VxLAN
Origem IGP, MED não definido, localpref 100, peso 0
Rótulo recebido 10000 ! Número VNI, que está associado à VLAN, onde o Host está localizado
Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8 ! Aqui você pode ver que o RT foi formado automaticamente com base nos números AS e VNI
Originador: 10.255.1.11 Lista de clusters: 10.255.1.102Vamos ver como os quadros parecem quando são transmitidos através da fábrica:
Suprimir-ARP
Ótimo, a conexão L2 entre os hosts foi estabelecida e poderíamos encerrar aqui. No entanto, nem tudo é simples. Enquanto tivermos poucos hosts, não surgirão problemas. Mas vamos imaginar situações em que temos centenas e milhares de hosts. Qual problema podemos enfrentar?
Esse problema é o tráfego BUM (Broadcast, Unknown Unicast, Multicast). Nesta artigo, abordaremos a opção de combater o tráfego de broadcast.
O principal gerador de Broadcast em redes Ethernet são os próprios hosts através do protocolo ARP.
No Nexus, foi implementado o seguinte mecanismo para lidar com solicitações ARP — suppress-arp.
O funcionamento desta funcionalidade é o seguinte:
- O Host-1 envia uma solicitação APR para o endereço de Broadcast de sua rede.
- A solicitação chega ao switch Leaf e, em vez de transmitir essa solicitação adiante na fábrica em direção ao Host-2 — o Leaf responde ele mesmo e indica o IP e o MAC corretos.
Dessa forma, a solicitação de Broadcast não foi enviada para a fábrica. Mas como isso pode funcionar se o Leaf conhece apenas o endereço MAC?
Tudo é bem simples, o EVPN route-type 2, além do endereço MAC, pode transmitir o par MAC/IP. Para isso, é necessário configurar um endereço IP na VLAN do Leaf. Surge a pergunta: qual IP deve ser definido? No Nexus, existe a possibilidade de criar um endereço distribuído (idêntico) em todos os switches:
feature interface-vlan
fabric forwarding anycast-gateway-mac 0001.0001.0001 ! definimos o MAC virtual para criar um gateway distribuído entre todos os switches
interface Vlan10
no shutdown
ip address 192.168.10.254/24 ! em todos os Leafs definimos o mesmo IP
fabric forwarding mode anycast-gateway ! dizemos para usar o MAC virtualDessa forma, a rede será vista da seguinte maneira pelos hosts:
Vamos verificar o BGP l2route evpn
Leaf11# sh bgp l2vpn evpn
Rede Próximo Salto Métrica LocPrf Peso Caminho
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216
10.255.1.21 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
10.255.1.10 100 0 i
* i 10.255.1.10 100 0 i
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.10.20]/248
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
<......>
Route Distinguisher: 10.255.1.21:32777
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 i
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.10.20]/248
*>i 10.255.1.20 100 0 i
<......>A partir da saída do comando, é possível ver que no EVPN route-type 2, além do MAC, agora também vemos o endereço IP do host.
Voltando à configuração do suppress-arp. Esta configuração é ativada para cada VNI individualmente:
interface nve1
member vni 10000
suppress-arpA seguir, surge uma certa complexidade:
- Para que esse recurso funcione, é necessário espaço na memória TCAM. Vou dar um exemplo de configuração para o suppress-arp:
hardware access-list tcam region arp-ether 256Para esta configuração, será necessário double-wide. Ou seja, se você definir 256, será necessário liberar 512 na TCAM. A configuração da TCAM vai além do escopo deste artigo, pois depende apenas do que foi solicitado e pode variar de uma rede para outra.
- A implementação do suppress-arp deve ser realizada em todos os switches Leaf. No entanto, a complexidade pode surgir na configuração dos pares Leaf que estão no domínio VPC. Ao modificar o TCAM, a consistência entre os pares será comprometida e um nó pode ser desconectado. Além disso, para aplicar a configuração, pode ser necessário reiniciar o dispositivo após a alteração do TCAM.
Como resultado, é preciso considerar cuidadosamente se vale a pena implementar essa configuração em sua fábrica em operação.
Com isso, concluímos a primeira parte do ciclo. Na próxima parte, abordaremos o roteamento através da fábrica VxLAN com a divisão de redes em diferentes VRF.
E agora convido todos para , onde falarei detalhadamente sobre o curso. Os primeiros 20 participantes que se registrarem para este webinar receberão um Certificado de desconto no e-mail dentro de 1-2 dias após a transmissão.
Fonte: habr.com
