VPNv4 паміж AS: што патрабуе кантракт перасылкі метак

Чытанне меткі VPNv4 на памежным маршрутызатары AS мала што дае, пакуль вы не даведаецеся, якую мадэль прамежкавых зносін паміж AS рэалізуе перадача. Метка не з'яўляецца ўласцівасцю маршруту сама па сабе; яна фіксуе пагадненне пра інкапсуляцыю і дастаўку паміж двума маршрутызатарамі. Вызначце мадэль, перш чым чытаць экран. Інакш вы адладжваеце кантракт, якога ніхто не запісаў.

Якую мадэль рэалізуе мяжа

Схема VRF-да-VRF злучае адпаведныя VRF праз маршрутызаваныя далучэнні. Кожны бок бачыць другі як суседзе кліенцкага краю, і яны абменьваюцца звычайнымі маршрутамі IPv4, таму на гэтай мяжы нічога не патрабуе MPLS.

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

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

Прачытайце адзін прэфікс ад пачатку да канца

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

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

Метка лакальная, і абяцанне таксама

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

RFC 4364 абмяжоўвае пазначаны VPNv4-пірынг даверанымі схемамі і папярэджвае супраць прыёму метак, якія ніколі не абвяшчаліся гэтаму піру. Гэта заява пра бяспеку не менш, чым пра пратакол. Трымайце публічныя інтэрнэт-адносіны маршрутызацыі далей ад прыватнага абмену маршрутамі VPN. Калі злучэнне — звычайны IP, не чакайце, што любая метка яго перажыве. А калі канал пазначаны, пацвердзьце, што знешняя транспартная метка правільна замяняецца на кожным хопе.

Метка, якая выглядае правільнай з аднаго боку і знікае з іншага, звычайна і ёсць гэтая неадпаведнасць, а не памылка маршрутызацыі.

Што запісаць пры прыёмцы

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

Менавіта гэтая нататка дазваляе наступнаму аператару правільна чытаць тое ж адлюстраванне метак. Без яе мадэль выводзіцца з канфігурацыі, а выведзеныя дапушчэнні — гэта шлях да паўтору той жа памылкі. Раздзел RFC 4364 пра прамежкавыя AS — месца, дзе варта вызначыць, якая мадэль мелася на ўвазе.