Čau, Habr. Turpinu rakstu sēriju par VxLAN EVPN tehnoloģiju, kas tika rakstīti speciāli kursa uzsākšanai
Pēdējā daļā mēs panācām vienu apraides domēnu, kas tika izveidots uz Nexus 9000v tīkla auduma. Tomēr tas nav viss uzdevumu loks, kas jārisina datu centru tīkla ietvaros. Un šodien mēs apsvērsim šādu uzdevumu - maršrutēšanu starp tīkliem vai starp VNI.
Atgādināšu, ka tiek izmantota Spine-Leaf topoloģija:
Sākumā mēs analizēsim, kā notiek maršrutēšana un kādas funkcijas tai ir.
Lai saprastu, vienkāršosim loģisko diagrammu un pievienosim vēl vienu VNI 20000 Host-2. Rezultāts ir:
Kā šajā gadījumā var pārsūtīt trafiku no viena resursdatora uz citu?
Ir divas iespējas:
- Saglabājiet informāciju par visiem VNI visos Leaf slēdžos, tad visa maršrutēšana notiks pirmajā tīkla lapā;
- Izmantojiet īpašu - L3 VNI
Pirmais veids ir vienkāršs un ērts. Tā kā jums ir jāuzsāk tikai visi VNI uz visiem Leaf slēdžiem. Tomēr dažu simtu vai tūkstošu VNI palaišana uz visas Leaf vairs nešķiet viegls uzdevums. Tāpēc darbā tas tiek izmantots diezgan reti.
Mēs analizēsim 2. metodi kā interesantāku un nedaudz sarežģītāku, bet dodot lielāku elastību rūpnīcas iekārtošanā.
Pievienosim "PROD" VRF topoloģijai. Pievienosim tam saskarni vlan 10 uz Leaf-11/12 pāra un interfeisu VLAN 20 uz Leaf-21. VLAN 20 ir saistīts ar 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
Lai izmantotu L3VNI, jāizveido jauns VLAN, jāsaista tas ar jauno VNI. Jaunajam VNI ir jābūt vienādam visās Leafs, kuras interesē VLAN 10 un 20 informācija.
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! Создаем L3 VNI
vrf context PROD
vni 99000 ! Привязываем L3 VNI к определенному VRF
Rezultātā diagramma izskatīsies šādi:
Atliek nedaudz pabeigt - pievienojiet vēl vienu interfeisu - interfeisu vlan 99 VRF PROD
interface Vlan99
no shutdown
vrf member PROD
ip forward ! На интерфейсе не должно быть IP. Используется только для пересылки пакетов между Leaf
Rezultātā kadra nodošanas loģika no Host-1 uz Host-2 ir šāda:
- Host-1 sūtīts rāmis nonāk VLAN 10 lapā, kas ir saistīta ar VNI 10000;
- Leaf pārbauda, kur atrodas galamērķa adrese, un atrod to, izmantojot L3 VNI uz otrā Leaf slēdža;
- Tiklīdz tiek atrasts maršruts uz galamērķa adresi, Leaf iesaiņo rāmi galvenē ar nepieciešamo L3VNI 99000 - un nosūta to uz otro lapu;
- Otrais Leaf slēdzis saņem datus no L3VNI 99000. Iegūst sākotnējo kadru un pārsūta to uz nepieciešamo L2VNI 20000 un pēc tam uz VLAN 20.
Šī darba rezultātā L3VNI novērš nepieciešamību saglabāt informāciju par visiem tīklā esošajiem VNI visos Leaf slēdžos.
Rezultātā, nosūtot trafiku no Host-1 uz Host-2, pakete tiek iesaiņota VxLAN iekšienē ar jauno VNI - 99000:
Jāskatās, kā tieši Leaf-1 uzzina par MAC adresi no cita VNI. Tas notiek arī ar EVPN maršruta tipa 2 (MAC / IP) palīdzību.
Tālāk ir parādīts maršruta izplatīšanas process par prefiksu, kas atrodas citā VNI:
Tas ir, no VNĪ 20000 saņemtajām adresēm ir divi RT.
Atgādināšu, ka no Update saņemtie maršruti iekrīt BGP tabulā ar VRF iestatījumos norādīto Route-target (process ir nedaudz sarežģītāks, taču šajā rakstā neiedziļināsimies).
Pati RT veido pēc formulas: AS:VNI (ja tiek izmantots automātiskais režīms).
RT veidošanas piemērs automātiskajā un manuālajā režīmā:
vrf context PROD
address-family ipv4 unicast
route-target import auto - автоматический режим работы
route-target export 65001:20000 - ручной режим формирования RT
Rezultātā iepriekš varat redzēt, ka prefiksiem no cita VNI ir divas RT vērtības.
Viens no tiem 65001:99000 ir papildu L3 VNI. Tā kā šis VNI ir vienāds visās lapās un uz to attiecas mūsu importēšanas noteikumi VRF iestatījumos, prefikss tiek ievietots BGP tabulā, ko var redzēt no izvades:
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
Ja aplūkojam saņemto atjauninājumu rūpīgāk, mēs varam redzēt, ka šim prefiksam ir divi RT:
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
<......>
Maršrutēšanas tabulā lapā Leaf-1 varat redzēt arī prefiksu 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
Vai pamanāt maršrutēšanas tabulā trūkstošo primāro prefiksu 192.168.20.0/24?
Tieši tā, viņa tur nav. Tas nozīmē, ka attālās lapas saņem informāciju tikai par resursdatoriem, kas atrodas jūsu tīklā. Un tā ir pareiza uzvedība. Iepriekš visos atjauninājumos varat redzēt, ka informācija tiek piegādāta kopā ar MAC / IP saturu. Nav prefiksu, par ko runāt.
Šis ir Host Mobility Manager (HMM) protokols, kas aizpilda ARP tabulu, no kuras tālāk tiek aizpildīta BGP tabula (šī raksta ietvaros mēs šo procesu izlaidīsim). Pamatojoties uz informāciju, kas saņemta no HMM, tiek izveidots EVPN maršruta tips 2 (pārsūta MAC / IP).
Tomēr, ja ir nepieciešams nodot informāciju par prefiksu?
Šāda veida informācijai ir EVPN maršruta tips 5 - tas ļauj nosūtīt prefiksus, izmantojot adresi-family l2vpn evpn (šāda veida maršruts šī rakstīšanas laikā ir tikai melnraksta versijā
Lai pārsūtītu prefiksus, VRF BGP procesā ir jāpievieno prefiksi, kas tiks reklamēti:
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
Rezultātā atjauninājums būs:
Apskatīsim BGP tabulu. Papildus EVPN maršruta tipam 2,3 ir parādījušies 5. tipa maršruti, kas satur informāciju par tīkla numuru:
<......>
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
<.......>
Prefikss parādījās arī maršrutēšanas tabulā:
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
Ar to tiek noslēgta VxLAN EVPN rakstu sērijas otrā daļa. Nākamajā daļā mēs apsvērsim dažādas maršrutēšanas iespējas starp VRF.
Avots: www.habr.com