supportforums.cisco.com · web viewa modo de ejemplo, puede utilizar los siguientes comandos para...

Layer 2 switch Operation.

Un switch ethernet opera en la capa 2 del modelo OSI, realizando decisiones acerca de como enviar frames basadas en la dirección MAC destino que se encuentra dentro de la frame. Esto significa que el medio ethernet no es mas compartido por los equipos conectados al dispositivo. Un switch ethernet en un nivel básico provee aislamiento entre los hosts conectados en diferentes formas:

- El alcance de los dominios de colision es limitado, a cada uno de los puertos switch port, el dominio de colision consiste del switch port en si mismo y del dispositivo conectado a dicho puerto.

- La conexion de los host puede operar en modo full duplex por que no hay contesion en el medio, los host pueden hablar y escuchar al mismo tiempo.

-El ancho de banda no es mas compartido, en lugar de eso, cada switch port ofrece ancho de banda dedicado atravez del switching fabric a otro switch port.

-Los errores en las frames no son propagados. Cada frame recibida en un switch port es checando por errores. las frames buenas son regeneradas cuando son enviadas o transmitidas. Esto es conocido como el store-and-forward tecnología de switching: Los paquetes son recibidos, guardados para inspeccion y después enviados.

-Usted puede limitar el trafico de broadcast a un volumen de umbral.

- De tal manera que el switch no enviara frames hasta que conozca la ubicación del destino. Un switch se le debe decir explicitamente donde estan los host ubicados o deberá aprender por el mismo. Usted puede configurar la ubicación de las direcciones mac address atravez del command-line interfaces, pero esto puede salirse de control rápidamente cuando hay muchas estaciones en la red o cuando las estaciones se mueven alrededor.

-Para dinamicamente aprender sobre la ubicación de las estaciones, un switch escucha a las frames entrantes y mantiene una tabla de información de direcciones. como un frame es recibida en un switch port, el switch inspecciona la dirección mac origen. Si la dirección no esta en su tabla de direcciones todavía, la dirección MAC address, switch port y Virtual LAN (VLan) en la cual esta arriba es grabada en la tabla. Aprender la ubicación de una dirección de un paquete entrante es fácil y sencillo. las frames de entrada también incluyen la dirección MAC address destino. De nuevo, el switch busca esta dirección en su tabla de direcciones, esperando encontrar el switch port y Vlan donde la dirección destino es adjunta. Si se encuentra la frame puede ser enviada fuera del switch port. Si la dirección no es encontrada en la tabla, el switch deberá tomar acciones mas drásticas la frame es enviada de modo best effort por la inundación (flooding it out) a todos los switch port asignados a la VLAN origen. Esto es conocido como unknown unicast flooding. Un switch constantemente escucha a frames entrantes en cada uno de sus puertos, aprendiendo MAC address de origen. Sin embargo, es conciente que el procedo de aprendizaje es permitido solo cuando el protocolo Spanning Tree Protocol (STP) algoritmo Referencia: Switch Operation for the CCNP BCMSN Exam, By David Hucaby.

a decidido que el puerto es estable para uso normal. STP esta interesado solo en mantener la red libre de loops (loop-free), donde las frames no seran enviadas recursivamente si un loop es formado, una frame inundada podra seguir el path looped, donde sera enviada una y otra vez.

Siguiendo las Frames.

Cuando la frame arriba al switch port, esta es puesta en una de las colas de puerto de ingreso. Cada cola puede contener frames para ser enviadas, con cada cola teniendo diferentes prioridades y niveles de servicio. el switch port después puede sera afinado frames importantes se conseguirá procesar y enviadas antes que frames menos importantes.

Como las colas de ingreso son servidas y las frames sale, el switch debe de arreglarselas no solo de donde enviar la frame, pero también si esta debe ser enviada y como. Las 3 fundamentales decisiones que deben ser tomadas: una preocupación con el descubrimiento de la interfaces de salida del switch port, y 2 preocupaciones con las políticas de envino. Todas estas decisiones son hechas simultanea mente por porciones independientes del switching hardware y pueden ser descriptas a continuación:

-L2 forwarding table- La dirección Mac address de destino de la frame es usada como un index, o como llave, dentro del Content-addressable memory (CAM). Si la dirección es encontrada, el switch port de egreso y la Vlan Id apropiado son leidos de la tabla (Si la dirección no es encontrada, la frame es marcada para inundar entonces es enviado a cada switch port en la Vlan).

-Security ACLs- Access control lists (ACL) puede ser usada para identificar frames de acuerdo con su MAC address, protocol types (for non-ip frames), ip address, protocols y layer 4 port numbers. La ternary content-addressable memory (TCAM)contiene ACLs en forma compilada de modo que una desicion puede ser hecha en si envia la frame en una sola búsqueda, single table lookup.

Multilayer Switching Operation.

Types of multilayer switching.

Catalys switching soporta 2 generaciones básicas o tipos de MLS: route caching (primera generación de MLS) y topology-based (Segunda generación de MLS). Esta seccion muestra un resumen de ambos.

Route caching- la primera generación de MLS, requiere de un route processor (RP) y switching engine (SE). El RP debe procesar el flujo de trafico del primer paquete para determinar el destino. El SE escucha el primer paquete y al destino resultado, y configura un shortcut de entrada en el cache del MLS. El SE enviara los paquetes subsecuentes en el mismo flujo de trafico.

Referencia: Switch Operation for the CCNP BCMSN Exam, By David Hucaby.

Topology-base- La segunda generación de MLS utiliza hardware especial. La información de ruteo de capa 3 es construida y populada en una sola base de datos de la topologia entera de la red. Esta base de datos y una tabla de búsqueda eficiente en hardware, es consultada, entonces los paquetes pueden ser enviados a alta velocidad. El match mas largo encontrado en la base de datos es usado como la correcta dirección destino de capa 3. Como la topologia de ruteo cambio durante el tiempo, la base de datos contenida en hardware puede ser actualizada dinamicamente sin impactar el performance. Este tipo de MLS es conocido como Cisco Express Forwarding (CEF). Un proceso de ruteo corriendo en la descarga del switch la tabla de base de datos actual dentro del Forwarding Information Base (FIB) son del Hardware.

Siguiendo el Paquete.

Los paquetes que arriba en un switch port son puestos en la apropiada cola de ingreso, como se hace en un switch de capa 2. Cada paquete se saca de la cola de ingreso y es inspeccionado por ambas direcciones destino de capa 2 y capa 3. Ahora, la decisión de donde es enviado el paquete es basada en dos tablas de direcciones, donde la decisión de como enviar el paquete sigue siendo basada en los resultados de las listas de acceso. Como en los switch de capa 2, todas estas decisiones son realizadas simultaneamente en Hardware.

L2 forwarding table- La dirección destino MAC es usada como un index para la tabla CAM. Si la frame contiene paquetes de capa 3 para ser enviados, la mac address destino es un puerto en capa 3 en el switch. En este caso, La tabla CAM resultante es usada solo para decidir que la frame debe ser procesada en la capa 3.

L3 forwarding table- La tabla FIB es consultada, usando la direccion Ip destino como index. El match mas largo encontrado en la tabla (ambas direccion y mascara), y la direccion de next-hop resultante es obtenida. El FIB tambien contiene entradas de direcciones MAC de next-hop en capa 2 y el puerto swich port de egreso (y el Vlan Id) por lo que una mayor búsqueda en la tabla no son necesarios.

Security ACLs- Listas de acceso de entrada y de salida son compiladas dentro de las entradas TCAM entonces la decisión de como enviar el paquete pueden ser determinadas como una sola búsqueda de tabla.

Qos ACLs- Clasificación de paquetes, políticas, y clasificación todas pueden ser realizadas en una sola búsqueda de tabla en la Qos TCAM.

Sin embargo recordemos que durante el proceso de multilayer switching, el destination next-hop fue obtenido de la tabla FIB, solo como un router lo hace. La dirección de capa 3 identifica al next-hop y encuentra su dirección de capa 2. Solo la dirección de capa 2 se utiliza, entonces la frame de capa 2 puede ser enviada sobre de. La dirección de capa 2 del next-hop deberá ser puesta dentro de la frame en lugar de la dirección destino (El switch multilayer). La dirección origen de la frame también deberá convertirse en la del multilayer Referencia: Switch Operation for the CCNP BCMSN Exam, By David Hucaby.

switch antes de enviarse al next-hop. Como cualquier buen router debe hacer, El Time-To-Live (TTL) valor en los paquetes de capa 3 deberá decrementarse en 1. Porque el contenido del paquete de capa 3 (El valor de TTL) han cambiado, El header de capa 3 de checksum debe recalcularse. y por que el contenido de capa 2 y 3 cambio, el checksum de capa 2 deberá ser re-calculado. En otras palabras, la frame completa ethernet deberá ser reescrita antes de ir a la cola de egresos. Esto también es completado eficientemente en hardware.

Multilayer Switching Exception.

CFE puede enviar mas paquetes ip entre los host. Esto ocurre cuando la dirección origen y destino (ambas MAC e Ip) ya conocidas y no otro parametro Ip no sera manipulado. Otros paquetes pueden ser enviados directamente por CFE y deberán ser manejados con mas detalles. Esto es hecho por una rápida inspeccion durante el proceso de decisión de envio. Si un paquete cumple con los criterios como son los siguientes, es marcado para su posterior procesamiento y envio o apuntado para procesamiento de switcheo en el CPU del switch.

-ARP request and replies.

-Paquetes ip que requiere de una respuesta del router(TTL ha expirado, MTU es excedido, se requiere de fragmentacion, etcétera)

- Ip broadcast que sera rele como Unicast (DHCP request, funciones Ip helper-address)

-Actualizaciones de protocolos de ruteo.

-Cisco Discovery protocol packets.

-Protocolos de ruteos IPX y servicios de anuncio.

-Paquetes que requieren de encripcion.

- Paquetes que disparan un Network Address Translation (NAT).

- Otros paquetes de protocolos no-Ip y no-IPX (AppleTalk, DECnet, etcétera)

Content-Addressable Memory.

Todos los modelos switchs Catalyst usan una tabla CAM para el switcheo de capa 2. Como las frames van arrivando en los switch ports, la direcciones MAC address son aprendidas y grabadas en la Tabla CAM. El puerto de arrivo y la Vlan ambas son grabadas en la tabla, junto con el time stamp. Si una mac address aprendida en el switch port se ha movido a un puerto diferente, La dirección MAC Address y el time stamp son grabados para el mas reciente puerto de arrivo. luego, la entrada previa es borrada. Los Referencia: Switch Operation for the CCNP BCMSN Exam, By David Hucaby.

Switches generalmente tiene largas tablas CAM de modo que muchas direcciones puede ser consultado para el envio de tramas. Sin embargo, no hay suficiente espacio de tablas para contener todas las direcciones posibles en grandes redes. Para administrar el espacio de la tabla CAM, stale entries (entradas obsoletas) (direcciones que no han sido escuchados por un periodo de tiempo) son caducadas. Por default, Las entradas Idle CAM son conservadas por 300 segundos antes de ser eliminados. Usted puede cambiar la configuración default usando el siguiente comando de configuración:

Switch(config)#mac address-table aging-time seconds

por default, las MAC address son aprendidas dinamicamente de las frames de entrada. Usted también puede configurar estéticamente entradas en la tabla CAM que contiene direcciones MAC address que no pueden ser aprendidas de otra forma. para hacer esto, use el siguiente comando de configuración:

Switch(config)#mac address-table static mac-address vlan vlan-id interface type mod/num

Exactamente que pasa cuando la MAC address de un host aprendida en un switch port, y después el host se mueve de modo que aparece en un switch port diferente? Ordinariamente, La entrada de la tabla CAM del host original debera de pasar por un periodo de caducidad después de 300 segundos, mientras esta dirección es aprendida en un nuevo puerto. Para evitar tener duplicidad de entradas en la tabla CAM, el switch purga cualquier entrada existente para la dirección MAC address que acaba de ser aprendida en diferente puerto. Esta aseveración es segura ya que las direcciones MAC son únicas. Un solo host nuca debe ser visto en mas de un switch port a menos que se tenga un problema en la red. Si un switch nota que una MAC address se esta comenzado aprender en un switch port alternativo, este genera un mensaje de error, La MAC address es "Flapping" entre interfaces.

Ternary Content-Addressable Memory.

En un Multilayer switch, sin embargo, todos los proceso de matching process que un ACL provee es implementado en hardware. TCAM permite a los paquetes se evaluados contra un entrada de lista de acceso en una sola búsqueda de tabla. La mayoría de los switches tiene múltiples TCAM de modo que ambas entradas y salidas de seguridad y QoS ACLs pueden ser evaluadas simultáneamente, o enteramente en paralelo con decisiones de envio de capa 2 y capa 3.

El software IOS de Catalyst tiene 2 componentes que son parte de la operación TCAM:

Feature Manager (FM)- Después de que una lista de acceso fue creada o configurada, el feature manager software compila, o fusiona, El ACE dentro de las entradas en la tabla TCAM, el TCAM después puede ser consultada a full frame-forwardong speed.


Switching Database Manager (SDM)- Usted puede particionar el TCAM en algunos switches Catalyst en areas para diferentes funciones. El software SDM cofigura o tunea las particiones de TCAM, si es necesario. (El TCAM se fija en Catalyst 4500 y 6500 y no puede reparticionarse).

TCAM Structure.

Las entradas de TCAM estan compuestas por valores, mascara, y resultados (VMR) combinados. Campos de una frame o headers de paquete son alimentados en el TCAM, donde ellos haran match contra el valor y mascara para llegar a un resultado. Como referencia rápida, estas pueden ser descriptas como sigue:

Valores (Values): son siempre cantidades de 134-bits, que consisten de dirección origen y dirección destino y otra información relevante de protocolo. Todos los patrones para hacer macth.

Mascara (Mask).- También son de una cantidad de 134-bit, en exactamente el mismo formato, o orden de bit, como el Values. Masks selecciona solo el valor en bits de interese. un bit de mascara esta configurada exactamente hace match al valor de bit o no esta configurado para valor de bit que no importa. La mascara usada en la TCAM es ajustada a direcciones o bit mask en ACEs.

Resultados.- Son valores numéricos que representan que accion debe tomar después de la búsqueda de TCAM occurre. Mientras listas de acceso tradicionales solo ofrecen resultados permit or deny, búsquedas TCAM ofrece un numero de posibles resultados o acciones. Por ejemplo, el resultados puede ser una desicion de permitir o denegar, un valor de index para Qos policer, apuntando al next-hop routing table, y sucesivamente.

Una simple lógica operación entre mascara y patrones no puede ser generado el resultado deseado. El TCAM también provee un mecanismo para realizar operaciones de capa 4 o comparaciones, también lo realiza en una sola búsqueda de tabla. Si un ACE tiene un puerto de operación, tal como gt, lt, neq, o range, El Feature Manager Software compila las entradas TCAM para incluir el uso de los operadores y operando lógicamente en unidades de operación (LOU). Solo algunos numeros limitados de LOU son disponibles en el TCAM. Si hay mas de una ACE con operadores de comparación operadores que hay en LOUs, El Features Manager debe romper el ACEs en múltiples ACE con solo matching regulares (Usando operadores eq)

-Uno que verifica para puertos UDP destino mayores a 1024.

-Uno que verifica para rangos de puertos UDP destino 1024 a 2047.

Monitoring Switching Tables.

CAM Table Operation.


Para ver el contenido de la tabla CAM, usted puede usar la siguiente forma de comando EXEC show mac address-table:

switch#show mac address-table dynamic [address mac-address | interface type mod/num | vlan vlan-id]

Las entradas que fueron aprendidas dinamicamente seran mostradas. usted puede agregar la palabra clave address para especificar un sola MAC address, o las palabras calves interface o Vlan para ver direcciones que fueron aprendidas en una interface o vlan especifica.

Suponga que este mismo comando no produce ninguna salida, mostrando nada sobre la interface y Vlan donde la dirección MAC address es encontrado. ¿Qué puede significar eso? o ya sea el host no ha enviar una trama que el switch puede utilizar para aprender su ubicación, o algo raro esta pasando. Quizas el host esta usando 2 tarjetas de red (NIC) para hacer balanceo de cargas, una NIC es solo para recibir trafico, mientras la otra es solo para enviar trafico. Por lo tanto, el switch nunca escucho y aprendido de sólo recepción de la dirección NIC.

Para ver todas las Mac address que esta actualmente encontradas en la interface Gigabit 1/0/29, usted puede usar el comando:

Switch# show mac address-table dynamic interface gigabitethernet1/0/29

Sin embargo, suponer el mismo comando es usado para checar la interface gigabitethernet1/0/49. La salida mostrada en el ejemplo 2-3 lista muchas direcciones MAC, todos se encuentran en una sola interfaz. Como puede ser aprendidas tantas direcciones en una sola interface del switch?, esta interface debe conducir a otro switch o a otra parte de la red donde otros dispositivos son encontrados.

Encontrando muchos host en una interface.


Para ver el tamaño de la tabla CAM, use el comando show mac address-table count, como se muestra en el ejemplo 2-4. MAC address totales son mostrados por cada vlan activa en el switch. Esto puede darte una buena idea de el tamaño de la tabla CAM y cuantos hosts estan usando la red.


Las entradas de la tabla CAM pueden ser borradas manualmente, si se necesita, usando el siguiente comando EXEC:

Switch#clear mac address-table dynamic [address mac-address | interface type mod/num | vlan vlan-id]

Conceptos Ethernet.

Ethernet escala para soportar incrementos de ancho de banda; El medio ethernet debe ser elegido para que coincida con la necesidad en cada punto de la red del campus. A medida que crecen las necesidades de ancho de banda, usted puede escalar los links entre accesos, distribución, y capa de core para hacer match con el requerimiento de carga.

Ethernet (10Mbps).

Cuando un usuario intenta trasmitir al mismo tiempo que otro, una colision ocurre, en otras palabras, ambos usuarios no pueden trasmitir datos al mismo tiempo ambos deben compartir el mismo medio de red. Ethernet esta basado en la tecnología Carrier sense multiple access collision detect (CSMA/CD), la cual requiere que las estaciones transmisoras den marcha atras por un perido aleatorio de tiempo cuando una


colision ocurre. Si una estacion debe esperar su turno para trasmitir, no pueden trasmitir y recibir al mismo tiempo. Esto es llamado operación half-duplex. Los switchs ethernet manejan este problema dinamicamente asignando ancho de banda dedicado de 10Mbps para cada puerto. el aumento de rendimiento de la red resultante se produce por reducción del número de usuarios conectados a un segmento de Ethernet. En efecto, las colisiones son menos probables y el dominio de colision es reducido en tamaño.

