Revise Todos Los Temas Clave: Descripción

||||||||||||||||||||
Capítulo 6: Configuración de la administración básica del conmutador 147
Revise todos los temas clave

Tabla 6-4 Temas clave para el Capítulo 6
Elemento clave Descripción Número de
del tema página
Ejemplo 6-2 Ejemplo de configuración de seguridad de inicio de sesión con contraseña (sin nombres de usuario) 132
Figura 6-5 Comandos de configuración SSH con seguridad de inicio de sesión de nombre de usuario relacionada 137
Términos clave que debe saber

Telnet, Secure Shell (SSH), nombre de usuario local, AAA, servidor AAA, modo de habilitación, puerta de enlace predeterminada, interfaz VLAN, búfer
de historial, DNS, resolución de nombre, mensaje de registro
Hacer laboratorios
El software Sim Lite es una versión del producto de aprendizaje de simulador completo de Pearson con un subconjunto de los laboratorios, incluido
con este libro de forma gratuita. El subconjunto de laboratorios se relaciona principalmente con esta parte. Tómese el tiempo para probar algunos de
los laboratorios. Como siempre, también consulte las páginas del sitio del blog del autor para ver los ejercicios de configuración (Config Labs) en 66
https://blog.certskills.com.
Referencias de comando
Las tablas 6-5, 6-6, 6-7 y 6-8 enumeran los comandos de configuración y verificación utilizados en este capítulo. Como
ejercicio de revisión fácil, cubra la columna izquierda en una tabla, lea la columna derecha e intente recuperar el comando sin
mirar. Luego repita el ejercicio, cubriendo la columna derecha, e intente recordar lo que hace el comando.
Tabla 6-5 Comandos de seguridad de inicio de sesión
Mando Modo / Propósito / Descripción
consola de línea 0 Cambia el contexto al modo de configuración de la consola.
línea vty 1st-vty last-vty Cambia el contexto al modo de configuración vty para el rango de líneas vty
enumeradas en el comando.
iniciar sesión Consola y modo de configuración vty. Le dice a IOS que solicite una contraseña.
contraseña valor de paso Consola y modo de configuración vty. Enumera la contraseña requerida si el iniciar sesión comando
(sin otros parámetros) está configurado.
iniciar sesión local Consola y modo de configuración vty. Le dice a IOS que solicite un nombre de usuario y
contraseña, que se verificará con los configurados localmente nombre de usuario comandos
de configuración global en este conmutador o enrutador.
nombre de usuario nombre secreto Comando global. Define uno de posiblemente múltiples nombres de usuario y contraseñas asociadas,
valor de paso que se utiliza para la autenticación de usuarios. Usado cuando el iniciar sesión local Se ha utilizado el
comando de configuración de línea.
||||||||||||||||||||
148 CCNA 200-301 Guía oficial de certificados, volumen 1
clave criptográfica generar rsa Comando global. Crea y almacena (en una ubicación oculta en la memoria flash) las claves
[ módulo 360..2048] requeridas por SSH.
entrada de transporte {telnet | ssh | Modo de configuración de línea vty. Define si el acceso Telnet / SSH está permitido en este
todos | ninguna} conmutador. Ambos valores se pueden configurar en un comando para permitir el acceso a
Telnet y SSH (el valor predeterminado).
Tabla 6-6 Cambiar la configuración de IPv4
interfaz vlan número Cambia el contexto al modo de interfaz VLAN. Para la VLAN 1, permite la
configuración de la dirección IP del conmutador.
dirección IP máscara de subred de Modo de interfaz VLAN. Configura estáticamente la dirección IP y la máscara del
dirección IP conmutador.
dirección IP dhcp Modo de interfaz VLAN. Configura el conmutador como un cliente DHCP para descubrir su dirección
IPv4, máscara y puerta de enlace predeterminada.
ip default-gateway Comando global. Configura la dirección IPv4 de la puerta de enlace predeterminada del conmutador. No
habla a es necesario si el conmutador usa DHCP.
servidor de nombres ip server-ip-1 Comando global. Configura las direcciones IPv4 de los servidores DNS, por lo que cualquier comando
server-ip-2 ... cuando inicie sesión en el conmutador utilizará el DNS para la resolución de nombres.
Tabla 6-7 Otra configuración del interruptor
nombre de host nombre Comando global. Establece el nombre de host de este conmutador, que también se usa como la primera
parte del símbolo del sistema del conmutador.
habilitar secreto valor de paso Comando global. Establece la contraseña de este interruptor que se requiere para
cualquier usuario para alcanzar el modo de habilitación.
tamaño de la historia longitud Modo de configuración de línea. Define el número de comandos contenidos en el búfer de historial, para
recuperarlos posteriormente, para los usuarios de esas líneas.
registro sincrónico Consola o modo vty. Le dice a IOS que envíe mensajes de registro al usuario en puntos de
interrupción naturales entre comandos en lugar de en el medio de una línea de salida.
[no] consola de registro Comando global que deshabilita o habilita la visualización de mensajes de registro en
la consola.
exec-timeout minutos Consola o modo vty. Establece el tiempo de espera de inactividad, de modo que después del período
[ segundos] definido de no acción, IOS cierra la sesión de inicio de sesión del usuario actual.
Technet24
||||||||||||||||||||
Capítulo 6: Configuración de la administración básica del conmutador 149
Tabla 6-8 Capítulo 6 Referencia de comandos EXEC
Mando Propósito
show running-config Enumera la configuración utilizada actualmente.
show running-config | comience la línea vty Canaliza (envía) la salida del comando a empezar comando, que solo enumera los
resultados que comienzan con la primera línea que contiene el texto "line vty".
muestre el arriendo de DHCP Lista cualquier información que el conmutador adquiera como cliente DHCP. Esto incluye la
dirección IP, la máscara de subred y la información de la puerta de enlace predeterminada.
muestre la clave criptográfica mypubkey rsa Enumera la clave pública y compartida creada para usar con SSH
utilizando el clave criptográfica generar rsa comando de configuración global.
muestre el ssh del ip Enumera la información de estado del servidor SSH, incluida la versión SSH.
muestra ssh Enumera la información de estado de las conexiones SSH actuales dentro y fuera del
conmutador local.
muestre las interfaces vlan número Enumera el estado de la interfaz, la dirección IPv4 y la máscara del conmutador, y 66
mucho más.
muestre el IP default-gateway Enumera la configuración del conmutador para su puerta de enlace predeterminada IPv4.
tamaño del historial del terminal X Cambia la longitud del búfer de historial solo para el usuario actual, solo para el
inicio de sesión actual en el conmutador.
mostrar historia Enumera los comandos en el búfer de historial actual.

||||||||||||||||||||
CAPÍTULO 7
Configuración y verificación de interfaces de

conmutador
Este capítulo cubre los siguientes temas de examen:
1.0 Fundamentos de la red
1.1 Explicar el papel y la función de los componentes de la red.
1.1.b Interruptores L2 y L3
1.4 Describir conceptos de conmutación
Hasta ahora en esta parte, ha aprendido las habilidades para navegar por la interfaz de línea de comandos (CLI) y usar comandos que
configuran y verifican las características del interruptor. Aprendió sobre el propósito principal de un conmutador: reenviar tramas de Ethernet
y aprendió cómo ver ese proceso en acción mirando la tabla de direcciones MAC del conmutador. Después de aprender sobre el plano de
datos del conmutador en el Capítulo 5, "Análisis de la Conmutación LAN Ethernet", aprendió algunas características del plano de
administración en el Capítulo 6, "Configuración de la administración básica del conmutador", como cómo configurar el conmutador para
admitir Telnet y Secure Shell (SSH ) configurando la dirección IP y la seguridad de inicio de sesión.
Este capítulo se centra en las interfaces de conmutador en dos secciones principales. La primera sección muestra cómo puede configurar y
cambiar el funcionamiento de las interfaces del conmutador: cómo cambiar la velocidad, el dúplex o incluso deshabilitar la interfaz. La segunda
mitad se centra en cómo usar los comandos show en un conmutador para verificar el estado de la interfaz del conmutador y cómo interpretar la
salida para encontrar algunos de los problemas más comunes con las interfaces del conmutador.
"¿Ya sé esto?" Examen

Responda el cuestionario (ya sea aquí o use el software PTP) si desea usar el puntaje para ayudarlo a decidir cuánto tiempo pasará
en este capítulo. Las respuestas a las letras se enumeran en la parte inferior de la página después del cuestionario. El Apéndice C,
que se encuentra tanto al final del libro como en el sitio web complementario, incluye tanto las respuestas como las explicaciones.
También puede encontrar respuestas y explicaciones en el software de prueba PTP.
Cuadro 7-1. "¿Ya sé esto?" Asignación de temas básicos de la sección a la pregunta

Sección de temas básicos Preguntas
Configuración de interfaces de conmutador 1–3
Análisis del estado y las estadísticas de la interfaz del conmutador 4–6
Technet24
||||||||||||||||||||
1) ¿Cuál de los siguientes describe una forma de deshabilitar la negociación automática estándar IEEE en un
¿Puerto 10/100 en un conmutador Cisco?
a. Configurar el negociar deshabilitar subcomando de interfaz
si. Configurar el no negociar subcomando de interfaz
C. Configurar el velocidad 100 subcomando de interfaz
re. Configurar el mitad dúplex subcomando de interfaz
mi. Configurar el dúplex completo subcomando de interfaz
F. Configurar el velocidad 100 y dúplex completo subcomandos de interfaz
2) ¿En cuál de los siguientes modos de la CLI podría configurar la configuración dúplex para la interfaz Fast
Ethernet 0/5?
a. Modo de usuario
si. Habilitar modo
C. Modo de configuración global
re. Modo VLAN
mi. Modo de configuración de la interfaz
3) Un switch Cisco Catalyst se conecta con su puerto Gigabit0 / 1 a la PC de un usuario final. El fin
El usuario, pensando que el usuario está ayudando, configura manualmente el sistema operativo de la PC para usar una velocidad de 1000
Mbps y usar dúplex completo, y deshabilita el uso de la negociación automática. El puerto G0 / 1 del conmutador tiene configuraciones
predeterminadas para velocidad y dúplex. ¿Qué ajustes de velocidad y dúplex decidirá usar el interruptor? (Elija dos respuestas)
a. Duplex completo
si. Medio duplex
C. 10 Mbps
re. 1000 Mbps
4) La salida de la muestra el estado de las interfaces comando en un interruptor 2960 muestra inter-
enfrentan Fa0 / 1 en un estado "deshabilitado". ¿Cuál de las siguientes afirmaciones es verdadera sobre la interfaz Fa0 / 1? (Elija tres
respuestas)
a. La interfaz está configurada con el apagar mando.
si. los muestre las interfaces fa0 / 1 El comando mostrará la interfaz con dos códigos de estado
de administración administrativa y protocolo de línea inactivo.
C. los muestre las interfaces fa0 / 1 El comando mostrará la interfaz con dos códigos de estado
de arriba y abajo.
re. La interfaz no se puede utilizar actualmente para reenviar cuadros.
mi. La interfaz se puede utilizar actualmente para reenviar cuadros.

||||||||||||||||||||
5) El conmutador SW1 utiliza su interfaz Gigabit 0/1 para conectarse al conmutador Gigabit 0/2 de SW2.
cara. La interfaz Gi0 / 2 de SW2 se configura con el velocidad 1000 y dúplex completo comandos SW1 utiliza todos los valores
predeterminados para los comandos de configuración de la interfaz en su interfaz Gi0 / 1. ¿Cuál de los siguientes es cierto sobre el
enlace después de que aparece? (Elija dos respuestas)
a. El enlace funciona a 1000 Mbps (1 Gbps).
si. SW1 intenta ejecutarse a 10 Mbps porque SW2 ha deshabilitado efectivamente el estándar IEEE
Dard autonegociación.
C. El enlace se ejecuta a 1 Gbps, pero SW1 usa half duplex y SW2 usa full duplex.
re. Ambos interruptores usan full duplex.
6) El interruptor SW1 se conecta a través de un cable para cambiar el puerto G0 / 1 de SW2. Cuál de los siguientes
Qué condiciones es más probable que causen que el contador de colisión tardía de SW1 continúe incrementándose?
a. El G0 / 1 de SW2 se ha configurado con un apagar subcomando de interfaz.
si. Los dos interruptores se han configurado con valores diferentes en el velocidad enterrar-
subcomando cara.
C. Existe una falta de coincidencia dúplex con SW1 configurado en dúplex completo.
re. Existe una falta de coincidencia dúplex con SW1 configurado en half duplex.
Temas de la fundación
Configuración de interfaces de conmutador

IOS usa el término interfaz para referirse a puertos físicos se utiliza para reenviar datos hacia y desde otros dispositivos. Cada interfaz
se puede configurar con varias configuraciones, cada una de las cuales puede diferir de una interfaz a otra. IOS utiliza subcomandos
de interfaz para configurar estos ajustes. Cada una de estas configuraciones puede ser diferente de una interfaz a la siguiente, por lo
que primero identificaría la interfaz específica y luego configuraría la configuración específica.
Esta sección comienza con una discusión de tres configuraciones relativamente básicas por interfaz: la velocidad del puerto, el
dúplex y una descripción de texto. Después de eso, el texto analiza brevemente un par de los subcomandos de interfaz más
comunes: el apagar y no apagarse comandos, que deshabilitan y habilitan administrativamente la interfaz, respectivamente. Esta
sección termina con una discusión sobre los conceptos de negociación automática, que a su vez dicta qué configuración elige usar
un interruptor al usar la negociación automática.
Configuración de velocidad, dúplex y descripción

Las interfaces de conmutación que admiten velocidades múltiples (interfaces 10/100 y 10/100/1000), de forma predeterminada, negociarán
automáticamente qué velocidad usar. Sin embargo, puede configurar los ajustes de velocidad y dúplex con el dúplex {auto | completo |
medio} y velocidad {auto | 10 | 100 1000} subcomandos de interfaz. Suficientemente simple.
La mayoría de las veces, usar la autonegociación tiene sentido, por lo que cuando configura el dúplex y la velocidad manualmente con
estos comandos, generalmente tiene una buena razón para hacerlo. Por ejemplo, tal vez desee establecer la velocidad lo más rápida
posible en los enlaces entre interruptores solo para evitar la posibilidad de que la negociación automática elija una velocidad más lenta.
Technet24
||||||||||||||||||||
Capítulo 7: Configuración y verificación de interfaces de conmutador 153
los descripción El subcomando de interfaz de texto le permite agregar una descripción de texto a la interfaz. Por ejemplo, si tiene
una buena razón para configurar la velocidad y el dúplex en un puerto, tal vez agregue una descripción que diga por qué lo hizo.
El ejemplo 7-1 muestra cómo configurar dúplex y
velocidad, así como el descripción comando, que es simplemente una descripción de texto que puede configurar el
administrador.
Ejemplo 7-1 Configurando velocidad, dúplex, y descripción en Switch Emma
Emma # configurar terminal
Ingrese los comandos de configuración, uno por línea. Termina con CNTL / Z. Emma (config) # interfaz
FastEthernet 0/1
Emma (config-if) # dúplex completo
Emma (config-if) # velocidad 100
Emma (config-if) # Descripción Impresora en el 3er piso, preajustada a 100 / completa
Emma (config-if) # salida
Emma (config) # rango de interfaz FastEthernet 0/11 - 20
Emma (config-if-range) # descripción usuarios finales se conectan aquí
Emma (config-if-range) # ^ Z
Emma #
Primero, concéntrese en la mecánica de moverse nuevamente en el modo de configuración observando detenidamente las
instrucciones de comando. Los diversos interfaz Los comandos mueven al usuario del modo global al modo de configuración de
interfaz para una interfaz específica. Por ejemplo, el ejemplo configura el dúplex, velocidad, y descripción todos los comandos justo 77
después de la interfaz FastEthernet 0/1 comando, lo que significa que las tres configuraciones se aplican a la interfaz Fa0 / 1 y no a
las otras interfaces. los muestra el estado de las interfaces El comando enumera gran parte de los detalles configurados en el
Ejemplo 7-1, incluso con solo una línea de salida por interfaz. El ejemplo 7-2 muestra un ejemplo, justo después de que la
configuración del ejemplo 7-1 se haya agregado al conmutador.
Ejemplo 7-2 Visualización del estado de la interfaz
Emma # muestra el estado de las interfaces
Puerto Nombre Estado Vlan Tipo de velocidad dúplex
Fa0 / 1 La impresora en el 3 ° piso no está conectada 1 completo 100 10 / 100BaseTX
Fa0 / 2 notconnect 1 auto auto 10 / 100BaseTX
Fa0 / 4 conectado 1 a-full a-100 10 / 100BaseTX
Fa0 / 11 los usuarios finales se conectan notconnect 1 auto auto 10 / 100BaseTX

||||||||||||||||||||
Gi0 / 1 notconnect 1 auto auto 10/100 / 1000BaseTX
Gi0 / 2 notconnect 1 auto auto 10/100 / 1000BaseTX
Trabajando a través de la salida en el ejemplo:
FastEthernet 0/1 (Fa0 / 1): Esta salida enumera los primeros caracteres de la descripción configurada. También
enumera la velocidad configurada de 100 y dúplex completo por velocidad y
dúplex comandos en el ejemplo 7-1. Sin embargo, también indica que Fa0 / 1 tiene un estado de no conectado, lo que
significa que la interfaz no está funcionando actualmente. (Ese puerto del conmutador no tenía un cable conectado al
recopilar este ejemplo, a propósito).
FastEthernet 0/2 (Fa0 / 2): El ejemplo 7-1 no configuró este puerto en absoluto. Este puerto tenía toda la configuración predeterminada. Tenga
en cuenta que el texto "automático" debajo del encabezado de velocidad y dúplex significa que este puerto intentará negociar automáticamente
ambas configuraciones cuando aparezca el puerto. Sin embargo, este puerto tampoco tiene un cable conectado (nuevamente a propósito, para
comparar).
FastEthernet 0/4 (Fa0 / 4): Al igual que Fa0 / 2, este puerto tiene toda la configuración predeterminada, pero se cableó a otro dispositivo que
funciona para dar otro ejemplo de contraste. Este dispositivo completó el proceso de negociación automática, por lo que en lugar de
"automático" en los encabezados de velocidad y dúplex, la salida enumera la velocidad negociada y el dúplex ( una completa y a-100). Tenga en
cuenta que el texto incluye el una- para significar que los valores de velocidad y dúplex enumerados se negociaron automáticamente.
Configuración de múltiples interfaces con el comando de rango de interfaz

La parte inferior de la configuración en el Ejemplo 7-1 muestra una forma de acortar el trabajo de configuración al realizar la
misma configuración en varias interfaces consecutivas. Para hacerlo, use el
rango de interfaz mando. En el ejemplo, el rango de interfaz FastEthernet 0/11 - 20 El comando le dice a IOS que los siguientes
subcomandos se aplican a las interfaces Fa0 / 11 a Fa0 / 20. Puede definir un rango siempre que todas las interfaces sean del
mismo tipo y estén numeradas consecutivamente.
NOTA Este libro detalla todos los parámetros completamente para evitar confusiones. Sin embargo, casi todos abrevian lo
que escriben en la CLI con la abreviatura única más corta. Por ejemplo, los comandos de configuración int f0 / 1 y int
corrió f0 / 11-20 También sería aceptable.
IOS no pone realmente el rango de interfaz comando en la configuración. En cambio, actúa como si hubiera
escrito el subcomando en cada interfaz en la especificada
Respuestas a la pregunta "¿Ya sé esto?" examen:
1 F 2 mi 3 A, D 4 4 A, B, D 5 5 A, D 6 6 re
Technet24
||||||||||||||||||||
rango. El ejemplo 7-3 muestra un extracto del show running-config comando, que enumera la configuración de las
interfaces F0 / 11–12 de la configuración del ejemplo 7-1. El ejemplo muestra el mismo comando de descripción en
ambas interfaces; para ahorrar espacio, el ejemplo no se molesta en mostrar las 10 interfaces que tienen el mismo texto
descriptivo.
Ejemplo 7-3 Cómo IOS expande los subcomandos escritos después rango de interfaz
Emma # show running-config
! Líneas omitidas para la brevedad de la interfaz
FastEthernet0 / 11 descripción ¡los usuarios finales se
conectan aquí!
interfaz FastEthernet0 / 12 descripción ¡los usuarios finales
se conectan aquí! Líneas omitidas por brevedad
Controlar administrativamente el estado de la interfaz con apagado

Como puede imaginar, los ingenieros de red necesitan una forma de derribar una interfaz sin tener que desplazarse
hasta el conmutador y quitar un cable. En resumen, debemos poder decidir qué puertos deben habilitarse y cuáles
deben deshabilitarse.
En un extraño giro de la frase, Cisco usa dos subcomandos de interfaz para configurar la idea de habilitar y deshabilitar
77
administrativamente una interfaz: apagar comando (para deshabilitar) y el no apagarse comando (para habilitar). Mientras que la no
apagarse El comando puede parecer un comando extraño para habilitar una interfaz al principio, usará mucho este comando en el
laboratorio y se convertirá en una segunda naturaleza. (La mayoría de las personas, de hecho, usan las abreviaturas cerrar y no
cerrado)
El ejemplo 7-4 muestra un ejemplo de deshabilitación de una interfaz usando el apagar subcomando de interfaz. En este caso, el
interruptor SW1 tiene una interfaz de trabajo F0 / 1. El usuario se conecta a la consola y desactiva la interfaz. IOS genera un mensaje
de registro cada vez que una interfaz falla o se recupera, y los mensajes de registro aparecen en la consola, como se muestra en el
ejemplo.
Ejemplo 7-4 Deshabilitar administrativamente una interfaz con apagar
SW1 # configurar terminal
Ingrese los comandos de configuración, uno por línea. Termina con CNTL / Z. SW1 (config) # interfaz
fastEthernet 0/1
SW1 (config-if) # apagar
SW1 (config-if) #
* *2 de marzo 03: 02: 19.701:% LINK-5-CHANGED: interfaz FastEthernet0 / 1, cambio de estado a administrativamente inactivo
* *2 de marzo 03: 02: 20.708:% LINEPROTO-5-UPDOWN: protocolo de línea en la interfaz FastEthernet0 / 1, cambio de estado a inactivo
Para volver a activar la interfaz, todo lo que tiene que hacer es seguir el mismo proceso pero usar el no apagarse comando en
su lugar. Antes de dejar lo simple pero curiosamente nombrado apagado / no apagado comandos, eche un vistazo a dos
comandos show importantes que enumeran el estado de una interfaz de apagado. los show
||||||||||||||||||||
estado de las interfaces El comando enumera una línea de salida por interfaz y, cuando se apaga, enumera el estado de la interfaz
como "deshabilitado". Eso tiene sentido lógico para la mayoría de las personas. los mostrar interfaces comando (sin el estado palabra
clave) enumera muchas líneas de salida por interfaz, dando una imagen mucho más detallada del estado y las estadísticas de la
interfaz. Con ese comando, el estado de la interfaz viene en dos partes, con una parte que usa la frase "administrativamente inactivo",
que coincide con el mensaje de registro resaltado en el Ejemplo 7-4.
El ejemplo 7-5 muestra un ejemplo de cada uno de estos comandos. Tenga en cuenta que ambos ejemplos también usan el parámetro F0 /
1 (abreviatura de Fast Ethernet0 / 1), que limita la salida a los mensajes sobre F0 / 1 solamente. También tenga en cuenta que F0 / 1 todavía
se apaga en este punto.
Ejemplo 7-5 La información de estado diferente sobre el apagado en dos diferentes show
Comandos
SW1 # muestre el estado de las interfaces f0 / 1
Fa0 / 1 discapacitado 1 auto auto 10 / 100BaseTX
SW1 # muestre las interfaces f0 / 1
FastEthernet0 / 1 está administrativamente inactivo, el protocolo de línea está inactivo (deshabilitado)
El hardware es Fast Ethernet, la dirección es 1833.9d7b.0e81 (bia 1833.9d7b.0e81) MTU 1500 bytes, BW 10000 Kbit / seg,
DLY 1000 usec,
confiabilidad 255/255, txload 1/255, rxload 1/255 Encapsulación ARPA, loopback
no establecido Keepalive set (10 seg)
Dúplex automático, velocidad automática, el tipo de medio es 10/100 El control de flujo de entrada BaseTX está
desactivado, el control de flujo de salida no es compatible Tipo de ARP: ARPA, ARP Tiempo de espera 04:00:00
Última entrada nunca, salida 00:00:36, salida bloqueada nunca Última limpieza de los
contadores "show interface" nunca
Cola de entrada: 0/75/0/0 (tamaño / máx. / Gotas / descargas); Caídas de salida totales: 0 Estrategia de cola: quince
cola de salida: 0/40 (tamaño / máx.)
Velocidad de entrada de 5 minutos 0 bits / seg, 0 paquetes / seg Velocidad de
salida de 5 minutos 0 bits / seg, 0 paquetes / seg
164 paquetes de entrada, 13267 bytes, 0 sin búfer Recibió 164
transmisiones (163 multidifusión) 0 runas, 0 gigantes, 0 aceleradores
0 errores de entrada, 0 CRC, 0 frame, 0 overrun, 0 ignorado 0 watchdog, 163 multicast, 0
pausa de entrada 0 paquetes de entrada con condición de dribble detectados 66700
paquetes de salida, 5012302 bytes, 0 underruns 0 errores de salida, 0 colisiones, 1
reinicio de interfaz 0 gotas de protocolo desconocido
0 balbuceos, 0 colisión tardía, 0 diferido 0 portador perdido, 0 sin portador, 0 pausa de salida
0 fallas del búfer de salida, 0 búferes de salida intercambiados
Technet24
||||||||||||||||||||
Eliminar la configuración con el comando no

Un propósito para los comandos específicos que se muestran en la Parte II del libro es enseñarle acerca de ese
comando. En algunos casos, los comandos no son el objetivo final y el texto intenta enseñarle algo sobre cómo
funciona la CLI. El siguiente tema breve trata más sobre el proceso que sobre los comandos.
Con algunos comandos de configuración de IOS (pero no todos), puede volver a la configuración predeterminada emitiendo
un No versión del comando. Qué significa eso? Déjame darte algunos ejemplos:
■ Si anteriormente había configurado velocidad 100 en una interfaz, el sin velocidad el comando en esa misma interfaz vuelve a la
configuración de velocidad predeterminada (que resulta ser velocidad automática).
■ La misma idea con el dúplex comando: una configuración anterior de mitad dúplex o dúplex completo, seguido por no
duplex en la misma interfaz, revierte la configuración al valor predeterminado de dúplex automático.
■ Si hubiera configurado un descripción comando con algo de texto, para volver al estado predeterminado de no
tener descripción comando para esa interfaz, use el Sin descripción
mando.
El ejemplo 7-6 muestra el proceso. En este caso, el puerto F0 / 2 del conmutador SW1 se ha configurado con velocidad
100, mitad dúplex enlace descriptivo a 2901-2, y apagar. Puede ver evidencia de las cuatro configuraciones en el
comando que comienza el ejemplo. (Este comando enumera la configuración en ejecución, pero solo la parte de esa
interfaz). El ejemplo muestra el 77
No versiones de esos comandos y se cierra con una confirmación de que todos los comandos han vuelto a los valores predeterminados.
Ejemplo 7-6 Eliminar varios ajustes de configuración utilizando el No Mando
SW1 # muestre la interfaz running-config f0 / 2
Configuración de construcción...
Configuración actual: 95 bytes!
interfaz FastEthernet0 / 2 descripción enlace a
2901-2 velocidad de apagado 100 dúplex
medio extremo
Ingrese los comandos de configuración, uno por línea. Termina con CNTL / Z. SW1 (config) # interfaz
fastethernet 0/2
SW1 (config-if) # sin velocidad
SW1 (config-if) # no duplex
SW1 (config-if) # Sin descripción
SW1 (config-if) # no apagarse

