Provya

Expertise pfSense

Sommaire des articles  -  Liens & Actualités  -  Firewall pour pfSense

[pfSense] Comprendre la priorisation de trafic

icon 05/06/2019

Dans pfSense, il existe 3 principaux mécanismes de priorisation de flux :

- CBQ - Class Based Queueing
- PRIQ - Priority Queueing
- HFSC - Hierarchical Fair-Service Curve

PRIQ est un protocole de priorisation très simple (simpliste ?) mais nécessitant de faire très attention dans sa configuration.

CBQ est sans doute le protocole à utiliser dans la plupart des cas pour une entreprise souhaitant une gestion de la priorisation de trafic simple et efficace.

HFSC est sans conteste le protocole le plus évolué permettant un niveau de souplesse avancé, au prix d'une forte complexité...


Nous nous proposons ici de passer en revue ces différents mécanismes.
Dans un prochain article, nous verrons comment les mettre en œuvre dans pfSense.



CBQ - Class Based Queueing


CBQ est un algorithme permettant de diviser la bande passante d'une connexion en multiples queues ou classes.
Le trafic est assigné à l'une des queues, en fonction du protocole source/destination utilisé, du numéro de port, de l'adresse IP, etc.

Chaque queue se voit attribuer une bande passante et une priorité.

Les queues CBQ sont organisées de manière hiérarchique. Au sommet, nous retrouvons la queue "ROOT" (racine).
Chaque queue fille partage la bande passante de sa queue mère.

Il est également possible d'autoriser une queue à utiliser la bande passante de sa queue parente si celle-ci est sous-utilisée.


Exemple :

Root Queue (5Mbps)
	- Queue 1 (2Mbps)
	- Queue 2 (2Mbps)
	- Queue 3 (1Mbps)

La somme de la bande passante attribuée aux queues filles ne peut pas être supérieure à la bande passante totale de la queue mère.
Ainsi, dans notre exemple, la somme des bandes passantes des queues 1, 2 et 3 ne peut être supérieure à la bande passante de la queue Root.

Chaque queue fille peut elle-même avoir des queues filles :

Root Queue (5Mbps)
	- Queue 1 (2Mbps)
		Queue VoIP (1Mbps)
		Queue SSH (1Mbps)
	- Queue 2 (2Mbps)
		Queue HTTP (800Kbps)
		Queue VNC (200Kbps)
	- Queue 3 (1 Mbps)

Pour chacune de ces queues, on peut activer l'emprunt ("borrow") de bande passante à sa queue mère :

Root Queue (5Mbps)
	- Queue 1 (2Mbps)
		Queue VoIP (1Mbps - borrow)
		Queue SSH (1Mbps)
	- Queue 2 (2Mbps)
		Queue HTTP (800Kbps)
		Queue VNC (200Kbps)
	- Queue 3 (1 Mbps)

Dans l'exemple ci-dessus, la queue VoIP dispose d'une bande passante de 1Mbps. Cependant, elle peut potentiellement utiliser jusqu'à 2Mbps (bande passante allouée à sa queue mère - Queue 1) si la queue SSH n'est pas pleine.

Une priorité est attachée à chaque queue. La priorité la plus forte sera préférée en cas de congestion. Si deux queues ont la même priorité, la distribution s'opère suivant un processus de type round-robin.

Root Queue (5Mbps)
	- Queue 1 (2Mbps, priorité 1)
		Queue VoIP (1Mbps - borrow, priorité 5)
		Queue SSH (1Mbps, priorité 3)
	- Queue 2 (2Mbps, priorité 1)
		Queue HTTP (800Kbps, priorité 1)
		Queue VNC (200Kbps, priorité 2)

Dans notre exemple ci-dessus, la queue 1 et la queue 2 ayant la même priorité, aucune des deux queues ne sera priorisée l'une par rapport à l'autre. Durant le temps où la queue 1 sera traitée, les queues filles seront traitées en même temps. La queue VoIP sera traitée en priorité par rapport à la queue SSH (en cas de congestion).
Il est à noter qu'uniquement les queue fille de la même queue mère sont comparées entre-elles (c'est-à-dire que la priorité de la queue VoIP sera comparée à la priorité de la queue SSH, mais ne sera pas comparée à la queue HTTP par exemple).


Davantage d'informations sur le protocole CBQ : CBQ sur openbsd.org - EN



