Übersicht über den Schutz vor verteilten Denial-of-Service-Angriffen (DDoS) auf der Steuerungsebene

Host-gebundene Datenverkehrsüberwachungssysteme bei DDoS-Verstößen

Zum Schutz der Steuerungsebene vor DDoS-Angriffen sind auf Geräten standardmäßig Policer für den Datenverkehr in Richtung Host aktiviert. Bei Bedarf können Sie viele policer-Standardwerte ändern. Hostgebundener Datenverkehr ist Datenverkehr, der für die Routing-Engine bestimmt ist, einschließlich Protokollsteuerpaketen für Routingprotokolle wie OSPF und BGP. Datenverkehr, der für Router-IP-Adressen bestimmt ist, wird ebenfalls als hostgebundener Datenverkehr betrachtet.

Die Policer legen Ratenlimits für den gesamten Steuerdatenverkehr für ein bestimmtes Protokoll oder in einigen Fällen für bestimmte Steuerpakettypen für ein Protokoll fest. Sie können Policeraktionen für Pakettypen und Protokollgruppen auf der Ebene des Geräts, der Routing-Engine und der Linecards überwachen. Sie können auch die Protokollierung von Policer-Ereignissen steuern.

Geräte unterbrechen den Steuerdatenverkehr, wenn er die Standardwerte oder konfigurierten Policer-Werte überschreitet. Wenn ein DDoS-Verstoß auftritt, stoppt das Gerät die Verarbeitung von Paketen nicht. Es begrenzt nur ihre Rate. Jeder Verstoß generiert sofort eine Benachrichtigung, um die Betreiber vor einem möglichen Angriff zu warnen. Das Gerät zählt den Verstoß und notiert den Zeitpunkt, zu dem der Verstoß beginnt, und den Zeitpunkt des zuletzt beobachteten Verstoßes. Wenn die Datenverkehrsrate unter den Schwellenwert für die Bandbreitenverletzung fällt, bestimmt ein Wiederherstellungs-Timer, wann der Datenverkehrsfluss als wieder normal angesehen wird. Wenn vor Ablauf des Timers keine weitere Verletzung auftritt, löscht das Gerät den Verstoßstatus und generiert eine Benachrichtigung.

Anmerkung:

Bei PTX-Routern und Switches der QFX-Serie ist der Timer auf 300 Sekunden eingestellt und kann nicht geändert werden.

Die erste Schutzlinie ist der Policer der Packet Forwarding Engine (PFE). Auf Geräten mit mehreren Linecards werden Policerstatus und Statistiken von jeder Linecard an die Routing-Engine weitergeleitet und aggregiert. Die Policer-Zustände werden während eines Switchovers beibehalten. Obwohl Linecard-Statistiken und die Anzahl der Verstöße während eines Switchovers beibehalten werden, sind dies bei den Routing-Engine-Policerstatistiken nicht der Fall. Der gesteuerte Datenverkehr, der von allen Ports der Linecard ankommt, läuft in der Packet Forwarding Engine zusammen, wo er überwacht wird. Überschüssige Pakete werden verworfen, bevor sie die Routing-Engine erreichen, und sichergestellt, dass die Routing-Engine nur so viel Datenverkehr erhält, wie sie verarbeiten kann.

Router der ACX-Serie, die diese Funktion unterstützen, unterstützen nur aggregierte Policer und keine Überwachung auf Linecard-Ebene. Sie können die Standardwerte des Policers auf der Ebene der Routing-Engine global oder für bestimmte Protokollgruppen ändern, was bis auf die PFE-Chipsatzebene weitergegeben wird. Sie können jedoch keine zusätzlichen Skalierungsparameter auf Linecard-Ebene anwenden, wie dies bei anderen Geräten der Fall ist. Sie können die Überwachung auf Routing-Engine-Ebene global oder für bestimmte Protokollgruppen deaktivieren. Durch das globale Deaktivieren der Überwachung wird der DDoS-Schutz der Steuerungsebene auf dem Gerät deaktiviert.

Switches und PTX-Serie-Router der QFX10000-Serie setzen DDoS-Schutzlimits auf drei Ebenen durch: im PFE-Chipsatz, in der Linecard und im Routing-Engine.

