MPLS L3VPN ലാബ് പിംഗ് ചെയ്യുന്നില്ലേ? ഈ അഞ്ച് ഹോപ്പുകൾ പരിശോധിക്കുക

ഉപഭോക്താവിന്റെ രണ്ട് റൗട്ടറുകൾ, ഒരു ജോടി provider edge ഉപകരണങ്ങൾ, പിശക് സന്ദേശമില്ലാതെ മരിക്കുന്ന ഒരു പിംഗ്. ചെറിയ MPLS L3VPN ലാബിൽ തകരാർ ഏതാണ്ട് എപ്പോഴും അഞ്ച് ചെക്ക്പോയിന്റുകളിൽ ഒന്നിൽ ഇരിക്കുന്നു, ഓരോന്നിനും ആശ്രിതത്വം പ്രവർത്തിക്കുന്നുണ്ടോ ഇല്ലയോ എന്ന് കാണിക്കുന്ന കമാൻഡ് ഉണ്ട്. തെറ്റ് എന്നത് പിംഗ് പരാജയപ്പെടുമ്പോഴെല്ലാം BGP വീണ്ടും ആരംഭിക്കുന്നതാണ്, ആശ്രിതത്വങ്ങൾ ക്രമത്തിൽ പരിശോധിക്കുന്നതിന് പകരം. നിങ്ങൾ നേരിട്ട് VRF കോൺഫിഗറേഷനിലേക്ക് ചാടിയാൽ, രണ്ട് ഉപകരണങ്ങൾ അകലെ പരിഹരിക്കപ്പെടാത്ത അടുത്ത ഹോപ്പിൽ നിന്ന് ആരംഭിച്ച പ്രശ്നത്തിൽ ഒരു മണിക്കൂർ ചെലവഴിച്ചേക്കാം.

പട്ടിക താഴെ നിന്ന് മുകളിലേക്ക് പ്രവർത്തിക്കുക. പാസാകുന്ന ചെക്ക്പോയിന്റ് പാസായി തന്നെ തുടരും, ആദ്യത്തെ പരാജയമാണ് ഡീബഗ് ചെയ്യാൻ യോഗ്യമായത്.

ആദ്യ ചെക്ക്പോയിന്റ്: PE-കൾ പരസ്പരം എത്തുന്നു

ഓരോ PE-ക്കും മറ്റേ PE-യുടെ loopback-ലേക്ക് ഒരു റൂട്ട് വേണം, ആ റൂട്ട് എന്തെങ്കിലും യഥാർത്ഥമായ ഒന്നിലൂടെ പരിഹരിക്കപ്പെടണം. interior gateway protocol അങ്ങോട്ടുള്ള സാധാരണ വഴിയാണ്, പക്ഷേ ആവർത്തന തിരച്ചിൽ ഒരു ജീവനുള്ള adjacency-യിൽ വീഴുന്നിടത്തോളം സ്ഥിത റൂട്ടും പ്രവർത്തിക്കും. IOS ശൈലിയിലുള്ള ഉപകരണങ്ങളിൽ, show ip route 10.0.0.2 എന്നിട്ട് show ip cef 10.0.0.2 prefix ഉണ്ടോ അതിന്റെ പിന്നിൽ പരിഹരിച്ച adjacency ഉണ്ടോ എന്ന് കാണിക്കുന്നു. പട്ടികയിലുള്ള റൂട്ട്, അതിന്റെ പിന്നിൽ adjacency ഇല്ലെങ്കിൽ, അത് എത്തിച്ചേരൽ അല്ല.

രണ്ട് ദിശകളും പരിശോധിക്കുക. അസമമായ IGP ചെലവുകൾ, തെറ്റായ വശത്തുള്ള passive interface അല്ലെങ്കിൽ loopback ഫിൽട്ടർ ചെയ്യുന്ന distribute list ഓരോന്നും ഒരു ദിശ മാത്രം തകർക്കുന്നു, ഒരു ദിശ സെഷൻ കൊല്ലാൻ മതി. loopback-കൾ പിംഗ് ചെയ്യുന്നുവെങ്കിലും BGP സെഷൻ Active-ൽ നിൽക്കുന്നുവെങ്കിൽ, മറ്റെന്തെങ്കിലും തൊടുന്നതിന് മുമ്പ് update source നോക്കുക.

രണ്ടാം ചെക്ക്പോയിന്റ്: ലേബൽ പാതയുണ്ട്

