L3VPN-ის გადაცემა: კერძო მარშრუტები, ნაგულისხმევი მარშრუტი თუ სრული ცხრილი?

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

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

დაიწყეთ ტრაფიკით, რომელიც არავის დაუგეგმავს

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

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

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

ჩაწერეთ კერძო პრეფიქსები მათი მარცხის შემთხვევასთან ერთად

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

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

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

შეამოწმეთ, რა დააყენა CE-მ სინამდვილეში

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

show ip bgp vpnv4 vrf BRANCH neighbors 192.0.2.1 received-routes
show ip bgp vpnv4 vrf BRANCH
show ip route vrf BRANCH 0.0.0.0

სამივე გაუშვით გადაცემის დღეს და არა თვის შემდეგ, სანამ ვინმეს ჯერ კიდევ ახსოვს შეთანხმებული. პირველი გამოტანა დამოკიდებულია soft-reconfiguration inbound ან შენახულ route refresh-ზე; არცერთის გარეშე CE ვერ გაჩვენებთ, რა უარყო. მეორე აჩვენებს მიღებულ და საუკეთესო მარშრუტებს პოლიტიკის შემდეგ. მესამე გეუბნებათ, სად მიდის ნაგულისხმევი სინამდვილეში და ეს არის ყველაზე სასარგებლო ხაზი მთელ გადაცემაში.

იგივე შემოწმებები გაუშვით მეორე CE-ზე, თუ საიტი ორმაგად არის მიერთებული. ორ კიდეს შორის ასიმეტრიული მიღება ხშირი მიზეზია იმისა, რომ „ერთი სერვერიდან მუშაობს, მეორიდან არა" და ის უხილავია კონფიგურაციის diff-ში, რომელიც სიმეტრიულად გამოიყურება.

უფრო დიდი ნაკადის შეფასება და არა მისი ვარაუდი

ზოგჯერ კლიენტს ნამდვილად სჭირდება ინტერნეტის მარშრუტების ინფორმაცია VRF-ის შიგნით, policy routing-ისთვის ან ცენტრალური გასასვლელისთვის, რომელიც პრეფიქსით მართავს. ეს არის მოთხოვნა, რომელიც უნდა ჩამოყალიბდეს, შემოიფარგლოს და ფასდებოდეს და არა ფარული ნაგულისხმევი. მას თან ახლავს მეხსიერება RIB-ისა და FIB-ისთვის, CPU განახლებებისთვის, ფილტრების მოვლა და მიღებული ცხრილის მფლობელი.

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

BGP/MPLS IP VPN-ის სპეციფიკაცია განიხილავს ინტერნეტწვდომის რამდენიმე მოწყობას თავად VPN სერვისის გვერდით და არ აცხადებს სრულ ცხრილს ან ნაგულისხმევს სავალდებულოდ ყოველი კლიენტისთვის, და სწორედ ის განყოფილება ღირს მითითებად, როცა „სტანდარტული პრაქტიკის" შესახებ მტკიცება ჩნდება: RFC 4364.

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