IGP Backbone

đź’ˇ
Toutes les configurations sont commit sur mon github : https://github.com/Nathan0510/Blog

IGP, c'est quoi ?

La fabric est maintenant opérationnelle, place à notre backbone MPLS.

J'ai eu la chance d'avoir un très bon prof à mon IUT et il nous a donné une bible (que j'ai gardé !) qui explique ce que c'est, le vocabulaire adapté et tout ce qui se rapproche d'un backbone opérateur.

Pour rappel, dans notre fabric VXLAN, on a configuré un underlay et un overlay (data/control plane). Le premier permet la connectivité IP entre Leaf/Spine et le second la circulation des informations VXLAN.

Et bah, faut se dire que c'est la mĂŞme chose pour un backbone MPLS. On va utiliser un IGP (Interior Gateway Protocol) qui va permettre de diffuser les routes interne et les IPs des loopbacks des routeurs.

Ensuite le MPLS et BGP se rajoute par dessus.

On peut dire que l'IGP va ĂŞtre l'underlay et le MPLS l'overlay.

Mais pourquoi j'ai encore besoin de connaître des Loopbacks ? Et bah pour établir les sessions BGP. L'utilisation d'un IGP ne suffit pas, par exemple, comment je ferai un L3VPN MPLS ? Comme vu dans l'épisode overlay, ce qui permet la configuration est une extension BGP (AFI 1 / SAFI 128) qui dépend de MPLS pour l'attribution de label.

Et qu'est ce qu'on va utiliser comme IGP ? On a encore le choix : OSPF, IS-IS et RIP.

Bien évidement, j'ai mis RIP pour respect pour ce protocole mais il est naze. J'ai décidé de partir sur de l'IS-IS. C'est un protocole de routage à état de lien et utilise l'algorithme de Dijkstra comme l'OSPF mais il permet de router n'importe quel niveau 3 ! Pas besoin d'avoir une instance OSPF pour l'IPv4 et une autre pour l'IPv6. IS-IS va se baser sur CLNS (Connection-Less Network Service) qui est implémenté par CNLP (Connection-Less Network Protocol) et non sur IP ! Allez un petit tableau comparatif :

OSPF IS-IS
Algo Dijkstra Dijkstra
Basé sur IP CLNP
AD 110 115
OSI 3 2,5
Metrique Interface En fonction de la bande passante 10
Nombre d'aire 6 2
Noms des échanges LSD TLV

Grosse introduction.... J'espère ne pas vous avoir tous perdu. J'ai décidé de séparer l'épisode Backbone en 3 parties ! Dans celui ci on va voir la mise en place de l'IGP IS-IS mais d'abord place au interco Routeur / Fabric.


Configuration fabric

On va terminer notre configuration du MLAG maintenant ! Pour rappel, notre architecture est celle ci :

J'ai du changer les IOS des Cisco. En effet, sur les vIOS, ce n'est possible de faire du EtherChannel L3.... Super ! Je suis donc parti sur des CSR1000V (équivalent au ASR 1000). Pitié, pensez à choisir la NIC vmxnet3 et non la tpl(e1000) ou la virtio-net-pci. Pour la première, elle n'est pas compatible donc il n'y a pas d'interfaces sur le routeur et la seconde.....misère ! Le routeur ne répond pas aux ARP request sur une sous-interface dot1q.........5H de perdu un samedi soir !

Allez, configurons les interfaces côté Leaf1 et 2 :

Leaf1-B1#sh run int eth6
interface Ethernet6
   description OUT_LNS1
   switchport trunk allowed vlan 10
   switchport mode trunk
   channel-group 10 mode active
  
Leaf1-B1#sh run int po10
interface Port-Channel10
   description PO_OUT_LNS1
   switchport trunk allowed vlan 10
   switchport mode trunk
   mlag 10

Il est lĂ  le fameux mlag 10. Configurons le port-channel sur le routeur. Ensuite, on pousse la mĂŞme configuration sur leaf2.

LNS1#sh run int gi8
interface GigabitEthernet8
 description OUT_LEAF1
 mtu 2000
 no ip address
 negotiation auto
 channel-group 10 mode active
end

LNS1#sh run int gi9
interface GigabitEthernet9
 description OUT_LEAF2
 mtu 2000
 no ip address
 negotiation auto
 channel-group 10 mode active
end

LNS1#sh run int po10
interface Port-channel10
 description PO_OUT_LEAF_B1
 mtu 2000
 no ip address
 no negotiation auto
end

Le no negociation auto est configuré sur le routeur pour que le leaf et le routeur savent sur quel speed et duplex s'accorder. La MTU est configurée à 2000 (voir épisode sur la MTU).

LNS1#sh int des
Po10                           up             up       PO_OUT_LEAF_B1

Le port-channel monte bien entre les 3 équipements. Top ! Maintenant, regardons l'état du MLAG sur leaf1 :

Leaf1-B1#sh mlag interfaces 10
                                                                   local/remote
  mlag      desc                   state      local      remote          status
--------- ---------------- ---------------- ---------- ----------- ------------
    10      PO_OUT_LNS1      active-full       Po10        Po10           up/up

Le MLAG monte bien ! Maintenant, si un des deux leaf venait à rendre l'âme alors le trafic passera par l'autre leaf ! Attention, il faut penser à ce que le trafic ne dépasse pas la moitié de la bande passante disponible sur le port-channel !

Si un leaf tombe alors on divise par deux la BP dispo !

Bon et maintenant, le truc chiant. Mapper le VLAN sur une VNI sur tous les leaf portant le vlan 10 :

Leaf1-B1#sh run int vxlan1
interface Vxlan1
   vxlan vlan 10 vni 100010

Leaf1-B1#sh run | s bgp
router bgp 65001
   vlan 10
      rd 65001:100010
      route-target both 10:100010
      redistribute learned

Allez, on fait la même chose sur l'autre couple de leaf et un petit test pour vérifier que c'est bon :

LNS1#sh run int po10.10
interface Port-channel10.10
 description L2-LNS-ISIS
 encapsulation dot1Q 10
 ip address 100.64.0.1 255.255.255.248

LNS2#sh run int po10.10
interface Port-channel10.10
 description L2-LNS-ISIS
 encapsulation dot1Q 10
 ip address 100.64.0.2 255.255.255.248

LNS1#ping 100.64.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.64.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/19/51 ms

Pensons déjà automatisation ! Qu'est ce qu'on a fait pour que ça fonctionne ?

  1. Création de l'interco port-channel entre leaf et routeur => Plus besoin d'y penser
  2. Création du vlan sur leaf et l'autoriser à circuler sur le Po
  3. Mapper le vlan sur une vni et configuration du BGP
  4. IP sur l'interco entre les routeurs MPLS

Honnêtement, un script ansible serait pas très compliqué à mettre en place.

Bon c'est pas le sujet mais c'est toujours intéressant d'imaginer dès le début de la mise en place à comment automatiser et pas une fois que tout est fini. Avoir cette méthode de réflexion permet d'anticiper les complexités et de penser simple au début !


L'IGP ISIS

Les intercos configurées, place à l'SIS. On a besoin de quoi ?

  1. Une interco IPv4 et v6 entre les deux routeurs
  2. Une loopback IPv4 et v6 sur les deux routeurs

Pas grand chose nan ?

Routeurs Interco v4 Interco v6 Loopback v4 Loopback v6
LNS1 100.64.0.1/29 2001:dead:cafe:babe::1/125 100.127.0.1 2001:dead:c0ca:c01a::1
LNS2 100.64.0.2/29 2001:dead:cafe:babe::2/125 100.127.0.2 2001:dead:c0ca:c01a::2

Les IPs 100.64.0.0/10 sont définis dans la RFC 6598. C'est une nouvelle plage d'IP privée réservée pour les opérateurs. Elle n'est pas annoncée sur Internet donc tout le monde peut s'en servir (équivalent aux IPs privées définies par la RFC 1918, on les connait tous celles ci).

Pourquoi un /29 et un /125 ? Un magicien ne révèle jamais tous ses secrets (voir en fin de l'épisode, on pense à l'avenir !).

Allez configurons tout ça :

LNS1#sh run int po10.10
interface Port-channel10.10
 description L2-LNS-ISIS
 encapsulation dot1Q 10
 ip address 100.64.0.1 255.255.255.248
 ipv6 address 2001:DEAD:CAFE:BABE::1/125
 ipv6 enable
end

LNS1#sh run int lo1
interface Loopback1
 description LO_MPLS
 ip address 100.127.0.1 255.255.255.255
 ipv6 address 2001:DEAD:C0CA:C01A::1/128
end

LNS1#ping 2001:DEAD:CAFE:BABE::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DEAD:CAFE:BABE::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 7/10/18 ms

LNS1#ping 2001:DEAD:C0CA:C01A::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DEAD:C0CA:C01A::2, timeout is 2 seconds:

% No valid route for destination
Success rate is 0 percent (0/1)

Le ping entre les loopbacks ne fonctionne pas et c'est normal ! Il est là l'utilité de l'IGP. Pour connaître ces foutues IP des loopbacks pour permettre l'établissement des sessions iBGP (qui sont montés entre deux loopbacks).

Pour l'ISIS, ca se passe ici :

LNS1#sh run | s isis
router isis
 net 49.0001.1001.2700.1000.00
 metric-style narrow
 log-adjacency-changes

LNS1#sh run int po10.10
interface Port-channel10.10
 description L2-LNS-ISIS
 encapsulation dot1Q 10
 ip address 100.64.0.1 255.255.255.248
 ip router isis
 ipv6 address 2001:DEAD:CAFE:BABE::1/125
 ipv6 enable

LNS1#sh run int lo1
interface Loopback1
 description LO_MPLS
 ip address 100.127.0.1 255.255.255.255
 ip router isis
 ipv6 address 2001:DEAD:C0CA:C01A::1/128

L'élément le plus important est le net. Ici c'est 49.0001.1001.2700.1000.00.
LNS1 implĂ©mente l’adresse NET 49.0001.1001.2700.1000.00 (Aire 49.0001, identifiant de routeur 1001.2700.1000). On ne peut pas change l'aire par contre l'identifiant doit ĂŞtre diffĂ©rent pour chaque routeur.

Aussi, l'ISIS va envoyer des trames avec du "rembourrage" jusqu'à la MTU. En gros, si j'ai une interco avec 9214 octet de MTU, alors l'ISIS va envoyer des paquets avec 9214 octets. Si 1500 MTU, alors 1500 octets. Ce principe permet d'éviter les missmatch MTU entre les deux routeurs !

Pour info, on peut supprimer ça avec un no isis hello-padding dans la configuration de l'ISIS. Avec cette commande, l'ISIS va envoyer des paquets avec 67 octets.

Bon allez, on affiche les voisins ISIS sur LNS1 :

LNS1#sh isis neighbors
System Id       Type Interface     IP Address      State Holdtime Circuit Id
LNS2            L1   Po10.10       100.64.0.2      UP    23       LNS1.01
LNS2            L2   Po10.10       100.64.0.2      UP    23       LNS1.01

Nickel, nos deux routeurs se voient bien en ISIS. Par contre, c'est quoi cette histoire de L1 et L2. C'est quoi l'intérêt dans notre cas d'avoir plusieurs zones vu la taille de notre backbone ?

Aucun ! C'est pour ça qu'on va préciser dans le process ISIS que ça va être uniquement un level 2 :

LNS1#sh run | s isis
router isis
 net 49.0001.1001.2700.1000.00
 is-type level-2-only
 metric-style narrow
 log-adjacency-changes

LNS1#sh isis neighbors

System Id       Type Interface     IP Address      State Holdtime Circuit Id
LNS2            L2   Po10.10       100.64.0.2      UP    25       LNS1.01

Maintenant, il n'y qu'un seul couple de voisins ISIS, celui en type L2.

Mais chef ! Tu nous bassines avec l'IPv6 mais tu l'as oublié nan ?

Effectivement ! Bon allons configurer tout ça (et c'est pas bien compliqué !) :

LNS1#sh run int lo1
interface Loopback1
 description LO_MPLS
 ip address 100.127.0.1 255.255.255.255
 ip router isis
 ipv6 address 2001:DEAD:C0CA:C01A::1/128
 ipv6 router isis
end

LNS1#sh run int po10.10
interface Port-channel10.10
 description L2-LNS-ISIS
 encapsulation dot1Q 10
 ip address 100.64.0.1 255.255.255.248
 ip router isis
 ipv6 address 2001:DEAD:CAFE:BABE::1/125
 ipv6 enable
 ipv6 router isis
end

Il suffit d'ajouter ipv6 router isis. Pas besoin de recréer un process ISIS pour l'IPv6 comme on l'aurait fait pour l'OSPF avec du v3.

Bon alors, ca fonctionne ou pas ?

LNS1#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.1/32 is directly connected, Port-channel10.10
C        100.127.0.1/32 is directly connected, Loopback1
i L2     100.127.0.2/32 [115/20] via 100.64.0.2, 00:06:25, Port-channel10.10

LNS1#ping 100.127.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.127.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 13/14/15 ms


LNS1#sh ipv6 route
LC  2001:DEAD:C0CA:C01A::1/128 [0/0]
     via Loopback1, receive
I2  2001:DEAD:C0CA:C01A::2/128 [115/20]
     via FE80::21E:7AFF:FE79:21C9, Port-channel10.10
C   2001:DEAD:CAFE:BABE::/125 [0/0]
     via Port-channel10.10, directly connected
L   2001:DEAD:CAFE:BABE::1/128 [0/0]
     via Port-channel10.10, receive
L   FF00::/8 [0/0]
     via Null0, receive

LNS1#ping 2001:DEAD:C0CA:C01A::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DEAD:C0CA:C01A::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/15/18 ms

A partir de LNS1, on arrive Ă  ping la loopback de LNS2 en IPv4 et IPv6 !

Tout ça pour seulement une pauvre IP apprise en ISIS ? Euh.... je suis désolé mais oui.

Pour ma défense, c'est juste que notre backbone est petit. Admettons, on a encore un autre couple de LNS mais dans un datacenter différent car on s'est agrandit.

On pourrait configurer 2 nouvelles intercos sur LNS1 (et LNS2) et donc encore des VLANs à diffuser… Sauf qu'on est un peu plus fainéant, on va juste diffuser le VLAN 10 sur les nouveaux LNS et mettre l'interface dans le process ISIS. Le /29 et /125 (6 IPs disponible) a été choisi pour ça (plutôt malin nan ?).

Bon OK pour l'IPv6, le /125 permet d'avoir 8 IPv6 disponible vu qu'il n'y a plus de notion d'adresse de réseau et broadcast.

On apprendra donc les loopbacks des autre LNS grâce à l'ISIS.


Echange ISIS wireshark

Le premier, le hello :

On voit que LNS1 envoie un hello sur son interco tag dot1q 10 et il rembourre la trame pour atteindre le maximum octets et ainsi éviter les missmatch MTU entre les 2 routeurs.

Le second : un LSP

Il sert à vérifier la connectivité des deux neighbors.
Mais où sont les loopbacks annoncées ?

HĂ© bah dans un autre LSP :

On voit que LNS1 annonce sa Loopback IPv4 et IPv6 tout en précisant via quel préfix son neighbor pourra la joindre. En l'occurrence, son interco avec LNS2.
LNS2 fait le même échange pour annoncer ses Loopbacks :

C'est aussi dans ces échanges que la métrique pour joindre les IPs est annoncée ! Par exemple, LNS2 annonce 100.127.0.2 avec une métrique de 10 :

Admettons, on set manuellement la métrique de l'ISIS sur LNS2 :

LNS2(config-subif)#isis metric 1000
Warning: for metrics greater than 63, 'metric-style wide'  should be configured on level-1-2, or it will be capped at 63.
LNS2(config-subif)#isis metric 50

Pourquoi on peut pas mettre au dela de 63 ? Car de base, dans la trame ISIS, 6 bits sont réservés pour le champ métrique. Il faut appliquer la commande metric-style wide pour dépasser cette limite.

Retournons dans wireshark et observons l'échange ISIS LSP :

Top ! On voit bien que la nouvelle métrique a été annoncée. Cela peut servir à dévier le trafic IGP au sein d'un backbone pour pouvoir faire une intervention sur un routeur sans déranger le trafic (MAJ, ajout interfaces, BGP, etc).


Récap et suite

A partir de maintenant, je vais plutôt faire des épisodes comme celui, avec qu'une seule tâche (ou deux mais petites) à faire ! Mais toujours avec une analyse de trame pour tout comprendre. L'épisode sur l'underlay était beaucoup trop long.

La diffusion des loopbacks étant OK, dans le prochain épisode, place à la configuration du BGP et du MPLS entre les LNS.

Je termine sur un petit mot de fin : Itachi est pas dans le top 15 puissance du verse 🥷🥷