ProHoster > Blog > Beheer > VxLAN fabriek. Deel 2

VxLAN fabriek. Deel 2

Hallo, Habr. Ik ga verder met de cyclus artikelen over de VxLAN EVPN-technologie, die speciaal zijn geschreven ter gelegenheid van de lancering van de cursus "Netwerkingenieur" van OTUS. Vandaag bekijken we een interessant deel van de taken — routing. Hoe cliché het ook klinkt, in het kader van het netwerkfabriek kan alles ingewikkelder zijn.

VxLAN fabriek. Deel 2

Deel 1 van de cyclus - L2-connectiviteit tussen servers

In het vorige deel hebben we één broadcast domein gerealiseerd, opgebouwd bovenop de netwerkfabriek op Nexus 9000v. Maar dit is lang niet het volledige scala aan taken dat moet worden opgelost binnen het datacenter netwerk. Vandaag gaan we de volgende taak bekijken — routing tussen netwerken of tussen VNI's.

Ter herinnering, we gebruiken de Spine-Leaf topologie:

VxLAN fabriek. Deel 2

Laten we eerst bekijken hoe de routing werkt en welke bijzonderheden er zijn.

Voor een beter begrip vereenvoudigen we het logische schema en voegen we nog een VNI 20000 toe voor Host-2. Eindresultaat:

VxLAN fabriek. Deel 2

Hoe kan het verkeer in dit geval van de ene Host naar de andere worden gestuurd?

Er zijn twee opties:

  1. Alle Leaf-switches houden informatie over alle VNI's, zodat alle routing plaatsvindt op de eerste Leaf in het netwerk;
  2. Een speciaal toegewezen — L3 VNI gebruiken.

De eerste optie is eenvoudig en handig. Het vereist slechts dat alle VNI's op alle Leaf-switches worden ingesteld. Toch lijkt het al snel geen eenvoudige taak om honderden of duizenden VNI's op alle Leaf in te voeren. Daarom wordt deze in de praktijk vrij zelden gebruikt.

Laten we de tweede optie onderzoeken, die interessanter en iets complexer is, maar meer flexibiliteit biedt bij het instellen van de fabriek.

We voegen de VRF "PROD" toe aan de topologie. We voegen interface vlan 10 toe op het paar Leaf-11/12 en interface VLAN 20 op Leaf-21. VLAN 20 associëren we met VNI 20000.

vrf context PROD
  rd auto       ! Route Distinguisher is niet cruciaal en kan automatisch worden aangemaakt
  address-family ipv4 unicast
    route-target both auto      ! we geven de Route-target aan waarmee prefixen in/uit VRF worden geïmporteerd en geëxporteerd
vlan 20
  vn-segment 20000

interface nve 1
  member vni 20000
    ingress-replication protocol bgp

interface Vlan10
  no shutdown
  vrf member PROD
  ip address 192.168.20.1/24
  fabric forwarding mode anycast-gateway

Om L3VNI te gebruiken, moet je een nieuwe VLAN creëren en deze associëren met de nieuwe VNI. De nieuwe VNI moet dezelfde zijn op alle Leaf-switches die geïnteresseerd zijn in informatie over VLAN 10 en 20.

vlan 99
  vn-segment 99000

interface nve1
  member vni 99000 associate-vrf        ! We creëren L3 VNI

vrf context PROD
  vni 99000                             ! Koppelen van L3 VNI aan een specifieke VRF

Als resultaat zal het schema er als volgt uitzien:

VxLAN fabriek. Deel 2

Er is nog maar een klein beetje te doen — een nieuwe interface toevoegen — interface vlan 99 in VRF PROD

interface Vlan99
  no shutdown
  vrf member PROD
  ip forward  ! De interface mag geen IP hebben. Wordt alleen gebruikt voor het doorsturen van pakketten tussen Leaf

De logica voor het doorgeven van het frame van Host-1 naar Host-2 is als volgt:

  1. Het frame dat door Host-1 wordt verzonden, komt aan op de Leaf in VLAN 10, dat is gekoppeld aan VNI 10000;
  2. Leaf controleert waar het bestemmingsadres zich bevindt en vindt het via L3 VNI op de tweede Leaf-switch;
  3. Zodra de route naar het bestemmingsadres is gevonden, verpakt de Leaf het frame in een header met de vereiste L3VNI 99000 — en stuurt het in de richting van de tweede Leaf;
  4. De tweede Leaf-switch ontvangt de gegevens van L3VNI 99000. Het haalt het oorspronkelijke frame eruit en verplaatst het naar de vereiste L2VNI 20000 en verder naar VLAN 20.