PRIQ - Priority Queueing


PRIQ est un protocole permettant de définir plusieurs queues attachées à une interface et d'y affecter une priorité. Une queue avec une priorité supérieure sera toujours traitée avant une queue avec une priorité plus faible.
Si deux queues ont à la même priorité, la distribution se fera suivant le processus round-robin.

La construction des queues PRIQ est plate (il n'y a pas de notion de queue mère et de queue fille) - il n'est pas possible de définir une queue au sein d'une autre queue.

Une queue "ROOT" (racine) est définie, qui sera la bande passante totale de la connexion. Les autres queues sont définies sous la queue ROOT.

Exemple :

Root Queue (2Mbps)
	- Queue 1 (priorité 2)
	- Queue 2 (priorité 1)

La queue Root est définie comme disposant de 2Mbps. La queue 1 disposant de la plus forte priorité, l'ensemble de ses paquets seront traités en priorité. Tant qu'il existe des paquets dans la queue 1, la queue 2 ne sera pas traitée.
Dans chaque queue, les paquets sont traités dans l'ordre FIFO (First IN First OUT).

/!\ Attention : il est bien important de comprendre que dans le processus PRIQ, les paquets se trouvant dans les queues disposant de la priorité la plus élevée sont toujours traités avant les paquets des autres queues.
Ainsi, si une queue disposant d'une priorité élevée reçoit un flux de paquet continu, les queues disposant d'une priorité plus faible seront peu, voire pas traitées.


Davantage d'informations sur le protocole PRIQ : PRIQ sur openbsd.org - EN



H-FSC


HFSC est un algorithme évolué de traitement hiérarchique permettant de répartir la bande passante d'un lien et de contrôler l'allocation de ressources en fonction de la bande passante et de la latence.

Tout comme dans l'algorithme CBQ, les queues HFSC sont organisées de manière hiérarchique. Au sommet, nous retrouvons la queue "ROOT" (racine).
Chaque queue fille partage la bande passante de sa queue mère.

Chaque queue fille peut elle-même avoir des queues filles :

Root Queue (5Mbps)
	- Queue 1 (2Mbps)
		Queue VoIP (1Mbps)
		Queue SSH (1Mbps)
	- Queue 2 (2Mbps)
		Queue HTTP (800Kbps)
		Queue VNC (200Kbps)
	- Queue 3 (1 Mbps)

Une priorité est donnée à chaque queue. Les priorités vont de 0 (priorité la plus faible) à 7 (priorité la plus forte). Comme pour CBQ, ces priorités ne sont appliquées qu'en cas de saturation du lien.

Root Queue (5Mbps)
	- Queue 1 (2Mbps, priorité 1)
		Queue VoIP (1Mbps, priorité 5)
		Queue SSH (1Mbps, priorité 3)
	- Queue 2 (2Mbps, priorité 1)
		Queue HTTP (800Kbps, priorité 1)
		Queue VNC (200Kbps, priorité 2)


Qlimit


Chaque queue se voit attribuée en plus un paramètre "Qlimit". Qlimit correspond à un buffer (tampon) qui va se remplir lorsque la bande passante attribuée à la queue sera saturée : plutôt que de rejeter les nouveaux paquets arrivant, ceux-ci vont être mis en file d'attente dans ce buffer.

La valeur de Qlimit (la taille du buffer donc) est exprimée en nombre de paquets. Par défaut, sa valeur est de 50.

Un fois que le buffer définit par Qlimit est saturé, les nouveaux paquets sont supprimés (drop).

Il n'est pas nécessaire, et sûrement contre-productif, de définir une valeur trop grande pour Qlimit : cela ne solvera pas un problème de saturation de bande-passante. Une trop grande valeur peut entraîner un "buffer bloat".

Pour calculer la bonne valeur de Qlimit, il faut se demander combien de temps nous souhaitons garder un paquet dans le buffer.

Si le concept de MTU ou de latence ne vous est pas familier, lisez tout d'abord les liens cités précédemment.

Si l'on souhaite qu'un paquet reste bufferisé au maximum 0,5 seconde (ce qui est déjà long), le calcul à effectuer pour connaître la valeur de Qlimit est le suivant :

(BP / 8) / MTU = nb paquets/sec.
Avec :
BP : bande passante (en bits/s)
MTU : MTU du lien (en bytes)

Par exemple, si nous disposons d'un lien offrant 10Mbps en upstream ayant une MTU de 1500 bytes :

(10.000.000 / 8) / 1500 = 833 pq/sec

Soit, si l'on souhaite une bufferisation de 0,5 sec sur notre lien : 833x0,5 = 416 paquets (=valeur de notre Qlimit)

Si vous ne souhaitez pas vous lancer dans de tels calculs, laissez la valeur par défaut de Qlimit (50 paquets).


realtime


Ce paramètre permet de définir la bande-passante minimale garantit en permanence à la queue.


upperlimit


Le paramètre upperlimit permet de définir une limite haute de bande passante que la queue ne pourra jamais dépasser.
Cela permet, par exemple, de limiter l'usage fait de la bande passante pour un type de service ou d'utilisateurs.


linkshare


Ce paramètre remplit la même fonctionnalité que le paramètre "bandwith" définit plus haut. C'est-à-dire qu'il permet de définir la bande-passante disponible pour une queue ; cette bande-passante pouvant être empruntée à d'autres queues.

Aussi, si nous définissons le paramètre "bandwith" ET le paramètre "link share (m2)", c'est le paramètre "linkshare m2" qui sera pris en compte.


Ainsi, nous avons les paramètres suivants :
  1. realtime : bande-passante minimale garantie à une queue
  2. linkshare : bande-passante globale attribuée à la queue (utilisée une fois que realtime est plein)
  3. upperlimit : bande-passante maximale que la queue ne pourra jamais dépassée
  4. bandwith : redondant avec linkshare. Peut être utilisé si l'on ne souhaite pas utiliser le mécanisme NLSC.

Il est important de comprendre que le paramètre "linkshare" n'est utile que si l'on souhaite activer le mode NLSC (non linear service curve). Autrement, seul le paramètre "bandwith" peut être utilisé dans le paramétrage des queues.


NLSC


NLSC est un mécanisme permettant de définir une bande-passante initiale, puis après un certain temps, une bande-passante définitive.
Ainsi, on va pouvoir définir une bande-passante qui va évoluer dans le temps.

Il existe 3 paramètres pour la configuration de NLSC :
  1. m1 : bande passante initiale attribuée à la queue
  2. m2 : bande passante définitive attribuée à la queue
  3. d : durée (en ms) durant laquelle la bande passante attribuée à la queue est la bande passante initiale (m1), avant de devenir la bande passante définitive (m2)

NLSC est principalement utilisé dans le but d'offrir un maximum de bande-passante sur un certain laps de temps, puis de brider cette bande-passante. Ainsi, ce "bridage" n'impacte que les gros fichiers transitant dans la queue concernée.

NLSC est activable aussi bien sur les directives realtime, upperlimit et linkshare.
Si l'on ne souhaite pas faire évoluer la bande-passante dans le temps, seul le paramètre m2 doit être défini.


Options


Il existe plusieurs options que l'on peut définir sur nos queues. Actuellement, elles sont au nombre de quatre :
  1. Default queue : permet de définir la queue par défaut. Il ne peut y avoir qu'une seule queue par défaut par interface.
  2. Explicit Congestion Notification (ECN) : ECN permet d'envoyer une notification de congestion sur le réseau afin de limiter le "drop" de paquets. N'est utilisable qu'entre deux équipements le supportant.
  3. Random Early Detection (RED) : utilisé avec ECN, offre un mécanisme de détection de congestion (avant qu'elle n'ait lieu).
  4. Random Early Detection In and Out (RIO) : idem RED.

Nous ne recommandons pas l'usage des paramètres RED, RIO et ECN.

Une fois tous ces paramètres appliqués, si nous reprenons notre exemple de queues définit précédemment :

Root Queue (5Mbps)
	- Queue 1 (2Mbps, upperlimit: 3Mbps, realtime: 1Mbps)
		Queue VoIP (1Mbps, realtime: 1Mbps, qlimit: 500)
		Queue SSH (1Mbps, qlimit 500)
	- Queue 2 (2Mbps, upperlimit: 3Mbps, default)
		Queue HTTP (800Kbps, realtime: 500Kbps)
		Queue VNC (200Kbps, qlimit: 500)


Nous venons de passer en revu les 3 principaux mécanismes de priorisation de trafic proposés dans pfSense.

Dans un prochain article, nous verrons comment les configurer et les activer dans pfSense.



Pour aller plus loin


[pfSense] Configurer la priorisation de trafic avec CBQ
[pfSense] Utiliser les limiters pour contrôler la bande-passante par utilisateur
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous


Retrouvez nos services et firewall pour pfSense & OPNsense



Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Soho pour pfSense et OPNsense         Firewall pro-Maxi pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

16 commentaires

météo blog - 11/03/2015 à 18:55:24

Un blog très intéressant ! Merci pour cette découverte du jour, Bien à vous.

@répondre #lien

Tchek - 08/08/2016 à 00:43:37

Très bon article. Merci beaucoup.

Bien à vous.

@répondre #lien

Hervé M - 05/08/2017 à 23:04:56

Merci d'avoir pris le temps d'expliquer clairement la QOS sous Pfsense. Un de nos administrateurs ayant commencé par implémenter en premier le H-SFC sans trop comprendre ce qu'il avait fait. Résultat : effets non satisfaisants.
Je vais donc reprendre le travail en implémentant le CBQ qui m'a paru dans l'explication très claire et sans doute suffisante pour nos besoins.
Bonne continuation !

@répondre #lien

MONTA - 18/11/2017 à 09:35:00

Bonjour,

Je n'arrive pas à trouver le document qu'il me faut depuis depuis, sur la priorisation de groupe d'adresse IP dans un même Alias et surtout le partage de bande passante dynamique des adresse IP dans notre LAN. Nous n'avons pas besoin de prioriser des différents trafics (VoiP, ...) juste surf sur internet simple http et https. Pourrais-je utiliser encore CBQ, ... ou avez-vous d'autres suggestions SVP. Je voudrais prioriser les IP : 192.168.1.1 - 192.168.1.5 avec une priorisation de 1 à 5 puis diviser la reste des bandes passantes (ex : 2Mpbs) pour 20 personnes, c'est à dire chacun a 102,4 Kbps équitablement. Très très GRAND MERCI à vous.

@répondre #lien

Guillaume - 19/11/2017 à 10:08:27

@MONTA :
Bonjour,

CC du commentaire que je vous ai laissé sur l'autre article :

CBQ peut effectivement être adapté à ce que vous souhaitez faire en terme de priorisation. Vous définissez des files d'attentes (queues), puis des règles d'affectation du trafic dans ces files. Ces règles peuvent être pour des services spécifiques (HTTP, SIP, etc.) ou pour des adresses IP (192.168.1.1 à .5), par exemple.

Pour le partage équitable de bande-passante entre vos 20 utilisateurs, je vous recommande de regarder du côté des limiters qui est clairement adapté pour cet usage.
Nous avons justement un article en cours de rédaction sur l'implémentation des limiters. Il devrait être publié d'ici la fin de l'année.

Cordialement,

Guillaume
--
Provya

@répondre #lien

MONTA - 20/11/2017 à 08:48:30

Merci beaucoup de votre aimable collaboration et votre article nous aide beaucoup. Je pense que beaucoup d'administrateur a le même problème de partage de bande passante. Malheureusement si on définit un limiteur pour un alias (groupe d'adresse IP) le premier utilisateur bouffe la bande passante et les restes n'ont plus. Donc il faut faire un limiteur par IP donc un RULE par IP, mais comme nous nous avons 70 utilisateurs. Encore Merci beaucoup

