Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Anwendung von Policern

Überblick über die Anwendung von Policern

Policer ermöglichen Es Ihnen, einfache Überwachung des Datenverkehrs auf bestimmten Schnittstellen oder virtuellen privaten Layer-2-Netzwerken (VPNs) durchzuführen, ohne einen Firewall-Filter zu konfigurieren. Um Policer anzuwenden, fügen Sie die Aussage ein policer :

Sie können diese Anweisungen auf den folgenden Hierarchieebenen einschließen:

  • [edit interfaces interface-name unit logical-unit-number family family]

  • [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family family]

In der family Anweisung kann cccdie Protokollfamilie , , inet, inet6, mplstccoder vpls.

Listen Sie in der arp Anweisung den Namen einer Policer-Vorlage auf, die ausgewertet werden soll, wenn Address Resolution Protocol (ARP)-Pakete auf der Schnittstelle empfangen werden. Standardmäßig ist ein ARP-Policer installiert, der von allen Ethernet-Schnittstellen gemeinsam genutzt wird, auf denen Sie die family inet Anweisung konfiguriert haben. Wenn Sie eine strengere oder nachsichtige Überwachung von ARP-Paketen wünschen, können Sie einen schnittstellenspezifischen Policer konfigurieren und auf die Schnittstelle anwenden. Sie konfigurieren einen ARP Policer genauso wie jeden anderen Policer auf [edit firewall policer] Hierarchieebene. Wenn Sie diesen Policer auf eine Schnittstelle anwenden, wird der Standardmäßige ARP Packet Policer außer Kraft gesetzt. Wenn Sie diesen Policer löschen, wird der Standard-Policer erneut wirksam.

  • Sie können einen anderen Policer für jede Protokollfamilie auf einer Schnittstelle konfigurieren, mit einem Eingabe-Policer und einem Ausgabe-Policer für jede Familie. Wenn Sie Policer anwenden, können Sie die Familie ccc, inet, , inet6, mpls, , tccoder vpls nur und einen ARP-Policer nur für das Familienprotokoll inet konfigurieren. Jedes Mal, wenn ein Policer referenziert wird, wird eine separate Kopie des Policers auf den Paketweiterleitungskomponenten für diese Schnittstelle installiert.

  • Wenn Sie sowohl Policer als auch Firewall-Filter auf eine Schnittstelle anwenden, werden Eingabe-Policer ausgewertet, bevor die Eingabe-Firewall-Filter und die Ausgabe-Policer nach den Ausgabe-Firewall-Filtern ausgewertet werden. Listen Sie in der input Anweisung den Namen einer Policer-Vorlage auf, die ausgewertet werden soll, wenn Pakete über die Schnittstelle empfangen werden. Listen Sie in der output Anweisung den Namen einer Policer-Vorlage auf, die ausgewertet werden soll, wenn Pakete über die Schnittstelle übertragen werden.

  • Für Abonnenten, die auf Routern der MX-Serie über eine aggregierte Ethernet-Schnittstelle (AE) enden, die mehrere FPCs umfasst, ist es möglich, dass eine Gesamtteilnehmerrate die konfigurierte Rate überschreitet, da die im Policer konfigurierte Obergrenze separat auf jede Schnittstelle im AE-Paket angewendet wird. Wenn Sie also beispielsweise beabsichtigen, dass ein Policer auf einer Drei-Mitglieder-AE-Schnittstelle eine bandwidth-limit von erzwingt 600m, müssen Sie den bandwidth-limit im Policer für 200m konfigurieren, um die drei Schnittstellen in der AE (d. h. 200 Mbit/s pro Schnittstelle, für insgesamt 600 Mbit/s) zu berücksichtigen.

  • Wenn Sie den Policer auf die Schnittstelle lo0anwenden, wird er auf Pakete angewendet, die von der Routing-Engine empfangen oder übertragen werden.

  • Wenn sich die Schnittstellen auf derselben FPC befinden, M120 und M320 Plattformen, wirken die Filter oder Policer nicht auf die Summe des Datenverkehrs, der die Schnittstellen ein- und austritt.

Anwendung aggregierter Policer

Anwendung aggregierter Policer

Wenn Sie einen Policer auf mehrere Protokollfamilien auf derselben logischen Schnittstelle anwenden, beschränkt der Policer den Datenverkehr für jede Protokollfamilie einzeln. Ein Policer mit einer Bandbreitengrenze von 50 Mbit/s, die sowohl auf IPv4- als auch IPv6-Datenverkehr angewendet wird, würde die Schnittstelle beispielsweise erlauben, 50 Mbit/s IPv4-Datenverkehr und 50 Mbit/s IPv6-Datenverkehr zu akzeptieren. Wenn Sie einen aggregierten Policer anwenden, würde der Policer der Schnittstelle erlauben, nur 50 Mbit/s IPv4- und IPv6-Datenverkehr zusammen zu empfangen.