||||||||||||||||||||
SW1 (config-if) # ^ Z
SW1 # SW1 # muestre la interfaz running-config f0 / 2
Configuración del edificio ... Configuración actual: 33
bytes!
interfaz FastEthernet0 / 2 final SW1 #
NOTA los show running-config y muestre la configuración de inicio los comandos generalmente no muestran los ajustes de configuración
predeterminados, por lo que la ausencia de comandos enumerados en la interfaz F0 / 2 al final del ejemplo significa que esos comandos
ahora usan valores predeterminados.
Autonegociación
Para cualquier interfaz 10/100 o 10/100/1000, es decir, interfaces que pueden ejecutarse a diferentes velocidades, Cisco Catalyst cambia por
defecto a una configuración de dúplex automático y velocidad automática Como resultado, esas interfaces intentan determinar automáticamente
la velocidad y la configuración dúplex a utilizar. Alternativamente, puede configurar la mayoría de los dispositivos, incluidas las interfaces de
conmutación, para usar una velocidad específica y / o dúplex.
En la práctica, usar la negociación automática es fácil: simplemente deje la velocidad y el dúplex en la configuración predeterminada y
deje que el puerto del conmutador negocie qué configuraciones usar en cada puerto. Sin embargo, pueden surgir problemas debido a
combinaciones desafortunadas de configuración. Por lo tanto, el siguiente tema muestra más detalles sobre los conceptos detrás de la
negociación automática, para que sepa mejor cómo interpretar el significado del cambio show comandos y cuándo elegir usar una
configuración particular.
Autonegociación en condiciones de trabajo

Los dispositivos Ethernet en los extremos de un enlace deben usar el mismo estándar; de lo contrario, no pueden enviar datos
correctamente. Por ejemplo, una NIC no puede usar 100BASE-T, que usa un cable UTP de dos pares con una velocidad de 100
Mbps, mientras que el puerto del conmutador en el otro extremo del enlace usa 1000BASE-T. Incluso si usó un cable que funciona
con Gigabit Ethernet, el enlace no funcionaría con un extremo que intenta enviar a 100 Mbps mientras que el otro intenta recibir los
datos a 1000 Mbps.
Actualizar a estándares Ethernet nuevos y más rápidos se convierte en un problema porque ambos extremos tienen que usar el mismo
estándar. Por ejemplo, si reemplaza una PC vieja por una nueva, la anterior podría haber estado usando 100BASE-T mientras que la
nueva usa 1000BASE-T. El puerto del conmutador en el otro extremo del enlace ahora necesita usar 1000BASE-T, por lo que debe
actualizar el conmutador. Si ese conmutador tuviera puertos que usarían solo 1000BASE-T, necesitaría actualizar todas las otras PC
conectadas al conmutador. Por lo tanto, tener ambas tarjetas de interfaz de red (NIC) para PC y puertos de conmutación que admitan
múltiples estándares / velocidades hace que sea mucho más fácil migrar al siguiente estándar mejor.
Technet24
||||||||||||||||||||
El protocolo de negociación automática IEEE ayuda a que sea mucho más fácil operar una LAN cuando las NIC y los puertos de
conmutación admiten velocidades múltiples. La negociación automática IEEE (estándar IEEE 802.3u) define un protocolo que permite que
los dos nodos Ethernet basados en UTP en un enlace negocien para que cada uno elija usar la misma configuración de velocidad y dúplex.
Los mensajes de protocolo fluyen fuera de las frecuencias eléctricas normales de Ethernet como señales fuera de banda a través del cable
UTP. Básicamente, cada nodo establece lo que puede hacer, y luego cada nodo elige las mejores opciones que ambos nodos admiten: la
velocidad más rápida y la mejor configuración dúplex, con dúplex completo mejor que medio dúplex.
NOTA La negociación automática se basa en el hecho de que el IEEE utiliza los mismos pines de cableado para 10BASE-T y
100BASE-T, y que 1000BASE-T simplemente se agrega a esos pines, agregando dos pares.
Muchas redes utilizan la negociación automática todos los días, particularmente entre los dispositivos de los usuarios y los conmutadores LAN
de la capa de acceso, como se muestra en la Figura 7-1. La compañía instaló un cableado de cuatro pares de la calidad adecuada para admitir
1000BASE-T, para estar listo para admitir Gigabit Ethernet. Como resultado, el cableado admite opciones Ethernet de 10 Mbps, 100 Mbps y
1000 Mbps. Ambos nodos en cada enlace se envían mensajes de negociación automática entre sí. El conmutador en este caso tiene todos los
puertos 10/100/1000, mientras que las NIC de PC admiten diferentes opciones.
Negociación automática habilitada

77
10 10/100 10/100/1000
1 2 3
Resultado: Resultado: Resultado:
10 100 1000
Completo Completo Completo
10/100/1000 10/100/1000 10/100/1000
Autonegociación habilitada, puertos 10/100/1000
Figura 7-1. Resultados de la negociación automática de IEEE con ambos nodos funcionando correctamente
La siguiente lista desglosa la lógica, una PC a la vez:
PC1: El puerto del conmutador afirma que puede ir tan rápido como 1000 Mbps, pero la NIC de PC1 afirma una velocidad máxima de
10 Mbps. Tanto la PC como el conmutador eligen la velocidad más rápida que admite cada uno (10 Mbps) y el mejor dúplex que
admite cada uno (completo).
PC2: PC2 afirma una mejor velocidad de 100 Mbps, lo que significa que puede usar 10BASE-T o 100BASE-T. El puerto del
conmutador y la NIC negocian el uso de la mejor velocidad de 100 Mbps y dúplex completo.
PC3: Utiliza una NIC 10/100/1000, que admite las tres velocidades y estándares, por lo que tanto la NIC como el puerto del
conmutador eligen 1000 Mbps y dúplex completo.

||||||||||||||||||||
Resultados de la negociación automática cuando solo un nodo utiliza la negociación automática
La Figura 7-1 muestra los resultados de la negociación automática IEEE cuando ambos nodos utilizan el proceso. Sin embargo, la mayoría de los
dispositivos Ethernet pueden deshabilitar la negociación automática, por lo que es tan importante saber qué sucede cuando un nodo intenta usar la
negociación automática pero el nodo no obtiene respuesta. Deshabilitar la negociación automática no siempre es una mala idea. Por ejemplo,
muchos ingenieros de red deshabilitan la negociación automática en los enlaces entre conmutadores y simplemente configuran la velocidad y el
dúplex deseados en ambos conmutadores. Sin embargo, pueden ocurrir errores cuando un dispositivo en una Ethernet predefine la velocidad y el
dúplex (y deshabilita la negociación automática), mientras que el dispositivo en el otro extremo intenta la negociación automática. En ese caso, el
enlace podría no funcionar en absoluto, o podría funcionar mal.
NOTA La configuración de la velocidad y el dúplex en una interfaz de switch Cisco Catalyst deshabilita la negociación automática.
La negociación automática de IEEE define algunas reglas (valores predeterminados) que los nodos deben usar como valores predeterminados
cuando falla la negociación automática, es decir, cuando un nodo intenta usar la negociación automática pero no escucha nada del dispositivo. Las
normas:
■ Velocidad: Use su velocidad más lenta compatible (a menudo 10 Mbps).
■ Dúplex: Si su velocidad = 10 o 100, use half duplex; de lo contrario, use full duplex. Los conmutadores Cisco pueden hacer una mejor
elección que el valor predeterminado de velocidad IEEE base porque los conmutadores Cisco pueden detectar la velocidad utilizada por otros
nodos, incluso sin negociación automática IEEE. Como resultado, los switches Cisco utilizan esta lógica ligeramente diferente para elegir la
velocidad cuando falla la negociación automática:
■ Velocidad: Detecte la velocidad (sin usar la negociación automática), pero si eso falla, use el valor predeterminado IEEE (la velocidad más
lenta admitida, a menudo 10 Mbps).
■ Dúplex: Use los valores predeterminados de IEEE: Si la velocidad = 10 o 100, use half duplex; de lo contrario, use full duplex.
NOTA Las interfaces Ethernet que usan velocidades superiores a 1 Gbps siempre usan dúplex completo.
La Figura 7-2 muestra tres ejemplos en los que tres usuarios cambian su configuración de NIC y deshabilitan la negociación automática, mientras que
el conmutador (con todos los puertos 10/100/1000) intenta la negociación automática. Es decir, todos los puertos del switch están predeterminados en velocidad
automática y duplex auto. La parte superior de la figura muestra los ajustes configurados en cada NIC de PC, con las elecciones realizadas por el
conmutador enumerado al lado de cada puerto de conmutador.
Technet24
||||||||||||||||||||
Configuración manual, negociación automática deshabilitada

10/100 10/100/1000 10/100
1 2 3
Configuraciones: Configuraciones: Configuraciones:

100 Completo 1000 completo 10 la mitad
Resultado: Resultado: Resultado:
F0 / 1 100 Medio F0 / 2 1000 completo F0 / 3 10 la mitad
Autonegociación habilitada, puertos 10/100/1000
Figura 7-2. Resultados de la negociación automática de IEEE con la negociación automática deshabilitada en un lado
Revisando cada enlace, de izquierda a derecha:
■ PC1: El conmutador no recibe mensajes de negociación automática, por lo que detecta la señal eléctrica para saber que PC1 está
enviando datos a 100 Mbps. El conmutador utiliza el dúplex predeterminado IEEE basado en la velocidad de 100 Mbps (medio
dúplex).
■ PC2: El conmutador usa los mismos pasos y lógica que con el enlace a la PC1, excepto que el conmutador elige usar 77
dúplex completo porque la velocidad es de 1000 Mbps.
■ PC3: El usuario elige mal, eligiendo la velocidad más lenta (10 Mbps) y la peor configuración dúplex (la mitad). Sin embargo, el
conmutador Cisco detecta la velocidad sin usar la negociación automática IEEE y luego usa el valor predeterminado de dúplex IEEE para
enlaces de 10 Mbps (semidúplex). PC1 muestra un resultado final clásico y desafortunadamente común: un desajuste dúplex. Los dos
nodos (PC1 y el puerto G0 / 1 de SW1) usan 100 Mbps, por lo que pueden enviar datos. Sin embargo, la PC1, que utiliza dúplex
completo, no intenta utilizar el acceso múltiple con detección de portadora con lógica de detección de colisión (CSMA / CD) y envía
tramas en cualquier momento. El puerto del conmutador F0 / 1, con half duplex, usa CSMA / CD. Como resultado, el puerto del
conmutador F0 / 1 creerá que se producen colisiones en el enlace, incluso si no se producen físicamente. El puerto del interruptor dejará
de transmitir, retrocederá, reenviará tramas, etc. Como resultado, el enlace está activo, pero funciona mal. La próxima sección titulada
"Problemas de velocidad de interfaz y dúplex" revisará este problema con un enfoque en cómo reconocer los síntomas de una falta de
coincidencia dúplex.
Autonegociación y LAN Hubs

Los centros de LAN también afectan el funcionamiento de la negociación automática. Básicamente, los concentradores no reaccionan a los mensajes
de negociación automática y no reenvían los mensajes. Como resultado, los dispositivos conectados a un concentrador deben usar las reglas IEEE
para elegir la configuración predeterminada, que a menudo da como resultado que los dispositivos usen 10 Mbps y half duplex.
La Figura 7-3 muestra un ejemplo de una pequeña LAN Ethernet que utiliza un concentrador 10BASE-T de 20 años. En esta LAN, todos los
dispositivos y puertos de conmutador son puertos 10/100/1000. El concentrador solo admite 10BASE-T.
||||||||||||||||||||
Resultado:
1 Resultado: 3
1000 completo 10 Mitad
10 Mitad
Hub 1
2 SW1 44
1000 completo Resultado:
10 Mitad
Figura 7-3 IEEE Autonegociación con un LAN Hub
Tenga en cuenta que los dispositivos de la derecha necesitan usar half duplex porque el hub requiere el uso del algoritmo CSMA
/ CD para evitar colisiones.
NOTA Si desea obtener más información sobre los dominios de colisión y el impacto de estos hubs LAN más antiguos, busque
en el sitio web complementario el Apéndice K, "Análisis de diseños de LAN Ethernet", en la sección titulada "Dominios de
colisión Ethernet".
Análisis del estado y las estadísticas de la interfaz del conmutador

Ahora que ha visto algunas de las formas de configurar las interfaces del conmutador, el resto del capítulo analiza más de cerca
cómo verificar que las interfaces funcionen correctamente. Esta sección también analiza aquellos casos más inusuales en los que la
interfaz funciona pero no funciona bien, como lo revelan los diferentes códigos y estadísticas de estado de la interfaz.
Códigos de estado de la interfaz y razones para los estados no trabajadores
Los switches Cisco en realidad usan dos conjuntos diferentes de códigos de estado de la interfaz: un conjunto de dos códigos (palabras) que usan
las mismas convenciones que los códigos de estado de la interfaz del enrutador, y otro conjunto con un solo código (palabra). Ambos conjuntos de
códigos de estado pueden determinar si una interfaz está funcionando. El interruptor mostrar interfaces y muestre la descripción de las interfaces los
comandos enumeran el estado de dos códigos denominado estado de línea y estado del protocolo El estado de la línea generalmente se refiere a si la
Capa 1 está funcionando, y el estado del protocolo generalmente se refiere a si la Capa 2 está funcionando.
NOTA Este libro se refiere a estos dos códigos de estado en forma abreviada simplemente enumerando los dos códigos con una barra
diagonal entre ellos, como Subir Subir.
El estado de la interfaz de código único corresponde a diferentes combinaciones de los códigos de estado de interfaz de dos códigos
tradicionales y puede correlacionarse fácilmente con esos códigos. Por ejemplo, el muestra el estado de las interfaces comando enumera un
estado de una sola palabra de conectado estado para interfaces de trabajo, con el mismo significado que las dos palabras Subir Subir estado
visto con el mostrar interfaces y muestre la descripción de las interfaces comandos La Tabla 7-2 enumera las combinaciones de código y
algunas causas raíz que podrían haber causado un estado de interfaz particular.
Technet24
||||||||||||||||||||
Tabla 7-2. Códigos de estado de la interfaz del conmutador LAN
Estado de la línea Estado del Estado de la Causa Raíz Típica

protocolo interfaz
administrativo abajo abajo discapacitado los apagar El comando está configurado en la interfaz.
abajo abajo no conectar Sin cable; mal cable; pines de cable incorrectos; velocidad
discordancia; el dispositivo vecino está (a) apagado, (b) apagar, o
(c) error deshabilitado.
arriba abajo notconnect No se espera en las interfaces físicas del conmutador LAN.
abajo abajo (err- err-disabled La seguridad del puerto ha deshabilitado la interfaz.

deshabilitado)
arriba arriba conectado La interfaz está funcionando.
Al examinar el estado de no conexión por un momento, tenga en cuenta que este estado tiene muchas causas que se han
mencionado en este libro. Por ejemplo, el uso de pines de cableado incorrectos, en lugar de los pines correctos explicados en el
Capítulo 2, "Fundamentos de las LAN Ethernet", causa un problema. Sin embargo, un tema puede ser particularmente difícil de
solucionar: la posibilidad de desajustes de velocidad y dúplex, como se explica en la siguiente sección. Como puede ver en la tabla,
tener un cable defectuoso es solo una de las muchas razones del estado inactivo / inactivo (o no conectado, según el muestra el
estado de las interfaces mando). Algunos ejemplos de las causas raíz de los problemas de cableado incluyen los siguientes:
77
■ La instalación de cualquier equipo que use electricidad, incluso equipos que no sean de TI, puede interferir con la
transmisión en el cableado y hacer que el enlace falle.
■ El cable podría dañarse, por ejemplo, si se encuentra debajo de la alfombra. Si la silla del usuario sigue aplastando el cable,
eventualmente la señal eléctrica puede degradarse.
■ Aunque los cables ópticos no sufren interferencia electromagnética (EMI), alguien puede intentar ser útil y mover un
cable de fibra óptica fuera del camino, doblándolo demasiado. Una curvatura en una forma demasiado apretada
puede evitar que el cable transmita bits (llamado macrobending).
Para los otros estados de interfaz enumerados en la Tabla 7-2, solo el estado arriba / arriba (conectado) necesita más discusión. Una
interfaz puede estar en un estado de funcionamiento, y realmente podría estar funcionando, o podría estar funcionando en un estado
degradado. Los siguientes temas analizan cómo examinar una interfaz up / up (conectada) para averiguar si funciona bien o si tiene
problemas.
Velocidad de interfaz y problemas de dúplex
Para discutir algunos de los problemas de velocidad y dúplex, primero considere la salida del muestra el estado de las interfaces y mostrar
interfaces comandos como se muestra en el Ejemplo 7-7. El primero de estos comandos enumera un resumen de una línea del estado de la
interfaz, mientras que el segundo comando proporciona muchos detalles, pero sorprendentemente, el más breve muestra el estado de las
interfaces El comando nos dice más sobre la negociación automática.

||||||||||||||||||||
Ejemplo 7-7 Visualización de la configuración de velocidad y dúplex en las interfaces del conmutador
SW1 # muestra el estado de las interfaces
Fa0 / 11 conectado 1 una completa 10 10 / 100BaseTX
Fa0 / 12 conectado 1 medio 100 10 / 100BaseTX
Fa0 / 14 discapacitado 1 auto auto 10 / 100BaseTX
! Líneas omitidas por brevedad
SW1 # muestre las interfaces fa0 / 13
FastEthernet0 / 13 está activo, el protocolo de línea está activo (conectado)
El hardware es Fast Ethernet, la dirección es 0019.e86a.6f8d (bia 0019.e86a.6f8d) MTU 1500 bytes, BW 100000 Kbit, DLY
100 usec,
confiabilidad 255/255, txload 1/255, rxload 1/255 Encapsulación ARPA, loopback
no establecido Keepalive set (10 seg)
Full-duplex, 100Mbps, el tipo de medio es 10 / 100BaseTX el control de flujo de entrada está apagado, el
control de flujo de salida no es compatible Tipo de ARP: ARPA, ARP Tiempo de espera 04:00:00
Última entrada 00:00:05, salida 00:00:00, salida bloqueada nunca Última limpieza de los
contadores "show interface" nunca
Cola de entrada: 0/75/0/0 (tamaño / máx. / Gotas / descargas); Caídas de salida totales: 0 Estrategia de cola: quince
cola de salida: 0/40 (tamaño / máx.)
Velocidad de entrada de 5 minutos 0 bits / seg, 0 paquetes / seg Velocidad de
salida de 5 minutos 0 bits / seg, 0 paquetes / seg
85022 paquetes de entrada, 10008976 bytes, 0 sin búfer Recibió 284
transmisiones (0 multidifusión) 0 runts, 0 gigantes, 0 aceleradores
reinicio de interfaz
Technet24
||||||||||||||||||||
0 gotas de protocolo desconocido
0 balbuceos, 0 colisión tardía, 0 diferido 0 pérdida de portadora, 0 sin portadora, 0 PAUSA de
salida 0 fallas del búfer de salida, 0 búferes de salida intercambiados
Aunque ambos comandos en el ejemplo pueden ser útiles, solo el muestra el estado de las interfaces
El comando implica cómo el interruptor determinó la configuración de velocidad y dúplex. La salida del comando enumera las configuraciones
negociadas automáticamente con un prefijo de una- y los valores establecidos manualmente sin el una- prefijo.
Por ejemplo, considere los puertos Fa0 / 12 y Fa0 / 13 en la salida del muestra el estado de las interfaces
mando. Para Fa0 / 13, una completa significa dúplex completo como negociado automáticamente, mientras que medio en Fa0 / 12 significa
semidúplex pero configurado manualmente. El ejemplo sombrea la salida del comando que implica que la velocidad y el dúplex de la interfaz Fa0 /
12 del conmutador no se encontraron a través de la negociación automática, pero Fa0 / 13 sí utilizó la negociación automática. En comparación,
tenga en cuenta que el muestre las interfaces fa0 / 13 comando (sin el estado opción) simplemente enumera la velocidad y el dúplex para la
interfaz Fast Ethernet 0/13, sin que nada implique que los valores se aprendieron a través de la negociación automática.
Cuando el proceso de negociación automática IEEE funciona en ambos dispositivos, es decir, ambos envían mensajes de negociación automática,
ambos dispositivos aceptan la velocidad más rápida y el mejor dúplex admitido por ambos dispositivos. Sin embargo, cuando un dispositivo usa la
negociación automática y el otro lo inhabilita, el primer dispositivo debe recurrir a la configuración predeterminada como se detalla anteriormente en
la sección "Resultados de la negociación automática cuando solo un nodo usa la negociación automática". Como recordatorio, esos valores
77
predeterminados son
■ Velocidad: Detecte la velocidad (sin usar la negociación automática), pero si eso falla, use el valor predeterminado IEEE (la velocidad más
lenta admitida, a menudo 10 Mbps).
■ Dúplex: Use los valores predeterminados de IEEE: Si la velocidad = 10 o 100, use half duplex; de lo contrario, use full duplex.
Cuando un interruptor debe usar sus valores predeterminados, debe obtener la velocidad correcta, pero puede elegir la configuración dúplex
incorrecta, creando una falta de coincidencia dúplex.
Por ejemplo, en la Figura 7-4, imagine que la interfaz Gi0 / 2 de SW2 se configuró con el
velocidad 100 y dúplex completo comandos (esta configuración no se recomienda en una interfaz con capacidad Gigabit, por
cierto). En los switches Cisco, configurando tanto el velocidad y dúplex
los comandos desactivan la negociación automática IEEE en ese puerto. Si la interfaz Gi0 / 1 de SW1 intenta usar la negociación automática,
SW1 también usaría una velocidad de 100 Mbps, pero por defecto usaría half duplex. El ejemplo 7-8 muestra los resultados de este caso
específico en SW1.
PC1 Fa0 / 11 Gi0 / 1 Gi0 / 2 Fa0 / 10 Fa0 / 1
SW1 SW2 R1
0200.1111.1111 Autonegociación Autonegociación 0200.0101.0101

Falla Está desactivado
velocidad 100
dúplex completo
Figura 7-4. Condiciones para crear un desajuste dúplex entre SW1 y SW2
||||||||||||||||||||
Ejemplo 7-8 Confirmación de falta de coincidencia dúplex en el interruptor SW1
SW1 # muestre el estado de las interfaces gi0 / 1
Gi0 / 1 conectado maletero media-100 100/100 / 1000BaseTX
Primero, tenga en cuenta que aunque SW1 tuvo que usar un valor predeterminado de negociación automática, el muestra el estado de las
interfaces El comando todavía muestra la velocidad y el dúplex con el una- prefijo. El puerto de SW2 se configuró manualmente en 100 /
Full, por lo que SW1 detectó la velocidad y funciona a 100 Mbps; sin embargo, las reglas de negociación automática le dicen a SW1 que use
half duplex, como lo confirma la salida en el Ejemplo 7-8. La salida no identifica el desajuste dúplex de ninguna manera; de hecho, encontrar
un desajuste dúplex puede ser mucho más difícil que encontrar un desajuste de velocidad. Por ejemplo, si establece deliberadamente la
velocidad en el enlace de la Figura 7-4 en 10 Mbps en un conmutador y 100 Mbps en el otro, ambos conmutadores enumerarían el puerto en
un estado inactivo / inactivo o no conectado. Sin embargo, en el caso que se muestra en el Ejemplo 7-8, con una falta de coincidencia
dúplex, Si la configuración dúplex no coincide en los extremos de un segmento Ethernet, la interfaz del conmutador seguirá estando
conectada (arriba / arriba) o conectada.
No solo el show El comando da la apariencia de que el enlace no tiene problemas, pero el enlace probablemente funcionará mal, con
síntomas de problemas intermitentes. La razón es que el dispositivo que usa half duplex (SW1 en este caso) usa la lógica de detección
de colisión de acceso múltiple con detección de portadora (CSMA / CD), espera para enviar cuando recibe una trama, cree que las
colisiones ocurren cuando físicamente no lo hacen, y en realidad deja de enviar un cuadro porque el interruptor piensa que ocurrió una
colisión. Con suficiente carga de tráfico, la interfaz podría estar en un estado de conexión, pero es extremadamente ineficiente para
pasar el tráfico.
Para identificar problemas de falta de coincidencia de dúplex, verifique la configuración de dúplex en cada extremo del enlace para ver si los valores
no coinciden. También puede observar el aumento de los contadores de colisión y de colisión tardía, como se explica en la siguiente sección.
Problemas comunes de la capa 1 en las interfaces de trabajo
Cuando la interfaz alcanza el estado de conexión (arriba / arriba), el conmutador considera que la interfaz está funcionando. El conmutador, por
supuesto, intenta usar la interfaz y, al mismo tiempo, el conmutador mantiene varios contadores de interfaz. Estos contadores de interfaz pueden
ayudar a identificar los problemas que pueden ocurrir a pesar de que la interfaz está en un estado de conexión, como los problemas
relacionados con el problema de falta de coincidencia de dúplex que se acaba de describir. Esta sección explica algunos de los conceptos
relacionados y algunos de los problemas más comunes.
Cada vez que la transmisión física tiene problemas, el dispositivo receptor puede recibir una trama cuyos bits han cambiado los valores. Estas
tramas no pasan la lógica de detección de errores implementada en el campo FCS en el avance de Ethernet, como se describe en el Capítulo
2. El dispositivo receptor descarta la trama y la cuenta como algún tipo de error de entrada. Los conmutadores Cisco enumeran este error como
un error CRC, como se destaca en el Ejemplo 7-9. (La verificación de redundancia cíclica [CRC] es un término relacionado con la forma en que
la secuencia de verificación de trama [FCS] matemática detecta un error).
Technet24
||||||||||||||||||||
Ejemplo 7-9 Contadores de interfaz para problemas de capa 1
SW1 # muestre las interfaces fa0 / 13
! líneas omitidas por brevedad
Recibió 284 transmisiones (0 multidifusión) 0 runas, 0 gigantes,
0 aceleradores
reinicio de interfaz 0 gotas de protocolo desconocido
0 balbuceos, 0 colisión tardía, 0 diferido 0 pérdida de portadora, 0 sin portadora, 0 PAUSA de
salida 0 fallas del búfer de salida, 0 búferes de salida intercambiados
El número de errores de entrada y el número de errores de CRC son solo algunos de los contadores en la salida
del mostrar interfaces mando. El desafío es decidir en qué contadores debe pensar, cuáles muestran que está
ocurriendo un problema y cuáles son normales y no son de interés.
El ejemplo destaca varios de los contadores como ejemplos para que pueda comenzar a comprender cuáles apuntan a
problemas y cuáles solo cuentan eventos normales que no son problemas. La siguiente lista muestra una breve 77
descripción de cada contador resaltado, en el orden que se muestra en el ejemplo:
Runas: Tramas que no cumplieron con el requisito mínimo de tamaño de trama (64 bytes, incluido el MAC de destino de
18 bytes, MAC de origen, tipo y FCS). Puede ser causado por colisiones.
Gigantes Tramas que exceden el requisito de tamaño máximo de trama (1518 bytes, incluido el MAC de destino de 18
bytes, el MAC de origen, el tipo y el FCS).
Errores de entrada Un total de muchos contadores, incluidos runas, gigantes, sin búfer, CRC, trama, desbordamiento y recuentos
ignorados.
CRC: Se recibieron marcos que no pasaron las matemáticas de FCS; puede ser causado por colisiones.
Marco: Tramas recibidas que tienen un formato ilegal, por ejemplo, que termina con un byte parcial; puede ser causado
por colisiones.
Salida de paquetes: Número total de paquetes (tramas) reenviados a la interfaz.
Errores de salida: Número total de paquetes (tramas) que el puerto del conmutador intentó transmitir, pero para los cuales se
produjo algún problema.
Colisiones: Contador de todas las colisiones que ocurren cuando la interfaz está transmitiendo una trama.
Colisiones tardías: El subconjunto de todas las colisiones que suceden después de que se ha transmitido el byte 64 de la trama. (En una LAN
Ethernet que funcione correctamente, las colisiones deben ocurrir dentro de los primeros 64 bytes; las colisiones tardías de hoy a menudo apuntan a
una falta de coincidencia de dúplex). Tenga en cuenta que muchos de estos contadores se producen como parte del proceso CSMA / CD que se usa
cuando se habilita half duplex. Las colisiones se producen como una parte normal de la lógica semidúplex impuesta por CSMA / CD, por lo que una
interfaz de conmutador con un contador de colisiones en aumento podría ni siquiera tener un