Het resultaat van deze werking van L3VNI is dat het niet nodig is om op alle Leaf-switches informatie te hebben over alle VNI's die in het netwerk zijn.

Dus, wanneer we verkeer van Host-1 naar Host-2 verzenden, wordt het pakket verpakt in VxLAN met een nieuwe VNI — 99000:

VxLAN fabriek. Deel 2

We moeten begrijpen hoe Leaf-1 de MAC-adres uit een andere VNI leert. Dit gebeurt ook met behulp van EVPN route-type 2 (MAC/IP).

Hieronder wordt het proces van het verspreiden van de route over een prefix in een andere VNI getoond:

VxLAN fabriek. Deel 2

Dat wil zeggen, de adressen verkregen uit VNI 20000 hebben twee RT's.
Ik herinner je eraan dat de routes die uit Update komen, in de BGP-tabel terechtkomen met het Route-target dat is aangegeven in de instellingen van VRF (het proces is iets gecompliceerder, maar we zullen hier in dit artikel niet dieper op ingaan).
De RT zelf wordt gevormd volgens de formule: AS:VNI (als de automatische modus wordt gebruikt).

Voorbeeld van RT-vorming in automatische en handmatige modus:

vrf context PROD
  address-family ipv4 unicast
    route-target import auto - automatische modus
    route-target export 65001:20000 - handmatige modus van RT-vorming

In het bovenstaande is te zien dat de prefixen uit een andere VNI twee waarden voor RT hebben.
Een daarvan is 65001:99000 — een aanvullende L3 VNI. Aangezien deze VNI overal hetzelfde is op alle Leaf en valt onder onze invoerregels in de instellingen van VRF — komt de prefix in de BGP-tabel, wat te zien is in de output:

sh bgp l2vpn evpn

   Netwerk            Volgende Hop            Metriek     LocPrf     Gewicht Pad
Route Distinguisher: 10.255.1.11:32777    (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216
                      10.255.1.10                       100      32768 i
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[32]:[192.168.10.10]/272
                      10.255.1.10                       100      32768 i
*>l[3]:[0]:[32]:[10.255.1.10]/88
                      10.255.1.10                       100      32768 i

Route Distinguisher: 10.255.1.21:32787
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]/272    ! Prefix verkregen uit VNI 20000
                      10.255.1.20                       100          0 i
*>i                   10.255.1.20                       100          0 i

Als we wat beter naar de verkregen update kijken, zien we dat deze prefix twee RT's heeft:

Leaf11# sh bgp l2vpn evpn 5001.0008.0007
BGP-routeringtabelinformatie voor VRF default, adresfamilie L2VPN EVPN
Route Distinguisher: 10.255.1.21:32787
BGP-routeringtabelvermelding voor [2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]/272, versie 5164
Paden: (2 beschikbaar, beste #2)
Vlaggen: (0x000202) (high32 00000000) op zenden-lijst, is niet in l2rib/evpn, is niet in HW

  Padtype: intern, pad is geldig, niet beste reden: Burenadres, geen gelabelde nexthop
  AS-Pad: GEEN, pad afkomstig intern van AS
    10.255.1.20 (metriek 81) van 10.255.1.102 (10.255.1.102)
      Oorsprong IGP, MED niet ingesteld, localpref 100, gewicht 0
      Ontvangen label 20000 99000                                 ! Twee labels voor VxLAN werking
      Extcommunity: RT:65001:20000 RT:65001:99000 SOO:10.255.1.20:0 ENCAP:8     ! Twee Route-target waarden, waarop deze prefix is gebaseerd
          Router MAC:5001.0005.0007
      Originator: 10.255.1.21 Clusterlijst: 10.255.1.102

In de routeringtabel op Leaf-1 kan ook de prefix 192.168.20.20/32 worden waargenomen:

Leaf11# sh ip route vrf PROD
192.168.10.0/24, ubest/mbest: 1/0, attached
 *via 192.168.10.1, Vlan10, [0/0], 01:29:28, direct
192.168.10.1/32, ubest/mbest: 1/0, attached
 *via 192.168.10.1, Vlan10, [0/0], 01:29:28, local
192.168.10.10/32, ubest/mbest: 1/0, attached
 *via 192.168.10.10, Vlan10, [190/0], 01:27:22, hmm
192.168.20.20/32, ubest/mbest: 1/0 ! Host-2 adres
 *via 10.255.1.20fault, [200/0], 01:20:20, bgp-65001, internal, tag 65001 ! Toegankelijk via Leaf-2
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! Via VNI 99000

Zag je de afwezigheid van de hoofdprefix 192.168.20.0/24 in de routeringtabel?
Klopt, die is er niet. Dat betekent dat de verwijderde Leaf alleen informatie over hosts ontvangt die in jouw netwerk zijn. En dat is het juiste gedrag. Bovenin in alle updates is te zien dat informatie met MAC/IP-inhoud binnenkomt. Er wordt niet gesproken over prefixes.

Dit werkt met het Host Mobility Manager (HMM) protocol, dat de ARP-tabel invult waaruit vervolgens de BGP-tabel wordt ingevuld (in dit artikel laten we dit proces achterwege). Op basis van de informatie verkregen uit HMM worden EVPN route-type 2 (MAC/IP wordt doorgegeven) gevormd.

Echter, wat te doen als er behoefte is om informatie over een bepaalde prefix door te geven?

Voor dit soort informatie bestaat EVPN route-type 5 — het maakt het mogelijk om prefixes door te geven via address-family l2vpn evpn (dit type routes is op het moment van schrijven alleen in draftversie beschikbaar. RFC, hierdoor kan het gedrag van dit type route verschillen tussen verschillende fabrikanten)

Voor het doorgeven van prefixes moeten in het BGP-proces voor VRF de prefixes worden toegevoegd die geannonceerd zullen worden:

router bgp 65001
  vrf PROD
    address-family ipv4 unicast
      redistribute direct route-map VNI20000        ! In dit geval adverteren we de prefixes die direct zijn aangesloten op Leaf in VNI 20000
route-map VNI20000 permit 10
  match ip address prefix-list VNI20000_OUT    ! We geven aan welke prefix-list gebruikt moet worden

ip prefix-list VNI20000_OUT seq 5 permit 192.168.20.0/24   ! We geven aan welke netwerken in EVPN route-type 5 zullen vallen

Uiteindelijk zal de Update zijn:

VxLAN fabriek. Deel 2

Laten we de BGP-tabel bekijken. Naast EVPN route-type 2 en 3 zijn er nu ook routes van type 5 verschenen, die informatie bevatten over het netwerknummer:

Netwerk            Volgende Hop            Metric     LocPrf     Gewicht Pad
Route Distinguisher: 10.255.1.11:3
* i[5]:[0]:[0]:[24]:[192.168.10.0]/224
                      10.255.1.10              0        100          0 ?
*>i                   10.255.1.10              0        100          0 ?

Route Distinguisher: 10.255.1.11:32777
* i[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216
                      10.255.1.10                       100          0 i
*>i                   10.255.1.10                       100          0 i
* i[2]:[0]:[0]:[48]:[5001.0007.0007]:[32]:[192.168.10.10]/272
                      10.255.1.10                       100          0 i
*>i                   10.255.1.10                       100          0 i
* i[3]:[0]:[32]:[10.255.1.10]/88
                      10.255.1.10                       100          0 i
*>i                   10.255.1.10                       100          0 i

Route Distinguisher: 10.255.1.12:3
*>i[5]:[0]:[0]:[24]:[192.168.10.0]/224      ! EVPN route-type 5 met prefixnummer
                      10.255.1.10              0        100          0 ?
* i

De prefix is ook in de routingtabel verschenen:

Leaf21# sh ip ro vrf PROD
192.168.10.0/24, ubest/mbest: 1/0
 *via 10.255.1.10fault, [200/0], 00:14:32, bgp-65001, internal, tag 65001 ! Externe prefix, bereikbaar via Leaf1/2 (Next-hop adres = virtueel IP tussen VPC-koppel)
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN ! Prefix bereikbaar via L3VNI 99000

192.168.10.10/32, ubest/mbest: 1/0
 *via 10.255.1.10fault, [200/0], 02:33:40, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN

192.168.20.0/24, ubest/mbest: 1/0, attached
 *via 192.168.20.1, Vlan20, [0/0], 02:39:44, direct
192.168.20.1/32, ubest/mbest: 1/0, attached
 *via 192.168.20.1, Vlan20, [0/0], 02:39:44, local
192.168.20.20/32, ubest/mbest: 1/0, attached
 *via 192.168.20.20, Vlan20, [190/0], 02:35:46, hmm

Hiermee beëindigen we het tweede deel van de serie artikelen over VxLAN EVPN. In het volgende deel zullen we verschillende routingopties tussen VRF bekijken.

Basisprincipes van het IPv6-protocol en de verschillen met IPv4

Bron: habr.com

Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers 🔥 Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers | ProHoster