Hei, Habr. Jatkan VxLAN EVPN -teknologiaa käsittelevää artikkelisarjaa, joka on kirjoitettu nimenomaan kurssin käynnistämistä varten OTUS:lta. Ja tänään tarkastelemme mielenkiintoista osaa tehtävästä - reititystä. Kuulostaapa se kuinka triviaalilta tahansa, verkkotehtaan työn puitteissa kaikki ei kuitenkaan välttämättä ole niin yksinkertaista.
Viimeisessä osassa saavutimme Nexus 9000v:n verkkokankaan päälle rakennetun lähetysalueen. Tämä ei kuitenkaan ole koko joukko tehtäviä, jotka on ratkaistava konesaliverkon sisällä. Ja tänään tarkastelemme seuraavaa tehtävää - reititystä verkkojen välillä tai VNI:iden välillä.
Haluan muistuttaa, että käytetään Spine-Leaf-topologiaa:
Katsotaanpa ensin, miten reititys tapahtuu ja mitä ominaisuuksia sillä on.
Ymmärtääksemme yksinkertaistetaan logiikkakaaviota ja lisätään toinen VNI 20000 Host-2:lle. Tulos on:
Kuinka tässä tapauksessa voit siirtää liikennettä isännästä toiseen?
On kaksi vaihtoehtoa:
- Säilytä tiedot kaikista VNI:istä kaikissa Leaf-kytkimissä, jolloin kaikki reititys tapahtuu verkon ensimmäisessä Leafissa;
- Käytä erillistä L3 VNI:tä
Ensimmäinen menetelmä on yksinkertainen ja kätevä. Koska sinun tarvitsee vain asentaa kaikki VNI kaikkiin Leaf-kytkimiin. Useiden satojen tai tuhansien VNI:iden määrittäminen kaikille Leafeille ei kuitenkaan enää vaikuta yksinkertaiselta tehtävältä. Siksi sitä käytetään melko harvoin työssä.
Katsotaanpa menetelmää 2, joka on mielenkiintoisempi ja hieman monimutkaisempi, mutta antaa enemmän joustavuutta tehtaan perustamisessa.
Lisätään "PROD" VRF-topologiaan. Siihen lisäämme rajapinnan vlan 10 Leaf-11/12 pariin ja rajapinnan VLAN 20 Leaf-21:een. VLAN 20 liittyy VNI 20000:een
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-gatewayJotta voit käyttää L3VNI:tä, sinun on luotava uusi VLAN ja liitettävä se uuteen VNI:hen. Uuden VNI:n on oltava sama kaikilla VLAN 10- ja 20-tiedoista kiinnostuneilla lehdillä
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! Создаем L3 VNI
vrf context PROD
vni 99000 ! Привязываем L3 VNI к определенному VRFTämän seurauksena kaavio näyttää tältä:
Vielä on tehtävä vähän - lisää vielä yksi käyttöliittymä - käyttöliittymä vlan 99 VRF PROD:ssa
interface Vlan99
no shutdown
vrf member PROD
ip forward ! На интерфейсе не должно быть IP. Используется только для пересылки пакетов между LeafTämän seurauksena logiikka kehyksen välittämiseksi isäntä-1:ltä isäntä-2:lle on seuraava:
- Isäntä-1:n lähettämä kehys saapuu Leafiin VLAN 10:ssä, joka liittyy VNI 10000:een;
- Leaf tarkistaa missä kohdeosoite on ja löytää sen L3 VNI:n kautta toisesta Leaf-kytkimestä;
- Heti kun reitti kohdeosoitteeseen löytyy, Leaf pakkaa kehyksen otsikkoon, jossa on tarvittava L3VNI 99000 - ja lähettää sen kohti toista Leafia;
- Toinen Leaf-kytkin vastaanottaa tietoja L3VNI 99000:sta. Se ottaa alkuperäisen kehyksen ja siirtää sen vaadittuun L2VNI 20000:een ja sitten VLAN 20:een.
Tämän työn tuloksena L3VNI poistaa tarpeen säilyttää tietoja kaikista verkossa olevista VNI:istä kaikissa Leaf-kytkimissä.
Tämän seurauksena, kun lähetämme liikennettä isäntä-1:ltä isäntä-2:lle, paketti pakataan VxLANin sisään uudella VNI-99000:lla:
Jää nähtäväksi, kuinka tarkasti Leaf-1 oppii MAC-osoitteen toisesta VNI:stä. Tämä tapahtuu myös käyttämällä EVPN-reititystyyppiä 2 (MAC/IP).
Seuraavassa näkyy prosessi, jolla reitti levitetään toisessa VNI:ssä sijaitsevan etuliitettä kohti:
Eli VNI 20000:lta vastaanotetuilla osoitteilla on kaksi RT:tä.
Muistutan, että Updatesta saadut reitit päätyvät BGP-taulukkoon VRF-asetuksissa määritetyllä Route-targetilla (prosessi on hieman monimutkaisempi, mutta emme syvenny tähän artikkeliin).
Itse RT muodostetaan kaavan mukaan: AS:VNI (jos käytetään automaattista tilaa).
Esimerkki RT:n muodostamisesta automaattisessa ja manuaalisessa tilassa:
vrf context PROD
address-family ipv4 unicast
route-target import auto - автоматический режим работы
route-target export 65001:20000 - ручной режим формирования RTYllä oleva tulos osoittaa, että toisen VNI:n etuliitteillä on kaksi RT-arvoa.
Yksi niistä on 65001:99000 - ylimääräinen L3 VNI. Koska tämä VNI on sama kaikilla lehdillä ja kuuluu tuontisääntöjemme alle VRF-asetuksissa, etuliite päätyy BGP-taulukkoon, joka näkyy tulosteesta:
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 iJos tarkastelemme lähemmin vastaanotettua päivitystä, voimme nähdä, että tällä etuliitteellä on kaksi RT:tä:
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
<......>Leaf-1:n reititystaulukossa näkyy myös etuliite 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 99000Huomasitko pääetuliitettä 192.168.20.0/24 puuttuvan reititystaulukosta?
Aivan oikein, hän ei ole siellä. Toisin sanoen etälehdet vastaanottavat tietoja vain verkossasi olevista isännistä. Ja tämä on oikeaa käytöstä. Kaikkien päivitysten yläpuolella näet, että tiedot tulevat MAC/IP-sisällön mukana. Ei puhuta mistään etuliitteistä.
Näin toimii Host Mobility Manager (HMM) -protokolla, joka täyttää ARP-taulukon, josta BGP-taulukko sitten täytetään (jätämme tämän prosessin pois tässä artikkelissa). HMM:ltä saatujen tietojen perusteella muodostetaan EVPN-reittityyppi 2 (lähettää MAC/IP:n).
Entä jos etuliitettä koskevia tietoja on kuitenkin lähetettävä?
Tämän tyyppisille tiedoille on olemassa EVPN-reittityyppi 5 - sen avulla voit lähettää etuliitteitä osoiteperheen kautta l2vpn evpn (tämän tyyppiset reitit ovat kirjoitushetkellä vain luonnosversiossa Tämän vuoksi tämän tyyppisen reitin käyttäytyminen voi vaihdella eri valmistajien välillä)
Etuliitteiden lähettämiseksi on tarpeen lisätä etuliitteitä, joita mainostetaan BGP-prosessissa VRF:lle:
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 5Tämän seurauksena päivityksessä on:
Katsotaanpa BGP-taulukkoa. EVPN-reittityypin 2,3 lisäksi on ilmestynyt tyypin 5 reitit, jotka sisältävät tietoa verkkonumerosta:
<......>
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
<.......> Etuliite ilmestyi myös reititystaulukkoon:
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, hmmTämä päättää VxLAN EVPN -artikkelisarjan toisen osan. Seuraavassa osassa tarkastellaan erilaisia vaihtoehtoja reitittämiseen VRF:ien välillä.
Lähde: will.com