Routeurs

Routeurs#

Trois niveaux de routage entourent le cluster, du plus proche des hyperviseurs au plus proche de l’extérieur. Tous préexistent à l’agent : celui-ci ne les configure pas et n’en a aucune connaissance.

Routeurs de cluster

raccordent les hyperviseurs entre eux. C’est le niveau dont dépend directement le plan de données VXLAN.

Routeurs de datacentre

agrègent les clusters d’un même site.

Routeurs de bordure

terminent le routage vers l’extérieur.

Routeur de cluster#

Le routeur de cluster est la passerelle des hyperviseurs et le voisin eBGP du route reflector, dont il apprend la loopback : c’est par lui que chaque hyperviseur joint 10.255.255.1 pour ouvrir sa session EVPN (VM route reflector).

Adressage#

Adresse

Interface

Rôle

192.168.14.1/24

interface du segment des hyperviseurs

passerelle par défaut des hyperviseurs et du route reflector

169.254.0.1/28

même interface, adresse secondaire

lien avec le route reflector (169.254.0.3) ; router-id ; le second routeur prend 169.254.0.2

Le MTU minimal du segment, imposé par VXLAN, est donné plus bas.

Configuration de FRR#

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

frr defaults traditional
hostname sw1
log syslog informational
!
ip prefix-list RR-LOOPBACK-IN seq 10 permit 10.255.255.1/32
!
route-map RR-IN permit 10
 match ip address prefix-list RR-LOOPBACK-IN
exit
!
route-map NO-OUT deny 999
exit
!
router bgp 65100
 no bgp default ipv4-unicast
 bgp router-id 169.254.0.1
 neighbor 169.254.0.3 remote-as 65000
 neighbor 169.254.0.3 description rr1
 neighbor 169.254.0.3 bfd
 !
 address-family ipv4 unicast
  neighbor 169.254.0.3 activate
  neighbor 169.254.0.3 route-map RR-IN in
  neighbor 169.254.0.3 route-map NO-OUT out
 exit-address-family
 !
exit
!

Ce qu’elle établit :

  • Route reflector : eBGP de l’AS 65100 vers l’AS 65000, avec BFD, en IPv4 unicast.

  • En entrée, seule la loopback du route reflector est acceptée (RR-IN) ; en sortie, rien n’est annoncé (NO-OUT). Symétrique de RR-LOOPBACK-OUT et NO-IN côté route reflector : chaque côté filtre, aucun ne dépend du filtre de l’autre.

  • Aucune session avec les hyperviseurs : le routeur leur sert de passerelle, pas de voisin BGP.

Le route reflector déclare aussi le second routeur (169.254.0.2). La redondance est l’objet de #54.

Note

Ce qui précède est le contrat du routeur de cluster : adresses, ASN, session, filtres. Sa traduction dans la configuration d’un constructeur n’a pas sa place ici.

Note

À rédiger. Reste à documenter, faute d’éléments de terrain :

  • pour le routeur de cluster : le matériel employé et sa version de référence ; la redondance — deux routeurs, mécanisme de bascule, comportement attendu pendant une bascule (#54) ;

  • pour les routeurs de datacentre et de bordure : tout — équipement, configuration de référence, ce qui est annoncé et filtré à chaque niveau, redondance ;

  • l’ordre de mise en service, et ce qui doit être opérationnel avant de préparer le premier hyperviseur.

Contraintes imposées par le reste du cluster#

Indépendamment des choix d’équipement, deux contraintes viennent de ce que fait l’agent.

Avertissement

MTU — l’agent crée bridges, veth et interfaces VXLAN avec un MTU figé à 1500, et VXLAN ajoute 50 octets d’encapsulation. Les liens entre hyperviseurs doivent donc accepter au moins 1550 octets. Cf. Architecture du cluster.

Avertissement

UDP 4789 doit passer entre hyperviseurs, dans les deux sens : c’est le port des tunnels VXLAN.

Avertissement

L’API de l’agent n’a aucune authentification. Le filtrage réalisé ici est aujourd’hui l’une des rares barrières entre cette API et le reste du réseau : son port ne doit être joignable que depuis le réseau d’administration. Cf. Configuration.