VxLAN fabrikk. Del 3

Hei, Habr. Jeg avslutter en serie artikler, dedikert til lanseringen av kurset "Nettverksingeniør" av OTUS, ved å bruke VxLAN EVPN-teknologi for ruting i stoffet og bruke brannmur for å begrense tilgang mellom interne tjenester

Tidligere deler av serien finner du på følgende lenker:

• 1 del av syklusen - L2-tilkobling mellom servere
• Del 2 av serien - Ruting mellom VNI-er
• Del 2.5 av serien - Teoretisk digresjon

I dag vil vi fortsette å studere rutingslogikken inne i VxLAN-stoffet. I den forrige delen så vi på intra-stoff-ruting innenfor en enkelt VRF. Imidlertid kan det være et stort antall klienttjenester i nettverket, og alle må distribueres i forskjellige VRF-er for å skille tilgang mellom dem. I tillegg til nettverksseparasjon kan det hende en bedrift må koble til en brannmur for å begrense tilgangen mellom disse tjenestene. Ja, dette kan ikke kalles den beste løsningen, men moderne realiteter krever "moderne løsninger".

La oss vurdere to alternativer for ruting mellom VRF-er:

1. Ruting uten å forlate VxLAN-stoffet;
2. Ruting på eksternt utstyr.

La oss starte med rutinglogikken mellom VRF-er. Det er et visst antall VRF-er. For å rute mellom VRF-er, må du velge en enhet i nettverket som vil vite om alle VRF-er (eller deler som det er behov for ruting mellom). En slik enhet kan for eksempel være en av Leaf-svitsjene (eller alle på en gang) . Denne topologien vil se slik ut:

Hva er ulempene med denne topologien?

Det er riktig, hver Leaf trenger å vite om alle VRF-ene (og all informasjonen som er i dem) på nettverket, noe som fører til minnetap og økt nettverksbelastning. Tross alt, ganske ofte trenger ikke hver Leaf-svitsj å vite om alt som er på nettverket.

La oss imidlertid vurdere denne metoden mer detaljert, siden for små nettverk er dette alternativet ganske egnet (hvis det ikke er noen spesifikke forretningskrav)

På dette tidspunktet har du kanskje et spørsmål om hvordan du overfører informasjon fra VRF til VRF, fordi poenget med denne teknologien er nettopp at informasjonsspredningen skal begrenses.

Og svaret ligger i funksjoner som eksport og import av ruteinformasjon (oppsett av denne teknologien ble vurdert i andre deler av syklusen). La meg gjenta kort:

Når du stiller inn VRF i AF, må du spesifisere route-target for import og eksport av ruteinformasjon. Du kan spesifisere det automatisk. Da vil verdien inkludere ASN BGP og L3 VNI knyttet til VRF. Dette er praktisk når du bare har ett ASN på fabrikken:

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

Men hvis du har mer enn ett ASN og trenger å overføre ruter mellom dem, vil manuell konfigurasjon være et mer praktisk og skalerbart alternativ route-target. Anbefalingen for manuell oppsett er det første tallet, bruk et som er praktisk for deg, for eksempel, 9999.
Den andre bør settes til å være lik VNI for den VRF.

La oss konfigurere det som følger:

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

Slik ser det ut i rutetabellen:

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

La oss vurdere det andre alternativet for ruting mellom VRF-er - gjennom eksternt utstyr, for eksempel brannmur.

Det er flere alternativer for å jobbe gjennom en ekstern enhet:

1. Enheten vet hva VxLAN er, og vi kan legge den til en del av stoffet;
2. Enheten vet ingenting om VxLAN.

Vi vil ikke dvele ved det første alternativet, siden logikken vil være nesten den samme som vist ovenfor - vi bringer alle VRF-er til brannmuren og konfigurerer ruting mellom VRF-er på den.

La oss vurdere det andre alternativet, når brannmuren vår ikke vet noe om VxLAN (nå dukker det selvfølgelig opp utstyr med VxLAN-støtte. For eksempel kunngjorde Checkpoint sin støtte i versjon R81. Du kan lese om det her, men alt dette er på teststadiet og det er ingen tillit til driftsstabiliteten).

Når du kobler til en ekstern enhet, får vi følgende diagram:

Som du kan se av diagrammet, vises en flaskehals ved grensesnittet til brannmuren. Dette må tas i betraktning i fremtiden ved planlegging av nettverket og optimalisering av nettverkstrafikken.

La oss imidlertid gå tilbake til det opprinnelige problemet med ruting mellom VRF-er. Som et resultat av å legge til brannmuren, kommer vi til den konklusjon at brannmuren må vite om alle VRF-er. For å gjøre dette må alle VRF-er også konfigureres på grensebladene, og brannmuren må kobles til hver VRF med en egen lenke.

Som et resultat, ordningen med brannmur:

Det vil si at på brannmuren må du konfigurere et grensesnitt til hver VRF som ligger på nettverket. Generelt ser ikke logikken komplisert ut, og det eneste jeg ikke liker her er det enorme antallet grensesnitt på brannmuren, men her er det på tide å tenke på automatisering.

Fint. Vi koblet til brannmuren og la den til alle VRF-er. Men hvordan kan vi nå tvinge trafikk fra hvert blad til å gå gjennom denne brannmuren?

På Leaf koblet til brannmuren vil ingen problemer oppstå, siden alle ruter er lokale:

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

Men hva med eksterne Leafs? Hvordan sende dem til standard ekstern rute?

Det stemmer, gjennom EVPN-rutetype 5, som alle andre prefikser over VxLAN-stoffet. Dette er imidlertid ikke så enkelt (hvis vi snakker om Cisco, da jeg ikke har sjekket med andre leverandører)

Standardruten må annonseres fra bladet som brannmuren er koblet til. For å overføre ruten må Leaf imidlertid kjenne den selv. Og her dukker det opp et visst problem (kanskje bare for meg), ruten må registreres statisk i VRF der du ønsker å annonsere en slik rute:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Deretter, i BGP-konfigurasjonen, setter du denne ruten i AF IPv4:

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

Det er imidlertid ikke alt. På denne måten blir ikke standardruten inkludert i familien l2vpn evpn. I tillegg til dette må du konfigurere redistribusjon:

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

Vi angir hvilke prefikser som kommer inn i BGP gjennom 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

Nå prefikset 0.0.0.0/0 faller inn i EVPN rute-type 5 og overføres til 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 også observere den resulterende rute-type 5 med standardruten 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

Dette avslutter serien med artikler viet EVPN. I fremtiden vil jeg prøve å vurdere driften av VxLAN i forbindelse med Multicast, siden denne metoden anses som mer skalerbar (for øyeblikket en kontroversiell uttalelse)

Hvis du fortsatt har spørsmål/forslag om emnet, vurder eventuell funksjonalitet til EVPN - skriv, vi vil vurdere det videre.

Kilde: www.habr.com