MPLS ფილიალების მარშრუტიზაცია: რას სწავლობს CE და ვისგან
ფილიალის კიდე მარშრუტებს პროვაიდერის კიდესთან ცვლის, არა შორეულ ფილიალთან. თვალი ადევნეთ ერთ პაკეტს და შეამოწმეთ ორივე გადაცემა, სანამ ობიექტს მიიღებთ.
ერთი ფილიალის ჰოსტი კავშირს ხსნის მეორე ფილიალის სერვერთან და ორივე ობიექტი ერთი და იმავე მართული MPLS მე-3 დონის VPN-ის უკანაა. ჰოსტმა იცის მხოლოდ საკუთარი ნაგულისხმევი კარიბჭე და მეტი არაფერი, რაც სწორია. მთავარია, რომ ადგილობრივი მომხმარებლის კიდე პაკეტს გადასცემს თავის პროვაიდერის კიდეს, ხოლო პროვაიდერის VPN მარშრუტიზაციის მდგომარეობა მას დანიშნულების პრეფიქსის მფლობელ ფილიალამდე მიიტანს.
ერთი პაკეტის გატარება მთელ გზაზე ყველაზე სწრაფი გზაა იმის სანახავად, რომელი ნაწილია მომხმარებლის პასუხისმგებლობა და რომელი ეკუთვნის სერვისს.
10.20.0.0/24 → CE-A → PE → provider core → PE → CE-B → 10.30.0.0/24
სად მთავრდება თითოეული ჰოპის სამუშაო
CE-A-ს სჭირდება მარშრუტი შორეულ LAN-ზე, რომელიც მიუთითებს მის ადგილობრივ პროვაიდერთან მიერთებაზე და არა შორეული ფილიალის WAN მისამართზე. შემდეგ პროვაიდერი პაკეტს თავის ბირთვში გადაიტანს VPN მარშრუტიზაციის მდგომარეობის გამოყენებით, ხოლო CE-B მას დანიშნულების LAN-ზე მიიტანს. არც ერთ მომენტში ჰოსტს არ სჭირდება ეტიკეტების, VRF-ების ან მეორე მხარის ინტერნეტ წრედის გაგება.
შეცდომა, რომელიც ბილეთებში არაერთხელ ჩნდება, არის ის, რომ A ფილიალში B ფილიალის WAN მისამართი შემდეგ ჰოპად კონფიგურდება. ორივე ფილიალმა იგივე სერვისი იყიდა, ამიტომ ჩანს, რომ ისინი მეზობლები უნდა იყვნენ. მაგრამ არ არიან: შემდეგი ჰოპი უნდა იყოს ხელმისაწვდომი იმ მარშრუტიზაციის დიზაინით, რომელიც რეალურად გაქვთ, ხოლო შორეული CE ჩვეულებრივ ბევრი ჰოპით არის დაშორებული იმ აღჭურვილობის მიღმა, რომელსაც თქვენ არ მართავთ. ამ დაშვებაზე აგებული სტატიკური მარშრუტი აქტიურად ჩანს და არაფერში იხსნება, რაც უარესია, ვიდრე არმყოფი მარშრუტი, რადგან ცხრილში სწორად გამოიყურება.
RFC 4364 გამოჰყოფს მომხმარებლისა და პროვაიდერის კიდეებს შორის გაცვლას პროვაიდერის მიერ VPN მარშრუტების გავრცელებისგან და ეს არის ზუსტად ის საზღვარი, რომელზეც ეს სახელმძღვანელოა. მომხმარებლის საქმეა თავის კიდეს უთხრას, რისი გადაცემა შეუძლია, და მიიღოს ის ხელმისაწვდომობა, რომელსაც სერვისი სანაცვლოდ სთავაზობს.
რაზე უნდა შეთანხმდეს გადაცემა
მექანიზმი შეარჩიეთ პროვაიდერთან ერთად და არა მის გარშემო. სტატიკური მარშრუტები, BGP ან CE-სა და PE-ს შორის მარშრუტიზაციის პროტოკოლის შეთანხმება ყველა ლეგიტიმურია და OSPF-ს ასეთი გადაცემისთვის განსაზღვრული MPLS VPN მოდელი აქვს. არც ერთი მათგანი არ არის მიზეზი ორ შორეულ მომხმარებლის კიდეს შორის OSPF მეზობლობის ასაგებად გაურკვეველი პროვაიდერის ბირთვის გავლით, რადგან ეს ის დიზაინია, რომელზეც პროვაიდერი არ შეთანხმებულა და ვერ უჭერს მხარს.
სანამ ახალი LAN ამუშავდება, ჩაწერეთ ოთხი რამ: პრეფიქსი, ადგილობრივი შემდეგი მარშრუტი CE-ზე, განცხადება, რომელსაც პროვაიდერი მიიღებს, და მარშრუტები, რომლებსაც პროვაიდერი დააბრუნებს. დაამატეთ ნებისმიერი ფილტრაცია, პრეფიქსის ლიმიტი ან ობიექტებს შორის შეზღუდვა, რომელსაც ხელშეკრულება აწესებს. ჯანსაღი მეზობლობა ინფორმაციის გაცვლის არხია და არ არის მტკიცებულება იმისა, რომ კონკრეტული პრეფიქსი მიღებულ იქნა; სესია შეიძლება აქტიური იყოს, სანამ თქვენი ახალი ქვექსელი ფილტრში ზის.
შემდეგ თვალი ადევნეთ პასუხს. B ფილიალს სჭირდება მარშრუტი უკან წყარო LAN-ზე, ხოლო მიმღებ მხარეს ჰოსტს სჭირდება საკუთარი კარიბჭე და საკუთარი სერვისის ნებართვები. CE-A-ზე გამოჩენილი მარშრუტი მხოლოდ ნახევარ ორმხრივ მგზავრობას ამყარებს და სწორედ ნახევარი მგზავრობაა მიზეზი იმისა, რომ ping ტესტის ერთი მიმართულება ჯანსაღად გამოიყურება, სანამ აპლიკაცია მაინც ვერ მუშაობს.
მიღებამდე შეამოწმეთ ორივე გადაცემა
შეაგროვეთ მარშრუტიზაციის მდგომარეობა ორივე მომხმარებლის კიდეზე, დაუდასტურეთ პროვაიდერს, რომ განზრახული LAN პრეფიქსები VPN-ში მიღებულ იქნა, და შემდეგ გამოსცადეთ ერთი ნებადართული აპლიკაცია თითოეული მიმართულებით. მხოლოდ მარშრუტების ცხრილები არ ამტკიცებს, რომ აპლიკაცია მუშაობს, ხოლო მხოლოდ აპლიკაციის ტესტი არ გეუბნებათ, რომელი მართვის სიბრტყე ჩავარდა, როცა ის არ მუშაობს.
show ip route vrf BRANCH 10.30.0.0
show ip bgp vpnv4 vrf BRANCH
show ip cef vrf BRANCH 10.30.0.10
წაიკითხეთ სამივე გამოსავალი ერთად. პირველი ამბობს, რისი სჯერა კიდეს, მეორე ამბობს, რა ისწავლა და რომელი პირისგან, ხოლო მესამე ამბობს, რას გადასცემს რეალურად. მათ შორის შეუთანხმებლობა ჩვეულებრივ პოლიტიკის ან რეკურსიის პრობლემაა და არა დაკარგული განცხადება, და ღირს მისი მოგვარება სანამ პროვაიდერს გამოძიებას სთხოვთ. წაიღეთ ეს სამი გამოსავალი ოპერატორთან ზარზე, რადგან ისინი პასუხობენ იმ კითხვების უმეტესობას, რომლებსაც მხარდაჭერის ინჟინერი სხვაგვარად დაგისვამდათ.
იცოდეთ, რას არ აწვდის სერვისი
ეს არის მე-3 დონის მარშრუტიზებული წვდომა. ეს არ არის მე-2 დონის წრე, რომელიც მაუწყებლობას ოფისებს შორის ავრცელებს, ამიტომ აღმოჩენის პროტოკოლები, მაუწყებლობაზე დამოკიდებული აპლიკაციები და საერთო სეგმენტის დაშვებები მასთან ერთად არ მოგზაურობენ. ბეჭდვა, სახელების დათვალიერება და ყველაფერი, რაც ადგილობრივ სეგმენტზეა დამოკიდებული, საკუთარ დიზაინს საჭიროებს.
VPN-ის გამიჯვნა დაშიფვრაც არ არის. ეტიკეტების კომუტაცია მომხმარებლებს პროვაიდერის ქსელში ცალ-ცალკე ინახავს და ის დატვირთვას კონფიდენციალურს არ ხდის, თუ ხელშეკრულება კონფიდენციალურობას მოითხოვს. სადაც ეს მნიშვნელოვანია, ის აპლიკაციამ ან გადაფარვის ფენამ უნდა უზრუნველყოს.
ბოლოს, შეინახეთ სერვისის მოდელი ჩაწერილი ობიექტის მარშრუტიზაციის კონფიგურაციის გვერდით. შემდეგმა ინჟინერმა, რომელიც ქვექსელს დაამატებს, უნდა შეძლოს წაიკითხოს რომელი პრეფიქსები ცხადდება, ვინ იღებს მათ და რა არის მოსალოდნელი დაბრუნების გზა: BGP/MPLS IP VPN სპეციფიკაცია არის მითითება იმ მოდელისთვის, რომელიც ამ ყველაფრის უკან დგას.