სჭირდება VPNv4-ს MPLS ბირთვში? სულაც არა
BGP VPNv4 აწარმოებს მარშრუტების განაწილების კონტექსტზე მოლაპარაკებას და არა გადაცემის გზაზე. გამოყავით იმპორტი, შემდეგი ჰოპის გადაწყვეტა და ის ინკაფსულაცია, რომელიც შეგიძლიათ გამოიყენოთ.
ორ როუტერს შორის VPNv4 მისამართების ოჯახის ჩართვა ქმნის მხოლოდ მარშრუტების განაწილების კონტექსტს და მეტს არაფერს. ის არ ამონტაჟებს გადაცემის გზას და არ ამბობს, რომელი ინკაფსულაცია მიიტანს კლიენტის პაკეტს შორეულ საბოლოო წერტილამდე. როცა ეს ორი ფაქტი ერთმანეთისგან გაიყოფა, კითხვა «სჭირდება ამას MPLS ბირთვში» უფრო ვიწრო და პასუხგასაცემი კითხვა ხდება პლატფორმის მიერ მხარდაჭერილ მონაცემთა სიბრტყეზე.
რაზე აწარმოებს მოლაპარაკებას მისამართების ოჯახი სინამდვილეში
მრავალპროტოკოლური BGP AFI 1-ისა და SAFI 128-ის ქვეშ გადააქვს VPNv4 ქსელური დონის ხელმისაწვდომობის ინფორმაცია და თითოეული ჩანაწერი მარშრუტის გამმიჯნავს უკავშირებს პრეფიქსსა და იარლიყს. სესია აწარმოებს მოლაპარაკებას იმაზე, რომ ორივე მხარეს შეუძლია ამ ინფორმაციის კოდირება და დეკოდირება. რაზეც ის არ აწარმოებს მოლაპარაკებას, არის მონაცემთა სიბრტყე. ყველაფერი ამ აბზაცის შემდეგ გადაცემას ეხება და აქედან არაფერი წყდება სესიის აწევით.
ამრიგად, წარმატებული სესია საკონტროლო სიბრტყის შესაძლებლობის მტკიცებულებაა და არა გადაცემის. როუტერს შეუძლია ათასობით VPNv4 ჩანაწერი შეინახოს და მაინც ყოველი კლიენტის პაკეტი გადააგდოს, და სწორედ ამიტომ აირევა ეს ორი წარუმატებლობის კლასი თავიდანვე.
ყურადღება მიაქციეთ იარლიყს NLRI-ში. ეს არის სერვისის იარლიყი, მიბმული VRF-ის შიგნით პრეფიქსზე, და მას გადაცემის როლი აქვს, როცა პაკეტი გამავალ საბოლოო წერტილს აღწევს. წაიკითხავს თუ არა მას რომელიმე გამშვები მოწყობილობა, ცალკე დიზაინის გადაწყვეტილებაა.
მიღება, იმპორტი და გადაცემა სამი ნაბიჯია
მარშრუტის მიღებას, მისი გამოყენების ნებართვას და მით გადაცემის უნარს მოწყობილობის სხვადასხვა ნაწილი ასრულებს. BGP ინახავს იმას, რასაც ისმენს; იმპორტის პოლიტიკა და მარშრუტის სამიზნის დამთხვევა განსაზღვრავს, რომელ VRF-ს შეუძლია მისი განხილვა; შემდეგ გადაცემის სიბრტყემ გამოცხადებული შემდეგი ჰოპი უნდა გადაწყვიტოს ისეთ რამედ, რომლის გაშვებაც ნამდვილად შეუძლია მავთულში.
| Step in the chain | What has to be true | How it fails quietly |
|---|---|---|
| NLRI exchange | Both speakers negotiate the VPNv4 capability | Session stays up while the family is never activated |
| Import eligibility | A route target on the received route matches the VRF import policy | The route exists in the table but never enters the VRF |
| Next-hop resolution | The advertised next hop resolves to a usable tunnel or label path | Best path is selected, then marked unreachable or unusable |
| Encapsulation | The egress endpoint can decapsulate what the ingress produced | Packets arrive and are discarded for a format mismatch |
სწორედ ამ შუა ნაბიჯში ცხოვრობს ყველაზე გასაოცარი წარუმატებლობები. მარშრუტი შეიძლება იყოს BGP ცხრილში, ვალიდური და თუნდაც საუკეთესო, მაშინ როცა VRF-ის მარშრუტების ცხრილი ცარიელი რჩება, რადგან არცერთი მარშრუტის სამიზნე არ დაემთხვა იმპორტის სიას. არაფერი არ ლოგავს პროტოკოლის შეცდომას, რადგან პროტოკოლის შეცდომა არ მომხდარა.
ბოლო ნაბიჯი არის ადგილი, სადაც პლატფორმის მხარდაჭერა ჩანს. ქვედა ფენაში მისაწვდომი შემდეგი ჰოპი ავტომატურად არ იხსნება VPN სერვისის ტრანსპორტად, და მოწყობილობამ შეიძლება მოითხოვოს კონკრეტული გვირაბის ტიპი, კონკრეტული იარლიყის ოპერაცია ან ორივე. გადაწყვეტის სტატუსის წაკითხვა უფრო ინფორმაციულია, ვიდრე მარშრუტების რაოდენობის წაკითხვა.
IP ბირთვს შეუძლია ატაროს სტეკი, რომელსაც ის არასოდეს გადართავს
შესანარჩუნებელი განსხვავება არის «ბირთვი MPLS-ს არ ამუშავებს» და «სერვისში არსად არ არსებობს იარლიყი» შორის. ეს სხვადასხვა მტკიცებაა და მხოლოდ პირველი ეხება გამშვებ მოწყობილობებს. RFC 4023 განსაზღვრავს MPLS-ის ტარებას IP ან GRE გვირაბებით და სწორედ ეს მექანიზმი ხდის მეორე მტკიცებას შესაძლებელს სრულიად IP ბირთვზე.
customer packet + service label
encapsulated in GRE, addressed to the egress tunnel endpoint
forwarded by ordinary IP routers on the outer header
decapsulated at the endpoint, label still meaningfulგამშვები როუტერები გადასცემენ გარე IP დანიშნულების მიხედვით და არ სჭირდებათ არც კლიენტის პრეფიქსები და არც მშობლიური იარლიყების გადართვა. შორეულ ბოლოში გარე გვირაბი მოიხსნება და სერვისის იარლიყი აგრძელებს თავის საქმეს. ბირთვმა გადაიტანა გაუმჭვირვალე დატვირთვა და სწორედ ეს არის ის, რაშიც IP ქსელი ძლიერია.
რასაც ეს დიზაინი არ გაძლევთ, არის უნივერსალური გარანტია. ეს არ არის მტკიცებულება, რომ ყოველი როუტერი ყოველ VPNv4 შემდეგ ჰოპს ნებისმიერ GRE ინტერფეისზე ხსნის, და არც მიზეზია მუშა მშობლიური MPLS კონფიგურაციის წასაშლელად. ეს არის უნივერსალური მტკიცების კონტრმაგალითი და პრაქტიკული კითხვა პლატფორმისთვის ლოკალური რჩება. ჩაწერეთ ეს კითხვა პლატფორმის შეზღუდვად და არა პროტოკოლის წესად.
გაიარეთ ჯაჭვი მოწყობილობაზე, სანამ გატყდება
დაიწყეთ მიღებული მარშრუტიდან და გაჩერდით პირველ ნაბიჯზე, რომელიც ვერ ხერხდება, რადგან შემდგომი ნაბიჯების დიაგნოსტიკა შეუძლებელია, სანამ წინა გატეხილია. ოთხი ბრძანება ფარავს ამის უმეტეს ნაწილს ტიპურ განხორციელებაში.
show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_Aწაიკითხეთ ისინი თანმიმდევრობად და არა ოთხ დამოუკიდებელ შემოწმებად. პირველი ადასტურებს, რომ ოჯახი აქტიურია და პარტნიორი მარშრუტებს ცვლის; მეორე აჩვენებს, მოვიდა თუ არა პრეფიქსი გამოსადეგი შემდეგი ჰოპით; მესამე ამტკიცებს იმპორტის უფლებას; მეოთხე აჩვენებს, დაუკავშირა თუ არა გადაცემის სიბრტყემ მას იარლიყი ან გვირაბი.
შემდეგ გამოსცადეთ დატვირთვის გზა ორივე მიმართულებით, MTU-ით, რომელიც უძლებს ინკაფსულაციას. GRE ამატებს სათაურის ბაიტებს და გზა, რომელიც პატარა ზონდებს გადის, შეიძლება ჩავარდეს სრული ზომის პაკეტებზე მხოლოდ ერთი მიმართულებით, რაც აპლიკაციის ხარვეზად გამოიყურება და არა ტრანსპორტის.
ორი ოპერაციული შენიშვნა ხურავს ციკლს. GRE ინკაფსულაციაა და არა კონფიდენციალურობა, ამიტომ არასანდო გამშვებ ქსელს სჭირდება მხარდაჭერილი უსაფრთხოების მოწყობა ზემოდან და არა ვარაუდი. და დიზაინის მიმოხილვამდე ჩაწერეთ, რომელ ინკაფსულაციას უჭერს პლატფორმა რეალურად მხარს, რადგან სწორედ ეს ერთი პასუხი წყვეტს, არის თუ არა მხოლოდ IP ბირთვი ვალიდური არჩევანი თუ გეგმა, რომელსაც გადაცემა არ შეუძლია.