Por que los switches ethernet reducen la posibilidad de una colision, las estaciones no tiene que escuchar unas a otras para tomar turno en transmisión en el cable. En su lugar, las estaciones pueden operar en modo full-duplex, trasmitiendo y recibiendo simultáneamente, El modo Full-Duplex aumentara a un mas el performance de la red, con throughput de 10Mbps en cada dirección, o 20Mbps de throughput total en cada puerto. Otra consideración cuando uno esta tratando con 10Mbps ethernet es el cableado físico. El cableado Ethernet involucra el trabajar con Unshielded twisted-pair (UTP) alambrando (10BASE-T Ethernet) usualmente restrictivo en distancia de 100 metros (328 pies) entre dispositivos activos. Manteniendo el cableado corto en distancia en el armario de cableado (wiring closet) también reduce rudidos y crosstalk cuando muchos cables son agrupados. En un ambiente de Red de Campus, ethernet se puede encontrar en la capa de acceso, entre los dispositivos de usuarios finales y la capa de switching de acceso. Sin embargo, en redes modernas, ganeraciones mas rápidas de ethernet son usualmente usadas in capas de acceso. Ethernet típicamente no se utiliza, ya sea en la distribución o la capa de core debido a su capacidad relativamente bajo ancho de banda.

Fast Ethernet.

Fast Ethernet opera en los 100Mbps y es definido en el estandard IEEE 802.3u. La red de campus puede usar fast ethernet enlaces en acceso y capa de distribución, si no se tiene disponibles enlaces de alta velocidad disponibles. Estos enlaces pueden soportar el tráfico agregado de múltiples segmentos ethernet en la capa de acceso. Fast Ethernet es generalmente usado para conectar estaciones de trabajo de usuarios finales a la capa de acceso y para proporcionar una mejor conflictividad a los servidores de la empresa. cableado para fast ethernet puede implicar UTP o fibra.


Full-Duplex Fast Ethernet.

Fast ethernet puede proveer hasta 100Mbps en cada dirección en una conexion de switch, para 200Mbps de throughput. El máximo throughput es posible cuando un solo dispositivo (Estacion de trabajo, servidor, router o otro switch) es conectado directamente al switch port. Ademas, el dispositivo en cada terminación del enlace ambos debe soportar operación Full-duplex, permitiendo que cada trasmisión a voluntad sin tener que detectar y recuperarse de colisiones. Las conexiones de red pueden automáticamente negociar las capacidades del enlace de modo que ambos pueden operar a un máximo nivel común. Esta negociación involucra la detección y seleccion la más alta tecnología de capa física (Ancho de banda disponible) y operación half-duplex o full-duplex. para negociar correctamente una conexión, ambos extremos deben estar configurados para la negociación automática. La velocidad del enlace es determinada por la señalizacion electrica de modo que cada extremo de un enlace puede determinar qué velocidad el otro extremo está tratando de usar. si ambos extremos del enlace están configurados para autonegociación, van a utilizar la velocidad más alta que es común a ellos. el modo dúplex de un enlace, Sin embargo, se negocia a través de un intercambio de información. esto significa que para un extremo a autonegotiate con éxito el modo dúplex, el otro extremo también se debe establecer en autonegotiate. De lo contrario, un extremo nunca ver la información duplex desde el otro extremo y no será capaz de determinar el modo correcto que debe utilizar. Si la negociación automática duplex falla, un puerto de switch siempre cae de nuevo a su configuración predeterminada: half-duplex. Autonegotiation utiliza las prioridades que se indican en la Tabla 3-3 para cada modo de Ethernet para determinar qué tecnología de acordar. Si ambos dispositivos pueden soportar más de una tecnología, se utiliza la tecnología con la más alta prioridad. Por ejemplo, si dos dispositivos pueden apoyar tanto 10BASE-T y 100BASE-TX, ambos dispositivos se utilice el modo de 100BASE-TX de prioridad más alta.

Para asegurar la configuración adecuada en ambos extremos de un enlace, Cisco recomienda que los valores apropiados para la velocidad de transmisión y el modo dúplex


pueden configurar manualmente en los puertos de conmutación. Esto impide cualquier posibilidad de que un extremo del enlace va a cambiar su configuración, lo que resulta en una conexión inutilizable. Si ajusta manualmente el puerto del switch, no se olvide de configurar manualmente el dispositivo en el otro extremo del enlace correspondiente. De lo contrario, puede producirse un desajuste velocidad o dúplex entre los dos dispositivos.

Cisco proporciona una capacidad adicional de Fast Ethernet, que permite varias conexiones Fast Ethernet que se juntan para un mayor rendimiento. Fast EtherChannel (FEC) permite de 2 a ocho Ethernet full dúplex para que actúen como un único enlace físico, para tener un agregado de ancho de banda duplex de 400-1600Mbps. Esta tecnología se describe con mayor detalle en el Capítulo 6, “Aggregating Switch Links.”

Gigabit Ethernet.

Sin embargo, la capa física se ha modificado para aumentar las velocidades de transmisión de datos. Dos tecnologías se fusionaron para obtener los beneficios de cada uno: el estándar Ethernet IEEE 802.3 y el Instituto Americano de Estándares Nacionales (ANSI) X3T11 FibreChannel. IEEE 802.3 sentó las bases del formato de trama, CSMA / CD, full duplex, y otras características de Ethernet. FibreChannel proporcionó una base de alta velocidad ASICs, componentes ópticos y mecanismos de codificación / decodificación y la serialización. El protocolo resultante se denomina IEEE 802.3z Gigabit Ethernet.

En una red de campus, puede utilizar Gigabit Ethernet para conectar cada dispositivo a un conmutador o para conectar dos interruptores juntos. La solución "Gigabit sobre cobre" que los medios de 1000BASE-T ofrece se basa en el estándar 802.3ab IEEE. Aquí, la


autonegociación soporta el mismo esquema de prioridad como Fast Ethernet, aunque 1000BASE-T full dúplex se convierte en la prioridad más alta, seguida por 1000BASE-T half dúplex. Modo dúplex del puerto de Gigabit Ethernet se establece siempre en full duplex en los switches Cisco, negociación automática para impresión dúplex no es posible. Finalmente, Cisco ha extendido el concepto de Fast EtherChannel para agrupar varios enlaces Gigabit Ethernet para actuar como una sola conexión física. Con Gigabit EtherChannel (GEC), Dos a ocho conexiones Gigabit Ethernet full dúplex pueden agregarse, por un único enlace lógico de hasta un rendimiento de 16 Gbps. Puerto agregación y la tecnología EtherChannel se describen con más detalle en el capítulo 6.

10-Gigabit Ethernet.

El 10 Gigabit Ethernet, también conocida como 10 GbE, y el estándar IEEE 802.3ae difieren de sus predecesores sólo en la capa física (PHY); 10 GbE opera sólo en modo full dúplex. El estándar define varios transceivers diferentes que se pueden utilizar como . Estos se clasifican en los siguientes:PhysicalMedia Dependent (PMD) interfaces. Estos se clasifican en los siguientes:

LAN PHY-Interconexiones switches en una red de campus, predominantemente en la capa Core.

WAN-PHY- Interfaz con la red existente óptica síncrona (SONET) o la jerarquía digital síncrona (SDH) redes que se encuentran normalmente en las redes de área metropolitana (MAN).

10-Gigabit Ethernet utiliza 10GBASE-X. Tabla 3-5 enumera los diferentes PMD definidos en el estándar, junto con el tipo de limitaciones de fibra y la distancia. Todos los PMD de fibra óptica se pueden utilizar ya sea como una LAN o Wan PHY, excepto para el 10GBASE-LX4, que es sólo un PHY LAN. Tenga en cuenta que los PMD longitud de onda larga tienen una significativamente mayor gasto que los demás.


Switches Cisco Catalyst PMD 10-Gigabit Ethernet soportados en forma de XENPAK, X2 y SFP +. En general, el factor de forma X2 es más pequeña que la XENPAK, y la SFP + es aún más pequeña, permitiendo una mayor densidad de puerto en un módulo de conmutación.

Connecting Switches and Devices.

Ethernet Port Cables and Connectors

Puertos Fast Ethernet (100BASE-FX) utilizan dos hebras de fibra multimodo (MMF) con MT-RJ o conectores SC para proporcionar conectividad. Los conectores MT-RJ son pequeñas y modulares, cada uno con un par de hebras de fibra óptica. El conector encaje en su lugar, pero hay que pulsar una pestaña para quitarla. Los conectores SC en los cables de fibra son de forma cuadrada. Estos conectores encajan a presión dentro y fuera del conector de puerto de conmutador como el conector es empujado en o sacó. Una hebra de fibra se utiliza como un camino de transmisión y el otro como un camino de recepción. La fibra de transmisión en un dispositivo interruptor debe conectarse a la fibra en el otro extremo de recepción.

Todas las familias de switches Catalyst soportan 10/100 autosensing (mediante la negociación automática Fast Ethernet) y 10/100/1000 autosensing Gigabit Ethernet. Estos puertos usan conectores RJ-45 en la Categoría 5 UTP de cableado para realizar las conexiones. Estos puertos pueden conectarse a otros dispositivos basados autosensing Ethernet UTP. Cableado UTP está dispuesto de manera que RJ-45 pines 1,2 y 3,6 forman dos pares trenzados. Estos pares se conectan directamente a través hasta el otro extremo.

Nota: Debido a las conexiones UTP Ethernet utilizan sólo pares 1,2 y 3,6, algunos instaladores de plantas de cable conectan sólo estos pares y dejar las dos posiciones de los


pares restantes vacía. Aunque este movimiento proporciona conectividad Ethernet, no es una buena práctica para las necesidades futuras. En cambio, los cuatro RJ-45 pares de conectores se deben conectar un extremo a otro.

Gigabit Ethernet Port Cables and Connectors.

Conexiones Gigabit Ethernet adoptan un enfoque diferente al ofrecer opciones modulares de conectividad. Switches Catalyst con puertos Gigabit Ethernet tienen aberturas rectangulares estandarizados que pueden aceptar gigabit interface converter (GBIC) o small form factor pluggable (SFP) modules. En cambio, el módulo correspondiente es intercambiable en caliente y está conectado al switch para soportar a los nuevos medios. Módulos GBIC pueden utilizar SC de fibra óptica y los conectores RJ-45 UTP. Módulos SFP pueden utilizar LC y MT-RJ de fibra óptica y los conectores RJ-45 UTP. Módulos GBIC y SFP están disponibles para los medios de Ethernet Gigabit siguiente:

1000BASE-SX- Conectividad de longitud de onda corta con conectores de fibra SC y MMF para distancias de hasta 550 m (1804 pies).

1000BASE-LX/LH- Conectividad LH-Long-wavelength/long-haul utilizando conectores de fibra SC y ya sea de fibra MMF o monomodo (SMF); MMF puede utilizarse para distancias hasta 550 m (1.804 pies), y SMF se pueden usar para distancias de hasta 10 km (32.810 pies). MMF requiere un cable especial modo de acondicionamiento para las distancias de fibra de menos de 100 m (328 pies) o superior a 300 m (984 pies). Esto evita que el GBIC saturen el receptor del extremo lejano de un cable corto y disminuye el efecto de retardo de modo diferencial en un cable largo.

1000BASE-ZX- Conectividad extendida a distancia utilizando conectores de fibra SC y SMF, trabaja para distancias de hasta 70 km, e incluso a 100 km cuando se utiliza con PremiumGrade SMF.

GigaStack—Utiliza un conector propietario con un cable de cobre de alta velocidad de datos con integridad de la señal y la interferencia rendimiento electromagnética (EMI), proporciona una conexión GBIC-to-GBIC entre apilar switches Catalyst o entre dos puertos de conmutación Gigabit a una distancia corta. La conexión es full duplex si sólo uno de los dos conectores de apilamiento se utiliza, si se utilizan ambos conectores, se cada uno se convierten en half duplex en un bus compartido.

1000BASE-T- Sports un conector RJ-45 para cuatro pares de cableado UTP, trabaja para distancias hasta 100 m (328 pies).

Nota-Debe utilizar una categoría 5 de cuatro pares (o superior) UTP cable cruzado para conectar dos puertos de conmutación 1000BASE-T back to back.

Precaución: Los módulos basados en fibra siempre tienen la receive fibra en el conector izquierdo y la fibra de transmisión en el conector de la derecha, según se mira los conectores. Estos módulos podrían producir radiación láser invisible desde el conector de


transmisión. Por lo tanto, mantener siempre conexiones no utilizadas con los tapones de goma, y ni se te ocurra mirar directamente a los conectores.

Switch Port Configuration

Selecting Ports to Configure

Para seleccionar un solo puerto del switch, ingrese el siguiente comando en el modo de configuración global:

Switch(config)# interface type module/number

El puerto se identifica por su tipo Ethernet (fastethernet, gigabitethernet, tengigabitethernet o VLAN), el módulo físico o "blade" a la que pertenece, y el número de puerto en el módulo. Algunos interruptores, como el Catalyst 2950 y 3560, no cuentan con múltiples módulos. Para los modelos, los puertos tienen un número de módulo de 0 (cero). A modo de ejemplo, la interfaz Fast Ethernet 0/14 se ha seleccionado para la configuración con el siguiente comando:

Switch(config)# interface fastethernet 0/14

El Catalyst 3750 es también un switch de configuración fija, pero puede ser stackeado con otros switches en la familia 3750. Las interfaces se hace referencia por el módulo y número de puerto, en donde el número de módulo representa la posición del switch en el stack. Por ejemplo, el puerto 24 en el interruptor en la posición 2 en la pila sería referenciado como Fast Ethernet 2/0/24.

Para seleccionar varios puertos arbitrarios para una opción de configuración común, se puede identificar como un "range" con entradas como una lista. Todos los números de puerto y las comas que los separan deben estar separados por espacios. Utilice el siguiente comando en el modo de configuración global:

Switch(config)# interface range type module/number [ , type module/number ...]

Por ejemplo, para seleccionar las interfaces Fast Ethernet 1/0/3, 1/0/7, 1/0/9 y 1/0/48 para la configuración, puede utilizar este comando:

Switch(config)# interface range fastethernet 1/0/3 , fastethernet 1/0/7 , fastethernet 1/0/9 , fastethernet 1/0/48

También puede seleccionar un rango continuo de puertos, desde una interfaz de inicio de una interfaz final. Introduzca el tipo de interfaz y el módulo, seguido por el número de puerto de inicio y termino separados por un guión con espacios. Utilice este comando en el modo de configuración global:

Switch(config)# interface range type module/first-number – last-number


Por ejemplo, podría seleccionar todos los 48 puertos Fast Ethernet en el módulo 1, con el siguiente comando:

Switch(config)# interface range fastethernet 1/0/1 - 48

Por último, a veces es necesario realizar cambios de configuración a varios grupos o rangos de puertos al mismo tiempo. Se puede definir una macro que contiene una lista de las interfaces o rangos de interfaces o ambos. A continuación, puede invocar la macro interfaz alcance justo antes de configurar los valores del puerto. Esto se aplica la configuración del puerto para cada interfaz que se identifica por la macro. Los pasos para definir y aplicar esta macro son los siguientes:

Paso 1. Defina el nombre de la macro y especificar tantas listas y rangos de interfaces, según sea necesario. La sintaxis del comando es abierta, pero sigue a la lista y la gama sintaxis de los comandos de campo interfaz definidos previamente:

Switch(config)# define interface-range macro-name type module/number [, type module/ number ...][type module/first-number – last-number] [...]

Paso 2. Invoque la macro llamada macro-nombre tal como lo haría con una interfaz regular, justo antes de entrar los comandos interfaz de configuración:

Switch(config)# interface range macro macro-name

A modo de ejemplo, supongamos que necesita configurar Gigabit Ethernet 2/0/1, 2/0/3 2/0/5, de, 3/0/1, 3/0/10 y 3/0/32 hasta el 3 de / 0/48 con un conjunto de configuraciones de la interfaz idénticos. Usted podría utilizar los siguientes comandos para definir y aplicar una macro, respectivamente:

Switch(config)# define interface-range MyGroup gig 2/0/1 , gig 2/0/3 – 2/0/5 , gig 3/0/1 , gig 3/0/10, gig 3/0/32 – 3/0/48

Switch(config)# interface range macro MyGroup

Identifying Ports

Para asignar un comentario o una descripción a un puerto, escriba el siguiente comando en el modo de configuración de interfaz:

Switch(config-if)# description description-string

La cadena de descripción se han incorporado espacios entre palabras, si es necesario. Para quitar una descripción, utilice el comando de configuración de interfaz no description.

Como un ejemplo, la interfaz Fast Ethernet 1/0/11 está marcado con "impresora en el edificio A, habitación 213":


Switch(config)# interface fast 1/0/11Switch(config-if)# description Printer in Bldg A, room 213

Port Speed

Para especificar la velocidad del puerto en un puerto Ethernet en particular, utilice el comando siguiente interfaz de configuración:

Switch(config-if)# speed {10 | 100 | 1000 | auto}

Port Duplex Mode

También puede asignar un modo de link específico con los switch port Ethernet - base. Por lo tanto, el puerto funciona en modo half-duplex, full-duplex o autonegotiated. Autonegotiation se permite sólo en UTP Fast Ethernet y Gigabit Ethernet. En este modo, el puerto participa en una negociación al intentar la operación full-duplex y luego halfduplex si la negociacion full duplex no se realiza correctamente. El proceso de negociación automática se repite cada vez que cambia de estado del link. Asegúrese de ajustar los dos extremos de un enlace a la misma velocidad y dúplex para eliminar cualquier posibilidad de que los dos extremos no coincidirá.

Para establecer el modo de enlace en un puerto del switch, ingrese el siguiente comando en el modo de configuración de interfaz:

Switch(config-if)# duplex {auto | full | half }

Managing Error Conditions on a Switch Port

Switches Catalyst pueden detectar condiciones de error automáticamente, sin más ayuda. Si se produce un error grave en un puerto de switch, ese puerto se puede apagar de forma automática hasta que alguien manualmente habilita el swich port de nuevo, o hasta que haya transcurrido un tiempo predeterminado.

Detecting Error Conditions


Por defecto, un switch Catalyst detecta una condición de error en cada puerto de switch para cada posible causa. Si se detecta una condición de error, el puerto del switch se pone en el estado errdisable y se desactiva. Puede ajustar este comportamiento a nivel mundial para que sólo ciertas causas provocan ningún puerto está desactivado. Utilice el siguiente comando en el modo de configuración global, donde se añade la no palabra clave para desactivar la causa específica:

Switch(config)# [ no] errdisable detect cause [ all | cause-name ]

■ all—Detects every possible cause

■ arp-inspection—Detects errors with dynamic ARP inspection

■ bpduguard—Detects when a spanning-tree bridge protocol data unit (BPDU) is received on a port configured for STP PortFast

