Comment un fabric EVPN sait où se trouve votre serveur

Un réseau commuté classique trouve un serveur en criant : il inonde la trame partout, regarde qui répond, mémorise le port. Un fabric BGP EVPN le trouve parce qu'on le lui dit. Cette seule différence explique pourquoi les fabrics EVPN montent en charge, basculent vite et peuvent être audités, et elle vaut d'être comprise même si vous n'en configurez jamais un vous-même.

Le problème du flood and learn

Le Layer 2 traditionnel apprend les adresses MAC à partir du trafic. Quand un switch ne sait pas où vit une destination, il inonde la trame sur chaque port du VLAN. Le spanning tree bloque ensuite assez de liens pour que l'inondation ne boucle pas indéfiniment, ce qui veut dire qu'une bonne part du câblage que vous avez payé reste inactive. Étendez ce VLAN sur de nombreux racks et vous obtenez de grands domaines de défaillance, une convergence lente et un réseau que personne ne peut décrire entièrement, parce que son état vit dans des tables qui se remplissent et expirent toutes seules.

VXLAN à lui seul résout le problème du transport : il enveloppe les trames Ethernet dans de l'UDP pour qu'un segment Layer 2 puisse traverser un underlay routé avec tous les liens actifs. Mais le VXLAN nu inonde encore pour apprendre. EVPN remplace cet apprentissage par un control plane.

Ce qu'EVPN annonce réellement

EVPN est une address family de BGP. Chaque switch leaf qui héberge des serveurs agit comme VXLAN tunnel endpoint (VTEP) et dit aux autres leaves ce qu'il sait, au moyen d'un petit nombre de types de routes. Trois d'entre eux font l'essentiel du travail :

• Type 2, annonce MAC et IP. Quand un serveur envoie sa première trame ou son premier ARP, le leaf local apprend sa MAC (et généralement son IP) et l'annonce à chaque autre leaf avec sa propre adresse VTEP comme next hop. Chaque leaf sait désormais où est ce serveur sans une seule inondation.
• Type 3, inclusive multicast. Chaque leaf annonce à quels segments il participe. Cela construit la liste des VTEP qui doivent recevoir le trafic broadcast et unknown pour chaque segment. Avec l'ingress replication, le leaf émetteur fait une copie unicast pour chacun d'eux, de sorte que l'underlay n'a besoin d'aucun multicast.
• Type 5, préfixe IP. Les sous-réseaux routés, par exemple un bloc d'adresses publiques derrière le firewall d'un client, sont annoncés comme préfixes dans un VRF de tenant.

Les route targets décident qui importe quoi. Les routes d'un segment portent son route target, et seuls les leaves configurés avec ce target les importent. C'est là que l'isolation des tenants est réellement appliquée, et c'est pourquoi la numérotation des segments et des route targets mérite une vraie discipline (nous y revenons plus bas).

Passerelles anycast : le même routeur partout

Dans un fabric EVPN, chaque leaf qui porte un segment peut en être la passerelle par défaut, avec la même IP et la même MAC virtuelle. Le premier saut d'un serveur est toujours le switch sur lequel il est branché. Si ce leaf tombe, le bond du serveur bascule sur l'autre leaf de la paire, qui répond déjà sur la même adresse de passerelle et la même MAC. Rien ne change sur le serveur, aucun protocole de passerelle n'a à élire qui que ce soit, et les charges de travail peuvent se déplacer entre racks en gardant leur passerelle.

Combiné à des paires de leaves en virtual port-channels, cela donne à chaque hôte deux switches physiques derrière un seul bond logique. Sur NX-OS, une passerelle anycast minimale ressemble à ceci :

fabric forwarding anycast-gateway-mac 0000.2222.3333
interface Vlan210
  vrf member TENANT-A
  ip address 192.0.2.1/26
  fabric forwarding mode anycast-gateway

Tracer un hôte : les commandes qui comptent

Quand quelque chose n'arrive pas là où il devrait, voici les commandes par lesquelles nous commençons sur Cisco Nexus, à peu près dans cet ordre :

show nve peers                         ! are the other VTEPs up?
show nve vni                           ! is the segment up, control plane learning?
show l2route evpn mac all              ! which MACs are local, which are remote, and from which peer
show bgp l2vpn evpn <mac-or-ip>        ! the actual route, its RD, RT and next hop
show ip arp suppression-cache detail   ! is ARP being answered locally?
show vpc consistency-parameters vlans  ! do both leaves of the pair agree?

L'histoire qu'elles racontent est généralement courte. Une MAC locale sur un leaf mais qui n'apparaît jamais dans BGP sur les autres désigne l'apprentissage local ou la configuration du segment. Une route présente mais non importée désigne les route targets. Un VTEP absent de show nve peers désigne l'underlay. Lire l'état du fabric de cette façon n'est possible que parce qu'EVPN garde cet état dans BGP, où il est visible et cohérent, plutôt que dans des tables apprises par inondation.

La numérotation est un contrôle de sécurité

Chaque segment a besoin d'un VXLAN network identifier (VNI) et de route targets, et le fabric acceptera n'importe quel nombre que vous tapez. Deux segments qui partagent accidentellement un identifiant sont pontés l'un à l'autre, en silence, et un VNI mal saisi qui appartient par hasard à un autre segment paraît parfaitement légitime sur chaque écran.

La défense est une règle et une machine qui la vérifie. Choisissez une dérivation fixe, par exemple VNI égale un offset fixe plus le numéro de VLAN local, avec des route targets dérivés du VNI, puis vérifiez-la automatiquement :

• Lisez la table VLAN vers VNI de chaque leaf à intervalle régulier.
• Confirmez que chaque entrée obéit à la règle.
• Confirmez que chaque leaf qui doit porter les mêmes segments porte des tables identiques.
• Comparez une empreinte de la table entière à une référence signée sous gestion de versions, pour qu'un changement voulu exige une re-signature délibérée avec un auteur, et qu'un changement involontaire alerte un ingénieur.

Nous exécutons exactement cette vérification sur notre fabric toutes les heures. Elle coûte quelques secondes d'accès en lecture seule et transforme une classe d'erreurs invisibles en alarme.

Ce qu'il faut demander à propos de votre propre fabric

• Vos passerelles sont-elles anycast sur chaque leaf, ou une seule paire de switches les possède-t-elle ?
• Chaque hôte est-il raccordé en double à une paire de leaves, ou seulement les plus coûteux ?
• Les hôtes en bond hashent-ils sur les couches 3 et 4, avec le côté switch assorti, pour que les deux liens portent réellement du trafic ?
• Existe-t-il une règle écrite pour la numérotation des VNI et des route targets, et quelque chose la fait-il respecter ?
• Un ingénieur peut-il vous montrer, avec des commandes comme celles ci-dessus, exactement où vit votre serveur et comment son trafic quitte le rack ?

Si vous voulez vos serveurs sur un fabric construit et vérifié de cette façon, ou si vous voulez de l'aide pour lire le vôtre, nous serons heureux de vous aider.

CTA

Parler à un ingénieur

Related

Sur le même sujet : Fabric du datacenter : EVPN/VXLAN sur Cisco Nexus · Comment nous changeons les choses : la discipline de changement réseau · Venir chez nous sans changer d'adresses : l'extension Layer 2