MPLS L3VPN ლაბორატორია ping-ს არ პასუხობს? შეამოწმეთ ეს ხუთი ნახტომი

ორი კლიენტის როუტერი, წყვილი provider edge მოწყობილობა და ping, რომელიც შეცდომის შეტყობინების გარეშე იღუპება. პატარა MPLS L3VPN ლაბორატორიაში ხარვეზი თითქმის ყოველთვის ხუთი საკონტროლო წერტილიდან ერთ-ერთზე ზის და თითოეულ მათგანს აქვს ბრძანება, რომელიც აჩვენებს ან რომ დამოკიდებულება მუშაობს, ან რომ ის აკლია. შეცდომაა BGP-ის ხელახლა გაშვება ყოველ ჯერზე, როცა ping ვერ გადის, დამოკიდებულებების თანმიმდევრობით შემოწმების ნაცვლად. თუ პირდაპირ VRF კონფიგურაციაზე გადახტებით, შეიძლება საათი დახარჯოთ პრობლემაზე, რომელიც ორი მოწყობილობით იქით გადაუწყვეტელი შემდეგი ნახტომით დაიწყო.

დაამუშავეთ სია ქვემოდან ზევით. საკონტროლო წერტილი, რომელიც გადის, გავლილად რჩება და პირველი მარცხი არის ის, რაც ღირს გამართვად.

პირველი საკონტროლო წერტილი: PE-ები ერთმანეთს აღწევენ

თითოეულ PE-ს სჭირდება მარშრუტი მეორე PE-ის loopback-ამდე და ეს მარშრუტი რაღაც რეალურის მეშვეობით უნდა გადაწყდეს. Interior gateway protocol არის ჩვეულებრივი გზა იქამდე, მაგრამ სტატიკური მარშრუტიც მუშაობს, სანამ რეკურსიული ძებნა ცოცხალ adjacency-ზე დაჯდება. IOS სტილის მოწყობილობებზე show ip route 10.0.0.2 და შემდეგ show ip cef 10.0.0.2 აჩვენებენ, არსებობს თუ არა პრეფიქსი და არის თუ არა მის უკან გადაწყვეტილი adjacency. ცხრილში არსებული მარშრუტი, რომლის უკან adjacency არ არის, ხელმისაწვდომობა არ არის.

შეამოწმეთ ორივე მიმართულება. ასიმეტრიული IGP ხარჯები, არასწორ მხარეს არსებული passive interface ან loopback-ის ფილტრირებადი distribute list თითოეული მხოლოდ ერთ მიმართულებას ამტვრევს და ერთი მიმართულება საკმარისია სესიის მოსაკლავად. თუ 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-ში. თუ თქვენი ლაბორატორია LDP-ის ნაცვლად იყენებს RSVP-TE-ს ან BGP-ის მიმდებარე იარლიყებს, შეამოწმეთ იმ მექანიზმის საკუთარი მდგომარეობა; ვივარაუდოთ, რომ LDP ყოველ ქვედა დონის იარლიყს ანაწილებს, ფანტომური შეცდომის დევნის ჩვეულებრივი გზაა. გატეხილი იარლიყის გზა მოგვიანებით ჩვეულებრივ ჩნდება როგორც VPN მარშრუტი, რომელიც არსებობს, მაგრამ გამოუსადეგარია.

მესამე საკონტროლო წერტილი: VPN მარშრუტი ხელუხლებელი მოვიდა

შეხედეთ ზუსტი კლიენტის პრეფიქსის VPNv4 ან VPNv6 მარშრუტს და არა სესიის შეჯამებას. show bgp vpnv4 unicast all 10.10.1.0/24 უნდა აჩვენებდეს route distinguisher-ს, შორეული PE-ის loopback-ზე დაყენებულ next hop-ს და იარლიყს. თუ პრეფიქსი აკლია, პირველი ეჭვმიტანილია საწყის PE-ზე ექსპორტის პოლიტიკა ან მიმღებ PE-ზე იმპორტის პოლიტიკა, ხოლო route target-ები ჩვეულებრივი დამნაშავეა.

