Wie eine EVPN-Fabric weiß, wo Ihr Server ist

Ein klassisches geswitchtes Netzwerk findet einen Server durch Rufen: Es flutet den Frame überallhin, sieht, wer antwortet, und merkt sich den Port. Eine BGP-EVPN-Fabric findet ihn, weil man es ihr sagt. Dieser eine Unterschied erklärt, warum EVPN-Fabrics skalieren, schnell umschalten und sich prüfen lassen, und er lohnt sich zu verstehen, selbst wenn Sie nie selbst eine konfigurieren.

Das Problem mit Flood and Learn

Traditionelles Layer 2 lernt MAC-Adressen aus dem Verkehr. Wenn ein Switch nicht weiß, wo ein Ziel liegt, flutet er den Frame aus jedem Port im VLAN. Spanning Tree blockiert dann genug Verbindungen, damit die Flut nicht endlos kreist, was bedeutet, dass ein guter Teil der Verkabelung, die Sie bezahlt haben, ungenutzt bleibt. Dehnen Sie dieses VLAN über viele Racks, und Sie bekommen große Ausfalldomänen, langsame Konvergenz und ein Netzwerk, das niemand vollständig beschreiben kann, weil sein Zustand in Tabellen lebt, die sich von selbst füllen und leeren.

VXLAN allein löst das Transportproblem: Es verpackt Ethernet-Frames in UDP, damit ein Layer-2-Segment ein geroutetes Underlay mit allen Verbindungen aktiv durchqueren kann. Aber reines VXLAN flutet immer noch, um zu lernen. EVPN ersetzt dieses Lernen durch eine Control Plane.

Was EVPN tatsächlich bekanntgibt

EVPN ist eine Address Family von BGP. Jeder Leaf-Switch, der Server beherbergt, arbeitet als VXLAN Tunnel Endpoint (VTEP) und teilt den anderen Leaves mit, was er weiß, mit einer kleinen Zahl von Routentypen. Drei davon erledigen den größten Teil der Arbeit:

• Typ 2, MAC- und IP-Advertisement. Wenn ein Server seinen ersten Frame oder ARP sendet, lernt das lokale Leaf seine MAC (und in der Regel seine IP) und gibt sie jedem anderen Leaf bekannt, mit der eigenen VTEP-Adresse als Next Hop. Jedes Leaf weiß nun, wo dieser Server ist, ohne eine einzige Flut.
• Typ 3, Inclusive Multicast. Jedes Leaf kündigt an, an welchen Segmenten es teilnimmt. Daraus entsteht die Liste der VTEPs, die Broadcast- und Unknown-Verkehr für jedes Segment erhalten sollen. Mit Ingress Replication erzeugt das sendende Leaf eine Unicast-Kopie für jedes davon, sodass das Underlay überhaupt kein Multicast braucht.
• Typ 5, IP-Präfix. Geroutete Subnetze, zum Beispiel ein Block öffentlicher Adressen hinter einer Kunden-Firewall, werden als Präfixe in ein Tenant-VRF bekanntgegeben.

Route Targets entscheiden, wer was importiert. Die Routen eines Segments tragen sein Route Target, und nur Leaves, die mit diesem Target konfiguriert sind, importieren sie. Hier wird die Isolation der Tenants tatsächlich durchgesetzt, und deshalb verdient die Nummerierung von Segmenten und Route Targets echte Disziplin (mehr dazu weiter unten).

Anycast Gateways: überall derselbe Router

In einer EVPN-Fabric kann jedes Leaf, das ein Segment trägt, dessen Default Gateway sein, mit derselben IP und derselben virtuellen MAC. Der erste Hop eines Servers ist immer der Switch, an dem er angeschlossen ist. Fällt dieses Leaf aus, schaltet das Bond des Servers auf das andere Leaf des Paares um, das bereits auf derselben Gateway-Adresse und MAC antwortet. Am Server ändert sich nichts, kein Gateway-Protokoll muss jemanden wählen, und Workloads können zwischen Racks wandern und ihr Gateway behalten.

