Ce RFC concerne les utilisateurs de
LISP (le protocole réseau, pas le langage
de programmation). Il décrit un nouvel outil, rig, le
Referral Internet Groper, qui permet
d'interroger les tables de correspondance
identificateur->localisateur.
Un point important de LISP (RFC 6830) est en effet
cette séparation de l'EID (l'identificateur d'une machine) et du
RLOC (le localisateur de cette machine, qui indique où envoyer les
paquets). Tout système ayant cette
séparation doit maintenir une
correspondance (mapping)
entre les deux : lorsque je veux écrire à telle machine dont je
connais l'EID, il faut que je trouve le localisateur. LISP permet
plusieurs mécanismes pour cette correspondance. L'outil rig,
présenté dans ce RFC, est conçu pour le mécanisme DDT (RFC 8111), une base de données arborescente et répartie. rig est donc un client DDT de déboguage, lig (RFC 6835) étant un autre outil, plus général (il
peut interroger d'autres bases que DDT).
Un client DDT comme rig (ou comme un routeur LISP lors de son
fonctionnement normal) va donc
envoyer des Map-Request (RFC 6830, section 6.1, et aussi RFC 6833) aux serveurs DDT.
La section 4 de notre RFC résume le fonctionnement de rig. Il
envoie le Map-Request et affiche le
Map-Referral de réponse. Il peut ensuite suivre
cette référence jusqu'à arriver au Map Server
qui gère ce préfixe. (Notez que c'est le RLOC du Map
Server qu'on obtient, sinon, on aurait un intéressant
problème d'œuf et de poule si on avait
besoin de DDT pour utiliser DDT...)
rig a donc besoin d'au moins deux paramètres, l'EID
(l'identificateur) qu'on cherche à résoudre, et le serveur DDT par
lequel on va commencer la recherche. (Pour l'EID, rig accepte
également un nom de domaine, qu'il va
traduire en EID dans le DNS.) La syntaxe
typique est donc :
rig to
La section 5 décrit les mises en œuvres existantes, sur les
routeurs Cisco. La syntaxe est un peu
différente de ce que je trouve dans
la doc' de Cisco mais, bon, tout ceci est expérimental et
en pleine évolution. Voici un exemple tiré de la documentation
officielle de Cisco (LISP DDT Configuration Commands) :
Device# lisp-rig 172.16.17.17 to 10.1.1.1
rig LISP-DDT hierarchy for EID [0] 172.16.17.17
Send Map-Request to DDT-node 10.1.1.1 ... replied, rtt: 0.007072 secs
EID-prefix [0] 172.16.17.16/28, ttl: 1, action: ms-not-registered, referrals:
10.1.1.1, priority/weight: 0/0
10.2.1.1, priority/weight: 0/0
10.3.1.1, priority/weight: 0/0
Et voilà, on sait que l'EID
172.16.17.17, il faut aller demander aux
serveurs
10.1.1.1,
10.2.1.1 et
10.3.1.1. Dans le RFC, on trouve un exemple
où rig suit ces références :
Router# rig 12.0.1.1 to 1.1.1.1
Send Map-Request to DDT-node 1.1.1.1 ... node referral, rtt: 4 ms
EID-prefix: [0] 12.0.0.0/16, ttl: 1440
referrals: 2.2.2.2
Send Map-Request to DDT-node 2.2.2.2 ... node referral, rtt: 0 ms
EID-prefix: [0] 12.0.1.0/24, ttl: 1440
referrals: 4.4.4.4, 5.5.5.5
Send Map-Request to DDT-node 4.4.4.4 ... map-server acknowledgement,
rtt: 0 ms
EID-prefix: [0] 12.0.1.0/28, ttl: 1440
referrals: 4.4.4.4, 5.5.5.5
Si vous voulez en savoir plus sur DDT et rig, vous pouvez aussi
regarder l'exposé
de Cisco ou celui de Paul
Vinciguerra à NANOG, ou bien la page officielle de la racine DDT
(qui semble peu maintenue).
