Mi primera entrada en el BLOG

Hola,

Me llamo Juan Miguel Huertas Alegre (JMHAlegre), nací en septiembre de 1972, estoy casado y tengo un niño de 8 años.

Tengo la titulación de Técnico Especialista en Informática de Gestión, y llevo metido en el mundo de las TIC desde hace más de 18 años. Empecé trabajando como formador, dando clases de Ofimática, realizando tareas de instalación y reparación de equipos de sobremesa, y manteniendo una red Novell, “que tiempos aquellos”. Durante los años que estuve realizando formación, me fui introduciendo en el mundo de la programación (Clipper, RPG, Cobol, …), hasta que en 1999 empecé a trabajar como programador de Visual Basic realizando aplicaciones CRM. En el 2003 me surgió un proyecto en el cual realicé tareas de Administrador/Técnico de Redes, configurando electrónica de fabricantes como Cisco, Enterasys, Juniper, Nortel y otros. En mi último trabajo, estuve en Vodafone España S.A.U. durante 1 año y medio, gestionando averías de Voz/Datos.

Actualmente estoy trabajando para INDRA como Ingeniero de Soporte N2 en el área de voz – LinkedIn: Juan Miguel Huertas Alegre

En cuanto a mis aficiones, me gusta la pesca (Carpa, Black Bass,…), y cuando tengo tiempo, también me gusta cocinar.

He creado este blog para compartir información relacionada con las TIC, principalmente temas relacionados con Cisco (certificaciones, documentación,…). Aunque también me gustaría debatir sobre temas relacionados con la pesca (lugares de pesca, señuelos,…), la cocina (recetas,…), etc.

Un saludo a tod@s,

JMHAlegre

Publicado en General | Etiquetado , | 4 comentarios

CCNP SWITCH 642-813 Official Certification Guide (Part II – Chapter 8 Respuestas correctas test)

1. Where should the root bridge be placed on a network?

a. On the fastest switch

b. Closest to the most users

c. Closest to the center of the network

d. On the least-used switch

2. Which of the following is a result of a poorly placed root bridge in a network?

a. Bridging loops form.

b. STP topology can’t be resolved.

c. STP topology can take unexpected paths.

d. Root bridge election flapping occurs.

3. Which of these parameters should you change to make a switch become a root bridge?

a. Switch MAC address

b. Path cost

c. Port priority

d. Bridge priority

4. What is the default 802.1D STP bridge priority on a Catalyst switch?

a. 0

b. 1

c. 32,768

d. 65,535

5. Which of the following commands is most likely to make a switch become the root bridge for VLAN 5, assuming that all switches have the default STP parameters?

a. spanning-tree root

b. spanning-tree root vlan 5

c. spanning-tree vlan 5 priority 100

d. spanning-tree vlan 5 root

6. What is the default path cost of a Gigabit Ethernet switch port?

a. 1

b. 2

c. 4

d. 19

e. 1000

7. What command can change the path cost of interface Gigabit Ethernet 3/1 to a value of 8?

a. spanning-tree path-cost 8

b. spanning-tree cost 8

c. spanning-tree port-cost 8

d. spanning-tree gig 3/1 cost 8

8. What happens if the root bridge switch and another switch are configured with different STP Hello timer values?

a. Nothing—each sends hellos at different times.

b. A bridging loop could form because the two switches are out of sync.

c. The switch with the lower Hello timer becomes the root bridge.

d. The other switch changes its Hello timer to match the root bridge

9. What network diameter value is the basis for the default STP timer calculations?

a. 1

b. 3

c. 7

d. 9

e. 15

10. Where should the STP PortFast feature be used?

a. An access-layer switch port connected to a PC

b. An access-layer switch port connected to a hub

c. A distribution-layer switch port connected to an access layer switch

d. A core-layer switch port

11. Where should the STP UplinkFast feature be enabled?

a. An access-layer switch.

b. A distribution-layer switch.

c. A core-layer switch.

d. All these answers are correct.

12. If used, the STP BackboneFast feature should be enabled on which of these?

a. All backbone- or core-layer switches

b. All backbone- and distribution-layer switches

c. All access-layer switches

d. All switches in the network

13. Which one of the following commands can be used to verify the current root bridge in VLAN 10?

a. show root vlan 10

