એક VTEP તરફ ECMP: VXLAN એન્ટ્રોપી ક્યાંથી આવે છે

હોસ્ટ રૂટ માટે સમાન-ખર્ચવાળું મલ્ટિપાથ નકામું છે એવું વિધાન એટલી વાર પુનરાવર્તિત થાય છે કે સાચું લાગે. /32 એક ગંતવ્ય સરનામું પસંદ કરે છે, અને તે પસંદગીમાં કંઈ પણ પેકેટને એક ભૌતિક લિંક સુધી મર્યાદિત કરતું નથી. જ્યારે ગંતવ્ય દૂરસ્થ VXLAN ટનલ એન્ડપોઇન્ટ હોય, ત્યારે ઘણા આગળના હોપ વિવિધ ઓવરલે ફ્લો વહન કરી શકે છે, અને તેઓ એમ કરે છે કે નહીં તે ફોરવર્ડિંગ હેશને શું જોવા દેવાય છે તેના પર આધાર રાખે છે. બાકીનું બાહ્ય હેડર પરનું ગણિત છે, પ્રીફિક્સનો ગુણધર્મ નથી.

રૂટ પહોંચ નક્કી કરે છે; હેશ વિતરણ નક્કી કરે છે.

દંતકથા: /32 એટલે એક જ માર્ગ

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

ફક્ત રૂટ ડિસ્પ્લે નહીં, સ્થાપિત ફોરવર્ડિંગ એન્ટ્રી જુઓ, કારણ કે હાર્ડવેર કે નીતિ મર્યાદા એવા ઉમેદવારો કાઢી નાખી શકે છે જે કંટ્રોલ પ્લેન હજી જાહેર કરે છે.

એન્ટ્રોપી ક્યાંથી આવવી જોઈએ

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

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

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

તમને ખરેખર જે હેશ મળે છે તે તપાસો

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

show ip route 10.255.0.5/32
show ip cef 10.255.0.5 internal
ip route show 10.255.0.5
tcpdump -ni eth0 -c 200 'udp port 4789' -vv

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

નમૂનાના પહેલાં અને પછી કાઉન્ટર નોંધો, અને અપલિંક વહેંચતા અસંબંધિત ટ્રાફિકની નોંધ લો, નહીંતર આંકડા હેશને લાયક હોય તેના કરતાં ખરાબ દેખાશે.

સમાન વિતરણનો અર્થ શું નથી

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

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

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