Suport technique et veille technologique
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.
- Novembre 2019 -
Le protocole d'annonces de routes BGP permet
d'attacher aux annonces des étiquettes, les
communautés, qui sont des
métadonnées pour les routes. Certaines
valeurs sont réservées pour des communautés « bien connues » qui
sont censées donner le même résultat partout. Mais ce n'est pas
vraiment le cas, comme l'explique ce RFC, qui demande qu'on améliore
la situation.
Les communautés sont normalisées dans le RFC 1997, qui décrit par la même occasion le concept de
communauté bien connue. Celles-ci sont enregistrées
à l'IANA. Voici un exemple d'annonce BGP avec des communautés :
TIME: 11/03/19 09:14:47
TYPE: BGP4MP/MESSAGE/Update
FROM: 89.149.178.10 AS3257
TO: 128.223.51.102 AS6447
ASPATH: 3257 8966 17557 136030 138368
NEXT_HOP: 89.149.178.10
COMMUNITY: 3257:4000 3257:8102 3257:50001 3257:50110 3257:54900 3257:54901 65535:65284
ANNOUNCE
103.131.214.0/24
Cette annonce du préfixe
103.131.214.0/24
contient sept communautés, dont une bien connue,
65535:65284
(
0xFFFFFF04
en
hexadécimal),
NOPEER
, normalisée dans le RFC 3765.
Le
RFC estime que le RFC 1997 était un
peu trop flou, et que cela explique partiellement les différences
que nous observons aujourd'hui.
Ainsi, le changement d'une communauté par la politique
locale d'un AS. Un routeur
BGP qui reçoit une annonce avec des
communautés peut évidemment modifier ces communautés (typiquement en
ajouter, mais parfois aussi en enlever). Tous les modèles de
routeurs permettent donc de modifier les communautés, entre autres
en fournissant une commande, appelée
set
ou un nom de ce genre, qui remplace les communautés
par un autre ensemble de communautés. Toutes les communautés ? Non,
justement, c'est là qu'est le problème : sur certains routeurs, les
communautés bien connues sont épargnées par cette opération, mais pas
sur d'autres routeurs.
(Personnellement, cela me semble un problème
d'interface utilisateur, qui ne concerne pas
vraiment le protocole. Mais je cite l'opinion du RFC, qui trouve
cette différence de comportement ennuyeuse, par exemple parce
qu'elle peut créer des problèmes si un technicien, passant sur un
nouveau type de routeur, suppose qu'une commande ayant le même nom
va avoir la même sémantique.)
La section 4 du RFC liste les comportements constatés sur les
routeurs :
- Sur Junos OS,
community
set
remplace toutes les communautés, bien connues ou
pas,
- Sur les Brocade NetIron,
set community
a le même effet,
- Même chose sur VRP de Huawei,
avec
community set
,
- Idem sur SR OS,
avec
replace
,
- Sur IOS XR,
set
community
remplace toutes les communautés
sauf certaines communautés bien connues,
comme NO_EXPORT
, ces communautés doivent être
retirées explicitement si on veut un grand remplacement ; la liste
des communautés ainsi préservées n'est même pas la liste enregistrée à l'IANA,
- Sur OpenBGPD,
set
community
ne supprime aucune des communautés
existantes, qu'elles soient bien connues ou pas.
La section 5 de notre RFC souhaite donc que, pour les futures communautés
spécifiées dans de futurs RFC, le comportement (remplaçable ou pas)
soit précisé par l'IETF.
À destination, cette fois, des gens qui font le logiciel des
routeurs, la section 6 suggère :
- De ne pas changer le comportement actuel, même pour
améliorer la cohérence, même si une communauté change de statut
(devenant bien connue) car ce changement serait trop
perturbant,
- Mais de documenter soigneusement (apparemment, ce n'est pas
fait) le comportement des commandes de type
set
; que font-elles aux communautés bien
connues ?
Quant aux opérateurs réseau, le RFC leur rappelle qu'on ne peut
jamais être sûr de ce que vont faire les AS
avec qui on s'appaire, et qu'il vaut mieux vérifier avec eux ce
qu'ils font des
NO_EXPORT
ou autres communautés
bien connues qu'on met dans les annonces qu'on leur envoie.
RFC 9562: Universally Unique IDentifiers (UUIDs)
- 12 mai -
Ce RFC normalise les UUID, une famille d'identificateurs uniques, obtenus sans registre central. Il remplace l'ancienne norme, le RFC 4122, avec (...)
RFC 9490: Report from the IAB Workshop on Management Techniques in Encrypted Networks (M-TEN)
- 9 mai -
Aujourd'hui, l'essentiel du trafic sur l'Internet est chiffré, et pour d'excellentes raisons. Pas question de revenir là-dessus, mais, ceci dit, il (...)
RFC 9557: Date and Time on the Internet: Timestamps with Additional Information
- 29 avril -
Ce RFC modifie légèrement le format des estampilles temporelles du RFC 3339, changeant à la marge une définition et, surtout, permettant d'y attacher (...)
RFC 9567: DNS Error Reporting
- 27 avril -
Lorsqu'un résolveur DNS détecte un problème avec une zone, l'empêchant de résoudre les noms dans cette zone, il n'avait pas de moyen simple et (...)
RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)
- 8 avril -
Ces deux nouveaux types d'enregistrement DNS, SVCB et sa variante HTTPS, permettent de donner des informations supplémentaires à un client réseau (...)