Bandbreitenlimit pro Port: Cisco Switch Konfiguration

Ein Bandbreitenlimit pro Port auf einem Cisco Switch ist eine der praktischsten Maßnahmen, um ein Campus-Netz stabil zu halten: Ein einzelner Client, ein falsch konfigurierter Server oder ein „hungriger“ Backup-Job kann sonst sehr schnell einen Uplink, ein VLAN oder ganze Access-Segmente ausbremsen. Mit einer Port-basierten Begrenzung (Rate Limiting) legen Sie fest, wie viel Datenverkehr ein einzelner Switchport maximal senden oder empfangen darf. Das hilft nicht nur bei der Fairness zwischen vielen Endgeräten, sondern auch bei der Fehlersuche, beim Schutz vor Fehlkonfigurationen und beim Einhalten organisatorischer Regeln (z. B. „Gäste maximal 20 Mbit/s“). Wichtig ist dabei: Cisco Switches bieten je nach Plattform und IOS/IOS XE-Version verschiedene Wege, Bandbreite pro Port zu begrenzen. Manche Modelle nutzen klassische Befehle wie rate-limit, viele moderne Umgebungen setzen auf QoS-Mechanismen mit Policern (Ingress) oder auf egressseitige Queue-/Scheduler-Limits. Dieser Leitfaden zeigt Ihnen die gängigen Methoden, erklärt die Unterschiede zwischen Ingress- und Egress-Limit, gibt praxistaugliche Konfigurationsbeispiele und beschreibt Best Practices, damit die Begrenzung wirksam ist, ohne Anwendungen unnötig zu beschädigen.

Warum Bandbreitenlimit pro Port sinnvoll ist

• Schutz vor „Noisy Neighbors“: Ein Gerät darf nicht die gesamte verfügbare Kapazität beanspruchen.
• Stabile Uplinks: Backups, Cloud-Sync oder große Downloads werden gedrosselt, bevor sie Trunks/Uplinks überlasten.
• Planbare Servicequalität: Kritische Dienste (z. B. VoIP, Videokonferenzen) leiden weniger, wenn Bulk-Traffic pro Port begrenzt wird.
• Segment-spezifische Regeln: Gäste, IoT oder Labore können bewusst „kleiner“ gehalten werden als Office-Clients.
• Fehlkonfigurationen abfangen: Ein falsch gesetztes Duplex/Speed oder ein defekter Treiber führt weniger schnell zu Netzproblemen.

Ingress vs. Egress: In welche Richtung begrenzen Sie?

Bevor Sie einen Befehl tippen, sollten Sie die Richtung verstehen. Auf Switchports gibt es grundsätzlich zwei Stellen, an denen Sie eingreifen können:

• Ingress (Input): Begrenzung dessen, was am Port ankommt (vom Endgerät zum Switch). Das ist häufig ein Policer, der bei Überschreitung verwirft oder ummarkiert.
• Egress (Output): Begrenzung dessen, was am Port hinausgeht (vom Switch zum Endgerät). Das erfolgt je nach Plattform über Scheduler-/Queue-Limits, Shaping oder spezielle Interface-Kommandos.

Praxisregel: Wenn Sie verhindern möchten, dass ein Client das Netz „flutet“, ist Ingress-Limit oft die relevanteste Maßnahme. Wenn Sie z. B. Gäste drosseln möchten, damit sie nur eine definierte Downloadrate bekommen, ist Egress-Limit häufig wichtiger, weil der Download vom Switch zum Client läuft.

Plattformrealität: Cisco Switch ist nicht gleich Cisco Switch

Die konkrete Syntax hängt stark von Modell und Software ab (Catalyst IOS, Catalyst IOS XE, Catalyst 9000, ältere 2960/3560/3750, usw.). Zwei Konsequenzen sind in der Praxis wichtig:

• Kommandos unterscheiden sich: Manche Geräte unterstützen MQC auf Switchports, andere nur bestimmte Policers oder legacy Rate-Limits.
• Hardware-Implementierung zählt: Viele Limits werden in Hardware (ASIC/TCAM) umgesetzt, was Verhalten und Granularität beeinflusst.

