DMVPN WAN-ի անցում պահուստի՝ երթուղային քաղաքականությո՞ւն, թե՞ թունելի անջատում
Պահուստի անցումը երկու տարբեր բան է նշանակում՝ քաղաքականություն, որը դադարում է ընտրել հաջորդ թռիչքը, կամ թունել, որը վարչականորեն իջնում է։ Ընտրեք՝ կախված նրանից, ինչ է դրանից կախված։
Երկու WAN ունեցող DMVPN հանգույցը պահուստի է անցնում երկու եղանակներից մեկով, և տարբերությունը մեծ է, քան թվում է։ Մեկը փոխում է, թե երթուղային քաղաքականությունը որ հաջորդ թռիչքն է ընտրում, այնպես որ փաթեթները շարունակում են հոսել, և փոխվում է միայն դրանց ելքը։ Մյուսը վարչականորեն անջատում է թունելը, ինչը իր հետ իջեցնում է այդ ինտերֆեյսի բոլոր ծառայությունները։ Երկուսն էլ կարող են ճիշտ լինել, քանի որ պատասխանում են տարբեր հարցերի։
Որոշումը գալիս է կարգավորումից առաջ
Երեք պայման է սա որոշում ձեզ համար։ Արդյո՞ք ուրիշ ինչ-որ բան կախված է նրանից, որ թունելի ինտերֆեյսը միացած լինի, օրինակ՝ երկրորդ DMVPN պրոֆիլը կամ դրա վիճակը կարդացող մոնիտորը։ Արդյո՞ք այն թրաֆիկը, որը պետք է անցնի պահուստի, կրում է իր սեփական քաղաքականությունը, թե՞ հենվում է գլոբալ երթուղային աղյուսակի վրա։ Եվ արդյո՞ք օպերատորին անհրաժեշտ է միանշանակ վիճակի փոփոխություն, թե՞ հանգիստ ուղու փոխարկումը ընդունելի է։ Պատասխանեք այդ երեքին, և ընտրությունը սովորաբար ինքն է կատարվում։
Եթե անջատումը իջեցնի աշխատող ծառայություններ, ապա երթուղային քաղաքականությունը ավելի փոքր գործողություն է։ Եթե պահանջն այն է, որ թունելը չգոյություն ունենա, քանի դեռ առաջնային WAN-ը իջած է, ոչ մի քաղաքականության գրառում չի կարող դա արտահայտել։
Գրեք պատասխանը, որովհետև կարգավորումը հեշտ մասն է։
Ինչ է իրականում փոխում երթուղային քաղաքականությունը
Քաղաքականության վրա հիմնված երթուղավորման դեպքում հետևվող օբյեկտը կարող է կառավարել հաջորդ թռիչքը։ Երթուղու քարտեզի գրառումը նշում է հաջորդ թռիչքի թեկնածուին և հետևվող օբյեկտին, որը պետք է միացած լինի այն օգտագործելու համար, և այդ հետևման վիճակը գալիս է IP SLA զոնդից։ Երբ օբյեկտն իջնում է, գրառումը դադարում է համապատասխանել, և փաթեթը գնահատվում է հաջորդ գրառմամբ կամ սովորական երթուղային աղյուսակով։
Այս վերջին մանրամասնությունը զարմացնում է մարդկանց. քաղաքականությունը, որը դադարում է ընտրել հաջորդ թռիչքը, սովորաբար թույլատրում է սովորական երթուղավորում՝ թրաֆիկը արգելափակելու փոխարեն։ Եթե ձեզ անհրաժեշտ է սև խոռոչ խափանման դեպքում, դուք պետք է այն գրեք։
Շարահյուսությունը տարբերվում է հարթակների և թողարկումների միջև, այնպես որ ստուգեք ուղեցույցը ձեր իրականում գործարկվող տարբերակի համար։
Ինչ է փոխում թունելի անջատումը
Ինտերֆեյսի անջատումը փոխում է վարչական վիճակը։ Դրանից կախված յուրաքանչյուր թունել, երթուղի և սեսիա իջնում է միանգամից, ինչը հենց այն է, ինչ ուզում եք, եթե թունելը այն բանն է, որը պետք է անհետանա։ Այսպես է նաև EEM հավելվածը WAN խնդիրը վերածում խափանման, որը ներառում է նաև անկապ ծառայություններ։
Եթե ընտրում եք այս ուղին, սահմանափակեք հավելվածը մեկ ինտերֆեյսով և մեկ գործարկիչով, պահպանեք նախորդ վարչական վիճակը, սահմանեք վերականգնման գործողությունը և համոզվեք, որ կրկնվող տատանումները չեն կարող այն հանգույցի մեջ գցել։
Կոշտ կոդավորված վերականգնման հրամանը կարող է նաև վերացնել մեկ այլ անձի կատարած սպասարկման անջատումը։
Թող զոնդը գնա այն ուղով, որը դուք եք մտածում
Զոնդը, որը հետևում է ընթացիկ լավագույն երթուղուն, տեղափոխվում է պահուստային WAN՝ մնացած ամեն ինչի հետ միասին, և հետո հայտնում է, որ առաջնայինը առողջ է, որովհետև այլևս չի օգտագործում այն։
Ամրացրեք զոնդը այն ուղու ինտերֆեյսին կամ աղբյուրի հասցեին, որը փորձարկում եք։ Ստուգեք նաև, թե ինչի վրա է ուղղված, քանի որ մատակարարի հաջորդ թռիչքին հասնելը ավելի քիչ է ապացուցում, քան այն ծառայությանը հասնելը, որի համար գոյություն ունի թունելը։ Սահմանեք վերև և ներքև ուշացումները գիտակցաբար. կարճ ներքև ուշացումը արագ է արձագանքում և տատանվում, մինչդեռ երկարը դիմանում է կարճ ցնցումներին և թաքցնում իրական խափանումները։ Cisco-ի IOS XE-ում հետևման և քաղաքականության երթուղավորման ուղեցույցը փաստաթղթավորում է աջակցվող համակցությունները, և ձեր հարթակի գործառույթների հավաքածուն որոշում է, թե դրանցից որոնք կարող եք օգտագործել։
Գրանցեք երկու ուշացումների արժեքները հետևվող օբյեկտի կողքին, այլապես ոչ ոք չի իմանա, թե ինչու այն այդպես վարվեց։
Որոշեք վերականգնումը, ապա ստուգեք
Վերականգնումն արժանի է իր որոշմանը։ Կապը, որն անընդհատ հատում է շեմը, կարող է սեսիաները ավելի հաճախ տեղափոխել, քան հստակ ձախողվածը, և յուրաքանչյուր տեղափոխում արժենում է բանալիների վերաբանակցում և հավելվածի կրկնակի փորձեր։ Ընտրեք կայունության պահանջ և թող ուշացումը արտահայտի այն։ Այնուհետև ստուգեք փոփոխության պատուհանում՝ զոնդի ուղին տեսանելի պահելով. ընտրված երթուղին, արտաքին գործընկերոջ ուղին և ինչ իրականում արեց հավելվածը։
Եթե պահուստի անցումը աշխատում է, բայց հավելվածը դեռ կոտրվում է, խնդիրը երթուղավորման շերտից վեր է, և ոչ մի հետևում այն չի ուղղի։
Պահեք այդ պատուհանի ապացույցները, քանի որ հաջորդ փոփոխությունը համեմատվելու է դրանց հետ։