Нуждае ли се VPNv4 от MPLS в ядрото? Не непременно
BGP VPNv4 договаря контекст за разпределение на маршрути, а не път за препращане. Отделете вноса, разрешаването на следващия хоп и инкапсулацията, която можете да използвате.
Включването на адресното семейство VPNv4 между два рутера създава само контекст за разпределение на маршрути и нищо повече. То не инсталира път за препращане и не казва коя инкапсулация ще пренесе клиентски пакет до отдалечената крайна точка. След като тези два факта се разделят, въпросът „нуждае ли се това от MPLS в ядрото“ се превръща в по-тесен и отговорим въпрос за поддържаната от платформата равнина за данни.
Какво всъщност договаря адресното семейство
Многопротоколният BGP пренася информацията за достижимост на мрежовия слой VPNv4 под AFI 1 и SAFI 128 и всеки запис свързва разграничител на маршрут с префикс и етикет. Сесията договаря, че и двете страни могат да кодират и декодират тази информация. Това, което не договаря, е равнина за данни. Всичко след този абзац се отнася до препращане и нищо от него не се решава от вдигането на сесията.
Така успешната сесия е доказателство за възможност на равнината за управление, а не за препращане. Рутер може да държи хиляди записи VPNv4 и пак да изхвърля всеки клиентски пакет; точно затова двата класа откази се бъркат на първо място.
Обърнете внимание на етикета в NLRI. Той е сервизен етикет, обвързан с префикс във VRF, и има роля при препращането, след като пакетът достигне изходната крайна точка. Дали някое транзитно устройство го чете, е отделно проектно решение.
Получаване, внос и препращане са три стъпки
Получаването на маршрут, разрешението да го използвате и способността да препращате с него се извършват от различни части на устройството. BGP съхранява това, което чува; политиката за внос и съвпадението на маршрутна цел решават кой VRF може да го обмисли; след това равнината за препращане трябва да разреши обявения следващ хоп в нещо, което наистина може да изтласка по кабел.
| Step in the chain | What has to be true | How it fails quietly |
|---|---|---|
| NLRI exchange | Both speakers negotiate the VPNv4 capability | Session stays up while the family is never activated |
| Import eligibility | A route target on the received route matches the VRF import policy | The route exists in the table but never enters the VRF |
| Next-hop resolution | The advertised next hop resolves to a usable tunnel or label path | Best path is selected, then marked unreachable or unusable |
| Encapsulation | The egress endpoint can decapsulate what the ingress produced | Packets arrive and are discarded for a format mismatch |
Именно тази средна стъпка е мястото на най-изненадващите откази. Маршрут може да присъства в таблицата на BGP, валиден и дори най-добър, докато таблицата за маршрути на VRF остава празна, защото нито една маршрутна цел не е съвпаднала със списъка за внос. Нищо не записва протоколна грешка, защото не е възникнала протоколна грешка.
Последната стъпка е мястото, където се проявява поддръжката на платформата. Следващ хоп, достижим в подложката, не се разрешава автоматично като транспорт на VPN услуга и устройството може да изисква конкретен тип тунел, конкретна операция с етикет или и двете. Четенето на състоянието на разрешаване е по-информативно от четенето на броя маршрути.
IP ядрото може да носи стек, който никога не комутира
Разграничението, което си струва да се запази, е между „ядрото не изпълнява MPLS“ и „никъде в услугата няма етикет“. Това са различни твърдения и само първото е за транзитните устройства. RFC 4023 дефинира пренасянето на MPLS през IP или GRE тунели и това е механизмът, който прави второто твърдение възможно върху изцяло IP ядро.
customer packet + service label
encapsulated in GRE, addressed to the egress tunnel endpoint
forwarded by ordinary IP routers on the outer header
decapsulated at the endpoint, label still meaningful
Транзитните рутери препращат по външната IP дестинация и не се нуждаят нито от клиентските префикси, нито от собствена комутация на етикети. В далечния край външният тунел се премахва и сервизният етикет възобновява работата си. Ядрото е преместило непрозрачен полезен товар — точно това, в което IP мрежата е силна.
Това, което този дизайн не ви дава, е универсална гаранция. Той не е доказателство, че всеки рутер разрешава всеки следващ хоп VPNv4 през всеки GRE интерфейс, и не е причина да изтриете работеща собствена MPLS конфигурация. Той е контрапример на универсалното твърдение и практическият въпрос остава локален за платформата. Запишете този въпрос като ограничение на платформата, а не като правило на протокола.
Извървете веригата на кутията, докато се скъса
Започнете от получения маршрут и спрете на първата стъпка, която се провали, защото следващите стъпки не могат да се диагностицират, докато предишна е счупена. Четири команди покриват голяма част от това при типична реализация.
show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_A
Четете ги като последователност, а не като четири независими проверки. Първата потвърждава, че семейството е активно и партньорът обменя маршрути; втората показва дали префиксът е пристигнал с използваем следващ хоп; третата доказва правото за внос; четвъртата показва дали равнината за препращане е обвързала етикет или тунел с него.
След това тествайте пътя на работното натоварване в двете посоки, с MTU, който издържа на инкапсулация. GRE добавя байтове за заглавка и път, който минава малки проби, може да се провали на пакети с пълен размер само в една посока, което изглежда като проблем на приложението, а не на транспорта.
Две оперативни бележки затварят цикъла. GRE е инкапсулация, а не поверителност, затова недоверена транзитна мрежа се нуждае от поддържана схема за сигурност отгоре, а не от предположение. И запишете коя инкапсулация платформата действително поддържа преди прегледа на дизайна, защото този единствен отговор решава дали изцяло IP ядро е валиден избор, или план, който не може да препраща.