RFC 7432
Avant de commencer à configurer l'EVPN, une petite lecture de la RFC s'impose !
On nous dit qu'EVPN annonce plusieurs types de routes :
- Ethernet Auto-Discovery (A-D) route : Utilisé lorsque l'Ethernet Segment Identifier (ESI) est configuré. Pour du multi-homing (une alternatif au MLAG ?)
- MAC/IP Advertisement route : Pour la diffusion et l'apprentissage des MACs et les IPs (si ARP).
- Inclusive Multicast Ethernet Tag route : Utilisé pour annoncer les VNI que le Leaf porte sur lui
- Ethernet Segment route : Utilisé dans le cas de multi-homing
- IP Prefix route (https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-prefix-advertisement-04#section-3) : Pour annoncer des préfixes IP
Dans notre cas, seulement la type 2 et la 3 semble nous intéresser (peut-être la 5 aussi). Allez, on met tout ça en place et on regardera les trames pour tout comprendre !
Configuration EVPN
Comme déjà dit, l'EVPN est une extension du protocole BGP donc c'est dans ce dernier que ca va nous intéresser.
Leaf1-B1#sh run | s bgp
router bgp 65001
neighbor GROUP_OVERLAY peer group
neighbor GROUP_OVERLAY remote-as 65000
neighbor GROUP_OVERLAY update-source Loopback1
neighbor GROUP_OVERLAY ebgp-multihop 2
neighbor GROUP_OVERLAY send-community extended
neighbor 2001:172:16:1::10 peer group GROUP_OVERLAY
neighbor 2001:172:16:1::10 description Spine1
neighbor 2001:172:16:1::20 peer group GROUP_OVERLAY
neighbor 2001:172:16:1::20 description Spine2
!
address-family evpn
neighbor GROUP_OVERLAY activate
Comme pour l'underlay, on crée un peer group avec dedans l'AS des Spines, l'update source Lo1 car c'est à partir de cette IP qu'on souhaite établir les sessions BGP.
Quant au multi-hop, dans une trame eBGP, le TTL est de 1, c'est à dire, que la trame ne va pouvoir traverser de routeur. Si le lien entre leaf/spine tombe alors la trame va devoir passer par le peer-link et donc par un autre leaf pour pouvoir monter une session eBGP. Il faut donc manuellement incrémenter la valeur du TTL dans la configuration BGP.
Le send-community extended va permettre l'envoie des RT (on voit ça après).
On ne peut pas peer sur un range d'interface ce coup ci donc on renseigne manuellement les peers avec l'IP des Spines tout en les mettant dans le groupe GROUP_OVERLAY.
Enfin, on active l'EVPN.
Côté Spine, même principe du BGP en mode écoute :
Spine1-B1#sh run | s bgp
router bgp 65000
bgp listen range 2001:172:16:1::/64 peer-group GROUP_OVERLAY peer-filter PF_FABRIC_AS
neighbor GROUP_OVERLAY peer group
neighbor GROUP_OVERLAY update-source Loopback1
neighbor GROUP_OVERLAY ebgp-multihop 2
neighbor GROUP_OVERLAY send-community extended
!
address-family evpn
neighbor GROUP_OVERLAY activate
Spine1-B1#sh bgp evpn summary
BGP summary information for VRF default
Router identifier 172.16.1.10, local AS number 65000
Neighbor Status Codes: m - Under maintenance
Neighbor V AS MsgRcvd MsgSent InQ OutQ Up/Down State PfxRcd PfxAcc
2001:172:16:1::1 4 65001 23 17 0 0 00:02:37 Estab 0 0
2001:172:16:1::2 4 65001 42 38 0 0 00:08:01 Estab 0 0
2001:172:16:1::3 4 65002 47 40 0 0 00:08:00 Estab 0 0
2001:172:16:1::4 4 65002 46 40 0 0 00:07:47 Estab 0 0
Leaf1-B1#sh bgp evpn summary
BGP summary information for VRF default
Router identifier 172.16.1.1, local AS number 65001
Neighbor Status Codes: m - Under maintenance
Description Neighbor V AS MsgRcvd MsgSent InQ OutQ Up/Down State PfxRcd PfxAcc
Spine1 2001:172:16:1::10 4 65000 111 126 0 0 00:00:00 Estab 0 0
Spine2 2001:172:16:1::20 4 65000 100 115 0 0 00:00:00 Estab 0 0
Toutes les sessions sont établies. Maintenant, intéressons nous sur les échanges BGP.
J'en profite pour détailler comment faire une capture de paquets sur eve-ng avec des paramètres bien spécifiques. Mon serveur est uniquement accessible avec une clé publique, sur un port différent que 22 et pas depuis le login root. Pour ce faire, il faut localiser le fichier wireshark_wrapper.bat (C:\Program Files\EVE-NG). (Pensez à mettre l'utilisateur dans le groupe sudoers 😜)
L'ouvrir et remplacer comme ça (avec les bonnes variables USERNAME, PORT et CHEMIN DE LA CLE PRIVEE) :
@ECHO OFF
SET USERNAME="USER"
SET PORT="PORT"
SET S=%1
SET S=%S:capture://=%
FOR /f "tokens=1,2 delims=/ " %%a IN ("%S%") DO SET HOST=%%a&SET INT=%%b
IF "%INT%" == "pnet0" SET FILTER=" not port %PORT%"
ECHO "Connecting to %USERNAME%@%HOST%..."
"C:\Program Files\EVE-NG\plink.exe" -ssh -P %PORT% -batch -i "CHEMIN DE LA CLE PRIVEE" %USERNAME%@%HOST% "sudo tcpdump -U -i %INT% -s 0 -w -%FILTER%" | "C:\Program Files\Wireshark\Wireshark.exe" -k -i -
Petit aparté fini, on rattaque !
Chaque address-family dans BGP est définit par un couple d'identifiant. Par exemple, VPNV4 (utilisé pour les L3VPN MPLS) est définit par AFI 1 / SAFI 128.
Pour celle d'EVPN, c'est AFI 25 / SAFI 70 comme le signale la RFC 7432 :
The EVPN NLRI is carried in BGP [RFC4271] using BGP Multiprotocol
Extensions [RFC4760] with an Address Family Identifier (AFI) of 25
(L2VPN) and a Subsequent Address Family Identifier (SAFI) of 70
(EVPN). The NLRI field in the MP_REACH_NLRI/MP_UNREACH_NLRI
attribute contains the EVPN NLRI (encoded as specified above).
Allez, maintenant, on ouvre la trame BGP (c'est un update et non un open après relecture, c'est pas grave, j'ai juste pas été assez rapide pour prendre le premier échange) et on retrouve bien l'identifiant de l'address-family ! Top, la RFC ne ment pas 😁.
La configuration de l'EVPN est déjà finie ! Place au data plane : VXLAN
Configuration VXLAN
VXLAN est configuré uniquement sur les VTEP donc les leafs dans notre topologie. Les spines ont aucune connaissance de faire du VXLAN, ils transportent juste l'information, comme les P dans une architecture MPLS.
Allez, on crée un VLAN sur les Leafs et on le map sur une VNI :
Leaf1-B1#sh run | s vlan 1000
vlan 1000
name TERMINAL
Leaf1-B1#sh run int eth8
interface Ethernet8
description TERMINAL
switchport access vlan 1000
Leaf1-B1#sh run int vxlan1
interface Vxlan1
vxlan source-interface Loopback2
vxlan udp-port 4789
vxlan encapsulation ipv6
vxlan vlan 1000 vni 101000
L'interface pour faire du VXLAN s'appelle ...... interface Vxlan ! Plutôt simple nan ? On vient lui préciser depuis quelle interface elle encapsule, la méthode d'encapsulation IPv6 et le mappage du VLAN sur la VNI.
Maintenant, comment faire pour que les échanges EVPN se fassent ?
Ca va se passer dans la configuration BGP :
Leaf1-B1#sh run | s vlan 1000
router bgp 65001
vlan 1000
rd 65001:101000
route-target both 1000:101000
redistribute learned
On crée un vlan 1000 et on lui indique un RD, un RT et le redistribute learned qui permet la diffusion des MACs. Il faut penser méthodiquement : le RD, je suis parti sur AS:VNI et pour le RT VLAN:VNI. Comme ça, c'est plus simple pour s'en souvenir !
Leaf1-B1#sh mac address-table vlan 1000
Mac Address Table
------------------------------------------------------------------
Vlan Mac Address Type Ports Moves Last Move
---- ----------- ---- ----- ----- ---------
1000 5000.0007.0007 DYNAMIC Et8 1 0:15:33 ago
La MAC est bien apprise sur le port eth8. Maintenant, faisons la même chose mais sur Leaf3. Et on raffiche la table MAC :
Leaf1-B1#sh mac address-table vlan 1000
Mac Address Table
------------------------------------------------------------------
Vlan Mac Address Type Ports Moves Last Move
---- ----------- ---- ----- ----- ---------
1000 5000.0007.0007 DYNAMIC Et8 1 0:15:33 ago
1000 5000.0008.0007 DYNAMIC Vx1 1 0:06:24 ago
La MAC de l'autre terminal remonte bien sur le port Vxlan1 !
Allons regarder de plus près les échanges BGP :
Premier échange : On voit que c'est dans un BGP update entre Leaf1 et Spine1 que les informations sont annoncées. On y retrouve l'AS de Leaf1 et le couple qui définit l'EVPN (AFI/SAFI). On voit aussi que c'est une route de type 3 qui est annoncée. Nickel ! Comme on l'a vu dans l'introduction, cette route permet au leaf de dire quels VNI il a en local. Là il annonce qu'il possède le VNI avec le rd 65001:101000 soit celui du VLAN 1000.
Ensuite :
Deuxième échange : encore un BGP UPDATE entre Leaf1 et Spine1. On y retrouve toujours bien l'AS de Leaf1 et l'AFI/SAFI de l'EVPN. Mais ce coup-ci, c'est une route de type 2 qui est annoncée (cf l'introduction pour les gens qu'ont déjà oublié !) pour annoncer la MAC de l'équipement branchée sur Et8.
Sur leaf3, on retrouve bien la MAC sur l'interface Vx1 :
Leaf3-B2#sh mac address-table vlan 1000
Mac Address Table
------------------------------------------------------------------
Vlan Mac Address Type Ports Moves Last Move
---- ----------- ---- ----- ----- ---------
1000 5000.0007.0007 DYNAMIC Vx1 1 0:01:17 ago
1000 5000.0008.0007 DYNAMIC Et8 1 0:00:02 ago
Faisons un ping entre les 2 terminaux :
LNS1#ping 192.168.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 10/11/15 ms
LNS1#sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.1.1 - 5000.0007.0007 ARPA GigabitEthernet0/7
Internet 192.168.1.2 22 5000.0008.0007 ARPA GigabitEthernet0/7
Et béh, si ça c'est pas beau ? Ca à l'air de bien faire le boulot l'EVPN nan ?
Et le pire dans tout ça, c'est que ça fonctionne comme le dit la RFC.
Allez, encore une petite commande pour prouver tout ça mais laquelle ?
Leaf1-B1#sh bgp evpn route-type ?
auto-discovery Filter by Ethernet auto-discovery (A-D) route (type 1)
ethernet-segment Filter by Ethernet segment route (type 4)
imet Filter by inclusive multicast Ethernet tag route (type 3)
ip-prefix Filter by IP prefix route (type 5)
join-sync Filter by multicast join sync route (type 7)
leave-sync Filter by multicast leave sync route (type 8)
mac-ip Filter by MAC/IP advertisement route (type 2)
smet Filter by selective multicast Ethernet tag route (type 6)
spmsi Filter by selective PMSI auto discovery route (type 10)
Euh, il y a beaucoup plus de type de routes que prévus là ? Dans l'introduction, on en a vu que 5.
Effectivement, tous les types de routes ne sont pas définis dans la RFC 7432. J'ai juste expliqué celles définies par celle ci et la 5 car on va peut-être s'en servir dans le futur ! Les autres ne me semblent pas utiles (du moins pas maintenant).
Allez, comme on vu dans un échange BGP, c'était une type 2 d'annoncée donc on va afficher la ...... type 2 !
Leaf1-B1#sh bgp evpn route-type mac-ip
BGP routing table information for VRF default
Router identifier 172.16.1.1, local AS number 65001
Route status codes: * - valid, > - active, S - Stale, E - ECMP head, e - ECMP
c - Contributing to ECMP, % - Pending best path selection
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop
Network Next Hop Metric LocPref Weight Path
* > RD: 65001:101000 mac-ip 5000.0007.0007
- - - 0 i
* >Ec RD: 65001:101000 mac-ip 5000.0008.0007
2001:172:16:2::3 - 100 0 65000 65002 i
* ec RD: 65001:101000 mac-ip 5000.0008.0007
2001:172:16:2::3 - 100 0 65000 65002 i
Oulah, encore un pavé ! Bon allez, on s'y met :
- La première est pour la MAC apprise en local
- La deuxième pour la MAC apprise en EVPN et passant par Spine1
- La troisième pour la MAC apprise en EVPN et passant par Spine2
C'était pas très compliqué finalement.
Bon, on va rentrer un peu plus dans le dur maintenant !
La façon où le VXLAN est monté s'appelle VLAN - based service. Petite lecture de la RFC pour tout comprendre :
6.1. VLAN-Based Service Interface
With this service interface, an EVPN instance consists of only a
single broadcast domain (e.g., a single VLAN). Therefore, there is a
one-to-one mapping between a VID on this interface and a MAC-VRF.
Since a MAC-VRF corresponds to a single VLAN, it consists of a single
bridge table corresponding to that VLAN. If the VLAN is represented
by multiple VIDs (e.g., a different VID per Ethernet segment per PE),
then each PE needs to perform VID translation for frames destined to
its Ethernet segment(s). In such scenarios, the Ethernet frames
transported over an MPLS/IP network SHOULD remain tagged with the
originating VID, and a VID translation MUST be supported in the data
path and MUST be performed on the disposition PE. The Ethernet Tag
ID in all EVPN routes MUST be set to 0.
Encore un beau pavé ! Bon, on va essayer de comprendre tout ça. On apprend le principe d'une MAC-VRF. On peut faire la comparaison avec l'IP-VRF (dans le cadre d'un L3VPN MPLS), au lieu de transporter de l'IP, dans le cas du VXLAN ce sont des MACs qui sont transportées.
On ne peut que faire du one-to-one mapping avec cette technique. Un VLAN = une VNI = un domaine de broadcast = une table.
Toute la deuxième partie ne nous intéresse pas, c'est utilisé pour du multi-homing.
Cette méthode a un gros défaut : la limite du one-to-one mapping. Associer chaque VLAN à une VNI puis l'annoncer dans le BGP... C'est chiant !
Allez, on lit encore un peu la RFC ! On va bien arriver à trouver une méthode qui va nous simplifier la vie quand même ! Peut-être le VLAN Bundle Service Interface ?
6.2. VLAN Bundle Service Interface
With this service interface, an EVPN instance corresponds to multiple
broadcast domains (e.g., multiple VLANs); however, only a single
bridge table is maintained per MAC-VRF, which means multiple VLANs
share the same bridge table. This implies that MAC addresses MUST be
unique across all VLANs for that EVI in order for this service to
work. In other words, there is a many-to-one mapping between VLANs
and a MAC-VRF, and the MAC-VRF consists of a single bridge table.
Furthermore, a single VLAN must be represented by a single VID --
e.g., no VID translation is allowed for this service interface type.
The MPLS-encapsulated frames MUST remain tagged with the originating
VID. Tag translation is NOT permitted. The Ethernet Tag ID in all
EVPN routes MUST be set to 0.
Bon et celle ci, ça dit quoi ? Déjà, on apprend que le many-to-one est possible ! On va pourvoir mapper plusieurs VLANs dans la même VNI ! Cool ? Et en plus, chaque VLAN possède un domaine de broadcast. Cependant, tous les VLANs possèdent une seule et même table ! Pas ouf finalement car ça veut dire que toutes les MACs doivent être différentes. On perd le principe même du VLAN. On avance bien mais c'est toujours pas ça.
6.3. VLAN-Aware Bundle Service Interface
With this service interface, an EVPN instance consists of multiple
broadcast domains (e.g., multiple VLANs) with each VLAN having its
own bridge table -- i.e., multiple bridge tables (one per VLAN) are
maintained by a single MAC-VRF corresponding to the EVPN instance.
Broadcast, unknown unicast, or multicast (BUM) traffic is sent only
to the CEs in a given broadcast domain; however, the broadcast
domains within an EVI either MAY each have their own P-Tunnel or MAY
share P-Tunnels -- e.g., all of the broadcast domains in an EVI MAY
share a single P-Tunnel.
Bon la dernière, c'est la bonne ? Le VLAN-Aware Bundle Service Interface ? Je l'avoue, j'ai pas tout mis, la définition était longue mais elle est disponible ici : https://www.rfc-editor.org/rfc/rfc7432.html#section-6.3.
Je crois qu'on a touché le jackpot ! On apprend que chaque VLAN possède son propre domaine de diffusion, sa propre table et le many-to-one est possible !
Mais à quoi ça va servir tout ça ? La seule limite est notre imagination ! Par exemple, on peut très bien penser à une MAC-VRF par service (MPLS, Téléphonie, Housing), une par client, etc.
Pour l'instant, notre backbone est petit et on n'est pas encore développé donc je ne vais pas utilisé cette méthode. Mais on garde ça dans un coin de la tête !
Conclusion
Etonnamment, l'épisode sur l'overlay aura été plus court que l'underlay. Notre fabric est opérationnelle ! Maintenant, les seules configurations qu'on va pousser dans la fabric sera lors d'une création d'un VLAN pour le propager (ou si rajout d'un leaf).
Mais qui dit pousser de la configuration dit erreurs humaines. Les eOS d'Arista possède une REST API mais de l'ansible est possible. On pourrait même installer le CloudVision d'Arista (l'équivalent de l'ACI chez Cisco, pour permettre de manager la fabric à partir d'un seul point). A voir par la suite ce qu'on fait.
Mais qui dit VXLAN/EVPN dit plus d'entêtes dans la trame et donc problème de...... MTU ! Avant de configurer notre MPLS et notre évasion Internet, le prochain (petit) épisode sera dédié sur le débug de la MTU et de la jumbo frame !
Je termine sur un petit mot de fin : Kakashi Double mangekyou sharingan Susano Perfect EST PLUS FORT que Gai 8 portes🥷🥷