route target-ის შემოწმება წაიკითხეთ BGP-ის მიღებისგან ცალკე. მარშრუტი შეიძლება მოვიდეს სწორი next hop-ით და მაინც არ დაჯდეს VRF-ში, რადგან importtarget არ ემთხვევა. მიმღებ PE-ზე show ip route vrf CUSTOMER 10.10.1.0 არის ის ტესტი, რომელსაც მნიშვნელობა აქვს; BGP ცხრილი მხოლოდ იმას ამტკიცებს, რომ მარშრუტმა საკონტროლო სიბრტყე გადაკვეთა.

მეოთხე საკონტროლო წერტილი: interface VRF-შია

route distinguisher-ისა და route target-ების მქონე VRF განსაზღვრება არცერთ interface-ს არ გადააქვს მასში. CE-ის მხარეს მდებარე interface-ს სჭირდება VRF მინიჭება და show ip vrf interfaces ან show ip interface brief უნდა ჩამოთვალოს ის სწორი ინსტანციის ქვეშ. ეს არის ის საკონტროლო წერტილი, სადაც კოპირებული კონფიგურაცია ყველაზე ხშირად ცდება, რადგან VRF ბლოკი სრულად გამოიყურება, სანამ interface ჯერ კიდევ გლობალურ ცხრილში ზის.

შემდეგ დაადასტურეთ, რომ PE-მ ისწავლა ადგილობრივი კლიენტის პრეფიქსი ამ VRF-ში და რომ CE-ს აქვს უკან დაბრუნების მარშრუტი კავშირის გავლით. CE-ზე PE-ზე მიმართული სტატიკური default საკმარისია ლაბორატორიისთვის, იმ პირობით, რომ PE-ის VRF-ში მარშრუტია CE-ის LAN-ამდე. თუ ორი ნახევრიდან რომელიმე აკლია, ping მარცხდება მანამ, სანამ რაიმე იარლიყი დაიდება.

მეხუთე საკონტროლო წერტილი: პასუხი სახლისკენ გზას პოულობს

თვალი ადევნეთ წინ მიმავალ პაკეტს და შემდეგ დაბრუნებულ პაკეტს, რადგან ისინი სხვადასხვა ცხრილს იყენებენ. შემავალ PE-ზე კლიენტის წყარო VRF-ის შიგნით შორეულ პრეფიქსამდე უნდა გადაწყდეს შორეული იარლიყით. გამავალ PE-ზე დანიშნულება იმავე VRF-ის შიგნით CE-ის მხარეს მდებარე interface-ამდე უნდა გადაწყდეს. თვით PE-დან გაგზავნილი ping მტკიცებულება არ არის: ის შეიძლება გლობალური ცხრილის ან სხვა წყაროს მისამართის გავლით გავიდეს, ამიტომ ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 არის ის ტესტი, რომელიც უნდა გაუშვათ.

ჰოსტების firewall-ები, reverse-path filtering და CE-ის access სიები კვლავ მოქმედებს. თუ წინ მიმავალი გზა მუშაობს და პასუხი იღუპება, პრობლემა დაბრუნების მხარის მარშრუტში ან ფილტრშია და არა MPLS ტრანსპორტში.

თითოეული საკონტროლო წერტილისთვის შეინახეთ ერთი ხაზი, რომელიც ასახელებს პირველ ჩავარდნილ დამოკიდებულებას. ეს ხაზი კლიენტის ping-ის ვერ გაკეთების ჩივილს აქცევს კონკრეტულ კითხვად ხელმისაწვდომობის, იარლიყების მდგომარეობის, მარშრუტის იმპორტის, interface-ის წევრობის ან დაბრუნების გზის შესახებ და ხელს უშლის შემდეგ გამართვის სესიას გაიმეოროს იგივე ხუთი ბრძანება იმავე თანმიმდევრობით.