Kial unu EVPN-luanto povas montri plurajn route distinguisher
Du RD en unu luanto ne estas konflikto. Iru de la CLI-eligo al la MAC-VRF aŭ IP-VRF, kiu kreis la itineron, poste kontrolu la RT-importon kaj la VNI.
Vi filtradas la EVPN-tabelon por unu luanto, kaj la itineroj portas du malsamajn route distinguisher. La unua instinkto estas konfigura konflikto, kaj tiu instinkto kutime malpravas. Luanta nomo estas komerca etikedo, ne unu sola objekto de la rega ebeno, do la ponta kunteksto kaj la enkursiga kunteksto ene de ĝi povas laŭleĝe anonci sub apartaj identigiloj. Iru unu itineron samtempe de la eligo reen al la loka servo-objekto, kiu ĝin kreis, kaj la dua RD ĉesas aspekti kiel eraro.
Komencu ĉe la eligo, kiu konfuzis vin
Elektu unu itineron anstataŭ la tuta tabelo. Notu ĝian itineran tipon, ĝian RD, la eksportitajn route target kaj la sekvan salteton. Tiuj kvar kampoj sufiĉas por identigi, kiu loka objekto anoncis ĝin kaj kiu fora politiko devus importi ĝin.
Sur aparato NX-OS-stila la detala vido atingiĝas per show bgp l2vpn evpn route-type 2 detail aŭ show bgp l2vpn evpn route-type 5 detail. Sur Junos la sama informo troviĝas en show route table bgp.evpn.0 detail. Malsama sintakso, samaj kampoj.
Ne komencu per egaligo de ĉiu montrata nombro. Egaligi RD-ojn estas la ŝanĝo, kiu rompas la importan politikon sur funkcianta fabric.
Donu al ĉiu identigilo sian taskon
| 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 tenas MAC-plusendajn informojn por ponta servo. IP-VRF provizas IP-enkursigan kuntekston por enkursigita servo. Luanto povas enhavi ambaŭ, tial unu luanto povas produkti pli ol unu RD sen iu ajn misagordo.
RFC 7432 atribuas la RD-on de la anoncanta MAC-VRF al ĝia EVPN NLRI kaj postulas malsamajn RD-ojn inter MAC-VRF-oj sur la sama PE. Route-target-proceduroj estas apartaj: ili permesas unu aŭ plurajn RT-atributojn kaj fidas la importan politikon por membreco. RD-egaleco ne estas tio, kio kreas komunan membrecon, kaj trakti ĝin tiel estas la radiko de ĉi tiu konfuzo.
Iru unu itineron de anonco al importo
Sekvu la itineron en unu direkto. Konfirmu la itineran tipon, la servon, kiu ĝin kreis, la RD-on, la eksportitajn RT-ojn kaj poste la importan politikon sur la ricevanta PE. Ĉiu paŝo respondas al malsama demando, kaj malsukceso ĉe iu ajn paŝo aspektas kiel la sama mankanta prefikso sur la alia flanko.
Post kiam la itinero ĉeestas, inspektu la instalitan plusendan kuntekston kaj la VNI-mapadon. Kongrua VNI ĉe ambaŭ finoj montras, ke la datena ebeno konsentas; ĝi ne montras, ke la rega ebeno importis la itineron per la celita politiko.
Se la itinero aperas sur la fora PE sed neniu trafiko fluas, la problemo moviĝis preter EVPN. Kontrolu la ligon VNI-al-VLAN aŭ VNI-al-VRF kaj la underlay-vojon antaŭ ol denove redakti route target. Komencu ĉe la mapado, poste la underlay kaj nur poste la rega ebeno. Malfari route-target-ŝanĝon por ĉasi daten-ebenan paneon estas fidinda maniero rompi funkciantan importon.
Prefiksoj de tavolo 3 ankoraŭ estas EVPN-itineroj
IP-prefikso en la EVPN-tabelo ne estas ordinara IPv4-unicast BGP. La itinero EVPN IP Prefix estas propra itinera tipo, kaj anoncoj de MAC/IP kaj IP-prefikso vojaĝas en la EVPN-adresfamilio, kiun RFC 7432 identigas kiel AFI 25 kaj SAFI 70.
Tiu distingo gravas, kiam vi komparas itineron en la EVPN-tabelo kun unu en la unicast-tabelo. Ili povas priskribi la saman celon kaj tamen esti produktitaj, filtritaj kaj importitaj per malsama politiko. Legi unu kiel pruvon pri la alia estas kiel ĝusta fabric aspektas rompita dum migrado.
Kontrolu la derivadon de la vendisto antaŭ kompari nombrojn
RFC 9136 etendas EVPN per IP Prefix-itineroj kaj precizigas, ĉu la aplikebla RD venas de la MAC-VRF aŭ IP-VRF-kunteksto. Tial L2-servo-etikedo kaj etikedo de enkursigita servo en la sama eligo devus esti legataj rilate al la objektoj, al kiuj ili apartenas, ne reduktitaj al unu RD por luanto.
Aŭtomata derivado de RD kaj RT estas vendisto-specifa. Legu la referencon de la deplojita vendisto pri la uzata formulo; aŭtomate generita valoro vidita sur unu ŝaltilo ne estas universala kodigo, kaj kompari la nombrojn de du vendistoj malofte pruvas ion.
Finu per skribita spuro por la itinero, per kiu vi komencis: tipo, origina objekto, RD, eksportita RT, importa politiko, instalita VNI. Ses kampoj klarigas la anoncon al ĉiu, kiu legos la bileton poste, kaj neniu el ili postulas, ke la nombroj de la luanto kongruu.