@répondre #lien

Guillaume - 20/11/2017 à 18:52:50

@MONTA :
Bonjour,

Non, les limiters ne fonctionnent pas comme ça. Et heureusement... :-)

La méthodologie est la suivante :
Limiter le débit d'upload
Vous créez un limiter (appelons le "Upload") en précisant le débit (ex : 1 Mbps) et pour le champ "Mask", vous laissez à "None".
Puis vous cliquez sur "Add new queue" afin d'ajouter une file enfante à ce limiter.
Dans la configuration de cette file enfante (que nous appellerons "Upload_LAN"), pour le champ "Mask", vous choisissez "Source addresses".

Limiter le débit de download
Vous créez un limiter (appelons le "Download") en précisant le débit (ex : 10 Mbps) et pour le champ "Mask", vous laissez à "None".
Puis vous cliquez sur "Add new queue" afin d'ajouter une file enfante à ce limiter.
Dans la configuration de cette file enfante (que nous appellerons "Download_LAN"), pour le champ "Mask", vous choisissez "Destination addresses".

Appliquer sur les règles firewall
Vous éditez votre (ou vos) règle(s) firewall de l'interface LAN et allez dans les options avancées (bouton "Display Advanced").
Pour le champ "In / Out pipe", vous choisissez pour la première liste déroulante la file "Upload_LAN" et pour la seconde liste déroulante la file "Download_LAN".

