Оразмеряване на голяма 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Записвайте какво прави платформата при пика на скока, а не в покой, и го повторете с включени функции за сигурност. Прототип, който показва само тиха таблица, е тест на паметта, а паметта никога не е била интересното число.