Der DDoS-Schutz der Steuerungsebene ermöglicht nicht nur die Benachrichtigung über Verstöße durch Ereignisprotokollierung, sondern ermöglicht auch die Überwachung von Policern und das Abrufen von Informationen wie der Konfiguration des Polizeiteams, der Anzahl der aufgetretenen Verstöße, Datum und Uhrzeit von Verstößen, der Paketankunftsrate und der Anzahl der empfangenen oder verworfenen Pakete.

Anmerkung:

DDoS-Schutzpolicen der Steuerungsebene reagieren auf die Datenverkehrswarteschlangen des Systems. Die QFX5100 und QFX5200 Leitungen von Switches verwalten den Datenverkehr für mehr Protokolle als die Anzahl der Warteschlangen, sodass das System häufig mehr als ein Protokoll derselben Warteschlange zuordnen muss. Wenn Datenverkehr für ein Protokoll eine Warteschlange mit anderen Protokollen teilt und gegen die Grenzwerte der DDoS-Schutzpolizei verstößt, melden diese Geräte eine Verletzung in dieser Warteschlange für alle zugeordneten Protokolle, da das System nicht unterscheidet, welcher Datenverkehr des Protokolls die Verletzung konkret verursacht hat. Sie können Ihre Erkenntnisse über die Datenverkehrstypen, die durch Ihr Netzwerk fließen, nutzen, um festzustellen, welches der gemeldeten Protokolle den Verstoß tatsächlich ausgelöst hat.

Unterstützte Plattformen

In Junos OS Version 14.2 und höher wird der DDoS-Schutz der Steuerungsebene auf bestimmten Plattformen unterstützt. Im Allgemeinen ist bei einigen Modellen der folgenden Plattformen der DDoS-Schutz der Steuerungsebene standardmäßig aktiviert und es werden Konfigurationsoptionen zum Ändern der Standardparameter des Policers unterstützt:

• Router der ACX-Serie.

• EX9200-Switches.

• Router der MX-Serie, auf denen nur MPCs installiert sind.

• Router der MX-Serie mit integrierter MPC

  Anmerkung:

  Der Einfachheit halber: Wenn sich der Text auf Linecards oder Linecard-Policer bezieht, ist damit bei diesen Routern die eingebaute MPC gemeint.

  Da diese Router keine FPC-Steckplätze haben, beziehen sich die Informationen, die in FPC Feldern nach show Befehlen angezeigt werden, tatsächlich auf TFEB.

• PTX-Serie Router, auf denen nur PE-basierte FPCs installiert sind (PTX3000, PTX5000, PTX1000 und PTX10000), unterstützen ab Version 17.4 R1 den DDoS-Schutz der Steuerungsebene Junos OS.

  PTX10002 Router unterstützen ab Version 18.2R1 Junos OS DDoS-Schutz auf Steuerungsebene.

  PTX10003 Router unterstützen DDoS-Schutz auf der Steuerungsebene ab Junos OS Evolved-Version 19.3R1.

  PTX10004-Router unterstützen DDoS-Schutz auf der Steuerungsebene ab Junos OS Evolved Version 20.3R1.

  PTX10008 Router unterstützen DDoS-Schutz auf der Steuerungsebene ab Junos OS Evolved Version 20.1R1.

• QFX-Serie Switches, einschließlich der QFX5100-Reihe, QFX5200 Line und der QFX10000-Reihe der Switches.

  QFX10002-60C-Switches unterstützen den DDoS-Schutz der Steuerungsebene ab Junos OS Version 18.1R1.

• T4000-Router, auf denen nur FPCs vom Typ 5 installiert sind.

Anmerkung:

• Auf Junos weiterentwickelt-Plattformen müssen Sie die und/oder inet6 Protokollfamilie inet auf der lo0-Schnittstelle des Geräts konfigurieren, damit der DDoS-Schutz für diese Protokollfamilien funktioniert.

• Einige Switches der EX-Serie verfügen möglicherweise über DDoS-Schutz auf der Steuerungsebene, unterstützen jedoch keine CLI-Optionen zum Anzeigen oder Ändern der Standard-Policer-Parameter.

