Ці патрэбны VPNv4 MPLS у ядры? Не абавязкова

BGP VPNv4 дамаўляецца пра кантэкст размеркавання маршрутаў, а не пра шлях перасылкі. Аддзяліце імпарт, развязанне наступнага пераходу і інкапсуляцыю, якую вы можаце выкарыстоўваць.

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

Што насамрэч дамаўляецца сямейства адрасоў

Шматпратакольны BGP пераносіць інфармацыю дасяжнасці сеткавага ўзроўню VPNv4 пад AFI 1 і SAFI 128, і кожны запіс спалучае дыскрымінатар маршруту з прэфіксам і меткай. Сеанс дамаўляецца, што абодва бакі могуць кадаваць і дэкадаваць гэтую інфармацыю. Чаго ён не дамаўляецца, дык гэта плоскасці даных. Усё пасля гэтага абзаца тычыцца перасылкі, і нішто з гэтага не вырашаецца ўзняццем сеансу.

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

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

Атрыманне, імпарт і перасылка — гэта тры крокі

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

Step in the chainWhat has to be trueHow it fails quietly
NLRI exchangeBoth speakers negotiate the VPNv4 capabilitySession stays up while the family is never activated
Import eligibilityA route target on the received route matches the VRF import policyThe route exists in the table but never enters the VRF
Next-hop resolutionThe advertised next hop resolves to a usable tunnel or label pathBest path is selected, then marked unreachable or unusable
EncapsulationThe egress endpoint can decapsulate what the ingress producedPackets arrive and are discarded for a format mismatch

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

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

IP-ядро можа несці стэк, які яно ніколі не перамыкае

Варта захаваць адрозненне паміж «ядро не запускае MPLS» і «нідзе ў сэрвісе няма меткі». Гэта розныя сцверджанні, і толькі першае тычыцца транзітных прылад. RFC 4023 вызначае перанос MPLS праз тунелі IP або GRE, і менавіта гэты механізм робіць другое сцверджанне магчымым на цалкам IP-ядры.

customer packet + service label
  encapsulated in GRE, addressed to the egress tunnel endpoint
  forwarded by ordinary IP routers on the outer header
  decapsulated at the endpoint, label still meaningful

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

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

Прайдзіце ланцуг на скрыні, пакуль ён не парвецца

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

show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_A

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

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

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

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