QoS und Storm Control auf Sophos Switch konfigurieren

Quality of Service (QoS) entscheidet bei Überlastung, welcher Traffic zuerst aus den Warteschlangen eines Switch-Ports gesendet wird. Bandwidth control setzt dagegen eine feste Obergrenze für ein- oder ausgehenden Traffic. Storm control verwirft Broadcast-, unbekannte Multicast- und unbekannte Unicast-Frames oberhalb eines Grenzwerts. Diese drei Funktionen ergänzen sich, sind aber nicht austauschbar.

Erfassen Sie zuerst Traffic und Markierungen und klären Sie, ob Sophos Fusion oder die lokale Oberfläche die Konfiguration schreibt. Legen Sie danach QoS und Queue-Zuordnung fest, rollen Sie Port-Trust, Bandbreitenlimits und Storm Control schrittweise aus und ergänzen Sie nur bei Bedarf eine Policy. Kontrollieren Sie gespeicherte Werte direkt; die tatsächliche Priorisierung und Grenzwerte prüfen Sie zusätzlich unter einer kontrollierten Lastprobe.

⚠️ Zu kleine Bandbreiten- oder Storm-Control-Werte verwerfen auch legitimen Traffic. Besonders auf Uplinks, Managementports sowie Ports zu Access Points, Telefonanlagen oder Servern können viele Geräte hinter einer einzigen Schnittstelle sichtbar sein. Ausgangswerte dokumentieren, zuerst einen unkritischen Testport ändern und einen unabhängigen Managementzugang bereithalten.

Kurzablauf:

1. In Sophos Fusion My Products > Switches > Switches > [Switch] > QoS öffnen.
2. Unter General settings QoS-Status, Scheduling method und Trust mode festlegen.
3. CoS mapping und DSCP mapping auf das eigene Markierungskonzept abbilden.
4. Unter Ports zuerst CoS mapping, danach Bandwidth control und Storm control pro Testport setzen.
5. Nur wenn eine genauere Klassifizierung erforderlich ist, unter Policies eine Policy hinzufügen und an die vorgesehenen Ports oder VLANs binden.
6. Synchronisation, Configuration source, Markierungen, Durchsatz und Verhalten unter kontrollierter Last prüfen.

Welche Funktion löst welches Problem?

QoS wirkt erst dann sichtbar, wenn mehrere Warteschlangen um dieselbe Ausgangskapazität konkurrieren. Ohne Engpass kann ein korrekt markiertes Paket genauso schnell wie anderer Traffic übertragen werden. Ein Bandbreitenlimit erzeugt demgegenüber bewusst einen Engpass. Storm Control ist kein allgemeines Rate-Limit: Es betrachtet die drei dokumentierten Frame-Klassen pro Port getrennt.

Voraussetzungen und Änderungsplan

Dieses Runbook verwendet Sophos Fusion. Dafür muss der Switch registriert, erreichbar und synchronisiert sein. Ausserdem gelten zwei klare Grenzen:

• Lizenz: Änderungen über Sophos Fusion setzen für jeden dort verwalteten Switch eine gültige Sophos Switch Support and Services Subscription voraus. Ohne gültige Subscription funktioniert der Switch weiter und kann lokal verwaltet werden, in Sophos Fusion lassen sich jedoch keine Änderungen vornehmen. Lizenzstatus und Registrierung sollten deshalb vor dem Wartungsfenster geprüft werden; der Ablauf Sophos Switch in Sophos Fusion registrieren erklärt diese Abhängigkeit.
• Berechtigung und führende Oberfläche: Das verwendete Sophos-Fusion-Konto muss Switch-Einstellungen ändern dürfen. Ein reiner Lesezugriff genügt nur für Bestandsaufnahme und Kontrolle. Wer lokal arbeitet, benötigt ein Konto mit Privilege type: Admin; Privilege type: User darf die Werte nur ansehen. Weil lokale Änderungen nicht automatisch mit Sophos Fusion synchronisiert werden, legen Sie vor dem Start eine schreibende Oberfläche fest und vermeiden parallele lokale Changes.

Notieren Sie vor der Konfiguration:

• betroffener Switch, Port, VLAN und Gegenstelle;
• Portgeschwindigkeit und normale sowie kurzzeitige Spitzenauslastung in beide Richtungen;
• Anwendungen, die bei Überlastung bevorzugt werden müssen;
• vorhandene CoS- und DSCP-Markierungen an Quelle, Uplink und Ziel;
• gewünschte Queue für jeden verwendeten CoS- beziehungsweise DSCP-Wert;
• bisheriger QoS-Status, Scheduling-Verfahren, Trust-Modus und alle Queue-Gewichte;
• bisherige Portwerte für CoS, Trust state, Egress (kbps), Ingress (kbps) sowie Broadcast, Multicast und Unicast;
• vorhandene Policies samt Bindung und Aktion;
• Configuration source jedes betroffenen Portwerts;
• ein Testclient, ein reproduzierbarer Datenstrom und Messwerte vor der Änderung;
• Wartungsfenster und Rückweg, falls der Managementpfad betroffen ist.

QoS-Markierungen müssen als Ende-zu-Ende-Konzept geplant werden. CoS nach IEEE 802.1p steht im 3-Bit-Feld eines VLAN-Tags und verwendet Werte von 0 bis 7. DSCP steht mit 6 Bit im IP-Header und verwendet Werte von 0 bis 63. Ein ungetaggtes Paket trägt kein 802.1p-CoS-Feld. VLAN-Tagging und PVID müssen deshalb vor einem CoS-basierten Rollout stimmen; die Grundlagen beschreibt die Anleitung Sophos Switch VLANs sicher konfigurieren.

Not set ist kein Ausschalter

Bei den globalen und portbezogenen QoS-Einstellungen bedeutet Not set, dass Sophos Fusion den Wert nicht vorgibt und der Switch seine lokale Konfiguration verwendet. Das gilt für Status, Scheduling method, portbezogenes CoS, Trust state, Bandbreitenlimits und Storm-Control-Werte. Ein sichtbares Not set beweist daher nicht, dass die Funktion inaktiv ist.

Soll Sophos Fusion einen Zustand verbindlich vorgeben, setzen Sie einen ausdrücklichen Wert und prüfen danach Configuration source. Halten Sie einen lokalen Wert fest, bevor Sie ihn überschreiben; sonst ist beim Rollback unklar, zu welchem Zustand Not set zurückführt.

Durchgängiger Musterfall

Das folgende Beispiel ist ein anpassbarer Testplan und kein Sophos-Default. Port 12 verbindet einen von der IT verwalteten Standort-Router mit dem Switch. Der Router normalisiert DSCP von Endgeräten nach einer separat getesteten Regel und markiert freigegebene Telefonie mit DSCP 46, übrigen Traffic mit DSCP 0; deshalb gilt er am Switch als vertrauenswürdige Quelle. Der priorisierte Strom verlässt den Switch über Uplink-Port 48. Auf Port 12 wurden eingehend 72 Mbit/s im Normalbetrieb, 84 Mbit/s als legitime Spitze und für Broadcast maximal 640 kbit/s gemessen. Ein vertraglich begrenzter 100-Mbit/s-Pfad soll vor grösseren Datenbursts geschützt werden, Telefonie soll bei einem Engpass am Uplink nutzbar bleiben und Broadcast soll Reserve erhalten.

Im Change-Protokoll erhalten die acht in der Oberfläche angezeigten Queues zur eindeutigen Referenz die lokalen Namen Q1 bis Q8. DSCP 46 wird auf Q7 («Sprache») abgebildet, DSCP 0 auf Q1 («Best Effort»). Als vorsichtiger erster WRR-Testplan erhält Q7 Gewicht 24, jede andere Queue Gewicht 8. Das ist nur ein relatives Verhältnis von 3:1 und weder eine Prozentangabe noch eine Bandbreitengarantie. Die Werte sind nicht allgemein empfehlbar: Sie dienen dazu, mit Gewichten grösser als 0 unter reproduzierbarer Konkurrenzlast zu beobachten, ob Sprache im vereinbarten Rahmen bleibt und alle benötigten Queues weiter bedient werden.

Für Port 12 setzt der Musterplan Ingress (kbps) auf 92400: gemessene Spitze 84'000 kbit/s plus ausdrücklich gewählte 10 Prozent Reserve ergeben 92'400 kbit/s; dieser Wert ist bereits durch 16 teilbar. Die Broadcast-Schwelle erhält 25 Prozent Reserve: 640 kbit/s × 1,25 = 800 kbit/s, ebenfalls ein zulässiges Vielfaches von 16. Die anderen Storm-Control-Klassen bleiben auf ihren dokumentierten Ausgangswerten. Diese Port-12-Werte dürfen nicht auf Uplink-Port 48 übertragen werden; dort treffen die Lasten mehrerer Geräte zusammen und erfordern eigene Messungen.

