EVPN-Firewall-Policy: zentrales Gateway kontra verteiltes IRB

Zwei EVPN-Designs platzieren das Mandanten-Gateway an unterschiedlichen Stellen, und die Firewall sieht in jedem Fall anderen Verkehr. Bei einem zentralen Gateway erreicht Verkehr zwischen Subnetzen die Firewall, weil dort geroutet wird. Bei verteiltem IRB routen die Leaf-Switches lokal, und die Firewall sieht nichts, sofern Sie sie nicht bewusst einfügen. Keines der Modelle ist falsch. Falsch ist, eine Firewall an der Grenze anzuhängen und anzunehmen, das Fabric liefere den Verkehr dorthin.

Zwei Modelle, zwei verschiedene Prüfpunkte

Benennen Sie zuerst die Flows, die geprüft werden müssen, denn die beiden Modelle behandeln sie unterschiedlich.

Verkehr innerhalb desselben Subnetzes ist die Zeile, die man vergisst. Zwei Hosts in einem VLAN sprechen über Bridging, und auf diesem Pfad sitzt keine geroutete Firewall, sofern nicht ein separates Prüfdesign für Layer 2 ihn abfängt. Das gilt in beiden Modellen, also ist es eine Designlücke und kein Vergleich zwischen ihnen.

Die übrigen drei Zeilen sind der Punkt, an dem die Modelle tatsächlich auseinandergehen.

Zentrales Gateway: einfache Prüfung, echte Transitkosten

Behalten Sie die Mandanten-VLANs als Layer-2-Dienste und legen Sie ihre Routing-Gateways auf die Firewall. Verkehr zwischen Subnetzen läuft dann zu diesem Gateway und zurück, möglicherweise selbst dann, wenn beide Hosts auf demselben Leaf sitzen. Der Prüfpunkt ist eindeutig, und das ist das ganze Argument für dieses Design. Die Kosten sind Transitlast auf der Firewall plus eine zentrale Abhängigkeit von Kapazität und Verfügbarkeit, die Sie jetzt einplanen müssen.

Begrenzen Sie die Änderung auf die Mandanten-Gateways, die Sie beabsichtigen. Jede VLAN-Adresse zu entfernen ist zu breit, wenn Management, Underlay und Plattform-Schnittstellen getrennte Aufgaben haben. Prüfen Sie auch ein zweites aktives Gateway, denn eines, das weiterhin um die Firewall herum routet, entwertet das Design still.

Dieses Modell lässt sich einem Auditor leichter erklären. Es ist nicht automatisch günstiger im Betrieb.

Verteiltes IRB: schneller Pfad, standardmäßig keine Prüfung

Mit verteilten Anycast-Gateways routet jeder Leaf den Mandantenverkehr lokal, und RFC 9135 beschreibt, warum das den Rücktransport über ein zentrales Gateway vermeidet. Der Vorteil ist real, und er hat eine direkte Folge: Aus dem Ort, an dem die Firewall eingesteckt ist, lässt sich keine Prüfung ableiten. Eine Firewall an einem Border-Leaf sieht externen Verkehr und alles, was Sie ausdrücklich dorthin umleiten.

Fügen Sie den Dienst mit einem Mechanismus ein, den die Plattform tatsächlich unterstützt: richtlinienbasierte Umleitung, einen Service-Node oder kontrolliertes Routing zwischen VRFs durch die Firewall. Treffen Sie den vorgesehenen Verkehr an seinem tatsächlichen Eingangspunkt. Eine Richtlinie auf einem hostzugewandten Interface erfasst kein Paket, das aus dem Overlay kommt.

Lesen Sie die installierten Routen statt der vorgesehenen Default-Route. Ein spezifischeres Mandanten-Präfix, direkt importiert, kann die Default-Route umgehen, die auf die Firewall zeigt, und in der Konfiguration wird nichts falsch aussehen.

Symmetrie ist eine Routing-Eigenschaft, keine Prüfgarantie

Symmetrisches IRB beschreibt, wie eingehende und ausgehende Provider-Edge-Knoten Routing und Bridging für einen Flow handhaben. Es sagt nichts darüber, ob beide Richtungen dasselbe zustandsbehaftete Gerät erreichen. ECMP, Anycast und Hochverfügbarkeit der Firewall beeinflussen, welcher Knoten den Rückverkehr sieht, und das unterstützte Zustandsmodell des Clusters entscheidet, ob das akzeptabel ist.

Verfolgen Sie den Rückweg für jeden Flow, der Ihnen wichtig ist, ausdrücklich. NAT ist kein universeller Ersatz für diese Arbeit, und Designs, die sich darauf stützen, finden die Lücke meist während eines Failovers statt während des Aufbaus.

Gehen Sie einen erforderlichen Flow und einen bewusst ausgeschlossenen Flow in beiden Richtungen durch, bevor Sie das Design freigeben.

Wie Sie wählen und was Sie in jedem Fall testen sollten

Wählen Sie das zentrale Gateway, wenn Prüfabdeckung wichtiger ist als Transitkapazität und Sie sich die zentrale Abhängigkeit leisten können. Wählen Sie verteiltes IRB, wenn lokales Routing der Punkt ist, und planen Sie Budget für ausdrückliche Dienst-Einfügung ein, statt sie anzunehmen.

Testen Sie dann das Routing, das Sie tatsächlich installiert haben, denn dort unterscheiden sich die beiden Designs am stärksten:

show ip route vrf TENANT 10.20.0.0/16
show bgp l2vpn evpn route-type prefix

Nehmen Sie Ausfall und Wiederherstellung des Service-Node in den Test auf. Eine Ausweichroute, die die Prüfung still umgeht, ist eine andere Entscheidung als eine geplante Fail-Open-Policy, und meist ist nur eine von beiden beabsichtigt. Das fertige Design benennt, wohin jede Verkehrsklasse routet, wo sie geprüft wird und was passiert, wenn dieser Prüfpfad nicht verfügbar ist.