Kāpēc viens EVPN nomnieks var rādīt vairākus route distinguisher
Divi RD vienā nomniekā nav konflikts. Ejiet no CLI izvades līdz MAC-VRF vai IP-VRF, kas izveidoja maršrutu, pēc tam pārbaudiet RT importu un VNI.
Jūs filtrējat EVPN tabulu vienam nomniekam, un maršruti nes divus dažādus route distinguisher. Pirmā reakcija ir konfigurācijas konflikts, un šī reakcija parasti ir nepareiza. Nomnieka nosaukums ir biznesa etiķete, nevis viens vadības plaknes objekts, tāpēc tiltu konteksts un maršrutēšanas konteksts tajā var likumīgi izsludināties ar atsevišķiem identifikatoriem. Ejiet pa vienam maršrutam no izvades atpakaļ uz vietējo pakalpojuma objektu, kas to izveidoja, un otrais RD pārstāj izskatīties kā kļūda.
Sāciet ar izvadi, kas jūs sajauca
Izvēlieties vienu maršrutu, nevis visu tabulu. Pierakstiet tā maršruta tipu, RD, eksportētos route target un nākamo lēcienu. Šie četri lauki ir pietiekami, lai noteiktu, kurš vietējais objekts to izsludināja un kurai attālinātai politikai tas būtu jāimportē.
NX-OS stila ierīcē detalizētais skats tiek sasniegts ar show bgp l2vpn evpn route-type 2 detail vai show bgp l2vpn evpn route-type 5 detail. Junos sistēmā tā pati informācija ir show route table bgp.evpn.0 detail. Cita sintakse, tie paši lauki.
Nesāciet ar to, ka visi parādītie skaitļi kļūst vienādi. RD izlīdzināšana ir tā izmaiņa, kas salauž importa politiku strādājošā fabric.
Dodiet katram identifikatoram savu darbu
| Identifier | Question it answers | Where it is used |
|---|---|---|
| Route distinguisher | Which distinct route context contributed this advertisement? | Makes otherwise identical prefixes unique in BGP |
| Route target | Which importing service policy should receive the route? | Extended community matched by import policy |
| VNI | Which VXLAN service context carries the traffic? | Data plane encapsulation and mapping |
MAC-VRF glabā MAC pārsūtīšanas informāciju tilta pakalpojumam. IP-VRF nodrošina IP maršrutēšanas kontekstu maršrutētam pakalpojumam. Nomnieks var ietvert abus, tāpēc viens nomnieks var radīt vairāk nekā vienu RD bez jebkādas konfigurācijas kļūdas.
RFC 7432 piešķir izsludinošā MAC-VRF RD tā EVPN NLRI un pieprasa atšķirīgus RD starp MAC-VRF tajā pašā PE. Route-target procedūras ir atsevišķas: tās pieļauj vienu vai vairākus RT atribūtus un dalībai paļaujas uz importa politiku. Kopīgu dalību nerada RD vienlīdzība, un šāda attieksme ir šī apjukuma sakne.
Izejiet vienu maršrutu no izsludināšanas līdz importam
Sekojiet maršrutam vienā virzienā. Apstipriniet maršruta tipu, to izveidojušo pakalpojumu, RD, eksportētos RT un tad saņēmēja PE importa politiku. Katrs solis atbild uz citu jautājumu, un neveiksme jebkurā solī izskatās kā tas pats trūkstošais prefikss otrā pusē.
Kad maršruts ir klāt, apskatiet instalēto pārsūtīšanas kontekstu un VNI kartējumu. VNI sakritība abos galos parāda, ka datu plakne piekrīt; tā neparāda, ka vadības plakne importēja maršrutu ar paredzēto politiku.
Ja maršruts parādās attālinātajā PE, bet satiksme neplūst, problēma ir pārsniegusi EVPN. Pārbaudiet VNI-uz-VLAN vai VNI-uz-VRF saistījumu un underlay ceļu, pirms atkal rediģējat route target. Sāciet ar kartējumu, tad underlay un tikai pēc tam vadības plakni. Route-target izmaiņu atsaukšana, lai izsekotu datu plaknes kļūmi, ir uzticams veids, kā salauzt strādājošu importu.
3. slāņa prefiksi joprojām ir EVPN maršruti
IP prefikss EVPN tabulā nav parasts IPv4-unicast BGP. EVPN IP Prefix maršruts ir atsevišķs maršruta tips, un MAC/IP un IP prefiksa izsludinājumi ceļo EVPN adrešu saimē, ko RFC 7432 norāda kā AFI 25 un SAFI 70.
Šī atšķirība ir svarīga, kad salīdzināt maršrutu EVPN tabulā ar maršrutu unicast tabulā. Tie var aprakstīt vienu un to pašu galamērķi un tomēr tikt radīti, filtrēti un importēti ar atšķirīgu politiku. Viena lasīšana kā pierādījums par otru ir tas, kāpēc pareizs fabric migrācijas laikā izskatās salauzts.
Pirms skaitļu salīdzināšanas pārbaudiet ražotāja atvasinājumu
RFC 9136 paplašina EVPN ar IP Prefix maršrutiem un norāda, vai piemērojamais RD nāk no MAC-VRF vai IP-VRF konteksta. Tāpēc L2 pakalpojuma etiķete un maršrutētā pakalpojuma etiķete vienā izvadē ir jālasa attiecībā pret objektiem, kuriem tās pieder, nevis jāsamazina līdz vienam RD uz nomnieku.
Automātiskā RD un RT atvasināšana ir ražotāja specifiska. Lasiet izvietotā ražotāja atsauci par izmantoto formulu; vienā komutatorā redzētā automātiski ģenerētā vērtība nav universāls kodējums, un divu ražotāju skaitļu salīdzināšana reti ko pierāda.
Pabeidziet ar rakstisku pēdu maršrutam, ar kuru sākāt: tips, izveidojušais objekts, RD, eksportētais RT, importa politika, instalētais VNI. Seši lauki izskaidro izsludinājumu ikvienam, kas lasīs biļeti nākamreiz, un neviens no tiem neprasa, lai nomnieka skaitļi sakristu.