Dans la première partie de cette série consacrée aux technologies VxLAN/EVPN très courantes aujourd’hui en DataCenter (DC), nous avons détaillé les objectifs à atteindre pour l’ingénierie de notre Fabric à savoir offrir les extensions traditionnelles en niveau 2 (VLAN) et niveau 3 (IP), permettre la segmentation par tenant (VRF), insérer des équipements filtrant (FW/IPS), et bien d’autres besoins ..
Dans cet article, nous allons construire étape par étape le réseau Underlay de notre Fabric VxLAN/EVPN, détailler et expliquer les configurations utilisées et aussi comment vérifier leur bon fonctionnement.
Pour ce faire, nous allons émulé un Lab pour représenter une architecture Leaf & Spine composée de deux Spines et quatre Leafs comme indiqué dans le schéma ci-après :
Ces architectures sont matures et constituent aujourd’hui le standard en environnement DataCenter (DC), en effet, chaque équipement joue un rôle spécifique qui lui est attribué :
- Les Leafs permettent le raccordement des équipements finaux comme les serveurs, les infrastructures de virtualisation, les NAS, les Firewalls, les SLBs, .. plusieurs vitesses de ports sont proposées pour ces raccordements (du 100 Mbits au 100 Gbits).
- Les Spines offrent un raccordement cohérent et déterministe des Leafs à travers des liens de haute capacité (100G/400G), ces Spines permettent par leur multiplication d’augmenter la capacité totale de traitement de la Fabric.
- On peut assimilier les Leafs à des cartes de ligne de la Fabric et les Spines au fond de panier de la Fabic.
Pour le choix de l’Underlay, plusieurs options sont possibles (OSPF, IS-IS ou BGP), chaque protocole apporte son lot d’avantages et d’inconvénients suivant le contexte et les contraintes, pour les plus curieux, une série de trois articles est faite sur ce sujet que vous pouvez consulter sur : http://mhd-experts.com/quel-routage-underlay-pour-ma-fabric-leaf-spine-partie-1/
Pour notre Lab nous avons sélectionné eBGP pour l’underlay dans le modèle Same AS on all Spines, Different AS on all Leafs tel que décrit dans la RFC 7938 : « Use of BGP for Routing in Large-Scale Data Centers »
Avant de configurer le protocole Underlay (eBGP), il faut au préalable configurer les paramètres d’adressage IP (loopbacks, interco), pour les réseaux d’interconnexions IP en point à point entre les Leafs et Spines, il y a plusieurs options :
- Option 1 : Découper statiquement plusieurs sous-réseau (/31 ou /30) pour les allouer à ces réseaux interconnexions, pour un petit besoin comme notre Lab, cela reste un exercice simple, cependant, pour des Fabrics de taille plus importante (plusieurs centaines de Leafs), un recours à l’automatisation est vivement préconisé.
- Option 2 : Implémenter sur les interfaces physique la fonctionnalité « IP Unnumbered » qui permet d’hériter l’adresse IP à partir d’une interface logique (Loopback), cette méthode marche très bien et est souvent utilisée avec les protocoles OSPF/IS-IS car elle présente une simplification importante de la configuration cependant, elle peut amener de la confusion dans l’exploitation au quotidien puisque toute les interfaces physiques de l’underlay d’un équipement (Leaf ou Spine) vont hériter de la même adresse IP.
- Option 3 : Implémenter le protocole IPv6 et ses avantages pour l’adressage Underlay, il s’agit de :
- Autoconfigurer les interfaces physique en Link Local (FE80 ::/10) à partir de leurs adresses MAC (EUI-64).
- Utiliser les fonctionnalités tel que décrites dans la RFC 4861 (IPv6 Neighbor Discovery) pour l’annonce et la découverte des voisins IPv6 (Router Discovery et Router Advertisement)
- Etablir automatiquement des sessions eBGP avec tous les voisins IPv6 découverts au préalable, ces sessions vont permettre par la suite d’échanger au sein de la Fabric des préfixes IPv4/IPv6 (Loopback) avec un next-hop en IPv6 (Adresse en Link Local).
Bien que les options 1 et 2 sont les plus courantes aujourd’hui dans les documentations constructeurs et les déploiements qu’on constate chez beaucoup de clients, nous allons opter pour l’option 3 pour ce Lab car elle est pertinente à mon sens, en effet, cette option permet de simplifier les configurations et d’établir automatiquement les sessions eBGP sans avoir à les configurer manuellement (BGP Unnumbered ). Je trouve personnellement cette option très intéressante pour simplifier les déploiements de Fabric DC en Large Scale.
Pour information, l’option 3 est un standard décrit dans la RFC 5549 « Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop».
Il faut d’abord activer le protocole IPv6 sur l’ensemble des équipements de la Fabric :
Spines (S1 et S2) : ipv6 unicast-routing ! interface Ethernet1-4 ipv6 enable ipv6 nd ra interval msec 5000 ! Leafs (L1,L2,L3 et L4) : ipv6 unicast-routing ! interface Ethernet1-2 ipv6 enable ipv6 nd ra interval msec 5000 !
Pour vérifier la bonne découverte des voisins IPv6 :
Spines (S1 et S2) : Spine11#show ipv6 nd ra neighbors VRF: default Interface IPv6 Address Last RA Received --------------- ------------------------------- ---------------- Ethernet1 fe80::74b1:dff:fede:e2d1 0:00:03 ago Ethernet2 fe80::8d1:6bff:fe27:8e72 0:00:03 ago Ethernet3 fe80::44d:21ff:fece:c37f 0:00:03 ago Ethernet4 fe80::981b:6bff:febc:c2c3 0:00:02 ago Leafs (L1,L2,L3 et L4) : Leaf101#show ipv6 nd ra neighbors VRF: default Interface IPv6 Address Last RA Received --------------- ------------------------------- ---------------- Ethernet1 fe80::7405:8fff:fee1:df9d 0:00:03 ago Ethernet2 fe80::b5:e1ff:fe29:6eba 0:00:03 ago
Maintenant que les voisins IPv6 sont découverts automatiquement, on peut configurer l’établissement automatique des sessions eBGP entre Leafs et Spines ainsi qu’annoncer des préfixes IPv4 (Loopbacks) conformément à la RFC 5549 :
Spines (exemple S1) :
interface loopback0
description < Loopback | EVPN Overlay Peering >
ip address 192.168.10.11/32
!
ip routing ipv6 interfaces
!
route-map RM-CONN-2-BGP permit 10
match interface Loopback0
!
peer-filter EBGP-UNDERLAY-AS
10 match as-range 65101-65199 result accept
!
router bgp 65100
router-id 192.168.10.11
no bgp default ipv4-unicast
timers bgp 10 30
distance bgp 20 200 200
maximum-paths 16 ecmp 16
graceful-restart restart-time 300
graceful-restart
bgp default ipv6-unicast
bgp listen range fe80::/10 peer-group V6_UNDERLAY_PEERS peer-filter EBGP-UNDERLAY-AS
neighbor V6_UNDERLAY_PEERS peer group
neighbor V6_UNDERLAY_PEERS send-community extended
neighbor V6_UNDERLAY_PEERS maximum-routes 10000
redistribute connected route-map RM-CONN-2-BGP
!
address-family ipv4
bgp next-hop address-family ipv6
neighbor V6_UNDERLAY_PEERS activate
neighbor V6_UNDERLAY_PEERS next-hop address-family ipv6 originate
!
!
Leafs (exemple L1) :
interface loopback0
description < Loopback | EVPN Overlay Peering >
ip address 192.168.10.101/32
!
interface loopback1
description < Loopback | VTEP VxLAN Tunnel Source >
ip address 192.168.11.101/32
!
ip routing ipv6 interfaces
!
route-map RM-CONN-2-BGP permit 10
match interface Loopback0
!
route-map RM-CONN-2-BGP permit 20
match interface Loopback1
!
router bgp 65101
router-id 192.168.10.101
no bgp default ipv4-unicast
timers bgp 10 30
distance bgp 20 200 200
maximum-paths 16 ecmp 16
graceful-restart restart-time 300
graceful-restart
bgp default ipv6-unicast
neighbor V6_UNDERLAY_PEERS peer group
neighbor V6_UNDERLAY_PEERS send-community extended
neighbor V6_UNDERLAY_PEERS maximum-routes 10000
redistribute connected route-map RM-CONN-2-BGP
neighbor interface Ethernet1-2 peer-group V6_UNDERLAY_PEERS remote-as 65100
!
address-family ipv4
bgp next-hop address-family ipv6
neighbor V6_UNDERLAY_PEERS activate
neighbor V6_UNDERLAY_PEERS next-hop address-family ipv6 originate
!
!
Pour vérifier le bon établissement des sessions eBGP entre les Leafs et Spines :
Spines (S1 et S2) : Spine11#show ip bgp summary BGP summary information for VRF default Router identifier 192.168.10.11, local AS number 65100 Neighbor Status Codes: m - Under maintenance Neighbor V AS MsgRcvd MsgSent InQ OutQ Up/Down State PfxRcd PfxAcc fe80::44d:21ff:fece:c37f%Et3 4 65103 2200 2206 0 0 05:12:48 Estab 2 2 fe80::8d1:6bff:fe27:8e72%Et2 4 65102 2203 2201 0 0 05:12:47 Estab 2 2 fe80::74b1:dff:fede:e2d1%Et1 4 65101 2216 2212 0 0 05:12:47 Estab 2 2 fe80::981b:6bff:febc:c2c3%Et4 4 65104 2214 2220 0 0 05:12:43 Estab 2 2 Leafs (L1,L2,L3 et L4) : Leaf101#show ip bgp summary BGP summary information for VRF default Router identifier 192.168.10.101, local AS number 65101 Neighbor Status Codes: m - Under maintenance Neighbor V AS MsgRcvd MsgSent InQ OutQ Up/Down State PfxRcd PfxAcc fe80::b5:e1ff:fe29:6eba%Et2 4 65100 2225 2221 0 0 05:13:53 Estab 7 7 fe80::7405:8fff:fee1:df9d%Et1 4 65100 2220 2223 0 0 05:13:53 Estab 7 7
L’interface Loopback0 (adressage en 192.168.10.x/32) est configurée sur les Leafs et Spines, elle est annoncée dans l’underlay pour permettre de faire fonctionner le plan de contrôle de l’overlay, en effet, les sessions BGP-EVPN seront réalisées à travers les interfaces Loopback0.
L’interface Loopback1 (adressage en 192.168.11.x/32) est configurée uniquement sur les Leafs, elle sera utilisée pour permettre l’encapsulation VxLAN de VTEP à VTEP, ce qui permet de faire fonctionner le plan de donnée de l’overlay.
Pour vérifier la bon fonctionnement du routage sur l’Underlay, il suffit de vérifier les tables de routages des Leafs & Spines et s’assurer de la présence des interfaces Loopback0 et Loopback1 qui seront utiles pour monter le réseau Overlay :
Spines (exemple S1) :
Spine11#show ip route bgp
VRF: default
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B - Other BGP Routes,
B I - iBGP, B E - eBGP, R - RIP, I L1 - IS-IS level 1,
I L2 - IS-IS level 2, O3 - OSPFv3, A B - BGP Aggregate,
A O - OSPF Summary, NG - Nexthop Group Static Route,
V - VXLAN Control Service, M - Martian,
DH - DHCP client installed default route,
DP - Dynamic Policy Route, L - VRF Leaked,
G - gRIBI, RC - Route Cache Route
B E 192.168.10.101/32 [20/0]
via fe80::74b1:dff:fede:e2d1, Ethernet1
B E 192.168.10.102/32 [20/0]
via fe80::8d1:6bff:fe27:8e72, Ethernet2
B E 192.168.10.103/32 [20/0]
via fe80::44d:21ff:fece:c37f, Ethernet3
B E 192.168.10.104/32 [20/0]
via fe80::981b:6bff:febc:c2c3, Ethernet4
B E 192.168.11.101/32 [20/0]
via fe80::74b1:dff:fede:e2d1, Ethernet1
B E 192.168.11.102/32 [20/0]
via fe80::8d1:6bff:fe27:8e72, Ethernet2
B E 192.168.11.103/32 [20/0]
via fe80::44d:21ff:fece:c37f, Ethernet3
B E 192.168.11.104/32 [20/0]
via fe80::981b:6bff:febc:c2c3, Ethernet4
Leafs (exemple L1) ECMP vers S1 et S2 :
Leaf101#show ip route bgp
VRF: default
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B - Other BGP Routes,
B I - iBGP, B E - eBGP, R - RIP, I L1 - IS-IS level 1,
I L2 - IS-IS level 2, O3 - OSPFv3, A B - BGP Aggregate,
A O - OSPF Summary, NG - Nexthop Group Static Route,
V - VXLAN Control Service, M - Martian,
DH - DHCP client installed default route,
DP - Dynamic Policy Route, L - VRF Leaked,
G - gRIBI, RC - Route Cache Route
B E 192.168.10.11/32 [20/0]
via fe80::7405:8fff:fee1:df9d, Ethernet1
B E 192.168.10.12/32 [20/0]
via fe80::b5:e1ff:fe29:6eba, Ethernet2
B E 192.168.10.102/32 [20/0]
via fe80::7405:8fff:fee1:df9d, Ethernet1
via fe80::b5:e1ff:fe29:6eba, Ethernet2
B E 192.168.10.103/32 [20/0]
via fe80::7405:8fff:fee1:df9d, Ethernet1
via fe80::b5:e1ff:fe29:6eba, Ethernet2
B E 192.168.10.104/32 [20/0]
via fe80::7405:8fff:fee1:df9d, Ethernet1
via fe80::b5:e1ff:fe29:6eba, Ethernet2
B E 192.168.11.102/32 [20/0]
via fe80::7405:8fff:fee1:df9d, Ethernet1
via fe80::b5:e1ff:fe29:6eba, Ethernet2
B E 192.168.11.103/32 [20/0]
via fe80::7405:8fff:fee1:df9d, Ethernet1
via fe80::b5:e1ff:fe29:6eba, Ethernet2
B E 192.168.11.104/32 [20/0]
via fe80::7405:8fff:fee1:df9d, Ethernet1
via fe80::b5:e1ff:fe29:6eba, Ethernet2
Leaf101#ping 192.168.10.104 source lo0 repeat 10
PING 192.168.10.104 (192.168.10.104) from 192.168.10.101 : 72(100) bytes of data.
80 bytes from 192.168.10.104: icmp_seq=1 ttl=64 time=5.99 ms
80 bytes from 192.168.10.104: icmp_seq=2 ttl=64 time=5.43 ms
80 bytes from 192.168.10.104: icmp_seq=3 ttl=64 time=4.51 ms
80 bytes from 192.168.10.104: icmp_seq=4 ttl=64 time=4.77 ms
80 bytes from 192.168.10.104: icmp_seq=5 ttl=64 time=4.33 ms
80 bytes from 192.168.10.104: icmp_seq=6 ttl=64 time=4.47 ms
80 bytes from 192.168.10.104: icmp_seq=7 ttl=64 time=4.50 ms
80 bytes from 192.168.10.104: icmp_seq=8 ttl=64 time=4.53 ms
80 bytes from 192.168.10.104: icmp_seq=9 ttl=64 time=4.69 ms
80 bytes from 192.168.10.104: icmp_seq=10 ttl=64 time=4.84 ms
--- 192.168.10.104 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 49ms
rtt min/avg/max/mdev = 4.333/4.808/5.994/0.498 ms, ipg/ewma 5.449/5.060 ms
Leaf101#ping 192.168.11.104 source lo1 repeat 10
PING 192.168.11.104 (192.168.11.104) from 192.168.11.101 : 72(100) bytes of data.
80 bytes from 192.168.11.104: icmp_seq=1 ttl=64 time=6.32 ms
80 bytes from 192.168.11.104: icmp_seq=2 ttl=64 time=5.55 ms
80 bytes from 192.168.11.104: icmp_seq=3 ttl=64 time=5.70 ms
80 bytes from 192.168.11.104: icmp_seq=4 ttl=64 time=4.75 ms
80 bytes from 192.168.11.104: icmp_seq=5 ttl=64 time=4.68 ms
80 bytes from 192.168.11.104: icmp_seq=6 ttl=64 time=4.42 ms
80 bytes from 192.168.11.104: icmp_seq=7 ttl=64 time=4.43 ms
80 bytes from 192.168.11.104: icmp_seq=8 ttl=64 time=4.55 ms
80 bytes from 192.168.11.104: icmp_seq=9 ttl=64 time=4.50 ms
80 bytes from 192.168.11.104: icmp_seq=10 ttl=64 time=4.48 ms
--- 192.168.11.104 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 52ms
rtt min/avg/max/mdev = 4.426/4.943/6.329/0.639 ms, ipg/ewma 5.821/5.173 ms
Une autre variante intéréssante de ce modèle consiste à configurer l’underlay en IPv6-Only (sans passer par la RFC 5549), il suffit pour cela de déclarer une adresses IPv6 pour l’interface loopback0 afin de permettre l’établissement des sessions EVPN en IPv6, et une autre adresse IPv6 pour l’interface Loopback1 sur uniquement les Leafs pour permettre l’encapsulation VxLAN en IPv6-Only, en effet, les dernières versions d’EOS supportent ce modèle d’encapsulation.
Les configurations à apporter sur la modification actuelle pour appliquer cette variante modèle sont assez simple :
Spines (exemple S1) : interface loopback0 description < Loopback | EVPN Overlay Peering > ipv6 address 2001:192:168:10::11/128 no ip address ! no ip routing ipv6 interfaces ! router bgp 65100 no address-family ipv4 ! Leafs (exemple L1) : interface loopback0 description < Loopback | EVPN Overlay Peering > ipv6 address 2001:192:168:10::101/128 no ip address ! interface loopback1 description < Loopback | VTEP VxLAN Tunnel Source > ip address 2001:192:168:11::101/128 no ip address ! ip routing ipv6 interfaces ! router bgp 65101 no address-family ipv4 !
Pour vérifier le bon fonctionnement du routage de l’underlay en Full IPv6 :
Spines (exemple S1) :
Spine11#show ipv6 bgp summary
BGP summary information for VRF default
Router identifier 192.168.10.11, local AS number 65100
Neighbor Status Codes: m - Under maintenance
Neighbor V AS MsgRcvd MsgSent InQ OutQ Up/Down State PfxRcd PfxAcc
fe80::44d:21ff:fece:c37f%Et3 4 65103 4071 4068 0 0 09:36:36 Estab 2 2
fe80::8d1:6bff:fe27:8e72%Et2 4 65102 4074 4073 0 0 09:36:35 Estab 2 2
fe80::74b1:dff:fede:e2d1%Et1 4 65101 173 173 0 0 00:22:28 Estab 2 2
fe80::981b:6bff:febc:c2c3%Et4 4 65104 4087 4079 0 0 09:36:31 Estab 2 2
Spine11#show ipv6 route
VRF: default
Displaying 9 of 12 IPv6 routing table entries
Codes: C - connected, S - static, K - kernel, O3 - OSPFv3,
B - Other BGP Routes, A B - BGP Aggregate, R - RIP,
I L1 - IS-IS level 1, I L2 - IS-IS level 2, DH - DHCP,
NG - Nexthop Group Static Route, M - Martian,
DP - Dynamic Policy Route, L - VRF Leaked,
RC - Route Cache Route
C 2001:192:168:10::11/128 [0/0]
via Loopback0, directly connected
B E 2001:192:168:10::101/128 [20/0]
via fe80::74b1:dff:fede:e2d1, Ethernet1
B E 2001:192:168:10::102/128 [20/0]
via fe80::8d1:6bff:fe27:8e72, Ethernet2
B E 2001:192:168:10::103/128 [20/0]
via fe80::44d:21ff:fece:c37f, Ethernet3
B E 2001:192:168:10::104/128 [20/0]
via fe80::981b:6bff:febc:c2c3, Ethernet4
B E 2001:192:168:11::101/128 [20/0]
via fe80::74b1:dff:fede:e2d1, Ethernet1
B E 2001:192:168:11::102/128 [20/0]
via fe80::8d1:6bff:fe27:8e72, Ethernet2
B E 2001:192:168:11::103/128 [20/0]
via fe80::44d:21ff:fece:c37f, Ethernet3
B E 2001:192:168:11::104/128 [20/0]
via fe80::981b:6bff:febc:c2c3, Ethernet4
Leafs (exemple L1) :
Leaf101#show ipv6 bgp summary
BGP summary information for VRF default
Router identifier 192.168.10.101, local AS number 65101
Neighbor Status Codes: m - Under maintenance
Neighbor V AS MsgRcvd MsgSent InQ OutQ Up/Down State PfxRcd PfxAcc
fe80::b5:e1ff:fe29:6eba%Et2 4 65100 4107 4089 0 0 00:22:05 Estab 7 7
fe80::7405:8fff:fee1:df9d%Et1 4 65100 4088 4098 0 0 00:22:05 Estab 7 7
Leaf101#show ipv6 route
VRF: default
Displaying 10 of 13 IPv6 routing table entries
Codes: C - connected, S - static, K - kernel, O3 - OSPFv3,
B - Other BGP Routes, A B - BGP Aggregate, R - RIP,
I L1 - IS-IS level 1, I L2 - IS-IS level 2, DH - DHCP,
NG - Nexthop Group Static Route, M - Martian,
DP - Dynamic Policy Route, L - VRF Leaked,
RC - Route Cache Route
B E 2001:192:168:10::11/128 [20/0]
via fe80::7405:8fff:fee1:df9d, Ethernet1
B E 2001:192:168:10::12/128 [20/0]
via fe80::b5:e1ff:fe29:6eba, Ethernet2
C 2001:192:168:10::101/128 [0/0]
via Loopback0, directly connected
B E 2001:192:168:10::102/128 [20/0]
via fe80::7405:8fff:fee1:df9d, Ethernet1
via fe80::b5:e1ff:fe29:6eba, Ethernet2
B E 2001:192:168:10::103/128 [20/0]
via fe80::7405:8fff:fee1:df9d, Ethernet1
via fe80::b5:e1ff:fe29:6eba, Ethernet2
B E 2001:192:168:10::104/128 [20/0]
via fe80::7405:8fff:fee1:df9d, Ethernet1
via fe80::b5:e1ff:fe29:6eba, Ethernet2
C 2001:192:168:11::101/128 [0/0]
via Loopback1, directly connected
B E 2001:192:168:11::102/128 [20/0]
via fe80::7405:8fff:fee1:df9d, Ethernet1
via fe80::b5:e1ff:fe29:6eba, Ethernet2
B E 2001:192:168:11::103/128 [20/0]
via fe80::7405:8fff:fee1:df9d, Ethernet1
via fe80::b5:e1ff:fe29:6eba, Ethernet2
B E 2001:192:168:11::104/128 [20/0]
via fe80::7405:8fff:fee1:df9d, Ethernet1
via fe80::b5:e1ff:fe29:6eba, Ethernet2
Leaf101#ping 2001:192:168:10::104 source lo0
PING 2001:192:168:10::104(2001:192:168:10::104) from 2001:192:168:10::101 : 52 data bytes
60 bytes from 2001:192:168:10::104: icmp_seq=1 ttl=63 time=0.314 ms
60 bytes from 2001:192:168:10::104: icmp_seq=2 ttl=63 time=0.139 ms
60 bytes from 2001:192:168:10::104: icmp_seq=3 ttl=63 time=0.057 ms
60 bytes from 2001:192:168:10::104: icmp_seq=4 ttl=63 time=0.052 ms
60 bytes from 2001:192:168:10::104: icmp_seq=5 ttl=63 time=0.063 ms
--- 2001:192:168:10::104 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.052/0.125/0.314/0.099 ms, ipg/ewma 0.164/0.214 ms
Leaf101#ping 2001:192:168:11::104 source lo1
PING 2001:192:168:11::104(2001:192:168:11::104) from 2001:192:168:11::101 : 52 data bytes
60 bytes from 2001:192:168:11::104: icmp_seq=1 ttl=63 time=0.318 ms
60 bytes from 2001:192:168:11::104: icmp_seq=2 ttl=63 time=0.122 ms
60 bytes from 2001:192:168:11::104: icmp_seq=3 ttl=63 time=0.111 ms
60 bytes from 2001:192:168:11::104: icmp_seq=4 ttl=63 time=0.104 ms
60 bytes from 2001:192:168:11::104: icmp_seq=5 ttl=63 time=0.108 ms
--- 2001:192:168:11::104 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.104/0.152/0.318/0.084 ms, ipg/ewma 0.188/0.232 ms
Et voila ! c’est fini pour l’Underlay, en quelques étapes seulement notre réseau Underlay est prêt à l’emploi, les Leafs sont maintenant visibles dans la Fabric à travers les interfaces Loopback0 et Loopback1, ces dernières vont servir plus tard pour configurer le réseau Overlay (Plan de contrôle et plan de donnée).
Un autre point important dans ce modèle de configuration de l’underlay est la scalabilité qu’il offre : dans le cas ou on souhaite rajouter un ou plusieurs nouveaux Leafs, la configuration reste très simple et facile, il suffit de dupliquer la configuration d’un Leaf en changeant uniquement l’adressage des interfaces Loopback0 et Loopback1, il n’y a plus besoin de se prendre la tête avec le découpage IP des réseaux d’interconnexions ainsi que l’établissement statique de toutes les sessions eBGP, ce point consitue un gain important pour l’exploitation (moins de source d’erreurs de configuration) ainsi que pour le déploiement de Fabric VxLAN/EVPN de taille importante.
Dans la troisième partie de cette série d’articles, nous allons pouvoir déployer l’Overlay EVPN et commencer à founir les premiers services d’extension de niveau 2 et niveau 3, nous allons aussi nous intéresser aux échanges EVPN (Type-1 à Type-5) et les expliquer à partir d’études de cas.
Si vous avez des questions ou vous avez besoin d’un complément d’informations ou une consultation spécifique à votre environement, n’hésitez pas à laisser un message en commentaire de la page ou nous contacter directement à l’adresse : contact@mhd-experts.com.
Architecture DC VxLAN-EVPN – Deep Dive – partie 3 - MHD Experts
janvier 25, 2023[…] l’article précédent, nous avons configuré l’Underlay de notre Fabric VxLAN/EVPN en profitant des avantages proposés […]