QFX નું MAC EVPN માં કેમ દેખાય છે પણ ફોરવર્ડિંગ ટેબલમાં નહીં

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

બે ટેબલ જે અલગ પ્રશ્નોના જવાબ આપે છે

Junos EVPN માં ડેટાબેઝ દરેક ઇન્સ્ટન્સ માટે MAC સરનામાં યાદી કરે છે અને દરેક કેવી રીતે આવ્યું તે પણ: એક્સેસ પોર્ટથી શીખેલું, Type 2 રૂટમાં પ્રાપ્ત, અથવા મલ્ટીહોમિંગ જૂથના ભાગ તરીકે ચિહ્નિત. Juniper નું show evpn database સંદર્ભ દરેક MAC અને દરેક ઇન્સ્ટન્સ મુજબના ફિલ્ટરને આવરી લે છે જે દૃશ્યને વાંચવા યોગ્ય બનાવે છે. તે ઇન્સ્ટન્સ અને MAC દ્વારા કી કરેલ કંટ્રોલ પ્લેન સારાંશ છે, હાર્ડવેર જે ટેબલથી ફ્રેમ સ્વિચ કરે છે તે નહીં.

સ્વિચિંગ ટેબલ એ જ ફોરવર્ડિંગ સ્થિતિ છે. બંને આઉટપુટ MAC ને VLAN અથવા VNI સંદર્ભ સાથે યાદી કરે છે, અને એટલે જ તેમની લાઇન દર લાઇન સરખામણી થાય છે, અને એટલે જ સરખામણી ભ્રામક બને છે. ડેટાબેઝમાંની એન્ટ્રી કહે છે કે રૂટ અસ્તિત્વમાં છે અને ઇન્સ્ટન્સમાં સ્વીકારાયું છે; પ્લેટફોર્મે તેને ફોરવર્ડિંગ માટે ઇન્સ્ટોલ કર્યું છે કે નહીં તે વિશે તે કંઈ કહેતું નથી.

Type 2 રૂટ MAC, વૈકલ્પિક IP, લેબલ અથવા VNI, રૂટ ડિસ્ટિંગ્વિશર અને દૂરના VTEP નું નામ આપતું નેક્સ્ટ હોપ વહન કરે છે. વાયર અને તે રૂટ વચ્ચે ચાર વસ્તુઓ તૂટી શકે છે: હોસ્ટ કદી શીખાતું નથી, રૂટ કદી જાહેર થતું નથી, ઇમ્પોર્ટ વખતે તે નકારાય છે, અથવા તેનો નેક્સ્ટ હોપ ઉકેલાતો નથી. દરેક નિષ્ફળતા ભિન્ન ટેબલ-સમૂહ ભરેલો છોડે છે, અને એટલે જ આ ક્રમનું નિદાન શક્ય છે.

સ્થાનિક શિક્ષણ હજી પણ પહેલા થાય છે

સામાન્ય ધારણા એ છે કે EVPN MAC શિક્ષણ લઈ લે છે, તેથી ખાલી ડેટાબેઝનો અર્થ ઓવરલે સમસ્યા હોવો જોઈએ. સ્થાનિક શિક્ષણ હજી પણ એક્સેસ બાજુ ચાલે છે, VXLAN પહેલાં જેમ: સ્વિચ માન્ય ફ્રેમનું સ્રોત MAC યોગ્ય VLAN અને સેવામાં શીખે છે, અને પછી જ તેના માટે Type 2 બનાવે છે. કોઈ સંબંધિત ફ્રેમ ન મોકલનાર હોસ્ટ પાસે જાહેર કરવા જેવું કંઈ નથી. જે હોસ્ટની ફ્રેમ VLAN સભ્યપદ, ફિલ્ટર અથવા એગ્રિગેટના ડાઉન સભ્ય દ્વારા કાઢી નાખવામાં આવે છે તે ઓવરલેની દૃષ્ટિએ સરખો દેખાય છે.

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

show interfaces ge-0/0/1.0
show ethernet-switching interface ge-0/0/1.0
show lacp interfaces ae0