Kombiniert mit Leaf-Paaren, die Virtual Port-Channels betreiben, bekommt jeder Host zwei physische Switches hinter einem logischen Bond. Unter NX-OS sieht ein minimales Anycast Gateway so aus:

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

Einen Host aufspüren: die Befehle, die zählen

Wenn etwas nicht dort ankommt, wo es soll, sind das die Befehle, mit denen wir auf Cisco Nexus beginnen, ungefähr in dieser Reihenfolge:

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?

Die Geschichte, die sie erzählen, ist meist kurz. Eine MAC, die auf einem Leaf lokal ist, aber auf den anderen nie in BGP auftaucht, deutet auf das lokale Lernen oder die Segmentkonfiguration. Eine Route, die vorhanden ist, aber nicht importiert wird, deutet auf die Route Targets. Ein VTEP, der in show nve peers fehlt, deutet auf das Underlay. Den Zustand der Fabric so zu lesen ist nur möglich, weil EVPN diesen Zustand in BGP hält, wo er sichtbar und konsistent ist, statt in durch Fluten gelernten Tabellen.

Nummerierung ist eine Sicherheitskontrolle

Jedes Segment braucht einen VXLAN Network Identifier (VNI) und Route Targets, und die Fabric akzeptiert jede Zahl, die Sie eintippen. Zwei Segmente, die versehentlich eine Kennung teilen, werden miteinander verbunden, stillschweigend, und ein vertippter VNI, der zufällig zu einem anderen Segment gehört, sieht auf jedem Bildschirm vollkommen legitim aus.

Die Verteidigung ist eine Regel und eine Maschine, die sie prüft. Wählen Sie eine feste Ableitung, zum Beispiel VNI gleich ein fester Offset plus die lokale VLAN-Nummer, mit Route Targets, die aus dem VNI abgeleitet werden, und prüfen Sie das dann automatisch:

• Lesen Sie die Zuordnung von VLAN zu VNI nach Zeitplan von jedem Leaf.
• Bestätigen Sie, dass jeder Eintrag der Regel gehorcht.
• Bestätigen Sie, dass jedes Leaf, das dieselben Segmente tragen soll, identische Zuordnungen trägt.
• Vergleichen Sie einen Fingerabdruck der gesamten Zuordnung mit einer signierten Referenz in der Versionsverwaltung, damit eine beabsichtigte Änderung eine bewusste neue Signatur mit Autor braucht und eine unbeabsichtigte einen Ingenieur alarmiert.

Genau diese Prüfung führen wir jede Stunde gegen unsere Fabric aus. Sie kostet ein paar Sekunden Lesezugriff und macht aus einer Klasse unsichtbarer Fehler einen Alarm.

Was Sie über Ihre eigene Fabric fragen sollten

• Sind Ihre Gateways Anycast auf jedem Leaf, oder besitzt ein Switch-Paar sie?
• Ist jeder Host dual-homed an ein Leaf-Paar angebunden, oder nur die teuren?
• Hashen gebondete Hosts auf Layer 3 und Layer 4, mit passender Switch-Seite, sodass beide Verbindungen tatsächlich Verkehr tragen?
• Gibt es eine schriftliche Regel für die Nummerierung von VNI und Route Targets, und setzt irgendetwas sie durch?
• Kann ein Ingenieur Ihnen mit Befehlen wie den obigen genau zeigen, wo Ihr Server liegt und wie sein Verkehr das Rack verlässt?

Wenn Sie Ihre Server in einer Fabric haben möchten, die so gebaut und geprüft wird, oder Hilfe beim Lesen Ihrer eigenen brauchen, helfen wir gern.

CTA

Mit einem Ingenieur sprechen

Related

Verwandt: Rechenzentrums-Fabric: EVPN/VXLAN auf Cisco Nexus · Wie wir Dinge ändern: Disziplin bei Netzwerkänderungen · Zu uns wechseln ohne Umnummerierung: Layer-2-Erweiterung