■ channel-misconfig—Detects an error with an EtherChannel bundle

■ dhcp-rate-limit—Detects an error with DHCP snooping

■ dtp-flap—Detects when trunking encapsulation is changing from one type to another

■ gbic-invalid—Detects the presence of an invalid GBIC or SFP module

■ ilpower—Detects an error with offering inline power

■ l2ptguard—Detects an error with Layer 2 Protocol Tunneling

■ link-flap—Detects when the port link state is “flapping” between the up and down states

■ loopback—Detects when an interface has been looped back

■ pagp-flap—Detects when an EtherChannel bundle’s ports no longer have consistent configurations

■ psecure-violation—Detects conditions that trigger port security configured on a port

■ rootguard—Detects when an STP BPDU is received from the root bridge on an unexpected port

■ security-violation—Detects errors related to port security

■ storm-control—Detects when a storm control threshold has been exceeded on a port

■ udld—Detects when a link is seen to be unidirectional (data passing in only one direction)


■ unicast-flood—Detects conditions that trigger unicast flood blocking on a port

■ vmps—Detects errors when assigning a port to a dynamic VLAN through VLAN membership policy server (VMPS)

Automatically Recover from Error Conditions

De forma predeterminada, los puertos pone en el estado errdisable deben volver a habilitarse manualmente. Esto se hace mediante el comando shutdown en el modo de configuración de interfaz, seguido por el comando no shutdown. Antes de volver a habilitar un puerto de la condición errdisable, siempre debe determinar la causa del problema para que la condición errdisable no vuelva a ocurrir.

Usted puede decidir tener un interruptor de volver a activar automáticamente un puerto errdisabled si es más importante mantener el vínculo hasta que el problema se puede resolver. Para volver a activar automáticamente un puerto errdisabled, primero debe especificar las causas errdisable que se pueden volver a activarse. Utilice este comando en el modo de configuración global, con un nombre de la causa de la lista anterior:

Switch(config)# errdisable recovery cause [all | cause-name]

Si cualquier causa errdisable están configurados para la recuperación automática, el puerto errdisabled queda abajo durante 300 segundos, por defecto. Para cambiar el tiempo de recuperación, utilice el siguiente comando en el modo de configuración global:

Switch(config)# errdisable recovery interval seconds

Puede configurar el intervalo de 30 a 86.400 segundos (24 horas).

A modo de ejemplo, puede utilizar los siguientes comandos para configurar todos los puertos de conmutación que se vuelve a habilitar automáticamente en 1 hora después de una violación de port security violation que se ha detectado:

Switch(config)# errdisable recovery cause psecurity-violation

Switch(config)# errdisable recovery interval 3600

Recuerde que las causas errdisable y la recuperación automática se configuran globalmente los ajustes se aplican a todos los puertos del switch.

Enable and Use the Switch Port

Si el puerto no está habilitado o se activa automáticamente, utilice el comando de configuración de interfaz no shutdown. Para ver la velocidad actual del puerto y el estado dúplex, utilice el comando show interface. Se puede ver un resumen de todos los estados de interfaz con el comando show interfaces status.


Looking for the Port State

Use el comando EXEC show interfaces para ver la información completa sobre el puerto del switch. El estado actual del puerto se da en la primera línea de la salida, como en el ejemplo 3-2.

El primer UP le dice al estado de la capa de enlace físico o los datos del puerto. Si esto se muestra como Down, el enlace se desconecta físicamente o un enlace no puede ser detectada. El segundo estado, dado como line protocol is Up, muestra el estado de la Capa 2. Si el estado se da como errdisable, el interruptor ha detectado una condición de error grave en este puerto y ha desactivado automáticamente. Para ver rápidamente una lista de los estados de todos los puertos del switch, utilice el comando EXEC show interface status. Del mismo modo, se puede ver una lista de todos los puertos en el estado errdisable (y la causa) con el comando show interface status err-disabled.

Looking for Speed and Duplex Mismatches

Si un usuario se da cuenta el tiempo de respuesta lento o bajo rendimiento en un switch port 10/100 o 10/100/1000, el problema podría ser una mismatch de coincidencia de la velocidad del puerto o en el modo dúplex entre el switch y el host. Esto es particularmente común cuando un extremo del enlace está configurado para negociar automáticamente los ajustes de enlace y el otro extremo no lo esta. Utilice el comando show interface para una interfaz específica y buscar los recuentos de errores que son mayores que 0. Por ejemplo, en la siguiente salida en el Ejemplo 3-3, el swich port se encuentra en negociar automáticamente la velocidad y el modo dúplex. Se ha decidido por 100 Mbps en half duplex. Tenga en cuenta que hay muchos runts (paquetes que se truncan antes de ser plenamente recibidos) y input errors. Estos son síntomas que existe una falta de coincidencia ajuste entre los dos extremos del enlace.


Debido a que este puerto esté negociación automática la velocidad del enlace, debe de haber detectado una señal eléctrica que indica 100 Mbps en común con el host. Sin embargo, el host muy probablemente se ha configurado para 100 Mbps en full duplex (no negociación automática). El cambio no fue capaz de intercambiar información a doble cara, por lo que cayó de nuevo a su valor predeterminado de medio dúplex. Una vez más, asegúrese siempre de ambos extremos de una conexión se ponen a la misma velocidad y dúplex.

VLANs and Trunks

En redes de campus switcheadas se pueden dividir en diferentes dominios de difusión o LAN virtuales (VLAN). Una topología de red plana o una red con un único dominio de difusión, puede ser fácil de implementar y administrar. Sin embargo, la topología de red plana no es escalable. En cambio, el campus se puede dividir en segmentos mediante VLANs, mientras que la capa 3 protocolos de enrutamiento administran la comunicación intervlan.


En un entorno conmutado ofrece la tecnología para superar las limitaciones de la red planas. Redes de switching se pueden subdividir en VLANs. Por definición, una VLAN es un solo dominio de boradcast. Todos los dispositivos conectados a la Vlan reciven broadcast se envíen por otros miembros de la VLAN. Sin embargo, los dispositivos conectados a una VLAN diferente no recibirán el mismo broadcast. (Naturalmente, los miembros de la VLAN también reciben paquetes unicast dirigidas hacia ellos desde otros miembros de la VLAN.). Una VLAN se han conectado los miembros ubicados en cualquier parte del red del campus, siempre y cuando la conectividad VLAN se proporciona entre todos los miembros. Switches de Capa 2 están configurados con una asignación de VLAN y proporcionan la conectividad lógica entre los miembros de la VLAN.

VLAN Membership

Cuando una VLAN se proporciona en un interruptor de la capa de acceso, el usuario final debe tener algún medio para ganar pertenencia a la misma. Existen dos métodos de composición de los switches Cisco Catalyst:

■ Static VLAN configuration

■ Dynamic VLAN assignment

Static VLANs


Automáticamente asumen conectividad VLAN cuando se conectan a un puerto. Normalmente, el dispositivo final ni siquiera es consciente de que la VLAN existe. El puerto del conmutador y su VLAN sólo se ven y se utiliza como cualquier otro segmento de la red, con otros miembros "locally attached" en el alambre.

Los puertos de switch a las VLAN se asignan por la intervención manual del administrador de la red, de ahí el carácter estático. Cada puerto recibe una ID de VLAN (PVID) que se asocia con un número de VLAN. Los puertos en un solo interruptor se pueden asignar y agrupar en muchos VLANs. A pesar de que dos dispositivos están conectados al mismo conmutador, el tráfico no pasará entre ellos si están conectados a los puertos en diferentes redes VLAN. Para realizar esta función, se puede utilizar un dispositivo de Capa 3 para enrutar paquetes o un dispositivo externo de la capa 2 para cerrar los paquetes entre las dos VLANs.

La membresía estática de puerto a VLAN normalmente se maneja de hardware con los circuitos integrados applicationspecific (application specific integrated circuits) (ASIC) en el interruptor. Esta membresía ofrece un buen rendimiento, ya que todas las asignaciones de puertos se realizan a nivel de hardware, sin búsquedas en tablas complejas necesarias.

Configuring Static VLANs

En esta sección se describen los comandos de conmutación necesarios para configurar VLAN estáticas. Por defecto, todos los puertos del switch se asignan a VLAN 1 se han establecido como un tipo de VLAN de Ethernet, y tienen una unidad de transmisión máxima (MTU) tamaño de 1500 bytes.

En primer lugar, la VLAN se debe crear en el switch, si no existe ya. Entonces, la VLAN se debe asignar a los switch port específicos. VLANs siempre se hace referencia a un Número de VLAN, que puede variar de 1 a 1005. VLAN 1 y 1002 a través de 1005 automáticamente se crean y se reservan para usos especiales. Por ejemplo, VLAN 1 es la VLAN por defecto para cada puerto de switch. VLANs 1002-1005 están reservados para las funciones existentes relacionados con Token Ring y FDDI conmutación.

Switches IOS Catalyst también soporta VLAN de rango extendido, en el que el número de VLAN puede ser desde 1 hasta 4094, para ser compatible con el estándar IEEE 802.1Q. El rango extendido se activa sólo cuando el conmutador está configurado para el modo VTP transparente con el modo VTP transparente comando de configuración global. Esto es debido a las limitaciones de versiones de VTP 1 y 2. VTP Versión 3 no permitir VLAN de alcance ampliado que se utilizarán y la publicidad, pero esta versión no está disponible en los switches Catalyst IOS en este momento. (VTP se trata en el capítulo 5, "Protocolo de Trunking VLAN.")

Tips: Aunque la amplia gama de números de VLAN permite un apoyo más, Existen VLAN en la red algunas limitaciones. Por ejemplo, un interruptor normalmente mantiene definiciones de VLAN en un archivo de base de datos especial, separado de la configuración del conmutador. El VLAN Trunking protocol (VTP) utiliza la base de datos VLAN para que las definiciones de VLAN pueden ser publicitados y compartidos entre


switches a través de enlaces troncales. Cuando se crean las VLAN de rango extendido, que no se almacenan en el archivo de base de datos de la VLAN. ¿Por qué es importante? Mientras el interruptor permanece en el modo VTP transparente, las VLAN extendidos se pueden utilizar. Sin embargo, si el interruptor está configurado después para participar en VTP como un servidor o un cliente, debe eliminar manualmente las VLAN extendidas. Para los switch port que se asignan a las VLAN extendidas, también debe volver a configurar las membresias de vlan a la VLAN dentro de la gama normal de VLAN.

Para configurar VLAN estáticas, comenzar por definir la VLAN con el comando siguiente en el modo de configuración global:

Switch(config)# vlan vlan-num

Switch(config-vlan)# name vlan-name

La VLAN numerada vlan-num es creada inmediatamente y se almacena en la base de datos, junto con una cadena de texto descriptivo definido por vlan-nombre (hasta 32 caracteres, sin espacios incrustados). El comando nombre es opcional, si no se utiliza, el nombre de la VLAN por defecto es de la forma VLAN XXX, donde XXX representa el número de VLAN. Si es necesario incluir espacios para separar las palabras en el nombre de VLAN, utilice caracteres de subrayado en su lugar.

A modo de ejemplo, puede utilizar los siguientes comandos para crear las VLAN 2 y 101:

Switch(config)# vlan 2Switch(config-vlan)# name EngineeringSwitch(config-vlan)# vlan 101Switch(config-vlan)# name Marketing

Para eliminar una VLAN de la configuración del switch, puede utilizar el comando no vlan vlan-num. A continuación, debe asignar uno o Más Puertos de cambiar a la VLAN. Utilice el siguiente comando comandos de configuracion:

Switch(config)# interface type module/numberSwitch(config-if)# switchportSwitch(config-if)# switchport mode accessSwitch(config-if)# switchport access vlan vlan-num

El comando inicial switchport configura el puerto para operar en capa 2. En la mayoría de los switches Catalyst los switch port su operación por default es en capa 2. En el caso, el Switch port debera de ya estar presente en la configuración y usted no necesitara ingresar explicitamente. De otra manera. el switch rechazara cualquier comando de configuración de capa 2 si el puerto no se encuentra configurado para operar en capa 2. El comando switchport mode access obliga al puerto que se asignará a sólo una única VLAN, proporcionando conectividad VLAN a la capa de acceso o el usuario final. El puerto recibe Referencia: Switch Operation for the CCNP BCMSN Exam, By David Hucaby.

una membresía de VLAN estática con el comando switchport access vlan. Aquí, la VLAN lógica hace referencia a la configuración de vlan-num (1-1005 o 1-4094).

Para comprobar la configuración de VLAN, utilice el comando show vlan para generar una lista de todas las VLAN definidas en el switch, junto con los puertos que se asignan a cada VLAN. Ejemplo 4-1 muestra un ejemplo de salida del comando show vlan.

Dynamic VLANs

VLANs dinámicas proporcionan membresía basada en la dirección MAC de un dispositivo de usuario final. Cuando un dispositivo está conectado a un puerto del switch, el switch debe, en efecto, consultar una base de datos para establecer la pertenencia a la VLAN. Un administrador de red debe asignar la dirección MAC del usuario a una VLAN en la base de datos de un servidor de suscripción Política de VLAN (VMPS). Con los switches de Cisco, se crean VLANs dinámicas y gestionar el uso de herramientas de gestión de red, como CiscoWorks. VLAN dinámicas permiten una gran cantidad de flexibilidad y movilidad para los usuarios finales, pero requieren más sobrecarga administrativa.

Deploying VLANs

Para implementar las VLAN, debe tener en cuenta el número de VLANs que necesita y la mejor forma de colocarlos. Como es habitual, el número de VLAN depende de los patrones de tráfico, tipos de aplicaciones, la segmentación de los grupos de trabajo comunes, y los requisitos de gestión de red.

Un factor importante a considerar es la relación entre las VLAN y los esquemas de direccionamiento IP utilizadas. Cisco recomienda un uno-a-uno entre las VLAN y subredes IP. Esta recomendación significa que si una subred con una máscara de 24 bits (255.255.255.0) se utiliza para una VLAN, no más de 254 dispositivos deben estar en la VLAN. Además, no debe permitir que las VLAN que se extienden más allá del dominio de


capa 2 del switch de distribución. En otras palabras, la VLAN no debe llegar a través de una red de core y en otro bloque de interruptores. La idea es de nuevo para mantener las emisiones y el movimiento de tráfico innecesario fuera del bloque central. Las VLAN se pueden escalar en el panel de control mediante el uso de dos métodos básicos:

■ End-to-end VLANs

■ Local VLANs

End-to-End VLANs

VLAN de extremo a extremo, también llamado VLAN en todo el campus, abarcan toda la estructura de switcheo de una red. Ellos están en condiciones de soportar la máxima flexibilidad y movilidad de los dispositivos finales. Los usuarios pueden ser asignados a las VLAN, independientemente de su ubicación física. Como usuario mueve alrededor del campus, pertenencia a la VLAN de ese usuario sigue siendo el mismo. Esto significa que cada VLAN debe estar disponible en la capa de acceso en cada bloque switch. VLAN de extremo a extremo deben agrupar los usuarios según las necesidades comunes. Todos los usuarios de una VLAN deberían tener más o menos los mismos patrones de flujo de tráfico, siguiendo la regla 80/20. Recordemos que esta norma estima que el 80 por ciento del tráfico del usuario se mantiene dentro del grupo de trabajo local, mientras que el 20 por ciento está destinado a un recurso remoto en la red del campus. Aunque se espera que sólo el 20 por ciento del tráfico en una VLAN pueda cruzar el core de la red, de extremo a extremo VLAN permiten que el 100 por ciento del tráfico en una sola VLAN para cruzar el CORE. Debido a que todas las VLAN deben estar disponibles en cada conmutador de capa de acceso, enlace troncal de VLAN debe ser utilizado para llevar a todas las VLAN entre los conmutadores de acceso-y-capa de distribución.

Tip: VLAN de extremo a extremo no se recomiendan en una red de empresa, a menos que haya una buena razón. En un extremo-a-extremo de VLAN, el tráfico de broadcast se realiza sobre de un extremo de la red a la otra, creando la posibilidad de que una tormenta de difusión o en la capa 2 bridging loop se extiendad por toda la extensión de una VLAN. Esto puede agotar el ancho de banda de los enlaces de distribución y de capa de Core, así como los recursos de CPU del switch. Ahora la tormenta o bucle tiene los Usuarios interrumpidas en el Extremo-a-Extremo de VLAN, ademas de los Usuarios de Otras Redes VLAN Que podrían Estar Cruzando el Core.

Local VLANs

Porque la mayoría de las redes empresariales se han movido hacia la regla 20/80 (en donde los recursos de Internet y servidor de intranet / están centralizados), de extremo a extremo de redes VLAN han hecho muy pesado y difícil de mantener. La regla 20/80 invierte el patrón de tráfico del extremo-a-extremo de VLAN: Sólo el 20 por ciento del tráfico es local, mientras que el 80 por ciento está destinado a un recurso remoto a través de la capa de Core. Los usuarios finales por lo general requieren el acceso a los recursos centrales


fuera de la VLAN. Los usuarios deben cruzar en el Core de la red con más frecuencia. En este tipo de red, VLAN deben ser diseñados para contener las comunidades de usuarios sobre la base de los límites geográficos, con poca consideración a la cantidad de tráfico que sale de la VLAN.VLANs locales o geográficas varían en tamaño de un solo switch en un wiring closet de un edificio entero. VLANs Arreglos de esta manera permite la función de la capa 3 de la red del campus para manejar inteligiblemente las cargas de tráfico intervlan, donde el tráfico pasa en el núcleo. Este escenario ofrece la máxima disponibilidad mediante varias rutas a los destinos, la máxima escalabilidad, manteniendo la VLAN dentro de un bloque de interruptores y máxima manejabilidad.

VLAN Trunks

Recuerde, el envío de información de un enlace de acceso en una VLAN a otra VLAN no es posible sin la intervención de un dispositivo, ya sea un router adicional de capa 3 o un puente capa externa 2.

Un enlace troncal, sin embargo, puede transportar más de una VLAN a través de un solo switch port.Los enlaces Trunk son más beneficiosas cuando los switches están conectados a otros switches o switches conectados a los routers. Un enlace troncal no está asignado a una VLAN específica. En cambio, una, varias o todas las VLAN activas pueden ser transportados entre los switches que utilizan un solo enlace troncal física.


Cisco admite enlaces troncales en tanto Fast Ethernet y Gigabit enlaces conmutación Ethernet y agregados enlaces Fast EtherChannel y Gigabit. Para distinguir entre el tráfico que pertenecen a diferentes VLAN en un enlace troncal, el switch debe tener un método de identificación de cada trama con la VLAN apropiada. Los switches en cada extremo de un enlace troncal tanto deben tener el mismo método para la correlación de los marcos con números de VLAN. La siguiente sección se refiere a varios métodos de identificación disponibles.

