Revisar conexiones simultáneas a un equipo Cisco

Cuando en nuestra empresa hay más de un administrador de redes es posible, incluso probable, que en caso de problemas de red varias personas estén conectadas simultáneamente en un mismo equipo. Si ambas personas están coordinadas y sólo se efectúan cambios de configuración desde una conexión no debería haber problemas, pero no siempre es el caso.

Una recomendación básica es forzar una desconexión por inactividad en las sesiones remotas (telnet, ssh) para evitar que un equipo llegue al número máximo de sesiones abiertas e impida conectarnos posteriormente.

En los equipos CISCO podemos ver quién está conectado a un switch en concreto (y cómo) con el comando who. Dicha instrucción nos devuelve un listado de las conexiones establecidas en el equipo indicando el número de consola usado (vty, con), el login con el que han establecido la conexión, el tiempo que llevan inactivos y la dirección IP origen de la conexión. Además el comando nos indicará con un * cuál es nuestra conexión.

En caso de problemas o si queremos ser los únicos conectados a nuestro equipo cuando realicemos un cambio de configuración existe un comando que nos permitirá cerrar las otras sesiones. Para ello simplemente introduciremos el comando clear line (vty/con) #. Basta con confirmar la acción (yes) para que se cierre la sesión remota seleccionada. En las últimas versiones de IOS ya no es posible cerrar nuestra propia conexión pero en todo caso hay que fijarse bien no sea cosa que nos cerremos nosotros mismos.

En siguiente ejemplo veremos un equipo donde hay dos usuarios conectados simultáneamente y deseamos cerrar la sesión de "admin-5". Para probar intentamos cerrar nuestra propia sesión y vemos como el propio equipo lo evita.

1. Comprobamos quien está conectado:

Switch_01#who
    Line       User         Host(s)         Idle       Location
*  1 vty 0     admin-1  idle            00:00:00   192.168.10.11
   2 vty 1     admin-5   idle            00:07:37   10.100.3.15
  Interface    User       Mode         Idle     Peer Address
Switch_01#

2. Intentamos matar nuestra propia sesión

Switch_01#clear line vty 0
% Not allowed to clear current line [OK]
Switch_01#

3. Cerramos la sesión remota de admin-5

Switch_01#clear line vty 1
[confirm]yes [OK]
Switch_01#

4. Comprobamos que la sesión de admin-5 ya no existe

Switch_01#who
    Line       User       Host(s)          Idle        Location
*  1 vty 0     admin-1      idle        00:00:00 192.168.10.11
  Interface    User     Mode             Idle       Peer Address
Switch_01#

Analizar tráfico en un router CISCO

Los routers CISCO incorporan una funcionalidad básica de análisis de tráfico. Al habilitar el sistema de ip accounting podemos ver el número de paquetes y de bytes que se envían dos direcciones IP a través de una interfaz. Sólo queda registrado tráfico IP y siempre el saliente de la interfaz. No se muestra el tráfico generado o finalizado en el propio equipo (pings desde o hacía nuestro router no aparecerán en el accounting).

Las interfaces en las que se puede hacer el análisis son tanto físicas (FastEthernet, etc.) como lógicas (VLAN, etc.). 

A la hora de analizar el tráfico es importante recordar que en estas muestras sólo se ve el tráfico saliente por lo que hay que elegir la interfez correcta para analizar el tráfico que nos interesa.

1. La activación del ip accounting se realiza dentro de la configuración de la interfaz en cuestión:

Router01(config)#interface vlan1
Router01(config-if)#ip accounting
Router01(config-if)#exit
Router01(config)#interface dialer 0
Router01(config-if)#ip accounting
Router01(config-if)#exit

2. Para ver el tráfico se solicita en el prompt normal

