Lorsqu'on configure une machine connectée à l'Internet, on indique
le routeur par défaut qu'elle doit
utiliser. Que faire s'il tombe en panne ? Utiliser
VRRP, le protocole que normalise notre RFC, qui
permet à plusieurs routeurs de se surveiller mutuellement, et de se
remplacer en cas de défaillance.
Prenons par exemple une machine Unix. Sa
table de routage va être :
% netstat -r -n
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 wlan0
Ici, 10.0.0.1 est le routeur par défaut (on utilise
parfois l'ancien terme, incorrect, de passerelle par défaut). Que se
passe t-il s'il tombe en panne ? La machine n'a plus accès qu'à une
petite portion de l'Internet, son réseau local (ici
10.0.0.0/24) et ceux pour lesquels
il existe une route via un autre routeur. En
IPv6, des mécanismes comme la découverte de
voisin () peuvent aider à trouver un
autre routeur, s'il existe, mais les délais sont souvent trop
élevés.
C'est évidemment inacceptable lorsqu'on veut pouvoir compter sur
son accès Internet. D'où le protocole VRRP,
normalisé à l'origine dans le , puis dans le . Cette ancienne
version était spécifique à IPv4 et notre est la première version de VRRP à être commune à IPv4 et
IPv6. Elle porte le numéro 3. (Bien à tort, je trouve, le RFC parle de « IPvX » lorsqu'il veut
désigner les deux familles, au lieu de simplement dire « IP ».)
La section 1 du RFC commence par introduire le problème et par
expliquer quelles sont les solutions possibles, avant VRRP. Ainsi
(section 1.2), en IPv4, les méthodes classiques étaient de faire
tourner un protocole de routage comme RIP () en mode « écoute seule », où la machine reçoit les mises
à jour de route, pour en déduire les routeurs possibles, mais n'en
envoie pas elle même. C'est ainsi que, à une époque lointaine, toutes
les machines Unix en réseau faisaient tourner le programme de routage
routed. L'utilisation d'un protocole de routage
par des machines non-routeuses a entraîné tellement de mauvaise
surprises que cette méthode n'est plus recommandée.
Il reste donc la découverte de routeur par le biais de messages
ICMP (), jamais réellement
déployée, ou bien les routes statiques, mises à la main ou via
DHCP. Cette solution a l'inconvénient de
l'absence de résistance aux pannes. Si le routeur par défaut s'arrête,
il n'y a pas de mécanisme de bascule automatique.
En IPv6 (section 1.3), il y a une possibilité supplémentaire, le
protocole de découverte de voisin du
qui permet, via la fonction Neighbor Unreachability
Detection (section 7.3 du ) de s'apercevoir qu'un routeur est en panne et d'en
chercher un autre. Avec les paramètres par défaut de la découverte de
voisin, un tel changement prend environ 40 secondes, ce qui est trop
pour la plupart des applications.
La section 1.6 décrit le vocabulaire de VRRP. Notons qu'un
« routeur VRRP » est un routeur qui parle le protocole VRRP mais qu'un
« routeur virtuel » est l'ensemble des routeurs (un maître et
plusieurs remplaçants) qui contribuent au fonctionnement continu d'une
adresse IP vers laquelle pointent les routes.
La section 2 est un résumé du cahier des charges de VRRP : service
continu pour une adresse IP, avec minimisation du temps de bascule
vers un autre routeur physique, possibilité d'exprimer une préférence
entre les différents routeurs physiques d'un même routeur virtuel,
minimiser les bascules inutiles (par exemple lorsqu'un ancien maître
redémarre), fonctionnement sur un réseau local coupé par des
ponts qui doivent apprendre l'adresse
MAC (section 2.4, qui
détaille ce problème), etc. VRRP fonctionne sur tout type de
réseau local mais, en pratique, est surtout utilisé sur
Ethernet (l'annexe A décrit les spécificités
des autres protocole comme le Token Ring).
La section 3 donne une vision générale du protocole VRRP. C'est
donc un protocole d'élection. Les routeurs
physiques communiquent par la diffusion
restreinte sur le réseau local. Pour chaque routeur
virtuel, identifié par un nombre nomé VRID (virtual router identifier), un maître est élu, et il
sera le seul à router. Les routes des machines non-routeuses
pointeront vers le routeur virtuel (cf. section 4.1 pour un schéma). Si on veut faire de la répartition de charge,
il faut plusieurs routeurs virtuels, avec des VRID différents,
cf. section 4.2 pour un bon exemple. Chaque
routeur virtuel a une adresse MAC (il n'y a donc pas de problème avec
les caches ARP).
Le maître diffuse périodiquement des messages VRRP
advertisement. Si le maître n'en envoie plus, un remplaçant
le... remplace, avec la même adresse IP (celle du routeur virtuel) et
la même adresse MAC.
Le protocole est normalisé en section 5. Le format des paquets est
en section 5.1 et 5.2. À noter :
L'adresse IPv4 de destination des paquets de diffusion est
224.0.0.18 et la IPv6 est
FF02:0:0:0:0:0:0:12.Le TTL des paquets doit être à 255 (cf
. ).VRRP n'utilise pas un des protocoles de transport classiques
comme UDP, il a son propre protocole, numéroté
112.Le VRID est sur huit bits et il n'existe pas de mécanisme pour
son allocation sur un réseau local, c'est à l'administrateur réseau de
s'assurer de son unicité.
La section 6 est consacréee à la machine à
états du protocole. Dans l'état d'attente
(Backup, section 6.4.2), le routeur VRRP écoute
passivement les annonces du maître et ne répond
pas aux requêtes ARP ou ND pour l'adresse IP du
routeur virtuel, et ignore les paquets envoyés à cette adresse. Si le
maître n'envoie plus d'annonces (par défaut, c'est après trois
annonces non reçues), le routeur
passe dans l'état Maître.
Inversement, le routeur dans l'état Maître (section 6.4.3), répond
aux requêtes ARP et ND pour l'adresse IP du routeur virtuel, traite
les paquets destinés à cette adresse, route les paquets qu'il reçoit
et envoie des annonces périodiques pour manifester qu'il est toujours
en service.
La section 7 décrit de manière très détaillée ce que doit faire un
routeur VRRP lorsqu'il reçoit ou émet les paquets VRRP. C'est là
qu'est spécifié le fait qu'un routeur maître doit utiliser l'adresse
MAC du routeur virtuel (et non pas celle du routeur physique)
lorsqu'il envoie les annonces de bon fonctionnement. C'est pour
permettre aux ponts et
commutateurs de trouver le routeur
physique. Cette adresse MAC est calculée (sections 7.3 et 12) et vaut
00-00-5E-00-01-{VRID} en IPv4 et
00-00-5E-00-02-{VRID} en IPv6.
Comme souvent sur un réseau, le diable est dans les détails
pratiques. Ils font l'objet de la section 8. Ainsi, la section 8.1.2
rappelle que, puisque le maître utilise toujours comme adresse MAC
celle du routeur virtuel présentée au paragraphe précédent, le client
ne peut pas découvrir qu'un routeur physique en a remplacé un autre.
Parmi ces problèmes opérationnels, celui de la sécurité a droit à
une section entière, la 9. En gros, VRRP n'a aucune sécurité. Les
versions précédentes avaient tenté de mettre en place quelques
mécanismes mais ils n'ont eu aucun succès et notre version 3 de VRRP
les supprime. Notons que le problème n'est pas créé par VRRP : sur le
réseau local, un méchant a énormément de moyens de perturber bien des
protocoles indispensables, à commencer par DHCP
et ARP. Par exemple, le méchant peut toujours
répondre aux requêtes ARP pour l'adresse IP du routeur et lui voler
ainsi le trafic. VRRP, où le méchant peut se faire désigner comme
maître, n'aggrave donc pas tellement la situation.
VRRP a toujours souffert d'une polémique récurrente sur un
brevet que détient
Cisco et qui est apparemment effectivement
appliqué (des développeurs VRRP ou bien de protocoles similaires ont,
semble t-il, reçu des menaces des avocats de Cisco). L'existence de ce
brevet n'est pas en soi contraire à la politique de
l'IETF. En effet, celle-ci accepte des
protocoles brevetés (il est difficile de faire autrement, compte-tenu
du membre, et du caractère ridiculement futile, de la grande majorité
des brevets logiciels) et demande juste que les prétentions
soient publiques, ce qui est le cas ici. D'innombrables messages, souvent courroucés,
ont été échangé sur les listes IETF au sujet de ce brevet. Cette situation a mené les développeurs
d'OpenBSD à développer un protocole concurrent,
CARP. On peut lire un point de vue (très
outrancier) sur cette polémique dans l'interview de Ryan
McBride. La réalité est plus complexe : les développeurs
d'OpenBSD ont adopté une attitude d'affrontement immédiatement (« comme
souvent », disent ceux qui connaissent les gens d'OpenBSD) et la
bureaucratie IETF n'a pas fait preuve de bonne volonté et a réagi par un blocage complet. Aujourd'hui, les
positions semblent hélas figées, au point que CARP, n'ayant pas eu de
numéro de protocole officiel (en raison de leur refus de se plier aux
procédures IANA, procédures d'ailleurs
incorrectement décrites par McBride), a tout simplement pris celui de
VRRP. Sur un réseau local, si on voit des paquets du protocole 112, il
peut donc s'agir de CARP ou bien de VRRP.
En raison du brevet Cisco sur HSRP (le
précurseur de VRRP), brevet dont la licence n'est apparemment
disponible que selon les conditions RAND (bien
insuffisantes pour du logiciel libre), il n'est
pas évident de faire une mise en œuvre libre de VRRP. Il existe
toutefois vrrpd et keepalived (aucun des deux ne semble intégrer IPv6).
La configuration de VRRP sur un routeur
Juniper est documentée en Configuring
VRRP and VRRP for IPv6 et Configure
Basic VRRP Support. Cela donne, par exemple :
address 192.0.2.0/25 {
vrrp-group 12 {
virtual-address 192.0.2.65;
priority 80;
}
Notez que vrrp-group est un terme purement
Juniper, c'est ce que le RFC appelle VRID (ici 12). Quant au concept de
priorité (ici 80, donc moins que la priorité par défaut), il est
décrit en
section 5.2.4. Avec vrrpd, la même configuration
serait :
ip address 192.0.2.2 255.255.255.128
vrrp 12 ip 192.0.2.1
vrrp 12 priority 80