როუტერის პინგი თუ VLAN ჰოსტი: რომელი PBR პოლიტიკა მოქმედებს?

VLAN 10-მა უნდა გამოიყენოს VPN, ხოლო VLAN 20-მა WAN, ამიტომ პირველი ტესტი არის პინგი როუტერიდან VLAN 10-ის ინტერფეისის მისამართის წყაროდ გამოყენებით. ის წარმატებულია, route-map მრიცხველები იზრდება და ყველა ასკვნის, რომ დიზაინი მუშაობს. არ მუშაობს. ეს პინგი ლოკალურად შეიქმნა, ხოლო ლოკალურად შექმნილი ტრაფიკი პოლიტიკის სხვა მიმაგრების წერტილს აღწევს, ვიდრე VLAN ინტერფეისზე მოსული პაკეტი.

სამი პირობა განსაზღვრავს, რომელ პოლიტიკას ამოწმებთ სინამდვილეში: სად იქმნება პაკეტი, სად შედის ის და რას ემთხვევა.

სად შედის პაკეტი, განსაზღვრავს, რომელი პოლიტიკა მუშაობს

ინტერფეისის route-map, რომელიც ip policy route-map-ით არის მიმაგრებული, ვრცელდება ამ ინტერფეისზე მოსულ პაკეტებზე, როგორც აღწერს IOS XE PBR-ის სახელმძღვანელო. VLAN 10-ის ჰოსტი აგზავნის თავის მოთხოვნას, ჩარჩო მოდის VLAN ქვეინტერფეისზე და როუტერი იქ აფასებს პოლიტიკას. როუტერის საკუთარი პაკეტი ამ ინტერფეისზე არასოდეს მოდის, რადგან ის როუტერში დაიბადა.

VLAN მისამართის წყაროდ არჩევა ცვლის სათაურს. ის არ ცვლის წარმომავლობას.

რატომ არ არის წყაროს მქონე პინგი ჯერ კიდევ ჰოსტი

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

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

როდის არის ლოკალური პოლიტიკა სწორი პასუხი

Cisco ადოკუმენტებს ip local policy route-map-ს იმ ტრაფიკისთვის, რომელსაც თავად როუტერი ქმნის. ეს ცალკე არეალია და სწორი ინსტრუმენტია, როცა მოთხოვნა ნამდვილად როუტერის საკუთარ ტრაფიკს ეხება. ეს არ არის გამოტოვებული ნაბიჯი, რომელიც ყველა VLAN-ის მართვის დიზაინს სჭირდება. იქ ფართო დამთხვევამ შეიძლება მართვისა და დამხმარე კავშირებზეც იმოქმედოს, რაც გაცილებით დიდი ცვლილებაა, ვიდრე ჩანს.

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

რა უნდა შემოწმდეს სამაგიეროდ ჰოსტზე

გაუშვით ტესტი VLAN 10-ის ავტორიზებული ჰოსტიდან მისი ნამდვილი წყაროს მისამართით, დანიშნულებით, პროტოკოლითა და პორტით. ჩაწერეთ შესვლის ინტერფეისი და route-map-ის დამთხვევა შედეგის გვერდით, რათა მტკიცებულებამ დაასახელოს შესრულებული პოლიტიკა. შემდეგ გაიმეორეთ VLAN 20-ის ჰოსტისთვის და დაადასტურეთ, რომ ის სხვა გზას ირჩევს.

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

რა შეუძლია შედეგს დაამტკიცოს და რა არა

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

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