||||||||||||||||||||
problema. Sin embargo, un problema, llamado colisiones tardías, apunta al clásico problema de desajuste dúplex.
Si un diseño LAN sigue las pautas de cableado, todas las colisiones deben ocurrir al final del byte 64 de cualquier trama. Cuando
un conmutador ya ha enviado 64 bytes de una trama, y el conmutador recibe una trama en esa misma interfaz, el conmutador
detecta una colisión. En este caso, la colisión es una colisión tardía, y el interruptor incrementa el contador de colisión tardía
además de las acciones habituales de CSMA / CD para enviar una señal de atasco, esperar un tiempo aleatorio e intentar
nuevamente. Con un desajuste dúplex, como el desajuste entre SW1 y SW2 en la Figura 7-4, la interfaz halfduplex probablemente
verá el incremento del contador de colisiones tardías. ¿Por qué? La interfaz half-duplex envía una trama (SW1), pero el vecino
full-duplex (SW2) envía en cualquier momento, incluso después del byte 64 de la trama enviada por el interruptor half-duplex.
Entonces, solo sigue repitiendo
mostrar interfaces y si ve que el contador de colisiones tardías se incrementa en una interfaz halfduplex, es posible que tenga un
problema de falta de coincidencia dúplex.
Una interfaz de trabajo (en un estado activo / activo) también puede sufrir problemas relacionados con el cableado físico. Es posible que los
problemas de cableado no sean lo suficientemente graves como para causar una falla completa, pero las fallas de transmisión provocan
que algunas tramas no pasen con éxito por el cable. Por ejemplo, una interferencia excesiva en el cable puede hacer que los diversos
contadores de error de entrada sigan creciendo, especialmente el contador CRC. En particular, si los errores CRC crecen, pero los
contadores de colisiones no lo hacen, el problema podría ser simplemente la interferencia en el cable. (El interruptor también cuenta cada
cuadro colisionado como una forma de error de entrada).
Revisión de capítulos
Una clave para obtener buenos resultados en los exámenes es realizar sesiones de revisión espaciadas repetitivas. Revise el material de este
capítulo utilizando las herramientas del libro o las herramientas interactivas para el mismo material que se encuentra en el sitio web
complementario del libro. Consulte la sección del elemento "Su plan de estudio" titulada "Paso 2: Desarrolle sus hábitos de estudio alrededor
del capítulo" para obtener más detalles. La Tabla 7-3 describe los elementos clave de revisión y dónde puede encontrarlos. Para seguir mejor
el progreso de su estudio, registre cuándo completó estas actividades en la segunda columna.
Tabla 7-3 Seguimiento de revisión de capítulos
Elemento de revisión Fecha (s) de revisión Recurso utilizado
Revisar temas clave Libro, sitio web
Revisar términos clave Libro, sitio web
Responde a las preguntas de DIKTA Libro, PTP
Revisar tablas de comandos Libro
Revisar tablas de memoria Sitio web
Hacer laboratorios Sim Lite, blog
Technet24
||||||||||||||||||||
Revise todos los temas clave

Tabla 7-4 Temas clave para el Capítulo 7
Elemento clave Descripción Número de
del tema página
Ejemplo 7-1 Ejemplo de configuración velocidad, dúplex, y descripción 153
Ejemplo 7-4 Ejemplo de deshabilitar una interfaz usando el apagar comando 155
Lista Reglas clave de decisión para la negociación automática en los switches Cisco cuando el 160
otro dispositivo no participa
Tabla 7-2. Dos tipos de términos de estado de interfaz y sus significados 163
Ejemplo 7-7 Ejemplo que muestra cómo encontrar la configuración de velocidad y dúplex, así como si se 164
aprendieron a través de la negociación automática
Lista Valores predeterminados para la negociación automática IEEE 165
Lista Explicaciones de diferentes estadísticas de error en las interfaces del conmutador 167
Términos clave que debe saber

seguridad portuaria, negociación automática, full duplex, half duplex, 10/100, 10/100/1000
77
Hacer laboratorios
El software Sim Lite es una versión del producto de aprendizaje de simulador completo de Pearson con un subconjunto de los laboratorios, incluido
gratis con este libro. La subred de los laboratorios se relaciona principalmente con esta parte. Tómese el tiempo para probar algunos de los
laboratorios. Como siempre, también consulte las páginas del sitio del blog del autor para ver los ejercicios de configuración (Config Labs) en
https://blog.certskills.com.
Referencias de comando
Las tablas 7-5 y 7-6 enumeran los comandos de configuración y verificación utilizados en este capítulo. Como ejercicio de
revisión fácil, cubra la columna izquierda en una tabla, lea la columna derecha e intente recuperar el comando sin mirar. Luego
repita el ejercicio, cubriendo la columna derecha, e intente recordar lo que hace el comando.
Tabla 7-5 Cambiar la configuración de la interfaz
interfaz escriba el número de puerto Cambia el contexto al modo de interfaz. El tipo es típicamente Fast Ethernet o
Gigabit Ethernet. Los números de puerto posibles varían según el modelo de
conmutador, por ejemplo, Fa0 / 1, Fa0 / 2, etc.
rango de interfaz escriba número de puerto Cambia el contexto al modo de interfaz para un rango de interfaces numeradas
- número de puerto final consecutivamente. Los subcomandos que siguen se aplican a todas las interfaces
en el rango.
||||||||||||||||||||
170 CCNA 200-301 Guía Oficial de Certificación, Volumen 1
apagado | no apagarse Modo de interfaz Deshabilita o habilita la interfaz, respectivamente.
velocidad {10 | 100 1000 | auto} Modo de interfaz Establece manualmente la velocidad a la velocidad indicada o, con la
configuración automática, negocia automáticamente la velocidad.
dúplex {auto | completo | medio} Modo de interfaz Establece manualmente el dúplex a la mitad o lleno, o para negociar
automáticamente la configuración del dúplex.
descripción texto Modo de interfaz Enumera cualquier texto de información que el ingeniero quiera
rastrear para la interfaz, como el dispositivo esperado en el otro extremo del cable.
sin dúplex sin Vuelve a la configuración predeterminada para cada subcomando de interfaz de velocidad
automática, auto dúplex, y la ausencia de un descripción
velocidad sin
mando.
descripción
Tabla 7-6 Capítulo 7 Referencia de comandos EXEC
Mando Propósito
show running-config Enumera la configuración utilizada actualmente
show running-config | interfaz teclea un número Muestra el extracto de la configuración en ejecución de la

interfaz de la lista y solo sus subcomandos
muestre la tabla de dirección mac dinámica Enumera las entradas aprendidas dinámicamente en la tabla de
[ interfaz teclea un número] [ vlan vlan-id] dirección (reenvío) del conmutador, con subconjuntos por interfaz y / o
VLAN
show mac address-table static [interfaz Enumera las direcciones MAC estáticas y las direcciones MAC aprendidas o
teclea un número] definidas con seguridad de puerto
mostrar interfaces [ teclea un número] estado Enumera una línea de salida por interfaz (o solo para la interfaz
listada, si se incluye), anotando la descripción, el estado
operativo y la configuración de dúplex y velocidad en cada
interfaz
mostrar interfaces [ teclea un número] Enumera el estado detallado y la información estadística sobre
todas las interfaces (o solo la interfaz listada)
muestre la descripción de las interfaces Muestra una línea de información por interfaz, con un estado
de dos elementos (similar al mostrar interfaces estado del
comando) e incluye cualquier descripción configurada en las
interfaces
Technet24
||||||||||||||||||||
Esta página se dejó en blanco intencionalmente

||||||||||||||||||||
Parte II Revisión
Mantenga un registro del progreso de la revisión de su parte con la lista de verificación que se muestra en la Tabla P2-1. Los detalles de cada tarea
siguen la tabla.
Tabla P2-1 Parte II Lista de verificación de revisión de parte
Actividad 1.a fecha completada 2.a fecha completada
Repita todas las preguntas de DIKTA Responda
Preguntas de repaso de partes Repase temas
clave Do Labs
Revise el Apéndice P en los videos del sitio web
complementario
Repita todas las preguntas DIKTA
Para esta tarea, responda la pregunta "¿Ya sé esto?" preguntas nuevamente para los capítulos de esta parte del libro,
utilizando el software PCPT.
Responda preguntas de revisión de parte
Para esta tarea, responda las preguntas de Revisión de parte para esta parte del libro, utilizando el software PTP.
Revisar temas clave

Revise todos los temas clave en todos los capítulos de esta parte, ya sea navegando por los capítulos o utilizando la aplicación Temas
clave en el sitio web complementario.
Laboratorios
Dependiendo de la herramienta de laboratorio elegida, aquí hay algunas sugerencias sobre qué hacer en el laboratorio:
Pearson Network Simulator: Si usa el simulador completo de Pearson ICND1 o CCNA, concéntrese más en el escenario de configuración
y los laboratorios de escenarios de solución de problemas asociados con los temas de esta parte del libro. Estos tipos de laboratorios
incluyen un conjunto más amplio de temas y funcionan bien como actividades de revisión parcial. (Consulte la Introducción para obtener
algunos detalles sobre cómo encontrar qué laboratorios son sobre temas en esta parte del libro).
Blog: laboratorios de configuración: El blog del autor incluye una serie de laboratorios centrados en la configuración que puede hacer en
papel, cada uno en 10-15 minutos. Revise y realice los laboratorios para esta parte del libro, tal como se encuentra en http://blog.certskills.com.
Luego navegue a los laboratorios de configuración práctica.
Technet24
||||||||||||||||||||
Otro: Si usa otras herramientas de laboratorio, como algunas sugerencias: Asegúrese de experimentar mucho con la configuración de
VLAN y la configuración de enlace troncal de VLAN. Además, pase algún tiempo cambiando la configuración de la interfaz como velocidad
y dúplex en un enlace entre dos conmutadores, para asegurarse de que comprende qué casos darían lugar a una falta de coincidencia
dúplex.
Revise el Apéndice P en el sitio web complementario
La edición anterior del plan de examen CCNA incluía la palabra "solucionar problemas" aplicada a Ethernet y VLAN,
mientras que el plan de examen CCNA actual no. El Apéndice P en el sitio web complementario contiene un capítulo de la
edición anterior del libro que se centró en la solución de problemas. Ese apéndice, denominado "Solución de problemas de
LAN", puede ser útil como herramienta para revisar los temas de esta parte del libro. (Tenga en cuenta que si usa este
apéndice adicional, puede ignorar las menciones de Port Security hasta que haya alcanzado ese tema en el CCNA 200-301
Guía Oficial de Certificación, Volumen 2.)
Ver videos
Los capítulos 4 y 5 recomiendan cada uno un video que puede ser útil para cualquiera que esté aprendiendo acerca de la CLI de
Cisco y los conceptos básicos de conmutación. Si aún no ha visto esos videos, tómese un momento para navegar al sitio web
complementario y ver los videos (enumerados en los Capítulos 4 y 5).
||||||||||||||||||||
La Parte II de este libro presenta los conceptos básicos de las LAN Ethernet, tanto en concepto como en cómo implementar las
características. Sin embargo, las dos características principales discutidas en la Parte III de este libro: LAN virtuales (VLAN) y Protocolo
de árbol de expansión (STP), afectan casi todo lo que ha aprendido sobre Ethernet hasta ahora. Las VLAN permiten que un ingeniero de
red cree LAN Ethernet separadas a través de opciones de configuración simples. La capacidad de separar algunos puertos de
conmutador en una VLAN y otros puertos de conmutador en otra VLAN brinda a los diseñadores de redes una herramienta poderosa para
crear redes. Una vez creadas, las VLAN también tienen un gran impacto en cómo funciona un conmutador, lo que luego afecta la forma
en que verifica y soluciona los problemas de funcionamiento de la LAN de un campus.
STP, y el Rapid STP (RSTP) relacionado y similar, actúa para evitar que las tramas se repitan en una LAN. Sin STP
o RSTP, en las LAN con enlaces redundantes, las transmisiones y algunas otras tramas se reenviarían alrededor y
alrededor de la LAN, eventualmente obstruyendo la LAN hasta dejarla inutilizable.
El plan actual del examen CCNA 200-301 incluye temas de examen para la configuración y verificación de VLAN y temas
relacionados. Sin embargo, los temas del examen CCNA solo mencionan conceptos RSTP en lugar de configuración /
verificación. Con ese fin, la Parte III se abre con el Capítulo 8, que va a la profundidad de configuración / verificación con
temas de VLAN, seguido del Capítulo 9, que presenta los conceptos de STP y RSTP.
La Parte III se cierra con el Capítulo 10, que incluye algunas configuraciones RSTP, junto con la configuración de capa 2
EtherChannel.
Otros recursos
Como una sugerencia adicional para aquellos que tienen la intención de pasar a CCNP Enterprise, considere leer o leer el
Apéndice P, "Solución de problemas de LAN", que se encuentra en el sitio web complementario en línea. Este apéndice, una
copia de un capítulo de la edición anterior del libro, toma un enfoque de resolución de problemas para muchos de los temas
encontrados en las Partes II y III de este libro. Aunque Cisco eliminó por completo la palabra solucionar problemas del plan de
examen CCNA en su versión actual CCNA 200-301, los temas siguen siendo relevantes y pueden ser de ayuda para revisar y
refinar lo que aprendió en las Partes II y III de este libro.
Technet24
||||||||||||||||||||
Parte III
Implementación de VLAN y STP
Capítulo 8: Implementación de LAN virtuales Ethernet
Capítulo 9: Conceptos del protocolo Spanning Tree
Capítulo 10: Configuración RSTP y EtherChannel
Parte III Revisión

||||||||||||||||||||
CAPÍTULO 8
Implementación de LAN virtuales Ethernet
Este capítulo cubre los siguientes temas de examen:
1.0 Fundamentos de la red
1.13 Describir conceptos de cambio
1.13.a MAC aprendizaje y envejecimiento
1.13.b Cambio de trama
1.13.c Inundación de marco
1.13.d tabla de direcciones MAC
2.0 acceso a la red
2.1 Configurar y verificar VLAN (rango normal) que abarcan varios conmutadores
2.1.a Puertos de acceso (datos y voz)
2.1.b VLAN predeterminada
2.1.c Conectividad
2.2 Configurar y verificar la conectividad entre conmutadores
2.2.a Puertos troncales
2.2.b 802.1Q
2.2.c VLAN nativa
Hasta ahora en este libro, ha aprendido que los conmutadores Ethernet reciben tramas Ethernet, toman decisiones y
luego reenvían (conmutan) esas tramas Ethernet. Esa lógica central gira en torno a las direcciones MAC, la interfaz en la
que llega el marco y las interfaces a las que el conmutador reenvía el marco.
Si bien es cierto, esa lógica omite cualquier consideración de LAN virtuales (VLAN). Las VLAN afectan la lógica de
conmutación para cada trama porque cada VLAN actúa como un subconjunto de los puertos del conmutador en una
LAN Ethernet. Los conmutadores creen que cada trama de Ethernet se recibe en una VLAN identificable, se reenvía en
función de las entradas de la tabla MAC para esa VLAN y se reenvían los puertos en esa VLAN. Este capítulo explora
esos conceptos y otros relacionados con las VLAN. En cuanto a la organización del capítulo, la primera sección
principal del capítulo explica los conceptos centrales. Estos conceptos incluyen cómo funcionan las VLAN en un solo
conmutador, cómo usar el enlace troncal de VLAN para crear VLAN que abarquen varios conmutadores y cómo
reenviar el tráfico entre las VLAN mediante un enrutador. La segunda sección principal muestra cómo configurar VLAN
y troncales de VLAN: cómo asignar interfaces estáticamente a una VLAN.
Technet24
||||||||||||||||||||
"¿Ya sé esto?" Examen

Responda el cuestionario (ya sea aquí o use el software PTP) si desea usar el puntaje para ayudarlo a decidir cuánto tiempo pasará
en este capítulo. Las respuestas a las letras se enumeran en la parte inferior de la página después del cuestionario. El Apéndice C,
que se encuentra tanto al final del libro como en el sitio web complementario, incluye tanto las respuestas como las explicaciones.
También puede encontrar respuestas y explicaciones en el software de prueba PTP.
Tabla 8-1. "¿Ya sé esto?" Asignación de temas básicos de la sección a la pregunta

Sección de temas básicos Preguntas
Conceptos de LAN virtual 1–3
Configuración y verificación de VLAN y VLAN Trunking 4–6
Solución de problemas de VLAN y troncales de VLAN 7–8
1) En una LAN, ¿cuál de los siguientes términos equivale mejor al término VLAN?
a. Dominio de colisión
si. Dominio de difusión
C. Subred
re. Interruptor único
mi. Maletero
2) Imagine un conmutador con tres VLAN configuradas. ¿Cuántas subredes IP se requieren, suponiendo que todos los hosts
en todas las VLAN quieran usar TCP / IP?
a. 0 0
si. 1
C. 2
re. 3
mi. No se puede distinguir de la información proporcionada.
3) El conmutador SW1 envía una trama para conmutar SW2 utilizando el enlace 802.1Q. De los cuales
Las respuestas describen cómo SW1 cambia o agrega a la trama de Ethernet antes de reenviar la trama a SW2.
a. Inserta un encabezado de 4 bytes y cambia las direcciones MAC
si. Inserta un encabezado de 4 bytes y no cambia las direcciones MAC
C. Encapsula el marco original detrás de un encabezado Ethernet completamente nuevo
re. Ninguna de las otras respuestas son correctas.

||||||||||||||||||||
4) Imagine que le dicen que el interruptor 1 está configurado con el auto dinámico parámetro para el enlace troncal en su interfaz
Fa0 / 5, que está conectada al interruptor 2. Debe configurar el interruptor 2. ¿Cuál de las siguientes configuraciones para el
enlace troncal podría permitir que funcione el enlace troncal? (Elija dos respuestas)
a. en
si. auto dinámico
C. dinámica deseable
re. acceso
mi. Ninguna de las otras respuestas son correctas.
5) Acaba de llegar un switch de Cisco. El conmutador nunca se ha configurado con ninguna

VLAN, pero VTP ha sido deshabilitado. Un ingeniero configura el vlan 22 y nombre Hannahs-VLAN comandos
y luego sale del modo de configuración. ¿Cuál de lo siguiente es cierto? (Elija dos respuestas)
a. La VLAN 22 aparece en la salida de la muestra breve vlan mando.
si. La VLAN 22 aparece en la salida de la show running-config mando.
C. La VLAN 22 no se crea mediante este proceso.
re. La VLAN 22 no existe en ese conmutador hasta que se asigne al menos una interfaz a
esa VLAN.
6) ¿Cuál de los siguientes comandos identifica las interfaces del conmutador como enlaces troncales entre
caras: interfaces que actualmente funcionan como troncales VLAN? (Elija dos respuestas)
a. mostrar interfaces
si. muestre las interfaces switchport
C. muestre el tronco de las interfaces
re. mostrar troncos
7) En un conmutador que deshabilita VTP, un ingeniero configura los comandos vlan 30 y

apagado vlan 30. ¿Qué respuestas deberían ser ciertas acerca de este cambio? (Elija dos respuestas)
a. los muestra breve vlan El comando debe enumerar la VLAN 30.
si. los show running-config El comando debe enumerar la VLAN 30.
C. El conmutador debe reenviar las tramas que llegan a los puertos de acceso en la VLAN 30.
re. El conmutador debe reenviar las tramas que llegan a los puertos troncales etiquetados con
VLAN 30.
8) los muestre las interfaces g0 / 1 troncal El comando proporciona tres listas de ID de VLAN. Cuales
Qué elementos limitarían las VLAN que aparecen en la primera de las tres listas de VLAN?
a. UNA apagado vlan 30 comando global
si. UNA switchport trunk permitido vlan subcomando de interfaz
C. Una opción STP para bloquear en G0 / 1
re. UNA no vlan 30 comando global
Technet24
||||||||||||||||||||
Capítulo 8: Implementación de LAN virtuales Ethernet 179
Temas de la fundación
Conceptos de LAN virtual

Antes de comprender las VLAN, primero debe tener una comprensión específica de la definición de una LAN. Por ejemplo, desde una
perspectiva, una LAN incluye todos los dispositivos de usuario, servidores, conmutadores, enrutadores, cables y puntos de acceso
inalámbrico en una ubicación. Sin embargo, una definición alternativa más estrecha de una LAN puede ayudar a comprender el
concepto de una LAN virtual: una LAN incluye todos los dispositivos en el mismo dominio de difusión.
Un dominio de difusión incluye el conjunto de todos los dispositivos conectados a la LAN, de modo que cuando cualquiera de los dispositivos
envía una trama de difusión, todos los demás dispositivos obtienen una copia de la trama. Entonces, desde una perspectiva, puede pensar que
una LAN y un dominio de difusión son básicamente lo mismo.
Usando solo la configuración predeterminada, un conmutador considera que todas sus interfaces están en el mismo dominio de difusión. Es decir,
para un conmutador, cuando una trama de difusión entró en un puerto de conmutador, el conmutador reenvía esa trama de difusión a todos los
demás puertos. Con esa lógica, para crear dos dominios de transmisión LAN diferentes, tenía que comprar dos conmutadores LAN Ethernet
diferentes, como se muestra en la Figura 8-1.
Broadcast Broadcast
Domain 1 Dino Wilma Domain 2
SW1 SW2 Betty

Fred
Subred 1 Subred 2
Figura 8-1. Creación de dos dominios de difusión con dos conmutadores físicos y sin VLAN 8
Al usar dos VLAN, un solo conmutador puede lograr los mismos objetivos del diseño en la Figura 8-1, para crear dos dominios
de difusión, con un solo conmutador. Con las VLAN, un conmutador puede configurar algunas interfaces en un dominio de
difusión y otras en otro, creando múltiples dominios de difusión. Estos dominios de difusión individuales creados por el
conmutador se denominan
LAN virtuales ( VLAN).
Por ejemplo, en la Figura 8-2, el conmutador único crea dos VLAN, tratando los puertos en cada VLAN como
completamente separados. El conmutador nunca reenviará una trama enviada por Dino (en la VLAN 1) a Wilma o
Betty (en la VLAN 2).
Broadcast
Domain 1 Dino Dominio 2
(VLAN 1) (VLAN 2)
Fred SW1 Betty Wilma Broadcast
Subred 1 Subred 2
Figura 8-2. Creación de dos dominios de difusión con un conmutador y VLAN
El diseño de LAN de campus para usar más VLAN, cada una con un número menor de dispositivos, a menudo ayuda a mejorar la
LAN de muchas maneras. Por ejemplo, una transmisión enviada por un host en una VLAN será recibida y procesada por todos los
demás hosts en la VLAN, pero no por hosts en una VLAN diferente. Limitar la cantidad de hosts que reciben una única trama de
transmisión reduce la cantidad de hosts que desperdician el esfuerzo al procesar transmisiones innecesarias. También reduce
||||||||||||||||||||
riesgos de seguridad porque menos hosts ven tramas enviadas por un host. Estas son solo algunas razones para
separar los hosts en diferentes VLAN. La siguiente lista resume los motivos más comunes para elegir crear dominios
de difusión más pequeños (VLAN):
■ Para reducir la sobrecarga de la CPU en cada dispositivo, mejorando el rendimiento del host, reduciendo la cantidad de
dispositivos que reciben cada trama de difusión
■ Para reducir los riesgos de seguridad al reducir la cantidad de hosts que reciben copias de tramas que inundan los
conmutadores (transmisiones, multidifusión y unidifusión desconocida)
■ Para mejorar la seguridad de los hosts mediante la aplicación de diferentes políticas de seguridad por VLAN
■ Para crear diseños más flexibles que agrupen a los usuarios por departamento o por grupos que trabajen juntos, en lugar de
por ubicación física
■ Para resolver problemas más rápidamente, porque el dominio de falla para muchos problemas es el mismo conjunto de dispositivos
que aquellos en el mismo dominio de transmisión
■ Para reducir la carga de trabajo para el Protocolo de árbol de expansión (STP) limitando una VLAN a un solo conmutador de acceso
El resto de este capítulo analiza de cerca la mecánica de cómo funcionan las VLAN en varios conmutadores Cisco, incluida la
configuración requerida. Para ese fin, la siguiente sección examina el enlace troncal de VLAN, una característica requerida al
instalar una VLAN que existe en más de un conmutador LAN.
Creación de VLAN de conmutadores múltiples usando Trunking
La configuración de VLAN en un solo conmutador requiere solo un pequeño esfuerzo: simplemente configura cada puerto para
indicarle el número de VLAN al que pertenece el puerto. Con varios conmutadores, debe considerar conceptos adicionales sobre
cómo reenviar el tráfico entre los conmutadores. Cuando utiliza VLAN en redes que tienen múltiples conmutadores interconectados,
los conmutadores deben usar VLAN trunking en los enlaces entre los interruptores. El enlace troncal de VLAN hace que los
conmutadores utilicen un proceso denominado Etiquetado de VLAN, mediante el cual el conmutador de envío agrega otro encabezado
al marco antes de enviarlo a través del enlace troncal. Este encabezado de enlace adicional incluye un Identificador de VLAN ( ID de
VLAN) para que el conmutador emisor pueda asociar la trama con una ID de VLAN particular, y el conmutador receptor pueda saber
a qué VLAN pertenece cada trama.
La Figura 8-3 muestra un ejemplo que muestra las VLAN que existen en varios conmutadores, pero no utiliza el enlace troncal.
Primero, el diseño utiliza dos VLAN: VLAN 10 y VLAN 20. Cada conmutador tiene dos puertos asignados a cada VLAN, por lo que
cada VLAN existe en ambos conmutadores. Para reenviar el tráfico en la VLAN 10 entre los dos conmutadores, el diseño incluye un
enlace entre los conmutadores, con ese enlace completamente dentro de la VLAN 10. Del mismo modo, para admitir el tráfico VLAN 20
entre los conmutadores, el diseño utiliza un segundo enlace entre los conmutadores, con ese enlace dentro VLAN 20. El diseño en la
Figura 8-3 funciona perfectamente. Por ejemplo, PC11 (en VLAN 10) puede enviar una trama a PC14. La trama fluye hacia SW1, sobre
el enlace superior (el que está en la VLAN 10) y hacia SW2.
Respuestas a la pregunta "¿Ya sé esto?" examen:
1 si 2 re 3 si 4 4 A, C 5 5 A, B 6 6 ANTES DE CRISTO 7 7 A, B 8 si
Technet24
||||||||||||||||||||
VLAN 10
11 12 13 14
El enlace está en la VLAN 10 El
SW1 SW2
enlace está en la VLAN 20
21 22 23 24
VLAN 20
Figura 8-3. VLAN multiswitch sin enlace troncal VLAN
El diseño que se muestra en la Figura 8-3 funciona, pero simplemente no escala muy bien. Requiere un enlace físico entre los
conmutadores para admitir cada VLAN. Si un diseño necesitara 10 o 20 VLAN, necesitaría 10 o 20 enlaces entre conmutadores,
y utilizaría 10 o 20 puertos de conmutador (en cada conmutador) para esos enlaces.
Conceptos de etiquetado de VLAN
El enlace troncal de VLAN crea un enlace entre los conmutadores que admite tantas VLAN como sea necesario. Como troncal de
VLAN, los conmutadores tratan el enlace como si fuera parte de todas las VLAN. Al mismo tiempo, la troncal mantiene el tráfico de
la VLAN separado, por lo que las tramas en la VLAN 10 no irían a los dispositivos en la VLAN 20, y viceversa, porque cada trama se
identifica por el número de VLAN cuando cruza la troncal. La figura 8-4 muestra la idea, con un solo enlace físico entre los dos
interruptores.
8
VLAN 10
20 10 20 10 20
SW1 SW2
VLAN 20
Figura 8-4. VLAN multiswitch con trunking
El uso del enlace troncal permite a los conmutadores reenviar tramas desde varias VLAN a través de una única conexión física
agregando un pequeño encabezado a la trama Ethernet. Por ejemplo, la Figura 8-5 muestra a PC11 enviando una trama de difusión en
la interfaz Fa0 / 1 en el Paso 1. Para inundar la trama, el interruptor SW1 necesita reenviar la trama de difusión para cambiar SW2. Sin
embargo, SW1 necesita que SW2 sepa que la trama es parte de la VLAN 10, de modo que después de recibir la trama, SW2 inundará
la trama solo en la VLAN 10 y no en la VLAN 20. Entonces, como se muestra en el Paso 2, antes enviando el marco, SW1 agrega un
encabezado de VLAN al marco original de Ethernet, con el encabezado de VLAN que enumera una ID de VLAN de 10 en este caso.
||||||||||||||||||||
VLAN 10 VLAN 10
14
Ethernet 1
0/1 3 0/1 0/2 3

