Защо един наемател в EVPN може да показва няколко route distinguisher
Два RD в един наемател не са конфликт. Проследете от изхода на CLI до MAC-VRF или IP-VRF, който е създал маршрута, после проверете вноса на RT и VNI.
Филтрирате таблицата на EVPN за един наемател и маршрутите носят два различни route distinguisher. Първата реакция е конфликт в конфигурацията и тази реакция обикновено е грешна. Името на наемателя е бизнес етикет, а не единен обект на контролната равнина, затова контекстът за свързване чрез мост и контекстът за маршрутизиране в него могат законно да се обявяват под отделни идентификатори. Проследявайте по един маршрут наведнъж от изхода обратно до локалния обект на услугата, който го е създал, и вторият RD спира да изглежда като грешка.
Започнете от изхода, който ви обърка
Изберете един маршрут, а не цялата таблица. Отбележете типа му, RD, експортираните route target и следващия хоп. Тези четири полета са достатъчни, за да определите кой локален обект го е обявил и коя отдалечена политика трябва да го внесе.
На устройство в стил NX-OS детайлният изглед се достига с show bgp l2vpn evpn route-type 2 detail или show bgp l2vpn evpn route-type 5 detail. В Junos същата информация се намира в show route table bgp.evpn.0 detail. Различен синтаксис, същите полета.
Не започвайте с изравняване на всяко показано число. Изравняването на RD е промяната, която чупи политиката за внос на работещ fabric.
Дайте на всеки идентификатор неговата задача
| Identifier | Question it answers | Where it is used |
|---|---|---|
| Route distinguisher | Which distinct route context contributed this advertisement? | Makes otherwise identical prefixes unique in BGP |
| Route target | Which importing service policy should receive the route? | Extended community matched by import policy |
| VNI | Which VXLAN service context carries the traffic? | Data plane encapsulation and mapping |
MAC-VRF съхранява информация за MAC препращане за bridging услуга. IP-VRF предоставя контекст за IP маршрутизиране на маршрутизирана услуга. Един наемател може да включва и двете и затова един наемател може да създаде повече от един RD без никаква грешка в конфигурацията.
RFC 7432 присвоява RD на обявяващия MAC-VRF на неговия EVPN NLRI и изисква различни RD между MAC-VRF на един и същ PE. Процедурите за route-target са отделни: те позволяват един или повече RT атрибута и разчитат на политиката за внос за членство. Равенството на RD не създава споделено членство и отношението към него по този начин е коренът на това объркване.
Проследете един маршрут от обявата до вноса
Следвайте маршрута в една посока. Потвърдете типа на маршрута, услугата източник, RD, експортираните RT и след това политиката за внос на приемащия PE. Всяка стъпка отговаря на различен въпрос и провал на която и да е стъпка изглежда като същия липсващ префикс от другата страна.
След като маршрутът присъства, прегледайте инсталирания контекст за препращане и съпоставянето на VNI. Съвпадението на VNI от двете страни показва, че равнината на данните е съгласна; то не показва, че контролната равнина е внесла маршрута чрез предвидената политика.
Ако маршрутът се появи на отдалечения PE, но трафик не тече, проблемът е излязъл отвъд EVPN. Проверете връзката VNI към VLAN или VNI към VRF и пътя на underlay, преди отново да редактирате route target. Започнете от съпоставянето, после underlay и само след това контролната равнина. Връщането на промяна по route-target, за да гоните проблем в равнината на данните, е надежден начин да счупите работещ внос.
Префиксите от слой 3 са все още EVPN маршрути
IP префикс в таблицата на EVPN не е обикновен IPv4-unicast BGP. маршрутът EVPN IP Prefix е отделен тип маршрут, а обявите на MAC/IP и IP-префикс пътуват в адресното семейство EVPN, което RFC 7432 определя като AFI 25 и SAFI 70.
Това разграничение е важно, когато сравнявате маршрут в таблицата на EVPN с маршрут в unicast таблицата. Те могат да описват една и съща дестинация и пак да бъдат създавани, филтрирани и внасяни от различни политики. Четенето на едното като доказателство за другото е причината правилен fabric да изглежда счупен по време на миграция.
Проверете извеждането на доставчика, преди да сравнявате числа
RFC 9136 разширява EVPN с маршрути IP Prefix и указва дали приложимият RD идва от контекста на MAC-VRF или на IP-VRF. Затова етикет на L2 услуга и етикет на маршрутизирана услуга в един и същ изход трябва да се четат спрямо обектите, на които принадлежат, а не да се свеждат до един RD на наемател.
Автоматичното извеждане на RD и RT зависи от доставчика. Прочетете справочника на внедрения доставчик за използваната формула; автоматично генерирана стойност, видяна на един комутатор, не е универсално кодиране и сравняването на числата на двама доставчици рядко доказва нещо.
Завършете с писмена следа за маршрута, с който започнахте: тип, обект източник, RD, експортиран RT, политика за внос, инсталиран VNI. Шест полета обясняват обявата на всеки, който ще прочете заявката след вас, и нито едно от тях не изисква числата на наемателя да съвпадат.