• Für Routerplattformen, die neben MPCs (MX-Serie), FPCs vom Typ 5 (T4000) oder PE-basierten FPCs (PTX3000, PTX5000, PTX1000 und PTX10000) auch über andere Linecards verfügen, akzeptiert die CLI die Konfiguration, aber die anderen Linecards sind nicht geschützt, sodass der Router nicht geschützt ist.

• DDoS-Schutzunterstützung für Control Plane für erweiterte Abonnentenverwaltung wurde in Junos OS Version 17.3R1 auf Routing-Plattformen hinzugefügt.

• So ändern Sie die standardkonfigurierten DDoS-Schutzparameter der Steuerungsebene für unterstützte Protokollgruppen und Pakettypen: Router der ACX-Serie, Router der PTX-Serie und Switches der QFX-Serie verfügen über CLI-Konfigurationsoptionen, die sich erheblich von den für Router der MX-Serie und T4000 verfügbaren Optionen unterscheiden. In den folgenden Konfigurationsanweisungen finden Sie die verfügbaren Konfigurationsoptionen auf verschiedenen Geräten:

  • Informationen zum Routing von Geräten mit Ausnahme von Routern der PTX-Serie finden Sie unter Protokolle (DDoS).

  • Informationen zu Routern der ACX-Serie, Routern der PTX-Serie und Switches der QFX-Serie finden Sie unter Protokolle (DDoS) (ACX-Serie, PTX-Serie und QFX-Serie).

Policer-Typen und Paketprioritäten

Der DDoS-Schutz der Steuerungsebene umfasst zwei Arten von Policern:

• Ein aggregierter Policer wird auf den vollständigen Satz von Pakettypen angewendet, die zu einer Protokollgruppe gehören. Sie können z. B. einen aggregierten Policer konfigurieren, der für alle PPPoE-Steuerpakettypen oder für alle DHCPv4-Steuerpakettypen gilt. Sie können Bandbreitengrenzwerte (Pakete pro Sekunde [pps]) und Burst-Grenzwerte (Pakete in einem Burst) angeben, die Bandbreiten- und Burst-Grenzwerte skalieren und eine Datenverkehrspriorität für aggregierte Policer festlegen. Ein aggregierter Policer wird von allen Protokollgruppen unterstützt.

• Ein einzelner Policer, auch Pakettyp-Policer genannt, wird jedem Kontrollpakettyp innerhalb einer Protokollgruppe zugeordnet. Sie können z. B. einen Policer für einen oder mehrere Typen von PPPoE-Kontrollpaketen, RADIUS-Steuerpaketen oder Multicast-Snooping-Paketen konfigurieren. Sie können Grenzwerte für Bandbreite (pps) und Burst (Pakete) angeben, die Bandbreiten- und Burst-Grenzwerte skalieren und eine Datenverkehrspriorität für Paketrichtlinier festlegen. Für einige Protokollgruppen stehen individuelle Policer zur Verfügung.

Die Unterstützung von Protokollgruppen und Pakettypen variiert je nach Plattform und Junos OS-Version wie folgt:

• Informationen zum Routing von Geräten mit Ausnahme von Routern der PTX-Serie finden Sie unter Protokolle (DDoS).

• Informationen zu Routern der ACX-Serie, Routern der PTX-Serie und Switches der QFX-Serie finden Sie unter Protokolle (DDoS) (ACX-Serie, PTX-Serie und QFX-Serie).

Ein Kontrollpaket wird zuerst von seinem einzelnen Policer (falls unterstützt) und dann von seinem aggregierten Policer überwacht. Ein Paket, das vom einzelnen Policer abgeworfen wird, erreicht nie den aggregierten Policer. Ein Paket, das den einzelnen Policer passiert, kann anschließend vom aggregierten Policer verworfen werden.

Anmerkung:

Router der ACX-Serie unterstützen den aggregierten Policer nur für alle unterstützten Protokollgruppen.