b. show root-bridge vlan 10

c. show spanning-tree vlan 10 root

d. show running-config

Saludos a tod@s,

JMHAlegre

Publicado en CCNP SWITCH 642-813 Official Certification Guide (Part II – Chapter 8 Respuestas correctas test), Cisco, SWITCH 642-813 | Etiquetado | Deja un comentario

CCNP SWITCH 642-813 Official Certification Guide (Part II – Chapter 8.5 Monitoring STP)

5. Monitoring STP

Debido a que STP utiliza diferentes tipos de contadores y cálculos dinámicos, predecir su estado es complejo. Para resolver y verificar el funcionamiento de STP podemos utilizar los siguientes comandos:

Commands for Dsiplaying Spanning-tree Information

Commands for Dsiplaying Spanning-tree Information

Saludos a tod@s,

JMHAlegre

Publicado en CCNP SWITCH 642-813 Official Certification Guide (Part II – Chapter 8.5 Monitoring STP), Cisco, Documentacion, libros y aplicaciones CCNP | Etiquetado , , | Deja un comentario

Documentacion, libros y aplicaciones para obtener la certificación de Cisco CCNP

DOCUMENTACIÓN y APLICACIONES para obtener certificación Cisco CCNP

Documentación

SWITCH 642-813

CCNP_SWITCH_642-813_Official_Certification_Guide
CCNP SWITCH Portable Command Guide
CCNP SWITCH 642-813 QUICK REFERENCE GUIDE
 
en_SWITCH_ILM_v6000
en_SWITCH_SLM_v6000
 
ICSN Course Admin Guide
ICSN Foundation_Learning_Guide
ICSN Lab Guide
 
Student Guide_Vol1
Student Guide_Vol2
 

ROUTE 642-902

CCNP ROUTE 642-902 Official Certification Guide
CCNP ROUTE 642-902 Quick Reference
CCNP ROUTE Complete Guide 1st Edition
CCNP ROUTE Portable Command Guide
 
en_ROUTE_ILM_v6000
en_ROUTE_SLM_v6000
 
IC IP_Routing Course Administration Guide
IC IP_Routing Lab Guide
IC IP_Routing Student Guide_Vol1
IC IP_Routing Student Guide_Vol2
IC IP_Routing Student Guide_Vol3
 

TSHOOT 642-832

CCNP_TSHOOT_642-832_Official_Certification_Guide
642-832_Foundation_Learning_Guide
 
en_TSHOOT_ILM_v60
en_TSHOOT_SLM_v60
 
TM CIP_Networks Course Administration Guide
TM Cisco IP Networks Lab Guide
TM Cisco IP Networks Student Guide_Vol1
TM Cisco IP Networks Student Guide_Vol2
 

Aplicaciones

Boson Netsim 8.0
Cisco Packet Tracer 5.3.2

 

Saludos a tod@s,

JMHAlegre

Publicado en Cisco, Documentacion, libros y aplicaciones CCNP | Etiquetado , , , , , , , | 1 Comentario

CCNP SWITCH 642-813 Official Certification Guide (Part II – Chapter 8.4 Redundant Link Convergence)

4. Redundant Link Convergence

Existen métodos adicionales que hacen que la convergencia STP sea más rápida en casos en los que falle un enlace. Estos métodos se definen a continuación:

  • Port Fast, este método habilita la conectividad rápida para aquellos puertos conectados a estaciones de trabajo o equipos terminales (Host).
  • Uplink Fast, este método habilita el enlace uplink rápido de un switch en la capa de acceso cuando existen coneciones duales hacia la capa de distribución.
  • Backbone Fast, este método habilita una convergencia rápida en el core después de una cambio de topología STP.

Port Fast: las estaciones de trabajo (Host) de los usuarios finales, están conectadas a los puertos de los switches ubicados en la capa de acceso. Cuando un host se reinicia, el switch verifica el cambio de estado del puerto lo que significa que éste no estará disponible hasta que los tiempos permitan que pase del estado de bloqueado a enviando. Con los temporizadores por defecto de STP la transición lleva unos 30 segundos, esto implica que el host no podrá enviar ni recibir datos hasta que transcurra dicho período. En el caso de que utilicemos un enlace EtherChannel con PAgP, tendremos que sumarle unos 20 segundos más.

