თითო თუნელზე QoS თქვენი hub-ის საერთო uplink-ს არ ზღუდავს

ეს რწმენა არითმეტიკას ჰგავს: ხუთი spoke, თითოეული 5 Mbit/s-ზე ჩამოყალიბებული, ამიტომ hub ატარებს მაქსიმუმ 25 Mbit/s-ს. პირველი ნახევარი მართალია, დასკვნა კი არა. თითო თუნელზე პოლიტიკა გამოიყენება ერთხელ თითო თუნელზე და არა ერთხელ hub-ზე, და საერთო uplink, რომელსაც ხუთივე თუნელი კვეთს, ამ გამოთვლაში არასდროს ჩნდება. Uplink-ზე გადატვირთულობა ზუსტად ისე რჩება, როგორც იყო.

საიდან მოდის ეს რწმენა

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

ასე რომ, 5 Mbit/s თითო spoke-ზე არის თითო თუნელზე ჭერი, და ჭერი იმდენია, რამდენი თუნელიც.

რას აკონტროლებს პოლიტიკის ერთი ეგზემპლარი

Cisco-ს QoS-ის გზამკვლევი თითო თუნელზე DMVPN-ში IOS XE-ზე აღწერს hub-ის გასასვლელ პოლიტიკას, რომელიც ირჩევა NHRP ჯგუფის ინფორმაციით და ცალ-ცალკე გამოიყენება თითოეულ spoke-ზე. ამ წინადადებიდან ორი შეზღუდვა გამომდინარეობს და ორივე უგულებელყოფილია. სიჩქარე ერთ spoke-ს ეკუთვნის და არა საერთო ვედროს, და ფუნქცია აკონტროლებს ტრაფიკს hub-იდან spoke-ისკენ და არა პირიქით.

დაგეგმეთ spoke-ის გაგზავნის მიმართულება დამოუკიდებლად. hub-ის გასასვლელ პოლიტიკაში არაფერი ზღუდავს იმას, რასაც ფილიალი ტვირთავს.

საერთო ლიმიტი საერთო ბარიერზე დააყენეთ

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

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

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

მრიცხველები ერთი კონკრეტული გზით ტყუიან

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

ძველი traffic-shape მაგალითის დაკოპირება დაუკავშირებელი პოლიტიკის რუკის გვერდით არ ამტკიცებს, რომ ორი სიჩქარე ერთსა და იმავე პაკეტებს აკონტროლებს.

შეამოწმეთ აგრეგატი და არა მხოლოდ ჭერი

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

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