Ethernet
G0 / 1 G0 / 2
20 10 20 10 20
SW1 SW2
VLAN 10 Ethernet
0/3 0/4 0/3 0/4
2
21 22 23 24
VLAN 20 11 VLAN 20 13
Figura 8-5. VLAN Trunking entre dos conmutadores
Cuando SW2 recibe la trama, entiende que la trama está en la VLAN 10. Luego, SW2 elimina el encabezado de la VLAN,
reenviando la trama original a sus interfaces en la VLAN 10 (Paso 3). Para otro ejemplo, considere el caso cuando PC21 (en la
VLAN 20) envía una transmisión. SW1 envía el puerto de difusión Fa0 / 4 (porque ese puerto está en la VLAN 20) y Gi0 / 1
(porque es un enlace troncal, lo que significa que admite varias VLAN diferentes). SW1 agrega un encabezado de enlace troncal
al marco, enumerando una ID de VLAN de 20. SW2 elimina el encabezado de enlace troncal después de determinar que el
marco es parte de la VLAN 20, por lo que SW2 sabe reenviar el marco solo a los puertos Fa0 / 3 y Fa0 / 4 , porque están en la
VLAN 20 y no en los puertos Fa0 / 1 y Fa0 / 2, porque están en la VLAN 10.
Los protocolos de enlace troncal 802.1Q e ISL VLAN
Cisco ha admitido dos protocolos de trunking diferentes a lo largo de los años: Inter-Switch Link (ISL) e IEEE 802.1Q. Cisco creó
el ISL años antes de 802.1Q, en parte porque el IEEE aún no había definido un estándar de enlace VLAN. Hoy, 802.1Q se ha
convertido en el protocolo de trunking más popular, con Cisco que ni siquiera se molesta en admitir ISL en muchos de sus
modelos de conmutadores en la actualidad.
Si bien tanto ISL como 802.1Q etiquetan cada cuadro con la ID de VLAN, los detalles difieren. 802.1Q inserta un encabezado VLAN
802.1Q adicional de 4 bytes en el encabezado Ethernet de la trama original, como se muestra en la parte superior de la Figura 8-6. En
cuanto a los campos en el encabezado 802.1Q, solo el campo de ID de VLAN de 12 bits dentro del encabezado 802.1Q importa para los
temas discutidos en este libro. Este campo de 12 bits admite un máximo teórico de 2 12 ( 4096) VLAN, pero en la práctica admite un
máximo de 4094. (Tanto 802.1Q como ISL usan 12 bits para etiquetar la ID de VLAN, con dos valores reservados [0 y 4095]).
Los switches Cisco dividen el rango de ID de VLAN (1–4094) en dos rangos: el rango normal y el rango extendido. Todos los
conmutadores pueden usar VLAN de rango normal con valores de 1 a 1005. Solo algunos conmutadores pueden usar VLAN de
rango extendido con ID de VLAN de 1006 a 4094. Las reglas para qué conmutadores pueden usar VLAN de rango extendido
dependen de la configuración de la VLAN Protocolo de enlace troncal (VTP), que se trata brevemente en la sección "Configuración
de enlace troncal VLAN", más adelante en este capítulo.
Technet24
||||||||||||||||||||
802.1Q
Dest. Dirección Fuente Dirección Etiqueta Tipo Datos FCS
Tipo Bandera de prioridad ID de VLAN (12 bits)
Figura 8-6 802.1Q Trunking
802.1Q también define una ID de VLAN especial en cada troncal como VLAN nativa ( por defecto usar VLAN 1). Por
definición, 802.1Q simplemente no agrega un encabezado 802.1Q a las tramas en la VLAN nativa. Cuando el interruptor en
el otro lado del tronco recibe un marco que no tiene
Encabezado 802.1Q, el conmutador receptor sabe que la trama es parte de la VLAN nativa. Tenga en cuenta que debido a este
comportamiento, ambos conmutadores deben acordar qué VLAN es la VLAN nativa. La VLAN nativa 802.1Q proporciona algunas
funciones interesantes, principalmente para admitir conexiones a dispositivos que no entienden el enlace troncal. Por ejemplo, un
conmutador Cisco podría conectarse a un conmutador que no entienda el enlace 802.1Q. El conmutador Cisco podría enviar tramas en
la VLAN nativa, lo que significa que la trama no tiene encabezado de enlace troncal, de modo que el otro conmutador entendería la
trama. El concepto de VLAN nativa brinda a los conmutadores la capacidad de pasar al menos el tráfico en una VLAN (la VLAN nativa),
lo que puede permitir algunas funciones básicas, como la posibilidad de acceder a Telnet en un conmutador.
Reenvío de datos entre VLAN

Si crea una LAN de campus que contiene muchas VLAN, normalmente todavía necesita todos los dispositivos para poder enviar
8
datos a todos los demás dispositivos. El siguiente tema trata algunos conceptos sobre cómo enrutar datos entre esas VLAN.
La necesidad de enrutamiento entre VLAN

Los conmutadores LAN que reenvían datos basados en la lógica de Capa 2, como se discutió hasta ahora en este libro, suelen ir por el
nombre Interruptor de capa 2. Por ejemplo, el Capítulo 5, "Análisis de la Conmutación LAN Ethernet", analizó cómo los conmutadores LAN
reciben tramas Ethernet (un concepto de Capa 2), observan la dirección MAC Ethernet de destino (una dirección de Capa 2) y reenvían la
trama Ethernet a otra interfaz . Todos esos conceptos están definidos por los protocolos de capa 2, de ahí el nombre de conmutador de
capa 2.
Los switches de capa 2 realizan su lógica por VLAN. Por ejemplo, en la Figura 8-7, las dos PC de la izquierda se sientan en la VLAN 10, en
la subred 10. Las dos PC de la derecha se sientan en una VLAN diferente (20), con una subred diferente (20). Tenga en cuenta que la
figura se repite anteriormente en la Figura 8-2, pero con el conmutador dividido en mitades, para enfatizar el punto de que los conmutadores
de capa 2 no reenviarán datos entre dos VLAN.
Como se muestra en la figura, cuando se configura con algunos puertos en VLAN 10 y otros en VLAN
20, el conmutador actúa como dos conmutadores separados en los que reenviará el tráfico. De hecho, un objetivo de las
VLAN es separar el tráfico en una VLAN de otra, evitando que las tramas en una VLAN se filtren a otras VLAN. Por ejemplo,
cuando Dino (en la VLAN 10) envía una trama de Ethernet, si SW1 es un conmutador de capa 2, ese conmutador no
reenviará la trama a las PC a la derecha en la VLAN 20.
||||||||||||||||||||
VLAN 10 VLAN 20
Subred 10 Dino Wilma Subred 20
Fred Betty
Figura 8-7 El conmutador de capa 2 no se enruta entre las VLAN
Enrutamiento de paquetes entre VLAN con un enrutador
Cuando se incluyen VLAN en un diseño de LAN de campus, los dispositivos en una VLAN deben estar en la misma subred. Siguiendo
la misma lógica de diseño, los dispositivos en diferentes VLAN deben estar en diferentes subredes.
Para reenviar paquetes entre VLAN, la red debe usar un dispositivo que actúe como un enrutador. Puede usar un enrutador real, así
como algunos otros interruptores que pueden realizar algunas funciones como un enrutador. Estos interruptores que también
realizan funciones de enrutamiento de capa 3 tienen el nombre interruptor multicapa o Interruptor de capa 3. Esta sección primero
discute cómo reenviar datos entre VLAN cuando se usan conmutadores de capa 2 y termina con una breve discusión sobre cómo
usar los conmutadores de capa 3. Por ejemplo, la Figura 8-8 muestra un enrutador que puede enrutar paquetes entre las subredes
10 y 20. La figura muestra el mismo conmutador de Capa 2 como se muestra en la Figura 8-7, con la misma perspectiva del
conmutador dividido en partes con dos diferentes VLAN y con las mismas PC en las mismas VLAN y subredes. Ahora el enrutador
R1 tiene una interfaz física LAN conectada al conmutador y asignada a la VLAN 10, y una segunda interfaz física conectada al
conmutador y asignada a la VLAN 20. Con una interfaz conectada a cada subred, el conmutador de capa 2 puede seguir haciendo
su trabajo. —Enviar marcos dentro de una VLAN, mientras que el enrutador puede hacer su trabajo— enrutar paquetes IP entre las
subredes.
VLAN 10 VLAN 20
Subred 10 Dino Wilma Subred 20
Fred Betty
F0 / 0 F0 / 1
R1
Figura 8-8. Enrutamiento entre dos VLAN en dos interfaces físicas
La figura muestra un paquete IP que se enruta de Fred, que se encuentra en una VLAN / subred, a Betty, que se encuentra
en la otra. El conmutador de capa 2 reenvía dos tramas Ethernet de capa 2 diferentes: una en VLAN 10, desde Fred a la
interfaz F0 / 0 de R1, y la otra en VLAN 20, desde la interfaz F0 / 1 de R1 a Betty. Desde la perspectiva de la Capa 3, Fred
envía el paquete IP a su enrutador predeterminado (R1), y R1 enruta el paquete a otra interfaz (F0 / 1) a otra subred donde
reside Betty.
El diseño de la Figura 8-8 funciona, pero hay varias soluciones diferentes para enrutar paquetes entre VLAN. Este
capítulo muestra la opción de usar un enrutador físico separado, con un
Technet24
||||||||||||||||||||
enlace separado por VLAN, porque puede ser la opción más fácil de entender y visualizar. El Capítulo 17,
“Enrutamiento IP en la LAN”, funciona a través de esas otras funciones para enrutar paquetes entre VLAN.
Configuración y verificación de VLAN y VLAN Trunking
Los switches Cisco no requieren ninguna configuración para funcionar. Puede comprar conmutadores Cisco, instalar
dispositivos con el cableado correcto, encender los conmutadores y funcionan. Nunca necesitaría configurar el conmutador, y
funcionaría bien, incluso si interconectara los conmutadores, hasta que necesitara más de una VLAN. Pero si desea usar
VLAN, y la mayoría de las redes empresariales lo hacen, debe agregar alguna configuración.
Este capítulo separa los detalles de configuración de VLAN en dos secciones principales. La primera sección analiza cómo configurar las
interfaces de acceso estático: las interfaces del conmutador configuradas para estar en una sola VLAN, por lo tanto, no utilizan enlaces
troncales VLAN. La segunda parte muestra cómo configurar las interfaces que usan el enlace troncal VLAN.
Crear VLAN y asignar VLAN de acceso a una interfaz

Esta sección muestra cómo crear una VLAN, asignarle un nombre a la VLAN y asignar interfaces a una VLAN. Para centrarse en estos detalles
básicos, esta sección muestra ejemplos que utilizan un solo conmutador, por lo que no se necesita el enlace troncal de VLAN.
Para que un conmutador Cisco reenvíe tramas en una VLAN particular, el conmutador debe estar configurado para creer que existe
la VLAN. Además, el conmutador debe tener interfaces que no sean troncales (llamadas interfaces de acceso, o interfaces de
acceso estático) asignado a la VLAN y / o troncales que admiten la VLAN. Los pasos de configuración para las interfaces de acceso
8
son los siguientes:
Lista de Paso 1. Para configurar una nueva VLAN, siga estos pasos:
verificación de configuración
A. Desde el modo de configuración, use el vlan vlan-id comando en la configuración global

modo de ración para crear la VLAN y mover al usuario al modo de configuración de VLAN.
SI. ( Opcional) Use el nombre nombre comando en modo de configuración de VLAN

para enumerar un nombre para la VLAN. Si no está configurado, el nombre de VLAN es VLAN ZZZZ dónde
ZZZZ es la ID de VLAN decimal de cuatro dígitos.
Paso 2. Para cada interfaz de acceso, siga estos pasos:
A. Utilizar el interfaz teclea un número comando en modo de configuración global para

pasar al modo de configuración de interfaz para cada interfaz deseada.
SI. Utilizar el switchport access vlan número de identificación comando en la configuración de la interfaz
modo de ración para especificar el número de VLAN asociado con esa interfaz.
C. ( Opcional) Use el acceso al modo switchport comando en la configuración de la interfaz
modo de ración para hacer que este puerto siempre funcione en modo de acceso (es decir, no troncal).
Si bien la lista puede parecer un poco desalentadora, el proceso en un solo interruptor es bastante simple. Por ejemplo,
si desea colocar los puertos del conmutador en tres VLAN: 11, 12 y
||||||||||||||||||||
13: primero agregas tres vlan comandos: vlan 11, vlan 12, y vlan 13. Luego, para cada interfaz, agregue un acceso de
switchport vlan 11 ( o 12 o 13) comando para asignar esa interfaz a la VLAN adecuada.
NOTA El termino VLAN predeterminada ( como se muestra en los temas del examen) se refiere a la configuración predeterminada en switchport
access vlan vlan-id comando, y ese valor predeterminado es ID de VLAN 1. En otras palabras, de forma predeterminada, cada puerto está asignado
para acceder a la VLAN 1.
Configuración de VLAN Ejemplo 1: Configuración de VLAN completa
Los ejemplos 8-1, 8-2 y 8-3 funcionan a través de un escenario con configuración y verificación de VLAN. Para comenzar, el Ejemplo 8-1
comienza mostrando las VLAN en el conmutador SW1 en la Figura 8-9, con todas las configuraciones predeterminadas relacionadas con las
VLAN.
VLAN 2
Fa0 / 13 Fa0 / 14
VLAN 1 VLAN 3
Fa0 / 12 Fa0 / 15
Fa0 / 11 Fa0 / 16
SW1
Figura 8-9 Red con un conmutador y tres VLAN
Ejemplo 8-1 Configuración de VLAN y asignación de VLAN a interfaces
SW1 # muestra breve vlan
Nombre de VLAN Estado Puertos
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 defecto activo Fa0 / 1, Fa0 / 2, Fa0 / 3, Fa0 / 4 Fa0 / 5, Fa0 / 6,
Fa0 / 7, Fa0 / 8 Fa0 / 9, Fa0 / 10, Fa0 / 11, Fa0 / 12
Fa0 / 13, Fa0 / 14, Fa0 / 15, Fa0 / 16 Fa0 / 17, Fa0 /
18, Fa0 / 19, Fa0 / 20 Fa0 / 21, Fa0 / 22, Fa0 / 23,
Fa0 / 24 Gi0 / 1, Gi0 / 2
1002 fddi-default acto / unsup
1003 token-ring-default acto / unsup
1004 fddinet-default acto / unsup
1005 trnet-default acto / unsup
El ejemplo comienza con el muestra breve vlan comando, que confirma la configuración predeterminada de cinco VLAN no eliminables, con
todas las interfaces asignadas a la VLAN 1. La VLAN 1 no se puede eliminar, pero se puede usar. Las VLAN 1002–1005 no se pueden
eliminar y no se pueden usar como VLAN de acceso en la actualidad. En particular, tenga en cuenta que este conmutador 2960 tiene 24
puertos Fast Ethernet (Fa0 / 1– Fa0 / 24) y dos puertos Gigabit Ethernet (Gi0 / 1 y Gi0 / 2), todos los cuales se enumeran como en
Technet24
||||||||||||||||||||
VLAN 1 según la salida de ese primer comando, lo que confirma que, de manera predeterminada, los conmutadores Cisco asignan todos los puertos a
la VLAN 1.
A continuación, el Ejemplo 8-2 muestra los pasos que reflejan la lista de verificación de configuración de VLAN, es decir, la
configuración de VLAN 2, más la asignación de VLAN 2 como VLAN de acceso en dos puertos: Fa0 / 13 y Fa0 / 14.
Ejemplo 8-2 Configuración de VLAN y asignación de VLAN a interfaces
Ingrese los comandos de configuración, uno por línea. Termina con CNTL / Z. SW1 (config) # vlan 2
SW1 (config-vlan) # nombre Freds-vlan
SW1 (config-vlan) # salida
SW1 (config) # rango de interfaz fastethernet 0/13 - 14
SW1 (config-if) # switchport access vlan 2
SW1 (config-if) # acceso al modo switchport
SW1 (config-if) # final
SW1 # muestra breve vlan
Nombre de VLAN Estado Puertos
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 defecto activo Fa0 / 1, Fa0 / 2, Fa0 / 3, Fa0 / 4 Fa0 / 5, Fa0 / 6,
Fa0 / 7, Fa0 / 8 Fa0 / 9, Fa0 / 10, Fa0 / 11, Fa0 / 12
Fa0 / 15, Fa0 / 16, Fa0 / 17, Fa0 / 18 Fa0 / 19, Fa0 /
20, Fa0 / 21, Fa0 / 22 Fa0 / 23, Fa0 / 24, Gi0 / 1,

8
Gi0 / 2
2 Freds-vlan activo Fa0 / 13, Fa0 / 14
1002 fddi-default acto / unsup
1003 token-ring-default acto / unsup
1004 fddinet-default acto / unsup
1005 trnet-default acto / unsup
Tómese un momento para comparar la salida del muestra breve vlan commands in Example 8-2 (after adding the
configuration) versus Example 8-1. Example 8-2 shows new information about VLAN 2, with ports Fa0/13 and Fa0/14
no longer being listed with VLAN 1, but now listed as assigned to VLAN 2.
To complete this scenario, Example 8-3 shows a little more detail about the VLAN itself. First, the show
running-config command lists both the vlan 2 and switchport access vlan 2 commands as configured in Example
8-2. Also, note that earlier Example 8-2 uses the
interface range command, with one instance of the switchport access vlan 2 interface subcommand. However,
Example 8-3 shows how the switch actually applied that command to both Fa0/13 and Fa0/14. Example 8-3 ends
with the show vlan id 2 command, which confirms the operational status that ports Fa0/13 and Fa0/14 are assigned
to VLAN 2.
||||||||||||||||||||
188 CCNA 200-301 Official Cert Guide, Volume 1
Example 8-3 Configuring VLANs and Assigning VLANs to Interfaces
SW1# show running-config
! Many lines omitted for brevity ! Early in the output:
vlan 2
name Freds-vlan !
! more lines omitted for brevity interface
FastEthernet0/13 switchport access vlan 2 switchport
mode access !
interface FastEthernet0/14 switchport access
vlan 2 switchport mode access !
SW1# show vlan id 2
VLAN Name Status Ports
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2 Freds-vlan active Fa0/13, Fa0/14
VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2 enet 100010 1500 - - - - - 0 0
Remote SPAN VLAN
- - - - - - - - - - - - - - - -
Disabled
Primary Secondary Type Ports
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The example surrounding Figure 8-9 uses six switch ports, all of which need to operate as access ports. That is,
each port should not use trunking but instead should be assigned to a single VLAN, as assigned by the switchport
access vlan vlan-id command. For ports that should always act as access ports, add the optional interface
subcommand switchport mode access. This command tells the switch to always be an access interface and
disables the protocol that negotiates trunking (Dynamic Trunking Protocol [DTP]) with the device on the other end of
the link. (The upcoming section “VLAN Trunking Configuration” discusses more details about the commands that
allow a port to negotiate whether it should use trunking.)
NOTE The book includes a video that works through a different VLAN configuration example as well. You can
find the video on the companion website.
Technet24
||||||||||||||||||||
Chapter 8: Implementing Ethernet Virtual LANs 189
VLAN Configuration Example 2: Shorter VLAN Configuration

Example 8-2 shows how to configure a VLAN and add two ports to the VLAN as access ports. Example 8-4 does
the same, this time with VLAN 3, and this time with a much briefer alternative configuration. The configuration
completes the configuration of the design shown in Figure 8-9, by adding two ports to VLAN 3.
Example 8-4 Shorter VLAN Configuration Example (VLAN 3)
SW1# configure terminal
Enter configuration commands, one per line. End with CNTL/Z. SW1(config)# interface range
Fastethernet 0/15 - 16
SW1(config-if-range)# switchport access vlan 3
% Access VLAN does not exist. Creating vlan 3 SW1(config-if-range)# ^ Z
SW1# show vlan brief
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4 Fa0/5, Fa0/6, Fa0/7,
Fa0/8 Fa0/9, Fa0/10, Fa0/11, Fa0/12 Fa0/17,
Fa0/18, Fa0/19, Fa0/20 Fa0/21, Fa0/22, Fa0/23,
Fa0/24 Gi0/1, Gi0/2
2 Freds-vlan active Fa0/13, Fa0/14

8
3 VLAN0003 active Fa0/15, Fa0/16
1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup
Example 8-2 shows how a switch can dynamically create a VLAN—the equivalent of the
vlan vlan-id global config command—when the switchport access vlan interface subcommand refers to a currently
unconfigured VLAN. This example begins with SW1 not knowing about VLAN 3. With the addition of the switchport
access vlan 3 interface subcommand, the switch realized that VLAN 3 did not exist, and as noted in the shaded
message in the example, the switch created VLAN 3, using a default name (VLAN0003). The engineer did not need
to type the vlan 3 global command to create VLAN 3; the switch did that automatically. No other steps are required
to create the VLAN. At the end of the process, VLAN 3 exists in the switch, and interfaces Fa0/15 and Fa0/16 are in
VLAN 3, as noted in the shaded part of the show vlan brief command output.
VLAN Trunking Protocol

Before showing more configuration examples, you also need to know something about a Cisco protocol and tool
called the VLAN Trunking Protocol (VTP). VTP is a Cisco proprietary
||||||||||||||||||||
tool on Cisco switches that advertises each VLAN configured in one switch (with the vlan
number command) so that all the other switches in the campus learn about that VLAN. This book does not discuss
VTP as an end to itself for a few different reasons. First, the current CCNA 200-301 exam blueprint ignores VTP, as do
the CCNP Enterprise Core and CCNP Enterprise Advanced Routing blueprints. Additionally, many enterprises choose
to disable VTP. Also, you can easily disable VTP so that it has no impact on your switches in the lab, which is exactly
what I did when building all the examples in this book.
However, VTP has some small impact on how every Cisco Catalyst switch works, even if you do not try to use VTP.
This brief section introduces enough details of VTP so that you can see these small differences in VTP that cannot
be avoided.
First, all examples in this book (and in Volume 2) use switches that disable VTP in some way. Interestingly, for much
of VTP’s decades of existence, most switches did not allow VTP to be disabled completely; on those switches, to
effectively disable VTP, the engineer would set the switch to use VTP transparent mode (with the vtp mode
transparent global command). Some switches now have an option to disable VTP completely with the vtp mode off global
command. For the purposes of this book, configuring a switch with either transparent mode or off mode disables
VTP.
Note that both transparent and off modes prevent VTP from learning and advertising about VLAN configuration.
Those modes allow a switch to configure all VLANs, including standard- and extended-range VLANs. Additionally,
switches using transparent or off modes list the vlan configuration commands in the running-config file.
Finally, on a practical note, if you happen to do lab exercises with real switches or with simulators, and you see
unusual results with VLANs, check the VTP status with the show vtp status command. If your switch uses VTP
server or client mode, you will find
■ The server switches can configure VLANs in the standard range only (1–1005).
■ The client switches cannot configure VLANs.
■ Both servers and clients may be learning new VLANs from other switches and seeing their VLANs deleted
by other switches because of VTP.
■ The show running-config command does not list any vlan commands; you must use other show commands
to find out about the configured VLANs.
If possible in the lab, switch to disable VTP and ignore VTP for your switch configuration practice until you
decide to learn more about VTP for other purposes.
NOTE Do not change VTP settings on any switch that also connects to the production network until you know how
VTP works and you talk with experienced colleagues. Doing so can cause real harm to your LAN. For example, if
the switch you configure connects to other switches, which in turn connect to switches used in the production
LAN, you could accidentally change the VLAN configuration in other switches with serious impact to the operation
of the network. You could delete VLANs and cause outages. Be careful and never experiment with VTP settings
on a switch unless it and the other switches connected to it have absolutely no physical links connected to the
production LAN.
Technet24
||||||||||||||||||||
VLAN Trunking Configuration

Trunking configuration between two Cisco switches can be very simple if you just statically configure trunking. For
example, most Cisco Catalyst switches today support only 802.1Q and not ISL. You could literally add one
interface subcommand for the switch interface on each side of the link ( switchport mode trunk), and you would
create a VLAN trunk that supported all the VLANs known to each switch.
However, trunking configuration on Cisco switches includes many more options, including several options for
dynamically negotiating various trunking settings. The configuration can either predefine different settings or tell
the switch to negotiate the settings, as follows:
■ The type of trunking: IEEE 802.1Q, ISL, or negotiate which one to use, on switches that support both types of
trunking.
■ The administrative mode: Whether to always trunk, always not trunk, or negotiate whether to trunk or
not.
First, consider the type of trunking. Cisco switches that support ISL and 802.1Q can negotiate which type to use,
using the Dynamic Trunking Protocol (DTP). If both switches support both protocols, they use ISL; otherwise, they
use the protocol that both support. Today, many Cisco switches do not support the older ISL trunking protocol.
Switches that support both types of trunking use the switchport trunk encapsulation {dot1q | isl | negotiate} interface
subcommand to either configure the type or allow DTP to negotiate the type. DTP can also negotiate whether the
two devices on the link agree to trunk at all, as guided by the local switch port’s administrative mode. The
administrative mode refers to the configuration setting for whether trunking should be used. Each interface also has
an operational
mode, which refers to what is currently happening on the interface and might have been chosen by DTP’s 8
negotiation with the other device. Cisco switches use the switchport mode
interface subcommand to define the administrative trunking mode, as listed in Table 8-2.
Table 8-2 Trunking Administrative Mode Options with the switchport mode Command
Command Option Description
access Always act as an access (nontrunk) port
trunk Always act as a trunk port
dynamic desirable Initiates negotiation messages and responds to negotiation messages to dynamically
choose whether to start using trunking
dynamic auto Passively waits to receive trunk negotiation messages, at which point the switch will
respond and negotiate whether to use trunking
For example, consider the two switches shown in Figure 8-10. This figure expands the design shown earlier in
Figure 8-9, with a trunk to a new switch (SW2) and with parts of VLANs 1 and 3 on ports attached to SW2. The two
switches use a Gigabit Ethernet link for the trunk. In this case, the trunk does not dynamically form by default
because both (2960) switches default to an administrative mode of dynamic auto, meaning that neither switch
initiates the trunk negotiation process. When one switch is changed to use dynamic desirable mode, which does
initiate the negotiation, the switches negotiate to use trunking, specifically
802.1Q because the 2960s support only 802.1Q.