വിദൂര loopback-ലേക്കുള്ള IP റൂട്ട് ഗതാഗതം ഒരു ലേബൽ ഇടുമെന്ന് തെളിയിക്കുന്നില്ല. LDP രൂപകൽപ്പനയിൽ, വിദൂര loopback-ന് പ്രാദേശികവും വിദൂരവുമായ ബൈൻഡിംഗ് ഉണ്ടെന്നും പുറത്തേക്ക് പോകുന്ന ലേബൽ forwarding പട്ടികയിൽ പ്രത്യക്ഷപ്പെടുന്നുവെന്നും ഉറപ്പാക്കുക. show mpls ldp bindings 10.0.0.2 32 ലേബൽ ജോടികൾ കാണിക്കുന്നു, show mpls forwarding-table 10.0.0.2 line card യഥാർത്ഥത്തിൽ എന്ത് ഇടും എന്ന് കാണിക്കുന്നു. രണ്ടാം കമാൻഡ് ഒരു ലേബലും കാണിക്കാത്തപ്പോഴോ IP-ലേക്ക് തിരികെ വീഴുമ്പോഴോ, രൂപകൽപ്പന കരുതുന്നതുപോലെ ഗതാഗതം VPN ട്രാഫിക് വഹിക്കുന്നില്ല.

ഈ വ്യത്യാസം MPLS forwarding state-നെ ലക്ഷ്യ prefix-കളിൽ നിന്ന് എങ്ങനെ വേർതിരിക്കുന്നു എന്നതിൽ നിന്ന് വരുന്നു, അതാണ് RFC 3031-ൽ വിവരിച്ച മാതൃക. നിങ്ങളുടെ ലാബ് LDP-യ്ക്ക് പകരം RSVP-TE അല്ലെങ്കിൽ BGP-യോട് ചേർന്ന ലേബലുകൾ ഉപയോഗിക്കുന്നുവെങ്കിൽ, ആ സംവിധാനത്തിന്റെ സ്വന്തം അവസ്ഥ പരിശോധിക്കുക; LDP ഓരോ അടിസ്ഥാന ലേബലും വിതരണം ചെയ്യുന്നു എന്ന് കരുതുന്നത് പ്രേത ബഗിനെ പിന്തുടരാനുള്ള സാധാരണ വഴിയാണ്. പൊട്ടിയ ലേബൽ പാത പിന്നീട് സാധാരണയായി ഉള്ളതും എന്നാൽ ഉപയോഗശൂന്യവുമായ VPN റൂട്ടായി പ്രത്യക്ഷപ്പെടുന്നു.

മൂന്നാം ചെക്ക്പോയിന്റ്: VPN റൂട്ട് സുരക്ഷിതമായി എത്തി

കൃത്യമായ ഉപഭോക്തൃ prefix-ന്റെ VPNv4 അല്ലെങ്കിൽ VPNv6 റൂട്ട് നോക്കുക, സെഷൻ സംഗ്രഹമല്ല. show bgp vpnv4 unicast all 10.10.1.0/24 route distinguisher, വിദൂര PE loopback-ലേക്ക് സജ്ജീകരിച്ച next hop, ഒരു ലേബൽ എന്നിവ കാണിക്കണം. prefix ഇല്ലെങ്കിൽ, ആദ്യ സംശയം ഉറവിട PE-യിലെ export നയമോ സ്വീകരിക്കുന്ന PE-യിലെ import നയമോ ആണ്, route target-കളാണ് സാധാരണ കുറ്റവാളി.

route target പരിശോധന BGP സ്വീകരണത്തിൽ നിന്ന് വേർതിരിച്ച് വായിക്കുക. ഒരു റൂട്ട് ശരിയായ next hop-നോടെ വന്ന്, importtarget പൊരുത്തപ്പെടാത്തതിനാൽ VRF-ൽ ഇറങ്ങാതിരിക്കാം. സ്വീകരിക്കുന്ന PE-യിൽ show ip route vrf CUSTOMER 10.10.1.0 ആണ് പ്രധാന പരീക്ഷ; BGP പട്ടിക റൂട്ട് നിയന്ത്രണ തലം കടന്നു എന്ന് മാത്രം തെളിയിക്കുന്നു.

നാലാം ചെക്ക്പോയിന്റ്: interface VRF-നുള്ളിൽ ഉണ്ട്