Um einen aggregierten Policer zu konfigurieren, fügen Sie die logical-interface-policer Anweisung auf [edit firewall policer policer-template-name] Hierarchieebene ein:

Damit der Policer als Aggregat behandelt werden kann, müssen Sie ihn auf mehrere Protokollfamilien auf einer einzigen logischen Schnittstelle anwenden, indem Sie die policer Anweisung angeben:

Sie können diese Anweisungen auf den folgenden Hierarchieebenen einschließen:

  • [edit interfaces interface-name unit logical-unit-number family family]

  • [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family family]

In der family Anweisung kann cccdie Protokollfamilie , , inet, inet6, mplstccoder vpls.

Die Protokollfamilien, auf die Sie den Policer nicht anwenden, sind vom Policer nicht betroffen. Wenn Sie beispielsweise eine einzige logische Schnittstelle so konfigurieren, dass SIE MPLS-, IPv4- und IPv6-Datenverkehr akzeptiert und den logischen Schnittstellen-Policer policer1 nur auf die IPv4- und IPv6-Protokollfamilien anwenden, unterliegt MPLS-Datenverkehr nicht den Einschränkungen von policer1.

Wenn Sie eine andere logische Schnittstelle anwenden policer1 , gibt es zwei Instanzen des Policer. Das bedeutet, dass junos OS den Datenverkehr auf separaten logischen Schnittstellen separat, nicht als Aggregat, kontrolliert, selbst wenn derselbe logische Schnittstellen-Policer auf mehrere logische Schnittstellen auf demselben physischen Schnittstellenport angewendet wird.

Beispiel: Anwendung aggregierter Policer

Konfigurieren Sie zwei logische Schnittstellen-Policer: aggregate_police1 und aggregate_police2. Wenden Sie sich auf aggregate_police1 IPv4- und IPv6-Datenverkehr an, der über die logische Schnittstelle fe-0/0/0.0 empfangen wird. Wenden Sie auf aggregate_police2 CCC- und MPLS-Datenverkehr an, der über die logische Schnittstelle fe-0/0/0.0 empfangen wird. Diese Konfiguration bewirkt, dass die Software nur eine Instanz von aggregate_police1 und eine Instanz von aggregate_police2erstellt.

Anwendung aggregate_police1 auf IPv4- und IPv6-Datenverkehr, der über eine andere logische Schnittstelle fe-0/0/0.1empfangen wird. Mit dieser Konfiguration erstellt die Software eine neue Instanz von , eine Instanz, aggregate_police1die für Einheit 0 gilt, und eine andere, die für Einheit 1 gilt.

Anwendung hierarchischer Policer auf erweiterte intelligente Queuing-PICs

Anwendung hierarchischer Policer auf erweiterte intelligente Queuing-PICs

M40e-, M120- und M320-Edge-Router und Core-Router der T-Serie mit Enhanced Intelligent Queuing (IQE)-PICs unterstützen hierarchische Policer in Eingangsrichtung und ermöglichen Es Ihnen, einen hierarchischen Policer für die Premium- und aggregierte (Premium plus normal) Datenverkehrsmenge auf eine Schnittstelle anzuwenden. Hierarchische Policer bieten funktionsübergreifende Funktionen zwischen der konfigurierten physischen Schnittstelle und der Packet Forwarding Engine.

Bevor Sie beginnen, gibt es einige allgemeine Einschränkungen, die für hierarchische Polizeibeamte gelten:

  • Nur eine Art von Policer kann für eine logische oder physische Schnittstelle konfiguriert werden. Ein hierarchischer Policer und ein regulärer Policer in derselben Richtung für dieselbe logische Schnittstelle sind beispielsweise nicht zulässig.

  • Die Verkettung der Policer – also das Anwenden von Policern sowohl an einem Port als auch an den logischen Schnittstellen dieses Ports – ist nicht erlaubt.

  • Es gibt eine Grenze von 64 Policern pro Schnittstelle, falls es keine BA-Klassifizierung gibt, die einen einzigen Policer pro DLCI bereitstellt.

  • Nur eine Art von Policer kann auf eine physische oder logische Schnittstelle angewendet werden.

  • Der Policer sollte unabhängig von der BA-Klassifizierung sein. Ohne BA-Klassifizierung wird der gesamte Datenverkehr auf einer Schnittstelle entweder als EF oder nicht-EF behandelt, basierend auf der Konfiguration. Bei der BA-Klassifizierung kann eine Schnittstelle bis zu 64 Policer unterstützen. Auch hier kann es sich um eine physische oder logische Schnittstelle (z. B. DLCI) gehen.

  • Mit der BA-Klassifizierung wird der sonstige Datenverkehr (der Datenverkehr, der nicht mit einem der BA-Klassifizierungs-DSCP/EXP-Bits übereinstimmt) als Nicht-EF-Datenverkehr kontrolliert. Für diesen Datenverkehr werden keine separaten Policer installiert.

