કોરમાં VPNv4 ને MPLS જોઈએ? જરૂરી નથી
BGP VPNv4 રૂટ-વિતરણ સંદર્ભ વિશે વાટાઘાટ કરે છે, ફોરવર્ડિંગ પાથ નહીં. ઇમ્પોર્ટ, નેક્સ્ટ-હોપ રિઝોલ્યુશન અને તમે ચલાવી શકો તે એન્કેપ્સ્યુલેશન અલગ કરો.
બે રાઉટર વચ્ચે VPNv4 એડ્રેસ ફેમિલી ચાલુ કરવાથી ફક્ત રૂટ-વિતરણ સંદર્ભ બને છે, વધુ કંઈ નહીં. તે ફોરવર્ડિંગ પાથ ઇન્સ્ટોલ કરતું નથી, અને કયું એન્કેપ્સ્યુલેશન ગ્રાહક પેકેટને દૂરના એન્ડપોઇન્ટ સુધી લઈ જશે તે કહેતું નથી. આ બે હકીકતો અલગ થઈ જાય પછી, «કોરમાં આને MPLS જોઈએ» એ પ્રશ્ન પ્લેટફોર્મ દ્વારા સમર્થિત ડેટા પ્લેન વિશે વધુ સાંકડો અને જવાબપાત્ર પ્રશ્ન બની જાય છે.
એડ્રેસ ફેમિલી ખરેખર શું વાટાઘાટ કરે છે
મલ્ટિપ્રોટોકોલ BGP એ AFI 1 અને SAFI 128 હેઠળ VPNv4 નેટવર્ક લેયર રિચેબિલિટી માહિતી વહન કરે છે, અને દરેક એન્ટ્રી રૂટ ડિસ્ટિંગ્વિશરને પ્રીફિક્સ અને લેબલ સાથે જોડે છે. સેશન વાટાઘાટ કરે છે કે બંને પક્ષો તે માહિતી એન્કોડ અને ડીકોડ કરી શકે છે. જેની પર તે વાટાઘાટ કરતું નથી તે ડેટા પ્લેન છે. આ ફકરા પછીનું બધું ફોરવર્ડિંગને લગતું છે, અને તેમાંથી કંઈ પણ સેશન ઉપર આવવાથી નક્કી થતું નથી.
તેથી સફળ સેશન નિયંત્રણ-પ્લેન ક્ષમતાનો પુરાવો છે, ફોરવર્ડિંગનો નહીં. રાઉટર હજારો VPNv4 એન્ટ્રી રાખી શકે છે અને છતાં દરેક ગ્રાહક પેકેટ કાઢી નાખી શકે છે, અને એટલે જ બે પ્રકારની નિષ્ફળતાઓ શરૂઆતમાં ભેળસેળ થાય છે.
NLRI માંના લેબલ પર ધ્યાન આપો. તે સેવા લેબલ છે, VRF ની અંદરના પ્રીફિક્સ સાથે બંધાયેલું છે, અને પેકેટ એગ્રેસ એન્ડપોઇન્ટ સુધી પહોંચે ત્યારે તેની ફોરવર્ડિંગ ભૂમિકા હોય છે. કોઈ ટ્રાન્ઝિટ ઉપકરણ તેને વાંચે છે કે નહીં, તે અલગ ડિઝાઇન નિર્ણય છે.
પ્રાપ્તિ, ઇમ્પોર્ટ અને ફોરવર્ડિંગ ત્રણ પગલાં છે
રૂટ મેળવવો, તેનો ઉપયોગ કરવાની પરવાનગી હોવી અને તેની સાથે ફોરવર્ડ કરી શકવું એ ઉપકરણના જુદા જુદા ભાગો કરે છે. BGP જે સાંભળે છે તે સંગ્રહે છે; ઇમ્પોર્ટ પોલિસી અને રૂટ-ટાર્ગેટ મેળ કયું VRF તેને ધ્યાનમાં લઈ શકે તે નક્કી કરે છે; પછી ફોરવર્ડિંગ પ્લેને જાહેર કરેલા નેક્સ્ટ હોપને એવી વસ્તુમાં ઉકેલવું પડે છે જે તે ખરેખર વાયર પર મોકલી શકે.
| Step in the chain | What has to be true | How it fails quietly |
|---|---|---|
| NLRI exchange | Both speakers negotiate the VPNv4 capability | Session stays up while the family is never activated |
| Import eligibility | A route target on the received route matches the VRF import policy | The route exists in the table but never enters the VRF |
| Next-hop resolution | The advertised next hop resolves to a usable tunnel or label path | Best path is selected, then marked unreachable or unusable |
| Encapsulation | The egress endpoint can decapsulate what the ingress produced | Packets arrive and are discarded for a format mismatch |
એ મધ્ય પગલામાં જ સૌથી આશ્ચર્યજનક નિષ્ફળતાઓ રહે છે. રૂટ BGP ટેબલમાં હાજર, માન્ય અને સૌથી સારો પણ હોઈ શકે, જ્યારે VRF રૂટ ટેબલ ખાલી રહે કારણ કે કોઈ રૂટ ટાર્ગેટ ઇમ્પોર્ટ સૂચિ સાથે મેળ ખાધો નથી. કંઈ પણ પ્રોટોકોલ ભૂલ લોગ કરતું નથી, કારણ કે કોઈ પ્રોટોકોલ ભૂલ થઈ નથી.
છેલ્લું પગલું એ છે જ્યાં પ્લેટફોર્મ સપોર્ટ દેખાય છે. અંડરલેમાં પહોંચી શકાય તેવો નેક્સ્ટ હોપ આપોઆપ VPN સેવા ટ્રાન્સપોર્ટ તરીકે ઉકેલાતો નથી, અને ઉપકરણ ચોક્કસ ટનલ પ્રકાર, ચોક્કસ લેબલ ઓપરેશન અથવા બંનેની માંગ કરી શકે છે. રિઝોલ્યુશન સ્થિતિ વાંચવી રૂટ સંખ્યા વાંચવા કરતાં વધુ માહિતીપ્રદ છે.
IP કોર એવો સ્ટેક વહન કરી શકે છે જે તે ક્યારેય સ્વિચ કરતું નથી
જે ભેદ જાળવવા યોગ્ય છે તે «કોર MPLS ચલાવતું નથી» અને «સેવામાં ક્યાંય લેબલ નથી» વચ્ચેનો છે. આ અલગ દાવાઓ છે, અને ફક્ત પહેલો ટ્રાન્ઝિટ ઉપકરણો વિશે છે. RFC 4023 IP અથવા GRE ટનલ દ્વારા MPLS વહનને વ્યાખ્યાયિત કરે છે, અને એ જ પદ્ધતિ સંપૂર્ણ IP કોર પર બીજા દાવાને શક્ય બનાવે છે.
customer packet + service label
encapsulated in GRE, addressed to the egress tunnel endpoint
forwarded by ordinary IP routers on the outer header
decapsulated at the endpoint, label still meaningfulટ્રાન્ઝિટ રાઉટર બહારના IP ગંતવ્ય પર ફોરવર્ડ કરે છે અને ગ્રાહક પ્રીફિક્સ કે નેટિવ લેબલ સ્વિચિંગની જરૂર હોતી નથી. દૂરના છેડે બહારની ટનલ દૂર થાય છે અને સેવા લેબલ તેનું કામ ફરી શરૂ કરે છે. કોરે અપારદર્શક પેલોડ ખસેડ્યું, જે IP નેટવર્ક જેમાં સારું છે તે બરાબર એ જ છે.
આ ડિઝાઇન તમને જે આપતું નથી તે સાર્વત્રિક બાંયધરી છે. તે પુરાવો નથી કે દરેક રાઉટર કોઈપણ GRE ઇન્ટરફેસ પર દરેક VPNv4 નેક્સ્ટ હોપ ઉકેલે છે, અને તે કાર્યરત નેટિવ MPLS કન્ફિગરેશન ડિલીટ કરવાનું કારણ નથી. તે સાર્વત્રિક દાવા સામેનું પ્રતિઉદાહરણ છે, અને વ્યવહારુ પ્રશ્ન પ્લેટફોર્મ પૂરતો સ્થાનિક રહે છે. એ પ્રશ્નને પ્રોટોકોલ નિયમ તરીકે નહીં, પ્લેટફોર્મ મર્યાદા તરીકે નોંધો.
બોક્સ પર સાંકળ તૂટે ત્યાં સુધી ચાલો
પ્રાપ્ત રૂટથી શરૂ કરો અને જે પહેલું પગલું નિષ્ફળ જાય ત્યાં અટકો, કારણ કે અગાઉનું પગલું તૂટેલું હોય ત્યારે પછીનાં પગલાંનું નિદાન કરી શકાતું નથી. સામાન્ય અમલીકરણમાં ચાર કમાન્ડ તેમાંથી મોટા ભાગને આવરી લે છે.
show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_Aતેમને ચાર સ્વતંત્ર તપાસ તરીકે નહીં, ક્રમ તરીકે વાંચો. પહેલું પુષ્ટિ કરે છે કે ફેમિલી સક્રિય છે અને પીઅર રૂટની આપલે કરે છે; બીજું બતાવે છે કે પ્રીફિક્સ ઉપયોગી નેક્સ્ટ હોપ સાથે આવ્યું છે કે નહીં; ત્રીજું ઇમ્પોર્ટ પાત્રતા સાબિત કરે છે; ચોથું બતાવે છે કે ફોરવર્ડિંગ પ્લેને તેની સાથે લેબલ કે ટનલ બાંધી છે કે નહીં.
પછી વર્કલોડ પાથને બંને દિશામાં ચકાસો, એવા MTU સાથે જે એન્કેપ્સ્યુલેશન ટકી જાય. GRE હેડર બાઇટ ઉમેરે છે, અને નાના પ્રોબ પાસ કરતો પાથ માત્ર એક દિશામાં પૂર્ણ કદના પેકેટ પર નિષ્ફળ જઈ શકે છે, જે ટ્રાન્સપોર્ટ ખામીને બદલે એપ્લિકેશન ખામી જેવું લાગે છે.
બે ઓપરેશનલ નોંધ ચક્ર પૂરું કરે છે. GRE એન્કેપ્સ્યુલેશન છે, ગોપનીયતા નહીં, તેથી અવિશ્વસનીય ટ્રાન્ઝિટ નેટવર્કને ધારણાને બદલે ઉપર સમર્થિત સુરક્ષા ગોઠવણીની જરૂર છે. અને ડિઝાઇન સમીક્ષા પહેલાં નોંધો કે પ્લેટફોર્મ ખરેખર કયું એન્કેપ્સ્યુલેશન સમર્થન આપે છે, કારણ કે એ એક જ જવાબ નક્કી કરે છે કે ફક્ત-IP કોર માન્ય પસંદગી છે કે ફોરવર્ડ કરી ન શકે તેવી યોજના.