VLAN Frame Identification

Identificación Frame o etiquetado, asigna un identificador único definido por el usuario para cada frame transportado en un enlace troncal. Piense en esto como el número ID de


VLAN o VLAN "color", como si cada VLAN se dibuja en un diagrama de red en un color único.

VLAN de identificación del chasis fue desarrollado para redes conmutadas. A medida que se transmite cada trama sobre un enlace troncal, un identificador único se coloca en el encabezado de la trama. A medida que cada switch en el camino recibe estos marcos, el identificador se examina para determinar a qué VLAN pertenecen los frames y luego se retira. Si las frames deben ser transportados a otro enlace troncal, se añade el identificador VLAN de nuevo en el encabezado de la trama. De lo contrario, si las tramas están destinados a cabo un enlace de acceso (nontrunk), el interruptor elimina el identificador de VLAN antes de transmitir las tramas a la estación final. Por lo tanto, todos los rastros de la asociación de VLAN se ocultan de la estación final.

La identificación de VLAN se puede realizar utilizando dos métodos, cada uno utilizando un mecanismo de identificador de trama diferente:

■ Inter-Switch Link (ISL) protocol

■ IEEE 802.1Q protocol

Inter-Switch Link Protocol

El Inter-Switch Link protocol (ISL) es un método propietario de Cisco para la conservación de laIdentificación de fuentes de VLAN de las tramas que pasan a través de un enlace troncal. ISL realiza la identificación frames en la capa 2 mediante la encapsulación de cada trama entre una header y un trailer.

Cuando una trama está destinada a cabo un enlace troncal a otro switch o router, ISL añade una cabecera de 26 bytes y un trailer de 4 bytes en la trama. La fuente de VLAN se identifica con un campo ID de VLAN de 15 bits en la cabecera. El trailer contiene una comprobación de redundancia cíclica (CRC) valor para garantizar la integridad de los datos de la nueva trama encapsulada.


IEEE 802.1Q Protocol

Como con Cisco ISL, IEEE 802.1Q se puede utilizar para la identificación de VLAN con troncos de Ethernet. Sin embargo, en lugar de encapsular cada marco con un cabezazo ID de VLAN y el remolque, 802.1Q incrusta la información de etiquetado dentro de la trama de Capa 2. Este método se conoce como único marcado o etiquetado interna.

802.1Q también introduce el concepto de una VLAN nativa en una troncal. Frames pertenecientes a esta VLAN no están encapsulados con cualquier información de etiquetado. Si una estación final está conectado a un enlace troncal 802.1Q, la estación final puede recibir y comprender únicamente las frames de VLAN nativas. Esto proporciona una forma sencilla de ofrecer full trunk encapsulation de los dispositivos que pueden entender que, al tiempo que las estaciones normales de acceso a cierta conectividad inherente sobre el trunk.

Los dos primeros bytes se utiliza como Tag Protocol Identifier (TPID) y siempre tienen un valor de 0x8100 para indicar una etiqueta 802.1Q. Los dos bytes restantes se utilizan como información de control de TCI (Tag) de campo. La información TCI contiene un campo de prioridad de tres bits, que se utiliza para implementar funciones de acompañamiento en el estándar de priorización 802.1Q/802.1p de clase de servicio (CoS). Un poco de la TCI es un indicador de formato canónico (CFI), marcar si las direcciones MAC son en formato Ethernet o Token Ring. (Esto también se conoce como formato canónico o formato little-endian o big-endian). Los últimos 12 bits se usan como un identificador de VLAN (VID) para indicar la fuente de la VLAN para la frame. El VID puede tener valores de 0 a 4095, pero las VLAN 0, 1, y 4.095 son reservados.

Debido a las tramas Ethernet no pueden exceder 1518 bytes, La información adicionales de etiquetado VLAN puede hacer que la frame se vuelva demasiado grande. frames, que apenas superan el tamaño MTU se denominan tramas baby giant frames. Interruptores generalmente reportan estos marcos como errores de Ethernet o marcos de gran tamaño.

Dynamic Trunking Protocol


Puede configurar manualmente los enlaces troncales en los switches Catalyst, ya sea para ISL o 802.1Qmodo. Además, Cisco ha puesto en marcha un protocolo propietario, punto a punto denominado protocolo de enlace troncal dinámico Dynamic Trunking Protocol (DTP), que negocia un modo de enlace común entre dos switches. La negociación cubre la encapsulación (ISL o 802.1Q) y si el enlace se convierte en un trunk en absoluto. Esto permite que los enlaces troncales para ser utilizados sin una gran cantidad de configuración manual o administración. El uso de la vacuna DTP se explica en la siguiente sección.

VLAN Trunk Configuration

VLAN Trunk Configuration

Utilice los siguientes comandos para crear un enlace troncal de VLAN:

Switch(config)# interface type mod/portSwitch(config-if)# switchportSwitch(config-if)# switchport trunk encapsulation {isl | dot1q | negotiate }Switch(config-if)# switchport trunk native vlan vlan-idSwitch(config-if)# switchport trunk allowed vlan {vlan-list | all |{add | except | remove} vlan-list}Switch(config-if)# switchport mode {trunk | dynamic {desirable | auto}}

■ Isl—VLANs are tagged by encapsulating each frame using the Cisco ISL protocol.

■ dot1q—VLANs are tagged in each frame using the IEEE 802.1Q standard protocol. The only exception is the native VLAN, which is sent normally and is not tagged.

■ negotiate (the default)—The encapsulation is negotiated to select either ISL or IEEE 802.1Q, whichever both ends of the trunk support. If both ends support both types, ISL is favored.

En el caso de un enlace trunk 802.1Q IEEE, debe configurar la VLAN nativa con el comando switchport trunk native vlan, identificando el número de VLAN no etiquetada o nativas como vlan-id (1-4094). Por defecto, un enlace troncal 802.1Q utiliza VLAN 1 como la VLAN nativa. En el caso de una troncal ISL, el uso de este comando no tiene efecto porque ISL no admite una VLAN sin etiqueta.

El último comando switchport trunk allowed vlan, define qué VLAN se pueden trunked sobre el enlace. De forma predeterminada, un switch transporta todas las VLAN activas (1-4094) sobre un enlace troncal. Una VLAN activa es aquella que se encuentra definida en el switch y tiene puertos asignados a ella. Usted puede adaptar la lista de las VLAN permitidas en el tronco con el comando switchport trunk allowed vlan alguna de las opciones siguientes:


■ vlan-list—An explicit list of VLAN numbers, separated by commas or dashes.

■ all—All active VLANs (1 to 4094) will be allowed.

■ add vlan-list —A list of VLAN numbers will be added to the already configured list; this is a shortcut to keep from typing a long list of numbers.

■ except vlan-list —All VLANs (1 to 4094) will be allowed, except for the VLAN numbers listed; this is a shortcut to keep from typing a long list of numbers.

■ remove vlan-list —A list of VLAN numbers will be removed from the already configured list; this is a shortcut to keep from typing a long list of numbers.

En el comando switchport mode, se puede establecer el modo de enlace troncal de cualquiera de los siguientes:

Trunk- Este ajuste coloca el puerto en modo trunking permanente. DTP sigue funcionando, por lo que si el puerto del switch del extremo lejano está configurado para trunk, dynamic desirable,dynamic auto mode, trunking se negoció con éxito.

Dynamic Desirable (default)- El puerto intenta activamente para convertir el enlace en modo trunk. En otras palabras, se "pide" al switch del extremo lejano levantar un enlace trunk. Si el switchport del extremo lejano está configurado en modo trunk, , dynamic desirable o dynamic auto mode , trunking se negoció con éxito.

Dynamic auto— El Puerto se puede convertir en un enlace trunk, pero sólo si el extremo lejano cambiar solicitan activamente. Por lo tanto, si el switchport de extremo lejano está configurado para trunk o dynamic desirable, trunking se negocia. Debido a que el comportamiento de negociación pasiva, el enlace nunca se convierte en un trunk si ambos extremos del enlace se dejan a la forma predeterminada de dynamic auto.

Para ver el estado de enlace trunk en un puerto de switch, utilice el comando show interface type mod/porttrunk , como se demuestra en el ejemplo 4-2.


Trunk Configuration Example

El enlace trunk debe utilizar la encapsulación 802.1Q, con VLAN 100 como VLAN nativa. En primer lugar, configurar Switch-D para negociar activamente un tronco con el interruptor del extremo lejano. Usted podría utilizar los siguientes comandos de configuración de Switch-D:

Switch-D(config)# interface gigabitethernet 2/1Switch-D(config-if)# switchport trunk encapsulation dot1qSwitch-D(config-if)# switchport trunk native vlan 100Switch-D(config-if)# switchport trunk allowed vlan 100-105Switch-D(config-if)# switchport mode dynamic desirable

En este punto, se estima que el switch A está configurado correctamente, también. Ahora, usted debe tratar de verificar que el trunk está funcionando como se esperaba. El switch D, se puede ver el estado del trunk con el siguiente comando:

Para su sorpresa, el estado del tronco es no-trunking. A continuación, debe comprobar que el enlace físico esta UP:


¿Qué podría estar impidiendo que el trunk se establezca? Si el switch D se encuentra en modo de negociación dynamic desirable negotiation mode, que está pidiendo activamente Cambiar A para abrir un trunk. Obviamente, switch A no debe estar de acuerdo. El modo dynamic desirable puede negociar un trunk con el resto de modos de trunking, por lo Cambiar de una interfaz no debe estar configurado para trunking. En su lugar, lo más probable es configurado como un puerto de acceso (acceso switchport mode).

El switch A se puede corregir mediante la configuración de su Gigabit Ethernet 2/1 interfaz para negociar un trunk. Switch D está en el modo dynamic desirable, por lo Interruptor A podría utilizar trunk, modo automático deseable, o dinámica dinámico. Ahora, supongamos que te das cuenta de VLAN 103 no se debe pasar entre estos interruptores. Puede utilizar cualquiera de las siguientes secuencias de comandos para podar manualmente VLAN 103 del tronco:

Cuando podar manualmente VLAN de que se les permita en un tronco, la misma operación se debe realizar en ambos extremos del enlace trunk. De lo contrario, uno de los dos interruptores todavía podría inundar la retransmisión de ese VLAN en el trunk, el uso de ancho de banda innecesario en una sola dirección.

Para completar, la configuración del switch A en este momento sería el siguiente aspecto:

Troubleshooting VLANs and Trunks


Si un ordenador en una ubicación no puede comunicarse con un PC en otra ubicación, donde ambos son asignados a la misma subred IP, asegúrese de que ambos sus switchports estan configurados para la misma VLAN. Si lo están, examinar la ruta de acceso entre los dos. Se realiza continuamente la VLAN a lo largo de la ruta de acceso? Si hay trunks en el camino, es la VLAN está llevando a través de los trunks?

Para comprobar la configuración de una VLAN en un switch, utilice el comando show vlan vlan-id, como se demuestra en el Ejemplo 4-3. Asegúrese de que la VLAN se muestre por tener un estado activo y que ha sido asignado a los puertos del switch correctos.

Para un trunk, estos parámetros deben ser agradable en ambos extremos antes de que el trunk puede funcionar correctamente:

- Trunking mode (unconditional trunking, negotiated, or non-negotiated).

- Trunk encapsulation (ISL, IEEE 802.1Q, or negotiated through DTP).

- Native VLAN. You can bring up a trunk with different native VLANs on each end; however, both switches will log error messages about the mismatch, and the potential exists that traffic will not pass correctly between the two native VLANs.

- The native VLAN mismatch is discovered through the exchange of CDP messages, not through examination of the trunk itself. Also, the native VLAN is configured independently of the trunk encapsulation, so it is possible to have a native VLAN mismatch even if the ports use ISL encapsulation. In this case, the mismatch is only cosmetic and won’t cause a trunking problem.


-Allowed VLANs. By default, a trunk allows all VLANs to be transported across it. If one end of the trunk is configured to disallow a VLAN, that VLAN will not be contiguous across the trunk.

Para ver una comparación de cómo se configura un switch port para trunking versus su estado activo, utilice el comando show interface type mod/num switchport , como se demuestra en el ejemplo 4-4. Busque los valores administrativos frente operativo, respectivamente, para ver si el tronco está funcionando como lo configuró.

Tenga en cuenta que el puerto se ha configurado para negociar una trunk a través DTP (dinámicoautomático), pero el puerto está funcionando en el modo acceso estático (nontrunking). Esto debería decirles que ambos extremos del enlace probablemente están configurados para el modo automático para que ni activamente solicitará un trunk.

Para obtener información más concisa sobre un puerto trunking, puede utilizar el comando show interface


[type mod/num] trunk, como se demuestra en el ejemplo 4-5.

Una vez más, se dio cuenta de que el puerto está en modo de negociación automática, pero en este momento no-trunking. Debido a que el puerto no está trunking, sólo el acceso VLAN (VLAN 1 en este ejemplo) aparece como permitido y activa en el tronco. Para ver si y cómo DTP se está utilizando en un switch, utilice el comando show dtp [interface type mod/num]. Especificación de una interfaz muestra la actividad de DTP con mayor detalle.

VLAN Trunking Protocol

Cisco ha desarrollado un método para gestionar VLANs a través de la red del campus. El VLAN Trunking Protocol (VTP) utiliza trunk frames de capa 2 para comunicar información de VLAN en un grupo de switches. VTP gestiona la adición, eliminación y cambio de nombre de VLAN a través de la red desde un punto central de control. Cualquier switch de participar en un intercambio de VTP es consciente de, y puede utilizar cualquier VLAN que gestiona VTP.

VTP Domains

VTP está organizado en dominios de gestión, o en áreas con requisitos comunes VLAN. Un switch puede pertenecer a un solo dominio VTP, además de compartir la información de VLAN con otros switches en el dominio. Switches en diferentes dominios VTP, sin embargo, no comparten información VTP.

Switches en un dominio VTP anuncian varios atributos a sus vecinos de dominio. Cada anuncio contiene información sobre el dominio de VTP gestión, número de revisión VTP, VLAN conocidos, y los parámetros específicos de VLAN. Cuando se añade una VLAN a un switch en un dominio de gestión, otros switches son notificados de la nueva VLAN a través de VTP advertisements. De esta manera, todos los switches en un dominio puede prepararse para recibir el tráfico en sus puertos troncales con la nueva VLAN.Referencia: Switch Operation for the CCNP BCMSN Exam, By David Hucaby.

VTP Modes

Para participar en un dominio de gestión de VTP, cada switch debe estar configurado para operar en uno de varios modos. El modo VTP determina cómo los procesos de conmutación y anuncia información VTP. Puede utilizar los siguientes modos:

Server Mode-Servidores modo de VTP Server tienen un control total sobre la creación de VLAN y modificación para sus dominios. Toda la información VTP se anuncia a otros switches en el dominio, mientras que toda la información recibida VTP está sincronizado con los otros conmutadores. Por defecto, un interruptor se encuentra en modo de servidor VTP. Tenga en cuenta que cada dominio VTP debe tener al menos un servidor para que las VLAN se pueden crear, modificar o eliminar, y la información de VLAN se puede propagar.

Client Mode- VTP cliente no permiten al administrador crear, cambiar o eliminar las VLAN. Por el contrario, escuchar a los anuncios VTP de otros switches y modificar sus configuraciones de VLAN en consecuencia. En efecto, este es un modo de escucha pasiva. La informacion recibida de VTP se transmite por los enlaces troncales a los switches vecinos en el dominio, por lo que el switch también actúa como un relé de VTP.

Transparent Mode- Switches en modo VTP transparente no participan en VTP. mientras que enmodo transparente, un switch no hace publicidad de su propia configuración de VLAN, El switch no sincroniza su base de datos de VLAN con los anuncios recibidos, En VTP versión 1, Un switch en modo trasparente incluso no hace relay información de VTP es recibida para otros switches a menos que sus nombres de dominio VTP y numeros de versión VTP coincidieran con los de los otros switches. En VTP versión 2, transparent switches hacen envio de publicaciones VTP recibidas atravez de sus puertos trunks, actuando como relay de VTP. Esto ocurre independientemente de la configuración del nombre de dominio VTP.

VTP Advertisements

Cada switch Cisco anuncia la participación en VTP VLAN (VLAN sólo 1-1005), números de revisión, y los parámetros de la VLAN atravez de sus puertos trunks para notificar a otros switches en el dominio de gestión. Publicaciones VTP se envían como multicast frames. El switch intercepta las frames enviados a la dirección de multicast VTP y las procesa con su procesador de supervisor. Frames VTP se envían a los enlaces trunks como un caso especial.

De forma predeterminada, los dominios de gestión están configurados para utilizar anuncios no seguras sin una contraseña. Usted puede agregar una contraseña para establecer el dominio en modo seguro. La misma contraseña se debe configurar en cada


interruptor en el dominio para que todos los conmutadores intercambien información VTP utiliza métodos de cifrado idénticos.

Switches VTP utilizan un índice llamado el número de revisión de configuración VTP para realizar un seguimiento de la información más reciente. Cada switch en un dominio VTP almacena el número de revisión de configuración que se oyó por última vez de un anuncio VTP. El proceso de anuncio VTP siempre comienza con la configuración de revisión número 0 (cero).

Cuando los cambios posteriores se realizan en un servidor VTP, el número de revisión se incrementa antes de que se envían los anuncios. Cuando los switches de escucha (configurado como miembros del mismo dominio VTP como el switch de publicidad) reciben un anuncio con un mayor número de revisión que se almacena localmente, el anuncio sobrescribe cualquier información de la VLAN almacenada.

Debido a esto, es muy importante para forzar siempre cualquier switch de red recién añadidos a tener un número de revisión 0 antes de ser conectado a la red. De lo contrario, un switch podría haber almacenado un número de revisión que es mayor que el valor actualmente en uso en el dominio.

El número de revisión VTP se almacena en la memoria NVRAM y no se ve alterada por un reinicio de alimentación del switch. Por lo tanto, el número de revisión se inicializa a 0 solamente usando uno de los siguientes métodos:

- Cambiar el modo de VTP del switch a transparente y cambie el modo de vuelta a modo servidor.

- Cambiar de dominio VTP del cambio a un nombre falso (un dominio VTP inexistente), y luego cambiar el dominio VTP de nuevo al nombre original.

Si el número de revisión VTP no se restablece a 0, el switch podría entrar en la red como un servidor VTP y tienen un número de revisión pre-existente (de una vida anterior) que es mayor que en anuncios legítimos anteriores. Información VTP del nuevo switch sería visto como más reciente, por lo que todos los otros switches en el dominio VTP con mucho gusto acepte su base de datos de la VLAN y sobrescribir sus buenos registros de bases de datos con información sobre el estado de VLANs nulas o eliminadas.