||||||||||||||||||||
VLAN 2
VLAN 1 Fa0/13 Fa0/14 VLAN 3
Fa0/12 Fa0/15
Fa0/11 Fa0/16
SW1
Gi0/1
Trunk
Gi0/2
Fa0/22 Fa0/23
Fa0/21 Fa0/24
SW2
Figure 8-10 Network with Two Switches and Three VLANs
Example 8-5 begins with SW1 configured as shown in Examples 8-2 and 8-4—that is, SW1 has two ports each
assigned to VLANs 1, 2, and 3. However, both SW1 and SW2 currently have all default settings on the interfaces
that connect the two switches. With the default setting of switchport mode dynamic auto, the two switches do not
trunk.
Example 8-5 Initial (Default) State: Not Trunking Between SW1 and SW2
SW1# show interfaces gigabit 0/1 switchport
Name: Gi0/1
Switchport: Enabled
Administrative Mode: dynamic auto Operational Mode:
static access
Administrative Trunking Encapsulation: dot1q Operational Trunking
Encapsulation: native Negotiation of Trunking: On Access Mode VLAN: 1
(default) Trunking Native Mode VLAN: 1 (default) Administrative Native
VLAN tagging: enabled Voice VLAN: none
Access Mode VLAN: 1 (default) Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled Voice VLAN: none
Administrative private-vlan host-association: none Administrative private-vlan mapping: none Administrative
private-vlan trunk native VLAN: none Administrative private-vlan trunk Native VLAN tagging: enabled
Administrative private-vlan trunk encapsulation: dot1q
Technet24
||||||||||||||||||||
Administrative private-vlan trunk normal VLANs: none Administrative private-vlan trunk
private VLANs: none Operational private-vlan: none Trunking VLANs Enabled: ALL Pruning
VLANs Enabled: 2-1001 Capture Mode Disabled Capture VLANs Allowed: ALL
Protected: false
Unknown unicast blocked: disabled Unknown multicast
blocked: disabled Appliance trust: none
! Note that the next command results in a single empty line of output. SW1# show interfaces trunk
SW1#
First, focus on the highlighted items from the output of the show interfaces switchport
command at the beginning of Example 8-3. The output lists the default administrative mode setting of dynamic auto.
Because SW2 also defaults to dynamic auto, the command lists SW1’s operational status as “access,” meaning that
it is not trunking. (“Dynamic auto” tells both switches to sit there and wait on the other switch to start the
negotiations.) The third shaded line points out the only supported type of trunking (802.1Q). (On a switch that
supports both ISL and 802.1Q, this value would by default list “negotiate,” to mean that the type of encapsulation is
negotiated.) Finally, the operational trunking type is listed as “native,” which is a reference to the 802.1Q native
VLAN. The end of the example shows the output of the show interfaces trunk command, but with no output. This 8
command lists information about all interfaces that currently operationally trunk; that is, it lists interfaces that
currently use VLAN trunking. With no interfaces listed, this command also confirms that the link between switches is
not trunking. Next, consider Example 8-6, which shows the new configuration that enables trunking. In this case,
SW1 is configured with the switchport mode dynamic desirable command, which asks the switch to both negotiate
as well as to begin the negotiation process, rather than waiting on the other device. The example shows that as soon
as the command is issued, log messages appear showing that the interface goes down and then back up again,
which happens when the interface transitions from access mode to trunk mode.
Example 8-6 SW1 Changes from Dynamic Auto to Dynamic Desirable
Enter configuration commands, one per line. End with CNTL/Z. SW1(config)# interface gigabit 0/1
SW1(config-if)# switchport mode dynamic desirable
SW1(config-if)# ^ Z
SW1#
||||||||||||||||||||
%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to

down
%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to

up SW1# show interfaces gigabit 0/1 switchport
Name: Gi0/1
Switchport: Enabled
Administrative Mode: dynamic desirable Operational Mode: trunk
Encapsulation: dot1q Negotiation of Trunking: On Access Mode VLAN: 1
(default) Trunking Native Mode VLAN: 1 (default) ! lines omitted for brevity
Example 8-6 repeats the show interfaces gi0/1 switchport command seen in Example 8-5, but after configuring
VLAN trunking, so this time the output shows that SW1’s G0/1 interface now operates as a trunk. Note that the
command still lists the administrative settings, which denote the configured values along with the operational
settings, which list what the switch is currently doing. SW1 now claims to be in an operational mode of trunk, with an
operational trunking encapsulation of dot1Q. Example 8-7 now repeats the same show interfaces trunk command
that showed no output at all back in Example 8-5. Now that SW1 trunks on its G0/1 port, the output in Example 8-7
lists G0/1, confirming that G0/1 is now operationally trunking. The next section discusses the meaning of the output
of this command. Also, note that the end of the example repeats the show vlan id 2 command; of note, it includes
the trunk port G0/1 in the output because the trunk port can forward traffic in VLAN 2.
Example 8-7 A Closer Look at SW1’s G0/1 Trunk Port
SW1# show interfaces trunk
Port Mode Encapsulation Status Native vlan
Gi0/1 desirable 802.1q trunking 1
Port Vlans allowed on trunk
Gi0/1 1-4094
Port Vlans allowed and active in management domain
Gi0/1 1-3
Port Vlans in spanning tree forwarding state and not pruned
Gi0/1 1-3
Technet24
||||||||||||||||||||
SW1# show vlan id 2
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2 Freds-vlan active Fa0/13, Fa0/14, G0/1
VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2 enet 100010 1500 - - - - - 0 0
Remote SPAN VLAN
- - - - - - - - - - - - - - - -
Disabled
Primary Secondary Type Ports
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
For the exams, you should be ready to interpret the output of the show interfaces switchport command, realize
the administrative mode implied by the output, and know whether the link should operationally trunk based on
those settings. Table 8-3 lists the combinations of the trunking administrative modes and the expected operational
mode (trunk or access) resulting from the configured settings. The table lists the administrative mode used on one
end of the link on the left, and the administrative mode on the switch on the other end of the link across the top of
the table.
Table 8-3 Expected Trunking Operational Mode Based on the Configured Administrative Modes
8
Administrative Mode Access Dynamic Auto Trunk Dynamic Desirable
access Access Access Do Not Use 1 Access
dynamic auto Access Access Trunk Trunk
trunk Do Not Use 1 Trunk Trunk Trunk
dynamic desirable Access Trunk Trunk Trunk
1 When two switches configure a mode of “access” on one end and “trunk” on the other, problems occur. Avoid this combination.
Finally, before leaving the discussion of configuring trunks, Cisco recommends disabling trunk negotiation on
most ports for better security. The majority of switch ports on most switches will be used to connect to users and
configured with the command switchport mode access —which also disables DTP. For ports without the switchport
mode access
command—for instance, ports statically configured to trunk with the switchport mode trunk command—DTP still
operates, but you can disable DTP negotiations altogether using the switchport nonegotiate interface
subcommand.
||||||||||||||||||||
Implementing Interfaces Connected to Phones

This next topic is strange, at least in the context of access links and trunk links. In the world of IP telephony,
telephones use Ethernet ports to connect to an Ethernet network so they can use IP to send and receive voice traffic
sent via IP packets. To make that work, the switch’s Ethernet port acts like an access port, but at the same time, the
port acts like a trunk in some ways. This last topic of the chapter works through those main concepts.
Data and Voice VLAN Concepts

Before IP telephony, a PC could sit on the same desk as a phone. The phone happened to use UTP cabling, with that
phone connected to some voice device (often called a voice switch
or a private branch exchange [PBX]). The PC, of course, connected using an unshielded twisted-pair (UTP) cable to
the usual LAN switch that sat in the wiring closet—sometimes in the same wiring closet as the voice switch. Figure
8-11 shows the idea.
User’s Desk Closet
Telephone UTP Voice

Switch
Ethernet UTP Ethernet

Switch
Figure 8-11 Before IP Telephony: PC and Phone, One Cable Each, Connect to Two Different Devices
The term IP telephony refers to the branch of networking in which the telephones use IP packets to send and
receive voice as represented by the bits in the data portion of the IP packet. The phones connect to the network like
most other end-user devices, using either Ethernet or Wi-Fi. These new IP phones did not connect via cable
directly to a voice switch, instead connecting to the IP network using an Ethernet cable and an Ethernet port built in
to the phone. The phones then communicated over the IP network with software that replaced the call setup and
other functions of the PBX. (The current products from Cisco that perform this IP telephony control function are
called Cisco Unified Communication Manager.)
The migration from using the already-installed telephone cabling to these new IP phones that needed UTP cables
that supported Ethernet caused some problems in some offices. In particular:
■ The older non-IP phones used a category of UTP cabling that often did not support 100Mbps or 1000-Mbps
Ethernet.
■ Most offices had a single UTP cable running from the wiring closet to each desk, but now two devices (the PC
and the new IP phone) both needed a cable from the desktop to the wiring closet.
■ Installing a new cable to every desk would be expensive, plus you would need more switch ports.
Technet24
||||||||||||||||||||
To solve this problem, Cisco embedded small three-port switches into each phone. IP telephones have included a
small LAN switch, on the underside of the phone, since the earliest IP telephone products. Figure 8-12 shows the
basic cabling, with the wiring closet cable connecting to one physical port on the embedded switch, the PC
connecting with a short patch cable to the other physical port, and the phone’s internal CPU connecting to an
internal switch port.
User’s Desk Wiring Closet
PC Phone
Ethernet UTP
IP
Ethernet
Switch
Patch Embedded
Cable Switch
Figure 8-12 Cabling with an IP Phone, a Single Cable, and an Integrated Switch
Sites that use IP telephony, which includes almost every company today, now have two devices off each access
port. In addition, Cisco best practices for IP telephony design tell us to put the phones in one VLAN and the PCs in
a different VLAN. To make that happen, the switch port acts a little like an access link (for the PC’s traffic), and a
little like a trunk (for the phone’s traffic). The configuration defines two VLANs on that port, as follows:
Data VLAN: Same idea and configuration as the access VLAN on an access port but defined as the VLAN
on that link for forwarding the traffic for the device connected to the phone on the desk (typically the user’s
8
PC).
Voice VLAN: The VLAN defined on the link for forwarding the phone’s traffic. Traffic in this VLAN is typically
tagged with an 802.1Q header.
Figure 8-13 illustrates this design with two VLANs on access ports that support IP telephones.
IP
Voice VLAN IP VLAN 11
IP
IP
Data VLAN
VLAN 10
Figure 8-13 A LAN Design, with Data in VLAN 10 and Phones in VLAN 11
||||||||||||||||||||
Data and Voice VLAN Configuration and Verification

Configuring a switch port to support IP phones, once you know the planned voice and data VLAN IDs, requires just
a few easy commands. Making sense of the show commands once it is configured, however, can be a challenge.
The port acts like an access port in many ways. However, with most configuration options, the voice frames flow
with an 802.1Q header, so that the link supports frames in both VLANs on the link. But that makes for some different
show command output.
Example 8-8 shows an example configuration. In this case, all four switch ports F0/1–F0/4 begin with default
configuration. The configuration adds the new data and voice VLANs. The example then configures all four ports as
access ports and defines the access VLAN, which is also called the data VLAN when discussing IP telephony. Finally,
the configuration includes the switchport voice vlan 11 command, which defines the voice VLAN used on the port.
The example matches Figure 8-13, using ports F0/1–F0/4.
Example 8-8 Configuring the Voice and Data VLAN on Ports Connected to Phones
Enter configuration commands, one per line. End with CNTL/Z. SW1(config)# vlan 10
SW1(config-vlan)# vlan 11
SW1(config-vlan)# interface range FastEthernet0/1 - 4
SW1(config-if)# switchport mode access
SW1(config-if)# switchport access vlan 10
SW1(config-if)# switchport voice vlan 11
SW1(config-if)#^ Z
SW1#
NOTE CDP, which is discussed in the CCNA 200-301 Official Cert Guide, Volume 2,
Chapter 9, “Device Management Protocols,” must be enabled on an interface for a voice access port to work
with Cisco IP phones. Cisco switches and routers enable CDP by default, so its configuration is not shown
here.
The following list details the configuration steps for easier review and study:
Config Step 1. Use the vlan vlan-id command in global configuration mode to create the data
Checklist
and voice VLANs if they do not already exist on the switch.
Step 2. Configure the data VLAN like an access VLAN, as usual:
A. Use the interface type number command global configuration mode to

move into interface configuration mode.
B. Use the switchport access vlan id-number command in interface configu-

ration mode to define the data VLAN.
C. Use the switchport mode access command in interface configuration mode

to make this port always operate in access mode (that is, to not trunk).
Step 3. Use the switchport voice vlan id-number command in interface configuration
mode to set the voice VLAN ID.
Technet24
||||||||||||||||||||
Verifying the status of a switch port configured like Example 8-8 shows some different output compared to the pure
access port and pure trunk port configurations seen earlier in this chapter. For example, the show interfaces
switchport command shows details about the operation of an interface, including many details about access ports.
Example 8-9 shows those details for port F0/4 after the configuration in Example 8-8 was added.
Example 8-9 Verifying the Data VLAN (Access VLAN) and Voice VLAN
SW1# show interfaces FastEthernet 0/4 switchport
Name: Fa0/4
Switchport: Enabled
Administrative Mode: static access Operational Mode:
static access
Encapsulation: native Negotiation of Trunking: Off Access Mode VLAN: 10
(VLAN0010) Trunking Native Mode VLAN: 1 (default) Administrative Native
VLAN tagging: enabled Voice VLAN: 11 (VLAN0011)
! The rest of the output is omitted for brevity
Working through the first three highlighted lines in the output, all those details should look familiar for any access
port. The switchport mode access configuration command statically configures the administrative mode to be an
access port, so the port of course operates as an access port. Also, as shown in the third highlighted line, the switchport
access vlan 10 configuration command defined the access mode VLAN as highlighted here. The fourth highlighted 8
line shows the one small new piece of information: the voice VLAN ID, as set with the switchport voice vlan 11 command
in this case. This small line of output is the only piece of information in the output that differs from the earlier access
port examples in this chapter.
These ports act more like access ports than trunk ports. In fact, the show interfaces
type number switchport command boldly proclaims, “Operational Mode: static access.” However, one other show command
reveals just a little more about the underlying operation with 802.1Q tagging for the voice frames. As mentioned
earlier, the show interfaces trunk command—that is, the command that does not include a specific interface in the
middle of the command—lists the operational trunks on a switch. With IP telephony ports, the ports do not show up in
the list of trunks either— providing evidence that these links are not treated as trunks. Example 8-10 shows just such
an example. However, the show interfaces trunk command with the interface listed in the middle of the command,
as is also shown in Example 8-10, does list some additional information. Note that in this case, the show interfaces
F0/4 trunk command lists the status as not-trunking, but with VLANs 10 and 11 allowed on the trunk. (Normally, on
an access port, only the access VLAN is listed in the “VLANs allowed on the trunk” list in the output of this
command.)
||||||||||||||||||||
Example 8-10 Allowed VLAN List and the List of Active VLANs
SW1# show interfaces F0/4 trunk
Fa0/4 off 802.1q not-trunking 1
Fa0/4 10-11
Fa0/4 10-11
Fa0/4 10-11
Summary: IP Telephony Ports on Switches

It might seem as though this short topic about IP telephony and switch configuration includes a lot of small twists
and turns and trivia, and it does. The most important items to remember are as follows:
■ Configure these ports like a normal access port to begin: Configure it as a static access port and assign it an
access VLAN.
■ Add one more command to define the voice VLAN ( switchport voice vlan vlan-id).
■ Look for the mention of the voice VLAN ID, but no other new facts, in the output of the
show interfaces type number switchport command.
■ Look for both the voice and data (access) VLAN IDs in the output of the show interfaces
type number trunk command.
■ Do not expect to see the port listed in the list of operational trunks as listed by the show interfaces trunk command.
Troubleshooting VLANs and VLAN Trunks

A switch’s data plane forwarding processes depend in part on VLANs and VLAN trunking. This final section of the
chapter focuses on issues related to VLANs and VLAN trunks that could prevent LAN switching from working
properly, focusing on a few items not yet discussed in the chapter. In particular, this section examines these steps
an engineer can take to avoid issues:
Step 1. Confirm that all VLANs are both defined and active.
Step 2. Check the allowed VLAN lists on both ends of each trunk to ensure that all VLANs intended to
be used are included.
Technet24
||||||||||||||||||||
Step 3. Check for incorrect trunk configuration settings that result in one switch operating as a trunk, with
the neighboring switch not operating as a trunk.
Step 4. Check the native VLAN settings on both ends of the trunk to ensure the settings match.
Access VLANs Undefined or Disabled

Switches do not forward frames for VLANs that are (a) not known because the VLAN is not configured or has not
been learned with VTP or (b) the VLAN is known, but it is disabled (shut down). This next topic summarizes the
best ways to confirm that a switch knows that a particular VLAN exists, and if it exists, determines the shutdown
state of the VLAN. First, on the issue of whether a VLAN exists on a switch, a VLAN can be defined to a switch in
two ways: using the vlan number global configuration command, or it can be learned from another switch using VTP.
As mentioned earlier in this chapter, the examples in this book assume that you are not using VTP. If you discover
that a VLAN does not exist on a switch, simply configure the VLAN as discussed earlier in the section, “Creating
VLANs and Assigning Access VLANs to an Interface.”
In addition to checking the configuration, you can check for the status of the VLAN (as well as whether it is known
to the switch) using the show vlan command. No matter the VTP mode, this command will list all VLANs known to
the switch, plus one of two VLAN state values, depending on the current state: either active or act/lshut. The second
of these states means that the VLAN is shut down. Shutting down a VLAN disables the VLAN on that switch only,
so the switch will not forward frames in that VLAN.
8
Switch IOS gives you two similar configuration methods with which to disable ( shutdown)
and enable ( no shutdown) a VLAN. Example 8-11 shows how, first by using the global command [ no] shutdown
vlan number and then using the VLAN mode subcommand [ no] shutdown. The example shows the global commands
enabling and disabling VLANs 10 and
20, respectively, and using VLAN subcommands to enable and disable VLANs 30 and 40, respectively.
Example 8-11 Enabling and Disabling VLANs on a Switch
SW2# show vlan brief
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4 Fa0/5, Fa0/6, Fa0/7,
Fa0/8 Fa0/9, Fa0/10, Fa0/11, Fa0/12 Fa0/14,
Fa0/15, Fa0/16, Fa0/17 Fa0/18, Fa0/19, Fa0/20,
Fa0/21 Fa0/22, Fa0/23, Fa0/24, Gi0/1
10 VLAN0010 act/lshut Fa0/13
20 VLAN0020 active
30 VLAN0030 act/lshut
||||||||||||||||||||
40 VLAN0040 active
1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup
Enter configuration commands, one per line. End with CNTL/Z. SW2(config)# no shutdown vlan 10
SW2(config)# shutdown vlan 20
SW2(config)# vlan 30
SW2(config-vlan)# no shutdown
SW2(config-vlan)# vlan 40
SW2(config-vlan)# shutdown
SW2(config-vlan)#
NOTE The output of the show vlan brief command also lists a state of “act/unsup” for the reserved VLAN IDs
1002–1005, with “unsup” meaning “unsupported.”
Mismatched Trunking Operational States

Trunking can be configured correctly so that both switches use trunking. However, trunks can also be
misconfigured, with a couple of different results: either both switches do not trunk, or one switch trunks and the other
does not. Both results cause problems. The most common incorrect configuration—which results in both switches
not trunking—is a configuration that uses the switchport mode dynamic auto command on both switches on the
link. The word auto just makes us all want to think that the link would trunk automatically, but this command is both
automatic and passive. As a result, both switches passively wait on the other device on the link to begin
negotiations. Example 8-12 highlights those parts of the output from the show interfaces switchport command that
confirm both the configured and operational states. Note that the output lists the operational mode as “static access”
rather than “trunking.”
Example 8-12 Operational Trunking State
SW2# show interfaces gigabit0/2 switchport
Name: Gi0/2
Switchport: Enabled
Administrative Mode: dynamic auto Operational Mode:
static access
Encapsulation: native ! lines omitted for brevity
Technet24
||||||||||||||||||||
A different incorrect trunking configuration has an even worse result: one switch trunks, sending tagged frames,
while the neighboring switch does not trunk, so the neighboring switch discards any frames it receives that have a
VLAN tag in the header. When this combination of events happens, the interface works in that the status on each
end will be up/up or connected. Traffic in the native VLAN will actually cross the link successfully because those
frames have no VLAN tags (headers). However, traffic in all the rest of the VLANs will not cross the link.
Figure 8-14 shows the incorrect configuration along with which side trunks and which does not. The side that trunks
(SW1 in this case) enables trunking using the command switchport mode trunk but also disables Dynamic
Trunking Protocol (DTP) negotiations using the
switchport nonegotiate command. SW2’s configuration also helps create the problem, by using one of the two
trunking options that relies on DTP. Because SW1 has disabled DTP, SW2’s DTP negotiations fail, and SW2
chooses to not trunk.
1 Frame has
2
VLAN 10 Eth. Frame
802.1Q: Discard!
Gi0/1 Gi0/2
SW1 Trunk Mode: On Trunk Mode: Access SW2
switchport mode trunk switchport mode dynamic desirable

switchport nonegotiate
Figure 8-14 Mismatched Trunking Operational States
The figure shows what happens when using this incorrect configuration. At Step 1, SW1 could (for example) forward 8
a frame in VLAN 10. However, SW2 would view any frame that arrives with an 802.1Q header as illegal because the
frame has an 802.1Q header, and SW2 treats its G0/2 port as an access port. So, SW2 discards any 802.1Q frames
received on that port.
The trunking issues shown here can be easily avoided by checking the configuration and by checking the trunk’s
operational state (mode) on both sides of the trunk. The best commands to check trunking-related facts are show
interfaces trunk and show interfaces switchport.
Just be aware that the switches do not prevent you from making these configuration mistakes.
The Supported VLAN List on Trunks

A Cisco switch can forward traffic for all defined and active VLANs. However, a particular VLAN trunk may not
forward traffic for a defined and active VLAN for a variety of other reasons. You should learn how to identify
which VLANs a particular trunk port currently supports and the reasons why the switch might not be forwarding
frames for a VLAN on that trunk port.
The first category in this step can be easily done using the show interfaces interface-id
trunk command, which only lists information about currently operational trunks. The best place to begin with this
command is the last section of output, which lists the VLANs whose
||||||||||||||||||||
traffic will be forwarded over the trunk. Any VLANs that make it to this final list of VLANs in the command output
meet the following criteria:
■ The VLAN has not been removed from the allowed VLAN list on the trunk (as configured with the switchport
trunk allowed vlan interface subcommand).
■ The VLAN exists and is active on the local switch (as seen in the show vlan command).
■ The VLAN has not been VTP-pruned from the trunk. (Because this book attempts to ignore VTP as much as
possible, this section assumes that VTP is not used and this feature has no impact on any trunks.) The trunk is in an
STP forwarding state in that VLAN (as also seen in the show spanning-tree vlan vlan-id command). The switchport
trunk allowed vlan interface subcommand gives the network engineer a method to administratively limit the VLANs
whose traffic uses a trunk. If the engineer wants all defined VLANs to be supported on a trunk, the engineer simply
does not configure this command. If the engineer would like to limit the trunk to support a subset of the VLANs
known to the switch, however, the engineer can add one or more switchport trunk allowed vlan interface
subcommands.
For instance, in a switch that has configured VLANs 1 through 100, but no others, by default the switch would
allow traffic in all 100 VLANs. However, the trunk interface command switchport trunk allowed vlan 1-60 would
limit the trunk to forward traffic for VLANs 1 through 60, but not the rest of the VLANs. Example 8-13 shows a
sample of the command output from the show interfaces trunk command, which confirms the first list of VLAN
IDs now lists VLANs 1–60. Without the switchport trunk allowed vlan command, the first list would have
included VLANs 1–4094.
Example 8-13 Allowed VLAN List and List of Active VLANs
Gi0/1 desirable 802.1q trunking 1
Gi0/1 1-60
Gi0/1 1-59
Gi0/1 1-58
The output of the show interfaces trunk command creates three separate lists of VLANs, each under a separate
heading. These three lists show a progression of reasons why a VLAN is not forwarded over a trunk. Table 8-4
summarizes the headings that precede each list and the reasons why a switch chooses to include or not include a
VLAN in each list. For instance, in Example 8-13, VLAN 60 has been shut down, and VLAN 59 happens to be in
Technet24
||||||||||||||||||||
an STP blocking state. (Chapter 9, “Spanning Tree Protocol Concepts,” has more information about STP.)
Table 8-4 VLAN Lists in the show interfaces trunk Command

List Heading Reasons
Position
First VLANs allowed VLANs 1–4094, minus those removed by the switchport trunk
allowed command
Second VLANs allowed The first list, minus VLANs not defined to the local switch (that is, there is not a vlan
and active… global configuration command or the switch has not learned of the VLAN with
VTP), and also minus those VLANs in shutdown mode
Third VLANs in
interface,
spanning tree… The second list,and minus
minus VLANs
VLANs VTP
in an pruned
STP fromstate
blocking that for
trunk
that
NOTE The companion website includes a video from the CCNA Exam Prep LiveLessons product, named
“Troubleshooting VLANs Allowed on a Trunk #1,” which works through the three lists of VLANs in the output of the show
interfaces interface-id trunk command in more detail.
Mismatched Native VLAN on a Trunk

Unfortunately, it is possible to set the native VLAN ID to different VLANs on either end of the trunk, using the switchport 8
trunk native vlan vlan-id command. If the native VLANs differ according to the two neighboring switches, the
switches will cause frames sent in the native VLAN to jump from one VLAN to the other.
For example, if switch SW1 sends a frame using native VLAN 1 on an 802.1Q trunk, SW1 does not add a VLAN
header, as is normal for the native VLAN. When switch SW2 receives the frame, noticing that no 802.1Q header
exists, SW2 assumes that the frame is part of SW2’s configured native VLAN. If SW2 has been configured to think
VLAN 2 is the native VLAN on that trunk, SW2 will try to forward the received frame into VLAN 2. (This effect of a
frame being sent in one VLAN but then being believed to be in a different VLAN is called VLAN hopping.)
Chapter Review
Review this chapter’s material using either the tools in the book or the interactive tools for the same material found on
the book’s companion website. Table 8-5 outlines the key review elements and where you can find them. To better
track your study progress, record when you completed these activities in the second column.
||||||||||||||||||||
Table 8-5 Chapter Review Tracking

