MPLS филиал маршруттамасы: CE нені және кімнен үйренеді

Бір филиалдағы хост басқа филиалдағы серверге қосылым ашады, ал екі алаң да бір басқарылатын MPLS 3-қабат VPN-нің артында тұр. Хост тек өзінің әдепкі шлюзін біледі және басқа ештеңе білмейді, бұл дұрыс. Маңыздысы — жергілікті клиент шеті пакетті өз провайдер шетіне тапсырады, ал провайдердің VPN маршруттау күйі оны мақсатты префикске ие филиалға жеткізеді.

Бір пакетті жол бойымен қадағалау — қай бөлігі клиенттің жауапкершілігі, қай бөлігі қызметке жататынын көрудің ең жылдам жолы.

10.20.0.0/24 → CE-A → PE → provider core → PE → CE-B → 10.30.0.0/24

Әр хоптың жұмысы қайда аяқталады

CE-A-ға алыс LAN-ға арналған маршрут керек, ол өзінің жергілікті провайдер қосылымына сілтеуі керек, алыс филиалдың WAN мекенжайына емес. Содан кейін провайдер пакетті VPN маршруттау күйін пайдаланып өз ядросы арқылы тасымалдайды, ал CE-B оны мақсатты LAN-ға жеткізеді. Ешбір сәтте хостқа белгілерді, VRF-терді немесе қарсы жақтың интернет арнасын түсіну қажет емес.

Тикеттерде қайта-қайта кездесетін қате — A филиалында B филиалының WAN мекенжайын келесі хоп ретінде конфигурациялау. Екі филиал да бір қызметті сатып алған, сондықтан олар көрші болуы керек сияқты көрінеді. Бірақ олай емес: келесі хоп шын мәнінде бар маршруттау дизайны арқылы қолжетімді болуы керек, ал алыс CE әдетте сіз басқармайтын жабдықтың артында көптеген хоп қашықтықта болады. Осы болжамға құрылған статикалық маршрут белсенді болып көрінеді және ешнәрсеге шешілмейді, бұл жоқ маршруттан да жаман, өйткені кестеде ол дұрыс көрінеді.

RFC 4364 клиент пен провайдер шеттері арасындағы алмасуды провайдердің VPN маршруттарын таратуынан бөледі, және бұл дәл осы нұсқаулық айналысатын шекара. Клиенттің міндеті — өз шетіне нені жеткізе алатынын айту және қызмет ұсынатын қолжетімділікті қабылдау.

Өткізу немен келісуі керек

Механизмді провайдермен бірге таңдаңыз, оның айналасында емес. Статикалық маршруттар, BGP немесе CE мен PE арасындағы маршруттау протоколы туралы келісім — барлығы заңды, және OSPF-тің мұндай өткізу үшін анықталған MPLS VPN моделі бар. Олардың ешқайсысы екі алыс клиент шетінің арасында анықталмаған провайдер ядросы арқылы OSPF көршілестігін құруға себеп емес, өйткені бұл провайдер келіспеген және қолдай алмайтын дизайн.

Жаңа LAN іске қосылмас бұрын төрт нәрсені жазып алыңыз: префикс, CE-дегі жергілікті келесі маршрут, провайдер қабылдайтын хабарландыру және провайдер қайтаратын маршруттар. Келісімшарт талап ететін кез келген сүзгілеуді, префикс шегін немесе алаңдар арасындағы шектеуді қосыңыз. Салауатты көршілестік — ақпарат алмасудың арнасы, және ол белгілі бір префикстің қабылданғанына дәлел емес; сессия қосулы тұрғанда жаңа қосалқы желіңіз сүзгіде отыруы мүмкін.

Содан кейін жауапты қадағалаңыз. B филиалына бастапқы LAN-ға қайтатын маршрут керек, ал қабылдаушы жақтағы хостқа өз шлюзі мен өз қызмет рұқсаттары керек. CE-A-да пайда болған маршрут айналымның тең жартысын ғана орнатады, ал жарты айналым — ping сынағының бір бағыты сау көрініп, қолданба әлі де сәтсіздікке ұшырауының себебі.

Тапсыру алдында екі өткізуді де тексеріңіз

Екі клиент шетінде маршруттау күйін жинаңыз, провайдермен көзделген LAN префикстерінің VPN-ге қабылданғанын растаңыз, содан кейін әр бағытта бір рұқсат етілген қолданбаны сынап көріңіз. Тек маршрут кестелері қолданбаның жұмыс істейтінін дәлелдемейді, ал тек қолданба сынағы жұмыс істемегенде қай басқару жазықтығы сәтсіздікке ұшырағанын айтпайды.

show ip route vrf BRANCH 10.30.0.0
show ip bgp vpnv4 vrf BRANCH
show ip cef vrf BRANCH 10.30.0.10

Үш шығысты бірге оқыңыз. Біріншісі шеттің неге сенетінін, екіншісі нені және қай әріптестен үйренгенін, үшіншісі шын мәнінде нені жіберетінін айтады. Олардың арасындағы сәйкессіздік әдетте жоқ хабарландыру емес, саясат немесе рекурсия мәселесі, және провайдерден тергеу сұрамас бұрын оны шешу керек. Осы үш шығысты оператормен сөйлесуге алып барыңыз, өйткені олар қолдау инженері әйтпесе қоятын сұрақтардың көбіне жауап береді.

Қызмет нені бермейтінін біліңіз

Бұл — 3-қабаттың маршрутталған қатынасы. Бұл кеңселер арасында хабар тарататын 2-қабаттың арнасы емес, сондықтан анықтау протоколдары, хабарға тәуелді қолданбалар және ортақ сегмент туралы болжамдар онымен бірге жүрмейді. Басып шығару, атауларды шолу және жергілікті сегментке тәуелді кез келген нәрсе өз дизайнын қажет етеді.

VPN-ді бөлу де шифрлау емес. Белгілерді ауыстыру тұтынушыларды провайдер желісінің ішінде бөлек ұстайды, және келісімшарт құпиялылықты талап етсе, ол жүктемені құпия етпейді. Бұл маңызды жерде оны қолданба немесе қабаттасқан қабат қамтамасыз етуі керек.

Соңында, қызмет моделін алаңның маршруттау конфигурациясының жанында жазып ұстаңыз. Келесі қосалқы желіні қосатын инженер қай префикстердің хабарланатынын, оларды кім қабылдайтынын және күтілетін қайтару жолы қандай екенін оқи алуы керек: BGP/MPLS IP VPN спецификациясы осының бәрінің артындағы модель үшін анықтама болып табылады.