VxLAN-fabriek. Deel 3

Hallo, Habr. Ik ben een reeks artikelen aan het afronden, gewijd aan de lancering van de cursus "Netwerktechnicus" door OTUS, met behulp van VxLAN EVPN-technologie voor routering binnen de fabric en met behulp van Firewall om de toegang tussen interne services te beperken

Eerdere delen van de serie zijn te vinden via de volgende links:

• 1 deel van de cyclus - L2-connectiviteit tussen servers
• Deel 2 van de serie - Routing tussen VNI's
• Deel 2.5 van de serie - Theoretische uitweiding

Vandaag zullen we doorgaan met het bestuderen van de routeringslogica binnen het VxLAN-weefsel. In het vorige deel hebben we gekeken naar intra-fabric routing binnen één VRF. Er kan echter een groot aantal clientservices in het netwerk aanwezig zijn, en deze moeten allemaal over verschillende VRF's worden verdeeld om de toegang daartussen te kunnen onderscheiden. Naast netwerkscheiding moet een bedrijf mogelijk een firewall aansluiten om de toegang tussen deze services te beperken. Ja, dit kan niet de beste oplossing worden genoemd, maar de moderne realiteit vereist ‘moderne oplossingen’.

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

1. Routering zonder de VxLAN-structuur te verlaten;
2. Routering op externe apparatuur.

Laten we beginnen met de routeringslogica tussen VRF's. Er zijn een bepaald aantal VRF's. Om tussen VRF's te routeren, moet je een apparaat in het netwerk selecteren dat op de hoogte is van alle VRF's (of delen waartussen routering nodig is). Zo'n apparaat kan bijvoorbeeld een van de Leaf-schakelaars zijn (of allemaal tegelijk). . Deze topologie ziet er als volgt uit:

Wat zijn de nadelen van deze topologie?

Dat klopt, elke Leaf moet op de hoogte zijn van alle VRF's (en alle informatie die zich daarin bevindt) op het netwerk, wat leidt tot geheugenverlies en verhoogde netwerkbelasting. Vaak hoeft elke Leaf-switch immers niet alles te weten wat zich op het netwerk bevindt.

Laten we deze methode echter in meer detail bekijken, aangezien deze optie voor kleine netwerken redelijk geschikt is (als er geen specifieke zakelijke vereisten zijn)

Op dit punt heb je misschien een vraag over hoe je informatie van VRF naar VRF kunt overbrengen, omdat het punt van deze technologie juist is dat de verspreiding van informatie beperkt moet worden.

En het antwoord ligt in functies zoals het exporteren en importeren van route-informatie (het opzetten van deze technologie werd overwogen in tweede delen van de cyclus). Laat ik het kort herhalen:

Wanneer u VRF in AF instelt, moet u dit opgeven route-target voor import- en exportrouteringsinformatie. U kunt dit automatisch opgeven. Dan omvat de waarde de ASN BGP en L3 VNI die aan de VRF zijn gekoppeld. Dit is handig als u slechts één ASN in uw fabriek heeft:

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

Als u echter meer dan één ASN heeft en routes daartussen moet overbrengen, is handmatige configuratie een handiger en schaalbaardere optie route-target. De aanbeveling voor handmatige installatie is het eerste nummer. Gebruik een nummer dat voor u handig is, bijvoorbeeld 9999.
De tweede moet zo worden ingesteld dat deze gelijk is aan de VNI voor die VRF.

Laten we het als volgt configureren:

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

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.20%default, [200/0], 00:24:45, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN          ! префикс доступен через L3VNI 99000

Laten we eens kijken naar de tweede optie voor routering tussen VRF's: via externe apparatuur, bijvoorbeeld Firewall.

Er zijn verschillende opties om via een extern apparaat te werken:

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

We zullen niet ingaan op de eerste optie, omdat de logica bijna hetzelfde zal zijn als hierboven weergegeven: we brengen alle VRF's naar de firewall en configureren de routering tussen VRF's daarop.

Laten we de tweede optie overwegen, wanneer onze firewall niets weet over VxLAN (nu verschijnt er natuurlijk apparatuur met VxLAN-ondersteuning. Checkpoint heeft bijvoorbeeld zijn ondersteuning aangekondigd in versie R81. Je kunt erover lezen hierDit bevindt zich echter allemaal in de testfase en er is geen vertrouwen in de stabiliteit van de werking).

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

Zoals u in het diagram kunt zien, verschijnt er een knelpunt op de interface met de Firewall. Hiermee moet in de toekomst rekening worden gehouden bij de planning van het netwerk en het optimaliseren van het netwerkverkeer.

Laten we echter terugkeren naar het oorspronkelijke probleem van routering tussen VRF's. Als gevolg van het toevoegen van de Firewall komen we tot de conclusie dat de Firewall alle VRF's moet kennen. Om dit te doen moeten alle VRF's ook op de grens Leafs worden geconfigureerd en moet de Firewall met een aparte link op elke VRF worden aangesloten.

Het resultaat is dat het schema met Firewall:

Dat wil zeggen dat u op de Firewall een interface moet configureren voor elke VRF die zich op het netwerk bevindt. Over het algemeen ziet de logica er niet ingewikkeld uit en het enige wat ik hier niet leuk vind, is het enorme aantal interfaces op de Firewall, maar hier is het tijd om na te denken over automatisering.

Prima. We hebben de firewall aangesloten en aan alle VRF's toegevoegd. Maar hoe kunnen we nu het verkeer van elk blad dwingen om door deze firewall te gaan?

Op Leaf verbonden met de Firewall zullen er geen problemen optreden, aangezien alle routes lokaal zijn:

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

Maar hoe zit het met afgelegen Leafs? Hoe kan ik ze de standaard externe route doorgeven?

Dat klopt, via EVPN-routetype 5, net als elk ander voorvoegsel over de VxLAN-structuur. Dit is echter niet zo eenvoudig (als we het over Cisco hebben, zoals ik niet bij andere leveranciers heb nagevraagd)

De standaardroute moet worden geadverteerd vanaf de Leaf waarmee de Firewall is verbonden. Om de route echter door te geven, moet Leaf deze zelf kennen. En hier doet zich een bepaald probleem voor (misschien alleen voor mij), de route moet statisch worden geregistreerd in de VRF waar je zo'n route wilt adverteren:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Stel vervolgens in de BGP-configuratie deze route in AF IPv4 in:

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

Maar dat is niet alles. Op deze manier wordt de standaardroute niet opgenomen in de familie l2vpn evpn. Daarnaast moet u de herverdeling configureren:

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 voorvoegsels via herverdeling in BGP terechtkomen

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 het voorvoegsel 0.0.0.0/0 valt in EVPN-routetype 5 en wordt verzonden naar de rest van Leaf:

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 de BGP-tabel kunnen we ook het resulterende routetype 5 waarnemen met de standaardroute via 10.255.1.5:

* 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

Hiermee is de reeks artikelen over EVPN afgesloten. In de toekomst zal ik proberen de werking van VxLAN in combinatie met Multicast te overwegen, aangezien deze methode als schaalbaarder wordt beschouwd (op dit moment een controversiële verklaring)

Als u nog steeds vragen/suggesties over dit onderwerp heeft, overweeg dan de functionaliteit van EVPN - schrijf, we zullen er verder over nadenken.

Bron: www.habr.com