Evitar que mensajes de consola molesten al conectarnos a un equipos Cisco

Cuando estamos conectado a un equipo por consola es común que nos muestre por pantalla todas aquellas entradas de log que vaya surgiendo ya que, por defecto, la consola es la salida predeterminada de dichos mensajes. Este comportamiento, que es muy útil cuando estás depurando errores (con algún debug activado) puede ser muy molesto si estamos configurando ya que, nuevamente de forma predeterminada, los mensajes salen por pantalla desde el punto donde esté el cursor en este momento. Eso hace que los mensajes de log pueden aparecer en mitad de la escritura un comando dificultando el trabajo con el equipo.

en Cisco se incorpora una sencilla instrucción que hace que los mensajes que aparecen por pantalla lo hagan en una línea por debajo de lo que estamos escribiendo, sin solaparase, lo cual facilita mucho la gestión: logging synchronous

La activación de este comando sería

ROUTER#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
ROUTER(config)#line console 0
ROUTER(config-line)#logging synchronous 
ROUTER(config-line)#end
ROUTER#

Conocer estado configuración actual de una interfaz en H3C

Cuando realizamos cambios de configuración en los puertos de un switch por regla general la mayoría de fabricantes requieren que se elimine la configuración anterior y se configuren los nuevos requerimientos. Durante este proceso esa toma suele quedar inoperativa ya quela configuración está a medias. Además el orden de las instrucciones suele ser importante (p.e. en Cisco antes de poner una interfaz en modo trunk hay que especificar el encapsulamiento) por lo que hay veces que podemos perdernos al darnos error alguna instrucción y no saber cuál es la configuración exacta de la interfaz en un momento dado.

Los nuevos switches HP, aquellos que han surgido tras al integración con 3Com, incorporan una funcionalidad muy útil que nos permite ver la configuración de una interfaz concreta sin tener que recurrir a ver toda la configuración general: display this.

Con esta instrucción podemos ver la configuración actual de una interfaz en el momento preciso sin tener que salir de la configuración de la interfaz y recurrir a instrucciones del tipo display current-configuration | begin 1/0/15

[SWITCH01-GigabitEthernet1/0/15]display this
#
interface GigabitEthernet1/0/15
 port link-mode bridge
 port link-type trunk
 port trunk permit vlan all
#
return
[SWITCH01-GigabitEthernet1/0/15]

[SWITCH01-GigabitEthernet1/0/9]display this
#
interface GigabitEthernet1/0/9
 port link-mode bridge
#
return
[SWITCH01-GigabitEthernet1/0/9] 

cambio máscara de red switch HP remoto

Supongamos que debemos realizar un cambio de direccionamiento IP de un switch en remoto. En esa base no tenemos ningún técnico ni siquiera un manos remotas.

El procedimiento habitual en un equipo HP desde consola sería:

1. Entrar en la configuración de la vlan
2. Eliminar la IP actual
3. Añadir la nueva IP

vlan 100
no ip address 10.0.0.97 255.255.248.0
ip address 10.0.0.125 255.255.248.0

El problema de este procedimiento es que en el punto 2 el equipo se queda sin dirección IP y por lo tanto todas las conexiones ssh se pierden y no hay manera de recuperarlas (salvo reiniciando el equipo para que cargue la configuración previa con su IP).

Los switches HP tienen un modo de "configuración visual" vía ssh: la opción menú:

La ventaja de usar este menú es que el sistema carga la configuración directamente evitando el problema de desconexión. Para cambiar la dirección IP sería suficiente con seguir el siguiente procedimiento:

#menu
Seleccionar 2. Switch Configuration...
Seleccionar 4. IP Configuration
Avanzar hasta Edit
Modificar los parámetros que necesitemos (dirección IP, máscara, etc.)
Pulsar Intro (volvemos al menú inferior)
Pulsar Save

Aquí se pierde la conexión pero nos podremos reconectar con la nueva IP.

Ya tenemos la neva configuración de red en nuestro equipo :)

Resumen tras una semana de la publicación

Esta semana ha sido más atareada de lo esperado por lo que no he podido realizar un seguimiento adecuado a la publicación del manual ni realizar más promoción que la del primer día, así que los resultados muestran que mis amigos le han echado un vistazo y poco más. Esperemos que en un futuro la propagación sea mayor :)

Los datos en crudo:

- Visitas a la entrada del blog: 48 visitas. Una de las entradas más vistas del blog :)

