Cisco: switches, routers y salas de comunicaciones de una sede con sala de trading

Qué vas a conseguir

Una sala de comunicaciones en la que un fallo de una fuente, de un switch o de un circuito no deja a nadie sin red, y en la que cualquier técnico del equipo sabe qué hay, dónde está cada cable y cómo entrar a un equipo aunque la red esté caída. En una sede con sala de trading la red no puede pararse en horario de mercado: cada minuto sin red en una mesa es una posición que nadie puede gestionar. Esta guía no repite VLANs ni troncales (están en la guía de Cisco del Nivel 4); se centra en cómo se diseña y se opera la sala para que esa exigencia se cumpla.

Antes de empezar

• El inventario de la sala: núcleo, pilas de acceso, routers, firewalls, servidor de consolas, SAI y PDU, con su número de serie y su contrato de soporte.
• El calendario de mercado que aplica a la sede (apertura, cierre, festivos de cada mercado en el que se opera) y la ventana de cambios acordada con el negocio.
• Los identificadores de circuito de cada operadora y su teléfono de incidencias 24x7.
• Acceso al gestor de contraseñas del equipo, con las credenciales locales de los equipos y del servidor de consolas.

1. Energía y redundancia

La regla es que nada crítico dependa de un solo elemento:

• Dos fuentes en cada switch y router, cada una a una PDU distinta, y cada PDU a un SAI distinto (o a dos ramas del mismo sistema de alimentación de la sede). Una fuente a la PDU A y otra a la PDU A no es redundancia.
• Núcleo en pareja: dos switches de núcleo (StackWise Virtual o una pareja con HSRP/VRRP, según el diseño), con los uplinks de cada pila de acceso repartidos entre los dos.
• Pilas de acceso con el cable de pila cerrado en anillo y, si el modelo lo permite, StackPower. Si un miembro cae, la pila sigue con los demás.
• Los puestos de una mesa repartidos entre miembros de la pila: si el puesto principal de un trader va al switch 2, su segundo equipo o su teléfono de mesa va al switch 3. Así, perder un miembro deja a la mesa a medio gas, no a oscuras.
• Dos routers o circuitos de operadoras distintas, con entradas al edificio por caminos distintos cuando el edificio lo permite.

Pide al responsable de instalaciones la autonomía real del SAI con la carga actual y la prueba del grupo electrógeno. El dato de la placa no sirve si se añadieron racks desde la instalación.

2. Etiquetado y cableado

• Colores fijos: por ejemplo, azul para puestos, amarillo para enlaces entre equipos, rojo para gestión y consola.
• La hoja de puertos (toma, panel, switch, puerto, VLAN) vive en un sitio único y se actualiza en el mismo cambio que mueve el cable. Una hoja desactualizada es peor que ninguna, porque alguien la creerá.
• Nada de latiguillos colgando entre racks ni cableado que tape las fuentes: cambiar una fuente en caliente no debe exigir mover cables de producción.

3. Consola fuera de banda y copias de configuración

Si el núcleo se cae, no vas a llegar a él por la red que él mismo da. El servidor de consolas tiene un cable de consola a cada equipo de la sala, su propia salida (una línea de datos móviles o un circuito independiente) y acceso solo para el equipo de redes, con MFA. Los puertos de gestión de los equipos van a una red de gestión separada.

Cada equipo guarda copias locales de su configuración al guardarla, y además una herramienta central (la de monitorización o un script programado) las recoge cada noche.

›show running-config | section archivearchive path flash:/archive/cfg maximum 10 write-memory time-period 1440›show archiveThe maximum archive configurations allowed is 10.There are currently 3 archive configurations saved.The next archive file will be named flash:/archive/cfg-4 Archive #  Name   1        flash:/archive/cfg-1   2        flash:/archive/cfg-2   3        flash:/archive/cfg-3 <- Most Recent

Con write-memory se guarda una copia cada vez que alguien hace write memory, y con time-period también una al día. Compara la copia central de anoche con la configuración actual antes de cualquier cambio: así sabes si alguien tocó algo fuera de procedimiento.

