MPLS маршрутизация на клонове: какво научава CE и от кого

Хост в един клон отваря връзка към сървър в друг, а двата обекта стоят зад една и съща управлявана MPLS VPN на 3-то ниво. Хостът знае само своя шлюз по подразбиране и нищо друго, което е правилно. Важното е, че локалният клиентски ръб предава пакета към ръба на доставчика си, а VPN състоянието за маршрутизация на доставчика го доставя до клона, който притежава префикса на местоназначението.

Проследяването на един пакет по пътя е най-бързият начин да се види коя част е отговорност на клиента и коя принадлежи на услугата.

10.20.0.0/24 → CE-A → PE → provider core → PE → CE-B → 10.30.0.0/24

Къде свършва работата на всеки хоп

CE-A се нуждае от маршрут за отдалечената LAN, който сочи към локалното му свързване с доставчика, а не към WAN адреса на отдалечения клон. След това доставчикът пренася пакета през собственото си ядро чрез VPN състоянието за маршрутизация, а CE-B го доставя в LAN-а на местоназначението. На нито един етап хостът не трябва да разбира етикети, VRF или интернет връзката на отсрещната страна.

Грешката, която постоянно се появява в тикетите, е WAN адресът на клон B да се конфигурира като следващ хоп в клон A. Двата клона са купили същата услуга, затова изглежда, че трябва да са съседи. Те не са: следващият хоп трябва да е достижим чрез дизайна на маршрутизация, който действително имате, а отдалеченият CE обикновено е на много хопове разстояние зад оборудване, което не администрирате. Статичен маршрут, изграден върху това допускане, се показва като активен и не се разрешава до нищо, което е по-лошо от липсващ маршрут, защото изглежда правилен в таблицата.

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

За какво трябва да се споразумее предаването

Изберете механизма заедно с доставчика, а не около него. Статични маршрути, BGP или споразумение за протокол за маршрутизация между CE и PE са еднакво законни, а OSPF има дефиниран модел за MPLS VPN при такова предаване. Никое от тях не е причина да се изгради OSPF съседство между два отдалечени клиентски ръба през неопределено ядро на доставчик, защото това е дизайн, с който доставчикът не се е съгласил и не може да поддържа.

Преди нова LAN да влезе в експлоатация, запишете четири неща: префикса, локалния следващ маршрут при CE, анонса, който доставчикът ще приеме, и маршрутите, които доставчикът ще върне. Добавете всякакво филтриране, ограничения за префикси или ограничения между обектите, които договорът налага. Здравословното съседство е канал за обмен на информация и не е доказателство, че даден префикс е приет; сесията може да е активна, докато новата ви подмрежа стои във филтър.

След това проследете отговора. Клон B се нуждае от маршрут обратно към изходната LAN, а хостът от приемащата страна — от свой шлюз и свои разрешения за услугата. Маршрут, който се появи на CE-A, установява половин обиколка, а половин обиколка е причината една посока на ping тест да изглежда здравословна, докато приложението все още се проваля.

Проверете двете предавания преди приемане

Съберете състоянието на маршрутизацията при двата клиентски ръба, потвърдете с доставчика, че предвидените LAN префикси са приети във VPN, и след това тествайте едно разрешено приложение във всяка посока. Само таблиците за маршрутизация не доказват, че приложението работи, а само тест на приложението не ви казва коя контролна равнина се е провалила, когато то не работи.

show ip route vrf BRANCH 10.30.0.0
show ip bgp vpnv4 vrf BRANCH
show ip cef vrf BRANCH 10.30.0.10

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

Знайте какво не предоставя услугата

Това е маршрутизиран достъп от 3-то ниво. Това не е верига от 2-ро ниво, която разпространява broadcast между офисите, така че протоколите за откриване, приложенията, зависими от broadcast, и допусканията за споделен сегмент не пътуват с нея. Печатането, разглеждането на имена и всичко, което зависи от локален сегмент, се нуждае от собствен дизайн.

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

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