En los puertos de un switch en los que conectamos estaciones de trabajo, nunca se crearán bucles de capa 2. Los switches Catalyst ofrecen la característica port fast la cual reduce los tiempos de cambio de estado en STP. Cuando el enlace del host levanta en un puerto configurado con port fast, el switch mueve el estado del puerto a enviado inmediatamente.

Una de las ventajas es que las BPDU TCN no son enviadas ante los cambios de estado de los puertos configurados con port fast.

Por defecto port fast está deshabilitado en todos los puertos, con lo que si queremos utilizar esta característica en todos los puertos de acceso, utilizaremos el siguiente comando:

switch(config)#spanning-tree portfast default

Si queremos deshabilitar esta característica, utilizaremos el siguiente comando:

switch(config)#no spanning-tree portfast default

Debemos tener presente que un puerto conectado a un dispositivo de capa 2 o un hub no debe tener habilitada esta opción.

También podemos configurar esta característica en un puerto específico del switch mediante el comando:

STP Portfast

Si queremos verificar el estado de un puerto, podemos hacerlo mediante el comando:

switch#show spanning-tree interface type mod/num portfast

Uplink Fast: si tomamos como ejemplo un switch de la capa de acceso el cual tiene enlaces redundantes (uplink) hacia los switches de distribución, por norma general un enlace estará en estado enviando mientras que el otro estará en estado bloqueado. En caso de que el enlace activo falle, deberemos esperar 50 segundos antes de que el enlace bloqueado pase al estado de enviando.

La característica Uplink Fast permite mantener un enlace en estado enviando y el resto en estado bloqueado, con la particularidad de que si el enlace en estado enviando falla, el enlace en estado bloqueado pasa inmediatamente a estado enviando.

switch(config)#spanning-tree uplinkfast [max-update-rate pkts-per-second]

Cuando habilitamos Uplink Fast, lo hacemos para todos los puertos y todas las VLAN’s, de esta forma se mantiene un registro de todos los posibles caminos hacie el root bridge. Esta configuración no está permitida en el root bridge, en el momento que configuramos uplink fast, la prioridad del switch cambia a 49152 haciendo que su elección como root bridge sea prácticamente imposible. También incrementa el coste de los puertos a 3000 para que estos no sean enlaces deseados hacia el root bridge.

El switch avisa del nuevo estado de los enlaces enviando tramas multicast con destino 0100.0ccd.cdcd en lugar de las estaciones contenidas en la tabla CAM. De esta forma conseguimos que los host aprendan las direcciones MAC hacia el origen.

A continuación se muestra un ejemplo de UplinkFast:

STP UplinkFast

BackboneFast: para que la convergencia sea más rápida en la capa de core, utilizamos el método BackboneFast, el cual mantiene al switch constantemente comprobando si existen caminos alternativos hacia el root bridge por si se detecta un fallo de enlace indirecto. Estos fallos ocurren cuando un enlace que no está directamente conectado falla. Cuando el switch recibe una BPDU inferior desde su bridge designado en su puerto raíz o en un puerto con estado bloqueado, detectará un fallo en enlace indirecto. Las BPDU’s con un número de secuencia inferior son enviados por los bridges designados que han perdido su conexión con el root bridge y estos se anuncian a sí mismos como nuevos root bridge.

Normalmente un switch debe esperar a que los temporizadores de max age expiren para responder a BPDU’s inferiores a las que ya se conocen. Pero con BackboneFast se puede determinar cuándo existen otros caminos alternativos hacia el root bridge según los tipos de puertos que reciben las BPDU’s inferiores:

  • Si la BPDU inferior se recibe en un puerto que está en estado bloqueado, el switch considera el root port y todos los demás puertos en estado bloqueado como caminos alternativos hacia el root bridge.
  • Si una BPDU inferior llega al root port, el switch considerará todos los puertos que están en estado bloqueado como caminos alternativos hacia el root bridge.
  • Si la BPDU llega al root port y no existen puertos bolqueados, el switch asume que ha perdido la conectividad con el root bridge. BackboneFast permite estos mecanismos antes de que el temporizador de max age expire.

Detectar caminos alternativos hacia el root bridge implica un proceso interactivo con otros switches. Si el switch local tiene puertos cloqueados, BackboneFast utiliza el protocolo RLQ (Root Link Query) para verificar que los switches que tiene por encima tienen conexiones establecidas hacia el root bridge.

