Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.
C’est alors la barrière de la prise en main qui fait peur, et pourtant...
Les logiciels libres
L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.
Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.
Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.
Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.
Il n'y a pas de rapport simple entre la longueur d'un
RFC et l'importance de la norme technique
qu'il spécifie. Ce RFC (vieux de plus de vingt ans) ne fait que cinq
pages mais décrit une technique qui est essentielle au bon
fonctionnement du routage sur
l'Internet, la technique des
communautés BGP.
Rien de plus simple que cette idée : une
communauté est juste une étiquette numérique
qu'on ajoute aux annonces de routes IP
transportées par le protocole BGP. On peut ainsi « décorer » ses
annonces comme on veut, et les autres routeurs BGP pourront ainsi
prendre des décisions fondées sur cette information
supplémentaire. Les communautés sont juste une syntaxe, on leur met
la signification qu'on veut.
Un tout petit rappel sur BGP : c'est
le protocole d'échange de routes entre les
opérateurs Internet. Son principe est simple (RFC 4271) : quand une route
apparait, on annonce à ses pairs BGP la route, sous la forme d'un
préfixe d'adresses IP, avec un certain
nombre d'attributs. Les attributs ont un format
et une sémantique précise. Voici un exemple d'une annonce reçue par
le service RouteViews, et affichée sous
forme texte par le logiciel bgpdump :
TIME: 02/17/17 15:00:00
TYPE: BGP4MP/MESSAGE/Update
FROM: 208.51.134.246 AS3549
TO: 128.223.51.102 AS6447
ORIGIN: IGP
ASPATH: 3549 3356 2914 30259
NEXT_HOP: 208.51.134.246
MULTI_EXIT_DISC: 13920
ATOMIC_AGGREGATE
AGGREGATOR: AS30259 10.11.1.1
COMMUNITY: 2914:410 2914:1001 2914:2000 2914:3000 3356:3 3356:86 3356:575 3356:666 3356:2011 3356:11940 3549:2011 3549:2017 3549:2521 3549:2582 3549:2950 3549:2991 3549:30840 3549:31826 3549:32344 3549:33036 3549:34076
WITHDRAW
93.181.192.0/19
ANNOUNCE
199.193.160.0/22
On y voit que le routeur
208.51.134.246
,
appartenant à l'AS
3549 (Level
3, ex-Global Crossing) a
annoncé une route à destination du préfixe
199.193.160.0/22
(il a aussi retiré une autre
route mais on ne s'en soucie pas ici). Cette annonce avait plusieurs
attributs comme le chemin d'AS (
ASPATH
) emprunté.
Les communautés (au nombre de 21 ici) sont un attribut
COMMUNITY
dont le
format est défini mais dont on fait ensuite ce qu'on
veut. L'utilisation la plus courante est d'indiquer l'origine d'une
route, pour d'éventuelles décisions ultérieures, en fonction de la
politique de routage. Les communautés sont donc un outil pour gérer
la complexité de ces politiques.
Le RFC définit d'ailleurs une communauté comme « un groupe de
destinations partageant une propriété commune ». Ainsi, dans le cas de
l'annonce ci-dessus, la lecture de la documentation des différents
opérateurs nous apprend que 3549:31826
indique
que la route a été apprise en Europe, au Royaume-Uni, que
2914:410
nous montre
qu'il s'agissait d'une route d'un client (et non pas d'un pair) de
NTT, etc.
L'exemple d'utilisation donné par le RFC date pas mal
(NSFNET n'existe plus) mais ce
genre de cas est toujours fréquent. NSFNET, financé par l'argent
public, ne permettait pas d'utilisation purement commerciale. Une
entreprise à but lucratif pouvait s'y connecter, mais seulement pour
échanger avec les organismes de recherche ou d'enseignement (le RFC
parle d'organismes respectant l'AUP, qui étaient les conditions
d'utilisation de NSFNET). Une
telle politique est facile à faire avec les communautés : on
étiquette toutes les routes issues du monde enseignement/recherche
avec une communauté signifiant « route AUP », et NSFNET pouvait
annoncer les routes AUP à tous et les routes non-AUP (n'ayant pas
cette communauté) seulement aux client AUP. Ainsi, deux entreprises
commerciales ne pouvaient pas utiliser NSFNET pour communiquer entre
elles. Sans les communautés, une telle politique aurait nécessité
une base complexe de préfixes IP, base difficile à maintenir,
d'autant plus que tous les routeurs de bord devaient y
accéder. (Avant les communautés, c'était bien ainsi qu'on procédait,
avec les retards et les erreurs qu'on imagine.)
Autre exemple d'utilisation donné par le RFC, l'agrégation de
routes. Si on annonce à la fois un préfixe englobant et un
sous-préfixe plus spécifique pour optimiser l'accès à un site particulier, on ne souhaite en général annoncer ce
sous-préfixe qu'aux pairs proches (les autres n'ont pas de chemin
meilleur vers ce site). On va donc étiqueter l'annonce faite à ces
pairs proches avec une
communauté indiquant « cette route est pour vous, mais ne la
propagez pas ». D'autres exemples d'utilisation figurent dans les
RFC 1998 et RFC 4384.
L'attribut COMMUNITY
(le RFC le nomme
COMMUNITIES
, ce qui est effectivement plus logique, mais il a bien été enregistré sous
le nom COMMUNITY
) est donc un attribut
optionnel (certaines annonces BGP ne l'utiliseront pas) et transitif
(c'est-à-dire qu'il est conçu pour être transmis avec l'annonce
lorsqu'on la relaie à ses pairs). Il consiste en un ensemble (non
ordonné, donc) de communautés, chacune occupant quatre octets (ce
qui est bien insuffisant aujourd'hui). Son code de type d'attribut
est 8. Le nombre de communautés dans une annonce est très
variable. Par exemple, le LU-CIX voit une
moyenne de 10,5 communautés par route sur ses serveurs de routes.
Si un attribut COMMUNITY
est mal formé, en
vertu du RFC 7606, la route annoncée sera
retirée. (À l'époque du RFC originel, une erreur aboutissait à
fermer toute la session BGP, retirant toutes les routes.)
Chaque communauté peut donc aller de 0x0000000 à 0xFFFFFFFF mais
les valeurs de 0x0000000 à
0x0000FFFF, et de 0xFFFF0000 à 0xFFFFFFFF sont réservées. D'autre
part, la convention recommandée est de mettre son numéro
d'AS dans les deux premiers octets, et une
valeur locale à l'AS dans les deux derniers. (Notez que ce système
ne marche plus avec les AS de quatre octets du RFC 6793, ce qui a mené aux RFC 4360 et
RFC 8092.) Prenons comme exemple de
communauté 0x0D1C07D1. On note les communautés sous forme de deux
groupes de deux octets chacun, séparés par un
deux-points. Cette communauté est donc
3356:2001
: AS 3356
(Level 3) et valeur locale 2001 (le choix des
valeurs locales est une décision... locale donc on ne peut savoir ce
que signifie 2001 qu'en regardant la documentation
de Level 3. Dit autrement, la valeur locale est opaque.)
Certaines valeurs sont réservées à des communautés « bien
connues ». C'est le cas par exemple de 0xFFFFFF01 (alias
NO_EXPORT
: ne pas transmettre cette annonce en
dehors de son AS), de 0xFFFFFF02 (NO_ADVERTISE
,
ne transmettre cette annonce à aucun autre routeur) ou bien de la
plus récente 0xFFFF029A (BLACKHOLE
, RFC 7999). Rappelez-vous que chaque routeur est
maître de ses décisions : les communautés bien connues sont une
suggestion, mais on ne peut jamais être sûr que le pair va la suivre
(c'est ainsi que, malgré les NO_EXPORT
que
mettent les nœuds anycast
qui veulent rester relativement locaux, on voit dans certains cas les annonces
se propager plus loin, parfois pour des bonnes et parfois pour des
mauvaises raisons.)
Enfin, le RFC précise qu'un routeur est libre d'ajouter ses
propres communautés aux annonces qu'il relaie, voire de supprimer
des communautés existantes (chacun est maître de son routage).
Quelques bonnes lectures sur les communautés BGP :
Certains looking glass affichent les communautés par exemple
celui de Cogent :
BGP routing table entry for 129.250.0.0/16, version 3444371605
Paths: (1 available, best #1, table Default-IP-Routing-Table)
2914
130.117.14.250 (metric 10109031) from 38.28.1.83 (38.28.1.83)
Origin IGP, metric 4294967294, localpref 100, valid, internal, best
Community: 174:11102 174:20666 174:21100 174:22010
Originator: 38.28.1.32, Cluster list: 38.28.1.83, 38.28.1.67, 38.28.1.235
Les communautés sont souvent documentées dans l'objet AS stocké
dans la base d'un RIR et accessible via
whois (ou, aujourd'hui,
RDAP). Ici, celle du
France-IX (notez l'utilisation d'AS privés) :
% whois AS51706
...
aut-num: AS51706
as-name: FRANCE-IX-AS
...
remarks: The following communities can be used by members:
remarks:
remarks: *****************************************************
remarks: ** Note: These communities are evaluated
remarks: ** on a "first match win" basis
remarks: *****************************************************
remarks: 0:peer-as = Don't send route to this peer as
remarks: 51706:peer-as = Send route to this peer as
remarks: 0:51706 = Don't send route to any peer
remarks: 51706:51706 = Send route to all peers
remarks: *****************************************************
remarks: ** Note: the community (51706:51706) is applied
remarks: ** by default by the route-server
remarks: *****************************************************
remarks:
remarks: 65101:peer-as = Prepend 1x to this peer
remarks: 65102:peer-as = Prepend 2x to this peer
remarks: 65103:peer-as = Prepend 3x to this peer
remarks: 65201:peer-as = Set MED 50 to this peer
remarks: 65202:peer-as = Set MED 100 to this peer
remarks: 65203:peer-as = Set MED 200 to this peer
remarks:
remarks: -----------------------------------------------------
remarks: BLACKHOLING, set the next-hop to the blackhole router
remarks: can be use with the basic community (above)
remarks:
remarks: 65535:666 = BLACKHOLE [RFC7999]
remarks:
remarks: https://www.franceix.net/en/technical/blackholing/
remarks:
remarks: -----------------------------------------------------
remarks: Set peer-as value as listed below for all IXP members:
remarks: (Can't be used for 51706:peer-as)
remarks: 64649 = FranceIX Marseille peers
remarks: 64650 = FranceIX Paris peers
remarks: 64651 = SFINX peers
remarks: 64652 = LyonIX peers
remarks: 64653 = LU-CIX peers
remarks: 64654 = TOP-IX peers
remarks: 64655 = TOUIX peers
remarks:
remarks: -----------------------------------------------------
remarks: Set peer-as value as listed below for 32 bits ASNs:
remarks: AS197422 -> AS64701 (Tetaneutral)
remarks: AS196689 -> AS64702 (Digicube)
[...]
remarks:
remarks: Extended Communities are supported and usage is
remarks: encouraged instead of 32b->16b mapping
remarks: -----------------------------------------------------
remarks: Communities that are in the public range
remarks: (1-64495:x) and (131072-4199999999:x)
remarks: will be preserved by the route-servers
remarks: -----------------------------------------------------
remarks: Well-known communities are not interpreted by the
remarks: route-servers and are propagated to all peers
remarks: -----------------------------------------------------
remarks:
remarks: The following communities are applied by the route-server:
remarks:
remarks: *****************************************************
remarks: ** WARNING
remarks: ** You should not set any of these by yourself
remarks: ** (from 51706:64495 to 51706:64699)
remarks: ** (and 51706:64800 to 51706:65535)
remarks: ** If you do so, your routes will be rejected
remarks: *****************************************************
remarks:
remarks: 51706:64601 = Prefix received from a peer on RS1 Paris
remarks: 51706:64602 = Prefix received from a peer on RS2 Paris
remarks: 51706:64611 = Prefix received from a peer on RS1 Marseille
remarks: 51706:64612 = Prefix received from a peer on RS2 Marseille
remarks:
remarks: 51706:64649 = Prefix received from a FranceIX Marseille peer
remarks: 51706:64650 = Prefix received from a FranceIX Paris peer
remarks: 51706:64651 = Prefix received from a SFINX peer
remarks: 51706:64652 = Prefix received from a LyonIX peer
remarks: 51706:64653 = Prefix received from a LU-CIX peer
remarks: 51706:64654 = Prefix received from a TOP-IX peer
remarks: 51706:64655 = Prefix received from a TOUIX peer
remarks:
remarks: 51706:64666 = Prefix with invalid route origin
...