pseudowire અંતિમ બિંદુઓ પર VLAN ટૅગ સામાન્ય કરવી: એક રનબુક

pseudowire ને સ્પર્શ કરતાં પહેલાં નક્કી કરો કે દરેક ગ્રાહક ધારને કયો ફ્રેમ મળવો જોઈએ. સાદા કિસ્સામાં CE A સેવા સીમાંકિત કરતો એક ટૅગ મોકલે છે અને CE B ટૅગ વગરના ફ્રેમની અપેક્ષા રાખે છે, અને આ તફાવત પ્રોવાઈડર ધાર પર જ ઉકેલાય છે. ટૅગ સ્થાનિક નીતિ છે, ગ્રાહકના Ethernet કરારનો ભાગ નથી, અને pseudowire મૂળ ફ્રેમને બદલે સહમત ફ્રેમ વહન કરે છે. કોઈપણ રૂપરેખાંકન પહેલાં બંને દિશાઓ લખો.

પહેલાં ફ્રેમ કરાર લખો

આગળની દિશા એક ટૅગ દૂર કરે છે અને પાછળની દિશા તે ફરી ઉમેરે છે. જો તમે તેમાંથી ફક્ત એક લખો, તો તમે એક દિશામાં કાર્યરત માર્ગ ચકાસશો અને સર્કિટને સ્વસ્થ જાહેર કરશો.

કરારને એટલો ટૂંકો રાખો કે ફેરફાર ટિકિટમાં પેસ્ટ કરી શકાય: કઈ ધાર ટૅગ સાથે મોકલે છે, કઈ ટૅગ વગર અપેક્ષા રાખે છે, અને કઈ ટૅગ કિંમત સેવા સીમાંકિત કરે છે.

pseudowire મોડ પર સંમત થાઓ

RFC 4448 raw અને tagged pseudowire મોડ વચ્ચે ભેદ કરે છે અને સેવા સીમાંકિત કરતા ટૅગ કેવી રીતે સંભાળાય છે તે વર્ણવે છે. raw મોડ હજી પણ ગ્રાહક ફ્રેમ સાથે સંબંધિત ટૅગ વહન કરી શકે છે, તેથી ભેદ ટૅગની સેવા-ભૂમિકા વિશે છે, ફક્ત 802.1Q હેડરની હાજરી વિશે નહીં. મોડને tagged વિરુદ્ધ untagged વાંચવું એ આ કામની વ્યાપ્તિ ખોટી રીતે નક્કી કરવાનો સૌથી સામાન્ય રસ્તો છે. કઈ ક્રિયાઓ જોઈએ તે નક્કી કરતાં પહેલાં સાથી સાથે મોડ પર સંમત થાઓ.

પછી વાસ્તવિક pseudowire પ્રકાર અને સાથીના પરિમાણો તપાસો. સ્થાનિક VLAN જોડાણ અને દૂરસ્થ પોર્ટ જોડાણ માટે સમર્થિત interworking ગોઠવણ જરૂરી છે, અને બે સ્થાનિક રીરાઇટ વિધાન સાબિત કરતા નથી કે જાહેર કરેલા સર્કિટ પ્રકારો મેળ ખાય છે.

જો control word અને MTU ની અપેક્ષાઓ અલગ હોય, તો તમારી પાસે વાટાઘાટની સમસ્યા છે જેને કોઈ રીરાઇટ સુધારશે નહીં. બંનેની પુષ્ટિ ડિઝાઇન દસ્તાવેજને બદલે સાથીના ચાલુ રૂપરેખાંકનથી કરો.

સ્થાનિક ટૅગ ક્રિયાઓ લાગુ કરો

Juniper ની VLAN CCC રીરાઇટ માર્ગદર્શિકા pop, push અને swap ક્રિયાઓને પ્લેટફોર્મ-વિશિષ્ટ પ્રતિબંધો સાથે દસ્તાવેજીકૃત કરે છે. પહેલેથી રૂપરેખાંકિત સુસંગત tagged યુનિટ માટે ઉદાહરણ દિશા ingress પર input-vlan-map pop અને egress પર output-vlan-map push છે. તે લીટીઓ ક્રિયાઓ દર્શાવે છે, સંપૂર્ણ ઇન્ટરફેસ અથવા સર્કિટ રૂપરેખાંકન નહીં. એક જ ઉપકરણ કુટુંબનું ઉદાહરણ સર્વત્ર લાગુ કરવાને બદલે સચોટ પ્લેટફોર્મ અને રિલીઝની પુષ્ટિ કરો.

યુનિટની સમર્થિત VLAN અને encapsulation સેટિંગ્સે હજી પણ ઇચ્છિત ટૅગ અને વર્ગીકરણ વ્યાખ્યાયિત કરવું પડશે. ખોટા ફ્રેમનું વર્ગીકરણ કરતા યુનિટ પરનું રીરાઇટ વિધાન સમસ્યા સુધારતું નથી, ખસેડે છે.

સેવા માટે જરૂરી કોઈપણ આંતરિક ગ્રાહક ટૅગ સાચવો. સ્ટૅક કરેલા ટૅગમાં, કંઈપણ દૂર કરતાં પહેલાં નક્કી કરો કે તમે કયો બાહ્ય ટૅગ બદલી રહ્યા છો.

કદનું બજેટ બનાવો, ફક્ત ટૅગનું નહીં

કદ બજેટમાં રાખેલા ટૅગ, વાસ્તવિક MPLS સ્ટેક અને control word સામેલ કરો. RFC 8469 Ethernet pseudowire માટે control word ની ભલામણ કરે છે, અને આ ભલામણ ફ્રેમ બજેટ બદલે છે, તમારું પ્લેટફોર્મ તેને ડિફૉલ્ટ રૂપે સક્ષમ કરે કે ન કરે. MTU બેભાગી સમાધાન કરો, તેની ચેતવણીને સમારકામ તરીકે દબાવવાને બદલે. દબાવેલી ચેતવણી તારીખ ભૂંસી નાખેલી આયોજિત અટકાવ છે.

બંને પ્રોવાઈડર ધાર પર એ જ બજેટ તપાસો, કારણ કે એક બાજુ ટૅગ અને બીજી બાજુ control word ઉમેરવું પહેલાં યોગ્ય રહેલા પેલોડને તોડવા માટે પૂરતું છે.

જો સંખ્યાઓ મેળ ન ખાય, તો યોજના બદલો, લોગિંગ સ્તર નહીં.

તેને ફ્રેમ દર ફ્રેમ સ્વીકારો

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

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

સર્કિટ ત્યારે પૂર્ણ થાય છે જ્યારે બંને દિશાઓ તમે શરૂઆતમાં લખેલા કરાર સાથે મેળ ખાય છે, ત્યારે નહીં જ્યારે પહેલી દિશા પાસ થાય.