¿Existe una mejor manera de diseñar una red de administración fuera de banda?


7

Me han pedido que ayude en el diseño de una red de administración "OOB", pero tengo un número limitado de recursos disponibles. Tengo lo siguiente:

  1. 1 par de pila Cisco 3750-X con un módulo de red C3KX-NM-1G en cada uno.
  2. 8 Switches "agregados" Cisco 2960-24TC-L.

Ejecutamos una topología de red Core Colapsada de Capa 2 con un núcleo Cisco 6509-E VSS. Tenemos 128 conmutadores de acceso conectados a nuestro núcleo a través de canales de puertos de 1 Gps. Es una mezcla de enlaces ascendentes de cobre y fibra. Fibra hasta el segundo piso y cobre en nuestro centro de datos.

El pensamiento actual de nuestro consultor es configurar el SVI de administración en cada uno de nuestros conmutadores de acceso con su propia VLAN conectada a nuestros 2690 conmutadores "agregados". Los conmutadores agregados a su vez se vincularán a la pila 3750-X a través de un enlace troncal 802.1q y se configurarán con IP sin numerar para emular un enlace de capa 3 sin pasar, en esencia, la comunicación L2 entre los conmutadores de acceso de producción. La pila 3750-X tendrá un Loopback configurado para cada VLAN individual que los conmutadores de acceso de producción usarán como una puerta de enlace predeterminada.

La idea / preocupación es que no queremos que nuestra red de administración pase el tráfico STP a los otros conmutadores de acceso o arriesguemos cualquier tipo de convergencia de red entre las dos redes separadas. Tipo de configuración de VLAN privada de "Pobre hombre".

Me pregunto si esta es la mejor manera o la más eficiente de configurar esto o si hay una mejor manera de hacerlo.


¿Estoy entendiendo esto correctamente? 128 interruptores en una vlan ??
Mike Pennington

En la red de producción tenemos más de 250 VLAN. En la red de administración OOB diseñada provisionalmente, habría una VLAN por cada conmutador de acceso que estamos administrando. (Excluidos los dispositivos que tienen una interfaz de administración dedicada, por supuesto)
JDGray

¿Qué tipo de árbol de expansión estás ejecutando? pvst, pvst rápido, rstp o mst?
Mike Pennington

PVST rápido (modo transparente VTP) La decisión de crear una red de administración OOB surge de una interrupción relacionada con STP en la que perdimos toda la conectividad con nuestra red de administración en banda.
JDGray

1
rapid pvst es el mejor árbol de expansión para esta topología ... incluso podría considerar una interfaz enrutada directa de treinta bits en el chasis vss si eso pudiera eliminar por completo el árbol de expansión ...
Mike Pennington

Respuestas:


7

Sé que los 3750X tienen una interfaz de administración en la parte posterior que es un puerto 10/100 Fast Ethernet. Está justo al lado del puerto de consola RJ-45. También creo que el conmutador 2960 que enumeró allí también tiene un puerto de administración en la parte frontal, encima de los puertos SFP.

Suponiendo que sus conmutadores no estén demasiado lejos, puede usar las interfaces de administración para administrar sus dispositivos de forma remota si lo desea. Por supuesto, necesitaría un cableado adicional para otro "conmutador de administración" que probablemente contendría la VLAN requerida solo para administrar estos dispositivos.

De lo contrario, también podría ejecutar un servidor de servidor de terminal como un OpenGear o algo así y hacer que las conexiones de la consola se vinculen a este dispositivo para controlarlas de forma remota si toda su red tiene problemas o no.

Estas interfaces de administración operan en su propio VRF y tampoco participarán en STP ya que no se están ejecutando en la VLAN activa que se les está conectando. Sin embargo, lo he visto en donde a algunas organizaciones les gusta tener la VLAN de administración en la misma subred que los hosts en el conmutador. Esto les permite hacer ping y verificar la tabla de direcciones arp / mac y determinar dónde los dispositivos son un poco más fáciles que si se tratara de una simple red L2. Sin embargo, hay ventajas y desventajas de cada método, dado que querías elegir un método fuera de banda. Yo diría que la interfaz de administración es probablemente su mejor dirección.


3
DEBE tener RS232, por lo que OpenGear, antiguo CPE de Cisco con puerto de sincronización o similar. La interfaz de administración ON-BAND es de lujo opcional, casi no tiene ningún beneficio para administrar el conmutador a través de los enlaces de producción. Comparte completamente el destino con el mismo IOS y el mismo plano de control. Al menos a través de RS232, puede dividirlo en rommon y volver a cargarlo.
ytti

1
@ytti muy cierto! La interfaz de administración en banda también le permite imágenes TFTP y FTP para ayudar a actualizar el conmutador, etc.
knotseh

3
También puede usar la ruta de datos de producción para TFTP / FTP. La interfaz de administración en banda generalmente no está conectada a ASIC / NPU, sino que se encuentra directamente en el plano de control, lo que significa que no puede protegerla del dispositivo en sí. Lo que significa que incluso cosas accidentales, como un bucle en su red NMS, podrían derribar todos sus dispositivos a la vez. Si lo va a usar, limite el acceso a él de manera muy estricta desde el conmutador NMS. (La solución real a esto es 'CMP', verdadero 'enciende Ethernet' usando diferentes HW y SW dentro del dispositivo, por desgracia, solo algunos dispositivos en el mundo de las redes tienen esto)
ytti

Nuestros switches Cisco 2960 no tienen interfaces de administración. Esta es una de mis preocupaciones con respecto a que sea nuestra red "OOB", ya que la interfaz que usamos en nuestros conmutadores de acceso como puerto de "administración" seguirá estando en el avión de tráfico. Intenté venderlos usando un sistema basado en consola para la administración fuera de banda, pero insistieron en que querían hacerlo de esta manera para facilitar la actualización del IOS si fuera necesario. Sin embargo, nos firmaron con cables de consola dedicados a cada conmutador de acceso y compraron los conmutadores de consola, probablemente Avocent, el próximo año fiscal.
JDGray
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.