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 (ZBF) en IN ISP1 qui cassait la sessions car il n'avait pas
tout vu passer :-( . je n'avais pas le pb avant car mon trafic
engineering etait tres symetrique, ce n'est que dernierement
qu'apparement de nouvelles annonces et/ou Local-pref / AS-PATH lenght
ont priorisés en l'occurrence ici des subnets OVH via ISP2 .
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
schema d'architecture:
Client OVH-> ISP1 -> Cisco ZBF -> Server443
Server443 -> ISP2 -> Internet -> Client OVH
du coup quand le Cisco (edge1/ISP1) ZBF voit le ACK depuis le client OVH
se pointer suivit du ClientHello (TLS) , il drop les 2 et cela plante
l'ensemble.
J'ai refais les captures avec Tshark, en effet c'est plus lisible , la
capture Client montre bien un debut de 3-way HandShake correcte (donc le
Sync-Ack (2) est bien revenu, mais par ISP2 (FranceIX))
1) SYN ->
2) <- SYN-ACK
3) ACK ->
4) ClientHello TLS ->
5) (retransmissions)
Coté serveur 1 & 2 se passent bien, mais le 3) ACK n'arrive pas
1) SYN ->
2) <- SYN-ACK
(no ACK received)
d'où ses retransmissions sucessives
1 SYN
2 SYN ACK
3 SYN ACK retransmission
4 SYN ACK retransmission
5 SYN ACK retransmission
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 .
une solution consiste a passer la policy-map en Pass plutot que Inspect
, en effet cela marche, je me prive de stafull et un-sollitated packets
et des verifications strictes des TCP flags, mais j'assure une asymetrie
et donc un trafic engineering en adequation avec les best PAth de mon
multi-home , compromi a faire sinon mieux ?
Merci
On 3/7/26 15:15, Paul Rolland (ポール・ロラン) wrote:
Hello,
On Sat, 7 Mar 2026 00:32:05 +0100
jehan procaccia INT via frnog<[email protected]> wrote:
ok j'ai descendu a une mtu 1260 , tj meme symptome
qq'un d'autre ma repondu de verifier en mettant une route statique en
retour Symetrique via REnater, deja fait
et oui là cela marche ... d'où mon doute sur l'asymetrie
je vais essayer de mettre en place une capture en sortie de mon routeur
edge2 (frontal FranceIX) et du core interne pour voir si ce ne serait
pas lui qui casse qq chose, mais c'est jamais facile a faire .
je ferais aussi du tshark + pcap pour completer comme le suggere David
Meme si ca reste difficilement compatible avec ton test ldaps qui marche,
on dirait quand meme un probleme de firewall stateful... un qui voit passer
le SYN sortant, et prepare la session, et le second qui voit revenir un
SYN+ACK pour lequel il n'a aucune info, et le bloque alors.
Mais il faudrait plus d'infos sur tes archis cote client/serveur pour aller
plus loin dans l'analyse.
Paul
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
