დიდი ვარსკვლავური VPN-ის ზომის განსაზღვრა: სანამ BGP-ს აირჩევთ, დათვალეთ
პრეფიქსები მარტივი რიცხვია. სესიები, განახლებების ნაკადი და აღდგენა ჰაბის ჩავარდნის შემდეგ წყვეტს, გაუძლებს თუ არა დიზაინი რამდენიმე ათას ფილიალს.
სამი ათასი ფილიალი როუტინგის პრობლემად ჟღერს, მაგრამ ბუღალტრული პრობლემასავით იქცევა. პრეფიქსების ჯამი ათ წუთში ითვლება და იშვიათად არის ის რიცხვი, რომელიც ტკივის. ტკივის სესიაზე დაყოფილი სამუშაო, განახლებების აფეთქება, როცა საერთო კომპონენტი ფუჭდება, და დრო, რომელიც გადაგზავნის ახალ ტოპოლოგიასთან ხელახლა შესაბამისობას სჭირდება.
ამიტომ არითმეტიკა სწორი თანმიმდევრობით გაიარეთ. დაითვალეთ კავშირები, დაითვალეთ პრეფიქსები და ალტერნატივები, შემდეგ დაითვალეთ, რა ხდება ცუდ საათში, და მხოლოდ ამის შემდეგ შეადარეთ პროტოკოლები და პლატფორმები. საპირისპირო წყობით ეს სავარჯიშო მარშრუტების ლიმიტებზე კამათად იქცევა, რომელსაც მაგიდაზე არსებული ინფორმაციით ვერავინ გადაწყვეტს.
ოთხი ბიუჯეტი, არა ერთი
ყოველი ბიუჯეტი სხვა კითხვას პასუხობს და თითოეული შეიძლება შემზღუდველი იყოს სხვადასხვა პლატფორმაზე. მათი ცალკე ჩაწერა ხელს უშლის ერთ დიდ პრეფიქსულ რიცხვს მთელი დიზაინის ნაცვლად დადგეს.
| Budget | What you are really counting |
|---|---|
| Sessions | Peers per hub, keepalive or hello processing, authentication state, and the per-neighbor memory that never shows up in a route count |
| Prefixes | Alternatives received, prefixes selected, entries installed for forwarding, and how much of that each spoke is allowed to see |
| Churn | Updates generated by a flapping link, a hub outage, or every branch reconnecting after a regional event |
| Recovery | Time to detect, reselect, reinstall and restore the application, measured end to end rather than per box |
ბოლო ორია ის, რასაც დიზაინის განხილვისას ტოვებენ. ქსელი, რომელიც სტაბილურ მდგომარეობაში კომფორტულად ეტევა მეხსიერებაში, მაინც შეიძლება ცუდად მოიქცეს, როცა ოთხასი ფილიალი ორ წუთში ხელახლა უერთდება, რადგან სამუშაო უფრო სწრაფად მოდის, ვიდრე მართვის სიბრტყე ახერხებს მის გამოცლას. ჩაწერეთ აფეთქების ზომა რიცხვად, იმასთან ერთად, რამდენ ხანს შეიძლება დარჩეს სერვისი გაუარესებული. ეს გაურკვეველ შფოთს ტესტად აქცევს, რომელიც ვინმეს ნამდვილად შეუძლია გაუშვას.
ოთხივეში იმალება პლატფორმის კითხვაც: იზიარებენ თუ არა დაშიფვრა, გადაგზავნა და როუტინგი ერთ პროცესორს, თუ ცალკე გზები აქვთ. ერთი და იგივე მარშრუტული ტევადობის ორი მოწყობილობა შეიძლება ძალიან განსხვავებულად მოიქცეს აფეთქების დროს, და მონაცემთა ფურცელი იშვიათად ამბობს, რომელს ყიდულობთ.
გააკეთეთ გამოთვლა საკუთარი რიცხვებით
აიღეთ გამოგონილი დიზაინი: 3,000 ფილიალი, სამ-სამი პრეფიქსი აგრეგაციამდე და ორი ჰაბი თითო ფილიალზე სარეზერვოდ. ჰაბების წყვილმა შეჯამებამდე დაახლოებით 9,000 ფილიალური პრეფიქსი უნდა შეინახოს, და დიზაინი 6,000 ფილიალი-ჰაბის სესიას გულისხმობს, თუ ყოველი ფილიალი ორივესთან თანაბარია.
ახლა დაამატეთ ის ნაწილები, რომლებიც პრეფიქსი არ არის. ყოველი სესია ატარებს მდგომარეობას და პერიოდულ შეტყობინებებს, მაშინაც კი, როცა არაფერი იცვლება. ყოველ ჰაბს შეუძლია ერთზე მეტი გზა შეინახოს პრეფიქსზე, თუ მისგან სწრაფი გადართვა მოსალოდნელია, ამიტომ ალტერნატივების რაოდენობამ შეიძლება გადააჭარბოს არჩეულების რაოდენობას. და ყოველი შტოს ხედვა ცალკე პოლიტიკის გადაწყვეტილებაა: ყოველ ფილიალს ყველა სხვისი მარშრუტის მიცემა ამრავლებს სამუშაოს ისე, რასაც ჰაბის მხარეს დათვლა არ ამჟღავნებს.
ეს საგეგმო რიცხვებია დიზაინის საუბრისთვის, არა რომელიმე პროდუქტის გაზომვა. სავარჯიშოს სასარგებლო შედეგი მრუდის ფორმაა, არა მტკიცება იმის შესახებ, სად ნებდება კონკრეტული როუტერი.
რას გაძლევთ BGP და რას გაძლევთ IGP
BGP გამოყოფს, რა მიიღო როუტერმა, რა აირჩია და რას აცხადებს, და თითოეული მათგანი პოლიტიკით იმართება. სწორედ ეს სჭირდება ფილიალურ ქსელს, რადგან შტომ ჩვეულებრივ უნდა ნახოს ნაგულისხმევი მარშრუტი, ცენტრალური სერვისები და ძალიან ცოტა სხვა. მხოლოდ საბოლოო ცხრილის დათვლა მალავს ალტერნატივებსა და განცხადებებს, და სწორედ ისინი იზრდება დუბლირების დამატებისას.
IGP ავტომატურად არასწორი არ არის. როცა ტოპოლოგია, ზონების სტრუქტურა და მეზობლობის მოდელი სერვისს შეესაბამება, ბმულის მდგომარეობის პროტოკოლი სწრაფად კონვერგირდება და ნაკლებ პოლიტიკურ ხარაჩოს მოითხოვს. ხაფანგია ვიფიქროთ, რომ მას შეუძლია BGP-ის მსგავსი ექსპორტის კონტროლი გამოხატოს თითოეულ მეზობელზე: OSPF-ის ზონა დატბორვის საზღვარია, არა ფილტრი, რომელსაც ერთ ფილიალზე ჩამოკიდებთ.
ნებისმიერ შემთხვევაში, ჯერ ხილვადობის მოდელი გადაწყვიტეთ. ნაგულისხმევი მარშრუტები, ცენტრალური სერვისების შეჯამებები ან ფილიალის სრული დეტალები სამი სხვადასხვა პროდუქტია, და შეჯამება, რომელიც უფრო კონკრეტულ ჩავარდნას მალავს, დიზაინის გადაწყვეტილებაა, რომელიც უნდა ჩაიწეროს და არა ავარიის დროს აღმოჩნდეს.
გამოსცადეთ აფეთქება, არა სტაბილური მდგომარეობა
შედარება ააგეთ იმ ჩავარდნის გარშემო, რომელსაც ნამდვილად ელით: ჰაბი გამორთულია, რეგიონული WAN მოვლენა, ან ტექნიკური მომსახურების ფანჯარა, რომელიც ადგილების ნახევარს ერთდროულად თიშავს. გაზომეთ აღდგენა ფილიალის თვალსაზრისით, აპლიკაციის ჩათვლით, რადგან წამებში კონვერგირებადი მართვის სიბრტყე ცოტას ნიშნავს, თუ სესიის აღდგენას წუთები სჭირდება.
show bgp vpnv4 unicast summary
show ip route vrf BRANCH summary
show processes cpu sorted | include BGP|OSPFჩაწერეთ, რას აკეთებს პლატფორმა აფეთქების პიკზე და არა სიმშვიდეში, და გაიმეორეთ უსაფრთხოების ფუნქციებით ჩართული. კონცეფციის დამტკიცება, რომელიც მხოლოდ მშვიდ ცხრილს აჩვენებს, მეხსიერების ტესტია, და მეხსიერება არასდროს ყოფილა საინტერესო რიცხვი.