VxLAN Fabrik. Teil 3

Hallo, Habr. Ich beende einen Zyklus von Artikeln, die dem Start des Kurses gewidmet sind "Netzwerktechniker" von OTUS, zur VxLAN EVPN-Technologie zur Routing innerhalb der Fabrik und zur Nutzung von Firewalls zur Einschränkung des Zugangs zwischen internen Diensten.

Die vorherigen Teile des Zyklus finden Sie unter den Links:

• Teil 1 der Reihe – L2-Konnektivität zwischen Servern
• Teil 2 des Zyklus — Routing zwischen VNI
• Teil 2.5 des Zyklus — Theoretische Abweichung

Heute werden wir weiterhin die Logik des Routings innerhalb der VxLAN-Fabrik untersuchen. Im vorherigen Teil haben wir das Routing innerhalb der Fabrik innerhalb eines VRF betrachtet. Es kann jedoch eine große Anzahl von Kundenservices im Netzwerk geben, die alle in verschiedene VRFs verteilt werden müssen, um den Zugang zwischen ihnen zu begrenzen. Zusätzlich zur netzwerkbasierten Trennung kann es für das Geschäft notwendig sein, eine Firewall zu verbinden, um den Zugang zwischen diesen Diensten einzuschränken. Ja, man kann dies nicht als die beste Lösung bezeichnen, jedoch erfordern die modernen Gegebenheiten "moderne Lösungen".

Betrachten wir zwei Routing-Varianten zwischen VRF:

1. Routing innerhalb der VxLAN-Fabrik;
2. Routing an externen Geräten.

Beginnen wir mit der Logik des Routings zwischen VRF. Es gibt eine bestimmte Anzahl von VRFs. Um zwischen VRFs zu routen, ist es notwendig, ein Gerät im Netzwerk zu bestimmen, das über alle VRFs (oder Teile davon, zwischen denen Routing erforderlich ist) informiert ist. Ein solches Gerät könnte beispielsweise einer der Leaf-Switches (oder alle auf einmal) sein. Die Topologie würde folgendermaßen aussehen:

Welche Nachteile hat eine solche Topologie?

Richtig, jeder Leaf muss über alle VRFs (und alle Informationen, die darin enthalten sind) im Netzwerk informiert sein, was zu einem Verlust von Speicher führt und die Belastung im Netzwerk erhöht. Denn es ist oft nicht notwendig, dass jeder Leaf-Switch über alles im Netzwerk Bescheid weiß.

Betrachten wir diese Methode jedoch genauer, da sie für kleine Netzwerke durchaus geeignet sein kann (wenn es keine speziellen Anforderungen des Geschäfts gibt).

An diesem Punkt könnte die Frage aufkommen, wie Informationen von einem VRF in ein anderes VRF übertragen werden, denn der Sinn dieser Technologie besteht gerade darin, dass die Verbreitung von Informationen eingeschränkt sein sollte.

Und die Antwort liegt in Funktionen wie Export und Import von Routinginformationen (die Konfiguration dieser Technologie haben wir in der der zweite Teil des Zyklus) behandelt. Kurz zusammengefasst:

Bei der Angabe von VRF in AF muss angegeben werden route-target für den Import und Export von Routing-Informationen. Dies kann im automatischen Modus angegeben werden. Dann wird ASN BGP und L3 VNI, das an VRF gebunden ist, zugewiesen. Dies ist praktisch, wenn in Ihrer Fabrik nur eine ASN verwendet wird:

vrf Kontext PROD20
  adressfamilie ipv4 unicast
    route-target export auto      ! Im automatischen Modus wird RT-65001:99000 exportiert
    route-target import auto

Sollten Sie jedoch mehr als eine ASN haben und Routen zwischen diesen übertragen müssen, ist eine manuelle Konfiguration die praktischere und skalierbarere Option. route-targetDie Empfehlung für die manuelle Konfiguration — verwenden Sie eine für Sie bequeme erste Zahl, zum Beispiel, 9999.
Die zweite sollte gleich VNI für dieses VRF sein.

Lassen Sie uns wie folgt konfigurieren:

vrf Kontext PROD10
  adressfamilie ipv4 unicast
    route-target export 9999:99000          
    route-target import 9999:99000
    route-target import 9999:77000         ! Beispiel 1 Import aus einem anderen VRF
    route-target import 9999:88000         ! Beispiel 2 Import aus einem anderen 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.20fault, [200/0], 00:24:45, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! Präfix über L3VNI 99000 verfügbar

