Чому MAC QFX видно в EVPN, але не в таблиці пересилання

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

Дві таблиці, що відповідають на різні питання

У Junos EVPN база даних перелічує MAC-адреси за екземплярами разом із тим, як кожна з'явилася: вивчена з порту доступу, отримана в маршруті Type 2 або позначена як частина групи multihoming. Довідник Juniper show evpn database охоплює фільтри за MAC і за екземпляром, які роблять подання читабельним. Це зведення площини керування з ключем за екземпляром і MAC, а не таблиця, якою обладнання комутує кадри.

Таблиця комутації — це і є стан пересилання. Обидва виводи перелічують MAC поруч із контекстом VLAN або VNI, і саме тому їх порівнюють рядок за рядком, і саме тому порівняння вводить в оману. Запис у базі каже, що маршрут існує і його прийнято в екземпляр; він нічого не каже про те, чи встановила його платформа для пересилання.

Маршрут Type 2 несе MAC, необов'язкову IP, мітку або VNI, розрізнювач маршруту й наступний стрибок, що називає віддалений VTEP. Між кабелем і цим маршрутом можуть зламатися чотири речі: хост так і не вивчено, маршрут так і не анонсовано, його відхилено під час імпорту або його наступний стрибок не розв'язується. Кожна невдача залишає заповненим інший набір таблиць, і саме тому цю послідовність узагалі можна діагностувати.

Локальне навчання все ще відбувається першим

Звичайне припущення — EVPN перебирає навчання MAC, тому порожня база має означати проблему overlay. Локальне навчання все ще працює на боці доступу, точно як до появи VXLAN: комутатор вивчає MAC джерела дозволеного кадру в правильному VLAN і сервісі й лише потім створює для нього Type 2. Хосту, який не надіслав жодного доречного кадру, нічого анонсувати. Хост, кадри якого відкидаються через членство у VLAN, фільтр або непрацюючого члена агрегату, виглядає однаково з погляду overlay.

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

show interfaces ge-0/0/1.0
show ethernet-switching interface ge-0/0/1.0
show lacp interfaces ae0

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

Де губиться віддалений MAC

Віддалений MAC зазнає невдачі в протилежному напрямку, і тихо. Маршрут Type 2 надходить, але потрапляє в екземпляр лише тоді, коли його ціль маршруту й VNI збігаються з локальною конфігурацією, і стає придатним лише тоді, коли наступний стрибок розв'язується в доступний VTEP. Незбіг цілі маршруту залишає в таблиці BGP дійсний маршрут, якого жоден екземпляр не запитує.

Прочитайте три подання по порядку: наявність маршруту, запис у базі, запис пересилання. Наведені нижче команди запитують той самий MAC на кожному етапі, а прикладний адрес зберігає виводи порівнюваними.

show evpn database instance blue mac-address 02:00:00:00:00:5c extensive
show route table bgp.evpn.0 | match 02:00:00:00:00:5c
show route table bgp.evpn.0 | match 02:00:00:00:00:5c extensive

Ці виводи відповідають на три окремі питання. Маршрут у bgp.evpn.0 без запису в базі вказує на політику імпорту, ціль маршруту або конфігурацію екземпляра. Запис у базі без запису пересилання вказує на програмування платформи, що належить до іншого шляху ескалації. Активний маршрут, наступний стрибок якого не розв'язується, — це проблема транспорту або мітки, і жодна кількість налагодження MAC її не виправить.

Перезавантаження, яке це виправило, доводить дуже мало

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

Перед будь-яким вікном обслуговування зафіксуйте, що перезавантаження зітре. Цих трьох команд достатньо для порівняння до і після, і вони нічого не змінюють на пристрої.

show evpn database instance blue
show route table bgp.evpn.0
show version

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

Чотири спостереження, які вирішують більшість випадків

Чотири спостереження охоплюють майже кожен випадок: точка підключення та її сервіс, MAC як прикладне значення, стан маршруту й бази, а також використовувана версія. Виберіть MAC, який явно є прикладом, щоб ніхто не сприйняв його за виробничу адресу: перший октет 02 позначає локально керовану unicast-адресу, решта октетів вільні, і тому 02:00:00:00:00:5c — безпечний заповнювач.

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