Traffic shaping qos

Florian22

hihihi

je te l avais bien dit @fra que t allais te faire rentrer dedans.

la prochaine fois ^^ la j'ai tout gloutonné le popcorn tout seul devant tes "non cordialement"! ^^

Florian22

@fra1000:

pardon c'est un peu imprécis…mais un peu de tolérance les gars quand même...

j'ai ajouté qq fichiers avec la conf du shaping

bien le merci

ps : les cahuetes et les popcorn c'est pour moi !

je veux pas foutre ma merde mais:

"j'ai donc besoin d'un expert"

enfin, bon c est vrai que par ecrit le ton fait difficilement la musique,
Mais:

si tu te fais rentrer dedans, c est parce que 1/ tu donnes aucun détails 2/ tu dis de manière détendue de la criniere "J'ai donc besoin d'un expert"

au moment ou j'ai attrappé mon popcorn, je me suis dit:

"mais attend, le gars, il croit quoi? quil est au SAV Pfsense? … a moins que ce soit @tatave qui encaisse les "support subscriptions" ce cachottier.

en tout etat de cause:

j'ai vu que tu avais envoyé des captures...
et donc? on est censé checker la config?

ce que veut te dire tatave, c'est que tu as un formulaire, que tu n'es pas obligé de respecter A LA LETTRE mais qui te permet d'avoir un cadre pour poster ta question

et surtout: pour pas que quand on lise ta question, on se dise "nan mais attend, le gars, il a fait aucun contre test, aucune recherche, aucune analyse, en gros il viens chercher son larbin"

=> Pour ca, il y a la gold subscription, ou tu fais "relire tes confs" et ou tu "fais configurer" et ou tu globalement "fais faire"
ce n est pas le cas ici.

(a moins que je me trompe, sans quoi moi aussi je ne vais pas tarder a me faire ouspiller)

Florian22

et concernant ton affaire, je lis que tu as "8 acces adsl2+ a 20M) (donc je présume que tu dévelloppes 100 a 110 megs a une deux-centaine de metre d'un central

sont il en gateway group tier 1 ?

ou utilises tu multilink ppp via orange ? (je me demande si ca marche sur orange d ailleurs, chez ovh oui je sais)

nan parce que si c est le choix 1, cela n'est pas si surprenant (d'ailleurs on sait pas quel pb tu rencontres en fait, il s illustre comment ton probleme)?

donc si c est choix 1, alors tu dois savoir que ce n est pas du bonding, mais une repartition qui d'ailleurs est parcellaire, puisque tu es obligé de creer des sous regles pour dispatcher les proto (comme ssl) qui kiffent pas trop la gateway pool.

donc concretement, utilise le formulaire, et dis nous le probleme, parce que les "c 'est pas efficace" c est juste un peu vague
que cherches tu a faire, qu est ce qui ne va pas + formulaire

et tu verras, ;)

Florian22

et je ne vois d'ailleurs aussi qu'un seul pool gateway dans tes rules.

tu ne differencies donc pas ?

tu dois avoir des erreurs exotiques en SSL, avec des connexions qui coupent bruatalement.
tu ne peux pas inserer le traffic ssl dans ton pool "loadbalance" surtout si tes 8 modems sont en tier1

proxiel

Effectivement nous avons un seul pool avec l'ensemble des gateways en tier 1. Nous n'avons pas de problèmes grace à l'option "Sticky connection" qu'on trouve dans system miscellaneous. Seul certaines applications qui utilisent plusieurs serveur cible peuvent nous poser des problèmes.

Le problème est que le surf avec ces règles est très lent voir impossible. Nous nous retrouvons avec des timeout que nous n'arrivons pas à expliquer.

Florian22

OK,

Ben je te remercie de prendre 10-15min a faire le formulaire, et surtout de faire ton schema "pieuvre"
a savoir

DU POSTE CLIENT SUR LE LAN ==================> toute la traversée ======> jusqu'auX WANs

et concernant le sticky, je ne pense pas que ce soit aussi simple, peut etre tatave pourra nous en parler.

a savoir : Faut il faire un sous groupe pour le SSL avec tiers 1 2 3 … et le trigger failover (donc dédier une seule interface de sortie a chaque fois rien que pour le ssl)

ou faire tout en tiers1 et activer sticky.

Florian22

le probleme avec sticky c'est que ca "lie" les states d'un client avec un WAN, jusqu'a expiration des states, et qu'il me semble que ca ne "balance" pas les states sur differents WANs.

en gros: la premiere requête ira sur un WAN, puis toutes les autres iront sur le meme, jusqu'a ce que le client n'ait plus de states ouvertes dans pf. (ce qui n'arrive jamais)

donc concretement : si tes utilisateurs sont résidentiels, ils auront le même WAN, jusqu'a ce quils ferment leur pc, et reviennent sur le réseau.

donc : au mieux, tes clients changeront de WAN souvent (si l'utilisateur a un profil, : "je viens, je pars, je ferme tout, je reviens"
au moyen pire, ils changeront de WAN chaque jour : "bon je vais me coucher, je ferme tout" (les states expirent)

au pire, ils restent quasiment tout le temps aggripés au meme wan 'genre celui qui laisse son pc tout le temps allumés, les connexions permanentes.

et beaucoup font cela !, ils sont plus nombreux qu'on le pense, moi par exemple dans radius je les identifie facilement, ce sont les seuls qui font tout le temps des sessions de 24 heures piles, ensuite l'appareil réouvre de lui meme une nouvelle session.

tu as des gens qui ont des connexions permanentes de 3-4-6 jours, autant de temps ou des states existent, et ou ton client va pas changer de WAN.

et ca perso, je trouve ca un peu pourri.

Tatave

Salut salut

@flo

même mes clients je les rembarre de la même manière, le plus amusant c'est qu'ils reviennent tous la tête entre les guibolles pour ne pas dire autre chose, et surtout quand ils veulent tout pour rien, que la résolutions est facturé au temps passé, ca piaille à réception de la douloureuse mais quand on leur montre les echanges de mails et le temps perdu pour avoir les info et tester x ou y idée ) et qu'on leur montre par a + b en passant par c que s'il avait bien tout donné au bon moment et pas comme ils l'ont fait, la note serait beaucoup moins salée.

@pour notre cornichon ici présent
je dirais effectivement on schémas et surtout pas mué (ip factices s'il veux mais quelle garde la logique de son archi et par piiter un vrai poste de demande d'entre aide, et pas un bout par ci pas la.

==> me venge sur un boite de tagada, Na

ps: si certain aime se faire taper dessus comme cela, pourquoi pas, mais a la longue cela use.

Florian22

Tu es d'accord avec moi concernant le stickky?

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