OSPF თუ EIGRP ASA VTI-ზე: რომელს უჭერს მხარს თქვენი გამოშვება
OSPFv2 და EIGRP ASA VTI-ზე მხოლოდ 9.19(1)-დან გადიან და მხოლოდ multicast-ის ჩართვით. შეადარეთ ორივე თქვენს გამოშვებაზე, შემდეგ შეამოწმეთ მეზობლები.
OSPF-ისა და EIGRP-ის შესახებ კამათების უმეტესობა ვარაუდობს, რომ გვირაბს პროტოკოლი უკვე შეუძლია, და ASA-ზე სწორედ ეს ვარაუდია ის ნაწილი, რომელიც პირველად უნდა შემოწმდეს. შედარება საინტერესო მხოლოდ მას შემდეგ ხდება, რაც დადასტურდება იმიჯი, VTI-ის ტიპი და multicast-ის გზა. ამ რიგის შეცდომა ნიშნავს, რომ ნახევარ დღეს გაატარებთ ტაიმერების რეგულირებაში გვირაბზე, რომელიც არასდროს შექმნის მეზობლობას. მე თითოეულ ასეთ პროექტს ვიწყებ გამოშვების შენიშვნებითა და მოქმედი კონფიგურაციით, და არა პროტოკოლის უპირატესობით.
გამოშვება წყვეტს პროტოკოლამდე
Cisco-ს VTI სახელმძღვანელო ASA 9.24-ისთვის გამოსადეგი დოკუმენტური საფუძველია: აღწერს სტატიკურ და დინამიკურ VTI-ებს და ჩამოთვლის სტატიკურ მარშრუტიზაციას, BGP-ს, OSPF-სა და EIGRP-ს. მისი ფუნქციების ისტორია OSPFv2-ისა და EIGRP-ის მხარდაჭერას VTI-ზე 9.19(1)-ს მიაკუთვნებს. ამაზე ძველი ყველაფერი სხვა საუბარია.
ასე რომ, პირველი ორი კითხვა მოსაწყენი და გადამწყვეტია:
| Check | What decides it |
|---|---|
| Image and release | Whether the feature history lists OSPFv2 or EIGRP on VTI for the version you run |
| VTI type | Static or dynamic, and which routing context the platform permits |
| Multicast on the tunnel | Whether it is enabled, and whether the group limits are respected |
მტკიცება, რომ ASA-ს არ შეუძლია VTI-ის გამოყენება ან IGP-ის ტარება, მართალი იყო ზოგიერთი ძველი იმიჯისთვის და არ არის მიმდინარე მხარდაჭერის მატრიცა. ანალოგიურად, 9.24-ის სახელმძღვანელო არ არის ბრძანება ყველა მოწყობილობის განახლებისა. ის ამბობს, რას უჭერს მხარს ის გამოშვება, და თქვენმა განლაგებულმა გამოშვებამ თავისთავად უნდა უპასუხოს.
unicast-ის გავლა არ ნიშნავს, რომ IGP ჩამოყალიბდება
იგივე სახელმძღვანელო აღნიშნავს, რომ unicast ნაგულისხმევად გადის და multicast უნდა ჩაირთოს OSPFv2-ის ან EIGRP-ისთვის VTI-ზე, multicast ჯგუფების დოკუმენტირებული შეზღუდვებით. სწორედ ეს ერთი წინადადება ხსნის ამ პროექტში ჩემს მიერ ნანახ წარუმატებელ მეზობლობათა უმეტესობას. გვირაბში მომუშავე ping ან მწვანე IPsec სტატუსი მხოლოდ unicast გზას ამტკიცებს. პროტოკოლის აღმოჩენას multicast გზა სჭირდება, და ორივე ცალ-ცალკე კონფიგურირდება.
hello ან hold ტაიმერებზე შეხებამდე შეამოწმეთ გვირაბის ინტერფეისის კონფიგურაციაში ის multicast პარამეტრი. თუ პარამეტრი არ არის, მეზობლობა არ არის ნელი, ის შეუძლებელია.
OSPF და EIGRP გვერდიგვერდ ერთსა და იმავე გვირაბზე
თავად გვირაბზე ორი პროტოკოლი ისე გამოიყურება, როგორც სხვაგან. OSPF-ს სჭირდება შესაბამისი ქსელის ტიპი, არე, ავთენტიფიკაცია და მეზობლის პარამეტრები; EIGRP-ს სჭირდება თავისი AS ნომერი და მასთან დაკავშირებული ინტერფეისის დონის პარამეტრები.
ხაფანგია მეზობლის განაცხადების კოპირება სხვა გვირაბის მოდელიდან. რჩევა სტატიკური მეზობლების შესახებ VTI-ს გარეშე პროექტში არსებობდა multicast-ის თავიდან ასაცილებლად და არ გადადის VTI-ზე, რომლისგანაც მოსალოდნელია პროტოკოლის ბუნებრივად ტარება. დააკონფიგურირეთ მხარდაჭერილი ინტერფეისის ქცევა, შემდეგ მიეცით პროტოკოლს საკუთარი მეზობლობის ჩამოყალიბების საშუალება.
შემდეგ შეადარეთ იმ ღერძებზე, რომლებიც თქვენს ტოპოლოგიაში ნამდვილად განსხვავდება: სხვა მხარესთან თავსებადობა, შესამოწმებელი კონვერგენციის ქცევა და თქვენი გუნდის ოპერაციული ცოდნა. ისტორიული ისტორია იმის შესახებ, რომ ერთი პროტოკოლი უფრო სწრაფი ან მსუბუქია, თქვენი ქსელის გაზომვა არ არის.
მეზობლები არ უდრის დაყენებულ მარშრუტებს
მეზობლობის აწევის შემდეგ გამოყავით ის, რაც წარმოიქმნება, იმისგან, რაც მიიღება. შეხედეთ, რომელ ფილიალის პრეფიქსებს აცხადებს ყოველი მხარე, რომლებიც მიიღება, რომლებიც ირჩევა და რომლებიც რეალურად აღწევს მარშრუტიზაციის ცხრილს. იმპორტის, ექსპორტისა და გადანაწილების ფარგლები განზრახ უნდა იყოს და არა ყველაფრის საერთო გამოცხადება, რაც მოწყობილობამ იცის.
show ospf neighbor და show eigrp neighbors გეუბნებიან, რომ სესია ცოცხალია. show route გეუბნებათ, მოვიდა თუ არა ფილიალის პრეფიქსი, და ეს სხვადასხვა კითხვაა.
აპლიკაციის გზა კვლავ მესამე კითხვაა. მეზობლური ურთიერთობა ავრცელებს ხელმისაწვდომობას; ის არ იძლევა ნებართვას firewall-ის გავლით და არ ამტკიცებს, რომ ტრაფიკის სელექტორები და ფილტრაციის წესები თანხმდება. გადაამოწმეთ დაშვებული ნაკადი და მისი პასუხის გზა დამტკიცებული ტესტით, იმის ნაცვლად, რომ ჩათვალოთ მარშრუტი პოლიტიკის გარანტიად.
რა უნდა ჩაიწეროს დასრულებულ შედარებაში
ჩაწერეთ გვირაბის ინტერფეისი, მისი მხარდამჭერი გამოშვება, თქვენ მიერ შემოწმებული კონტროლის გაცვლა და თქვენ მიერ შემოსაზღვრული მარშრუტის პოლიტიკა. დაამატეთ multicast პარამეტრი, რადგან სწორედ ეს დეტალი წყვეტს ჩუმად, მუშაობს თუ არა დანარჩენი. შეინახეთ ეს ჩანაწერი განლაგებული გამოშვების გვერდით, რათა მოგვიანებით ფუნქციის ცვლილება გადაიხედოს იმ ვარაუდიდან დაწყების გარეშე, რომელიც უკვე გაუქმდა.
თუ ამ ოთხიდან რომელიმე აკლია, თქვენ გაქვთ უპირატესობა და არა პროექტი. ჯერ გაასწორეთ დაკარგული ფაქტი; პროტოკოლის არჩევა ადვილი ნაწილია.