J'ai trouvé que ton exposé manquait un peu de métriques/métrologie (j'y étais mais j'ai eu la flemme de poser des questions). Genre : nombre de sessions simultanées, taille de tes tables et de tes tables d'états.
Oui, 10 minutes c'est court pour tout ça. J'ai dû élaguer et aller vite.
Tu mentionnes les tailles en pointe de tes tables d'états, alors je me pose la question : est-ce que la taille que tu pré-configures est réservée d'office dans la mémoire, ou est-ce que tu pourrais quand même être à cours d'espace dans le kernel alors que tu n'as pas encore rempli ta table ?
Je pense que les états sont alloués au fur et à mesure. La taille de la table est de 1 500 000 avec en moyenne 400 000 états (soit 200 000 connexions) Je n'ai jamais été confronté à un manque de ram, au bout de quelques jours le pare-feu se stabilise à 3,2G libre (sur 4G).
Des gens m'ont dit avoir rempli des tables avec 3 500 000 états sous FreeBSD et que ça marchait encore (c'était lent ceci dit)
Pas facile de tester tout ça sans matériel de test.
L'impact de pfsync a-t-il été évalué ? (ie est-ce que ça marche mieux sans)
Non, mais on est en mode sans "defer".
Aussi, est-ce que tu filtres le trafic inter-vlan dans ces FW ?
On a pas de vlan sur ces PF. C'est juste des pare-feu pour protéger internet.
Enfin bon, c'était sympa de voir ta présentation, même si c'est pas très optimiste finalement :))
J'y peux rien si ça tiens pas :) Et encore avec OpenBSD 5.3 c'est la cata, là les utilisateurs de visio râlent, mais j'ai pu patcher le soucis (plus de MSI sur em(4)).
Est-ce que tu vas tester FreeBSD 10, et surtout est-ce que c'est testable en gardant le u-cop2 en openbsd ?
Oui on va tester FreeBSD 10 (quand ?), on prévoit du nouveau matériel en passant. Je ne sais pas si carp FreeBSD/openbsd sont compatibles, je ne m'y risquerais pas trop en prod.
patpro ~ patrick proniewski :
J'ai trouvé que ton exposé manquait un peu de métriques/métrologie (j'y
étais mais j'ai eu la flemme de poser des questions).
Genre : nombre de sessions simultanées, taille de tes tables et de tes
tables d'états.
Oui, 10 minutes c'est court pour tout ça. J'ai dû élaguer et aller vite.
Tu mentionnes les tailles en pointe de tes tables d'états, alors je me
pose la question : est-ce que la taille que tu pré-configures est
réservée d'office dans la mémoire, ou est-ce que tu pourrais quand même
être à cours d'espace dans le kernel alors que tu n'as pas encore rempli
ta table ?
Je pense que les états sont alloués au fur et à mesure. La taille de
la table est de 1 500 000 avec en moyenne 400 000 états (soit 200 000
connexions) Je n'ai jamais été confronté à un manque de ram, au bout
de quelques jours le pare-feu se stabilise à 3,2G libre (sur 4G).
Des gens m'ont dit avoir rempli des tables avec 3 500 000 états sous
FreeBSD et que ça marchait encore (c'était lent ceci dit)
Pas facile de tester tout ça sans matériel de test.
L'impact de pfsync a-t-il été évalué ? (ie est-ce que ça marche mieux
sans)
Non, mais on est en mode sans "defer".
Aussi, est-ce que tu filtres le trafic inter-vlan dans ces FW ?
On a pas de vlan sur ces PF. C'est juste des pare-feu pour protéger
internet.
Enfin bon, c'était sympa de voir ta présentation, même si c'est pas très
optimiste finalement :))
J'y peux rien si ça tiens pas :) Et encore avec OpenBSD 5.3 c'est la
cata, là les utilisateurs de visio râlent, mais j'ai pu patcher le
soucis (plus de MSI sur em(4)).
Est-ce que tu vas tester FreeBSD 10, et surtout est-ce que c'est
testable en gardant le u-cop2 en openbsd ?
Oui on va tester FreeBSD 10 (quand ?), on prévoit du nouveau matériel en
passant. Je ne sais pas si carp FreeBSD/openbsd sont compatibles, je ne
m'y risquerais pas trop en prod.
J'ai trouvé que ton exposé manquait un peu de métriques/métrologie (j'y étais mais j'ai eu la flemme de poser des questions). Genre : nombre de sessions simultanées, taille de tes tables et de tes tables d'états.
Oui, 10 minutes c'est court pour tout ça. J'ai dû élaguer et aller vite.
Tu mentionnes les tailles en pointe de tes tables d'états, alors je me pose la question : est-ce que la taille que tu pré-configures est réservée d'office dans la mémoire, ou est-ce que tu pourrais quand même être à cours d'espace dans le kernel alors que tu n'as pas encore rempli ta table ?
Je pense que les états sont alloués au fur et à mesure. La taille de la table est de 1 500 000 avec en moyenne 400 000 états (soit 200 000 connexions) Je n'ai jamais été confronté à un manque de ram, au bout de quelques jours le pare-feu se stabilise à 3,2G libre (sur 4G).
Des gens m'ont dit avoir rempli des tables avec 3 500 000 états sous FreeBSD et que ça marchait encore (c'était lent ceci dit)
Pas facile de tester tout ça sans matériel de test.
L'impact de pfsync a-t-il été évalué ? (ie est-ce que ça marche mieux sans)
Non, mais on est en mode sans "defer".
Aussi, est-ce que tu filtres le trafic inter-vlan dans ces FW ?
On a pas de vlan sur ces PF. C'est juste des pare-feu pour protéger internet.
Enfin bon, c'était sympa de voir ta présentation, même si c'est pas très optimiste finalement :))
J'y peux rien si ça tiens pas :) Et encore avec OpenBSD 5.3 c'est la cata, là les utilisateurs de visio râlent, mais j'ai pu patcher le soucis (plus de MSI sur em(4)).
Est-ce que tu vas tester FreeBSD 10, et surtout est-ce que c'est testable en gardant le u-cop2 en openbsd ?
Oui on va tester FreeBSD 10 (quand ?), on prévoit du nouveau matériel en passant. Je ne sais pas si carp FreeBSD/openbsd sont compatibles, je ne m'y risquerais pas trop en prod.
patpro ~ patrick proniewski
In article <l8q72q$2mgl$, Patrick Lamaizière wrote:
> Tu mentionnes les tailles en pointe de tes tables d'états, alors je me > pose la question : est-ce que la taille que tu pré-configures est > réservée d'office dans la mémoire, ou est-ce que tu pourrais quand même > être à cours d'espace dans le kernel alors que tu n'as pas encore rempli > ta table ?
Je pense que les états sont alloués au fur et à mesure. La taille de la table est de 1 500 000 avec en moyenne 400 000 états (soit 200 000 connexions) Je n'ai jamais été confronté à un manque de ram, au bout de quelques jours le pare-feu se stabilise à 3,2G libre (sur 4G).
Sous FreeBSD, j'ai eu des soucis avec une table (pas d'états) de 38000 ip alors que la RAM du serveur était largement surdimensionnée (16Go) et que pf était réglé pour accepter des tables d'un million d'items. La relation entre la taille max des tables, et ce qu'elles peuvent vraiment contenir ne semble donc pas tout à fait immédiate. La version de pf sur OpenBSD est sans doute plus aboutie que son portage en retard sur FreeBSD, mais bon, ça reste peut être une piste.
Des gens m'ont dit avoir rempli des tables avec 3 500 000 états sous FreeBSD et que ça marchait encore (c'était lent ceci dit)
Pas facile de tester tout ça sans matériel de test.
sans clients de tests aussi, parce que simuler de vrais usages c'est sans doute pas évident :/
Oui on va tester FreeBSD 10 (quand ?), on prévoit du nouveau matériel en passant. Je ne sais pas si carp FreeBSD/openbsd sont compatibles, je ne m'y risquerais pas trop en prod.
je peux comprendre... :) j'ai plein d'idées farfelues que personne ne veut tester en prod.
patpro
-- photo http://photo.patpro.net/ blog http://www.patpro.net/
In article <l8q72q$2mgl$1@poup.poupinou.org>,
Patrick Lamaizière <adresse@est.invalid> wrote:
> Tu mentionnes les tailles en pointe de tes tables d'états, alors je me
> pose la question : est-ce que la taille que tu pré-configures est
> réservée d'office dans la mémoire, ou est-ce que tu pourrais quand même
> être à cours d'espace dans le kernel alors que tu n'as pas encore rempli
> ta table ?
Je pense que les états sont alloués au fur et à mesure. La taille de
la table est de 1 500 000 avec en moyenne 400 000 états (soit 200 000
connexions) Je n'ai jamais été confronté à un manque de ram, au bout
de quelques jours le pare-feu se stabilise à 3,2G libre (sur 4G).
Sous FreeBSD, j'ai eu des soucis avec une table (pas d'états) de 38000
ip alors que la RAM du serveur était largement surdimensionnée (16Go) et
que pf était réglé pour accepter des tables d'un million d'items.
La relation entre la taille max des tables, et ce qu'elles peuvent
vraiment contenir ne semble donc pas tout à fait immédiate.
La version de pf sur OpenBSD est sans doute plus aboutie que son portage
en retard sur FreeBSD, mais bon, ça reste peut être une piste.
Des gens m'ont dit avoir rempli des tables avec 3 500 000 états sous
FreeBSD et que ça marchait encore (c'était lent ceci dit)
Pas facile de tester tout ça sans matériel de test.
sans clients de tests aussi, parce que simuler de vrais usages c'est
sans doute pas évident :/
Oui on va tester FreeBSD 10 (quand ?), on prévoit du nouveau matériel en
passant. Je ne sais pas si carp FreeBSD/openbsd sont compatibles, je ne
m'y risquerais pas trop en prod.
je peux comprendre... :)
j'ai plein d'idées farfelues que personne ne veut tester en prod.
patpro
--
photo http://photo.patpro.net/
blog http://www.patpro.net/
In article <l8q72q$2mgl$, Patrick Lamaizière wrote:
> Tu mentionnes les tailles en pointe de tes tables d'états, alors je me > pose la question : est-ce que la taille que tu pré-configures est > réservée d'office dans la mémoire, ou est-ce que tu pourrais quand même > être à cours d'espace dans le kernel alors que tu n'as pas encore rempli > ta table ?
Je pense que les états sont alloués au fur et à mesure. La taille de la table est de 1 500 000 avec en moyenne 400 000 états (soit 200 000 connexions) Je n'ai jamais été confronté à un manque de ram, au bout de quelques jours le pare-feu se stabilise à 3,2G libre (sur 4G).
Sous FreeBSD, j'ai eu des soucis avec une table (pas d'états) de 38000 ip alors que la RAM du serveur était largement surdimensionnée (16Go) et que pf était réglé pour accepter des tables d'un million d'items. La relation entre la taille max des tables, et ce qu'elles peuvent vraiment contenir ne semble donc pas tout à fait immédiate. La version de pf sur OpenBSD est sans doute plus aboutie que son portage en retard sur FreeBSD, mais bon, ça reste peut être une piste.
Des gens m'ont dit avoir rempli des tables avec 3 500 000 états sous FreeBSD et que ça marchait encore (c'était lent ceci dit)
Pas facile de tester tout ça sans matériel de test.
sans clients de tests aussi, parce que simuler de vrais usages c'est sans doute pas évident :/
Oui on va tester FreeBSD 10 (quand ?), on prévoit du nouveau matériel en passant. Je ne sais pas si carp FreeBSD/openbsd sont compatibles, je ne m'y risquerais pas trop en prod.
je peux comprendre... :) j'ai plein d'idées farfelues que personne ne veut tester en prod.
patpro
-- photo http://photo.patpro.net/ blog http://www.patpro.net/
