VxLAN fabriek. Deel 3

Hallo, Habr. Ik ben bezig met het afsluiten van een cyclus van artikelen, gewijd aan de lancering van de cursus "Netwerkingenieur" van OTUS, over de technologie VxLAN EVPN voor routing binnen de fabric en het gebruik van een Firewall om de toegang tussen interne services te beperken.

De eerdere delen van de cyclus zijn te vinden via de links:

• Deel 1 van de cyclus - L2-connectiviteit tussen servers
• Deel 2 van de cyclus - Routing tussen VNI
• Deel 2.5 van de cyclus - Theoretische terugtrekking

Vandaag zullen we de logica van routing binnen de VxLAN-fabric verder bestuderen. In het vorige deel bekeken we de routing binnen de fabric in het kader van één VRF. Er kunnen echter een enorm aantal client-services zijn en ze moeten allemaal in verschillende VRF's worden verdeeld om de toegang tussen hen te scheiden. Naast de netwerkscheiding kan het voor bedrijven nodig zijn om een Firewall aan te sluiten, om de toegang tussen deze services te beperken. Ja, dit is niet de beste oplossing, maar de moderne realiteit vereist "moderne oplossingen".

Laten we twee opties voor routing tussen VRF's bekijken:

1. Routing zonder de VxLAN-fabric te verlaten;
2. Routing op externe apparatuur.

Laten we beginnen met de logica van routing tussen VRF's. Er is een bepaald aantal VRF's. Om te routeren tussen VRF's is het noodzakelijk een apparaat in het netwerk aan te wijzen dat kennis heeft van alle VRF's (of van de delen daar tussen waarvoor routing nodig is). Dergelijke apparaten kunnen bijvoorbeeld een van de Leaf-switches zijn (of allemaal tegelijk). Deze topologie ziet er als volgt uit:

Wat zijn de nadelen van dergelijke topologie?

Juist, elke Leaf moet op de hoogte zijn van alle VRF's (en alle informatie die daarin is) in het netwerk, wat leidt tot geheugenverlies en een hogere belasting van het netwerk. Vaak hoeft elke Leaf-switch niet van alles op de hoogte te zijn.

Laten we echter deze methode verder bekijken, aangezien deze optie heel goed geschikt is voor kleine netwerken (tenzij er specifieke eisen van het bedrijf zijn).

Op dit punt kunt u zich afvragen hoe informatie van VRF naar VRF kan worden overgedragen, want het doel van deze technologie is juist dat de verspreiding van informatie beperkt moet zijn.

En het antwoord ligt in functies zoals export en import van routeringsinformatie (de configuratie van deze technologie werd besproken in de the second deel van de cyclus). Kort samengevat:

Bij het instellen van VRF in AF moet je route-target opgeven. voor het importeren en exporteren van route-informatie. Dit kan automatisch worden ingesteld. Dan wordt de ASN BGP en de L3 VNI die aan de VRF is gekoppeld, meegenomen. Dit is handig wanneer u in uw fabriek slechts één ASN gebruikt:

vrf context PROD20
  address-family ipv4 unicast
    route-target export auto      ! In automatische modus wordt RT-65001:99000 geëxporteerd
    route-target import auto

Als u echter meer dan één ASN heeft en routes tussen deze ASN's moet doorgeven, is handmatige configuratie een handigere en schaalbaardere optie. route-target opgeven.De aanbeveling voor handmatige configuratie — gebruik het eerste getal dat u handig vindt, bijvoorbeeld, 9999.
Het tweede moet gelijk worden gemaakt aan de VNI voor deze VRF.

We configureren als volgt:

vrf context PROD10
  address-family ipv4 unicast
    route-target export 9999:99000          
    route-target import 9999:99000
    route-target import 9999:77000         ! Voorbeeld 1 import vanuit een andere VRF
    route-target import 9999:88000         ! Voorbeeld 2 import vanuit een andere VRF

Hoe het eruit ziet in de routeringstabel:

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 ! prefix beschikbaar via L3VNI 99000

Laten we de tweede optie voor routering tussen VRF bekijken — via extern apparatuur, bijvoorbeeld een Firewall.

