EIGRP-ის მეზობლები DMVPN-ის გადაფარვაზე არ ადიან

unicast გადაფარვაზე მუშაობს და მეზობლობა მაინც იშლება, ამიტომ შეამოწმეთ NHRP-ის multicast რეპლიკაცია, გვირაბის EIGRP პოლიტიკა და IPsec სამ ცალკე ფენად.

გვირაბი აწეულია, ერთი spoke მეორეს ping-ს უკეთებს, და EIGRP მაინც არ აჩვენებს არცერთ მეზობელს hub-ზე. ეს კომბინაცია ნორმალურია და არა იდუმალი: ping ადასტურებს unicast ხელმისაწვდომობას NHRP-ის გავლით, ხოლო EIGRP-ის hello-ები multicast-ია. DMVPN-ის გადაფარვაზე მარშრუტიზაციის პროტოკოლის მიწოდების მოდელი მეორე კონფიგურაციის ზედაპირია და სწორედ მას გამოტოვებენ ხალხი, რადგან პირველი ზედაპირი უკვე ჯანსაღად გამოიყურება. ქვემოთ ყოველი ფენა საკუთარი ბრძანებით მოწმდება, ამიტომ ერთ ფენაში ჩავარდნა სიის თავში არ დაგაბრუნებთ.

ჩამოწერეთ ის მეზობლობები, რომლებსაც ელოდებით

ნებისმიერი show ბრძანების წინ შეადგინეთ მოკლე სია: რომელი spoke რომელ hub-თან უნდა იყოს peer, რომელი გვირაბის ინტერფეისით და რომელ EIGRP ავტონომიურ სისტემაში. მრავალhubიანი დიზაინები hub-ებს შორის არსებულ ხარვეზებში იშლება, და სია «EIGRP გატეხილია» ფრაზას «spoke 3 hub 2-ზე არ რეგისტრირდება»-დ აქცევს. ჩართეთ ის გვირაბის ქვექსელები, რომლებსაც ყოველ რგოლზე ელოდებით, რადგან ორ ბოლოს შორის მისამართების შეუთანხმებლობა ზუსტად პროტოკოლის ჩავარდნას ჰგავს. ჩაწერეთ სია ბილეთში, რომ შემდეგმა ცვლამ დიზაინს შეადაროს და არა ბოლო ეკრანის სურათს.

შეამოწმეთ NHRP, შემდეგ multicast გზა

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

show dmvpn
show ip nhrp
show ip nhrp nhs detail
interface Tunnel0
 ip nhrp network-id 1
 ip nhrp nhs 203.0.113.1 nbma 198.51.100.1
 ip nhrp map multicast 198.51.100.1
 tunnel mode gre multipoint
 tunnel key 100

სწორედ ip nhrp map multicast სტრიქონი აძლევს spoke-ს საშუალებას, თავისი hello-ები hub-ს გაუგზავნოს როგორც რეპლიცირებული multicast გადაფარვის გავლით, და აძლევს hub-ის multicast-ს საშუალებას მიაღწიოს რეგისტრირებულ spoke-ებს. მის გარეშე unicast NHRP-ის გავლით მუშაობს, multicast კი არა, და სწორედ ეს გაყოფა ხდის ping-ს მტკიცებულების მსგავსს. Cisco-ის სახელმძღვანელო IOS XE DMVPN აღწერს hub-ისა და spoke-ების multicast ქცევას ყოველი ფაზისთვის, ამიტომ მოარგეთ თქვენი კონფიგურაცია იმ ფაზას, რომელიც ნამდვილად განათავსეთ და ნუ დააკოპირებთ ფრაგმენტს სხვა ტოპოლოგიიდან.

შეამოწმეთ თავად EIGRP-ის ინტერფეისის პოლიტიკა

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

show ip eigrp interfaces detail Tunnel0
show ip eigrp neighbors detail
show run | section router eigrp
router eigrp 100
 network 10.10.0.0 0.0.0.255
 passive-interface default
 no passive-interface Tunnel0

ავთენტიფიკაცია და მეტრიკის წონები ორივე ბოლოზე უნდა ემთხვეოდეს. არასწორი რეჟიმის გასაღების ჯაჭვი ან K მნიშვნელობის შეუთანხმებლობა hello-ებს აგდებს მიმღებთან აშკარა syslog სტრიქონის გარეშე. თუ დიზაინი იყენებს ცხადად კონფიგურირებულ unicast მეზობლებს, სრულად მიჰყევით ამ მოდელს და ნუ დააფენთ მას multicast პარამეტრებს, სანამ რამე არ ამოვა.

GRE-ის ტარება და IPsec-ის დაცვა ცალ-ცალკე გეჭიროთ

DMVPN multicast-ს GRE-ის შიგნით ატარებს, ხოლო IPsec იცავს GRE პაკეტებს და არა შიდა multicast-ს უშუალოდ. ამიტომ გავრცელებული მტკიცება, რომ IPsec-ს multicast-ის ტარება არ შეუძლია, ამ დიზაინისთვის მცდარია და დიაგნოზის სახით უსარგებლო. შეამოწმეთ გვირაბზე IPsec პროფილი, თითოეული peer-ის უსაფრთხოების ასოციაციები და გვირაბის ინტერფეისის მდგომარეობა სამ ცალკე ფაქტად.

show crypto ipsec sa peer 198.51.100.1
show interfaces Tunnel0 | include line protocol
show ip nhrp multicast

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

შეამოწმეთ მარშრუტები და არა მხოლოდ მეზობლების რაოდენობა

როგორც კი მეზობლობა ჩამოყალიბდება, წაიკითხეთ, რას აცხადებს და აყენებს ის. მრავალწერტილოვან გვირაბზე split horizon და next-hop-ის ქცევა წყვეტს, შეუძლია თუ არა spoke-ს hub-ის გავლით სხვა spoke-მდე მისვლა, და შეჯამებამ შეიძლება დამალოს prefix მაშინაც, როცა მეზობლური ურთიერთობა სრულყოფილია.

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

ჩაწერეთ ფაზური დიზაინი, multicast ასახვა და EIGRP პოლიტიკა ერთ ადგილას. შემდეგ ინჟინერს დიზაინი დასჭირდება და არა ჩანაწერი.

დაკავშირებული სტატიები