AFI і SAFI: прочитайте пару раніше за назву служби

Можна бачити, як сесія піднімається, як з'являється маршрут, і все одно читати не ту службу. Пара чисел на початку кожного оголошення, ідентифікатор родини адрес та ідентифікатор наступної родини адрес вирішує, який розбірник читає корисне навантаження і яка таблиця зберігає результат. Помилитеся в парі — політика імпорту, зіставлення цілі маршруту й пошук наступного переходу виконуються проти структури, якої ніхто не оголошував. Шлях нижче починається з цієї пари й завершується результатом пересилання.

До якої таблиці належить маршрут, вирішують два числа

Пара з'являється двічі: усередині багатопротокольної можливості, де промовець оголошує родину, і перед кожним NLRI, яке ця родина несе. Тому це властивість маршруту, а не налаштування на вихідному вузлі. Постачальники друкують її як назву на кшталт Address family VPNv4 Unicast, і формулювання кочує між випусками, поки числа залишаються на місці.

Чотири кодування покривають майже всі корпоративні випадки: 1 з 128 для VPN-IPv4 з міткою MPLS, 2 з 128 для відповідника IPv6, 25 з 65 для VPLS із сигналізацією BGP і 25 з 70 для EVPN. Перша помилка — вважати, що кожна служба Layer 2 стоїть за 25 з 65, що приховує EVPN. Друга — розглядати дві родини IP як одну родину з довшою адресою, хоча вони узгоджуються окремо й можуть прийматися на різних партнерах. Третя з'являється, коли шаблон копіюють із випуску, який знає лише одну з них. Довідка в реєстрі вирішує всі три швидше за здогад, побудований на назві служби.

Вважайте чотири рядки прикладами з реєстру IANA, а не самим реєстром. Коли число не збігається ні з чим відомим, подивіться на нього, перш ніж будувати навколо нього політику.

AFI 25 несе два не пов'язані формати NLRI

Обидві родини Layer 2 сидять під AFI 25, і схожість на цьому закінчується. NLRI для VPLS у RFC 4761 section 3.2.2 несе довжину, розрізнювач маршруту, VE ID, зсув блоку VE, розмір блоку VE і базу міток, які разом називають кінцеву точку pseudowire та її мітку. EVPN зберігає AFI 25 і переходить на SAFI 70, де корисне навантаження — тип маршруту: автоматичне виявлення Ethernet, оголошення MAC/IP, включний multicast, сегмент Ethernet, префікс IP. Тому той самий зсув у байтах означає в двох родинах різне. Розбірник, написаний для однієї, читає іншу без скарг і видає безглуздя. Пара — єдине попередження, що тлумачення хибне.

Поле, яке в одній родині означає зсув блоку VE, не має відповідника в іншій, а маршрут оголошення MAC/IP існує лише в EVPN. Цитувати атрибут так, ніби він стосується обох, — це шлях, яким огляд запису йде не туди.

Коли хтось дає вам запис або таблицю постачальника, запитайте, до якої родини належить атрибут. Потім переконайтеся, що приймальна реалізація підтримує цю родину, а не назву служби з опису. Дві платформи можуть обидві заявляти підтримку VPLS, реалізуючи різні родини сигналізації. Пара їх розділяє; ярлик продукту — ні.

Власна родина адрес сесії — окреме питання

VPN-IPv6 регулярно оголошується через сесію, TCP-з'єднання якої йде поверх IPv4, і це підтримуваний проєкт, а не несправність. Тому читання лише зведення сесії нічого не говорить про те, які родини VPN обмінюють партнери.

Родина NLRI, транспортна родина й родина пересилання — три незалежні рішення. Маршрутизатор може говорити IPv4 зі своїм партнером, приймати доступність VPN-IPv6 і встановлювати маршрут, наступний перехід якого — адреса IPv6, доступна шляхом, якого ви не передбачали. Кожному рівню потрібне своє підтвердження. Майданчики, що повідомляють про недосяжні цілі IPv6, тоді як оголошення виглядають правильно, зазвичай втратили розв'язання наступного переходу, а не узгодження родин.

Перевірте родину адрес сесії окремо, потім родини, які вона несе, потім те, що ядро може переслати. Розділення трьох запобігає частому хибному діагнозу, коли правильне оголошення читають як доказ, що IPv6 працює від краю до краю. Воно доводить лише те, що один партнер розповів іншому про префікс.

Узгоджено, отримано, імпортовано, встановлено

Для одного очікуваного маршруту чотири стани мають виконуватися за порядком, і кожен спостережуваний. Родина має бути узгоджена з цим партнером, маршрут має надійти, ціль маршруту має імпортувати його в потрібний контекст, а наступний перехід має розв'язатися, щоб маршрут встановився. Пропуск першого стану робить інші три без відповіді, бо неузгоджена родина не породжує маршрутів для огляду. На платформах у стилі Cisco зведення родин і можливості за партнерами — окремі команди.

show bgp all summary
show bgp vpnv4 unicast all summary
show bgp l2vpn evpn summary
show bgp neighbors <peer-address> | include Address family

Узгодження видно в обміні можливостями, який друкується за партнерами, а встановлена сесія без жодної зазначеної родини не несе нічого з запитаного. Імпорт вирішують цілі маршрутів, що переносяться як розширені спільноти, тож правильна пара з неправильно набраною ціллю залишає таблицю порожньою. Встановлення потім залежить від розв'язання наступного переходу в приймальному контексті, що може не вдатися, поки кожне оголошення виглядає бездоганно.

Підтвердьте площину даних останньою, бо маршрут у таблиці — твердження, а не доставка. Ті самі чотири стани стосуються кожної родини; змінюються лише команди й назви таблиць.

Чого пара родин не доводить ніколи

Правильне читання пари каже, як тлумачити наступну маршрутну інформацію, і це все твердження. Воно нічого не каже про досяжність, політику чи здоров'я площини даних. Змішування двох породжує впевнені заяви про мережу, яку ніхто не перевіряв. Незбіг цілі маршруту й зламаний наступний перехід виглядають однаково, якщо дивитися лише на пару. Пара — інструкція з читання, ніколи не вирок.

Коли ескалюєте, покладіть пару, ціль маршруту й розв'язаний наступний перехід в одну нотатку. Тоді наступний інженер має три незалежні речі для перевірки замість назви служби, яку треба перетлумачувати. Якщо узгодження немає, вони бачать це одразу, хибна ціль залишає імпорт помітно відсутнім, а нерозв'язаний наступний перехід залишає маршрут присутнім, але непридатним.