oui , mais finalement ce n'etait pas completement reglé car une fois le
ZBF reglé, j'ai activé un nouveau PATH via un autre peering (favorisé
un 10G vs 1G)
et là c'est retombé en panne :-( . encore pas mal de minutes/heure de
recherche pour me rendre compte que l'uptream alternatif en 10G fait du
uRPF "loose"
ip verify unicast source reachable-via any
=> bref il faut que je lui annonce les prefixes sur lesquels il reçoit
mon outPut par lui même (ISP2xG) pour ne pas droper cet output !
j'ai commencé par annoncer un ou deux /24 pour verifier, mais ils ne
partaient pas , meme apres un bgp clear soft,
l'explication est donc que comble de tout ça, sur mon edge2, comme j'ai
un /16, j'ai fais des aggregats /22 voire /18
genre
aggregate-address 157.150.12.0 255.255.252.0 summary-only
donc il faut dans la prefix list de la route-map BGP preciser l'aggregat
/22 pour que l'annonce parte .
bref, pas facile le multi-homing ...
pour revenir au pb N°1 (statefull ZBF) il faudrait peut-etre que je
revise mon filtrage en effet plus "south" , mais les catalyst 8500 font
bcp de choses en Asic et tiennent le 10G d'où la concentration des
fonctions dessus, dans l'academic on a pas trop les moyens de se payer
de palo-alto ou Fortinet en plusieurs exemplaires et qui tiennent de
tels debit sans brider les performances .
jehan .
On 3/7/26 18:47, Paul Rolland (ポール・ロラン) wrote:
Hello,
On Sat, 7 Mar 2026 16:15:46 +0100
jehan procaccia INT <[email protected]> wrote:
oui c'est finalement bien ça, désolé pour le bruit, j'etais persuadé d'un
filtrage outPut ou upstream, mais finalement c'est mon stateFull firewall
<snip>
pour les details de l'analyse, c'est donc mon Cisco ZBF qui ne laissait
pas passer le ACK (3) du client OVH sachant qu'il n'avait pas vu le
Syn-ACK (2) préalable repasser par lui en retour et ainsi n'a pu
completer la session 3-way Handshake afin de remplir correctement sa
table des sessions ouvertes
le fautif, cisco ZBF avec cette config
policy-map type inspect isp1-IN
class type inspect basic-services-cm
inspect
class-map type inspect match-any basic-services-cm
match protocol https
et il n'etait pas listé un protocol ldapS, d'où l'explication que cela
marchait bien avec ce dernier malgre l'asymetrie .
Merci beaucoup pour le retour avec les elements d'analyse, et content que
ton probleme soit "regle" (ou a defaut d'etre regle, maintenant
parfaitement compris).
Bon we a tous,
Paul
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