BackboneFast es fácil de configurar y opera haciendo que el temporizador max age sea más breve  cuando es necesario. Todo y esto, los puertos deberán pasar por los estados de escuchando/aprendiendo. Finalmente este proceso queda reducido de 50 a 30 segundos.

Para configurar esto, utilizaremos el siguiente comando:

switch(config)#spanning-tree backbonefast

BackboneFast debe estar habilitado en todos los switches de la red debido al requerimiento de peticiones RLQ para mantener informados a todos los switches sobre la estabilidad de la red. El protocolo RLQ sólo funciona si BackboneFast esta configurado.

Para verificar el funcionamiento de BackboneFast, utilizaremos el siguiente comando:

switch#show spanning-tree backbonefast

A continuación os adjunto un ejemplo en el que se realiza la configuración de portfast y uplinkfast y se realizan una serie de verificaciones para comprobar la convergencia de la red.

 

Saludos a tod@s,

JMHAlegre

Publicado en CCNP SWITCH 642-813 Official Certification Guide (Part II – Chapter 2 Switch Operation), CCNP SWITCH 642-813 Official Certification Guide (Part II – Chapter 8.4 Redundant Link Convergence), Cisco, SWITCH 642-813 | Etiquetado , , , , , , , , , | Deja un comentario

CCNP SWITCH 642-813 Official Certification Guide (Part II – Chapter 8.3 Tuning Spanning-Tree Convergence)

3. Tuning Spanning-Tree Convergence

STP utiliza varios temporizadores, una secuencia de estados a través de los cuales los puertos deben pasar, y unas condiciones de cambios de topologías específicas para prevenir los bucles de capa 2. Estos parámetros o requerimientos están configurados con los valores por defecto para un tamaño de red específico. En la mayoría de los casos, los valores por defecto de STP son suficientes para mantener una red libre de bucles.

Existen otras situaciones en las que los temporizadores por defecto de STP pueden retrasar la convergencia de la red al tener que esperar a que estos expiren sus tiempos.

Por ejemplo, cuando un PC se conecta a un puerto del switch este no puede generar ningún bucle en la red. Otra situación tiene que ver con el tamaño de la red, en una red pequeña los valores de los temporizadores por defecto pueden retrasar su funcionamiento por lo que deberíamos configurar valores más bajos a los temporizadores.

Modifying STP Timers

STP utiliza 3 temporizadores los cuales podemos modificar tal y como mostraremos a continuación. Estos temporizadores sólo los cambiaremos en el root bridge, el cual propagará dicha modificación al resto de switches mediante las BPDU’s.

Manually Configuring STP Timers

Manually Cinfiguring STP Timers

Manually Cinfiguring STP Timers

Estos temporizadores pueden ser modificados para una sola instancia STP con el parámetro vlan-id o para todas omitiendo este parámetro.

El temporizador Hello es el que regula el envío de las BPDU’s desde el root bridge hacia el resto de switches. Este temporizador también configura el intervalo de tiempo en el que el switch espera escuchar el Hello de sus vecinos. Las BPDU’s de configuración por defecto se envían cada 2 segundos, este parámetro puede ser modificado por valores comprendidos entre 1 y 10 segundos.

El temporizador Forward Delay determina la cantidad de tiempo en el que el puerto está en estado escunchando/aprendiendo antes de pasar al estado enviando. por defecto este temporizador tiene un valor de 15 segundos y podemos modificarlo por valores comprendidos entre 4 y 30 segundos. Este parámetro debemos configurarlo con especial atención ya que de el depende la propagación de las BPDU’s. Si configuramos valores inapropiados, podemos provocar bucles en la red.

El temporizador Max Age especifica el tiempo de vida de una BPDU almacenada la cual ha sido recibida en un puerto designado. Estas BPDU’s también son recibidas por los puertos no designados para los tiempos especificados. Si se produce un fallo en el envío de las BPDU’s el cual es ajeno a la red, como por ejemplo el filtrado por ACL o Firewall, el switch que está recibiendo, espera a que el temporizador Max Age termine para escuchar otras BPDU’s. A partir de este mecanismo el puerto no designado pasa al estado aprendido, el puerto pasa a ser designado y se reestablece la conectividad en el segmento. Para modificar el valor por defecto de este temporizador de 20 segundos se utiliza el parámetro Max Age el cual está comprendido por valores entre 6 y 40 segundos.

