RD срещу RT в MPLS VPN: уникалност срещу политика на внос

Разграничителят на маршрути прави припокриващите се префикси различими, а целта на маршрута определя кои маршрути може да внася даден VRF. Проследете един MPLS маршрут през двете роли.

Два клиентски обекта могат да обявяват 10.20.0.0/24 и двата остават валидни в една доставчикова мрежа. Разграничителят на маршрути поддържа тези обявления различни; целта на маршрута решава кой клиентски VRF може да вземе копие. Те стоят една до друга в конфигурацията и вършат съвсем различни работи. Объркването между двете води до промени, които изглеждат разумни и не оправят нищо.

Проследете един маршрут от клиентския ръб до отдалечен VRF и разделението става конкретно: идентичността се прикача, преди маршрутът да влезе в BGP, а политиката за разпространение се оценява, когато маршрутът достигне приемащия доставчиков ръб.

Маршрутът VPN-IPv4 е RD плюс IPv4 префикс

RFC 4364 дефинира адресното семейство VPN-IPv4 като осембайтов разграничител на маршрути, последван от четирибайтов IPv4 адрес. RD се поставя пред клиентския префикс, така че два еднакви префикса от различни обекти стават два различни BGP маршрута.

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

Самият формат на RD е стойност, избрана от администратора, обикновено номер на автономна система и локален номер. Числовата му форма е конвенция, а не знак, че двете полета споделят значение с цел на маршрута, която случайно използва същите цифри.

RD прави припокриващите се префикси различими

Разгледайте две обявления за един и същ префикс. Обект A носи RD 65000:101, а обект B носи RD 65000:202, и двете за 10.20.0.0/24. Сега BGP държи два маршрута VPN-IPv4, които могат да бъдат сравнявани, филтрирани и избирани независимо.

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

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

RT е BGP атрибут, а не етикет в пакета

Политиката за износ прикача една или повече цели на маршрута към маршрута като разширени общностни атрибути на BGP. Приемащият доставчиков ръб сравнява тези атрибути с политиката за внос на всеки VRF. RT пътува с маршрута през контролната равнина. Сравнението се извършва изцяло в маршрутната политика, преди да бъде препратен какъвто и да е клиентски пакет.

Клиентските пакети с данни не носят RT. След като маршрутът е инсталиран в VRF, препращането използва таблицата на този VRF и стека от MPLS етикети, който архитектурата задава. Доставчиковият ръб не чете цел на маршрута от всеки клиентски пакет.

Един маршрут може да носи няколко RT, а един VRF може да внесе няколко. Конфигурацията често изглежда като кратък блок:

vrf definition CUST-A
 rd 65000:101
 address-family ipv4
  route-target export 65000:500
  route-target import 65000:500

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

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

Един маршрут може да е допустим за даден VRF и въпреки това да не се появи в таблицата му за препращане. Допустимостта е филтър; след това нормалният процес на решение на BGP сравнява допустимите маршрути и избира един. По-стар или по-малко предпочитан маршрут може да загуби от друг допустим път.

Проверявайте избрания маршрут, а не само политиката за внос. VRF, който внася RT 65000:500 и не показва маршрут за 10.20.0.0/24, може да е получил маршрута и да го е отхвърлил при избора, или да не го е получил изобщо.

Това разграничение е важно и когато се появи неочакван префикс. Твърде широка политика за внос може да привлече маршрути, които обектът не е възнамерявал да използва, и уникалността на RD не предотвратява това. Обхватът на разпространение е въпрос на RT политика.

Проследете липсващ маршрут в реда на контролната равнина

Започнете с обявлението: изнася ли изходният VRF предвидения RT и съществува ли маршрутът като VPN-IPv4 маршрут на рефлектора на маршрути или на приемащия PE? След това проверете атрибута такъв, какъвто е получен, а не какъвто е конфигуриран при подателя.

След това сравнете списъка за внос на приемащия VRF с действителните RT стойности на маршрута. Накрая прегледайте избрания маршрут в този VRF и обвързването на етикета. Всяка стъпка отговаря на различен въпрос и скокът към RD обикновено пропуска именно грешната.

Запишете RD, изнесения RT, внесения RT и избрания следващ хоп за работещия и за неизправния обект. Четири стойности една до друга превръщат неясното “VPN не предава маршрути” в точната стъпка от контролната равнина, която се различава.

Подобни статии