Router#show ip accounting
Source Destination Packets Bytes
10.101.101.12 10.200.200.3 3 180
10.101.101.15 10.107.5.29 3 180
10.101.101.15 10.200.200.5 1 52
10.101.101.150 10.100.14.35 1 41
10.101.102.154 10.203.254.1 12 2079
10.101.103.10 10.210.25.23 12 3358
10.101.101.15 10.230.15.14 6 1531
10.101.102.152 10.201.20.14 10 3967
Accounting data age is 1d03h
Router#

Configuración gestión web segura en switches HP Procurve

En una entrada anterior vimos la idoneidad de sustituir los accesos vía telnet por el protocolo cifrado ssh.
En esta entrada veremos como permitir la gestión de un switch con la interfaz web pero activando el protocolo cifrado https.

Nuevamente primero activaremos el acceso vía https y sólo una vez confirmado el funcionamiento desactivaremos el acceso en claro.

1. Generar la clave de cifrado

crypto key generate cert 1024

2. Activamos el acceso web cifrado

web-management ssl

3. Desactivamos el acceso en claro

no web-management plaintext

Tras estos cambios ya no podremos acceder a nuestro equipo con http por lo que estaremos obligados a usar el protocolo cifrado https.

Definir zona horaria en switches HP Procurve

Vimos en una entrada anterior como sincronizar la hora de todos nuestros equipos de red usando un servidor horario común.

Dependiendo de la configuración de dicho servidor podemos encontrarnos con los equipos estén configurados en horario UTC o en nuestra zona horaria. En caso de usar relojes UTC, lo más habitual, puede ser interesante configurar los switches para que tengan en cuenta las variaciones horarias debido a los horarios de verano-invierno existentes en las distintas zonas.

Los equipos HP Procurve llevan una serie de zonas preconfiguradas que tienen en cuenta estas modificaciones y adaptan la hora del equipo a la hora oficial de nuestra zona.

Las opciones predefinidas en los equipos HP Procurve son:

• none
• alaska
• continental-us-and-canada
• middle-europe-and-portugal
• southern-hemisphere
• western-europe
• user-defined

La configuración de la zona horaria de Europa occidental (España, Portural, francias, etc.) sería:

Switch_HP(config)#time daylight-time-rule western-europe

Redirigir tráfico DHCP a servidores remotos

El protocolo DHCP permite la configuración remota de la configuración de dirección IP y algunas opciones extras a los equipos de nuestra red. Para ello cuando un equipo necesita conectarse a la red simplemente manda un paquete broadcast a todos los equipos de su red. Si dicho paquete llega a un servidor DHCP le responde directamente al equipo con la información necesaria para conectarse y empezar a trabajar en la red.

La principal limitación de este procedimiento es que supone una visibilidad directa entre el equipo solicitante y el servidor DHCP. Este requerimiento obligaría a disponer de un servidor DHCP en todos y cada uno de los segmentos de nuestra red. Si nuestra red dispone de 5 VLAN necesitaríamos tener definidos 5 servidores. Si hablamos de una red con oficinas remotas deberíamos, al menos, tener 1 servidor en cada base con la multiplicación de problemas y trabajos de gestión.

Para los administradores de red es preferible tener un único servidor DHCP por base, o incluso centralizar toda la gestión en un único servicio para toda la compañía.

Para permitir que un equipo dentro de una VLAN determinada, donde no hay servidor DHCP propio, pueda recibir la información necesaria simplemente deberemos indicar a qué servidor DHCP hay que redireccionar las peticiones dentro de la configuración de la VLAN correspondiente. Obviamente el switch deberá tener la configuración de enrutamiento necesaria para poder alcanzar dicho servidor.

Si bien esta configuración puede realizarse en cualquier equipo que tenga la VLAN definida para simplificar la configuración y facilitar la resolución de problemas es aconsejable realizar esta configuración únicamente en los equipos CORE de nuestra red.

Switch_HP(config)#vlan 55
Switch_HP(config-vlan)#ip helper-address 10.11.12.13