Olá, habr. Atualmente sou o líder do curso de Engenheiro de Rede da OTUS.
Antecipando o início de uma nova inscrição para o curso , preparei uma série de artigos sobre a tecnologia VxLAN EVPN.
Há uma grande quantidade de material sobre como funciona o VxLAN EVPN, por isso quero coletar várias tarefas e práticas para resolver problemas em um data center moderno.
Na primeira parte da série sobre a tecnologia VxLAN EVPN, quero examinar uma maneira de organizar a conectividade L2 entre hosts na parte superior de uma estrutura de rede.
Todos os exemplos serão realizados em um Cisco Nexus 9000v, montado na topologia Spine-Leaf. Não nos deteremos na configuração de uma rede Underlay neste artigo.
- Rede subjacente
- Peering BGP para família de endereços l2vpn evpn
- Configurando o NVE
- Suprimir-arp
Rede subjacente
A topologia utilizada é a seguinte:
Vamos definir o endereçamento 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 доступен чеерз два Spine
*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 доступен чеерз два Spine
*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 na verificação de consistência e se as configurações em ambos os nós são idênticas:
Leaf11# show vpc
vPC domain id : 1
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
Configuration consistency status : success
Per-vlan consistency status : success
Type-2 consistency status : success
vPC role : primary
Number of vPCs configured : 0
Peer Gateway : Disabled
Dual-active excluded VLANs : -
Graceful Consistency Check : Enabled
Auto-recovery status : Disabled
Delay-restore status : Timer is off.(timeout = 30s)
Delay-restore SVI status : Timer is off.(timeout = 10s)
Operational Layer3 Peer-router : Disabled
vPC status
----------------------------------------------------------------------------
Id Port Status Consistency Reason Active vlans
-- ------------ ------ ----------- ------ ---------------
5 Po5 up success success 1Pareamento BGP
Finalmente, você pode prosseguir com a configuração da rede Overlay.
Como parte do artigo, é necessário organizar uma rede entre hosts, conforme mostrado no diagrama abaixo:
Para configurar uma rede Overlay, você precisa habilitar o BGP nos switches Spine e Leaf com suporte para a família l2vpn evpn:
feature bgp
nv overlay evpnEm seguida, você precisa configurar o peering BGP entre Leaf e Spine. Para simplificar a configuração e otimizar a distribuição de informações de roteamento, configuramos o Spine como um servidor Route-Reflector. Escreveremos todos os Leaf na configuração usando templates para otimizar a configuração.
Portanto, as configurações do Spine ficam 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 peering 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 você pode ver, não houve problemas com o BGP. Vamos prosseguir com a configuração do VxLAN. Outras configurações serão feitas apenas no lado Leaf dos switches. Spine atua apenas como o núcleo da rede e está envolvido apenas na transmissão de tráfego. Todo o trabalho de encapsulamento e determinação de caminho ocorre apenas em switches Leaf.
Configurando o NVE
NVE - interface virtual de rede
Antes de iniciar a configuração, vamos apresentar alguma terminologia:
VTEP - Vitual Tunnel End Point, o dispositivo no qual o túnel VxLAN começa ou termina. O VTEP não é necessariamente qualquer dispositivo de rede. Um servidor que suporta a tecnologia VxLAN também pode atuar como servidor. Em nossa topologia, todos os switches Leaf são VTEP.
VNI - Virtual Network Index - identificador de rede dentro do VxLAN. Uma analogia pode ser feita com a VLAN. No entanto, existem algumas diferenças. Ao usar uma malha, as VLANs se tornam exclusivas apenas dentro de um switch Leaf e não são transmitidas pela rede. Mas cada VLAN pode ter um número VNI associado a ela, que já é transmitido pela rede. Sua aparência e como pode ser usado serão discutidos mais adiante.
Vamos ativar o recurso para que a tecnologia VxLAN funcione e a capacidade de associar números VLAN a um número VNI:
feature nv overlay
feature vn-segment-vlan-basedVamos configurar a interface NVE, responsável pelo funcionamento do VxLAN. Esta interface é responsável por encapsular frames em cabeçalhos VxLAN. Você pode fazer uma analogia com a interface Tunnel para GRE:
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0No switch Leaf-21 tudo é criado sem problemas. No entanto, se verificarmos a saída do comando show nve peers, então estará vazio. Aqui você precisa retornar à configuração do VPC. Vemos que Leaf-11 e Leaf-12 trabalham em pares e estão unidos por um domínio VPC. Isso nos dá a seguinte situação:
O Host-2 envia um quadro para o Leaf-21 para que o transmita pela rede para o Host-1. Contudo, Leaf-21 vê que o endereço MAC do Host-1 está acessível através de dois VTEPs ao mesmo tempo. O que o Leaf-21 deve fazer neste caso? Afinal, isso significa que um loop pode aparecer na rede.
Para resolver esta situação, precisamos que o Leaf-11 e o Leaf-12 também atuem como um único dispositivo dentro da fábrica. A solução é bastante simples. Na interface Loopback a partir da qual construímos o túnel, adicione 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 de outros VTEPs, obtemos a seguinte topologia:
Ou seja, agora será construído o túnel entre o endereço IP do Leaf-21 e o IP virtual entre dois Leaf-11 e Leaf-12. Agora não haverá problemas para aprender o endereço MAC de dois dispositivos e o tráfego poderá passar de um VTEP para outro. Qual dos dois VTEPs processará o tráfego é decidido usando a 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 você pode ver acima, o endereço 10.255.1.10 está disponível imediatamente através de dois Next-hops.
Nesta fase, tratamos da conectividade básica. Vamos prosseguir com a configuração da interface NVE:
Vamos habilitar imediatamente a Vlan 10 e associá-la ao VNI 10000 em cada Folha para os hosts. Vamos configurar um túnel L2 entre hosts
vlan 10 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
vn-segment 10000 ! Ассоциируем VLAN с номер VNI
interface nve1
member vni 10000 ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
ingress-replication protocol bgp ! указываем, что для распространения информации о хосте используем BGPAgora vamos verificar os cinco peers e a tabela do 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 ! Видим что peer доступен с secondary адреса
Leaf11# sh bgp l2vpn evpn
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000) ! От кого именно пришел этот l2VNI
*>l[3]:[0]:[32]:[10.255.1.10]/88 ! EVPN route-type 3 - показывает нашего соседа, который так же знает об 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 EVPN tipo 3. Esse tipo de rota fala sobre peer(Leaf), mas onde estão nossos hosts?
O problema é que as informações sobre os hosts MAC são transmitidas via rota EVPN tipo 2
Para ver nossos hosts, você precisa configurar a rota EVPN tipo 2:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoVamos fazer ping do Host-2 para o 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 o tipo de rota 2 com endereço MAC do host apareceu na tabela BGP - 5001.0007.0007 e 5001.0008.0007
Leaf11# sh bgp l2vpn evpn
<......>
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216 ! evpn route-type 2 и mac адрес хоста 1
10.255.1.10 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216 ! evpn route-type 2 и mac адрес хоста 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
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 iA seguir, você pode ver informações detalhadas sobre Atualização, na qual recebeu informações sobre o MAC Host. Abaixo não está toda a saída do comando.
Leaf21# sh bgp l2vpn evpn 5001.0007.0007
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.255.1.11:32777 ! отправил Update с MAC Host. Не виртуальный адрес VPC, а адрес Leaf
BGP routing table entry for [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216,
version 1507
Paths: (2 available, best #2)
Flags: (0x000202) (high32 00000000) on xmit-list, is not in l2rib/evpn, is not i
n HW
Path type: internal, path is valid, not best reason: Neighbor Address, no labe
led nexthop
AS-Path: NONE, path sourced internal to AS
10.255.1.10 (metric 81) from 10.255.1.102 (10.255.1.102) ! с кем именно строим VxLAN тоннель
Origin IGP, MED not set, localpref 100, weight 0
Received label 10000 ! Номер VNI, который ассоциирован с VLAN, в котором находится Host
Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8 ! Тут видно, что RT сформировался автоматически на основе номеров AS и VNI
Originator: 10.255.1.11 Cluster list: 10.255.1.102
<........>Vamos ver como ficam os quadros quando passam pela fábrica:
Suprimir-ARP
Ótimo, agora temos comunicação L2 entre os anfitriões e poderíamos terminar aí. Porém, nem tudo é tão simples. Enquanto tivermos poucos hosts não haverá problemas. Mas vamos imaginar uma situação em que temos centenas e milhares de hosts. Que problema podemos enfrentar?
Este problema é o tráfego BUM (Broadcast, Unknown Unicast, Multicast). Neste artigo, consideraremos a opção de lidar com o tráfego de transmissão.
O principal gerador de Broadcast nas redes Ethernet são os próprios hosts através do protocolo ARP.
Nexus implementa o seguinte mecanismo para combater solicitações ARP - suprimir-arp.
Este recurso funciona da seguinte maneira:
- 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 passar essa solicitação para a estrutura em direção ao Host-2, o Leaf responde sozinho e indica o IP e MAC necessários.
Assim, a solicitação do Broadcast não foi para a fábrica. Mas como isso pode funcionar se o Leaf conhece apenas o endereço MAC?
Tudo é bastante simples, a rota EVPN tipo 2, além do endereço MAC, pode transmitir uma combinação MAC/IP. Para fazer isso, você precisa configurar um endereço IP na VLAN no Leaf. Surge a pergunta: qual IP devo definir? No Nexus é possível criar um endereço distribuído (mesmo) em todos os switches:
feature interface-vlan
fabric forwarding anycast-gateway-mac 0001.0001.0001 ! задаем virtual mac для создания распределенного шлюза между всеми коммутаторами
interface Vlan10
no shutdown
ip address 192.168.10.254/24 ! на всех Leaf задаем одинаковый IP
fabric forwarding mode anycast-gateway ! говорим использовать Virtual macAssim, do ponto de vista dos hosts, a rede ficará assim:
Vamos verificar o BGP l2route evpn
Leaf11# sh bgp l2vpn evpn
<......>
Network Next Hop Metric LocPrf Weight Path
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
<......>Na saída do comando você pode ver que na rota EVPN tipo 2, além do MAC, agora também vemos o endereço IP do host.
Vamos voltar à configuração do supressão-arp. Esta configuração é habilitada para cada VNI separadamente:
interface nve1
member vni 10000
suppress-arpEntão surge alguma complexidade:
- Para que esse recurso funcione, é necessário espaço na memória TCAM. Aqui está um exemplo de configurações para suprimir-arp:
hardware access-list tcam region arp-ether 256Esta configuração exigirá largura dupla. Ou seja, se você definir 256, precisará liberar 512 no TCAM. A configuração do TCAM está além do escopo deste artigo, pois a configuração do TCAM depende apenas da tarefa atribuída a você e pode diferir de uma rede para outra.
- A implementação do supressão-arp deve ser feita em todos os switches Leaf. No entanto, pode surgir complexidade ao configurar pares Leaf residentes em um domínio VPC. Se o TCAM for alterado, a consistência entre os pares será quebrada e um nó poderá ser retirado de operação. Além disso, pode ser necessária uma reinicialização do dispositivo para aplicar a configuração de alteração do TCAM.
Como resultado, você precisa considerar cuidadosamente se, na sua situação, vale a pena implementar essa configuração em uma fábrica em funcionamento.
Isso conclui a primeira parte da série. Na próxima parte, veremos o roteamento por meio de uma malha VxLAN com separação de redes em diferentes VRFs.
E agora convido a todos para , dentro do qual contarei detalhadamente sobre o curso. Os primeiros 20 participantes que se inscreverem neste webinar receberão um certificado de desconto por e-mail dentro de 1 a 2 dias após a transmissão.
Fonte: habr.com