Automatically Configuring STP Timers

La configuración de los temporizadores de STP puede realizarse también de forma automática. Los switches Catalyst utilizan el siguiente comando para realizar la configuración automática de dichos temporizadores:

switch(config)#spanning-tree vlan vlan-list root {primary | secondary} [diameter diameter [hello-time hello-time]]

Los temporizadores de STP serán ajustados acorde a la especificación IEEE 802.1D con sólo indicar el diámetro de la red tomado como el número máximo de switches que el tráfico debe atravesar en la red de capa 2, este puede ser un valor comprendido entre 1 y 7 saltos. El parámetro Hello Time es opcional, el cual tiene un valor por defecto de 2 segundos.

Todos estos cambios los realizaremos en el root bridge, el cual propagará dichos cambios al resto de switches mediante las BPDU’s.

En el siguiente ejemplo tenemos una pequeña red compuesta de 3 switches conectados de forma triangular. En la siguiente imagen se muestran los temporizadores de STP usados por la VLAN 100 teniendo en cuenta que dichos temporizadores están configurados por defecto.

STP Timer Values

STP Timer Values

A continuación vamos a modificar el temporizador Hello Time a 1 segundo y el diámetro a 3 ya que por defecto este lo tenemos a 7 saltos.

switch(config)#spanning-tree vlan 100 root primary diameter 3 hello-time 1

El resultado de realizar este cambio es el siguiente:

STP Timer Configuration Changes

STP Timer Configuration Changes

Saludos a tod@s,

JMHAlegre

Publicado en CCNP SWITCH 642-813 Official Certification Guide (Part II – Chapter 2 Switch Operation), CCNP SWITCH 642-813 Official Certification Guide (Part II – Chapter 8 Spanning-Tree Configuration), CCNP SWITCH 642-813 Official Certification Guide (Part II – Chapter 8.3 Tuning Spanning-Tree Convergence), Cisco, SWITCH 642-813 | Etiquetado , , , , , | Deja un comentario

CCNP SWITCH 642-813 Official Certification Guide (Part II – Chapter 8.2 Spanning-Tree Customization)

2. Spanning-Tree Customization

La decisión más importante en el diseño de STP es la ubicación del root bridge, otras decisiones, como por ejemplo un camino libre de bucles, ocurrirán una vez implementemos STP. Existen motivos especiales donde necesitemos realizar una mejora u optimización adicional.

Como ya se indicó en puntos anteriores, los criterios de elección se llevan a cabo según:

    • El mejor bridge ID
    • El menor root path cost
    • El menor sender bridge ID
    • El menor sender port ID

Mejorando la configuración del root path cost

El root path cost para cada puerto de un switch es determinado por los costes acumulativos a medida que las BPDU van viajando. Cuando un switch recibe una BPDU el coste del puerto que recibe se suma a root path cost de esa BPDU. El valor por defecto es inversamente proporcional al ancho de banda del puerto, este valor es configurable.

Antes de modificar el root path cost de los switches deberiamos calcular el root path cost de todos los enlaces alternativos. Estos cambios deben hacerse con mucha precaución.

El siguiente comando sirve para modificar el coste de un puerto:

switch(config-if)#spanning-tree vlan vlan-id cost cost

Si el parámetro vlan es utilizado, entonces el coste del puerto es modificado únicamente para esa VLAN en particular, de lo contrario el coste se modifica para todas las VLAN’s de ese puerto. El coste tiene un rango de 1 hasta 65535. Tenemos unos valores standard que se corresponden con el ancho de banda del puerto.

STP Port Cost

STP Port Cost

En el siguiente ejemplo se cambia el coste de la VLAN 10 a un valor de 2 en un puerto de 1 Gbps (coste por defecto 4):

switch(config-if)#spanning-tree vlan 10 cost 2

Una vez realizado esto, podemos comprobar el coste del puerto para la VLAN 10 mediante el comando:

switch#show spanning-tree interface type mod/num [cost]

STP Port Cost values on an Interface

STP Port Cost values on an Interface

