Provya

Expertise pfSense

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

[pfSense] Configurer la priorisation de trafic avec CBQ

icon 28/08/2019 - 27 commentaires

English version: [pfSense] Configuring traffic shaping with CBQ

pfSense offre plusieurs mécanismes de priorisation de trafic. Après notre premier article présentant le mode de fonctionnement des trois principaux mécanismes de priorisation ([pfSense] Comprendre la priorisation de trafic), nous procédons dans cet article à sa mise en application à l'aide du protocole CBQ.

Article mis à jour le  : 28/08/2019

Si nos besoins en règles de priorisation de trafic sont des besoins traditionnels, il est conseillé de travailler avec CBQ.

Nous ne détaillerons pas ici le mode de fonctionnement de CBQ, ni ses avantages ou inconvénients. Nous traiterons d'un cas pratique de mise en application sous pfSense et des bonnes pratiques à respecter.
Le mode de fonctionnement de CBQ est présenté dans notre article dédié : [pfSense] Comprendre la priorisation de trafic



Généralités sur la priorisation de trafic


Pour la mise en place de la priorisation de trafic, nous allons configurer d'un côté des queues (file d'attente) et de l'autre des rules (règles d'affectation des paquets dans ces files d'attente) :
  • Queues : "file d'attente" à laquelle est associée une priorité de traitement et une bande passante
  • Rules : "règle d'affectation" définissant la queue par laquelle un paquet va transiter. Ces règles sont les mêmes que pour la configuration du firewall : filtrage par port et adresse IP source, port et adresse IP de destination, protocole utilisé, etc.

La priorité de traitement la plus forte doit toujours être donnée aux applications nécessitant un traitement temps-réel. Typiquement, la VoIP.

La priorité suivante doit toujours être donnée aux acquittements TCP (ACK). Les ACK correspondent à des sortes d'accusé de réception sur les données transmises en TCP. Il est important que ces paquets soient prioritaires car autrement l'émetteur considérera que les paquets envoyés n'ont pas été correctement reçus et procédera à leur réémissions. Ce qui, par effet boule de neige, augmentera la charge sur la ligne Internet.

