Перадача L3VPN: прыватныя маршруты, маршрут па змаўчанні ці поўная табліца?

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

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

Пачніце з трафіку, які ніхто не планаваў

Задайце адно пытанне перад тым, як з’явіцца любы спіс прэфіксаў: калі пакет не супадае ні з адным прыватным маршрутам, куды ён павінен ісці? Філіял з уласнай інтэрнэт-лініяй звычайна трымае лакальны маршрут па змаўчанні, таму звычайны вэб-трафік выходзіць праз лакальны фаервол і ніколі не кранае правайдэра. У такім дызайне VPN нясе толькі аддаленыя прыватныя пляцоўкі, а выбар робяць больш канкрэтныя прэфіксы.

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

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

Запішыце прыватныя прэфіксы разам з выпадкам збою

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

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

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

Праверце, што CE сапраўды ўсталяваў

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

show ip bgp vpnv4 vrf BRANCH neighbors 192.0.2.1 received-routes
show ip bgp vpnv4 vrf BRANCH
show ip route vrf BRANCH 0.0.0.0

Запусціце ўсе тры ў дзень перадачы, а не праз месяц, пакуль нехта яшчэ памятае, пра што дамовіліся. Першы вывад залежыць ад soft-reconfiguration inbound або ад захаванага абнаўлення маршрутаў; без аніводнага з іх CE не можа паказаць вам, што ён адхіліў. Другі паказвае прынятыя і найлепшыя шляхі пасля палітыкі. Трэці гаворыць, куды насамрэч ідзе маршрут па змаўчанні, і гэта самы карысны радок ва ўсёй перадачы.

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

Абгрунтуйце большую стужку, а не меркуйце яе

Часам кліенту сапраўды патрэбна інфармацыя пра інтэрнэт-шляхі ўнутры VRF — для маршрутызацыі па палітыцы або для цэнтральнага выхаду, які кіруе па прэфіксах. Гэта патрабаванне, якое трэба заявіць, акрэсліць і ацаніць, а не схаваны маршрут па змаўчанні. Разам з ім прыходзяць памяць для RIB і FIB, працэсар для абнаўленняў, абслугоўванне фільтраў і ўласнік для выніковай табліцы.

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

Спецыфікацыя BGP/MPLS IP VPN разглядае некалькі схемаў доступу ў інтэрнэт побач з самой паслугай VPN і не абвяшчае поўную табліцу або маршрут па змаўчанні абавязковымі для кожнага кліента; менавіта гэты раздзел варта паказваць, калі з’яўляецца сцвярджэнне пра "стандартную практыку": RFC 4364.

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