Два арандатары нумаруюць сваю філію аднолькава — 10.50.0.0/24, — і пасля змены маршрут аднаго з іх знікае з краю правайдэра, а другі працягвае працаваць. Прычына такой заяўкі — звычайна адмова ад размежавальніка маршруту (RD) пад падставай, што «метка ўжо ідэнтыфікуе кліента». Гэта не так. RD і метка адказваюць на два розныя пытанні, і гэты разрыў становіцца бачным толькі тады, калі адрасы перакрываюцца.

Адзін маршрут там, дзе іх павінна быць два

Звычайны IPv4 unicast параўноўвае два шляхі да аднаго прэфікса і ўсталёўвае лепшы. Маршрут 10.50.0.0/24 ад кліента A і маршрут 10.50.0.0/24 ад кліента B — гэта адзін ключ, таму перамагае адзін, а другі застаецца толькі як рэзервовы шлях. Пратакол зрабіў тое, што яму сказалі; плоскасць кіравання папрасілі захаваць два розныя маршруты пад адным ідэнтыфікатарам.

Вынік выглядае як адсутны маршрут, а не як памылка: PE, які прайграў, па-ранейшаму перасылае свайго кліента лакальна, таму ping унутры пляцоўкі паспяховы, а міжпляцовачны тэст правальваецца. Перад тым як чапаць палітыку, палічыце запісы для гэтага прэфікса ў табліцы VPNv4.

RD пераўтварае адзін ключ у два

Васьмібайтавы размежавальнік маршруту дадаецца перад прэфіксам IPv4, і аб’ект, які пераносіць BGP, стае адрасам VPN-IPv4 замест прэфікса IPv4. Два кліенты могуць трымаць адны і тыя ж 32 біты, бо 64 біты спераду розныя. Існуюць тыпы фармату для RD на аснове AS і для RD на аснове адраса, і выбар належыць зыходнаму PE. RD на аснове AS — звычайная справа, калі PE падзяляюць адзін AS; на аснове адраса — калі не падзяляюць.

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

Метка — гэта лакальная інструкцыя перасылкі

Кожнае абвяшчэнне таксама нясе метку MPLS, і яе значэнне абмежавана маршрутызатарам, які яе выдзеліў. Іншы PE можа выдаць той жа нумар для зусім іншага пункту прызначэння. Менавіта таму метка не можа замяніць ідэнтычнасць кліента: нумар правільны толькі побач з наступным пераходам і станам перасылкі, які яго ўсталяваў.

Дэталёвасць выдзялення залежыць ад рэалізацыі і дызайну: адны платформы выдзяляюць адну метку на VRF, іншыя — на прэфікс, і метка можа пазначаць дзеянне перасылкі, а не кліента. Дзве розныя меткі, што вядуць да аднаго пункту прызначэння, не супярэчнасць, і адзін і той жа нумар меткі на двух PE — таксама.

FieldWhere it livesScopeIf you remove it
RDVPNv4 NLRIPer advertised routeOverlapping prefixes collide
Route targetExtended communityImport and export policyRoute lands in the wrong VRF
LabelLabeled NLRI and forwarding statePer allocating routerNo instruction for the data plane
Next hopPath attributePer pathThe label cannot be resolved

Чаму адно не можа замяніць другое

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

Акуратнае супрацьпастаўленне плоскасці кіравання і плоскасці даных — гэта навучальны прыём, а не апісанне кадавання. RFC 8277 змяшчае метку ўнутры пазначанага NLRI, таму само абвяшчэнне нясе прывязку; выкарыстанне яе для перасылкі — наступны, асобны крок.

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

Падобныя артыкулы