બે ગ્રાહકો માટે એક જ /24? VPNv4 ને RD અને લેબલ જોઈએ
બે ભાડૂતો એક જ /24 જાહેર કરી શકે છે કારણ કે RD દરેક રૂટને તેની પોતાની ઓળખ આપે છે. લેબલ બીજા પ્રશ્નનો જવાબ આપે છે: કેવી રીતે ફોરવર્ડ કરવું.
બે ભાડૂતો તેમની શાખાને એક જ 10.50.0.0/24 થી નંબર આપે છે, અને બદલાવ પછી એક ભાડૂતનો રૂટ પ્રોવાઇડર એજ પરથી અદૃશ્ય થાય છે જ્યારે બીજો કામ કરતો રહે છે. તે ટિકિટ પાછળનું સરળીકરણ સામાન્ય રીતે રૂટ ડિસ્ટિંગ્વિશર (RD) છોડી દેવાનું હોય છે, કારણ કે "લેબલ પહેલેથી જ ગ્રાહકને ઓળખે છે". તે નથી કરતું. RD અને લેબલ બે અલગ પ્રશ્નોના જવાબ આપે છે, અને આ તફાવત ત્યારે જ દેખાય છે જ્યારે ઓવરલેપ થતા સરનામાં તેને ફરજ પાડે છે.
જ્યાં બે હોવા જોઈએ ત્યાં એક રૂટ
સામાન્ય IPv4 યુનિકાસ્ટ એક જ પ્રીફિક્સ તરફના બે માર્ગોની સરખામણી કરે છે અને સારો ઇન્સ્ટોલ કરે છે. ભાડૂત A તરફથી 10.50.0.0/24 અને ભાડૂત B તરફથી 10.50.0.0/24 એક જ કી છે, તેથી એક જીતે છે અને બીજો ફક્ત બેકઅપ માર્ગ તરીકે ટકી રહે છે. પ્રોટોકોલે જે કહેવાયું તે કર્યું; કંટ્રોલ પ્લેનને એક જ ઓળખકર્તા હેઠળ બે અલગ રૂટ સંગ્રહવાનું કહેવાયું હતું.
પરિણામ ભૂલ કરતાં ખોવાયેલા રૂટ જેવું લાગે છે: જે PE હારી ગયું તે હજી પણ પોતાના ભાડૂતને સ્થાનિક રીતે ફોરવર્ડ કરે છે, તેથી સાઇટની અંદરનું પિંગ સફળ થાય છે અને સાઇટો વચ્ચેની કસોટી નિષ્ફળ જાય છે. કોઈપણ નીતિને સ્પર્શ કરતા પહેલા VPNv4 કોષ્ટકમાં તે પ્રીફિક્સની એન્ટ્રીઓ ગણો.
RD એક કીને બે બનાવે છે
આઠ બાઇટનું રૂટ ડિસ્ટિંગ્વિશર IPv4 પ્રીફિક્સ પહેલાં ઉમેરવામાં આવે છે, અને BGP જે ઑબ્જેક્ટ વહન કરે છે તે IPv4 પ્રીફિક્સને બદલે VPN-IPv4 સરનામું બને છે. બે ભાડૂતો સમાન 32 બિટ રાખી શકે છે કારણ કે આગળના 64 બિટ અલગ છે. AS-આધારિત RD અને સરનામા-આધારિત RD માટે ફોર્મેટ પ્રકારો છે, અને પસંદગી મૂળ PEની છે. PEઓ એક જ AS વહેંચે ત્યારે AS-આધારિત RD સામાન્ય છે, અને ન વહેંચે ત્યારે સરનામા-આધારિત.
RD ને સભ્યપદના ટૅગ તરીકે ન વાંચો. રૂટ ટાર્ગેટ આયાત અને નિકાસ નિયંત્રિત કરે છે અને કયા VRF રૂટ ઇન્સ્ટોલ કરી શકે તે નક્કી કરે છે; RD ફક્ત એ બાંયધરી આપે છે કે રૂટની પોતાની ઓળખ છે. દરેક VRFને તેનું પોતાનું RD આપવું સામાન્ય પ્રથા છે, કારણ કે તે આ મેપિંગને રૂટ દૃશ્યમાં વાંચવા યોગ્ય રાખે છે.
લેબલ સ્થાનિક ફોરવર્ડિંગ સૂચના છે
દરેક જાહેરાત MPLS લેબલ પણ વહન કરે છે, અને તેનો અર્થ તે રાઉટર સુધી મર્યાદિત છે જેણે તે ફાળવ્યું છે. બીજું PE અસંબંધિત લક્ષ્ય માટે એ જ નંબર આપી શકે છે. તેથી જ લેબલ ગ્રાહકની ઓળખનું સ્થાન લઈ શકતું નથી: નંબર ફક્ત આગળના હોપ અને તેને ઇન્સ્ટોલ કરનારી ફોરવર્ડિંગ સ્થિતિની બાજુમાં જ સાચો છે.
ફાળવણીની દાણાદારતા અમલીકરણ અને રચના પ્રમાણે બદલાય છે: કેટલાક પ્લેટફોર્મ દરેક VRF માટે એક લેબલ ફાળવે છે, અન્ય દરેક પ્રીફિક્સ માટે, અને લેબલ ગ્રાહકને બદલે ફોરવર્ડિંગ ક્રિયા ઓળખી શકે છે. એક જ લક્ષ્ય સુધી પહોંચતા બે અલગ લેબલ વિરોધાભાસ નથી, અને બે PE પર એક જ લેબલ નંબર પણ નથી.
| Field | Where it lives | Scope | If you remove it |
|---|---|---|---|
| RD | VPNv4 NLRI | Per advertised route | Overlapping prefixes collide |
| Route target | Extended community | Import and export policy | Route lands in the wrong VRF |
| Label | Labeled NLRI and forwarding state | Per allocating router | No instruction for the data plane |
| Next hop | Path attribute | Per path | The label cannot be resolved |
એક બીજાનું સ્થાન કેમ ન લઈ શકે
જાહેરાત વાંચવાનો અર્થ ચાર વસ્તુઓ એકસાથે જોવી: RD-યોગ્ય પ્રીફિક્સ, રૂટ ટાર્ગેટ, આગળનો હોપ અને લેબલ. વપરાશકર્તા પેકેટ વાંચવાનો અર્થ તે માહિતીમાંથી ઇન્સ્ટોલ થયેલો સ્ટેક જોવો. સ્વસ્થ રચનામાં બંને બાજુ મેળ ખાય છે, અને તૂટેલી રચનામાં સામાન્ય રીતે એક બાજુ સાચી અને બીજી જૂની હોય છે. તે સરખામણી ઓળખની સમસ્યાને ફોરવર્ડિંગની સમસ્યાથી અલગ પાડે છે.
કંટ્રોલ પ્લેન અને ડેટા પ્લેન વચ્ચેનો સુઘડ વિરોધ શિક્ષણ સાધન છે, એન્કોડિંગનું વર્ણન નથી. RFC 8277 લેબલને લેબલવાળા NLRIની અંદર મૂકે છે, તેથી જાહેરાત પોતે જ બંધન વહન કરે છે; તેને ફોરવર્ડિંગ માટે વાપરવું એ પછીનું, અલગ પગલું છે.
જ્યારે ભાડૂતનો રૂટ ખોવાય, તો આ ક્રમમાં તપાસો: પ્રીફિક્સ માટે બે VPNv4 એન્ટ્રી, દરેક પર સાચો રૂટ ટાર્ગેટ, ઉકેલી શકાય તેવો આગળનો હોપ, અને એવું લેબલ જેના માટે પ્રાપ્તકર્તા PE પાસે સ્થિતિ છે. ઓળખને ફોરવર્ડિંગ મૂલ્યથી સુધારવી, અથવા ઊલટું, એક ચકાસણી પાસ કરશે અને બીજીમાં નિષ્ફળ જશે.