F5 tiempos de espera de sesión

Nuestros equilibradores de carga F5 ejecutan la versión 10.2.4. Migramos desde las tarjetas de equilibrador de carga de Cisco en el Catalyst 6500 y solíamos poder ejecutar sesiones xterm en nuestros servidores Solaris y Linux sin que las sesiones murieran después de 15 minutos.

Nuestro jefe tiene miedo de aumentar el número de 900 segundos en nuestro perfil de F5 tcp, porque en otra compañía en la que estaba hicieron esto y agotó todos los recursos en el F5 de conexiones colgadas.

¿Hay alguna otra manera de evitar que las sesiones se reinicien sin cambiar el tiempo de espera? Esta es nuestra configuración

profile fastL4 fwd_fastL4_15m {
  defaults from fastL4
  idle timeout 900
}

virtual route_outbound {
  destination any:any
  mask none
  ip forward
  profile fwd_fastL4_15m
}

¿Hay alguna otra manera de evitar que las sesiones se reinicien sin cambiar el tiempo de espera?

Ya mencionó que los keepalives no se utilizaron en su antiguo equilibrador de carga de Cisco, por lo que me centraré en lo que puede hacer con el F5.

Hay dos problemas que debes resolver ...

• El F5 envía un reinicio al cliente cuando la sesión TCP expira de la tabla de estado
• El F5 elimina la sesión TCP después de que caduque

Esos dos problemas parecen relacionados, pero tienen diferentes soluciones en el F5.

Solución de reinicios de TCP :

F5 restablece las sesiones TCP agotadas por defecto. Puede deshabilitar ese comportamiento reset on timeout disabledentro de su perfil TCP. Sin embargo, todo esto hace que el F5 no restablezca la conexión del cliente, pero la sesión caducará de la tabla de estado del F5 la próxima vez que alguien tome un descanso durante un par de horas y luego mueva el puntero del mouse nuevamente en el xterm .

Resolver el vencimiento de la sesión dentro del F5 :

Úselo loose initiation enableen su perfil TCP. loose initiationpermite que el F5 cree una entrada en la tabla de estado TCP cada vez que ve un paquete TCP desconocido. Mientras estas conexiones sean confiables, y dentro de su empresa, no hay ningún problema para encender loose initiation.

Esencialmente, loose initiationhace que el F5 se comporte más como un enrutador que como un equilibrador de carga, que es lo que necesita en esta situación. Las sesiones xterm crean un socket TCP procedente de TCP / 6000 para el cliente. En este caso, no está equilibrando la carga de las sesiones xterm de todos modos.

Solución final :

Su perfil final debería verse así ...

profile fastL4 fwd_fastL4_5m_loose {
  defaults from fastL4
  reset on timeout disable
  idle timeout 300
  loose initiation enable
}
virtual route_outbound {
  destination any:any
  mask none
  ip forward
  profile fwd_fastL4_5m_loose
}

Técnicamente, puede cambiar el tiempo de espera de 900 segundos a 300 segundos, ya que está habilitando el inicio de sesión suelta en el route_outboundservicio. El documento de solución F5 7595 es una buena referencia para reenviar configuraciones de servidores virtuales como esta ... consulte la sección titulada "Emulación de enrutamiento IP sin estado con servidores virtuales de reenvío BIG-IP LTM".

Para las sesiones de término, creo que la mejor opción es usar aplicaciones o sistemas operativos del sistema operativo para mantener la conexión a través del SLB, lo que le permite mantener su tiempo de inactividad donde lo desee.

Esto depende de la aplicación y el sistema operativo. Consulte Evitar que la sesión SSH de Linux se desconecte como un método que puede funcionar.

La preocupación de su gerente al aumentar el tiempo de inactividad es muy subjetiva. La velocidad de flujo típica (conexión / seg.) Y las duraciones de inactividad entre su entorno y el último podrían ser muy diferentes. Si su velocidad de flujo o duraciones inactivas son mucho más bajas, puede permitirse aumentar el tiempo de espera. Deberá poner a cero la capacidad de flujo, lo que tiene libre y la rapidez con la que pasa por ellos.

El tiempo de espera inactivo predeterminado del CSM es 3600. Lo mismo para el ACE para conexiones TCP inactivas .