En otras palabras, un nuevo switch servidor podría inadvertidamente provocar que cualquier otro switch de funcionamiento para vaciar todos los registros de todas las VLAN en la producción. Las VLAN se eliminan de la base de datos VTP y de los switches, haciendo cualquier puerto del switch que se les asigna a ser inactivos. Esto se conoce como un problema de sincronización de VTP. Por partes críticas de su red, usted debe considerar utilizar el modo VTP transparente para evitar el problema de sincronización de llegar a ser nunca un problema.

Summary advertisements— Servidores de dominio VTP envían anuncios de resumen cada 300 segundos y cada vez que se produce un cambio de base de datos VLAN. El Referencia: Switch Operation for the CCNP BCMSN Exam, By David Hucaby.

resumen anuncio enumera información sobre el dominio de gestión, incluyendo la versión VTP, nombre de dominio, número de revisión de configuración, marca de tiempo, MD5 código hash cifrado, y el número de anuncios subconjunto de seguir. Para los cambios de configuración de VLAN, resumen de avisos son seguidos por uno o más anuncios subconjunto con los datos de configuración de VLAN más específicos. La Figura 5-1 muestra el formato de anuncio de resumen.

Subset advertisements—Servidores de dominio VTP envían anuncios de subset después de producirse un cambio de configuración VLAN. Estos anuncios muestran los cambios específicos que se han realizado, como la creación o eliminación de una VLAN, la suspensión o la activación de una VLAN, cambiar el nombre de una VLAN, y el cambio de unidad de transmisión máxima de una VLAN (MTU). Anuncios de subset pueden enumerar los siguientes parámetros de VLAN: estado de la VLAN, tipo de VLAN (como Ethernet o Token Ring), MTU, LENGTHOF el nombre de VLAN, número de VLAN, el valor de identificador de asociación de seguridad (SAID), y Nombre de la VLAN. Las VLAN se enumeran por separado en los anuncios subset secuenciales.

Advertisement requests from clients— Un cliente de VTP puede solicitar cualquier información de la VLAN que le falta. Por ejemplo, un switch de cliente podría ser reseteado y tener su base de datos de VLAN se aclaró, y su pertenencia al dominio VTP puede ser cambiado, o puede escuchar un anuncio de resumen VTP con un número de revisión mayor del que tiene actualmente. Después de una solicitud advertisement cliente, los servidores de dominio VTP responden con sumarios y subset anuncios para ponerla al día. Switches Catalyst en modo de servidor VTP almacén de información por separado de la configuración del switch en la NVRAM. Datos VLAN y VTP se guardan en el archivo vlan.dat en el sistema de archivos de memoria flash del switch. Toda la información VTP, incluido el número de revisión de configuración VTP, se mantiene incluso cuando el switch es apagado. De esta manera, un interruptor puede recuperar la última configuración de la VLAN conocido a partir de su base de datos VTP después de que se reinicia.

VTP Configuration

De forma predeterminada, cada switch funciona en modo de servidor VTP para el management domain NULL (a blank string), sin contraseña o modo seguro. Si el switch oye un anuncio de resumen VTP en un puerto de trunk de cualquier otro switch, que aprende automáticamente el nombre de dominio VTP, VLAN, y el número de revisión de configuración que oye. Esto hace que sea fácil para que aparezca un nuevo switch en un dominio VTP existente. Sin embargo, tenga en cuenta que el nuevo switch permanece en modo de servidor VTP, algo que podría no ser deseable.

Tip: Usted debe adquirir el hábito de double check sobre la configuración de VTP de cualquier cambio antes de agregarlo a su red. Asegúrese de que el número de revisión de configuración VTP se establece en 0. Usted puede hacer esto mediante el aislamiento del switch de la red, ponerlo en marcha y con el comando show vtp status, como se demuestra en la siguiente salida:Referencia: Switch Operation for the CCNP BCMSN Exam, By David Hucaby.

Switch# show vtp statusVTP Version : 2Configuration Revision : 0Maximum VLANs supported locally : 1005Number of existing VLANs : 5VTP Operating Mode : ServerVTP Domain Name :VTP Pruning Mode : DisabledVTP V2 Mode : DisabledVTP Traps Generation : DisabledMD5 digest : 0x57 0xCD 0x40 0x65 0x63 0x59 0x47 0xBDConfiguration last modified by 0.0.0.0 at 0-0-00 00:00:00

Aquí, el switch tiene un número de revisión de configuración de 0, y está en el estado por defecto del modo de servidor VTP con un nombre de dominio de VTP indefinido. Sería seguro para añadir este switch a la red.

Las siguientes secciones explican los comandos y las consideraciones que se deben utilizar para configurar un switch para el funcionamiento de VTP.

Debe tener en cuenta que hay dos formas admitidas para configurar VLAN y VTP información en un switch catalyst IOS:

■ Global configuration mode commands (for example, vlan , vtp mode, and vtp domain)

■ VLAN database mode commands

El comando vlan EXEC base de datos todavía se apoya en catalizador de IOS Software sólo para compatibilidad con versiones anteriores, pero esto no está cubierto en el curso interruptor o el examen.

Configuring a VTP Management Domain.

Antes de añadir un switch en una red, se debe identificar el dominio de administración VTP. Si este switch es el primero en la red, se debe crear el management domain. De lo contrario, el switch podría tener que unirse a un dominio de gestión existente con otros switches existentes.

Usted puede utilizar el siguiente comando de configuración global para asignar un switch a un management domain, donde el nombre de dominio es una cadena de texto de hasta 32 caracteres de longitud:

Switch(config)# vtp domain domain-name


Configuring the VTP Mode

Server mode— El modo de servidor se puede utilizar en cualquier switch en un dominio de gestión, incluso si otro switch servidor y cliente están en uso. Este modo proporciona cierta redundancia en caso de fallo del servidor en el dominio. Cada dominio de gestión de VTP debe tener al menos un servidor. El primer servidor definido en una red también define el dominio de gestión que será utilizado por los servidores de VTP futuros y clientes. El modo de servidor es el modo VTP predeterminado y permite crear y suprimir VLAN.

Client mode—Si otros switches están en el dominio de administración, debe configurar un nuevo switch para el funcionamiento en modo cliente. De esta manera, el switch se ve obligado a aprender cualquier información VTP existente desde un servidor existente fiable. Después de que el switch ha aprendido la información VTP actual, puede volver a configurar para el modo servidor si se va a utilizar como servidor redundante.

Transparent mode—Este modo se utiliza cuando un parámetro no compartirá la información de VLAN con cualquier otro switch en la red. VLANs todavía se pueden crear, eliminar y modificar el switch transparente. Sin embargo, no se anuncian a otros switches vecinos. Publicaciones VTP recibidos por un switch transparente, sin embargo, se desvían a otros switches en los enlaces trunks. Mantener switches en modo transparente, puede eliminar la posibilidad de duplicación, superposición de VLANs en una red grande con muchos administradores de red.

Puede configurar el modo de VTP con la siguiente secuencia de configuración global comandos:

Switch(config)# vtp mode {server | client | transparent }Switch(config)# vtp password password

Si el dominio está funcionando en modo seguro, una contraseña se puede definir también. La contraseña se puede configurar sólo en servidores VTP y clientes. La contraseña no se envía, en su lugar, un resumen MD5 o código hash se calcula y se envían en publicaciones VTP (servidores) y se utiliza para validar anuncios recibidos (clientes). La contraseña es una cadena de 1 a 32 caracteres (mayúsculas y minúsculas).

Si el VTP es implementado de manera segura usando password, comience por la configuración de un password en el VTP server. Los switches clientes conservara la ultima información VPT conocida pero no puede procesar los anuncios recibidos hasta que la misma contraseña se configura en ellos, también.

Table 5-2 shows a summary of the VTP modes. You can use this table for quick review as you study VTP operation.


Configuring the VTP Version.

Dos versiones de VTP están disponibles para su uso en un dominio de gestión. Switches Catalyst son capaces de ejecutar cualquier versión VTP versión 1 o 2. Dentro de un dominio de gestión, las dos versiones no son interoperables. Por lo tanto, la misma versión VTP debe configurarse en cada switch en un dominio. VTP versión 1 es el protocolo predeterminado en un switch.

Si un switch es capaz de ejecutar VTP versión 2, sin embargo, un switch puede coexistir con otros switches de versión 1, siempre y cuando su versión VTP 2 no está activado. Esta situación es importante si desea utilizar la versión 2 en un dominio. Entonces sólo un switch de modo de servidor necesita tener VTP versión 2 habilitada. El nuevo número de versión se propaga al resto de los switches versión 2 con capacidad de dominio, haciendo que todo para permitir automáticamente la versión 2 para su uso.

Tip: Una tercera versión de VTP aborda algunas de las deficiencias tradicionales. Por ejemplo, la versión 3 de VTP admite los números de VLAN extendidas (1 a 4.095) que son compatibles con el estándar de enlace trunk IEEE 802.1Q. En el momento de escribir estas líneas, VTP v3 sólo está disponible en las plataformas Catalyst de Cisco que ejecutan el sistema operativo CatOS (no-IOS). Por lo tanto, sólo las versiones 1 y 2 de VTP están cubiertos en el examen de final de carrera y en este texto.

Las dos versiones del VTP difieren en las características que apoyan. VTP versión 2 ofrece las siguientes características adicionales sobre la versión 1:

Version-dependent transparent mode—En el modo transparente, la versión VTP 1 trata de hacer match con la versión VTP y el nombre de dominio antes de transmitir la información a otros switches que utilizan VTP. VTP versión 2 en modo transparente VTP reenvía los mensajes sin comprobar el número de versión. Debido a que sólo un dominio se admite en un switch, el nombre de dominio no tiene que ser revisado.


Consistency checks— VTP versión 2 realiza comprobaciones de coherencia en los parámetros de VLAN y VTP introducidos desde la interfaz de línea de comandos (CLI) o por el Simple Network Management Protocol (SNMP). Este control ayuda a evitar errores en cosas tales como nombres y números de VLAN se propague a otros switches en el dominio. Sin embargo, no hay pruebas de consistencia se realizan en los mensajes de VTP que se reciben en los enlaces trunks o en los datos de configuración y la base de datos que se leen de la memoria NVRAM.

Token Ring support—VTP versión 2 es compatible con el uso de conmutación Token Ring y Token Ring VLAN. (Si se utiliza la conmutación Token Ring, VTP versión 2 debe estar activado.)

Unrecognized Type-Length-Value (TLV) support— VTP versión 2 interruptores propagan mensajes de cambio de configuración recibidos a cabo otros enlaces troncales, incluso si el supervisor de interruptor no puede analizar o entender el mensaje. Por ejemplo, un VTP anuncio contiene un campo de tipo para indicar qué tipo de mensaje VTP se está enviando. VTP mensaje de tipo 1 es un anuncio de resumen, y el mensaje de tipo 2 es un anuncio subset. Una extensión de VTP que utiliza otros tipos de mensajes y otros valores de longitud del mensaje puede estar en uso. En lugar de dejar el mensaje VTP no reconocido, la versión 2 todavía se propaga la información y mantiene una copia en la NVRAM.

El número de versión VTP se configura con el siguiente comando de configuración global:

Switch(config)# vtp version {1 | 2}

Por defecto, un switch utiliza VTP Versión 1.

VTP Configuration Example

Como un ejemplo, un switch está configurado como el servidor VTP en un dominio llamado MyCompany. El dominio VTP utiliza seguridad con el password bigsecret. Puede utilizar los siguientes comandos de configuración para lograr esto:

Switch(config)# vtp domain MyCompanySwitch(config)# vtp mode serverSwitch(config)# vtp password bigsecret

VTP Status

Los parámetros VTP actuales de un dominio de gestión se pueden visualizar con el comando show vtp status. Ejemplo 5-1 muestra un ejemplo de salida de este comando desde un switch que actúa como un cliente VTP en el dominio VTP llamada CampusDomain.


Mensaje VTP y contadores de errores también se pueden visualizar con el comando show vtp counters. Puede utilizar este comando para solucionar problemas básicos VTP para ver si el interruptor está interactuando con otros nodos en el dominio VTP. Ejemplo 5-2 muestra un ejemplo de salida del comando contadores VTP espectáculo.

VTP Pruning


Propagación de la información de la VLAN. Esta situación hace que los enlaces trunks entre switches para llevar el tráfico de todas las VLAN, no sólo de las creadas específicamente VLAN.

Considere la red que se muestra en la Figura 5-4. Cuando la PC host del usuario final en la VLAN 3 envía una difusión, El switch Catalyst C envía la trama a todos los puertos de la VLAN 3, incluyendo el enlace trunk para el switch catalyst A. El catalyst A, a su vez, reenvía la emisión a Catalyst B y D sobre los enlaces trunk. Catalyst B y D envian el broadcast sólo sus enlaces de acceso que han sido configurados para la VLAN 3. Si Catalyst B y D no tienen usuarios activos en VLAN 3, envío las freames de broadcast a ellos consumiendo ancho de banda en los enlaces trunk y recursos del procesador en ambos switches, sólo para que los switches B y D descartan los marcos.

VTP pruning hace un uso más eficiente del ancho de banda del trunk al reducir el tráfico inundado innecesaria. Broadcast y unknown unicast frames en una VLAN que es enviada sobre enlaces trunk solo si el switch en el extremo final de recepción del trunk tiene puertos en dicha Vlan. VTP pruning se produce como una extensión a la versión VTP 1, utilizando un tipo de mensaje VTP adicional. Cuando un switch Catalyst tiene un puerto asociado con una VLAN, el switch envía un anuncio a sus switches vecino que tiene puertos activos en esa VLAN. Los vecinos mantienen esta información, Habilitandolos para decidir donde inundar el trafico de una VLAN que usara un puerto trunk.

La figura 5-5 muestra la red de la Figura 5-4 con VTP pruning habilitado. Como Catalyst B no ha anunciado el uso de VLAN 3, Catalyst A purgara VLAN 3 del enlace trunk a B y elegirán no inundar el tráfico VLAN 3 de Catalyst B a través del enlace trunk. Catalyst D ha anunciado la necesidad de VLAN 3, por lo que el tráfico será inundado al mismo.Referencia: Switch Operation for the CCNP BCMSN Exam, By David Hucaby.

TIP: Aunque VTP pruning ha determinado que una VLAN no es necesario en un trunk, una instancia del protocolo Spanning Tree (STP) se ejecutará por cada VLAN que se permite en el enlace trunk. Para reducir el número de instancias de STP, Usted manualmente puede hacer el "prune" de las VLAN que no sean necesarios en el trunk y dejar sólo los necesarios. Utilice el comando switchport trunk allowed vlan para identificar las VLAN que se deben agregar o quitar de un trunk.

Enabling VTP Pruning

De forma predeterminada, el VTP pruning esta deshabilitado en switches IOS-base. Para habilitar pruning, use los siguientes comandos de configuración global:

Switch(config)# vtp pruning

Si utiliza este comando en el servidor VTP, también anuncia que el pruning debe estar habilitado para todo el dominio de gestión. Todos los otros switches escucharan ese anuncio también permitirán el pruning.

Cuando el pruning está habilitado, todas las VLAN de propósito general son elegibles para el pruning en todos los enlaces trunks, si es necesario. Sin embargo, puede modificar la lista predeterminada de elegibilidad de pruning con el siguiente comando de interfaz de configuración:

Switch(config)# interface type mod/numReferencia: Switch Operation for the CCNP BCMSN Exam, By David Hucaby.

Switch(config-if)# switchport trunk pruning vlan {{{add | except | remove } vlan-list} | none}

De forma predeterminada, las VLAN 2 a 1001 son elegibles, o "enable", para el pruning potencial sobre cada trunk. Utilice una de las siguientes palabras clave con el comando para adaptar la lista:

■ vlan-list—Una lista explícita de los números de VLAN elegibles (de nada a 2-1001), separados por comas y guiones.

■ add vlan-list—Se añade una lista de números de VLAN (nada 2-1001) a la lista que ya está configurada, lo que es un atajo para no escribir una larga lista de números.

■ except vlan-list— Todas las VLANs son elegibles a excepción de los números de VLAN lista (para entre 2 y 1001), lo que es un atajo para no escribir una larga lista de números.

■ remove vlan-list—Se extrae una lista de números de VLAN (nada 2-1001) de la lista que ya está configurada, lo que es un atajo para no escribir una larga lista de números.

■ none—No VLAN will be eligible for pruning.

TIP: Tenga en cuenta que la poda de VTP no tiene ningún efecto en los interruptores de la mode.Instead transparente VTP, los switches se deben configurar manualmente para "podar" VLANs de enlaces troncales. En este caso, la poda siempre está configurado en el lado de aguas arriba de un tronco. (El interruptor lado de aguas abajo no tiene ningún puertos que pertenecen a la VLAN podado, así que no hay necesidad de podar de ese extremo.)

Troubleshooting VTP

Si el switch no parece estar recibiendo información actualizada de un servidor VTP, considere las siguientes causas:

- El switch está configurado para el modo transparente VTP. En este modo, publicaciones VTP entrantes no son procesados, sino que se transmiten sólo a otros switches en el dominio.

- Si el switch está configurado como un cliente VTP, puede que no haya otro interruptor que funciona como un servidor VTP. En este caso, configurar el switch local para convertirse en un propio servidor de VTP.

-El enlace hacia el servidor VTP no está en modo de enlace trunk. Publicaciones VTP se envían solamente sobre los enlaces trunk. Utilice el comando show interface type mod / num switchport para verificar el modo de funcionamiento como un trunk.


-Asegúrese de que el nombre de dominio VTP está configurado correctamente para que coincida con la del servidor VTP.

-Asegúrese de que la versión de VTP es compatible con otros switches en el dominio VTP.

-Asegúrese de que la contraseña de VTP coincide con otros en el dominio VTP. Si el servidor no utiliza una contraseña, asegúrese de que la contraseña está desactivada o se borrada en el switch local.

TIP: Por encima de todo, comprobar la configuración VTP de un switch antes de conectarlo a una red de producción. Si el switch se ha configurado previamente o usado en otra parte, que podría estar ya en el modo de servidor VTP y tienen un número de revisión de configuración VTP que es más alta que la de otros switches en el dominio VTP de producción. En ese caso, otros switches escucharan y aprenderán del nuevo switch, ya que tiene un número de revisión más alto y debe conocer la información más reciente. Esto podría hacer que el nuevo interruptor para introducir VLANs falsas en el dominio o, peor aún, para hacer todos los otros switches en el dominio para borrar todas las VLANs activas.

Aggregating Switch Links

Switch Port Aggregation with EtherChannel

