Մեծ աստղային VPN-ի չափը որոշելիս՝ նախ հաշվեք, նոր ընտրեք BGP
Նախածանցերը հեշտ թիվն են։ Աշխատանքային նստաշրջանները, թարմացումների հոսքը և հանգույցի խափանումից հետո վերականգնումը որոշում են՝ դիմանում է արդյոք նախագիծը մի քանի հազար մասնաճյուղերի դեպքում։
Երեք հազար մասնաճյուղը հնչում է որպես երթուղորման խնդիր, բայց իրեն պահում է որպես հաշվապահական խնդիր։ Նախածանցների ընդհանուր քանակը հաշվարկվում է տասը րոպեում, և դա հազվադեպ է այն թիվը, որ ցավ է պատճառում։ Ցավ է պատճառում յուրաքանչյուր նստաշրջանի աշխատանքը, թարմացումների պոռթկումը, երբ ընդհանուր բաղադրիչը խափանվում է, և այն ժամանակը, մինչև փոխանցումը նորից համապատասխանի նոր տոպոլոգիային։
Ուստի անցեք թվաբանությունը ճիշտ հերթականությամբ։ Հաշվեք կապերը, հաշվեք նախածանցներն ու այլընտրանքները, ապա հաշվեք, թե ինչ է կատարվում վատ ժամին, և միայն դրանից հետո համեմատեք արձանագրություններն ու հարթակները։ Հակառակ հերթականությամբ վարժությունը վերածվում է երթուղիների սահմանների շուրջ վեճի, որը ոչ ոք չի կարող ավարտել սեղանին եղած տեղեկություններով։
Չորս բյուջե, ոչ մեկը
Յուրաքանչյուր բյուջե պատասխանում է մեկ այլ հարցի, և յուրաքանչյուրը կարող է սահմանափակող լինել տարբեր հարթակում։ Դրանք առանձին գրելը թույլ չի տալիս, որ մեկ մեծ նախածանցային թիվը կանգնի ամբողջ նախագծի փոխարեն։
| Budget | What you are really counting |
|---|---|
| Sessions | Peers per hub, keepalive or hello processing, authentication state, and the per-neighbor memory that never shows up in a route count |
| Prefixes | Alternatives received, prefixes selected, entries installed for forwarding, and how much of that each spoke is allowed to see |
| Churn | Updates generated by a flapping link, a hub outage, or every branch reconnecting after a regional event |
| Recovery | Time to detect, reselect, reinstall and restore the application, measured end to end rather than per box |
Վերջին երկուսն են, որոնք բաց թողնվում են նախագծի վերանայման ժամանակ։ Ցանցը, որը կայուն վիճակում հարմարավետ տեղավորվում է հիշողության մեջ, կարող է վատ վարվել, երբ չորս հարյուր մասնաճյուղեր վերամիանում են երկու րոպեում, որովհետև աշխատանքը գալիս է ավելի արագ, քան կառավարման հարթությունը հասցնում է այն դատարկել։ Գրանցեք պոռթկումի չափը որպես թիվ, դրա հետ միասին, թե որքան ժամանակ ծառայությունը կարող է մնալ վատթարացած։ Դա անորոշ մտահոգությունը դարձնում է փորձարկում, որը ինչ-որ մեկը կարող է իրականում անցկացնել։
Չորսի մեջ էլ թաքնված է հարթակի հարց. արդյոք գաղտնագրումը, փոխանցումը և երթուղավորումը կիսում են նույն պրոցեսորը, թե ունեն առանձին ուղիներ։ Նույնական երթուղային հզորությամբ երկու սարքեր կարող են շատ տարբեր վարվել պոռթկումի տակ, և տվյալների թերթիկը հազվադեպ է ասում, թե որն եք գնում։
Կատարեք հաշվարկը ձեր սեփական թվերով
Վերցրեք հորինված նախագիծ. 3,000 մասնաճյուղ, յուրաքանչյուրը երեք նախածանց մինչ համախմբումը, և երկու հանգույց յուրաքանչյուր մասնաճյուղի համար՝ ավելորդության համար։ Հանգույցների զույգը պետք է պահի մոտավորապես 9,000 մասնաճյուղային նախածանց մինչ ամփոփումը, և նախագիծը ենթադրում է 6,000 մասնաճյուղ-հանգույց նստաշրջան, եթե յուրաքանչյուր մասնաճյուղ հարակից է երկուսին էլ։
Այժմ ավելացրեք այն մասերը, որոնք նախածանց չեն։ Յուրաքանչյուր նստաշրջան կրում է վիճակ և պարբերական հաղորդագրություններ, նույնիսկ երբ ոչինչ չի փոխվում։ Յուրաքանչյուր հանգույց կարող է պահել մեկից ավելի ուղի մեկ նախածանցի համար, եթե արագ անջատում է սպասվում, ուստի այլընտրանքների թիվը կարող է գերազանցել ընտրվածների թվին։ Եվ յուրաքանչյուր ճյուղի տեսքը առանձին քաղաքականության որոշում է. յուրաքանչյուր մասնաճյուղի տալ բոլոր մյուսների երթուղիները բազմապատկում է աշխատանքը այնպես, ինչը հանգույցի կողմի հաշվարկը չի բացահայտում։
Սրանք պլանավորման թվեր են նախագծային զրույցի համար, ոչ թե որևէ արտադրանքի չափում։ Վարժության օգտակար արդյունքը կորի ձևն է, ոչ թե պնդումը, թե որտեղ է տվյալ երթուղիչը տեղի տալիս։
Ինչ է տալիս BGP-ն, և ինչ է տալիս IGP-ն
BGP-ն առանձնացնում է այն, ինչ երթուղիչը ստացել է, ինչ ընտրել և ինչ հայտարարում է, և դրանցից յուրաքանչյուրը վերահսկվում է քաղաքականությամբ։ Դա հենց այն է, ինչ պետք է մասնաճյուղային ցանցին, որովհետև ճյուղը սովորաբար պետք է տեսնի լռելյայն երթուղին, կենտրոնական ծառայությունները և շատ քիչ այլ բան։ Միայն վերջնական աղյուսակը հաշվելը թաքցնում է այլընտրանքներն ու հայտարարությունները, և դրանք հենց այն մասերն են, որ աճում են, երբ ավելորդություն եք ավելացնում։
IGP-ն ինքնաբերաբար սխալ չէ։ Երբ տոպոլոգիան, տարածքների կառուցվածքը և հարևանության մոդելը համապատասխանում են ծառայությանը, կապի վիճակի արձանագրությունը արագ համընկնում է և ավելի քիչ քաղաքականության կառուցակարգ է պահանջում։ Թակարդն այն ենթադրությունն է, թե այն կարող է արտահայտել նույն արտահանման վերահսկողությունը յուրաքանչյուր հարևանի համար, ինչ BGP-ն. OSPF տարածքը ջրհեղեղի սահման է, ոչ թե զտիչ, որ կարելի է կախել մեկ մասնաճյուղից։
Ամեն դեպքում, նախ որոշեք տեսանելիության մոդելը։ Լռելյայն երթուղիները, կենտրոնական ծառայությունների ամփոփումները կամ մասնաճյուղի ամբողջական մանրամասները երեք տարբեր արտադրանք են, և ամփոփումը, որը թաքցնում է ավելի կոնկրետ խափանում, նախագծային որոշում է, որը պետք է գրվի, ոչ թե հայտնաբերվի խափանման ընթացքում։
Փորձարկեք պոռթկումը, ոչ թե կայուն վիճակը
Համեմատությունը կառուցեք ձեր իրականում սպասվող խափանման շուրջ. հանգույցը իջել է, տարածքային WAN իրադարձություն, կամ սպասարկման պատուհան, որը կես տեղամասերը միանգամից անջատում է։ Չափեք վերականգնումը մասնաճյուղի տեսանկյունից՝ ներառյալ հավելվածը, որովհետև վայրկյաններում համընկնող կառավարման հարթությունը քիչ բան է նշանակում, եթե նստաշրջանը վերականգնելու համար րոպեներ են պետք։
show bgp vpnv4 unicast summary
show ip route vrf BRANCH summary
show processes cpu sorted | include BGP|OSPFԳրանցեք, թե հարթակը ինչ է անում պոռթկումի գագաթնակետին, ոչ թե հանգստի ժամանակ, և կրկնեք դա անվտանգության գործառույթները միացված։ Հայեցակարգի ապացույցը, որը ցույց է տալիս միայն հանգիստ աղյուսակ, հիշողության թեստ է, իսկ հիշողությունը երբեք հետաքրքիր թիվ չէր։