Aujourd'hui, on va parler routeurs logiciels et OSPF. Les sujets abordés vont être assez variés : mode commit ou pas, configurations de base et résolution d'un problème àlacon.
Table des matières
Commit
Le "mode commit" permet d'appliquer une série de modifications en une seule fois, one-shot : vous tapez des commandes de configuration, elles sont bufferisées. Quand vous avez finis, vous tapez la commande qui va bien (« commit » la plupart du temps, logique 😛 ) et les modifications sont réellement appliquées. C'est pratique pour éviter les bourdes et pour éviter les fluctuations sur le réseau dûes à des modifications successives. La présence d'un mode commit est l'une des différences principales entre Cisco et Juniper.
Bilan de présence de nos jours (je n'ai pas vérifié si chaque implémentation est complète, juste qu'elle existe) :
- Cisco : un mode commit est disponible sur certaines séries comme XR.
- Juniper : disponible partout à ma connaissance.
- Quagga : pas de mode commit ni d'équivalent.
- BIRD : pas de mode commit mais le fonctionnement de BIRD (modification du fichier de config, reload/configure) permet de simuler un début de mode commit.
- XORP : un mode commit est disponible.
Appliquons à un cas concret : on a un réseau interne avec de l'OSPF (ou ISIS) qui tourne. On veut changer le poids sur plusieurs liens d'un même routeur. Pour les besoins d'une expérience de recherche, on a besoin que toutes les modifications soient faites en une seule fois et que le routeur en question n'émette qu'un seul LSA Update (ce point est fondamental). Quelles implémentations de routeur purement logiciel sont compatibles ?
- XORP : malgré son mode commit, XORP émet autant de LSA Update que de liens dont le poids a changé pour refléter les changements.
- BIRD : on modifie le poids des interfaces dans le fichier de configuration, on reload BIRD et ça juste marche : un seul LSA Update émis.
Configurations OSPF basiques pour les routeurs logiciels
Quand on veut une configuration minimale pour faire de l'OSPF juste pour tester deux-trois trucs, on trouve de tout sur le web et pas que des configurations allégées (authentification OSPF, tuning des différents timers, identification dans la CLI, ...). Mention spéciale aux développeurs de XORP et à ceux de BIRD qui fournissent des exemples minimalistes dans leur documentation.
Voici quelques configs de base qui juste fonctionnent. Une machine, deux interfaces eth0-198.18.0.2/30 eth1-198.18.0.5/30, une seule aire OSPF, pas de sécurité.
Quagga
ospfd.conf :
hostname ospfd
line vty
no login
log syslog warnings
router ospf
router-id 198.18.0.2
network 198.18.0.0/16 area 0
|
zebra.conf :
hostname Router line vty no login log syslog warnings |
BIRD
router id 198.18.0.2;
log syslog {warning, error, fatal};
protocol kernel {
scan time 20;
export all;
import all;
}
protocol device {
scan time 10;
}
protocol ospf {
import all;
export all;
area 0 {
interface "eth0", "eth1";
};
}
|
XORP
interfaces {
interface eth0 {
default-system-config
}
interface eth1 {
default-system-config
}
}
protocols {
ospf4 {
router-id: 198.18.0.2
area 0.0.0.0 {
interface eth0 {
vif eth0 {
address 198.18.0.2 {
}
}
}
interface eth1 {
vif eth1 {
address 198.18.0.5 {
}
}
}
}
}
}
|
Interopérabilité des implémentations de routeurs logiciels
Un petit mot sur l'interopérabilité des routeurs logiciels en ce qui concerne OSPF :
- Quagga-BIRD : OK
- Quagga-XORP : OK
- BIRD-XORP : OK sauf avec des liens point-to-point. J'ai essayé plusieurs configurations sans obtenir de résultat. Mais l'erreur est sans doute de mon côté : j'ai encore un peu de mal avec XORP. Sans liens ptp, j'ai aussi observé des comportements étranges : BIRD/XORP boucle sur "DB Description" ou une avalanche continue de LSA Request/Update/Ack. Un petit restart des routeurs et ça part correctement.
Un problème bien lourd
J'ai une maquette de test bateau :
R1-eth0:198.18.0.1/30-----eth0:198.18.0.2/30-R2-eth1:198.18.0.5/30-----eth0:198.18.0.6/30-R3 |
R1 et R3 pourraient être des routeurs de bordure du réseau (BGP, tout ça) et R2 l'un des routeurs interne du réseau.
Si je mets que du Quagga sur les trois routeurs, ça juste marche.
Si je mets que du BIRD, ça juste marche.
Si je mets que du XORP, ça juste marche.
Si je mets du XORP et du Quagga (que ce soit Quagga ou XORP sur R2 et l'inverse ailleurs), ça marche.
Si je mets du BIRD et du Quagga ou du XORP : ça ne marche pas.
« Ça ne marche pas » = les routeurs communiquent entre eux, s'échangent des LSA Update mais le préfixe n'apparaît pas dans la table de routage de R1 ni dans celle de R3.
Les Hello-interval (délai entre deux messages Hello) et les Dead-interval (si je ne reçois pas de Hello, en combien de temps je considère que mon pair est mort), qui doivent être les mêmes pour tous les routeurs d'un même réseau et qui sont définis, dans les implémentations, à 10 secondes et 40 secondes respectivement pour un réseau local (RFC 2328, annexe C3, page 223) ne sont pas en cause : les routeurs communiquent et échangent des LSA Update.
Je vous passe les différentes hypothèses que j'ai émis et les différents tests que j'ai fait pour les invalider une par une, pour en arriver à la conclusion : /30 et /31 sont des subnet d'interconnexion : il ne peut y avoir que deux machines tout au plus. Il faut donc le préciser aux routeurs logiciels (pas que à BIRD mais bien aux deux extrémités !). Cela se fait avec les directives suivantes :
Quagga (ospfd.conf) :
interface eth0 ip ospf network point-to-point interface eth1 ip ospf network point-to-point |
BIRD :
interface "eth0", "eth1" {
type ptp;
};
|
Je ne sais pas pourquoi cela fonctionne quand on utilise le même logiciel sur tous les nœuds ou quand on utilise Quagga et XORP ... J'imagine que BIRD fait un traitement plus strict ...
Ça saute aux yeux quand on n'est pas plongé dans ses configs, c'est une erreur de débutant mais si ça peut servir à d'autres ...