OSPF მეზობლები VPN-ზე არ ყალიბდება? შეამოწმეთ ეს თანმიმდევრობით
ხუთი შემოწმება, თითოეულს თავისი სიმპტომი აქვს: ბმულის მოდელი, 89 პროტოკოლის ფილტრაცია, მეზობლის პარამეტრები, მეზობლობის მდგომარეობა და შემდეგ ის, რაც რეალურად რეკლამირდება.
გვირაბი მუშაობს, ინტერფეისები ერთსა და იმავე ქვექსელშია და OSPF მაინც არაფერს აჩვენებს. უმეტეს შემთხვევაში გვირაბი რიგზეა და OSPF-ის ერთი მოთხოვნა არ სრულდება. შეასრულეთ ქვემოთ მოცემული ხუთი შემოწმება თანმიმდევრობით და გაჩერდით პირველზე, რომელიც ვერ გაივლის.
თითოეულ შემოწმებას განსხვავებული სიმპტომი აქვს, ამიტომ თანმიმდევრობა სიაზე მნიშვნელოვანია.
შემოწმება 1: სწორია თუ არა ბმულის მოდელი
წერტილ-წერტილის ინტერფეისი და საერთო მრავალწვდომიანი ქსელი სხვადასხვა OSPF გარემოა. broadcast-LAN კონფიგურაციის გვირაბზე კოპირება აქ ყველაზე გავრცელებული შეცდომაა. დააყენეთ ქსელის ტიპი, რომელსაც VPN-ის იმპლემენტაცია მხარს უჭერს, ჩვეულებრივ წერტილ-წერტილი მარშრუტიზებული გვირაბისთვის. შემდეგ დაადასტურეთ, რომ პლატფორმა თანხმდება, რადგან ზოგიერთი იმპლემენტაცია უგულებელყოფს ან გადაფარავს პარამეტრს.
თუ ბმულის მოდელი არასწორია, სიაში შემდეგი ვერაფერი დაგეხმარებათ.
შემოწმება 2: ნებადართულია თუ არა პაკეტების გავლა
OSPFv2 არის IP პროტოკოლი 89, და არა TCP ან UDP პორტი, ამიტომ პორტებისთვის დაწერილი firewall წესი ჩუმად ყრის მას. Hello ასევე მიდის multicast მისამართებზე, რაც პოლიტიკამ შეიძლება არ დაუშვას. დაუშვით პროტოკოლი 89 გვირაბის ბოლოებს შორის, შემდეგ შეამოწმეთ, სჭირდება თუ არა პლატფორმას მეზობლის მკაფიო განაცხადები.
გვირაბი, რომელიც მხოლოდ ping-ს ატარებს, პოლიტიკის პრობლემაა და არა მარშრუტიზაციის.
შემოწმება 3: ემთხვევა თუ არა მეზობლის პარამეტრები
არეალის ID, hello და dead ინტერვალები, აუთენტიფიკაცია და stub დროშები ყველა უნდა ემთხვეოდეს. შეუსაბამობა ჩვეულებრივ მეზობელს ხილულ მდგომარეობაში ტოვებს ჩუმად ჩავარდნის ნაცვლად, რაც სასარგებლოა. შეადარეთ მოქმედი კონფიგურაცია ორივე ბოლოზე, და არა განზრახული.
MTU-ის შეუსაბამობაა დახვეწილი. ის ბლოკავს მონაცემთა ბაზის გაცვლას ExStart-ზე, ამიტომ მეზობელი ვერასდროს აღწევს Full-ს.
შემოწმება 4: რას ამბობს მდგომარეობა
მდგომარეობა ასახელებს ჩავარდნას. Init ნიშნავს, რომ hello მოდის, მაგრამ ეს მარშრუტიზატორი მათში არ არის ჩამოთვლილი, რაც მიუთითებს ერთმხრივ გზაზე ან multicast პრობლემაზე. Two-Way ნორმალურია broadcast სეგმენტზე არა-DR მეზობელთან და არანორმალური წერტილ-წერტილ ბმულზე. ExStart ან Exchange-ის გაჭედვა ნიშნავს MTU ან მონაცემთა ბაზის აღწერის პრობლემას. Loading ნიშნავს, რომ ბმულის მდგომარეობის მოთხოვნებს პასუხი არ ეძლევა.
წაიკითხეთ მდგომარეობა სანამ რამეს შეცვლით, რადგან ის სიის უმეტეს ნაწილს გამორიცხავს.
show ip ospf neighbor ბეჭდავს მდგომარეობას, მეზობლის მისამართს და dead ტაიმერს. შეადარეთ ეს ტაიმერი ორივე მხარის hello ინტერვალს: dead ინტერვალი hello-ს ოთხჯერ ტოლი ნორმალურია, ყველაფერი სხვა შეუსაბამობაა. მდგომარეობის სვეტი მთელი გვერდის ყველაზე სწრაფი წაკითხვაა.
შემოწმება 5: რა რეკლამირდება რეალურად
Full მეზობლობა მარშრუტი არ არის. შეამოწმეთ რომელი ქსელები იქმნება, რომლები ისწავლება და რომლები დგინდება მარშრუტიზაციის ცხრილში. ქსელის დეკლარაციის არქონა ან გადანაწილების პოლიტიკა, რომელიც გამორიცხავს საიტის პრეფიქსს, იძლევა ჯანსაღ მეზობელს და ცარიელ ცხრილს.
შემდეგ გამოსცადეთ ჰოსტის დონის აპლიკაცია და დაბრუნების გზა, რადგან მარშრუტიზაციის პროტოკოლი firewall-ს არ ხსნის.
IPv6-ისთვის OSPFv3-ს საკუთარი მოთხოვნები აქვს და ეს არ არის მისამართების ოჯახის გადამრთველი ყოველ OSPFv2 პარამეტრზე. გამოიყენეთ შესაბამისი პროტოკოლი და პლატფორმის დოკუმენტაცია. და თუ კავშირი ერთი ფიქსირებული ბმულია, შეადარეთ სტატიკური მარშრუტები სანამ დაამატებთ მართვის სიბრტყეს, რომლის ოპერირებაც მოგიწევთ.