Cisco ofrece otro método de escalacion de ancho de enlace mediante la agregación o agrupación, enlaces paralelos, denominada tecnología EtherChannel. De dos a ocho links de cualquiera Fast Ethernet (FE), Gigabit Ethernet (GE), o 10-Gigabit Ethernet (10GE) se agrupan como una relación lógica de Fast EtherChannel (FEC), Gigabit EtherChannel (GEC), o 10-Gigabit EtherChannel (10GEC), respectivamente. Este paquete proporciona un ancho de banda full-duplex de hasta 1600 Mbps (ocho enlaces de Fast Ethernet), 16 Gbps (ocho enlaces de Gigabit Ethernet), o 160 Gbps (ocho enlaces de 10 Gigabit-Ethernet).

Por lo general, que tiene múltiples enlaces o en paralelo entre los switches crea la posibilidad de bridging loops, una condición indeseable. EtherChannel evita esta situación mediante la agrupación de enlaces paralelos en un solo, enlace lógico único, que puede actuar ya sea como un puerto acceso o un enlace trunk. Switches o dispositivos en cada extremo del enlace EtherChannel deben comprender y utilizar la tecnología EtherChannel para su correcto funcionamiento.

En cambio, el tráfico se distribuye a través de los enlaces individuales dentro del EtherChannel. Cada uno de estos enlaces funciona a su velocidad inherente (200 Mbps full duplex para FE), pero sólo transmite tramas que se le plantean por el hardware EtherChannel. Si un enlace dentro del paquete se ve favorecida por el algoritmo de distribución de carga, que enlazan llevará una cantidad desproporcionada de tráfico. En otras palabras, la carga no siempre se distribuye por igual entre los enlaces individuales. El proceso de balanceo de carga se explica con más detalle en la siguiente sección.


EtherChannel también proporciona redundancia con varios enlaces físicos agrupados. Si uno de los enlaces en el paquete falla, el tráfico enviado a través de ese enlace automáticamente se mueve a un enlace adyacente. Failover se produce en menos de unos pocos milisegundos y es transparente para el usuario final. A medida que más enlaces fallan, más tráfico se mueve a otros enlaces adyacentes. Del mismo modo, como enlaces se restauran, la carga se redistribuye automáticamente entre los enlaces activos.

Bundling Ports with EtherChannel

Bundles EtherChannel pueden constar de hasta ocho puertos físicos de la misma tipo Ethernet y velocidad. Algunas restricciones de configuración existen para asegurar que los enlaces configurados de manera similar sólo se encuentran agrupados. En general, todos bundles puertos primero deben pertenecer a la misma VLAN. Si se utiliza como un trunk, puertos bundle deben estar en modo de enlace trunk, tienen la misma VLAN nativa, y pasar el mismo conjunto de VLANs. Cada uno de los puertos deben tener la misma velocidad y dúplex antes de ser empaquetado. Puertos bundle también deben tener la misma configuracion spanning-tree idénticos.

Distributing Traffic in EtherChannel

El tráfico en un EtherChannel se distribuye a través de los enlaces bundle individuales de una manera determinista, sin embargo, la carga no está necesariamente equilibrada por igual a través de todos los enlaces. En su lugar, las tramas se transmitirán en un enlace específico, como resultado de un algoritmo de hash. El algoritmo puede utilizar la dirección IP de origen, dirección IP de destino, o una combinación de las direcciones de origen y destino IP, direcciones MAC de origen y de destino, o los números de puerto TCP / UDP. El algoritmo de control calcula un patrón binario que selecciona un número de enlace en el bundle para llevar a cada frame.

Si es ordenado sólo una dirección o un número de puerto, el switch envía cada cuadro mediante el uso de uno o más de low-order bits del valor hash como un índice en los enlaces bundle. Si dos direcciones o números de puerto son hashed, un switch realiza una operación OR exclusiva (XOR) en uno o más low-order bits de las direcciones o números de puerto TCP / UDP como un índice en los enlaces bundle.


La operación XOR se lleva a cabo de forma independiente en cada posición de bit en el valor de la dirección. Si los dos valores de dirección tienen el mismo valor de bit, el resultado XOR es siempre 0. Si los dos bits de dirección son diferentes, el resultado XOR es siempre 1. De esta manera, las tramas pueden ser distribuidos estadísticamente entre los enlaces con la suposición de que MAC o direcciones IP a sí mismos se distribuyen estadísticamente a lo largo de la red. En un enlace de cuatro EtherChannel, el XOR se lleva a cabo en la parte inferior 2 bits de los valores de dirección, lo que resulta en un valor XOR 2 bits (cada bit se calcula por separado) o un número de enlace de 0 a 3.

Como ejemplo, considere un paquete que se envía desde la dirección IP 192.168.1.1 a 172.31.67.46. Debido EtherChannels pueden construirse de dos a ocho links individuales, sólo se necesitan los más a la derecha (menos significativos) 3 bits como un índice de referencia. A partir de las direcciones de origen y de destino, estos bits son 001 (1) y 110 (6), respectivamente. Para un EtherChannel de dos enlace, un XOR 1 bits se realiza en la dirección del bit más a la derecha: 1 XOR 0 = 1, causando Enlace 1 en el haz para ser utilizado. Un enlace de cuatro EtherChannel produce un XOR 2 bits: 01 XOR 10 = 11, causando Enlace 3 en el haz para ser utilizado. Por último, un enlace de ocho EtherChannel requiere un XOR 3 bits: 001 XOR 110 = 111, donde se selecciona Enlace 7 en el paquete.

Una conversación entre dos dispositivos siempre se envía a través del mismo enlace EtherChannel porque las dos direcciones de extremos permanecen igual. Sin embargo, cuando un dispositivo se comunica con otros dispositivos, lo más probable es que las direcciones de destino se distribuyen por igual a 0 y 1 en el último bit (incluso y valores de dirección impares). Esto hace que los cuadros que se distribuyen a través de los enlaces EtherChannel.

Sin embargo, si un par de anfitriones tiene un volumen mucho mayor de tráfico que el otro par, un link del canal se utiliza mucho más que el otro. Esto todavía puede crear un desequilibrio de la carga. Para remediar esta situación, se debe considerar otros métodos de algoritmos de hash para el canal. Por ejemplo, un método que combina la direcciones de origen y de destino, junto con UDP o números de puerto TCP en una sola operación XOR puede distribuir el tráfico de manera muy diferente. A continuación, los paquetes se colocan en los enlaces dentro del bundle basado en las aplicaciones (números de puerto) que se utilizan en las conversaciones entre los dos host. Los posibles métodos de hash se describen en la siguiente sección.

Configuring EtherChannel Load Balancing


La operación de hash se puede realizar en cualquiere MAC o direcciones IP y puede estar basada únicamente en las direcciones de origen o de destino, o ambos. Utilice el siguiente comando para configurar la distribución de frames para todos los enlaces de switching EtherChannel:

Switch(config)# port-channel load-balance method

Tenga en cuenta que el método de balanceo de carga se ajusta con un comando de configuración global. Debe establecer el método global para el switch, y no en función de cada puerto.

La configuración por defecto es utilizar Source XOR Destination Ip address, o el método src-dst-ip. El valor predeterminado para el Catalyst 2970 y 3560 es src-mac para los switches de capa 2. Si el switch de Capa 3 se utiliza en el EtherChannel, el método src-dst-ip se utilizará siempre, a pesar de que no se puede configurar.

Normalmente, la acción por defecto debería resultar en una distribución estadística de las frames, sin embargo, se debe determinar si el EtherChannel está desequilibrado de acuerdo con los patrones actuales de tráfico. Por ejemplo, si un servidor está recibiendo la mayor parte del tráfico en una Ethernet Channel, la dirección del servidor (la dirección IP de destino) siempre se mantendrá constante en las muchas conversaciones. Esto puede causar un enlace sea usado en exceso si la dirección IP de destino se utiliza como un componente de un método de equilibrio de carga. En el caso de una de cuatro brazos Ethernet Channel, quizás dos de los cuatro enlaces son usados en exceso. Configurar el uso de direcciones MAC, o sólo las direcciones IP de origen, podrían hacer que la distribución sea más equilibrado en todos los enlaces agrupados.


TIP: Para verificar que tan eficiente es un metodo configurado de balanceo de carga, puede utilizar el comando show etherchannel port-channel. Se muestra cada enlace del canal, junto con un valor de "carga" hexagonal. Aunque esta información no es intuitivo, puede utilizar los valores hexadecimales para tener una idea de la carga de tráfico de cada enlace en relación con los demás.

En algunas aplicaciones, el tráfico EtherChannel podría consistir en protocolos distintos al protocolo IP. Por ejemplo, IPX o frames SNA pueden ser switcheadas con IP. Protocolos no IP deben ser distribuidos de acuerdo a las direcciones MAC ya que las direcciones IP no son aplicables. En este caso, el switch debe estar configurado para utilizar direcciones MAC en lugar de la IP por defecto.

TIP: Un caso especial resulta cuando un router está conectado a una EtherChannel. Recordemos que un router utiliza siempre su dirección MAC en las frames de Ethernet, a pesar de que es el reenvío de paquetes hacia y desde muchas direcciones IP diferentes. En otras palabras, muchas estaciones finales envían frames a a la dirección del router local con la dirección MAC del router como destino. Esto significa que la dirección MAC de destino es la misma para todas las tramas destinadas a través del router.

Por lo general, esto no representa un problema debido a que las direcciones MAC de origen son todos different. Cuando dos enrutadores reenvían frames el uno al otro, sin embargo, tanto de origen y de destino de las direcciones MAC que se mantiene constante, y se utiliza sólo un link del EtherChannel. Si las direcciones MAC se mantienen constantes, seleccione las direcciones IP en su lugar. Más allá de eso, si la mayor parte del tráfico es entre las mismas dos direcciones IP, como en el caso de los dos servidores que hablan, elegir números de puerto IP para dispersar a las frames a través de diferentes enlaces.

Usted debe elegir el método de balanceo de carga que proporciona la mayor distribución y variedad a los enlaces del canal cuando estan indexed. También considere el tipo de direccionamiento que se utiliza en la red. Si la mayor parte del tráfico es IP, podría tener sentido para equilibrar la carga de acuerdo a las direcciones IP o números de puerto TCP / UDP.

Pero si se utiliza el balanceo de carga IP, Que ocurre con los frames que no sean IP? Si una frame no puede cumplir los criterios de reparto de carga, el switch se cae automáticamente a la "Next lowest" método. Con Ethernet, direcciones MAC deben estar siempre presentes, por lo que el switch distribuye las frames de acuerdo con sus direcciones MAC.

Un switch también ofrece cierta protección inherente contra el bridging loop con EtherChannels. Cuando los puertos se encuentran agrupados en un EtherChannel, broadcast de entreada y multicast entrada (recibidas) son enviados de vuelta a lo largo de cualquiera de los restantes puertos del canal. Brocast de salida y multicast son de balanceados como cualquier otra: Las direcciones broadcast o multicast se convierte en parte del cálculo de hash para seleccionar un enlace de canal de salida.

EtherChannel Negotiation Protocols


EtherChannels se pueden negociar entre dos switches para proporcionar una configuración de enlace dinámico. Dos protocolos están disponibles para negociar enlaces bundle en switches Catalyst. El protocolo Port Aggregation Protocol (PAgP) es una solución de Cisco-propietario y El protocolo Aggregation Control Protocol (LACP) is standards based.

Port Aggregation Protocol

Para proporcionar la configuración EtherChannel automática y la negociación entre los switches, Cisco desarrolló el Protocolo de Port Aggregation. Paquetes PAgP se intercambian entre los switches sobre los puertos EtherChannel-capaces. Los vecinos se identifican y las capacidades de los grupo de puertos se aprenden y se comparan con las capacidades del switch local. Los puertos que tienen el mismo ID del dispositivo vecino y la capacidad de grupo de puertos se agrupan como un enlace EtherChannel bidireccional punto a punto.

PAgP forma EtherChannel sólo en los puertos que están configuradas para cualquiera de las VLANs estáticas idénticas o trunking. PAgP también modifica dinámicamente los parámetros de la EtherChannel si uno de los puertos de paquetes se modifica. Por ejemplo, si se cambia la VLAN configurada, la velocidad o el modo dúplex de un puerto en un paquete establecido, PAgP reconfigura ese parámetro para todos los puertos en el haz.

PAgP se puede configurar en el active mode (desirable), en el que un switch pide activamente un interruptor farend para negociar un EtherChannel, o en modo pasivo (automático, el valor predeterminado), en el que un interruptor negocia un EtherChannel sólo si el extremo más alejado se inicia.

Link Aggregation Control Protocol

LACP es una alternativa basada en estándares para PAgP, que se define en el estándar IEEE 802.3ad (también conocido como IEEE 802.3 Cláusula 43, "Link Aggregation"). Paquetes LACP se intercambian entre los switches atraves de los puertos EtherChannel-capaces. Al igual que con PAgP, los vecinos se identifican y capacidades del grupo de


puertos se aprenden y se comparan con las capacidades de switcheo locales. Sin embargo, LACP también asigna roles a los puntos finales de EtherChannel's.

El switch con la prioridad más baja de sistema (un valor de prioridad 2-byte seguida de una dirección MAC del switch de 6 bytes) se le permite tomar decisiones sobre qué puertos están participando activamente en el EtherChannel en un momento dado.

Los puertos se seleccionan y se activan en función de su valor de prioridad de puerto (port priority) (una prioridad de 2 bytes seguido por un número de puerto de 2 bytes), donde un valor bajo indica una prioridad más alta. Un conjunto de hasta 16 posibles links se puede definir para cada EtherChannel. A través de LACP, un switch selecciona hasta ocho de ellos con las prioridades del puerto más bajas como enlaces activos en el EtherChannel en cada momento. Los otros enlaces son colocados en un estado de espera y se habilitarán en el EtherChannel si uno de los enlaces activos falla.

Al igual que PAgP, LACP se puede configurar en el active mode (activo), en el que un switch pide activamente a un switch remoto negociar un EtherChannel, o en passive mode (pasivo), en la que un switch negocia un EtherChannel sólo si el extremo más alejado inicia.

EtherChannel Configuration

Para cada EtherChannel en un switch, se debe elegir el protocolo de negociación EtherChannel y asignar los switch ports individuales al EtherChannel. Tanto la negociación por PAgP y EtherChannels LACP se describen en las siguientes secciones. También puede configurar un EtherChannel utilizar el modo On, que incondicionalmente agrupa los enlaces. En este caso, ni PAgP ni paquetes LACP se envían o reciben. En los puertos se configuran para ser miembros de un EtherChannel, el parámetro genera automáticamente una interfaz lógica port-channel. Esta interfaz representa el canal en su conjunto.

Configuring a PAgP EtherChannel

Para configurar los puertos de switch para PAgP negociación (por defecto), utilice los siguientes comandos:

Switch(config)# interface type mod/numSwitch(config-if)# channel-protocol pagpSwitch(config-if)# channel-group number mode { on | {{auto | desirable} [non-silent]}}

En todos los modelos Catalyst IOS basadas en Cisco, puede seleccionar entre PAgP y LACP como un protocolo de canal de negociación. Algunos modelos más antiguos, sin embargo, sólo ofrecen PAgP, por lo que el comando de protocolo de canal no está disponible. Cada interfaz que será incluido en un solo bundle EtherChannel debe ser Referencia: Switch Operation for the CCNP BCMSN Exam, By David Hucaby.

configurado y asignado al mismo número de grupo de canal único o numero de port-Channel (1 a 64). La negociacion de Canal debe ser configurada en modo On (sin condiciones de canal, no hay negociación PAgP), Auto (escuchar pasivamente y esperar a que se le pregunte), o Desirable (preguntar activamente).

Tips: Los switches Catalyst IOS based no asignan interfaces para los grupos de canales predeterminados por defecto. De hecho, las interfaces no se asignan a los grupos de canales hasta que configure manualmente. Esto es diferente de conmutadores Catalyst OS (CatOS), tales como el Catalyst 4000 (Supervisores I y II), 5000, y 6500 (modo híbrido). En esas plataformas, tarjetas de línea Ethernet se dividen en grupos de canales predeterminados.

Por defecto, PAgP opera en silent submode con el modo desirable y Auto Modes, y permite añadir puertos al que EtherChannel incluso si el otro extremo del enlace está en silencio y nunca transmite paquetes PAgP. Esto podría parecer ir en contra de la idea de PAgP, en el que se supone que dos puntos finales negociaran un canal. Después de todo, ¿cómo pueden dos switches negociar si no se reciben paquetes PAgP?

La clave está en la frase "si el otro extremo está en silencio." El modo silent submode escucha cualquier paquete PAgP desde el otro extremo, en busca de negociar un canal. Si no se recibe, silent submode asume que un canal debe ser construido de todos modos, así que no se esperan más paquetes PAgP desde el otro extremo.

Esto permite que un switch formara un EtherChannel con un dispositivo como un servidor de archivos o un analizador de red que no participa en PAgP. En el caso de un analizador de red conectada al otro extremo, también puede ser que desee para ver los paquetes PAgP generados por el cambio, como si estuviera utilizando un EtherChannel normales PAgP.

Si esperas un switch con capacidades PAgP el otro extremo, se debe añadir la palabra clave non-silent al modo Desirable or Auto Mode. Para ello es necesario que cada puerto reciba paquetes PAgP antes de añadirlos a un canal. Si PAgP no se escucha en un puerto activo, el puerto permanece en el estado UP, pero PAgP informes en el Protocolo Spanning Tree (STP) que el puerto está Down.

Como un ejemplo de configuración PAgP, suponga que desea que un switch utilice un balanceo de carga de hash Ether-Channel de ambos números de puerto de origen y destino. Un Gigabit EtherChannel se construye a partir de las interfaces Gigabit Ethernet 3/1 a 3/4, con el switch activamente negociando el canal. El switch no debe esperar a escuchar los silent partners. Puede utilizar los siguientes comandos de configuración para lograr esto:

Switch(config)# port-channel load-balance src-dst-portSwitch(config)# interface range gig 3/1 – 4Switch(config-if)# channel-protocol pagpSwitch(config-if)# channel-group 1 mode desirable non-silent

Configuring a LACP EtherChannel


Para configurar los switch port para negociación LACP, utilice los siguientes comandos:

Switch(config)# lacp system-priority prioritySwitch(config)# interface type mod/numSwitch(config-if)# channel-protocol lacpSwitch(config-if)# channel-group number mode { on | passive | active}Switch(config-if)# lacp port-priority priority

En primer lugar, debe tener el switch define la prioridad de sistema LACP (1 a 65.535, por defecto 32768). Si se desea, un switch debe ser asignado un sistema de prioridad más bajo que el otro de modo que pueda tomar decisiones sobre las funciones del EtherChannel. De lo contrario, los dos switches tendrá la misma prioridad de sistema (32,768), y el que tiene la dirección MAC más baja se convertirá en el que toma las decisiones.

Cada interfaz incluido en un solo bundle EtherChannel debe ser asignada al mismo número de grupo único de canal (1 a 64). La negociacion del Canal negociación debe ser On (Unconditionally, no hay negociación LACP), passive (escuchar pasivamente y esperar a que se le pregunte) o activa (consultar activamente).

Puede configurar más interfaces en el número de channel group que se les permite estar activo en el channel. Esto prepara interfaces de reserva adicional para reemplazar las interfaces que fallen. Utilice el comando port-priority lacp para configurar una prioridad más baja del puerto (1 a 65.535, por defecto 32768) para las interfaces que deben estar activas, y una mayor prioridad para las interfaces que puede permanecer en el estado de espera. De lo contrario, sólo tiene que utilizar el escenario predeterminado, en el que todos los puertos por defecto de 32768 y los números de puerto inferiores (en orden de número de interfaz) se utilizan para seleccionar los puertos activos.

Como un ejemplo de configuración de LACP, suponga que desea configurar un switch para negociar un Gigabit EtherChannel uso de interfaces Gigabit Ethernet 2/1 a 2/4 y 3/1 a 3/4. Interfaces Ethernet Gigabit 2/5 a 2/8 y 3/5 a 3/8 también están disponibles, por lo que estos se pueden utilizar como enlaces de reserva para reemplazar los enlaces caídos en el canal. Este switch activamente debe negociar el canal y debe ser el que toma las decisiones acerca de la operación del canal.

Puede utilizar los siguientes comandos de configuración para lograr esto:

Switch(config)# lacp system-priority 100Switch(config)# interface range gig 2/1 – 4 , gig 3/1 – 4Switch(config-if)# channel-protocol lacpSwitch(config-if)# channel-group 1 mode activeSwitch(config-if)# lacp port-priority 100Switch(config-if)# exitSwitch(config)# interface range gig 2/5 – 8 , gig 3/5 – 8Switch(config-if)# channel-protocol lacpSwitch(config-if)# channel-group 1 mode activeReferencia: Switch Operation for the CCNP BCMSN Exam, By David Hucaby.

Observe que las interfaces Gigabit Ethernet y 2/5-8 3/5-8 han dejado a sus prioridades de puerto predeterminados de 32.768. Esto es más alto que los otros, que se han configurado para el 100, por lo que se llevará a cabo como interfaces en espera.

Troubleshooting an EtherChannel

Si usted encuentra que un EtherChannel está teniendo problemas, recuerda que el concepto se basa en configuraciones compatibles en ambos extremos del canal. Aquí están algunos recordatorios acerca del funcionamiento EtherChannel y la interacción:

-EtherChannel modo ON no envía ni recibe paquetes PAgP o LACP. Por lo tanto, ambos extremos se deben establecer en el modo ON antes de que puedan formar el canal.

- Etherchannel modo desirable (PAgP) o active (LACP) intenta pedir al extremo para abrir un canal. Por lo tanto, el otro extremo remoto se debe establecer en cualquier modo desirable o auto mode.

- EtherChannel Auto (PAgP) o en modo passive (LACP) participa en el protocolo de canal, pero sólo si el otro extremo pide participación. Por lo tanto, dos switches en el modo automático o pasivo no formarán un EtherChannel.

-PAgP desirable y auto modes default to the silent submode, en el que no se espera ningún paquete PAgP desde el otro extremo. Si los puertos están configurados para nonsilent submode, paquetes PAgP deben ser recibidas antes de que formar un canal.

En primer lugar, comprobar el estado EtherChannel con el comando show etherchannel summary. Cada puerto en el canal se muestra, junto con banderas que indican el estado del puerto, como se muestra en el Ejemplo 6-1.


El estado del canal de puerto muestra la interfaz lógica EtherChannel en su conjunto. Esto debe mostrar SU (canal de Capa 2, en uso) si el canal está en funcionamiento. También puede examinar el estado de cada puerto en el canal. Tenga en cuenta que la mayoría de los puertos del canal tienen banderas (P), lo que indica que están activos en el canal de puertos. Un puerto de muestra, ya que físicamente no está conectado o hacia abajo. Si un puerto está conectado, pero no bundle en el canal, que tendrá una bandera independiente, o (I).

Puede comprobar el modo de negociación de canal con el comando show etherchannel port, como se muestra en el ejemplo 6-2. El switch local se muestra usando del modo shown using desirable mode, con PAgP (Desirable-Sl is desirable silent mode). Tenga en cuenta que también se puede ver el modo de negociación del extremo bajo las banderas Partner Flags heading, como A, o en modo automático.


Dentro de un switch, un EtherChannel no puede formarse a menos que cada uno de los puertos del componente o miembro se ha configurado de forma coherente. Cada uno debe tener el mismo modo de conmutación (acceso o trunk), nativo VLAN, VLAN trunking, la velocidad del puerto, modo puerto duplex, y así sucesivamente.

Usted puede ver la configuración de un puerto mirando la interfaz show running-config interfacetype mod/ num. Además, el show interface type mod/num etherchannel muestra los parámetros EtherChannel para un único puerto. Si configura un puerto de manera incompatible con los demás por un EtherChannel, aparecen mensajes de error del switch.

Algunos mensajes desde el switch puede tener un aspecto como errores pero son parte del proceso de etherchannel normal. Por ejemplo, como un nuevo puerto es configurado como miembro de un EtherChannel existente, es posible que vea el siguiente mensaje:


4d00h: %EC-5-L3DONTBNDL2: FastEthernet0/2 suspended: incompatible partner port with FastEthernet0/1

Cuando el puerto primero se añade a la EtherChannel, es incompatible debido a que el STP se ejecuta en el canal y el nuevo puerto. Después de STP lleva el nuevo puerto a través de la progresión de los estados, el puerto se agrega automáticamente a la EtherChannel.

Otros mensajes indican un port-compatibility error. En estos casos, se muestra la causa del error. Por ejemplo, el siguiente mensaje indica que Fast ethernet0/3 tiene un modo dúplex diferente de los otros puertos de la EtherChannel:

4d00h: %EC-5-CANNOT_BUNDLE2: FastEthernet0/3 is not compatible with FastEthernet0/1 and will be suspended (duplex of Fa0/3 is full, Fa0/1 is half)

Por último, se puede verificar que el algoritmo de balanceo de carga o hashing EtherChannel con el comando show etherchannel load-balance. Recuerde que los switches en cada extremo de un EtherChannel pueden tener diferentes métodos de equilibrio de carga. El único inconveniente de esto es que el equilibrio de carga será asimétrico en las dos direcciones a través del canal.

Table 6-5 lists the commands useful for verifying or troubleshooting EtherChannel operation.

Traditional Spanning Tree Protocol

IEEE 802.1D Overview

El STP se define en el estándar IEEE 802.1D.

Bridging Loops


Si llega una trama con una dirección de destino que no se encuentra en la tabla del bridge, el bridge no puede determinar en qué puerto enviara la frame para la transmisión. este tipo de trama se conoce como un unknown unicast. En este caso, el bridge trata la frame como si se tratara de broadcast e inunda a todos los puertos restantes. Cuando una respuesta a la frame que se escuchó, el bridge puede aprender la ubicación de la estación desconocida y puede agregarlo a la bridge table para uso futuro.

Este proceso de transmisión de un único frame alrededor y alrededor de entre dos switches se conoce como bridging loop. Ni el switch es consciente del otro, por lo que cada uno reenvía felizmente la misma frame de ida y vuelta entre sus segmentos. Tenga en cuenta también que debido a que dos switches están involucrados en el bucle, la frame original ha sido duplicado y ahora es enviado en alrededor de dos bucles contra-rotación. Lo que deja la frame se pueda reenviar de esta manera para siempre? Nada! PC-4 comienza a recibir frames dirigidas a él tan rápido como los switches de ellos pueden reenviar.

¿Qué pasaría si el PC-1 envía una frame de broadcast en su lugar? Los bridging loops (recordemos que dos de ellos son producidos por dos switches en paralelo) se forman exactamente igual que antes. Las frames de difusión siguen circulando para siempre. Ahora, sin embargo, cada dispositivo de usuario final situada en ambos segmentos A y B reciben y procesa cada frame de broadcast. Este tipo de broadcast storm puede saturar fácilmente los segmentos de la red y llevar a todos los hosts de los segmentos a su detención.

La única manera de poner fin a la condición de bridging loop es romper físicamente el loop desconectando los puertos del switch o apagar un switch. Obviamente, sería mejor prevenir bridging loops que se enfrenta a la búsqueda y romper después de que se forman.

Preventing Loops with Spanning Tree Protocol

STP fue desarrollado para superar la posibilidad de tender un bridging loop de manera que los switches redundantes y switches path podrían ser utilizados por sus beneficios. Básicamente, el protocolo permite a los switches tomar conciencia del otro para que puedan negociar un camino libre de bucles a través de la red.

Loops se descubren antes de que estén disponibles para su uso, y enlaces redundantes se cerraron efectivamente para prevenir la formación de loops. En el caso de enlaces redundantes, los switches pueden ser conscientes de que un link shutdown para la prevención de loops debe ser llevado rápidamente a UP en caso de una falla del enlace.

STP se comunica entre todos los switches conectados en una red. Cada switch ejecuta el algoritmo spanning-tree sobre la base de información recibida de otros switches vecinos. El algoritmo elige un punto de referencia en la red y calcula todas las rutas redundantes a ese punto de referencia. Cuando se detectan rutas redundantes, el algoritmo spanning-tree toma


un camino por el que transmita las frames y deshabilita, o bloques, el reenvío de las otras rutas de acceso redundantes.

Spanning-Tree Communication: Bridge Protocol Data Units

STP opera como interruptores comunicándose uno con el otro. Los mensajes de Data se intercambian en forma de unidades de datos del bridging protocol data units (BPDU). Un switch envía una frame de BPDU por los puertos, utilizando la dirección MAC única del mismo puerto como una dirección de origen. El switch no tiene conocimiento de los otros switches alrededor de el, así que las frames BPDU se envían con una dirección de destino del bien conocido STP dirección multicast 01-80-c2-00-00-00.

Existen dos tipos de BPDU:

■ Configuration BPDU, used for spanning-tree computation

■ Topology Change Notification (TCN) BPDU, used to announce changes in the network topology

El intercabio de mesajes de BPDU trabajan con el objetivo de elegir puntos de refrencia como base para una topologia de spanning-tree estable. Los loops pueden ser identificados y removidos colocando puertos redundantes en estado de bloqueo o en estado de espera standby. Por default, Los BPDUS son enviados por todos los switch ports canda 2 segundos de modo que la informacion de la topologia actual es intercambiada y los loops son identificados rapidamente.

Electing a Root Bridge.

Para que todos los switches de la red estén de acuerdo en una topología libre de loops, un marco común de referencia debe existir para utilizar como guía. Este punto de referencia es llamado el root bridge. Un proceso de elección entre todos los interruptores conectados elige el root bridge. Cada switch tiene un único bridge ID que los identifica de entre los demás switches. El bridge ID es un valor de 8-byte, el cual consiste de los siguientes campos:

Bridge Priority (2 bytes): La prioridad o peso de un switch en relación con los otros switches. El campo de prioridad puede tener un valor de 0 a 65535 y el valor default es 32,768 (o 0x8000) en cada switch Catalyst.


Mac Address (6 bytes): La dirección de Mac usada por el switch puede provenir del módulo de supervisora, el backplane o un pool de 1024 direcciones que son asignadas a cada supervisora o backplane, dependiendo del modelo del switch. En cualquier evento, esta dirección es un hard-coded y única, y el usuario no puede cambiarlas.

El proceso de elección procede como sigue: Cada switch comienza enviando BPDUs con su root bridge ID igual a su propio bridge ID y el bridge ID del sender que es su propio Bridge ID. El bridge ID del transmisor simplemente dice a los otros switches quien es el transmisor actual del mensaje de BPDU. (Después de que el root bridge es elegido, los mensajes de configuración solo son enviados por el root bridge. Todos los otros bridges enviaran o harán relay de los BPDUs, agregando su propio Sender Bridge IDs al mensaje). Los mensajes BPDUs recibidos son analizados en caso de observar a un mejor root bridge anunciado. Un root bridge es considerado mejor si su valor de root bridge ID es menor que los demás. Nuevamente, piense en que el root bridge es compuesta por los campos Bridge ID y la dirección mac address. Si dos valores de bridge priority son iguales, la dirección mac address más baja hace el bridge ID mejor. Cuando un switch escucha a un mejor root bridge, este remplaza su propio root bridge ID con el root bridge ID anunciado en los BPDU. El switches después requiere recomendar o anunciar el nuevo root bridge ID en su propio mensaje de BPDU. Aunque este continuara identificándose como el transmisor del bridge ID. Antes o después, la elección converge y todos los switches están de acuerdo en la elección de uno de ellos como root bridge. Como podía esperarse, si un nuevo switch con menor Bridge priority es encendido, el comenzara advirtiéndose como root bridge. Debido a que el nuevo interruptor tiene un root bridge inferior, todos los switches tarde o temprano reconsideraran y registraran a este como el nuevo root bridge. Esto también puede suceder si el nuevo switch tiene un bridge ID igual al del root bridges pero con menor dirección mac address. La elección de root bridge es un proceso en curso, lanzado por el intercambio del root bridge ID en el BPDU cada 2 segundos.


En esta red, cada switch tiene el valor default de bridge priority de 32,768. Los switches son interconectados con enlaces fastethernet. los 3 switches tratan de elegirse a ellos mismos como root, pero todos ellos tiene el mismo valor de prioridad. Los resultados de la eleccion producen el root bridge se determine por la direccion mac address de valor mas bajo, la cual es la del Catalyst A.

Electing Root Ports.

Ahora que se tiene asignado un punto de referencia la red entera de switcheo, cada switche no root debe averiguar donde se encuentra en relación con el root bridge. Esta acción puede ser realizada por la elección de un solo root port en cada no root switch. El puerto root siempre apunta al root bridge actual. STP utiliza el concepto de costo para determinar muchas cosas. La selección del root port involucra la evaluación del root path cost. Este valor es el costo acumulado de todos los links que conducen al root bridge. Un enlace particular de un switch también tiene un costo asociado con él, llamado path cost. Para entender la diferencia entre estos valores, recuerde que solo el root path cost es transportando dentro del BPDU. A medida que el root cost viaja a


lo largo, otros switches pueden modificar este valor volviéndolo acumulativo. El path cost, sin embargo, no es contenido en el BPDU. Solo es conocido por el switch local donde el puerto (o Path al switch vecino) reside. El Path cost es definido por un valor de 1-byte, los valores default son mostrados en la tabla. Generalmente, a mayor ancho de banda del enlace, es menor el costo transportado atreves de él.

El valor del root path es determinado como se muestra a continuación:

1. El root Bridge envía un BPDU con un valor de path cost de 0 por que sus puertos directamente se encuentran en el root bridge.

2. Cuando el más cercano vecino recibe el BPDU, este agrega el path cost de su propio puerto donde recibió el BPDU. (Esto es realizado al momento de recibir la BPDU).

3. El vecino envía un BPDU con el nuevo valor acumulativo como root path cost.


4. El root path cost es incrementado por el costo del ingress port path cost como se recibe la BPDU en cada interruptor en la línea.

5. Note el énfasis en incrementar del root path cost en el momento de recibir el BPDU. Cuando realice el cálculo del algoritmo manual de spanning-tree, recuerde calcular el nuevo root path cost en el momento que un BPDU es recibido por un puerto del switch, no en el momento de su salida.

Después de incrementar el costo del root path, el switch también registra el valor en su memoria. Cuando se recibe una BPDDU en otro puerto y el nuevo costo del root path es menor que el valor registrado anteriormente, este valor más bajo se convierte en el nuevo root path. Además, el costo más bajo le indica al switch que el path al root bridge debe ser mejor usando este puerto. El switch tiene ahora determinado cuál de estos puertos tiene el mejor path al root.


El root bridge, Catalyst A, ya se encuentra seleccionado. Por lo tanto, los otros switches en la red deben escoger un puerto que tenga el mejor path al root bridge. Catalyst B selecciona su puerto 1/1, con un costo de root path de 0 más 19, el puerto 1/2 no es elegido por que su costo de root path es de 0 (BPDU desde catalyst A) mas 19 ( Path cost del enlace A-C), más 19 ( path cost del enlace B-C), el total es de 38. Catalyst C hace una elección idéntica del Puerto 1/1. Para eliminar la posibilidad de briding loops, STP hace un calculo final para identificar un designated por en cada segmento de la red. Supongamos que dos o más switches tienen puertos conectados a un solo segmento de red común. Si aparece un frame en ese segmento, todos los bridge intentan enviar a su destino. Recordemos que este comportamiento fue la base de un brindgen loop y se debe evitar.

Electing Designated Ports.

Para remover la posibilidad de bringing loops. STP hace un cómputo final para identificar un puerto designated port en cada uno de los segmentos Referencia: Switch Operation for the CCNP BCMSN Exam, By David Hucaby.

de red. Suponga que 2 o más switches tiene puertos conectados un solo segmento de red común. Si frames aparecen en este segmento, todos los bridgs intentan enviar la frame a su destino. Recordamos que este comportamiento es la base de los bridging loops y se debe evitar. En su lugar, solo un enlace en el segmento debe enviar tráfico a y desde ese segmento, El que es elegido como designated port. Los switches escogen un puerto designated basado en el menor valor acumulativo de root path cost al root bridge. Por ejemplo, un switche siempre tiene la idea de su propio root path cost, el cual es anunciado en sus propios BPDUs. Si un switch vecino en el segmento compartido de Lan envía un BPDU anunciado un costo menor de root path, el vecino tendrá el designated port. Si un switch vecino solo aprende solo valores altos de costo de root path desde otros BPDUs recibidos en un puerto, Sin embargo, este asume correctamente que su propio puerto es el designated port del segmento. Da cuenta de que todo el proceso de determinación STP sólo ha servido para identificar los bridges y puertos. Todos los puertos siguen activos, los bridging loops continúan asechando nuestra red. STP tiene un conjunto de estados progresivos que debe pasar cada puerto, independiente del tipo o identificación. Estos estados activamente previene la formación de loops.

Si uno o mas enlaces tiene el mismo costo de root path. El resultado es una condicion de empate, a menos que se consideren otros factores. Todos los desempates en STP son desididos basandose en la siguiente secuencia de 4 condiciones:

1.- Menor root bridge ID.

2.- Menor costo de root path al root bridge.

3.- Menor ID de bridge del transmisor.

4.- Menor port ID de transmiros.


Catalyst A- Debido a que este switch es el root bridge, todos sus puertos activos son desigandos como designated port, En el root bridge, el root path cost de cada puerto es 0.

