Comment aurais-je pu fêter les 7 RFCs sur LISP qui viennent d’être publiés autrement qu’en vous montrant comment cette super technologie peut être utilisée!
Certains se rappellent peut-être que j’avais abordé dans un post l’année dernière la question de la virtualisation du réseau sans avoir à mettre en oeuvre un transport MPLS avec L3VPNoMGRE. Si cela fonctionne parfaitement certains la jugent encore trop compliquée car elle nécessite la mise en oeuvre de BGP, et aussi parce qu’on garde du MPLS au niveau de la couche de service. Ici je vais vous montrer comment virtualiser simplement son réseau avec LISP. Vous allez comprendre pourquoi de plus en plus d’entreprises adoptent cette technologie, elle est vraiment simple à mettre en oeuvre!
Un peu de théorie
Partons du commencement: une adresse IP représente dans l’internet actuel 2 choses, l’identité du host et son emplacement sur le réseau. Cela pose des problèmes évidents quand on parle de mobilité: on ne peut pas simplement garder son adresse IP puisqu’il faut avoir une adresse qui correspond à son sous-réseau. LISP propose un ensemble de mécanismes au niveau du réseau qui vont permettre de découpler les notions d’identifiant (EID) et d’emplacement (ou locator – RLOC). Un système de mapping permet à la fois d’enregistrer les correspondances EID <-> RLOC et de répondre aux requêtes des équipements qui voudraient connaître le/les RLOC (locator) pour un certain EID (identifiant).
Les terminaux connectés au réseau continuent de parler IP, sans prendre en compte LISP. C’est le réseau qui va se charger de tout: enregistrer les mappings, de faire les lookups, et bien sûr LISP-encapsuler vers le bon RLOC. Il y a bien encapsulation au niveau du réseau entre routeurs qui font la démarcation entre le monde LISP (où les adresses IP sont des identifiants) et le monde internet classique (où les adresses IP sont des locators).
Prenons un exemple: A veut parler à B. Tous les 2 sont dans des sites LISP. A va faire un lookup DNS et va récupérer l’adresse IP pour joindre le host B. A va naturellement envoyer un paquet IP classique à l’adresse de destination indiquée par le DNS et celui-ci finira par atteindre le routeur LISP à l’accès du site. Ce dernier va regarder dans son cache LISP local comment joindre B. S’il n’a pas l’information il va demander à un map server LISP cette information et il va la récupérer (puisque le routeur LISP du site côté B aura pris soin d’abord d’enregistrer le mapping idoine). Ce routeur (appelé ITR – Ingress Tunnel Router) va ensuite encapsuler le paquet initial envoyé par A vers le locator correspondant à B. L’encapsulation est spécifique à LISP et nous le verrons plus tard offre de nombreux avantages dont la possibilité de définir des instance-IDs et du coup de permettre la virtualisation (Ca tombe bien c’est le titre de mon post!). Le paquet LISP va ensuite être routé de manière classique entre les sites et va atteindre la destination qui sera le routeur LISP du site de B. Ce routeur qui ici à le rôle d’ETR (Egress Tunnel Router) et va décapsuler le paquet, puis le router naturellement sur le réseau du site jusqu’à B. Quand B répond le même mécanisme se passe, sauf que l’ETR devient l’ITR et vice-versa. La magie est que si pour une raison le site côté B devait finalement être reconnecté par exemple chez un autre opérateur, tout continuerait à marcher. Le PETR côté B annoncerait un nouveau locator pour les mêmes EID et les communications pourraient continuer avec les mêmes adresses IP.
Je m’arrête là: d’un point de vue théorique il y a pleins de choses écrites et beaucoup plus didactiques que mon explication texte (voir références tout en bas de cet article). Si je devais vulgariser je dirais LISP = Mobile IP + DNS + simplicité 🙂
Topologie du lab et matériels/IOS utilisés
Ma topologie est simple, j’ai 3 routeurs qui simuleront des routeurs d’accès de sites LISP (xTR = ETR + ITR). Ce sont mon VSS 6500 en sup2T à gauche, un 892-W en bas et un 2951 à droite. En haut, un routeur 2951 sera dédié à la fonction Map Server / Map resolver. En pratique bien sûr pas besoin de matériel dédié dans la plupart des cas. Au coeur un Catalyst 3560-X agira simplement comme routeur IPv4 (pas de VRF configurées).
J’ai installé sur les ISR G2 une version 15.3(1)T. Au niveau catalyst 6500 une version Beta est en place: LISP sera officiellement supporté fin mars.
Configuration
ISR1 (xTR)
Au niveau ISR1, je définis mes 2 VRF (IPv4 uniquement à ce stade). Pour ne pas multiplier inutilement le nombre d’équipements de la maquette, les tests sont réalisés depuis des interfaces de loopbacks placées dans chaque VRF.
Définition des 2 VRF TENANT-A et TENANT-B:
vrf definition TENANT-A ! address-family ipv4 exit-address-family ! vrf definition TENANT-B ! address-family ipv4 exit-address-family
Configuration des interfaces Loopback11 et Loopback12 qui simuleront les connexions locales vers chaque réseau virtuel.
interface Loopback11 vrf forwarding TENANT-A ip address 10.154.201.1 255.255.255.0 ! interface Loopback12 vrf forwarding TENANT-B ip address 10.154.202.1 255.255.255.0
Et enfin configuration de LISP (configuration des RLOC et des mappings à publier sur le map-server pour chaque VRF). Il suffit d’indiquer que le routeur est ETR et ITR pour IPv4 et d’indiquer où se trouvent le map-server et le map-resolver. Un point très important à noter est que l’on va associer chaque VRF (notion locale) à une instance-id LISP. Ce champ instance-id sera intégré dans le header LISP et permettra de distinguer les différents VPN au niveau transport (équivalent du VLAN pour Ethernet)
router lisp locator-set SITE-1 10.154.102.2 priority 1 weight 50 10.154.103.2 priority 1 weight 50 exit ! eid-table default instance-id 0 exit ! eid-table vrf TENANT-A instance-id 201 database-mapping 10.154.201.0/24 locator-set SITE-1 exit ! eid-table vrf TENANT-B instance-id 202 database-mapping 10.154.202.0/24 locator-set SITE-1 exit ! ipv4 itr map-resolver 10.154.101.2 ipv4 itr ipv4 etr map-server 10.154.101.2 key CISCOKEY ipv4 etr exit
ISR3 (xTR)
Configuration similaire à ISR1, notez que les préfixes respectivement associés aux VRF TENANT-A et TENANT-B 10.14.211.0/24 et 10.154.212.0/24 sur les interfaces loopback11 et loopback12.
router lisp locator-set SITE-2 10.154.104.2 priority 0 weight 100 exit ! eid-table default instance-id 0 exit ! eid-table vrf TENANT-A instance-id 201 database-mapping 10.154.211.0/24 locator-set SITE-2 exit ! eid-table vrf TENANT-B instance-id 202 database-mapping 10.154.212.0/24 locator-set SITE-2 exit ! ipv4 itr map-resolver 10.154.101.2 ipv4 itr ipv4 etr map-server 10.154.101.2 key CISCOKEY ipv4 etr exit
ISR2 (MS/MR)
Là ça change un peu puisque ISR2 ne connecte pas de site, il a juste la fonction de map-server et de map-resolver (on parle de MS/MR). Il va juste accepter les enregistrements des préfixes 10.154.0.0/16 (ainsi que les plus spécifiques). Vous noterez qu’une clé est partagée (CISCOKEY) entre ETR et map-server pour s’assurer que l’information est bien publiée par les routeurs autorisés. Vous noterez aussi qu’il est possible de définir sur le MS/MR une notion de site. Les préfixes qui vont être enregistrés par les ETR vont être associés à un site ce qui peut simplifier le troubleshooting. Ici j’ai fait simple: un seul site est défini et tous mes préfixes y sont enregistrés!
router lisp site RESEAU-1 authentication-key CISCOKEY eid-prefix instance-id 201 10.154.0.0/16 accept-more-specifics eid-prefix instance-id 202 10.154.0.0/16 accept-more-specifics exit ! ipv4 map-server ipv4 map-resolver ipv6 map-server ipv6 map-resolver exit
Tests simples et résultats
Au niveau du MS/MR
Commençons par regarder sur le MS/MR les enregistrements faits par les différents ETR
ISR2#sh lisp site
LISP Site Registration Information
Site Name Last Up Who Last Inst EID Prefix
Register Registered ID
RESEAU-1 never no -- 201 10.154.0.0/16
00:00:23 yes 10.154.103.2 201 10.154.201.0/24
00:00:58 yes 10.154.104.2 201 10.154.211.0/24
00:00:43 yes 10.154.105.2 201 10.154.221.0/24
never no -- 202 10.154.0.0/16
00:00:05 yes 10.154.103.2 202 10.154.202.0/24
00:00:01 yes 10.154.104.2 202 10.154.212.0/24
00:00:17 yes 10.154.105.2 202 10.154.222.0/24
On voit tous les préfixes configurés sur les sites LISP (EID - indentifiants) y compris ceux configurés sur mon cat6k (10.154.221.0/24 et 10.154.222.0/24). On peut aussi lire l'instance-id (201 ou 202). Le MS/MR n'a aucune idée de quelle VRF est associée à chaque instance-id, celle-ci n'est importante qu'au sein de l'xTR. Ici tous les préfixes sont associés au site RESEAU-1 car c'est ainsi que l'on a défini notre configuration (tous les préfixes compris dans 10.154.0.0/16 avec les instance-id 201 et 202 sont associés à RESEAU-1)
On peut avoir plus de détails pour chaque préfixe, notamment les RLOC correspondant aux EIDs inscrits dans le map-server.
ISR2#sh lisp instance-id 201 site 10.154.201.0/24 LISP Site Registration Information Site name: RESEAU-1 Allowed configured locators: any Requested EID-prefix: EID-prefix: 10.154.201.0/24 instance-id 201 First registered: 01:40:08 Routing table tag: 0 Origin: Dynamic, more specific of 10.154.0.0/16 Merge active: No Proxy reply: No TTL: 1d00h State: complete Registration errors: Authentication failures: 0 Allowed locators mismatch: 0 ETR 10.154.103.2, last registered 00:00:35, no proxy-reply, no map-notify TTL 1d00h, no merge, nonce 0xA4279353-0x709DCE16 state complete, no security-capability xTR-ID 0x00022385-0x434CBB15-0xCD7B8BB2-0x4A20B0E5 site-ID unspecified Locator Local State Pri/Wgt 10.154.102.2 yes up 1/50 10.154.103.2 yes up 1/50
On voit clairement les 2 locators pour le préfixe 10.154.201.0/24 avec l’instance-id 201, qui correspondent bien aux adresses configurées sur ISR1 (adresses en sortie du réseau, joignables par les autres équipements)
Au niveau d’un ITR
Regardons tout d’abord sur ISR1 la table locale de mapping EID->RLOC pour l’instance-id 201.
ISR1#sh ip lisp instance-id 201 map-cache LISP IPv4 Mapping Cache for EID-table vrf TENANT-A (IID 201), 1 entries 0.0.0.0/0, uptime: 1w0d, expires: never, via static send map-request Negative cache entry, action: send-map-request
On voit que le cache est vide: pour chaque adresse de destination le routeur devra demander au map-resolver pour trouver la correspondance.
Je simule maintenant la communication d’un client connecté sur ISR1 (VRF TENANT-A) vers un autre client connecté derrière ISR3 (VRF TENANT-A également). Pour cela je fais un ping simple entre les loopbacks des routeurs.
ISR1#ping vrf TENANT-A 10.154.211.1 source 10.154.201.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.154.211.1, timeout is 2 seconds: Packet sent with a source address of 10.154.201.1 ..!!! Success rate is 60 percent (3/5), round-trip min/avg/max = 1/1/1 ms
On peut observer que les premiers paquets sont perdus. En effet l’ITR n’ayant pas d’information dans son cache à ce moment là a besoin d’un petit moment pour récupérer le locator correspondant.
ISR1#sh ip lisp instance-id 201 map-cache LISP IPv4 Mapping Cache for EID-table vrf TENANT-A (IID 201), 2 entries 0.0.0.0/0, uptime: 1w0d, expires: never, via static send map-request Negative cache entry, action: send-map-request 10.154.211.0/24, uptime: 00:00:06, expires: 23:59:54, via map-reply, complete Locator Uptime State Pri/Wgt 10.154.104.2 00:00:06 up 1/100
A la fin du process le cache local a été mis à jour. On voit donc bien une différence majeure entre LISP, qui fonctionne en mode PULL, par rapport à du routage traditionnel qui fonctionne en mode PUSH. Chaque routeur ne récupère les routes que des sites qu’il souhaite joindre. Cette caractéristique est essentielle et permettra de scaler pour les évolutions prochaines de l’Internet (vous avez peut-être entendu parler de Internet of Everything?)
On peut vérifier qu’il y a étanchéité entre les VPN (je tente un ping entre 2 adresses sur des VRF distinctes sur ISR1 et ISR3, et associées à des instance-id différentes)
ISR1#ping vrf TENANT-A 10.154.212.1 source 10.154.201.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.154.212.1, timeout is 2 seconds: Packet sent with a source address of 10.154.201.1 ..... Success rate is 0 percent (0/5)
On a bien segmentation car aucune réponse ne revient. On peut maintenant regarder le cache à l’issue de ce nouveau ping:
ISR1#sh ip lisp instance-id 201 map-cache LISP IPv4 Mapping Cache for EID-table vrf TENANT-A (IID 201), 3 entries 0.0.0.0/0, uptime: 1w0d, expires: never, via static send map-request Negative cache entry, action: send-map-request 10.154.211.0/24, uptime: 00:08:39, expires: 23:51:21, via map-reply, complete Locator Uptime State Pri/Wgt 10.154.104.2 00:08:39 up 1/100 10.154.212.0/22, uptime: 00:00:13, expires: 00:00:46, via map-reply, forward-native Negative cache entry, action: forward-native
On voit que la situation est un peu plus complexe qu’elle n’y paraît. Le map-server qui n’a pas d’entrée pour le couple adresse/instance-id en question, a répondu de transférer les paquets nativement (c’est-à-dire que l’adresse de destination n’est pas un site LISP). On notera que le préfixe 10.154.212.0/22 qui est le plus grand préfixe comprenant l’adresse de destination (10.154.212.1) et qui ne comprend aucun préfixe enregistré. Comme le réseau n’a pas de route vers 10.154.212.0/22 alors les paquets sont droppés.
Conclusion
Je préfère m’arrêter là pour ce premier post sur LISP sur la virtualisation d’un réseau. Que retenir?
- La configuration est extrêmement simple (quelques lignes pour virtualiser toute une infrastructure)
- Le troubleshooting est également simplifié car on se base sur un transport IP dans le coeur
- Comme on n’a pas besoin de MPLS des équipements plus légers comme des 860, 870 ou 880 peuvent suffir
- On a bâti une infra de base qui permettra après en un clin d’oeil d’activer d’autres services. Par exemple je montrerai dans un prochain post comment déployer IPv6 simplement sur l’infrastructure montrée ici.
- Chaque site décide simplement de la priorité et du poids de chaque accès (RLOC). Il est donc très simple de faire du Traffic Engineering en indiquant des ratios entre RLOCs (par exemple 30/70).
Bref, en quelques minutes j’ai créé un réseau multi-services sans MPLS, sans BGP et capable de fonctions avancées. Notez qu’ici je n’ai pas chiffré les échanges entre les sites. Cela aurait très simplement pu être fait via la technologie GETVPN que nous utilisons déjà pour le chiffrement (sans tunnel). Je montrerai la aussi ultérieurement comment configurer tout cela.
Références
- Ciscolive365 : nombreuses présentations des différents CiscoLive avec techtorials précis
- lisp4.net : site LISP officiel
- IETF LISP working group : standardisation
- lisp.cisco.com : site Cisco dédié à LISP (et accessible via LISP!) avec publication des nouveautés
Authors
4 commentaires
Post très intéressant. Merci.
Je reste un peu dubitatif par contre au sujet des remarques concernant la complexité (toute relative pour une entreprise) dans l’usage de BGP et de MPLS qui vous ont été adressé. J’y vois une contradiction vis à vis de LISP dans la mesure où les protocoles précités ont été introduit pour l’un depuis plus de 10 ans et quand à l’autre on peut déjà dire qu’il est centenaire 🙂 Il sont largement plus documenté que le LISP qui quant à lui à pour le moment le défaut de la jeunesse.
Je viens d’un monde très MPLS donc j’ai également regardé LISP tout d’abord avec un regard dubitatif. Mais dans un contexte entreprise, avec des équipes qui souvent ne gèrent ni BGP, ni MPLS, il faut admettre que LISP est plus adapté car plus simple. Un exemple de cette simplicité est que l’on va reposer sur un backbone purement IP, là où MPLS aurait nécessité d’intervenir sur tous les équipements du coeur de réseau! Attention je ne suis pas du tout en train de dire que MPLS doit être mis à la poubelle 🙂 Il existe juste une alternative avec LISP qui pourra être plus adaptée dans certains cas. Qu’on se le dise!
Merci Jérôme pour ce post.
A mon avis, LISP pourra être utilisé sur un réseau d’entreprise quand les développeurs se seront penchés sur la connectivité LISP/non LISP.
Pour le moment, c’est sympa en lab quand tout est en LISP, mais si on souhaite avoir une passerelle entre le monde LISP et le monde non LISP (soit pour le temps de la migration, soit par choix de ne pas tout migrer), on commence déjà à être embêté, quant à avoir deux passerelles redondantes, il y a de nombreux cas où ce n’est pas possible (en particulier quand le routeur LISP passerelle ne peut pas détecter la panne du lien non-LISP).
Bonjour Philippe. Sur ta première remarque je ne suis pas complètement d’accord. On commence à avoir des développements en entreprise et séduire plus d’un client! Tu n’as qu’a voir les clients qui ont témoigné lors des derniers Cisco Live pour constater qu’on est sortis des labs (même si j’admets que certains d’entre eux n’ont pas encore mis en production).
Pour ce qui est de la connectivité LISP/non LISP, je te rejoins sur le fait qu’elle peut être améliorée même si elle permet déjà aujourd’hui de répondre à certaines problématiques. Des solutions sont envisagées (protocole de routage entre xTR et PxTR par exemple). Mais note que le côté stateless de LISP permet d’aller vers des solutions anycast aussi on n’est pas complètement démunis. On a même un opérateur virtuel qui a choisi cette solution pour connecter ses clients (qui obtiennent leur connexion physique via des connexions standard chez des opérateurs classiques). On a une offre de multihoming simple sans avoir à gérer demande d’ASN ou préfixe PI.
Donc oui des améliorations vont voir le jour mais ce n’est pas bloquant pour tous les déploiements, loin de là je pense.
A bientot!