Hierarchischer Policer – Überblick

Hierarchisches Policing verwendet zwei Token-Buckets, einen für aggregierten (Nicht-EF)-Datenverkehr und einen für Premium-Datenverkehr (EF). Welcher Datenverkehr EF ist und welcher nicht-EF ist, wird durch die Class-of-Service-Konfiguration bestimmt. Logischerweise wird hierarchische Polizeiarbeit durch die Verkettung von zwei Polizisten erreicht.

Abbildung 1: Hierarchischer PolizistHierarchischer Polizist

In dem Beispiel in Abbildung 1wird der EF-Datenverkehr von Premium Policer und nicht EF-Datenverkehr von Aggregate Policer kontrolliert. Das bedeutet, dass für EF-Datenverkehr die außerhalb der Spezifikation festgelegte Aktion für Premium Policer konfiguriert ist, der in-spec-EF-Datenverkehr jedoch weiterhin die Token vom Aggregate Policer verbraucht.

Ef-Datenverkehr wird jedoch niemals an die außerhalb der Spezifikations-Aktion des Aggregate Policer übermittelt. Wenn die außerhalb der Spezifikation enthaltene Aktion des Premium Policer nicht auf "Verwerfen" festgelegt ist, verwenden diese nicht die Token vom Aggregate Policer. Aggregate Policer kontrolliert nur den Nicht-EF-Datenverkehr. Wie Sie sehen können, kann der Aggregate Policer-Token-Bucket negativ werden, wenn alle Token vom Nicht-EF-Datenverkehr verbraucht werden und Sie dann überlasten ef-Datenverkehr erhalten. Aber das wird für eine sehr kurze Zeit sein, und über einen Bestimmten Zeitraum wird es sich im Durchschnitt herausholen. Zum Beispiel:

  • Premium Policer: Bandbreite 2 Mbit/s, OOS-Aktion: Verwerfen

  • Aggregierter Policer: Bandbreite 10 Mbit/s, OOS-Aktion: Verwerfen

In dem oben genannten Fall wird EF-Datenverkehr garantiert 2 Mbit/s und der Nicht-EF-Datenverkehr steigt von 8 Mbit/s auf 10 Mbit/s, je nach Eingaberate des EF-Datenverkehrs.

Hierarchische Policing-Merkmale

Hierarchische Token-Bucket-Funktionen umfassen:

  • Eingehender Datenverkehr wird zuerst in EF- und Nicht-EF-Datenverkehr klassifiziert, bevor ein Policer angewendet wird:

    • Die Klassifizierung erfolgt über die Q-Tree-Suche

  • Kanalnummer wählt einen gemeinsam genutzten Token-Bucket Policer aus:

    • Dual-Token-Bucket-Policer ist in zwei Single-Bucket-Policer unterteilt:

      • Policer1 – EF-Datenverkehr

      • Policer2 – Datenverkehr ohne EF

  • Der gemeinsam genutzte Token-Bucket wird verwendet, um den Datenverkehr wie folgt zu steuern:

    • Policer1 ist auf EF-Rate festgelegt (z. B. 2 Mbit/s)

    • Policer2 ist auf aggregierte Schnittstellen-Policed-Rate festgelegt (z. B. 10 Mbit/s).

    • EF-Datenverkehr wird auf Policer1 angewendet.

      • Wenn der Datenverkehr in-spec ist, darf er sowohl Policer1 als auch Policer2 passieren und sich ablösen.

      • Wenn datenverkehrsunabhängig ist, kann er verworfen oder mit einer neuen FC- oder Verlustpriorität markiert werden. Policer2 macht nichts mit ef-Datenverkehr außerhalb der Spezifikation.

    • Nicht-EF-Datenverkehr wird nur auf Policer2 angewendet.

      • Wenn der Datenverkehr in-spec ist, darf er Policer2 passieren und dekrementiert werden.

      • Wenn datenverkehrsfrei ist, wird er verworfen oder mit einem neuen FC markiert oder mit einer neuen Drop-Priorität festgelegt.

  • Geschwindigkeitsbegrenzung der Portgeschwindigkeit auf eine gewünschte Geschwindigkeit auf Layer 2

  • Ratenbegrenzung des EF-Datenverkehrs

  • Geschwindigkeitsbegrenzung des Nicht-EF-Datenverkehrs

  • Policing-Tropfen pro Farbe gezählt

