Нормализиране на VLAN тагове в крайните точки на pseudowire: runbook
Определете какъв кадър трябва да получава всеки клиентски ръб, след което локално реализирайте pop, push или swap. Включете MPLS стека и control word в бюджета за MTU.
Определете какъв кадър трябва да получава всеки клиентски ръб, преди да пипате pseudowire. В простия случай CE A изпраща един таг, който разграничава услугата, а CE B очаква кадри без таг, и именно на доставчиковия ръб тази разлика се решава. Тагът е локална политика, а не част от Ethernet договора на клиента, и pseudowire пренася договорения кадър, а не оригиналния. Запишете двете посоки преди каквато и да е конфигурация.
Първо запишете договора за кадър
Посоката напред премахва таг, а обратната го добавя отново. Ако запишете само една от тях, ще тествате работещ път в една посока и ще обявите веригата за изправна.
Дръжте договора достатъчно кратък, за да го поставите в заявката за промяна: кой ръб изпраща с таг, кой очаква без таг и коя стойност на тага разграничава услугата.
Съгласувайте режима на pseudowire
RFC 4448 различава режимите pseudowire raw и tagged и описва как се обработват таговете, които разграничават услугата. Режимът raw все още може да носи тагове, принадлежащи на клиентския кадър, затова разликата се отнася до служебната роля на тага, а не до самото присъствие на заглавка 802.1Q. Четенето на режима като tagged срещу untagged е най-разпространеният начин тази работа да се обхване погрешно. Съгласувайте режима с партньора, преди да решите кои операции ви трябват.
След това проверете действителния тип pseudowire и параметрите на партньора. Локално VLAN свързване и отдалечено портово свързване изискват поддържана схема за interworking, а две локални инструкции за пренаписване не доказват, че обявените типове вериги съвпадат.
Ако очакванията за control word и MTU се различават, имате проблем със съгласуването, който никакво пренаписване не решава. Потвърдете и двете от работещата конфигурация на партньора, а не от проектния документ.
Приложете локалните операции с тагове
ръководството на Juniper за пренаписване на VLAN CCC документира операции pop, push и swap със специфични за платформата ограничения. За вече конфигуриран съвместим елемент с таг илюстративната посока е input-vlan-map pop на входа и output-vlan-map push на изхода. Тези редове илюстрират операции, а не пълна конфигурация на интерфейс или верига. Потвърдете точната платформа и версия, вместо да прилагате примера на едно семейство устройства навсякъде.
Поддържаните от елемента настройки за VLAN и инкапсулация все още трябва да определят желания таг и класификация. Инструкция за пренаписване върху елемент, който класифицира грешните кадри, премества проблема, вместо да го решава.
Запазете всички вътрешни клиентски тагове, които услугата изисква. При стекови тагове определете кой външен таг променяте, преди да премахнете нещо.
Планирайте размера, не само таговете
Включете в бюджета за размер запазените тагове, действителния MPLS стек и control word. RFC 8469 препоръчва control word за Ethernet pseudowire и тази препоръка променя бюджета на кадъра независимо дали вашата платформа го включва по подразбиране. Съгласувайте несъответствие в MTU, вместо да потискате предупреждението му като ремонт. Потиснато предупреждение е планирана авария с изтрита дата.
Проверете същия бюджет на двата доставчикови ръба, защото едната страна да добави таг, а другата control word е достатъчно, за да се счупи полезен товар, който преди е бил наред.
Ако числата не съвпадат, променете плана, а не нивото на журналиране.
Приемайте го кадър по кадър
За приемането прегледайте очаквания кадър на всяко клиентско свързване в двете посоки. След това упражнете приложния и управляващия трафик, който услугата наистина изисква, по одобрения тестов план, защото ping доказва много по-малко от кадър с таг, който пристига непокътнат. Запишете договора за кадър за вход и изход заедно с конфигурацията на веригата. Именно този запис прави следващата промяна проследима.
Дръжте режима, операциите с тагове, бюджета за MTU и резултата от теста на едно място, тъй като имат смисъл само заедно. Разделянето им в три заявки гарантира, че следващият инженер отново ще открие същото ограничение.
Веригата е готова, когато двете посоки отговарят на договора, написан в началото, а не когато мине първата посока.