બંડલ ઉપર હોવા કરતાં પસંદ કરેલ LACP સભ્યો વધુ મહત્ત્વના છે, કારણ કે એગ્રિગેટ એક સભ્ય પર ઉપર હોઈ શકે છે જ્યારે હોસ્ટનો ટ્રાફિક ડાઉન કે બ્લોક થયેલ લિંક પર હેશ થાય છે. ઇન્ટરફેસ કાઉન્ટર શાંત હોસ્ટને ડ્રોપ કરતા હોસ્ટથી અલગ પાડે છે, કારણ કે જે હોસ્ટ કદી મોકલતું નથી અને જે હોસ્ટની ફ્રેમ વર્ગીકરણ દ્વારા કાઢી નાખવામાં આવે છે તે બંને એ જ ખાલી ટેબલ છોડે છે.

દૂરનું MAC ક્યાં ખોવાય છે

દૂરનું MAC વિરુદ્ધ દિશામાં નિષ્ફળ જાય છે, અને શાંતિથી. Type 2 રૂટ આવે છે, પરંતુ તે ઇન્સ્ટન્સમાં ત્યારે જ પ્રવેશે છે જ્યારે તેનું રૂટ ટાર્ગેટ અને VNI સ્થાનિક રૂપરેખાંકન સાથે મેળ ખાય, અને ત્યારે જ ઉપયોગી બને છે જ્યારે નેક્સ્ટ હોપ પહોંચી શકાય તેવા VTEP માં ઉકેલાય. રૂટ ટાર્ગેટની અસંગતિ BGP ટેબલમાં માન્ય રૂટ છોડે છે જે કોઈ ઇન્સ્ટન્સ કદી માંગતું નથી.

ત્રણ દૃશ્યો ક્રમમાં વાંચો: રૂટની હાજરી, ડેટાબેઝ એન્ટ્રી, ફોરવર્ડિંગ એન્ટ્રી. નીચેના આદેશો દરેક તબક્કે એ જ MAC ને પૂછે છે, અને નમૂનાનું સરનામું આઉટપુટને તુલનાત્મક રાખે છે.

show evpn database instance blue mac-address 02:00:00:00:00:5c extensive
show route table bgp.evpn.0 | match 02:00:00:00:00:5c
show route table bgp.evpn.0 | match 02:00:00:00:00:5c extensive

તે આઉટપુટ ત્રણ અલગ પ્રશ્નોના જવાબ આપે છે. bgp.evpn.0 માં રૂટ હોય પણ ડેટાબેઝ એન્ટ્રી ન હોય તો તે ઇમ્પોર્ટ પોલિસી, રૂટ ટાર્ગેટ કે ઇન્સ્ટન્સ રૂપરેખાંકન તરફ ઇશારો કરે છે. ડેટાબેઝ એન્ટ્રી હોય પણ ફોરવર્ડિંગ એન્ટ્રી ન હોય તો તે પ્લેટફોર્મ પ્રોગ્રામિંગ તરફ ઇશારો કરે છે, જે બીજા એસ્કલેશન માર્ગનું છે. જે સક્રિય રૂટનો નેક્સ્ટ હોપ ઉકેલાતો નથી તે પરિવહન કે લેબલ સમસ્યા છે, અને MAC ડિબગિંગની કોઈ માત્રા તેને સુધારતી નથી.

જે રીબૂટે તેને સુધાર્યું તે ખૂબ ઓછું સાબિત કરે છે

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

કોઈપણ જાળવણી વિન્ડો પહેલાં, રીસ્ટાર્ટ શું ભૂંસશે તે કેપ્ચર કરો. આ ત્રણ આદેશો પહેલાં અને પછીની સરખામણી માટે પૂરતા છે, અને ઉપકરણ પર કંઈ બદલતા નથી.

show evpn database instance blue
show route table bgp.evpn.0
show version

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

ચાર નિરીક્ષણ જે મોટાભાગના કિસ્સા નક્કી કરે છે

ચાર નિરીક્ષણ લગભગ દરેક કિસ્સો આવરી લે છે: એટેચમેન્ટ અને તેની સેવા, નમૂના મૂલ્ય તરીકે MAC, રૂટ અને ડેટાબેઝની સ્થિતિ, અને વપરાતું બિલ્ડ. એવું MAC પસંદ કરો જે સ્પષ્ટપણે નમૂનો હોય જેથી કોઈ તેને પ્રોડક્શન સરનામું ન સમજે: પ્રથમ ઓક્ટેટ 02 સ્થાનિક રીતે સંચાલિત યુનિકાસ્ટ સરનામું દર્શાવે છે, બાકીના ઓક્ટેટ મુક્ત છે, અને તેથી 02:00:00:00:00:5c સુરક્ષિત પ્લેસહોલ્ડર છે.

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