Лабараторыя MPLS L3VPN не адказва на ping? Праверце гэтыя пяць скокаў

Два кліенцкія рутары, пара прылад provider edge і ping, які памірае без паведамлення пра памылку. У невялікай лабараторыі MPLS L3VPN няспраўнасць амаль заўсёды сядзіць у адной з пяці кантрольных кропак, і кожная з іх мае каманду, якая паказвае альбо што залежнасць працуе, альбо што яна адсутнічае. Памылка — перазапускаць BGP кожны раз, калі ping не праходзіць, замест таго каб правяраць залежнасці па парадку. Калі вы адразу скокнеце ў канфігурацыю VRF, вы можаце выдаткаваць гадзіну на праблему, якая пачалася з нявырашанага наступнага скока праз два прылады далей.

Апрацоўвайце спіс знізу ўверх. Кантрольная кропка, якая праходзіць, застаецца пройдзенай, і першы збой — той, які варта адладжваць.

Першая кантрольная кропка: PE дасягаюць адзін аднаго

Кожнаму PE патрэбен маршрут да loopback іншага PE, і гэты маршрут павінен вырашацца праз нешта рэальнае. Interior gateway protocol — звычайны шлях туды, але і статычны маршрут працуе, пакуль рэкурсіўны пошук не спыніцца на жывым adjacency. На прыладах у стылі IOS show ip route 10.0.0.2 і затым show ip cef 10.0.0.2 паказваюць, ці існуе прэфікс і ці ёсць за ім вырашаны adjacency. Маршрут у табліцы без adjacency за ім — не дасягальнасць.

Праверце абодва кірункі. Асіметрычныя выдаткаванні IGP, passive interface на няправільным баку або distribute list, які фільтруе loopback, ламаюць кожны толькі адзін кірунак, а аднаго кірунку дастаткова, каб забіць сесію. Калі loopback-і адказваюць на ping, але сесія BGP стаіць у Active, паглядзіце на update source, перш чым чапаць што-небудзь іншае.

Другая кантрольная кропка: існуе шлях метак

IP маршрут да аддаленага loopback не даказвае, што транспарт паставіць метку. У праекце LDP пацвердзіце, што аддалены loopback мае лакальнае і аддаленае звязванне і што зыходная метка з'яўляецца ў forwarding табліцы. show mpls ldp bindings 10.0.0.2 32 паказвае пары метак, а show mpls forwarding-table 10.0.0.2 паказвае, што line card фактычна паставіць. Калі другая каманда не паказвае ніякай меткі або вяртаецца на IP, транспарт не нясе VPN трафік так, як мяркуе праект.

Розніца выходзіць з таго, як MPLS аддзяляе forwarding state ад прэфіксаў прызначэння, мадэль, апісаная ў RFC 3031. Калі ваша лабараторыя выкарыстоўвае RSVP-TE або меткі, суседнія з BGP, замест LDP, праверце ўласны стан гэтага механізму; меркаваць, што LDP размяркоўвае кожную метку ніжняга слоя, — часты спосаб ганяцца за фантомнай памылкай. Зламаны шлях метак звычайна пазней паўстае як VPN маршрут, які існуе, але непрыдатны да выкарыстання.

Трэцяя кантрольная кропка: VPN маршрут прыйшоў цэлым

Паглядзіце на VPNv4 або VPNv6 маршрут дакладнага прэфікса кліента, а не на зводку сесіі. show bgp vpnv4 unicast all 10.10.1.0/24 павінен паказаць route distinguisher, next hop, усталяваны на loopback аддаленага PE, і метку. Калі прэфікс адсутнічае, першы падазроны — палітыка экспарту на зыходным PE або палітыка імпарту на прымаючым PE, а route target-ы — звычайны вінаваты.

Чытайце праверку route target асобна ад прыёму BGP. Маршрут можа прыйсці з правільным next hop і ўсё ж не апынуцца ў VRF, бо importtarget не супадае. На прымаючым PE show ip route vrf CUSTOMER 10.10.1.0 — гэта тэст, які мае значэнне; табліца BGP толькі даказвае, што маршрут перасёк кантрольную плоскасць.

Чацвёртая кантрольная кропка: interface знаходзіцца ў VRF

Вызначэнне VRF з route distinguisher і route target-амі не перамяшчае ніводнага interface у яго. Interface да CE патрабуе прызначэння VRF, і show ip vrf interfaces або show ip interface brief павінен пералічыць яго пад правільнай інстанцыяй. Гэта тая кантрольная кропка, дзе скапіяваная канфігурацыя найчасцей памыляецца, бо блок VRF выглядае поўным, пакуль interface яшчэ сядзіць у глабальнай табліцы.

Затым пацвердзіце, што PE вывучыў лакальны прэфікс кліента ў гэты VRF і што CE мае маршрут назад праз падключэнне. Статычны default на CE, які паказвае на PE, дастатковы для лабараторыі, пры ўмове што VRF на PE мае маршрут да LAN кліента. Калі адсутнічае любая з дзвюх палоў, ping падае перш, чым будзе пастаўлена любая метка.

Пятая кантрольная кропка: адказ знаходзіць шлях дадому

Прасочвайце пакет наперад, а затым зваротны пакет, бо яны выкарыстоўваюць розныя табліцы. На ўваходным PE крыніца кліента павінна вырашыцца ўнутры VRF да аддаленага прэфікса з аддаленай меткай. На зыходным PE прызначэнне павінна вырашыцца ўнутры таго ж VRF да interface да CE. Ping, адпраўлены з самога PE, не з'яўляецца доказам: ён можа выйсці праз глабальную табліцу або іншы адрас крыніцы, і таму ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 — гэта тэст, які трэба выканаць.

Сеткавыя экраны на хостах, reverse-path filtering і access спісы на CE па-ранейшаму дзейнічаюць. Калі шлях наперад працуе, а адказ памірае, праблема ў маршруце або фільтры на зваротным баку, а не ў транспарце MPLS.

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