QoS ต่อทันเนลไม่ได้จำกัด uplink รวมของฮับคุณ

ความเชื่อนี้ฟังดูเหมือนเลขคณิต ห้าสโปกที่ถูกจัดรูปให้เหลือ 5 Mbit/s ต่อตัว ฮับจึงรับส่งได้มากที่สุด 25 Mbit/s ครึ่งแรกจริง ข้อสรุปไม่จริง นโยบายต่อทันเนลถูกใช้หนึ่งครั้งต่อทันเนล ไม่ใช่หนึ่งครั้งต่อฮับ และ uplink ที่ใช้ร่วมกันซึ่งทั้งห้าทันเนลต้องผ่านไม่เคยปรากฏในการคำนวณนั้น ความแออัดบน uplink ยังคงอยู่เหมือนเดิมทุกประการ

ความเชื่อนี้มาจากไหน

ความสับสนนี้เข้าใจได้ เพราะข้อมูลกลุ่ม NHRP ทำให้คำจำกัดความนโยบายหนึ่งรายการใช้ได้กับสโปกทั้งชุด ซึ่งอ่านดูเหมือนงบประมาณร่วมในไฟล์กำหนดค่า สิ่งที่มันหมายถึงจริง ๆ คือแต่ละสโปกได้อินสแตนซ์ของคำจำกัดความนั้นเป็นของตัวเอง

ดังนั้น 5 Mbit/s ต่อสโปกคือเพดานต่อทันเนล และมีเพดานเท่าจำนวนทันเนล

อินสแตนซ์นโยบายหนึ่งรายการควบคุมอะไร

คู่มือ Cisco เรื่อง QoS ต่อทันเนลใน DMVPN บน IOS XE อธิบายนโยบายขาออกจากฮับที่เลือกผ่านข้อมูลกลุ่ม NHRP และใช้แยกกับแต่ละสโปก มีข้อจำกัดสองข้อตามมาจากประโยคนั้น และทั้งสองข้อถูกมองข้าม อัตราเป็นของสโปกเดียวไม่ใช่ถังร่วม และฟีเจอร์นี้ควบคุมทราฟฟิกจากฮับไปยังสโปก ไม่ใช่ทางกลับกัน

วางแผนทิศทางการส่งของสโปกแยกต่างหาก ไม่มีสิ่งใดในนโยบายขาออกจากฮับจำกัดสิ่งที่สาขาอัปโหลด

วางขีดจำกัดรวมไว้ที่คอขวดที่ใช้ร่วมกัน

ปริมาณรวมต้องถูกจัดรูปในจุดที่แข่งขันกันจริง คืออินเทอร์เฟซกายภาพที่ทุกทันเนลใช้ร่วมกัน Cisco ระบุ shaper class-default บนอินเทอร์เฟซกายภาพว่าเป็นนโยบายกายภาพพร้อมกันที่รองรับสำหรับฟีเจอร์นี้ ซึ่งเป็นถ้อยคำที่แคบกว่าลำดับชั้นใด ๆ ที่คุณพิมพ์ได้ สมมติว่านโยบายกายภาพที่สองตามอำเภอใจที่คุณคิดขึ้นไม่ได้รับการรองรับจนกว่าจะมีใครพิสูจน์ตรงกันข้าม

จากนั้นตัดสินใจว่าเกิดอะไรขึ้นเมื่อทุกสโปกยุ่งพร้อมกัน ทราฟฟิกใดถูกอนุญาต คลาสใดได้ลำดับความสำคัญ และคิวใดเป็นเจ้าของการแข่งขัน เพดานต่อสโปกไม่ตอบคำถามเหล่านี้สักข้อ เพราะแต่ละสโปกถูกพิจารณาแยกกัน

จับคู่หน่วยการจัดรูปและการบัญชีโอเวอร์เฮดกับการส่งมอบจริง โอเวอร์เฮดของการห่อหุ้มที่คุณละไว้จากการคำนวณอัตราจะปรากฏเป็นลิงก์ที่อิ่มตัวก่อนตัวเลขที่กำหนดไว้

ตัวนับโกหกในแบบหนึ่งที่เฉพาะเจาะจง

อ่านตัวนับที่ชั้นที่คุณกำลังจัดรูป คู่มือ Cisco เดียวกันเตือนว่าตัวนับนโยบายของอินเทอร์เฟซหลักอาจไม่แม่นยำในการจัดวางแบบนี้ นั่นเป็นข้อควรระวังเกี่ยวกับตัวนับ ไม่ใช่หลักฐานว่าคลาสตรงกันหรือทิ้ง แยกเรื่องนี้ออกจากผลลัพธ์ของแอปพลิเคชัน ซึ่งเป็นสิ่งเดียวที่ผู้ใช้สัมผัส

การคัดลอกตัวอย่าง traffic-shape เก่าไว้ข้าง ๆ แผนที่นโยบายที่ไม่เกี่ยวข้องไม่ได้พิสูจน์ว่าทั้งสองอัตราควบคุมแพ็กเก็ตเดียวกัน

ทดสอบปริมาณรวม ไม่ใช่แค่เพดาน

เริ่มด้วยสโปกที่ยุ่งหนึ่งตัวและยืนยันว่ามันถึงเพดานของมัน จากนั้นเสนอทราฟฟิกจากทุกตัวพร้อมกันภายใต้แผนที่ได้รับอนุมัติ และเฝ้าดูอินเทอร์เฟซกายภาพข้าง ๆ ตัวเลขต่อทันเนล หากแต่ละสโปกอยู่ที่เพดานของตนในขณะที่ uplink แน่นและความหน่วงเพิ่มขึ้น นโยบายต่อสโปกทำงานตามที่ออกแบบไว้ทุกประการ และงบประมาณยังผิดอยู่

วิธีแก้ ณ จุดนั้นคือการตัดสินใจเรื่องความจุหรือการรับเข้า การปรับตัวเลขต่อสโปกใหม่เพียงเปลี่ยนว่าสาขาใดบ่นก่อน