Konfigurieren hierarchischer Policer

Um einen hierarchischen Policer zu konfigurieren, wenden Sie die policing-priority Anweisung auf die richtige Weiterleitungsklasse an und konfigurieren Sie einen hierarchischen Policer für die Aggregiert- und Premium-Ebene. Weitere Informationen zur Class-of-Service finden Sie im Junos OS Class of Service-Benutzerhandbuch für Routing-Geräte.

HINWEIS:

Hierarchische Policer können nur auf physischen SONET-Schnittstellen konfiguriert werden, die auf einem IQE PIC gehostet werden. Es werden nur aggregierte und Premium-Stufen unterstützt.

CoS-Konfiguration von Weiterleitungsklassen für hierarchische Polizisten

Detaillierte Informationen zur Class-of-Service-Konfiguration und -Anweisungen finden Sie im Junos OS Class of Service-Benutzerhandbuch für Routing-Geräte.

Firewall-Konfiguration für Hierarchische Polizisten

Sie können den hierarchischen Policer wie folgt anwenden:

Sie haben auch die Möglichkeit, den Policer auf physischer Portebene wie folgt anzuwenden:

Konfigurieren eines einstufigen Zwei-Farb-Policers

Sie können einen einstufigen zweifarbigen Policer wie folgt konfigurieren:

Sie können den Policer wie folgt anwenden:

Sie haben auch die Möglichkeit, den Policer auf physischer Portebene wie folgt anzuwenden:

Konfigurieren eines Single-Rate Color-Blind Policers

In diesem Abschnitt werden Farbblind- und Farbsensibilitäts-Policer mit einzelner Rate beschrieben.

Sie können einen Single-Rate-Color Blind Policer wie folgt konfigurieren:

Sie können den Single-Rate-Color Blind Policer wie folgt anwenden:

Sie können einen farbsensensigen Policer mit nur einer Rate wie folgt konfigurieren:

Sie können den farbsensensigen Policer für eine einzelne Rate wie folgt anwenden:

Sie haben auch die Möglichkeit, den Policer auf physischer Portebene wie folgt anzuwenden:

Konfigurieren eines zweistufigen Tricolor Marker Policers

Das Ingress-Policing wird mit einem Zwei-Rate Tricolor Marker (trTCM) implementiert. Dies geschieht mit einem Dual-Token-Bucket (DTB), der zwei Raten beibehält, zugesagt und einen Spitzenwert. Das statische Policing des Ausgangs verwendet auch einen Token-Bucket.

Die Token-Buckets führen die folgenden Eingangs-Policing-Funktionen aus:

  • (1K) trTCM – Dual-Token-Eimer (rot, gelb und grün)

  • Policing basiert auf Layer-2-Paketgröße:

    • Offset nach +/- Byte einstellen

  • Markierung ist farbbewusst und farbblind:

    • Color Aware muss die Farbe durch q-Tree-Suche festgelegt haben, basierend auf:

      • Tos

      • EXP

  • Programmierbare Markierungsaktionen:

    • Farbe (rot, gelb, grün)

    • Drop basierend auf Farbe und Überlastungsprofil

  • Policer wird anhand der eintreffenden Kanalnummer ausgewählt:

    • Kanalnummer LUT erzeugt Policer-Index und Warteschlangenindex

    • Mehrere Kanäle können denselben Policer gemeinsam nutzen (LUT erstellt den gleichen Policer-Index)

  • Unterstützen Sie Ingress Policing und trTCM auf den folgenden Ebenen:

    • Warteschlange

    • Logische Schnittstelle (ifl/DLCI)

    • Physische Schnittstelle (ifd)

    • Physischer Port (Controller ifd)

    • Beliebige Kombinationen aus logischer Schnittstelle, physischer Schnittstelle und Port

  • Prozentsatz der Unterstützung von Schnittstellengeschwindigkeit und Bits pro Sekunde

Geschwindigkeitsbeschränkungen können auf ausgewählte Warteschlangen am Eingang und auf vordefinierte Warteschlangen am Ausgang angewendet werden. Der Token-Bucket arbeitet im Farbbewusstseins- und Farbblindmodus (spezifiziert durch RFC 2698).

Konfigurieren eines color-blind trTCM

Sie können den dreifarbigen zweistufigen farbblinden Policer wie folgt anwenden:

Sie haben auch die Möglichkeit, den Policer auf physischer Portebene wie folgt anzuwenden:

Konfigurieren eines farbbewussten trTCM

Sie können den dreifarbigen, farbsen Policer mit zwei Geschwindigkeiten wie folgt anwenden:

Sie haben auch die Möglichkeit, den Policer auf physischer Portebene wie folgt anzuwenden: