CE RIP રૂટથી રિમોટ VRF સુધી: એક્સપોર્ટ ક્યાં થાય છે

RIPv2 અપડેટ પ્રોવાઇડર એજ પર આવે છે, VRF રૂટિંગ ટેબલમાં જમા થાય છે, અને જ્યાં સુધી કંઈક તેને સ્પષ્ટ રીતે એક્સપોર્ટ ન કરે ત્યાં સુધી ત્યાં જ રહે છે. ત્રણ નિર્ણયો ક્રમમાં થાય છે, અને દરેક પોતાના કારણસર પ્રીફિક્સને નકારી શકે છે. તેમને એક જ ઘટના તરીકે વાંચવાને કારણે લોકો ખોટા બોક્સ પાછળ દોડે છે જ્યારે રિમોટ સાઇટ એ નેટવર્ક સુધી પહોંચી શકતી નથી જે CE સ્પષ્ટપણે જાહેર કરે છે. PE દ્વારા રૂટને અનુસરો અને ક્રમ સ્વયં સ્પષ્ટ થઈ જાય છે.

PE એ RIP અપડેટ સાથે શું કરે છે

PE VRF ઇન્ટરફેસ પર અપડેટ મેળવે છે, સ્રોત માન્ય પડોશી છે તે તપાસે છે, અને જાહેરાતમાંથી મેળવેલા હોપ કાઉન્ટ સાથે પ્રીફિક્સને VRF રૂટિંગ ટેબલમાં નાખે છે. એ ટેબલ પોતાના એડમિનિસ્ટ્રેટિવ ડિસ્ટન્સ અને પોતાની શ્રેષ્ઠ-માર્ગ પસંદગી સાથેનું સામાન્ય રૂટિંગ ટેબલ છે. જો CE એ જ પ્રીફિક્સને જુદા જુદા મેટ્રિક સાથે બે વાર જાહેર કરે, તો ટેબલમાં ફક્ત સારો એક જ ટકી રહે છે. આ પગલામાં પ્રોવાઇડર બેકબોનનો કોઈ સંબંધ નથી.

પ્રીફિક્સ હવે એક જ ગ્રાહકના રૂટિંગ સંદર્ભમાં અસ્તિત્વ ધરાવે છે, જે બીજે ક્યાંય પહોંચી શકાય તેનાથી ઘણું દૂર છે.

એક્સપોર્ટ એ નીતિની ક્રિયા છે, પ્રોટોકોલનું પરિણામ નહીં

VRF છોડવા માટે, રૂટને VPN રૂટ વહન કરતી MP-BGP પ્રક્રિયામાં ફરી વહેંચવો પડે છે, અને તેને રૂટ ટાર્ગેટ એક્સ્ટેન્ડેડ કમ્યુનિટીની જરૂર પડે છે જે નક્કી કરે કે કઈ રિમોટ VRF તેને આયાત કરી શકે. RFC 4364 માંની આર્કિટેક્ચર એ જ કારણસર એ વિનિમયોને CE-થી-PE પ્રોટોકોલથી અલગ રાખે છે. એજ પર RIP વાપરવાથી એ વિશે કંઈ કહેવાતું નથી કે પ્રોવાઇડર નેટવર્ક પાર શું જવું જોઈએ.

કંઈપણ ગોઠવતા પહેલાં એક્સપોર્ટ કરાર લખી નાખો: એ ગ્રાહક પ્રીફિક્સ જે રિમોટથી પહોંચવા યોગ્ય હોવા જોઈએ, એ રૂટ જે સ્થાનિક રહેવા જોઈએ, અને કોઈપણ ડિફોલ્ટ, વધુ-વિશિષ્ટ અથવા સહિયારી-સેવા અપવાદો. એ કરારને વાસ્તવિક VRF સામે મેળવો, બીજા ગ્રાહકની સમાન નામવાળી VRF સામે નહીં.

આયાત બાજુ પોતાના રૂટ ટાર્ગેટ સાથેની બીજી નીતિ છે, અને મેળ ખાતો એક્સપોર્ટ બિન-મેળ ખાતી આયાત સાથે એવું પ્રીફિક્સ બનાવે છે જે બેકબોનમાં અસ્તિત્વ ધરાવે છે અને કોઈ રિમોટ ટેબલમાં દેખાતું નથી.

રીડિસ્ટ્રિબ્યુશન અને સ્પષ્ટ ઓરિજિનેશન જુદી રીતે વર્તે છે

