Junos L2VPN: спачатку правільна аформіце дагавор на далучэнне кліента

Перш чым чапаць pseudowire, прасачыце адзін кадр кліента да PE і паглядзіце, дзе ён павінен апынуцца. Фізічны порт класіфікуе яго ў лагічную адзінку, гэтая адзінка нясе інкапсуляцыю, а адзінка прывязаная да сэрвісу. Тры асобныя рашэнні, тры асобныя спосабы памыліцца. Большасць выпадкаў, эскалаваных як збой сігналізацыі, насамрэч ёсць кадрам, аднесеным да адзінкі, якую ніхто не наладзіў для гэтага сэрвісу. Таму пачынайце з далучэння і рухайцеся вонкі.

Запішыце дагавор на кадр

Зафіксуйце дагавор да выбару любой канфігурацыі: без тэга, з адным сэрвісным тэгам або са стэкам. Дадайце MTU, які будзе адпраўляць кліент, і апрацоўку тэгаў, чаканую ў кожным кірунку, бо гэта ўзгодненыя ўласцівасці, а не лакальныя перавагі. Нумар адзінкі — толькі ідэнтыфікатар, і ён нічога не кажа пра тое, якія кадры прыме інтэрфейс.

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

Узгадніце інкапсуляцыю з дагаворам

Сэрвіс з адным тэгам звычайна выкарыстоўвае інкапсуляцыю VLAN-кола, напрыклад vlan-ccc, тады як кадры без тэга патрабуюць простай формы Ethernet-кола, а стэку патрэбны пашыраны варыянт, які разумее два тэгі. На платформе, што падтрымлівае сэрвісную інкапсуляцыю на адзінку, адзін фізічны інтэрфейс можа змясціць некалькі адразу, што зручна і адначасова ёсць спосабам, якім кадр трапляе не ў тую адзінку. Там, дзе дапаможнік для вашай платформы патрабуе family ccc, наладзьце гэта як частку поўнага далучэння, а не прыкручвайце да маршрутызаванага інтэрфейсу. Дапаможнік па інкапсуляцыях пералічвае, якія тыпы далучэння выстаўляюць якія патрабаванні.

Не дадавайце аператар family на кожны інтэрфейс на ўсялякі выпадак. Канфігурацыя, з-за якой працуе адно кола, можа прымусіць наступнае прымаць кадры, якіх яго кліент ніколі не адпраўляе.

Прывяжыце далучэнне да патрэбнага сэрвісу

VPN 2-га ўзроўню з сігналізацыяй BGP, кола з сігналізацыяй LDP і іншыя падтрымліваныя сэрвісы маюць уласную канфігурацыю прывязкі інтэрфейсу і сігналізацыі, і яны не ўзаемазаменныя. Калі змяшаць стыль далучэння аднаго з сігналізацыяй другога, атрымаецца кола, якое паведамляе пра піра і ніколі не пераносіць кадр.

Параўнайце дальні канец з блізкім, а не разглядайце любы з іх ізалявана: адрас піра, ідэнтыфікатар сэрвісу, пагадненне пра інкапсуляцыю, чаканне наконт control word і бюджэт памеру. Ніжэйшы ўзровень MPLS можа быць цалкам здаровы, пакуль далучэнне адсутнічае або класіфікаванае ў іншым месцы, таму тэст, які глядзіць толькі на ніжэйшы ўзровень, тут нічога не даказвае.

Правярайце кадрам, а не статусам

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

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

Потым запішыце гэта

Зафіксуйце чатыры значэнні ў сэрвіснай нататцы: дагавор, інкапсуляцыя, адзінка і прывязка да сэрвісу. Гэтыя чатыры патрэбныя новаму інжынеру, і іх рэдка прамаўляе праверка канфігурацыі.

Калі кола зламаецца праз паўгода, гэтая нататка стане розніцай паміж чвэрцю гадзіны працы і паўторным вывадам усяго праекта з працоўнай канфігурацыі. Дадайце дату апошняй праверкі, каб нататка казала і пра тое, наколькі яна састарэлая.