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 :

DC Fabric – Leaf & Spine Architecture

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 »

DC Fabric : Underlay Architecture

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.

Author

Hicham est un architecte réseau avec plus de 22 ans d’expérience dans le domaine des réseaux et essentiellement sur les environnements Cisco, il dispose d’un diplôme d’ingénieur d’état dans le domaine des Réseaux et Télécoms et aussi de quatre certifications CCIE dans les domaines (Routing & Switching, Security, Service Provider et Datacenter). Durant son expérience, Hicham est intervenu sur des projets importants et complexes chez les opérateurs ainsi que les grandes entreprises sur différents domaines (LAN, WAN, DATACENTER), il réalise souvent des audits sur des architectures complexes pour les optimiser ainsi que des formations auprès de ses clients afin de démystifier les technologies pour une meilleure compréhension et simplification de l’exploitation au quotidien. Hicham est contributeur du blog MHD Experts et joignable à l’adresse : hicham.tahri@mhd-experts.com

Write A Comment