CoS Queuing für Tunnel – Übersicht
Auf einer Firewall der SRX-Serie, auf der Junos OS ausgeführt wird, ist eine Tunnelschnittstelle eine interne Schnittstelle und unterstützt viele der gleichen CoS-Funktionen wie eine physische Schnittstelle. Die Tunnelschnittstelle stellt eine virtuelle Punkt-zu-Punkt-Verbindung zwischen zwei Firewalls der SRX-Serie an Remote-Punkten über ein IP-Netzwerk her.
Sie können beispielsweise CoS-Funktionen für generische Routing-Kapselung (GRE) und IP-IP-Tunnelschnittstellen konfigurieren. Tunneling-Protokolle kapseln Pakete innerhalb eines Transportprotokolls.
GRE- und IP-IP-Tunnel werden mit Services wie IPsec und NAT verwendet, um Punkt-zu-Punkt-VPNs einzurichten. Mit Junos OS können Sie CoS-Warteschlangen, Planung und Shaping für den Datenverkehr, der über diese Tunnelschnittstellen ausgeht, aktivieren. Ein Beispiel für die Konfiguration von CoS Queuing für GRE-Tunnel finden Sie unter Beispiel: Konfigurieren von CoS Queuing für GRE- oder IP-IP-Tunnel.
CoS-Warteschlangen werden in GRE-Tunneln in Chassis-Clustern nicht unterstützt.
Vorteile von CoS Queuing für Tunnelschnittstellen
CoS-Warteschlangen für Tunnelschnittstellen haben die folgenden Vorteile:
Trennt den Tunneldatenverkehr.
Jeder Tunnel kann so geformt werden, dass ein Tunnel mit Datenverkehr mit niedriger Priorität andere Tunnel mit Datenverkehr mit hoher Priorität nicht überfluten kann.
Der Datenverkehr für einen Tunnel wirkt sich nicht auf den Datenverkehr in anderen Tunneln aus.
Steuert die Tunnelbandbreite.
Der Datenverkehr durch verschiedene Tunnel darf eine bestimmte Bandbreite nicht überschreiten.
Angenommen, Sie haben drei Tunnel zu drei Remote-Standorten über eine einzige WAN-Schnittstelle. Sie können CoS-Parameter für jeden Tunnel so auswählen, dass der Datenverkehr zu einigen Standorten mehr Bandbreite erhält als der Datenverkehr zu anderen Standorten.
Passt CoS-Richtlinien an.
Sie können je nach Benutzeranforderungen unterschiedliche Richtlinien für Warteschlangen, Planung und Formgebung auf verschiedene Tunnel anwenden. Jeder Tunnel kann mit unterschiedlichen Scheduler-Zuordnungen, unterschiedlichen Warteschlangentiefen usw. konfiguriert werden. Die Anpassung ermöglicht es Ihnen, granulare CoS-Richtlinien zu konfigurieren, die eine bessere Kontrolle über den Tunnelverkehr bieten.
Priorisiert den Datenverkehr, bevor er in einen Tunnel gelangt.
CoS-Warteschlangen verhindern beispielsweise, dass Pakete mit niedriger Priorität vor Paketen mit hoher Priorität geplant werden, wenn die Schnittstellengeschwindigkeit höher ist als die Geschwindigkeit des Tunneldatenverkehrs. Diese Funktion ist am nützlichsten, wenn sie mit IPsec kombiniert wird. In der Regel verarbeitet IPsec Pakete auf FIFO-Weise. Mit CoS-Warteschlangen kann jeder Tunnel jedoch Pakete mit hoher Priorität gegenüber Paketen mit niedriger Priorität priorisieren. Außerdem kann jeder Tunnel so geformt werden, dass ein Tunnel mit Datenverkehr mit niedriger Priorität Tunnel mit Verkehr mit hoher Priorität nicht überflutet.
CoS in logischen Tunneln konfigurieren
CoS verfügt über vier typische Szenarien, die eine Verbindung mit Remote-Standorten über sichere Tunnel ermöglichen. Verschiedene sichere Tunnel können sich jedoch über unterschiedliche reth-Schnittstellen mit verschiedenen Netzwerkanbietern (NP) verbinden. Für einen bestimmten NP kann eine begrenzte Uplink-Bandbreite verwendet werden, um Geschäfte mit hoher Priorität zu priorisieren und zu vermeiden, dass der Datenverkehr auf der NP-Seite blindlings unterbrochen wird. Derzeit unterstützt CoS keine Warteschlangen zwischen physischen Interfaes (IFD). Einen gemeinsam genutzten Policer zu haben, funktioniert nicht so gut wie Warteschlangen, der Policer kann Datenverkehr mit hoher Priorität unabhängig von der Priorität verwerfen. Um Warteschlangen auf einem IFD zu unterstützen, damit CoS-Funktionen Warteschlangen und -strukturierung priorisieren können, ist eine logische Tunnel- (LT) und NP-Konfiguration erforderlich.
Sie müssen ein Paar logischer Tunnel definieren, die eins zu eins NPs zugeordnet sind und den Datenverkehr mit Routing an die LT-Schnittstelle umleiten, bevor Sie den Datenverkehr über einen sicheren Tunnel verschlüsseln.
Konfigurieren Sie beispielsweise lt-0/0/0.0 und lt-0/0/0.1, um inet 0 und NP1 (virtueller Router) zu verbinden, und konfigurieren Sie eine statische Route, um Datenverkehr als lt-0/0/0.0 Next-Hop an NP1 umzuleiten. Da NP1 über eine Bandbreite von 10 Mbit/s für Upstreamdatenverkehr verfügt, kann lt-0/00.0 mit einem Bandbreiten-Shaping von 10 Mbit/s konfiguriert werden. Siehe Abbildung 1.
routing-instances {
NP1 {
instance-type virtual-router;
interface lt-0/0/0.1;
interface lo0.0;
interface reth1.0;
interface reth2.0;
interface st0.1;
interface st0.2;
routing-options {
static {
route 59.200.200.1/32 next-hop <next-hop addr of ipsec tunnel st0.1>;
route 59.200.200.2/32 next-hop <next-hop addr of ipsec tunnel st0.2>;
route 60.60.60.1/32 next-hop st0.1;
route 60.60.60.2/32 next-hop st0.2;
route 58.58.58.1/32 next-hop lt-0/0/0.1;
route 58.58.58.2/32 next-hop lt-0/0/0.1;
}
}
}
NP2 {
instance-type virtual-router;
interface lt-0/0/0.3;
interface lo0.1;
interface reth3.0;
interface reth4.0;
interface st0.3;
interface st0.4;
routing-options {
static {
route 59.200.200.3/32 next-hop <next-hop addr of ipsec tunnel st0.3>;
route 59.200.200.4/32 next-hop <next-hop addr of ipsec tunnel st0.4>;
route 60.60.60.3/32 next-hop st0.3;
route 60.60.60.4/32 next-hop st0.4;
route 58.58.58.3/32 next-hop lt-0/0/0.3;
route 58.58.58.4/32 next-hop lt-0/0/0.3;
}
}
}
}
routing-options {
static {
route 60.60.60.1/32 next-hop lt-0/0/0.0;
route 60.60.60.2/32 next-hop lt-0/0/0.0;
route 60.60.60.3/32 next-hop lt-0/0/0.2;
route 60.60.60.4/32 next-hop lt-0/0/0.2;
}
}
class-of-service {
interfaces {
lt-0/0/0 {
unit 0 {
shaping-rate 10m;
}
unit 2 {
shaping-rate 10m;
}
}
Funktionsweise von CoS Queuing
Abbildung 2 zeigt die CoS-bezogene Verarbeitung für Datenverkehr, der in einen Tunnel ein- und ausgeht. Weitere Informationen zur datenstrombasierten Paketverarbeitung finden Sie im Benutzerhandbuch für datenflussbasierte und paketbasierte Verarbeitung für Sicherheitsgeräte.
Einschränkungen bei CoS-Shapern für Tunnelschnittstellen
Beachten Sie beim Definieren einer CoS-Shaping-Rate auf einer Tunnelschnittstelle die folgenden Einschränkungen:
Die Shaping-Rate auf der Tunnelschnittstelle muss kleiner sein als die der physischen Ausgangsschnittstelle.
Die Shaping-Rate misst nur die Paketgröße, die das Layer-3-Paket mit GRE- oder IP-IP-Kapselung enthält. Die durch die physikalische Schnittstelle hinzugefügte Layer-2-Verkapselung wird bei der Messung der Formungsrate nicht berücksichtigt.
Das CoS-Verhalten funktioniert nur dann wie erwartet, wenn die physische Schnittstelle den geformten GRE- oder IP-IP-Tunnelverkehr allein überträgt. Wenn die physische Schnittstelle anderen Datenverkehr überträgt und dadurch die verfügbare Bandbreite für den Tunnelschnittstellenverkehr verringert wird, funktionieren die CoS-Funktionen nicht wie erwartet.
Es ist nicht möglich, einen Logical Interface Shaper und einen Virtual Circuit Shaper gleichzeitig auf dem Router zu konfigurieren. Wenn Virtual Circuit Shaping gewünscht wird, definieren Sie keinen logischen Schnittstellenshaper. Definieren Sie stattdessen eine Shaping-Rate für alle virtuellen Schaltkreise.