VxLAN-fabrik. Del 3

Hej, Habr. Jeg afslutter cyklen af artikler, der handler om lanceringen af kurset "Netværksingeniør" fra OTUS, om VxLAN EVPN-teknologi til routing inden for fabrikken og brugen af Firewall til at begrænse adgangen mellem interne tjenester

De tidligere dele af cyklen kan findes via links:

• 1. del af cyklen – L2-forbindelse mellem servere
• 2. del af cyklen – Routing mellem VNI
• 2.5 del af cyklen – Teoretisk tilbageholdelse

I dag fortsætter vi med at undersøge routinglogikken inden for VxLAN-fabrikken. I den foregående del gennemgik vi routing inden for fabrikken inden for en enkelt VRF. Men der kan være en enorm mængde servicekunder i netværket, og alle skal fordeles i forskellige VRF'er for at adskille adgangen mellem dem. Udover netværksadskillelse kan virksomheden have behov for at tilslutte en Firewall for at begrænse adgangen mellem disse tjenester. Ja, det kan ikke kaldes den bedste løsning, men de moderne realiteter kræver "moderne løsninger".

Lad os se på to muligheder for routing mellem VRF:

1. Routing uden at forlade VxLAN-fabrikken;
2. Routing på ekstern udstyr.

Lad os begynde med routinglogikken mellem VRF. Der er et bestemt antal VRF'er. For at route mellem VRF'er er det nødvendigt at dedikere en enhed i netværket, som kender til alle VRF'er (eller den del, der kræver routing). En sådan enhed kan for eksempel være en af Leaf-switchene (eller alle på én gang). Denne topologi vil se således ud:

Hvilke ulemper er der ved denne topologi?

Korrekt, hver Leaf skal kende til alle VRF'er (og al den information, der findes i dem) i netværket, hvilket fører til hukommelsestab og øget belastning på netværket. For det er det ofte ikke nødvendigt for hver Leaf-switch at kende til alt, hvad der findes i netværket.

Men lad os se på denne metode nærmere, da denne løsning er ganske anvendelig for mindre netværk (hvis der ikke er nogen specifikke krav fra virksomheden)

På dette tidspunkt kan du have spørgsmål om, hvordan man overfører information fra VRF til VRF, da ideen med denne teknologi netop er, at spredningen af information skal begrænses.

Og svaret ligger i funktioner som eksport og import af ruteinformation (konfigurationen af ​​denne teknologi blev behandlet i den anden del af cyklen). Jeg vil kort gentage:

Når du angiver VRF i AF, skal du angive route-target til import og eksport af ruteinformation. Dette kan angives automatisk. Så vil det indeholde ASN BGP og L3 VNI, der er knyttet til VRF. Dette er praktisk, når du har kun én ASN i fabrikken:

vrf context PROD20
  address-family ipv4 unicast
    route-target export auto      ! I automatisk tilstand eksporteres RT-65001:99000
    route-target import auto

Men hvis du har mere end én ASN og skal videregive ruter imellem dem, vil det være mere praktisk og skalerbart at konfigurere det manuelt. route-targetAnbefalingen i manuel konfiguration — det første nummer, brug et, der passer dig, for eksempel, 9999.
Det andet skal være lig med VNI for denne VRF.

Vi konfigurerer 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         ! Eksempel 1 import fra en anden VRF
    route-target import 9999:88000         ! Eksempel 2 import fra en anden VRF

Sådan ser det ud i routing-tabellen:

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 ! præfikset er tilgængeligt via L3VNI 99000

Lad os se på den anden mulighed for routing mellem VRF — gennem ekstern udstyr, såsom en firewall.

Der kan antages flere muligheder for drift gennem et eksternt enhed:

1. Enheden ved, hvad VxLAN er, og vi kan tilføje den til en del af fabrikken;
2. Enheden ved ikke noget om VxLAN.

Vi stopper ikke ved den første mulighed, da logikken næsten vil være den samme som vist ovenfor — vi strækker alle VRF til firewall og konfigurerer routing mellem VRF på den.

Lad os se på den anden mulighed, når vores firewall ikke ved noget om VxLAN (i øjeblikket kommer der dog udstyr med understøttelse af VxLAN. For eksempel har Checkpoint annonceret sin støtte i version R81. Det kan læses om det, her, men det er stadig i testfase, og der er ingen garanti for stabil drift).

Når der tilsluttes et eksternt enhed, får vi følgende skema:

Som det ses på skemaet — der opstår en flaskehals ved forbindelsen til firewallen. Dette skal tages i betragtning i fremtiden ved netplanlægning og optimering af netværkstrafik.

Men lad os vende tilbage til den oprindelige opgave med routing mellem VRF. Som følge af tilføjelsen af Firewall kommer vi frem til, at Firewall skal være klar over alle VRF. For dette formål skal alle VRF også være konfigureret på de grænseflader, og Firewall tilsluttes til hver VRF med en separat forbindelse.

Sådan ser diagrammet med Firewall ud:

Det vil sige, at Firewall skal have et interface konfigureret i hver VRF, der er i netværket. Generelt ser logikken ikke svær ud, og det eneste, der muligvis kan være problematisk, er det store antal interfaces på Firewall, men nu er det tid til at tænke over automation.

Godt. Vi har tilsluttet Firewall og tilføjet den til alle VRF. Men hvordan får vi nu trafikken fra hver Leaf til at gå gennem denne Firewall?

På Leaf, der er tilsluttet Firewall, vil der ikke opstå problemer, da alle ruter er lokale:

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

Men hvordan skal vi håndtere de fjerntliggende Leaf? Hvordan skal vi videresende den eksterne standardrute til dem?

Korrekt, via EVPN route-type 5, ligesom enhver anden præfiks i VxLAN-fabrikken. Men det er ikke så simpelt (hvis vi taler om Cisco, da jeg ikke har tjekket hos andre leverandører)

Den standardrute skal annonceres fra Leaf, som er tilsluttet Firewall. Men for at overføre ruten, skal Leaf selv kende den. Og her opstår der et problem (måske kun for mig), ruten skal angives statisk i den VRF, hvor du vil annoncere en sådan rute:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Derefter i BGP-indstillingerne angiv denne rute i AF IPv4:

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

Men det er ikke alt. På denne måde vil standardruten ikke komme ind i familien l2vpn evpn. Derudover skal du konfigurere redistribuering:

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

Vi angiver, hvilke præfikser der præcist vil komme ind i BGP gennem 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 kommer præfikset 0.0.0.0/0 ind i EVPN route-type 5 og overføres til de øvrige 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 - Virtuel adresse Leaf (da Leaf fungerer som VPS-par), til hvilken Firewall er tilsluttet

I BGP-tabellen kan vi også se den modtagne route-type 5 med standardruten gennem 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

Her afslutter vi cyklen af artikler dedikeret til EVPN. Fremover vil jeg forsøge at undersøge, hvordan VxLAN fungerer sammen med Multicast, da denne metode anses for at være mere skalerbar (på nuværende tidspunkt en omstridt påstand).

Hvis du har spørgsmål eller forslag til at overveje en bestemt funktionalitet i EVPN — skriv, så ser vi nærmere på det.

Kilde: habr.com