Mejorando la configuración del port ID

El último criterio en la decisión de STP es el port ID. Este es el identificador del puerto que utiliza el switch y que tiene un valor de 16 bits de los cuales 8 bits se corresponden con la prioridad y los 8 restantes con el número del puerto. La prioridad del puerto es un valor comprendido entre 0 y 255 y por defecto tiene un valor de 128. El número de puerto tiene un rango comprendido entre 0 y 255 y representa la ubicación física del puerto real. Los números de puerto empiezan con 1 en los puertos 0/1 y se van incrementando a través de cada módulo. En función de los módulos que tengamos los números de puerto no tienen por qué ser consecutivos.

El port ID puede modificar la decisión de STP a través de la prioridad, el siguiente comando modifica ese parámetro:

switch(config-if)#spanning-tree vlan vlan-id port-priority port-priority

Se puede modificar la prioridad del puerto para una o más VLAN’s utilizando el parámetro vlan a través de un rango de valores separados por comas, de lo contrario la prioridad del puerto se aplicará a todas las VLAN’s de dicho puerto. Un valor de prioridad menor indica una mayor preferencia o mejor camino hacia el root bridge.

El siguiente ejemplo cambia la prioridad del puerto 3/16 de 128 a 64 para las VLAN’s 10 y 100:

STP Port Priority Values after Configuration

STP Port Priority Values after Configuration

Saludos a tod@s,

JMHAlegre

Publicado en CCNP SWITCH 642-813 Official Certification Guide (Part II – Chapter 8 Spanning-Tree Configuration), CCNP SWITCH 642-813 Official Certification Guide (Part II – Chapter 8.2 Spanning-Tree Customization), Cisco, SWITCH 642-813 | Etiquetado , , , , , | Deja un comentario

CCNP SWITCH 642-813 Official Certification Guide (Part II – Chapter 8.1 STP Root Bridge)

1. STP Root Bridge

Los cálculos de STP son predecibles, pero existen otros factores que pueden influir en las decisiones de STP haciendo que el resultado no sea el deseado. Uno de los principales ajustes que se pueden realizar en STP, es seleccionar la ubicación del root bridge dentro de la red.

También se pueden configurar enlaces redundantes para realizar balanceo de carga, de esta forma STP converge mas rápido y de manera previsible ante una situación inesperada o un cambio de topología.

Por defecto STP está habilitado para todas las VLAN’s y en todos los puertos del switch. Si alguna instancia de STP ha sido deshabilitada, esta puede volver a habilitarse mediante el comando:

switch(config)#spanning-tree vlan vlan-id

Ubicación del Root Bridge (Switch raíz)

Aunque STP puede funcionar sin la necesidad de tener que elegir la situación del root bridge, éste es uno de los puntos que debemos tener en cuenta antes de empezar a configurar STP.

El root bridge es elegido como punto de referencia común dentro de la red y todos los demas switches tienen conectados sus puertos con el mejor coste hacia él. La elección también está basada en que el root bridge puede convertirse en el punto central de la red que interconecta otros segmentos de la red, en definitiva, el root bridge puede estar soportando mucha carga de conmutación. Si dejamos que STP elija el root bridge puede ocurrir que dicha elección no sea la apropiada.

La elección del root bridge está basada en el switch que tenga el menor bridge ID, el cual está compuesto por la prioridad y la dirección MAC, debemos tener en cuenta que por defecto la prioridad es la misma en todos los switches.

Si dejamos todos los switches configurados con los valores por defecto sólo será elegido un root bridge, lo cual implica que no tendremos un root bridge de respaldo en caso de fallo, por lo tanto la redundancia es un factor que deberemos tener en cuenta.

La siguiente imagen muestra una porción de una red típica de un campus de modelo jerárquico.

Root Bridge Elecction

Root Bridge Elecction

El switch A y el switch B son equipos de acceso, mientras que el switch C y el switch D forman el core y el switch E conecta una granja de servidores al core de la red.

La mayoría de los switches tienen enlaces redundantes hacia otras capas de la jerarquía, el switch B sólo tiene una conexión hacia el core. A este switch se le debería añadir un nuevo enlace hacia el core con el fin de tener redundancia. En este caso el switch A se convertirá en el root bridge debido a que tiene la MAC más baja y la prioridad de todos los switches es la misma (32768).

