Résumé

  • 0.0.0.0/0 et ::/0 ne fixent aucun bit de destination, mais correspondent à toute adresse qui n’a pas de route plus spécifique. Leur portée réelle change donc quand le reste de la table change.
  • Générer, exporter, recevoir, accepter, sélectionner, programmer et réellement acheminer une route par défaut sont des actes distincts. Une lumière verte à un seul étage ne démontre jamais toute la chaîne.
  • Le dernier recours n’est défendable que s’il est limité au bon voisin, conditionné par une preuve proche du service promis, contrôlé aussi par le receveur et retiré dans un délai mesuré lorsque cette preuve disparaît.

Imaginons un petit réseau, AS 64580, qui reçoit seulement quelques routes régionales et une route par défaut de son fournisseur AS 64520. À 09 h 41, AS 64520 perd le transport vers son principal transit. La liaison client et la session EBGP restent intactes. Une poignée de préfixes régionaux continue de fonctionner par un autre chemin. La commande de génération du défaut, elle, n’était soumise à aucune condition.

Le client conserve donc /0 comme best path. Son FIB envoie toujours le trafic résiduel au même routeur. Les probes vers le loopback du fournisseur, un resolver local et deux réseaux couverts par des routes plus spécifiques passent. D’autres paquets entrent chez AS 64520 puis s’arrêtent devant l’amont disparu.

La scène est synthétique, mais elle ne suppose aucun comportement exotique. BGP n’oblige pas une annonce artificielle de défaut à suivre l’état d’un autre transit. Une session vivante ne certifie pas les chemins situés au-delà du voisin. Et le préfixe zéro ne contient aucune liste des destinations que son auteur sait encore atteindre.

Le domaine mouvant de /0

Le choix de forwarding décrit par RFC 1812 commence par la correspondance du préfixe, puis retient la correspondance la plus longue. Un /24 gagne donc sur un /0 pour les adresses qu’il couvre. Le défaut n’intervient qu’après l’élimination de toutes les solutions plus précises.

Cela produit un domaine résiduel. Il n’est pas attaché une fois pour toutes à la route. Si 198.51.100.0/24 apparaît, ses adresses sortent du domaine du défaut. Si le /24 est retiré, elles y rentrent immédiatement. L’annonce /0 n’a changé ni de hash ni d’attribut ; son pouvoir pratique vient pourtant de s’élargir.

Le même mécanisme existe en IPv6 avec ::/0. Autoriser la version IPv4 ne vaut pas consentement automatique pour IPv6. Chaque famille possède ses routes, ses politiques, ses next hops et ses échecs.

RFC 4098 distingue la route par défaut d’une table default-free et d’une table complète default-free. Recevoir une seule promesse de dernier recours économise de l’état, mais retire au client la visibilité destination par destination. Recevoir la table complète déplace davantage de décision chez le client et exige davantage de ressources. Un mélange de défaut et de routes sélectionnées crée encore un autre modèle. Aucun de ces choix n’est intrinsèquement souverain ; chacun répartit information, coût et dépendance différemment.

L’annonce doit être un acte explicite

RFC 4632 exige que les implémentations sachent accepter le préfixe dégénéré 0.0.0.0/0. Il précise aussi qu’une annonce inter-domaine ne doit jamais naître comme option implicite non configurée : le routeur ne doit la transmettre à un autre domaine qu’après configuration explicite.

RFC 7454 ajoute la discipline relationnelle. Hors de configurations particulières entre customer et provider, l’acceptation ou la publicité de 0.0.0.0/0 et ::/0 n’est normalement pas souhaitée ; le filtrage général est recommandé. Le texte reconnaît en revanche qu’un client peut demander uniquement le défaut à son fournisseur.

La validité dépend donc du couple de réseaux et du service convenu. Une annonce autorisée vers un client ne doit pas être héritée par un peer-group qui inclut un route server, un upstream ou un autre tenant. Une route acceptée dans une VRF ne doit pas entrer dans la table voisine simplement parce qu’un profil de configuration partage ses clauses.

Le fournisseur doit établir une liste exacte de destinataires. Le client doit accepter exact /0 uniquement depuis les voisins dont le rôle justifie ce pouvoir. Les deux filtres sont utiles : l’erreur de l’un rencontre encore l’autonomie de l’autre.

RFC 8212 traite la frontière voisine : l’absence de politique import/export EBGP ne doit pas devenir une permission silencieuse. Il ne transforme toutefois pas une politique explicite en bonne politique. Un objet route-map peut exister et autoriser un mauvais voisin, une mauvaise famille ou une condition qui ne mesure plus rien d’utile.