- Visualizaciones del manual: 48 también

- Descargas del manual: 8 

Redes sociales:

- Twitter: 2 retweets

- Facebook: 0 Me gustas o comentarios

- Google+: 1 +1

- LinkedIn: 2 recomendaciones de personas que no conozco de nada

Si quieres aumentar la estadística... descargate el manual o reenvíalo a tus conocidos.

Y por si algún iluso tenía dudas... en PayPal: 0€, aunque esto estaba más que cantado :)

Gracias a todos por vuestro interés.

P.D. En cuanto baje mi ritmo de vida llegarán más entradas al Blog.

Recomendaciones de configuración en redes LAN

Esta entrada del blog sirve para anunciar la presentación al público del manual que he escrito con una serie de recomendaciones de configuración de switches para redes en entornos LAN.

El manual abarca desde las configuraciones mínimas para poder dar servicio y tener una gestión remota de los equipos a algunas configuraciones que permiten la securización de nuestra plataforma.

Existe muchas información sobre redes LAN en inglés, pero es más difícil de encontrar en castellano. Por ello tras varias entradas del blog decidí dar el siguiente paso y unificar la información en un único documento fácil de seguir.

Para cualquier duda o comentario podéis contactar conmigo en: recomendaciones.lan@gmail.com.

 

He decidido publicar el documento gratuitamente para facilitar al máximo su difusión, si bien si consideras que el manual te ha ayudado y quieres agradercerlo, además de enviar un mail, puedes hacer una donación con PayPal ;)

Podéis descargaroslo aquí en Calaméo.

Conocer todas las direcciones IP de un switch

En los equipos de capa 3 es posible,y en entornos no básicos probable, que un equipo tenga configuradas más de una dirección IP.

Los equipos pueden tener varias direcciones IP en cada interfaz, física o lógica, además estas direcciones estarán o no publicadas en los diferentes protocolos de enrutamiento. Los switches avanzados permiten configurar diferentes direcciones IP y rangos en las distintas VLAN.

Esta posible profusión de direcciones IP pertenecientes a diferentes subredes con los problemas de enrutamiento correspondiente hace que a veces necesitemos saber de un vistazo qué direccionamiento IP tiene un equipo en concreto para evaluar el correcto funcionamiento o localizar una avería.

En los switches HP la instrucción es muy simple: show ip. Con este comando podremos ver de un vistazo las diferentes VLAN definidas en el equipo y su dirección IP, si la hubiera.

Switch_HP# show ip
 Internet (IP) Service
  IP Routing : Disabled
  Default Gateway : 10.10.1.1  
  Default TTL     : 64
  Arp Age         : 20
  VLAN         | IP Config  IP Address      Subnet Mask  
  ------------ + ---------- --------------- ---------------
  DEFAULT_VLAN | Disabled
  WIRELESS     | Manual    10.10.4.13
  SWITCHES     | Manual     10.10.1.13      255.255.255.0
  TELEFONOS    | Disabled

Switch_HP# 

En los switches CISCO podremos ver esta información de todas las interfaces físicas y lógicas (Port-Channel, vlan, loopback, etc.).

Switch_CISCO#sh ip interface brief
Interface              IP-Address      OK? Method Status                Protocol
Vlan1                  unassigned      YES NVRAM  administratively down down  
Vlan10                 10.10.10.14     YES NVRAM  up                    up    
Vlan11                 10.10.11.14     YES NVRAM  up                    up    
GigabitEthernet1/0/1   unassigned      YES unset  down                  down  
GigabitEthernet1/0/2   unassigned      YES unset  up                    up    
GigabitEthernet1/0/3   unassigned      YES unset  down                  down  
GigabitEthernet1/0/4   unassigned      YES unset  administratively down down  
GigabitEthernet1/0/5   unassigned      YES unset  up                    up    
GigabitEthernet1/0/6   unassigned      YES unset  up                    up    
GigabitEthernet1/0/7   unassigned      YES unset  down                  down  
...
...
 
GigabitEthernet1/0/25  unassigned      YES unset  up                    up    
GigabitEthernet1/0/26  unassigned      YES unset  up                    up    
GigabitEthernet1/0/27  unassigned      YES unset  down                  down  
GigabitEthernet1/0/28  unassigned      YES unset  administratively down down  
Port-channel1          unassigned      YES unset  down                  down  
Port-channel2          unassigned      YES unset  down                  down  
Port-channel3          unassigned      YES unset  up                    up    
Port-channel4          unassigned      YES unset  up                    up    
Switch_CISCO#

