Selektive klassenbasierte Filterung auf PTX-Routern

Für unterstützte Router und Linecards der PTX-Serie können Sie IPv4- und IPv6-Datenverkehr basierend auf der Quell- oder Zielklassifizierung (Source Class Usage, SCU) und (Destination Class Usage, DCU) filtern. Dies ist nützlich, da es bedeutet, dass Sie einen Filter selektiv auf eine Teilmenge von Paketen in einer Klasse anwenden können, anstatt auf alle Pakete in der Klasse. Darüber hinaus wird der Paketfluss durch die Packet Forwarding Engine (PFE) optimiert und die Filterung ist effizienter.

Service Providern ermöglicht die klassenbasierte Filterung die Bereitstellung erweiterter Services wie:

• Manipulation des Per-Hop-Verhaltens durch Anpassen der Weiterleitungsklasse des Pakets basierend auf der Quell- oder Zielpaketklasse und anderen Filterkriterien.

• Begrenzung der Datenverkehrsrate auf bestimmte Kundenschnittstellen, wobei ein hohes Datenverkehrsvolumen zurückgehen kann (z. B. bei DDoS-Angriffen). Normalerweise würden Sie einen ausgehenden Schnittstellenfilter bereitstellen, um die Rate des Datenverkehrs zu begrenzen. Dies kann jedoch ineffizient sein, da der Datenverkehr in verteilten Systemen immer noch die Fabric durchquert und nur begrenzte Fabric-Bandbreite beansprucht. Noch deutlicher wird die Ineffizienz in einem Virtual Output Queueing-System wie PTX, bei dem der Eintritt in die Ausgangswarteschlange erfolgt, bevor der Ausgabefilter ausgeführt wird, und jede nachfolgende Drop-Aktion im Ausgabefilter eine Kompensation erfordert – es muss mehr Datenverkehr in die Warteschlange eingelassen werden, was mehr Fabric-Bandbreite und mehr Ausgangs-On-Chip-Pufferspeicher erfordert (was eine begrenzte Ressource ist). Klassenbasierte Filter werden in der Eingangspipeline ausgeführt, bevor die Pakete in die Ausgangswarteschlange aufgenommen werden. Dieser Mechanismus wird gegenüber regulären Ausgabeschnittstellenfiltern empfohlen, wenn Sie erwarten, dass große Datenverkehrsmengen an bestimmte Ziele verworfen werden.

Die klassenbasierte Filterung ist auch effektiv für "Low-and-Slow"-DoS-Angriffe, die auf Anwendungs- und Serverressourcen abzielen, indem sie normale Datenverkehrsmuster nachahmen.

Um die klassenbasierte Filterung zu unterstützen, werden zwei neue Bindungspunkte in der Weiterleitungstabelle für PTX-Router eingeführt: source-class und destination-class.

Hier wird die CLI-Hierarchie angezeigt, wobei src-class-name oder dest-class-name der Name des Filters ist, den Sie in der entsprechenden Richtlinie definiert haben.

Sie können auch instanzspezifische Filter für mehrere SCU- und DCU-Klassen konfigurieren. Standardmäßig wird nur ein Satz von Leistungsindikatoren und Policern für einen Filter instanziiert. Im instanzspezifischen Filter wird für jeden Filteranfügepunkt ein separater Satz von Zählern und Policern erstellt.

Ursprünglich wurde die Funktion Source Class Usage (SCU) eingeführt, um eine statistische Aufschlüsselung des Datenverkehrs bereitzustellen, der an eine bestimmte Schnittstelle pro Ursprungspräfix (identifiziert durch die Quellklasse) gesendet wird. Destination Class Usage (DCU) wurde ursprünglich eingeführt, um eine statistische Aufschlüsselung des auf einer Schnittstelle empfangenen Datenverkehrs pro Zielpräfix (identifiziert durch die Zielklasse) bereitzustellen.

Sowohl Quell- als auch Zielklassen werden dem Paket bei der Quell- oder Zielsuche zugewiesen. Daher können Übereinstimmungsbedingungen für Quell- und Zielfilter nur ausgewertet werden, wenn der Filter nach der Suche ausgeführt wird.

Juniper Router unterstützen mehrere Filterbindungspunkte. Diejenigen, die das Ergebnis der Quell- und Zielklassifizierung nutzen können, sind unten mit Nutzungsrichtlinien aufgeführt:

• Ausgabeschnittstellenfilter (Schnittstellen festlegen <Schnittstellenname> Familie inet filter <output>. Wird auf jeder PTX-Plattform unterstützt, aber nicht empfohlen, wenn erwartet wird, dass große Datenverkehrsmengen in einem stabilen Zustand verworfen werden (z. B. bei der Implementierung eines Filters zur Abwehr von DDoS-Angriffen). Verworfener DDoS-Angriffsdatenverkehr kann aufgrund der begrenzten Fabric-Bandbreite und des begrenzten Ausgangs-On-Chip-Pufferspeichers möglicherweise nicht durch anderen Datenverkehr kompensiert werden, der die DDoS-Angriffskriterien nicht erfüllt.

• Filtern Sie nach der Suche nach Weiterleitungstabellenfiltern (setzen Sie die Weiterleitungsoptionsfamilie inet filter <filtername> Ausgabe). Unterstützt auf den Plattformen Express 2 (PE) und Express 3 (ZX). Die Filter werden jedoch in der Ausgangspipeline instanziiert, daher ähnelt das Verwerfungsverhalten dem regulären Ausgabeschnittstellenfilter.

• Quell- oder Zielklassenspezifischer Bindungspunkt (routing-options forwarding-table source-class src-class-name family [inet | inet6] filter <filter- name>) setzen). Unterstützt auf den Plattformen Express 2 (PE), Express 3 (ZX) und Express 4 (BT). Dieser Filter wird in der Eingangspipeline instanziiert. Dies ist die empfohlene Option, um große Datenverkehrsmengen zu verwerfen. Diese Option wird auch empfohlen, wenn Sie die Weiterleitungsklasse und anschließend die Zuweisung der Ausgabewarteschlange überschreiben müssen. In einem Warteschlangensystem für virtuelle Ausgaben wird die Warteschlange in der Eingangspipeline ausgewählt, und jede Außerkraftsetzung muss auch in der Eingangspipeline erfolgen.

In diesem Beispiel wird gezeigt, wie Firewallaktionen (Verwerfen, Ablehnen oder Überwachen) auf IPv4- und IPv6-Datenverkehrsflüsse auf der Grundlage der Quell- oder Zielklassifizierung angewendet werden. Sie gilt für PTX10001-36MR-, PTX10003-160C-, PTX10003-80C-, PTX10004- und PTX10008-Router mit Junos Evolved OS Version 21.2 PTX10016 Router mit JUNOS Evolved OS Version 21.4 oder PTX3000, PTX-5000, PTX1000, PTX10002, PTX10008 PTX10016 Router mit Junos OS Version 21.2 oder höher.

• Anforderungen
• Überblick
• Konfiguration

Überblick

In diesem Beispiel werden drei Routinggeräte verwendet: ein Kunden-Edge-Gerät (CE), ein Provider-Edge-Gerät (PE) und ein Provider-Core-Gerät (P). Die Konfiguration für IPv4-Datenverkehr wird angezeigt und umfasst zwei Sätze von SCU- und DCU-Klassen sowie die Firewallfilter. In der folgenden Abbildung stellen die /32-IP-Präfixe Hosts dar, die mit dem Kunden-Edge (CE) bzw. Provider-Router (P) verbunden sind.

Abbildung 1: Beispielnetzwerk

In diesem Beispiel definieren wir zwei Klassen von Datenverkehr: SCU-1 und SCU-2, wobei das erste den Präfixen im Subnetz 172.16.2.0/24 und das zweite den Präfixen im Subnetz 172.16.3.0/24 zugewiesen wird. Andere Präfixe haben keine Klassenzuweisungen. Wie im folgenden CLI-Codeausschnitt gezeigt, wird auf dem PE-Router eine Routing-Richtlinie definiert, um Präfixe für die Quellklasse scu-1 und die Quellklasse scu-2 zuzuweisen.

Um den Datenverkehr zu berücksichtigen, der von CE in die Schnittstellen von PE eingeht, verwendet die auf dem PE-Router definierte Richtlinie namens dcu-class Routenfilter, um den Datenverkehr in dcu-1zu platzieren, andere Präfixe haben keine Klassenzuweisungen.

Die Richtlinien werden dann auf die Weiterleitungstabelle angewendet.

Im nächsten Schritt konfigurieren wir einen Filter auf dem PE-Router.

Fügen Sie diesen Filter an die spezifischen Quell- und Zielklassenbindungspunkte auf dem PE-Router an.