Wenn Sie Ihre genaue Plattform nachschlagen möchten, sind diese Einstiege hilfreich: Cisco Catalyst 9000 Dokumentation und die Cisco IOS Command Reference. Für QoS-/Policing-Grundlagen bietet sich außerdem die Cisco QoS Konfigurationsübersicht an.

Methode 1: Ingress-Policing per Policy Map (MQC) auf dem Switchport

In vielen Cisco-Umgebungen ist der sauberste Ansatz für ein Bandbreitenlimit pro Port ein Ingress-Policer über MQC: Sie klassifizieren den Traffic (oft einfach „alles“) und begrenzen dann die Rate. Vorteil: Das Modell ist klar, dokumentierbar und lässt sich kontrolliert an viele Ports ausrollen. Nachteil: Nicht jede Switchplattform unterstützt MQC-Policies auf Layer-2-Access-Ports in gleicher Form.

Beispiel: Ingress-Limit auf 20 Mbit/s (alles am Port)

configure terminal
class-map match-any LIMIT-ALL
match any
policy-map POLICE-20M-IN
class LIMIT-ALL
police 20000000 conform-action transmit exceed-action drop
end

Dann auf dem Interface anwenden:

configure terminal
interface GigabitEthernet1/0/10
description Client-Port mit 20M Ingress-Limit
service-policy input POLICE-20M-IN
end

Hinweis: Die Einheit der Police-Rate ist je nach Plattform bps (Bits pro Sekunde). In der Praxis lohnt sich ein Sicherheitszuschlag bzw. eine klare Dokumentation, ob Sie brutto/netto rechnen, da Protokolloverhead nicht immer intuitiv ist.

Varianten: Überschreitung droppen oder remarken

Ein reines Drop-Policing ist die härteste Form. In manchen Designs ist es sinnvoll, Überschreitungen nicht zu droppen, sondern „abzuwerten“, damit sie in einer niedrigeren QoS-Klasse landen:

policy-map POLICE-20M-IN
class LIMIT-ALL
police 20000000
conform-action transmit
exceed-action set-dscp-transmit default

Ob set-dscp-transmit oder ähnliche Optionen verfügbar sind, ist plattformabhängig. Der Grundgedanke bleibt: Drop ist strikt, Remarking ist „sanfter“, setzt aber voraus, dass Ihr Netz QoS-Ende-zu-Ende konsistent behandelt.

Methode 2: Legacy Rate-Limit auf dem Interface

Auf älteren Plattformen oder in bestimmten IOS-Varianten existieren klassische Interface-Befehle für Rate Limiting (häufig als rate-limit bekannt). Das ist pragmatisch, aber weniger flexibel als MQC. Außerdem ist die Syntax je Plattform unterschiedlich, und die Granularität kann eingeschränkt sein.

Beispiel (generisches Muster, plattformabhängig)

configure terminal
interface GigabitEthernet1/0/12
description Legacy Rate-Limit Beispiel
rate-limit input 20000000 8000 8000 conform-action transmit exceed-action drop
end

Da die Parameter (Burst, Units) stark variieren können, ist hier besonders wichtig, die Kommandoreferenz Ihrer konkreten Switchplattform zu nutzen. Nutzen Sie dafür den Anchor-Text Cisco IOS Command Reference.

Methode 3: Egress-Begrenzung über Queue-/Scheduler-Limits

Egress-Limits sind auf Switches oft weniger einheitlich als Ingress-Policing, weil die Ausgabe in Hardware-Queues und Scheduler-Mechanismen umgesetzt wird. Viele Catalyst-Plattformen bieten Befehle, die eine Port-Ausgaberate als Prozent der Portgeschwindigkeit begrenzen oder Queue-Bandbreiten steuern. Das ist besonders relevant, wenn Sie Downloadraten pro Endgerät drosseln möchten.

Wann Egress-Limit sinnvoller ist als Ingress

• Gäste drosseln: Der typische „schwere“ Traffic ist der Download vom Internet zum Client (Egress am Client-Port).
• Broadcast-/Multicast-Last: Wenn Endgeräte von bestimmten Traffic-Arten „überschwemmt“ werden, kann Egress-Steuerung helfen.
• Uplink-Schonung: Je nach Design kann Egress-Limiting an kritischen Ports verhindern, dass ein Zielsystem überfahren wird.

