Per-Tunnel-QoS deckelt nicht den Gesamt-Uplink deines Hubs

Der Glaube klingt wie Arithmetik: fünf Spokes, jeder auf 5 Mbit/s geformt, also trägt der Hub höchstens 25 Mbit/s. Die erste Hälfte stimmt, die Schlussfolgerung nicht. Eine Per-Tunnel-Richtlinie wird einmal pro Tunnel angewendet, nicht einmal pro Hub, und der gemeinsame Uplink, den alle fünf Tunnel überqueren, taucht in dieser Rechnung nie auf. Die Überlastung auf dem Uplink bleibt genau so bestehen, wie sie war.

Woher der Glaube kommt

Die Verwirrung ist verständlich, weil NHRP-Gruppeninformationen es erlauben, eine Richtliniendefinition auf eine ganze Gruppe von Spokes anzuwenden. Das liest sich wie ein gemeinsames Budget in einer Konfigurationsdatei. Tatsächlich bedeutet es, dass jeder Spoke seine eigene Instanz dieser Definition erhält.

5 Mbit/s pro Spoke ist also eine Obergrenze pro Tunnel, und es gibt so viele Obergrenzen wie Tunnel.

Was eine Richtlinieninstanz steuert

Ciscos Leitfaden zu QoS pro Tunnel in DMVPN unter IOS XE beschreibt eine Hub-Egress-Richtlinie, die über NHRP-Gruppeninformationen ausgewählt und separat auf jeden Spoke angewendet wird. Aus diesem Satz folgen zwei Grenzen, und beide werden ignoriert. Die Rate gehört zu einem einzelnen Spoke und nicht zu einem gemeinsamen Topf, und die Funktion steuert den Datenverkehr vom Hub zum Spoke, nicht umgekehrt.

Plane die Senderichtung des Spokes unabhängig. Nichts in einer Hub-Egress-Richtlinie begrenzt, was eine Filiale hochlädt.

Setze die Gesamtgrenze am gemeinsamen Engpass

Das Aggregat muss dort geformt werden, wo es tatsächlich konkurriert: an der physischen Schnittstelle, die alle Tunnel teilen. Cisco dokumentiert einen class-default-Shaper auf der physischen Schnittstelle als die unterstützte gleichzeitige physische Richtlinie für diese Funktion, was eine engere Aussage ist als jede Hierarchie, die du eingeben kannst. Gehe davon aus, dass die willkürliche zweite physische Richtlinie, die du erfunden hast, nicht unterstützt wird, bis jemand das Gegenteil beweist.

Dann entscheide, was passiert, wenn alle Spokes gleichzeitig beschäftigt sind. Welcher Verkehr zugelassen wird, welche Klasse priorisiert wird und welche Warteschlange den Wettbewerb besitzt. Eine Obergrenze pro Spoke beantwortet keine dieser Fragen, weil jeder Spoke für sich betrachtet wird.

Passe Formungseinheiten und Overhead-Abrechnung an die tatsächliche Übergabe an. Kapselungs-Overhead, den du aus der Ratenberechnung weglässt, zeigt sich als eine Verbindung, die vor der konfigurierten Zahl sättigt.

Zähler lügen auf eine bestimmte Weise

Lies Zähler auf der Ebene, die du formst. Derselbe Cisco-Leitfaden warnt, dass Richtlinienzähler der Hauptschnittstelle in dieser Anordnung ungenau sein können. Das ist ein Vorbehalt zum Zähler, kein Beweis dafür, dass eine Klasse trifft oder verwirft. Halte dies getrennt vom Anwendungsergebnis, dem Einzigen, was der Nutzer erlebt.

Ein altes Traffic-Shape-Beispiel neben eine unabhängige Policy-Map zu kopieren, belegt nicht, dass beide Raten dieselben Pakete steuern.

Teste das Aggregat, nicht nur die Obergrenze

Beginne mit einem beschäftigten Spoke und bestätige, dass er seine Obergrenze erreicht. Biete dann Verkehr von allen gleichzeitig nach einem genehmigten Plan an und beobachte die physische Schnittstelle neben den Zahlen pro Tunnel. Wenn jeder Spoke an seiner Obergrenze sitzt, während der Uplink ausgelastet ist und die Verzögerung steigt, arbeitet die Richtlinie pro Spoke genau wie entworfen, und das Budget ist weiterhin falsch.

Die Korrektur ist an diesem Punkt eine Kapazitäts- oder Zulassungsentscheidung. Das Nachjustieren der Zahlen pro Spoke ändert nur, welche Filiale sich zuerst beschwert.