Pakettypen innerhalb einer Protokollgruppe haben eine standardmäßige, konfigurierbare Priorität: niedrig, mittel oder hoch. Jedes Steuerpaket konkurriert mit anderen Paketen um die Bandbreite innerhalb der Paketratenbegrenzung, die von seinem aggregierten Policer basierend auf der für jeden Pakettyp in der Protokollgruppe konfigurierten Priorität festgelegt wird.

Der Prioritätsmechanismus ist absolut. Datenverkehr mit hoher Priorität erhält Bandbreite bevorzugt Datenverkehr mit mittlerer und niedriger Priorität. Datenverkehr mit mittlerer Priorität erhält Bandbreite gegenüber Datenverkehr mit niedriger Priorität. Für Datenverkehr mit niedriger Priorität kann nur die Bandbreite genutzt werden, die für Datenverkehr mit hoher und mittlerer Priorität übrig bleibt. Wenn der Datenverkehr mit höherer Priorität die gesamte Bandbreite beansprucht, wird der gesamte Datenverkehr mit niedrigerer Priorität verworfen.

In Versionen vor Junos OS-Version 23.2R1 bestimmt auf Geräten der MX-Serie der Linecard-Typ im Gerät die DDoS-Priorität (Distributed Denial of Service) eingehender Protokolle. Ab Junos OS Version 23.2R1 bestimmt das Gerät die DDoS-Priorität eines Protokolls basierend auf der DDoS-Parametertabelle. Diese Erweiterung ermöglicht es dem Gerät, alle Pakete eines bestimmten Protokolls standardmäßig gleich zu behandeln, unabhängig von der Linecard des Geräts. Diese Funktion verbessert die Konsistenz bei der Priorisierung von Protokollen durch Geräte im Netzwerk zum Schutz vor DDoS-Angriffen. Tabelle 1 listet die Änderung der Standard-DDOS-Priorität auf. Sie können die Priorität mit dem edit system ddos-protection protocol proto-name (aggregate | subtype) priority level CLI-Befehl ändern.

Tabelle 1: Standard-DDOS-Priorität in der DDOS-Parametertabelle

	Standard-DDOS-Priorität des Protokolls in der DDOS-Parametertabelle
	Vor Junos OS-Version 23.2R1	Nach Junos OS-Version 23.2R1
BGP	Niedrig	Hoch
LDP	Hoch	Hoch
ICMP	Hoch	Mittel
ICMPv6	Hoch	Mittel
ND_ROUTER_SOLICIT	Hoch	Hoch
ND_ROUTER_ADVERT	Niedrig	Hoch
ND_NEIGHBOUR_SOLICIT	Hoch	Hoch
ND_NEIGHBOUR_ADVERT	Niedrig	Hoch
ND_NEIGHBOUR_REDIRECT	Niedrig	Hoch
IGMP	Hoch
BFD	Hoch	Hoch
GRE-Keepalive	Hoch	Hoch
GRE	Niedrig	Mittel

Beispiel für Prioritätsverhalten von Polizisten

Überlegen Sie beispielsweise auf einem Gerät, das DDoS-Schutz auf Steuerungsebene für die PPPoE-Protokollgruppe unterstützt, wie Sie Pakettypen innerhalb dieser Protokollgruppe konfigurieren können. Ignorieren Sie andere PPPoE-Pakettypen für dieses Beispiel. Nehmen wir an, Sie konfigurieren einzelne Policer für PADI- und PADP-Pakete sowie einen PPPoE-Aggregat-Policer für alle diese Pakete. Sie priorisieren PAPT-Pakete gegenüber PADI-Paketen, da PAPT-Pakete es der PPPoE-Anwendung ermöglichen, Ressourcen freizugeben, um neue Verbindungen zu akzeptieren. Daher weisen Sie den PADP-Paketen eine hohe Priorität und den PADI-Paketen eine niedrige Priorität zu.

Der aggregierte Policer legt einen Grenzwert für die Gesamtpaketrate für die Protokollgruppe fest. PAPT-Pakete, die von ihrem individuellen Policer übergeben werden, haben Zugriff auf diese Bandbreite vor PADI-Paketen, die von ihrem individuellen Policer übergeben werden, da die PAPT-Pakete eine höhere Priorität haben. Wenn so viele PAPT-Pakete übergeben werden, dass sie die gesamte verfügbare Bandbreite verbrauchen, dann werden alle PADI-Pakete verworfen, da am aggregierten Policer keine Bandbreite mehr übrig ist.

