Traffic shaping qos
-
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 + formulaireet tu verras, ;)
-
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 -
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.
-
OK,
Ben je te remercie de prendre 10-15min a faire le formulaire, et surtout de faire ton schema "pieuvre"
a savoirDU 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.
-
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.
-
Salut salut
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.
-
Tu es d'accord avec moi concernant le stickky?
-
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 totaleCette 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,
-
"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) -
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.
-
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 ..etcc est pas con du tout!!! ca m etais pas venu une seconde a l esprit !!!!!!!!!! lol je me sens con la
–-
concernant le demandeur fra1000on 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
-
"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.
-
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
-
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 ..etcc 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.
-
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 lacomment 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 -
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 ^^
-
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
-
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
-
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 BC => 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.
-
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