Con estos comandos y de un ismple vistazo podemos tener una visión global de la configuración IP de los equipos.

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#

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

Password Recovery en switch HP

Podemos encontrarnos en la situación de tener que realizar un cambio de configuración en un switch al cual no podemos conectarnos en remoto ni por consola.

Existe un procedimiento para reiniciar el equipo HP Procurve de tal forma que el equipo arranque con la configuración actual pero sin estar protegido por contraseña. Este procedimiento implica acceso físico al equipo y el reinicio del mismo por lo que se deberá tener en cuenta en caso de tratarse de un equipo productivo.

1. Accederemos físicamente al equipo y buscaremos el botón "Clear".

2. Pulsamos el botón "Clear" durante 10 segundos. Es posible que debamos pulsar el botón con un clip o similar. En este momento se reinicia el equipo por lo que habrá una pérdida de servicio.

3. Una vez el equipo se haya reiniciado podremos acceder normalmente (vía consola, telnet o ssh, según la configuración que tenga el equipo). Una vez dentro del equipo podremos cambiar las contraseñas locales o revisar la configuración de autenticación remota.

Securizar los protocolos de acceso remoto a switches HP

En la configuración de fábrica de los switches HP viene activado el acceso a los equipos vía telnet que es un protocolo de acceso no cifrado, es decir que toda la información que viaja entre nuestro ordenador y el switch va en texto plano (incluyendo las contraseñas) y por lo tanto es susceptible de ser interceptada.Existe un protocolo con las mismas funcionalidades que telnet pero con una conexión cifrada: ssh.

Obviamente si realizamos esta configuración en remoto primero activaremos el protocolo ssh antes de desactivar los de acceso en telnet.

1. Activar protocolo ssh

Para activarlo deberemos crear una clave de cifrado en el switch y posteriormente activar el protocolo.

crypto key generate ssh
ip ssh

2. Desactivar la opción del protocolo telnet

Una vez confirmado que tenemos acceso al equipo usando el nuevo protocolo procederemos a desactivar la opción de telnet.

no telnet-server

Configuración básica SNMP en switches HP Procurve

El protocolo SNMP nos permite monitorizar remotamente muchos parámetros de nuestros equipos, desde el consumo de CPU o memoria, al ancho de banda consumido en una interfaz. Con esa monitorización remota podremos conocer el estado de nuestra red de forma fácil y centralizada.

La configuración del protocolo SNMP en switches HP Procurve se basa en definir diferentes comunidades SNMP y la definición de los servidores desde los que aceptar las peticiones. Si hemos securizado el acceso a los equipos con el comando ip authorized-managers hay que añadir la dirección de los servidores SNMP dentro de los rangos permitidos.

El stándar SNMP, RFC1157, indica cómo estándar la comunidad de sólo lectura public. La primera medida de seguridad es no utilizar dicha comunidad sino una creada específicamente para nuestro entorno. Si se desea se puede generar una comunidad de sólo lectura para los entornos de monitorización y una que sí permita el envío de parámetros al equipo desde un entorno más cerrado.

Existe una versión mejorada del protocolo, SNMPv3, que mejora en gran medida la seguridad e integridad del protocolo base ya que permite la encriptación del tráfico y una autenticación de los equipos basada en sistemas de claves, etc. Si bien con el protocolo sencillo se cumplen la mayoría de las funciones en casi todos los entornos, pero que en casos especiales (banca, seguridad, etc.) debería usarse el más moderno y seguro.

En el siguiente ejemplo, la empresa NewSwitchingTech, quiere monitorizar todos los switches de su red desde un servidor central.

1. Desactivamos la comunidad public

no snmp-server community public

2. Definimos nuestras comunidades SNMP (sólo lectura, acceso total)

snmp-server community NST-sl manager restricted
snmp-server community NST-at manager unrestricted

3. Definimos desde qué servidor esperar peticiones SNMP y con qué comunidad. 

snmp-server host 10.10.10.5 community "NTS-sl"

4. Nos aseguramos que este servidor esté dentro de la lista de accesos permitidos

ip authorized-managers 10.10.10.5 255.255.255.255

Logs remotos en HP Procurve

