Sous FreeBSD J'aimerais savoir si la synchro bulk de pfsync(4)
fonctionne pour quelqu'un ? J'ai systématiquement un problème de bulk
fail. La synchro des états fonctionne correctement par contre.
Un "chez moi ça marche" me serait utile :-)
kernel: carp: demoted by 0 to
1000 (pfsync bulk start)
kernel: carp:
demoted by 0 to 3000 (pfsync bulk fail)
J'ai passé du temps et j'ai juste trouvé (à confirmer disons que des
fois ça marche) le work around suivant :
1) initialiser pfsync après PF parce que /etc/rc.d/pf start flush les
états et que c'est dans mon pf.conf que je spécifie la taille de la
table d'états (1400000)
2) modifier /etc/rc.d/pfsync pour faire un sleep de 10s après le
chargement du module pfsync.ko (à noter que si chargé par
/boot/loader.conf ça ne marche pas plus)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Patrick Lamaizière
Patrick Lamaizière :
2) modifier /etc/rc.d/pfsync pour faire un sleep de 10s après le chargement du module pfsync.ko (à noter que si chargé par /boot/loader.conf ça ne marche pas plus) load_kld pfsync ++ sleep 10 ifconfig pfsync0 $_syncpeer syncdev $pfsync_syncdev $pfsync_ifconfig up
en fait ça marche mal aussi...
Pour finir un /etc/rc.d/pfsync restart, bien qu'il y ait un log de bulk start échoue toujours également.
Sur un restart avec tcpdump on voit qu'on envoie pas de requete d'update au peer Par contre *deux* "service pfsync start" provoque l'envoi et le bulk update réussi. je fais faire un PR
Patrick Lamaizière :
2) modifier /etc/rc.d/pfsync pour faire un sleep de 10s après le
chargement du module pfsync.ko (à noter que si chargé par
/boot/loader.conf ça ne marche pas plus)
2) modifier /etc/rc.d/pfsync pour faire un sleep de 10s après le chargement du module pfsync.ko (à noter que si chargé par /boot/loader.conf ça ne marche pas plus) load_kld pfsync ++ sleep 10 ifconfig pfsync0 $_syncpeer syncdev $pfsync_syncdev $pfsync_ifconfig up
en fait ça marche mal aussi...
Pour finir un /etc/rc.d/pfsync restart, bien qu'il y ait un log de bulk start échoue toujours également.
Sur un restart avec tcpdump on voit qu'on envoie pas de requete d'update au peer Par contre *deux* "service pfsync start" provoque l'envoi et le bulk update réussi. je fais faire un PR
Patrick Lamaizière
Patrick Lamaizière : hello,
Patrick Lamaizière :
2) modifier /etc/rc.d/pfsync pour faire un sleep de 10s après le chargement du module pfsync.ko (à noter que si chargé par /boot/loader.conf ça ne marche pas plus) load_kld pfsync ++ sleep 10 ifconfig pfsync0 $_syncpeer syncdev $pfsync_syncdev $pfsync_ifconfig up
en fait ça marche mal aussi...
Pour finir un /etc/rc.d/pfsync restart, bien qu'il y ait un log de bulk start échoue toujours également.
Sur un restart avec tcpdump on voit qu'on envoie pas de requete d'update au peer Par contre *deux* "service pfsync start" provoque l'envoi et le bulk update réussi. je fais faire un PR
Il y a clairement un problème, mais quand le nombre d'états est important le bulk sync se passe bien (ça peut prendre jusqu'à 5 minutes ici). En utilisant pfsync de base. bon...
Patrick Lamaizière :
hello,
Patrick Lamaizière :
2) modifier /etc/rc.d/pfsync pour faire un sleep de 10s après le
chargement du module pfsync.ko (à noter que si chargé par
/boot/loader.conf ça ne marche pas plus)
Pour finir un /etc/rc.d/pfsync restart, bien qu'il y ait un log de bulk
start échoue toujours également.
Sur un restart avec tcpdump on voit qu'on envoie pas de requete d'update
au peer
Par contre *deux* "service pfsync start" provoque l'envoi et le bulk
update réussi.
je fais faire un PR
Il y a clairement un problème, mais quand le nombre d'états est
important le bulk sync se passe bien (ça peut prendre jusqu'à 5 minutes
ici). En utilisant pfsync de base.
2) modifier /etc/rc.d/pfsync pour faire un sleep de 10s après le chargement du module pfsync.ko (à noter que si chargé par /boot/loader.conf ça ne marche pas plus) load_kld pfsync ++ sleep 10 ifconfig pfsync0 $_syncpeer syncdev $pfsync_syncdev $pfsync_ifconfig up
en fait ça marche mal aussi...
Pour finir un /etc/rc.d/pfsync restart, bien qu'il y ait un log de bulk start échoue toujours également.
Sur un restart avec tcpdump on voit qu'on envoie pas de requete d'update au peer Par contre *deux* "service pfsync start" provoque l'envoi et le bulk update réussi. je fais faire un PR
Il y a clairement un problème, mais quand le nombre d'états est important le bulk sync se passe bien (ça peut prendre jusqu'à 5 minutes ici). En utilisant pfsync de base. bon...
Patrick Lamaizière
Patrick Lamaizière : Hello,
Patrick Lamaizière :
2) modifier /etc/rc.d/pfsync pour faire un sleep de 10s après le chargement du module pfsync.ko (à noter que si chargé par /boot/loader.conf ça ne marche pas plus) load_kld pfsync ++ sleep 10 ifconfig pfsync0 $_syncpeer syncdev $pfsync_syncdev $pfsync_ifconfig up
en fait ça marche mal aussi...
On a fini par trouver (non sans mal), en fait la fibre du lien de synchro était à moitiée défectueuse en charge. D'où de nombreux problèmes avec la synchro des états. Ce qui nous a mis la puce à l'oreille c'est que le compteur de packets en sortie sur l'interface pfsync était bien supérieur à celui du lien physique. En fouillant plus avant, il y a un compteur sur les cartes ix (sysctl dev.ix.N.queue.N.br_drop -quelque chose comme ça-) qui s'incrémentait. Par contre pas d'incrémentation du nombre d'erreurs en sortie sur l'interface physique, bizarre. Et aussi, parfois lors d'un ping, une erreur send no buffer space available, mais ça j'ai compris qu'après. Cordialement,
Patrick Lamaizière :
Hello,
Patrick Lamaizière :
2) modifier /etc/rc.d/pfsync pour faire un sleep de 10s après le
chargement du module pfsync.ko (à noter que si chargé par
/boot/loader.conf ça ne marche pas plus)
On a fini par trouver (non sans mal), en fait la fibre du lien de
synchro était à moitiée défectueuse en charge. D'où de nombreux
problèmes avec la synchro des états.
Ce qui nous a mis la puce à l'oreille c'est que le compteur de packets
en sortie sur l'interface pfsync était bien supérieur à celui du lien
physique. En fouillant plus avant, il y a un compteur sur les cartes ix
(sysctl dev.ix.N.queue.N.br_drop -quelque chose comme ça-) qui
s'incrémentait.
Par contre pas d'incrémentation du nombre d'erreurs en sortie sur
l'interface physique, bizarre.
Et aussi, parfois lors d'un ping, une erreur send no buffer space
available, mais ça j'ai compris qu'après.
2) modifier /etc/rc.d/pfsync pour faire un sleep de 10s après le chargement du module pfsync.ko (à noter que si chargé par /boot/loader.conf ça ne marche pas plus) load_kld pfsync ++ sleep 10 ifconfig pfsync0 $_syncpeer syncdev $pfsync_syncdev $pfsync_ifconfig up
en fait ça marche mal aussi...
On a fini par trouver (non sans mal), en fait la fibre du lien de synchro était à moitiée défectueuse en charge. D'où de nombreux problèmes avec la synchro des états. Ce qui nous a mis la puce à l'oreille c'est que le compteur de packets en sortie sur l'interface pfsync était bien supérieur à celui du lien physique. En fouillant plus avant, il y a un compteur sur les cartes ix (sysctl dev.ix.N.queue.N.br_drop -quelque chose comme ça-) qui s'incrémentait. Par contre pas d'incrémentation du nombre d'erreurs en sortie sur l'interface physique, bizarre. Et aussi, parfois lors d'un ping, une erreur send no buffer space available, mais ça j'ai compris qu'après. Cordialement,
