À propos d'Option C Inter-AS VPN et RR hors bande

Bonjour à tous.

Je fais face à un problème lors de la configuration d’Option-C Inter-AS L3VPN. Voici le problème : le RR n’est pas directement connecté à l’ASBR (il y a des routeurs entre les deux) et le RR ne participe pas à LDP/RSVP/SR : il n’y a pas de LSP entre le RR et les PEs/ASBR.

En raison de cela, la route vers le RR dans l’autre ASN est dans la table inet.0 et il y a une étiquette pour y accéder (l’étiquette BGP-LU envoyée par l’ASBR), mais le problème est que cette étiquette a été générée par l’ASBR et non par le routeur connecté directement au RR. En résumé, la boucle de l’interface loopback de l’autre ASN n’est pas accessible dans la couche de données.

Existe-t-il une solution pour régler ce problème sans mettre en place une LSP du RR à l’ASBR ?

J’attends avec impatience le guidage des membres du groupe. Merci.

La topologie ressemble à ceci

option C (blog networkfuntimes)

Avez-vous un schéma ou un diagramme à fournir ? Cela faciliterait la compréhension de votre configuration.

Avez-vous une politique configurée pour exporter la boucle de retour ? De plus, les RR auront besoin de résolutions si hors chemin de données.

Regardez ceci

J’ai modifié le post pour ajouter un lien vers le diagramme de topologie.

Les résolutions sont déjà configurées. Les boucles de retour sont échangées (car j’ai configuré la politique d’exportation pour redistribuer l’adresse de la boucle de retour).
Le problème est que la route vers la boucle de retour du RR dans l’autre AS n’affiche qu’une seule étiquette, et cette étiquette n’est pas reconnue par les routeurs P comme ayant été générée par l’ASBR local.

Il semble y avoir plusieurs façons de résoudre ce problème, mais cet article finit par mettre en place des LSP entre le RR et l’ASBR/PE.
Je sais qu’une LSP résoudrait ce problème. Je suis curieux de connaître ces « plusieurs solutions » et je n’en vois pas d’autre.

Utilisez-vous LDP ou RSVP ?

Le trafic transitera-t-il par le RR ? Si oui, alors vous pouvez créer une passerelle statique par défaut dans la table inet.3 sur le RR. Cela satisfera la récursion L3VPN vers inet.3 et permettra au RR d’annoncer les routes, sans avoir besoin de LSP vers PEs.

LDP est utilisé dans une ASN et RSVP dans l’autre, mais cela ne devrait pas influencer le résultat.

L’annonce des routes par le RR aux PE n’est pas le problème. Le RR possède une route vers l’autre RE dans inet.0 et pourtant il ne forme pas un peering BGP avec le RR dans l’autre ASN.

Je relis ton post initial et je comprends mieux le problème maintenant. Non, tu ne peux pas faire du unicast étiqueté multi-hop. Comme tu l’as découvert, les routeurs entre ne reconnaîtront pas l’étiquette. Tu dois donc soit établir une connexion tunnel entre les émetteurs BGP-LU, soit faire participer les routeurs intermédiaires à la distribution des étiquettes.

Oui, je suppose que ce sont les seules solutions possibles. Merci.