AWS VGW સબનેટ રૂટ એક પણ VPN ટનલ કેમ પસંદ કરી શકતું નથી

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

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

એક જેવા લાગતા બે સ્તર

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

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

VGW ખરેખર શું સરખાવે છે

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

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

આગળ મૂકવું, અને ક્યારે તે કંઈ કરતું નથી

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

ફેરફાર પછી AWS બાજુએ પ્રાપ્ત પથ તપાસો. જે આગળ મૂકવું ગ્રાહક ઉપકરણ છોડ્યું જ નથી તે AWS એ અવગણ્યું હોય તેવા જ દેખાય છે.

સ્થિર રૂટ આખી દલીલને અવગણે છે

જો કનેક્શન સ્થિર રૂટિંગ વાપરે તો લંબાવવા માટે AS_PATH નથી. AWS સ્થિર VPN રૂટને એ જ પ્રીફિક્સ માટે BGP દ્વારા શીખેલા રૂટ પર પ્રાધાન્ય આપતા દસ્તાવેજીકૃત કરે છે, તેથી મિશ્ર રચના સંપૂર્ણ ગતિશીલ જેવી વર્તતી નથી. પહેલાં રૂટિંગનો પ્રકાર નક્કી કરો, પછી તેના માટે ઉપલબ્ધ પ્રાધાન્યની પદ્ધતિ પસંદ કરો.

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

ટ્રાન્ઝિટ ગેટવે અલગ જવાબ કેમ છે

ટ્રાન્ઝિટ ગેટવે VPN જોડાણો પર સમાન-ખર્ચ બહુપથને ટેકો આપે છે, તેથી બે કનેક્શન એક સ્ટેન્ડબાય રહેવાને બદલે ટ્રાફિક વહેંચી શકે છે. તે રચનાની નિષ્ફળતાની સપાટી અલગ છે: પ્રવાહ ટનલો પર ફેલાય છે, અને એક ટનલ ડાઉન થવાથી ભારનો ફક્ત એક ભાગ ખસે છે. VGW ની રેસીપી ટ્રાન્ઝિટ ગેટવે પર કે ઊલટું નકલ કરવાથી એવી અપેક્ષાઓ ઊભી થાય છે જે બંને પ્લેટફોર્મ પૂરી કરતું નથી.

પદ્ધતિ પહેલાં મોડેલ પસંદ કરો: નિશ્ચિત પ્રાધાન્ય સાથે સક્રિય અને સ્ટેન્ડબાય, અથવા ECMP સાથે સક્રિય અને સક્રિય.

સેટ કર્યા પછી શું ચકાસવું

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

પછી મંજૂર કરેલી ફેલઓવર કસોટી ચલાવો અને બચેલો પથ સેવા વહન કરે છે તે જુઓ. ફક્ત રૂપરેખાંકન તફાવતમાં રહેલું પ્રાધાન્ય હજી પ્રાધાન્ય નથી.