Чаму адзін арэндакар EVPN можа паказваць некалькі route distinguisher
Два RD у адным арэндакары — не канфлікт. Прайдзіце ад вываду CLI да MAC-VRF або IP-VRF, які стварыў маршрут, затым праверце імпарт RT і VNI.
Вы фільтруеце табліцу EVPN для аднаго арэндакара, і маршруты нясуць два розныя route distinguisher. Першая думка — канфлікт канфігурацыі, і звычайна гэтая думка памылковая. Імя арэндакара — гэта бізнес-метка, а не адзіны аб'ект плоскасці кіравання, таму кантэкст маставання і кантэкст маршрутызацыі ўнутры яго могуць цалкам законна абвяшчацца пад асобнымі ідэнтыфікатарамі. Праходзьце па адным маршруце за раз ад вываду назад да лакальнага аб'екта паслугі, які яго стварыў, і другі RD перастане выглядаць як памылка.
Пачніце з вываду, які вас зблытаў
Выберыце адзін маршрут, а не ўсю табліцу. Занатуйце яго тып маршруту, яго RD, экспартаваныя route target і наступны хоп. Гэтых чатырох палёў дастаткова, каб вызначыць, які лакальны аб'ект яго абвясціў і якая аддаленая палітыка павінна яго імпартаваць.
На прыладзе ў стылі NX-OS дэталёвы прагляд адкрываецца камандай show bgp l2vpn evpn route-type 2 detail або show bgp l2vpn evpn route-type 5 detail. На Junos тая ж інфармацыя знаходзіцца ў show route table bgp.evpn.0 detail. Іншы сінтаксіс, тыя ж палі.
Не пачынайце з таго, каб зрабіць усе паказаныя лікі роўнымі. Ураўноўванне RD — гэта змена, якая ламае палітыку імпарту на працоўным fabric.
Дайце кожнаму ідэнтыфікатару сваю працу
| 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 захоўвае інфармацыю перасылкі MAC для паслугі маставання. IP-VRF дае кантэкст маршрутызацыі IP для маршрутызаванай паслугі. Арэндакар можа ўключаць абодва, таму адзін арэндакар можа стварыць больш за адзін RD без якой-небудзь памылкі канфігурацыі.
RFC 7432 прызначае RD аб'яўляючага MAC-VRF яго EVPN NLRI і патрабуе розных RD сярод MAC-VRF на адным PE. Працэдуры route-target асобныя: яны дазваляюць адзін або некалькі атрыбутаў RT і спадзяюцца на палітыку імпарту для членства. Роўнасць RD — не тое, што стварае супольнае членства, і менавіта такое стаўленне з'яўляецца коранем гэтай блытаніны.
Прайдзіце адзін маршрут ад аб'явы да імпарту
Ідзіце па маршруце ў адным кірунку. Пацвердзіце тып маршруту, паслугу-крыніцу, RD, экспартаваныя RT, а затым палітыку імпарту на прымаючым PE. Кожны крок адказвае на іншае пытанне, і збой на любым кроку выглядае як той жа адсутны прэфікс на іншым баку.
Калі маршрут прысутнічае, аглядзіце ўсталяваны кантэкст перасылкі і адлюстраванне VNI. Супадзенне VNI на абодвух канцах паказвае, што плоскасць даных згодная; яно не паказвае, што плоскасць кіравання імпартавала маршрут праз прызначаную палітыку.
Калі маршрут з'яўляецца на аддаленым PE, але трафік не ідзе, праблема выйшла за межы EVPN. Праверце прывязку VNI да VLAN або VNI да VRF і шлях underlay, перш чым зноў рэдагаваць route target. Пачніце з адлюстравання, затым underlay, і толькі потым плоскасць кіравання. Адкат змены route-target для пошуку няспраўнасці плоскасці даных — надзейны спосаб зламаць працоўны імпарт.
Прэфіксы ўзроўню 3 па-ранейшаму з'яўляюцца маршрутамі EVPN
Прэфікс IP у табліцы EVPN — не звычайны BGP IPv4-unicast. маршрут EVPN IP Prefix — гэта ўласны тып маршруту, а аб'явы MAC/IP і IP-прэфіксаў ідуць у сямействе адрасоў EVPN, якое RFC 7432 вызначае як AFI 25 і SAFI 70.
Гэтае адрозненне важнае, калі вы параўноўваеце маршрут у табліцы EVPN з маршрутам у табліцы unicast. Яны могуць апісваць адзін і той жа пункт прызначэння і ўсё ж стварацца, фільтравацца і імпартавацца рознымі палітыкамі. Чытанне аднаго як доказу пра іншае — гэта тое, як правільны fabric выглядае зламаным падчас міграцыі.
Праверце вытворнасць пастаўшчыка, перш чым параўноўваць лікі
RFC 9136 пашырае EVPN маршрутамі IP Prefix і ўказвае, ці паходзіць адпаведны RD з кантэксту MAC-VRF або IP-VRF. Таму метку паслугі L2 і метку маршрутызаванай паслугі ў адным вывадзе трэба чытаць адносна аб'ектаў, якім яны належаць, а не зводзіць да аднаго RD на арэндакара.
Аўтаматычная вытворнасць RD і RT залежыць ад пастаўшчыка. Чытайце даведнік разгорнутага пастаўшчыка пра формулу, якая выкарыстоўваецца; аўтаматычна згенераванае значэнне, убачанае на адным камутатары, не з'яўляецца ўніверсальным кадаваннем, і параўнанне лікаў двух пастаўшчыкоў рэдка штосьці даказвае.
Скончыце пісьмовым следам для маршруту, з якога вы пачалі: тып, аб'ект-крыніца, RD, экспартаваны RT, палітыка імпарту, усталяваны VNI. Шэсць палёў тлумачаць аб'яву кожнаму, хто будзе чытаць заяўку наступным, і ні адзін з іх не патрабуе, каб лікі арэндакара супадалі.