Beispiel für eine Policer-Hierarchie

DDoS-Policer auf der Steuerungsebene sind so organisiert, dass sie dem hierarchischen Fluss des protokollgesteuerten Datenverkehrs entsprechen. Der Steuerdatenverkehr, der von allen Ports einer Linecard kommt, läuft auf der Packet Forwarding Engine zusammen. Steuern Sie den Datenverkehr von allen Linecards auf dem Router, der auf die Routing-Engine konvergiert. In ähnlicher Weise werden die DDoS-Policer hierarchisch entlang der Kontrollpfade platziert, sodass überschüssige Pakete so früh wie möglich auf dem Pfad verworfen werden. Dieser Entwurf schont Systemressourcen, indem überschüssiger, schädlicher Datenverkehr entfernt wird, sodass die Routing-Engine nur die Menge an Datenverkehr erhält, die sie verarbeiten kann.

Um dieses Design beispielsweise auf Routern der MX-Serie zu implementieren, sind fünf DDoS-Policer vorhanden: Einer auf der Packet Forwarding Engine (dem Chipsatz), zwei auf der Linecard und zwei auf der Routing-Engine. Für einige Protokollgruppen ist auch ein aggregierter Policer auf der Packet Forwarding Engine vorhanden, so dass insgesamt sechs Policer verfügbar sind. Der Einfachheit halber folgt der Text dem allgemeinen Fall. Abbildung 1 zeigt z. B. den Policer-Prozess für PPPoE-Datenverkehr. Abbildung 2 zeigt den Policer-Prozess für DHCPv4-Datenverkehr. (Derselbe Vorgang gilt auch für DHCPv6-Datenverkehr.)

Anmerkung:

Denken Sie daran, dass Router der PTX-Serie und Switches der QFX-Serie ein einfacheres Design mit Policern nur in der Packet Forwarding Engine haben. PTX10003- und PTX10008-Router setzen DDoS-Schutzgrenzwerte der Steuerungsebene auf drei Ebenen durch, zwei auf der Ebene des Packet Forwarding Engine Chipsatzes und der Linecards und eine auf der Routing-Engine-Ebene. Pakettyp- und Aggregatrichtlinier funktionieren jedoch auf all diesen Plattformen ähnlich.

Steuerpakete kommen zur Verarbeitung und Weiterleitung bei der Packet Forwarding Engine an. Der erste Policer (1) ist entweder ein einzelner Policer (Abbildung 1) oder ein aggregierter Policer (Abbildung 2).

• Der erste Policer ist ein einzelner Policer für Protokollgruppen, die einzelne Policer unterstützen, mit zwei Ausnahmen. Für DHCPv4- und DHCPv6-Datenverkehr ist der erste Policer ein aggregierter Policer.

• Der erste Policer ist ein Aggregat-Policer für Protokollgruppen, die nur Aggregat-Policer unterstützen.

Der Datenverkehr, der den ersten Polizisten passiert, wird von einem oder beiden der Linecard-Polizisten überwacht. Wenn die Karte über mehr als eine Packet Forwarding Engine verfügt, läuft der Datenverkehr von allen Paketweiterleitungsmodulen auf den Linecard-Policern zusammen.

• Wenn der Datenverkehr zu einer Protokollgruppe gehört, die einzelne Policer unterstützt, durchläuft er den Linecard Individual Policer (2) und dann den Linecard Aggregate Policer (3). Datenverkehr, der den einzelnen Policer passiert, kann vom aggregierten Policer verworfen werden. Obwohl der DHCPv4- und DHCPv6-Datenverkehr von einem aggregierten Policer in der Packet Forwarding Engine überwacht wurde, wird er auf der Linecard wie andere Protokolle gehandhabt, die individuelle Policer unterstützen.

• Wenn der Datenverkehr zu einer Protokollgruppe gehört, die nur aggregierte Policer unterstützt, wird der Datenverkehr nur vom Linecard-Aggregatpolicer überwacht.

Der Datenverkehr, der die Linecard-Policer passiert, wird von einem oder beiden Routing-Engine-Policern überwacht. Der Datenverkehr von allen Linecards läuft in den Routing-Engine-Policern zusammen.

• Wenn der Datenverkehr zu einer Protokollgruppe gehört, die einzelne Policer unterstützt, durchläuft er die Routing-Engine Individual Policer (4) und dann die Routing-Engine Aggregate Policer (5). Datenverkehr, der den einzelnen Policer passiert, kann vom aggregierten Policer verworfen werden. Der DHCPv4- und DHCPv6-Datenverkehr der Routing-Engine wird wie zuvor auf Linecard-Ebene wie andere Protokolle gehandhabt, die individuelle Policer unterstützen.

• Wenn der Datenverkehr zu einer Protokollgruppe gehört, die nur aggregierte Policer unterstützt, überwacht nur der aggregierte Policer den Datenverkehr.

Bei diesem Entwurf werten drei Policer den Datenverkehr für Protokollgruppen aus, die nur aggregierte Policer unterstützen. Dazu gehören unter anderem ANCP, dynamisches VLAN, FTP und IGMP-Datenverkehr. Der Datenverkehr für Protokollgruppen, die sowohl aggregierte als auch individuelle Policer unterstützen, wird von allen fünf Policern ausgewertet. Dazu gehören unter anderem DHCPv4, MLP, PPP, PPPoE und Virtual Chassis-Datenverkehr .

Abbildung 1 zeigt, wie der DDoS-Schutz der Steuerungsebene PPPoE-Steuerpakete überwacht:

1. PADR-Pakete werden beispielsweise beim ersten Policer der Packet Forwarding Engine ausgewertet, um festzustellen, ob sie innerhalb der Paketratenlimits liegen. PADR-Pakete, die den Grenzwert überschreiten, werden verworfen.

2. Alle PADR-Pakete, die den Policer auf allen Paketweiterleitungsmodulen auf der Linecard passieren, werden als Nächstes vom einzelnen Linecard-Policer ausgewertet. PADR-Pakete, die den Grenzwert überschreiten, werden verworfen.

3. Alle PADR-Pakete, die den Linecard-Einzelpolicer passieren, werden zum Linecard-Aggregat-Policer weitergeleitet. PADR-Pakete, die den Grenzwert überschreiten, werden verworfen.

4. Alle PADR-Pakete, die von den Linecard-Aggregatpolicern auf allen Linecards auf dem Router übergeben werden, werden an den einzelnen Routing-Engine-Policer weitergeleitet. PADR-Pakete, die den Grenzwert überschreiten, werden verworfen.

5. Schließlich werden alle PADR-Pakete, die von der individuellen Routing-Engine-Polizei übergeben werden, an die aggregierte Routing-Engine-Police weitergeleitet. PADR-Pakete, die den Grenzwert überschreiten, werden verworfen. PADR-Pakete, die hier nicht verworfen werden, werden als sicherer, normaler Datenverkehr weitergeleitet.

Standardmäßig haben alle drei einzelnen Policer (Packet Forwarding Engine, Linecard und Routing-Engine) das gleiche Paketratenlimit für einen bestimmten Pakettyp. Bei dieser Konstruktion kann der gesamte Steuerdatenverkehr einer Packet Forwarding Engine und einer Linecard die Routing-Engine erreichen, solange kein konkurrierender Datenverkehr desselben Typs von anderen Packet Forwarding Engines oder Linecards vorhanden ist. Wenn konkurrierender Datenverkehr vorhanden ist, werden überschüssige Pakete an den Konvergenzpunkten verworfen. Das heißt, sie werden bei allen konkurrierenden Packet Forwarding Engines auf der Linecard und bei allen konkurrierenden Linecards auf der Routing-Engine abgelegt.

Beispiel für das Verhalten eines Policers zur Begrenzung der Paketrate

