IPv6 у MPLS VPN: тры выбары, а не адна сям'я адрасоў
Маршруты VPN кліента, сеанс BGP паміж PE і транспарт у ядры — гэта асобныя рашэнні. Сеанс можа ісці ў адной сям'і і несці іншую.
Скажыце «запусціце IPv6 L3VPN праз IPv6 BGP» на аглядзе праекта — і ў гэтым адным сказе схаваныя тры асобныя рашэнні. Якія прэфіксы належаць VPN кліента, якія адрасы нясуць сеанс маршрутызацыі паміж краямі правайдэра і якое ядро перамяшчае пазначаны пакет — гэта незалежныя выбары. Усе яны могуць быць IPv6, могуць быць змяшанымі, і змешванне дазволена наўмысна. Менавіта развязванне гэтых трох і ператварае расплывістае патрабаванне ў тое, што можна праверыць на платформе.
Аддзяліце тры задачы
Першая задача — маршрут кліента: прэфіксы IPv6, якія належаць аднаму кантэксту маршрутызацыі VPN і павінны заставацца па-за любым іншым кантэкстам. Другая — злучэнне маршрутызацыі паміж маршрутызатарамі краю правайдэра, якія абменьваюць гэтыя прэфіксы. Трэцяя — транспарт, які нясе пазначаны пакет кліента праз ядро да далёкага краю. Назваць толькі адну з іх — гэта яшчэ не праект.
| Job | The question it answers | What confusion looks like |
|---|---|---|
| Customer VPN routes | Which IPv6 prefixes belong to each VPN context, and how are they kept apart? | Prefixes leak into the global table and between customers |
| PE-to-PE BGP session | Which addresses carry the routing connection between the two edges? | A session-family mismatch gets chased as a core transport fault |
| Transport to the remote PE | How does the chosen core move the labelled packet to the far edge? | A route is present and unforwardable in the same moment |
Кожная задача мае сваю сям'ю адрасоў, свае рэжымы адмоваў і часта сваю каманду. Табліца карысная менавіта таму, што адзін сказ у дакуменце праекта схільны згортваць усе тры радкі ў адзін.
Сям'я маршруту — VPN-IPv6, а не IPv6 unicast
RFC 4659 вызначае сям'ю BGP/MPLS IPv6 VPN, і членства ў ёй дакладнейшае, чым мяркуе слова IPv6. Маршрут там — гэта дыскрымінатар маршруту, далучаны да прэфікса IPv6 і закадаваны пад AFI 2 і SAFI 128. Звычайны IPv6 unicast — іншая сям'я, таму аб'ява, якая ў looking glass выглядае як прэфікс, можа зусім не быць тым жа аб'ектам. Няправільнае чытанне сям'і — першы шлях, якім гэты праект ідзе не так.
Розніца праяўляецца на краі, дзе маршрут павінен спачатку трапіць у патрэбны кантэкст VPN, перш чым нешта зрабіць. Атрыманне прэфікса даказвае, што абмен адбыўся, і нічога не кажа пра ўсталяванне. Гэтая прага спараджае класічную скаргу, калі сеанс узняты, а кліент усё яшчэ без сувязі.
Сеанс можа ісці ў іншай сям'і, чым VPN
Нішто не прымушае BGP-злучэнне паміж двума краямі выкарыстоўваць уласную сям'ю VPN. Спецыфікацыя дапускае сеанс IPv4 або IPv6, а транспарт IPv6 VPN сам вызначаны па-над абодвума тыпамі ядра. Таму сеанс IPv6 нічога не кажа пра сям'ю таго, што ён нясе, і не выбірае плоскасць даных. Тры незалежныя біты, і праект павінен несці ўсе тры асобна.
Гэта вызваляе і адначасова лёгка чытаецца няправільна. Маршруты кліента IPv6 могуць ісці па сеансе з адрасам IPv4, а маршруты IPv4 — па сеансе IPv6, калі платформа падтрымлівае гэтую камбінацыю і наступны хоп развязваецца. Чаго быць не павінна — гэта каб сеанс падказваў карысную нагрузку, у дакуменце праекта або ў маніторынгу, які пазней даказвае працу сэрвісу.
Наступны хоп у ядры IPv4 мае ўласнае кадаванне
Калі ядро пад VPN — IPv4, маршрут не з'яўляецца з наступным хопам, які ўваходны край можа выкарыстаць напрамую. Ён прыходзіць у форме IPv6, адлюстраванай у IPv4, і менавіта так спецыфікацыя выражае выхадны край, калі транспарт пад ім — IPv4. Тады ўваходны маршрутызатар мусіць ператварыць гэты адлюстраваны адрас у тое, да чаго ён сапраўды можа дабрацца праз ядро, і развязанне — гэта крок, які ціха правальваецца.
Чытайце гэта як залежнасць перасылкі, а не як радок для капіравання паміж прыладамі. Пацвердзіце тры рэчы на платформе, якую вы сапраўды запускаеце: абвешчаны наступны хоп развязваецца ў прыдатны шлях, стос метак прымаецца, і пункт прызначэння трапляе ў патрэбны кантэкст VPN. Любы з гэтых збояў пакідае сеанс, які выглядае здаровым і нічога не перасылае, таму праверка належыць да прыёмачнага прагону, а не да позняга інцыдэнту.
Запішыце патрабаванне ў чатыры радкі
Патрабаванне, якое варта праверыць, называе чатыры рэчы: сям'ю VPN, транспарт сеансу, кадаванне наступнага хопа і ўладкаванне ядра. Затым яно называе адзін прэфікс кліента, які трэба прасачыць ад пачатку да канца: праз абмен, усталяванне, развязанне метак і зваротны шлях. «Падтрымлівае IPv6 BGP» не пакрывае ні аднаго з чатырох і хавае, дзе насамрэч сядзіць неадпаведнасць.
Здаровы сеанс без абмену VPN-IPv6 — няпоўны, і атрыманы маршрут VPN без працуючай перасылкі таксама няпоўны. Калі трымаць гэта асобнымі радкамі прыёмкі, наступная размова пра пошук няспраўнасці будзе кароткай, бо радок, што падае, ужо запісаны.