BGP სესია აქტიურია, კლიენტის გზა გატეხილია: MPLS DMVPN-ზე

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

ეს ნაპრალი ყველაზე ადვილად MPLS-over-DMVPN არქიტექტურაში ჩანს, სადაც ჰაბის გზა და პირდაპირი spoke გზა შეიძლება სხვაგვარად იქცეოდეს იმ მიზეზების გამო, რომლებსაც პირინგთან კავშირი არ აქვს.

რას ამტკიცებს სესია რეალურად

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

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

ოთხი მექანიზმი და არა ერთი

Cisco-ს დოკუმენტაცია MPLS-ისა DMVPN-ზე ნაწილებს მკაფიოდ ჰყოფს. MP-BGP კლიენტის გადასაფარავი ფენის ლეიბლებს პროვაიდერის კიდის მოწყობილობებს შორის ავრცელებს. MPLS ამ ლეიბლებს იყენებს პაკეტის გადაცემის კონტექსტის ასარჩევად. NHRP გადასაფარავი ფენის მისამართს უკავშირებს იმ სატრანსპორტო ბოლოს, რომელიც დინამიკურ გვირაბს სჭირდება. IPsec კი პირის გზას იცავს იქ, სადაც გამოიყენება.

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

შეადარეთ ჰაბის გზა მოკლე გზას, თითო ცვლადი ერთდროულად

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

შედარების დროს ნაკადი უცვლელად შეინარჩუნეთ. დაკვირვებებს შორის წყაროს ჰოსტის, VRF-ის ან დანიშნულების შეცვლა ორ ურთიერთდაუკავშირებელ ისტორიას ქმნის, და ეს არის ამ სავარჯიშოს ჩავარდნის ყველაზე გავრცელებული გზა.

loopback ტესტები ცალკე განყოფილებაში შეინახეთ

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

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

ვერსიისა და ხარვეზის მტკიცებებს საკუთარი მტკიცებულება სჭირდება

ველის ანგარიშები ზოგჯერ გვირჩევენ ჰოსტის ნიღბის ან BGP წყაროს მისამართის შეცვლას, და ასეთი ანგარიშები ღირს წაიკითხოთ მხოლოდ იმ ხარვეზთან ერთად, რომლის შესახებ დაიწერა, და იმ გამოშვებებთან, რომლებზეც იმოქმედა. ერთი გამოშვების გვერდის ავლა არ არის განცხადება, რომ არქიტექტურა ყოველ /32 პრეფიქსს არ უჭერს მხარს.

გამოიყენეთ დოკუმენტაცია, რომელიც შეესაბამება თქვენს DMVPN ფაზას, პლატფორმას და გამოშვებას, და გახსოვდეთ, რომ ერთი თავი შეიძლება რამდენიმე განლაგებას მოიცავდეს, მათ შორის FlexVPN-ს. ერთი განლაგების მაგალითი ჩუმად არ გადადის მეორეზე. აირჩიეთ სესიის ბოლოები იმ საკონტროლო სიბრტყის არქიტექტურისთვის, რომელიც ნამდვილად გჭირდებათ, შემდეგ ცალ-ცალკე შეამოწმეთ კლიენტის გადაცემის გზა, რადგან ყოველი loopback ნიღბის გადაწერა არ ცვლის იმის გარკვევას, რომელი სამუშაო ჩავარდა.