Concierto Arpege
Polar_888
Mensajes publicados
257
Fecha de registro
Estado
Miembro
Última intervención
-
Polar_888 Mensajes publicados 257 Fecha de registro Estado Miembro Última intervención -
Polar_888 Mensajes publicados 257 Fecha de registro Estado Miembro Última intervención -
Hola,
utilizo el software Arpege concerto que permite gestionar ausencias de personas.
Este software funciona en TSE.
A veces se bloquea cuando se realiza una acción del tipo: dar un motivo de ausencia.
Entonces nos desconectamos del software sin cerrarlo adecuadamente.
Me pregunto si no será debido a un problema en la red. (¿Ancho de banda insuficiente?)
¿Qué opinan?
Gracias
utilizo el software Arpege concerto que permite gestionar ausencias de personas.
Este software funciona en TSE.
A veces se bloquea cuando se realiza una acción del tipo: dar un motivo de ausencia.
Entonces nos desconectamos del software sin cerrarlo adecuadamente.
Me pregunto si no será debido a un problema en la red. (¿Ancho de banda insuficiente?)
¿Qué opinan?
Gracias
Configuración: Windows XP Mozzila Firefox
8 respuestas
Difícil dar una opinión sobre esta cuestión, ya que haría falta un diagnóstico mucho más profundo del problema.
Habría que conocer la arquitectura con más detalle para poder avanzar hipótesis.
Habría que conocer la arquitectura con más detalle para poder avanzar hipótesis.
Primero gracias por tu respuesta.
La arquitectura en la que trabajo es una ciudad.
He sniffado con Wireshark/Ethereal el tráfico que pasa por uno de los (numerosos) sitios donde el software falla.
Obtengo mensajes de este tipo en una cantidad relativamente importante (casi 1/3):
132 8.902833 10.1.***.** 10.60.**.* TPKT [TCP Previous segment lost] Continuation
133 8.902867 10.60.**.* 10.1.***.** TCP [TCP Dup ACK 131#1] oraclenames > ms-wbt-server [ACK] Seq=3006 Ack=32076 Win=65535 Len=0 SLE=33536 SRE=34757
134 8.905082 10.1.***.** 10.60.20.1 TPKT [TCP Out-Of-Order] Continuation
También obtengo tramas de este tipo:
11818 689.376478 10.1.***.*** 10.60.**.* TCP [TCP Keep-Alive] microsoft-ds > jlicelmd [ACK] Seq=1 Ack=1 Win=62874 Len=1
11819 689.376496 10.60.**.* 10.1.***.*** TCP [TCP Keep-Alive ACK] jlicelmd > microsoft-ds [ACK] Seq=1 Ack=2 Win=64289 Len=0
¿Creeis que estos mensajes pueden ser la causa de mi problema?
Algunos mensajes no llegan en el orden correcto si he entendido bien..
Gracias
La arquitectura en la que trabajo es una ciudad.
He sniffado con Wireshark/Ethereal el tráfico que pasa por uno de los (numerosos) sitios donde el software falla.
Obtengo mensajes de este tipo en una cantidad relativamente importante (casi 1/3):
132 8.902833 10.1.***.** 10.60.**.* TPKT [TCP Previous segment lost] Continuation
133 8.902867 10.60.**.* 10.1.***.** TCP [TCP Dup ACK 131#1] oraclenames > ms-wbt-server [ACK] Seq=3006 Ack=32076 Win=65535 Len=0 SLE=33536 SRE=34757
134 8.905082 10.1.***.** 10.60.20.1 TPKT [TCP Out-Of-Order] Continuation
También obtengo tramas de este tipo:
11818 689.376478 10.1.***.*** 10.60.**.* TCP [TCP Keep-Alive] microsoft-ds > jlicelmd [ACK] Seq=1 Ack=1 Win=62874 Len=1
11819 689.376496 10.60.**.* 10.1.***.*** TCP [TCP Keep-Alive ACK] jlicelmd > microsoft-ds [ACK] Seq=1 Ack=2 Win=64289 Len=0
¿Creeis que estos mensajes pueden ser la causa de mi problema?
Algunos mensajes no llegan en el orden correcto si he entendido bien..
Gracias
Hola,
El hecho de que los mensajes no lleguen al otro lado no es necesariamente signo de un problema
Sin embargo, si esto ocurre de forma continua y tienes muchos 'lost' y 'duplicate', probablemente eso significa que una ruta/equipo utilizado es fuente de problemas: destrucción de paquetes, latencia.
Esto podría explicarse por una QoS que tendría que ser agresiva debido a un tráfico demasiado alto en comparación con el ancho de banda disponible ... o simplemente por un enlace defectuoso (cableado, negociación, etc.) que sería fuente de pérdidas de paquetes.
¿Has realizado un traceroute al servidor y examinado el conjunto de enlaces atravesados? ¿Este camino es siempre el mismo (no hay parches de puertos que provoquen un reruteo, latencia o pérdidas de paquetes?), ¿un ping bastante largo y con la MTU máxima da qué resultado? ¿latencia ok? ¿pérdidas? ....
El hecho de que los mensajes no lleguen al otro lado no es necesariamente signo de un problema
Sin embargo, si esto ocurre de forma continua y tienes muchos 'lost' y 'duplicate', probablemente eso significa que una ruta/equipo utilizado es fuente de problemas: destrucción de paquetes, latencia.
Esto podría explicarse por una QoS que tendría que ser agresiva debido a un tráfico demasiado alto en comparación con el ancho de banda disponible ... o simplemente por un enlace defectuoso (cableado, negociación, etc.) que sería fuente de pérdidas de paquetes.
¿Has realizado un traceroute al servidor y examinado el conjunto de enlaces atravesados? ¿Este camino es siempre el mismo (no hay parches de puertos que provoquen un reruteo, latencia o pérdidas de paquetes?), ¿un ping bastante largo y con la MTU máxima da qué resultado? ¿latencia ok? ¿pérdidas? ....
Gracias por tu respuesta
¿qué entiendes por errores de puertos?
Voy a intentar hacer lo que dices para las pruebas.
Para la prueba de ping:
No tuve ninguna pérdida para 250 tramas enviadas, cada una de 1500 bytes (MTU)
Para el traceroute:
1 <1 ms <1 ms <1 ms 10.11.***.***
2 <1 ms <1 ms <1 ms 10.39.*.**
3 <1 ms <1 ms 1 ms 10.39.***.**
4 2 ms <1 ms <1 ms 10.39.***.***
5 3 ms 2 ms <1 ms 86.79.*.*
6 163 ms 17 ms 20 ms 86.78.**.**
7 18 ms 15 ms 13 ms 10.60.**.*
Estos resultados parecen correctos ...
El problema también puede venir de la aplicación en el equipo cliente ... Pero ¿cómo asegurarlo?
Lo que sucede realmente durante una modificación es que el software se cierra de forma abrupta sin avisar, pero la acción "quién provocó el fallo" se tiene en cuenta de todas formas.
Este problema no ocurre en todos los sitios... Es lo que me lleva a pensar que el problema viene de la red.
¿Qué opinas?
¿qué entiendes por errores de puertos?
Voy a intentar hacer lo que dices para las pruebas.
Para la prueba de ping:
No tuve ninguna pérdida para 250 tramas enviadas, cada una de 1500 bytes (MTU)
Para el traceroute:
1 <1 ms <1 ms <1 ms 10.11.***.***
2 <1 ms <1 ms <1 ms 10.39.*.**
3 <1 ms <1 ms 1 ms 10.39.***.**
4 2 ms <1 ms <1 ms 10.39.***.***
5 3 ms 2 ms <1 ms 86.79.*.*
6 163 ms 17 ms 20 ms 86.78.**.**
7 18 ms 15 ms 13 ms 10.60.**.*
Estos resultados parecen correctos ...
El problema también puede venir de la aplicación en el equipo cliente ... Pero ¿cómo asegurarlo?
Lo que sucede realmente durante una modificación es que el software se cierra de forma abrupta sin avisar, pero la acción "quién provocó el fallo" se tiene en cuenta de todas formas.
Este problema no ocurre en todos los sitios... Es lo que me lleva a pensar que el problema viene de la red.
¿Qué opinas?
Hola,
Utilizo el término 'bagot' para designar un puerto que pasa regularmente de estado up a down: problemas de negociación, de cableado...
250 tramas, es un poco escaso para detectar un posible fallo.
¿Los sitios en los que se produce el problema no tienen un punto en común? ¿Un enlace tomado, mientras que los demás no?
¿Cómo se accede al LAN? ¿switch? ¿hub? ...
Utilizo el término 'bagot' para designar un puerto que pasa regularmente de estado up a down: problemas de negociación, de cableado...
250 tramas, es un poco escaso para detectar un posible fallo.
¿Los sitios en los que se produce el problema no tienen un punto en común? ¿Un enlace tomado, mientras que los demás no?
¿Cómo se accede al LAN? ¿switch? ¿hub? ...
Hola,
todos los sitios en los que se observa el problema están conectados mediante un ADSL RPV gestionado por Mégalis con una velocidad de 1 Mbit.
Por lo tanto, no tengo acceso a esos routers. :(
Por otro lado, el acceso a la LAN se realiza a través de switches.
Voy a volver a hacer una prueba de ping con más tramas por si acaso.
De nuevo, gracias por tu ayuda :)
todos los sitios en los que se observa el problema están conectados mediante un ADSL RPV gestionado por Mégalis con una velocidad de 1 Mbit.
Por lo tanto, no tengo acceso a esos routers. :(
Por otro lado, el acceso a la LAN se realiza a través de switches.
Voy a volver a hacer una prueba de ping con más tramas por si acaso.
De nuevo, gracias por tu ayuda :)
Hola,
he vuelto a hacer una prueba con muchas más tramas (8900) haciendo ping a todos los equipos transitados y parece que las pérdidas de paquetes se sitúan entre dos equipos.
Sin embargo solo observo 5 paquetes perdidos de 8900 y un tiempo de respuesta de aproximadamente 57ms.
¿Qué opinas al respecto?
he vuelto a hacer una prueba con muchas más tramas (8900) haciendo ping a todos los equipos transitados y parece que las pérdidas de paquetes se sitúan entre dos equipos.
Sin embargo solo observo 5 paquetes perdidos de 8900 y un tiempo de respuesta de aproximadamente 57ms.
¿Qué opinas al respecto?
Hola,
Aunque estas 5 pérdidas no sean necesariamente normales (y que no especifiques, en tu publicación, el tamaño de los paquetes enviados), no creo que eso pueda explicar tus problemas.
Aunque estas 5 pérdidas no sean necesariamente normales (y que no especifiques, en tu publicación, el tamaño de los paquetes enviados), no creo que eso pueda explicar tus problemas.
Hola,
ok si no, hice una prueba con Wireshark (Ethereal) en los PCs que dan problemas.
Encuentro un número muy alto de tramas con error
"Checksum: 0x4293 [incorrect, should be 0xc527 (maybe caused by "TCP checksum offload"?)]
Good Checksum: False
Bad Checksum: True"
Según mis investigaciones creo que se trata de un falso error pero no estoy seguro... Encontré en un sitio web que se podría hacer desaparecer este error modificando una propiedad de la tarjeta de red en el ordenador, “offload checksum” a “none”.
Los errores ya no aparecen pero no sé si eso va a resolver el problema. ¿Qué opinan de esta técnica?
Espero comentarios de los usuarios.
Gracias
ok si no, hice una prueba con Wireshark (Ethereal) en los PCs que dan problemas.
Encuentro un número muy alto de tramas con error
"Checksum: 0x4293 [incorrect, should be 0xc527 (maybe caused by "TCP checksum offload"?)]
Good Checksum: False
Bad Checksum: True"
Según mis investigaciones creo que se trata de un falso error pero no estoy seguro... Encontré en un sitio web que se podría hacer desaparecer este error modificando una propiedad de la tarjeta de red en el ordenador, “offload checksum” a “none”.
Los errores ya no aparecen pero no sé si eso va a resolver el problema. ¿Qué opinan de esta técnica?
Espero comentarios de los usuarios.
Gracias