En una entrada anterior vimos cómo configurar el envío de los logs a un servidor remoto en equipos CISCO.  En esta entrada veremos la misma configuración para equipos HP Procurve.

La configuración básica en estos equipos es tan sencilla como identificar los servidores donde queremos enviar los loggs:

logging 10.10.10.3

Sincronizar hora en switches

Si hemos centralizado los logs en un único servidor es conveniente que todos los equipos tenga la misma hora. Para ello haremos uso de un servidor NTP accesible en la red.

CISCO:

La configuración del protocolo NTP en CISCO es sencilla. Simplemente hay que indicarle al equipo cuáles son los servidores que queremos usar:

ntp server 10.10.10.3
ntp server 192.168.10.23

HP Procurve:

En estos equipos hay que configurar el protocolo y posteriormente aplicarlo:

1. Configurar el protocolo consiste en indicarle el servidor al que queremos solicitar la hora y el modo de uso:

sntp server 10.10.10.3
sntp server 192.168.10.23
sntp unicast

2. Aplicar la configuración del protocolo al sistema de hora del equipo:

timesync sntp

Logs remotos en CISCO

Cuando el número de equipos se incrementa se hace necesario centralizar los registros de eventos en un único punto. Es conveniente pues montar un servidor de syslog. 

Una vez tengamos el servidor configurado hay que configurar los equipos para que envíen los registros de logs al servidor remoto.

1. Definimos el servidor al que enviar los logs:

logging 10.10.10.10

2. Definimos el nivel de logs que queremos enviar al servidor. Puede que sólo queramos enviar los eventos críticos o todos.

La tabla de niveles de logs es la siguiente:

0—emergencies

1—alerts

2—critical

3—errors

4—warnings

5—notification

6—informational

7—debugging

El comando sería:

logging facility local5

3. A continuación configuramos el equipo para que envíe los logs al servidor con origen una de las direcciones IP del equipo. Esto es importante por si hay que gestionar permisos en firewalls. En el ejemplo usaremos como origen la IP definida en la interface vlan2:

logging source-interface Vlan2

4. Al ser un servidor centralizado de logs en dicho servidor habrá registros de todos los los equipos por lo que para poder discriminar qué logs son de qué equipo se puede usar dos parámetros: la IP del equipo o el hostname. Los comandos serían:

logging origin-id ip
logging origin-id hostname

Securizar acceso por consola a un switch CISCO

En una entrada anterior configuramos los switches para controlar el acceso remoto. También hemos visto como securizar el acceso por consola física a un switch HP. En esta entrada veremos como securizar este mismo acceso a la consola física en un switch CISCO. Nuevamente esta configuración debería aplicarse en todos aquellos switches que no estén directamente controlados por el personal del departamento de redes.

Si el equipo sólo dispone de usuarios locales la configuración sería:

1. Definir el modelo de autenticación

SW_CISCO(config)#aaa new-model

2. Definimos dos roles de autenticación: el general y el de acceso por consola. Es aconsejable que la consola física tenga un rol propio ya que nos permitirá que en caso de configurar TACACS+ en un futuro no perdamos el acceso por consola a un switch fuera de red.

SW_CISCO(config)#aaa authentication login default local
SW_CISCO(config)#aaa authentication login CONSOLE local

3. Aplicamos el rol creado a la consola:

SW_CISCO(config)#line con 0
SW_CISCO(config-line)#login authentication CONSOLE

Si en un futuro configuramos tacacs+ simplemente habría que cambiar el rol por defecto sin afectar al acceso por consola:

SW_CISCO(config)#aaa authentication login default tacacs+ local

Securizar acceso por consola a un switch HP

En una entrada anterior configuramos los switches para controlar el acceso remoto. En esta entrada veremos cómo conseguir que aunque alguien se conecte físicamente por la consola del equipo se le pida contraseña. Esta configuración debería ser aplicada en todos los switches de una ubicación no controlada por los administradores de red (sedes remotas, habitación con acceso de personal externos). Cabe indicar que es un requisito de la normativa PCI DSS.

Si tan sólo hemos definido las contraseñas locales la configuración sería:

SwitchHP(config)# aaa authentication console login local
SwitchHP(config)# aaa authentication console enable local

Si nuestro equipo tiene configurado un sistema de autenticación externo (RADIUS, TACACS+), la configuración indica en qué orden debe buscar el acceso. En el siguiente ejemplo buscaría primero en el servidor RADIUS externo y si no existiera allí revisaría la configuración local.

