ECMP դեպի մեկ VTEP։ որտեղից է գալիս VXLAN-ի էնտրոպիան
Հեռավոր VTEP-ն կարող է ունենալ հավասար արժեքով մի քանի հաջորդ ցատկ, բայց /32-ը դրանք օգտակար չի դարձնում։ Բաշխումը կախված է արտաքին tuple-ից և աղբյուրի պորտի հեշից։
Այն պնդումը, թե հավասար արժեքով բազմուղին անիմաստ է հոսթի երթուղու համար, կրկնվում է այնքան հաճախ, որ ճիշտ է հնչում։ /32-ը ընտրում է նպատակակետ հասցե, և այդ ընտրության մեջ ոչինչ չի սահմանափակում փաթեթը մեկ ֆիզիկական կապով։ Երբ նպատակակետը հեռավոր VXLAN թունելի վերջնակետն է, մի քանի հաջորդ ցատկ կարող են կրել տարբեր overlay հոսքեր, և դա անում են, թե ոչ՝ կախված է նրանից, թե ինչ է թույլատրվում տեսնել փոխանցման հեշին։ Մնացածը թվաբանություն է արտաքին վերնագրի վրա, ոչ թե նախածանցի հատկություն։
Երթուղին որոշում է հասանելիությունը, հեշը՝ բաշխումը։
Առասպել․ /32-ը նշանակում է մեկ ուղի
OSPF-ը կարող է հայտնել հավասար արժեքով հասանելիություն VTEP-ի loopback-ին, մինչդեռ փոխանցման աղյուսակը տեղադրում է հաջորդ ցատկերի խումբ նույն նախածանցի համար։ Արձանագրությունը տալիս է թեկնածուներին, հարթակը որոշում է, թե որոնք են օգտագործելի և ինչպես է նշանակվում փաթեթը։ Ոչ մի երթուղավորման արձանագրություն չի հաշվարկում նոր հեշ յուրաքանչյուր ինկապսուլացված կադրի համար։ Հենց այդ բաժանումն է պատճառը, որ նույնական երթուղիներ ունեցող երկու երթուղիչներ կարող են տրաֆիկը տարբեր կերպ բաշխել։
Նայեք տեղադրված փոխանցման գրառմանը, ոչ միայն երթուղու ցուցադրմանը, քանի որ սարքաշարի կամ քաղաքականության սահմանափակումները կարող են դուրս գցել թեկնածուներ, որոնք կառավարման հարթությունը դեռ հայտարարում է։
Որտեղից պետք է գա էնտրոպիան
Երկու VTEP-ների միջև արտաքին աղբյուրի և նպատակակետի հասցեները մնում են ֆիքսված, իսկ UDP նպատակակետ պորտը սովորական տեղակայման մեջ 4789 է։ Հեշը, որը կարդում է միայն այդ արժեքները, տեսնում է հաստատուն մուտք և վերադարձնում հաստատուն ուղի։ Ինչ-որ բալ արտաքին վերնագրում պետք է փոխվի, և VTEP-ն այն սարքն է, որը կարող է դա անել։
RFC 7348 առաջարկում է UDP աղբյուրի պորտը ստանալ ինկապսուլացված կադրի ներսի դաշտերից։ Այնուհետև տարբեր ներքին զրույցներ առաջացնում են տարբեր արտաքին tuple-ներ, ինչը սովորական տրանսպորտային հեշին աշխատելու բան է տալիս։
Եթե փոխանցման սարքաշարը կարող է ավելի խորը նայել փաթեթի մեջ, ստուգեք, թե նրա հեշի իրականացումը որ ներքին դաշտերն է աջակցում։ Այդ խորությունը չպետք է համարել պահանջ բոլոր underlay սարքերի համար, քանի որ միայն աղբյուրի պորտի փոփոխականությունն արդեն իսկ բացահայտում է օգտակար տարբերություններ։
Ստուգեք այն հեշը, որը իրականում ստանում եք
Չափեք, այլ ոչ թե ենթադրեք։ Վերցրեք ինկապսուլացված տրաֆիկի նմուշ և նայեք արտաքին աղբյուրի պորտերին, ապա համեմատեք արդյունքը փոխանցման գրառումների և յուրաքանչյուր կապի հաշվիչների հետ։
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-ը չի փոփոխում դաշտը, և underlay-ի ոչ մի կարգավորում բեռը չի բաշխի։ Շատ տարբեր պորտեր՝ մեկ օգտագործվող հաջորդ ցատկով, ավելի շուտ մատնանշում են փոխանցման խմբին։
Գրանցեք հաշվիչները նմուշից առաջ և հետո, և նկատեք uplink-ները կիսող անկապ տրաֆիկը, հակառակ դեպքում թվերը ավելի վատ կերևան, քան հեշը արժանի է։
Ինչ չի նշանակում հավասարաչափ բաշխումը
Հոսքի հաշվով հեշը նախատեսված է մեկ զրույց մեկ ուղու վրա պահելու համար, քանի դեռ նրա մուտքերը և հասանելի ուղիների բազմությունը մնում են անփոփոխ։ Այդ պատճառով մեկ մեծ TCP փոխանցումը չի միավորում բոլոր uplink-ները, և կապեր ավելացնելը չի արագացնի այդ հոսքը։ Սա նորմալ վարք է, ոչ թե խափանում։
Մի քանի հոսք կարող են նաև պատահաբար բախվել նույն հաջորդ ցատկի վրա։ Կարճ նմուշը կարող է շատ ծուռ թվալ, մինչ հեշը անում է հենց այն, ինչի համար կարգավորվել է, և կապի խափանումը կամ ուղիների բազմության փոփոխությունը կարող են տեղափոխել հաստատված հոսքերը փոխանցման կեսին։
Փորձարկեք ներկայացուցչական հասցեների զույգերով, տրանսպորտներով և արագություններով՝ հաստատված պլանի համաձայն, և կապերի ագրեգացիայի անդամների ընտրությունը առանձին պահեք երթուղավորված բազմուղու ընտրությունից, որովհետև հեշավորման երկու փուլեր կազմում են իրենց սեփական օրինաչափությունը։ Լցված հաջորդ ցատկերի խումբը և տեսանելի արտաքին էնտրոպիան բացատրում են արդյունքը, նախածանցի երկարությունը՝ ոչ։