QoS global konfigurieren

Öffnen Sie QoS > General settings, um Verarbeitung, Scheduling und Markierungsquelle festzulegen.

1. Status und Scheduling method wählen

Unter Status stehen Enabled, Disabled und Not set zur Verfügung. Für einen zentral verwalteten QoS-Rollout Enabled wählen.

Die Scheduling method bestimmt, wie die acht Arbeitswarteschlangen bedient werden:

• Strict priority: Der Switch bedient immer zuerst die höher priorisierte Queue. Niedrigere Queues kommen erst zum Zug, wenn die höher priorisierten leer sind. Das ist für sehr zeitkritischen Traffic eindeutig, kann bei dauerhaft hoher Last in einer hohen Queue aber niedrigere Queues verdrängen.
• WRR: Weighted Round Robin verteilt Bandbreite gemäss Queue-Gewichten über die Queues. Für jede der acht Queues muss ein Queue weight zwischen 0 und 128 gesetzt werden; 128 ist die höchste Gewichtung. Die zitierte Sophos-Dokumentation erklärt jedoch nicht, ob 0 die Bedienung ausschaltet, nur minimiert oder je nach Modell beziehungsweise Firmware anders wirkt.
• Not set: Das lokal konfigurierte Scheduling-Verfahren bleibt wirksam.

Für ein gemischtes Unternehmensnetz ist WRR meist der kontrolliertere Startpunkt, weil die Bedienung der Queues über ihre Gewichte verteilt wird. Für jede benötigte Queue zunächst ein Gewicht grösser als 0 planen. 0 nur verwenden, wenn seine Wirkung auf dem eingesetzten Modell und Firmwarestand separat nachgewiesen wurde. Unter Konkurrenzlast muss der Test zeigen, dass jede benötigte Queue tatsächlich bedient wird. Strict Priority wird nur gewählt, wenn die hoch priorisierte Last begrenzt und das Risiko für die übrigen Queues getestet ist. Die Gewichte sind keine Bandbreite in kbit/s und keine Prozentwerte; sie werden relativ zueinander geplant. Im Musterfall tragen Sie für Q7 24 und für Q1–Q6 sowie Q8 jeweils 8 ein; passen Sie diesen ersten Testplan erst aufgrund der gemessenen Engpasswirkung an.

2. Trust mode festlegen

Unter Trust mode stehen drei Verfahren zur Verfügung:

• DSCP: Der Switch verwendet die Layer-3-Markierung im IP-Header.
• 802.1p: Der Switch verwendet die CoS-Markierung im VLAN-Tag.
• 802.1p-DSCP: Der Switch kann zwischen Layer-2- und Layer-3-QoS-Markierungen übersetzen, wenn Netzsegmente unterschiedliche Verfahren verwenden.

DSCP ist passend, wenn die Anwendungen beziehungsweise vertrauenswürdige Netzwerkkomponenten IP-Pakete konsistent markieren. 802.1p passt zu einem kontrollierten, VLAN-getaggten Layer-2-Design. 802.1p-DSCP wird nur eingesetzt, wenn die Übersetzung Teil des dokumentierten Ende-zu-Ende-Konzepts ist. Ein Trust-Modus korrigiert keine falschen oder missbräuchlichen Markierungen.

⚠️ Sophos dokumentiert das portbezogene Trust state ausschliesslich für die CoS-/802.1p-Markierung eingehender Pakete. Es ist kein portbezogener Schalter für das Vertrauen in DSCP dokumentiert. Untrusted darf deshalb nicht als Schutz vor einer vom Endgerät gesetzten DSCP-Markierung verstanden werden. DSCP nur vertrauen, wenn die Quelle vertrauenswürdig ist oder eine separat verifizierte Kontrolle die DSCP-Werte an der Quelle beziehungsweise vorgelagert erzwingt oder normalisiert. Fehlt eine solche Kontrolle, DSCP als nicht vertrauenswürdig behandeln und Trust mode: DSCP auf diesem Segment nicht einsetzen.

Im Musterfall ist Trust mode: DSCP nur deshalb zulässig, weil die IT den Router verwaltet und im Mitschnitt sowohl DSCP 46 als auch DSCP 0 geprüft hat. Wäre Port 12 ein frei zugänglicher Clientport ohne separat verifizierte DSCP-Durchsetzung oder -Normalisierung, dürfte dieser Testplan dort nicht ausgerollt werden.

