Junos L2VPN: първо подредете правилно договора за прикачване на клиента

Преди да пипнете pseudowire, проследете един клиентски кадър до PE и вижте къде трябва да кацне. Физическият порт го класифицира в логическа единица, тази единица носи инкапсулация, а единицата е свързана с услуга. Три отделни решения, три отделни начина да сгрешите. Повечето случаи, ескалирани като неизправност в сигнализацията, всъщност са кадър, класифициран в единица, която никой не е конфигурирал за тази услуга. Затова започнете от прикачването и работете навън.

Запишете договора за кадъра

Запишете договора, преди да изберете каквато и да е конфигурация: без етикет, един служебен етикет или стек. Добавете MTU, което клиентът ще изпраща, и обработката на етикетите, очаквана във всяка посока, защото това са договорени свойства, а не локални предпочитания. Номерът на единицата е само идентификатор и не казва нищо за това кои кадри ще приеме интерфейсът.

Напишете го в служебната бележка, а не в коментар към тикета. Човекът, който ще дебъгва това след шест месеца, ще прочете бележката. Тикета няма да прочете.

Съгласувайте инкапсулацията с договора

Услуга с един етикет обикновено използва инкапсулация на VLAN верига като vlan-ccc, докато кадрите без етикет се нуждаят от простата форма на Ethernet верига, а стекът — от разширения вариант, който разбира два етикета. На платформа, която поддържа служебна инкапсулация за единица, един физически интерфейс може да хоства няколко наведнъж, което е удобно и същевременно е начинът, по който кадър попада в грешната единица. Там, където ръководството за вашата платформа изисква family ccc, конфигурирайте го като част от цялостното прикачване, вместо да го прикрепяте към маршрутизиран интерфейс. Ръководството за инкапсулации изброява кои типове прикачване налагат какви изисквания.

Не добавяйте family инструкция към всеки интерфейс за всеки случай. Конфигурацията, която кара една верига да работи, може да накара следващата да приема кадри, които нейният клиент никога не изпраща.

Свържете прикачването с правилната услуга

BGP-сигнализирана VPN от слой 2, LDP-сигнализирана верига и останалите поддържани услуги имат всяка своя конфигурация за свързване на интерфейс и сигнализация и не са взаимозаменяеми. Смесването на стила на прикачване на едната със сигнализацията на другата дава верига, която отчита peer и никога не пренася кадър.

Сравнете далечния край с близкия край, вместо да преглеждате който и да е от тях изолирано: адрес на peer, идентификатор на услуга, споразумение за инкапсулация, очакване за control word и бюджет за размер. MPLS основата може да е напълно здрава, докато прикачването липсва или е класифицирано другаде; затова тест, който гледа само основата, тук не доказва нищо.

Проверявайте с кадъра, не със статуса

Прочетете локалните броячи на интерфейса, докато клиентът изпраща трафик, после състоянието на услугата и след това потвърдете, че пристигащият кадър е договореният кадър, включително неговия етикет. Поправено прикачване доставя този кадър; самата промяна на статуса не доказва нищо.

Където имате право да снимате, погледнете кадъра в двете посоки. Асиметрията на етикетите лесно се пропуска в изглед на статус и е очевидна в запис. Тази асиметрия обяснява и оплакванията, които работят в едната посока и се провалят в другата.

След това го запишете

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

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