HΓ© Habr. Ik vervolg de reeks artikelen over VxLAN EVPN-technologie, die zijn speciaal geschreven voor de lancering van de cursus
In het laatste deel hebben we één uitzenddomein gerealiseerd bovenop een netwerkstructuur op een Nexus 9000v. Dit is echter niet het hele scala aan taken dat moet worden opgelost in het kader van het datacenternetwerk. En vandaag zullen we de volgende taak overwegen: routering tussen netwerken of tussen VNI's.
Laat me je eraan herinneren dat de Spine-Leaf-topologie wordt gebruikt:
Om te beginnen zullen we analyseren hoe routering plaatsvindt en welke functies het heeft.
Laten we voor een beter begrip het logicaschema vereenvoudigen en nog een VNI 20000 voor Host-2 toevoegen. Het resultaat is:
Hoe kunt u in dit geval verkeer van de ene host naar de andere overbrengen?
Er zijn twee opties:
- Bewaar informatie over alle VNI's op alle Leaf-switches, dan vindt alle routering plaats op de eerste Leaf in het netwerk;
- Gebruik speciaal - L3 VNI
De eerste manier is eenvoudig en handig. Omdat u alleen alle VNI's op alle Leaf-switches hoeft te starten. Een paar honderd of duizenden VNI's op de hele Leaf draaien lijkt echter geen gemakkelijke taak meer. Daarom wordt het in het werk vrij zelden gebruikt.
We zullen methode 2 analyseren, omdat deze interessanter en iets gecompliceerder is, maar meer flexibiliteit biedt bij het opzetten van de fabriek.
Laten we "PROD" toevoegen aan de VRF-topologie. Laten we interface vlan 10 eraan toevoegen op het Leaf-11/12-paar en interface VLAN 20 op Leaf-21. VLAN 20 is gekoppeld aan VNI 20000
vrf context PROD
rd auto ! Route Distinguisher Π½Π΅ ΠΏΡΠΈΠ½ΡΠΈΠΏΠΈΠ°Π»Π΅Π½ ΠΈ ΠΌΠΎΠΆΠ΅ΠΌ ΠΈΡΠΏΠΎΠ»ΡΠ·ΠΎΠ²Π°ΡΡ ΡΡΠΎΡΠΌΠΈΡΠΎΠ²Π°Π½Π½ΡΠΉ Π°Π²ΡΠΎΠΌΠ°ΡΠΈΡΠ΅ΡΠΊΠΈ
address-family ipv4 unicast
route-target both auto ! ΡΠΊΠ°Π·ΡΠ²Π°Π΅ΠΌ Route-target Ρ ΠΊΠΎΡΠΎΡΡΠΌ Π±ΡΠ΄ΡΡ ΠΈΠΌΠΏΠΎΡΡΠΈΡΠΎΠ²Π°ΡΡΡΡ ΠΈ ΡΠΊΡΠΏΠΎΡΡΠΈΡΠΎΠ²Π°ΡΡΡΡ ΠΏΡΠ΅ΡΠΈΠΊΡΡ Π²/ΠΈΠ· VRF
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 u een nieuw VLAN maken en dit aan de nieuwe VNI koppelen. De nieuwe VNI moet hetzelfde zijn op alle Leafs die geΓ―nteresseerd zijn in VLAN 10- en 20-informatie.
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! Π‘ΠΎΠ·Π΄Π°Π΅ΠΌ L3 VNI
vrf context PROD
vni 99000 ! ΠΡΠΈΠ²ΡΠ·ΡΠ²Π°Π΅ΠΌ L3 VNI ΠΊ ΠΎΠΏΡΠ΅Π΄Π΅Π»Π΅Π½Π½ΠΎΠΌΡ VRF
Als gevolg hiervan ziet het diagram er als volgt uit:
Het blijft een beetje afmaken - voeg nog een interface toe - interface vlan 99 in VRF PROD
interface Vlan99
no shutdown
vrf member PROD
ip forward ! ΠΠ° ΠΈΠ½ΡΠ΅ΡΡΠ΅ΠΉΡΠ΅ Π½Π΅ Π΄ΠΎΠ»ΠΆΠ½ΠΎ Π±ΡΡΡ IP. ΠΡΠΏΠΎΠ»ΡΠ·ΡΠ΅ΡΡΡ ΡΠΎΠ»ΡΠΊΠΎ Π΄Π»Ρ ΠΏΠ΅ΡΠ΅ΡΡΠ»ΠΊΠΈ ΠΏΠ°ΠΊΠ΅ΡΠΎΠ² ΠΌΠ΅ΠΆΠ΄Ρ Leaf
Als gevolg hiervan is de logica van het doorgeven van het frame van Host-1 naar Host-2 als volgt:
- Een frame verzonden door Host-1 arriveert op een Leaf in VLAN 10, dat is gekoppeld aan VNI 10000;
- Leaf controleert waar het bestemmingsadres is en vindt dit via L3 VNI op de tweede Leaf-switch;
- Zodra de route naar het bestemmingsadres is gevonden, verpakt de Leaf het frame in een header met de benodigde L3VNI 99000 - en stuurt deze naar de tweede Leaf;
- De tweede Leaf-switch ontvangt gegevens van L3VNI 99000. Haalt het originele frame op en brengt dit over naar de vereiste L2VNI 20000 en vervolgens naar VLAN 20.
Als resultaat van dit werk neemt L3VNI de noodzaak weg om informatie over alle VNI's die zich op het netwerk bevinden op alle Leaf-switches bij te houden.
Als gevolg hiervan, wanneer we verkeer van Host-1 naar Host-2 sturen, wordt het pakket verpakt in VxLAN met de nieuwe VNI - 99000:
Het valt nog te bezien hoe Leaf-1 precies leert over het MAC-adres van een andere VNI. Dit gebeurt ook met behulp van EVPN routetype 2 (MAC/IP).
Het volgende toont het proces van het propageren van een route over een prefix in een andere VNI:
Dat wil zeggen, adressen ontvangen van VNI 20000 hebben twee RT's.
Laat me je eraan herinneren dat de routes die zijn ontvangen van Update in de BGP-tabel vallen met het Route-doel gespecificeerd in de VRF-instellingen (het proces is iets gecompliceerder, maar we zullen niet op dit artikel ingaan).
De RT zelf wordt gevormd door de formule: AS:VNI (indien automatische modus wordt gebruikt).
Een voorbeeld van RT-vorming in automatische en handmatige modus:
vrf context PROD
address-family ipv4 unicast
route-target import auto - Π°Π²ΡΠΎΠΌΠ°ΡΠΈΡΠ΅ΡΠΊΠΈΠΉ ΡΠ΅ΠΆΠΈΠΌ ΡΠ°Π±ΠΎΡΡ
route-target export 65001:20000 - ΡΡΡΠ½ΠΎΠΉ ΡΠ΅ΠΆΠΈΠΌ ΡΠΎΡΠΌΠΈΡΠΎΠ²Π°Π½ΠΈΡ RT
Hierdoor ziet u hierboven dat voorvoegsels van een andere VNI twee RT-waarden hebben.
Een van hen 65001:99000 is een extra L3 VNI. Omdat deze VNI op alle Leafs hetzelfde is en onder onze importregels in de VRF-instellingen valt, komt het voorvoegsel in de BGP-tabel, wat te zien is aan de uitvoer:
sh bgp l2vpn evpn
<.....>
Network Next Hop Metric LocPrf Weight Path
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 ! ΠΡΠ΅ΡΠΈΠΊΡ ΠΏΠΎΠ»ΡΡΠ΅Π½Π½ΡΠΉ ΠΈΠ· VNI 20000
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 i
Als we de ontvangen update nader bekijken, kunnen we zien dat dit voorvoegsel twee RT's heeft:
Leaf11# sh bgp l2vpn evpn 5001.0008.0007
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.255.1.21:32787
BGP routing table entry for [2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.2
0]/272, version 5164
Paths: (2 available, best #2)
Flags: (0x000202) (high32 00000000) on xmit-list, is not in l2rib/evpn, is not i
n HW
Path type: internal, path is valid, not best reason: Neighbor Address, no labeled nexthop
AS-Path: NONE, path sourced internal to AS
10.255.1.20 (metric 81) from 10.255.1.102 (10.255.1.102)
Origin IGP, MED not set, localpref 100, weight 0
Received label 20000 99000 ! ΠΠ²Π° label Π΄Π»Ρ ΡΠ°Π±ΠΎΡΡ VxLAN
Extcommunity: RT:65001:20000 RT:65001:99000 SOO:10.255.1.20:0 ENCAP:8 ! ΠΠ²Π° Π·Π½Π°ΡΠ΅Π½ΠΈΡ Route-target, Π½Π° ΠΎΡΠ½ΠΎΠ²Π΅, ΠΊΠΎΡΠΎΡΡΡ
Π΄ΠΎΠ±Π°Π²ΠΈΠ»ΠΈ Π΄Π°Π½Π½ΡΠΉ ΠΏΡΠ΅ΡΠΈΠΊΡ
Router MAC:5001.0005.0007
Originator: 10.255.1.21 Cluster list: 10.255.1.102
<......>
In de routeringstabel op Leaf-1 zie je ook het voorvoegsel 192.168.20.20/32:
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
*via 10.255.1.20%default, [200/0], 01:20:20, bgp-65001, internal, tag 65001 ! ΠΠΎΡΡΡΠΏΠ½ΡΠΉ ΡΠ΅ΡΠ΅Π· Leaf-2
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! Π§Π΅ΡΠ΅Π· VNI 99000
Let op het ontbrekende primaire voorvoegsel 192.168.20.0/24 in de routeringstabel?
Dat klopt, hij is er niet. Dat wil zeggen, externe Leafs ontvangen alleen informatie over de hosts die zich op uw netwerk bevinden. En dit is het juiste gedrag. Hierboven zie je in alle updates dat er informatie komt met de inhoud van MAC/IP. Er zijn geen voorvoegsels om over te spreken.
Dit is het Host Mobility Manager (HMM)-protocol, dat de ARP-tabel vult van waaruit de BGP-tabel verder wordt gevuld (we laten dit proces achterwege in het kader van dit artikel). Op basis van de informatie ontvangen van de HMM worden routetype 2 EVPN's gevormd (verzonden door MAC / IP).
Maar wat als er informatie over een voorvoegsel moet worden doorgegeven?
Voor dit soort informatie is er EVPN-routetype 5 - hiermee kunt u prefixen verzenden via adresfamilie l2vpn evpn (dit type route is op het moment van schrijven alleen in de conceptversie
Om prefixen over te dragen, is het noodzakelijk om prefixen toe te voegen in het BGP-proces voor VRF, dat zal worden geadverteerd:
router bgp 65001
vrf PROD
address-family ipv4 unicast
redistribute direct route-map VNI20000 ! Π Π΄Π°Π½Π½ΠΎΠΌ ΡΠ»ΡΡΠ°Π΅ Π°Π½ΠΎΠ½ΡΠΈΡΡΠ΅ΠΌ ΠΏΡΠ΅ΡΠΈΠΊΡΡ ΠΏΠΎΠ΄ΠΊΠ»ΡΡΠ΅Π½ΠΈΠ΅ Π½Π΅ΠΏΠΎΡΡΠ΅Π΄ΡΡΠ²Π΅Π½Π½ΠΎ ΠΊ Leaf Π² VNI 20000
route-map VNI20000 permit 10
match ip address prefix-list VNI20000_OUT ! Π£ΠΊΠ°Π·ΡΠ²Π°Π΅ΠΌ ΠΊΠ°ΠΊΠΎΠΉ ΠΈΡΠΏΠΎΠ»ΡΠ·ΠΎΠ²Π°ΡΡ prefix-list
ip prefix-list VNI20000_OUT seq 5 permit 192.168.20.0/24 ! Π£ΠΊΠ°Π·ΡΠ²Π°Π΅ΠΌ ΠΊΠ°ΠΊΠΈΠ΅ ΡΠ΅ΡΠΈ Π±ΡΠ΄ΡΡ ΠΏΠΎΠΏΠ°Π΄Π°ΡΡ Π² EVPN route-type 5
Als gevolg hiervan zal Update zijn:
Laten we eens kijken naar de BGP-tabel. Naast EVPN-routetype 2,3 zijn er type 5-routes verschenen die informatie bevatten over het netwerknummer:
<......>
Network Next Hop Metric LocPrf Weight Path
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 Ρ Π½ΠΎΠΌΠ΅ΡΠΎΠΌ ΠΏΡΠ΅ΡΠΈΠΊΡΠ°
10.255.1.10 0 100 0 ?
* i
<.......>
Het voorvoegsel verscheen ook in de routeringstabel:
Leaf21# sh ip ro vrf PROD
192.168.10.0/24, ubest/mbest: 1/0
*via 10.255.1.10%default, [200/0], 00:14:32, bgp-65001, internal, tag 65001 ! Π£Π΄Π°Π»Π΅Π½Π½ΡΠΉ ΠΏΡΠ΅ΡΠΈΠΊΡ, Π΄ΠΎΡΡΡΠΏΠ½ΡΠΉ ΡΠ΅ΡΠ΅Π· Leaf1/2(Π°Π΄ΡΠ΅Ρ Next-hop = virtual IP ΠΌΠ΅ΠΆΠ΄Ρ ΠΏΠ°ΡΠΎΠΉ VPC)
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN ! ΠΡΠ΅ΡΠΈΠΊΡ Π΄ΠΎΡΡΡΠΏΠ΅Π½ ΡΠ΅ΡΠ΅Π· L3VNI 99000
192.168.10.10/32, ubest/mbest: 1/0
*via 10.255.1.10%default, [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
Dit concludeert het tweede deel van een reeks artikelen over VxLAN EVPN. In het volgende deel zullen we verschillende opties voor routering tussen VRF's bekijken.
Bron: www.habr.com