Résumé

  • Les rôles BGP permettent à deux réseaux voisins de comparer leurs attentes — fournisseur, client, pair ou serveur de routes — avant d’échanger des annonces ; une incompatibilité confirmée peut empêcher la session eBGP.
  • OTC transporte une limite de propagation avec la route, mais n’authentifie ni le contrat commercial ni les exceptions par préfixe et ne remplace pas les politiques explicites d’importation et d’exportation.

Analyse

Une fuite de routes n’est pas nécessairement une fausse origine. Le RFC 7908 la définit comme une annonce propagée au-delà de la portée prévue. Une route peut viser la bonne destination et pourtant passer d’un fournisseur à un autre, ou d’un pair vers un fournisseur, dans une direction interdite par les relations concernées. L’erreur se trouve alors dans la chaîne de transmission.

Cette chaîne a longtemps reposé sur la seule configuration locale. Un opérateur qualifiait un voisin de client, de fournisseur ou de pair, puis construisait des filtres autour de cette conviction. Rien dans la session n’obligeait l’autre extrémité à raconter la même histoire. Une faute, un filtre absent ou une automatisation défectueuse pouvait devenir une route acceptée ailleurs.

Le RFC 9234 ajoute un échange avant les routes. Le message BGP OPEN peut porter une capacité de rôle : Provider, Customer, Route Server, Route Server Client ou Peer. Si les deux extrémités annoncent un rôle, la paire doit être cohérente. Provider fait face à Customer, Route Server à Route Server Client et Peer à Peer. Sinon, la connexion est rejetée avec la notification Role Mismatch.

Ce contrôle vérifie la cohérence du protocole, pas la vérité commerciale. Le routeur ne lit ni contrat de transit, ni facture, ni engagement de trafic. Deux opérateurs peuvent configurer des rôles compatibles mais faux. Ils peuvent aussi entretenir une relation différente selon le préfixe, le service ou la géographie. Le RFC qualifie alors la relation de complexe et interdit d’utiliser un rôle unique sur la session. Il faut séparer les sessions lorsque c’est possible ou conserver une politique par préfixe.

Le second mécanisme agit sur les UPDATE. Only to Customer, ou OTC, est un attribut de chemin optionnel et transitif de code 35. Sa valeur sur quatre octets contient un numéro de système autonome. Une fois qu’une route est envoyée vers un client, un pair ou un client de serveur de routes, OTC indique qu’elle ne doit ensuite progresser que vers des clients.

Une route portant OTC et reçue d’un client ou d’un client de serveur de routes devient inéligible. Un cas précis de désaccord avec un pair produit le même résultat. À l’exportation, une route déjà marquée OTC ne doit pas être envoyée à un fournisseur, à un pair ou à un serveur de routes. Le signal peut donc bloquer une erreur locale et révéler une fuite plusieurs sauts plus loin.

Un déploiement partiel reste utile. Lorsqu’une route arrive d’un fournisseur, d’un pair ou d’un serveur de routes sans OTC, le réseau conforme peut ajouter l’attribut. Le RFC y voit un avantage pour les premiers adoptants. Mais l’attribut n’est pas protégé cryptographiquement : un AS intermédiaire peut l’enlever, et un marquage erroné peut supprimer une propagation légitime.

La compatibilité impose un choix. Si un voisin annonce un rôle et l’autre non, le comportement normal consiste à poursuivre avec le rôle configuré localement. Le mode strict peut refuser ce voisin muet. Le RFC déconseille d’en faire le réglage par défaut, car une mise à jour logicielle pourrait empêcher la session de démarrer.

Le RFC 8212 demeure le socle : aucune route eBGP ne devrait être importée ou exportée sans politique explicite. Les rôles et OTC n’autorisent pas l’origine, ne rendent pas sûre une politique permissive et ne remplacent pas les filtres de préfixes ou de chemins. Le registre de l’IANA confirme seulement les codes sur le fil — 35 pour OTC et 11 pour Role Mismatch — sans prouver le déploiement d’un réseau nommé.

Sources