Review Element Review Date(s) Resource Used
Review key topics Book, website
Review key terms Book, website
Answer DIKTA questions Book, PTP
Review config checklists Book, website
Review command tables Book
Review memory tables Website
Do labs Sim Lite, blog
Watch video Website
Review All the Key Topics

Table 8-6 Key Topics for Chapter 8
Key Topic Description Page
Element Number
Figure 8-2 Basic VLAN concept 179
List Reasons for using VLANs 180
Figure 8-5 Diagram of VLAN trunking 182
Figure 8-6 802.1Q header 183
Table 8-2 Options of the switchport mode command 191
Table 8-3 Expected trunking results based on the configuration of the 195
switchport mode command
List Definitions of data VLAN and voice VLAN 197
List Summary of data and voice VLAN concepts, configuration, and verification 200
Table 8-4 Analysis of the three VLAN lists in the output from the show interfaces interface-id 205
trunk command
Key Terms You Should Know

802.1Q, trunk, trunking administrative mode, trunking operational mode, VLAN, VTP, VTP transparent mode,
Layer 3 switch, access interface, trunk interface, data VLAN, voice VLAN, native VLAN, default VLAN, static
access interface
Technet24
||||||||||||||||||||
Do Labs
The Sim Lite software is a version of Pearson’s full simulator learning product with a subset of the labs, included
free with this book. The Sim Lite with this book includes a couple of labs about VLANs. Also, check the author’s
blog site pages for configuration exercises (Config Labs) at https://blog.certskills.com.
Command References
Tables 8-7 and 8-8 list configuration and verification commands used in this chapter, respectively. As an easy
review exercise, cover the left column in a table, read the right column, and try to recall the command without
looking. Then repeat the exercise, covering the right column, and try to recall what the command does.
Table 8-7 Chapter 8 Configuration Command Reference

Command Description
vlan vlan-id Global config command that both creates the VLAN and puts the CLI
into VLAN configuration mode
name vlan-name VLAN subcommand that names the VLAN
[ no] shutdown VLAN mode subcommand that enables ( no shutdown)

or disables ( shutdown) the VLAN
[ no] shutdown vlan vlan-id Global config command that has the same effect as the [ no]
shutdown VLAN mode subcommands
vtp mode {server | client | Global config command that defines the VTP mode
transparent | off} 8
Interface subcommand that configures the trunking

switchport mode {access | dynamic {auto | desirable}
| trunk} administrative mode on the interface
switchport access vlan vlan-id Interface subcommand that statically configures the interface into
that one VLAN
switchport trunk encapsulation Interface subcommand that defines which type of trunking to use,
{ dot1q | isl | negotiate} assuming that trunking is configured or negotiated
switchport trunk native vlan vlan- id Interface subcommand that defines the native VLAN for a trunk port
switchport nonegotiate Interface subcommand that disables the negotiation of VLAN

trunking
switchport voice vlan vlan-id Interface subcommand that defines the voice VLAN on a port,
meaning that the switch uses 802.1Q tagging for frames in this VLAN
switchport trunk allowed vlan Interface subcommand that defines the list of allowed VLANs
{ add | all | except | remove} vlan- list
||||||||||||||||||||
Table 8-8 Chapter 8 EXEC Command Reference

Command Description
show interfaces interface-id Lists information about any interface regarding

switchport administrative settings and operational state
show interfaces interface-id trunk Lists information about all operational trunks (but no
other interfaces), including the list of VLANs that can be forwarded
over the trunk
show vlan [brief | id vlan-id | name Lists information about the VLAN
vlan-name | summary]
show vlan [ vlan] Displays VLAN information
show vtp status Lists VTP configuration and status information
Technet24
||||||||||||||||||||
This page intentionally left blank

||||||||||||||||||||
CHAPTER 9
Spanning Tree Protocol Concepts

This chapter covers the following exam topics:
2.0 Network Access
2.4 Configure and verify (Layer 2/Layer 3) EtherChannel (LACP)
2.5 Describe the need for and basic operations of Rapid PVST+ Spanning Tree Protocol and identify basic
operations
2.5.a Root port, root bridge (primary/secondary), and other port names
2.5.b Port states (forwarding/blocking)
2.5.c PortFast benefits
Spanning Tree Protocol (STP) allows Ethernet LANs to have the added benefits of installing redundant links in a
LAN, while overcoming the known problems that occur when adding those extra links. Using redundant links in a
LAN design allows the LAN to keep working even when some links fail or even when some entire switches fail.
Proper LAN design should add enough redundancy so that no single point of failure crashes the LAN; STP allows
the design to use redundancy without causing some other problems.
Historically, the IEEE first standardized STP as part of the IEEE 802.1D standard back in
1990, with pre-standard versions working even before that time. Over time, the industry and IEEE improved STP, with
the eventual replacement of STP with an improved protocol: Rapid Spanning Tree Protocol (RSTP). The IEEE first
released RSTP as amendment 802.1w and, in
2004, integrated RSTP into the 802.1D standard.
An argument could be made to ignore STP today and instead focus solely on RSTP. Most modern networks use
RSTP instead of STP. The most recent models and IOS versions of Cisco switches default to use RSTP instead of
STP. Plus, the CCNA 200-301 exam topics mention RSTP by name, but not STP. However, STP and RSTP share
many of the same mechanisms, and RSTP’s improvements can be best understood in comparison to STP. For that
reason, this chapter presents some details that apply only to STP, as a learning tool to help you understand RSTP.
This chapter organizes the material into three sections. The first section presents some core concepts about how both
STP and RSTP discover a tree made of nodes (switches) and links so that no loops exist in a network. The second
section then takes a brief look at the area for which STP differs the most from RSTP: in how STP reacts to changes in
the network. This chapter ends with a third major section that details RSTP, including how RSTP works much better
that STP when reacting to changes.
“Do I Know This Already?” Quiz

Take the quiz (either here or use the PTP software) if you want to use the score to help you decide how much time
to spend on this chapter. The letter answers are listed at the bottom
Technet24
||||||||||||||||||||
of the page following the quiz. Appendix C, found both at the end of the book as well as on the companion website,
includes both the answers and explanations. You can also find both answers and explanations in the PTP testing
software.
Table 9-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping
Foundation Topics Section Questions
STP and RSTP Basics 1–2
Details Specific to STP (and Not RSTP) 3–4
Rapid STP Concepts 5–7
1. Which of the following port states are stable states used when STP has completed con-
vergence? (Choose two answers.)
a. Blocking
b. Forwarding
c. Listening
d. Learning
e. Discarding
2. Which of the following bridge IDs wins election as root, assuming that the switches
with these bridge IDs are in the same network?
a. 32769:0200.1111.1111
b. 32769:0200.2222.2222
c. 4097:0200.1111.1111
d. 4097:0200.2222.2222
e. 40961:0200.1111.1111
3. Which of the following are transitory port states used only during the process of STP
convergence? (Choose two answers.)
a. Blocking
b. Forwarding
c. Listening
d. Learning
e. Discarding
4. Which of the following facts determines how often a nonroot bridge or switch sends
an STP Hello BPDU message?
a. The Hello timer as configured on that switch.
b. The Hello timer as configured on the root switch.
c. It is always every 2 seconds.
d. The switch reacts to BPDUs received from the root switch by sending another
BPDU 2 seconds after receiving the root BPDU.
||||||||||||||||||||
5. Which of the following RSTP port states have the same name and purpose as a port
state in traditional STP? (Choose two answers.)
a. Blocking
b. Forwarding
c. Listening
d. Learning
e. Discarding
6. RSTP adds features beyond STP that enable ports to be used for a role if another port
on the same switch fails. Which of the following statements correctly describe a port role that is waiting to
take over for another port role? (Choose two answers.)
a. An alternate port waits to become a root port.
b. A backup port waits to become a root port.
c. An alternate port waits to become a designated port.
d. A backup port waits to become a designated port.
7. What STP feature causes an interface to be placed in the forwarding state as soon as
the interface is physically active?
a. STP
b. EtherChannel
c. Root Guard
d. PortFast
Foundation Topics
STP and RSTP Basics

Without some mechanism like Spanning Tree Protocol (STP) or Rapid STP (RSTP), a LAN with redundant links
would cause Ethernet frames to loop for an indefinite period of time. With STP or RSTP enabled, some switches
block ports so that these ports do not forward frames. STP and RSTP intelligently choose which ports block, with
two goals in mind:
■ All devices in a VLAN can send frames to all other devices. In other words, STP or RSTP does not block too
many ports, cutting off some parts of the LAN from other parts.
■ Frames have a short life and do not loop around the network indefinitely. STP and RSTP strike a balance,
allowing frames to be delivered to each device, without causing the problems that occur when frames loop through
the network over and over again.
NOTE This first major section of the chapter explains details of both STP and RSTP, so this section uses the term STP/RSTP
to refer to these protocols together. Note that this term is just a convenient shorthand. Later in the chapter, the text
will point out differences between STP and RSTP and begin using the terms STP and RSTP separately, referring to
only the specific protocol.
Technet24
||||||||||||||||||||
Chapter 9: Spanning Tree Protocol Concepts 213
STP/RSTP prevents looping frames by adding an additional check on each interface before a switch uses it to send or
receive user traffic. That check: If the port is in STP/RSTP forwarding state in that VLAN, use it as normal; if it is in
STP/RSTP blocking state, however, block all user traffic and do not send or receive user traffic on that interface in that
VLAN. Note that these STP/RSTP states do not change the other information you already know about switch
interfaces. The interface’s state of connected/notconnect does not change. The interface’s operational state as either
an access or trunk port does not change. STP/RSTP adds this additional state, with the blocking state basically
disabling the interface. In many ways, those last two paragraphs sum up what STP/RSTP does. However, the details
of how STP/RSTP does its work can take a fair amount of study and practice. This first major section of the chapter
begins by explaining the need for STP/RSTP and the basic ideas of what STP/RSTP does to solve the problem of
looping frames. The majority of this section then looks at how STP/RSTP goes about choosing which switch ports to
block to accomplish its goals.
The Need for Spanning Tree

STP/RSTP prevents three common problems in Ethernet LANs. All three problems occur as a side effect of one fact:
without STP/RSTP, some Ethernet frames would loop around the network for a long time (hours, days, literally forever
if the LAN devices and links never failed). Just one looping frame causes what is called a broadcast storm. Broadcast
storms happen when any kind of Ethernet frames—broadcast frames, multicast frames, or unknown-destination unicast
frames—loop around a LAN indefinitely. Broadcast storms can saturate all the links with copies of that one single
frame, crowding out good frames, as well as significantly impacting end-user device performance by making the PCs
process too many broadcast frames. To help you understand how this occurs, Figure 9-1 shows a sample network in
which Bob sends a broadcast frame. The dashed lines show how the switches forward the frame when STP/RSTP
does not exist.
9
Larry Archie
Fa0/11 Gi0/1 Gi0/2 Fa0/12
SW1 SW2
Gi0/2 Gi0/1
Gi0/1
Gi0/2
SW3
Fa0/13
0200.3333.3333 Bob
Figure 9-1 Broadcast Storm

||||||||||||||||||||
NOTE Bob’s original broadcast would also be forwarded around the other direction, with SW3 sending a copy of
the original frame out its Gi0/1 port. To reduce clutter, Figure 9-1 does not show that frame.
Remember that LAN switch? That logic tells switches to flood broadcasts out all interfaces in the same VLAN
except the interface in which the frame arrived. In Figure 9-1, that means SW3 forwards Bob’s frame to SW2, SW2
forwards the frame to SW1, SW1 forwards the frame back to SW3, and SW3 forwards it back to SW2 again.
When broadcast storms happen, frames like the one in Figure 9-1 keep looping until something
changes—someone shuts down an interface, reloads a switch, or does something else to break the loop. Also
note that the same event happens in the opposite direction. When Bob sends the original frame, SW3 also
forwards a copy to SW1, SW1 forwards it to SW2, and so on.
The storm also causes a much more subtle problem called MAC table instability. MAC table instability means that
the switches’ MAC address tables keep changing because frames with the same source MAC arrive on different
ports. To see why, follow this example, in which SW3 begins Figure 9-1 with a MAC table entry for Bob, at the
bottom of the figure, associated with port Fa0/13:
0200.3333.3333 Fa0/13 VLAN 1
However, now think about the switch-learning process that occurs when the looping frame goes to SW2, then SW1,
and then back into SW3’s Gi0/1 interface. SW3 thinks, “Hmm…the source MAC address is 0200.3333.3333, and it
came in my Gi0/1 interface. Update my MAC table!” This results in the following entry on SW3, with interface Gi0/1
instead of Fa0/13:
0200.3333.3333 Gi0/1 VLAN 1
At this point, SW3 itself cannot correctly deliver frames to Bob’s MAC address. At that instant, if a frame arrives at
SW3 destined for Bob—a different frame than the looping frame that causes the problems—SW3 incorrectly
forwards the frame out Gi0/1 to SW1, creating even more congestion.
The looping frames in a broadcast storm also cause a third problem: multiple copies of the frame arrive at the
destination. Consider a case in which Bob sends a frame to Larry but none of the switches know Larry’s MAC
address. Switches flood frames sent to unknown destination unicast MAC addresses. When Bob sends the frame
destined for Larry’s MAC address, SW3 sends a copy to both SW1 and SW2. SW1 and SW2 also flood the frame,
causing copies of the frame to loop. SW1 also sends a copy of each frame out Fa0/11 to Larry. As a result, Larry
gets multiple copies of the frame, which may result in an application failure, if not more pervasive networking
problems.
Table 9-2 summarizes the main three classes of problems that occur when STP/RSTP is not used in a LAN that has
redundancy.
Answers to the “Do I Know This Already?” quiz:
1 A, B 2 C 3 C, D 4 B 5 B, D 6 A, D 7 D
Technet24
||||||||||||||||||||
Table 9-2 Three Classes of Problems Caused by Not Using STP in Redundant LANs
Problem Description
Broadcast storms The forwarding of a frame repeatedly on the same links, consuming significant parts
of the links’ capacities
MAC table instability The continual updating of a switch’s MAC address table with
incorrect entries, in reaction to looping frames, resulting in frames being sent to the
wrong locations
Multiple frame A side effect of looping frames in which multiple copies of one frame are delivered to
transmission the intended host, confusing the host
What Spanning Tree Does

STP/RSTP prevents loops by placing each switch port in either a forwarding state or a blocking state. Interfaces in the
forwarding state act as normal, forwarding and receiving frames. However, interfaces in a blocking state do not
process any frames except STP/RSTP messages (and some other overhead messages). Interfaces that block do not
forward user frames, do not learn MAC addresses of received frames, and do not process received user frames.
Figure 9-2 shows a simple STP/RSTP tree that solves the problem shown in Figure 9-1 by placing one port on SW3 in
the blocking state.
Larry Archie
Fa0/11 Gi0/1 Gi0/2 Fa0/12
SW1 SW2
3 Gi0/2 3 Gi0/1 4
5
2
BLOCK
Gi0/1
Gi0/2
SW3
Fa0/13
1
0200.3333.3333 Bob
Figure 9-2 What STP/RSTP Does: Blocks a Port to Break the Loop
Now when Bob sends a broadcast frame, the frame does not loop. As shown in the steps in the figure:
Step 1. Bob sends the frame to SW3.
Step 2. SW3 forwards the frame only to SW1, but not out Gi0/2 to SW2, because SW3’s Gi0/2
interface is in a blocking state.
||||||||||||||||||||
Step 3. SW1 floods the frame out both Fa0/11 and Gi0/1.
Step 4. SW2 floods the frame out Fa0/12 and Gi0/1.
Step 5. SW3 physically receives the frame, but it ignores the frame received from SW2 because SW3’s
Gi0/2 interface is in a blocking state.
With the STP/RSTP topology in Figure 9-2, the switches simply do not use the link between SW2 and SW3 for
traffic in this VLAN, which is the minor negative side effect of STP. However, if either of the other two links fails,
STP/RSTP converges so that SW3 forwards instead of blocks on its Gi0/2 interface.
NOTE The term STP convergence refers to the process by which the switches collectively realize that something
has changed in the LAN topology and determine whether they need to change which ports block and which ports
forward.
That completes the description of what STP/RSTP does, placing each port into either a forwarding or blocking
state. The more interesting question, and the one that takes a lot more work to understand, is how and why
STP/RSTP makes its choices. How does STP/RSTP manage to make switches block or forward on each interface?
And how does it converge to change state from blocking to forwarding to take advantage of redundant links in
response to network outages? The following pages answer these questions.
How Spanning Tree Works

The STP/RSTP algorithm creates a spanning tree of interfaces that forward frames. The tree structure of
forwarding interfaces creates a single path to and from each Ethernet link, just like you can trace a single path in a
living, growing tree from the base of the tree to each leaf.
NOTE STP was created before LAN switches even existed, using LAN bridges to connect LANs. Today, switches play
the same role as bridges, implementing STP/RSTP. However, many STP/RSTP terms still refer to bridge. For the
purposes of STP/RSTP and this chapter, consider the terms bridge and switch synonymous.
The process used by STP, sometimes called the spanning-tree algorithm ( STA), chooses the interfaces that should
be placed into a forwarding state. For any interfaces not chosen to be in a forwarding state, STP/RSTP places the
interfaces in blocking state. In other words, STP/RSTP simply picks which interfaces should forward, and any
interfaces left over go to a blocking state.
STP/RSTP uses three criteria to choose whether to put an interface in forwarding state:
■ STP/RSTP elects a root switch. STP puts all working interfaces on the root switch in forwarding state.
■ Each nonroot switch considers one of its ports to have the least administrative cost between itself and the
root switch. The cost is called that switch’s root cost. STP/RSTP
Technet24
||||||||||||||||||||
places its port that is part of the least root cost path, called that switch’s root port ( RP), in forwarding state.
■ Many switches can attach to the same Ethernet segment, but due to the fact that links connect two devices, a
link would have at most two switches. With two switches on a link, the switch with the lowest root cost, as
compared with the other switches attached to the same link, is placed in forwarding state. That switch is the
designated switch, and that switch’s interface, attached to that segment, is called the designated port ( DP).
NOTE The real reason the root switches place all working interfaces in a forwarding state (at step 1 in the list) is
that all its interfaces on the root switch will become DPs. However, it is easier to just remember that all the root
switches’ working interfaces will forward frames.
All other interfaces are placed in blocking state. Table 9-3 summarizes the reasons STP/RSTP places a port in
forwarding or blocking state.
Table 9-3 STP/RSTP: Reasons for Forwarding or Blocking

Characterization of Port STP State Description
All the root switch’s ports Forwarding The root switch is always the designated switch
on all connected segments.
Each nonroot switch’s root port Forwarding The port through which the switch has the least
cost to reach the root switch (lowest root cost).
Each LAN’s designated port Forwarding The switch forwarding the Hello on to the
segment, with the lowest root cost, is the designated
switch for that segment.
All other working ports Blocking The port is not used for forwarding user frames, nor are any
frames received on these interfaces considered for
forwarding. 9
NOTE STP/RSTP only considers working interfaces (those in a connected state). Failed interfaces (for example,
interfaces with no cable installed) or administratively shutdown interfaces are instead placed into an STP/RSTP disabled
state. So, this section uses the term
working ports to refer to interfaces that could forward frames if STP/RSTP placed the interface into a forwarding
state.
NOTE STP and RSTP do differ slightly in the use of the names of some states like blocking and disabled, with RSTP
using the status term discarding. However, those minor differences do not change the meaning of the discussions in
this first section of the chapter. The upcoming section titled “Comparing STP and RSTP” discusses these
differences, both important and minor.
||||||||||||||||||||
The STP Bridge ID and Hello BPDU

The STA begins with an election of one switch to be the root switch. To better understand this election process, you
need to understand the STP/RSTP messages sent between switches as well as the concept and format of the
identifier used to uniquely identify each switch. The STP/RSTP bridge ID ( BID) is an 8-byte value unique to each
switch. The bridge ID consists of a 2-byte priority field and a 6-byte system ID, with the system ID being based on a
universal (burned-in) MAC address in each switch. Using a burned-in MAC address ensures that each switch’s
bridge ID will be unique. STP/RSTP defines messages called bridge protocol data units ( BPDU), also called
configuration BPDUs, which switches use to exchange information with each other. The most common BPDU, called
a Hello BPDU, lists many details, including the sending switch’s BID. By listing its own unique BID, switches can tell
which switch sent which Hello BPDU. Table 9-4 lists some of the key information in the Hello BPDU.
Table 9-4 Fields in the STP Hello BPDU

Field Description
Root bridge ID The bridge ID of the switch the sender of this Hello currently believes to be the root
switch
Sender’s bridge ID The bridge ID of the switch sending this Hello BPDU Sender’s root cost
The STP/RSTP cost between this switch and the current root
Timer values on the root Includes the Hello timer, MaxAge timer, and forward delay timer
switch
For the time being, just keep the first three items from Table 9-4 in mind as the following sections work through the
three steps in how STP/RSTP chooses the interfaces to place into a forwarding state. Next, the text examines the
three main steps in the STP/RSTP process.
Electing the Root Switch

Switches elect a root switch based on the BIDs in the BPDUs. The root switch is the switch with the lowest numeric
value for the BID. Because the two-part BID starts with the priority value, essentially the switch with the lowest
priority becomes the root. For example, if one switch has priority 4096, and another switch has priority 8192, the
switch with priority 4096 wins, regardless of what MAC address was used to create the BID for each switch. If a tie
occurs based on the priority portion of the BID, the switch with the lowest MAC address portion of the BID is the root.
No other tiebreaker should be needed because switches use one of their own universal (burned-in) MAC addresses
as the second part of their BIDs. So if the priorities tie, and one switch uses a MAC address of 0200.0000.0000 as
part of the BID and the other uses 0811.1111.1111, the first switch (MAC 0200.0000.0000) becomes the root switch.
STP/RSTP elects a root switch in a manner not unlike a political election. The process begins with all switches
claiming to be the root by sending Hello BPDUs listing their own BID as the root BID. If a switch hears a Hello that
lists a better (lower) BID, that switch stops
Technet24
||||||||||||||||||||
advertising itself as root and starts forwarding the superior Hello. The Hello sent by the better switch lists the better
switch’s BID as the root. It works like a political race in which a less-popular candidate gives up and leaves the
race, throwing his support behind the more popular candidate. Eventually, everyone agrees which switch has the
best (lowest) BID, and everyone supports the elected switch—which is where the political race analogy falls apart.
NOTE A better Hello, meaning that the listed root’s BID is better (numerically lower), is called a superior Hello; a
worse Hello, meaning that the listed root’s BID is not as good (numerically higher), is called an inferior Hello.
Figure 9-3 shows the beginning of the root election process. In this case, SW1 has advertised itself as root, as have
SW2 and SW3. However, SW2 now believes that SW1 is a better root, so SW2 is now forwarding the Hello
originating at SW1. So, at this point, the figure shows SW1 is saying Hello, claiming to be root; SW2 agrees and is
forwarding SW1’s Hello that lists SW1 as root; but SW3 is still claiming to be best, sending its own Hello BPDUs,
listing SW3’s BID as the root.
Root Cost: 0
My BID: 32,769: 0200.0001.0001 Root BID:
32,769: 0200.0001.0001
Gi0/1
SW1
Gi0/2 Gi0/1 Gi0/2 SW2
Root Cost: 0 My BID: 32,769: 0200.0001.0001

Root BID: 32,769: 0200.0001.0001 Root Cost: 4
My BID: 32,769: 0200.0002.0002
Root BID: 32,769: 0200.0001.0001
9
Root Cost: 0 My BID: 32,769: 0200.0003.0003 Root
BID: 32,769: 0200.0003.0003 Gi0/1
Root Cost: 0
My BID: 32,769: 0200.0003.0003 Root BID:
Gi0/2 32,769: 0200.0003.0003
SW3
Figure 9-3 Beginnings of the Root Election Process
Two candidates still exist in Figure 9-3: SW1 and SW3. So, who wins? Well, from the BID, the lower-priority switch
wins; if a tie occurs, the lower MAC address wins. As shown in the figure, SW1 has a lower BID
(32769:0200.0001.0001) than SW3 (32769:0200.0003.0003), so SW1 wins, and SW3 now also believes that SW1 is
the better switch. Figure 9-4 shows the resulting Hello messages sent by the switches.
Summarizing, the root election happens through each switch claiming to be root, with the best switch being elected
based on the numerically lowest BID. Breaking down the BID into its components, the comparisons can be made as
■ The lowest priority
■ If that ties, the lowest switch MAC address

||||||||||||||||||||
Root Cost: 0
My BID: 32,769: 0200.0001.0001 Root BID:
32,769: 0200.0001.0001
1
Gi0/1
SW1
Gi0/2 Gi0/1 Gi0/2 SW2
Root Cost: 0
My BID: 32,769: 0200.0001.0001 Root BID: Root Cost: 4
32,769: 0200.0001.0001 My BID: 32,769: 0200.0002.0002
Root BID: 32,769: 0200.0001.0001
1
2
Root Cost: 5
Gi0/1 My BID: 32,769: 0200.0003.0003
Gi0/2 Root BID: 32,769: 0200.0001.0001
SW3
Figure 9-4 SW1 Wins the Election
Choosing Each Switch’s Root Port

The second part of the STP/RSTP process occurs when each nonroot switch chooses its one and only root port. A
switch’s RP is its interface through which it has the least STP/RSTP cost to reach the root switch (least root cost).
The idea of a switch’s cost to reach the root switch can be easily seen for humans. Just look at a network diagram
that shows the root switch, lists the STP/RSTP cost associated with each switch port, and identifies the nonroot
switch in question. Switches use a different process than looking at a network diagram, of course, but using a
diagram can make it easier to learn the idea.
Figure 9-5 shows just such a figure, with the same three switches shown in the last several figures. SW1 has
already won the election as root, and the figure considers the cost from SW3’s perspective. (Note that the figure
uses some nondefault cost settings.) SW3 has two possible physical paths to send frames to the root switch: the
direct path to the left and the indirect path to the right through switch SW2. The cost is the sum of the costs of all
the switch ports the frame would exit if it flowed over that path. (The calculation ignores the inbound ports.) As you
can see, the cost over the direct path out SW3’s G0/1 port has a total cost of 5, and the other path has a total
cost of 8. SW3 picks its G0/1 port as root port because it is the port that is part of the least-cost path to send
frames to the root switch.
Technet24
||||||||||||||||||||
Root
Cost 4
SW1
Gi0/2 SW2
Total Cost Total Cost

=5 Cost 5 Cost 4 =8
Gi0/1 Gi0/2
SW3
Figure 9-5 How a Human Might Calculate STP/RSTP Cost from SW3 to the Root (SW1)
Switches come to the same conclusion but using a different process. Instead, they add their local interface
STP/RSTP cost to the root cost listed in each received Hello BPDU. The STP/RSTP port cost is simply an integer
value assigned to each interface, per VLAN, for the purpose of providing an objective measurement that allows
STP/RSTP to choose which interfaces to add to the STP/RSTP topology. The switches also look at their neighbor’s
root cost, as announced in Hello BPDUs received from each neighbor.
Figure 9-6 shows an example of how switches calculate their best root cost and then choose their root port, using the
same topology and STP/RSTP costs as shown in Figure 9-5. STP/RSTP on SW3 calculates its cost to reach the root
over the two possible paths by adding the advertised cost (in Hello messages) to the interface costs listed in the
figure.
My Root Cost Out

Hello 9
G0/2 is 4
Root Cost = 0 0+4=4
Interface
Root
Cost = 4
SW1 Gi0/1 Gi0/2 SW2
Gi0/2 Gi0/1
Hello
Hello
Root Cost = 0
Root Cost = 4
Root Cost out G0/1 is 5 Root