Nehmen wir zum Beispiel an, du stellst die Policer-Option bandwidth für PADI-Pakete auf 1000 Pakete pro Sekunde ein. Dieser Wert gilt für die einzelnen PADI-Policer an der Packet Forwarding Engine, der Linecard und der Routing-Engine. Wenn nur die Karte in Steckplatz 5 PADI-Pakete empfängt, können bis zu 1000 PADI pps die Routing-Engine erreichen (wenn der PPPoE Aggregate policer nicht überschritten wird). Nehmen wir jedoch an, dass die Karte in Steckplatz 9 auch PADI-Pakete mit 1000 pps empfängt und dass ihr PPPoE-Aggregat-Policer nicht überschritten wird. Der Datenverkehr passiert die einzelnen und aggregierten Policer an beiden Linecards und wird zur Routing-Engine weitergeleitet. Bei der Routing-Engine beträgt die kombinierte Paketrate 2000 pps. Da der PADI Policer an der Routing-Engine nur 1000 PADI pps passieren lässt, verwirft er die überschüssigen 1000 Pakete. Die überschüssigen Pakete werden so lange verworfen, wie das Bandbreitenlimit (pps) überschritten wird.

Sie können einen Skalierungsfaktor sowohl für das Bandbreitenlimit (pps) als auch für das Burst-Limit (Pakete in einem Burst) an der Linecard anwenden, um die Datenverkehrslimits für jeden Steckplatz präzise abzustimmen. Nehmen wir zum Beispiel an, der einzelne Policer stellt die PADI-Paketrate auf 1000 pps und die Burst-Größe auf 50.000 Pakete ein. Du kannst das Datenverkehrslimit für PADI-Pakete auf jeder Linecard reduzieren, indem du die Slot-Nummer und den Skalierungsfaktor angibst. Ein Bandbreitenskalierungsfaktor von 20 für Steckplatz 5 reduziert den Datenverkehr in diesem Beispiel auf 20 Prozent von 1000 pps bzw. 200 pps für die Linecard in diesem Steckplatz. In ähnlicher Weise reduziert ein Burst-Skalierungsfaktor von 50 für diesen Slot die Burst-Größe um 50 Prozent auf 25.000 Pakete. Standardmäßig sind die Skalierungsfaktoren auf 100 festgelegt, sodass der Datenverkehr mit 100 Prozent des Ratenlimits passieren kann.

DDoS-Schutz auf der Steuerungsebene im Vergleich zum Paketüberlastungsschutz bei Teilnehmeranmeldungen

Zusätzlich zu den DDoS-Schutzfunktionen der Steuerungsebene verfügen Router der MX-Serie auch über einen integrierten Überlastungsmechanismus für die Teilnehmeranmeldung. Der Anmeldeüberlastungsschutzmechanismus (auch als Lastdrosselungsmechanismus bezeichnet) überwacht die eingehenden Anmeldepakete des Teilnehmers und lässt nur das zu, was das System entsprechend der vorherrschenden Belastung des Systems verarbeiten kann. Pakete, die die Kapazität des Systems übersteigen, werden verworfen. Durch das Abwerfen dieser überschüssigen Last ist das System in der Lage, eine optimale Leistung aufrechtzuerhalten und eine Verschlechterung der Anmeldeabschlussrate unter Überlastbedingungen zu verhindern. Dieser Mechanismus verbraucht nur minimale Ressourcen und ist standardmäßig aktiviert. Es ist keine Benutzerkonfiguration erforderlich.

Der Schutz, den dieser Mechanismus bietet, ist zweitrangig gegenüber dem, was DDoS-Schutz auf der Steuerungsebene als erste Verteidigungsebene gegen hohe Raten eingehender Pakete bietet. DDoS-Schutz auf Steuerungsebene arbeitet auf der Packet Forwarding Engine und schützt vor allen Pakettypen aller Protokolle. Im Gegensatz dazu befindet sich der Anmeldeüberlastungsschutzmechanismus auf der Routing-Engine und funktioniert speziell nur für eingehende Verbindungsinitiierungspakete, z. B. DHCPv4-DHCPDISCOVER-, DHCPv6 SOLICIT- und PPPoE-PADI-Pakete.