Чаму MAC-адрас QFX паказваецца ў EVPN, але не ў табліцы перасылкі

Знаходжанне MAC у базе EVPN даказвае, што ён быў абвешчаны або атрыманы як маршрут, і нічога больш. Табліца перасылкі — гэта іншая структура, якая праграмуецца пазней, таму адзін і той жа MAC можа быць у адной і адсутнічаць у другой, хоць кожны пратакол працуе правільна. Калі лічыць гэтыя два вынікі копіямі адзін аднаго, інжынеры шукаюць збой BGP, тады як рэальны разрыў — гэта палітыка імпарту або нявырашаны наступны хоп. Вартае пытанне не ў тым, ці ведае фабрык пра MAC, а ў тым, на якім этапе ён перастаў перадавацца.

Дзве табліцы, якія адказваюць на розныя пытанні

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

Табліца камутацыі — гэта і ёсць стан перасылкі. Абодва вынікі пералічваюць MAC побач з кантэкстам VLAN або VNI, і менавіта таму іх параўноўваюць радок за радком, і менавіта таму параўнанне ўводзіць у зман. Запіс у базе кажа, што маршрут існуе і быў прыняты ў экзэмпляр; ён нічога не кажа пра тое, ці ўсталявала яго платформа для перасылкі.

Маршрут Type 2 нясе MAC, неабавязковы IP, метку або VNI, дыскрымінатар маршруту і наступны хоп, які называе аддалены VTEP. Паміж кабелем і гэтым маршрутам могуць зламацца чатыры рэчы: хост ніколі не вывучаны, маршрут ніколі не абвешчаны, ён адхілены пры імпарце або яго наступны хоп не вырашаецца. Кожны збой пакідае розны набор запоўненых табліц, і менавіта таму паслядоўнасць можна дыягнаставаць.

Лакальнае вывучэнне па-ранейшаму ідзе першым

Распаўсюджанае дапушчэнне: EVPN бярэ на сябе вывучэнне MAC, таму пустая база азначае праблему оверлея. Лакальнае вывучэнне па-ранейшаму працуе на баку доступу, як і да з'яўлення VXLAN: камутатар вывучае MAC крыніцы дазволенага кадра ў правільным VLAN і сэрвісе і толькі пасля гэтага стварае для яго Type 2. Хост, які не адправіў ніводнага датычнага кадра, не мае чаго абвяшчаць. Хост, кадры якога адкідваюцца членствам у VLAN, фільтрам або непрацуючым членам агрэгата, выглядае аднолькава з пункту гледжання оверлея.

Пачніце з кропкі падключэння і рухайцеся наперад камандамі толькі для чытання. Мэта — даказаць, што кадр ад хоста прайшоў у патрэбным сэрвісе, бо нішто ўнізе не кампенсуе кадр, які так і не прыйшоў.

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 — бяспечны запаўняльнік.

Затым хай адказы паказваюць на этап, які зламаўся. Адсутнасць вывучэння на падключэнні азначае бок доступу; маршрут без запісу ў базе — імпарт; запіс у базе без стану перасылкі — праграмаванне. Якім бы ён ні быў, перадайце сабраныя вынікі разам з хостам, інтэрфейсам, сэрвісам і зборкай, каб наступны інжынер мог узнавіць шлях, а не паўтараць запыт.