Traffic shaping qos

proxiel

Bonjour,

Voici un schéma qui résume l'ensemble de mon réseau.
L'ensemble des modems sont connectés sur des lignes du même opérateur. (Aucune ligne en PPPOE du fait du problème de gateway similaire)

Nous avons un seul pool gateway avec tout en tier 1.

Sur ça nous n'avons absolument aucun problème et l'infra fonctionne depuis plusieurs années maintenant.

Nous avions testés au départ avec du "Wizzard" MultiWan + Single Lan mais avons abandonné de faire de mettre le traffic shapping aussi sur les WAN car nous avions des problèmes dû aux ports aléatoires de retour.

Le problème que nous avons :

Nous créons 1 qInternet sur le Lan dans laquelle nous mettons des "Sous queues" :
qACK Priority 6
30 % de la bande passante totale

Cette queue nous l'atribuons à l'ensemble des règles pour le ACK

Nous ajoutons ensuite à la queue internet une qOthersHigh dans laquelle nous mettons les ports de 1 à 1024 et plusieurs ports connus de vpn, les ports 8001 à 8100…

Et nous ajoutons enfin une qP2P en default.

Nous y attribuons 3 Mbits

Schema final :

Lan
qInternet 120Mb
qACK 30% Minimum
qOthersHigh 60% Minimum
qP2P 3Mo (Default)

Voici l'ensemble de notre configuration.

Merci,

QOS.png_thumb

Florian22

"le probleme que nous avons est:"

=> oui ok et donc? ce probleme quel est il? quelle est la symptomatique?

concernant le stycky, on en reparlera mais je suis sur

1/ d avoir lu quelque part que ca generait le comportement de "fixation d'un client sur une sortie"
2/ de l'avoir moi même expérimenté (essai, + kill des states + essai)

=> après c'est a vous de voir si ce comportement peut poser PB. a savoir, que vous allez avoir des utilisateurs qui vont stagner sur un de vos modems.
(c'est grace a ce phenomene que vous n'avez pas de pb avec SSL et les modems en tiers 1 monogroupe)

Juve

Florian a raison, le fonctionnement du sticky est le suivant :

a la première connexion nécessitant un acheminement par une gateway, pf réalise l'élection de la gateway puis inscrit dans une table l'association client <-> gateway avec le timestamp du moment de l'élection.
a chaque nouvelle session, pf évalue cette table pour savoir si une adhérence à une gateway existe déjà. Si l'entrée existe, le timestamp est mis a jour.
pf possede un thread d'arriere plan qui toutes les secondes évalue cette table. si la différence entre le moment de l'évaluation et le timestamp est suprérieure a la valeur du timeout(configurable). Alors l'entrée est supprimée et une nouvelle élection de gateway aura lieu au prochain acheminement.

En résumé : sticky = client collé à une gateway.
Il est préférable d'avoir des regles en amont pour HTTPS par exemple, utilisant des pool failover pour ces protocoles. En jouant sur les masques côté source et plusieurs règles/pool, on peut tout a fait obtenir un loadbalancing équitable.

Bon courage.

Florian22

@Juve:

Il est préférable d'avoir des regles en amont pour HTTPS par exemple, utilisant des pool failover pour ces protocoles. En jouant sur les masques côté source et plusieurs règles/pool, on peut tout a fait obtenir un loadbalancing équitable.

Bon courage.

salut juve.

peux tu m en dire plus? (même si c'est hors sujet)

tu veux dire que si par exemple tu as 5 sorties,
et que tu as 5 origines réseau (vlan par ex)

tu peux simuler un éclatement par les regles et mettre le tier 1 different pour chacun des wan vis a vis du ssl
et mettre les 4 autres sur chacun des pools en tiers 2 .. 3 ..etc

c est pas con du tout!!! ca m etais pas venu une seconde a l esprit !!!!!!!!!! lol je me sens con la

–-
concernant le demandeur fra1000

on est bien d'accord, le stiky lui evite d'avoir donc de gros pb avec le controle d'origines/session sur ssl

je ne sais pas encore quel est la symptomatique de son pb, mais avec sticky activé,
il ne dispose que d'un balancing basé sur ce que tu décris (timestamp, assignation wan)

et donc il se retrouve avec des requêtes qui ne se distribuent pas, et ne maitrise pas qu'il puisse avoir deux ou trois utilisateurs a requetes gourmandes qui seraient aggripées sur le meme wan

(j espere que je me fais comprendre ;) ) mdr