route distinguisher-ഉം route target-കളുമുള്ള VRF നിർവചനം ഒരു interface-ഉം അതിലേക്ക് മാറ്റുന്നില്ല. CE-യിലേക്കുള്ള interface-ന് VRF അനുവദനം വേണം, show ip vrf interfaces അല്ലെങ്കിൽ show ip interface brief അത് ശരിയായ ഇൻസ്റ്റൻസിന് കീഴിൽ ലിസ്റ്റ് ചെയ്യണം. പകർത്തിയ കോൺഫിഗറേഷൻ ഏറ്റവും കൂടുതൽ തെറ്റ് വരുത്തുന്ന ചെക്ക്പോയിന്റ് ഇതാണ്, കാരണം VRF ബ്ലോക്ക് പൂർണ്ണമായി തോന്നുന്നു പക്ഷേ interface ഇപ്പോഴും ആഗോള പട്ടികയിൽ ഇരിക്കുന്നു.

തുടർന്ന് PE പ്രാദേശിക ഉപഭോക്തൃ prefix ആ VRF-ൽ പഠിച്ചുവെന്നും CE-ക്ക് കണക്ഷനിലൂടെ തിരികെ ഒരു റൂട്ട് ഉണ്ടെന്നും ഉറപ്പാക്കുക. CE-യിൽ PE-യിലേക്ക് ചൂണ്ടുന്ന സ്ഥിത default ലാബിന് മതി, PE-യുടെ VRF-ൽ CE-യുടെ LAN-ലേക്ക് റൂട്ട് ഉണ്ടെങ്കിൽ. രണ്ടിൽ ഏതെങ്കിലും പകുതി ഇല്ലെങ്കിൽ, ഒരു ലേബൽ ഇടുന്നതിന് മുമ്പ് തന്നെ പിംഗ് പരാജയപ്പെടുന്നു.

അഞ്ചാം ചെക്ക്പോയിന്റ്: മറുപടി വീട്ടിലേക്കുള്ള വഴി കണ്ടെത്തുന്നു

മുന്നോട്ട് പോകുന്ന പാക്കറ്റും തുടർന്ന് തിരികെ വരുന്ന പാക്കറ്റും ട്രാക്ക് ചെയ്യുക, കാരണം അവ വ്യത്യസ്ത പട്ടികകൾ ഉപയോഗിക്കുന്നു. പ്രവേശന PE-യിൽ ഉപഭോക്തൃ ഉറവിടം VRF-നുള്ളിൽ വിദൂര prefix-ലേക്ക് വിദൂര ലേബലോടെ പരിഹരിക്കപ്പെടണം. നിർഗമന PE-യിൽ ലക്ഷ്യം അതേ VRF-നുള്ളിൽ CE-യിലേക്കുള്ള interface-ലേക്ക് പരിഹരിക്കപ്പെടണം. PE-യിൽ നിന്ന് തന്നെ അയച്ച പിംഗ് തെളിവല്ല: അത് ആഗോള പട്ടികയിലൂടെയോ മറ്റൊരു ഉറവിട വിലാസത്തിലൂടെയോ പുറത്തുപോകാം, അതിനാലാണ് ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 പ്രവർത്തിപ്പിക്കേണ്ട പരീക്ഷ.

ഹോസ്റ്റുകളുടെ ഫയർവാളുകൾ, reverse-path filtering, CE-യുടെ access പട്ടികകൾ എന്നിവ ഇപ്പോഴും ബാധകമാണ്. മുന്നോട്ടുള്ള പാത പ്രവർത്തിച്ച് മറുപടി മരിക്കുന്നുവെങ്കിൽ, പ്രശ്നം തിരികെ വരുന്ന വശത്തെ റൂട്ടിലോ ഫിൽട്ടറിലോ ആണ്, MPLS ഗതാഗതത്തിലല്ല.

ഓരോ ചെക്ക്പോയിന്റിനും ആദ്യം പരാജയപ്പെട്ട ആശ്രിതത്വത്തിന്റെ പേര് പറയുന്ന ഒരു വരി സൂക്ഷിക്കുക. ആ വരി ഉപഭോക്താവിന് പിംഗ് ചെയ്യാനാകുന്നില്ല എന്ന പരാതിയെ എത്തിച്ചേരൽ, ലേബൽ അവസ്ഥ, റൂട്ട് ഇറക്കുമതി, interface അംഗത്വം അല്ലെങ്കിൽ തിരികെയുള്ള പാത എന്നിവയെക്കുറിച്ചുള്ള നിർദ്ദിഷ്ട ചോദ്യമാക്കി മാറ്റുന്നു, അടുത്ത ഡീബഗ് സെഷൻ അതേ അഞ്ച് കമാൻഡുകൾ അതേ ക്രമത്തിൽ ആവർത്തിക്കുന്നത് തടയുന്നു.