🥇VxLAN Fabrik. Del 3

Hej, Habr. Jag avslutar en serie artiklar, som handlar om lanseringen av kursen "Nätverksingenjör" från OTUS, om VxLAN EVPN-teknologi för routing inom fabriken och användning av brandväggar för att begränsa tillgången mellan interna tjänster.

Tidigare delar av serien kan hittas via länkarna:

Idag fortsätter vi att undersöka logiken bakom routing inom VxLAN-fabriken. I den föregående delen diskuterade vi routing inom fabriken inom ramen för en VRF. Men ett nätverk kan ha ett stort antal tjänster/kunder, och alla måste fördelas i olika VRF för att avgränsa åtkomsten mellan dem. Utöver nätverksavgränsning kan företaget behöva ansluta en brandvägg för att begränsa åtkomsten mellan dessa tjänster. Även om detta inte kan kallas den bästa lösningen, kräver moderna realiteter "moderna lösningar".

Låt oss titta på två alternativ för routing mellan VRF:

Routing, utan att lämna VxLAN-fabriken;
Routing på extern utrustning.

Vi börjar med logiken för routing mellan VRF. Det finns ett visst antal VRF. För att göra routing mellan VRF måste man avsätta en enhet i nätverket som känner till alla VRF (eller den del mellan vilka routing behövs). En sådan enhet kan till exempel vara en av Leaf-switcharna (eller alla på en gång). Topologin skulle se ut som följer:

Vilka nackdelar finns det med en sådan topologi?

Rätt, varje Leaf måste känna till alla VRF (och all information som finns i dem) i nätverket, vilket leder till minnesförlust och ökad belastning på nätverket. Det är ganska ofta som varje Leaf-switch inte behöver veta allt som finns i nätverket.

Men låt oss granska denna metod mer i detalj, eftersom den kan vara helt lämplig för små nätverk (om det inte finns några specifika krav från företaget).

Vid detta tillfälle kan du få frågan om hur man överför information från VRF till VRF, eftersom syftet med denna teknologi just är att spridningen av information ska vara begränsad.

Och svaret ligger i sådana funktioner som export och import av routinformation (konfigurationen av denna teknologi diskuterades i andra delen av serien). Låt mig kort repetera:

Vid angivande av VRF i AF måste man ange route-target för import och export av rutinformation. Detta kan anges automatiskt. Då kommer värdet att innehålla ASN BGP och L3 VNI kopplat till VRF. Det är praktiskt när du använder bara en ASN i fabriken:

vrf context PROD20
  address-family ipv4 unicast
    route-target export auto      ! I automatiskt läge exporteras RT-65001:99000
    route-target import auto

Men om du har mer än en ASN och behöver överföra rutter mellan dem, så blir manuell konfiguration ett mer bekvämt och skalbart alternativ. route-target. Rekommendationen för manuell konfiguration är att använda ett första nummer som passar dig, till exempel, 9999.
Det andra bör göras lika med VNI för denna VRF.

Vi konfigurerar på följande sätt:

vrf context PROD10
  address-family ipv4 unicast
    route-target export 9999:99000          
    route-target import 9999:99000
    route-target import 9999:77000         ! Exempel 1 import från en annan VRF
    route-target import 9999:88000         ! Exempel 2 import från en annan VRF

Så här ser det ut i routingtabellen:

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 ! prefixet är tillgängliga via L3VNI 99000

Låt oss överväga det andra alternativet för routing mellan VRF — via extern utrustning, till exempel en brandvägg.

Man kan överväga flera alternativ för drift via extern enhet:

Enheten vet vad VxLAN är och vi kan lägga till den i en del av fabriken;
Enheten vet inget om VxLAN.

Vi kommer inte att stanna vid första alternativet, eftersom logiken blir praktiskt taget densamma som ovan — vi drar alla VRF till brandväggen och konfigurerar routing mellan VRF där.

Låt oss överväga det andra alternativet, när vår brandvägg inte vet något om VxLAN (just nu kommer det givetvis utrustning med stöd för VxLAN. Till exempel har Checkpoint meddelat sitt stöd i version R81. Du kan läsa om detta ). Ett typiskt exempel på användning:, men det är allt i teststadiet och det finns ingen garanti för stabilitet).

Vid anslutning av extern enhet ser vi följande schema:

Som syns i schemat — det finns en flaskhals vid anslutningen till brandväggen. Detta måste beaktas i framtiden vid nätverksplanering och optimering av nätverkstrafik.

Men låt oss återvända till det ursprungliga syftet med routing mellan VRF. Som ett resultat av att lägga till brandväggen måste vi se till att brandväggen känner till alla VRF. För detta ändamål måste alla VRF också konfigureras på gränssnittens Leaf, och brandväggen kopplas till varje VRF med en separat länk.

Som resultat är schemat med Firewall:

Det vill säga, det är nödvändigt att konfigurera ett gränssnitt på varje VRF som finns i nätverket på Firewall. Generellt sett ser logiken inte så komplicerad ut, och det enda som kan vara ointressant här är det stora antalet gränssnitt på Firewall, men nu är det dags att tänka på automatisering.

Bra. Vi har kopplat in Firewall, lagt till det i alla VRF. Men hur får vi nu trafiken från varje Leaf att gå genom denna Firewall?

På Leaf anslutet till Firewall uppstår inga problem, eftersom alla rutter är lokala:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6w5d, statisk       ! standardrutt genom Firewall

Men hur ska vi göra med avlägsna Leaf? Hur får vi dem att ta emot den externa standardruten?

Rätt, genom EVPN route-type 5, precis som vilket annat prefix som helst i VxLAN-fabriken. Men det är inte så enkelt (om vi pratar om Cisco, jag har inte kontrollerat med andra leverantörer)

Det är nödvändigt att annonsera standardrutten från Leaf som är ansluten till Firewall. Men för att överföra rutten måste Leaf känna till den själv. Här uppstår ett problem (kanske bara för mig), rutten måste skrivas in statiskt i den VRF där du vill annonsera en sådan rutt:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Därefter i BGP-konfigurationen ange denna rutt i AF IPv4:

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

Men det är inte allt. Därmed kommer standardrutten inte att ingå i familjen l2vpn evpn. Dessutom är det nödvändigt att konfigurera redistribuering:

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

Vi anger vilka specifika prefix som ska ingå i BGP genom redistribuering

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 går prefixet 0.0.0.0/0 in i EVPN route-type 5 och överförs till de andra 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 - Virtuell adress Leaf (eftersom Leaf fungerar som en VPS-par), som brandväggen är ansluten till

I BGP-tabellen kan vi också se den mottagna route-type 5 med standardrutten 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

Vi avslutar här denna serie artiklar om EVPN. Jag kommer senare att försöka granska hur VxLAN fungerar i samband med Multicast, eftersom denna metod anses mer skalbar (även om det för närvarande är en omtvistad påstående).

Om ni har några frågor eller förslag angående att diskutera någon funktionalitet i EVPN – skriv till oss, så undersöker vi det vidare.

Källa: habr.com

VxLAN fabrik. Del 3