CE RIP მარშრუტიდან დისტანციურ VRF-მდე: სად ხდება ექსპორტი

RIPv2 განახლება აღწევს პროვაიდერის კიდეს, ხვდება VRF მარშრუტიზაციის ცხრილში და იქ ჩერდება, თუ რაღაც მას ცხადად არ აექსპორტებს. სამი გადაწყვეტილება თანმიმდევრულად ხდება და თითოეულს შეუძლია პრეფიქსი საკუთარი მიზეზით უარყოს. მათი ერთ მოვლენად წაკითხვა არის მიზეზი იმისა, რომ ადამიანები არასწორ მოწყობილობას ეძებენ, როცა დისტანციური ადგილი ვერ აღწევს ქსელს, რომელსაც CE ნათლად აცხადებს. მიჰყევით მარშრუტს PE-ს გავლით და თანმიმდევრობა ცხადი გახდება.

რას აკეთებს PE RIP განახლებასთან

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

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

ექსპორტი პოლიტიკის აქტია და არა პროტოკოლის შედეგი

VRF-დან გასასვლელად მარშრუტი უნდა გადანაწილდეს VPN მარშრუტების გადამტან MP-BGP პროცესში და მას სჭირდება მარშრუტის მიზნის გაფართოებული თემი, რომელიც განსაზღვრავს, რომელ დისტანციურ VRF-ებს შეუძლიათ მისი იმპორტი. RFC 4364-ის არქიტექტურა სწორედ ამ მიზეზით ინახავს ამ გაცვლებს CE-დან-PE პროტოკოლისგან ცალკე. კიდეზე RIP-ის გამოყენება არაფერს ამბობს იმაზე, რა უნდა გადაკვეთოს პროვაიდერის ქსელმა.

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

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

გადანაწილება და ცხადი წარმოშობა განსხვავებულად იქცევა

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

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

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

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

შეამოწმეთ ჯაჭვი ოთხ ადგილას

შეხედეთ CE-ის განაცხადს, VRF მარშრუტიზაციის ცხრილს, VPN მარშრუტების ცხრილს მისი მარშრუტის მიზნით და დისტანციურ VRF-ში იმპორტს, ამ თანმიმდევრობით. IOS-ზე ეს ნიშნავს CE მეზობლის გამომავალს, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, და იგივე ბრძანებას შორეულ PE-ზე. IOS-XR-ზე ეკვივალენტური გამომავალი ამის ქვეშაა: show bgp vrf CUSTOMER ipv4 unicast. ბრძანებების სახელები განსხვავდება, ოთხი საკონტროლო წერტილი არა.

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

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