ഒരു 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 പ്രഖ്യാപിക്കുന്ന MAC-VRF-ന്റെ RD അതിന്റെ EVPN NLRI-യ്ക്ക് നൽകുന്നു, ഒരേ PE-യിലെ MAC-VRF-കൾക്കിടയിൽ വ്യത്യസ്ത RD ആവശ്യപ്പെടുന്നു. route-target നടപടിക്രമങ്ങൾ വെവ്വേറെയാണ്: ഒന്നോ അതിലധികമോ RT ആട്രിബ്യൂട്ടുകൾ അനുവദിക്കുകയും അംഗത്വത്തിന് ഇംപോർട്ട് നയത്തെ ആശ്രയിക്കുകയും ചെയ്യുന്നു. പങ്കിട്ട അംഗത്വം സൃഷ്ടിക്കുന്നത് RD സമത്വമല്ല, അങ്ങനെ കാണുന്നതാണ് ഈ ആശയക്കുഴപ്പത്തിന്റെ വേര്.
പ്രഖ്യാപനത്തിൽ നിന്ന് ഇംപോർട്ട് വരെ ഒരു റൂട്ട് പിന്തുടരുക
ഒരു ദിശയിൽ റൂട്ട് പിന്തുടരുക. റൂട്ട് തരം, അത് സൃഷ്ടിച്ച സേവനം, RD, കയറ്റുമതി ചെയ്ത RT-കൾ, തുടർന്ന് സ്വീകരിക്കുന്ന PE-യിലെ ഇംപോർട്ട് നയം എന്നിവ സ്ഥിരീകരിക്കുക. ഓരോ ഘട്ടവും വ്യത്യസ്ത ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു, ഏതെങ്കിലും ഘട്ടത്തിലെ പരാജയം മറുവശത്ത് അതേ കാണാത്ത പ്രിഫിക്സ് പോലെ തോന്നും.
റൂട്ട് ഉള്ളപ്പോൾ ഇൻസ്റ്റാൾ ചെയ്ത ഫോർവേഡിംഗ് സന്ദർഭവും VNI മാപ്പിംഗും പരിശോധിക്കുക. ഇരുവശത്തും VNI ഒത്തുപോകുന്നത് ഡാറ്റ പ്ലെയിൻ യോജിക്കുന്നു എന്ന് കാണിക്കുന്നു; നിയന്ത്രണ പ്ലെയിൻ ഉദ്ദേശിച്ച നയത്തിലൂടെ റൂട്ട് ഇംപോർട്ട് ചെയ്തു എന്ന് അത് കാണിക്കുന്നില്ല.
റൂട്ട് ദൂരസ്ഥ PE-യിൽ പ്രത്യക്ഷപ്പെട്ടിട്ടും ട്രാഫിക് ഒഴുകുന്നില്ലെങ്കിൽ പ്രശ്നം EVPN കടന്നു പോയി. വീണ്ടും route target തിരുത്തുന്നതിന് മുമ്പ് VNI-മുതൽ-VLAN അല്ലെങ്കിൽ VNI-മുതൽ-VRF ബൈൻഡിംഗും underlay പാതയും പരിശോധിക്കുക. മാപ്പിംഗിൽ തുടങ്ങി, പിന്നെ underlay, അതിന് ശേഷം മാത്രം നിയന്ത്രണ പ്ലെയിൻ. ഡാറ്റ പ്ലെയിൻ തകരാറിന് പിന്നാലെ route-target മാറ്റം പിൻവലിക്കുന്നത് പ്രവർത്തിക്കുന്ന ഇംപോർട്ട് തകർക്കാനുള്ള വിശ്വസനീയ വഴിയാണ്.
പാളി 3 പ്രിഫിക്സുകൾ ഇപ്പോഴും EVPN റൂട്ടുകളാണ്
EVPN പട്ടികയിലെ IP പ്രിഫിക്സ് സാധാരണ IPv4-unicast BGP അല്ല. 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. ആറ് ഫീൽഡുകൾ അടുത്ത തവണ ടിക്കറ്റ് വായിക്കുന്നവർക്ക് പ്രഖ്യാപനം വിശദീകരിക്കുന്നു, അവയൊന്നും ടെനന്റിന്റെ സംഖ്യകൾ ഒത്തുപോകണമെന്ന് ആവശ്യപ്പെടുന്നില്ല.