IPv6 MPLS VPN-ში: სამი არჩევანი და არა ერთი მისამართების ოჯახი
მომხმარებლის VPN მარშრუტები, PE-ებს შორის BGP სესია და ბირთვის ტრანსპორტი ცალკე გადაწყვეტილებებია. სესია შეიძლება ერთ ოჯახში მუშაობდეს და მეორე ატაროს.
თუ დიზაინის მიმოხილვაზე იტყვით „გაუშვი IPv6 L3VPN IPv6 BGP-ის თავზე“, ამ ერთ წინადადებაში სამი ცალკე გადაწყვეტილება იმალება. რომელი პრეფიქსები ეკუთვნის მომხმარებლის VPN-ს, რომელი მისამართები ატარებს მარშრუტიზაციის სესიას პროვაიდერის კიდეებს შორის და რომელი ბირთვი გადაადგილებს იარლიყიან პაკეტს, ეს დამოუკიდებელი არჩევანია. ყველა შეიძლება იყოს IPv6, შეიძლება იყოს შერეული, და შერევა განზრახ დაშვებულია. სწორედ ამ სამის გარჩევა აქცევს ბუნდოვან მოთხოვნას იმად, რაზეც პლატფორმის გამოცდა შეიძლება.
გამოყავით სამი საქმე
პირველი საქმე მომხმარებლის მარშრუტია: IPv6 პრეფიქსები, რომლებიც ეკუთვნის VPN მარშრუტიზაციის ერთ კონტექსტს და უნდა დარჩეს ყველა სხვა კონტექსტის გარეთ. მეორე არის მარშრუტიზაციის კავშირი პროვაიდერის კიდურ როუტერებს შორის, რომლებიც ცვლიან ამ პრეფიქსებს. მესამე არის ტრანსპორტი, რომელიც იარლიყიან მომხმარებლის პაკეტს ბირთვში გაატარებს შორეულ კიდემდე. მათგან მხოლოდ ერთის დასახელება ჯერ არ არის დიზაინი.
| Job | The question it answers | What confusion looks like |
|---|---|---|
| Customer VPN routes | Which IPv6 prefixes belong to each VPN context, and how are they kept apart? | Prefixes leak into the global table and between customers |
| PE-to-PE BGP session | Which addresses carry the routing connection between the two edges? | A session-family mismatch gets chased as a core transport fault |
| Transport to the remote PE | How does the chosen core move the labelled packet to the far edge? | A route is present and unforwardable in the same moment |
თითოეულ საქმეს აქვს თავისი მისამართების ოჯახი, წარუმატებლობის თავისი ფორმები და ხშირად თავისი გუნდი. ცხრილი სწორედ ამიტომ სასარგებლოა, რომ დიზაინის დოკუმენტში ერთი წინადადება სამივე სტრიქონს ერთში ამტვირთავს.
მარშრუტის ოჯახია VPN-IPv6 და არა IPv6 unicast
RFC 4659 განსაზღვრავს BGP/MPLS IPv6 VPN ოჯახს და მასში წევრობა უფრო კონკრეტულია, ვიდრე სიტყვა IPv6 მიგვანიშნებს. მარშრუტი იქ არის მარშრუტის გამმიჯნავი, დაკავშირებული IPv6 პრეფიქსთან და დაშიფრული AFI 2 და SAFI 128-ის ქვეშ. ჩვეულებრივი IPv6 unicast სხვა ოჯახია, ამიტომ looking glass-ში პრეფიქსის მსგავსი განცხადება შეიძლება საერთოდ არ იყოს იგივე ობიექტი. ოჯახის არასწორად წაკითხვა პირველი გზაა, რომლითაც ეს დიზაინი ფუჭდება.
განსხვავება კიდეზე იჩენს თავს, სადაც მარშრუტი ჯერ სწორ VPN კონტექსტში უნდა დაჯდეს, სანამ რამეს იზამს. პრეფიქსის მიღება ამტკიცებს, რომ გაცვლა მოხდა და არაფერს ამბობს ინსტალაციაზე. სწორედ ეს ღრეჩო წარმოშობს კლასიკურ ანგარიშს, როცა სესია აწეულია და მომხმარებელი კვლავ სიბნელეშია.
სესია შეიძლება VPN-ისგან განსხვავებულ ოჯახში მუშაობდეს
ვერაფერი აიძულებს ორ კიდეს შორის BGP კავშირს გამოიყენოს VPN-ის საკუთარი ოჯახი. სპეციფიკაცია უშვებს IPv4 ან IPv6 სესიას, და IPv6 VPN ტრანსპორტი თავად განსაზღვრულია ორივე ბირთვის ტიპზე. ამიტომ IPv6 სესია არაფერს ამბობს იმის ოჯახზე, რასაც ატარებს, და მონაცემთა სიბრტყესაც არ ირჩევს. სამი დამოუკიდებელი ბიტი, და დიზაინმა სამივე ცალ-ცალკე უნდა შეინარჩუნოს.
ეს ათავისუფლებს და ამავდროულად ადვილად იკითხება არასწორად. IPv6 მომხმარებლის მარშრუტები შეიძლება IPv4 მისამართიანი სესიით იმოძრაონ, ხოლო IPv4 მარშრუტები IPv6-ით, თუ პლატფორმა ამ კომბინაციას უჭერს მხარს და შემდეგი ნახტომი იხსნება. რაც არ უნდა მოხდეს, არის ის, რომ სესიამ დატვირთვა მიანიშნოს, დიზაინის დოკუმენტში ან იმ მონიტორინგში, რომელიც მოგვიანებით ამტკიცებს სერვისს.
IPv4 ბირთვზე შემდეგ ნახტომს საკუთარი კოდირება აქვს
როცა VPN-ის ქვეშ ბირთვი IPv4-ია, მარშრუტი არ ჩნდება ისეთი შემდეგი ნახტომით, რომელსაც შემომავალი კიდე პირდაპირ გამოიყენებდა. ის მოდის IPv4-ში დასახატული IPv6 ფორმით, და სწორედ ასე გამოხატავს სპეციფიკაცია გამავალ კიდეს, როცა ქვემოთა ტრანსპორტი IPv4-ია. შემდეგ შემომავალ როუტერს ეს დასახატული მისამართი უნდა აქციოს იმად, რასაც ის ნამდვილად მიაღწევს ბირთვის გავლით, და გადაწყვეტა ის საფეხურია, რომელიც ჩუმად ფუჭდება.
წაიკითხეთ ეს გადაცემის დამოკიდებულებად და არა მოწყობილობებს შორის გადასაწერ სტრიქონად. დაადასტურეთ სამი რამ იმ პლატფორმაზე, რომელსაც ნამდვილად უძღვებით: გამოცხადებული შემდეგი ნახტომი იხსნება გამოსაყენებელ გზამდე, იარლიყების დასტა მიიღება, და დანიშნულების ადგილი ჯდება განზრახული VPN კონტექსტში. თუ რომელიმე მათგანი ჩავარდა, რჩება სესია, რომელიც ჯანმრთელად გამოიყურება და არაფერს გადასცემს, ამიტომ ეს შემოწმება მისაღების გაშვებას ეკუთვნის და არა გვიანდელ ინციდენტს.
დაწერეთ მოთხოვნა ოთხ სტრიქონში
გამოცდის ღირსი მოთხოვნა ასახელებს ოთხ რამეს: VPN-ის ოჯახს, სესიის ტრანსპორტს, შემდეგი ნახტომის კოდირებას და ბირთვის მოწყობას. შემდეგ ასახელებს ერთ მომხმარებლის პრეფიქსს, რომელიც ბოლომდე უნდა გაიყოლოს: გაცვლის, ინსტალაციის, იარლიყის გადაწყვეტისა და დაბრუნების გზის გავლით. „IPv6 BGP-ს უჭერს მხარს“ ოთხთაგან არც ერთს არ ფარავს და მალავს, სად არის სინამდვილეში შეუსაბამობა.
ჯანმრთელი სესია VPN-IPv6 გაცვლის გარეშე არასრულია, და მიღებული VPN მარშრუტი მომუშავე გადაცემის გარეშე თანაბრად არასრულია. მათი ცალკე მისაღებ სტრიქონებად შენახვა ამოკლებს შემდეგ პრობლემის მოძიების საუბარს, რადგან ჩავარდნილი სტრიქონი უკვე დაწერილია.