Ola habr. Actualmente son o responsable do curso de "Enxeñeiro de redes" na OTUS.
En previsión do inicio dunha nova matrícula para o curso , preparei unha serie de artigos sobre tecnoloxía VxLAN EVPN.
Hai unha gran cantidade de material sobre o funcionamento de VxLAN EVPN, polo que quero recoller varias tarefas e prácticas para resolver problemas nun centro de datos moderno.
Na primeira parte do ciclo de tecnoloxía VxLAN EVPN, quero considerar unha forma de organizar a conectividade L2 entre hosts enriba dunha fábrica de rede.
Todos os exemplos realizaranse en Cisco Nexus 9000v, ensamblados na topoloxía Spine-Leaf. Non nos deteremos na configuración da rede Underlay neste artigo.
- rede subxacente
- Peering BGP para address-family l2vpn evpn
- Configuración de NVE
- Suprimir-arp
rede subxacente
A topoloxía utilizada é a seguinte:
Establecemos o enderezo en 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.20Comprobamos que hai 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, intraComprobamos que se creou o dominio VPC e que os dous interruptores pasaron a comprobación de coherencia e que a configuración de ambos os nodos é idéntica:
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 1Peering BGP
Finalmente, podemos pasar á configuración da rede de superposición.
Como parte do artigo, é necesario organizar unha rede entre hosts, como se mostra no seguinte diagrama:
Para configurar unha rede de superposición, cómpre activar BGP nos interruptores Spine e Leaf con compatibilidade coa familia l2vpn evpn:
feature bgp
nv overlay evpnA continuación, cómpre configurar o peering BGP entre Leaf e Spine. Para simplificar a configuración e optimizar a distribución da información de enrutamento, configuramos Spine como servidor Route-Reflector. Escribiremos todas as follas na configuración a través de modelos para optimizar a configuración.
Entón, a configuración de Spine ten o seguinte aspecto:
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 configuración do interruptor Leaf é semellante:
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 SPINEEn Spine, comprobe o peering con todos os interruptores 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 podes ver, non houbo problemas con BGP. Pasemos á configuración de VxLAN. A configuración adicional realizarase só no lado dos interruptores Leaf. Spine só actúa como o núcleo da rede e só participa na transmisión do tráfico. Todo o traballo sobre encapsulamento e definición de camiños ocorre só nos interruptores Leaf.
Configuración de NVE
NVE - interface virtual de rede
Antes de comezar a configuración, introduzamos algunha terminoloxía:
VTEP - Vitual Tunnel End Point, o dispositivo no que comeza ou remata o túnel VxLAN. VTEP non é necesariamente ningún dispositivo de rede. Tamén pode actuar un servidor compatible con tecnoloxía VxLAN. Na nosa topoloxía, todos os interruptores Leaf son VTEP.
VNI - Virtual Network Index - identificador de rede dentro de VxLAN. Podes facer unha analoxía coa VLAN. Non obstante, hai algunhas diferenzas. Cando se usa un fabric, as VLAN só se fan únicas dentro dun conmutador Leaf e non se transmiten pola rede. Pero cada VLAN pódese asociar cun número VNI que xa se transmite pola rede. O que parece e como se pode usar comentarase a continuación.
Activa a función para que a tecnoloxía VxLAN funcione e a posibilidade de asociar números de VLAN cun número de VNI:
feature nv overlay
feature vn-segment-vlan-basedImos configurar a interface NVE, que é responsable do funcionamento de VxLAN. Esta interface é responsable de encapsular marcos en cabeceiras VxLAN. Podes facer unha analoxía coa interface Tunnel para GRE:
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0No interruptor Leaf-21, todo se crea sen problemas. Non obstante, se comprobamos a saída do comando show nve peers, entón estará baleiro. Aquí cómpre volver á configuración de VPC. Vemos que Leaf-11 e Leaf-12 están emparellados e unidos por un dominio VPC. Isto dá lugar á seguinte situación:
Host-2 envía unha trama a Leaf-21 para ser enviada pola rede a Host-1. Non obstante, Leaf-21 ve que o enderezo MAC do Host-1 está dispoñible a través de dous VTEP á vez. Que debería facer Leaf-21 neste caso? Despois de todo, isto significa que pode aparecer un bucle na rede.
Para resolver esta situación, necesitamos que Leaf-11 e Leaf-12 actúen tamén como un único dispositivo dentro da fábrica. Resólvese de xeito sinxelo. Na interface Loopback desde a que estamos construíndo o túnel, engade o enderezo secundario. O enderezo secundario debe ser o mesmo nos dous VTEP.
interface loopback0
ip add 10.255.1.10/32 secondaryAsí, dende o punto de vista doutros VTEP, obtemos a seguinte topoloxía:
É dicir, agora construirase o túnel entre o enderezo IP de Leaf-21 e a IP virtual entre dous Leaf-11 e Leaf-12. Agora non haberá problemas para aprender a dirección MAC de dous dispositivos e o tráfico pódese transferir dun VTEP a outro. Cal dos dous VTEP procesará o tráfico decídese mediante a táboa de encamiñamento de 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 podes ver arriba, o enderezo 10.255.1.10 está dispoñible inmediatamente a través de dous Next-hops.
Nesta fase, descubrimos a conectividade básica. Pasemos á configuración da interface NVE:
Activaremos inmediatamente Vlan 10 e asociarémolo con VNI 10000 en cada folla para hosts. Configura un 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 imos comprobar nve peers e táboa 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 ! Видим что 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 iArriba vemos rutas só EVPN tipo de ruta 3. Este tipo de rutas fala de iguais (Folla), pero onde están os nosos anfitrións?
E o caso é que a información sobre os hosts MAC transmítese a través do tipo de ruta EVPN 2
Para ver os nosos anfitrións, debes configurar o tipo de ruta EVPN 2:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoImos facer ping de Host-2 a 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 a continuación podemos ver que o tipo de ruta 2 apareceu na táboa BGP co enderezo MAC dos hosts - 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 continuación, podes ver información detallada sobre Actualización, na que recibiu información sobre o host MAC. Abaixo non está a saída completa 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
<........>Vexamos como se ven os cadros cando se pasan pola fábrica:
Suprimir-ARP
Xenial, temos unha conexión L2 entre hosts e este podería ser o final. Non obstante, non todo é tan sinxelo. Mentres teñamos poucos anfitrións, non haberá problemas. Pero imaxinemos situacións nas que temos centos e miles de anfitrións. Que problema podemos enfrontarnos?
Este problema é o tráfico BUM (Broadcast, Unknown Unicast, Multicast). No marco deste artigo, consideraremos a opción de combater o tráfico de difusión.
O principal xerador de difusión nas redes Ethernet son os propios servidores a través do protocolo ARP.
Nexus implementa o seguinte mecanismo para xestionar as solicitudes ARP: suppress-arp.
Esta función funciona así:
- Host-1 envía unha solicitude APR ao enderezo de difusión da súa rede.
- A solicitude chega ao interruptor Leaf e en lugar de pasar esta solicitude á fábrica cara ao Host-2, o Leaf responde por si mesmo e indica a IP e a MAC desexadas.
Así, a solicitude de Broadcast non chegou á fábrica. Pero como pode funcionar isto se Leaf só coñece o enderezo MAC?
Todo é bastante sinxelo, o tipo de ruta EVPN 2, ademais do enderezo MAC, pode transmitir un paquete MAC / IP. Para iso, o Leaf debe estar configurado cun enderezo IP na VLAN. Xorde a pregunta, que IP preguntar? En nexus, é posible crear un enderezo distribuído (o mesmo) en todos os interruptores:
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 macAsí, desde o punto de vista dos anfitrións, a rede terá o seguinte aspecto:
Comprobe 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
<......>Desde a saída do comando, pódese ver que no tipo de ruta EVPN 2, ademais do MAC, agora tamén vemos o enderezo IP do host.
Volvamos á configuración de supresión-arp. Esta configuración está habilitada para cada VNI por separado:
interface nve1
member vni 10000
suppress-arpEntón hai algunha dificultade:
- Esta función require espazo na memoria TCAM. Vou dar un exemplo de configuración para suppress-arp:
hardware access-list tcam region arp-ether 256Esta configuración precisará dobre ancho. É dicir, se estableces 256, entón debes liberarse en TCAM 512. A configuración de TCAM está fóra do alcance deste artigo, xa que a configuración de TCAM depende só da tarefa que se che asignou e pode diferir dunha rede a outra.
- A implementación de suppress-arp debe facerse en todos os interruptores Leaf. Non obstante, a complexidade pode xurdir cando se configuran pares de follas situados nun dominio VPC. Ao cambiar TCAM, a consistencia entre os pares romperase e un nodo pode quedar fóra de servizo. Ademais, pode ser necesario reiniciar o dispositivo para aplicar a configuración de cambio de TCAM.
Como resultado, debes considerar coidadosamente se paga a pena implementar esta configuración nunha fábrica que funcione na túa situación.
Conclúe así a primeira parte do ciclo. Na seguinte parte, consideraremos o enrutamento a través dunha fábrica VxLAN con separación de rede entre diferentes VRF.
E agora convido a todos , no que falarei polo miúdo do curso. Os primeiros 20 participantes que se rexistren neste seminario web recibirán un certificado de desconto por correo electrónico dentro de 1-2 días despois da emisión.
Fonte: www.habr.com