SwitchHP(config)# aaa authentication console login radius local
SwitchHP(config)# aaa authentication console enable radius local

Limitar el acceso a switches

Una regla básica para mantener una red segura es limitar el acceso a los equipos. 

La seguridad de acceso incluiría dos grandes accesos:

Seguridad física

La opción más simple es tener los equipos en salas cerradas con llave donde los usuarios no tengan acceso. Lamentablemente esto no es siempre posible.

Seguridad lógica

Los equipos están en la misma red física que los usuarios y por ello debemos asegurarnos de que no puedan acceder. Una buena estrategia es usar una VLAN específica para la gestión siempre diferente a la de usuarios.

Aún dificultando el acceso al tener diferentes VLAN hay que asegurarse que las conexiones remotas a los equipos (ssh, https), además de requerir usuario y contraseña, estén limitadas a aquellas con origen el departamento de redes de nuestra empresa.

HP:

El fabricante HP utiliza una estrategia sencilla para asegurar que las conexiones entrantes sean del departamento que nos interesa. Definimos las direcciones IP de aquellos que están autorizados a acceder. Esta limitación general aplica a todos los métodos de acceso (telnet, ssh, http, https):

ip authorized-managers 10.10.10.0 255.255.255.192
ip authorized-managers 10.20.10.0 255.255.255.192

CISCO:

El fabricante CISCO recurre a las access-list de tal forma que definimos una lista con aquellas direcciones que queremos permitir para posteriormente aplicar dicha ACL a la confiugración de accesos.

access-list 19 permit 10.10.10.0 0.0.0.64
access-list 19 permit 10.10.20.0 0.0.0.64
line vty 0 4
 access-class 19 in
 transport input ssh

Con esta configuración forzamos que el acceso sea únicamente vía ssh con 5 sesiones máximo y limitamos los rangos de acceso.

Evitar switches no controlados en nuestra red

Sala de reuniones de una empresa mediana (tres consultores y un cliente...)

[Consultor 1] Oye José. Necesito bajarme el correo para recibir la última versión del powerpoint.

[Cliente] OK. Conectate en esa toma de pared.

[Consultor 2] Pues a mí también me iría bien conectarme.

[Cliente] Tú mismo...

[Consultor 3] ¿Puedo... ?

[Cliente] Sí claro.

[Consultor 3] Pues no quedan tomas libres...

[Consultor 1] Tranquilo Tomás, que yo tengo un switch... Mira lo conectamos a la pared y nosotros dos al switch.

....

[voces del exterior] ¿Tenéis Internet?.. Yo no, ¿tú? ... Me da un error la Excel...

Mientras tanto en la sala de explotación de redes...

[Ingeniero 1] Miguel, necesito los presupuestos para el mantenimiento del año que viene de los radioenlaces..

[Ingeniero 2] Sí... ya me lo pediste ayer...

Aparece una luz roja en la pantalla de monitorización de sistemas

[Ingeniero 1] Mierda. Se ha ido la red de la oficina de Teruel.

La aparición de un switch no controlado puede tirarte toda una red y dejando en nada meses de planificación, configuración y estabilización de tu red de usuarios.

No te puedes fiar de que los usuarios no conecten nada a la red (aunque siempre juren no hacerlo), así que tenemos que controlarlos nosotros mismos.

El principal problema de que conecten un switch no controlado en nuestra red es que pueda producir un cambio en la topología del arból de STP. Estos cambios pueden ser imperceptibles o provocar problemas (a la Telefonia IP no le gustan los cambios).

Los switches de gama media permiten dos acciones para este problema:

• Ignorar los mensajes del protocolo STP que envíe un switch no controlado.
• Bloquear la toma donde se conecte un switch no controlado.
• Avisar, vía SNMP, a los gestores de red.

Al aplicar estas políticas es muy importante tener un mapa de red con el conexionado físico de los equipos, ya que debemos permitir el tráfico de BPDU en aquellos enlaces conectados físicamente (estén activos o deshabilitados por STP) para evitarnos sorpresas al activarse caminos de backup (ante la caída de un switch la topología puede cambiar bastante, según la red que haya montada).

Para configurar estas protecciones simplemente debemos entrar en la configuración de spanning-treey activar estas opciones de securización.

En HP:

switch06(config)# spanning-tree 1-47 bpdu-filter bpdu-protection