Предаване на L3VPN: частни маршрути, маршрут по подразбиране или пълна таблица?

Веригата ви работи, VRF е конфигуриран и доставчикът задава кратък въпрос, който решава останалата част от дизайна: какво трябва да получи клиентският ръб? Три отговора са обичайни и нито един от тях не следва от факта, че съществува стек от етикети. Това са решения за услугата относно това къде трафикът напуска клона.

Преминаването на предаването подред е най-евтиният начин да се направи правилно. Започвате от това какво се случва с трафика, който не съвпада с нищо, после записвате частните префикси и поведението им при отказ и едва след това говорите колко голям поток сте готови да носите.

Започнете с трафика, който никой не е планирал

Задайте един въпрос, преди да се появи който и да е списък с префикси: когато пакет не съвпада с нито един частен маршрут, накъде трябва да отиде? Клон със собствена интернет връзка обикновено пази локален маршрут по подразбиране, така че обичайният уеб трафик излиза през локалната защитна стена и никога не докосва доставчика. При такъв дизайн VPN носи само отдалечените частни обекти, а по-конкретните префикси правят избора.

Клонът, който трябва да използва централен изход, е обратният случай. Там маршрутът по подразбиране сочи към услугата и доставчикът или централният обект притежава препращането, обратната маршрутизация и всяко преобразуване. Да се каже "по подразбиране към VPN" без такъв собственик води до клон, който резолвва имена и не достига до нищо.

Двата дизайна се различават по това как изглежда отказът на маршрутизацията и затова гадането е скъпо. С локален маршрут по подразбиране загубен частен маршрут изпраща този трафик в интернет, където защитната стена го изхвърля или, по-лошо, отговаря нещо, което не сте предвидили. С централен маршрут по подразбиране същата загуба премахва интернет достъпа напълно и заявката пристига като "целият клон е паднал". Нито един от двата отказа не е грешен сам по себе си, но само един от тях отговаря на услугата, която сте продали, и една BGP конфигурация няма да ви каже кой сте изградили.

Запишете частните префикси заедно със случая на отказ

Изброете префиксите, до които клонът трябва да достигне, и отбележете кои от тях са обобщени. Агрегат, който е с един бит по-широк, привлича неизвестни дестинации във VPN и това е приемливо само ако далечната страна действително ги притежава и препраща.

После опишете желаното поведение, когато частната услуга откаже. Запазен маршрут за отхвърляне държи трафика далеч от неоторизиран път и дава чисто, очаквано прекъсване. Плаващ маршрут по подразбиране може да запази достъпността, като се премести на резервен път, но само ако резервният път има право да носи този трафик.

Пазете достъпността и разрешения отстъп като две отделни изисквания в документа за предаване. Екипите, които ги сливат, в крайна сметка спорят дали клонът е трябвало да падне, вместо да проверят дали договорената политика е приложена.

Проверете какво наистина е инсталирал CE

Намерението на конфигурацията и състоянието на препращането се разминават достатъчно често, че проверката принадлежи на предаването, а не на прегледа на инцидента. На клиентски ръб IOS-XE трите команди по-долу отговарят на три различни въпроса: какво е било предложено, какво е било прието и какво действително се използва.

show ip bgp vpnv4 vrf BRANCH neighbors 192.0.2.1 received-routes
show ip bgp vpnv4 vrf BRANCH
show ip route vrf BRANCH 0.0.0.0

Изпълнете и трите в деня на предаването, а не месец по-късно, докато някой още помни какво е договорено. Първият изход зависи от soft-reconfiguration inbound или от запазено обновяване на маршрути; без нито едно от двете CE не може да ви покаже какво е отхвърлил. Вторият показва приетите и най-добрите пътища след политиката. Третият ви казва накъде наистина отива маршрутът по подразбиране и това е най-полезният ред в цялото предаване.

Направете същите проверки на втори CE, ако обектът е с два канала. Асиметричното приемане между два ръба е честа причина за "работи от един сървър и не работи от друг" и е невидимо в разлика в конфигурацията, която изглежда симетрична.

Обосновете по-голям поток, вместо да го предполагате

Понякога клиентът наистина се нуждае от информация за интернет пътища вътре във VRF, за маршрутизация по политика или за централен изход, който се управлява по префикс. Това е изискване, което трябва да се заяви, очертае и оцени, а не скрит маршрут по подразбиране. То идва с памет за RIB и FIB, процесор за обновявания, поддръжка на филтри и собственик на получената таблица.

Аргументите за капацитет грешат и в двете посоки. Пълна таблица не е забранена във VRF и също не е безплатна. По същия начин не можете да извлечете днешната цена от стар брой маршрути и по-малкото разпределение на етикети не премахва цената за съхранение на маршрути.

Спецификацията BGP/MPLS IP VPN обсъжда няколко схеми за интернет достъп до самата VPN услуга и не обявява пълна таблица или маршрут по подразбиране за задължителни за всеки клиент; именно този раздел си струва да се посочи, когато се появи твърдение за "стандартна практика": RFC 4364.

Затворете предаването, като запишете обявения набор, получения набор и избрания набор до договорената политика за изход и като тествате една частна дестинация, една предвидена публична дестинация и един случай на загуба на маршрут. Подписан запис на тези три теста решава повече спорове от всяко твърдение за това какво правят повечето мрежи.