evince Posté(e) le 5 avril 2017 Partager Posté(e) le 5 avril 2017 (modifié) Bonsoir à tous, Depuis la dernière mise à jour (6.1-15047-update2), j'ai énormément de pertes de paquets vers mon NAS (DS-111). Le CPU et la RAM n'ont pas l'air de s'emballer, l'accès à l'interface ne cause pas de soucis, meme en cas de pertes de paquets. Je vois pas mal de soucis suite à cette mise à jour. Merci d'avance, Modifié le 7 avril 2017 par evince 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fenrir Posté(e) le 5 avril 2017 Partager Posté(e) le 5 avril 2017 Tu as testé en branchant le nas en direct sur ton pc (il faut mettre une ip fixe des 2 cotés ou utiliser des adresses apipa) ? Si le pb disparait, c'est probablement un équipement un chemin qui est en cause (box, switch, câble, ...), sinon il faut creuser. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
evince Posté(e) le 5 avril 2017 Auteur Partager Posté(e) le 5 avril 2017 Mon NAS est raccordé à un switch et mon pc au même switch. Je ne vois pas d'erreurs CRC ni rien. C'est survenu après la mise à jour, car j'ai un monitoring est il s'est affolé directement aprés. J'exclus un matériel dans le chemin. Les pertes de paquets sont synchrones : Délai d’attente de la demande dépassé. Délai d’attente de la demande dépassé. Délai d’attente de la demande dépassé. Délai d’attente de la demande dépassé. Réponse de 10.5.0.11 : octets=32 temps<1ms TTL=64 Réponse de 10.5.0.11 : octets=32 temps<1ms TTL=64 Réponse de 10.5.0.11 : octets=32 temps<1ms TTL=64 Réponse de 10.5.0.11 : octets=32 temps<1ms TTL=64 Réponse de 10.5.0.11 : octets=32 temps<1ms TTL=64 Délai d’attente de la demande dépassé. Délai d’attente de la demande dépassé. Délai d’attente de la demande dépassé. Réponse de 10.5.0.11 : octets=32 temps<1ms TTL=64 Réponse de 10.5.0.11 : octets=32 temps<1ms TTL=64 Réponse de 10.5.0.11 : octets=32 temps<1ms TTL=64 Réponse de 10.5.0.11 : octets=32 temps<1ms TTL=64 Délai d’attente de la demande dépassé. Délai d’attente de la demande dépassé. Délai d’attente de la demande dépassé. Délai d’attente de la demande dépassé. Réponse de 10.5.0.11 : octets=32 temps<1ms TTL=64 Réponse de 10.5.0.11 : octets=32 temps<1ms TTL=64 Réponse de 10.5.0.11 : octets=32 temps<1ms TTL=64 Réponse de 10.5.0.11 : octets=32 temps<1ms TTL=64 Réponse de 10.5.0.11 : octets=32 temps<1ms TTL=64 Délai d’attente de la demande dépassé. Délai d’attente de la demande dépassé. Délai d’attente de la demande dépassé. Délai d’attente de la demande dépassé. Réponse de 10.5.0.11 : octets=32 temps<1ms TTL=64 Réponse de 10.5.0.11 : octets=32 temps<1ms TTL=64 Réponse de 10.5.0.11 : octets=32 temps<1ms TTL=64 Réponse de 10.5.0.11 : octets=32 temps<1ms TTL=64 Réponse de 10.5.0.11 : octets=32 temps<1ms TTL=64 Délai d’attente de la demande dépassé. Délai d’attente de la demande dépassé. Délai d’attente de la demande dépassé. Délai d’attente de la demande dépassé. Réponse de 10.5.0.11 : octets=32 temps<1ms TTL=64 Réponse de 10.5.0.11 : octets=32 temps<1ms TTL=64 Réponse de 10.5.0.11 : octets=32 temps<1ms TTL=64 Réponse de 10.5.0.11 : octets=32 temps<1ms TTL=64 Réponse de 10.5.0.11 : octets=32 temps=5 ms TTL=64 Délai d’attente de la demande dépassé. Délai d’attente de la demande dépassé. Délai d’attente de la demande dépassé. Délai d’attente de la demande dépassé. Sait-on faire un downgrade? 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fenrir Posté(e) le 5 avril 2017 Partager Posté(e) le 5 avril 2017 À ta place je ferais tout de même le test en direct, afin d'éliminer tout autre facteur externe (pb matériel, mais aussi anomalies sur le réseau, comme un conflit d'ip, un cache arp, mtu,...). Si depuis le nas, tu ping un autre équipement, même problème ? Pour le downgrade, c'est rarement possible (ça dépend des modèles, aucune idée pour ton nas) mais dans tous les cas ça nécessite de bidouiller (sur un DS710, il faut démonter le boitier pour accéder à la carte). 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
evince Posté(e) le 6 avril 2017 Auteur Partager Posté(e) le 6 avril 2017 Merci pour ton aide. Il ne saurait pas y avoir de confilt, c'est un vlan particulier avec authentification radius et machines en ip fixe (non modifiées dernièrement) . Ce qui est curieux c'est qu'à partir du syno, je n'ai aucune perte, que ce soit vers l'extérieur ou vers le Gateway. MàJ : J'ai remarqué dans mon routeur un nombre élevé de sessions à partir du syno. J'ai killé toutes ces sessions (environ 500), et maintenant cela semble être rentré dans l'ordre ... Je ne sais pas du tout ce qui a pu se passer. Merci pour l'aide en tous cas :) 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fenrir Posté(e) le 6 avril 2017 Partager Posté(e) le 6 avril 2017 Si tu ne dis pas tout ... on ne peut pas deviner que tu fais tu 802.1x ou du 802.1q (attribution dynamique ?) Pour les sessions, tu parles des sessions eap ou tcp ? L'eap ne devrait pas avoir d'impact (sauf si le couple cpu/ram de l'équipement qui gère le 802.1x est trop juste), pour les sessions tcp, 500 ce n'est pas énorme (c'est même très peu). 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
evince Posté(e) le 6 avril 2017 Auteur Partager Posté(e) le 6 avril 2017 C'étaient des sessions TCP. Et pour un NAS qui n'a pas (ou presque pas) de packages installés, 500 sessions TCP c'est énorme. Je ne vois pas pourquoi il ouvre autant de sessions de lui même, je n'ai aucun services exposés à Internet, tout passe par VPN. Et je ne vois pas pourquoi Synology cherche à communiquer par exemple avec la Corée du Sud, Bref, j'ai filtré les accès et tout roule, merci. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fenrir Posté(e) le 6 avril 2017 Partager Posté(e) le 6 avril 2017 Vérification des mises à jour (dsm+paquets+signatures+...), réponses à tes sollicitations, ... mais si ton nas ne fait rien et n'est pas accessible depuis Internet, 500 ça fait effectivement bcp. Une session TCP ça a une durée de vie limitée (par défaut c'est 2h sous Linux), ton firewall devrait les clore de lui même passé ce délai => vérifie qu'il le fait bien. J'ai déjà vu des équipements qui géraient mal les flags RST et FIN => les sessions s’accumulaient (par contre pas de souci avant plusieurs dizaines milliers de sessions). Si le problème est résolu, merci d'éditer ton titre pour l'indiquer. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Rejoindre la conversation
Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.