De nouveaux protocoles
Pas tant que ca enfaite ! Comme on l'a vu, le BGP va nous permettre d'échanger les communautés pour faire du L3VPN / L2VPN MPLS. Et accessoirement peer avec le BR pour récupérer la défault route.
Il faut savoir que je n'aime pas le statique. Vive le dynamique ! Le but est de ne mettre AUCUNE route statique dans le backbone (bon on sera obligé des fois). On va donc se servir du BGP en plus de l'ISIS.
Allez, un peu de définition :
- P : Provider (équivalent au spine dans une fabric EVPN/VXLAN)
- PE : Provider Edge (équivalent au leaf dans une fabric EVPN/VXLAN)
- CPE : Customer Premises Equipement : Routeur en bout de ligne chez le client
Les P n'ont aucune connaissance du trafic data plane, ils routent juste les paquets. Il n'y a pas de configuration BGP sur un P ! Juste un IGP (ISIS, OSPF). Contrairement aux PE où eux, montent des peer BGP avec chaque PE pour avoir les routes. Un PE est le routeur où sont montées les interco avec chaque CPE.
Mais dans notre backbone, on a que 2 routeurs, n'est ce pas ?
Oui ! On ne va pas utiliser de P, nous n'en avons strictement aucune utilité. A quoi bon rajouter 2 P (2 pour la redondance) alors que nous avons que 2 PE ? On fera qu'une interco entre nos deux PE.
De la configuration en moins, c'est déjà ça 😄.
Un exemple d'architecture dans un backbone plus développé :
Bon et maintenant le MPLS, c'est quoi ?
Défini dans la RFC 3031, le MultiProtocol Label Switching est un protocole (nan jure ?) entre le niveau 2 et le 3 du modèle OSI. Appelons ce niveau le 2,5. Un terme important utilisé dans MPLS est le Forwarding Equivalence Class (FEC), c'est un groupe de paquets qui est commuté de la même façon. Dans le cas du MPLS, le label va être attribué à un FEC (tous les paquets ayant le même next-hop vont être dans le même FEC).
Donc MPLS va permettre de mettre une étiquette sur les paquets IP en fonction du next-hop pour éviter que le routeur aille chercher dans sa table de routage et avoir un certain temps de traitement. Toute l'intelligence va se faire au niveau juste en dessous d'IP.
ATTENTION ! Il y a un abus de langage que beaucoup de personnes font. Le MPLS est le protocole. Et non, un réseau privé qui interconnecte plusieurs sites géographiquement distancé d'une entreprise, plus communément appelé un L3VPN MPLS. Ce VPN (Virtual Private Network) va s'appuyer sur la technologie MPLS pour fonctionner. Vendre un MPLS ne veut rien dire à part si on a vendu la configuration d'un backbone MPLS à quelqu'un (bonne chance !).
Encore un peu de vocabulaire :
- LER : Routeur MPLS qui va poser un label en fonction du next-hop
- LSR : Routeur MPLS qui va s'occuper uniquement du "switching" du paquet
3 actions sont possible :
- Push : Mettre un label sur un paquet
- Swap : Echanger un label par un autre
- Pop : Supprimer un label
Par défaut, le label est supprimé à l'avant dernier saut. Si on prend la topologie suivante :
Le paquet part de LER1 donc le label sera supprimé à LSR2.
Et comment sont définis les labels ? Grâce au protocole LDP (RFC 3036). Le LDP va être le control plane et le MPLS le data plane.
Toujours plus grosse l'intro ! Bon, on s'active et on va voir comment on monte tout ça.
Configuration MPLS
Tout d'abord, on va activer le MPLS :
LNS1#sh run | i mpls
mpls ip
mpls label protocol ldp
LNS1(config)#int po10.10
LNS1(config-subif)#mpls ip
Par défaut, MPLS va utiliser le protocole le protocole LDP pour établir les labels. Et on active mpls sur l'interface voulue. Les deux routeurs se voient bien !
LNS1#sh mpls ldp neighbor
Peer LDP Ident: 100.127.0.2:0; Local LDP Ident 100.127.0.1:0
TCP connection: 100.127.0.2.40565 - 100.127.0.1.646
State: Oper; Msgs sent/rcvd: 25/24; Downstream
Up time: 00:15:50
LDP discovery sources:
Port-channel10.10, Src IP addr: 100.64.0.2
Addresses bound to peer LDP Ident:
100.127.0.2 100.64.0.2
Regardons la table MPLS :
LNS1#sh mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
16 Pop Label 100.127.0.2/32 0 Po10.10 100.64.0.2
Pour tout paquet ayant un next-hop 100.64.0.2, le local label est 16 et le routeur va pop le label sur son interface de sortie. Et comment ce label est choisi ?
Ouvrons wireshark pour regarder les échanges !
On commence par un basique Hello pour découvrir sur ses segments ses voisins. Regardez, il annonce sa loopback comme IP servant à établir son neighbor.
Ensuite, LNS2 répond avec un initialization message pour établir les neighbors
Une fois les neighbor établis, place aux écahnges des labels (échange de LNS2 vers LNS1) :
Il se passe quoi dans ce message ?
Il y a deux préfixes (100.127.0.1 et 100.127.0.2) avec chacun un label d'attribué. Pour le premier, le label est 0x00010 (16 en décimale) et le second, c'est 0x00003 (3 en décimale).
Il faut savoir que les labels 0 à 15 sont réservés (cf RFC 3032). Donc les labels commencent à 16.
Mais pourquoi dans ce cas, il y a un label 3 pour la Loopback de LNS2 ?
Et bah, il faut s'avoir que toutes les routes apprises en connected vont avoir ce label ? Pourquoi ? Cf l'intro, le label est pop à l'avant dernier saut. Dans le cas d'une interco entre 2 routeurs, MPLS ne servira à rien dans cette configuration (comme le montre ce ping entre LNS1 et LNS2 ):
Du coup, pourquoi on a fait ca enfaite ?
Pour les échanges L3VPN MPLS. Bon je m'avance un peu sur la configuration BGP mais regardez :
Dans le routage global, il ne va pas avoir de label vu que toutes les routes seront apprises en connected sur les 2 routeurs ! Par contre, dans le cas d'un L3VPN MPLS, il y a de base deux labels : 1 pour le routage global et 1 autre pour le VPN. Si on est dans le cas d'une interco entre 2 PE alors il va y avoir qu'un seul label, celui du L3VPN.
Pour rappel, un bon admin réseau est fainéant. Pour éviter que les labels se recouvrent, on va utiliser un bienfait de l'IGP : l'autoconfig des labels.
LNS2(config)#router isis
LNS2(config-router)#mpls ldp autoconfig
Hop, comme ça, c'est pas nous qui gérons les labels. Top, encore de la configuration en moins.
Mais il y a un problème !
Tout le monde vante les bienfaits du MPLS pour faire de la QoS, mais si le label est pop à l'avant dernier saut, comment le dernier routeur fait pour savoir la QoS à appliquer ?
Et bah, on va manuellement dire aux routeurs de ne pas pop le label.
LNS1(config)#mpls ldp explicit-null
Le label sera "explicit-null" ce qui veut dire ce que veut dire 😄 Par contre, le champ Experimental Bits est bien présent ! Top.
LNS1#sh mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
16 explicit-n 100.127.0.2/32 0 Po10.10 100.64.0.2
Mais chef, t'as encore oublié IPv6 là ?
LDP est le protocole pour la distribution de label en IPv4 (OUI, seulement en IPv4).
LDPv6 est défini dans la RFC 7552 et est SEULEMENT implémenté sur les IOS-XR. Les CSR 1000v sont des IOS-XE donc adieu la possibilité de faire du MPLS dans un core full IPv6.
MERCI BEAUCOUP CISCO <3
Une solution serait d'utiliser du segment-routing (SRv6, la relève de MPLS ?). Je le mettrai en place mais pas tout de suite (à l'heure actuelle, je n'ai aucune compétence sur ce protocole). Après, honnêtement, il n'y a pas beaucoup de besoin de la part de client pour des MPLS IPv6 donc on va temporiser ! Des solutions de contournement existent (https://www.rfc-editor.org/rfc/rfc7439#section-3.3.2) mais je trouve cela beaucoup trop moche.
Bon maintenant place au BGP.
Configuration iBGP
Un petit tableau pour définir nos besoins :
| Routeurs | AS | Loopback v4 | Loopback v6 |
|---|---|---|---|
| LNS1 | 64555 | 100.127.0.1 | 2001:DEAD:C0CA:C01A::1 |
| LNS2 | 64555 | 100.127.0.2 | 2001:DEAD:C0CA:C01A::2 |
Pas grand chose, ouf ! Pour rappel, la loopback est connue grâce à l'ISIS.
LNS1#sh run | s bgp
router bgp 64555
bgp log-neighbor-changes
timers bgp 30 60
neighbor LNS_V4 peer-group
neighbor LNS_V4 remote-as 64555
neighbor LNS_V4 update-source Loopback1
neighbor LNS_V6 peer-group
neighbor LNS_V6 remote-as 64555
neighbor LNS_V6 update-source Loopback1
neighbor 2001:DEAD:C0CA:C01A::2 peer-group LNS_V6
neighbor 100.127.0.2 peer-group LNS_V4
!
address-family ipv4
redistribute connected
neighbor LNS_V4 next-hop-self
neighbor 100.127.0.2 activate
exit-address-family
!
address-family vpnv4
neighbor LNS_V4 send-community both
neighbor 100.127.0.2 activate
exit-address-family
!
address-family ipv6
redistribute connected
neighbor LNS_V6 next-hop-self
neighbor 2001:DEAD:C0CA:C01A::2 activate
exit-address-family
!
address-family vpnv6
neighbor LNS_V6 send-community both
neighbor 2001:DEAD:C0CA:C01A::2 activate
exit-address-family
Je suis parti sur le même principe de créer un peer-group, un pour la session v4 et un autre pour la v6. Dedans, on indique l'AS et l'interface depuis laquelle on souhaite peer.
Les address-family ipvX sont pour le routage global. On renseigne, bien évidement, le next-hop-self car en iBGP, le next-hop ne change pas ! Et le redistribute connected va permettre d'annoncer toutes les routes apprises en connected sur le LNS (ce qui va être utile pour les sessions PPP des clientes, on va ça dans un futur épisode).
Les vpnvX sont pour les échanges de communauté (permettent en autre les L3VPN MPLS). RIP le MPLS IPv6 sur l'IOS-XE !
Toutes les sessions BGP pour chaque famille d'adresse remontent bien.
LNS1#sh bgp all summary
For address family: IPv4 Unicast
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
100.127.0.2 4 64555 41 41 12 0 0 00:10:37 2
For address family: IPv6 Unicast
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2001:DEAD:C0CA:C01A::2
4 64555 7 7 8 0 0 00:00:33 2
For address family: VPNv4 Unicast
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
100.127.0.2 4 64555 41 41 4 0 0 00:10:37 1
For address family: VPNv6 Unicast
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2001:DEAD:C0CA:C01A::2
4 64555 7 7 1 0 0 00:00:33 0
Un petit test, on va créer une loopback sur LNS1 :
LNS1#sh run int lo100
interface Loopback100
ip address 192.168.1.2 255.255.255.255
end
LNS2#sh ip route
100.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 100.64.0.0/29 is directly connected, Port-channel10.10
L 100.64.0.2/32 is directly connected, Port-channel10.10
i L2 100.127.0.1/32 [115/20] via 100.64.0.1, 00:08:19, Port-channel10.10
C 100.127.0.2/32 is directly connected, Loopback1
192.168.1.0/32 is subnetted, 1 subnets
B 192.168.1.2 [200/0] via 100.127.0.1, 00:00:03
LNS2#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 = 8/38/154 ms
Le ping fonctionne et dans la trame wireshark, on voit bien l'entête MPLS :
La configuration d'un L3VPN MPLS ne se fera pas dans cet épisode mais dans un autre un peu plus tard.
Conclusion
Dans cet épisode, on a configuré notre backbone MPLS, on va pouvoir proposer des L3VPN MPLS au client !
Très bonne idée mais actuellement notre backbone n'a pas accès à Internet. Je ne sais pas quel client voudrait bien d'un opérateur comme le nôtre ! De plus, pour les clients qui veulent juste du public+NAT (j'appelle cela comme ça quand le client veut juste un accès internet), notre réseau est tout bonnement inutile.
Bon allez, prochain épisode, mise en place de notre sortie Internet.
Je termine sur un petit mot de fin : Newsong est le meilleur opening de Naruto Shippuden 🥷🥷