Warum ein EVPN-Tenant mehrere Route Distinguisher zeigen kann
Zwei RDs in einem Tenant sind kein Konflikt. Gehen Sie von der CLI-Ausgabe zum MAC-VRF oder IP-VRF, der die Route erzeugt hat, und prüfen Sie dann RT-Import und VNI.
Sie filtern die EVPN-Tabelle für einen Tenant, und die Routen tragen zwei verschiedene Route Distinguisher. Der erste Reflex ist ein Konfigurationskonflikt, und dieser Reflex ist meist falsch. Ein Tenant-Name ist ein Geschäftslabel, kein einzelnes Objekt der Steuerungsebene, daher dürfen der Bridging-Kontext und der Routing-Kontext darin unter getrennten Kennungen annoncieren. Gehen Sie jeweils eine Route von der Ausgabe zurück zum lokalen Dienstobjekt, das sie erzeugt hat, und der zweite RD hört auf, wie ein Fehler auszusehen.
Beginnen Sie bei der Ausgabe, die Sie verwirrt hat
Wählen Sie eine Route statt der ganzen Tabelle. Notieren Sie ihren Routentyp, ihren RD, ihre exportierten Route Targets und den nächsten Hop. Diese vier Felder genügen, um festzustellen, welches lokale Objekt sie annonciert hat und welche entfernte Policy sie importieren sollte.
Auf einem Gerät im NX-OS-Stil erreicht man die Detailansicht mit show bgp l2vpn evpn route-type 2 detail oder show bgp l2vpn evpn route-type 5 detail. Auf Junos stehen dieselben Informationen in show route table bgp.evpn.0 detail. Andere Syntax, dieselben Felder.
Beginnen Sie nicht damit, jede angezeigte Zahl gleich zu machen. RDs gleichzusetzen ist die Änderung, die die Import-Policy auf einem funktionierenden Fabric bricht.
Geben Sie jeder Kennung ihre Aufgabe
| Identifier | Question it answers | Where it is used |
|---|---|---|
| Route distinguisher | Which distinct route context contributed this advertisement? | Makes otherwise identical prefixes unique in BGP |
| Route target | Which importing service policy should receive the route? | Extended community matched by import policy |
| VNI | Which VXLAN service context carries the traffic? | Data plane encapsulation and mapping |
Ein MAC-VRF hält MAC-Weiterleitungsinformationen für einen Bridging-Dienst. Ein IP-VRF liefert einen IP-Routing-Kontext für einen gerouteten Dienst. Ein Tenant kann beides enthalten, deshalb kann ein Tenant mehr als einen RD erzeugen, ohne dass eine Fehlkonfiguration vorliegt.
RFC 7432 weist dem annoncierenden MAC-VRF dessen RD für seine EVPN NLRI zu und verlangt unterschiedliche RDs über MAC-VRFs auf demselben PE. Route-Target-Verfahren sind getrennt: Sie erlauben ein oder mehrere RT-Attribute und stützen sich für die Zugehörigkeit auf die Import-Policy. RD-Gleichheit ist nicht das, was gemeinsame Zugehörigkeit erzeugt, und genau diese Annahme ist die Wurzel der Verwirrung.
Gehen Sie eine Route von der Ankündigung bis zum Import
Folgen Sie der Route in eine Richtung. Bestätigen Sie Routentyp, den erzeugenden Dienst, den RD, die exportierten RTs und dann die Import-Policy auf dem empfangenden PE. Jeder Schritt beantwortet eine andere Frage, und ein Fehler an irgendeinem Schritt sieht wie dasselbe fehlende Präfix auf der Gegenseite aus.
Sobald die Route vorhanden ist, prüfen Sie den installierten Weiterleitungskontext und das VNI-Mapping. Ein übereinstimmender VNI an beiden Enden belegt, dass die Datenebene übereinstimmt; er belegt nicht, dass die Steuerungsebene die Route über die vorgesehene Policy importiert hat.
Erscheint die Route auf dem entfernten PE, fließt aber kein Verkehr, hat sich das Problem über EVPN hinaus verschoben. Prüfen Sie die VNI-zu-VLAN- oder VNI-zu-VRF-Bindung und den Underlay-Pfad, bevor Sie erneut Route Targets bearbeiten. Beginnen Sie beim Mapping, dann beim Underlay und erst dann bei der Steuerungsebene. Eine Route-Target-Änderung zurückzunehmen, um einem Datenebenenfehler nachzujagen, ist ein zuverlässiger Weg, einen funktionierenden Import zu brechen.
Layer-3-Präfixe sind weiterhin EVPN-Routen
Ein IP-Präfix in der EVPN-Tabelle ist kein gewöhnliches IPv4-unicast-BGP. Die EVPN IP Prefix-Route ist ein eigener Routentyp, und MAC/IP- sowie IP-Präfix-Ankündigungen laufen in der EVPN-Adressfamilie, die RFC 7432 als AFI 25 und SAFI 70 bezeichnet.
Dieser Unterschied zählt, wenn Sie eine Route aus der EVPN-Tabelle mit einer aus der Unicast-Tabelle vergleichen. Sie können dasselbe Ziel beschreiben und dennoch von unterschiedlicher Policy erzeugt, gefiltert und importiert werden. Eine als Beweis für die andere zu lesen, lässt ein korrektes Fabric während einer Migration kaputt aussehen.
Prüfen Sie die Ableitung des Herstellers, bevor Sie Zahlen vergleichen
RFC 9136 erweitert EVPN um IP Prefix-Routen und legt fest, ob der geltende RD aus dem MAC-VRF- oder dem IP-VRF-Kontext stammt. Deshalb sollte ein L2-Dienstlabel und ein Label eines gerouteten Dienstes in derselben Ausgabe gegen die Objekte gelesen werden, zu denen sie gehören, und nicht auf einen RD pro Tenant reduziert werden.
Die automatische Ableitung von RD und RT ist herstellerspezifisch. Lesen Sie die Referenz des eingesetzten Herstellers für die verwendete Formel; ein automatisch erzeugter Wert auf einem Switch ist keine universelle Kodierung, und der Vergleich zweier Herstellerzahlen beweist selten etwas.
Schließen Sie mit einer schriftlichen Spur für die Route, mit der Sie begonnen haben: Typ, erzeugendes Objekt, RD, exportierter RT, Import-Policy, installierter VNI. Sechs Felder erklären die Ankündigung jedem, der das Ticket als Nächstes liest, und keines davon verlangt, dass die Zahlen des Tenants übereinstimmen.