Warteschlangen beim Fortigate Traffic Shaping

Quality of Service gewann in den letzten Jahren immer wie mehr an Bedeutung. VoIP ist einer der Mechanismen, welcher in den meisten Fällen auf Traffic Priorisierung angewiesen ist. In diesem Blog-Eintrag wird aufgezeigt, wie die Fortigate mit dem Thema umgeht und mit Traffic Shaping einen Teil von QoS abdeckt.

In jeder Security Policy kann ein Traffic Shaper Objekt angegeben werden. In diesen Traffic Shaper Objekten kann definiert werden:

  • Traffic Priority (Low (Wert=3))|Medium (Wert=2)|High (Wert=1))
  • Guaranteed Bandwith (garantierte Bandbreite, die ein User oder Service konstant hat)
  • Maximum Bandwith (die Maximale Bandbreite, die ein User oder Service bekommt. Diese Bandbreite ist nicht konstant und kann auch weniger sein)
  • DSCP (DSCP kann gesetzt werden, wird aber von der Fortigate nicht umgesetzt. Wird zum Teil von Routern und Switchen verwendet)
TrafficShaper

Letztendlich arbeitet die Fortigate aber nicht nur mit 3 Warteschlangen, sondern insgesamt mit 5 verschiedenen Queues. In welche Queue das Paket gelangt, ist nicht nur von der Traffic Shaper Priority abhängig, sondern von der gesamten Paketpriorität. Diese wird wie folgt berechnet:

packet priority = ToS-based priority + Traffic-Shaper Priority

Die ToS-based priority ist eine globale Einstellung im CLI unter config system global (set tos-based-priority [low|medium|high]) und wird in Low (Wert=2), Medium (Wert=1) und High (Wert=0) unterteilt. Der Default-Wert unter FortiOS 4.3 und 5 ist Medium. Zusätzlich kann die ToS-based priority aufgrund der ToS-bits im IP Header des Pakets definiert werden. Dieses passiert ebenfalls im CLI unter config system tos-based-priority (set tos [0-15]).

Anhand dieser Werte entstehen die 5 Queues, wovon der Administrative Traffic immer in Queue 0 ist. Der Administrative Traffic beinhaltet allen Traffic, welcher nicht von der Firewall Policy reguliert wird, z.B. HTTPS / SSH Access oder IPSec Negotiation.

Wichtig ist beim Einsatz eines Traffic Shapers, dass alle Policies mit dem gleichen Source und Destination Interface ein Traffic Shaper Profil zugewiesen haben.
Wenn Sie zum Beispiel VoIP Traffic von LAN zu WAN priorisieren möchten und dieser Policy ein Traffic-Shaper Profil mit Priorität High (Wert=1) zuweisen und das ToS-Bit Medium ist (Wert=1), dann landet der VoIP Traffic in der Queue 2. Wenn aber der restliche Traffic von LAN zu WAN kein Traffic-Shaper Profil zugewiesen hat, dann ist die Priorität des Traffics 1, da per Default ToS auf Medium (Wert=1) gesetzt ist und der Traffic Shaper nicht definiert ist (Wert=0)) und somit landen diese Pakete in der Queue 1 und werden vor dem VoIP Traffic abarbeitet. Anders formuliert ist der Traffic ohne aktives Traffic-Shaper Profil immer in der Queue, welche vom ToS definiert wird – also immer höher priorisiert als der Traffic mit Traffic Shaper Profil in der Firewall Policy.
Ein IPSec VPN Interface wird als eigenständiges Interface betrachtet. Wenn wir davon ausgehen, dass das WAN1 Interface dem VPN Interface übergeordnet ist und wir von LAN –> IPSec Interface ein Traffic Shaper verwenden, so muss von LAN –> WAN1 KEIN Traffic Shaper verwendet werden.

Wenn im CLI die ToS-based priority auf High (Wert=0) gesetzt wird, dann wird der Traffic dem Administrativen Traffic gleichgestellt.

Leave a Reply

Your email address will not be published. Required fields are marked *