En la siguiente imagen se muestra el estado de convergencia de STP.

STP Converged

STP Converged

A continuación se muestra la topología dejando sólo los enlaces funcionales.

Final Spanning-Tree Structure

Final Spanning-Tree Structure

El root bridge elegido es un equipo de la capa de acceso, las estaciones de trabajo del switch A pueden alcanzar los servidores situados en el switch E cruzando la capa de core, sin embargo las estaciones de trabajo conectadas al switch B tienen que cruzar la capa de core, volver a la capa de acceso para volver a cruzar nuevamente la capa de core para alcanzar el switch E.

Configuración del root Bridge

Para prevenir lo sucedido en el ejemplo anterior es necesario llevar a cabo 2 acciones:

  1. Configurar un switch adecuado como root bridge.
  2. Configurar otro switch como root de respaldo en caso de que el principal falle.

Como punto de referencia común ambos dispositivos deberían estar ubicados cerca del centro de la red (Distribución). En caso de ser una red plana la mejor opción sería un switch ubicado cerca de la granja de servidores.

Para configurar un switch como root bridge podemos utilizar los siguientes métodos:

  • Manualmente configurando la prioridad, de tal forma que tenga un valor menor que el resto de switches. Obviamente debemos conocer el valor de prioridad de todos los switches. El comando que utilizaremos para realizar esta acción es:

switch(config)#spanning-tree vlan vlan-list priority bridge-priority

El valor por defecto de bridge-priority es de 32768, pero el rango de configuración va desde 0 a 65535. En el caso de que tengamos habilitado el System ID extendido de STP, la prioridad por defecto será 32768 más el número de VLAN. En este caso el rango estará comprendido entre 0 y 61440 pero sólo se podrán utilizar múltiplos de 4096. Los switches Catalyst sólo ejecutan una instancia STP por cada VLAN (PVST+), siempre deberiamos configurar un root bridge apropiado para cada VLAN. El siguiente comando configura la prioridad para las VLAN’s 5, 100-200 a 4096:

switch(config)#spanning-tree vlan 5,100-200 priority 4096

  • Es posible que el propio switch tome la prioridad para ser el root bridge basándose en ciertas condiciones. Para llevar a cabo esta función utilizaremos el comando siguiente:

switch(config)#spanning-tree vlan vlan-id root {primary | secondary} [diameter diameter]

Mediante este comando, el switch busca en la red quién es el root bridge y una vez encontrado éste se autoconfigura con una prioridad menor para poder convertirse en el root bridge. Si utilizamos el parámetro primary, la prioridad será de 24576, mientras que si utilizamos el parámetro secondary la prioridad será de 28672.

A continuación se muestra un ejemplo en el que un switch está utilizando la prioridad por defecto para la VLAN 100. En el modo extendido system ID la prioridad será de 32868, es decir, 32768 más 100 (VLAN  ID).

STP Bridge Priority

STP Bridge Priority

La prioridad por defecto es mayor que la que tiene actualmente el root bridge, de tal forma que este switch no puede convertirse en root bridge. Ahora se configura el switch con el método automático para intentar que esta situación cambie:

Configure a Root Bridge

Configure a Root Bridge

Como podemos comprobar, el método ha fallado, la prioridad actual del root bridge es de 4200 y debido a que esa prioridad es menor que 24576 el switch trata de poner su prioridad con un valor inferior a 4200. Aunque la prioridad resultante es de 104, la configuración de system ID extendido requiere que este valor sea múltiplo de 4096 con lo que sólo existe una posibilidad, poner la prioridad a 0. Esto significa que sólo podemos configurar esta prioridad de forma manual mediante el siguiente comando:

switch(config)#spanning-tree vlan 100 priority 0

Con esto conseguimos el siguiente resultado:

Bridge Priorities with Extended System ID

Bridge Priorities with Extended System ID

Saludos a tod@s,

JMHAlegre

Publicado en CCNP SWITCH 642-813 Official Certification Guide (Part II – Chapter 8 Spanning-Tree Configuration), CCNP SWITCH 642-813 Official Certification Guide (Part II – Chapter 8.1 STP Root Bridge), Cisco, SWITCH 642-813 | Etiquetado , , , , , , , | Deja un comentario