6.3. Routing Locator Reachability (Joignabilité du localisateur de routage)

6.3. Routing Locator Reachability (Joignabilité du localisateur de routage)

Plusieurs mécanismes sont actuellement définis pour déterminer la joignabilité des localisateurs de routage (Routing Locators, RLOCs):

1. Un ETR peut examiner les Locator-Status-Bits dans l'en-tête LISP des paquets de données encapsulés provenant d'un ITR. Si l'ETR agit également comme un ITR et qu'il est nécessaire de retourner du trafic vers le site de l'ITR d'origine, il peut utiliser ces informations d'état pour aider à la sélection des RLOCs.

2. Un ITR peut recevoir des messages ICMP Network Unreachable ou Host Unreachable pour les RLOCs qu'il utilise. Cela indiquerait que le RLOC pourrait être défaillant. Notez que faire confiance aux messages ICMP peut ne pas être souhaitable, mais les ignorer complètement n'est pas non plus souhaitable. Les implémentations sont encouragées à suivre les meilleures pratiques actuelles en matière de traitement de ces situations.

3. Un ITR participant au système de routage global peut déterminer qu'un RLOC est défaillant en fonction de l'existence ou non d'une route dans la RIB BGP (Routing Information Base) correspondant à l'adresse IP du RLOC.

4. Un ITR peut recevoir un message ICMP Port Unreachable de l'hôte de destination. Cela se produit lorsque l'ITR tente d'utiliser un mécanisme d'interopérabilité [RFC6832] et que les données encapsulées LISP sont envoyées vers un site qui n'a pas de capacité LISP.

5. Un ITR peut recevoir un Map-Reply d'un ETR en réponse à un Map-Request émis précédemment. L'adresse RLOC source du Map-Reply est très probablement active, car l'ETR a pu envoyer le Map-Reply à l'ITR.

6. Lorsqu'un ETR reçoit un paquet encapsulé d'un ITR, le RLOC source dans l'en-tête externe du paquet est très probablement actif.

7. Une paire ITR/ETR peut utiliser les algorithmes de joignabilité de localisateur décrits dans cette section, à savoir Echo-Noncing ou RLOC-Probing.

Lors de la détermination de la joignabilité up/down du localisateur en examinant les Locator-Status-Bits dans les paquets de données encapsulés LISP, l'ETR recevra l'état le plus récent de la joignabilité de tous les ETRs du site de l'ITR encapsulant. Les ITRs basés sur CE du site source peuvent déterminer mutuellement la joignabilité en utilisant l'IGP du site de la manière suivante:

o En fonctionnement normal, chaque ITR annoncera une route par défaut dans l'IGP du site.

o Si un ITR tombe en panne ou si son lien montant vers le PE tombe en panne, sa route par défaut expirera ou sera retirée.

Ainsi, chaque ITR peut observer si d'autres ITRs annoncent toujours une route par défaut et définir les Locator-Status-Bits pour ceux-ci en conséquence.

Les RLOCs répertoriés dans un Map-Reply sont numérotés avec des ordinaux 0 à n-1. Les Locator-Status-Bits dans un paquet encapsulé LISP sont numérotés de 0 à n-1 à partir du bit de poids le plus faible. Par exemple, si le RLOC en troisième position du Map-Reply tombe en panne (ordinal 2), tous les ITRs du site effaceront le troisième bit le moins significatif (xxxx x0xx) du champ Locator-Status-Bits qu'ils définissent pour les paquets encapsulés.

Lors de la désencapsulation, un ETR examinera le champ Locator-Status-Bits pour tout changement. Lorsqu'un bit passe de 1 à 0, et que l'ETR agit également comme ITR, il cessera d'encapsuler les paquets vers le RLOC marqué comme down. Il ne recommencera à utiliser ce RLOC que lorsque le Locator-Status-Bit correspondant reviendra à 1. Les Locator-Status-Bits sont associés au Locator-Set pour chaque EID-Prefix. Par conséquent, lorsqu'un localisateur devient inaccessible, le Locator-Status-Bit correspondant à la position de ce localisateur dans la liste retournée lors du dernier Map-Reply sera mis à zéro pour cet EID-Prefix.

Lorsque les ITRs dans un site ne sont pas déployés sur les routeurs CE, un IGP peut toujours être utilisé pour déterminer la joignabilité du localisateur à condition que les localisateurs soient injectés dans l'IGP. Cela se fait généralement lors de la configuration d'adresses /32 sur des interfaces de bouclage.

Lorsqu'un ITR utilise les messages ICMP Network Unreachable ou Host Unreachable comme moyen de déterminer l'inaccessibilité, il cessera d'utiliser le localisateur décrit dans la liste de localisateurs du Map-Reply. Cependant, cette méthode n'est pas fiable car de nombreux opérateurs de réseau désactivent la génération de ICMP Destination Unreachable.

Si un ITR reçoit effectivement un message ICMP Network Unreachable ou Host Unreachable, il peut générer lui-même un message ICMP Destination Unreachable pour l'hôte qui a initié le paquet de données encapsulé par l'ITR.

De plus, un ITR activé pour BGP peut vérifier unilatéralement la RIB pour voir si les adresses de localisateur dans le Locator-Set d'une entrée de mappage correspondent à un préfixe. S'il n'en trouve pas et que BGP fonctionne dans la Default-Free Zone (DFZ), il peut décider de ne pas utiliser le localisateur même si les Locator-Status-Bits indiquent que le localisateur est actif. Dans ce cas, il n'y a pas de chemin disponible de l'ITR vers l'ETR auquel le localisateur est attribué. Voir [LOC-ID-ARCH] pour plus de détails.

En option, un ITR peut envoyer un Map-Request à un localisateur, et si un Map-Reply est retourné, il a déterminé que le localisateur est joignable. Évidemment, l'envoi de telles sondes augmente le nombre de messages de contrôle générés par les routeurs tunnel pour le trafic actif, donc l'hypothèse est faite que les localisateurs annoncés sont joignables.

Cette hypothèse crée effectivement une dépendance: l'inaccessibilité du localisateur est détectée en recevant un message ICMP Host Unreachable. Lorsqu'un localisateur est déterminé inaccessible, il ne sera plus utilisé pour le trafic actif, ce qui équivaut à répertorier ce localisateur avec une Priority de 255 dans le Map-Reply.

Un ITR peut tester la joignabilité d'un localisateur inaccessible en envoyant périodiquement des Requests. Les Requests et les Replies doivent tous deux être limités en débit. Les tests de joignabilité du localisateur ne sont jamais effectués avec des paquets de données, car cela augmenterait le risque de perte de paquets dans les sessions de bout en bout.

Lorsqu'un ETR désencapsule un paquet, il sait qu'il est joignable depuis l'ITR encapsulant car le paquet est arrivé via ce chemin. Dans la plupart des cas, l'ETR pourra également atteindre l'ITR, mais cela ne peut pas être supposé car les chemins peuvent être asymétriques. Lorsqu'il existe un flux de trafic unidirectionnel de l'ITR vers l'ETR, l'ITR ne devrait pas utiliser l'absence de trafic de retour comme indication que l'ETR est inaccessible. Au lieu de cela, d'autres mécanismes doivent être utilisés pour déterminer la joignabilité.