freebsd pfsync bulk fail ?

Le
Patrick Lamaizière
Hello,

(freebsd 10.3-STABLE/amd64)

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)

load_kld pfsync
++ sleep 10
ifconfig pfsync0 $_syncpeer syncdev $pfsync_syncdev
$pfsync_ifconfig up

Pour finir un /etc/rc.d/pfsync restart, bien qu'il y ait un log de bulk
start échoue toujours également.

Merci.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Patrick Lamaizière
Le #26408725
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
Le #26413463
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
Le #26419363
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,
Publicité
Poster une réponse
Anonyme