On considère que la bande passante nécessaire pour les ACK est de 10 à 15% du débit maximum offert en dowload (nous verrons en fin d'article comment affiner ce réglage).

Enfin, par convention de nommage, les queues commencent toujours par la lettre "q" (ex : qVoIP, qACK, qDefault, ...).
Pour le nommage des queues, et afin de facilité la lisibilité, nous recommandons l'utilisation du lowerCamelCase.



Cas d'application


Nous partirons du cas d'application suivant : une entreprise disposant d'une connexion Internet SDSL de 3Mbps sur laquelle transite sa téléphonie (VoIP) vers son opérateur SIP et le reste de sa data (surf, messagerie, etc.).

Le besoin est de prioriser sa téléphonie afin de garantir la qualité des communications et de disposer d'une répartition dynamique de sa bande passante.

Nous respecterons le principe KISS et mettrons en place les trois queues suivantes :
  • qVoIP : ce sera la queue réservée à la téléphonie
  • qACK : ce sera la queue réservée aux paquets ACK
  • qDefaut : la queue par défaut par laquelle nous ferons passer le reste du trafic

Il est important de démarrer avec un nombre de queues réduit et sur des règles d'affectation simples. Puis, de procéder à du fine-tuning si nécessaire.

La queue qVoip disposera de la priorité la plus forte et d'une bande passante de 1Mbps (ce qui correspond environ à 10 appels simultanés avec le codec G.711)
La queue qACK disposera de la priorité suivante et d'une bande passante de 10% du débit max en download, soit 300Kbps.
Enfin, la queue qDefaut disposera d'une priorité assez faible (et du reste de la bande passante) permettant l'ajout ultérieur de queues avec des priorités intermédiaires en cas de besoin.



Configuration des queues


Nous commençons par la configuration des queues sur l'interface WAN.

Se rendre dans le menu Firewall > Traffic Shaper :

menu Firewall > Traffic Shaper pfSense - Provya


Dans l'onglet « By Interface » (celui par défaut), cliquer sur « WAN » :

création file de priorisation de trafic pfSense - Provya


Renseigner les champs comme suit :
  • Enable/Disable : cocher la case pour activer la priorisation de trafic sur l'interface WAN
  • Scheduler Type : choisir "CBQ"
  • Bandwidth : indiquer le débit max en upload diminué de 10% (soit 2700Kbps)
  • Queue Limit : laisser vide (sauf si l'on souhaite modifier la taille du buffer de paquets)
  • TBR Size : laisser vide

Cliquer sur le bouton "Save" pour valider la configuration.

Exemple de résultat obtenu :

détails configuration priorisation de trafic pfSense - Provya


À noter : ne pas tenir compte pour le moment du message nous invitant à appliquer les changements. Nous le ferons lorsque nous aurons fini de configurer l'ensemble des queues.

Nous allons maintenant créer les queues. Pour cela, se repositionner sur l'interface "WAN" :

création file de priorisation de trafic pfSense - Provya


Puis cliquer sur le bouton "Add new Queue".

Renseigner les champs comme suit :
  • Enable/Disable : cocher la case pour activer la file d'attente
  • Queue Name : le nom de la file d'attente. Ici, ce sera "qVoIP"
  • Priority : on choisit "7"
  • Queue Limit : laisser vide (sauf si l'on souhaite modifier la taille du buffer de paquets)
  • Scheduler options : laisser vide
  • Description : une description optionnelle
  • Bandwidth : la bande passante allouée à la queue. Dans notre exemple, "1000 Kbps"
  • Scheduler specific options : cocher cette case afin d'activer le partage dynamique de bande-passante pour cette queue

Cliquer sur le bouton "Save" pour valider la configuration.

Exemple de résultat obtenu :

création file qVoIP QoS pfSense - Provya


Notre première queue est créée. Pour la création de la suivante, nous nous repositionnons sur l'interface WAN (l'icône a pris la forme d'un dossier) :

dossier queue wan QoS pfSense - Provya


Puis cliquer sur le bouton "Add new Queue".

Renseigner les champs comme suit :
  • Enable/Disable : cocher la case pour activer la file d'attente
  • Queue Name : le nom de la file d'attente. Ici, ce sera "qACK"
  • Priority : on choisit "6"
  • Queue Limit : laisser vide (sauf si l'on souhaite modifier la taille du buffer de paquets)
  • Scheduler options : laisser vide
  • Description : une description optionnelle
  • Bandwidth : la bande passante allouée à la queue. Dans notre exemple, "300Kbps"
  • Scheduler specific options : cocher cette case afin d'activer le partage dynamique de bande-passante pour cette queue

Cliquer sur le bouton "Save" pour valider la configuration.

Exemple de résultat obtenu :

création file qACK QoS pfSense - Provya


Notre seconde queue est créée. Pour la création de la troisième et dernière queue (la queue par défaut), nous nous repositionnons sur l'interface WAN.
Puis nous cliquons sur le bouton "Add new Queue".

Renseigner les champs comme suit :
  • Enable/Disable : cocher la case pour activer la file d'attente
  • Queue Name : le nom de la file d'attente. Ici, ce sera "qDefaut"
  • Priority : on choisit "2"
  • Queue Limit : laisser vide (sauf si l'on souhaite modifier la taille du buffer de paquets)
  • Scheduler options : cocher la case "Default Queue"
  • Description : une description optionnelle
  • Bandwidth : la bande passante allouée à la queue. Dans notre exemple, "1400Kbps"
  • Scheduler specific options : cocher cette case afin d'activer le partage dynamique de bande-passante pour cette queue

Cliquer sur le bouton "Save" pour valider la configuration.

Exemple de résultat obtenu :

création file qDefaut QoS pfSense - Provya


L'ensemble de nos queues côté WAN est créé. Nous disposons de 3 queues :
  1. qVoIP : pour le trafic à destination ou en provenance du fournisseur SIP
  2. qACK : pour le trafic ACK (acquittement TCP)
  3. qDefaut : pour le reste du trafic

Nous allons maintenant activer la priorisation de trafic sur l'interface LAN. Cliquer sur « LAN » :

création file de priorisation de trafic QoS pfSense - Provya


Renseigner les champs comme suit :
  • Enable/Disable : cocher la case pour activer la priorisation de trafic sur l'interface LAN
  • Scheduler Type : choisir "CBQ"
  • Bandwidth : indiquer le débit max en download diminué de 10% (soit 2700Kbps)
  • Queue Limit : laisser vide (sauf si l'on souhaite modifier la taille du buffer de paquets)
  • TBR Size : laisser vide

Cliquer sur le bouton "Save" pour valider la configuration.

Exemple de résultat obtenu :

détails configuration priorisation de trafic QoS pfSense - Provya


Nous allons maintenant dupliquer les queues créées sur l'interface WAN vers l'interface LAN. Se rendre dans l'onglet "By Queue" :

menu By Queue QoS pfSense - Provya


Sélectionner la queue "qVoIP", puis, dans la section "LAN", choisir "Clone Shaper on this interface" :

cloner QoS entre interfaces pfSense - Provya


Procéder de la même manière avec les queues "qACK" et "qDefaut".

Nos queues sont toutes créées :

afficher liste des queues QoS pfSense - Provya


Nous validons l'ensemble de ces paramétrages en cliquant sur le bouton "Apply Changes" :

Bouton Apply changes pfSense - Provya




Configuration des rules


Nous allons maintenant créer les règles d'affectation du trafic dans ces queues.
La configuration s'effectue au niveau des règles du Firewall. Elle peut s'effectuer directement depuis les règles existantes, ou en créant des règles génériques sur l'interface "Floating".

Les règles de vérification du Firewall s'opèrent dans l'ordre suivant :
  1. Règles définies en Floating
  2. Règles définies sur les groupes d'interfaces
  3. Règles définies sur les interfaces logiques

Pour un rappel sur le mode de fonctionnement des interfaces réseaux ou groupe d'interfaces sous pfSense, se référer à l'article dédié [pfSense] Comprendre la gestion des interfaces réseaux.

Dans notre cas, nous ne toucherons pas aux règles de filtrage en place sur nos interfaces ou groupe d'interfaces, mais nous créerons des règles spécifiques d'affectation du trafic depuis l'interface "Floating".
C'est ce que nous recommandons de faire systématiquement. Ainsi, nous ne mélangeons pas la partie "filtrage firewall" de la partie "règles de priorisation de trafic".

Pour cela, se rendre dans le menu "Firewall" > "Rules", puis sur l'onglet "Floating" :

menu Firewall Rules Floating pfSense - Provya


La méthode de création des règles de firewall depuis l'onglet "Floating" est exactement la même que pour n'importe quelle interface. La seule différence est la présence de l'action "Match".

L'action "Match" signifie qu'aucune décision ne sera prise quant à l'acceptation (Pass) ou au refus (Block ou Reject) du paquet, mais que s'il correspond (="match") aux critères définis (adresse IP source ou destination, port source ou destination, système d'exploitation, protocole, etc.), alors il se verra appliquer les options définies dans les "Advanced Options" (comme les queues d'affectation ou la gateway, par exemple).

Si nous reprenons notre exemple, nous devons créer les règles suivantes :
  1. Une première règle pour diriger le trafic en provenance de l'opérateur de VoIP vers la queue "qVoIP"
  2. Une seconde règle pour diriger le trafic à destination de l'opérateur de VoIP vers la queue "qVoIP"
  3. Une dernière règle pour diriger tous les paquets ACK du trafic TCP vers la queue "qACK"

Nous créons notre première règle en cliquant sur le bouton "Add" et renseignons les champs comme suit :
  • Action : nous choisissons "Match"
  • Interface : nous choisissons l'interface "WAN"
  • Direction : nous choisissons "in" (c'est-à-dire arrivant sur l'interface WAN)
  • Protocol : nous choisissons "UDP" (les protocoles de VoIP SIP et RTP utilisant UDP)
  • Source : nous choisissons "Single host or alias" et renseignons l'adresse IP du serveur VoIP de l'opérateur

Exemple de résultat obtenu :

règle de floating QoS pfSense - Provya


Puis, dans la section "Advanced Options", nous cliquons sur le bouton "Display Advanced" et localisons en bas de page la ligne "Ackqueue / Queue". La première liste déroulante correspond à la queue d'acquittement (paquets ACK), la seconde liste déroulante correspond à la queue en tant que telle.

On ne peut choisir une "Ackqueue" (première liste déroulante), que si on a choisi une queue (seconde liste déroulante).

Ici, nous choisissons la queue "qVoIP" et nous laissons l'Ackqueue à "none" (les protocoles de VoIP SIP et RTP utilisant UDP).

Exemple de résultat obtenu :

advanced options pour règle de floating QoS pfSense - Provya


Enfin, nous cliquons sur "Save" pour valider la règle.
Voila notre première règle créée :

exemple règle floating qVoIP pour QoS pfSense - Provya


Nous créons une nouvelle règle en cliquant sur le bouton "Add".

Nous renseignons les champs comme suit :
  • Action : nous choisissons "Match"
  • Interface : nous choisissons l'interface "WAN"
  • Direction : nous choisissons "out" (c'est-à-dire sortant par l'interface WAN)
  • Protocol : nous choisissons "UDP"
  • Destination : nous choisissons "Single host or alias" et renseignons l'adresse IP du serveur VoIP de l'opérateur
Dans la section "Advanced Options", nous cliquons sur le bouton "Display Advanced", puis localisasons la ligne "Ackqueue / Queue".
Nous laissons la première liste déroulante à "none", et choisissons "qVoIP" pour la seconde.

Exemple de résultat obtenu :

exemple 2 règle floating qVoIP pour QoS pfSense - Provya


Nous cliquons sur "Save" pour valider la règle.

Nous créons enfin la dernière règle en cliquant sur le bouton "Add".

Nous renseignons les champs comme suit :
  • Action : nous choisissons "Match"
  • Interface : nous choisissons les interfaces "WAN" et LAN
  • Protocol : nous choisissons "TCP"
Dans la section "Advanced features", nous cliquons sur le bouton "Advanced" se trouvant sur la ligne "Ackqueue/Queue".
Nous choisissons "qACK" dans première liste déroulante à "none", et choisissons "qDefaut" dans la seconde.

On clique sur "Save" pour valider la règle.

Exemple de résultat obtenu :

exemple règle floating qACK et qDefaut pour QoS pfSense - Provya


Nos trois règles d'affectation sont créées. Nous cliquons sur "Apply changes" pour valider la configuration.

exemple complet priorisation de trafic QoS pfSense - Provya




Remise à zéro de la table d'état


Les règles de priorisation de trafic ne s'appliquent que sur les nouvelles connexions. Les connexions en cours (visibles dans la table d'état) ne sont pas impactées par les règles que nous venons de créer.
Aussi, pour que ces règles soient prises en compte totalement, il est nécessaire de vider la table d'état.

Pour cela, se rendre dans le menu "Diagnostics" > "States".
Cliquer sur l'onglet "Reset States", puis sur le bouton "Reset" :

Reset table d'états pfSense - Provya


À noter : la page va charger sans fin. Ce comportement est normal : l'état de la connexion entre notre navigateur et le pfSense vient d'être réinitialisé.
Il suffit de rafraîchir la page pour continuer.



Analyse et Debug


Les statistiques d'utilisation des queues se trouvent dans le menu "Status" > "Queues" :

menu Status Queues pfSense - Provya


Si l'on voit des "drops" de paquets (avant-dernière colonne du tableau) dans une des queues prioritaires (qVoIP ou qACK), cela signifie que la bande passante qui leur est allouée est trop faible et qu'il faut, a priori, l'augmenter.

En revanche, avoir du drops de paquets dans les queues disposant d'une priorité faible (qDefaut) est normal : en cas de saturation de la ligne Internet, ces queues ne sont pas prioritaires.


La priorisation de trafic est maintenant en place sur notre pfSense !



Pour aller plus loin


[pfSense] Comprendre la priorisation de trafic
[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


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtrem pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Comprendre la priorisation de trafic

icon 05/06/2019 - 16 commentaires

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


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtrem pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :