VxLAN fabrikk. Del 3

Hei, Habr. Jeg avslutter en serie artikler, som handler om lanseringen av kurset "Nettverksingeniør" fra OTUS, om VxLAN EVPN-teknologi for ruting innenfor fabrikken og bruk av brannmur for å begrense tilgangen mellom interne tjenester.

De tidligere delene av serien kan finnes via lenkene:

• Del 1 av serien — L2-tilkobling mellom servere
• Del 2 av serien — Ruting mellom VNI
• Del 2.5 av serien — Teoretisk avstikk

I dag skal vi fortsette å studere logikken for ruting innenfor VxLAN-fabrikken. I den forrige delen så vi på ruting innenfor fabrikken i rammen av en VRF. Men i nettverket kan det være et enormt antall klienttjenester, og alle må fordeles på forskjellige VRF-er for å avgrense tilgangen mellom dem. I tillegg til nettverksavgrensningen kan det være behov for å koble til 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 se på to alternativer for ruting mellom VRF-er:

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

Vi begynner med logikken for ruting mellom VRF-er. Det finnes et bestemt antall VRF-er. For å rute mellom VRF-er, er det nødvendig å avse en enhet i nettverket som vil vite om alle VRF-er (eller de delene som det er behov for ruting mellom). En slik enhet kan for eksempel være en av Leaf-svitsjene (eller alle på en gang). Topologien vil se slik ut:

Hvilke ulemper er det med en slik topologi?

Riktig, hver Leaf må vite om alle VRF-er (og all informasjon som finnes i dem) i nettverket, noe som fører til minnetap og økt belastning på nettverket. Det er jo ganske ofte at hver Leaf-svitsj ikke trenger å vite om alt som finnes i nettverket.

Men la oss se nærmere på denne metoden, da denne løsningen kan være helt passende for små nettverk (hvis det ikke er noen spesifikke forretningskrav).

På dette punktet kan det dukke opp et spørsmål om hvordan informasjon overføres fra en VRF til en annen, siden essensen med denne teknologien nettopp er at spredning av informasjon må begrenses.

Og svaret ligger i funksjoner som eksport og import av rutingsinformasjon (innstillingen av denne teknologien ble gjennomgått i den andre delen av serien). Kort oppsummering:

Når man angir VRF i AF, må man spesifisere route-target for importing and exporting routing information. This can be set in automatic mode. Then the ASN BGP and L3 VNI associated with the VRF will be included. This is convenient when you have only one ASN in your factory:

vrf context PROD20
  address-family ipv4 unicast
    route-target export auto      ! In automatic mode, RT-65001:99000 is exported
    route-target import auto

However, if you have more than one ASN and need to transmit routes between them, a more convenient and scalable option would be manual configuration route-target. The recommendation for manual configuration is to use the first number that is convenient for you, for example, 9999.
The second should be set equal to the VNI for this VRF.

We will configure it as follows:

vrf context PROD10
  address-family ipv4 unicast
    route-target export 9999:99000          
    route-target import 9999:99000
    route-target import 9999:77000         ! Example 1 import from another VRF
    route-target import 9999:88000         ! Example 2 import from another VRF

How it appears in the routing table:

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 ! prefikset er tilgjengelig gjennom L3VNI 99000

Let's consider the second option for routing between VRFs — through external equipment, such as a Firewall.

Several operating modes through external devices can be assumed:

1. The device knows what VxLAN is and we can integrate it into the part of the factory;
2. The device knows nothing about VxLAN.

We will not dwell on the first option, as the logic will be practically the same as shown above — we bring all VRFs to the Firewall and configure routing between VRFs there.

Let's consider the second option, when our Firewall knows nothing about VxLAN (currently, of course, equipment with VxLAN support is emerging. For example, Checkpoint announced its support in version R81. You can read about this here, however, it's all in the testing phase and there is no confidence in the stability of operation).

When connecting external devices, we get the following scheme:

As seen from the diagram — a bottleneck appears at the interface with the Firewall. This must be taken into account when planning the network and optimizing network traffic.

However, let's return to the original task of routing between VRFs. As a result of adding a Firewall, we come to the conclusion that the Firewall must be aware of all VRFs. For this, all VRFs must also be configured on the border Leaf, and the Firewall is connected to each VRF through a separate link.

Som følge av dette er skjemaet med brannmur:

Det betyr at du må konfigurere grensesnittet på brannmuren for hver VRF som finnes i nettverket. Generelt sett er logikken ikke vanskelig, og det eneste som kan være lite attraktivt er det store antallet grensesnitt på brannmuren, men her begynner man å tenke på automatisering.

Greit. Vi har koblet til brannmuren og lagt den til alle VRF. Men hvordan skal vi nå få trafikken fra hver Leaf til å gå gjennom denne brannmuren?

På Leaf som er koblet til brannmuren, vil det ikke være noen problemer, ettersom alle rutene er lokale:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6w5d, statisk       ! standard rute via brannmur

Men hvordan skal vi håndtere fjern-Leaf? Hvordan kan vi sende dem den eksterne standardruten?

Riktig, gjennom EVPN route-type 5, akkurat som enhver annen prefiks i VxLAN-fabrikken. Men dette er ikke så enkelt (hvis vi snakker om Cisco, har jeg ikke sjekket hos andre leverandører)

Det er nødvendig å annonsere standardruten fra Leaf som er koblet til brannmuren. Men for at ruten skal kunne overføres, må Leaf selv vite om den. Og her oppstår et lite problem (kanskje bare for meg), ruten må angis statisk i den VRF der du vil annonsere en slik rute:

vrf kontekst PROD10
    ip rute 0.0.0.0/0 10.254.13.55

Deretter i BGP-konfigureringen angi denne ruten i AF IPv4:

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

Men dette er ikke alt. På denne måten vil ikke standardruten havne i familien l2vpn evpn. I tillegg må redistribusjon konfigureres:

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            nettverk 0.0.0.0/0
            redistribusjon statisk rute-kart COMMON_OUT

Vi angir hvilke prefikser som vil komme inn i BGP gjennom redistribusjon

rute-kart COMMON_OUT tillate 10
  match ip-adresse prefiks-liste COMMON_OUT

ip prefiks-liste COMMON_OUT sekvens 10 tillate 0.0.0.0/0

Nå kommer prefikset 0.0.0.0/0 inn i EVPN route-type 5 og overføres til de andre 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 adresse Leaf (siden Leaf fungerer som en VPS-par), som brannmuren er tilkoblet

I BGP-tabellen kan vi også se den mottatte route-type 5 med standardruten gjennom 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 avslutter nå artikkelsyklusen om EVPN. I fremtiden vil jeg forsøke å se på hvordan VxLAN fungerer sammen med Multicast, siden denne metoden anses for å være mer skalerbar (for øyeblikket et omdiskutert utsagn).

Hvis dere har spørsmål eller forslag angående noen funksjonalitet i EVPN – ta kontakt, så ser vi nærmere på det.

Kilde: habr.com