proxiel

@Florian22:

"le probleme que nous avons est:"

=> oui ok et donc? ce probleme quel est il? quelle est la symptomatique?

Concrètement, un fois les queues créés et les floating en place, tout le traffic vers le "wan" time out.

Ping, web, etc…

(Nous avons essayé de placer les floats alternativement sur les Wans, le lan, wans+lan.)

Concernant le Sticky, oui effectivement, c'est la solution simple pour le SSL (particulièrement le HTTPS) et le multiwan.

Florian22

vous avez donc trouvé le problème, puisque il apparait avec VOTRE configuration du shaping (donc érronée)

quel type de réseau exploitez vous? (conso, profil user, profil conso, étendue)

vous avez une foule de regles, cela parait étonnant

Juve

@Florian22:

tu veux dire que si par exemple tu as 5 sorties,
et que tu as 5 origines réseau (vlan par ex)

tu peux simuler un éclatement par les regles et mettre le tier 1 different pour chacun des wan vis a vis du ssl
et mettre les 4 autres sur chacun des pools en tiers 2 .. 3 ..etc

c est pas con du tout!!! ca m etais pas venu une seconde a l esprit !!!!!!!!!! lol je me sens con la

Oui tu as compris.

Florian22

@Juve:

Oui tu as compris.

OK ;)

et dans un cas de double Nat comme celui la ?

je schematise:

1 2 3 4 5

lan wan lan wan's
<–------------------------------------------------------------------------------------------------>
CLIENT ++++++++ PASSERELLE +++++++ BALANCER --- MULTI WANS
<-------------------------------------------------------------------------------------------------->
dhcp+proxy dhcp bridges

<<------------------------->>
entre la et la

comment tu ferais pour propager la reconnaissance de sources sachant que 4 voit tout le trafic comme si il ne venait que de 3 ?

je sais c'est atypique, mais ca provient d'une utilité qui fait que Squid ne fonctionne pas en multi
donc il est mis sur la passerelle. qui contient également des fonctions de portail captif

EA1000

@Florian22:

vous avez donc trouvé le problème, puisque il apparait avec VOTRE configuration du shaping (donc érronée)

quel type de réseau exploitez vous? (conso, profil user, profil conso, étendue)

vous avez une foule de regles, cela parait étonnant

Bonjour Flo,

Je suis Ed un collaborateur de Fra.

Effectivement, le problème venait de la configuration des règles PFs, c'est sur que si on les mets en "Pass" et pas en "Queue" ça risque pas de marcher, RTFM(enu)… RTFMM même que...

Enfin au moins maintenant ça fonctionne bien. Merci pour vos idées en tout cas.

Pour répondre à ta question:

Nous fournissons un service d'accès au web dans des lieux publics.

L'étendue varie d'une dizaine de postes clients à plus d'un centaine en fonction des sites.

Nous avons sur nos pfsense le portail captif (qui bride la bp per user.), l'ensemble des règles nous permet de restreindre le service DNS à celui du PF (on a une couche de filtrage par le DNS), ainsi que de permettre l'accès à l'infra à différents prestats.

voilà voilà.

Sinon, juste pour comprendre précisément, sticky va "coller" tout le trafic d'un client à un wan, jusqu'à ce qu'il n'y ai plus de connections pour ce client?

Et de bonnes fêtes à vous au fait ^^

Florian22

