VxLAN-Fabrik. Teil 3

Hallo, Habr. Ich beende eine Artikelserie, gewidmet dem Start des Kurses "Netzwerktechniker" von OTUS, Verwendung der VxLAN EVPN-Technologie für das Routing innerhalb der Fabric und Verwendung einer Firewall, um den Zugriff zwischen internen Diensten einzuschränken

Frühere Teile der Serie finden Sie unter folgenden Links:

• 1 Teil des Zyklus – L2-Konnektivität zwischen Servern
• Teil 2 der Serie – Routing zwischen VNIs
• Teil 2.5 der Serie – Theoretischer Exkurs

Heute werden wir die Routing-Logik innerhalb der VxLAN-Fabric weiter untersuchen. Im vorherigen Teil haben wir uns mit dem Intra-Fabric-Routing innerhalb eines einzelnen VRF befasst. Allerdings kann es im Netzwerk eine große Anzahl von Client-Diensten geben, die alle auf verschiedene VRFs verteilt werden müssen, um den Zugriff zwischen ihnen zu unterscheiden. Zusätzlich zur Netzwerktrennung muss ein Unternehmen möglicherweise eine Firewall anschließen, um den Zugriff zwischen diesen Diensten einzuschränken. Ja, dies kann nicht als die beste Lösung bezeichnet werden, aber moderne Realitäten erfordern „moderne Lösungen“.

Betrachten wir zwei Optionen für das Routing zwischen VRFs:

1. Routing ohne Verlassen der VxLAN-Struktur;
2. Routing auf externen Geräten.

Beginnen wir mit der Routing-Logik zwischen VRFs. Es gibt eine bestimmte Anzahl von VRFs. Um zwischen VRFs zu routen, müssen Sie ein Gerät im Netzwerk auswählen, das über alle VRFs (oder Teile, zwischen denen Routing erforderlich ist) Bescheid weiß. Ein solches Gerät könnte beispielsweise einer der Leaf-Switches (oder alle auf einmal) sein. . Diese Topologie sieht folgendermaßen aus:

Was sind die Nachteile dieser Topologie?

Das ist richtig, jeder Leaf muss über alle VRFs (und alle darin enthaltenen Informationen) im Netzwerk Bescheid wissen, was zu Speicherverlust und erhöhter Netzwerklast führt. Schließlich muss nicht jeder Leaf-Switch über alles Bescheid wissen, was sich im Netzwerk befindet.

Betrachten wir diese Methode jedoch genauer, da diese Option für kleine Netzwerke durchaus geeignet ist (sofern keine besonderen Geschäftsanforderungen bestehen).

An dieser Stelle haben Sie möglicherweise eine Frage zur Übertragung von Informationen von VRF zu VRF, denn der Sinn dieser Technologie besteht genau darin, dass die Verbreitung von Informationen begrenzt werden sollte.

Und die Antwort liegt in Funktionen wie dem Export und Import von Routing-Informationen (die Einrichtung dieser Technologie wurde in berücksichtigt zweite Teile des Zyklus). Lassen Sie mich kurz wiederholen:

Wenn Sie VRF in AF einstellen, müssen Sie angeben route-target für den Import und Export von Routing-Informationen. Sie können es automatisch angeben. Dann umfasst der Wert den ASN BGP und den L3 VNI, der dem VRF zugeordnet ist. Dies ist praktisch, wenn Sie in Ihrer Fabrik nur eine ASN haben:

vrf context PROD20
  address-family ipv4 unicast
    route-target export auto      ! В автоматическом режиме экспортируется RT-65001:99000
    route-target import auto

Wenn Sie jedoch mehr als eine ASN haben und Routen zwischen diesen übertragen müssen, ist die manuelle Konfiguration eine bequemere und skalierbarere Option route-target. Die Empfehlung für die manuelle Einrichtung ist die erste Nummer. Verwenden Sie eine für Sie geeignete Nummer, z. B. 9999.
Der zweite Wert sollte auf den VNI für diesen VRF eingestellt werden.

Konfigurieren wir es wie folgt:

vrf context PROD10
  address-family ipv4 unicast
    route-target export 9999:99000          
    route-target import 9999:99000
    route-target import 9999:77000         ! Пример 1 import из другого VRF
    route-target import 9999:88000         ! Пример 2 import из другого VRF

So sieht es in der Routing-Tabelle aus:

Leaf11# sh ip route vrf prod
<.....>
192.168.20.0/24, ubest/mbest: 1/0
    *via 10.255.1.20%default, [200/0], 00:24:45, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN          ! префикс доступен через L3VNI 99000

Betrachten wir die zweite Option für das Routing zwischen VRFs – über externe Geräte, zum Beispiel eine Firewall.

Es gibt mehrere Möglichkeiten, über ein externes Gerät zu arbeiten:

1. Das Gerät weiß, was VxLAN ist, und wir können es einem Teil der Fabric hinzufügen.
2. Das Gerät weiß nichts über VxLAN.

Wir werden uns nicht mit der ersten Option befassen, da die Logik fast die gleiche ist wie oben gezeigt – wir bringen alle VRFs zur Firewall und konfigurieren dort das Routing zwischen VRFs.

Betrachten wir die zweite Option, wenn unsere Firewall nichts über VxLAN weiß (jetzt tauchen natürlich Geräte mit VxLAN-Unterstützung auf. Checkpoint hat beispielsweise seine Unterstützung in Version R81 angekündigt. Sie können darüber lesen hierDies alles befindet sich jedoch noch in der Testphase und es besteht kein Vertrauen in die Stabilität des Betriebs.

Beim Anschluss eines externen Geräts erhalten wir folgendes Diagramm:

Wie Sie dem Diagramm entnehmen können, entsteht an der Schnittstelle zur Firewall ein Engpass. Dies muss künftig bei der Planung des Netzwerks und der Optimierung des Netzwerkverkehrs berücksichtigt werden.

Kehren wir jedoch zum ursprünglichen Problem des Routings zwischen VRFs zurück. Durch das Hinzufügen der Firewall kommen wir zu dem Schluss, dass die Firewall über alle VRFs Bescheid wissen muss. Dazu müssen alle VRFs auch auf den Border-Leafs konfiguriert sein und die Firewall muss mit jedem VRF über einen separaten Link verbunden sein.

Als Ergebnis das Schema mit Firewall:

Das heißt, Sie müssen auf der Firewall eine Schnittstelle zu jedem VRF im Netzwerk konfigurieren. Im Allgemeinen sieht die Logik nicht kompliziert aus und das einzige, was mir hier nicht gefällt, ist die große Anzahl an Schnittstellen auf der Firewall, aber hier ist es an der Zeit, über Automatisierung nachzudenken.

Bußgeld. Wir haben die Firewall angeschlossen und zu allen VRFs hinzugefügt. Aber wie können wir nun den Datenverkehr von jedem Leaf dazu zwingen, diese Firewall zu passieren?

Wenn Leaf mit der Firewall verbunden ist, treten keine Probleme auf, da alle Routen lokal sind:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6w5d, static       ! маршрут по-умолчанию через Firewall

Was ist jedoch mit Remote-Leafs? Wie übergebe ich ihnen die standardmäßige externe Route?

Das ist richtig, über EVPN-Routentyp 5, wie jedes andere Präfix über der VxLAN-Fabric. Dies ist jedoch nicht so einfach (wenn wir über Cisco sprechen, da ich mich nicht bei anderen Anbietern erkundigt habe)

Die Standardroute muss von dem Leaf aus bekannt gegeben werden, mit dem die Firewall verbunden ist. Um die Route zu übermitteln, muss Leaf diese jedoch selbst kennen. Und hier entsteht ein gewisses Problem (vielleicht nur für mich), die Route muss statisch im VRF registriert sein, wo man eine solche Route ausschreiben möchte:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Als nächstes legen Sie in der BGP-Konfiguration diese Route in AF IPv4 fest:

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0

Das ist jedoch noch nicht alles. Auf diese Weise wird die Standardroute nicht in die Familie aufgenommen l2vpn evpn. Darüber hinaus müssen Sie die Umverteilung konfigurieren:

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0
            redistribute static route-map COMMON_OUT

Wir geben an, welche Präfixe durch Umverteilung in BGP gelangen

route-map COMMON_OUT permit 10
  match ip address prefix-list COMMON_OUT

ip prefix-list COMMON_OUT seq 10 permit 0.0.0.0/0

Jetzt das Präfix 0.0.0.0/0 Fällt in den EVPN-Routentyp 5 und wird an den Rest von Leaf übertragen:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.255.1.5%default, [200/0], 5w6d, bgp-65001, internal, tag 65001, segid: 99000 tunnelid: 0xaff0105 encap: VXLAN
    ! 10.255.1.5 - Виртуальный адрес Leaf(так как Leaf выступают в качестве VPС пары), к которому подключен Firewall

In der BGP-Tabelle können wir auch den resultierenden Routentyp 5 mit der Standardroute über 10.255.1.5 beobachten:

* i[5]:[0]:[0]:[0]:[0.0.0.0]/224
                      10.255.1.5                        100          0 i
*>i                   10.255.1.5                        100          0 i

Damit ist die Artikelreihe zum Thema EVPN abgeschlossen. In Zukunft werde ich versuchen, den Betrieb von VxLAN in Verbindung mit Multicast in Betracht zu ziehen, da diese Methode als skalierbarer gilt (derzeit eine umstrittene Aussage)

Wenn Sie noch Fragen/Anregungen zu diesem Thema haben, denken Sie über die Funktionalität von EVPN nach – schreiben Sie, wir werden uns weiter damit befassen.

Source: habr.com