Sept états derrière un seul mot

Dire « le défaut est présent » mélange au moins sept observations. Le fournisseur produit d’abord un candidat : annonce synthétique, route static, generated route ou route BGP. Sa politique export décide ensuite si le voisin la reçoit. Le client reçoit l’UPDATE, applique sa politique import, compare le résultat avec d’autres candidats, installe le gagnant dans la RIB puis programme le next hop dans la FIB. Enfin, un paquet tente réellement de traverser le voisin.

Chaque transition possède son propre échec. Une route peut être générée mais filtrée, reçue mais rejetée, acceptée mais non sélectionnée, sélectionnée mais pas encore inscrite dans le hardware. Elle peut être parfaitement programmée localement et aboutir à un blackhole après le premier saut.

La récursion du NEXT_HOP ne clôt pas la preuve. Elle montre que le routeur local sait joindre son prochain saut. AS_PATH ne clôt pas davantage la preuve : il décrit la propagation de l’annonce /0, pas le chemin réel vers chaque adresse comprise dans son domaine résiduel. 64520 dans le path ne signifie pas que toutes les destinations se trouvent à un AS de distance.

Le retrait est lui aussi ciblé. Les procédures UPDATE de RFC 4271 permettent de retirer /0 sans détruire la session ni les autres routes. Un outil qui ne sait répondre que par un clear du voisin augmente inutilement le blast radius et efface une partie des indices nécessaires au diagnostic.

Les implémentations ne promettent pas la même chose

La documentation Cisco IOS actuelle présente neighbor ... default-originate comme une décision par voisin et indique que le routeur local n’a pas besoin de posséder 0.0.0.0. Sur Nexus, la route artificielle peut être envoyée sans exister dans la routing table ni devenir une entrée du BGP RIB local. Une route-map facultative rend la génération conditionnelle à une route installée qui satisfait le match.

FRRouting ne publie pas 0.0.0.0/0 par défaut, même lorsque cette route figure dans la table. L’opérateur doit activer explicitement neighbor ... default-originate et peut lui associer une route-map.

Junos place le contrôle dans son modèle de routing policy. Les routes BGP actives suivent la politique d’export BGP ; une route static, aggregate ou generated explicitement configurée doit être autorisée par l’export pour entrer dans BGP. Les exemples conditionnels relient ainsi état actif de la route et politique.

Ces différences changent un incident. Supprimer une static /0 peut ne rien faire à une annonce artificielle Cisco sans condition. Sur un design où l’export dépend d’une generated route active, la même suppression peut être précisément le signal de retrait. Un runbook portable seulement par son vocabulaire risque donc de conserver une promesse morte.

La seule méthode sûre consiste à tester la version déployée. Observer la table locale, le BGP RIB, l’Adj-RIB-Out ou la vue advertised-routes et la réception du client. Retirer le support réel tout en gardant la session client. Mesurer la réévaluation, l’UPDATE de retrait, le nouveau best path, l’écriture FIB et le rétablissement des paquets. Puis restaurer et vérifier le retour.

La condition n’est qu’un témoin

Rendre l’annonce conditionnelle ne suffit pas. Il faut démontrer que la condition représente le service auquel /0 donne accès.

Un loopback de provider accessible prouve ce loopback. Une interface up prouve le carrier local. Une route static active peut simplement prouver qu’une configuration existe. Un compteur de table supérieur à un seuil prouve un volume, pas le fonctionnement de l’egress choisi. Une session BFD prouve un voisin et un chemin donnés. Le monde résiduel du défaut est plus large que chacune de ces mesures.

Le service doit précéder la métrique. Si le contrat porte sur un transit Internet étendu, les canaries doivent traverser le même egress que les clients et viser plusieurs réseaux indépendants. Si le défaut désigne uniquement une sortie WAN privée, le test doit rester dans ce périmètre. Une définition trop vaste produit une condition impossible à prouver ; une définition cachée derrière le mot « Internet » produit des litiges.

Combiner les signaux oblige à choisir entre deux erreurs. Exiger que tout réussisse peut retirer le dernier chemin utile lorsqu’une seule cible de mesure tombe. Se contenter d’une réussite peut conserver le défaut au milieu d’une panne majeure. Quorum, temporisation, hysteresis et seuil de retour déterminent qui supporte le coût d’un retrait précoce ou tardif.

La décision combinée doit être enregistrée comme une machine d’état. Conserver chaque entrée, l’instant du changement, la raison de la décision, l’instant du retrait, le changement de FIB et la récupération des paquets. Une capture prise après le retour à la normale ne peut pas reconstruire cette chaîne.

