Bonjour habr. Je suis actuellement responsable du cours "Network Engineer" à OTUS.
En prévision du début d'une nouvelle inscription au cours , j'ai préparé une série d'articles sur la technologie VxLAN EVPN.
Il existe une énorme quantité de matériel sur le fonctionnement de VxLAN EVPN, je souhaite donc collecter diverses tâches et pratiques pour résoudre les problèmes dans un centre de données moderne.
Dans la première partie du cycle technologique VxLAN EVPN, je souhaite envisager un moyen d'organiser la connectivité L2 entre les hôtes au-dessus d'une usine de réseau.
Tous les exemples seront réalisés sur Cisco Nexus 9000v, assemblé dans la topologie Spine-Leaf. Nous ne nous attarderons pas sur la configuration du réseau Underlay dans cet article.
- réseau sous-jacent
- Appairage BGP pour la famille d'adresses l2vpn evpn
- Configuration NVE
- Supprimer-arp
réseau sous-jacent
La topologie utilisée est la suivante :
Définissons l'adressage sur tous les appareils :
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.20Vérifions qu'il existe une connectivité IP entre tous les appareils :
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, intraVérifions que le domaine VPC a été créé et que les deux commutateurs ont réussi le contrôle de cohérence et que les paramètres sur les deux nœuds sont identiques :
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 1Appairage BGP
Enfin, nous pouvons passer à la configuration du réseau Overlay.
Dans le cadre de l'article, il est nécessaire d'organiser un réseau entre les hôtes, comme le montre le schéma ci-dessous :
Pour configurer un réseau Overlay, vous devez activer BGP sur les commutateurs Spine et Leaf avec prise en charge de la famille l2vpn evpn :
feature bgp
nv overlay evpnEnsuite, vous devez configurer le peering BGP entre Leaf et Spine. Pour simplifier la configuration et optimiser la distribution des informations de routage, nous configurons Spine en tant que serveur Route-Reflector. Nous allons écrire toutes les Leaf dans la config via des templates afin d'optimiser le paramétrage.
Ainsi, les paramètres de Spine ressemblent à ceci :
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 LEAFLa configuration sur le commutateur Leaf ressemble à :
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 SPINESur Spine, vérifiez le peering avec tous les commutateurs 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 0Comme vous pouvez le voir, il n'y a eu aucun problème avec BGP. Passons à la configuration de VxLAN. Une configuration supplémentaire sera effectuée uniquement du côté des commutateurs Leaf. Spine n'agit que comme le cœur du réseau et n'est impliqué que dans la transmission du trafic. Tous les travaux sur l'encapsulation et la définition du chemin se produisent uniquement sur les commutateurs Leaf.
Configuration NVE
NVE - interface virtuelle réseau
Avant de commencer la configuration, introduisons quelques termes :
VTEP - Virtual Tunnel End Point, l'appareil sur lequel le tunnel VxLAN commence ou se termine. VTEP n'est pas nécessairement un périphérique réseau. Un serveur supportant la technologie VxLAN peut également agir. Dans notre topologie, tous les commutateurs Leaf sont des VTEP.
VNI - Virtual Network Index - identifiant de réseau dans VxLAN. Vous pouvez faire une analogie avec VLAN. Cependant, il existe quelques différences. Lors de l'utilisation d'une structure, les VLAN ne deviennent uniques qu'au sein d'un seul commutateur Leaf et ne sont pas transmis sur le réseau. Mais chaque VLAN peut être associé à un numéro VNI déjà transmis sur le réseau. Ce à quoi il ressemble et comment il peut être utilisé sera discuté ci-dessous.
Activez la fonctionnalité pour que la technologie VxLAN fonctionne et la possibilité d'associer des numéros VLAN à un numéro VNI :
feature nv overlay
feature vn-segment-vlan-basedConfigurons l'interface NVE, qui est responsable du fonctionnement de VxLAN. Cette interface est responsable de l'encapsulation des trames dans les en-têtes VxLAN. Vous pouvez établir une analogie avec l'interface Tunnel pour GRE :
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0Sur le commutateur Leaf-21, tout est créé sans problème. Cependant, si nous vérifions la sortie de la commande show nve peers, alors il sera vide. Ici, vous devez revenir à la configuration du VPC. Nous voyons que Leaf-11 et Leaf-12 sont appariés et unis par un domaine VPC. Cela se traduit par la situation suivante :
Host-2 envoie une trame à Leaf-21 pour être envoyée sur le réseau à Host-1. Cependant, Leaf-21 voit que l'adresse MAC de Host-1 est disponible via deux VTEP à la fois. Que doit faire Leaf-21 dans ce cas ? Après tout, cela signifie qu'une boucle pourrait apparaître dans le réseau.
Pour résoudre cette situation, nous avons besoin que Leaf-11 et Leaf-12 agissent également comme un seul appareil au sein de l'usine. Il est résolu tout simplement. Sur l'interface Loopback à partir de laquelle nous construisons le tunnel, ajoutez l'adresse secondaire. L'adresse secondaire doit être la même sur les deux VTEP.
interface loopback0
ip add 10.255.1.10/32 secondaryAinsi, du point de vue des autres VTEP, on obtient la topologie suivante :
Autrement dit, le tunnel sera désormais construit entre l'adresse IP de Leaf-21 et l'adresse IP virtuelle entre deux Leaf-11 et Leaf-12. Désormais, l'apprentissage de l'adresse MAC à partir de deux appareils ne posera aucun problème et le trafic peut être transféré d'un VTEP à un autre. Lequel des deux VTEP traitera le trafic est décidé à l'aide de la table de routage sur 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, intraComme vous pouvez le voir ci-dessus, l'adresse 10.255.1.10 est disponible immédiatement via deux Next-hops.
À ce stade, nous avons déterminé la connectivité de base. Passons à la configuration de l'interface NVE :
Nous allons immédiatement activer Vlan 10 et l'associer à VNI 10000 sur chaque Leaf pour les hôtes. Configurer un tunnel L2 entre les hôtes
vlan 10 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
vn-segment 10000 ! Ассоциируем VLAN с номер VNI
interface nve1
member vni 10000 ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
ingress-replication protocol bgp ! указываем, что для распространения информации о хосте используем BGPVérifions maintenant nve peers et table pour 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 iCi-dessus, nous ne voyons que les routes EVPN de type 3. Ce type de routes parle de pair (Leaf), mais où sont nos hôtes ?
Et le fait est que les informations sur les hôtes MAC sont transmises via EVPN route-type 2
Pour voir nos hôtes, vous devez configurer EVPN route-type 2 :
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoEnvoyons un ping de Host-2 à 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 msEt ci-dessous, nous pouvons voir que le type de route 2 est apparu dans la table BGP avec l'adresse MAC des hôtes - 5001.0007.0007 et 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 iEnsuite, vous pouvez voir des informations détaillées sur la mise à jour, dans lesquelles vous avez reçu des informations sur l'hôte MAC. Ci-dessous n'est pas la sortie entière de la commande
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
<........>Voyons à quoi ressemblent les cadres lorsqu'ils sont passés par l'usine :
Supprimer-ARP
Super, nous avons une connexion L2 entre les hôtes et cela pourrait être la fin. Cependant, tout n'est pas si simple. Tant que nous aurons peu d'hôtes, il n'y aura pas de problèmes. Mais imaginons des situations où nous avons des centaines et des milliers d'hôtes. À quel problème pouvons-nous être confrontés ?
Ce problème est le trafic BUM (Broadcast, Unknown Unicast, Multicast). Dans le cadre de cet article, nous envisagerons la possibilité de lutter contre le trafic de diffusion.
Le principal générateur de diffusion dans les réseaux Ethernet est les hôtes eux-mêmes via le protocole ARP.
Nexus implémente le mécanisme suivant pour traiter les requêtes ARP : suppress-arp.
Cette fonctionnalité fonctionne comme ceci :
- Host-1 envoie une requête APR à l'adresse de diffusion de son réseau.
- La requête parvient au commutateur Leaf et au lieu de transmettre cette requête plus loin à l'usine vers Host-2, le Leaf répond lui-même et indique l'IP et le MAC souhaités.
Ainsi, la demande de diffusion n'est pas allée à l'usine. Mais comment cela peut-il fonctionner si Leaf ne connaît que l'adresse MAC ?
Tout est assez simple, EVPN route-type 2, en plus de l'adresse MAC, peut transmettre un bundle MAC/IP. Pour cela, la Leaf doit être configurée avec une adresse IP dans le VLAN. La question se pose, quelle IP demander ? Sur nexus, il est possible de créer une (même) adresse distribuée sur tous les commutateurs :
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 macAinsi, du point de vue des hôtes, le réseau ressemblera à ceci :
Vérifier 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
<......>D'après la sortie de la commande, on peut voir que dans EVPN route-type 2, en plus du MAC, nous voyons maintenant également l'adresse IP de l'hôte.
Revenons au paramètre suppress-arp. Ce paramètre est activé séparément pour chaque VNI :
interface nve1
member vni 10000
suppress-arpEnsuite, il y a une difficulté:
- Cette fonction nécessite de l'espace dans la mémoire TCAM. Je vais donner un exemple de réglage pour suppress-arp :
hardware access-list tcam region arp-ether 256Cette configuration nécessitera une double largeur. C'est-à-dire que si vous définissez 256, vous devez libérer dans TCAM 512. La configuration de TCAM dépasse le cadre de cet article, car la configuration de TCAM dépend uniquement de la tâche qui vous est assignée et peut différer d'un réseau à l'autre.
- L'implémentation de suppress-arp doit être effectuée sur tous les commutateurs Leaf. Cependant, la complexité peut survenir lors de la configuration sur des paires de feuilles situées dans un domaine VPC. Lors du changement de TCAM, la cohérence entre les paires sera rompue et un nœud peut être mis hors service. De plus, un redémarrage de l'appareil peut être nécessaire pour appliquer le paramètre de modification TCAM.
Par conséquent, vous devez examiner attentivement s'il vaut la peine d'implémenter ce paramètre sur une usine en activité dans votre situation.
Ceci conclut la première partie du cycle. Dans la partie suivante, nous examinerons le routage via une usine VxLAN avec une séparation de réseau entre différents VRF.
Et maintenant, j'invite tout le monde à , dans lequel je parlerai en détail du cours. Les 20 premiers participants qui s'inscriront à ce webinaire recevront un certificat de réduction par e-mail dans les 1-2 jours suivant la diffusion.
Source: habr.com