Quand tu dis routeur C c'est du Juniper, il fait quoi ? Routeur ?
Firewall ?
Ça ressemble à un grand classique d'une table de sessions quelque part
sur une boite sur le chemin (firewall qui offloade le TCP dans un
ASIC/NP, load-balancer quelque part) ?
Je ne connais pas assez bien Juniper pour t'aider mais je dirais que si
il y a perte de la route, le routeur devrait switch le trafic sur le
path suivant, mais si tu rajoutes le VPN et donc potentiellement des
SA/SP dans la boucle, tu as peut être un offload des paquets à chiffrer
ou tout simplement des sessions TCP sur un type firewall ?
T'as 2 trucs qui peuvent se télescoper la. Mais j'irais chercher de ce
que côté la, surtout si en ICMP / UDP tu ne constates pas le soucis.
Le 01-02-2021 16:28, Mickael Hubert a écrit :
Bonjour à tous,
j'ai un petit souci de sessions TCP restant actives après un switch de
BGP. Pour infos ces 2 sessions sont à l'intérieur de tunnels IPSEC VTI.
Je ne parle pas des sessions TCP du BGP en lui-même, mais de trafic TCP
classique en fait.
L'infra :
Il y a 2 sessions BGP (1 par DC), les 2 connectées, avec une route map
pour forcer le trafic a passer par un des 2 tunnels.
Le failover BGP se fait très bien, un nouveau trafic passera
correctement par le tunnel encore UP (standy -> active).
Mais les sessions TCP déjà ouvertes entre le serveur C et les serveurs
A ou B restent actives sur le serveur C. Pourtant, le routeur VPN C
voit bien les sessions TCP comme closed.
Il faut attendre un timeout sur le serveur C pour qu'il initie de
nouvelles sessions TCP, mais c'est 8 mins de downtime .... chaud pour
du failover ...
Pour info le serveur C c'est un SBC Oracle qui fait du SIP TCP (pas
possible de repasser en SIP UDP, trop facile ;) )...
Le routeur VPN C c'est du Juniper.
Avez-vous déjà vu ce genre de phénomène ? J'imagine bien qu'il faut
changer le timer TCP sur l'Oracle, mais c'est à priori chaud pour mon
client.
N'y a-t'il pas un moyen sur un Juniper de balancer du TCP/RST lors
d'une coupure de VPN ou autre palliatif ?
Merci d'avance pour votre aide !
++
--
Fabien VINCENT
_@beufanet_
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