Catalyst B- El puerto 1/1 de Catalyst A es el DP del segmento A-B ya que tiene el costo mas bajo de root path cost (0). El puerto 1/2 de Catalyst B es el deisganted port del segmento B-C. El root path cost para cada segmento es de 19, determinado por el BPDU de entrada en el puerto 1/1. Debido a que el costo de root path cost es igual en ambos puertos del segmento, el DB debera ser escogido por el siguiente criterio, el menor ID del bridge. Cuando Catalyst B envia un BPDU a Catalyst C, este tiene la menor direccion Mac en el bridge ID. Catalyst C tambien envia su BPDU a Catalyst B, pero el Bridge ID del trasmisor es mayor, por lo tanto, Catalyst B puerto 1/2 es seleccionado como DP del segmento.

Catalyst C - Catalyst A puerto 1/2 es el DP del segmento A-C por que este tiene el valor de root path cost menor (0). Catalyst B puerto 1/2 es el puerto DP del segmento B-C. Por lo tanto, Catalyst C port 1/2 no sera un puerto root port ni tampoco un designated por. Como


los discutimos en las siguientes secciones, cualquier puerto que no es electo como cualquiera de estas posiciones entra en un estado de bloqueo. Donde el bloqueo ocurre, los bridging loops se rompen.

STP States.

Para participar en STP, cada puerto de el switch debe pasar por un progreso atravez de diferentes estados. Un puerto comienza su vida en el estado Disable, moviéndose atravez algunos estados pasivos y, finalmente, entra en el estado activo si se le permite enviar tráfico. Los estados de los puertos STP son los siguientes:

Disable.- Los puertos están administrativamente en shutdown por el administrador de la red o por el sistema debido a una condición de falla, se encuentran en estado Disable. Este estado es especial y no es parte de la progresión normal de los puertos en STP.

Blocking.- Después de inicializar, este se encuentra en estado blocking de modo que ningún bridging loop se puede formar. En el estado blocking, el puerto no puede recibir o enviar datos y no puede agregar direcciones Mac a su tabla de direcciones. En lugar, a un puerto se le permite solo recibir BPDUs de modo que el switch puede oir a otros switches vecinos. Adicionalmente, puertos que son puestos en el modo standby para remover bridging loops entran en blocking.

Listeing.-Un puerto se mueve de blocking to listening si el switch piensa que el puerto puede ser seleccionando como root port o designated port. En otras palabras, el puerto está en el camino para comenzar a enviar tráfico. En el estado listeing, el puerto continuo si poder enviar o recibir frames de datos, sin embargo, esta permitido que el puerto envié o reciba BPDUs de modo que este participa activamente en el proceso de topología de STP. Aquí, El puerto finalmente se le permite convertirse en un puerto root port o desigated por que el switch puede anunciar el puerto enviando BPDUs a otros switches. Si el puerto pierde su estatus de root port o designated port, este regresa al estado de blocking.

Learning.- Después de un periodo de tiempo llamado Forward Delay en el estado Listeing, al puerto se le permite moverse al estado learning. El puerto continúa enviando y recibiendo BPDUs como antes. Adicionalmente, el switch ahora puede aprender nuevas mac address para que sea agregadas a su tabla de direcciones. Esto leda al puerto un periodo extra de participación en silencio y permite al switch ensamblar por lo menos algo de información sobre direcciones. El puerto no puede enviar todavía ninguna frame de datos.

Forwarding.- Después de otro periodo de tiempo Forward Delay en el estado de learning, se le permite al puerto del switch moverse al estado Forwarding. El puerto ahora puede enviar y recibir frames de datos, colectar direcciones mac para su tabla de mac address, y enviar y recibir


BPDUs. El puerto ahora es completamente funcional dentro de la topología de Spanning-tree.

El siguiente comando nos puede ayudar a verificar el estado de un puerto dentro de la topologia Spanning-Tree:

Switch#show spanning interface fastethernet 0/1

Note también el time stamps y el estado del puerto proveído por el comando debug spanning-tree switch state, el cual nos da un idea de la sincronía entre los estados del puerto.


STP Timers.

STP usa 3 timers para asegurarse que la red converge apropiadamente antes de que un bridging loop sea formado. Los timers y sus valores de default se muestran a continuación:

Hello Time.- El intervalo de tiempo entre en el que el root bridge envía un BPDU de configuracion. El valor del timer Hello configurado en el switch root bridge determina el Hello timer para todos los switches nonrot porque ellos solo hacen relay de las BPDus de configuracion cuando son recibidas desde el root. Sin embargo, todos los switches localmente tienen configurado el tiempo del timer Hello que será usado como timer para TCN BPDUs cuanto estos son retrasmitidos. El estándar IEEE 802.1D especifica que el valor default del Hello timer es de 2 Segundos.

Forward Delay.- El intervalo de tiempo que el switch port emplea en ambos estados Listening y Learning. El valor por default es de 15 segundos.


Max (Maximum) Age.- El intervalo de tiempo que el switch guarda una BPDU antes de descartarla. Durante la ejecución de STP, cada switch port conserva una copia del mejor BPDU que el escucho. Si el switch port pierde el contacto con el origen de BPDU (No son recibidos BPDUs de él), el switch asume que un cambio en la topología se ha producido después del lapso del timer Max Age y entonces el BPDU caduca. El timer por default tiene un valor de 20 segundos.

Los valores de los timers nunca deben ser cambiados de sus valores por defecto, sin una cuidadosa consideración. Después los valores deben cambiarse solo en el switch root bridge. Recuerde que los valores de timer son anunciados en un campo dentro del BPDU. El root bridge se asegurara que el valor de timer sea propagado a los otros switches. El diámetro de la red puede ser configurado en el switch root bridge para reflejar con mayor exactitud el verdadero tamaño de la red física. Hacer que el valor más preciso reduce el tiempo total de la convergencia STP durante un cambio de topología. Cisco también recomienda que si los cambios deben hacerse, solo el diámetro de la red debe ser modificado en el switch root bridge. Cuando el diámetro de la red cambia, el switch calcula nuevos valores para los 3 timers automáticamente.

Topology Changes.

Para anunciar un cambio en una red productiva, el switch envía un TCN BPDU. Un cambio en topología ocurre cuando un switch mueve un puerto en el estado forwarding o mueve el puerto desde Forwarding o learning al estado de blocking. En otras palabras, un puerto en un switch activo se va a Up o va a down. El switch envía un TCN BPU atravez de su puerto root por lo que, en última instancia, el root bridge recibe la noticia del cambio de topología. Observe que el TCN BPDU no lleva ningún dato sobre el cambio, pero informa a los destinatarios que un cambio ocurrió. También note que el switch no enviara TCN BPUDs si el Referencia: Switch Operation for the CCNP BCMSN Exam, By David Hucaby.

puerto fue configurado para habilitar PortFast. El switch continúa enviando TCN BPDUs cada intervalo Hello Timer hasta que él tenga un acknowledgment de sus vecinos en la capa superior. Como el vecino de la capa superior recibe el TCN BPDU, Ellos lo propagan hasta el root bridge y envían su propio acknowledgment. Sin embargo, el root bridge setea la bandera de Topology Change en su Configuration BPDU, que es relay a todos los otros bridge en la red. Esto es hecho para señalar el Topology change y causara que el resto de los bridges acorten su tabla de bringing envejeciendo los tiempos desde el default (300 segundos) hasta el valor de Forward Delay (Default 15 segundos). Esta condición causa que la localización de las direcciones mac address sean purgadas mucho antes que lo normal, aliviando de la corrupción a la tabla de bridge que pudiera ocurrir debido a un cambio en la topología, Sin embargo, cualquier estación que este activamente comunicándose durante este periodo de tiempo son conservado en la tabla de bridge. Esta condición tiene una duración de la suma de la Forward Delay y el Max Age (por defecto 15 + 20 segundos).

Direct Topology Changes.

Un cambio de topología directa es uno que puede ser detectado en una interfaz del switch. Por ejemplo, si un enlace troncal de repente se cae, el switch en cada extremo del enlace puede inmediatamente detectar una falla de enlace. La ausencia de ese cambio de topología de bridging en el enlace, entonces los demás switches serán notificados. Esta red acaba de sufrir un fallo de enlace entre el Catalyst A y el Catalyst C. La secuencia de eventos se desarrolla a continuación:

1.- Catalyst C detecta el enlace caído en su puerto 1/1, Catalyst A detecta en una caída de enlace en su puerto 1/2.

2.- Catalyst C remueve el "mejor" BPDU que este recibió desde el root sobre el puerto 1/1. El puerto 1/1 está ahora abajo entonces le BPDU ya no es válido.

Normalmente, Catalyst C tratara de enviar un mensaje TCN atravez de su root port, para alcanzar el root bridge. Aquí, el root port está roto, entonces será imposible. Sin una funcionalidad avanzada como STP UplinkFast, Catalyst C no es consiente que existe otro path al root. También, Catalyst A es consciente de la condición de enlace caído en su puerto 1/2. Este normalmente tratara de enviar un mensaje TCN atravez de su puerto root para tratar de alcanzar el root bridge. Aquí, Catalyst A es el root, entonces no es realmente necesario.

3.- El root Bridge, Catalyst A, enviara un mensaje de configuración BPDU Referencia: Switch Operation for the CCNP BCMSN Exam, By David Hucaby.

con el bit encendido de TCN atravez de su puerto 1/1. Este es recibido y renviado a cada uno de los switches atravez del camino, informando a cada uno del cambio de topología.

4.-Catalyst B y Catalyst C reciben el mensaje de TCN. La única reacción que esto switches toman es acortar el envejecimiento de su tabla bridging al Forwarding Delay timer. En este punto, ellos no conocen como la topología ha cambiado; Ellos solo saben que debe forzar el envejecimiento de las entradas más recientes en su brindging table.

5.- Catalyst C básicamente solo se sienta a esperar a escuchar desde sus root bridge otra vez. El mensaje MPDU TCN es recibido en el puerto 1/2, que previamente se encontraba en el estado de blocking. Este BPDU se convierte en el mejor recibido desde el root, entonces el puerto 1/2 se convierte en el nuevo root port. Catalyst C ahora puede progresar el puerto 1/2 desde blocking atravez de los estados listening, learning y Forwarding. Como resultado de una falla directa de un enlace, la topología ha cambiado y STP tiene que converger otra vez. Note que solo el Catalyst C ha sufrido los efectos reales de la falla. Switch A y B escucharon el nuevo cambio de topología pero no tuvieron que mover ningún enlace por los estados de STP. En otras palabras, la red completa no tuvo que ir atravez de una re convergencia masiva de STP. El total de tiempo que el usuario en el Catalyst C perdió conectividad fue más o menos el tiempo que el puerto 1/2 le toma en el estado Listening y Learning. Con los valores de timers default de STP, esto equivale aproximadamente 2 veces el periodo de Forward Delay (15 segundos) o 30 segundos en total.

Indirect Topology Changes.

El estado de los enlaces en cada switch permance arriba, pero algo entre ellos esta fallando o esta filtrando el trafico. Este puede ser otro dispositivo, como un switch de service provider, un firewall, etcétera. Como resultado, ningun dato (Incluyendo BPDUs) pueden pasar entre los switches.


STP puede detectar y recuperarse de una falla indirecta, gracias a un mecanismo de timer. La secuencia de eventos se desarrolla como sigue:

1.- Catalyst A y C ambos despliegan una condición de enlaces arriba; los datos comienzan a ser filtrados en algún lugar del enlace.

2.- No es detectada ninguna falla de enlace, así que no hay envió de mensajes TCN.

3.- Catalyst C ya almaceno el mejor BPDU que había recibido desde el root atraves del puerto 1/1. No hay más BPDUs recibidas desde el root atraves de ese puerto. Después de que el timer MAX AGE expira, no hay otro BPDU disponible para refrescar la mejor entrada, por lo que se vacía. Catalyst C ahora debe esperar a escuchar el root atraves de alguno de sus puertos.Referencia: Switch Operation for the CCNP BCMSN Exam, By David Hucaby.

4.- El siguiente Configuration BPDU desde el root es escuchado en el puerto 1/2 del Catalyst C. Este BPDU se convierte en la mejor entrada, y el puerto 1/2 se convierte en el root port. Ahora el puerto progresara desde blocking atraves de Listening, Learning, y finalmente Forwarding. Como resultado de la falla indirecta, la topología no cambia inmediatamente. La ausencia de BPDU desde el root causa que Catalyst C tome acciones. Por qué este tipo de fallas se basa en la actividad de los timers de STP, por lo general toma más tiempo para detectar y mitigar. En este ejemplo el total de tiempo que el usuario en Catalyst C pierde conectividad será más o menos el tiempo que tarda el MAX Age en expirar (20 Segundos), más el tiempo hasta recibir el siguiente mensaje Configuration BPDU recibido (2 segundos) en el puerto 1/2, más el tiempo que el puerto 1/2 le toma en el estado Listening (15 segundos) y Learning (15 segundos). En otras palabras, Un lapso de 52 segundos si los valores de default son usados.

Insignificant Topology Changes.


Para ver el efecto que esto tiene en la topología STP y la red, tenga en cuenta lo siguiente secuencia de eventos:

1.- La PC en el puerto del catalyst 2/12 es apagada. El switch detecta el estatus de este link como caído.

2.- Catalyst C comienza enviando TCN BPDUs hacia el root, sobre su puerto 1/1.

3.- El root envia un TCN acknowledgment de regreso al Catalyst C y después envia un Configuration BPDU con el bit de TCN encendido a todos los switches debajo de él. Esto es hecho para informar a cada switch del cambio de topología en algún lugar de la red.

4.- la bandera TCN es recibida desde el root, y ambos Catalyst B y Catalyst C acortan sus tiempos de la tabla de bridge. Esto causa que entradas en espera sean purgadas, dejando solo las estaciones que activamente están transmitiendo en la tabla. El tiempo aging se queda corto para la duración de los temporizadores Forward Delay y Max Age.

Note que este tipo de cambio de topología es principalmente cosmético. No se produjo un cambio real en la topología porque ningún switch no tiene un puerto que cambie de estado atraves del cual alcance al root. En lugar, apagar una PC causa que todos los switches haga envejezcan (Age out) las entradas de su bridge table o CAM mucho más rápido de lo normal. Al principio, esto no parece ser un problema importante debido a que el estado de enlace PC sólo afecta a la "novedad" de los contenidos de la tabla CAM. Si las entradas del CAM table son vaciadas como resultado, ellos probablemente las volverán aprender. Esto se convierte en un problema cuando cada PC es considerada. Ahora cada vez que cualquier PC en la red se encienda o se apague, cada switch en la red debe llevar un proceso de aging de las entradas de la tabla CAM. Tablas vacías significan más unicasts desconocidos, lo que significa más broadcast o paquetes inundados de toda la red. Afortunadamente, Los switches Catalyst cuentan con una funcionalidad que designa a un puerto como un caso especial. Se puede habilitar el STP PortFast en un puerto con una sola PC conectada a él. Como resultado, No se envían mensajes TCN cuando el estado de este puerto cambia, y el puerto se va directa al estado de forwarding.

Types of STP.

Common Spanning Tree.

El estándar IEEE802.1Q especifica cómo debe estar un vlan en un trunk entre switches. También especifica una sola instancia de STP que Referencia: Switch Operation for the CCNP BCMSN Exam, By David Hucaby.

compone todas las Vlans. Esta instancia es referida como Common Spanning Tree (CST). Todos los BPDUs de CST son transmitidos sobre el enlace trunk usando la native Vlan con frames Untagged. Teniendo un solo STP para varias Vlans simplifica la configuración de un switch y reduce la carga de CPU durante el cálculo de STP. Sin embargo, tener una sola instancia de STP puede tener limitaciones. Enlaces redundantes entre los switches serán bloqueados sin capacidad de balancear carga. En esta condición también puede ocurrir que CST permita reenvío por error en un enlace que no lleva una VLAN específica, mientras que otros enlaces serían bloqueados.

Per-Vlan Spanning Tree.

Cisco tiene una versión propietaria de STP que ofrece mayor flexibilidad que la versión CST. per-Vlan Spanning Tree (PVST) opera con instancias separadas de STP por cada Vlan individualmente. Esto permite que STP en cada Vlan sea configurado independientemente, ofreciendo mejor performance y puesta a punto para las condiciones específicas. Múltiples Spanning Trees también permiten la posibilidad de balanceo de carga sobre enlaces redundantes cuando los enlaces son asignados a diferentes Vlans. Un enlace podría enviar un conjunto de Vlans, mientras que otro enlace redundante puede enviar un conjunto diferente de Vlans. Debido a su naturaleza propietaria, PVST requiere del uso de Cisco Inter-Switch Link (ISL) encapsulación de enlaces troncales entre los switches. En las redes donde coexisten TSVP y CST, ocurren problemas de interoperabilidad. Cada uno requiere de un método troncal diferente, entonces las BPDUs nunca son intercambiadas entre los tipos de STP.

Per-Vlan Spanning Tree plus.

Cisco tiene una segunda version propietaria de STP que permite a dispositivos interoperar con ambos PVST y CST. Per-Vlan Spanning Tree Plus (PVST+) soporta eficientemente 3 grupos de STP en la misma red de Campus:

Catalyst Switches running PVST. Catalyst Switches running PVST+ Switches running CST Over 802.1Q


Para hacer esto, PVST+ actúa como un traductor entre grupos de switches CST y grupo de Switches PVST. PVST+ puede comunicarse directamente PVST mediante el uso del trunk ISL. Para comunicarse con CST, sin embargo, PVST+ intercambia BPDUs con el CST como Untagged frames sobre la native Vlan. BPDUs de otras instancias de STP (otras Vlans) se propagan a través de las porciones de las CST de la red por un túnel. PVST+ envía estas BPDUs mediante el uso una dirección única de multicast entonces los switches CST lo envían a los vecinos abajo de ellos sin interpretarlo primero. Eventualmente, el BPDUs tunneled alcanzaran otro PVST+ switches donde serán entendidas.

Spanning-Tree Configuration.

STP Root Bridge.

Tip:Por default, STP es habilitado para todas las vlan activas y en todos los puertos de un switch. STP debe permanecer habilitado en redes para prevenir Bridging Loops. Sin embargo, podría encontrar que STP se ha desactivado de alguna manera. Si una instancia entera de STP es desabilitada, usted la puede habilitar con los siguientes comandos de configuracion global:

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

Si STP fue desabilitado para una vlan especifica en un puerto especifico, se puede rehabilitar con el siguiente comando de configuracion de interface:

Switch (config-if)# spanning-tree vlan vlan-id


supportforums.cisco.com · web viewa modo de ejemplo, puede utilizar los siguientes comandos para...

Documents