Betrachten wir die zweite Möglichkeit der Routing zwischen VRF — über externe Geräte, beispielsweise Firewalls.

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

1. Das Gerät weiß, was VxLAN ist, und wir können es in den Teil der Fabrik integrieren;
2. Das Gerät weiß nichts über VxLAN.

Wir werden beim ersten Vorschlag nicht stehen bleiben, da die Logik praktisch dieselbe sein wird, wie oben gezeigt — wir führen alle VRF zur Firewall und konfigurieren das Routing zwischen den VRF dort.

Betrachten wir die zweite Option, bei der unsere Firewall nichts über VxLAN weiß (derzeit gibt es natürlich Geräte mit VxLAN-Unterstützung. Beispielsweise hat Checkpoint dessen Unterstützung in Version R81 angekündigt. Näheres dazu kann man lesen hier, aber das befindet sich alles noch in der Testphase, und es gibt keine Gewissheit über die Stabilität des Betriebs).

Beim Anschluss eines externen Geräts ergibt sich folgendes Schema:

Wie aus dem Schema ersichtlich — entsteht ein Engpass an der Schnittstelle zur Firewall. Dies sollte bei der weiteren Planung des Netzwerks und der Optimierung des Datenverkehrs berücksichtigt werden.

Kommen wir jedoch zu der ursprünglichen Aufgabe des Routings zwischen den VRF. Durch die Hinzufügung der Firewall kommen wir zu dem Punkt, dass die Firewall über alle VRF informiert sein muss. Dafür müssen auch an den Grenz-Leafs alle VRF konfiguriert sein, und wir schließen die Firewall mit einer separaten Verbindung an jedes VRF an.

Infolgedessen das Schema mit der Firewall:

Das bedeutet, dass die Schnittstelle für jede VRF, die im Netzwerk vorhanden ist, in der Firewall konfiguriert werden muss. Im Grunde ist die Logik nicht kompliziert, und das Einzige, was hier unangenehm sein könnte, ist die enorme Anzahl an Schnittstellen in der Firewall, doch hier sollte man über Automatisierung nachdenken.

Gut. Wir haben die Firewall angeschlossen und sie in alle VRFs hinzugefügt. Aber wie können wir jetzt den Datenverkehr von jedem Leaf durch diese Firewall schicken?

Am Leaf, der mit der Firewall verbunden ist, wird es keine Probleme geben, da alle Routen lokal sind:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6w5d, statisch       ! Standardroute über die Firewall

Wie sieht es jedoch mit den entfernten Leafs aus? Wie übergeben wir ihnen die externe Standardroute?

Genau, über EVPN route-type 5, wie jede andere Präfix im VxLAN-Netzwerk. Allerdings ist das nicht so einfach (wenn wir über Cisco sprechen, habe ich das bei anderen Anbietern nicht überprüft).

Die Standardroute muss von dem Leaf angekündigt werden, das mit der Firewall verbunden ist. Damit der Leaf die Route weitergeben kann, muss er sie kennen. Hier entsteht ein gewisses Problem (möglicherweise nur bei mir). Die Route muss statisch in dem VRF eingetragen werden, in dem Sie diese Route ankündigen möchten:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Im BGP müssen wir dann diese Route im AF IPv4 festlegen:

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

Das ist jedoch nicht alles. Auf diese Weise gelangt die Standardroute nicht in das Familiensegment l2vpn evpn. Zusätzlich muss eine Neuzuteilung konfiguriert werden:

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

Wir geben an, welche Präfixe durch die Neuzuteilung 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 kommt das Präfix 0.0.0.0/0 in EVPN route-type 5 und wird an die anderen Leafs weitergegeben:

0.0.0.0/0, ubest/mbest: 1/0
 *via 10.255.1.5fault, [200/0], 5w6d, bgp-65001, internal, tag 65001, segid: 99000 tunnelid: 0xaff0105 encap: VXLAN
 ! 10.255.1.5 - Virtuelle Adresse Leaf (da Leaf als VPS-Paar fungieren), an das die Firewall angeschlossen ist

In der BGP-Tabelle können wir auch den empfangenen route-type 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 beenden wir den Zyklus über EVPN. In Zukunft werde ich versuchen, die Funktionsweise von VxLAN in Kombination mit Multicast zu betrachten, da diese Methode als skalierbarer gilt (derzeit eine umstrittene Aussage).

Wenn Sie Fragen oder Vorschläge dazu haben, welche Funktionalitäten von EVPN betrachtet werden sollten, schreiben Sie mir, wir werden das zusätzlich prüfen.

Quelle: habr.com