Cost out G0/2 is 8
0+5=5 4+4=8
Interface
Interface
Cost = 5
Cost = 4
Gi0/1 Gi0/2
SW3
Figure 9-6 How STP/RSTP Actually Calculates the Cost from SW3 to the Root
||||||||||||||||||||
Focus on the process for a moment. The root switch sends Hellos, with a listed root cost of
0. The idea is that the root’s cost to reach itself is 0.
Next, look on the left of the figure. SW3 takes the received cost (0) from the Hello sent by SW1 and adds the
interface cost (5) of the interface on which that Hello was received. SW3 calculates that the cost to reach the root
switch, out that port (G0/1), is 5. On the right side, SW2 has realized its best cost to reach the root is cost 4. So,
when SW2 forwards the Hello toward SW3, SW2 lists a root cost 4. SW3’s STP/RSTP port cost on port G0/2 is 4,
so SW3 determines a total cost to reach root out its G0/2 port of 8. As a result of the process depicted in Figure 9-6,
SW3 chooses Gi0/1 as its RP because the cost to reach the root switch through that port (5) is lower than the other
alternative (Gi0/2, cost 8). Similarly, SW2 chooses Gi0/2 as its RP, with a cost of 4 (SW1’s advertised cost of 0 plus
SW2’s Gi0/2 interface cost of 4). Each switch places its root port into a forwarding state.
Switches need a tiebreaker to use in case the best root cost ties for two or more paths. If a tie occurs, the switch
applies these three tiebreakers to the paths that tie, in order, as follows:
1. Choose based on the lowest neighbor bridge ID.
2. Choose based on the lowest neighbor port priority.
3. Choose based on the lowest neighbor internal port number.
Choosing the Designated Port on Each LAN Segment

STP/RSTP’s final step to choose the STP/RSTP topology is to choose the designated port on each LAN segment.
The designated port (DP) on each LAN segment is the switch port that advertises the lowest-cost Hello onto a LAN
segment. When a nonroot switch forwards a Hello, the nonroot switch sets the root cost field in the Hello to that
switch’s cost to reach the root. In effect, the switch with the lower cost to reach the root, among all switches
connected to a segment, becomes the DP on that segment.
For example, earlier Figure 9-4 shows in bold text the parts of the Hello messages from both SW2 and SW3 that
determine the choice of DP on that segment. Note that both SW2 and SW3 list their respective cost to reach the root
switch (cost 4 on SW2 and cost 5 on SW3). SW2 lists the lower cost, so SW2’s Gi0/1 port is the designated port on
that LAN segment. All DPs are placed into a forwarding state; so in this case, SW2’s Gi0/1 interface will be in a
forwarding state.
If the advertised costs tie, the switches break the tie by choosing the switch with the lower BID. In this case, SW2
would also have won, with a BID of 32769:0200.0002.0002 versus SW3’s 32769:0200.0003.0003.
NOTE Two additional tiebreakers are needed in some cases, although these would be unlikely today. A single switch
can connect two or more interfaces to the same collision domain by connecting to a hub. In that case, the one switch
hears its own BPDUs. So, if a switch ties with itself, two additional tiebreakers are used: the lowest interface
STP/RSTP priority and, if that ties, the lowest internal interface number.
Technet24
||||||||||||||||||||
The only interface that does not have a reason to be in a forwarding state on the three switches in the examples
shown in Figures 9-3 through 9-6 is SW3’s Gi0/2 port. So, the STP/RSTP process is now complete. Table 9-5
outlines the state of each port and shows why it is in that state.
Table 9-5 State of Each Interface

Switch State Reason Why the Interface Is in Forwarding State
Interface
SW1, Gi0/1 Forwarding The interface is on the root switch, so it becomes the DP on that link. SW1, Gi0/2
Forwarding The interface is on the root switch, so it becomes the DP on that link. SW2, Gi0/2 Forwarding The root
port of SW2.
SW2, Gi0/1 Forwarding The designated port on the LAN segment to SW3. SW3, Gi0/1
Forwarding The root port of SW3.
SW3, Gi0/2 Blocking Not the root port and not the designated port.
Note that the examples in this section focus on the links between the switches, but switch ports connected to
endpoint devices should become DPs and settle into a forwarding state. Working through the logic, each switch will
forward BPDUs on each port as part of the process to determine the DP on that LAN. Endpoints should ignore those
messages because they do not run STP/RSTP, so the switch will win and become DP on every access port.
Configuring to Influence the STP Topology

STP/RSTP works by default on Cisco switches, so all the settings needed by a switch have a useful default. Switches
have a default BID, based on a default priority value and adding a universal MAC address that comes with the switch
hardware. Additionally, switch interfaces have default STP/RSTP costs based on the current operating speed of the
switch interfaces. Network engineers often want to change the STP/RSTP settings to then change the choices 9
STP/RSTP makes in a given LAN. Two main tools available to the engineer are to configure the bridge ID and to
change STP/RSTP port costs.
First, to change the BID, the engineer can set the priority used by the switch, while continuing to use the universal
MAC address as the final 48 bits of the BID. For instance, giving a switch the lowest priority value among all
switches will cause that switch to win the root election.
Port costs also have default values, per port, per VLAN. You can configure these port costs, which will in turn
impact many switch’s calculations of the root cost. For instance, to favor one link, give the ports on that link a lower
cost, or to avoid a link, give the ports a higher cost.
Of course, it helps to know the default cost values so you can then choose alternative values as needed. Table 9-6
lists the default port costs suggested by IEEE. IOS on Cisco switches has long used the default settings as defined
as far back as the 1998 version of the IEEE 802.1D standard. The latest IEEE standard to suggest RSTP default
costs (as of the
||||||||||||||||||||
publication of this book), the 2018 publication of the 802.1Q standard, suggests values that are more useful when
using links faster than 10 Gbps.
Table 9-6 Default Port Costs According to IEEE

Ethernet Speed IEEE Cost: 1998 (and Before) IEEE Cost: 2004 (and After)
10 Mbps 100 2,000,000
100 Mbps 19 200,000
1 Gbps 4 20,000
10 Gbps 2 2000
100 Gbps N/A 200
1 Tbps N/A 20
Of note in regards to these defaults, the cost defaults based on the operating speed of the link, not the maximum
speed. That is, if a 10/100/1000 port runs at 10 Mbps for some reason, its default STP cost on a Cisco switch is 100,
the default cost for an interface running at 10 Mbps. Also, if you prefer the defaults in the right-side column of Table
9-6, note that Cisco Catalyst switches can be configured to use those values as defaults with a single global
configuration command on each switch ( spanning-tree pathcost method long).
Details Specific to STP (and Not RSTP)

As promised in the introduction to this chapter, the first section showed features that apply to both STP and RSTP.
This next heading acts as the turning point, with the next several pages being about STP only. The upcoming
section titled “Rapid STP Concepts” then shows details specific to RSTP, in contrast to STP.
Once the engineer has finished all STP configuration, the STP topology should settle into a stable state and not
change, at least until the network topology changes. This section examines the ongoing operation of STP while the
network is stable, and then it covers how STP converges to a new topology when something changes.
Note that almost all the differences between STP and RSTP revolve around the activities of waiting for and reacting to
changes in the topology. STP performed well for the era and circumstances in which it was created. The “rapid” in
RSTP refers to the improvements to how fast RSTP could react when changes occur—so understanding how STP
reacts will be useful to understand why RSTP reacts faster. These next few pages show the specifics of STP (and not
RSTP) and how STP reacts to and manages convergence when changes happen in an Ethernet LAN.
STP Activity When the Network Remains Stable

An STP root switch sends a new Hello BPDU every 2 seconds by default. Each nonroot switch forwards the Hello
on all DPs, but only after changing items listed in the Hello. (As a result, the Hello flows once over every working
link in the LAN.)
Technet24
||||||||||||||||||||
When forwarding the Hello BPDU, each switch sets the root cost to that local switch’s calculated root cost. The
switch also sets the “sender’s bridge ID” field to its own bridge ID. (The root’s bridge ID field is not changed.)
Assuming a default Hello timer of 2 seconds on the root switch, each switch will forward the received (and
changed) Hellos out all DPs so that all switches continue to receive Hellos every 2 seconds. The following steps
summarize the steady-state operation when nothing is currently changing in the STP topology:
Step 1. The root creates and sends a Hello BPDU, with a root cost of 0, out all its working interfaces (those
in a forwarding state).
Step 2. The nonroot switches receive the Hello on their root ports. After changing the Hello to list their
own BID as the sender’s BID and listing that switch’s root cost, the switch forwards the Hello out
all designated ports.
Step 3. Steps 1 and 2 repeat until something changes.
When a switch fails to receive a Hello, it knows a problem might be occurring in the network. Each switch relies
on these periodically received Hellos from the root as a way to know that its path to the root is still working. When
a switch ceases to receive the Hellos, or receives a Hello that lists different details, something has failed, so the
switch reacts and starts the process of changing the spanning-tree topology.
STP Timers That Manage STP Convergence

For various reasons, the STP convergence process requires the use of three timers, listed in Table 9-7. Note that all
switches use the timers as dictated by the root switch, which the root lists in its periodic Hello BPDU messages.
Table 9-7 STP Timers

9
Timer Default Description
Value
Hello 2 seconds The time period between Hellos created by the root.
MaxAge 10 times How long any switch should wait, after ceasing to hear Hellos, before trying to
Hello change the STP topology.
Forward 15 seconds Delay that affects the process that occurs when an interface
delay changes from blocking state to forwarding state. A port stays in an interim listening
state, and then an interim learning state, for the number of seconds defined by the
forward delay timer.
If a switch does not get an expected Hello BPDU within the Hello time, the switch continues as normal. However, if
the Hellos do not show up again within MaxAge time, the switch reacts by taking steps to change the STP topology.
With default settings, MaxAge is 20 seconds (10 times the default Hello timer of 2 seconds). So, a switch would go
20 seconds without hearing a Hello before reacting.
||||||||||||||||||||
After MaxAge expires, the switch essentially makes all its STP choices again, based on any Hellos it receives from
other switches. It reevaluates which switch should be the root switch. If the local switch is not the root, it chooses its
RP. And it determines whether it is DP on each of its other links.
The best way to describe STP convergence is to show an example using the same familiar topology. Figure 9-7
shows the same familiar figure, with SW3’s Gi0/2 in a blocking state, but SW1’s Gi0/2 interface has just failed.
Hello
Root is SW1 I am
SW1
Root Cost = 0
Root
Larry DP DP RP DP Archie
Fa0/11 Gi0/1 Gi0/2 Fa0/12
SW1 SW2
Hello DP Gi0/2 DP Gi0/1
Root is SW1 I am Hello

SW1
Root is SW1 I am
Root Cost = 0
SW2
Root Cost = 4
RP Gi0/1
Gi0/2 Legend:
SW3 RP – Root Port

DP Fa0/13 DP – Designated Port
– Blocking Port
– Failing Link
Bob
Figure 9-7 Initial STP State Before SW1-SW3 Link Fails
In the scenario shown in the figure, SW3 reacts to the change because SW3 fails to receive its expected Hellos on
its Gi0/1 interface. However, SW2 does not need to react because SW2 continues to receive its periodic Hellos in its
Gi0/2 interface. In this case, SW3 reacts either when MaxAge time passes without hearing the Hellos, or as soon as
SW3 notices that interface Gi0/1 has failed. (If the interface fails, the switch can assume that the Hellos will not be
arriving in that interface anymore.)
Now that SW3 can act, it begins by reevaluating the choice of root switch. SW3 still receives the Hellos from SW2,
as forwarded from the root (SW1). SW1 still has a lower BID than SW3; otherwise, SW1 would not have already
been the root. So, SW3 decides that SW1 wins the root election and that SW3 is not the root.
Next, SW3 reevaluates its choice of RP. At this point, SW3 is receiving Hellos on only one interface: Gi0/2. Whatever
the calculated root cost, Gi0/2 becomes SW3’s new RP. (The cost would be 8, assuming the STP costs had no
changes since Figures 9-5 and 9-6.)
Technet24
||||||||||||||||||||
SW3 then reevaluates its role as DP on any other interfaces. In this example, no real work needs to be done.
SW3 was already DP on interface Fa0/13, and it continues to be the DP because no other switches connect to
that port.
Changing Interface States with STP

STP uses the idea of roles and states. Roles, like root port and designated port, relate to how STP analyzes the LAN
topology. States, like forwarding and blocking, tell a switch whether to send or receive frames. When STP converges,
a switch chooses new port roles, and the port roles determine the state (forwarding or blocking).
Switches using STP can simply move immediately from forwarding to blocking state, but they must take extra time
to transition from blocking state to forwarding state. For instance, when switch SW3 in Figure 9-7 formerly used port
G0/1 as its RP (a role), that port was in a forwarding state. After convergence, G0/1 might be neither an RP nor DP;
the switch can immediately move that port to a blocking state.
However, when a port that formerly blocked needs to transition to forwarding, the switch first puts the port
through two intermediate interface states. These temporary STP states help prevent temporary loops:
■ Listening: Like the blocking state, the interface does not forward frames. The switch removes old stale (unused)
MAC table entries for which no frames are received from each MAC address during this period. These stale MAC
table entries could be the cause of the temporary loops.
■ Learning: Interfaces in this state still do not forward frames, but the switch begins to learn the MAC
addresses of frames received on the interface.
STP moves an interface from blocking to listening, then to learning, and then to forwarding state. STP leaves the
interface in each interim state for a time equal to the forward delay timer, which defaults to 15 seconds. As a result, a
convergence event that causes an interface to change from blocking to forwarding requires 30 seconds to transition 9
from blocking to forwarding. In addition, a switch might have to wait MaxAge seconds (default 20 seconds) before
even choosing to move an interface from blocking to forwarding state. For example, follow what happens with an
initial STP topology as shown in Figures 9-3 through 9-6, with the SW1-to-SW3 link failing as shown in Figure 9-7. If
SW1 simply quit sending Hello messages to SW3, but the link between the two did not fail, SW3 would wait MaxAge
seconds before reacting (20 seconds is the default). SW3 would actually quickly choose its ports’ STP roles, but then
wait 15 seconds each in listening and learning states on interface Gi0/2, resulting in a 50-second convergence delay.
Table 9-8 summarizes spanning tree’s various interface states for easier review.
||||||||||||||||||||
Table 9-8 IEEE STP (Not RSTP) States

State Forwards Data Learns MACs Based on Transitory or
Frames? Received Frames? Stable State?
Blocking No No Stable
Listening No No Transitory
Learning No Yes Transitory
Forwarding Yes Yes Stable
Disabled No No Stable
Rapid STP Concepts

The original STP worked well given the assumptions about networks and networking devices in that era. However, as
with any computing or networking standard, as time passes, hardware and software capabilities improve, so new
protocols emerge to take advantage of those new capabilities. For STP, one of the most significant improvements
over time has been the introduction of Rapid Spanning Tree Protocol (RSTP), introduced as standard IEEE 802.1w.
NOTE Just to make sure you are clear about the terminology: Throughout the rest of the chapter, STP refers to the
original STP standard only, and use of the term RSTP does not include STP.
Before getting into the details of RSTP, it helps to make sense of the standards numbers a bit.
802.1w was actually an amendment to the 802.1D standard. The IEEE first published 802.1D in 1990, and anew in
1998. After the 1998 version of 802.1D, the IEEE published the 802.1w amendment to 802.1D in 2001, which first
standardized RSTP.
Over the years, other meaningful changes happened in the standards as well, although those changes probably do
not impact most networkers’ thinking when it comes to working with STP or RSTP. But to be complete, the IEEE
replaced STP with RSTP in the revised 802.1D standard in 2004. In another move, in 2011 the IEEE moved all the
RSTP details into a revised 802.1Q standard. As it stands today, RSTP actually sits in the 802.1Q standards
document.
As a result, when reading about RSTP, you will see documents, books, videos, and the like that refer to RSTP and
include various references to 802.1w, 802.1D, and 802.1Q—and they might all be correct based on timing and
context. At the same time, many people refer to RSTP as 802.1w because that was the first IEEE document to
define it. However, for the purposes of this book, focus instead on the RSTP acronym rather than the IEEE
standards numbers used with RSTP over its history.
NOTE The IEEE sells its standards, but through the “Get IEEE 802” program, you can get free PDFs of the current
802 standards. To read about RSTP today, you will need to download the 802.1Q standard, and then look for the
sections about RSTP.
Technet24
||||||||||||||||||||
Now on to the details about RSTP in this chapter. As discussed throughout this chapter, RSTP and STP have
many similarities, so this section next compares and contrasts the two. Following that, the rest of this section
discusses the concepts unique to RSTP that are not found in STP—alternate root ports, different port states,
backup ports, and the port roles used by RSTP.
Comparing STP and RSTP

RSTP works just like STP in several ways, as discussed in the first major section of the chapter. To review:
■ RSTP and STP elect the root switch using the same rules and tiebreakers.
■ RSTP and STP switches select their root ports with the same rules.
■ RSTP and STP elect designated ports on each LAN segment with the same rules and tiebreakers.
■ RSTP and STP place each port in either forwarding or blocking state, although RSTP calls the blocking state the discarding
state.
In fact, RSTP works so much like STP that they can both be used in the same network. RSTP and STP switches
can be deployed in the same network, with RSTP features working in switches that support it and traditional STP
features working in the switches that support only STP.
With all these similarities, you might be wondering why the IEEE bothered to create RSTP in the first place. The
overriding reason is convergence. STP takes a relatively long time to converge (50 seconds with the default
settings when all the wait times must be followed). RSTP improves network convergence when topology changes
occur, usually converging within a few seconds (or in slow conditions, in about 10 seconds).
RSTP changes and adds to STP in ways that avoid waiting on STP timers, resulting in quick transitions from
forwarding to discarding (blocking) state and vice versa. Specifically, RSTP, compared to STP, defines more cases 9
in which the switch can avoid waiting for a timer to expire, such as the following:
■ RSTP adds a mechanism by which a switch can replace its root port, without any waiting to reach a forwarding
state (in some conditions).
■ RSTP adds a new mechanism to replace a designated port, without any waiting to reach a forwarding state (in
some conditions).
■ RSTP lowers waiting times for cases in which RSTP must wait for a timer. For instance, imagine a failure case in
which a link remains up, but for some reason, a nonroot switch stops hearing the Hello BPDUs it had been hearing in
the past. STP requires a switch to wait for MaxAge seconds, which STP defines based on 10 times the Hello timer, or
20 seconds, by default. RSTP shortens this timer, defining MaxAge as three times the Hello timer. Additionally, RSTP
can send messages to the neighboring switch to inquire whether a problem has occurred rather than wait for timers.
The best way to get a sense for these mechanisms is to see how the RSTP alternate port and the backup port both
work. RSTP uses the term alternate port to refer to a switch’s other
||||||||||||||||||||
ports that could be used as the root port if the root port ever fails. The backup port concept provides a backup port on
the local switch for a designated port. (Note that backup ports apply only to designs that use hubs, so they are
unlikely to be useful today.) However, both are instructive about how RSTP works. Table 9-9 lists these RSTP port
roles.
Table 9-9 Port Roles in RSTP

Function Port Role
Port that begins a nonroot switch’s best path to the root Root port
Port that replaces the root port when the root port fails Alternate port
Switch port designated to forward onto a collision domain Designated port
Port that replaces a designated port when a designated port fails Backup port
Port that is administratively disabled Disabled port
RSTP differs from STP in a few other ways as well. For instance, with STP, the root switch creates a Hello with all
other switches, updating and forwarding the Hello. With RSTP, each switch independently generates its own
Hellos. Additionally, RSTP allows for queries between neighbors, rather than waiting on timers to expire, as a
means to avoid waiting to learn information. These types of protocol changes help RSTP-based switches isolate
what has changed in a network and react quickly to choose a net RSTP topology. The next few pages work
through some of those overt RSTP features that differ from STP.
RSTP and the Alternate (Root) Port Role

With STP, each nonroot switch places one port in the STP root port (RP) role. RSTP follows that same convention,
with the same exact rules for choosing the RP. RSTP then takes another step beyond STP, naming other possible
RPs, identifying them as alternate ports.
To be an alternate port, both the RP and the alternate port must receive Hellos that identify the same root switch.
For instance, in Figure 9-8, SW1 is the root. SW3 will receive Hello BPDUs on two ports: G0/1 and G0/2. Both
Hellos list SW1’s bridge ID (BID) as the root switch, so whichever port is not the root port meets the criteria to be an
alternate port. SW3 picks G0/1 as its root port in this case and then makes G0/2 an alternate port. An alternate port
basically works like the second-best option for the root port. The alternate port can take over for the former root
port, often very rapidly, without requiring a wait in other interim RSTP states. For instance, when the root port fails,
or when Hellos stop arriving on the original root port, the switch changes the former root port’s role and state: (a)
the role from root port to a disabled port, and (b) the state from forwarding to discarding (the equivalent of STP’s
blocking state). Then, without waiting on any timers, the switch changes roles and state for the alternate port: its
role changes to be the root port, with a forwarding state.
Notably, the new root port also does not need to spend time in other states, such as learning state, instead moving
immediately to forwarding state.
Technet24
||||||||||||||||||||
Root
DP RP
Gi0/1 Gi0/2
SW1 SW2
DP Gi0/2 DP Gi0/1
Root is SW1 I am Root is SW1 I am

SW1 SW2
Root Cost = 0 Root Cost = 4
Legend:
RP – Root Port
RP Gi0/1 ALT – Alternate Port
ALT
– Discarding State
Gi0/2
SW3 – Failing Link
Figure 9-8 Example of SW3 Making G0/2 Become an Alternate Port
Figure 9-9 shows an example of RSTP convergence. SW3’s root port before the failure shown in this figure is SW3’s
G0/1, the link connected directly to SW1 (the root switch). Then SW3’s link to SW1 fails as shown in Step 1 of the
figure.
Root
DP RP
Gi0/1 Gi0/2
SW1 SW2
DP Gi0/2 ALTALTDP Gi0/1
2
1 RSTP
9
4
Legend:
Immediate
Change to RP – Root Port
Gi0/1 3 Forwarding
ALT – Alternate Port
RP – Discarding State
Gi0/2
SW3 – Failing Link
Figure 9-9 Convergence Events with SW3 G0/1 Failure
Following the steps in Figure 9-9:
Step 1. The link between SW1 and SW3 fails, so SW3’s current root port (Gi0/1) fails.
Step 2. SW3 and SW2 exchange RSTP messages to confirm that SW3 will now transition its former
alternate port (Gi0/2) to be the root port. This action causes SW2 to flush the required MAC table
entries.
Step 3. SW3 transitions Gi0/1 to the disabled role and Gi0/2 to the root port role.
Step 4. SW3 transitions Gi0/2 to a forwarding state immediately, without using learning state, because this
is one case in which RSTP knows the transition will not create a loop.
||||||||||||||||||||
As soon as SW3 realizes its Gi0/1 interface has failed, the process shown in the figure takes very little time. None of
the processes rely on timers, so as soon as the work can be done, the convergence completes. (This particular
convergence example takes about 1 second in a lab.)
RSTP States and Processes

The depth of the previous example does not point out all details of RSTP, of course; however, the example does show
enough details to discuss RSTP states and internal processes. Both STP and RSTP use port states, but with some
differences. First, RSTP keeps both the learning and forwarding states as compared with STP, for the same purposes.
However, RSTP does not even define a listening state, finding it unnecessary. Finally, RSTP renames the blocking
state to the discarding state and redefines its use slightly. RSTP uses the discarding state for what STP defines as two
states: disabled state and blocking state. Blocking should be somewhat obvious by now: the interface can work
physically, but STP/RSTP chooses to not forward traffic to avoid loops. STP’s disabled state simply meant that the
interface was administratively disabled. RSTP just combines those into a single discarding state. Table 9-10 shows the
list of STP and RSTP states for comparison purposes.
Table 9-10 Port States Compared: STP and RSTP

Function STP State RSTP State
Port is administratively disabled Disabled Discarding
Stable state that ignores incoming data frames and is not used to forward data Blocking Discarding
frames
Interim state without MAC learning and without forwarding Listening Not used
Interim state with MAC learning and without forwarding Learning Learning
Stable state that allows MAC learning and forwarding of data frames Forwarding Forwarding
RSTP also changes some processes and message content (compared to STP) to speed convergence. For example,
STP waits for a time (forward delay) in both listening and learning states. The reason for this delay in STP is that, at
the same time, the switches have all been told to time out their MAC table entries. When the topology changes, the
existing MAC table entries may actually cause a loop. With STP, the switches all tell each other (with BPDU
messages) that the topology has changed and to time out any MAC table entries using the forward delay timer. This
removes the entries, which is good, but it causes the need to wait in both listening and learning state for forward
delay time (default 15 seconds each). RSTP, to converge more quickly, avoids relying on timers. RSTP switches tell
each other (using messages) that the topology has changed. Those messages also direct neighboring switches to
flush the contents of their MAC tables in a way that removes all the potentially loop-causing entries, without a wait. As
a result, RSTP creates more scenarios in which a formerly discarding port can immediately transition to a forwarding
state, without waiting, and without using the learning state, as shown in the example in Figure 9-9.
Technet24
||||||||||||||||||||
RSTP and the Backup (Designated) Port Role

The RSTP backup port role acts as yet another new RSTP port role as compared to STP. As a reminder, the RSTP
alternate port role creates a way for RSTP to quickly replace a switch’s root port. Similarly, the RSTP backup port
role creates a way for RSTP to quickly replace a switch’s designated port on some LAN.
The need for a backup port can be a bit confusing at first because the need for the backup port role only happens
in designs that are a little unlikely today. The reason is that a design must use hubs, which then allows the
possibility that one switch connects more than one port to the same collision domain.
Figure 9-10 shows an example. SW3 and SW4 both connect to the same hub. SW4’s port F0/1 happens to win the
election as designated port (DP). The other port on SW4 that connects to the same collision domain, F0/2, acts as
a backup port.
SW1 SW2
SW3 SW4
F0/4 F0/1 F0/2
DP Backup
Hub
Figure 9-10 RSTP Backup Port Example
With a backup port, if the current designated port fails, SW4 can start using the backup port with rapid
9
convergence. For instance, if SW4’s F0/1 interface were to fail, SW4 could transition F0/2 to the designated
port role, without any delay in moving from discarding state to a forwarding state.
RSTP Port Types

The final RSTP concept included here relates to some terms RSTP uses to refer to different types of ports and the
links that connect to those ports.
To begin, consider the basic image in Figure 9-11. It shows several links between two switches. RSTP considers
these links to be point-to-point links and the ports connected to them to be point-to-point ports because the link
connects exactly two devices (points). RSTP further classifies point-to-point ports into two categories.
Point-to-point ports that connect two switches are not at the edge of the network and are simply called point-topoint
ports. Ports that instead connect to a single endpoint device at the edge of the network, like a PC or server, are
called point-to-point edge ports, or simply edge ports. In Figure 9-11, SW3’s switch port connected to a PC is an
edge port.
||||||||||||||||||||
Point-to-point Point-to-point
Port Port
SW1 SW2
SW3 SW4
Point-to-point Shared
Edge Port Port
Hub
Figure 9-11 RSTP Link Types
Finally, RSTP defines the term shared to describe ports connected to a hub. The term
shared comes from the fact that hubs create a shared Ethernet; hubs also force the attached switch port to use
half-duplex logic. RSTP assumes that all half-duplex ports may be connected to hubs, treating ports that use half
duplex as shared ports. RSTP converges more slowly on shared ports as compared to all point-to-point ports.
Optional STP Features