Er kunnen verschillende manieren worden voorgesteld voor het werken via een extern apparaat:

1. Het apparaat weet wat VxLAN is en we kunnen het in een deel van de fabriek toevoegen;
2. Het apparaat weet niets van VxLAN.

We zullen niet stoppen bij de eerste optie, aangezien de logica praktisch hetzelfde zal zijn als hierboven getoond — we brengen alle VRF naar de Firewall en configureren daarop de routering tussen VRF.

Laten we de tweede optie bekijken, wanneer onze Firewall niets weet van VxLAN (tegenwoordig komen er natuurlijk apparaten met VxLAN-ondersteuning. Bijvoorbeeld, Checkpoint heeft de ondersteuning aangekondigd in versie R81. Hierover kunt u lezen here, maar dit is allemaal nog in testfase en er is geen zekerheid over de stabiliteit van de werking).

Bij het aansluiten van een extern apparaat krijgen we het volgende schema:

Zoals uit het schema blijkt — er ontstaat een knelpunt bij de verbinding met de Firewall. Dit moet in de toekomst worden meegenomen bij het plannen van het netwerk en het optimaliseren van het netwerkverkeer.

Laten we echter terugkeren naar de oorspronkelijke taak van routering tussen VRF. Als gevolg van de toevoeging van de Firewall komen we tot de conclusie dat de Firewall van alle VRF op de hoogte moet zijn. Hiervoor moeten op de grens-Leaf ook alle VRF zijn ingesteld, en de Firewall verbinden we met elke VRF via een aparte link.

In het gevolg het schema met Firewall:

Dat betekent dat op de Firewall een interface voor elke VRF in het netwerk moet worden ingesteld. In het algemeen lijkt de logica niet moeilijk, en het enige wat wellicht tegenvalt, is het enorme aantal interfaces op de Firewall, maar hier is het tijd om na te denken over automatisering.

Goed. We hebben de Firewall aangesloten, deze toegevoegd aan alle VRF's. Maar hoe zorgen we er nu voor dat het verkeer van elke Leaf via deze Firewall gaat?

Op de Leaf die met de Firewall is verbonden, zijn er geen problemen, omdat alle routes lokaal zijn:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6w5d, statisch       ! standaard route via Firewall

Maar hoe zit het met de externe Leaf? Hoe geven we hen de externe standaardroute?

Inderdaad, via EVPN route-type 5, net als elke andere prefix in de VxLAN-fabriek. Maar het is niet zo eenvoudig (tenzij we over Cisco praten, ik heb het niet bij andere leveranciers gecontroleerd)

De standaardroute moet worden aangekondigd vanaf de Leaf die met de Firewall is verbonden. Maar om de route door te geven, moet de Leaf deze zelf kennen. En hier ontstaat een bepaald probleem (misschien alleen bij mij), de route moet statisch worden ingesteld in de VRF waar je zo'n route wilt aankondigen:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Vervolgens in de BGP-configuratie deze route instellen in AF IPv4:

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

Maar dat is nog niet alles. Op deze manier komt de standaardroute niet in de familie l2vpn evpn. Daarnaast is het nodig om herdistributie in te stellen:

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

We geven aan welke prefixen door de herdistributie in BGP komen:

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

Nu komt de prefix 0.0.0.0/0 in EVPN route-type 5 en wordt doorgegeven aan de andere Leaf:

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 - Virtueel adres Leaf (aangezien Leaf fungeert als VPS-paar), waaraan de Firewall is verbonden

In de BGP-tabel kunnen we ook de ontvangen route-type 5 met de standaardroute via 10.255.1.5 zien:

* 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

Dit is het einde van deze reeks artikelen over EVPN. In de toekomst zal ik proberen om de werking van VxLAN in combinatie met Multicast te bekijken, aangezien deze methode als meer schaalbaar wordt beschouwd (momenteel een betwistbare bewering).

Als u nog vragen of suggesties heeft over het bespreken van bepaalde functionaliteiten van EVPN, laat het ons weten, dan bekijken we het verder.

Bron: habr.com