Die EVPN-Grenze um die Exportrichtlinie bauen, nicht um die Anbindungen
Zuerst die übergreifenden Routen und die ASN-Beziehung festlegen. Die Layer-2-Anbindung folgt dann aus einer Anforderung, und jeder Tenant erhält nur den Export, den er braucht.
Die übliche Annahme ist, dass das Layer-2-Anbindungsmodell an der Grenze alles darüber bestimmt, also beginnt das Design mit einem vPC-Paar und arbeitet sich nach oben. Meist endet es mit Routing-Entscheidungen, die zufällig getroffen werden. Eine EVPN-Grenze ist zuerst eine Routing-Grenze: ein Tenant-Routing-Kontext trifft auf eine externe Routing-Domäne, und was diese Linie überquert, ist eine Richtlinienaussage. Wählen Sie die Routen, die ASN-Beziehung und die Fehlerpfade, bevor jemand über Port-Channels streitet. Das Anbindungsmodell folgt dann aus einer Anforderung, statt eine vorzugeben.
Beginnen Sie mit dem, was die Grenze überquert
Schreiben Sie die Routen auf, die auf jeder Seite sichtbar sein sollen, die Richtung, in die sie laufen, und wer eine Änderung dieser Liste genehmigt. Eine Grenze, die alles annimmt und alles ankündigt, hat keine Richtlinie, nur ein Kabel.
Benennen Sie dann den Fehler, den Sie betreiben wollen: ein Uplink ausgefallen, ein Border-Leaf ausgefallen oder die gesamte externe Domäne nicht erreichbar. Jede Antwort ändert, ob Sie zwei unabhängige Nachbarn, eine gemeinsame Layer-2-Anbindung oder beides brauchen.
Erst wenn diese beiden Listen existieren, ist die Anbindungsfrage beantwortbar. Davor wirkt jeder Mechanismus gleich gültig. Danach schließen sich die meisten selbst aus. Das ist das ganze Argument dafür, die Routing-Arbeit zuerst zu machen.
ASN- und Peering-Grenze festlegen
Ein Fabric mit privaten AS peeret üblicherweise über eBGP mit der öffentlichen Grenzdomäne, und der interessante Teil ist die Richtlinie auf beiden Seiten. Legen Sie fest, welche Präfixe akzeptiert, welche angekündigt werden und welchen AS Path der Upstream erhalten soll.
RFC 6996 reserviert einen ASN-Bereich für den privaten Gebrauch, und diese ASN sollen nicht in globalen Ankündigungen erscheinen. Wenden Sie die von der Plattform unterstützte Entfernungs- oder Filterrichtlinie an und prüfen Sie die resultierende Ankündigung, statt anzunehmen, das Gerät habe es erledigt. Dieser Schritt gibt Ihnen auch nicht die Befugnis, ein beliebiges öffentliches Präfix anzukündigen, das ist ein separates Gespräch mit dem Adressinhaber.
Eine Konföderation oder ein local-AS-Feature ist eine Designentscheidung für eine bestimmte Topologie. Nichts davon ist obligatorisch, nur weil Fabric und Upstream unterschiedliche ASN-Rollen verwenden, und eines ohne die Anforderung zu übernehmen, fügt jeder künftigen Änderung bewegliche Teile hinzu.
Layer-3-Uplinks brauchen kein Multichassis-LAG
Unabhängige geroutete Schnittstellen mit eigenen BGP-Nachbarn ergeben zwei klare Pfade und zwei klare Fehlerdomänen. vPC oder ein anderes Multichassis-LAG dient einer Layer-2-Anbindungsanforderung und ist das richtige Werkzeug, wenn diese Anforderung besteht.
Eine pauschale Regel, dass jedes Grenzpaar vPC verwenden muss oder es vermeiden muss, verdeckt die Bedingungen, die den Fall tatsächlich entscheiden. Fragen Sie, was die Anbindung tragen muss, und wählen Sie dann den Mechanismus, der es mit den wenigsten gemeinsamen Fehlermodi trägt.
Die Routing-Richtlinie, die Sie zuerst geschrieben haben, ändert sich nicht, wenn sich der Anbindungsmechanismus ändert, was ein gutes Zeichen dafür ist, dass die Reihenfolge richtig war.
Exportieren Sie nur, was der Tenant braucht
Ein Tenant braucht vielleicht eine Default-Route, eine Auswahl externer Präfixe oder eine viel größere Tabelle. Wählen Sie diesen Umfang anhand realer Weiterleitungs- und Control-Plane-Kapazität, nicht anhand einer alten Zahl von Internet-Routen, die niemand neu gemessen hat.
Die EVPN IP Prefix-Route, üblicherweise Type 5 genannt und definiert in RFC 9136, trägt Präfixinformationen im Overlay. Die Implementierung braucht weiterhin passende Export- und Importrichtlinien plus Next-Hop-Auflösung, sodass der Empfang einer externen BGP-Route an der Grenze nicht bedeutet, dass jedes Tenant-VRF sie importiert.
Nicht jedes Leaf braucht die vollständige Tabelle, nur weil die Grenze sie hält. Verteilen Sie, was der Traffic des Tenants benötigt, und lassen Sie die Grenze den Rest besitzen.
Ein Präfix durchgängig prüfen
Wählen Sie ein repräsentatives externes Präfix und verfolgen Sie es durch das vorgesehene VRF der Grenze, die Exportrichtlinie, den Weiterleitungskontext des empfangenden Leaf und den Rückweg zu einer Tenant-Quelle. Ein Präfix, das an einer Stelle erscheint und an der nächsten nicht, lokalisiert den Fehler sofort.
Bestätigen Sie, wie der Next Hop über das Overlay aufgelöst wird, denn eine Route, die mit unaufgelöstem Next Hop vorhanden ist, leitet nichts weiter. Wiederholen Sie die Prüfung dann nach einer Uplink-Änderung, denn dann weichen Richtlinie und Next-Hop-Auflösung am häufigsten voneinander ab.
Reihenfolge der Arbeit: die übergreifenden Routen auflisten, die ASN-Richtlinie abstimmen, die Anbindung für ihre tatsächliche Aufgabe wählen, den Export je Tenant abgrenzen und dann ein Präfix und seinen Rückweg prüfen.