Mit Update speichern.

CoS und DSCP auf Queues abbilden

Stellen Sie zuerst in einem Mitschnitt fest, welche Markierung tatsächlich ankommt. Wählen Sie dann die geplante Queue, speichern Sie das Mapping und prüfen Sie es unter Konkurrenzlast. Eine Markierung allein erzeugt noch keine bevorzugte Bedienung; dazu müssen Queue-Auswahl und Scheduling zusammenpassen.

CoS mapping

Unter CoS mapping weisen Sie jedem CoS-Wert von 0 bis 7 eine Traffic-Queue zu. Sophos ordnet den Werten typischerweise diese Traffic-Arten zu:

Die Tabelle beschreibt die dokumentierte typische Nutzung, aber keine Empfehlung für das eigene Netz. Verfolgen Sie die Werte Ihrer Telefone, Access Points oder Anwendungen im Mitschnitt, ordnen Sie nur die beobachteten Werte der geplanten Queue zu und speichern Sie mit Update. Der DSCP-Musterfall nutzt kein CoS-Mapping; bestehende CoS-Zuordnungen bleiben daher unverändert.

DSCP mapping

Unter DSCP mapping können Sie jeden DSCP-Wert einer Queue zuweisen. Die dokumentierten Wertebereiche sind:

Priorisieren Sie nur Werte, die Ihr Netz bewusst vergibt. Im Musterfall hat der Mitschnitt DSCP 46 vom verwalteten Router bestätigt; der Wert liegt im dokumentierten Bereich für Voice-Medien und wird auf die lokal als Q7 bezeichnete Queue abgebildet. DSCP 0 gelangt gemäss Testplan in Q1. Speichern Sie mit Update und verfolgen Sie beide Werte anschliessend bis zum Uplink-Port 48. In einer anderen Umgebung müssen Sie separat prüfen, welche Werte Endgerät, Telefonanlage, Firewall und WAN setzen und erhalten.

Nicht den gesamten Bereich einer hohen Kategorie allein aufgrund dieser Übersicht ungeprüft bevorzugen. Entscheidend sind die tatsächlich verwendeten Markierungen und die Vertrauenswürdigkeit ihrer Quelle.

Ports konfigurieren

Öffnen Sie QoS > Ports und bearbeiten Sie zuerst einen Testport. Hier setzen Sie CoS-Vertrauen, Bandbreite und Storm Control pro Port. Auf einem Uplink sieht der Switch alle dahinterliegenden Geräte zusammen; übernehmen Sie deshalb keinen Wert eines einzelnen Endgeräts als Uplink-Wert.

1. CoS und Trust state setzen

Ordnen Sie in der Tabelle CoS mapping die Portrolle diesen Feldern zu:

• CoS: Wert von 0 bis 7, entsprechend dem globalen CoS-Mapping;
• Trust state: Trusted: CoS-Markierung eingehender Pakete vertrauen;
• Trust state: Untrusted: CoS-Markierung eingehender Pakete nicht vertrauen;
• Not set: den jeweiligen lokalen Portwert verwenden;
• Configuration source: Herkunft der Portkonfiguration.

Ein Port zu einer kontrollierten Infrastrukturkomponente kann Trusted sein, wenn deren CoS-Markierungen geprüft und Bestandteil des Designs sind. Ein gewöhnlicher Benutzer- oder frei zugänglicher Edge-Port wird nicht allein deshalb vertraut, weil ein Endgerät hohe CoS-Werte senden kann. Wählen Sie dort Untrusted, setzen Sie den vorgesehenen CoS-Wert gemäss Portrolle, wählen Sie Update und prüfen Sie Configuration source. Trust state gilt nur für CoS/802.1p; bei DSCP gilt die zuvor beschriebene separate Vertrauensgrenze.

2. Bandwidth control setzen

Begrenzen Sie in der Tabelle Bandwidth control nur die Richtung, die laut Messung Schutz benötigt:

• Egress (kbps): maximale ausgehende Bandbreite;
• Ingress (kbps): maximale eingehende Bandbreite.

Beide Werte müssen ein Vielfaches von 16 sein und zwischen 16 und 10.000.000 kbit/s liegen. 0 schaltet die Bandbreitenkontrolle für die betreffende Richtung aus. Not set übernimmt den lokalen Wert.