Vous aurez alors une bande-passante équitablement répartie entre tous vos utilisateurs du LAN.

Pensez bien-sûr à sauvegarder et appliquer les changements pour qu'ils soient pris en compte.

Mes explications sont succinctes, mais vous devriez vous en sortir.
Comme indiqué dans mon précédent commentaire, un article détaillé sortira d'ici la fin de cette année.

(L'article est sorti : pfSense - Utiliser les limiters pour contrôler la bande-passante par utilisateur)

N'hésitez pas à revenir partager vos résultats.

Cordialement,

Guillaume
--
Provya

@répondre #lien

MONTA - 21/11/2017 à 07:15:24

Bonjour,

Vraiment reconnaissant de votre collaboration. Nous allons appliquer cette méthode et vous tenir au courant du résultat bientôt.
Encore MERCI.

@répondre #lien

MONTA - 21/11/2017 à 08:37:54

Désolé si nous revenons très tôt, nous avons utilisé la version 2.3.3-RELEASE FreeBSD 10.3-RELEASE-p16 de Pfsense mais nous n'avons pas trouvé la configuration de file enfante dont vous avez préciser. "Dans la configuration de cette file enfante (que nous appellerons "Download_LAN"), pour le champ "Mask", vous choisissez "Destination addresses". Nous devons attendre l'article correspondant mais si vous pouvez répondre avant, c'est beaucoup mieux
Toutes nos excuses. Merci d'avance

@répondre #lien

Guillaume - 21/11/2017 à 09:16:40

@MONTA :
Bonjour,

Sur votre limiter, vous avez un bouton en bas de page : "Add new queue".

Cordialement,

Guillaume
--
Provya

@répondre #lien

MONTA - 23/11/2017 à 06:39:00

Bonjour,

Nous sommes trompé sur l'ordre de configuration. Il faut sauvegarder le limiteur puis on revient à cliquer sur le bouton "Add new queue". Encore Merci beaucoup

@répondre #lien

MONTA - 24/11/2017 à 07:18:43

Bonjour,

En fin, c'est déjà Noël chez nous ici ! on a maintenant le partage de bande passante équitable entre nos utilisateurs LAN, partage dynamique selon le nombre d'utilisateur connecté, on a pu constaté directement par le menu Status-> Traffic Graph la consommation up/down ou autre Monitoring de bande passante.
Grand Merci au site www.provya.net et tous les acteurs de cet merveilleux site.
MERCI BEAUCOUP.

@répondre #lien

Autourdupc - 28/12/2017 à 13:46:46

Bonjour.

Un grand merci pour ces explications détaillées et claires.

J'utilise pfsense sur un AMD Geode en version 2.3.5-RELEASE-p1 (i386) FreeBSD 10.3.
J'ai su rmon réseau local un Raspberry Pi2 intégrant un FreePBX et je reçois des appels via un SIP OVH que je redirige au besoin sur mon téléphone Android avec ZoIPER.

Ma connexion est une ligne ADSL Free (download 7 Mbits, upload 0,65 Mbits). Autant dire que l'upload est très limité.

J'ai donc mis en place le CBQ qui fonctionne parfaitement mais je vois encore des Drops sur mon qACK de mon WAN... Je suppose qu c'est sur l'upload que j'ai ces pertes.

Quels paramétrages me conseillez-vous ?

Bien cordialement,
Laurent (Lyon)

@répondre #lien

Guillaume - 28/12/2017 à 17:44:40

@Autourdupc :
Bonjour Laurent,

Impossible de vous répondre, vous ne fournissez aucun élément de configuration (quelles queues avez-vous mis en place, quelle bande-passante avez-vous alloué à chaque queue, etc.).

Je vous invite à poster votre demande d'aide communautaire sur le forum français de pfSense : https://forum.pfsense.org/index.php?board=7.0.

Cordialement,

Guillaume
--
Provya

@répondre #lien

icon Flux RSS des commentaires de cet article