Re: [TECH] academique, routage BGP asymetrique casse TLS 443

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/