Ինչու AWS VGW ենթացանցի երթուղին չի կարող ընտրել մեկ VPN թունել
Դեպի վիրտուալ մասնավոր դարպաս ենթացանցի երթուղին չի կարող անվանել իր թունելներից մեկը։ Որտեղ է իրական նախապատվությունը՝ AS_PATH, թունելի առողջությունը և ստատիկ երթուղիները։
Երկու Site-to-Site VPN միացումներ ավարտվում են մեկ վիրտուալ մասնավոր դարպասի վրա և հայտարարում են նույն ճյուղի նախադիրքը։ Ենթացանցի երթուղիների աղյուսակը պահում է մեկ գրառում այդ նախադիրքի համար՝ ուղղված դարպասին, և ոչ մի դաշտ, որը կանվանի թունել։ Ուստի միացումների միջև նախապատվությունը տեղի է ունենում այնտեղ, որտեղ կոնսոլը այն երթուղավորում չի անվանում։ Իմանալը, թե որ շերտն է տիրում որոշմանը, տարբերությունն է աշխատող պահուստի և ոչինչ չփոխող փոփոխության միջև։
Երկու շերտ խաղի մեջ են՝ VPC երթուղին, որը նշում է դարպասը, և դարպասի սեփական թունելի ընտրությունը։ Դրանք խառնելը ստեղծում է փոփոխություններ, որոնք երթուղիների աղյուսակում ճիշտ են թվում և երբեք չեն տեղափոխում ոչ մի փաթեթ։
Երկու շերտ, որոնք մեկի տեսք ունեն
Ենթացանցի երթուղին պատասխանում է մեկ հարցի՝ այս նպատակակետի համար ո՞ր կապը։ Դրա թիրախը վիրտուալ մասնավոր դարպասն է, և դրա չափանիշը մրցում է միայն նույն աղյուսակի այլ երթուղիների հետ։ Այդ գրառման մեջ ոչինչ չի տարբերում թունել մեկը թունել երկուսից կամ A միացումը B միացումից։ Ավելի կոնկրետ նախադիրքը այլ նպատակակետային համապատասխանություն է, ոչ թե ավելի նուրբ ուղու ընտրություն։
Դարպասը պատասխանում է հաջորդ հարցին՝ այդ նախադիրքի համար պահվող թունելներից ո՞րն է հիմա տեղափոխում երթևեկությունը։ Այդ որոշումը գալիս է թունելի առողջությունից և հաճախորդի դարպասից ստացված BGP հատկանիշներից, և այն երբեք չի հայտնվում ենթացանցի երթուղիների աղյուսակում։
Ինչ է VGW-ն իրականում համեմատում
Առողջությունն առաջինն է։ Անջատված թունելը կամ չբարձրացած BGP սեանսը պարտվում է նախքան որևէ հատկանիշի քննարկումը։ Այդ պատճառով արդեն ձախողվող միացման վրա ուղու նախադասումը ոչինչ չի փոխում։
Նույն նախադիրքի համար թույլատրելի ուղիների մեջ AWS-ը նախընտրում է ավելի կարճ AS_PATH-ը։ Երբ երկու ուղիներ հավասար երկարություն ունեն, այն համեմատում է MED-ը՝ պայմանավորված ուղու առաջին AS-ի վերաբերյալ փաստաթղթավորված պայմանով։ Կարդացեք հրապարակված կարգը, ոչ թե բանահյուսական տարբերակը, որովհետև բանահյուսությունը սովորաբար բաց է թողնում առողջության քայլը և ստատիկ երթուղու բացառությունը։ Մեկ հետևանք՝ պահուստային միացման վրա երեք նախադասումը հիմնականը դարձնում է խիստ ավելի կարճ, և դա նախապատվությունն արտահայտելու սովորական ձևն է։
Նախադասումը, և երբ այն ոչինչ չի անում
Նախադասումը տեղի է ունենում հաճախորդի դարպասի ելքային հայտարարություններում, ոչ թե AWS-ի ներսում։ Դուք ավելացնում եք ձեր ASN-ը երկու կամ երեք անգամ այն նախադիրքին, որը ցանկանում եք, որ AWS-ը խուսափի, և այնուհետև AWS-ը տեսնում է ավելի երկար ուղի այդ միացման համար։ Հիմնական միացումը պահում է առանց նախադասման հայտարարությունը։ Եթե երկու միացումներն էլ հայտարարում են նույն ASN-ից նույն թվով նախադասումներով, դուք ոչ մի նախապատվություն չեք արտահայտել։
Փոփոխությունից հետո ստուգեք ստացված ուղին AWS-ի կողմում։ Նախադասումը, որը երբեք չի լքել հաճախորդի սարքը, ճիշտ նույն տեսքն ունի, ինչ AWS-ի անտեսածը։
Ստատիկ երթուղիները անտեսում են ամբողջ փաստարկը
Եթե միացումն օգտագործում է ստատիկ երթուղավորում, երկարացնելու AS_PATH չկա։ AWS-ը փաստաթղթավորում է ստատիկ VPN երթուղիները որպես նույն նախադիրքի համար BGP-ով սովորած երթուղիներից առաջնահերթ, ուստի խառը ձևավորումն իրեն չի պահում որպես լիովին դինամիկ։ Նախ որոշեք երթուղավորման տեսակը, ապա ընտրեք դրա համար գոյություն ունեցող նախապատվության մեխանիզմը։
Նույն նախադիրքը հայտարարող երկու ստատիկ միացումների դեպքում օգտակար լծակը նախադիրքն է՝ հայտարարեք ավելի կոնկրետ տիրույթ այն միացման վրա, որը ցանկանում եք օգտագործել, և ընդունեք, որ փոխել եք, թե որ նպատակակետն է համապատասխանում, ոչ թե որ ուղին է հաղթում։
Ինչու տրանզիտ դարպասը այլ պատասխան է
Տրանզիտ դարպասը աջակցում է հավասար արժեքի բազմուղի VPN կապերի վրա, ուստի երկու միացումներ կարող են կիսել երթևեկությունը՝ փոխարենը մեկը պահուստում կանգնելու։ Այդ ձևավորումն ունի ձախողման այլ մակերես՝ հոսքերը տարածվում են թունելներով, և մեկ թունելի անկումը տեղափոխում է բեռի միայն մի մասը։ VGW-ի բաղադրատոմսը տրանզիտ դարպասի վրա պատճենելը կամ հակառակը ստեղծում է ակնկալիքներ, որոնք ոչ մի հարթակ չի բավարարում։
Ընտրեք մոդելը մեխանիզմից առաջ՝ ակտիվ և պահուստ ամրագրված նախապատվությամբ, կամ ակտիվ և ակտիվ ECMP-ով։
Ինչ ստուգել կարգավորումից հետո
Հերթով հաստատեք չորս բան։ Ենթացանցի աղյուսակը դեռ լուծում է նախադիրքը նախատեսված դարպասին։ Դարպասը երկու թունելներն էլ ցույց է տալիս որպես ակտիվ։ Ստացված AS_PATH-ը այն միացման վրա, որը ցանկանում եք խուսափել, ավելի երկար է, քան մյուսը։ Եվ այդ ենթացանցի ինստանսից իրական հոսքն անցնում է սպասվող թունելով՝ դիտարկված երկու ծայրերում, ոչ թե եզրակացված կանաչ կարգավիճակից։
Այնուհետև գործարկեք հաստատված փոխարկման թեստը և տեսեք, թե ինչպես է վերապրած ուղին կրում ծառայությունը։ Միայն կոնֆիգուրացիայի տարբերության մեջ գոյություն ունեցող նախապատվությունը դեռ նախապատվություն չէ։