EVPN નો શાંત હોસ્ટ કદી ઉકેલાતો નથી: ARP ને અનુસરીને બાઈન્ડિંગ સુધી જાઓ

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

આગલો ARP અથવા ND વિનિમય અનુસરો

IPv4 માટે, વિનંતી કરતા હોસ્ટનો ARP વિનિમય જુઓ; IPv6 માટે, Neighbor Solicitation અને Advertisement અનુસરો. ખાતરી કરો કે વિનંતી ઇચ્છિત સ્થાનિક સેગમેન્ટ અને ઇચ્છિત VNI માં પ્રવેશે છે, કારણ કે જે વિનંતી કદી યોગ્ય bridge domain સુધી પહોંચતી નથી તેનો કોઈ પ્રોક્સી જવાબ આપી શકતું નથી.

પછી જુઓ કે fabric લક્ષ્ય વિશે શું જાણે છે. ફક્ત MAC માર્ગ Layer 2 ગંતવ્યને ઓળખી શકે છે જ્યારે પ્રોક્સી પાસે હજી તેના માટે કોઈ IP-to-MAC બાઈન્ડિંગ નથી. આ અલગ રેકોર્ડ છે, અને એક તપાસવાથી બીજા વિશે કંઈ ખબર પડતી નથી.

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

બે રેકોર્ડ જે મેળ ખાવા જોઈએ

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

દૂરના જોડાણ પર, તપાસો કે એન્ડપોઈન્ટ ખરેખર વિનિમય પ્રાપ્ત કરે છે અને તેનો જવાબ આપે છે. તેનો જવાબ સ્થાનિક શિક્ષણ અને અનુરૂપ EVPN જાહેરાતને રિફ્રેશ કરે છે, તેથી જ મેન્યુઅલ ping વસ્તુઓ સુધારતું લાગે છે: તમે એ ટ્રાફિક પેદા કર્યો જેની fabric રાહ જોતું હતું. તે એ પણ સમજાવે છે કે સુધારો કેમ ટકતો નથી: રિફ્રેશ થયેલી એન્ટ્રી જૂની થતાં જ એન્ડપોઈન્ટ ફરી શાંત થઈ જાય છે. નિર્ધારિત ping લક્ષણની સારવાર કરે છે અને ડિઝાઇનની ખાલી જગ્યા છુપાવે છે.

જવાબ પછી, પસંદ કરેલા માર્ગ અને સ્થાપિત ફોર્વર્ડિંગ સ્થિતિને વિનંતીકર્તા તરફ પાછા અનુસરો. રિઝોલ્યુશન સફળ થવું અને ફોર્વર્ડિંગ સફળ થવું એ બે અલગ ઘટનાઓ છે, અને જે ટિકિટ તેમને ભેગી કરે છે તે તમને ખોટા સ્તરે મોકલે છે.

ધોરણ ખરેખર શું ધારે છે

RFC 9161 ગતિશીલ પ્રોક્સી શિક્ષણ અને અજાણ્યા ARP અને ND વિનંતીઓના ડિફોલ્ટ floodingનું વર્ણન કરે છે. તે floodingનું સંપૂર્ણ દમન ફક્ત એવા ડિપ્લોયમેન્ટ સુધી મર્યાદિત છે જેમના શિક્ષણ અથવા પ્રોવિઝનિંગ ધારણાઓ તેને સુરક્ષિત બનાવે છે, જે મોટાભાગના કન્ફિગરેશન માર્ગદર્શિકાઓ સૂચવે તેના કરતાં સાંકડી શરત છે.

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

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

રિફ્રેશ, વૃદ્ધાવસ્થા અને સ્થિર વિકલ્પ

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

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

જાણીતા, સંચાલિત એન્ડપોઈન્ટ માટે, સ્થિર અથવા કન્ટ્રોલર-પ્રોવિઝન્ડ બાઈન્ડિંગ કાયદેસર બીજું મોડેલ છે. તેને એવા માલિકની જરૂર છે જે બદલી અને સ્થળાંતર સંભાળે, કારણ કે પ્રોવિઝન્ડ રેકોર્ડ જ્યારે હોસ્ટ બીજા પોર્ટ પર જાય ત્યારે જાતે અપડેટ થતો નથી.

આગલી ટિકિટ પહેલાં શું રેકોર્ડ કરવું

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

પછી નક્કી કરો કે ત્રણમાંથી કયું તમે ચલાવવા તૈયાર છો. flooding સાથે શોધ, વાસ્તવિક જીવનકાળ સાથે રિફ્રેશ, અથવા માલિક સાથે પ્રોવિઝનિંગ — બધા વાજબી છે. જે fabric એક માટે કન્ફિગર થયું છે અને બીજા જેવું વર્તવાની અપેક્ષા રાખે છે ત્યાં જ શાંત હોસ્ટ અદૃશ્ય થાય છે.