Leiten Sie den Grenzwert aus einer Messung und nicht aus der Portgeschwindigkeit allein ab. Er muss oberhalb der normalen Last samt zulässiger Spitzen liegen, aber unterhalb der Kapazität, die geschützt werden soll. Runden Sie den gewünschten Wert auf ein zulässiges Vielfaches von 16. Für den Musterfall führt die gemessene Spitze von 84'000 kbit/s plus 10 Prozent Reserve zu Ingress (kbps): 92400; Egress (kbps) bleibt auf dem dokumentierten Ausgangswert. Diese Reserve ist eine bewusste Change-Entscheidung und kein Sophos-Richtwert.

Nur eine Richtung ändern, wenn auch nur diese begrenzt werden soll. Mit Update speichern, die Konfigurationsquelle kontrollieren und erst nach einem erfolgreichen Test weitere Ports bearbeiten.

3. Storm control setzen

Storm Control misst eingehende Frames pro Port getrennt und verwirft Frames der jeweiligen Klasse, sobald deren Rate den gesetzten Grenzwert überschreitet. Wählen Sie in der Tabelle nur die gemessene Klasse, die Sie begrenzen wollen:

• Broadcast (kbps) für Broadcast-Frames;
• Multicast (kbps) für unbekannte Multicast-Frames;
• Unicast für unbekannte Unicast-Frames; auch dieser Wert wird in kbit/s gesetzt.

Die verkürzten UI-Bezeichnungen Multicast und Unicast beziehen sich in der dokumentierten Wirkung auf unknown multicast und unknown unicast, nicht auf den gesamten bekannten Multicast- beziehungsweise Unicast-Traffic.

Jeder Wert muss ein Vielfaches von 16 sein und zwischen 16 und 10.000.000 liegen. 0 schaltet Storm Control für die betreffende Frame-Klasse aus; Not set verwendet die lokale Konfiguration. Die Eingabe ist eine Datenrate in kbit/s und keine Paketanzahl, auch wenn Storm Control Frames zählt beziehungsweise klassifiziert.

So wählen Sie die Schwelle:

1. Normale und kurzzeitige Spitzen pro Port und Frame-Klasse messen.
2. Pro Klasse einen Wert oberhalb legitimer Spitzen festlegen.
3. Auf ein zulässiges Vielfaches von 16 setzen.
4. Zuerst einen Edge-Testport ändern und mit Update speichern.
5. Namensauflösung, DHCP, Geräteerkennung und bewusst verwendeten Multicast-Traffic erneut testen.
6. Uplinks erst nach einer separaten Messung und mit ausreichender Reserve konfigurieren.

Im Musterfall setzen Sie nur Broadcast (kbps) auf 800: Die gemessene Spitze von 640 kbit/s plus 25 Prozent Reserve ergibt bereits ein Vielfaches von 16. Multicast (kbps) und Unicast behalten ihre dokumentierten Ausgangswerte. Ein pauschaler, niedriger Wert für alle Ports ist kein sicherer Standard. Broadcasts für ARP oder DHCP und Multicast für Discovery- oder Medienanwendungen können legitim sein. Auf einem Uplink ist deren Summe typischerweise höher als auf einem einzelnen Clientport.

Eine QoS-Policy nur bei Bedarf hinzufügen

Unter QoS > Policies lassen sich Protokoll-basierte Policies auf Ports oder VLANs anwenden. Die globale Markierung und das Portverhalten reichen aus, wenn Traffic bereits zuverlässig klassifiziert ist. Im Musterfall ist deshalb keine Policy nötig: Der verwaltete Router liefert überprüftes DSCP 46 beziehungsweise 0, und das DSCP-Mapping trennt beide Ströme bereits. Ergänzen Sie eine Policy nur, wenn die Klassifizierung anhand der in Sophos Fusion angebotenen Merkmale genauer erfolgen muss.

Wenn das Mapping nicht genügt, öffnen Sie Add policy und füllen nur die benötigten Bereiche aus:

• Class name als eindeutiger Policyname;
• Ports binding für die Ports, auf denen die Policy gilt;
• MAC address für Quell- und Ziel-MAC-Adressen;
• IP address für Quell- und Ziel-IP-Adressen;
• VLAN und VLAN-Priorität;
• Service mit Ethertype und Service Type;
• Protocol aus der Auswahlliste oder Custom für einen definierten IANA-IP-Protokollwert;
• Action und der von der Aktion zugewiesene Wert.

