Entre ARN et Grifon, deux FAI associatifs, le premier autour de Strasbourg, l'autre autour de Rennes, nous avons deux tunnels GRE (un par routeur) depuis avril 2016 afin qu'ARN partage ses transits IP avec Grifon dans l'optique de palier, sans un surcoût inabordable, les insuffisances (les services Google et HE sont inaccessibles en IPv6, les services Google sont lents en IPv4, etc.) de l'unique transitaire de Grifon, c'est-à-dire Cogent. Depuis la fin 2016, Grifon dispose d'un deuxième transitaire physique, Quantic Telecom, et n'a donc plus besoin d'ARN. Nous avons décidé de conserver les tunnels au moins quelques mois, "au cas où", histoire de ne pas avoir à refaire la config' à l'arrache si jamais il y a un problème.

En conséquence, Grifon positionne la communauté BGP « no-export » (0xFFFFFF01 aka 65535:65281) sur les annonces BGP qu'elle envoie à ARN, ce qui a pour effet qu'ARN n'annonce pas à ses transitaires qu'elle connaît directement Grifon, ce qui a pour effet qu'aucun trafic à destination de Grifon transitera par ARN. En plus de cela, Grifon affecte, à la session BGP avec ARN, une préférence (distance administrative dans la langue Cisco) plus faible afin de passer par ARN pour sortir du trafic uniquement si aucun autre choix n'est possible.

Samedi dernier, l'infrastructure de Grifon était en maintenance totale et le routeur a été redémarré. Comme FreeBSD n'est pas un système sérieux pour équiper un routeur un poil moderne, les tunnels GRE ne sont pas remontés automagiquement. Pourtant, à partir de ce moment-là, on constate qu'ARN réannonce Grifon sur Internet. Pourquoi ?! Si les sessions BGP, établies en passant par les tunnels, étaient allumées, alors l'annonce BGP en provenance du tunnel serait privilégiée (AS_PATH plus court + préférence locale plus élevée) et la communauté BGP no-export serait respectée donc ARN ne devrait rien ré-annoncer. Si les sessions BGP étaient éteintes, alors ARN, n'ayant aucune route directe vers Grifon, ne devrait rien réannoncer non plus.

Chez ARN, nous avons deux routeurs. L'un tourne avec BIRD, l'autre avec Quagga. Demandons à ces logiciels ce qu'ils annoncent aux transitaires d'ARN :

    bird6> sh route export bgp_cogent
    2a00:5881:8100::/40 unreachable [static_arn_allocations 01:24:19] * (200)

    quagga> sh ipv6 bgp nei 2001:978:2:57::7:1 advertised-routes
    [...]
    *> 2a00:5881:8100::/40   2001:978:2:57::7:3  0  32768 i
    *> 2a00:5884::/32        2001:978:2:57::7:3  0  32768 174 204092 i

En effet, si BIRD exporte uniquement l'allocation IP d'ARN, Quagga réannonce l'allocation de Grifon dont il a eu connaissance via Cogent (on voit cela car le numéro d'AS de Cogent, 174, traîne dans l'AS_PATH ;) ).

Pourtant, on a configuré un filtre :

    neighbor UPSTREAM-v6 prefix-list ARN-AND-DOWNSTREAMS-V6 out

    ipv6 prefix-list ARN-AND-DOWNSTREAMS-V6 seq 5 permit 2a00:5881:8100::/40
    ipv6 prefix-list ARN-AND-DOWNSTREAMS-V6 seq 10 permit 2a00:5884::/32

Celui-ci indique de redistribuer notre allocation et celle de Grifon à tous nos transitaires dès qu'une route est présente dans la RIB BGP. Pour qu'une route atterisse dans la RIB, il faut soit en être à l'origine (« network » et « aggregate-address » dans la configuration, principalement) ou l'importer dans notre RIB depuis un autre protocole (depuis la gRIB/FIB Linux, depuis OSPF/ISIS (même si c'est très fortement déconseillé par les bonnes pratiques !), etc.) ou l'obtenir via un pair BGP, ce qui est le cas ici puisque Cogent appprend l'existence de Grifon à nos routeurs.

Comment faire pour ne pas que le Quagga d'ARN redistribue l'annonce qu'il obtient via Cogent ? En filtrant sur l'AS_PATH : il faut (re)annoncer uniquement les routes dont l'AS_PATH est vide (ce qui signifie que l'annonce a été crée/générée localement afin d'annoncer un préfixe local) ou s'il contient uniquement l'ASN de Grifon.

Comment écrit-on cela dans la langue de Cisco ?

    address-family ipv6
      neighbor UPSTREAM-v6 filter-list no-redistribute-grifon-over-cogent out
    exit-address-family

    ip as-path access-list no-redistribute-grifon-over-cogent permit ^$|^204092$

Notons :

• Qu'il faut aussi appliquer cela à la session BGPoIPv4 ;

• Que l'on aurait pu utiliser une liste séquentielle au lieu d'un "OU" dans une seule regex :

  ip as-path access-list no-redistribute-grifon-over-cogent permit seq 5 ^$
  ip as-path access-list no-redistribute-grifon-over-cogent permit seq 10 ^204092$

Et pourquoi BIRD ne fuite rien, lui ? Parce que la syntaxe de sa config' est moins vaseuse : on filtre les préfixes reçus sur la session BGP avec Grifon et, lors de l'export vers les trannsitaires, on filtre sur le protocole d'origine (celui qui a fait entrer le préfixe dans la RIB). Exemple :

    template bgp UPSTREAM
    {
        [...]

        export where proto = "static_arn_allocations" || proto = "bgp_grifon" ;
        export limit 2 action disable;
    }

Pour information, un template BIRD est l'équivalent d'un peer-group dans la terminologie Cisco. Ici, nous exportons au maximum deux préfixes qui peuvent provenir uniquement des protocoles désignés par leur nom c'est-à-dire la session BGP avec Grifon et la null-route correspondante à notre allocation IP.

ÉDIT DU 13/02/2017 À 18H40 : bonne remarque en https://twitter.com/chiwawa_42/status/831061688472522752 . Oui, les bonnes pratiques privilégient plutôt que l'on attribue des communautés aux downstreams et que l'on s'en serve pour filtrer. Car les communautés regroupent toutes les opérateurs possibles en un mécanisme unique donc ça génère moins d'aléas et d'oublis dans la conf'. Mais, à l'heure actuelle, ARN a fourni du transit IP à Grifon pour dépanner et ne fournit pas de transit IP à d'autres structures. Or, quand on a un seul downstream, une config' avec des communautés demande plus de taff : il faut toujours matcher les préfixes en entrée du downstream, leur attribuer une communauté et il faut matcher cette communauté en sortie sur les upstreams. Sans compter qu'un filtrage par préfixe en sortie sur les upstreams reste nécessaire malgré les communautés : une fausse manip' peut conduire à attribuer la communauté "ceci est un downtream" à un pair qui n'en est pas un (le filtrage par préfixe limite la casse, ceinture et bretelles) ou, plus simplement, le routeur peut se vautrer et ignorer les communautés (bug connu en 12.2.33SRC, par exemple).

Merci à Chiwawa d'avoir prolongé la convers' sur IRC. :) FIN DE L'ÉDIT DU 13/02/2017 À 18H40.