4. Ventanas de cambio y visitas de operadoras

• Fuera del horario de mercado: los cambios en núcleo, routers y pilas que dan servicio a la sala de trading se hacen por la noche o en fin de semana, con el calendario de festivos a la vista. Un día festivo en un mercado puede ser laborable en otro en el que la sede opera.
• Congelación en fechas sensibles: cierres de trimestre, vencimientos y días de publicación de datos macroeconómicos relevantes para la mesa. El negocio te dirá cuáles.
• Cada cambio con plan de vuelta atrás probado, persona de redes en la sala o con consola, y una prueba de humo al terminar: un puesto de cada mesa con red, plataformas de mercado conectadas, telefonía de mesa con tono.
• Visitas de operadoras: siempre con ticket previo, nombre del técnico, identificador del circuito y alguien de IT acompañando. El técnico de una operadora toca su equipo, no el tuyo; si para su trabajo hay que reiniciar tu router, eso es un cambio y va en ventana.

Una intervención "sin impacto" de una operadora a las 10:00 en un día de mercado no existe. Pide que se haga en ventana aunque digan que no corta.

5. El ticket: "una mesa de trading se ha quedado sin red a las 8:55"

Cinco minutos antes de la apertura, seis puestos de la mesa de renta fija no tienen red. Los teléfonos de la misma mesa sí funcionan.

1. Acota: seis puestos de una misma fila y los teléfonos funcionando apunta a un elemento común, no a seis cables.
2. La hoja de puertos dice que esos seis puestos van todos al switch 3 de la pila de la planta 3, y los teléfonos al switch 2.
3. La pila:

›show switchSwitch/Stack Mac Address : 0c11.6700.1a00 - Local Mac AddressMac persistency wait time: Indefinite                                             H/W   CurrentSwitch#   Role    Mac Address     Priority Version  State-------------------------------------------------------------*1       Active   0c11.6700.1a00     15     V02     Ready 2       Standby  0c11.6700.2b00     14     V02     Ready 3       Member   0000.0000.0000      0             Removed›show logging | include STACKMGROct 28 08:53:12: %STACKMGR-6-SWITCH_REMOVED: Switch 1 R0/0: stack_mgr: Switch 3 has been removed from the stack.

1. En la sala: el switch 3 está apagado. Tiene una sola fuente instalada (la segunda nunca se llegó a pedir) y está conectada a la PDU B, que ha saltado.
2. Recuperar ya: rearma la PDU si instalaciones confirma que es seguro; si no, mueve los seis latiguillos a puertos libres del switch 1 o 2 en la misma VLAN (consulta la hoja) y anota el cambio. Prioridad: la mesa operando a las 9:00.
3. Después: pide la segunda fuente, revisa qué más tiene una sola fuente o una sola PDU, y reparte los puestos de esa mesa entre miembros, como en la sección 1. El informe de la incidencia dice causa, tiempo sin servicio y qué se cambia para que no se repita.

6. Lo que revisas cada mes

• Fuentes y PDU: que cada equipo tiene dos fuentes en estado correcto (show environment power) y cada una en una PDU distinta.
• El estado del SAI y su autonomía, con instalaciones.
• Que la copia central de configuración de anoche existe para todos los equipos y que no hay diferencias sin cambio aprobado.
• El servidor de consolas: que llegas a cada equipo y que su línea de salida funciona.
• La hoja de puertos contra la realidad en una muestra de tomas.
• El soporte y el fin de vida de los equipos de la sala.

Siguientes pasos

• La guía de Cisco: switches y routers del Nivel 4 cubre VLANs, troncales, el router con circuito de respaldo y los cambios en remoto con red de seguridad.
• La guía de Fortinet FortiGate cubre el firewall que suele estar en la misma sala.
• La guía de SolarWinds sirve para vigilar fuentes, pilas y circuitos y guardar las configuraciones.
• La guía de Backup y DR/BCP sitúa la sala en el plan de continuidad de la sede.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.