ლეიბლი თითო VRF-ზე თუ თითო პრეფიქსზე? რეალური სიმძლავრის ანგარიში

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

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

რას ზოგავს რეალურად თითოეული გამოყოფა

თითო პრეფიქსზე გამოყოფა გადამისამართების ინფორმაციას ლეიბლში ატარებს. გამომავალ მარშრუტიზატორს შეუძლია პაკეტი პირდაპირ სწორ მეზობლობაზე გაგზავნოს დანიშნულების ძიების გარეშე, რის გამოც ის კარგად მასშტაბირდება VRF-ის დიდი მარშრუტების კრებულებისთვის და რის გამოც ის ხარჯავს ერთ ლეიბლს ყოველ გამოცხადებულ პრეფიქსზე ყოველ VRF-ში. თითო VRF-ზე გამოყოფა, მაგალითად Junos vrf-table-label, აცხადებს ერთ ლეიბლს ყოველ მარშრუტიზაციის ინსტანციაზე და იყენებს ამ ლეიბლს VRF-ის ცხრილის ასარჩევად; შემდეგ მარშრუტიზატორი ასრულებს IP ძიებას ცხრილის შიგნით.

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

ლეიბლების დავთარი პატარაა

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

სანამ აირჩევთ, დაითვალეთ ლეიბლები როგორც სერვისისთვის, ისე ტრანსპორტისთვის. VRF-ზე დიზაინს მაინც სჭირდება ტრანსპორტის ლეიბლები loopback-ებისთვის და გზის ყოველი ნახტომისთვის, და მაინც სჭირდება მეზობლობის მდგომარეობა. თუ დიზაინის აღწერა ითვლის მხოლოდ სერვისის ლეიბლებს, დაზოგვა არასწორ დავთარზე იზომება.

მარშრუტების ნაკადები მეხსიერებას ხარჯავს ლეიბლებამდე

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

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

როდის არის VRF-ზე ლეიბლირება სწორი ნაგულისხმევი

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

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

ბიუჯეტი, რომლის დაცვაც შეგიძლიათ

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

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

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