Da die konkrete Syntax stark plattformabhängig ist, sollten Sie hier bewusst im jeweiligen QoS-/Switch-Guide nachschlagen. Als Einstieg ist der Anchor-Text Cisco QoS Konfigurationsübersicht hilfreich, weil dort die Dokumente nach Switchfamilie aufgeteilt sind.

Praxisbeispiele: Bandbreitenlimit pro Port für typische Szenarien

Beispiel A: Gastport auf 10 Mbit/s begrenzen

• Ziel: Gäste sollen das Netz nicht dominieren, aber normal surfen können.
• Technik: Häufig Egress-Limit für Download + optional Ingress-Limit für Upload.

Pragmatischer Ansatz (Ingress-Policing als Mindestmaßnahme):

class-map match-any LIMIT-ALL
match any
policy-map POLICE-10M-IN
class LIMIT-ALL
police 10000000 conform-action transmit exceed-action drop

interface GigabitEthernet1/0/20
description Guest-Port
service-policy input POLICE-10M-IN

Wenn der Download die Hauptlast ist, ergänzen Sie (plattformabhängig) ein Egress-Limit, um die Nutzererfahrung planbarer zu machen.

Beispiel B: Backup-Server-Port „zähmen“ (nachts schnell, tagsüber begrenzt)

• Ziel: Tagsüber soll Backup-Traffic nicht den Betrieb stören.
• Technik: Ingress-Policing am Backup-Server-Port (Upload ins Netz) und/oder QoS-Klassifizierung als Scavenger.

In vielen Umgebungen ist es besser, Backup nicht hart zu droppen, sondern in eine niedrigere QoS-Klasse zu verschieben. Wenn Sie dennoch ein Limit setzen müssen, verwenden Sie ein moderates Policing und planen Sie Wartungsfenster über Zeitsteuerung (plattformabhängig) oder über separate Policies.

Beispiel C: IoT-Port begrenzen, um „Sturm“ einzudämmen

• Ziel: IoT-Geräte sollen nie so viel Traffic erzeugen, dass das Segment instabil wird.
• Technik: Ingress-Policing, zusätzlich Security-Mechanismen (z. B. DHCP Snooping, DAI) je nach Umfeld.

Hier ist ein striktes Drop-Policing oft akzeptabel, weil IoT-Workloads meist geringe Bandbreite benötigen und ein Überschreiten eher auf Fehlverhalten hindeutet.

Bandbreitenlimit und QoS: Wie beides zusammenspielt

Ein Port-Limit ist eine Form von QoS, aber es ist nicht dasselbe wie ein Klassenmodell mit Priorisierung. Zwei typische Interaktionen:

• Port-Limit ohne Klassen: Alles wird gleich begrenzt. Gut für Fairness, aber Voice/Video profitieren nicht automatisch.
• Port-Limit plus Klassen: Innerhalb der begrenzten Rate werden wichtige Klassen bevorzugt (z. B. Voice in LLQ, Daten als Best Effort). Das ist oft die beste Kombination, wenn ein Port sowohl Echtzeit- als auch Bulk-Traffic führen kann.

Wenn Sie VoIP am selben Access-Port wie einen PC betreiben (Telefon + PC), ist ein reines Bandbreitenlimit möglicherweise nicht optimal. Hier ist ein QoS-Design mit Trust Boundary und Priorisierung oft wichtiger als ein reiner Deckel, damit Latenz und Jitter niedrig bleiben.

Best Practices: Bandbreitenlimit pro Port sauber und betriebssicher umsetzen

• Richtung bewusst wählen: Ingress schützt das Netz vor dem Endgerät, Egress steuert die Versorgung des Endgeräts (z. B. Download).
• Schrittweise ausrollen: Erst auf wenige Ports testen, dann in Gruppen (z. B. über Interface-Ranges) ausrollen.
• Realistische Raten: Zu niedrige Limits erzeugen „mysteriöse“ Anwendungsprobleme; zu hohe Limits bringen keinen Nutzen.
• Bursts beachten: Viele Protokolle senden in Bursts; zu harte Limits können unnötig droppen. Wo möglich, Burst-Parameter sinnvoll wählen.
• Dokumentation: Portbeschreibung und Policy-Namen sprechend halten (z. B. POLICE-20M-IN).
• Keine Überraschungen für kritische Ports: Uplinks, Serverports für Echtzeitdienste, Storage-Links und Cluster-Verbindungen nur mit klarer Absicht limitieren.
• Ende-zu-Ende denken: Ein Port-Limit löst keinen Engpass im WAN, wenn der Flaschenhals woanders liegt.

