🥇VxLAN fabrik. Del 3

Hej, Habr. Jag avslutar en serie artiklar, tillägnad lanseringen av kursen "Nätverksingenjör" av OTUS, använder VxLAN EVPN-teknik för routing inom strukturen och använder brandvägg för att begränsa åtkomst mellan interna tjänster

Tidigare delar av serien finns på följande länkar:

Idag kommer vi att fortsätta att studera routinglogiken inuti VxLAN-tyget. I den föregående delen tittade vi på routing inom tyget inom en enda VRF. Det kan dock finnas ett stort antal klienttjänster i nätverket, och alla måste distribueras till olika VRF:er för att skilja åtkomst mellan dem. Förutom nätverksseparation kan ett företag behöva ansluta en brandvägg för att begränsa åtkomsten mellan dessa tjänster. Ja, detta kan inte kallas den bästa lösningen, men moderna verkligheter kräver "moderna lösningar".

Låt oss överväga två alternativ för routing mellan VRF:er:

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

Låt oss börja med routinglogiken mellan VRF:er. Det finns ett visst antal VRF. För att dirigera mellan VRF:er måste du välja en enhet i nätverket som känner till alla VRF:er (eller delar som routing behövs mellan). En sådan enhet kan till exempel vara en av Leaf-switcharna (eller alla på en gång) . Denna topologi kommer att se ut så här:

Vilka är nackdelarna med denna topologi?

Det stämmer, varje Leaf behöver veta om alla VRF:er (och all information som finns i dem) på nätverket, vilket leder till minnesförlust och ökad nätverksbelastning. När allt kommer omkring, ganska ofta behöver inte varje Leaf-switch veta om allt som finns på nätverket.

Men låt oss överväga denna metod mer detaljerat, eftersom det här alternativet är ganska lämpligt för små nätverk (om det inte finns några specifika affärskrav)

Vid det här laget kan du ha en fråga om hur man överför information från VRF till VRF, eftersom poängen med denna teknik är just att spridningen av information ska begränsas.

Och svaret ligger i funktioner som export och import av routinginformation (inställning av denna teknik övervägdes i 2. delar av cykeln). Låt mig upprepa kort:

När du ställer in VRF i AF måste du ange route-target för import och export av ruttinformation. Du kan ange det automatiskt. Då kommer värdet att inkludera ASN BGP och L3 VNI som är associerade med VRF. Detta är praktiskt när du bara har ett ASN i din fabrik:

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

Men om du har mer än ett ASN och behöver överföra rutter mellan dem, kommer manuell konfiguration att vara ett mer bekvämt och skalbart alternativ route-target. Рекомендация в ручной настройке — первое число, использовать удобное Вам, например, 9999.
Den andra bör vara lika med VNI för den VRF.

Låt oss konfigurera det enligt följande:

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

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

Låt oss överväga det andra alternativet för routing mellan VRF:er - genom extern utrustning, till exempel brandvägg.

Det finns flera alternativ för att arbeta via en extern enhet:

Enheten vet vad VxLAN är och vi kan lägga till det i en del av tyget;
Enheten vet ingenting om VxLAN.

Vi kommer inte att uppehålla oss vid det första alternativet, eftersom logiken kommer att vara nästan densamma som visas ovan - vi tar alla VRF:er till brandväggen och konfigurerar routing mellan VRF:er på den.

Låt oss överväga det andra alternativet, när vår brandvägg inte vet något om VxLAN (nu dyker naturligtvis upp utrustning med VxLAN-stöd. Till exempel meddelade Checkpoint sitt stöd i version R81. Du kan läsa om det här, dock är allt på teststadiet och det finns inget förtroende för driftstabiliteten).

När du ansluter en extern enhet får vi följande diagram:

Som du kan se i diagrammet uppstår en flaskhals i gränssnittet med brandväggen. Detta måste beaktas i framtiden vid planering av nätverket och optimering av nätverkstrafik.

Men låt oss återgå till det ursprungliga problemet med routing mellan VRF:er. Som ett resultat av att lägga till brandväggen kommer vi till slutsatsen att brandväggen måste känna till alla VRF:er. För att göra detta måste alla VRF:er också konfigureras på gränsen Leafs, och brandväggen måste anslutas till varje VRF med en separat länk.

Som ett resultat, schemat med brandvägg:

Det vill säga, på brandväggen måste du konfigurera ett gränssnitt för varje VRF som finns i nätverket. I allmänhet ser logiken inte komplicerad ut och det enda jag inte gillar här är det enorma antalet gränssnitt på brandväggen, men här är det dags att tänka på automatisering.

Bra. Vi kopplade in brandväggen och la till den i alla VRF:er. Men hur kan vi nu tvinga trafik från varje Leaf att gå genom denna brandvägg?

На Leaf, подключенному к Firewall, никаких проблем не возникнет, так как все маршруты локальные:

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

Men hur är det med avlägsna Leafs? Hur skickar man dem till den externa standardvägen?

Det stämmer, genom EVPN-rutttyp 5, som alla andra prefix över VxLAN-tyget. Detta är dock inte så enkelt (om vi pratar om Cisco, eftersom jag inte har kollat med andra leverantörer)

Standardrutten måste annonseras från Leaf som brandväggen är ansluten till. Men för att kunna överföra rutten måste Leaf känna till den själv. Och här uppstår ett visst problem (kanske bara för mig), rutten måste registreras statiskt i VRF där man vill annonsera en sådan väg:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Därefter, i BGP-konfigurationen, ställ in denna rutt i AF IPv4:

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

Det är dock inte allt. På så sätt kommer inte standardrutten att inkluderas i familjen l2vpn evpn. Utöver detta måste du konfigurera omfördelning:

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

Vi anger vilka prefix som kommer in i BGP genom omfördelning

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 prefixet 0.0.0.0/0 faller in i EVPN-rutttyp 5 och sänds till resten av 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

I BGP-tabellen kan vi också observera den resulterande rutttyp 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

Detta avslutar serien av artiklar som ägnas åt EVPN. I framtiden kommer jag att försöka överväga driften av VxLAN i kombination med Multicast, eftersom denna metod anses vara mer skalbar (för närvarande ett kontroversiellt uttalande)

Om du fortfarande har frågor/förslag om ämnet, överväg eventuella funktioner hos EVPN - skriv, vi överväger det vidare.

Källa: will.com

VxLAN fabrik. Del 3

Lägg en kommentar Avbryt svar