Ethertype bezeichnet das Protokoll in der Nutzlast eines Ethernet-Frames. Service type verwendet DSCP-Werte zur Identifikation des Traffics. Setzen Sie nur Kriterien, die der freigegebene Traffic tatsächlich erfüllt, und binden Sie die Policy an die vorgesehenen Ports oder das vorgesehene VLAN. Prüfen Sie die in der Oberfläche angebotene Action samt Wert gegen den QoS-Plan; übertragen Sie keine nicht dokumentierte Aktion aus einer anderen Sophos-Produktoberfläche.

Mit Save speichern. Danach in der Policyübersicht Ports binding, Binding source, Match-Kriterien, Action und Configuration source gegen den Plan prüfen. Zum Ändern den Class name öffnen und erneut Save wählen. Zum Entfernen die Policy markieren und Delete policy wählen.

Wirkung validieren

Eine gespeicherte Konfiguration ist noch kein Funktionsnachweis. Kontrollieren Sie zuerst die gespeicherten Werte, danach Markierungen und Queue-Zuordnung, anschliessend das Verhalten unter Engpass und zuletzt Limits sowie Storm Control.

1. Konfiguration kontrollieren

• Status, Scheduling method, alle acht WRR-Gewichte und Trust mode entsprechen dem Change-Plan; jede benötigte Queue hat entweder ein Gewicht grösser als 0 oder den zuvor geforderten modell- und firmwarebezogenen Nachweis.
• CoS- und DSCP-Werte zeigen auf die vorgesehenen Queues.
• Pro Port stimmen CoS, Trust state, Ingress-/Egress-Limit und alle drei Storm-Control-Werte.
• Configuration source zeigt die erwartete zentrale oder lokale Herkunft.
• Bei Policies stimmen Bindung, Match-Kriterien, Aktion und Konfigurationsquelle.
• Nach der Synchronisation die Ansicht neu laden und kontrollieren, dass keine alten Werte angezeigt werden.

2. Markierung und Queue-Zuordnung prüfen

An einem Testport einen Paketmitschnitt an einer geeigneten Messstelle durchführen und kontrollieren, ob die erwartete VLAN-CoS- beziehungsweise IP-DSCP-Markierung vorhanden ist. Danach mit genau diesem Wert das konfigurierte Mapping vergleichen. Fehlt die Markierung schon an der Quelle, kann das Queue-Mapping sie nicht wie geplant klassifizieren. Bei Untrusted Ports darf man nicht voraussetzen, dass eine vom Endgerät gesetzte CoS-Markierung wirksam bleibt.

Für ein DSCP-Design zusätzlich von einem nicht vertrauenswürdigen Testendgerät absichtlich einen hohen DSCP-Wert senden. Im Musterfall steht dieses Endgerät hinter dem Standort-Router. Mit Paketmitschnitt vor und nach dessen Normalisierung sowie mit kontrolliertem Engpasstest prüfen, ob der unerlaubte Wert trotzdem die darauf abgebildete hohe Queue erreicht. Bricht die separat vorgesehene Durchsetzung oder Normalisierung diesen Versuch nicht wie geplant ab, Trust mode: DSCP auf dem Segment nicht ausrollen.

3. QoS unter kontrollierter Last testen

Zuerst Latenz, Jitter, Verlust und Durchsatz ohne Konkurrenzlast erfassen. Danach auf dem betroffenen Ausgangspfad kontrolliert Best-Effort-Last erzeugen und dieselben Messwerte für den priorisierten Datenstrom wiederholen. Im Musterfall müssen die Mitschnitte DSCP 46 und DSCP 0 bis zum Uplink-Port 48 zeigen; die gespeicherte Konfiguration muss diese Werte Q7 beziehungsweise Q1 zuordnen. Erst der Engpasstest zeigt, ob die Telefonie mit Q7-Gewicht 24 im vereinbarten Rahmen bleibt und Q1 sowie alle weiteren benötigten Queues mit Gewicht 8 weiterhin bedient werden. Ohne tatsächlichen Engpass bestätigt ein unveränderter Ping die Priorisierung nicht.

4. Limits und Storm Control testen

Für Bandwidth control jeweils nur eine Richtung belasten. Im Musterfall muss die Portansicht zunächst Ingress (kbps): 92400 mit der erwarteten Configuration source zeigen. Beim anschliessenden Ingress-Test darf der gemessene Nutzdatendurchsatz das konfigurierte Portlimit nicht überschreiten; Protokoll-Overhead und Messmethode können dazu führen, dass der sichtbare Anwendungsdurchsatz etwas darunterliegt.

Storm Control nicht durch einen unkontrollierten Sturm im Produktionsnetz testen. Eine begrenzte, isolierte Lastprobe verwenden, die normale Dienste nicht gefährdet. Im Musterfall belegt die gespeicherte Schwelle 800 kbit/s allein noch keine Schutzwirkung: Normale Broadcast-Spitzen bis zum gemessenen Bereich müssen ohne Dienststörung funktionieren, die isolierte Probe oberhalb der Schwelle muss dagegen eine Begrenzung erkennen lassen. Prüfen Sie vor und nach der Änderung mindestens ARP, DHCP, DNS, benötigte Discovery-Protokolle und produktiv verwendeten Multicast. Wenn die Oberfläche des eingesetzten Modells passende Port- oder Drop-Zähler anbietet, deren Veränderung ergänzend dokumentieren; ein solcher Zähler wird hier nicht als überall vorhandenes Pflichtfeld vorausgesetzt.

Betrieb und Lifecycle

Prüfen Sie QoS beim betrieblich festgelegten Netzwerk-Review sowie nach Firmware-, Topologie- oder Anwendungsänderungen. Neue Telefone, Access Points, Uplinks und VLANs können Markierungen, Auslastung und legitime Broadcast- oder Multicast-Spitzen verändern; solche Ereignisse sind aussagekräftigere Auslöser als eine pauschale Kalenderfrist.

Halten Sie für spätere Anpassungen mindestens fest:

• verwendete CoS- und DSCP-Werte, Queue-Zuordnung, Scheduling-Verfahren und WRR-Gewichte;
• CoS-Trust: Trusted Ports und die kontrollierte Markierungsquelle;
• DSCP-Trust: Segmente und separat verifizierte Durchsetzung oder Normalisierung;
• Messbasis und Reserve hinter jedem Bandbreiten- und Storm-Control-Wert;
• Policies mit fachlichem Owner, Match, Bindung, Aktion und geplantem Entfernungszeitpunkt;
• Messwerte aus Normalbetrieb und kontrolliertem Engpasstest sowie Datum der letzten Prüfung;
• lokale Abweichungen und die jeweilige Configuration source.

Lesen Sie nach einem Firmwareupdate oder Austausch Konfiguration und Configuration source erneut. Wiederholen Sie den markierten Testfluss und jene Positiv- und Engpasstests, deren Funktion die Änderung berührt. Entfernen Sie nicht mehr verwendete Policies oder Trust-Ausnahmen kontrolliert und ändern Sie Limits nur aufgrund neuer Messwerte.

Typische Fehlerbilder

Sprache oder Video wird trotz QoS nicht bevorzugt

1. Prüfen, ob Status wirklich Enabled ist oder Not set einen unerwarteten lokalen Zustand übernimmt.
2. Mit einem Mitschnitt kontrollieren, ob CoS beziehungsweise DSCP tatsächlich am Switch ankommt.
3. Bei CoS/802.1p den Trust mode und das portbezogene Trust state mit der Markierungsquelle vergleichen.
4. Bei DSCP den globalen Trust mode sowie die separat verifizierte Durchsetzung oder Normalisierung prüfen.
5. Den beobachteten Wert im CoS mapping beziehungsweise DSCP mapping nachverfolgen.
6. Scheduling method und bei WRR alle acht Gewichte prüfen.
7. Sicherstellen, dass der Lasttest wirklich denselben Ausgangsport überlastet. QoS auf diesem Switch behebt keinen Engpass an einer anderen Stelle des Pfads.

Niedrig priorisierter Traffic bricht vollständig ein

Bei Strict priority prüfen, ob eine höhere Queue dauerhaft ausgelastet ist. Falls ja, die Ursache der hohen Last beseitigen oder im Wartungsfenster auf ein geplantes WRR-Verfahren wechseln. Bei WRR alle acht Gewichte mit dem Plan vergleichen, 0 für eine benötigte Queue ohne den zuvor geforderten Nachweis ersetzen und danach den Konkurrenztest für jede benötigte Queue wiederholen.

Durchsatz ist unerwartet niedrig

• Ingress (kbps) und Egress (kbps) auf vertauschte Richtung prüfen.
• Kontrollieren, ob der Wert ein bewusstes Vielfaches von 16 und nicht versehentlich in Mbit/s statt kbit/s eingegeben wurde.
• Bei Not set den lokalen Wert und Configuration source untersuchen.
• Bandbreitenlimit vorübergehend auf den dokumentierten Ausgangswert zurücksetzen und denselben Test wiederholen.
• Wenn nur eine Traffic-Klasse betroffen ist, zusätzlich Policy, Mapping und Scheduling statt allein das Portlimit prüfen.

DHCP, ARP oder Discovery fällt nach Storm Control sporadisch aus

Der Grenzwert für Broadcast, Multicast oder Unicast liegt wahrscheinlich unter einer legitimen Spitze. Betroffene Klasse auf den vorherigen Wert zurücksetzen, normale Dienste erneut testen und die tatsächliche Spitzenrate messen. Auf Uplinks berücksichtigen, dass der Port den aggregierten Traffic mehrerer Geräte sieht. Nicht gleichzeitig alle drei Schwellen erhöhen; sonst bleibt unklar, welche Klasse die Störung verursacht hat.

Eine Policy trifft nicht oder erfasst zu viel Traffic

• Ports binding und Binding source gegen den tatsächlichen Eingangsport beziehungsweise das VLAN prüfen.
• Quell- und Zielrichtung bei MAC- und IP-Adressen kontrollieren.
• VLAN-ID, VLAN-Priorität, Ethertype, DSCP-Service-Type und Protokollwert einzeln mit einem Mitschnitt vergleichen.
• Bei Custom sicherstellen, dass der eingetragene Wert wirklich die beabsichtigte IANA-IP-Protokollnummer ist.
• Policyaktion und zugewiesenen Wert in der Übersicht kontrollieren.
• Kriterien schrittweise auf den freigegebenen Match zurückführen und nach jeder Änderung erneut testen.

Sophos Fusion zeigt Werte, das Verhalten passt aber nicht dazu

Zuerst Synchronisationszustand und Ziel-Switch prüfen. Danach Configuration source lesen und alle Not set-Werte gegen die lokale Konfiguration vergleichen. Nicht wiederholt dieselben Central-Werte speichern, ohne den wirksamen lokalen Zustand zu erfassen. Bei einer Policy zusätzlich Binding source kontrollieren.

Rollback

Arbeiten Sie beim Rückbau die Änderung in umgekehrter Reihenfolge ab und verwenden Sie die vor dem Change dokumentierten Werte. Not set, 0 und Disabled haben unterschiedliche Bedeutungen und dürfen nicht als Synonyme verwendet werden.

1. Eine neu hinzugefügte Policy unter Policies markieren und Delete policy wählen. Wurde eine bestehende Policy geändert, ihre dokumentierten Match-, Bindungs- und Aktionswerte wiederherstellen und mit Save sichern.
2. Unter Ports > Storm control nur die geänderten Klassen auf den vorherigen Wert zurücksetzen. 0 schaltet die betreffende Kontrolle aus; Not set überlässt sie der lokalen Konfiguration.
3. Unter Ports > Bandwidth control geänderte Ingress (kbps)- und Egress (kbps)-Werte wiederherstellen. Auch hier bedeutet 0 ausgeschaltet, Not set lokal verwaltet.
4. Portbezogenes CoS und Trust state auf die Ausgangswerte zurücksetzen.
5. Globale CoS- und DSCP-Mappings, Trust mode, Scheduling method und alle Queue-Gewichte vollständig wiederherstellen.
6. Status auf den vorherigen Wert setzen: Disabled schaltet zentral aus; Not set aktiviert nicht automatisch den vorherigen Central-Zustand, sondern gibt die Entscheidung an die lokale Konfiguration zurück.
7. Jede Ansicht mit Update beziehungsweise die Policy mit Save sichern und die Synchronisation abwarten.
8. Den ursprünglichen Positivtest für Management, normale Anwendungen, Sprache/Video, DHCP, DNS und benötigten Multicast wiederholen.

Wenn ein Portlimit oder Storm Control den Managementzugang beeinträchtigt, versuchen Sie keine weiteren Änderungen über denselben instabilen Pfad. Verwenden Sie den vorbereiteten unabhängigen Zugang und setzen Sie zuerst nur den zuletzt geänderten Portwert zurück. Lesen Sie zum Abschluss Configuration source einmal für alle zurückgebauten Werte: Der Rückbau ist erfolgreich, wenn Konfiguration und Quelle dem dokumentierten Ziel entsprechen und Normalbetrieb sowie kontrollierter Lasttest wieder nachvollziehbare Ergebnisse liefern.