Bakit ang isang EVPN tenant ay maaaring magpakita ng maraming route distinguisher
Dalawang RD sa isang tenant ay hindi kontrahan. Sundan mula sa CLI output hanggang sa MAC-VRF o IP-VRF na gumawa ng ruta, pagkatapos suriin ang RT import at VNI.
Sinasala mo ang talahanayan ng EVPN para sa isang tenant, at ang mga ruta ay may dalawang magkaibang route distinguisher. Ang unang reaksyon ay kontrahan sa configuration, at ang reaksyong iyon ay karaniwang mali. Ang pangalan ng tenant ay isang business label, hindi isang solong object ng control plane, kaya ang bridging context at ang routing context sa loob nito ay maaaring legal na mag-anunsyo sa ilalim ng magkahiwalay na identifiers. Sundan ang isang ruta sa bawat pagkakataon mula sa output pabalik sa lokal na service object na gumawa nito, at ang pangalawang RD ay titigil sa pagmumukhang pagkakamali.
Simulan sa output na nagpagulo sa iyo
Pumili ng isang ruta sa halip na ang buong talahanayan. Itala ang uri ng ruta, ang RD, ang mga na-export na route target at ang susunod na hop. Sapat ang apat na field na iyon para matukoy kung aling lokal na object ang nag-anunsyo nito at aling remote policy ang dapat mag-import nito.
Sa isang device na NX-OS ang estilo, ang detalyadong view ay nakukuha sa show bgp l2vpn evpn route-type 2 detail o show bgp l2vpn evpn route-type 5 detail. Sa Junos, ang parehong impormasyon ay nasa show route table bgp.evpn.0 detail. Iba ang syntax, pareho ang mga field.
Huwag magsimula sa paggawang pantay ang bawat numerong ipinapakita. Ang pagpapantay ng mga RD ang pagbabagong sumisira sa import policy sa isang gumaganang fabric.
Bigyan ang bawat identifier ng kanyang trabaho
| 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 |
Ang MAC-VRF ay nagtatago ng impormasyon ng pagpapasa ng MAC para sa isang bridging service. Ang IP-VRF ay nagbibigay ng routing context ng IP para sa isang routed service. Maaaring isama ng isang tenant ang pareho, kaya ang isang tenant ay makakagawa ng higit sa isang RD nang walang anumang maling configuration.
Itinatalaga ng RFC 7432 ang RD ng nag-anunsyong MAC-VRF sa EVPN NLRI nito at nangangailangan ng magkaibang RD sa mga MAC-VRF sa parehong PE. Hiwalay ang mga pamamaraan ng route-target: pinapayagan nila ang isa o higit pang RT attribute at umaasa sa import policy para sa membership. Ang pagkakapantay ng RD ay hindi ang lumilikha ng shared membership, at ang pagtrato dito nang ganoon ang ugat ng kalituhang ito.
Sundan ang isang ruta mula sa announcement hanggang sa import
Sundin ang ruta sa isang direksyon. Kumpirmahin ang uri ng ruta, ang service na gumawa nito, ang RD, ang mga na-export na RT, at pagkatapos ang import policy sa PE na tumatanggap. Bawat hakbang ay sumasagot sa ibang tanong, at ang pagkabigo sa alinmang hakbang ay mukhang parehong nawawalang prefix sa kabilang panig.
Kapag naroon na ang ruta, siyasatin ang naka-install na forwarding context at ang VNI mapping. Ang pagtugma ng VNI sa magkabilang dulo ay nagpapakita na sang-ayon ang data plane; hindi nito ipinapakita na in-import ng control plane ang ruta sa pamamagitan ng inaasahang policy.
Kung lumitaw ang ruta sa remote PE pero walang trapikong dumadaloy, lumampas na ang problema sa EVPN. Suriin ang binding ng VNI-sa-VLAN o VNI-sa-VRF at ang landas ng underlay bago muling i-edit ang route target. Magsimula sa mapping, pagkatapos ang underlay, at pagkatapos lamang ang control plane. Ang pag-rollback ng pagbabago sa route-target para habulin ang sira ng data plane ay isang maaasahang paraan ng pagsira sa gumaganang import.
Ang mga prefix ng layer 3 ay mga ruta pa rin ng EVPN
Ang IP prefix sa talahanayan ng EVPN ay hindi ordinaryong IPv4-unicast BGP. Ang rutang EVPN IP Prefix ay sarili nitong uri ng ruta, at ang mga anunsyo ng MAC/IP at IP-prefix ay naglalakbay sa pamilya ng address ng EVPN, na tinutukoy ng RFC 7432 bilang AFI 25 at SAFI 70.
Mahalaga ang pagkakaibang iyon kapag inihahambing mo ang isang ruta sa talahanayan ng EVPN sa isa sa talahanayan ng unicast. Maaari nilang ilarawan ang parehong destinasyon at gayon pa man ay magawa, masala at ma-import ng magkaibang policy. Ang pagbasa sa isa bilang ebidensya tungkol sa isa pa ang dahilan kung bakit ang tamang fabric ay mukhang sira sa panahon ng migration.
Suriin ang derivation ng vendor bago ihambing ang mga numero
Pinalalawak ng RFC 9136 ang EVPN gamit ang mga rutang IP Prefix at tinutukoy kung ang naaangkop na RD ay nagmumula sa MAC-VRF o IP-VRF context. Kaya ang isang L2 service label at isang routed service label sa parehong output ay dapat basahin laban sa mga object na kinabibilangan nila, hindi bawasan sa isang RD kada tenant.
Ang awtomatikong derivation ng RD at RT ay vendor-specific. Basahin ang reference ng naka-deploy na vendor para sa formula na ginagamit; ang awtomatikong nabuong halaga na nakita sa isang switch ay hindi universal encoding, at ang paghahambing ng mga numero ng dalawang vendor ay bihirang magpatunay ng anuman.
Tapusin gamit ang nakasulat na trace para sa rutang sinimulan mo: uri, object na pinagmulan, RD, na-export na RT, import policy, naka-install na VNI. Anim na field ang nagpapaliwanag ng anunsyo sa sinumang susunod na magbabasa ng ticket, at wala sa mga ito ang nangangailangan na magtugma ang mga numero ng tenant.