Verifikation: So prüfen Sie, ob das Bandbreitenlimit wirklich greift

Nach der Konfiguration sollten Sie nicht raten, sondern messen. Je nach eingesetzter Methode nutzen Sie unterschiedliche Befehle.

MQC/Policer prüfen (typisch auf Routern und vielen L3-fähigen Plattformen)

• show policy-map interface GigabitEthernet1/0/10 (Treffer, Drops, Polize-Statistik)
• show policy-map und show class-map (Definitionen)

Interface-Statistiken prüfen

• show interfaces GigabitEthernet1/0/10 (Rate, Drops, Errors)
• show interfaces counters errors (plattformabhängig)

Interpretation:

• Wenn Counters in der Policy steigen, matcht die Klassifizierung.
• Wenn Drops steigen, ist das Limit aktiv und wird überschritten (oder das Burst-Verhalten passt nicht).
• Wenn nichts steigt, ist die Policy nicht gebunden oder der Traffic läuft anders (z. B. anderes Interface, LAG/EtherChannel).

Troubleshooting: Typische Gründe, warum das Limit nicht wirkt

• Falsche Richtung: Sie limitieren Ingress, aber Sie wollten Download (Egress) begrenzen.
• Policy nicht gebunden: Konfig existiert, aber service-policy fehlt am Interface.
• EtherChannel: Port ist Mitglied eines Port-Channels, die Policy muss ggf. am Port-Channel oder an den Member-Ports passend angewendet werden (plattformabhängig).
• Marking/Trust: Wenn Sie innerhalb eines Limits priorisieren wollen, aber Markierungen nicht stimmen, wirkt QoS „zufällig“.
• Engpass ist woanders: Der Link ist nicht der Flaschenhals, daher sehen Sie keine sichtbare Wirkung.
• Plattformlimits: Bestimmte QoS/Policer-Funktionen sind auf dem Modell nicht verfügbar oder verhalten sich anders als erwartet.

Saubere Port-Gruppen: Bandbreitenlimits effizient ausrollen

In der Praxis wollen Sie selten nur einen einzelnen Port limitieren. Typische Gruppen sind „Gästeports“, „IoT-Ports“, „Studentenlabor“, „Drucker“ oder „Unmanaged Devices“. Ein wartbarer Ansatz ist:

• Pro Gruppe eine klar benannte Policy (z. B. POLICE-10M-IN, POLICE-20M-IN).
• Interface-Descriptions, die Zweck und Limit enthalten.
• Ausrollen über Interface-Ranges (vorsichtig, mit Pilotports).

Beispiel: Policy auf mehrere Ports anwenden

configure terminal
interface range GigabitEthernet1/0/20 - 24
description Guest-Ports mit 10M Ingress-Limit
service-policy input POLICE-10M-IN
end

Checkliste: Bandbreitenlimit pro Port auf Cisco Switch korrekt umsetzen

• Ist klar, ob Ingress oder Egress begrenzt werden soll (Upload vs. Download)?
• Ist die Plattform bekannt und sind die passenden QoS/Rate-Limit-Features verfügbar?
• Wurde ein realistisches Limit gewählt (inkl. Burst-Verhalten und Overhead)?
• Ist die Policy korrekt am Interface gebunden (oder am Port-Channel, falls relevant)?
• Wurde die Wirkung verifiziert (Counters, Drops, Interface-Statistiken)?
• Sind kritische Ports (Uplinks, Echtzeitdienste, Storage) bewusst ausgenommen oder passend priorisiert?
• Ist die Konfiguration dokumentiert (Descriptions, sprechende Policy-Namen, Change-Prozess)?

Für die vertiefende, modellbezogene Umsetzung (Catalyst-Serie, IOS/IOS XE-Version) sind der Anchor-Text Cisco QoS Konfigurationsübersicht sowie die Cisco IOS Command Reference die besten Ausgangspunkte, um die exakt unterstützten Befehle für Ihre Hardware nachzuschlagen.

copy running-config startup-config

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.