quelle est la politique de service de votre réseau (j'entends par la : quels sont les flux autorisés par vos CGV et quels sont les flux que vous ne souhaitez pas voir sur votre réseau)

exemple : VPN, exemple, SMTP etc..

je vais vous repondre dans la globalité, et vous préconiser en suivant

EA1000

De façon générale, tout est autorisé sauf le P2P.

Concrètement, c'est la raison qui nous a poussés à mettre en place la QoS, à savoir laisser le trafic des "ports bien connus" passer, et bottlenecker le reste.

Au demeurant, on se doute bien qu'il suffit au client d'avoir un VPN pour faire ce qu'il veut (vu que qu'on autorise les VPNs ;D )…

Et bon réveillon à vous, avec modération! :D

Florian22

par defaut le paranoiaque que je suis fait l'inverse :

bloquer tout > autoriser ce que l on veut.

je vous invite a retirer vos rules de shaping qui sont non fiables (objet du post)
pourquoi ne pas confier la QoS a vos switches et AP, les cisco le font.

et de bosser via des rules, et pool de rules, directement sur la toute premiere interface coté clients.

par ailleurs, vous ne pouvez bloquer le p2p (sans vous aventurer dans le réseau style MACDONALDS (ports 80/443 only) et encore.. vous et moi savons que c'est contournable tout ca..)

pour ce faire, faites le via dns, en interdisant les autres dns, et en vous appuyant sur un service de blackliste dns, par categories,

bloquez le p2p (ce qui aura pour effet de mettre un terme au trackers et au annuaires)
bloquez les categories, proxy, vpn,

bloquez le vpn par rule
faites du cas par cas, si un user veut son VPN université, dérogez le. dites lui que vous le dérogez, dites lui que si l'infra VPN Université évolue, il devra vous recontacter pour MaJ, faites vous mousser en rendant un service dérogé.

a/ les VPN restent bien bloqués
b/ son VPN (innoffensif) est dérogé
c/ ca marche pour lui, vous rendez un service

=> par ailleurs, si un utilisateur veut utiliser un VPN, par defaut whynot, ce n est pas votre responsabilité qui sera engagée pour le trafic encapsulé effectué
-> Bon débarras, vous ne faites que transporter, collecter.
-> Attention, si le réseau de destination est pourri, c'est vous qui mangerez => les utilisateurs ne voient generalement peu plus loin que le bout de leur nez
-> Vous vous obligez donc a gerer les demandes SAV pour mauvaises qualité de lignes pour cause de destination VPN a chier -> travail en +

vous ne pouvez rien faire de plus, et de toutes facons en cas de pb, via ces methodes, vous remplissez vos obligations HADOPI en termes de mise a disposition d acces

(je le sais, étant été une fois ya longtemps contraint de me justifier sur un réseau en particulier qui cumulait a cause d'un utilisateur précis, de nombreux mails de procedures graduée.

n'encombrez pas votre réseau, vous ne pouvez rien faire pour empecher un utilisateur qui veut a tout prix.
et en sur encombrant le réseau, en le "nord coree-isant" vous vous ferez mal voir de ceux qui "ne veulent pas a tout prix"

faites juste le max pour vous exonnerer

n'hesitez pas a flanquer dehors un utilisateur qui ne joue pas le jeu,
mieux vaut UNE resiliation unilaterale, qu'un RENSSENTI GLOBAL des autres, parce que vous nord coreeisez le réseau,

la hadopi n'a aucun pouvoir, le seul pouvoir qu'elle a, c'est d aprecier votre bonne foi, ou votre insuffisance, et vous "faire poursuivre" ou pas, ou se retourner contre l'abonné que vous aurez bien identifié en étant pas en "insuffisance".

la liste des methodes est longues

-CGV
-Mail automatique de rappel aux CGV lorsque le proxy detecte un truc (mot clé, extension fichier)
-Anti contournement (sites proxy, vpn) dans le max du possible (sans rentrer dans le style coree du nord)

blackisting dns (confiez cela a opendns ou la concurrence, faire des blacklistes, et pire, les tenir a jour, ce n est pas votre metier)
identifier l user a chaque mail hadopi
mettre en demeure l user, l informer quil viole les CGV, l informer de la proc hadopi.
garder trace de l incident pendant 6 mois (reset hadopi)

si vous faites cela, il ne peut rien vous arriver, la hadopi ne PEUT pas vous faire poursuivre, vous n etes pas de mauvaise foi quant aux obligations d'empechement

(même si la hadopi a un discours du style '' vous etes tenu d'empecher, vous n'y avez pas reussi, c est de votre faute''

clairement non.

–
en fait vous l'aurez compris, tout ca est la pierre angulaire du dilemme qui est présent sur chaque réseau commercial
(et encore plus sur les réseaux, a population jeune, contenus-vores, peu fortunés, extremement exigeants)

A => Se proteger juridiquement
B => Proteger la qualité de service face aux trafics qui non seulement engagent votre responsabilité, et que vous devez transporter, et qui consomment des ressources globales au dépit des bonnes ressources, empecher que A-C-D atteigne B

C => Proposer un réseau le moins réstreint possible

D => Le restreindre au maximum possible en ayant l'art que ca ne puisse etre "vu/compris" que par 2-3% des utilisateurs
(les geeks, les grandes gueules qui ont tout vu et savent tout)

E => Se faire bien voir (etre vu comme un réseau fiable) par les 97% autres, (les rentables)
pour sefaire bien voir, on actionne "B"

ABCDE - pierre angulaire chiante, mais vitale dans un réseau ou les usagers ne sont pas QUE des usagers, mais des clients.

Tatave

salut salut

je dirais +1
et rajouterais un F

dire ok je le fait mais vous me signez un papier votre demande et qui vous engage nommément en cas de problème et que cela me dégage de toutes responsabilités

Florian22

nan mais tatave quand tu y penses, combien de trous ducs vont sur vpnbook.com ou autre site du style et se font bourrer le mou, et utilisent ca non stop ?

c est insecure
ca degrade potentiellement la qualité globale de la ligne (ressenti utilisateur)
ca genere des retours service client

moi c est pour cela que j interdis le VPN, je ne les autorises que lorsqu ils sont legitimes, travail, fac..
cas par cas.

–
pour mesurer l'ampleur du probleme, il suffit de voir combien de postes clients executent cacaoweb.exe
et entendre la réaction de je m en foutisme quand tu expliques au gens qu'ils ont gagné un formatage avec cette merde

les gens veulent globalement le beurre et l argent du beurre, souvent ils croient tout savoir.
interdire les VPN d anonymisation ultra mutualisés, et hors de controles

c est autant se rendre service que leur rendre. quid de la protection des données? quid de la qualité de service?

tu as des gens qui utilisent des DNS basés a l autre bout de la terre, va leur expliquer ca... t es fichu d avance, ils aiment pas qu on critique leur materiel..
lol

mieux vaut interdire l'utilisation de ce genre de choses, et forcer l homogenéisation
surtout sur des réseaux " de facs, de résidences, de travail" bref, tu m as compris

en plus tu detectes pleins de choses bizarres en faisant comme ca,
tu n imagines pas combien de retours nous avons eu, lorsque nous avons bloqué les DNS tiers

combien d'appareils dégueulasses, avaient des reglages statiques, de DNS, alors que l user ne sait meme pas ce que sait qu'un DNS

combien d'appareils avec processus malveillant, surfaient SUR NOS RESEAUX -- en NOTRE NOM -- avec des DNS de merde vereux aux états unis.

tu as beau dire que c est pour ca que le surf était finalement lent (sur nos réseaux)
tu nes que rarement cru. et ton image "fiabilité réseau" en a pris un coup

Tatave

salut salut

je répondrais a cela comme me l'avais dit en son temps mon mentor en informatique ==> un bon réseau informatique c'est un réseau sans utilisateur penses y connaitre au moins il y aura moins de "cons" dessus et que des personnes "con"pétantes sont celle qui utilisent sans chercher plus loin, c'est un outils de travail , bien que des fois même là on n'est pas sorti de l'auberge non plus et loin de là.

Cordialement

Florian22

tatave, il manque des mots et des conjonctions de coordination dans tes posts a chaque fois

c'est dur ! de te suivre