Pourquoi cette comparaison ?
Je ne sais pas si vous vous en souvenez mais lors de la configuration de l'overlay EVPN/VXLAN dans la fabric, j'avais énuméré les différentes types de routes que EVPN implémentait dont la 5 !
Elle permet de diffuser des préfixes IP via les peerings EVPN.
Et donc ?
On peut très bien penser à des livrer des L3VPN MPLS aux clients mais avec la techno EVPN !
Et en plus, un VPN MPLS fonctionne uniquement v4. Bah oui, LDP n'a pas été pensé pour du v6 !
Vous avez deviné le sujet de cet épisode ?
OUI ! On supprime le MPLS pour passer en full core EVPN. On va voir les avantages (et d'autres 😄).
Enfin... On va aussi s'aider du VXLAN ! Au lieu d'une architecture en VLAN-BASED (donc du pur L2 over L4), on va faire du L3 over L4 ! (Trop stylé nan ?)
Cet épisode posera les bases pour l'implémentation du SR-MPLS (avant le SRv6. Bah oui, on avance lentement mais surement au but ultime : un backbone full core IPv6).
Pour bien faire la comparaison entre le MPLS et EVPN/VXLAN, on va partir sur une belle architecture MPLS avec 2 P et 2 PE :
(Si vous avez oublié le principe des P et PE, un petit tour sur l'épisode du MPLS 😋)
Configuration IGP
Pour que PE1 puisse peer avec PE2, il faut que les IPs de loopback soient diffusées via un IGP. Je suis parti sur l'ISIS :
| Routeur | Loopback | IP 1 | IP 2 |
|---|---|---|---|
| PE1 | 100.127.0.0 | 100.64.0.0 | |
| P1 | 100.127.0.1 | 100.64.0.1 | 100.65.0.0 |
| P2 | 100.127.0.2 | 100.64.0.3 | 100.65.0.1 |
| PE2 | 100.127.0.3 | 100.64.0.2 |
Exemple avec PE1 :
PE1#sh run | s isis
router isis BACKBONE
net 49.0001.2700.0000.0000.00
is-type level-2
log-adjacency-changes
!
address-family ipv4 unicast
interface Ethernet2
description P1
no switchport
ip address 100.64.0.0/31
isis enable BACKBONE
isis network point-to-point
interface Loopback1
ip address 100.127.0.0/32
isis enable BACKBONE
L'ISIS monte bien. Les Loopbacks sont bien annoncées et apprises par les PE !
PE1#sh isis neighbors
Instance VRF System Id Type Interface SNPA State Hold time Circuit Id
BACKBONE default P1 L2 Ethernet2 P2P UP 27 1A
PE1#sh ip route
C 100.64.0.0/31 is directly connected, Ethernet2
I L2 100.64.0.2/31 [115/30] via 100.64.0.1, Ethernet2
I L2 100.65.0.0/31 [115/20] via 100.64.0.1, Ethernet2
C 100.127.0.0/32 is directly connected, Loopback1
I L2 100.127.0.1/32 [115/20] via 100.64.0.1, Ethernet2
I L2 100.127.0.2/32 [115/30] via 100.64.0.1, Ethernet2
I L2 100.127.0.3/32 [115/40] via 100.64.0.1, Ethernet2
PE1#ping 100.127.0.3
PING 100.127.0.3 (100.127.0.3) 72(100) bytes of data.
80 bytes from 100.127.0.3: icmp_seq=1 ttl=62 time=6.16 ms
80 bytes from 100.127.0.3: icmp_seq=2 ttl=62 time=4.29 ms
80 bytes from 100.127.0.3: icmp_seq=3 ttl=62 time=4.33 ms
80 bytes from 100.127.0.3: icmp_seq=4 ttl=62 time=4.45 ms
80 bytes from 100.127.0.3: icmp_seq=5 ttl=62 time=4.26 ms
--- 100.127.0.3 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 26ms
rtt min/avg/max/mdev = 4.256/4.696/6.164/0.736 ms, ipg/ewma 6.596/5.405 ms
L'IGP ? Done. Au suivant !
Configuration BGP
A notre niveau, c'est pas ce qui pose le plus de problème ! On est expert BGP avec notre underlay/overlay 😎
PE1#sh run | s bgp
router bgp 65000
timers bgp 15 30
neighbor 100.127.0.3 remote-as 65000
neighbor 100.127.0.3 update-source Loopback1
neighbor 100.127.0.3 description PE2
neighbor 100.127.0.3 send-community extended
!
address-family evpn
neighbor 100.127.0.3 activate
!
address-family ipv4
no neighbor 100.127.0.3 activate
PE1#sh bgp evpn summary
BGP summary information for VRF default
Router identifier 100.127.0.0, local AS number 65000
Neighbor Status Codes: m - Under maintenance
Description Neighbor V AS MsgRcvd MsgSent InQ OutQ Up/Down State PfxRcd PfxAcc
PE2 100.127.0.3 4 65000 45 44 0 0 00:04:15 Estab 0 0
On peer avec PE2 avec son AS. Il faut penser à update-source avec la Loopback car on est en iBGP donc peering BGP avec les Loopbacks ! Le send community permet d'envoyer les RT des VRF.
Pourquoi un no activate sur l'adress-family ipv4 ? Dans l'épisode du DCI, j'ai eu des problématiques avec les peers des EPVN qui diffusaient les routes IPv4 via ce peering. J'avais mis en place une route-map qui deny tout. Mais on peut très bien penser à désactiver tout simplement le v4 pour ce peering ! C'est une autre solution qui fonctionne (et qui est peut-être un plus propre ?)
Bon le plus simple est fait. Attaquons nous au plus compliqué ?
Configuration VRF/VXLAN
Pour commencer, on crée la VRF sur les deux PE :
PE1#sh run | i vrf
vrf instance NARUTO
ip routing vrf NARUTO
Et oui sur eOS, le RD se situe dans la configuration BGP et non pas dans la VRF.
Ensuite, on place quelques interfaces dans la VRF :
interface Ethernet7.1000
encapsulation dot1q vlan 1000
vrf NARUTO
ip address 192.168.100.1/24
!
interface Ethernet7.2000
encapsulation dot1q vlan 2000
vrf NARUTO
ip address 192.168.200.1/24
On parle de VXLAN depuis le début mais il est où ?
Hé bah juste la :
PE1#sh run int vxlan1
interface Vxlan1
vxlan source-interface Loopback1
vxlan udp-port 4789
vxlan vrf NARUTO vni 200
Dans la fabric, on translate un VLAN à une VNI. Ici, au lieu d'un VLAN, on translate une VRF à une VNI. Ici, la VRF NARUTO sera translaté dans les échanges VXLAN dans la VNI 200.
Donc une VNI = une VRF 😃
Pour finir, la configuration du BGP. Attention, petite subtilité dans la configuration des route-target :
router bgp 65000
vrf NARUTO
rd 65000:65000
route-target import evpn 65000:65000
route-target export evpn 65000:65000
redistribute connected
Dans le BGP de la VRF NARUTO, on importe et exporte les routes depuis la table EVPN !
Il existe aussi d'autres méthodes d'importe/exporte :
PE1(config-router-bgp-vrf-NARUTO)#route-target import ?
ASN(asplain):nn or ASN(asdot):nn or IP-address:nn Route Target
evpn EVPN address family
flow-spec-vpn-ipv4 Flowspec VPN IPv4 unicast
address family
flow-spec-vpn-ipv6 Flowspec VPN IPv6 unicast
address family
vpn-ipv4 MPLS L3 VPN IPv4 unicast
address family
vpn-ipv6 MPLS L3 VPN IPv6 unicast
address family
Pour être honnête, c'est la première fois que j'entends parler de flow-spec. Apparemment, il sert à se protéger des attaques DDoS ? Stylé tout ça !
Et pour les autres, c'est assez simple à comprendre.
Si on avait utilisé un L3VPN MPLS (donc avec un data plane MPLS), on aurait importé avec vpn-ipv4 !
On peut aussi penser à une utilisation de l'EVPN et VPN-IPV4 commune ! Imaginez, un PE avec une patte dans un backbone EVPN et un autre dans un MPLS. Si on importe avec les deux, les routes, bien qu'apprises via deux manières différentes, vont être inscrites dans la table de routage de la VRF (Bon OK, à labber ! Mais dans l'idée, c'est stylé nan ?)
Côté PE2 :
PE2#sh run int eth7
interface Ethernet7
no switchport
vrf NARUTO
ip address 192.168.2.1/24
PE2#sh ip route vrf NARUTO
VRF: NARUTO
Gateway of last resort is not set
C 192.168.2.0/24 is directly connected, Ethernet7
B I 192.168.100.0/24 [200/0] via VTEP 100.127.0.0 VNI 200 router-mac 50:00:00:f6:ad:37 local-interface Vxlan1
B I 192.168.200.0/24 [200/0] via VTEP 100.127.0.0 VNI 200 router-mac 50:00:00:f6:ad:37 local-interface Vxlan1
Les routes dans la VRF sont apprises via le VTEP 100.127.0.0 (PE1 avec la VNI 200).
Un petit ping ?
PE2#ping vrf NARUTO 192.168.100.1
PING 192.168.100.1 (192.168.100.1) 72(100) bytes of data.
80 bytes from 192.168.100.1: icmp_seq=1 ttl=65 time=17.7 ms
80 bytes from 192.168.100.1: icmp_seq=2 ttl=65 time=8.38 ms
80 bytes from 192.168.100.1: icmp_seq=3 ttl=65 time=6.50 ms
80 bytes from 192.168.100.1: icmp_seq=4 ttl=65 time=5.14 ms
80 bytes from 192.168.100.1: icmp_seq=5 ttl=65 time=16.0 ms
--- 192.168.100.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 57ms
rtt min/avg/max/mdev = 5.139/10.752/17.749/5.131 ms, pipe 2, ipg/ewma 14.307/14.289 ms
PE2#ping vrf NARUTO 192.168.200.1
PING 192.168.200.1 (192.168.200.1) 72(100) bytes of data.
80 bytes from 192.168.200.1: icmp_seq=1 ttl=65 time=6.72 ms
80 bytes from 192.168.200.1: icmp_seq=2 ttl=65 time=4.37 ms
80 bytes from 192.168.200.1: icmp_seq=3 ttl=65 time=4.30 ms
80 bytes from 192.168.200.1: icmp_seq=4 ttl=65 time=4.76 ms
80 bytes from 192.168.200.1: icmp_seq=5 ttl=65 time=4.58 ms
--- 192.168.200.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 25ms
rtt min/avg/max/mdev = 4.304/4.946/6.724/0.903 ms, ipg/ewma 6.367/5.812 ms
C'est quand même incroyable que les RFC mentent pas ! Allez, comme d'habitude, une petite analyse de trame.
Wireshark
C'est dans un update que ca ce passe (l'échange est initié par PE2 ici).
On commence par regarder les EXTEND_COMMUNITIES :
On apprend donc le route-target de la route (Hé oui, ce que je vous ai dit plus haut, n'était pas un mensonge ! L'utilité du send-community extended). C'est aussi dedans qu'on apprend la méthode d'encapsulation. Ici VXLAN !
Bon et les routes dans tout ça ?
On retrouve le couple AFI/SAFI de l'EVPN (25/70). C'est bien une route type 5 d'annoncée et le préfixe IP : 192.168.2.0/24.
Par contre c'est quoi ce MPLS ? Tu nous avais pas dit qu'on utilisait pas le MPLS chef ? Tu nous as menti ? Choqué.
Nan gros, attends. Reste tranquille men.
C'est parce qu'EVPN a quand même hérité des propriétés de MPLS ! On retrouve bien la VNI 200 qu'on a mis en place (20012). On n'allait pas changer le contenu de la trame BGP pour les VNI quand même. C'est historique et ca restera comme ça.
Bon OK, le 12. Je ne sais pas d'où il sort. Même en relisant la RFC, je ne comprends pas :/ Peut être un offset ?
Si quelqu'un lit ça, svp, un peu d'aide serait la bienvenue !
En changeant la VNI par 2000 :
Le label dans la trame change bien.
Bon OK et un petit ping maintenant ?
On observe bien que le paquet est encapsulé dans la VNI 200 !
Amélioration
Le MPLS a été crée dans le début des années 2000 et n'est donc pas DU TOUT adapté aux besoins d'Internet et des FAI d'aujourd'hui et c'est NORMAL. Qui aurait pu pensé que le réseau évoluerait autant en l'espace d'une vingtaine d'années ?
Par conséquent, de nouveaux protocoles ont commencé à émerger dont l'EVPN. Il permet plein de choses comme on a déjà pu le voir dans ce blog 😄
Aujourd'hui, il nous a permit de montrer qu'un backbone sans MPLS est possible TECHNIQUEMENT.
L'EVPN/VXLAN avec les routes types 5 permettent d'outrepasser le MPLS que ce soit en v4 ou en v6 (Oui j'ai pas montré le v6, je ne voulais pas vous montrer une solution de bricolage qui permet de faire les deux).
Dans la réalité, et dans mon backbone, cela voudrait dire que chaque paquet passe par deux entêtes VXLAN.... Bonjour les performances !
De plus, cela ne permet pas de faire du trafic engineering et ce n'est pas scalable sur un grand backbone.
Il faudrait donc un protocole qui est stylé (bah oui, le but dans le réseau est de s'amuser), permet le v4 comme le v6, pas trop d'entêtes, simple à configurer, remplace le MPLS, implémente le trafic engineering et est compatible avec EVPN.
Euh toujours plus ? Comme si un tel protocole existait LOL
Hé bah si, il existe ! Le Segment routing ! Et je peux vous dire une chose : il est sacrément beau gosse ce protocole. Mais VRAIMENT beaucoup trop !
Prochain épisode orienté backbone ? La mise en place du SR-MPLS. (Toujours dans un environnement de test/lab, dans le backbone que je virtualise, je passerai directement en SRv6 avec des beaux ASR9k en PE/P 🤩🤩🤩)
On fera donc de l'EVPN/SR-MPLS en v4 et v6 !
Je termine sur un petit mot de fin : Vive les Lan2Lan, les serveurs à 3000 balles pour du lab et l'IPoE !