Les députés membres de la commission « commerce » ont approuvé ce sulfureux projet de traité avec une majorité très nette : 25 pour, 15 contre et une abstention. La droite du PPE (dont LR) a voté pour, avec l’appui notamment des libéraux (dont l’UDI-Modem – à l'exception de Marielle de Sarnez, qui s'est abstenue). Les écologistes et les élus de la GUE (gauche unitaire européenne, dont le Front de gauche), tout comme les élus FN, s’y sont opposés. Quant aux sociaux-démocrates européens, le groupe s’est divisé, certains étant favorables au texte (dont une majorité d’Allemands), d’autres opposés (dont les socialistes français et belges).

[...]

Désormais, c’est au parlement européen de se prononcer. L’institution détient un droit de veto sur les traités commerciaux depuis l’entrée en vigueur en 2009 du traité de Lisbonne. En 2012, elle avait jeté à la poubelle un autre projet de traité commercial, l’ACTA. Cette fois, les équilibres semblent différents. « On n’a pas besoin d’un agenda transatlantique à la Trump, mais à la Trudeau », a déclaré Marietje Schaake, une élue libérale néerlandaise, à l’unisson de nombre de ses collègues. Pour ses partisans, le CETA est la meilleure des réponses au « désengagement » de Trump, parce que ce n’est pas un simple accord de libre-échange classique, mais un texte, à leurs yeux, plus ambitieux et protecteur.

[...]

De son côté, la conservatrice française Tokia Saïfi, favorable au texte, a exhorté la commission de Bruxelles à faire, une fois de plus, « davantage de pédagogie » auprès des citoyens. « Il y avait des manifestations samedi [contre le CETA, en France notamment – ndlr], et certains montraient nos photos et nos noms, pour dénoncer les eurodéputés qui s’apprêtent à voter pour le CETA. On a franchi un cap, là », s’est inquiétée l’ancienne secrétaire d’État.

Ne pas se remettre en question, juste expliquer aux braves gens qu'il-elle-s se trompent forcément. Normal.

[...]

Le chapitre portant sur la « coopération réglementaire » a focalisé une partie de l’attention, lors du débat lundi (Mediapart en a déjà parlé en 2015, dans un article portant sur le Tafta, le traité de libre-échange avec les États-Unis). En résumé, il s’agit de mettre en place un « forum » d’experts, afin de renforcer la coopération des autorités de régulation, en Europe comme au Canada, au fil des années, sans avoir besoin de rouvrir les négociations du CETA en tant que telles. Mais les ONG sont persuadées que cette structure renforcera l’influence des lobbies de l’industrie, au cœur des processus de décision. Quant aux eurodéputés, certains continuent de redouter que ce mécanisme empiète sur leur travail de législateur.

[...]

Le vote devrait donc avoir lieu à Strasbourg aux alentours du 15 février. Justin Trudeau, déjà présent à Bruxelles à l’automne, pourrait faire le déplacement en Alsace pour assister au vote. Les débats et le vote en plénière pourraient toutefois s’avérer un peu plus difficiles qu’au sein de la commission commerce, où les députés sont globalement plus favorables au libre- échange que l’ensemble de leurs collègues. D’autres commissions internes au parlement européen ont adopté des « opinions » sur le CETA ces dernières semaines, dont celle consacrée à l’emploi, qui a rejeté, elle, le traité.

En cas de feu vert à Strasbourg, le CETA pourrait entrer en vigueur, de manière provisoire, dès avril 2017. Considéré comme un traité « mixte », il devra ensuite être voté par l’ensemble des parlements
nationaux – et parfois, régionaux – au sein des 28, pour rendre son approbation définitive.

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.