Traffic Shaping auf der Fortigate v5.4

Viele Supportanfragen hinsichtlich des Traffic Shapings auf der Fortigate haben uns dazu bewogen einen eigenen Blogartikel hierfür zu schreiben.

Die grössten Irrtümer

Traffic Shaper werden genutzt, um eine gewisse Bandbreite zu garantieren, darüber hinaus dem Traffic eine Priorität zuzuordnen und eine maximale Bandbreite zu setzen.

Aber Vorsicht:

• Bandbreite kann nicht garantiert werden. Das Feature „guaranteed bandwith“ setzt den Traffic in die Warteschlange mit der allerhöchsten Priorität. Damit versucht die Fortigate diesen Traffic vorrangig zu behandeln – garantieren kann das aber niemand ;-).
• Dem Traffic, der über die garantierte Bandbreite hinaus geht, wird die angegebene Priorität zugewiesen. Das bedeutet aber nicht , dass „high“ Traffic immer schneller abgearbeitet wird, als anderer Traffic. Zunächst mal: Prioritäten greifen erst, wenn das ausgehende Interface seine eigene Kapazität erreicht. So lange ein Interface nicht ausgelastet ist, wird jeglicher Traffic gleich behandelt. Ein weiteres Missverständnis ist, dass Traffic, dem die Priorität „high“ zugeordnet ist, schneller verarbeitet wird, als Traffic, für den kein Traffic Shaper konfiguriert ist. Eigentlich ist es sogar genau umgekehrt… Weiter unten kommen wir noch mal zur Berechnung der eigentlichen Priorität.
• Traffic, der über die konfigurierte maximale Bandbreite hinausgeht, wird gedroppt. Aber auch das heisst nicht, dass ein Interface dadurch entlastet wird. Gerade bei TCP Traffic, muss man damit rechnen, dass die gedroppten Pakete vom Sender „re-transmitted“ werden, wenn diese vom Empfänger nicht bestätigt werden.

Soweit mal zu den wichtigsten Hinweisen.

Jetzt aber mal von vorne:

So früh wie möglich

Traffic Shaping wird auf der Fortigate erst am ausgehenden Interface durchgeführt. D.h. dass Traffic, der die maximale Bandbreite überschreitet, trotzdem vorher noch durch das komplette Content Scanning, wie z.B. AntiVirus und Application Detection, durchgelaufen ist. Da das eine ziemliche Verschwendung wäre, ist es sinnvoll, Traffic – der eh später gedroppt wird – bereits am eingehenden Interface zu droppen:

config system interface
  edit <ingress-interface-name>
    set inbandwidth <rate>
    set outbandwidth <rate>
end

<rate> wird in kb/s angegeben. <rate> = 0 heisst, dass Traffic hier nicht limitiert wird.

Traffic Shaper und Prioritäts-Warteschlangen

Die Fortigate kennt für jedes physikalische Interface 6 Prioritäten oder Warteschlangen. Jeder Warteschlange wird eine Priorität zugeordnet und die Warteschlangen werden anhand ihrer Priorität abgearbeitet. Innerhalb jeder Warteschlange gilt “first in, first out”. Virtuelle Interfaces nutzten die Warteschlangen des physikalischen Interfaces.

Die Warteschlange 0 ist für den Admin-Traffic (z.B. Zugriff aufs WebUI) bestimmt und für Traffic, welcher über den Traffic Shaper innerhalb der “garantieren Bandbreite” fällt. Für allen anderen Traffic wird die Warteschlange berechnet aus der Summe der Prioriät vom Traffic Shaper und der ToS-based Priorität.

Die Priorität des Traffic Shapers ist ja allgemein bekannt und hier gilt:

• high = 1
• medium = 2
• low = 3

Etwas weniger bekannt ist, dass hierzu aber noch die globale bzw. ToS-based priorty hinzu gezählt werden muss. Diese ergibt sich aus folgenden Settings:

config system global
  set traffic-priority-level {high|<medium>|low}
end

config system tos-based-priority
  edit <n>
    set tos [0-15]
    set priority [high|medium|low]
  next
end

Für Pakete, welche das ToS byte im IP Header gesetzt haben,  wird geprüft, ob über “config system tos-based-priority” ein Eintrag mit entsprechendem tos-Wert vorhanden ist. Falls ja, bekommt dieser Traffic die dort konfigurierte Priorität high, medium oder low zugewiesen. Gibt es hier keinen entsprechenden Eintrag oder ist das ToS Byte gar nicht gesetzt, so bekommt der Traffic die Priority vom “config sytem global > set traffic-priority” zugewiesen.

Irritierend ist, dass hier andere Wertigkeiten für high, medium und low gelten:

• high = 0
• medium = 1
• low = 2

Damit wird Traffic, der nicht innerhalb einer “garantierten Bandbreite” liegt, immer in eine der Warteschlangen 1..5 kommen:

Gesamt-Priorität = Globale bzw. ToS Priorität (0, 1, 2) + Traffic Shaper Priorität (1, 2, 3)

Zusammenfassung

• Traffic, dem kein Traffic Shaper zugeordnet ist, kommt in eine der Warteschlangen 0, 1 oder 2. Je nach globaler oder ToS Priorität
• Bei Traffic, welchem ein Traffic Shaper zugeordnet ist, muss man es differenzierter betrachten. Überschreitet der Traffic nicht die “garantierte Bandbreite” so kommt, dieser Traffic in die Warteschlange 0 und ist somit gegenüber Traffic ohne Traffic Shaper bevorzugt.
• Der Traffic, der die im Traffic Shaper garantierte Bandbreite überschreitet, kommt in eine der Warteschlangen 1..5. Je nach Traffic Shaper Priorität, globaler oder ToS Priorität. Auf jeden Fall wird er gegenüber Traffic ohne Traffic Shaper nachrangig behandelt.
• Überschreitet der Traffic die maximale Bandbreite vom Traffic Shaper, so wird der Traffic gedroppt.

Insgesamt heisst das also, dass Traffic ohne Traffic Shaper immer in einer besseren Warteschlange liegt, als der gleiche Traffic, welcher über den Traffic Shaper die Priority high, medium oder low zugeordnet bekommt. D.h. dass Traffic über den Traffic Shaper prinzipiell eher “verlangsamt” wird (sofern man nicht in die “garantierte Bandbreite” fällt). Um das zu verhindern und sinnvoll mit Traffic Shaper arbeiten zu können, sollte sämtlicher Traffic (,welcher die Fortigate auf einem bestimmten Interface verlässt,) über Traffic Shaper geführt werden. Nur so kann dieser Traffic sinnvoll über die Warteschlangen gegeneinander abgewogen werden.

Nachtrag 1 :

Erwähnenswert ist noch der Traffic Shaping im Zusammenhang mit dem Session Offloading vom NP. Der NP unterstützt die Prioritäts-Warteschlangen und auch die maximale Bandbreite – aber nicht die garantierte Bandbreite! Wird Traffic im Normalfall ge-offloaded und konfiguriert man dann auf die entsprechende Firewall-Regel einen Traffic Shaper mit garantierter Bandbreite, so wird dieser Traffic automatisch von der CPU bearbeitet und nicht mehr ge-offloaded, d.h. man verlangsamt den Traffic durch die Konfiguration der garantierten Bandbreite…