VxLAN-Fabrik. Teil 3

Hallo, Habr. Ich beende einen Zyklus von Artikeln, die dem Start eines Kurses "Netzwerktechniker" von OTUS, rund um die VxLAN EVPN-Technologie zur Routing innerhalb der Fabrik und der Nutzung von Firewalls zur Zugriffsbegrenzung zwischen internen Diensten gewidmet sind.

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 Exkursion

Heute setzen wir die Untersuchung der Routing-Logik innerhalb der VxLAN-Fabrik fort. Im vorherigen Teil haben wir das Routing innerhalb der Fabrik im Rahmen eines VRF betrachtet. Allerdings kann es in einem Netzwerk eine enorme Anzahl von Kundenservices geben, die alle in verschiedene VRFs verteilt werden müssen, um den Zugang zwischen ihnen zu beschränken. Neben der Netzwerksegmentierung kann es für Unternehmen notwendig sein, eine Firewall anzuschließen, um den Zugang zwischen diesen Services 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 VRFs:

1. Routing, ohne die VxLAN-Fabrik zu verlassen;
2. Routing auf externen Geräten.

Lass uns mit der Logik des Routings zwischen VRF beginnen. Es gibt eine bestimmte Anzahl von VRF. Um zwischen diesen VRF zu routen, muss ein Gerät im Netzwerk bereitgestellt werden, das über alle VRF (oder Teile von ihnen, zwischen denen das Routing notwendig ist) informiert ist. Ein solches Gerät könnte beispielsweise einer der Leaf-Switches (oder alle auf einmal) sein. Eine solche Topologie würde folgendermaßen aussehen:

Was sind die Nachteile einer solchen Topologie?

Richtig, jeder Leaf muss über alle VRF (und alle darin enthaltenen Informationen) im Netzwerk informiert sein, was zu einem Speicherverlust und einer erhöhten Last im Netzwerk führt. Denn es ist ganz häufig nicht nötig, dass jeder Leaf-Switch über alles informiert ist, was im Netzwerk vorhanden ist.

Betrachten wir diese Vorgehensweise jedoch näher, da diese Option für kleine Netzwerke durchaus geeignet sein könnte (sofern keine spezifischen Geschäftsanforderungen vorliegen).

An diesem Punkt könnte die Frage aufkommen, wie Informationen von einem VRF zu einem anderen VRF übertragen werden, denn der Sinn dieser Technologie besteht gerade darin, dass die Informationsverbreitung begrenzt sein sollte.

Die Antwort liegt in Funktionen wie dem Export und Import von Routing-Informationen (die Konfiguration dieser Technologie haben wir im Teil des Zyklus betrachtet). Kurz gesagt: der zweite Teile des Zyklus). Kurz zusammengefasst:

Beim Festlegen von VRF in AF muss angegeben werden route-target für den Import und Export von Routing-Informationen. Dies kann im automatischen Modus festgelegt werden. Dann werden ASN BGP und L3 VNI, die mit VRF verbunden sind, als Wert verwendet. Das ist praktisch, wenn in Ihrer Fabrik nur eine ASN verwendet wird:

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

Wenn Sie jedoch mehr als eine ASN haben und Routen zwischen ihnen übertragen müssen, ist die manuelle Konfiguration eine bequemere und skalierbare Option. route-targetDie Empfehlung für die manuelle Konfiguration — verwenden Sie eine beliebige Zahl, die Ihnen angenehm ist, zum Beispiel 9999.
Die zweite sollte gleich dem VNI für dieses VRF sein.

Wir konfigurieren dies wie folgt:

vrf context PROD10
  address-family 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, intern, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! Präfix über L3VNI 99000 verfügbar

Betrachten wir die zweite Variante der Routenführung zwischen VRFs — über externe Geräte, wie beispielsweise Firewalls.

Es können mehrere Betriebsvarianten über ein externes Gerät angenommen werden:

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

Wir werden nicht beim ersten Ansatz anhalten, da die Logik praktisch identisch ist wie oben beschrieben — wir führen alle VRFs zur Firewall und konfigurieren das Routing zwischen den VRFs dort.

Betrachten wir die zweite Variante, bei der unsere Firewall nichts über VxLAN weiß (derzeit erscheinen Geräte mit VxLAN-Unterstützung, zum Beispiel hat Checkpoint die Unterstützung in Version R81 angekündigt. Dazu kann man hier, jedoch befindet sich das alles noch in der Testphase und es gibt keine Gewissheit über die Stabilität der Funktion).

Wenn wir ein externes Gerät anschließen, ergibt sich das folgende Schema:

Wie im Schema zu sehen ist, entsteht ein Engpass an der Verbindung zur Firewall. Dies muss bei der Planung des Netzwerks und der Optimierung des Netzwerkverkehrs berücksichtigt werden.

Wenden wir uns jedoch der ursprünglichen Aufgabe der Routenerstellung zwischen VRF zu. Durch die Hinzufügung der Firewall muss die Firewall über alle VRF informiert sein. Dazu müssen an den Grenz-Leafs ebenfalls alle VRF konfiguriert werden, und die Firewall wird mit jeder VRF über eine separate Verbindung verbunden.

Das Ergebnis mit der Firewall sieht folgendermaßen aus:

Das heißt, auf der Firewall muss ein Interface für jede VRF in dem Netzwerk konfiguriert werden. Insgesamt sieht die Logik nicht komplex aus, und das Einzige, was störend sein könnte, ist die große Anzahl an Interfaces auf der Firewall, aber hier sollte man über Automatisierung nachdenken.

Gut. Wir haben die Firewall angeschlossen und sie in alle VRF integriert. Aber wie lassen wir jetzt den Datenverkehr von jedem Leaf durch diese Firewall fließen?

Auf dem Leaf, der mit der Firewall verbunden ist, gibt es keine Probleme, da alle Routen lokal sind:

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

Aber was ist mit den entfernten Leafs? Wie übermitteln wir ihnen die externe Standardroute?

Richtig, über den EVPN-Routentyp 5, wie bei jedem anderen Präfix in der VxLAN-Fabrik. Allerdings ist das nicht so einfach (wenn wir über Cisco sprechen, haben wir das bei anderen Anbietern nicht überprüft).

Um das Standardrouting anzukündigen, ist es erforderlich, dass Leaf, das mit der Firewall verbunden ist, dies übernimmt. Allerdings muss Leaf den Route selbst kennen, um ihn anzukündigen. Hier entsteht ein gewisses Problem (vielleicht nur bei mir), da die Route statisch in der VRF, in der Sie solche Routen ankündigen möchten, eingetragen werden muss:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Anschließend müssen Sie diese Route in der BGP-Konfiguration im AF IPv4 angeben:

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

Das ist jedoch nicht alles. So wird die Standardroute nicht in die Familie l2vpn evpn. Zusätzlich müssen Sie die Redistribution einrichten:

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

Hier geben wir an, welche Präfixe über die Redistribution 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 gelangt das Präfix 0.0.0.0/0 in den EVPN route-type 5 und wird an die anderen Leaf weitergegeben:

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

In der BGP-Tabelle können wir auch den empfangenen Route-Typ 5 mit dem Standardweg ü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 von Artikeln über EVPN. In Zukunft werde ich versuchen, die Funktion von VxLAN in Kombination mit Multicast zu betrachten, da diese Methode als skalierbarer betrachtet wird (derzeit eine umstrittene Aussage).

Wenn Sie Fragen oder Vorschläge zum Thema haben, um eine bestimmte Funktionalität von EVPN zu betrachten — schreiben Sie, wir werden dies weiter überprüfen.

Quelle: habr.com