To close out the chapter, the last few topics introduce a few optional features that make STP work even better or be
more secure: EtherChannel, PortFast, and BPDU Guard.
EtherChannel
One of the best ways to lower STP’s convergence time is to avoid convergence altogether. EtherChannel provides
a way to prevent STP convergence from being needed when only a single port or cable failure occurs.
EtherChannel combines multiple parallel segments of equal speed (up to eight) between the same pair of switches,
bundled into an EtherChannel. The switches treat the EtherChannel as a single interface with regard to STP. As a
result, if one of the links fails, but at least one of the links is up, STP convergence does not have to occur. For
example, Figure 9-12 shows the familiar three-switch network, but now with two Gigabit Ethernet connections
between each pair of switches.
With each pair of Ethernet links configured as an EtherChannel, STP treats each EtherChannel as a single link. In
other words, both links to the same switch must fail for a switch to need to cause STP convergence. Without
EtherChannel, if you have multiple parallel links between two switches, STP blocks all the links except one. With
EtherChannel, all the parallel links can be up and working at the same time, while reducing the number of times
STP must converge, which in turn makes the network more available.
Technet24
||||||||||||||||||||
Larry Archie
SW1 SW2
SW3
Bob
Figure 9-12 Two-Segment EtherChannels Between Switches
The current CCNA exam blueprint includes a topic for the configuration of both Layer 2 EtherChannels (as described
here) as well as Layer 3 EtherChannels. Chapter 10, “RSTP and EtherChannel Configuration,” shows how to
configure Layer 2 EtherChannels, while Chapter
17, “IP Routing in the LAN,” shows how to configure Layer 3 EtherChannels. Note that Layer 2 EtherChannels
combine links that switches use as switch ports, with the switches using Layer 2 switching logic to forward and
receive Ethernet frames over the EtherChannels. Layer 3 EtherChannels also combine links, but the switches use
Layer 3 routing logic to forward packets over the EtherChannels.
PortFast
PortFast allows a switch to immediately transition from blocking to forwarding, bypassing listening and learning
states. However, the only ports on which you can safely enable PortFast are ports on which you know that no
bridges, switches, or other STP-speaking devices are connected. Otherwise, using PortFast risks creating loops, the
very thing that the listening and learning states are intended to avoid.
9
PortFast is most appropriate for connections to end-user devices. If you turn on PortFast on ports connected to
end-user devices, when an end-user PC boots, the switch port can move to an STP forwarding state and forward
traffic as soon as the PC NIC is active. Without PortFast, each port must wait while the switch confirms that the port
is a DP. With STP in particular (and not RSTP), the switch waits in the temporary listening and learning states
before settling into the forwarding state.
As you might guess from the fact that PortFast speeds convergence, RSTP includes PortFast. You might recall the
mention of RSTP port types, particularly point-to-point edge port types, around Figure 9-11. RSTP, by design of the
protocol, converges quickly on these point-to-point edge type ports by bypassing the learning state, which is the
same idea Cisco originally introduced with PortFast. In practice, Cisco switches enable RSTP point-to-point edge
ports by enabling PortFast on the port.
||||||||||||||||||||
BPDU Guard
STP and RSTP open up the LAN to several different types of possible security exposures. For example:
■ An attacker could connect a switch to one of these ports, one with a low STP/RSTP priority value, and become
the root switch. The new STP/RSTP topology could have worse performance than the desired topology.
■ The attacker could plug into multiple ports, into multiple switches, become root, and actually forward much of
the traffic in the LAN. Without the networking staff realizing it, the attacker could use a LAN analyzer to copy
large numbers of data frames sent through the LAN.
■ Users could innocently harm the LAN when they buy and connect an inexpensive consumer LAN switch (one
that does not use STP/RSTP). Such a switch, without any STP/RSTP function, would not choose to block any
ports and could cause a loop. The Cisco BPDU Guard feature helps defeat these kinds of problems by disabling a
port if any BPDUs are received on the port. So, this feature is particularly useful on ports that should be used only
as an access port and never connected to another switch. In addition, the BPDU Guard feature helps prevent
problems with PortFast. PortFast should be enabled only on access ports that connect to user devices, not to other
LAN switches. Using BPDU Guard on these same ports makes sense because if another switch connects to such
a port, the local switch can disable the port before a loop is created.
Chapter Review
One key to doing well on the exams is to perform repetitive spaced review sessions. Review this chapter’s material
using either the tools in the book or interactive tools for the same material found on the book’s companion website.
Refer to the “Your Study Plan” element for more details. Table 9-11 outlines the key review elements and where you
can find them. To better track your study progress, record when you completed these activities in the second
column.
Table 9-11 Chapter Review Tracking

Review Element Review Date(s) Resource Used
Review key topics Book, website
Review key terms Book, website
Answer DIKTA questions Book, PTP
Review memory tables Website
Technet24
||||||||||||||||||||
Review All the Key Topics

Table 9-12 Key Topics for Chapter 9
Key Topic Description Page
Element Number
Table 9-2 Lists the three main problems that occur when not using STP 215
in a LAN with redundant links
Table 9-3 Lists the reasons why a switch chooses to place an interface 217
into forwarding or blocking state
Table 9-4 Lists the most important fields in Hello BPDU messages 218
List Logic for the root switch election 219
Figure 9-6 Shows how switches calculate their root cost 221
Table 9-6 Lists the original and current default STP port costs for 224
various interface speeds
Step list A summary description of steady-state STP operations 225
Table 9-7 STP timers 226
List Definitions of what occurs in the listening and learning states 227
Table 9-8 Summary of 802.1D states 228
List Key similarities between 802.1D STP and 802.1w RSTP 229
List Methods RSTP uses to reduce convergence time 229
Table 9-9 List of 802.1w port roles 230
Table 9-10 Comparisons of port states with 802.1D and 802.1w 232
Key Terms You Should Know

blocking state, BPDU Guard, bridge ID, bridge protocol data unit (BPDU), designated port, EtherChannel, forward
delay, forwarding state, Hello BPDU, learning state, listening state, MaxAge, PortFast, root port, root switch, root
cost, Spanning Tree Protocol (STP), rapid STP (RSTP), alternate port, backup port, disabled port, discarding state
||||||||||||||||||||
CHAPTER 10
RSTP and EtherChannel

Configuration
This chapter covers the following exam topics:
2.0 Network Access
2.4 Configure and verify (Layer 2/Layer 3) EtherChannel (LACP)
2.5 Describe the need for and basic operations of Rapid PVST+ Spanning Tree Protocol and identify basic
operations
2.5.a Root port, root bridge (primary/secondary), and other port names
2.5.b Port states (forwarding/blocking)
2.5.c PortFast benefits
This chapter shows how to configure Rapid Spanning Tree Protocol (RSTP) and Layer 2 EtherChannels. The
EtherChannel content, in the second major section of the chapter, follows a typical flow for most
configuration/verification topics in a certification guide: it reviews concepts, shows configurations, and provides show
commands that point out the configuration settings and operational state. The details include how to manually
configure a channel, how to cause a switch to dynamically create a channel, and how EtherChannel load distribution
works. The first section of the chapter explores RSTP implementation taking a different approach. Cisco mentions
RSTP concepts, but not configuration/verification, in the CCNA exam topics. However, to get a real sense of RSTP
concepts, especially some concepts specific to Cisco Catalyst switches, you need to work with RSTP configuration
and verification. The first section of the chapter explores RSTP implementation, but as a means to the end of more
fully understanding RSTP concepts.
For those of you who, like me, probably would want to go ahead and practice configuring RSTP, do some show
commands, and understand more fully, you do have some options:
■ Read Appendix O, “Spanning Tree Protocol Implementation,” from this book’s companion website. The
appendix is a chapter from the previous edition of this book, with full details of configuration/verification of
STP and RSTP.
■ Use the STP/RSTP config labs on my blog site (as regularly listed in the Chapter Review section of each
chapter).
“Do I Know This Already?” Quiz

Take the quiz (either here or use the PTP software) if you want to use the score to help you decide how much time
to spend on this chapter. The letter answers are listed at the bottom of the page following the quiz. Appendix C,
found both at the end of the book as well as on the companion website, includes both the answers and
explanations. You can also find both answers and explanations in the PTP testing software.
Technet24
||||||||||||||||||||
Table 10-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping
Foundation Topics Section Questions
Understanding RSTP Through Configuration 1–3
Implementing EtherChannel 4–6
1. Which type value on the spanning-tree mode type global command enables the use
of RSTP?
a. rapid-pvst
b. pvst
c. rstp
d. rpvst
2. Examine the following output from the show spanning-tree vlan 5 command, which
describes a root switch in a LAN. Which answers accurately describe facts related to the root’s bridge ID?
SW1# show spanning-tree vlan 5
VLAN0005
Spanning tree enabled protocol rstp Root ID Priority
32773
Address 1833.9d7b.0e80
Cost 15
Port 25 (GigabitEthernet0/1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
a. The system ID extension value, in decimal, is 5.
b. The root’s configured priority value is 32773.
c. The root’s configured priority value is 32768.
d. The system ID extension value, in hexadecimal, is 1833.9d7b.0e80.
3. With the Cisco RPVST+, which of the following action(s) does a switch take to iden-
tify which VLAN is described by a BPDU? (Choose three answers.)
a. Adds a VLAN tag when forwarding a BPDU on trunks
b. Adds the VLAN ID in an extra TLV in the BPDU
c. Lists the VLAN ID as the middle 12 bits of the System ID field of the BPDU
d. Lists the VLAN ID in the System ID Extension field of the BPDU

||||||||||||||||||||
4. An engineer configures a switch to put interfaces G0/1 and G0/2 into the same Layer 2
EtherChannel. Which of the following terms is used in the configuration commands?
a. EtherChannel
b. PortChannel
c. Ethernet-Channel
d. Channel-group
5. Which combinations of keywords on the channel-group interface subcommand on

two neighboring switches will cause the switches to use LACP and attempt to add the link to the
EtherChannel? (Choose two answers.)
a. desirable and active
b. passive and active
c. active and auto
d. active and active
6. A Cisco Catalyst switch needs to send frames over a Layer 2 EtherChannel. Which
answer best describes how the switch balances the traffic over the four active links in the channel?
a. Breaks each frame into fragments of approximately one-fourth of the original

frame, sending one fragment over each link
b. Sends the entire frame over one link, alternating links in sequence for each succes-
sive frame
c. Sends the entire frame over one link, choosing the link by applying some math to
fields in each frame’s headers
d. Sends the entire frame over one link, using the link with the lowest percent utiliza-
tion as the next link to use
Foundation Topics
Understanding RSTP Through Configuration

Cisco IOS switches today typically default to using RSTP rather than STP, with default settings so that RSTP works
with no configuration. You can buy some Cisco switches and connect them with Ethernet cables in a redundant
topology, and RSTP will ensure that frames do not loop. And even if some switches use RSTP and some use STP,
the switches can interoperate and still build a working spanning tree—and you never even have to think about
changing any settings!
Although RSTP works without any configuration, most medium-size to large-size campus LANs benefit from some
STP configuration. For instance, Figure 10-1 shows a typical LAN design model, with two distribution layer switches
(D1 and D2). The design may have dozens of access layer switches that connect to end users; the figure shows
just three access switches (A1, A2, and A3). For a variety of reasons, most network engineers make the distribution
layer switches be the root.
Technet24
||||||||||||||||||||
Chapter 10: RSTP and EtherChannel Configuration 241
Best Choices to be Root
Distribution
D1 D2 Switches
Access
A1 A2 A3 Switches
10/100/1000 10/100/1000 10/100/1000
Figure 10-1 Typical Configuration Choice: Making Distribution Switch Be Root
NOTE Cisco uses the term access switch to refer to switches used to connect to endpoint devices. The term distribution
switch refers to switches that do not connect to endpoints but rather connect to each access switch, providing a
means to distribute frames throughout the LAN. If you want to read more about LAN design concepts and terms,
refer to this book’s companion website for Appendix K, “Analyzing Ethernet LAN Designs.”
As discussed in the introduction to this chapter, this first section of the chapter examines a variety of STP/RSTP
configuration topics, but with a goal of revealing a few more details about how STP and RSTP operate. Following this
opening section about RSTP configuration, the next section examines how to configure Layer 2 EtherChannels, and
how that impacts STP/RSTP.
The Need for Multiple Spanning Trees

The IEEE first standardized STP as the IEEE 802.1D standard, first published back in 1990. To put some
perspective on that date, Cisco did not have a LAN switch product line at the time, and virtual LANs did not exist
yet. Instead of multiple VLANs in a physical Ethernet LAN, the physical Ethernet LAN existed as one single
10
broadcast domain, with one instance of STP.
By the mid 1990s, VLANs had appeared on the scene, along with LAN switches. The emergence of VLANs posed a
challenge for STP—the only type of STP available at the time— because STP defined a single common spanning
tree (CST) topology for the entire LAN. The IEEE needed an option to create multiple spanning trees so that traffic
could be balanced across the available links, as shown in Figure 10-2. With two different STP instances, SW3 could
block on a different interface in each VLAN, as shown in the figure.
||||||||||||||||||||
VLAN 1 STP Topology VLAN 2 STP Topology
Root Root
Gi0/1 Gi0/2 SW2 Gi0/1 Gi0/2 SW2

SW1 SW1
Gi0/2 Gi0/1 Gi0/2 Gi0/1
Gi0/1 Gi0/2 Gi0/1 Gi0/2
SW3 SW3
Figure 10-2 Load Balancing with One Tree for VLAN 1 and Another for VLAN 2
STP Modes and Standards

Because of the sequence of events over the history of the various STP family of protocols, vendors like Cisco
needed to create their own proprietary features to create the per-VLAN spanning tree concept shown in Figure
10-2. That sequence resulted in the following:
■ When STP was the only STP standard back in the 1990s with 802.1D, Cisco created the STP-based Per VLAN
Spanning Tree Plus (PVST+) protocol, which creates one spanning tree instance per VLAN.
■ When the IEEE introduced RSTP (in 802.1D amendment 802.1w, in the year 2001), Cisco also created the Rapid
PVST+ (RPVST+) protocol. RPVST+ provided more features than standardized RSTP, including one tree per
VLAN.
■ The IEEE did not adopt Cisco’s PVST+ or RPVST+ into their standards to create multiple spanning trees.
Instead, the IEEE created a different method: Multiple Spanning Tree Protocol (MSTP), originally defined in
802.1Q amendment 802.1s. Figure 10-3 shows the features as a timeline for perspective.
RSTP &
STP MST
1990 2000 2010
PVST+ RPVST+
Figure 10-3 Timeline of Per-VLAN and Multiple STP Features
Today, Cisco Catalyst switches give us three options to configure on the spanning-tree mode command, which tells
the switch which type of STP to use. Note that the switches do not support STP or RSTP with the single tree (CST).
They can use either the Ciscoproprietary and STP-based PVST+, Cisco-proprietary and RSTP-based RPVST+, or
the IEEE standard MSTP. Table 10-2 summarizes some of the facts about these standards and options,
Answers to the “Do I Know This Already?” quiz:
1 A 2 A, C 3 A, B, D 4 D 5 B, D 6 C
Technet24
||||||||||||||||||||
along with the keywords used on the spanning-tree mode global configuration command. Example 10-1, which
follows, shows the command options in global configuration mode.
Table 10-2 STP Standards and Configuration Options

Name Based on STP or # Trees Original IEEE Config Parameter
RSTP? Standard
STP STP 1 (CST) 802.1D N/A
PVST+ STP 1/VLAN 802.1D pvst
RSTP RSTP 1 (CST) 802.1w N/A
Rapid PVST+ RSTP 1/VLAN 802.1w rapid-pvst
MSTP RSTP 1 or more* 802.1s mst
* MSTP allows the definition of as many instances (multiple spanning tree instances, or MSTIs) as chosen by the network designer but
does not require one per VLAN.
Example 10-1 STP Status with Default STP Parameters on SW1 and SW2
SW1(config)# spanning-tree mode ?
mst Multiple spanning tree mode
pvst Per-Vlan spanning tree mode
rapid-pvst Per-Vlan rapid spanning tree mode SW1(config)#
The Bridge ID and System ID Extension

To support the idea of multiple spanning trees, whether one per VLAN or simply multiple as created with MSTP, the
protocols must consider the VLANs and VLAN trunking. (That’s one reason why RSTP and MSTP now exist as part
of the 802.1Q standard, which defines VLANs and VLAN trunking.) To help make that work, the IEEE redefined the
format of the original BID value to help make per-VLAN instances of STP/RSTP become a reality. Originally, a
switch’s BID was formed by combining the switch’s 2-byte priority and its 6-byte MAC address. The revised rules
divide the original priority field into two separate fields, as shown in Figure 10-4: a 4-bit priority field and a 12-bit 10
subfield called the system ID extension ( which represents the VLAN ID).
2 Bytes 6 Bytes
Priority (0 – System ID (MAC Original Format

65,535) Address) Bridge ID
System ID
Priority
System ID Extension (Typically System ID (MAC Extension (MAC
(Multiple of
Holds VLAN ID) Address) Address
4096)
Reduction)
4 Bits 12 Bits 6 Bytes
Figure 10-4 STP System ID Extension

||||||||||||||||||||
Cisco switches let you configure the BID, but only the priority part. The switch fills in its universal (burned-in)
MAC address as the system ID. It also plugs in the VLAN ID of a VLAN in the 12-bit system ID extension field;
you cannot change that behavior either. The only part configurable by the network engineer is the 4-bit priority
field. However, configuring the number to put in the priority field may be one of the strangest things to configure
on a Cisco router or switch. As shown at the top of Figure 10-4, the priority field was originally a 16-bit number,
which represented a decimal number from 0 to 65,535. Because of that history, the configuration command ( spanning-tree
vlan vlan-id
priority x) requires a decimal number between 0 and 65,535. But not just any number in that range will suffice; it must
be a multiple of 4096, as emphasized in the help text shown in Example 10-2.
Example 10-2 Help Shows Requirements for Using Increments of 4096 for Priority
SW1(config)# spanning-tree vlan 1 priority ?
<0-61440> bridge priority in increments of 4096 SW1(config)#
Table 10-3 lists all the configurable values for the STP/RSTP priority. However, do not worry about memorizing the
values. Instead, the table lists the values to emphasize two points about the binary values: the first 4 bits in each
value differ, but the last 12 bits remain as 12 binary zeros.
Table 10-3 STP/RSTP Configurable Priority Values

Decimal Value 16-bit Binary Equivalent Decimal Value 16-bit Binary Equivalent
0 0000 0000 0000 0000 32768 1000 0000 0000 0000
4096 0001 0000 0000 0000 36864 1001 0000 0000 0000
8192 0010 0000 0000 0000 40960 1010 0000 0000 0000
12288 0011 0000 0000 0000 45056 1011 0000 0000 0000
16384 0100 0000 0000 0000 49152 1100 0000 0000 0000
20480 0101 0000 0000 0000 53248 1101 0000 0000 0000
24576 0110 0000 0000 0000 57344 1110 0000 0000 0000
28672 0111 0000 0000 0000 61440 1111 0000 0000 0000
Note that while you can set the priority to any of the 16 decimal values in Table 10-3, Cisco provides a convenient
means to create a primary and secondary root switch concept without configuring an actual number. In most LAN
designs, only a small number of switches would be good candidates to ever be the root switch based on where the
switches sit within the topology. Think of the preferred switch as the primary switch and the next-best option as the
secondary switch. Then, to configure those two switches to be the two most likely switches to be the root switch,
simply configure
spanning-tree vlan x root primary ( on the switch that should be primary)
spanning-tree vlan x root secondary ( on the switch that should be secondary)
Technet24
||||||||||||||||||||
These two commands cause the switch to make a choice of priority value but then store the chosen priority value in
the spanning-tree vlan x priority value command. The command with root primary or root secondary does not
appear in the configuration. When configuring root primary, the switch looks at the priority of the current root switch
and chooses either (a) 24,576 or (b) 4096 less than the current root’s priority (if the current root’s priority is 24,576
or less) to the configuration instead. When configuring, root secondary always results in that switch using a priority
of 28,672, with the assumption that the value will be less than other switches that use the default of 32,768, and
higher than any switch configured as root primary.
How Switches Use the Priority and System ID Extension

Cisco Catalyst switches configure the priority value using a number that represents a 16-bit value; however, the
system ID extension exists as the low-order 12 bits of that same number. This next topic works through connecting
those ideas.
When the switch builds its BID to use for RSTP in a VLAN, it must combine the configured priority with the VLAN
ID of that VLAN. Interestingly, the configured priority results in a 16-bit priority that always ends with 12 binary 0s.
That fact makes the process of combining values to create the BID a little simpler for the switch and possibly a little
simpler for network engineers once you understand it all.
First, consider the process shown in Figure 10-5. The top shows the configured priority value (decimal 32768), in
16-bit binary form, with a System ID Extension of 12 zeros. Moving down the figure, you see the binary version
of a VLAN ID (decimal 9). At the last step, the switch replaces those last 12 bits of the System ID Extension with
the value that matches the VLAN ID and uses that value as the first 16 bits of the BID.
Priority System ID Extension
Configured Priority 1000 0000 0000 0000
VLAN ID 9 0000 0000 1001
10
16-Bit Priority 1000 0000 0000 1001
Figure 10-5 Configured Priority (16-Bit) and System ID Extension (12-Bit) Added
As it turns out, the process shown in Figure 10-5 is just the sum of the two numbers—both in binary and decimal.
To see an example, refer to upcoming Example 10-3, which demonstrates the following details:
■ The output shows details about VLAN 9.
■ The root switch has been configured with the spanning-tree vlan 9 priority 24576
command.
■ The local switch (the switch on which the command was gathered) has been configured with the spanning-tree
vlan 9 priority 32768 command.
||||||||||||||||||||
■ Conveniently, the decimal equivalent of the two switches’ first 16 bits—the original 16-bit priority
field—can be easily calculated in decimal. In this example:
■ Root Switch: 24,576 (priority) + 9 (VLAN ID) = 24585
■ Local Switch: 32,768 (priority) + 9 (VLAN ID) = 32777
The output in Example 10-3 matches this logic. The top highlight shows the priority of the root switch (24585),
which is the sum of the root switch’s priority setting (configured as
24,576) plus 9 for the VLAN ID. The second highlight shows a value of 32,777, calculated as the local switch’s
priority setting of 32,768 plus 9 for the VLAN ID.
Example 10-3 Examining the 16-bit Priority as Interpreted in Cisco show Commands
SW1# show spanning-tree vlan 9
VLAN0009
Spanning tree enabled protocol rstp Root ID
Priority 24585
Address 1833.9d7b.0e80
Cost 4
Port 25 (GigabitEthernet0/1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32777 (priority 32768 sys-id-ext 9)
Address f47f.35cb.d780
! Output omitted for brevity
RSTP Methods to Support Multiple Spanning Trees

Although the history and configuration might make the BID priority idea seem a bit convoluted, having an extra 12-bit
field in the BID works well in practice because it can be used to identify the VLAN ID. VLAN IDs range from 1 to
4094, requiring 12 bits. For the purposes of discussion, focus on the standard RSTP and its Cisco-proprietary cousin
RPVST+. Both use the RSTP mechanisms as discussed in Chapter 9, “Spanning Tree Protocol Concepts,” but
RPVST+ uses the mechanisms for every VLAN, while standard RSTP does not. So how do their methods differ?
■ RSTP creates one tree—the Common Spanning Tree (CST)—while RPVST+ creates one tree for each and
every VLAN.
■ RSTP sends one set of RSTP messages (BPDUs) in the network, no matter the number of VLANs, while
RPVST+ sends one set of messages per VLAN.
■ RSTP and RPVST+ use different destination MAC addresses: RSTP with multicast address
0180.C200.0000 (an address defined in the IEEE standard), and RPVST+ with multicast address
0100.0CCC.CCCD (an address chosen by Cisco).
■ When transmitting messages on VLAN trunks, RSTP sends the messages in the native VLAN with no VLAN
header/tag. RPVST+ sends each VLAN’s messages inside that VLAN—for instance, BPDUs about VLAN 9
have an 802.1Q header that lists VLAN 9.
Technet24

Revise Todos Los Temas Clave: Descripción

Cargado por

Copyright:

Formatos disponibles

Revise Todos Los Temas Clave: Descripción

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Revise Todos Los Temas Clave: Descripción

Cargado por

Copyright:

Formatos disponibles

||||||||||||||||||||

Capítulo 6: Configuración de la administración básica del conmutador 147

Revise todos los temas clave

Elemento clave Descripción Número de

del tema página

Términos clave que debe saber

de historial, DNS, resolución de nombre, mensaje de registro

Tabla 6-5 Comandos de seguridad de inicio de sesión

Mando Modo / Propósito / Descripción

consola de línea 0 Cambia el contexto al modo de configuración de la consola.

148 CCNA 200-301 Guía oficial de certificados, volumen 1

Mando Modo / Propósito / Descripción

Tabla 6-6 Cambiar la configuración de IPv4

Mando Modo / Propósito / Descripción

habla a es necesario si el conmutador usa DHCP.

Tabla 6-7 Otra configuración del interruptor

Mando Modo / Propósito / Descripción

parte del símbolo del sistema del conmutador.

recuperarlos posteriormente, para los usuarios de esas líneas.

Capítulo 6: Configuración de la administración básica del conmutador 149

Tabla 6-8 Capítulo 6 Referencia de comandos EXEC

show running-config Enumera la configuración utilizada actualmente.

dirección IP, la máscara de subred y la información de la puerta de enlace predeterminada.

mostrar historia Enumera los comandos en el búfer de historial actual.

Configuración y verificación de interfaces de

1.0 Fundamentos de la red

1.1 Explicar el papel y la función de los componentes de la red.

1.4 Describir conceptos de conmutación

"¿Ya sé esto?" Examen

Cuadro 7-1. "¿Ya sé esto?" Asignación de temas básicos de la sección a la pregunta

Configuración de interfaces de conmutador 1–3

Análisis del estado y las estadísticas de la interfaz del conmutador 4–6

¿Puerto 10/100 en un conmutador Cisco?

a. Configurar el negociar deshabilitar subcomando de interfaz

si. Configurar el no negociar subcomando de interfaz

C. Configurar el velocidad 100 subcomando de interfaz

re. Configurar el mitad dúplex subcomando de interfaz

mi. Configurar el dúplex completo subcomando de interfaz

F. Configurar el velocidad 100 y dúplex completo subcomandos de interfaz

si. Habilitar modo

C. Modo de configuración global

re. Modo VLAN

mi. Modo de configuración de la interfaz

si. Medio duplex

re. 1000 Mbps

a. La interfaz está configurada con el apagar mando.

re. La interfaz no se puede utilizar actualmente para reenviar cuadros.

mi. La interfaz se puede utilizar actualmente para reenviar cuadros.

152 CCNA 200-301 Guía oficial de certificados, volumen 1

enlace después de que aparece? (Elija dos respuestas)

a. El enlace funciona a 1000 Mbps (1 Gbps).

re. Ambos interruptores usan full duplex.

a. El G0 / 1 de SW2 se ha configurado con un apagar subcomando de interfaz.

Configuración de interfaces de conmutador

Configuración de velocidad, dúplex y descripción

medio} y velocidad {auto | 10 | 100 1000} subcomandos de interfaz. Suficientemente simple.

Capítulo 7: Configuración y verificación de interfaces de conmutador 153

Ejemplo 7-1 Configurando velocidad, dúplex, y descripción en Switch Emma

Emma # configurar terminal