VM route reflector

VM route reflector#

Le route reflector est le point de rendez-vous du plan de contrôle : plutôt que de maintenir une session entre chaque paire d’hyperviseurs, chaque hyperviseur ouvre une session vers le route reflector, qui redistribue.

Il tourne lui-même en machine virtuelle, ce qui crée une dépendance circulaire à traiter explicitement : la VM qui porte le plan de contrôle du cluster est hébergée par le cluster.

Adressage#

Le route reflector est sur le même segment L2 que les hyperviseurs, avec trois adresses :

Adresse

Interface

Rôle

une adresse de 192.168.14.0/24

interface principale

celle de n’importe quelle machine du segment ; les réponses aux hyperviseurs en partent

169.254.0.3/28

interface principale, adresse secondaire

le lien avec les routeurs de cluster (169.254.0.1 et .2), sur le même L2

10.255.255.1/32

lo1, interface dummy

router-id, cluster-id et source des sessions EVPN ; seule route annoncée aux routeurs

Les hyperviseurs ne connaissent que la loopback : ils ouvrent leur session vers 10.255.255.1 par leur passerelle (192.168.14.1), les routeurs l’ayant apprise du route reflector en eBGP. Aucune adresse d’hyperviseur n’est déclarée côté route reflector : il accepte toute session venant du segment (bgp listen range).

L’adresse du lien est une adresse secondaire de l’interface principale, pas une interface à part : même L2, même MAC sur le fil, une interface de moins qu’avec un ipvlan. Elle doit survivre aux renouvellements DHCP de l’adresse principale : la déclarer dans la configuration réseau du système, pas la poser à la main.

Note

Non vérifié sur l’image de production. Avec NetworkManager, la forme attendue est :

nmcli connection modify <connexion> +ipv4.addresses 169.254.0.3/28
nmcli connection add type dummy ifname lo1 con-name lo1 \
    ipv4.method manual ipv4.addresses 10.255.255.1/32 ipv6.method disabled

Ces commandes restent à valider sur l’image golden.

Configuration de FRR#

bgpd et bfdd activés dans /etc/frr/daemons.

frr defaults traditional
hostname rr1
log syslog informational
!
ip prefix-list RR-LOOPBACK-OUT seq 10 permit 10.255.255.1/32
!
route-map NO-IN deny 999
 description deny
exit
!
router bgp 65000
 no bgp default ipv4-unicast
 bgp router-id 10.255.255.1
 bgp cluster-id 10.255.255.1
 neighbor CLUSTER peer-group
 neighbor CLUSTER remote-as 65100
 neighbor CLUSTER bfd
 neighbor 169.254.0.1 peer-group CLUSTER
 neighbor 169.254.0.1 description router-1
 neighbor 169.254.0.2 peer-group CLUSTER
 neighbor 169.254.0.2 description router-2
 neighbor fabric peer-group
 neighbor fabric remote-as 64600
 neighbor fabric local-as 64600 no-prepend replace-as
 neighbor fabric capability extended-nexthop
 neighbor fabric update-source 10.255.255.1
 bgp listen range 192.168.14.0/24 peer-group fabric
 bgp listen limit 200
 !
 address-family ipv4 unicast
  network 10.255.255.1/32
  neighbor CLUSTER activate
  neighbor CLUSTER prefix-list RR-LOOPBACK-OUT out
  neighbor CLUSTER route-map NO-IN in
 exit-address-family
 !
 address-family l2vpn evpn
  neighbor fabric activate
  neighbor fabric route-reflector-client
 exit-address-family
 !
exit
!

Ce qu’elle établit :

  • Routeurs de cluster (groupe CLUSTER) : eBGP vers l’AS 65100, avec BFD, en IPv4 unicast. Le route reflector n’annonce que sa loopback (RR-LOOPBACK-OUT) et n’accepte rien (NO-IN) : il ne reçoit aucune route des routeurs.

  • Hyperviseurs (groupe fabric) : voisins dynamiques, toute session venant de 192.168.14.0/24 étant acceptée, jusqu’à 200. local-as 64600 no-prepend replace-as fait que, du point de vue des hyperviseurs, la session est en iBGP dans l’AS 64600 — celui de leur configuration — alors que le route reflector est en AS 65000 face aux routeurs.

  • EVPN : seule famille activée vers les hyperviseurs, qui sont ses clients (route-reflector-client) : il réfléchit les routes EVPN de chacun vers tous les autres.

Avertissement

Les tunnels ne survivent pas à la perte du route reflector. Avec un seul route reflector et sans graceful-restart, à l’arrêt de FRR sur le route reflector, la session EVPN des hyperviseurs tombe aussitôt, FRR retire les routes apprises et, avec elles, le VTEP distant et l’entrée d’inondation du VXLAN — plus aucun paquet ne passe entre hyperviseurs, à 30 s comme à 90 s. Au redémarrage de FRR sur le route reflector, VTEP distant et trafic reviennent 31 s plus tard. Le trafic entre VM d’un même hyperviseur n’est pas concerné. La redondance (deux route reflectors) ou graceful-restart sont les deux leviers ; ni l’un ni l’autre n’est encore qualifié.

Note

À rédiger. Reste à documenter :

  • la création de la VM : ressources, subnet et mode utilisés (bridge, pour pouvoir la lancer sur n’importe quel hyperviseur), et s’il s’agit d’une VM créée par l’agent comme les autres ou d’un cas particulier — l’image, elle, est l’image golden de Construction de l’image qcow2 ;

  • la redondance : une seule VM route reflector, ou deux, et sur quels hyperviseurs ;

  • la procédure de reconstruction — l’état du cluster pendant l’absence du route reflector est décrit ci-dessus : plus de trafic entre hyperviseurs ;

  • la procédure d’amorçage : ce qui fonctionne, et dans quel ordre, quand on démarre un cluster entier depuis zéro — le premier hyperviseur n’a pas de session FRR établie tant que cette VM n’existe pas, cf. Premier hyperviseur.

Points de vigilance#

Avertissement

L’agent ne réattache pas les VM existantes à son démarrage, et les processus QEMU ne survivent pas à un redémarrage de l’hyperviseur. Le redémarrage de l’hyperviseur qui héberge le route reflector est donc un événement à part entière : la procédure de remise en service doit être écrite, et testée.

Avertissement

instance-id valant le nom de la VM, recréer la VM route reflector sous le même nom sur le même disque fait que cloud-init ne rejoue pas le user-data. Cf. Metadata et cloud-init.