Нармалізацыя тэгаў VLAN на канцавых пунктах pseudowire: runbook

Вызначыце, які кадр павінен атрымліваць кожны кліенцкі край, перш чым кранаць 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 і вынік тэсту ў адным месцы, бо яны маюць сэнс толькі разам. Размеркаванне іх па трох заяўках гарантуе, што наступны інжынер зноў выявіць тое ж абмежаванне.

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