EIGRP მეზობელი თუ DMVPN ტრანზიტი? ჯერ როლი შეამოწმეთ

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

ნაბიჯი 1: დახაზეთ ორი როლი

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

ტრანზიტული როუტერი გარე პაკეტებს გადასცემს თავისი ჩვეულებრივი IP მარშრუტიზაციითა და პოლიტიკით. მას არ სჭირდება დაცული გვირაბის შიგნით გადატანილი პროტოკოლის გაშვება და ამ პაკეტების შემდგომ გადასაცემად EIGRP პროცესიც არ სჭირდება.

ნაბიჯი 2: შეამოწმეთ, რას ასრულებს შუა მოწყობილობა

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

ამრიგად, პირველი ნამდვილი კითხვა არ არის, რომელი პროტოკოლი დავამორთოთ. კითხვაა, არის თუ არა ყუთი hub, spoke, სუფთა underlay ნახტომი თუ Layer 2 სერვისი, რომელიც კადრებს ატარებს ბოლო წერტილებს შორის.

ნაბიჯი 3: შეამოწმეთ მეზობლის მართვის სიბრტყე

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

RFC 7868 აღწერს EIGRP-ს როგორც IP პროტოკოლს multicast მართვის გაცვლით, ამიტომ მეზობლური ურთიერთობა არ არის ის, რაც შუამავალ როუტერს შეუძლია შეცვალოს პაკეტების დანიშნულებისკენ მარშრუტიზაციით. ან მართვის გაცვლა პარტნიორამდე აღწევს, ან მეზობლობა არ ყალიბდება.

ნაბიჯი 4: შეამოწმეთ, რომ ტრანსპორტი მართვის გაცვლას აწვდის

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

გამჭვირვალე Layer 2 სერვისი, წერტილ-წერტილ გვირაბი და მრავალწერტილოვანი DMVPN ღრუბელი multicast-ს სხვადასხვაგვარად აწვდიან. მიჰყევით რეალურად დანერგილი გადაწყვეტის მხარდაჭერილ ინტერფეისის, NHRP და multicast მოდელს იმის ნაცვლად, რომ ჩათვალოთ სამივე ერთნაირად მოქმედებს.

ნაბიჯი 5: ხელახლა დააპროექტეთ საზღვარი, თუ მონაწილეობას ვერ იღებს

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

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

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