રીડિસ્ટ્રિબ્યુશન એ રૂટ લે છે જે પહેલેથી VRF ટેબલમાં છે અને રૂટ મેપ દ્વારા ફિલ્ટર થઈને તેમને BGP માં કોપી કરે છે. મેપ નક્કી કરે છે કે કયા પ્રીફિક્સ પાત્ર છે અને તે કયા એટ્રિબ્યુટ લે છે, અને મેટ્રિક સ્પષ્ટ રીતે સેટ કરવો પડે કારણ કે RIP હોપ કાઉન્ટનો BGP મેટ્રિક તરીકે કોઈ અર્થ નથી. તમે જે અસેટ છોડો છો તે એવી રીતે વારસામાં મળે છે જે છ મહિના પછી કન્ફિગ વાંચનારને સામાન્ય રીતે આશ્ચર્યમાં મૂકે છે.

પરસ્પર રીડિસ્ટ્રિબ્યુશન એ છે જ્યાં શાંત નુકસાન થાય છે. BGP માં એક્સપોર્ટ થયેલું પ્રીફિક્સ બીજા રીડિસ્ટ્રિબ્યુશન પોઇન્ટ દ્વારા પાછું આવી શકે છે, અને ટૅગ્સ કે ફિલ્ટર વગર રૂટ ડોલે છે જ્યારે બંને ટેબલ કોઈપણ ક્ષણે વિશ્વસનીય લાગે છે. પરત માર્ગ રોકવા ટોપોલોજી પર ભરોસો કરવાને બદલે એજ પર લગાવેલા ટૅગ્સ પર ફિલ્ટર કરો.

સ્પષ્ટ ઓરિજિનેશન વધુ સુઘડ લાગે છે અને તે બિનશરતી નથી. નેટવર્ક સ્ટેટમેન્ટને સામાન્ય રીતે પ્રીફિક્સ ઓરિજિનેટ થાય તે પહેલાં રૂટિંગ ટેબલમાં મેળ ખાતા રૂટની જરૂર પડે છે, તેથી CE જે ક્ષણે જાહેરાત બંધ કરે તે ક્ષણે જાહેરાત અદૃશ્ય થાય છે. તે ઘણી વાર એ વર્તન છે જે તમે ઇચ્છો છો, અને તે કાયમ ગોઠવાયેલા રહેતા સ્ટેટિક રૂટ જેવું નથી. બંનેમાંથી કોઈપણ વર્તન ધારવાને બદલે પ્લેટફોર્મનો વાસ્તવિક નિયમ તપાસો.

ગમે તે રીતે, દરેક પ્રીફિક્સ વિશે પૂછવાનો પ્રશ્ન એ છે કે કયો સક્રિય સ્રોત તેને પાત્ર બનાવે છે અને એ સ્રોત અદૃશ્ય થાય ત્યારે શું થાય છે.

ચાર જગ્યાએ સાંકળ ચકાસો

CE જાહેરાત, VRF રૂટિંગ ટેબલ, તેના રૂટ ટાર્ગેટ સાથેનું VPN રૂટ ટેબલ, અને રિમોટ VRF આયાત, એ ક્રમમાં જુઓ. IOS પર તેનો અર્થ CE પડોશી આઉટપુટ, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, અને દૂરના PE પર એ જ આદેશ. IOS-XR પર સમાન આઉટપુટ આ હેઠળ છે: show bgp vrf CUSTOMER ipv4 unicast. આદેશોનાં નામ અલગ છે, ચાર ચેકપોઇન્ટ નહીં.

જે પ્રીફિક્સ નકારવું જોઈએ તેને પસાર થવું જોઈએ તેની જેટલી કાળજીથી ચકાસો, કારણ કે બધું મંજૂર કરતી નીતિ પ્રથમ અપવાદ આવે ત્યાં સુધી સાચી નીતિ જેવી જ દેખાય છે. પછી પાછળ ખેંચવાનું જુઓ: CE ઇન્ટરફેસ બંધ કરો, અને ખાતરી કરો કે રિમોટ એન્ટ્રી રાહ જોવાયેલા ટાઇમરમાં અદૃશ્ય થાય છે, રહી જતી નથી.

દરેક નીતિનો માલિક કોણ છે તે નોંધો. જ્યારે પ્રોવાઇડર CE ચલાવે છે, ત્યારે પહોંચાડાયેલું વર્તન સેવા કરારમાં આવે છે, અને મેનેજ કરેલા ઉપકરણ પર અલગ પ્રોટોકોલ કે પાછળ ખેંચવાની નીતિ રૂટિંગ સમસ્યા પહેલાં દસ્તાવેજીકરણની સમસ્યા છે.