Les routes plus précises fabriquent de faux succès

Dans l’incident initial, plusieurs probes réussissent parce que leurs destinations utilisent des routes plus précises. Ils ne testent jamais le défaut cassé. Si le parc de monitoring se concentre sur des services locaux ou populaires annoncés spécifiquement, un petit îlot fonctionnel peut masquer la panne de la majorité du trafic résiduel.

Le défaut peut aussi être sain et perdre malgré tout. Une route /24 obsolète, mal filtrée ou associée à un next hop mort gagne par longest match et détourne ce bloc vers l’échec. La réussite de /0 ne doit donc pas supprimer l’alarme du plus spécifique.

Chaque canary doit conserver la route effectivement choisie : préfixe gagnant, RIB, next hop, FIB et egress. Une réponse HTTP sans cette attribution ne permet pas de dire quelle politique elle a validée. Lorsqu’un plus spécifique apparaît ou disparaît, la classification du canary doit changer même si /0 reste identique.

Deux défauts ne prouvent pas davantage deux destins indépendants. Des routeurs différents peuvent partager fibre métropolitaine, upstream, contrôleur ou cible de santé. Le test « couper une session » vérifie la redondance de session ; il ne vérifie pas nécessairement la défaillance commune réelle.

La fuite transfère un pouvoir qui n’a pas été demandé

Recevoir un défaut d’une relation non autorisée revient à remettre à ce voisin tout le trafic que la table ne décrit pas plus précisément. Un core qui détient une table complète peut n’exposer qu’un petit résidu. Un client qui n’a aucun autre chemin peut transférer presque tout son trafic.

Le filtre export doit lier /0 aux seuls customers concernés et bloquer peers, providers, route servers et tenants étrangers. Le filtre import doit être exact, propre à l’AFI/SAFI et à la routing instance. Les générateurs automatiques doivent tester l’héritage de peer-groups et les deux familles séparément.

Comparer ensuite intention et résultat. La configuration répond à « qui devrait recevoir ? ». La vue Adj-RIB-Out répond à « qui a été servi par ce speaker ? ». La vue du receveur répond à « qui l’a réellement reçu et accepté ? ». Un collecteur public peut détecter une fuite plus lointaine, mais son silence n’est pas une preuve universelle d’absence.

Une preuve qui va jusqu’au paquet

Le registre opérationnel commence par une phrase de service : transit public général, accès à un ensemble externe, sortie de WAN privé ou autre objet délimité. Il associe advertiser, receiver, rôle, famille, VRF, propriétaire de l’approbation et propriétaire du retrait.

Il consigne ensuite le mode de génération, la condition, ses sources, le quorum, les timers, l’hysteresis et l’action en échec. Au runtime, il préserve la route candidate, le résultat post-policy, les vues reçue et acceptée, le motif du best path, la récursion, la FIB matérielle et les alternatives.

Les canaries partent du réseau receveur, là où la confiance devient un acte de forwarding. Certaines cibles doivent n’être accessibles que par /0; d’autres doivent être volontairement couvertes par des routes plus précises. Elles doivent être réparties entre dépendances réelles et conserver l’egress observé.

Le test de panne garde la session client active et supprime le véritable support amont. Il mesure séparément la chute du predicate, le retrait, la sélection d’un défaut alternatif, la programmation hardware et le retour des paquets. S’il n’existe pas d’alternative, il vérifie au moins que le client cesse d’envoyer vers une promesse morte.

Le rollback restaure l’ensemble : génération, condition, timers, scope de voisins, attributs, préférence import et monitoring. Une configuration revenue sans FIB conforme ni paquets récupérés n’est pas un rollback vérifié.

Une coordination mince n’autorise pas une dépendance sans sortie

La route par défaut peut être une excellente coordination minimale. Le provider n’impose pas toute sa table au customer ; le customer garde la liberté d’accepter, de préférer ou de refuser ; un retrait peut fermer le contrat sans fermer la session. Peu d’information commune suffit.

Cette minceur interdit précisément de surinterpréter la route. Le mot provider n’est pas une preuve de forwarding. L’UPDATE n’est pas un certificat de service. L’accord initial n’est pas un abandon permanent du contrôle local.

La primauté du code en fonctionnement impose un ordre : le contrat expose l’intention commerciale, la configuration l’intention technique, l’UPDATE l’acte d’annonce, RIB et FIB la décision locale, le paquet le résultat. Chaque niveau répond à sa question et aucun ne doit usurper le suivant.