Switches : Switches Cisco Catalyst de la serie 6500

Mejores prácticas para los Switches Catalyst de las series 6500/6000 y Swutches Catalyst de las series 4500/4000 que utilizan software Cisco IOS

21 Enero 2009 - Traducción manual
Otras Versiones: PDFpdf | Traducción Automática (31 Julio 2013) | Inglés (3 Septiembre 2006) | Comentarios

Contenidos

Introducción
Antes de comenzar
     Antecedentes
     Referencias
     Configuración básica
     Protocolos de planos de control de Catalyst
     VLAN 1
Características estándar
     Protocolo de troncal VLAN
     Negociación automática de Fast Ethernet
     Negociación automática de Ethernet Gigabit
     Protocolo de conexión troncal dinámica
     Spanning Tree Protocol
     EtherChannel
     Detección de enlace unidireccional
     Conmutación de capas múltiple
     Tramas gigantes
Funciones de seguridad del software Cisco IOS
     Funciones de seguridad básicas
     Soluciones para la seguridad de AAA
     TACACS+
Configuración de la administración
     Diagramas de la red
     Interfaz de administración y VLAN nativa del switch
     Administración fuera de banda
     Registro del sistema
     SNMP (Protocolo de administración simple de red):
     Network Time Protocol (protocolo de hora de red)
     Protocolo de detección de Cisco
Configuración de lista de control
     Comandos globales
     Comandos de interfaz
Discusiones relacionadas de la comunidad de soporte de Cisco

Introducción

Este documento proporciona las mejores prácticas para los switches Catalyst de las series 6500/6000 y 4500/4000 que ejecutan software Cisco IOS® en el Supervisor Engine.

Los switches Catalyst de las series 6500/6000 y los switches Catalyst de las series 4500/4000 soportan uno de estos sistemas operativos que se ejecutan en el Supervisor Engine.

  • Catalyst OS (CatOS)

  • Software Cisco IOS

Con CatOS, existe la opción de ejecutar el software Cisco IOS en las tarjetas secundarias del router o módulos como:

  • La tarjeta de función del switch multicapa (MSFC) en el Catalyst 6500/6000

  • El módulo 4232 de Capa 3 (L3) en el Catalyst 4500/4000

En este modo, existen dos líneas de comandos para la configuración:

  • La línea de comando CatOS para conmutación

  • La línea de comandos para el software Cisco IOS para enrutamiento

CatOS en el software del sistema, que se ejecuta en el Supervisor Engine. El software Cisco IOS que se ejecuta en el módulo de enrutamiento es una opción que requiere el software del sistema CatOS.

Para el software Cisco IOS, existe sólo una línea de comando para la configuración. En este modo, la funcionalidad de CatOS ha sido integrada al software Cisco IOS. La integración dio como resultado una única línea de comando para las configuraciones de conmutación y enrutamiento. En este modo, el software Cisco IOS es el software del sistema y reemplaza CatOS.

Ambos sistemas operativos, tanto el de CatOS como el del software Cisco IOS se implementan en redes críticas. CatOS, con la opción del software Cisco IOS para las tarjetas secundarias del router y los módulos, es soportado en estas series de switches:

  • Catalyst 6500/6000

  • Catalyst 5500/5000

  • Catalyst 4500/4000

El software del sistema Cisco IOS es soportado en estas series de switches:

  • Catalyst 6500/6000

  • Catalyst 4500/4000

Consulte el documento: Mejores prácticas para los switches Catalyst de las series 4500/4000, 5500/5000 y 6500/6000 que ejecutan Configuración y administración de CatOS para información sobre CatOS, ya que este documento cubre el software del sistema Cisco IOS.

El software Cisco IOS proporciona a los usuarios alguna de estas ventajas:

  • Una única interfaz del usuario

  • Una plataforma unificada de administración de redes

  • Características de QoS optimizadas

  • Soporte de conmutación distribuida

Este documento proporciona una guía para la configuración modular. Por consiguiente, se puede leer cada sección independientemente y hacer modificaciones en un tratamiento por fases. Este documento asume una compresión básica y familiaridad con la interfaz del usuario del software Cisco IOS. El documento no cubre el diseño global de la red de campus.

Antes de comenzar

Antecedentes

La solución que ofrece este documento representa años de experiencia en el campo de parte de los ingenieros de Cisco quienes trabajan con redes complejas y muchos de los clientes más grandes. En consecuencia, este documento enfatiza la configuración práctica que garantiza el éxito de la red. Este documento ofrece estas soluciones:

  • Soluciones que poseen, estadísticamente, el más amplio campo de exposición y por lo tanto, el riesgo más bajo.

  • Soluciones simples, que negocian un poco de flexibilidad para resultados predecibles.

  • Soluciones fáciles de manejar y que pueden configurar los equipos de funcionamiento de redes.

  • Soluciones que fomentan gran disponibilidad y estabilidad.

Referencias

Existen muchos sitios de referencia para la línea de productos de Catalyst 6500/6000 y Catalyst 4500/4000 en Cisco.com. Las referencias incluidas en esta sección proporcionan información más exhaustiva sobre los temas que trata este documento.

Consulte las Páginas de soporte de LAN switching para más información sobre cualquiera de los temas que cubre este documento. Las páginas de soporte proporcionan documentación de productos y también documentos sobre resolución de problemas y configuración.

Este documento proporciona referencias a material público en Internet como lectura complementaria. Sin embargo, otras referencias de educación y orientación son:

Configuración básica

Esta sección se refiere a las características implementadas cuando se utilizan la mayoría de las redes Catalyst.

Protocolos de planos de control de Catalyst

Esta sección se refiere a los protocolos que corren entre los switches en circunstancias normales de operación. Será útil una comprensión básica de los protocolos al abordar cada sección.

Tráfico de Supervisor Engine

Muchas de las funciones activadas en la red Catalyst necesitan dos o más switches para cooperar. Por lo tanto, debe haber un intercambio controlado de mensajes de señal de mantenimiento, parámetros de configuración y cambios de administración. Tanto si estos protocolos sean propiedad de Cisco, como los Protocolos de Detección de Cisco (CDP), como si se basan en normas, como IEEE 802.1D (Spanning Tree Protocol [STP]), todos poseen ciertos elementos en común cuando los protocolos se implementan en las series Catalyst.

En una trama básica de envío, los marcos de datos del usuario se originan en sistemas finales. La dirección de origen (SA) y la dirección de destino (DA) de los marcos de datos no se modifican en los dominios conmutados de Capa 2 (L2). Las tablas de búsqueda de la memoria de contenido direccional (CAM) en cada switch de Supervisor Engine son alimentadas por un proceso de aprendizaje de SA. Las tablas indican qué puerto de egreso envía cada trama recibida. Si se desconoce el destino o si la trama se destina a una dirección de transmisión o multidifusión, el proceso de aprendizaje estará incompleto. Cuando el proceso esté incompleto, la trama será enviada (inundada) fuera de todos los puertos en esa VLAN. El switch debe reconocer qué tramas serán conmutadas a través del sistema y qué tramas serán dirigidas al switch CPU. El switch CPU se conoce también como el Procesador de la administración de la red (NMP).

Las entradas especiales en la tabla CAM se utilizan para crear el plano de control de Catalyst. Estas entradas especiales se denominan entradas de sistema. El plano de control recibe y dirige el tráfico al NMP en un switch de puerto interno. Por lo tanto, con el uso de los protocolos con direcciones de destino MAC conocidos, el tráfico del plano de control puede separarse del tráfico de datos.

Cisco posee un Ethernet MAC de rango reservado y las direcciones de protocolo, como muestra la tabla en esta sección. Este documento cubre cada dirección reservada en detalle, pero esta tabla proporciona un resumen, con el fin de facilitar la lectura:

Función

SNAP1 Tipo de protocolo HDLC 2

MAC de multidifusión de destino

PAgP3

0x0104

01-00-0c-cc-cc-cc

PVST+, RPVST+4

0x010b

01-00-0c-cc-cc-cd

Bridge VLAN

0x010c

01-00-0c-cd-cd-ce

UDLD5

0x0111

01-00-0c-cc-cc-cc

CDP

0x2000

01-00-0c-cc-cc-cc

DTP6

0x2004

01-00-0c-cc-cc-cc

UplinkFast STP

0x200a

01-00-0c-cd-cd-cd

Árbol de expansión IEEE 802.1D

N/A—DSAP7 42 SSAP8 42

01-80-c2-00-00-00

ISL9

N/A

01-00-0c-00-00-00

VTP10

0x2003

01-00-0c-cc-cc-cc

Pausa IEEE 802.3x

N/A - DSAP 81 SSAP 80

01-80-C2-00-00-00>0F

1 SNAP = Protocolo de acceso de subred.

2 HDLC = Control del enlace de datos de alto nivel.

3 PAgP = Protocolo de agrupamiento de puertos.

4 PVST+ = Per VLAN Spanning Tree+ y RPVST+ = PVST+ rápido.

5 UDLD = Detección de enlace unidireccional.

6 DTP = Protocolo de conexión troncal dinámica.

7 DSAP = punto de acceso al servicio de destino.

8 SSAP = punto de acceso al servicio de origen.

9 ISL = Enlace entre switches.

10 VTP = Protocolo de troncal VLAN.

La mayoría de los protocolos de control de Cisco utilizan una encapsulación IEEE 802.3 SNAP, que incluye Control de enlace lógico (LLC) 0xAAAA03 e Identificador único organizacional (OUI) 0x00000C. Puede ver esto en una salida de analizador de LAN.

Estos protocolos suponen conectividad de punto a punto. Tenga en cuenta que el uso deliberado de direcciones de destino multidifusión activa dos switches Catalyst para comunicarse de manera transparente sobre switches que no son de Cisco. Los dispositivos que no entienden e interceptan las tramas simplemente las inundan. No obstante, las conexiones punto a multipunto a través de entornos de varios fabricantes pueden resultar en un comportamiento inconsistente. En general, evite las conexiones punto a multipunto a través de entornos de varios fabricantes. Los protocolos terminan en los routers de Capa 3 y funcionan solamente dentro de un dominio conmutado. Estos protocolos reciben prioridad sobre la información del usuario por el procesamiento y la programación del circuito integrado específico de la aplicación (ASIC) de ingreso.

Ahora la discusión se vuelve al SA. Los protocolos del switch utilizan direcciones MAC que se toman de un banco de direcciones disponibles. Un EPROM en el chasis proporciona un banco de direcciones disponibles. Ejecute los comandos show module para visualizar el rango de direcciones que se encuentran disponibles para cada módulo para el origen del tráfico como unidades de datos del protocolo bridge (BPDUs) o tramas ISL. Éste es una salida de comando de ejemplo:

>show module
…

Mod MAC-Address(es)                        Hw     Fw         Sw
--- -------------------------------------- ------ ---------- -----------------
1   00-01-c9-da-0c-1e to 00-01-c9-da-0c-1f 2.2    6.1(3)     6.1(1d)
    00-01-c9-da-0c-1c to 00-01-c9-da-0c-1
    00-d0-ff-88-c8-00 to 00-d0-ff-88-cb-ff
!--- Estos son los MAC para el tráfico de origen.

VLAN 1

VLAN 1 tiene un significado especial en las redes Catalyst.

Cuando establece conexión troncal, el Supervisor Engine de Catalyst utiliza siempre la VLAN predeterminada, VLAN1, para etiquetar un número de protocolos de control y administración. Dichos protocolos incluyen CDP, VTP y PAgP. Todos los puertos de switches, que incluyen la interfaz sc0 interna, están configurados de manera predeterminada para ser miembros de VLAN 1. Todas las troncales transportan VLAN 1 de manera predeterminada.

Estas definiciones son necesarias para ayudar a clarificar algunos términos bien utilizados en la red Catalyst:

  • Esta VLAN de administración es donde reside sc0 para CatOS y los switches de menor capacidad. Se puede modificar esta VLAN. Tenga esto en cuenta cuando esté interconectando CatOS y los switches Cisco IOS.

  • La VLAN nativa es la VLAN a la que vuelve un puerto cuando no está realizando conexiones troncales. Además, la VLAN nativa es la VLAN sin etiquetas en una troncal IEEE 802 1Q.

Hay varios motivos válidos para ajustar una red y alterar el comportamiento de los puertos VLAN 1:

  • Cuando el diámetro de VLAN 1, como cualquier otra VLAN, se torna lo suficientemente grande como para ser un riesgo para la estabilidad, particularmente desde una perspectiva de STP, se debe efectuar un recorte de la VLAN. Consulte la sección Interfaz de administración de switches y la sección VLAN nativa para más detalles.

  • Los datos del plano de control en la VLAN 1 deben mantenerse separados de los datos del usuario para simplificar la resolución de problemas y maximizar los ciclos de CPU disponibles. Evite bucles de Capa 2 en VLAN 1 al diseñar redes multicapa de campus sin STP. Para evitar los bucles de Capa 2, borre manualmente la VLAN 1 de los puertos troncales.

En resumen, tenga en cuenta que esta información sobre las actualizaciones de las troncales:

  • CDP, VTP, y PAgP son siempre reenviadas en enlaces troncales con un indicador VLAN 1. Esto ocurre incluso si se eliminó la VLAN1 de las troncales y no es la VLAN nativa. Si elimina la VLAN 1 para la información del usuario, la acción no tendrá impacto alguno en el tráfico del plano de control que aún se envía por medio de la VLAN 1.

  • En una troncal ISL, los paquetes DTP se envían en VLAN1. Este es el caso aun cuando se eliminó la VLAN1 de la troncal y no es la VLAN nativa. En una troncal 802.1Q, los paquetes DTP son enviados a la VLAN nativa. Este es el caso aun cuando se eliminó la VLAN1 nativa de la troncal.

  • En PVST+, BPDU las 802.1Q IEEE son enviadas sin etiqueta a la VLAN1 del common Spanning Tree común para interoperar con otros proveedores, excepto que la VLAN 1 haya sido eliminada de la troncal. Este es el caso independientemente de la configuración de la VLAN nativa. Cisco PVST+ BPDU se envían y se etiquetan para todas las otras VLAN. Consulte la sección Spanning Tree Protocol para más detalles.

  • Las BDU de árbol de expansión múltiple (MST) 802.1s se envían siempre en VLAN 1 tanto en troncales ISL como 802.1Q. Esto se aplica aun cuando VLAN 1 ha sido eliminada de las troncales.

  • No elimine o desactive la VLAN 1 en las troncales entre los bridges MST y los bridges PVST +. Sin embargo, en el caso que la VLAN 1 se desactive, el bridge MST debe tornarse raíz para que todas las VLAN eviten la ubicación del bridge MST de los puertos delimitadores en el estado de no concordancia con la raíz. Consulte Understanding Multiple Spanning Tree Protocol (802.1s) [Introducción al Spanning Tree Protocol múltiple (802.1s)] para más detalles.

Características estándar

Esta sección del documento se basa en características de conmutación que son comunes a todos los entornos. Configure estas características en todos los dispositivos de software Cisco IOS de los switches Catalyst en la red del cliente.

Protocolo de troncal VLAN

Propósito

Un dominio VTP, también denominado dominio de administración de VLAN, está formado por uno o más switches interconectados a través de una troncal que comparte el mismo nombre de dominio VTP. VTP se designa para permitir a los usuarios realizar modificaciones en las configuraciones VLAN de manera central en uno o más switches. VTP comunica automáticamente las modificaciones a todos los otros switches en el dominio VTP (red). Puede configurarse un switch para que se encuentre en un solo dominio VTP. Antes de crear las VLAN, determine el modo VTP que se utilizará en la red.

Información operativa general

VTP es un protocolo de mensajes de Capa 2. VTP administra la adición, la eliminación y renombra las VLAN en toda la red para mantener la consistencia en la configuración de las VLAN. VTP minimiza las configuraciones erróneas y las inconsistencias de las configuraciones que pueden dar como resultado gran cantidad de problemas. Estos problemas incluyen nombre de VLAN duplicados, las especificaciones de tipo VLAN especificadas y las violaciones de seguridad.

De manera predeterminada, el switch se encuentra en el modo servidor VTP y en el estado de dominio de no administración. Estos parámetros predeterminados se modifican cuando el switch recibe un anuncio para un dominio sobre un enlace troncal o cuando se configura un dominio de administración.

El protocolo VTP comunica entre los switches con el uso de un destino Ethernet multidifusión conocido MAC (01-00-0c-cc-cc-cc) y el tipo de protocolo SNAP HDLC 0x2003. Al igual que los protocolos intrínsecos, VTP también utiliza una encapsulación IEEE 802.3 SNAP, que incluye LLC 0xAAAA03 y OUI0x00000C. Puede ver esto en el rastro de un analizador de LAN. VTP no funciona en los puertos no troncales. Por consiguiente, los mensajes no pueden ser enviados hasta que DTP haya formado la troncal de manera rápida. En otras palabras, VTP es un tamaño de carga útil de ISL o 802.1Q.

Los tipos de mensajes incluyen:

  • Anuncios de resumen cada 300 segundos (seg)

  • Anuncios de subgrupos y anuncios de pedido cuando hay modificaciones

  • Uniones cuando el recorte de VTP está activado

El número de revisiones de las configuraciones de VTP se incrementa en uno con cada modificación en el servidor, y esa tabla se propaga a través del dominio.

Al eliminar una VLAN, los puertos que eran miembro de la VLAN introduzca un estado desactivado. De igual manera, si un switch en el modo cliente no puede recibir la tabla VTP VLAN en el inicio, de un servidor VTP u otro cliente VTP, todos los puertos en las VLAN además de las VLAN 1 predeterminadas serán desactivadas.

Se puede configurar la mayoría de los switches Catalyst para que funcionen en cualquiera de estos modos de VTP:

  • Servidor: en el modo servidor VTP, se puede:

    • Crear VLAN

    • Modificar las VLAN

    • Eliminar las VLAN

    • Especificar otros parámetros, como la versión VTP y el recorte VTP, para el dominio completo de VTP

    Los servidores VTP anuncian su configuración VLAN a los otros switches en el mismo dominio VTP. Los servidores VTP también sincronizan las configuraciones VLAN con otros switches sobre una base de anuncios que se reciben a través de enlaces troncales. El servidor VTP es el modo predeterminado.

  • Cliente: los clientes VTP se comportan de la misma manera que los servidores VTP. Sin embargo no podrá crear, modificar o eliminar las VLAN en un cliente VTP. Además, el cliente no recuerda la VLAN después de reiniciar debido a que no se escribe ninguna información VLAN en NVRAM.

  • Transparente: los switches VTP transparente no participan en VTP. Un switch VTP transparente no anuncia su configuración VLAN y no sincroniza su configuración VLAN sobre una base de anuncios recibidos. Sin embargo, en la versión 2 VTP, los switches transparentes reenvían anuncios VTP que reciben los switches por sus interfaces troncales.

Función

Servidor

Cliente

Transparente

Off1

Emisión de mensajes VTP

No

Escuchar mensajes VTP

No

Crear VLAN

No

Sí (sólo de importancia local)

Recordar VLAN

No

Sí (sólo de importancia local)

1El software Cisco IOS no posee la opción de deshabilitar el VTP mediante el modo desactivado.

En la tabla siguiente hay un resumen de la configuración original:

Función

Valor predeterminado

Nombre de dominio de VTP

Nulo

modo VTP

Servidor

Versión del VTP

La versión 1 está activada

Recorte VTP

Desactivado

En el modo VTP transparente, las actualizaciones de VTP simplemente se ignoran. La dirección MAC de multidifusión del VIP se elimina de la CAM del sistema que se utiliza normalmente para recoger las tramas de control y dirigirlas al Supervisor Engine. Dada la forma en que el protocolo utiliza una dirección de multidifusión, el switch en modo transparente o un switch de otro fabricante simplemente inunda la trama a los demás controladores Cisco en el dominio.

La versión 2 del VTP (VTPv2) permite la flexibilidad funcional que describe esta lista. Sin embargo, VTPv2 no es compatible con la versión 1 de VTP (VTPv1):

  • Soporte Token Ring.

  • Soporte para información del VTP no identificada: los switches propagan los valores que no pueden analizar.

  • Modo transparente dependiente de la versión: el modo transparente no verifica el nombre del dominio. Esta opción permite el uso de más de un dominio a través de un dominio transparente.

  • Propagación del número de versión: en caso de que todos los switches soporten VTPv2, todos los switches podrán ser activados mediante la configuración de un único switch.

Consulte Introducción y configuración del Protocolo de conexiones troncales de la VLAN (VTP) para más información.

Funcionamiento de VTP en el software Cisco IOS

Las modificaciones de configuración en CatOS se escriben a NVRAM inmediatamente después de que se realiza una modificación. En cambio, el software Cisco IOS no guardará las modificaciones de configuración a NVRAM excepto que se ejecute el comando copy run start. El cliente VTP y los sistemas de servidores exigen actualizaciones VTP desde otros servidores VTP para que se guarden inmediatamente en NVRAM sin intervención del usuario. Los requisitos de actualización de VTP se alcanzan mediante el funcionamiento de CatOS predeterminado, pero el modelo de actualización del software Cisco IOS exige un funcionamiento de actualización alternativo.

Para esta alteración, una base de datos VLAN se introdujo en el software Cisco IOS para Catalyst 6500 como método para guardar inmediatamente las actualizaciones de VTP para los servidores y clientes VTP. En algunas versiones de software, esta base de datos VLAN con forma de un archivo aparte en NVRAM, denominado el archivo vlan.dat. Verifique su versión de software para determinar si es necesaria una copia de respaldo de la base de datos VLAN. Puede ver la información VTP/VLAN almacenada en el archivo vlan.dat para el cliente VTP o el servidor VTP si ejecuta el comando show vtp status.

Toda la configuración VTP/VLAN no se guarda en el archivo startup config en NVRAM cuando se ejecuta el comando copy run start en estos sistemas. Esto no se aplica a los sistemas que ejecutan VTP transparente. Los sistemas transparentes de VTP guardan todas las configuraciones VTP/VLAN en el archivo startup config en NVRAM cuando se ejecuta el comando copy run start.

En las versiones del software IOS de Cisco anteriores a la versión 12.2(15)JA del software Cisco IOS, puede configurar VTP y VLAN a través de la base del modo de base de datos VLAN El modo de base de datos VLAN es un modo separado del modo de configuración global. El motivo de este requisito de configuración es que, cuando configura el dispositivo en el modo servidor VTP o el modo cliente VTP, los vecinos VTP pueden actualizar la base de datos VLAN dinámicamente a través de los anuncios VTP. No necesita autopropagar estas actualizaciones a la configuración. Por lo tanto, la base de datos VLAN y la información VTP no se almacena en la configuración principal, pero se almacena en NVRAM en un archivo con el nombre de vlan.dat.

Este ejemplo muestra cómo crear una VLAN Ethernet en modo base de datos VLAN:

Switch#vlan database
Switch(vlan)#vlan 3
VLAN 3 added:
Name: VLAN0003
Switch(vlan)#exit
APPLY completed.
Exiting....

En la versión 12.1(11b)E y posterior del software Cisco IOS, puede configurar VTP y VLAN a través de la base de datos VLAN o través del modo de configuración global. En el servidor modo VTP o el modo VTP transparente, la configuración de las VLAN sigue actualizando el archivo vlan.dat en NVRAM. Sin embargo, estos comandos no se guardan en la configuración. Por lo tanto, los comandos no se muestran en al configuración en ejecución.

Consulte la sección Configuración de VLAN en modo de configuración global del documento Configuración de VLAN para obtener más información.

Este ejemplo muestra cómo crear una VLAN Ethernet en el modo de configuración global y cómo verificar la configuración:

Switch#configure terminal
Switch(config#vtp mode transparent
Setting device to VTP TRANSPARENT mode.
Switch(config#vlan 3
Switch(config-vlan)#end
Switch#
OR
Switch#vlan database
Switch(vlan#vtp server
Switch device to VTP SERVER mode.
Switch(vlan#vlan 3
Switch(vlan#exit
APPLY completed.
Exiting....
Switch#

Nota: La configuración de VLAN se almacena en el archivo vlan.dat, que se almacena en la memoria no volátil. Para realizar un a copia de respaldo completa de su configuración, incluya el archivo vlan.dat en la copia de respaldo junto con la configuración. Después, si todo el switch o el módulo del Supervisor Engine exige un reemplazo, el administrador de la red deberá cargar estos dos archivos para reestablecer la configuración completa:

  • El archivo vlan.dat

  • El archivo de configuración

VTP y VLAN extendidas

La función ID del sistema ampliado se utiliza para habilitar la identificación VLAN de alcance extendido. Cuando la ID del sistema ampliado se activa, se desactiva el conjunto de direcciones MAC utilizado para el árbol de expansión de VLAN y deja una única dirección MAC que identifica el switch. La versión 11.2 (11b)EX del software Cisco IOS y 12.1(13)E introduce el soporte de ID de sistema ampliado para Catalyst 6000/6500 para ofrecer soporte de VLAN 4096 en cumplimiento de la norma IEEE 802.1Q. Esta función se introdujo en la versión 12.1(12c)EW del software Cisco IOS para los switches Catalyst 4000/4500. Estas VLAN se organizan en diferentes rangos, cada uno de los cuales puede usarse de manera diferente. Alguna de estas VLAN se propagan a otros switches en red cuando se utiliza VTP. Las VLAN de alcance extendido no se propagan, por lo tanto debe configurar las VLAN de rango ampliado manualmente en cada dispositivo de red. Esta función de ID de sistema ampliado equivale a la función de reducción de dirección MAC en Catalyst OS.

Esta tabla describe los rangos de VLAN:

VLAN

Rango

Uso

¿Propagados por VTP?

0, 4095

Reservado

Sólo para uso del sistema. No puede visualizar o utilizar estas VLAN.

1

Normal

Cisco predeterminado. Puede utilizar esta VLAN, pero no puede eliminarla.

2–1001

Normal

En cuanto VLAN Ethernet, Puede crear, usar y eliminar estas VLAN.

1002–1005

Normal

Valores predeterminados de Cisco para FDDI y Token Ring. No es posible eliminar las VLAN 1002–1005.

1006–4094

Reservado

Para VLAN Ethernet únicamente.

No

Los protocolos del switch utilizan una dirección MAC procedente de un banco de direcciones disponibles que suministran una EPROM en el chasis como parte de los identificadores de bridge para las VLAN que se ejecutan bajo PVST+ y RPVST+. Los switches de las series Catalyst 6000/6500 y Catalyst 4000/4500 soportan tanto 1024 como direcciones MAC 64 que dependen del tipo de chasis.

Los switches Catalyst con direcciones MAC 1024 no permiten ID de sistema ampliado de manera predeterminada. Las direcciones MAC se asignan de manera secuencial, con la primera dirección MAC en el rango asignado a VLAN 1, la segunda dirección MAC en el rango asignado a VLAN 2 y así sucesivamente. Esto permite a los switches soportar VLAN 1024 y cada VLAN utiliza un único identificador de bridge.

Tipo de chasis

Dirección de chasis

WS-C4003-S1, WS-C4006-S2

1024

WS-C4503, WS-C4506

641

WS-C6509-E,WS-C6509, WS-C6509-NEB, WS-C6506-E, WS-C6506, WS-C6009, WS-C6006, OSR-7609-AC, OSR-7609-DC

1024

WS-C6513, WS-C6509-NEB-A, WS-C6504-E, WS-C6503-E, WS-C6503, CISCO7603, CISCO7606, CISCO7609, CISCO 7613

641

1 El chasis con direcciones MAC 64 activa la ID de sistema ampliado de manera predeterminada y la función no puede ser desactivada.

Consulte la Sección Introducción al ID del bridge de Configuración STP e IEEE 802.1 MST para obtener más información.

En los switches de las series Catalyst con direcciones MAC 1024, para habilitar la ID de sistema ampliado permite el soporte de VLAN 4096 que se ejecutan bajo PVST+ o 16 instancias MISTP para tener identificadores únicos sin el aumento del número de direcciones MAC que se necesitan en el switch. La ID de sistema ampliado reduce el número de direcciones MAC que necesita STP de una por cada VLAN o o instancia MISTP a una por switch.

Esta figura muestra el identificador de bridge cuando la ID de sistema ampliado no está activada. El identificador de bridge consiste en una prioridad de bridge de 2 bytes y una dirección MAC de 6 bytes.

185-t.gif

La ID de sistema ampliado modifica la porción del Identificador de bridge del Spanning Tree Protocol (STP) de las Unidades de dato de protocolo de bridge (BPDU). El campo original de prioridad de 2 bytes se divide en 2 campos; un campo de prioridad de 4 bit y una extensión de ID de sistema de 12 bit que permite la numeración de Vlan de 0-4095.

185-u.gif

Cuando la ID de sistema ampliado se activa en los switches Catalyst para aprovechar el rango extendido de las VLAN, es necesario que esté activado en todos los switches dentro del mismo dominio de STP. Esto es necesario para mantener consistentes los cálculos de raíz STP en todos los switches. Una vez que la ID de sistema ampliado se activa, la prioridad del bridge de raíz se torna un múltiplo de 4096 más la VLAN ID. Los switches sin ID de sistema ampliado pueden solicitar una raíz inadvertidamente debido a que tienen un granularidad más fina en la selección de su ID del bridge.

Mientras que se recomienda mantener la configuración consistente de ID de sistema ampliado dentro del mismo dominio STP, no es factible imponer la ID de sistema ampliado en todos los dispositivos de red cuando introduce un nuevo chasis con la dirección MAC 64 al dominio STP. Sin embargo, es importante entender que cuando dos sistemas se configuran con la misma prioridad del Árbol de expansión, el sistema sin ID de sistema ampliado posee una mejor prioridad de árbol de expansión. Ejecute este comando para habilitar la configuración de ID de sistema ampliado:

spanning-tree extend system-id

Las VLAN internas están asignadas en orden ascendente, que comienzan en VLAN 1006. Se recomienda asignar al usuario las VLAN lo más cerca posible de VLAN 4094 para evitar conflictos entre las VLAN de usuario y las VLAN internas. Ejecute el comando show vlan internal usage en un switch para mostrar las VLAN asignadas internamente.

Switch#show vlan internal usage

VLAN Usage
---- --------------------
1006 online diag vlan0
1007 online diag vlan1
1008 online diag vlan2
1009 online diag vlan3
1010 online diag vlan4
1011 online diag vlan5
1012 PM vlan process (trunk tagging)
1013 Port-channel100
1014 Control Plane Protection
1015 L3 multicast partial shortcuts for VPN 0
1016 vrf_0_vlan0
1017 Egress internal vlan
1018 Multicast VPN 0 QOS vlan
1019 IPv6 Multicast Egress multicast
1020 GigabitEthernet5/1
1021 ATM7/0/0
1022 ATM7/0/0.1
1023 FastEthernet3/1
1024 FastEthernet3/2
------deleted------

En IOS nativo, vlan internal allocation policy descending puede configurarse para que las VLAN internas se asignen en orden descendente. El equivalente de CLI para el software CatOS no está oficialmente soportado.

vlan internal allocation policy descending

Recomendación sobre la configuración de Cisco

Las VLAN pueden crearse cuando un Catalyst 6500/6000 se encuentra en modo servidor VTP, aun sin el nombre de dominio VTP. Configure el nombre de dominio VTP primero, antes de configurar la VLAN en los switches Catalyst 6500/6000 que ejecutan el software del sistema Cisco IOS. La configuración en este orden mantiene consistencia con otros switches Catalyst que ejecutan CatOS.

No hay una recomendación específica acerca de si se debe utilizar los modos cliente/servidor VTP o los modos VTP transparentes. Algunos clientes prefieren la comodidad del modo cliente/servidor VTP, a pesar de algunas consideraciones que se informan en esta sección. La recomendación es tener dos switches de modo servidor en cada dominio para la redundancia típica de dos switches de capa de distribución. Establezca el resto de los switches en el dominio al modo cliente. Al implementar el modo cliente/servidor con el uso de VTPv2, recuerde que un número de revisión mayor siempre se acepta en el mismo dominio VTP. Si un switch que fue configurado tanto en el modo cliente VTP o en el modo servidor se introduce al dominio VTP y posee un número de revisión mayor que los servidores VTP existentes, este sobrescribirá la base de datos VLAN dentro del dominio VTP. Si la modificación de la configuración no es intencional y las VLAN se eliminan, esta sobreescritura puede provocar una mayor pausa en la red. Para asegurar que los switches cliente o servidores poseen siempre un número de revisión de configuración menor que la del servidor, modifique el nombre del dominio cliente VTP a algo distinto al nombre estándar y luego vuelva al estándar. Esta acción establece la revisión de la configuración en el cliente a 0.

Existen ventajas y desventajas en la habilidad VTP para realizar modificaciones en una red. Muchas empresas prefieren un método cuidadoso y la utilización del modo VTP transparente por las siguientes razones:

  • Esta práctica facilita un buen control de cambio debido a que los requisitos para modificar una VLAN en un switch o puerto troncal debe ser considerado un switch a la vez.

  • El modo VTP transparente limita el riesgo de un error del administrador, como la eliminación accidental de una VLAN. Esos errores pueden afectar todo el dominio.

  • Las VLAN pueden separarse de las troncales hacia los switches que no poseen puertos en la VLAN. Esto da como resultado que la inundación de tarmas sea más eficaz en el ancho de banda. El recorte manual también posee un diámetro reducido de árbol de expansión. Consulte la sección Protocolo de conexión troncal dinámica para más información Una configuración VLAN por switch también facilita esta práctica.

  • No hay riesgo de que un nuevo switch ingrese en la red con un número de revisión VTP mayor que sobrescriba la configuración completa del dominio VLAN.

  • El modo VTP transparente del software Cisco IOS soportan Campus Manager 3.2, que es parte de CiscoWorks2000. La anterior restricción que le exigía tener al menos un servidor en un dominio VTP ha sido eliminada.

Comandos VTP

Comentarios

vtp domain name

El CDP verifica el nombre para ayudar a impedir que no haya problemas de cableado entre los dominios. El nombre del dominio distingue entre mayúsculas y minúsculas.

vtp mode {server | client | transparent}

VTP funciona en uno de estos tres modos.

vlan vlan_number

Esto crea una VLAN con la ID proporcionada.

switchport trunk allowed vlan_range

Este es un comando de la interfaz que habilita a las troncales para transportar VLAN donde sea necesario. El valor predeterminado es todas las VLAN.

switchport trunk pruning vlan_range

Este es un comando de la interfaz que limita el diámetro STP mediante el recorte manual, como por ejemplo en las troncales desde la capa de distribución a la capa de acceso, donde no existe la VLAN. De manera predeterminada, todas las VLAN son aptas para recorte.

Otras opciones

VTPv2 es un requisito en los entornos Token Ring, donde el modo cliente/servidor es altamente recomendado.

La sección Recomendación sobre la configuración de Cisco de este documento apoya los beneficios del recorte de VLAN para reducir la inundación de tramas innecesaria. El comando vtp pruning recorta las VLAN automáticamente, lo cual detiene la inundación ineficiente de las tramas en donde no son necesarias.

Nota: A diferencia del recorte manual de VLAN, el recorte automático no limita el diámetro del árbol de expansión.

La IEEE produjo una arquitectura basada en normas para alcanzar resultados similares al VTP. Como miembro del Protocolo de registro de atributo genérico 802.1Q (GARP), el Protocolo de registro de VLAN genérico (GVRP) permite la interfuncionabilidad en la administración de VLAN entre proveedores. Sin embargo, la GVRP se encuentra fuera del alcance de este documento.

Nota: El software Cisco IOS no posee la capacidad del modo VTP desconectado y sólo soporta VTPv1 y VTPv2 con recorte.

Negociación automática de Fast Ethernet

Propósito

La negociación automática es una función opcional de la norma IEEE 802.3u Fast Ethernet (FE). La negociación automática permite a los dispositivos intercambiar automáticamente la información sobre la velocidad y las capacidades dúplex sobre un enlace. La negociación automática funciona en la Capa 1 (L1). La función se realiza en todos los puertos que se asignan a las áreas donde los usuarios o dispositivos transitorios se conectan a la red. Los ejemplos incluyen switches de capas de acceso y concentradores.

Información operativa general

La negociación automática utiliza una versión modificada de la prueba de integridad del enlace para los dispositivos 10BASE-T para negociar la velocidad e intercambiar otros parámetros de negociación automática. La prueba de integridad del enlace 10BASE-T original se denomina Pulso de enlace normal (NLP). La versión modificada de la prueba de integridad del enlace para La negociación automática de 10/100 Mbps se denomina Pulso de enlace normal (FLP). Los dispositivos 10BASE-T esperan un impulso de ráfaga cada 16 (+/-8) milisegundos (ms) como parte de la prueba de integridad del enlace. FLP para que la negociación automática 10/100-Mbps envíe estos impulsos cada 16 (+/-8) ms con los pulsos adicionales cada 62.5 (+/-7) microsegundos. Los pulsos dentro de la secuencia de ráfaga generan las palabras del código que se utilizan para el intercambio de compatibilidad entre los socios.

En 10BASE-T, un pulso de enlace es enviado siempre que aparece una estación. Esto es un pulso simple que se envía cada 16 ms. Los dispositivos 10BASE-T también envían un pulso de enlace cada 16 ms cuando el enlace está inactivo. Los pulsos de enlace también son llamados latido o NLP.

Un dispositivo 100BASE-T envía FLP. Este pulso es enviado como una ráfaga en vez de un pulso. Esta ráfaga se completa en 2 ms y nuevamente repetida cada 16 ms. En la inicialización, el dispositivo transmite un mensaje de16-bit FLP al socio de enlace para la negociación de velocidad, dúplex y control de flujo. Este mensaje de 16-bit se envía repetidamente hasta que el mensaje es reconocido por el socio.

Nota: Para la especificación IEEE 802.3u, no puede configurar manualmente un socio de enlace para 100-Mbps dúplex completo y aun autonegociar a dúplex completo con el otro socio de enlace. Un intento para configurar un socio de enlace para 100-Mbps dúplex completo y el otro socio de enlace para la autonegociación da como resultado una discordancia dúplex. La discordancia dúplex resulta debido a que un socio de enlace autonegocia y no observa ningún parámetro de negociación automática del otro socio de enlace. El primer socio de enlace está predeterminado con una configuración semidúplex

Todos los módulos de conmutación Ethernet de Catalyst 6500 soportan 10/100 Mbps y semidúplex o dúplex completo. Ejecute el comando show interface capabilities para verificar la funcionalidad en otro switch Catalyst.

Una de las causas más comunes en los problemas de desempeño en los enlaces 10/100-Mbps Ethernet tienen lugar cuando un enlace funciona a semidúplex mientras el otro puerto funciona a dúplex completo. Esta situación sucede ocasionalmente cuando se reinicia uno o ambos puertos en un enlace y el proceso de negociación automática no resulta en la misma configuración para ambos socios de enlace. La situación además sucede cuando se vuelve a configurar sólo un lado de un enlace y se olvidan de volver a configurar el otro lado. Se puede evitar la necesidad de las llamadas de soporte relacionadas si:

  • Crea una política que necesita la configuración de los puertos para el comportamiento necesario para todos los dispositivos no transitorios.

  • Hace cumplir la política con medidas de control de cambio adecuadas.

Los síntomas típicos del desempeño emiten un aumento de la secuencia de verificación de trama (FCS), verificación por redundancia cíclica (CRC), alineación o fragmentos minúsculos en el switch.

En el modo semidúplex, se posee un par de cables de recepción y otro par de transmisión. Ambos cables no pueden usarse a la misma vez. El dispositivo no puede transmitir cuando existe un paquete en el lado receptor.

En el modo dúplex completo, se posee el mismo par de cables de transmisión y recepción. Si embargo, ambos pueden utilizarse al mismo tiempo ya que las funciones de Detección de portadora y Detección de colisiones han sido desactivadas. El dispositivo puede transmitir y recibir al mismo tiempo.

Por consiguiente, una conexión de semidúplex a dúplex completo funciona, pero existe un gran número de colisiones en el lado semidúplex que resultan en un desempeño deficiente. Las colisiones se producen debido a que el dispositivo que se configura a dúplex completo puede transmitir al mismo tiempo que el dispositivo recibe información.

Los documentos en esta lista tratan la negociación automática en detalle. Estos documentos explican cómo funciona la negociación automática y discute varias opciones de configuración:

Un error muy común acerca de la negociación automática es que es posible configurar manualmente un socio de enlace para 100-Mbps dúplex completo y aun autonegociar a dúplex completo con el otro socio de enlace. De hecho, un intento por hacerlo resulta en una discordancia dúplex. Esto es una consecuencia debido a que un socio de enlace autonegocia, no observa ningún parámetro de negociación automática del otro socio de enlace y está predeterminado con una configuración semidúplex.

Muchos de los módulos de conmutación Ethernet de Catalyst soportan 10/100Mbps y semidúplex y dúplex completo. No obstante, puede confirmar esto si ejecuta el comando show interface mod/port capabilities.

FEFI

La Indicación de fallo final (FEFI) protege las interfaces 100BASE-FX (fibra) y Gigabit mientras que la negociación automática protege 100BASE-TX (cobre) contra fallos relacionados con la señalización/capa física.

Un fallo final es un error en el enlace que puede detectar una estación mientras que la otra estación no puede. Un ejemplo es un cable de transmisión desconectado. En este ejemplo, la estación remitente recibe la información válida y detecta que el enlace es bueno a través del monitor de integridad. La estación remitente no puede, sin embargo, detectar que la otra estación no recibe la transmisión. Una estación 100BASE-FX que detecta ese fallo remoto puede modificar INACTIVO la secuencia transmitida para enviar un patrón de bit especial para informar al vecino del fallo remoto. El patrón de bit especial se lo conoce como el patrón FEFI-IDLE. El patrón FEFI-IDLE posteriormente activa un un cierre del puerto remoto (errDisable). Consulte la sección Detección de enlace unidireccional de este documento para obtener más información sobre protección contra fallos.

Estos soportes de módulos/hardware para switches FEFI

  • Catalyst 6500/6000 y 4500/4000:

    • Todos los módulos 100BASE-FX y los módulos GE.

Recomendación del puerto de infraestructura de Cisco

Ya sea para configurar la negociación automática en enlaces 10/100-Mbps o para la codificación de velocidad y dúplex finalmente depende del tipo de socio de enlace o dispositivo final que haya conectado al puerto del switch Catalyst. La negociación automática entre los dispositivos finales y los switches Catalyst generalmente funcionan bien y los switches Catalyst cumplen con la especificación IEEE 802.3u. Sin embargo, cuando la tarjeta de interfaz de red (NIC) o los switches de otros proveedores no cumplen exactamente, pueden aparecer problemas. Además, las funciones avanzadas específicas del proveedor que no se describen en la especificación IEEE 802.3u para la negociación automática 10/100-Mbps puede provocar incompatibilidad de hardware y otros inconvenientes. Este tipo de características avanzadas incluyen la autopolaridad y la integridad del cableado. Este documento proporciona un ejemplo:

En determinadas situaciones, necesita establecer un host, la velocidad del puerto y el dúplex. En general, complete estos pasos básicos de solución de problemas:

  • Asegúrese de que la negociación automática se encuentre configurada en ambos lados del enlace o que el código de fuente se encuentre configurado en ambos lados.

  • Verifique las release notes para las advertencias.

  • Verifique la versión del controlador NIC o del sistema operativo que ejecute. Generalmente se necesita el último controlador o parche.

Como regla, primero utilice la negociación automática para cualquier tipo de socio de enlace. Existen beneficios evidentes para la configuración de la negociación automática para dispositivos transitorios como los equipos portátiles. La negociación automática también funciona bien con otros dispositivos, por ejemplo:

  • Con dispositivos no transitorios como los servidores y estaciones de trabajo fijas.

  • De switch a switch.

  • De switch a router.

Sin embargo, por alguna de las razones que se enumeran en esta sección, pueden aparecen los problemas de negociación. Consulte Configuración y resolución de problemas de negociación automática semidúplex y dúplex completa de Ethernet 10/100/1000Mb para los pasos de resolución básicos en estos caso.

Negociación automática inhabilitada para:

  • Puertos que soportan dispositivos de infraestructura de red como los switches y los routers.

  • Otros sistemas finales no transitorios como los servidores e impresoras.

Siempre codifique la velocidad y el dúplex para estos puertos.

Manualmente configure estas configuraciones de enlace 10/100-Mbps para velocidad y dúplex, que son generalmente 100-Mbps dúplex completo:

  • De switch a switch.

  • De switch a servidor.

  • De switch a router.

Si la velocidad de puerto se establece en automática en un puerto Ethernet de 10/100 Mbps, tanto la velocidad y el dúplex se autonegocian. Ejecute este comando de interfaz para establecer el puerto en auto:

Switch(config)#interface fastethernet slot/port
Switch(config-if)#speed auto
!--- Este es el valor predeterminado.

Emita estos comandos de interfaz para realizar configurar la velocidad el dúplex:

Switch(config)#interface fastethernet slot/port
Switch(config-if)#speed {10 | 100 | auto}
Switch(config-if)#duplex {full | half}

Recomendación del puerto de acceso de Cisco

Los usuarios finales, los trabajadores móviles y los host transitorios necesitan negociación automática para minimizar la administración de estos hosts. Puede hacer funcionar la negociación automática también con los switches Catalyst. Generalmente se necesita los últimos controladores NIC.

Ejecute estos comando globales para habilitar la negociación automática de la velocidad para el puerto:

Switch(config)#interface fastethernet slot/port
Switch(config-if)#speed auto

Nota: Si la velocidad de puerto se establece en automática en un puerto Ethernet de 10/100 Mbps, tanto la velocidad y el dúplex se autonegocian. No puede modificar el modo dúplex de los puertos de negociación automática.

Cuando las NIC o los switches de otros proveedores no cumplen exactamente con la especificación IEEE 802.3u, pueden aparecer problemas. Además, las funciones específicas de los proveedores que no se describen en la especificación IEEE 802.3u para la negociación automática 10/100-Mbps puede provocar incompatibilidad del hardware y otros problemas. Esas funciones avanzadas incluyen la autopolaridad y la integridad del cableado.

Otras opciones

Cuando la negociación automática se desactiva entre los switches, también se puede perder la indicación de fallo de Capa 1 debido a ciertos problemas. Utilice los protocolos de Capa 2 para incrementar la detección de fallos como el UDLD agresivo.

La negociación automática no detecta estas situaciones, aun cuando la negociación automática se encuentra inhabilitada.

  • Los puertos se pueden atascar y no recibir o transmitir

  • Un lado de la línea está activo pero el otro se ha desactivado.

  • Los cables de fibra están mal conectados.

La negociación automática no detecta estos problemas debido a que no se encuentran en la capa física. El problema puede conducir a bucles STP o agujeros negros en el tráfico.

UDLD puede detectar todos estos casos y errdisable ambos los puertos en el enlace, si UDLD se configura a ambos finales. De esta manera, UDLD impide los bucles STP y los agujeros negros en el tráfico.

Negociación automática de Ethernet Gigabit

Propósito

Gigabit Ethernet (GE) cuenta con un procedimiento de negociación automática que es más extensivo que el procedimiento utilizado para 10/100-Mbps Ethernet (IEEE 802.3z). Con los puertos GE, la negociación automática se utiliza para intercambiar:

  • Parámetros de control de flujo

  • Información de fallo remoto

  • Información de dúplex

    Nota: Los puertos de la serie Catalyst GE solo soporta el modo dúplex completo.

IEEE 802.3z ha sido eliminado por IEEE 802.3:2000 specs. Consulte Redes de área local y metropolitana + Suscripción de estándares preliminares (LAN/MAN 802s)leavingcisco.com para obtener más información.

Información operativa general

A diferencia de la negociación automática con 10/100-Mbps FE, la negociación automática GE no involucra la negociación de la velocidad del puerto. Tampoco puede ejecutar el comando set port speed para deshabilitar la negociación automática. La negociación de puerto GE se encuentra activada de manera predeterminada y los puertos en en ambos finales del enlace GE deben tener la misma configuración. El enlace no aparece si los puertos a cada final del enlace están establecidos de manera inconsistente, lo que significa que los parámetros intercambiados son diferentes.

Por ejemplo, suponga que existen dos dispositivos, A y B. Cada dispositivo puede tener una negociación automática activada o desactivada. Esta es una tabla que posee configuraciones posibles y sus respectivos estados de enlace:

Negociación

B habilitado

B inhabilitado

A habilitado

en funcionamiento en ambos lados

A fuera de servicio, B en funcionamiento

A inhabilitado

A en funcionamiento, B fuera de servicio

en funcionamiento en ambos lados

En GE, la sincronización y la negociación automática (si están activadas) se llevan a cabo en el inicio del enlace a través del uso de una secuencia especial de palabras claves de enlace reservadas.

Nota: Existe un diccionario de palabras válidas y no todas las palabras posibles son válidas en GE.

La vida de una conexión GE puede caracterizarse de esta manera:

185-n.gif

Una pérdida de sincronización significa que MAC detecta un enlace inactivo. La pérdida de sincronización se aplica donde la negociación automática se encuentra activada o desactivada. La sincronización se pierde en ciertas condiciones fallidas, como el recibo de tres palabras inválidas consecutivas. Si esta condición persiste por 10 ms, una condición fallida de sincronización se verificada y el enlace se modifica a estado de enlace inactivo. Después que se pierde la sincronización, se necesitan tres palabras válidas consecutivas para volver a sincronizar. Otros hechos catastróficos, como la pérdida de la señal de recepción (Rx), provocará un hecho de enlace inactivo.

La negociación automática es una parte del proceso de enlace ascendente. Cuando el enlace está activo, la negociación automática se termina. Sin embargo, el switch aun supervisa el estado del enlace. Si la negociación automática está desactivada en un puerto, la fase de negociación automática no es más una opción.

La especificación GE de cobre (1000BASE-T) soporta la negociación automática a través del Next Page Exchange (Intercambio de la próxima página). Next Page Exchange permite la negociación automática para 10/100/1000-Mbps de velocidad en puertos de cobre.

Nota: Sin embargo, la especificación de fibra GE sólo realiza prestaciones para la negociación de dúplex, control de flujo y la detección de fallos remoto. Los puertos de fibra GE no negocian la velocidad del puerto. Consulte las secciones 28 y 37 de las especificaciones IEEE 802.3-2002 leavingcisco.com si desea obtener más información acerca de la negociación automática.

La demora en el inicio de la sincronización es una función del software que controla el tiempo de negociación automática total. Si la negociación automática no tiene éxito dentro de este tiempo, el firmware reinicia la negociación automática en caso de que haya un bloqueo. El comando sync-restart-delay sólo tiene efecto cuando la negociación automática se encuentra habilitada.

Recomendación del puerto de infraestructura de Cisco

La configuración de la negociación automática es mucho más crítica en un entorno GE que en un entorno 10/100 Mbps. Sólo negociación automática inhabilitada en estas situaciones:

  • En los puertos de los switches que se vinculan con dispositivos que no pueden soportar negociaciones.

  • En donde aparecen problemas de conectividad por problemas de interoperabilidad.

Negociaciones Gigabit habilitadas en todos los enlaces de switch a switch y generalmente, en todos los dispositivos GE. El valor predeterminado en la interfaz Gigabit es negociación automática. Sin embargo, ejecute este comando para asegurar que la negociación automática está habilitada.

switch(config)#interface type slot/port
switch(config-If)#no speed 
!--- Este comando establece el puerto para negociar automáticamente los parámetros Gigabit. 

Una excepción conocida es cuando se conecta al Router de switch Gigabit (GSR) que ejecuta el software Cisco IOS que es anterior a software Cisco IOS versión 12.0(10)S, la versión que agregó el control de flujo y la negociación automática. En este caso, apague esas dos funciones. Si no apaga esas funciones, el puerto del switch informa que no está conectado y el GSR informa los errores. Éste es una secuencia de comando de interfaz de muestra:

flowcontrol receive off
flowcontrol send off
speed nonegotiate

Recomendación del puerto de acceso de Cisco

Debido a que FLP puede variar entre proveedores, se deben observar las conexiones de switch a servidor en una base caso por caso. Los clientes de Cisco han encontrado algunos problemas en la negociación de Gigabit respecto de los servidores Sun, HP e IBM. Todos los dispositivos deben utilizar la negociación automática excepto que el proveedor de NIC especifique lo contrario.

Otras opciones

El control de flujo es una parte opcional de la especificación 802.3x. El control de flujo debe negociarse si lo utiliza. Los dispositivos pueden o no enviar y/o responder a una tarma de PAUSA (MAC 01-80-C2-00-00-000F reconocida). Y los dispositivos posiblemente pueden no aceptar el pedido de control de flujo del vecino en el final lejano. Un puerto con un búfer de entrada que comienza a llenarse envía una trama de PAUSA para el socio de enlace. El socio de enlace detiene la transmisión y sostiene cualquier trama adicional en los búferes de salida de los socios de enlace. Esta función no resuelve ningún problema de sobresuscripción de estado constante. Sin embargo, la función efectivamente hace más grande el búfer de entrada por alguna porción del búfer de salida asociado a través de ráfagas.

La función PAUSA se diseña para impedir el descarte innecesario de las tramas recibidas por los dispositivos (switches, routers o estaciones finales) debido a que las condiciones de desbordamiento del búfer que provoca el desbordamiento del tráfico transitorio a corto plazo. Un dispositivo bajo un desbordamiento de tráfico impide el desbordamiento del búfer cuando el dispositivo envía una trama de PAUSA. La trama de PAUSA contiene parámetros que indican que la longitud del tiempo para que el socio dúplex completo espere antes de que el socio envíe más marco de datos. Este socio que recibe la trama de PAUSA deja de enviar información durante el período especificado. Cuando caduca este temporizador, la estación comienza a enviar marcos de datos nuevamente, desde donde la estación haya dejado.

Una estación que emite una PAUSA puede emitir otra trama de PAUSA que contiene un parámetro de tiempo cero. Esta acción cancela el resto del período de pausa. Entonces, una trama de PAUSA recientemente recibida anula cualquier operación de PAUSA que esté actualmente en progreso. Además, la estación que emite la trama de PAUSA puede extender el período de PAUSA. La estación que emite la trama de PAUSA contiene un parámetro no cero antes de la caducidad del primer período de PAUSA.

Esta operación de PAUSA no es un control de flujo en base a la velocidad. La operación es un mecanismo simple de inicio-detención que permite al dispositivo en tráfico, el que envió la trama de PAUSA, la posibilidad de reducir el congestionamiento del búfer.

El mejor uso de esta función se encuentra en los enlaces entre los puertos de acceso y los hosts finales, donde el búfer de salida host es potencialmente tan grande como la memoria virtual. El uso de switch a switch tiene ventajas limitadas.

Emita estos comandos de interfaz para controlar esto en los puertos del switch:

flowcontrol {receive | send} {off | on | desired}


>show port flowcontrol

 Port  Send FlowControl    Receive FlowControl   RxPause TxPause
       admin    oper       admin    oper
-----  -------- --------   -------- --------     ------- -------
 6/1   off      off        on       on           0       0
 6/2   off      off        on       on           0       0
 6/3   off      off        on       on           0       0

Nota: Todos los módulos Catalyst responden a una trama de PAUSA si se negocia. Algunos módulos (por ejemplo, WS-X5410 y WS-X4306) nunca envían tramas de pausa, aun cuando negocian para hacerlo, ya que no son bloqueadores.

Protocolo de conexión troncal dinámica

Propósito

Para ampliar las VLAN entre los dispositivos, las troncales identifican temporalmente y marcan (local del enlace) las tramas Ethernet originales. Esta acción habilita a las tramas a que sean multiplexadas en un único enlace. La acción también garantiza que las la transmisión VLAN separada y los dominios de seguridad se mantengan entre los switches. Las tablas CAM mantienen la trama del mapeo de VLAN dentro de los switches.

Información operativa general

DTP es la segunda generación del ISL dinámico (DISL). DISL sólo soporta ISL. DTP soporta tanto ISL como 802.1Q. Esta admisión asegura que los switches en cada finale de una troncal coincidan en diferentes parámetros de tramas de conexión troncal. Estos parámetros incluyen:

  • El tipo de encapsulación configurada

  • VLAN nativa

  • Capacidad del hardware

El soporte de DTP además ayuda a proteger contra la inundación de tramas con etiquetas por puertos no troncales, que es un grave riesgo potencial de seguridad. DTP protege dichas inundaciones ya que asegura que los puertos y sus vecinos se encuentran en estados coherentes.

Modo de conexión troncal

DTP se encuentra en el protocolo de Capa 2 que negocia los parámetros de configuración entre un puerto de switch y su vecino. DTP utiliza otra dirección MAC multidifusión conocida de 01-00-0c-cc-cc-cc y un tipo de protocolo SNAP de 0x2004. Esta tabla describe la función en cada uno de los modos de negociación DTP posible:

Modo

Función

¿Tramas DTP transmitidas?

Etapa final (Puerto local)

Auto dinámico (equivalente al modo Auto en CatOS)

Hace que el puerto sea capaz de convertir el enlace en una troncal. El puerto se convierte en un puerto troncal si el puerto vecino está configurado en modo encendido o deseable .

Sí, periódicamente

Conexión troncal

Troncal (equivalente al modo ENCENDIDO en CatOS)

Coloque el puerto en modo de conexión troncal permanente y negocie para convertir el enlace en una troncal. El puerto se convierte en un puerto troncal aun si el puerto vecino no acepta la modificación.

Sí, periódicamente

Conexión troncal, sin condiciones

No negociación

Coloca al puerto en modo de conexión troncal pero no permite al puerto generar tramas DTP. Debe configurar manualmente el puerto de vecindad como un puerto troncal para establecer un enlace troncal. Esto es útil para dispositivos que no soportan DTP.

No

Conexión troncal, sin condiciones

Deseable dinámico (CatOS el comando comparable se encuentra deseable)

Hace que el puerto intente convertir el enlace en un enlace troncal. El puerto se convierten en un puerto troncal si el puerto está configurado en encendido, deseable, o Auto modo

Sí, periódicamente

Termina en estado de conexión troncal estado sólo si el modo remoto se encuentra encendido, Auto, o deseable.

Acceso

Coloque el puerto en modo de conexión no troncal permanente y negocie para convertir el enlace en un enlace no troncal. El puerto se convierte en un puerto no troncal aun si el puerto vecino no acepta la modificación.

No, en estado constante, pero transmite información para acelerar la detección de finale remoto después de una modificación desde encendido.

Conexión no troncal

Nota: EL tipo de encapsulación ISL y 802.1Q puede establecerse o negociarse.

En la configuración predeterminada, el DTP asume estas características en el enlace:

  • Las conexiones punto a punto y los dispositivos de Cisco soportan puertos troncales 802.1Q que sólo son punto a punto.

  • Durante la negociación DTP, los puertos no participan en STP. El puerto se agrega al STP únicamente después que el tipo de puerto se vuelve uno de estos tres tipos:

    • Acceso

    • ISL

    • 802.1Q

    PAgP es el próximo proceso a ejecutarse antes que el puerto participe en STP. PAgP se utiliza para la negociación automática de EtherChannel.

  • VLAN 1 siempre está presente en el puerto troncal. Si el puerto está conectado mediante conexión troncal el modo ISL, los paquetes DTP se envía a la VLAN 1. Si el puerto no está conectado mediante conexión troncal en el modo ISL, los paquetes DTP son enviados a la VLAN nativa (para puertos troncales o no troncales 802.1Q).

  • Los paquetes DTP transfieren el nombre de dominio VTP, más la configuración troncal y el estado del administrador. El nombre de dominio VTP debe coincidir para que aparezca un enlace troncal negociado. Estos paquetes se envían cada segundo a través de la negociación y cada 30 segundos después de la negociación. Si un puerto en modo Auto o deseable no detecta un paquete DTP dentro de 5 minutos (min), el puerto se establece como no troncal.

precauciónPrecaución: Debe entender que los modos troncal, no negociación y acceso especifican explícitamente en qué estado termina el puerto. Una configuración incorrecta puede generar un estado peligroso/incoherente en el que un lado se encuentra en conexión troncal y el otro no.

Consulte Configuración de la conexión troncal ISL (Lenguaje de sistema interactivo) en switches de las familias 5500/5000 y 6500/6000 de Catalyst para más detalles acerca de ISL. Consulte Conexión troncal entre los Switches de las series Catalyst 4500/4000, 5500/5000 y 6500/6000 que utilizan la encapsulación 802.1Q con Cisco CatOS System Software para más información acerca de 802.1Q.

Tipo de encapsulación

Información general sobre el funcionamiento de ISL

ISL es un protocolo de conexión troncal propiedad de Cisco (esquema de etiquetado VLAN). ISL se ha utilizado durante muchos años. Por el contrario, 802.1Q es más nuevo pero 802.1Q es la norma IEEE.

ISL encapsula completamente, la trama original en un esquema de etiquetas de dos niveles. De esta manera, ISL es de forma eficaz un protocolo de tunelización y, como un beneficio adicional, transporta tramas no Ethernet. ISL agrega un encabezado de 26 bytes y un FCS de 4 bytes a la trama Ethernet estándar. Los puertos que se configuran para ser troncales esperan y manejan las tramas Ethernet más grandes. ISL soporta 1024 VLAN.

Formato de trama – La etiqueta ISL está sombreada

185-a.gif

185-b.gif

Consulte Formato de trama del enlace entre switches y de IEEE 802.1Q para más información.

Información general sobre el funcionamiento de 802.1Q

A pesar de que la norma IEEE 802.1Q sólo pertenece a Ethernet, la norma especifica mucho más que los tipos de encapsulación. 802.1Q incluye, entre otros Protocolos de registro de atributo genérico (GARP), las mejoras del árbol de expansión y el etiquetado 802.1p QoS. Consulte Normas IEEE en línea leavingcisco.com para obtener más información.

El formato de trama 802.1Q preserva la Ethernet SA y DA originales. Sin embargo, los switches deben esperar recibir ahora tramas baby-giant, aun en puertos de acceso en donde los hosts pueden utilizar el etiquetado para expresar la prioridad del usuario 802.1p para la señalización QoS. La etiqueta es de 4 bytes. Las tramas 802.1Q Ethernet v2 son de 1522 bytes, lo cual representa un logro del grupo de trabajo de IEEE 802.3ac. Además, 802.1Q soporta espacio de numeración para 4096 VLAN.

Todas esos marcos de datos que se transmiten y reciben son 802.1Q etiquetadas, excepto para aquellos marcos de datos que se encuentran en la VLAN nativa. En este caso, existe una etiqueta implícita basada en la configuración de ingreso del puerto del switch. Las tramas en la VLAN nativa siempre se transmiten sin etiqueta y se reciben normalmente sin etiqueta. Sin embargo, estas tramas también pueden recibirse con etiquetas.

Si desea más información, consulte estos documentos:

Formato de trama 802.1Q/802.1p

185-c.gif

Recomendación sobre la configuración de Cisco

Un principio de diseño primario de Cisco sirve para la consistencia en la red donde la consistencia es posible. Todos los productos más nuevos de Catalyst soportan 802.1Q y algunos sólo soportan 802.1Q, como los módulos anteriores en las series Catalyst 5500/5000 y 6500/6000. Por lo tanto, todas las nuevas implementaciones deben seguir esta norma IEEE 802.1Q y las redes más antiguas deben migrar gradualmente desde ISL.

Ejecute estos comandos de interfaz para habilitar la conexión troncal 802.1Q en un puerto en particular:

Switch(config)#interface type slot#/port#
Switch(config-if)#switchport
!--- Configure la interfaz como un puerto de Capa 2.
Switch(config-if)#switchport trunk encapsulation dot1q

La norma IEEE permite la interoperabilidad entre vendedores. La interoperabilidad entre vendedores es ventajosa en todos los entornos Cisco a medida que nuevos dispositivos y NIC hosts con capacidad 802.1p comienzan a estar disponibles. A pesar de que las implementaciones ISL y 802.1Q son sólidas, la norma IEEE finalmente posee más implementación práctica y mayor soporte por parte de terceros, que incluye soporte para los analizadores de red. Además, una consideración menor es que la norma 802.1Q posee además una tara de encapsulación más baja que ISL.

Para mayor integridad, el etiquetado implícito en la VLAN nativa crea una consideración de seguridad. La transmisión de las tramas desde una VLAN, VLAN X, a otra VLAN, VLAN Y, es posible sin un router. La transmisión puede ocurrir sin un router si el puerto de origen (VLAN X) se encuentra en la misma VLAN que la VLAN nativa de una troncal 802.1Q trunk en el mismo switch. La solución alternativa es utilizar una VLAN ficticia para la VLAN nativa de la troncal.

Ejecute estos comandos de interfaz para establecer una VLAN como nativa (la predeterminada) para la conexión troncal 802.1Q en un puerto en particular:

Switch(config)#interface type slot#/port#
Switch(config-If)#switchport trunk native vlan 999

Debido a que todo el hardware más reciente soporta 802.1Q, haga que todas las nuevas implementaciones sigan la norma IEEE 802.1Q y gradualmente migre las redes anteriores desde ISL. Hasta hace poco, muchos módulos Catalyst 4500/4000 no soportaban ISL. Por lo tanto, 802.1Q es la única opción para la conexión troncal Ethernet. Consulte el resultado del comando show interface capabilities o del comando show port capabilities para CatOS. Debido a que el soporte de conexión troncal requiere el hardware apropiado, un módulo que no soporta 802.1Q jamás podrá soportar 802.1Q. Una actualización del software no confiere soporte para 802.1Q. La mayoría de los nuevos hardware para los switches Catalyst 6500/6000 y Catalyst 4500/4000 soportan ISL y 802.1Q.

Si la VLAN 1 se ha eliminado de una conexión troncal como trata la sección Interfaz de administración y VLAN nativa, a pesar que los datos del usuario se transmiten y reciben, NMP continua pasando protocolos de control en VLAN 1. Los ejemplo de los protocolos de control incluyen CDP y VTP.

También, como trata la sección VLAN 1, los paquetes CDP, VTP, y PAgP siempre son enviados por VLAN 1 en las conexiones troncales. Con el uso de la encapsulación dot1q (802.1Q), estas tramas de control son etiquetadas con VLAN 1 si se modifica la VLAN nativa del switch. Si la conexión troncal dot1q a un router y la VLAN nativa se modifica en el switch, será necesaria una subinterfaz en VLAN 1 para recibir las tramas CDP etiquetadas y proporcionar la visibilidad vecina CDP en el router.

Nota: Existe una observación de seguridad potencial con dot1q causada por el etiquetado implícito de la VLAN nativa. Es posible la transmisión de las tramas desde una VLAN a otra sin un router. Consulte las Preguntas más frecuentes sobre Detección de Intrusiónleavingcisco.com para obtener más información. La solución alternativa es utilizar una VLAN ID para la VLAN nativa de la conexión troncal que no se usa para el acceso del usuario final. Para alcanzar esto, la mayoría de los clientes de Cisco simplemente dejan la VLAN1 como la VLAN nativa en la conexión troncal y asignan puertos de acceso a las VLAN que no sea la VLAN 1.

Cisco recomienda una configuración de modo de conexión troncal explícita de deseable dinámico en ambos finales. Este modo es el modo predeterminado. En este modo, los operadores de red pueden confiar en los mensajes de estado syslog y la línea de comandos que un puerto está en funcionamiento y en conexión troncal. Este modo es diferente del modo encendido, que puede hacer que un puerto aparezca en funcionamiento aun cuando el vecino esté mal configurado. Además, las troncales en modo deseable proporciona estabilidad en situaciones en que un lado del enlace no puede volverse una conexión troncal o pierde el estado de troncal.

Si el tipo de encapsulación se negocia entre los switches con el uso de DTP y ISL es elegido como el ganador predeterminado si ambos finales lo soportan, debe ejecutar el comando de interfaz para especificar dot1q 1:

switchport trunk encapsulation dot1q

1 Ciertos módulos que incluyen WS-X6548-GE-TX y WS-X6148-GE-TX no soportan la conexión troncal ISL. Estos módulos no aceptan el comando switchport trunk encapsulation dot1q.

Nota: Ejecute el comando switchport mode access para desactivar las conexiones troncales en un puerto. Esta inhabilitación ayuda a eliminar el tiempo de negociación perdido cuando los puertos de host se activen.

Switch(config-if)#switchport host

Otras opciones

Otra configuración común del cliente utiliza el modo deseable dinámico en la capa de distribución y la configuración predeterminada más simple (modo auto dinámico) en la capa de acceso. Algunos switches, como Catalyst 2900XL, routers Cisco IOS u otros dispositivos de proveedores, no soportan generalmente la negociación troncal a través de DTP. Se puede utilizar el modo no negociación para establecer un puerto para la conexión troncal absolutamente con estos dispositivos. Este modo puede ayudar a estandarizar en una configuración común a todos los campus.

Cisco recomienda no negociación cuando se conecte a un router Cisco IOS. A través de un bridge, algunas tramas DTP recibidas desde un puerto configurado con switchport mode trunk pueden volver al bridge troncal. Una vez recibida la trama DTP el puerto del switch trata de renegociar sin necesidad. Para renegociar, el puerto del switch desactiva la conexión troncal. y luego en funcionamiento. Si no negociación está activada, el switch no envía tramas DTP.

switch(config)#interface type slot#/port#
switch(config-if)#switchport mode dynamic desirable
!--- Configure la interfaz como una conexión troncal en el modo
!--- deseable para el enlace de switch a switch con VLAN múltiples.
!--- Y... 
switch(config-if)#switchport mode trunk
!--- Fuerce la interfaz en modo troncal sin negociación de la conexión troncal.
!--- O... 
switch(config-if)#switchport nonegotiate
!--- Configure el modo de conexión troncal para no enviar paquetes de negociación DTP
!--- para conexiones troncales a routers.
switch(config-if)#switchport access vlan vlan_number
!--- Configure la VLAN de seguridad para la interfaz.
switch(config-if)#switchport trunk native vlan 999
!--- Configure la VLAN nativa.
switch(config-if)#switchport trunk allowed vlan vlan_number_or_range
!--- Configure las VLAN que tienen acceso en la troncal.

Spanning Tree Protocol

Propósito

El árbol de expansión mantiene un entorno de Capa 2 libre de bucle en el switch redundante y las redes de bridge. Sin STP, las tramas se multiplican de manera indefinida. Esta ocurrencia provoca que SE funda la red debido a que el gran tráfico interrumpe todos los dispositivos en el dominio de difusión.

En algunos aspectos, STP es un protocolo antiguo que fue inicialmente desarrollado para especificaciones de bridge basadas en un software lento (IEEE 802.1D). Sin embargo, el STP puede ser complicado para implementarlo con éxito en grandes redes de switches que poseen:

  • Muchas VLAN

  • Muchos switches en un dominio

  • Soporte de proveedores múltiples

  • Nuevas mejoras de IEEE

El software de sistema Cisco IOS ha empleado nuevos desarrollos de STP. Nuevas normas IEEE que incluyen 802.1w Rapid STP y los protocolos de árbol de expansión múltiple 802.1s proporcionan rápida convergencia, distribución de carga y escalada de plano de control. Además, las funciones de mejoras de STP como RootGuard, filtrado de BPDU, protección Portfast BPDU y protección de bucle tiene como objetivo proporcionar protección adicional contra los bucles de reenvío de Capa 2.

Información general sobre el funcionamiento de PVST+

La elección del bridge raíz por VLAN es ganado por el switch con el Identificador de bridge raíz. más bajo (BID). El BID es la prioridad del bridge combinada con la dirección MAC del switch.

Inicialmente, las BPDU se envían desde todos los switches y contienen el BID de cada switch y el costo del trayecto para alcanzar ese switch. Esto habilita la determinación el bridge de raíz y el trayecto de costo más bajo a la raíz. Los parámetros adicionales de configuración que son transportados en BPDU desde la raíz sobrescriben aquellos parámetros que están localmente configurados de manera que toda la red utilice temporizadores consistentes. Para cada BPDU que recibe un switch desde la raíz , el NMP central de Catalyst procesa una nueva BPDU y la envía con la información raíz.

Luego, la topología converge a través de estos pasos:

  1. Se elige un único bridge de raíz para todo el dominio del dominio del Árbol de expansión.

  2. Se elige un puerto raíz (frente a un bridge raíz) en todos bridges sin raíz.

  3. Se elige un puerto designado para el reenvío de BPDU en cada segmento.

  4. Los puertos no designados se vuelven bloqueadores.

Si desea más información, consulte estos documentos:

Opciones básicas predeterminadas del temporizador (segundos)

Nombre

Función

2 seg.

hello

Controla la salida de las BPDU.

15 seg.

forward delay (Fwddelay)

Controla la longitud del tiempo que emplea un puerto en el estado de escucha y aprendizaje e influencia el proceso de modificación de la topología.

20 seg.

maxage

Controla la longitud del tiempo que el switch mantiene la la topología actual antes de que el switch busque un trayecto alternativo. Después del tiempo máximo (maxage) de desactualización, una BPDU es considerada desactualizada y el switch busca un nuevo puerto raíz desde el conjunto de puertos de bloqueo. Si ningún puerto bloqueado se encuentra disponible, el switch solicitará ser la raíz en los puertos designados.

Cisco recomienda no modificar los temporizadores ya que esto puede afectar adversamente la estabilidad. La mayoría de las redes implementadas no está ajustada. El temporizador STP simple al que se puede acceder a través de la línea de comando (como el intervalo de saludo, maxage, y demás) son parte de un complejo grupo de otros temporizadores asumidos e intrínsecos. Por lo tanto, es difícil ajustar los temporizadores y considerar todas las ramificaciones. Además, puede socavar la protección UDLD. Consulte la sección Condición de detección de enlace unidireccional (UniDirectional Link Detection o UDLD) para obtener más detalles.

Nota sobre los temporizadores STP:

Los valores de los temporizadores STP predeterminados se basan en un cálculo que considera un diámetro de red de siete switches (siete saltos de switches desde la raíz al final de la red) y el tiempo que sea necesario para que una BPDU viaje desde el bridge raíz a los switches de borde en la red, que están a siete saltos de distancia. Esta suposición computa los valores del temporizador que son aceptables para la mayoría de las redes. Sin embargo, se puede modificar estos temporizadores a valores más óptimos para acelerar los tiempos de convergencia a través de las modificaciones de la topología de la red.

Puede configurar el bridge raíz con el diámetro de la red para una VLAN específica y los valores del temporizador se computan respectivamente. Cisco recomienda que, si deben hacer modificaciones, sólo se configuren los parámetros del diámetro y el tiempo de saludo opcional en el bridge raíz para la VLAN.

spanning-tree vlan vlan-id [root {primary | secondary}]
[diameter diameter-value [hello hello-time]]
!--- Este comando debe estar en una línea.

Este macro realiza la raíz del switch para la VLAN especificada, computa los nuevos valores del temporizador sobre la base del diámetro y el tiempo de saludo especificado y propaga esta información en la configuración de BPDU para todos los demás switches en la topología.

La sección Estados y funciones de puerto nuevos describe STP 802.1D y compara y contrasta STP 802.1D con STP rápido (RSTP). Consulte Introducción Protocolos del árbol de expansión rápidos (802.1w) para obtener más información sobre RSTP.

Estados y funciones de puerto nuevos

802.1D se define en cuatro diferentes estados de puertos:

  • Escucha

  • Aprendizaje

  • Bloqueo

  • Reenvío

Consulte la tabla en la sección de Estados de puertos para más información. El estado del puerto está mezclado (ya sea que bloquee o envíe tráfico), ya que es la función que cumple el puerto en la topología activa (puerto raíz, puerto designado, y demás). Por ejemplo, desde un punto de vista operativo, no existe diferencia entre un puerto en estado de bloqueo y un puerto en estado de escucha. Ambos descartan tramas y no aprenden direcciones MAC. La diferencial real yace en la función que el árbol de expansión asigna al puerto. Se puede suponer que un puerto de escucha es un puerto designado o raíz y se encuentra en camino a estado de reenvío. Desafortunadamente, una vez que el puerto se encuentra en estado de reenvío, no hay manera de inferir por el estado del puerto si el puerto es raíz o designado. Esto demuestra el fallo de esta terminología basada en el estado. RSTP dirige este fallo debido a que RSTP desacopla la función y el estado de un puerto.

Estados de puertos

Estado de puerto en STP 802.1D

Estados de puertos

Significa

Sincronización predeterminada al siguiente estado

desactivado

Bajo desempeño administrativo.

 

Bloqueo

Recepción de BPDU y cese de información del usuario.

Monitorea la recepción de BPDU. Espera de 20 segundos para la caducidad de maxage o cambio inmediato si se detecta el fallo de enlace directo/local.

Escucha

Envía o recibe BPDU para controlar si se necesita volver al bloqueo.

Espere 15 segundos Fwddelay.

Aprendizaje

Crea la tabla de topología/CAM.

Espere 15 segundos Fwddelay.

Reenvío

Envía/recibe datos.

 

El cambio de la topología básica total es:

  • 20 + 2 (15) = 50 seg, si está esperando la caducidad de maxage)

  • 30 segundos para fallo de enlace directo

Sólo existen tres estados de puertos restantes en RSTP, que corresponden a los tres estados operativos posibles. Los estados 802.1D desactivado (disabled), bloqueo (blocking) y escucha (listening) se han combinado en un único estado de descarte (discarding) de 802.1w.

Estado de puerto STP (802.1D)

Estado de puerto RSTP (802.1w)

¿El puerto está incluido en la topología activa?

¿El puerto está aprendiendo las direcciones MAC?

Desactivado

Descarte

No

No

Bloqueo

Descarte

No

No

Escucha

Descarte

No

Aprendizaje

Aprendizaje

Reenvío

Reenvío

Roles de puerto

Ahora la función es una variable asignada a un puerto dado. El puerto raíz y las funciones del puerto designado permanecen, mientras que la función del puerto de bloqueo se divide en funciones de puerto de respaldo y alternativo. El algoritmo de árbol de expansión (STA) determina la función de un puerto sobre la base de BPDU. Recuerde esto acerca de las BPDU para simplificar las cosas: siempre hay una manera de comparar cualquiera de las dos BPDU y decidir si una es más útil que la otra. La base de la decisión es el valor almacenado en la BPDU y, en ocasiones, el puerto en el que la BPDU se recibe. El recordatorio de esta sección explica de manera muy práctica los métodos para las funciones del puerto.

Función de puerto raíz

El puerto que recibe la mejor BPDU en un bridge es el puerto raíz. Éste es el puerto más cercano al bridge raíz en términos de costo de trayecto. El STA selecciona un solo bridge raíz de toda la red conectada por bridges (por VLAN). El bridge de la raíz envía BPDU que son más útiles que las que envían cualquier otro bridge. El bridge de la raíz es el único bridge en la red que no tiene un puerto raíz. Todos los demás bridges reciben BPDU en al menos un puerto.

185-o.gif

Función del puerto designado

Un puerto es designado si puede enviar la mejor BPDU en el segmento al puerto que está conectado. Los bridges 802.1D unen diferentes segmentos (segmentos Ethernet, por ejemplo) para crear un dominio con bridge. En un segmento dado, puede haber sólo un trayecto hacia el bridge de la raíz. Si hay dos trayectos, habrá un bucle de conexión en bridge en la red. Todos los bridges que están conectados a un segmento dado escuchan las BPDU de los otros y coinciden con respecto al bridge que envía la mejor BPDU como el bridge designado para el segmento. El puerto correspondiente en ese bridge está designado.

185-p.gif

Funciones de puerto de respaldo y alternativo

Estas dos funciones de puerto corresponden al estado de bloqueo de 802.1D. Un puerto bloqueado es, por definición, un puerto que no es el designado ni el puerto raíz. Un puerto bloqueado recibe una BPDU más útil que la que envía en su segmento. Recuerde que un puerto requiere necesariamente recibir las BPDU para permanecer bloqueado. RSTP introduce estas dos funciones con este fin.

Un puerto alternativo en un puerto que está bloqueado por recibir más BPDU útiles desde otro bridge. Este diagrama muestra:

185-q.gif

Un puerto de respaldo es un puerto que está bloqueado por recibir más BPDU útiles desde el mismo bridge en el que se encuentra el puerto. Este diagrama muestra:

185-r.gif

Esta diferenciación ya se realizó internamente en 802.1D. Este hecho muestra esencialmente la manera en que funciona Cisco UplinkFast. La razón detrás de esto es que un puerto alternativo proporciona un trayecto alternativo al bridge raíz. Por consiguiente, este puerto puede reemplazar el puerto raíz si falla. Por supuesto, un puerto de respaldo proporciona conectividad al mismo segmento y no puede garantizar una conectividad alternativa al bridge raíz. Por lo tanto, el puerto de respaldo se excluye del grupo del enlace ascendente.

Como resultado, RSTP calcula la topología final para el árbol de expansión con el uso del mismo criterio que 802.1D. No hay ningún cambio en la manera en que se utilizan las diferentes prioridades del bridge y el puerto. El nombre de bloqueo se utiliza para el estado de descarte en la implementación de Cisco. CatOS versión 7.1 y las últimas versiones muestran aun los estado de escucha y aprendizaje, que ofrecen más información acerca de un puerto que la que requiere la norma IEEE. Sin embargo, la nueva característica es que existe una diferencia entre la función que el protocolo ha determinado para un puerto y su estado actual. Por ejemplo, ahora es perfectamente válido para un puerto ser designado y bloquear al mismo tiempo. Mientras que esto ocurre generalmente por períodos de tiempo muy cortos, simplemente significa que este puerto es un estado de transición hacia el estado de reenvío designado.

Interacciones STP con VLAN

Existen tres maneras diferentes de correlacionar las VLAN con el Árbol de expansión:

  • Un único Common Spanning Tree para todas las VLAN o el Protocolo del árbol de expansión común (CST), como IEEE 802.1D

  • Un Árbol de expansión por VLAN o un Árbol de expansión compartido, como Cisco PVST

  • Un único Árbol de expansión por grupo de VLAN o múltiples árboles de expansión (MST) como IEEE 802.1s

Desde el punto de vista de la configuración, estos tres tipos de modos de árboles de expansión como se relacionan con la interacción con VLAN pueden configurarse en uno de los tres tipos de modos:

  • pvst . Por el árbol de expansión de VLAN Esto en realidad implementa PVST+, pero se advierte en el software Cisco IOS como simple PVST.

  • rapid-pvst. La evolución de la norma 802.1D mejora los tiempos de convergencia e incorpora las propiedades basadas en las normas (802.1w) para UplinkFast y BackboneFast.

  • mst. Esta es la norma 802.1s para un árbol de expansión por grupo de VLAN o MST. Esto también incorpora el componente rápido 802.1w dentro de la norma.

Un único Árbol de expansión para todas las VLAN permite sólo una topología activa y por lo tanto ningún balance de carga. Un puerto bloqueado STP para todas las VLAN y no transporta datos.

Un Árbol de expansión por VLAN o PVST+ permite el balance de carga pero requiere más procesamientos de BPDU en la CPU a medida que el número de VLAN aumenta.

La nueva norma 802.1s (MST) permite la definición de hasta 16 instancias/topologías STP activas y el mapeo de todas las VLAN para estas instancias. En un entorno típico de campus, sólo dos instancias necesitan ser definidas. Esta técnica permite que STP se adapte para miles de VLAN mientras habilita el balance de carga.

El soporte para PVST rápido y MST previo al estándar se presenta en el software Cisco IOS versión 11.2 (11b)EX y 12.1 (13)E para Catalyst 6500. Catalyst 4500 con el software Cisco IOS versión 12.1(12c)EW y las versiones posteriores soportan MST preestándar. El soporte PVST rápido se agrega al software Cisco IOS versión 12.1(19)EW para plataforma Catalyst 4500. EL MST que cumple con las normas está soportado en en el software Cisco IOS versión 12.2 (18)SXF para Catalyst 6500 y en el software Cisco IOS versión 12.2 (25)SG para los switches de la serie Catalyst 4500.

Consulte Introducción al Spanning Tree Protocol rápido (802.1w) e Introducción al Protocolo del árbol de expansión múltiple (802.1s) para obtener más información.

Puertos de árbol de expansión lógico

Las release notes Catalyst 4500 y 6500 proporcionan una guía sobre el número de puertos lógicos en el Árbol de expansión por switch. La suma de todos los puertos lógicos equivale al número de troncales en el switch por el número de VLAN activas en las troncales, más el número de las interfaces de conexión no troncal en el switch. El software Cisco IOS genera un mensaje de registro del sistema si el número máximo de las interfaces lógicas excede el límite. Se recomienda no exceder la guía recomendada.

Esta tabla compara el número de puertos lógicos soportado con varios modo STP y de tipo superior:

Supervisor

PVST+

RPVST+

MST

Catalyst 6500 Supervisor 1

6.0001 total

1.200 por modo de conmutación

6.000 en total

1.200 por modo de conmutación

25.000 en total

3.000 2 por módulo de conmutación

Catalyst 6500 Supervisor 2

13.0001 en total

1.800 2 por módulo de conmutación

10.000 en total

1.800 2 por módulo de conmutación

50.000 en total

6.000 2 por módulo de conmutación

Catalyst 6500 Supervisor 720

13.000 en total

1.800 2 por módulo de conmutación

10.000 en total

1.800 2 por módulo de conmutación

50.0003 en total

6.000 2 por módulo de conmutación

Catalyst 4500 Supervisor Engine 720

1.500 en total

1.500 en total

25.000 en total

Catalyst 4500 Supervisor Engine II plus-10GE

1.500 en total

1.500 en total

25.000 en total

Catalyst 4500 Supervisor IV

3.000 en total

3.000 en total

50.000 en total

Catalyst 4500 Supervisor V

3.000 en total

3.000 en total

50.000 en total

Catalyst 4500 Supervisor Engine V 10GE

3.000 en total

3.000 en total

80.000 en total

1 El número máximo de puertos lógicos totales que se soportan en PVST+ anteriores al software Cisco IOS versión 12.1(13)E es 4.500.

2 10 Mbps, 10/100 Mbps y 100 Mbps los módulos de los switches soportan un máximo de 1.200 interfaces lógicas por módulo.

3 El número máximo de puertos lógicos totales soportados en MST antes que el software Cisco IOS versión 12.2(17b)SXA es 30.000.

Recomendación

Es difícil proporcionar una recomendación de modo de árbol de expansión sin información detallada como el hardware, software, número de dispositivos y número de VLAN. En general, si el número de puertos lógicos no excede la guía recomendada, se recomendará el modo PVST rápido para la implementación de una nueva red. El modo PVST rápido proporciona convergencia de red rápida sin necesidad de configuración adicional como Backbone Fast y Uplink Fast. Ejecute el siguiente comando para configurar el árbol de expansión en modo PVST rápido:

spanning-tree mode rapid-pvst

Otras opciones

En una red dentro de una mezcla de hardware heredado y un software más antiguo, se recomienda el modo PVST+. Ejecute este comando para configurar el árbol de expansión en modo PVST+:

spanning-tree mode pvst
---- Esto está predeterminado y se muestra en la configuración.

Se recomienda el modo MST para VLAN en todas las redes diseñadas con grandes cantidades de VLAN. Para esta red, la suma de los puertos lógicos puede exceder la guía para PVST y PVST rápido. Ejecute este comando para configurar el árbol de expansión en modo MST:

spanning-tree mode mst

Formatos BPDU

Para soportar la norma IEEE 802.1Q, Cisco amplió el protocolo PVST que existe para proporcionar el protocolo PVST+. PVST+ agrega soporte para enlaces a través de la región de árbol de expansión simple IEEE 802.1Q. PVST+ es compatible tanto con el árbol de expansión simple IEEE 802.1Q como con los protocolos Cisco PVST existentes. Además, PVST+ agrega mecanismos de verificación para asegurar que no haya configuraciones inconsistentes de la conexión troncal de puerto y VLAN ID en los switches. PVST+ es plug-and-play compatible con PVST, sin la necesidad de un comando o configuración de interfaz de línea de comando (CLI).

Aquí hay algunos puntos para destacar de la teoría operativa del protocolo PVST+.

  • PVST+ interactúa con el árbol de expansión simple 802.1Q. PVST+ interactúa con los switches que cumplen con 802.1Q en STP común a través de la conexión troncal 802.1Q. El Common spanning tree común se encuentra de manera predeterminada en la VLAN 1, la VLAN nativa. Un common spanning tree común BPDU se transmite o recibe con la dirección MAC de grupo de bridges de la norma IEEE (01-80-c2-00-00-00, tipo de protocolo 0x010c) a través de enlaces 802.1Q. El Common spanning tree común puede arraigarse en PVST o en la región del árbol de expansión simple.

  • PVST+ envía las BPDU PVST por túnel a través de regiones 802.1Q VLAN como datos de multidifusión. Para cada VLAN en una conexión troncal, las BPDU con dirección MAC de Cisco Shared STP (01-00-0c-cc-cd) son transmitidas o recibidas. Para las VLAN que son equivalentes al Identificador de puerto VLAN (PVID), la BPDU no está etiquetada. Para todas las demás VLAN, las BPDU están etiquetadas.

  • PVST+ tiene compatibilidad descendente con el switch Cisco existente en PVST a través de la conexión troncal ISL. Las BPDU encapsuladas por ISL son transmitidas o recibidas. a través de las troncales ISL, que es lo mismo que con Cisco PVST anterior.

  • PVST+ verifica inconsistencias de VLAN y puertos. PVST+ bloquea aquellos puertos que reciben BPDU inconsistentes a fin de impedir la aparición de bucles de reenvío. PVST+ también notifica a los usuarios a través de mensajes syslog sobre cualquier inconsistencia.

Nota: En las redes ISL, todas las BPDU se envían mediante el uso de la dirección IEEE MAC.

Recomendaciones sobre la configuración de Cisco

Todos los switches Catalyst poseen STP habilitado de manera predeterminada. Aunque elija un diseño que no incluya bucles de Capa 2 y STP no está habilitado para mantener activamente un puerto bloqueado, deje la función habilitada por estos motivos.

  • Si hay un bucle, STP impide cuestiones que podrían empeorar mediante datos de difusión y multidifusión. A menudo, un mal arreglo, un cable malo u otra causa provoca un bucle.

  • STP protege contra un fallo de EtherChannel.

  • La mayoría de las redes se configuran con STP y por lo tanto obtienen exposición máxima de campo. La exposición máxima generalmente equivale a un código más estable.

  • STP protege contra el mal comportamiento de tarjetas de interfaz de red dobles conectadas (o activadas en conexión en bridge en servidores).

  • Muchos protocolos están íntimamente relacionados con STP en código. Algunos ejemplos incluyen:

    • PAgP

    • Indagación de Protocolo de mensajes de grupos de Internet (IGMP)

    • Conexión troncal

    Si lo ejecuta sin STP, puede obtener resultados no deseados.

  • Durante una interrupción del funcionamiento informada, los ingenieros de Cisco generalmente sugieren que el problema del fallo es la no utilización de STP, del todo posible.

Para habilitar el árbol de expansión en todas las VLAN, ejecute estos comando globales:

Switch(config)#spanning-tree vlan vlan_id
!--- Especifique la VLAN que desea modificar. 
Switch(config)#default spanning-tree vlan vlan_id
!--- Configure los parámetros del árbol de expansión.

No modifique los temporizadores, lo que puede causar un efecto adverso en la estabilidad. La mayoría de las redes implementadas no está ajustada. Los temporizadores STP simples a los que se puede acceder a través de la línea de comando, como el intervalo de saludo y maxage, poseen un complejo grupo de otros temporizadores asumidos e intrínsecos. Por lo tanto, puede tener dificultades si intenta ajustar los temporizadores y y considerar todas las ramificaciones. Además, puede socavar la protección UDLD.

Lo ideal es que mantenga el trafico de los usuarios fueran de la VLAN de administración. Este documento no se aplica en los switches Catalyst 6500/6000 del switch Cisco IOS. Además, debe respetar esta recomendación en los switches Cisco IOS de finales más pequeños y los switches CatOS que pueden tener una interfaz de administración aparte y necesitan estar integrados con los switches Cisco IOS. Especialmente con los procesadores de switches Catalyst más antiguos mantenga la VLAN de administración separada de la información del usuario para evitar problemas con STP. Una estación final con comportamiento equivocado puede potencialmente mantener tan ocupado al Supervisor Engine con paquetes de difusión que el procesador puede perder una o más BPDU. Sin embargo, los switches más nuevos con CPU más potentes y controles de regulación no tienen en cuenta esta consideración. Consulte la sección Interfaz de administración y VLAN nativa del switch, de este documento para más información.

No diseñe en exceso la redundancia. Esto puede llevar a demasiados puertos bloqueados y puede afectar adversamente la estabilidad a largo plazo. Mantenga el diámetro STP total por debajo de siete saltos. Trate de diseñar al modelo multicapa de Cisco siempre que este diseño sea posible. Las características del modelo:

  • Dominios conmutados más pequeños

  • triángulos STP

  • Puertos bloqueados predecibles

Consulte Gigabit Campus Network Design—Principles and Architecture (Diseño de redes Gibabit de oficinas centrales. Principios y arquitectura) para más detalles.

Reconozca y domine dónde reside la funcionalidad de la raíz y los puertos bloqueados. Documente esta información en el diagrama de la topología. Conozca la topología del árbol de expansión, que es esencial para la resolución de problemas. Estos puertos bloqueados se encuentran en donde comienza la resolución de problemas de STP. La causa de la modificación de bloqueo a reenvío es a menudo la parte clave del análisis de causa raíz. Elija la distribución y las capas del núcleo como la ubicación de la raíz/raíz secundaria debido a que estas capas son consideradas las partes más estables de la red. Verifique si es óptimo el desempeño de la Capa 3 y si Hot Standby Router Protocol (HSRP) se superpone con los trayectos de reenvío de datos de la Capa 2.

Este comando es un macro que configura la prioridad del bridge. La raíz establece la prioridad para ser más baja que la predeterminada (32.768), y la secundaria configura la prioridad para ser razonablemente más baja que la predeterminada:

Switch(config)#interface type slot/port
Switch(config)#spanning-tree vlan vlan_id root primary 
!--- Configure un switch como una raíz para una VLAN particular.

Nota: Este macro configura prioridad de la raíz para ser:

  • 8192 de forma predeterminada.

  • La prioridad raíz actual menos 1, si se conoce otro bridge de raíz.

  • La prioridad raíz actual, si la dirección MAC es menor que la raíz actual.

Separe las VLAN innecesarias de los puertos troncales, lo cual es un ejercicio bidireccional. La acción limita el diámetro de STP y NMP que procesan la tara en porciones de la red en donde no se necesitan determinadas VLAN. El recorte automático de VTP no elimina STP del enlace troncal. También se puede eliminar la VLAN 1 predeterminada de conexiones troncales.

Consulte Problemas del Spanning Tree Protocol y consideraciones de diseño relacionadas para más información.

Otras opciones

Cisco posee otro protocolo STP, denominando bridge VLAN, que funciona con el uso de la dirección MAC de destino conocida de 01-00-0c-cd-cd-ce y el tipo de protocolo de 0x010c.

Este protocolo es el más útil si existe la necesidad de hacer un bridge de protocolo no enrutable o heredado entre las VLAN sin interferencia con las instancias IEEE del árbol de expansión IEEE que se ejecutan en esas VLAN. Si las interfaces de VLAN para el tráfico sin bridge se bloquean por el tráfico de la Capa 2, el tráfico la Capa 3 que recubre se se separará inadvertidamente también, lo que representa un efecto colateral indeseado. Este bloqueo de Capa 2 puede tener lugar fácilmente si las interfaces de VLAN para el tráfico sin bridge participan en el mismo STP como las IP VLAN. El bridge VLAN es una instancia separada de STP para los protocolos en bridge. El protocolo proporciona una topología separada que puede ser manipulada sin efecto en el tráfico IP.

Ejecute el protocolo del bridge VLAN si se requiere una conexión en bridge entre las VLAN en los routers de Cisco tal como las MSFC.

Función STP PortFast

Se puede utilizar PortFast para evitar el funcionamiento normal del árbol de expansión en los puertos de acceso. PortFast acelera la conectividad entre estaciones finales y los servicios a los que las estaciones finales deben conectarse después de la inicialización del enlace. Esta implementación Microsoft DHCP necesita ver el puerto de acceso en modo de reenvío inmediatamente después que el estado del enlace se encuentre en funcionamiento para solicitar y recibir una dirección IP. Algunos protocolos, Packet Exchange (IPX - Intercambio de paquetes Internetwork)/Sequenced Packet Exchange (SPX – Intercambio de paquetes secuenciado), necesitan ver el puerto de acceso en el modo de reenvío inmediatamente después que el estado del enlace se encuentre en en funcionamiento para evitar problemas al Obtener el servidor más cercano (GNS).

Consulte Utilización de Portfast y otros comandos para solucionar retrasos al iniciar la conectividad de la estación para más información.

Información general sobre el funcionamiento de PortFast

PortFast omite los estados normales de escucha, aprendizaje y de reenvío de STP. La función mueve un puerto directamente del modo bloqueo a reenvío después de que el enlace se encuentra en funcionamiento. Si esta función no está habilitada, STP descarta toda la información del usuario hasta que el puerto esté listo para moverse al modo de reenvío. Este proceso puede tomar (2 x ForwardDelay) tiempo, que serán unos 30 segundos de manera predeterminada.

El modo PortFast impide la generación de de una Notificación de cambio de la topología STP (TCN) cada vez que un puerto cambia de aprendizaje a reenvío. las TCN son normales. Sin embargo, una onda de TCN que alcanza el bridge raíz puede extender el tiempo de convergencia de manera innecesaria. Una onda de TCN ocurre generalmente en la mañana, cuando la gente enciende su PC.

Recomendación sobre la configuración del puerto de acceso de Cisco

Configure STP PortFast en encendido para todos los puertos de host habilitados. Además, configure explícitamente STP PortFast en desactivado para los enlaces de switch a switch que no estén en uso.

Ejecute el comando macro switchport host en el modo de configuración de interfaz para implementar la configuración recomendada para los puertos de acceso. La configuración también ayuda a la negociación automática y al desempeño de la conexión significativamente:

switch(config)#interface type slot#/port#

switch(config-if)#switchport host
switchport mode will be set to access
spanning-tree portfast will be enabled
channel group will be disabled
!--- Este comando macro modifica estas funciones.

Nota: PortFast no significa que el árbol de expansión no se ejecute en todos los puertos. Aún se envían, se reciben y se procesan BDPU. El árbol de expansión es fundamental para una LAN completamente funcional. Con la detección y el bloqueo de bucles, un bucle puede hacer caer involuntariamente la LAN completa rápidamente.

Además, puede deshabilitar la conexión troncal y la canalización para todos los puertos host. Cada puerto de acceso se encuentra habilitado de manera predeterminada para conexión troncal y canalización, y sin embargo no se esperan switches vecinos por diseño en los puertos de host. Si deja que estos protocolos negocien, el retraso subsiguiente en la activación del puerto pueden conducir a situaciones indeseables. Los paquetes iniciales de las estaciones de trabajo, como los pedidos DHCP y IPX, no se reenvían.

Una mejor opción es configurar PortFast de manera predeterminada en el modo de configuración global con el uso de este comando:

Switch(config)#spanning-tree portfast enable

Después, en cualquier puerto de acceso que tenga un concentrador o switch sólo en una LAN, deshabilite la función PortFast en cada interfaz con el comando interface:

Switch(config)#interface type slot_num/port_num
Switch(config-if)#spanning-tree portfast disable

Otras opciones

La protección PortFast BPDU proporciona un método para impedir bucles. La protección BPDU. mueve un puerto sin conexión troncal al estado errDisable cuando recibe un BPDU en ese puerto.

En circunstancias normales, nunca reciba paquetes BPDU en un puerto de acceso que esté configurado para PortFast. Una BPDU entrante indica una configuración no válida. La mejor acción es cerrar el puerto de acceso.

El software de sistema Cisco IOS ofrece un comando global útil que habilita automáticamente BPDU-ROOT-GUARD en cualquier puerto habilitado para UplinkFast. Siempre utilice este comando. El comando funciona basado en cada switch y no en cada puerto.

Ejecute este comando global para habilitar BPDU-ROOT-GUARD:

Switch(config)#spanning-tree portfast bpduguard default

Un mensaje de trampa o syslog de Protocolo simple de administración de red (SNMP) notifica al administrador de la red si el puerto deja de funcionar. También puede configurar un tiempo de recuperación automática para los puertos errDisable. Consulte la sección Detección de enlace unidireccional (UniDirectional Link Detection) de este documento para más información.

Consulte Ampliación de la seguridad en el árbol de expansión Portfast BPDU para más detalles.

Nota: PortFast para los puertos troncales se introdujo en el software Cisco IOS versión 12.1(11b)E. PortFast para puertos troncales se diseñó para aumentar los tiempos de convergencia para las redes de Capa 3. Cuando utilice esta función, asegúrese de deshabilitar la protección BPDU y el filtro BPDU basado en la interfaz.

UplinkFast

Propósito

UplinkFast provee una rápida convergencia STP luego de un fallo de enlace directo en la capa de acceso de la red. UplinkFast funciona sin modificación del STP. El fin es acelerar el tiempo de convergencia en circunstancias específicas a menos de tres segundos, en lugar de los 30 segundos típicos de retraso. Consulte Comprensión y configuración de la función Uplink Fast de Cisco.

Información operativa general

Con el modelo de diseño multicapa de Cisco en la capa de acceso, el enlace de bloqueo se mueve inmediatamente al estado de reenvío si se pierde el enlace ascendente de reenvío. La función no espera los estados de escucha y aprendizaje .

Un grupo de enlace ascendente es un conjunto de puertos por VLAN que puede considerarse como un puerto raíz y un puerto raíz de respaldo. En circunstancias normales, el puerto raíz asegura la conectividad desde el acceso hacia la raíz. Si esta conexión de raíz primaria falla por cualquier motivo, en enlace raíz de respaldo se inicia inmediatamente, sin necesidad de pasar por los 30 segundos típicos de retardo de convergencia.

Ya que UplinkFast elude efectivamente el proceso de cambio y manejo de topología de STP normal (escucha y aprendizaje), un mecanismo de corrección de topología alternativa será necesario. El mecanismo necesita actualizar los switches en el dominio con la información que las estaciones final locales son alcanzables a través de un trayecto alterno. Así, el switch de capa de acceso que ejecuta UplinkFast también genera tramas para cada dirección MAC en su tabla CAM hacia una dirección MAC multidifusión conocida (01-00-0c-cd-cd-cd HDLC protocolo 0x200a). Este proceso actualiza la tabla CAM en todos los switches en el dominio con la nueva topología.

Recomendación de Cisco

Cisco recomienda habilitar UplinkFast para los switches de acceso con puertos bloqueados si ejecuta el árbol de expansión 802.1D. No utilice UplinkFast en los switches sin el conocimiento implícito de la topología de un enlace raíz de respaldo (generalmente switches de distribución y de núcleo en el diseño multicapa de Cisco). En términos generales no habilite UplinkFast en un switch con más de dos salidas de una red. Si el switch se encuentra en un entorno de acceso complejo y se tiene más de un enlace de bloqueo y un enlace de reenvío, puede evitar el uso de esta función en el switch o consultar al Ingeniero de Servicios Avanzados.

Ejecute este comando global para habilitar UplinkFast:

Switch(config)#spanning-tree uplinkfast

Este comando en el software Cisco IOS no ajusta automáticamente todos los valores de prioridad del bridge a un valor alto. En cambio, el comando sólo modifica aquellas VLAN con prioridad de bridge que no han sido cambiadas manualmente a otro valor. Además, a diferencia de CatOS, cuando reestablece un switch que tenía UplinkFast habilitado, la opción no de este comando (no spanning-tree uplinkfast) revierte todos los valores modificados a los predeterminados. Por lo tanto, cuando utilice este comando debe verificar el estado actual de las prioridades del bridge antes y después para asegurar de obtener el resultado deseado.

Nota: Necesita todas las palabras claves de todos los protocolos para el comando UplinkFast cuando la función de filtrado de protocolo está habilitada. Dada la forma en que CAM graba el tipo de protocolo como también la información MAC y VLAN cuando se encuentra habilitado el filtro de protocolo, se debe generar una trama UplinkFast para cada protocolo en cada dirección MAC. La palabra clave de valor indica los paquetes por segundo de las tramas de actualización de topología UplinkFast. El valor predeterminado es recomendable. No es necesario que configure UplinkFast con RSTP ya que el mecanismo se encuentra incluido de manera nativa y automáticamente habilitado en RSTP.

BackboneFast

Propósito

BackboneFast proporciona convergencia rápida desde fallos de enlace indirectos. BackboneFast reduce los tiempos de convergencia desde el predeterminado de 50 segundos a, generalmente, 30 segundos y, de esta manera, agrega funcionalidad a STP. Otra vez, esta función sólo se aplica cuando ejecuta 802.1D. No configure esta función cuando ejecute PVST rápido o MST (que incluye el componente rápido).

Información operativa general

BackboneFast se inicia cuando un puerto raíz o puerto bloqueado en un switch recibe BPDU inferiores desde el bridge designado. El puerto recibe generalmente BPDU inferiores cuando un switch descendente pierde la conexión a la raíz y empieza a enviar BPDU para elegir una nueva raíz. Una BPDU inferior identifica a un switch como el bridge raíz y el bridge designado.

Bajo las reglas normales del árbol de expansión, el switch receptor ignora las BPDU inferiores para el tiempo maxage configurado. De manera predeterminada, el tiempo máximo es de 20 segundos. Sin embargo, con BackboneFast, el switch considera a la BPDU inferior como una señal de un posible cambio en la topología. El switch utiliza BPDU de consulta de enlace raíz (RLQ) para determinar si tiene otro trayecto alternativo hacia el bridge raíz. Esta adición al protocolo RLQ permite a un switch verificar si la raíz se encuentra aun disponible. RLQ mueve un puerto bloqueado a reenvío más temprano y notifica al switch aislado que envía la BPDU inferior que la raíz se encuentra aun allí.

Aquí se encuentran algunas de las características principales del funcionamiento del protocolo:

  • Un switch transmite el paquete RLQ solamente fuera del puerto raíz (lo que significa que el paquete va hacia la raíz).

  • Un switch que recibe un RLQ puede responder si es el switch raíz o si ese switch sabe que ha perdido la conexión con la raíz. Si el switch no conoce estos hechos debe reenviar la consulta fuera de su puerto raíz.

  • Si un switch pierde conexión con la raíz, el switch debe responder a esta consulta de forma negativa.

  • La respuesta debe ser enviada únicamente por el puerto desde donde surgió la consulta.

  • El switch de la raíz debe responder siempre a esta consulta con una respuesta positiva.

  • Si se recibe la respuesta en un puerto que no sea raíz, se la elimina.

La operación puede reducir el tiempo de convergencia STP hasta 20 segundos debido a que maxage no debe caducar. Consulte Comprensión y configuración de Backbone Fast en switches Catalyst para obtener más información.

Recomendación de Cisco

Habilite BackboneFast en todos los switches que ejecutan STP únicamente si todo el dominio del árbol de expansión puede soportar esta función. Puede agregar el prefijo sin interrupciones a una red de producción.

Ejecute este comando global para habilitar BackboneFast:

Switch(config)#spanning-tree backbonefast

Nota: Debe configurar este comando de nivel global en todos los switches en un dominio. El comando agrega la funcionalidad a STP que todos los switches necesitan para comprender.

Otras opciones

BackboneFast no está soportado en los switches Catalyst 2900XL y 3500XL. En general, necesita habilitar BackboneFast si el dominio del switch contiene estos switches además de los switches Catalyst 4500/4000, 5500/5000 y 6500/6000. Cuando implementa BackboneFast en entornos con switches XL, bajo topologías estrictas, puede habilitar la función donde el switch XL sea el último switch en línea y sólo se conecta al núcleo en dos lugares. No implemente esta función si la arquitectura de los switches XL se encuentra como cadena margarita.

No es necesario que configure UplinkFast con RSTP u 802.1 debido a que el mecanismo se encuentra incluido de manera nativa y automáticamente habilitado en RSTP.

Protección de bucles de árbol de expansión

La Protección de bucles es una optimización propia de Cisco para STP. La protección de bucles protege las redes de Capa 2 de los bucles que puedan ocurrir debido al malfuncionamiento de una interfaz de red, CPU ocupada o cualquier cosa que impida el reenvío normal de BPDU. Un bucle de STP se crea cuando un puerto de bloqueo en una topología redundante transmite de manera errónea al estado de reenvío. En general, esto ocurre porque uno de los puertos en una topología redundante físicamente (no necesariamente el puerto de bloqueo STP) dejó de recibir BPDU.

La Protección de bucles sólo es útil en redes de switches cuando los switches se encuentran conectados por enlaces punto a punto, como es el caso en la mayoría de redes modernas de campus y centros de datos. La idea es que, en un enlace punto a punto, un bridge designado no puede desaparecer sin enviar una BPDU inferior o desactivando el enlace. La función de protección de bucle de STP se introdujo en el software Cisco IOS versión 12.1(13)E para Catalyst 6500 y en el software Cisco IOS versión 12.1(9)EA1 para los switches Catalyst 4500.

Consulte Árbol de expansión Mejoras del protocolo usando las funciones de Protección de bucle y Detección de desviación BPDU para obtener más información acerca de la protección de bucle.

Información operativa general

La protección de bucle verifica si un puerto raíz o un puerto raíz alternativo/de respaldo recibe BPDU. Si el puerto no recibe BPDU, la protección de bucle coloca al puerto en un estado incoherente (bloqueado) hasta que comienza a recibirlas nuevamente. Un puerto en el estado incoherente no transmite BPDU. Si ese puerto recibe BPDU nuevamente, el puerto (y el enlace) será considerado viable nuevamente. La condición de bucle incoherente será eliminada del puerto y STP determinará el estado del mismo. De esta manera, la recuperación es automática.

La protección de bucle aísla el fallo y permite la convergencia del árbol de expansión a una topología estable sin el enlace o bridge fallido. La protección de bucle impide los bucles de STP con la velocidad de la versión STP que se encuentran en uso. No hay dependencia en el propio STP (802.1D o 802.1w) o cuando ajuste los temporizadores STP. Por estos motivos Cisco recomienda que implemente la protección de bucle junto con UDLD en topologías que dependan de STP y en donde el software soporte las funciones.

Cuando el protector de bucle bloquea un puerto incoherente, se registra este mensaje.

%SPANTREE-SP-2-LOOPGUARD_BLOCK: Loop guard blocking port GigabitEthernet2/1 on VLAN0010

Después que se ha recibido la BDPU en un puerto en un estado STP de bloqueo incoherente con el bucle, el puerto pasa a otro estado STP. De acuerdo con la BPDU recibida, esto significa que la recuperación es automática y no es necesaria ninguna intervención. Después de la recuperación, se registra este mensaje:

%SPANTREE-SP-2-LOOPGUARD_UNBLOCK: Loop guard unblocking port GigabitEthernet2/1 on
VLAN0010

Interacción con otras funciones STP

Seguridad raíz

La protección raíz obliga a un puerto a ser siempre designado. La Protección de bucle es efectiva sólo si el puerto es puerto raíz o un puerto alternativo, lo que significa que sus funciones se excluyen mutuamente. Por lo tanto, la protección de bucle y la protección raíz no pueden habilitarse en un puerto al mismo tiempo.

UplinkFast

La protección de bucle es compatible con UplinkFast. Si la protección de bucle pone un puerto raíz en estado de bloqueo, UplinkFast coloca en estado de reenvío un nuevo puerto raíz. Además, UplinkFast no selecciona un puerto inconsistente con bucles como puerto raíz.

BackboneFast

La protección de bucle es compatible con Backbone Fast. BackboneFast es activado por la recepción de un BPDU inferior que proviene de un bridge designado. Debido a que las BPDU son recibidas desde este enlace, la protección de bucle no se activa. Por lo tanto, BackboneFast y la protección de bucle son compatibles.

PortFast

PortFast cambia un puerto al estado de reenvío designado inmediatamente una vez conectado. Debido a que el puerto activado por PortFast no es un puerto raíz/alternativo, la protección de bucle y PortFast se excluyen mutuamente.

PAgP

La Protección de bucle utiliza los puertos conocidos por STP. Por lo tanto, la protección de bucle puede sacar ventaja de la abstracción de los puertos lógicos que proporciona PAgP. Sin embargo, para formar un canal, todos los puertos físicos agrupado en el canal deben poseer configuraciones compatibles. PAgP implementa configuraciones uniformes de protección de bucle en todos los puertos físicos para formar un canal. Tenga en cuenta las siguientes advertencias cuando configure la protección de bucle en un EtherChannel:

  • STP siempre recoge el primer puerto operativo en el canal para enviar las BPDU. Si ese enlace se torna unidireccional, la protección de bucle bloquea los canales, aun si otros enlaces en el canal funcionan correctamente.

  • Si un grupo de puertos que ya se encuentran bloqueados por la protección de bucle se agrupan para formar un canal, STP pierde toda la información del estado para esos puertos y un nuevo puerto de canal puede alcanzar posiblemente el estado de reenvío con una función designada.

  • Si un canal se encuentra bloqueado por la protección de bucle y el canal se divide, STP pierde toda la información de estado. Los puerto físicos individuales pueden posiblemente alcanzar el estado de reenvío con una función designada, aun si uno o más de los enlaces que forman el canal son unidireccionales.

En estos últimos dos casos, hay una posibilidad de un bucle hasta que UDLD detecte el fallo. Pero la protección de bucle no puede detectarlo.

Protección de bucle y Comparación de función UDLD

La Protección de bucle y la funcionalidad UDLD se superponen parcialmente en el sentido que ambos protegen de los fallos del STP causados por enlaces unidireccionales. Estas dos funciones son distintas en la forma de abordar el problema y también en la funcionalidad. Específicamente, existen fallos unidireccionales específicos que UDLD no puede detectar, como fallos causados por un CPU que no envía BPDU. Además, el uso de temporizadores STP agresivos y el modo RSTP pueden dar como resultado bucles antes de que UDLD pueda detectar los fallos.

La Protección de bucle no funciona en enlaces compartidos o en aquellas situaciones en las que el enlace ha sido unidireccional desde la activación del enlace. En el caso de un enlace que ha sido unidireccional desde la activación del enlace, el puerto recibe BPDU y se torna designado. Esto puede ser una conducta normal, así que la protección de bucle no cubre este caso particular. UDLS brinda protección contra tal escenario.

La habilitación de UDLD y de la protección de bucle provee el mayor nivel de protección. Para más información sobre la comparación de una función entre la protección de bucle y UDLD, consulte:

Recomendación de Cisco

Cisco recomienda habilitar la protección de bucle globalmente en una red de switch con bucles físicos. Puede habilitar la protección de bucle globalmente en todos los puertos. Efectivamente, la función se habilita en todos los enlaces punto a punto. El enlace punto a punto es detectado por el estado dúplex del enlace. Si dúplex está lleno, el enlace es considerado punto a punto.

Switch(config)#spanning-tree loopguard default

Otras opciones

Para switches que no soportan una configuración de protección de bucle global, la recomendación es habilitar la función en todos los puertos individuales, lo que incluye puertos de canal de puerto. A pesar de que no hay beneficios si habilita la protección de bucle en un puerto designado, no considere la habilitación como un problema. Además, una reconvergencia válida del árbol de expansión puede convertir realmente un puerto designado en un puerto raíz, que haga la función útil en este puerto.

Switch(config)#interface type slot#/port#
Switch(config-if)#spanning-tree guard loop

Las redes con topología libres de bucles aun pueden beneficiarse con la protección de bucle en el caso que los bucles se introduzcan accidentalmente. Sin embargo, la habilitación de la protección de bucle en este tipo de topología puede conducir a problemas de aislamiento de redes. Si construye una topología libre de bucles y desea evitar los problemas de aislamiento de red, puede deshabilitar la protección de bucle global o individualmente. No habilite la protección de bucle en enlaces compartidos.

Switch(config)#no spanning-tree loopguard default
!--- Esto es la configuración global.

o bien

Switch(config)#interface type slot#/port#
Switch(config-if)#no spanning-tree guard loop
!--- Esta es la configuración de la interfaz.

Protección raíz del árbol de expansión

La función de protección de raíz proporciona una forma de imponer la ubicación del bridge raíz en la red. La protección raíz garantiza que el puerto en el que se ha habilitado el protector de raíz sea el puerto designado. En general, los puertos del bridge raíz son todos puertos designados, a menos que dos o más puertos del bridge raíz estén conectados entre sí. Si el bridge recibe BPDU STP superiores en un puerto habilitado con la protección raíz, éste desplaza este puerto a un estado STP. Este estado de no concordancia con la raíz es el mismo que un estado de escucha. No se reenvía tráfico a través de este puerto. De este modo, el protector de raíz impone la la posición del bridge raíz. La protección raíz se encuentra disponible en el antiguo software Cisco IOS versión 12.1E y posterior.

Información operativa general

La protección raíz es un mecanismo incorporado en STP. La protección raíz no posee un temporizador propio y depende de la recepción de BPDU únicamente. Cuando la protección raíz se aplica a un puerto, niega al puerto la posibilidad de convertirse en puerto raíz. Si la recepción de un BPDU activa la convergencia del árbol de expansión que hace que un puerto designado se vuelva un puerto raíz, el puerto raíz es puesto luego en estado raíz inconsistente. Este mensaje syslog ilustra:

%SPANTREE-SP-2-ROOTGUARD_BLOCK: Root guard blocking port GigabitEthernet2/1 on VLAN0010

Después de que el puerto deja de enviar BPDU superiores, el puerto se desbloquea nuevamente. A través de STP, el puerto pasa del estado de escucha al estado de aprendizaje, y las transiciones eventuales al estado de reenvío. Este mensaje syslog muestra la transición:

%SPANTREE-SP-2-ROOTGUARD_UNBLOCK: Root guard unblocking port GigabitEthernet2/1
on VLAN0010

La recuperación es automática. No es necesaria la intervención humana.

Debido a que la protección raíz obliga a un puerto a ser siempre designado y la protección de bucle es efectiva sólo si el puerto es un puerto raíz o un puerto alternativo, las funciones se excluyen mutuamente. Por lo tanto, no puede habilitar la protección de bucle y la protección raíz en un puerto al mismo tiempo.

Consulte Mejora del protector de raíz del Spanning Tree Protocol para más información.

Recomendación de Cisco

Cisco recomienda habilitar la función de protección raíz en los puertos que se conectan a los dispositivos de red que no se encuentran bajo estricto control administrativo. Para configurar la protección raíz, utilice estos comandos cuando se encuentre en el modo de configuración de interfaz:

Switch(config)#interface type slot#/port#
Switch(config-if)#spanning-tree guard root

EtherChannel

Propósito

EtherChannel abarca un algoritmo de distribución de tramas que multiplexa eficientemente tramas a través del componente 10/100-Mbps o los enlaces Gigabit. El algoritmo de distribución de tramas permite la multiplexión inversa de canales múltiples en un enlace lógico simple. A pesar de que cada plataforma difiere de la próxima plataforma en implementación, debe entender estas propiedades comunes:

  • Debe haber un algoritmo para multiplexar estadísticamente tramas sobre canales múltiples. En los switches Catalyst, esto se relaciona con el hardware. Aquí hay ejemplos:

    • Catalyst 5500/5000s: la presencia o falta de Ethernet Bundling Chip (EBC – Chip de agrupamiento Ethernet) en el módulo.

    • Catalyst 6500/6000s: un algoritmo que puede leer más allá de la trama y multiplexar por la dirección IP.

  • Existe la creación de un canal lógico de modo que una instancia simple de STP puede ser ejecutada o un par de enrutamientos puedan ser utilizados, lo que depende de si es EtherChannel de Capa 2 o 3.

  • Existe un protocolo de administración para verificar la consistencia del parámetro en ambos finales del enlace y para ayudar a administrar la recuperación de agrupamientos desde el fallo o adición del enlace. Este protocolo puede ser PAgP o Protocolo de control de agrupamiento de enlace (LACP).

Información operativa general

EtherChannel abarca un algoritmo de distribución de tramas que multiplexa eficientemente tramas a través del componente 10/100-Mbps, los enlaces Gigabit o los enlaces 10-Gigabit. Las diferencias en los algoritmos por plataforma surgen de la capacidad de cada tipo de hardware de extraer la información de encabezado de trama para hacer tomar la decisión de distribución.

El algoritmo de distribución de carga es un opción global para ambos protocolos de control de canales. PAgP y LACP utilizan un algoritmo de distribución de trama debido a que la norma IEEE no ordena ningún algoritmo de distribución particular. Sin embargo, cualquier algoritmo de distribución asegura que, al recibir las tramas, el algoritmo no causa el mal ordenamiento de las tramas que son parte de cualquier conversación dada o duplicación de tramas.

Esta tabla ilustra el algoritmo de distribución de trama en detalle para cada plataforma enumerada:

Plataforma

Algoritmo de balance de carga del canal

Serie Catalyst 3750

Catalyst 3750 que ejecuta el algoritmo de balance de carga del software Cisco IOS que utiliza direcciones MAC o IP y el mensaje de origen o de destino, o ambos.

Serie Catalyst 4500

Catalyst 4500 que ejecuta el algoritmo de balance de carga del software Cisco IOS que utiliza direcciones MAC, direcciones IP o números de puerto Capa 4 (L4), y tanto la fuente del mensaje o el destino del mismo o ambos.

Series Catalyst 6500/6000

Existen dos algoritmos de hash que pueden ser utilizados y que dependen del hardware del Supervisor Engine. El hash es un polinomio de decimoséptimo grado que se implementa en el hardware. En todos los casos, el hash toma Direcciones MAC, IP o número de puerto IP TCP/UDP y aplica el algoritmo para generar un valor de 3 bits. Este proceso ocurre independientemente de SA y DA. Luego, la operación XOR se utiliza con los resultados para generar otro valor de 3 bits. El valor determina qué puerto se utiliza en el canal para reenviar el paquete. Los canales en Catalyst 6500/6000 pueden formarse entre los puertos en cualquier módulo y pueden tener hasta 8 puertos.

Esta tabla indica los métodos de distribución soportados en varios modelos de Catalyst 6500/6000 Supervisor Engine. La tabla también muestra el comportamiento predeterminado:

Hardware

Descripción

Métodos de distribución

WS-F6020A (motor de Capa 2)

WS-F6K-PFC (motor de Capa 3)

Supervisor Engine I y Supervisor Engine IA posteriores

Supervisor Engine IA/Tarjeta de función de política (PFC1)

MAC capa 2: SA; DA; SA y DA

IP de capa 3: SA; DA; SA y DA (predeterminada)

WS-F6K-PFC 2

Supervisor Engine II/PFC2

MAC capa 2: SA; DA; SA y DA

IP de capa 3: SA; DA; SA y DA (predeterminada)

Sesión de Capa 4: Puerto S; puerto D; S y puerto D

WS-F6K-PFC3A

WS-F6K-PFC3B

WS-F6K-PFC3BXL

Supervisor Engine 720/PFC3A

Supervisor Engine 720/Supervisor Engine 32/PFC3B

Supervisor Engine 720/PFC3BXL

MAC capa 2: SA; DA; SA y DA

IP de capa 3: SA; DA; SA y DA (predeterminada)

Sesión de Capa 4: Puerto S; puerto D; S y puerto D

Nota: Con la distribución de Capa 4, el primer paquete fragmentado utiliza la distribución de Capa 4. Todos los paquetes subsiguientes utilizan la distribución de Capa 3.

Nota: Consulte estos documentos para más detalles acerca del soporte para EtherChannel en otras plataformas y cómo configurar y solucionar problemas en EtherChannel:

Recomendación de Cisco

SPAN en los switches Catalyst de las series 2940, 2950, 2955, 2970, 3550, 3560 y 3750 realizan el balance de carga troceando las direcciones IP de origen y de destino de forma predeterminada. Esto se recomienda, asumiendo que IP es el protocolo dominante. Ejecute este comando para configurar el balance de carga:

port-channel load-balance src-dst-ip
!--- Éste es el valor predeterminado.

Otras opciones

Dependiendo del flujo del tráfico, puede utilizar la distribución de Capa 4 para mejorar el balance de carga si la mayor parte del tráfico se encuentra entre la misma dirección IP de origen y de destino. Debe entender que, cuando la distribución de Capa 4 está configurada, el hash sólo incluye los puertos de origen y destino de Capa 4. No combina las direcciones IP de capa 3 en el algoritmo de hash. Ejecute este comando para configurar el balance de carga:

port-channel load-balance src-dst-port

Nota: La distribución de Capa 4 no es configurable en los switches de la serie Catalyst 3750.

Ejecute el comando show etherchannel load-balance para verificar la política de distribución de tramas.

Dependiendo de las plataformas de hardware, puede utilizar los comandos CLI para determinar qué interfaz en EtherChannel reenvía el flujo específico de tráfico, con la política de distribución de trama como base.

Para los switches Catalyst 6500, ejecute el comando remote login switch para reiniciar iniciar una sesión remota a la consola del Procesador del Switch (SP). A continuación, ejecute el comando test etherchannel load-balance interface port-channel number {ip | l4port | mac} [source_ip_add | source_mac_add | source_l4_port] [dest_ip_add | dest_mac_add | dest_l4_port].

Para los switches Catalyst 3750, ejecute el comando test etherchannel load-balance interface port-channel number {ip | mac} [source_ip_add | source_mac_add] [dest_ip_add | dest_mac_add].

Para Catalyst 4500, el comando equivalente aun no está disponible.

Pautas de la configuración de EtherChannel y Restricciones

EtherChannel verifica las propiedades de los puertos en todos los puertos físicos antes de agregar puertos compatibles en un puerto lógico simple. Las pautas y restricciones de configuración varían en las diferentes plataformas de los switches. Siga estas pautas y restricciones para evitar problemas de agrupación. Por ejemplo, si QoS está habilitado, los EtherChannels no se formaran cuando se agrupen los módulos de conmutación de las series Catalyst 6500/6000 con capacidades QoS diferentes. En los switches de las series Catalyst 6500 que ejecutan el software Cisco IOS, puede deshabilitar la verificación de atributo del puerto QoS en la agrupación EtherChannel con el comando no mls qos channel-consistencyport-channel interface. El comando show interface capability. mod/port muestra la capacidad del puerto QoS y determina si los puertos son compatibles.

Consulte estas pautas para diferentes plataformas para evitar problemas de configuración:

  • Configuring Layer 3 and Layer 2 EtherChannel (Catalyst 6500 Series Cisco IOS software Configuration Guide, 12.2SX) (Configuración de EtherChannel de Capa 2 y Capa 3 [Guía de configuración del software Cisco IOS de la serie Catalyst 6500, 12.2SX])

  • Configuring Layer 3 and Layer 2 EtherChannel (Catalyst 6500 Series Cisco IOS Software Configuration Guide, 12.1E) (Configuración de EtherChannel de Capa 2 y Capa 3 [Guía de configuración del software Cisco IOS de la serie Catalyst 6500, 12.1E])

  • Configuring Layer 3 and Layer 2 EtherChannel (Catalyst 4500Series Switch Cisco IOS Software) (Configuración de EtherChannel de Capa 2 y Capa 3 [Guía de configuración del software Cisco IOS de Catalyst 4500, 12.2(31)SG])

  • Configuring EtherChannels (Catalyst 3750 Switch Software Configuration 12.2(25)SEE) (Configuración de EtherChannels [Guía de configuración del software del switch Catalyst 3750, 12.2(25)SEE)])

El número máximo de EtherChannels soportados también dependen de la plataforma de hardware y las versiones del software. Los switches Catalyst 6500 que ejecutan el software Cisco IOS versión 12.2 (18)SXE y posterior soportan un máximo de 128 interfaces de canal de puerto. Las versiones de software anteriores al software Cisco IOS versión 12.2(18)SXE soportan un máximo de 64 interfaces de canal de puerto. El número de grupo configurable puede ser de 1 a 256, independientemente de la versión de software. Los switches de la serie Catalyst 4500 soportan un máximo de 64 EtherChannels. Para los switches 3750, la recomendación es no configurar más de 48 EtherChannels en la pila del switch.

Cálculos de costos del puerto del árbol de expansión

Debe entender el cálculo del costo del puerto del árbol de expansión para EtherChannels. Puede calcular el costo del puerto del árbol de expansión para EtherChannels con el método corto o largo. De forma predeterminada, el costo del puerto se calcula en modo corto.

Esta tabla ilustra el costo del puerto del árbol de expansión para un EtherChannel de Capa 2 en función del número de interfaces en EtherChannel:

Interfaz

Costo del puerto STP

Modo corto (16 bits)

Costo del puerto STP

Modo largo (32 bits)

100-Mbps Ethernet

19

200,000

GE

4

20,000

Gigabit EtherChannel de dos puertos (GEC)

3

10,000

GEC de tres puertos

2

6666

GEC de cuatro puertos

2

5000

GEC de cinco puertos

2

4000

GEC de seis puertos

2

3333

GEC de siete puertos

2

2857

GEC de ocho puertos

1

2500

10-GE

2

2000

10-Gigabit EtherChannel de dos puertos

1

1000

Con el uso del cálculo de modo corto predeterminado, un GEC de ocho puertos posee un costo de árbol de expansión más bajo que un 10-GE. Si el comportamiento deseado es preferir el 10-GE, configure el cálculo de método largo con el uso del comando spanning-tree pathcost method long. O configure manualmente el costo del puerto del árbol de expansión con el uso del comando spanning-tree cost cost.

Nota: En CatOS, el costo del puerto del árbol de expansión para un EtherChannel permanece igual después que falla el enlace de miembro de canal de puerto. En el software Cisco IOS, el costo del puerto para EtherChannel se actualiza inmediatamente para reflejar el nuevo ancho de banda disponible. Si el comportamiento deseado es evitar cambios innecesarios en la topología del árbol de expansión, puede configurar de manera estática el costo del puerto del árbol de expansión con el uso del comando spanning-tree cost cost.

Protocolo de agrupamiento de puertos (PAgP)

Propósito

PAgP es un protocolo de administración que verifica la consistencia del parámetro en ambos finales del enlace. PAgP además asiste al canal con adaptación al fallo o adición del enlace. Aquí hay algunas características de PAgP:

  • PAgP requiere que todos los puertos del canal pertenezcan a la misma VLAN o estén configurados como puertos troncales. Debido a que las VLAN dinámicas pueden forzar la modificación de un puerto en una VLAN diferente, las VLAN dinámicas no se incluyen en la participación de EtherChannel.

  • Si ya existe un agrupamiento y se modifica la configuración de un puerto, todos los puertos del agrupamiento se modifican para coincidir con esa configuración. Un ejemplo de esa modificación es una modificación de VLAN o una modificación del modo de conexión troncal.

  • PAgP no agrupa puertos que operan con diferente velocidad o dúplex de puerto. Si la velocidad y el dúplex se cambian cuando existe un agrupamiento, PAgP cambia la velocidad y el dúplex para todos los puertos en el agrupamiento.

Información operativa general

El puerto PAgP controla cada puerto físico (o lógico) individuales que será agrupado. La misma dirección MAC de grupo multidifusión se usa para los paquetes CDP para enviar paquetes PAgP. La dirección MAC es 01-00-0c-cc-cc-cc. Pero el valor del protocolo es 0x0104. Este es un resumen de la operación del protocolo:

  • Mientras el puerto físico esté habilitado, los paquetes PAgP se transmiten cada segundo durante la detección, y cada 30 segundos en estado constante.

  • Si se reciben los paquetes de datos pero no se recibe ningún paquete PAgP, se asume que el puerto está conectado a un dispositivo que no es PAgP capaz.

  • Escuche los paquetes PAgP que demuestran que el puerto físico posee una conexión bidireccional a otro dispositivo no apto para PAgP.

  • Tan pronto como se reciben esos paquetes en un grupo de puertos físicos, trate de formar un puerto agregado.

  • Si los paquetes PAgP se detienen por un período, el estado de PAgP se rompe.

Procesamiento normal

Estos conceptos ayudan a demostrar el comportamiento del protocolo:

  • Agport: un puerto lógico compuesto de todos los puertos físicos en el mismo agrupamiento y puede ser identificado por su propio ifIndex SNMP. Un agport no contiene puertos no operacionales.

  • Channel: un agrupamiento que cumple con el criterio de formación. Un canal puede contener puertos no operativos y es un superconjunto de agport. Los protocolos, que incluyen STP y VTP pero no CDP y DTP, se ejecutan en PAgP sobre los agports. Ninguno de estos protocolos puede enviar o recibir paquetes hasta que PAgP adjunte los agports a uno o más puertos físicos.

  • Capacidad de grupos: cada puerto físico y agport posee una configuración de parámetros denominada capacidad de grupo. Un puerto físico puede agruparse con otro puerto físico que posee la misma capacidad de grupoy sólo con ese puerto físico.

  • Procedimiento de agrupamiento: cuando un puerto físico alcanza el estado UpData o UpPAgP, el puerto se adjunta a un agport determinado. Cuando el puerto abandona cualquiera de esos estados para pasar a otro, el puerto se separa del agport.

Esta tabla proporciona más detalles acerca de los estados:

Estado

Significado

UpData

No se han recibido paquetes PAgP. Se envían paquetes PAgP. El puerto físico es el único puerto conectado al agport. No se produce entrada y salida de paquetes PAgP (Protocolo de puerto agregado) entre el puerto físico y el puerto agregado.

BiDir

Exactamente un paquete PAgP ha sido recibido que demuestra que existe una conexión bidireccional para un vecino justamente. El puerto físico no está conectado a ningún agport Los paquetes PAgP se envían y reciben.

UpPAgP

Este puerto físico, tal vez en asociación con otros puertos físicos, está conectado a un agport. Los paquetes PAgP se envían y reciben en el puerto físico. Los paquetes Non-PAgP (Protocolo de puerto agregado) entran y salen entre el puerto físico y el agport.

Ambos finales de las conexiones deben coincidir en el agrupamiento. El agrupamiento se define como el grupo más grande de los puertos en el agport que permiten ambos finales de una conexión.

Cuando un puerto físico alcanza el estado UpPAgP, el puerto asignado al agport que posee puerto físicos miembros que coincide con la capacidad de grupo del nuevo puerto físico y que se encuentran en el estado BiDir o el estado UpPAgP. Cualquiera de esos puertos BiDir se mueven al estado UpPAgP al mismo tiempo. Si no existiera un agport que posee parámetros de puertos físicos constituyentes compatibles con con los puertos físicos recientemente activos, el puerto se asigna a un agport con parámetros apropiados que no poseen puertos físicos asociados.

El tiempo de espera PAgP puede producirse en el último vecino conocido del puerto físico. El puerto de espera se elimina del agport. Al mismo tiempo, se remueven todos los puertos físicos en el mismo agport cuyos temporizadores también hayan agotado el tiempo de espera. Esto habilita un agport cuyo otro final ha muerto para romper todo de una vez, en lugar de un puerto físico por vez.

Comportamiento en caso de fallos

Si un enlace en un canal que existe fallo, el agport se actualiza y el tráfico se fragmenta en los enlaces que permanecen sin pérdida. Ejemplo de esos fallos incluyen:

  • El puerto está desconectado

  • El Conversor de interfaz Gigabit (GBIC) se ha eliminado

  • La fibra se ha roto

Nota: Cuando falle un enlace en un canal con la energía apagada o la eliminación del módulo, el comportamiento puede ser diferente. Por definición, un canal requiere dos puertos físicos. Si un puerto se pierde de este sistema en un canal de dos puertos, el agport lógico se rompe y el puerto físico original se reinicia con respecto al árbol de expansión. El tráfico puede descartarse hasta que STP permita al puerto tornarse disponible para datos nuevamente.

Esta diferencia en los dos modos de fallos es importante cuando planee el mantenimiento de la red. Puede haber una modificación de topología de STP la cual deba tener en cuenta cuando realice una eliminación en línea o una inserción de un módulo. Debe administrar cada enlace físico en el canal con el sistema de administración de la red (NMS) debido a que agport puede permanecer sin cambios durante un fallo.

Complete una de estas recomendaciones para mitigar modificaciones de topologías indeseadas en Catalyst 6500/6000:

  • Si se utiliza un puerto simple por módulo para formar un canal, use tres o más módulos (tres en total).

  • Si el canal abarca dos módulos, utilice dos puertos en cada módulo (cuatro puertos en total).

  • Si se necesita un canal de dos puertos a través de dos tarjetas, utilice sólo los puerto de Supervisor Engine.

Opciones de configuración

Puede configurar EtherChannels en diferentes modos, como lo resume esta tabla:

Modo

Opciones configurables

Activado

PAgP fuera de funcionamiento. Los canales de puertos, independientemente de cómo está configurado el puerto vecino. Si el modo de puerto vecino está encendidose forma un canal.

Auto

El agrupamiento está bajo el control del protocolo PAgP. Un puerto se coloca en estado de negociación pasivo. No se envían paquetes PAgP a la interfaz hasta que por lo menos un paquete PAgP se recibe indicando que el remitente opera en el modo deseable.

Deseable

El agrupamiento está bajo el control del protocolo PAgP. Un puerto se coloca en estado de negociación activo, en el que el puerto inicia las negociaciones con otros puertos a través de transmisiones de paquetes PAgP. Se forma un canal con otro grupo de puertos tanto en el modo deseable o auto.

No silencioso

Esto se predetermina en los puertos fibra FE y GE de Catalyst 5500/5000.

Una palabra clave de modo auto o deseable. Si no se reciben paquetes de datos en la interfaz, ésta nunca se adjuntará a agport y no podrá usarse para datos.

Esta verificación bidireccional fue proporcionada por un hardware específico de Catalyst 5500/5000 debido a que algunos fallos de enlace resultan en una interrupción del canal. Cuando habilita el modo no silencioso a un puerto vecino de recuperación no se le permite volver a interrumpir el canal sin necesidad.

Una agrupación más flexible y verificaciones mejoradas de la bidireccionalidad se encuentran presentes de manera predeterminada en el hardware de las series Catalyst 4500/4000 y 6500/6000.

Silencioso

Esto se predetermina en todos los puertos Catalyst 6500/6000 y 4500/4000, como también en los puerto de cobre 5500/5000.

Una palabra clave de modo auto o deseable. Si no se reciben paquetes de datos en la interfaz, después de un período de agotamiento de tiempo de espera de 15 segundos, la interfaz se adjunta a un agport. Por lo tanto, la interfaz puede utilizarse para la transmisión de datos.

El modo Silencioso también permite la operación de canal en el caso de un socio que puede ser un analizador o un servidor que nunca envía PAgP.

La configuración silencioso/no silencioso afecta la reacción de los puertos para situaciones que provocan tráfico unidireccional. Cuando un puerto no se encuentra habilitado para transmitir debido a una interfaz física fallida o un cable de fibra dañado, el puerto vecino aun puede ser dejado en el estado operativo. El socio continúa transmitiendo información. Sin embargo, la información se pierde debido a que el tráfico de retorno no puede recibirse. También pueden formarse bucles en el árbol de expansión a causa de la naturaleza unidireccional del enlace.

Algunos puertos de fibras tiene la capacidad de poner el puerto en un estado no operativo cuando el puerto pierde su señal de recepción (FEFI). Esta acción provoca que el puerto del socio se torne no operativo y efectivamente provoca que los puertos en ambos finales del enlace se desactiven.

Cuando utiliza dispositivos que transmiten datos (BPDU) y no puede detectar condiciones unidireccionales, utilice el modo no silencioso para permitir que los puertos permanezcan no operativos hasta que los datos de recepción se encuentren presentes y se verifique que el enlace es bidireccional. La cantidad de tiempo necesario para que PAgP detecte un enlace unidireccional es de 3.5 * 30 segundos = 105 seg. Treinta segundos es el tiempo entre dos mensajes PAgP sucesivos. Utilice UDLD que es el detector más rápido de enlaces unidireccionales.

Cuando utiliza dispositivos que no transmiten datos, utilice el modo silencioso. El uso del modo silencioso obliga al puerto a conectarse y permanecer operativo sin importar que los datos recibidos estén o no presentes. Además, para aquellos puertos que pueden detectar la presencia de una condición unidireccional, el modo silencioso se utiliza de manera predeterminada. Los ejemplos de estos puertos son plataformas más nuevas que utilizan la Capa 1 FEFI y UDLD.

Para apagar la canalización en una interfaz, ejecute el comando no channel-group number:

Switch(config)#interface type slot#/port#
Switch(config-if)#no channel-group 1 

Verificación

La tabla en esta sección ofrece un resumen de todos los escenarios posibles de los modos de canalización PAgP entre dos switches directamente conectados, Switch A y Switch B. Algunas de estas combinaciones pueden provocar que STP coloque los puertos en el lado de canalización en estado errDisable lo cual significa que esas combinaciones cierran los puertos en el lado de canalización. La función de protección de error de configuración EtherChannel se encuentra habilitada de manera predeterminada.

Modo de canal de Switch A

Modo de canal del switch B

Estado de canal de Switch A

Estado de canal de Switch B

Activado

Activado

Canal (no PAgP)

Canal (no PAgP)

Activado

No está configurado

Sin canal (puerto errDisable)

Sin canal

Activado

Auto

Sin canal (puerto errDisable)

Sin canal

Activado

Deseable

Sin canal (puerto errDisable)

Sin canal

No está configurado

Activado

Sin canal

Sin canal (puerto errDisable)

No está configurado

No está configurado

Sin canal

Sin canal

No está configurado

Auto

Sin canal

Sin canal

No está configurado

Deseable

Sin canal

Sin canal

Auto

Activado

Sin canal

Sin canal (puerto errDisable)

Auto

No está configurado

Sin canal

Sin canal

Auto

Auto

Sin canal

Sin canal

Auto

Deseable

Canal PAgP

Canal PAgP

Deseable

Activado

Sin canal

Sin canal

Deseable

No está configurado

Sin canal

Sin canal

Deseable

Auto

Canal PAgP

Canal PAgP

Deseable

Deseable

Canal PAgP

Canal PAgP

Recomendación sobre la configuración para los Canales L2

Habilite PAgP y utilice una configuración deseable en todos los enlaces EtherChannel. Consulte este comando para más información:

Switch(config)#interface type slot#/port#
Switch(config-if)#no ip address
!--- Esto asegura que no existe ninguna dirección IP
!---asignada al puerto LAN. 
Switch(config-if)#channel-group number mode desirable
!---Especifique el número de canal y el modo PAgP.

Verifique la configuración de esta manera:

Switch#show run interface port-channel number
Switch#show running-config interface type slot#/port#
Switch#show interfaces type slot#/port# etherchannel
Switch#show etherchannel number port-channel 

Impida errores en la configuración EtherChannel

Puede configurar de manera errónea un EtherChannel y crear un bucle de árbol de expansión. Este error en la configuración puede arruinar el proceso del switch. El software de sistema Cisco IOS incluye la función spanning-tree etherchannel guard misconfig para impedir este problema.

Ejecute este comando de configuración en todos los switches Catalyst que ejecutan el software Cisco IOS como un software de sistema.

Switch(config)#spanning-tree etherchannel guard misconfig

Otras opciones

Al canalizar dos dispositivos que no soportan PAgP pero soportan LACP, la recomendación es habilitar LACP con la configuración LACP activa en ambos finales de los dispositivos. Consulte la sección Protocolo de control de agrupación de enlace (LACP) de este documento para más información.

Al canalizar dos dispositivos que no soportan PAgP o LACP, debe codificar el canal a encendido. Este requisito aplica estos dispositivos de ejemplo:

  • Servidores

  • Local Director

  • Switches de contenido

  • Routers

  • Switches con software anterior

  • Switches Catalyst 2900XL/3500XL

  • Catalyst 8540s

Ejecute los comandos siguientes:

Switch(config)#interface type slot#/port#
Switch(config-if)#channel-group number mode on

Protocolo de control de agregación de enlaces (LACP)

LACP es un protocolo que permite a los puertos con características similares formar un canal a través de la negociación dinámica con switches contiguos. PAgP es un protocolo propiedad de Cisco que puede ejecutar en los switches Cisco y en aquellos switches que presentan los vendedores registrados. Pero LACP, que se define como IEEE 802.3ad, permite a los switches Cisco administrar la canalización Ethernet con dispositivos que cumplen la especificación 802.3ad.

LACP es soportado en estas plataformas y versiones:

  • Catalyst de las series 6500/6000 con la versión 12.1(11b)EX del software Cisco IOS y posteriores

  • Catalyst de la serie 4500 con la versión 12.1(13)EW del software Cisco IOS y posterior

  • Catalyst de la serie 3750 con la versión 12.1(14)EA1 del software Cisco IOS y posterior

Existen pocas diferencias entre LACP y PAgP desde una perspectiva funcional. Ambos protocolos soportan un máximo de ocho puertos en cada canal y las misma propiedades del puerto se verifican antes de formar el agrupamiento. Estas propiedades del puerto incluyen:

  • Velocidad

  • Dúplex

  • VLAN nativa y tipo de conexión troncal

Las diferencias más notables entre LACP y PAgP son:

  • El protocolo LACP puede ejecutarse sólo en puertos dúplex completo y no soporta puertos semidúplex.

  • El protocolo LACP soporta puertos de espera activos. LACP siempre trata de configurar el número máximo de puertos compatibles en un canal, hasta el máximo permitido por el hardware (ocho puertos). Si LACP no puede agrupar todos los puertos compatibles (por ejemplo, si el sistema remoto posee limitaciones de hardware más restrictivas), todos los puertos que no pueden estar incluidos activamente en el canal se colocan en estado de espera activo y se utilizan sólo si uno de los puertos utilizados falla.

Nota: Para los switches de la serie Catalyst 4500, el número máximo de puertos para el que puede asignar la misma clave administrativa es ocho. Para los switches Catalyst 6500 y 3750 que ejecutan el software del sistema Cisco IOS, LACP trata de configurar el el número máximo de puertos compatibles en EtherChannel, hasta el máximo permitido por el hardware (ocho puertos). Se pueden configurar ocho puertos adicionales como puertos de espera activos.

Información operativa general

LACP controla cada puerto físico (o lógico) individual a agrupar. Los paquetes LACP se envían por medio del uso de la dirección MAC de grupos de multidifusión 01-80-c2-00-00-02. El valor de tipo/valor es 0x8809 con un subtipo de 0x01. Este es un resumen del protocolo de operación:

  • El protocolo depende de los dispositivos para anunciar sus capacidades de agrupación e información de estado. Las transmisiones se envían de manera regular y periódica en cada enlace de agrupación.

  • Mientras el puerto físico esté habilitado, los paquetes LACP se transmiten cada segundo durante la detección y cada 30 segundos en estado constante.

  • Los socios en un enlace de agrupación escuchan la información que es enviada dentro del protocolo y decide qué acción o acciones tomar.

  • Los puertos compatibles se configuran en un canal, hasta el máximo permitido por el hardware (ocho puertos).

  • Los agrupamientos se mantienen por intercambio regular y oportuno de información de estado actualizada entre los socios de enlaces. Si la configuración. cambia (debido a un fallo en el enlace, por ejemplo), los socios de parámetros se desconectan y realizan la acción apropiada basada en el nuevo estado del sistema.

  • Además de las transmisiones de unidad de datos LACP periódica (LACPDU), si hay un cambio en la información del estado, el protocolo transmite un LACPDU conducido por el hecho a los socios. Los socios de protocolos realizan las acciones correspondientes según el nuevo estado del sistema.

Parámetros de LACP

Para permitir a LACP determinar si un grupo de enlaces se conecta al mismo sistema y si esos enlaces son compatibles desde el punto de vista de la agrupación, es necesario poder establecer:

  • Un identificador global único para cada sistema que participa en agrupación de enlace.

    A cada sistema que ejecuta LACP se le debe asignar una prioridad que puede elegirse automáticamente (con la prioridad de manera predeterminada de 32768) o ser elegida por el administrador. La prioridad del sistema se utiliza principalmente en conjunto con una dirección MAC del sistema para formar el identificador de sistema.

  • Un medio para identificar el grupo de capacidades asociadas con cada puerto y con cada agrupación, entendido por un sistema dado.

    Cada puerto en el sistema debe asignar una prioridad, ya sea automáticamente (con la prioridad de manera predeterminada de 128) o ser elegida por el administrador. La prioridad se utiliza en conjunto con el número de puerto para formar el identificador del puerto.

  • Un medio para identificar una agrupación de enlace y su agregador asociado.

    La habilidad de un puerto para agruparse con otro se resume en un simple parámetro entero de 16 bits estrictamente mayor a cero denominado clave. Cada clave es determinada en base a diferentes factores, como:

    • Las características físicas del puerto, que incluyen la velocidad de datos, duplexidad y punto a punto o medio compartido

    • Restricciones de configuración establecidas por el administrador de la red

    Hay dos claves asociadas con cada puerto:

    • Una clave administrativa

    • Una clave operativa

    La clave administrativa permite la manipulación de los valores claves mediante la administración y por lo tanto, el usuario puede elegir esta clave. Una clave operativa es utilizada por el sistema para formar agrupaciones. El usuario no puede elegir o cambiar esta clave directamente. El grupo de puertos en un sistema dado que comparte el mismo valor de clave operativa son miembros del mismo grupo de claves.

Por lo tanto, dados dos sistemas y un grupo de puertos con la misma clave administrativa, cada sistema trata de agrupar los puertos, empezando desde el puerto con la prioridad más alta en sistema de prioridad más alta. Este comportamiento es posible ya que cada sistema conoce estas prioridades:

  • La propia prioridad, que tanto el usuario como el software asignaron

  • La prioridad del socio, que se ha descubierto a través de paquetes LACP

Comportamiento en caso de fallos

El comportamiento de fallo para LACP es el mismo que el comportamiento de fallo para PAgP. Si un enlace en un canal que existe fallo (por ejemplo, si el puerto se desconecta, se elimina un GBIC o se rompe una fibra), el agport se actualiza y el el tráfico se fragmenta en los enlaces restantes en 1 segundo. El tráfico que no requiera la reestructuración después del fallo (que es un tráfico que sigue enviando en el mismo enlace) no sufre ninguna pérdida. La restauración de los enlaces fallidos activa otra actualización del agport y el tráfico se fragmenta nuevamente.

Opciones de configuración

Puede configurar LACP EtherChannels en diferentes modos, como lo resume esta tabla:

Modo

Opciones configurables

Activado

La agrupación de enlace está obligada a formarse sin ninguna negociación LACP. El switch no envía el paquete LACP ni procesa ningún paquete LACP entrante. Si el puerto del vecino está encendido, se forma un canal.

Está apagada o no está configurada

El puerto no está canalizando, independientemente de la configuración del puerto vecino.

Pasiva (Predeterminada)

Esto es similar al modo automático en PagP. El switch no inicia el canal, pero entiende los paquetes LACP entrantes. El par (en estado activo) inicia la negociación (enviando un paquete LACP) que recibe el switch y al cual responde, eventualmente formando la agrupación de canales con el par.

Activo

Esto es similar al modo deseado en PAgP. Este switch inicia la negociación para formar un enlace global. El enlace global se forma si el otro final se ejecuta en modo LACP pasivo o activo.

LACP utiliza un temporizador interno de 30 segundos (Slow_Periodic_Time) después que se establecen los LACP EtherChannels. El número de segundos antes de la invalidación de la información LACPDU recibida al utilizar tiempos prolongados (3 veces el Slow_Periodic_Time) es 90. Se recomienda UDLD como un detector más rápido de enlaces unidireccionales. No puede ajustar los temporizadores LACP y, en este punto, no puede configurar los switches para utilizar la transmisión de unidad de datos de protocolo rápida (PDU) (cada segundo) para mantener el canal después de que se haya formado el mismo.

Verificación

La tabla en esta sección ofrece un resumen de todos los escenarios posibles de los modos de canalización LACP entre dos switches directamente conectados (Switch A y Switch B). Algunas de estas combinaciones pueden provocar que la protección EtherChannel coloque los puertos en el lado de canalización puertos en estado errdisable. La función de protección de error de configuración EtherChannel se encuentra habilitada de manera predeterminada.

Modo de canal de Switch A

Modo de canal del switch B

Estado de canal de Switch A

Estado de canal de Switch B

Activado

Activado

Canal (no LACP)

Canal (no LACP)

Activado

Desactivado

Sin canal (puerto errDisable)

Sin canal

Activado

Pasivo

Sin canal (puerto errDisable)

Sin canal

Activado

Activo

Sin canal (puerto errDisable)

Sin canal

Desactivado

Desactivado

Sin canal

Sin canal

Desactivado

Pasivo

Sin canal

Sin canal

Desactivado

Activo

Sin canal

Sin canal

Pasivo

Pasivo

Sin canal

Sin canal

Pasivo

Activo

Canal LACP

Canal LACP

Activo

Activo

Canal LACP

Canal LACP

Recomendaciones de Cisco

Cisco recomienda habilitar PAgP en las conexiones de canales entre los switches Cisco. Al canalizar dos dispositivos que no soportan PAgP pero soportan LACP, la recomendación es habilitar LACP con la configuración LACP activa en ambos finales de los dispositivos.

En los switches que ejecutan CatOS, todos los puertos en un Catalyst 4500/4000 y Catalyst 6500/6000 utilizan el protocolo de canal PAgP predeterminado. Para configurar los puertos para que utilice LACP, debe configurar los protocolos de canales en los módulos hacia LACP. LACP y PAgP no pude ejecutarse en el mismo módulo en los switches que ejecutan CatOS. Esta limitación no se aplica a los switches que ejecutan el software Cisco IOS. Los switches que ejecutan el software Cisco IOS pueden soportar PAgP y LACP en el mismo módulo. Ejecute estos comandos para configurar el modo de canal LACP para activar y asignar un número de clave administrativa:

Switch(config)#interface range type slot#/port#
Switch(config-if)#channel-group admin_key mode active

El comando show etherchannel summary. muestra un resumen de una línea por canal que incluye esta información:

  • Números de grupos

  • Números de puertos de canal

  • Estado de los puertos

  • Los puertos que son parte de un canal

El comando show etherchannel port-channel muestra la información detallada del canal de puerto para todos los grupos de canales. El resultado incluye esta información:

  • Estado del canal

  • Protocolo usado

  • El tiempo desde que los puertos se agruparon

Para mostrar la información detallada para un grupo de canal específico, con los detalles de cada puerto mostrado de manera separada, use el comando show etherchannel channel_number detail. El resultado del comando incluye los detalles del socio y los detalles del canal de puerto. Consulte Configuración de LACP (802.3ad) entre un Catalyst 6500/6000 y un Catalyst 4500/ 4000 para más información.

Otras opciones

Con los dispositivos de los canales que no soportan PAgP o LACP, debe codificar el canal a encendido. Esto depende se aplica a los siguientes dispositivos:

  • Servidores

  • Local Director

  • Switches de contenido

  • Routers

  • Switches con software más antiguos

  • Switches Catalyst 2900XL/3500XL

  • Catalyst 8540s

Ejecute los comandos siguientes:

Switch(config)#interface range type slot#/port#
Switch(config-if)#channel-group admin_key mode on

Detección de enlace unidireccional

Propósito

UDLD es propiedad de Cisco, protocolo liviano desarrollado para detectar instancias de comunicaciones unidireccionales entre los dispositivos. Existen otros métodos para detectar el estado bidireccional de los medios de transmisión, como FEFI. Sin embargo, existen instancias en las que los mecanismo de detección de la Capa 1 no son suficientes. Estos escenarios pueden resultar en:

  • La operación imprevisible de STP

  • La inundación excesiva o incorrecta de los paquetes

  • El envío del tráfico a agujeros negros

La función de UDLD direcciona las condiciones fallidas en las interfaces Ethernet de fibra y cobre:

  • La supervisión de las configuraciones del cableado físico: cierra como errDisable cualquier puerto mal conectado.

  • Protege contra los enlaces unidireccionales: en la detección de un enlace unidireccional que se produce debido al mal funcionamiento de los medios o del puerto/interfaz, el puerto afectado se cierra como errDisable. Se genera el mensaje syslog correspondiente.

  • Además, el modo UDLD agresivo verifica que un enlace bidireccional previamente considerado no pierda conectividad en el caso que el enlace no se pueda usar debido a la congestión. El modo UDLD agresivo realiza verificaciones de conectividad en curso a través del enlace. El fin principal del modo UDLD agresivo es evitar el agujero negro de tráfico en determinadas condiciones fallidas que no están dirigidas por el modo UDLD normal.

Consulte Introducción y configuración de la función del protocolo de detección de enlace unidireccional (UDLD) para más detalles.

El árbol de expansión posee un flujo de BDPU unidireccional de estado constante y puede tener los fallos que proporciona esta lista de secciones. Un puerto puede fallar rápidamente en la transmisión de BPDU, que provoca una modificación en el estado STP de bloqueo a reenvío en el vecino. Sin embargo, existe aun un bucle ya que el puerto todavía puede recibir.

Información operativa general

UDLD es un protocolo de Capa 2 que funciona sobre la capa LLC (destino MAC 01-00-0c-cc-cc-cc, SNAP HDLC protocolo de tipo 0x0111). Cuando ejecuta UDLD en combinación con FEFI y los mecanismos de negociación automática de Capa 1, puede validar la integridad física (L1) y lógica (L2) de un enlace.

UDLD brinda prestaciones para las funciones de protección que FEFI y la negociación automática no pueden realizar. Estas funciones incluyen:

  • La detección y la memoria caché de la información vecina

  • El cierre de todos los puertos mal conectados

  • Detección del mal funcionamiento de interfaz/puertos lógicos o los fallos en los enlaces que no son punto a punto

    Nota: Cuando los enlaces no son punto a punto, atraviesan los conversores de medios o los concentradores.

UDLD emplea estos dos mecanismo básicos.

  1. UDLD detecta los vecinos y mantiene la información actualizada en una memoria caché local.

  2. UDLD envía un tren de mensajes de sonda/eco UDLD al detectar un nuevo vecino o siempre que un vecino solicite la resincronización de la memoria caché.

UDLD envía constantemente mensajes de sondas/eco en todos los puertos. En la recepción del mensaje UDLD correspondiente en un puerto, se activa una fase de detección y un proceso de validación. El puerto estará habilitado si se reúnen todas las condiciones válidas. Las condiciones se cumplen si el puerto es bidireccional y está correctamente conectado. Si no se cumplen las condiciones el puerto será errDisable, lo que activará este mensaje syslog:

UDLD-3-AGGRDISABLE: Neighbor(s) of port disappeared on bidirectional link.
   Port disabled
UDLD-3-AGGRDISABLEFAIL: Neighbor(s) of port disappeared on bidirectional link.
   Failed to disable port
UDLD-3-DISABLE: Unidirectional link detected on port disabled.
UDLD-3-DISABLEFAIL: Unidirectional link detected on port, failed to disable port.
UDLD-3-SENDFAIL: Transmit failure on port.
UDLD-4-ONEWAYPATH: A unidirectional link from port to port of device [chars]
   was detected.

Para una lista completa de los mensajes por instalación, que incluyen eventos UDLD consulte Mensajes UDLD (Mensajes del sistema Cisco IOS , Volumen 2 de 2).

Después de establecer un enlace y clasificarlo como bidireccional, el UDLD continúa anunciando mensajes de sonda/eco en el intervalo predeterminado de 15 seg.

La siguiente tabla aporta más información acerca de los estados de los puertos:

Estado de puerto

Comentario

Indeterminado

La detección de UDL en progreso/de vecindad ha sido deshabilitada.

No aplicable

UDLD ha sido deshabilitada.

Cierre

Se ha detectado el enlace unidireccional y el puerto ha sido deshabilitado.

Bidireccional

Se ha detectado el enlace bidireccional

Mantenimiento de memoria caché de vecino

UDLD envía periódicamente paquetes de saludo de sonda/eco en cada interfaz activa para mantener la integridad de la memoria caché de vecino UDLD. En la recepción de un mensaje de saludo, el mensaje se guardará en memoria y se almacenará por un período máximo, definido como tiempo en espera. Cuando el tiempo en espera caduca, la entrada de caché correspondiente caduca. Si se recibe un nuevo mensaje de saludo dentro del período de tiempo en espera, la entrada nueva reemplaza a la anterior y el temporizador tiempo de vida correspondiente es reestablecido.

Siempre que una interfaz UDLD habilitada se deshabilita o siempre que un dispositivo se reestablece, se borran todas las entradas de caché existentes para las interfaces que afecta la modificación de la configuración. Esto mantiene la integridad de la memoria caché UDLD. UDLD transmite por lo menos un mensaje para informar a los respectivos vecinos de la necesidad de purgar las entradas de caché correspondientes.

Mecanismo de detección de Eco

El mecanismo de eco forma la base del algoritmo de detección. Siempre que un dispositivo UDLD detecta un nuevo vecino o recibe un pedido de resincronización de un vecino desincronizado, el dispositivo comienza o se reinicia la ventana de detección en el lado de la conexión y envía una ráfaga de mensajes de eco en respuesta. Debido a que este comportamiento debe ser el mismo a través de todos los vecinos, el remitente del eco espera recibir ecos como respuesta. Si la ventana de detección finaliza sin la recepción de algún mensaje de respuesta válido, el enlace es considerado unidireccional. Desde este punto de vista, se puede activar un reestablecimiento del enlace o el proceso de cierre del puerto. Otras condiciones anormales que verifica el dispositivo son:

  • Fibras de transmisión (Tx) con bucle de retorno para el conector Rx del mismo puerto

  • El mal cableado en el caso de una interconexión del medio compartido (por ejemplo, un concentrador o dispositivo similar)

Tiempo de convergencia

Para impedir los bucles STP, el software Cisco IOS versión 12.1 y posterior han reducido el intervalo de mensaje predeterminado UDLD de 60 a 15 segundos. Este intervalo fue modificado para cerrar un enlace unidireccional antes que un puerto bloqueado en el árbol de expansión 802.1D sea capaz de pasar al estado de reenvío. Este valor de intervalo de mensaje determina el rango al que un vecino envía sondas UDLD después de la fase de conexión o detección. El intervalo de mensaje no necesita coincidir en ambos finales de un enlace, a pesar de que se prefiera la configuración consistente siempre que sea posible. Cuando se establecen los vecinos UDLD, el intervalo de mensajes configurado se envía al vecino y el intervalo de tiempo en espera para ese par se calcula como:

3 * (message interval)

Como tal, la relación de par caduca después que se pierden tres saludos consecutivos (o sondas). Debido a que los intervalos de mensajes son diferentes en cada lado, este valor de pausa es simplemente diferente en cada lado y un lado reconoce un fallo más rápidamente.

El tiempo aproximado necesario para que UDLD detecte un fallo unidireccional de un enlace previamente constante es aproximadamente:

2.5 * (message interval) + 4 seconds

Esto es aproximadamente 41 segundos con el intervalo de mensaje predeterminado de 15 segundos. Esta cantidad de tiempo es mucho más corta que los 50 segundo necesarios generalmente para que STP vuelva a converger. Si NMP CPU posee algunos ciclos libres y si el usuario supervisa cuidadosamente su nivel de utilización (una buena práctica) se aceptará una reducción del intervalo de mensaje (aun) al mínimo de 7 segundos. Además, esta reducción del intervalo de tiempo ayuda a acelerar la detección por un factor importante.

Nota: El mínimo es 1 segundo en el software Cisco IOS versión 12.2(25)SEC.

Por lo tanto, UDLD tiene una dependencia asumida de los temporizadores del árbol de expansión predeterminado. Si STP se fija para converger más rápidamente que UDLD, considere un mecanismo alternativo, como la función de protección de bucle STP. Considere un mecanismo alternativo en este caso cuando implemente RSTP (802.1w), también, debido a que RSTP posee características de convergencia en ms, dependiendo de la topología. Por estos motivos utilice la protección de bucle junto con UDLD para proporcionar la mayor protección. La protección de bucle impide los bucles STP con la velocidad de la versión STP en uso. Un UDLD cuida la detección de las conexiones unidireccionales en los enlaces EtherChannel individuales o en casos en que las BPDU no fluyen por la dirección caída.

Nota: UDLD es independiente de STP. UDLD no atrapa cada situación de fallo de STP, como por ejemplo aquellos fallos causados por una CPU que no envía BPDU por un tiempo mayor a (2 * Fwddelay + maxage). Por este motivo, Cisco recomienda que implemente UDLD junto con la protección de bucle en topologías que dependen de STP.

precauciónPrecaución: Tenga en cuenta las versiones anteriores de UDLD en los switches 2900XL/3500XL que usan un intervalo de mensaje predeterminado de 60 segundos no configurable.. Son propensos a las condiciones de bucle de árbol de expansión.

Modo UDLD agresivo

UDLD agresivo fue creado para dirigir específicamente aquellos pocos casos en el que se necesita una verificación de conectividad bidireccional. Como tal, la función de modo agresivo proporciona la protección mejorada contra las condiciones de enlace unidireccional en estas situaciones:

  • Cuando la pérdida de UDLD PDU es simétrica y ambos finales caducan. En este caso, ningún puerto es errdisabled.

  • Un lado del enlace posee un puerto atascado (ambos Tx y Rx).

  • Un lado del enlace permanece arriba mientras que el otro lado desciende.

  • La negociación automática u otro mecanismo de detección de fallo de Capa 1 se encuentra deshabilitada.

  • Se desea una reducción en los mecanismos de dependencia en la Capa 1 FEFI.

  • Necesita protección máxima contra fallos de enlaces unidireccionales en enlaces punto a punto FE/GE. Específicamente, en donde no se soporta ninguna fallo entre dos vecinos, las sondas UDLD agresivas pueden considerarse como un latido, la presencia del cual garantiza la salud del enlace.

El caso más común para la implementación de UDLD agresivo es realizar la verificación de la conectividad en un miembro de un agrupamiento cuando al negociación automática u otro mecanismo de detección de fallo de Capa 1 se encuentra deshabilitado o sin uso. Es particularmente útil con conexiones EtherChannel debido a que PAgP y LACP, aun estando habilitadas, no utilizan temporizadores de saludos muy bajos en el estado constante. En este caso, UDLD agresivo posee beneficios adicionales para impedir posibles bucles de árbol de expansión.

Es importante entender que el modo normal UDLD no verifica una condición de enlace unidireccional, aun después de que un enlace alcance el estado bidireccional. UDLD está hecho para detectar problemas de Capa 2 que provocan bucles STP y aquellos problemas son generalmente unidireccionales (debido al flujo de BPDU sólo en una dirección en el estado constante). Por lo tanto, el uso de UDLD normal junto con la negociación automática y la protección de bucle (para redes que dependen de STP) es casi siempre suficiente. Con el modo UDLD agresivo habilitado, después que todos los vecinos de un puerto hayan caducado, tanto en el anuncio o en la fase de detección , el modo UDLD agresivo reinicia la secuencia de conexión en un esfuerzo por resincronizar con cualquier vecino que pueda estar fuera de sincronización. Si después de un tren rápido de mensajes (ocho reintentos fallidos) el enlace es aun considerado indeterminado, el puerto se coloca en el estado errdisable.

Nota: Algunos switches no son aptos para el modo UDLD agresivo. Actualmente, Catalyst 2900XL y Catalyst 3500XL poseen intervalos de mensajes codificados de 60 segundos. Esto no se considera lo suficientemente rápido como para proteger posibles bucles STP (con los parámetros STP predeterminados asumidos).

Enlaces de recuperación automática de UDLD

La recuperación errdisable se encuentra deshabilitada globalmente de manera predeterminada. Después de habilitarla globalmente, si un puerto pasa al estado errdisable, se rehabilitará automáticamente después de un intervalo de tiempo seleccionado. El tiempo predeterminado es de 300 segundos, que es un temporizador global y se mantiene para todos los puertos en un switch. Dependiendo de la versión de software, se puede impedir manualmente la rehabilitación de un puerto si configura el tiempo en espera errdisable para ese puerto para deshabilitarlo con el uso del mecanismo de recuperación de tiempo en espera errdisable para UDLD:

Switch(config)#errdisable recovery cause udld

Considere el uso de la función de tiempo en espera errdisable al implementar el modo UDLD agresivo con las capacidades de administración de red no fuera de banda, particularmente en la capa de acceso o en cualquier dispositivo que pueda tornarse aislado de la red en el caso de una situación errdisable.

Consulte errdisable recovery (Referencia de comandos del IOS de Cisco de la serie Catalyst 6500, 12.1 E) para más detalles sobre cómo configurar un período de tiempo en espera para los puertos en estado errdisable.

La recuperación Errdisable puede ser especialmente importante para UDLD en la capa de acceso cuando los switches de acceso se encuentran distribuidos a través del entorno de campus y la visita manual de cada switch para rehabilitar ambos uplinks toma un tiempo considerable.

Cisco no recomienda la recuperación errdisable en el núcleo de la red debido a que generalmente existen múltiples puntos de entrada al núcleo y la recuperación automática en el núcleo puede conducir a problemas recurrentes. Por consiguiente, se debe rehabilitar manualmente un puerto en el núcleo si UDLD deshabilita el puerto.

UDLD en los enlaces enrutados

Con el propósito de esta discusión, un enlace enrutado es uno de de estos dos tipos de conexiones:

  • El punto a punto entre dos nodos de router (configurados con una máscara de subred de 30 bits)

  • Una VLAN con múltiples puertos pero que soportan sólo conexiones enrutadas, como en una topología de núcleo de Capa 2 dividida

Interior Gateway Routing Protocol (IGRP) posee características únicas con respecto a cómo maneja las relaciones de vecinos y la convergencia del router. Esta sección describe las características relevantes para la discusión, que compara dos de los protocolos de routers más prevalecientes utilizados hoy, Protocolo Open Shortest Path First (OSPF) e IGRP mejorado (EIGRP).

Nota: Un fallo en la Capa 1 o en la Capa 2 en cualquier red enrutada punto a punto resulta en el desmembramiento casi inmediato de la conexión de Capa 3. Dada la forma en que sólo el puerto del switch en esa VLAN pasa a un estado no conectado sobre el fallo de Capa 1/Capa 2, la función de estado automático de la interfaz sincroniza los estados de los puertos de Capa 2 y Capa 3 en aproximadamente dos segundos y coloca la interfaz de VLAN de Capa 3 en un estado de encendido/apagado (protocolo en línea apagado).

Si asume los valores predeterminados del temporizador, OSPF envía mensajes de saludos cada 10 segundos y posee un intervalo muerto de 40 segundos (4 * saludo). Estos temporizadores son consistentes para OSPF punto a punto y redes de transmisión. Debido a que OSPF requiere comunicaciones bidireccionales para formar una adyacencia, el tiempo de fallo en el peor de los casos es de 40 segundos. Esto es verdad aun si el fallo de Capa 1/Capa 2 no es puro en una conexión punto a punto y deja un escenario casi listo con el que el debe negociar el protocolo de Capa 3. Debido a que el tiempo de detección de UDLD es muy similar al tiempo de detección de un temporizador muerto OSPF que caduca (aproximadamente 40 segundos), las ventajas de la configuración del modo normal UDLD en un enlace punto a punto de Capa 3 OSPF son limitadas.

En muchos caos, EIGRP converge más rápido que OSPF. Pero es importante destacar que las comunicaciones bidireccionales no son un requisito para que los vecinos intercambien información de routers. En escenarios casi listos muy específicos, , EIGRP es vulnerable al envío a agujeros negros de tráfico que dura hasta que otro evento vuelve activos a los routers. El modo Normal UDLD puede aliviar estas circunstancias debido a que detecta el fallo del enlace unidireccional y el deshabilita el puerto de errores.

Para las conexiones enrutadas de Capa 3 que utilizan cualquier protocolo de enrutamiento, UDLD normal aun proporciona protección contra los problemas presentes luego de la activación inicial del enlace, como un mal cableado o hardware defectuoso. Además, el modo UDLD agresivo proporciona estas ventajas en las conexiones enrutadas de Capa 3:

  • Impide el envío innecesario a agujeros negros de tráfico (con temporizadores mínimos requerido en algunos caso).

  • Coloca un enlace alternado en estado errdisable.

  • Protege contra los bucles que resultan de las configuraciones de EtherChannel de Capa 3.

Comportamiento predeterminado de UDLD

El UDLD está globalmente deshabilitado y preparado para la habilitación en puertos de fibra de manera predeterminada. Debido a que UDLD es un protocolo de infraestructura necesaria entre los switches únicamente, UDLD se deshabilita de manera predeterminada en los puertos de cobre, que tienden a utilizarse para el acceso al host. Tenga en cuenta que debe habilitar UDLD globalmente y en el nivel de la interfaz antes de que los vecinos puedan alcanza el estado bidireccional. El intervalo de mensaje predeterminado es de 15 segundos. Sin embargo, el intervalo de mensaje predeterminado puede mostrar siete segundos en algunos casos. Consulte la ID de error de Cisco CSCea70679(solamente clientes registrados) para más información. El intervalo de mensaje predeterminado se configura entre siete y 90 segundos y el modo UDLD agresivo se deshabilita. Software Cisco IOS versión 12.2(25)SEC reduce este temporizador a un segundo.

Recomendación sobre la configuración de Cisco

En la gran mayoría de los casos, Cisco recomienda que habilite el modo normal UDLD en todos los enlaces punto a punto FE/GE entre los switches Cisco y configure el intervalo de mensaje UDLD a 15 segundos cuando utilice el temporizador del árbol de expansión 802.1D predeterminado. Además, en donde las redes dependen de STP para la redundancia y la convergencia (lo que significa que hay uno o más puertos en estado STP de bloque en la topología) utilice UDLD en conjunto con las funciones y protocolos correspondientes. Dichas funciones incluyen FEFI, la negociación automática, la protección de bucle y demás. Generalmente, si la negociación automática está habilitada, no es necesario el modo agresivo ya que la negociación automática compensa para la detección de fallo en la Capa 1.

Ejecute una de estas opciones de comandos para habilitar UDLD:

Nota: La sintaxis ha cambiado a través de varias plataformas/versiones.

  • udld enable
    !--- Una vez habilitados globalmente, todos los puertos de fibra FE y GE
    tendrán UDLD habilitadas de forma predeterminada.
    udld port

    o

  • udld enable
    !--- Los puertos de cobre se algunas versiones anteriores del software Cisco IOS
    !--- pueden tener UDLD habilitada por un comando de puerto individual.

Debe habilitar manualmente los puertos que están cerrados por síntomas de enlaces unidireccionales. Utilice uno de estos métodos:

udld reset
!--- Reestablezca globalmente todas las interfaces UDLD cerradas.
no udld port
udld port [aggressive]
!--- Por interfaz, reestablezca y rehabilite las interfaces UDLD cerradas.

Los comandos errdisable recovery cause udld y errdisable recovery interval interval los comandos de configuración global pueden utilizarse para recuperar automáticamente desde el estado de desactivar error UDLD.

Cisco recomienda que sólo utilice el mecanismo de recuperación errdisable en la capa de acceso de la red, con temporizadores de recuperación de 20 minutos o más, si el acceso al switch es difícil. La mejor situación es no permitir el tiempo para la estabilización de la red y la resolución de problemas, antes de que el puerto vuelva a estar en línea y provoque la inestabilidad de la red.

Cisco recomienda que no utilice los mecanismos de recuperación en el núcleo de la red debido a que esto puede provocar inestabilidad que se relaciones con eventos de convergencia cada vez que se active un enlace fallido. El diseño de redundancia de una red de núcleo proporciona un trayecto de respaldo para un enlace fallido y da tiempo para una investigación acerca de los motivos de fallo de UDLD.

Utilice UDLD sin Protección de bucle STP

Para el punto a punto de Capa 3 o los enlaces de Capa en donde existe una topología STP sin bucles (ningún puerto bloqueando), Cisco recomienda que habilite UDLD agresivo en los enlaces punto a punto FE/GE entre los switches Cisco. En este caso, el el intervalo de mensaje se configura en siete segundos y el temporizador STP 802.1D predeterminado.

UDLD en EtherChannels

Ya sea que la protección de bucle STP esté desplegada, el modo UDLD agresivo se recomienda para cualquier configuración EtherChannel, junto con el modo de configuración deseado. En las configuraciones EtherChannel, un fallo en el enlace del canal que transporta el tráfico de control de las BPDU del árbol de expansión y PAgP puede provocar bucles inmediatos entre los socios del canal si el enlace del canal se desagrupa. El modo UDLD agresivo cierra un puerto fallido. PAgP (modo de canal auto/deseado) puede luego negociar un nuevo enlace de control y eliminar efectivamente un enlace fallido del canal.

UDLD with 802.1w Spanning Tree

Para impedir bucles al utilizar nuevas versiones de árbol de expansión, utilice el modo UDLD normal y la protección de bucle STP con RSTP como 802.1w. La UDLD puede proporcionar protección desde enlaces unidireccionales durante la fase de conexión y la protección de bucle STP puede impedir bucles STP en el caso que el enlace se vuelva unidireccional después de que UDLD haya establecido el enlace como bidireccional. Debido a que no puede configurar UDLD para que sea menor que los temporizador predeterminados 802.1w, la protección de bucle STP es necesaria para prevenir completamente los bucles en las topologías redundantes.

Consulte Introducción y configuración de la función del protocolo de detección de enlace unidireccional (UDLD) para más detalles.

Evaluar y supervisar UDLD

No es fácil evaluar UDLD sin un componente genuinamente defectuoso/unidireccional en el laboratorio, como GBIC defectuoso. El protocolo ha sido diseñado para detectar los escenarios de fallos menos comunes que aquellos escenarios que se utilizan generalmente en el laboratorio. Por ejemplo, si realiza una evaluación simple como la desconexión de un hilo de fibra para ver estado deseable errdisable, primero necesita apagar la negociación automática de la Capa 1. De lo contrario, el puerto físico queda fuera de servicio, lo cual reestablece la comunicación de mensaje UDLD. El final remoto se mueve al estado indeterminado en el modo UDLD normal y mueve el estado errdisable sólo con el uso del modo UDLD agresivo.

Un método adicional de evaluación simula la pérdida de PDU vecino para UDLD. El método es utilizar los filtros de capa MAC para bloquear la dirección de hardware UDLD/CDP mientras permite el paso de otras direcciones. Algunos switches no envían tramas UDLD cuando el puerto está configurado para ser un destino Analizador de puertos del switch (SPAN), que simula un vecino UDLD que no responde.

Para supervisar UDLD, utilice este comando:

show udld gigabitethernet1/1
Interface Gi1/1
---
Port enable administrative configuration setting: Enabled
Port enable operational state: Enabled
Current bidirectional state: Bidirectional
Current operational state: Advertisement - Single neighbor detected
Message interval: 7
Time out interval: 5

Además, desde el modo habilitado en el software Cisco IOS versión 12.2(18)SXD o switches posteriores, puede ejecutar el comando oculto show udld neighbor para verificar los contenidos de caché UDLD (de la manera en que CDP lo hace). Generalmente es muy útil la memoria caché UDLD para la memoria caché CDP para verificar si existe una anomalía específica del protocolo. Siempre que CDP también sea afectado, generalmente significa que todas las BPDU/PDU están afectadas. Por lo tanto, también verifique STP. Por ejemplo, verifique las modificaciones recientes de identidad o los cambios en la ubicación de los puertos raíz/designados.

Puede supervisar el estado UDLD y la consistencia en la configuración con el uso de las variables UDLD SNMP MIB de Cisco.

Conmutación de capas múltiple

Información general

En los software del sistema Cisco IOS, se soporta la conmutación de capas múltiples (MLS) en las series Catalyst 6500/6000. y sólo internamente. Esto significa que el router debe estar instalado en el switch. Los Supervisor Engines de Catalyst 6500/6000 más recientes soportan MLS CEF, donde la tabla de enrutamiento es descargada a cada tarjeta. Esto requiere hardware adicional, que incluye la presencia de una Tarjeta de reenvío distribuido (DFC). Las DFC no son soportadas en el software CatOS, aunque opte por utilizar el software Cisco IOS en la tarjeta del router. Las DFC sólo se soporta en el software del sistema Cisco IOS.

La memoria caché MLS utilizada par habilitar las estadísticas NetFlow en los switches Catalyst es la memoria caché basada en el flujo que la tarjeta del Supervisor Engine I y los switches Catalyst antiguos utilizan para habilitar la conmutación de la Capa 3. MLS está habilitado de manera predeterminada en el Supervisor Engine 1 (o Supervisor Engine 1A) con MSFC o MSFC2. No es necesaria una configuración MLS adicional para la funcionalidad de MLS de manera predeterminada. Puede configurar la memoria caché MLS en uno de los tres modos:

  • destino

  • origen y destino

  • origen y puerto de destino

La máscara de flujo se utiliza para determinar el modo MLS para el switch. Estos datos son utilizados posteriormente para habilitar los flujos de Capa 3 en el Supervisor Engine IA provisto por los switches Catalyst. Las hojas del Supervisor Engine II no utilizan la memoria caché MLS para conmutar paquetes debido a que esta tarjeta está habilitada con hardware CEF, lo cual representa una tecnología mucho más extensible. La memoria caché MLS se mantiene en la tarjeta Supervisor Engine II para habilitar la exportación estadística NetFlow únicamente. Por lo tanto, el Supervisor Engine II puede habilitarse para el flujo completo si fuera necesario, sin impactar negativamente en el switch.

Configuración

El tiempo de envejecimiento de MLS se aplica a todas las entradas de caché MLS. El valor del tiempo de envejecimiento se aplica directamente a la desactualización del modo de destino. Se divide el valor del tiempo de envejecimiento de MLS en dos para derivar el tiempo del modo de envejecimiento origen a destino. Divida el valor del tiempo de envejecimiento de MLS en ocho para encontrar el tiempo de envejecimiento del flujo completo. El valor del tiempo de envejecimiento de MLS predeterminado es de 256 segundos.

Puede configurar el tiempo de envejecimiento normal en el rango de 32 a 4092 segundos en incrementos de ocho segundos. Todo valor del tiempo de envejecimiento que no es múltiplo de ocho segundos se ajusta al múltiplo más cercano a 8 seg. Por ejemplo, un valor de 65 se ajusta a 64 y un valor de 127 se ajusta a 128.

Otros eventos pueden provocar la purga de las entradas de MLS. Dichos eventos incluyen:

  • Cambios de enrutamiento

  • Un cambio en el estado del enlace

    Por ejemplo, el enlace PFC está inactivo.

Para mantener el tamaño de la memoria caché MLS por debajo de 32.000 entradas, habilite estos parámetros después de ejecutar el comando mls aging:

Normal: configures the wait before aging out and deleting shortcut entries in
the L3 table.

Fast aging: configures an efficient process to age out entries created for flows that
only switch a few packets and then are never used again. The fast aging parameter uses
the time keyword value to check if at least the threshold keyword value of packets has
been switched for each flow. If a flow has not switched the threshold number of packets
during the time interval, then the entry in the L3 table is aged out.

Long: configures entries for deletion that have been up for the specified value even if
the L3 entry is in use. Long aging is used to prevent counter wraparound, which could
cause inaccurate statistics. 

Configuración

Una entrada típica de caché que se elimina es la entrada para los flujos en ambas direcciones a un Nombre del servidor DNS o servidor TFTP que posiblemente nunca sea utilizada nuevamente después que la entrada haya sido creada. La detección y el vencimiento de estas entradas ahorra espacio en la memoria caché MLS para otro tráfico de datos.

Si necesita habilitar el tiempo de envejecimiento rápido de MLS, configure el valor inicial a 128 seg. Si el tamaño de la memoria caché MLS continua creciendo por encima de las 32.000 entradas, disminuya la configuración hasta que el tamaño de la memoria caché se encuentre por debajo de 32.000. Si la memoria caché continua creciendo por encima de las 32.000 entradas, disminuya el tiempo de envejecimiento MLS normal.

Configuración de MLS recomendada por Cisco

Deje MLS al valor predeterminado, sólo el destino excepto que sea necesaria la exportación de NetFlow. Si se requiere NetFlow, habilite el flujo completo de MLS sólo en el sistema de Supervisor Engine II.

Ejecute este comando para habilitar el destino de flujo MLS:

Switch(config)#mls flow ip destination

Tramas gigantes

Fragmentación de la unidad máxima de transmisión

La Fragmentación de la unidad máxima de transmisión (MTU) es el datagrama o tamaño del paquete más grande en bytes que una interfaz puede enviar o recibir sin fragmentar el paquete.

Para la norma IEEE 802.3, el tamaño máximo de la trama Ethernet es:

  • 1518 bytes para las tramas regulares (1500 bytes más 18 bytes adicionales de encabezado Ethernet y cola CRC)

  • 1522 bytes para tramas encapsuladas 1Q (1518 más 4 bytes de etiquetado)

Baby Giants: La función Baby Giants permite al switch pasar/enviar paquetes que son ligeramente más grandes que IEEE Ethernet MTU, en lugar de declarar las tramas de tamaño excesivo y descartarlas.

Jumbo: La definición del tamaño de la trama depende del proveedor, ya los tamaños de las tramas no son parte de la norma IEEE. Las tramas Jumbo son tramas mayores que el tamaño de la trama Ethernet estándar (que es de 1518 bytes y que incluye el encabezado de Capa 2 y la secuencia de verificación de tramas [FCS]).

El tamaño predeterminado de MTU es de 9216 bytes después de habilitada la trama jumbo en el puerto individual.

Al esperar paquetes mayores que 1518 bytes

Para transportar el tráfico a través de redes conmutadas, asegúrese de que el tráfico transmitido MTU no exceda el soportado en las plataformas del switch. Existen varios motivos por los que el tamaño de MTU de ciertas tramas puede truncarse:

  • Requisitos específicos del vendedor. Las aplicaciones y determinados NIC pueden especificar un tamaño de MTU que se encuentre fuera de los 1500 bytes estándar. Esta cambio ha ocurrido debido a los estudios que prueban que un incremento en el tamaño de la trama Ethernet puede incrementar el desempeño promedio.

  • Conexión troncal. Para transportar información VLAN ID entre switches u otros dispositivos de red, la conexión troncal ha sido empleada para aumentar la trama Ethernet estándar. Hoy, las dos formas más comunes de conexiones troncales son:

    • Encapsulación ISL propiedad de Cisco

    • 802.1Q

  • Multiprotocol Label Switching (MPLS). Después de habilitar MPLS en una interfaz, MPLS tiene el potencial para aumentar el tamaño de la trama de un paquete, que depende del número de etiquetas en la pila de etiquetas para un paquete con etiqueta MPLS. El tamaño total de una etiqueta es de 4 bytes. El tamaño total de una pila de etiquetas es:

    n * 4 bytes

    Si se forma una pila de etiquetas, es posible que las tramas excedan la MTU.

  • Tunelización 802.1Q. Los paquetes de tunelización 802.1Q contienen dos etiquetas 802.1Q, de los cuales sólo uno a la vez es visible generalmente para el hardware. Por consiguiente, la etiqueta interna agrega 4 bytes al valor de MTU (tamaño de carga útil).

  • Interfaz de transporte universal (UTI)/Protocolo de tunelización de Capa 2 versión 3 (Layer 2TPv3). UTI/la Capa 2TPv3 encapsula los datos de la Capa 2 para que se envíen a través de la red IP. UTI/Capa 2TPv3 puede aumentar el tamaño original de la trama por hasta 50 bytes. La nueva trama incluye un nuevo encabezado IP (20 bytes), encabezado de Capa 2TPv3 (12 bytes) y un nuevo encabezado de Capa 2. La carga útil de Capa 2TPv3 consiste en la trama de Capa 2 completa, que incluye el encabezado de Capa 2.

Propósito

Los switches basados en el hardware de alta velocidad (1 Gbps y 10 Gbps) han hecho de las tramas jumbo una solución concreta para los problemas de desempeño subóptimo. Aun no existen normas oficiales para el tamaño de las tramas jumbo, un valor común que se adopta con frecuencia es 9216 bytes (9 KB).

Consideración sobre la eficiencia de las redes

Puede calcular la eficiencia de la red para envío de paquetes si divide el tamaño de la carga útil por la suma del valor de sobrecarga y el tamaño de la carga útil.

Aunque la eficiencia de la red aumenta con las tramas jumbo es sólo moderada, y va desde 94,9 por ciento (1500 bytes) a 99,1 por ciento (9216 bytes), la sobrecarga de proceso (utilización de CPU) de los dispositivos de red y los host finales disminuye proporcionalmente al tamaño del paquete. Este es el motivo por el cual las tecnologías de red LAN y WAN de alto desempeño tienden a preferir tamaños de tramas máximas más grandes.

La mejora en el desempeño sólo es posible cuando se realizan las largas transferencias de datos. Las aplicaciones de ejemplos incluyen:

  • Comunicación de servidores adosados (por ejemplo, transacciones de Sistema de archivos de red [NFS]

  • Agrupación de servidores

  • Respaldo de datos de alta velocidad

  • Interconexión de supercomputadora de alta velocidad

  • Transferencias de datos de aplicaciones gráficas

Consideración del desempeño de red

El desempeño de TCP sobre WAN (Internet) han sido estudiadas en profundidad. Esta ecuación explica cómo el desempeño de TCP tiene un límite superior basada en:

  • El tamaño del segmento máximo (MSS), que es la longitud de MTU menos la longitud de los encabezados TCP/IP

  • Tiempo de viaje de ida y vuelta (RTT)

  • La pérdida del paquete

185-s.gif

De acuerdo a esta fórmula, el máximo desempeño TCP alcanzable es directamente proporcional a MSS. Esto significa que, con RTT constante y la pérdida de paquetes puede duplicar el desempeño TCP si duplica el tamaño del paquete. Del mismo modo, cuando utiliza tramas jumbo en lugar de tramas 1518 byte, un aumento de seis veces el tamaño brinda una mejora potencial de seis veces en el desempeño TCP de una conexión Ethernet.

Información operativa general

La especificación de la norma IEEE 802.3 define el tamaño de trama Ethernet máxima de 1518. Las tramas de encapsulación 802.1Q, con una longitud de entre 1519 y 1522 bytes, se agregaron a la especificación 802.3 en una etapa posterior a través del apéndice de IEEE Std 802.3ac-1998. A veces son denominadas en la literatura como baby giants.

En general, los paquetes se clasifican como tramas gigantes cuando exceden la longitud máxima Ethernet especificada para una conexión Ethernet específica. Los paquetes Giant también son conocidos como tramas jumbo.

El punto más importante de confusión acerca de las tramas jumbo es la configuración: diferentes interfaces soportan diferentes tamaños máximos de paquetes y, a veces, tratan los grandes paquetes de diferentes maneras.

Catalyst serie 6500

Esta tabla trata de resumir los tamaños MTU actualmente soportados por diferentes tarjetas en la plataforma Catalyst 6500:

Tarjeta de línea

Tamaño de MTU

Valor predeterminado

9216 bytes

WS-X6248-RJ-45, WS-X6248A-RJ-45, WS-X6248-TEL, WS-X6248A-TEL, WS-X6348-RJ-45, WS-X6348-RJ45V, WS-X6348-RJ-21 y WX-X6348-RJ21V

8092 bytes (limitado por el chip PHY)

WS-X6148-RJ-45(V), WS-X6148-RJ-21(V), WS-X6148-45AF y WS-X6148-21AF

9100 bytes (a 100 Mbps)

9216 bytes (a 10 Mbps)

WS-X6516-GE-TX

8092 bytes (a 100 Mbps)

9216 bytes (a 10 o 1000 Mbps)

WS-X6148(V)-GE-TX, WS-X6148-GE-45AF, WS-X6548(V)-GE-TX y WS-X6548-GE-45AF

1500 bytes

OSM ATM (OC12c)

9180 bytes

OSM CHOC3, CHOC12, CHOC48 y CT3

9216 bytes (OCx y DS3)

7673 bytes [T1, E1]

FlexWAN

7673 bytes (CT3 T1/DS0)

9216 bytes [OC3c POS]

7673 bytes (T1)

WS-X6148-GE-TX y WS-X6548-GE-TX

Sin soporte

Consulte Configuración de la conmutación Ethernet, Fast Ethernet, Gigabit Ethernet y 10-Gigabit Ethernet para obtener más información.

Soporte de Capa 2 y Capa 3 Jumbo en el software Cisco IOS de Catalyst 6500/6000

Existe soporte de Capa 2 y Capa 3 jumbo con PFC/MSFC1, PFC/MSFC2, y PFC2/MSFC2 en todos los puertos GE que están configuradas como interfaces físicas de Capa 2 y Capa 3. El soporte existe independientemente de si estos puertos son troncales o de canalización. Esta función se encuentra disponible en el software Cisco IOS versión 12.1.1E posteriores.

  • Los tamaños de MTU de todos los puertos físicos habilitados jumbo están unidos. Un cambio en uno de ellos cambia todos los demás. Siempre conservan el mismo tamaño de trama jumbo de MTU después de ser habilitados.

  • Durante la configuración, puede habilitar todos los puertos en la misma VLAN como jumbo habilitados o no habilitar ninguno de ellos como jumbo habilitados.

  • El tamaño de MTU de la interfaz virtual conmutada (SVI) (Interfaz VLAN) se establece separadamente de los puertos físicos MTU. Un cambio en los puertos físicos MTU no cambia el tamaño SVI MTU. Además, un cambio en SVI MTU no afecta los puertos físicos MTU.

  • Las tramas jumbo de Capa 2 y Capa 3 soportadas en interfaces FE comienzan en el software Cisco IOS versión 12.1(8a)EX01. El comando mtu 1500 deshabilita jumbo en FE y el comando mtu 9216 habilita jumbo en FE. Consulte la ID de error de Cisco CSCdv90450 (solamente clientes registrados).

  • Las tramas jumbo de Capa 3 en interfaces VLAN se soportan sólo en:

    • PFC/MSFC2 (software Cisco IOS versión 12.1(7a)E y posteriores).

    • PFC2/MSFC2 (software Cisco IOS versión 12.1(8a)E4 y posteriores).

  • No se recomienda el uso de tramas jumbo con PFC/MSFC1 para interfaces VLAN (SVIs) debido a que MSFC1 posiblemente no pueda manejar la fragmentación como se desea.

  • No se soporta la fragmentación para paquetes dentro de la misma VLAN (Capa 2 jumbo).

  • Los paquetes que necesitan fragmentación a través de VLAN/subredes (Capa 3 jumbo) son enviados al software para la fragmentación.

Introducción al Soporte de Tramas Jumbo en el software Cisco IOS de Catalyst 6500/6000

Una trama jumbo es una trama más grande que el tamaño de la trama Ethernet predeterminada. Para habilitar el soporte de tramas jumbo, puede configurar un tamaño de MTU mayor que el predeterminado o una interfaz VLAN y con el software Cisco IOS versión 12.1(13)E y posterior, configure el tamaño de la LAN global del puerto MTU.

Bridged and Routed Traffic Size Check in Cisco IOS (Verificación del tamaño del tráfico enrutado y conectado en el software Cisco IOS)

Tarjeta de línea

Acceso

Egreso

10-, 10/100-, puertos 100-Mbps

La verificación del tamaño MTU fue realizada.

El soporte de tramas Jumbo compara el tamaño del tráfico que ingresa con el tamaño de la LAN global de puerto MTU al ingreso 10-, 10/100-, y 100-Mbps Ethernet y los puertos 10-GE LAN que poseen un tamaño MTU no predeterminado configurado. No se realizó el tráfico de puertos excesivo en

La verificación del tamaño MTU.

Los puertos configurados con un tamaño MTU no predeterminado transmiten tramas que contienen paquetes de cualquier tamaño mayores de 64 bytes. Con un tamaño MTU no predeterminado configurado, los puertos Ethernet LAN 10-, 10/100-, y 100-Mbps no verifican las tramas de salida excesivas.

No se ha realizado la verificación del tamaño

MTU de los puertos GE.

Los puertos configurados con un tamaño MTU no predeterminado aceptan tramas que contienen paquetes de cualquier tamaño mayores de 64 bytes y no verifican las tramas de ingreso excesivas.

Se realizó la verificación del tamaño MTU.

El soporte de tramas Jumbo compara el tamaño del tráfico de salida con el tamaño MTU del puerto LAN de salida en la salida GE y puertos LAN 10-GE que poseen un tamaño MTU no predeterminado configurado. El tráfico de puerto es excesivo.

Puertos 10-GE

Se realizó la verificación del tamaño MTU.

El tráfico de puerto es excesivo.

Se realizó la verificación del tamaño MTU.

El tráfico de puerto es excesivo.

SVI

No se ha realizado la verificación del tamaño MTU.

La SVI no verifica el tamaño de tramas en el lado de ingreso.

Se realizó la verificación del tamaño MTU.

El tamaño MTU está verificado en el lado de salida de la SVI.

 

PFC

Todo el tráfico enrutado

Para el tráfico que debe estar enrutado, el soporte de tramas jumbo en PFC compara el tamaño del tráfico con el tamaño MTU configurado y proporciona la conmutación de Capa 3 para el tráfico jumbo entre interfaces configuradas con tamaños MTU que son lo suficientemente grandes para acomodar el tráfico.

Entre las interfaces que no están configuradas con tamaños MTU lo suficientemente grandes:

  • Si el bit Don't Fragment (DF) no está configurado, el PFC envía el tráfico al MSFC para fragmentarlo y enrutarlo en el software.

  • Si el bit DF se configura, el PFC deja caer el tráfico.

Recomendaciones de Cisco

Si se implementan correctamente, las tramas jumbo pueden proporcionar una mejora potencial seis veces en el desempeño TCP de una conexión Ethernet, con fragmentación reducida excesiva (más menos tara de la CPU en los dispositivos finales).

Debe asegurarse de que no existe un dispositivo intermedio que no pueda manejar el tamaño MTU especificado. Si este dispositivo fragmenta y reenvía los paquetes, se anulará el proceso completo. Esto puede resultar en una sobrecarga agregada en este dispositivo para la fragmentación y el reensamblado de los paquetes.

En esos casos, el descubrimiento de MATU del trayecto IP ayuda a los remitentes a encontrar la longitud mínima del paquete común apropiada para transmitir tráfico a través de cada trayecto. De manera alternativa, puede configurar los dispositivos de host aptos para tramas jumbo con un tamaño MTU mínimo de todos los que se soportan en la red.

Debe verificar cuidadosamente cada dispositivo para asegurarse de poder soportar el tamaño MTU. Consulte la tabla del soporte de tamaño MTU en esta sección.

Las tramas Jumbo puede habilitarse en estos tipos de interfaces:

  • interfaz de canal de puerto

  • SVI

  • Interfaz física (Capa 2/ Capa 3)

Puede habilitar las tramas jumbo en el canal de puerto o en la interfaz física que participa en el canal de puerto. Es muy importante asegurarse de que el MTU en la interfaz física sea el mismo. De no ser así, puede producirse una interfaz suspendida. Debe cambiar la MTU de una interfaz de canal de puerto ya que se modifica la MTU de todos los puertos miembro.

Nota: Si la MTU de un puerto miembro no puede cambiarse al nuevo valor debido a que el puerto miembro es el puerto de bloqueo, se suspende el canal de puerto.

Siempre asegúrese de que todas las interfaces físicas en una VLAN estén configuradas para tramas jumbo antes de configurar el soporte en una SVI. La MTU de un paquete no se verifica en el lado de ingreso de una SVI. Sin embargo, si se verifica en el lado de salida de un SVI. Si un paquete MTU es mayor que la SVI MTU de salida, el paquete es fragmentado por el software (si el bit DF no está configurado), lo que resulta en un mal desempeño. La fragmentación del software sólo tiene lugar en la conmutación de Capa 3. Cuando se envía un paquete a un puerto de Capa 3 o una SVI con una MTU menor, se produce la fragmentación de software.

La MTU de una SVI siempre debe ser menor que la más pequeña de las MTU entre todos los puertos del switch en la VLAN.

Catalyst serie 4500

Las tramas jumbo están soportadas principalmente en los puertos no bloqueadores de tarjetas de línea Catalyst 4500 Estos puertos GE no bloqueadores poseen una conexión directa con los recurso físico de conmutación de Supervisor Engine y soporta tramas jumbo:

  • Supervisor Engines

    • WS-X4515, WS-X4516: dos puertos GBIC de enlace ascendente en Supervisor Engine IV o V

    • WS-X4516-10GE: dos enlaces ascendentes 10-GE y los cuatro enlaces ascendentes 1-GE de módulo extraíble de forma pequeña (SFP)

    • WS-X4013+: dos enlaces ascendentes 1-GE

    • WS-X4013+10GE: dos enlaces ascendentes 10-GE y los cuatro enlaces ascendentes 1-GE SFP

    • WS-X4013+TS: 20 puertos 1-GE

  • Tarjetas de línea

    • WS-X4306-GB: seis puertos 1000BASE-X (GBIC) módulo GE

    • WS-X4506-GB-T: seis puertos 10/100/1000-Mbps y seis puertos SFP

    • WS-X4302-GB dos puertos 1000BASE-X (GBIC) módulo GE

    • Los primeros dos puertos GBIC de un módulo GE de conmutación de servidor de 18 puertos (WS-X4418-GB) y puertos GBIC del módulo WS-X4232-GB-RJ

  • Switches de configuración fija

    • WS-C4948: todos los 48 puertos 1-GE

    • WS-C4948-10GE: todos los 48 puertos 1-GE y dos puertos 10-GE

Puede utilizar estos puertos GE no bloqueadores para soportar tramas jumbo 9-KB o la supresión de la difusión de software (Supervisor Engine IV únicamente). Todas las demás tarjetas de línea soportan tramas baby giant. Puede utilizar baby giants para la conexión en bridge de MPLS o para traspaso Q en Q con carga útil máxima de 1552 bytes.

Nota: El tamaño de la tramas aumenta con las etiquetas ISL/802.1Q.

Baby giants y las tramas jumbo son transparentes para otras funciones del Cisco IOS con Supervisor Engine IV y V.

Funciones de seguridad del software Cisco IOS

Funciones de seguridad básicas

En una época, la seguridad generalmente se ignoraba en los diseños de campus. Sin embargo, ahora la seguridad es una parte esencial de cada red para empresas. Normalmente, el cliente ha establecido una política de seguridad para ayudar a definir qué herramientas y tecnologías de Cisco son aplicables. Consulte Nociones fundamentales sobre ISP de Ciscoleavingcisco.com para más información en Nociones esenciales del software Cisco IOS, que incluyen la seguridad del software Cisco IOS.

Protección de contraseña básica

La mayoría de los dispositivos del software Cisco IOS están configurados con dos niveles de contraseñas. El primer nivel es para el acceso Telnet al dispositivo, que también es conocido como el acceso vty. Después de que el acceso vty fue otorgado, debe obtener el acceso a modo habilitado o el modo EXEC privilegiado.

Asegure el modo habilitado en el switch

La habilitación de contraseña permite al usuario ganar acceso completo al dispositivo. Proporcione la habilitación de contraseña sólo a gente de confianza.

Switch(config)#enable secret password

Asegúrese de que la contraseña obedezca estas reglas:

  • La contraseña debe contener entre uno y 25 caracteres numéricos en mayúscula y minúscula.

  • La contraseña no debe contener un número como primer carácter.

  • Se pueden utilizar los espacios entre líneas, pero serán ignorados No se reconocen el espacio intermedio ni el seguido.

  • La verificación de la contraseña diferencia entre mayúscula y minúscula. Por ejemplo, la contraseña Secreta es distinta de la contraseña secreta.

Nota: El comando enable secret utiliza la función de hash de Message Digest 5 (MD5) criptográfico. Si ejecuta el comando show running-config podrá ver esta contraseña cifrada. El uso del comando enable password es otra forma de configurar la habilitación de contraseña. Sin embargo, el algoritmo cifrado utilizado con el comando enable password es débil y puede ser invertido para obtener la contraseña. Por consiguiente, no utilice el comando enable password Utilice el comando enable secret para una mejor seguridad: Consulte Aspectos del cifrado de contraseña de IOS de Cisco para más información.

Asegure el acceso Telnet/VTY al switch

De manera predeterminada, el software Cisco IOS soporta cinco sesiones Telnet activas. Las sesiones son denominadas vty 0 a 4. Puede habilitar estas líneas para la consola. Pero para habilitar la sesión, debe además configurar la contraseña para estas líneas.

Switch(config)#line vty 0 4
Switch(config-line)#login
Switch(config-line)#password password

El comando login configura estas líneas para el acceso Telnet. El comando password configura una contraseña. Asegúrese de que la contraseña obedezca estas reglas:

  • El primer carácter no puede ser un número.

  • La cadena puede contener cualquier carácter alfanumérico, hasta 80 caracteres. El carácter incluye los espacios.

  • No puede especificar la contraseña en el formato número-espacio-carácter. Este espacio después del carácter causa problemas. Por ejemplo, hola 21 es una contraseña legal,. pero 21 hola no es una contraseña legal.

  • La verificación de la contraseña diferencia entre mayúscula y minúscula. Por ejemplo, la contraseña Secreta es distinta de la contraseña secreta.

Nota: Con esta configuración de línea vty, el switch almacena la contraseña en texto sin cifrar. Si alguien ejecuta el comando show running-config la contraseña será visible. Parea evitar esta situación, utilice el comando service password-encryption. El comando tranquilamente cifra la contraseña. El comando sólo cifra la contraseña de línea vty y la habilitación de contraseña configurada con el comando enable password. La habilitación de contraseña configurada con el comando enable secret utiliza un cifrado más fuerte. La configuración con el comando enable secret es el método recomendado.

Nota: Para tener más flexibilidad en la administración de la seguridad, asegúrese de que todos los dispositivos del software Cisco IOS implementen el modelo de seguridad de autenticación, autorización y contabilidad (AAA). AAA puede utilizar local, RADIUS, y bases de datos TACACS+. Consulte la sección de configuración de Autenticación TACACS+ para obtener más información.

Cambie la oración anterior a como estaba.

Soluciones para la seguridad de AAA

Información general sobre el funcionamiento de AAA

Los controles de control de acceso tienen permiso para acceder al switch y los servicios que pueden utilizar los usuarios. Los servicios de seguridad de red AAA proporcionan el marco primario para establecer control de acceso en su switch.

Esta sección describe varios aspectos de AAA en detalle:

  • Autenticación. Este proceso valida la identidad solicitada de un usuario o dispositivo final. Primero, los métodos varios pueden usarse para autenticar los usuarios especificados. Estos métodos definen el tipo de autenticación para realizar (por ejemplo, TACACS+ o RADIUS). También se define la secuencia en la cual se intentan estos métodos de autenticación. Los métodos se aplican luego a las interfaces correspondientes, que activan la autenticación.

  • Autorización. Este proceso otorga los derechos de acceso a un usuario, grupo de usuarios, sistema o proceso. El proceso AAA puede realizar una autorización única o una autorización por tarea. El proceso define los atributos (en el servidor AAA) que el usuario puede cumplir. Siempre que el usuario inicie un servicio, el switch consulta al servidor AAA y solicita permiso para autorizar al usuario. Si el servidor AAA lo aprueba, el usuario estará autorizado. Si el servidor AAA no lo aprueba, el usuario no obtendrá el permiso para ejecutar el servicio. Puede usar este proceso para especificar que algunos usuarios pueden ejecutar ciertos comandos.

  • Contabilidad. Este proceso le permite rastrear el servicio al que han accedido los usuarios y la cantidad de recursos de red que consume los usuarios. Cuando la contabilidad se encuentra habilitada, el switch informa la actividad del usuario al servidor AAA en forma de registros contables. Los ejemplos registrados de la actividad de los usuarios incluye el tiempo de sesión y el tiempo de inicio y detención. Luego, el análisis de esta actividad puede tener lugar para fines administrativos o de facturación.

A pesar que AAA es el método primario y recomendado para el control de acceso, el software Cisco IOS proporciona funciones para el control de acceso simple que está fuera del alcance de este AAA. Las funciones adicionales incluyen:

  • Autenticación del nombre de usuario local

  • Autenticación de contraseñas de línea

  • Autenticación para habilitar contraseñas

Pero estas funciones no proporcionan el mismo grado de control de acceso posible con AAA.

Para entender mejor AAA, consulte estos documentos:

Estos documentos no necesariamente mencionan los switches. Pero los conceptos AAA que describen los documentos se aplican a los switches.

TACACS+

Propósito

De manera predeterminada, las contraseñas de modo no privilegiado y privilegiado son globales. Estas contraseñas se aplican a cada usuario que accede al switch o router, desde el puerto de la consola o a través de la sesión Telnet a través de la red. La implementación de estas contraseñas en los dispositivos de red consume mucho tiempo y no están centralizadas. Además, puede tener dificultades con la implementación de las restricciones de acceso con el uso de las listas de control de acceso (ACL) que pueden ser propensas a errores de configuración. Para superar estos problemas, tome un método centralizado cuando configure los nombres de usuarios, contraseñas y políticas de acceso en un servidor central. Este servidor puede ser el Servidor de Control de Acceso Seguro de Cisco (ACS) o cualquier servidor de terceros. Los dispositivos se configuran para utilizar esta base de datos centralizada para las funciones AAA. En este caso, los dispositivos son switches del software Cisco IOS. El protocolo utilizado entre los dispositivos y el servidor central puede ser:

  • TACACS+

  • RADIUS

  • Kerberos

TACACS+ es una implementación común en las redes de Cisco y es el aspecto central de esta sección. TACACS+ proporciona estas funciones:

  • Autenticación. El proceso que identifica y verifica a un usuario. Pueden utilizarse varios métodos para autenticar a un usuario. Pero el método más común incluye una combinación de nombre de usuario y contraseña.

  • Autorización. Cuando el usuario intenta ejecutar un comando, el switch puede verificar el servidor TACACS+ para determinar si el usuario recibió permiso para utilizar ese comando en particular.

  • Contabilidad. Este proceso registra lo que hace o ha hecho un usuario en un dispositivo.

Consulte Comparación de TACACS+ y RADIUS para una comparación entre TACACS+ y RADIUS.

Información operativa general

El protocolo TACACS+ envía nombres de usuarios y contraseñas al servidor centralizado. La información se encuentra cifrada en la red con el hash unidireccional MD5. Consulte RFC 1321leavingcisco.com para obtener más información. TACACS+ utiliza el puerto 49 TCP como protocolo de transporte que ofrece estas ventajas en UDP:

Nota: RADIUS utiliza UDP.

  • Transporte orientado a la conexión

  • Reconocimiento separado de que se ha recibido un pedido (reconocimiento TCP [ACK]), independientemente de cómo sea el mecanismo de autenticación del final posterior cargado

  • Indicación inmediata de la caída de un servidor (reestablecer paquetes [RST])

Durante una sesión, si se necesita la autorización adicional, el switch verifica con TACACS+ para determinar si el usuario recibió permiso para utilizar un comando en particular. Este paso proporciona mayor control sobre los comandos que pueden ejecutarse en el switch y proporciona la desconexión por el mecanismo de autenticación. Con el uso del comando de contabilidad, puede revisar los comandos que un usuario en particular haya ejecutado mientras el usuario está conectado a un dispositivo de red en particular.

El diagrama muestra el proceso de autorización involucrado:

185-d.gif

Cuando un usuario se autentica en un dispositivo de red con el uso de TACACS+ en un simple intento de inicio de sesión ASCII, generalmente ocurre este proceso:

  • Una vez establecida la conexión, el switch contacta al daemon de TACACS+ para obtener un mensaje de pedido de nombre de usuario. El switch luego muestra el mensaje de pedido para el usuario. El usuario ingresa un nombre de usuario y el switch contacta al daemon de TACACS+ para obtener un mensaje de pedido de contraseña. El switch muestra el el mensaje de pedido de contraseña para el usuario, que ingresa una contraseña que también se envía al daemon de TACACS+.

  • El dispositivo de red recibirá eventualmente una de estas respuestas del daemon de TACACS+:

    • ACCEPT: se autentica al usuario y puede comenzar el servicio. Si el dispositivo de red se configura para que solicite autorización, en este momento comienza la autorización.

    • REJECT: no se ha podido autenticar al usuario. Se le ha negado el acceso al usuario o se le ha pedido que intente nuevamente la secuencia de inicio de sesión. El resultado depende del daemon de TACACS+.

    • ERROR: se ha producido un error durante la autenticación. El error puede estar en el daemon o en la conexión de la red entre el daemon y el switch. Si se recibe una respuesta de ERROR, el dispositivo de red generalmente trata de usar un método alternativo para autenticar el usuario.

    • CONTINUE: se le pide al usuario información de autenticación adicional.

  • Los usuarios primero deben realizar correctamente la autenticación TACACS+ antes de continuar con la autenticación TACACS+.

  • Si se solicita la autorización de TACACS+ , el daemon de TACACS+ será nuevamente contactado. El daemon de TACACS+ vuelve una respuesta de autorización ACCEPT o REJECT. Si se devuelve una respuesta ACCEPT , la respuesta contiene datos en forma de atributos utilizados para dirigir la sesión EXEC o NETWORK del usuario. Esto determina qué comando puede acceder el usuario.

Pasos de configuración AAA básica

La configuración de AAA es relativamente simple después de entender el proceso básico. Para configurar la seguridad en un router o servidor de acceso Cisco con el uso de AAA, siga estos pasos:

  1. Para habilitar AAA, ejecute el comando aaa new-model de configuración global.

    Switch(config)#aaa new-model

    Recomendación: Guarde su configuración antes de configurar los comandos AAA. Guarde la configuración nuevamente sólo después de haber completado todas sus configuraciones AAA y se haya asegurado que las mismas funcionan correctamente. Luego, puede recargar el switch para recuperar el bloqueo imprevisto (antes de guardar la configuración), si fuera necesario.

  2. Si decide utilizar un servidor de seguridad aparte, configure los parámetros del protocolo de seguridad como RADIUS, TACACS+, o Kerberos.

  3. Use el comando aaa authentication para definir la lista de métodos para autenticación.

  4. Use el comando login authentication para aplicar la lista de método para una interfaz o línea en particular.

  5. Ejecute el comando opcional aaa authorization para configurar la autorización.

  6. Ejecute el comando opcional aaa accounting para configurar la contabilidad.

  7. Configure el servidor externo AAA para procesar los pedidos de autenticación y autorización desde el switch.

    Nota: Consulte la documentación del servidor AAA para más información.

Configuración de autenticación TACACS+

Siga estos pasos para configurar la autenticación TACACS+

  1. Ejecute el comando aaa new-model en el modo de configuración global para habilitar AAA en el switch.

  2. Defina el servidor TACACS+ y la clave asociada.

    Esta clave se utiliza para cifrar el tráfico entre el servidor TACACS+ y el switch. En el comando tacacs-server host 1.1.1.1 key mysecretkey, el servidor TACACS+ se encuentra en la dirección IP 1.1.1.1, y la clave de cifrado es mysecretkey. Para verificar que el switch puede alcanzar el servidor TACACS+, inicie un Protocolo de Mensaje de Control de Internet (ICMP) emitiendo un ping desde el switch.

  3. Defina una lista de métodos.

    Una lista de métodos define la secuencia de mecanismos de actualización para intentar diferentes servicios. Los diferentes servicios pueden ser, por ejemplo:

    • Habilitar

    • Inicio de sesión (para vty/acceso Telnet)

      Nota: Consulte la sección Funciones de seguridad básica de este documento para más información acerca de vty/acceso Telnet.

    • Consola

    Este ejemplo considera el inicio de sesión únicamente. Debe aplicar la lista de método para las interfaces/línea:

    Switch(config)#aaa authentication login METHOD-LIST-LOGIN group tacacs+ line
    Switch(config)#line vty 0 4
    Switch(config-line)#login authentication METHOD-LIST-LOGIN
    Switch(config-line)#password hard_to_guess

    En esta configuración, el comando aaa authentication login utiliza el nombre de lista adoptado METHOD-LIST-LOGIN y utiliza el método tacacs+ antes de utilizar la línea de métodos. Los usuarios se autentican con el uso del servidor TACACS+ como primer método. Si el servidor TACACS+ no responde o envía un mensaje de ERROR, la contraseña configurada en la línea es utilizada como segundo método. Pero si el servidor TACACS+ deniega al usuario y responde con el mensaje REJECT, AAA considera la transacción exitosa y no utiliza el segundo método.

    Nota: La configuración no se completa hasta que aplique la lista (METHOD-LIST-LOGIN) para la línea vty. Ejecute el comando login authentication METHOD-LIST-LOGIN en el modo de configuración de línea, como se muestra en este ejemplo.

    Nota: El ejemplo crea una entrada posterior para cuando el servidor TACACS+ no se encuentra disponible. Los administradores de seguridad pueden o posiblemente no pueden aceptar la implementación de una entrada posterior. Asegúrese de que la decisión de implementar dichas entradas posteriores cumplan con las políticas de seguridad del sitio.

Configuración de autenticación RADIUS

La configuración RADIUS es casi idéntica a la configuración TACACS+. Simplemente sustituya la palabra RADIUS por TACACS en la configuración. Esta es una configuración RADIUS de muestra para el puerto de acceso COM:

Switch(config)#aaa new-model
Switch(config)#radius-server host 1.1.1.1 key mysecretkey
Switch(config)#aaa authentication login METHOD-LIST-LOGIN group radius line
Switch(config)#line con 0
Switch(config-line)#login authentication METHOD-LIST-LOGIN
Switch(config-line)#password hard_to_guess

Mensajes de registro

Cree anuncios de dispositivos apropiados que indiquen específicamente las acciones del acceso no autorizado. No anuncie el nombre del sitio ni la información de la red a usuarios no autorizados. Los anuncios proporcionan recursos en caso que un dispositivo esté comprometido y se atrape un culpable. Ejecute el siguiente comando para crear anuncios de inicio de sesión:

Switch(config)#banner motd ^C
*** Unauthorized Access Prohibited ***
^C

Seguridad física

Asegure la autorización correspondiente para acceder físicamente a los dispositivos de acceso. Mantenga el equipo en un lugar controlado (cerrado). Para garantizar que el equipo siga funcionando y no sea afectado por una mala manipulación o por factores ambientales, asegúrese de que todos los equipos tengan:

  • Un Suministro de Energía Ininterrumpido (UPS), con fuentes redundantes donde sea posible

  • Control de temperatura (aire acondicionado)

Recuerde que si una persona de intención maliciosa accede físicamente, habrá más probabilidad de interrupción a través de la recuperación de contraseña u otro medio.

Configuración de la administración

Diagramas de la red

Propósito

Los diagramas de redes limpios son fundamentales en el funcionamiento de las redes. El diagrama se torna crucial durante la resolución de problemas y es el vehículo más importante para la comunicación de información durante el incremento de vendedores y socios durante una interrupción. No subestime la preparación, disponibilidad y accesibilidad proporcionada por los diagramas de red.

Recomendación

Son necesarios estos tres tipos de diagramas:

  • Diagrama general. Incluso para las redes más grandes, es importante un diagrama que muestra la conectividad lógica o física extremo a extremo. A menudo, las empresas que han implementado un diseño jerárquico documentan cada capa por separado. Cuando planea y soluciona un problema, lo que importa es conocer cómo se conectan los dominios.

  • Diagrama físico. Este diagrama muestra todo el hardware y el cableado del switch y del router. Augúrese que los diagramas designen cada uno de estos aspectos:

    • Troncales

    • Enlaces

    • Velocidades

    • Grupos de canales

    • Números de puerto

    • Ranuras

    • Tipos de chasis

    • Software

    • Dominios VTP

    • bridge raíz

    • Prioridad de bridge raíz de respaldo

    • Dirección MAC

    • Puertos bloqueados por VLAN

    Para una mayor claridad, muestra dispositivos internos como el router Catalyst 6500/6000 MSFC como un router en un palillo conectado a través de una conexión troncal.

  • Diagrama lógico. Este diagrama muestra sólo la funcionalidad de Capa 3 lo que significa que muestra a los routers como objetos y VLAN como segmentos Ethernet. Asegúrese de que los diagramas designen cada uno de estos aspectos:

    • Direcciones de IP

    • Subredes

    • Direccionamiento secundario

    • HSRP activo y en espera

    • Capa de acceso de núcleo/distribución

    • Información de enrutamiento

185-e.gif

Interfaz de administración y VLAN nativa del switch

Propósito

Esta sección describe la importancia y potenciales problemas del uso de la VLAN 1 predeterminada. Esta sección cubre los problemas potenciales cuando se ejecuta el tráfico de administración al switch en la misma VLAN que el tráfico del usuario en las series de switches 6500/6000.

Los procesadores en los Supervisor Engines y MSFC para la serie Catalyst utiliza VLAN 1 para un número de protocolos de control y administración. Algunos ejemplos incluyen:

  • Protocolos de control de switches:

    • STP BPDU

    • VTP

    • DTP

    • CDP

  • Protocolo de administración:

    • SNMP (Protocolo de administración simple de red)

    • Telnet

    • SSH (Protocolo de Secure Shell)

    • Syslog

Cuando la VLAN se usa de esta manera, se la denomina VLAN nativa. La configuración del switch establece la VLAN 1 como la VLAN nativa predeterminada en los puertos troncales Catalyst. Puede dejar la VLAN 1 como la VLAN nativa. Pero tenga en cuenta que cualquier switch que ejecute el software del sistema Cisco IOS en su red establece todas las interfaces configuradas como puertos del switches de Capa 2 a puertos de acceso en VLAN 1 de manera predeterminada. Lo más probable es que un switch en cualquier parte de la red utilice VLAN 1 como una VLAN para el tráfico de usuarios.

La principal preocupación con el uso de VLAN 1 es que, en general, el Supervisor Engine NMP no necesita ser interrumpido por la mayor parte de la difusión y el tráfico de multidifusión generados por las estaciones finales. Las aplicaciones de multidifusión en particular tienden a enviar una gran cantidad de datos entre servidores y clientes. El Supervisor Engine no necesita ver estos datos. Si los recursos o búferes del Supervisor Engine están completamente ocupados mientras el Supervisor Engine escucha el tráfico innecesario, es posible que el Supervisor Engine no vea los paquetes de administración que pueden provocar un bucle de árbol de expansión o fallo EtherChannel (en el peor de los casos).

El comando show interfaces interface_type slot/port counters y el comando show ip traffic pueden darle alguna indicación de:

  • La proporción de difusión para el tráfico de unidifusión

  • La proporción de IP a tráfico no IP (que no se ve generalmente en las VLAN de administración)

VLAN 1 designa y maneja la mayoría del tráfico de plano de control. VLAN 1 se habilita en todos las conexiones troncales de manera predeterminada. Con redes de campus más extensas, debe tener cuidado del diámetro del dominio STP de VLAN 1. La inestabilidad en una parte de la red puede afectar la VLAN 1 e influenciar la estabilidad del plano de control y la estabilidad de STP para todas las demás VLAN. Puede limitar las transmisiones VLAN 1 de información de los usuarios y el funcionamiento de STP en una interfaz. Simplemente no configure la VLAN en la interfaz troncal.

Esta configuración no detiene la transmisión de los paquetes de control enviados de switch a switch en VLAN 1, como con un analizador de red. Pero no se envía ninguna información y STP no se ejecuta en este enlace. Por consiguiente, puede utilizar esta técnica para dividir la VLAN 1 en dominios de fallos más pequeños.

Nota: No puede eliminar VLAN 1 de los enlaces troncales a Catalyst 2900XL/3500XL

Aun cuando tenga cuidado al restringir las VLAN de usuario a dominios de switches relativamente pequeños y respectivamente los límites de fallos pequeños/Capa 3, algunos clientes tienden a tratar la VLAN de administración de manera diferente. Estos clientes tratan de cubrir toda la red con una subred de administración simple. No existe una razón técnica para que una aplicación NMS central deba ser adyacente de Capa 2 a los dispositivos que administra la aplicación, tampoco esto es argumento de seguridad calificada. Limite el diámetro de las VLAN de administración a la misma estructura de dominio del router como la de las VLAN de usuarios. Considere la administración fuera de banda y/o el soporte SSH como una manera de incrementar la seguridad de administración de la red.

Otras opciones

Hay consideraciones de diseño para estas recomendaciones Cisco en algunas topologías. Por ejemplo, un diseño multicapa de Cisco común y preferido es uno que evite el uso de un árbol de expansión activo. De esta manera, el diseño solicita la restricción de cada subred/VLAN IP a un switch de capa de acceso simple (o grupo de switches). En estos diseños no hay enlaces troncales configurados hacia la capa de acceso.

¿Ha creado una VLAN de administración aparte y habilitado la conexión troncal para transportarla entre la Capa 2 de acceso y la Capa 3 de distribución? No hay una respuesta fácil a esta pregunta. Considere estas dos opciones para una revisión del diseño con el ingeniero de Cisco:

  • Opción 1: realice una conexión troncal de dos o tres VLAN de la capa de distribución hacia cada switch de capa de acceso. Esta configuración permite una VLAN de datos, una VLAN de voz y una VLAN de administración, y además tiene el beneficio de que STP se encuentra inactivo. Se necesita un paso extra en la configuración para eliminar la VLAN 1 de las conexiones troncales. En esta solución, existen también puntos de diseño a considerar para evitar la confección de agujeros negros temporales del tráfico enrutado durante la recuperación de un error. Utilice STP PortFast para conexiones troncales (en el futuro) o la sincronización automática de estado de VLAN con reenvío de STP.

  • Opción 2: una VLAN simple para datos y administración puede ser aceptable. Si desea mantener la interfaz sc0 separada de la información del usuario, el hardware de los switches más nuevos hace que este hecho sea un problema menor de lo que era. El hardware más nuevo proporciona:

    • CPU más potentes y controles para el control de plano de limitación de la tarifa.

    • Un diseño con dominios de difusión relativamente pequeños apoyados por el diseño multicapa.

    Para tomar una decisión final, examine el perfil del tráfico de difusión para la VLAN y discuta las capacidades del hardware del switch con con el ingeniero de Cisco. Si la VLAN de administración contiene todos los usuarios en ese switch de capa de acceso, utilice los filtros de entrada IP para asegurar el switch de los usuarios, como para la sección Funciones de seguridad del software Cisco IOS.

Recomendación sobre la Interfaz de administración y la VLAN nativa de Cisco

Interfaz de administración

El software del sistema Cisco IOS le ofrece la opción de configurar las interfaces como interfaces de Capa 3 o como puertos del switch de Capa 2 en una VLAN. Cuando se utiliza el comando switchport en el software Cisco IOS, todos los puertos de los switches son puertos de acceso en VLAN 1 de manera predeterminada. Por lo tanto, excepto que se configure de otro modo, la información del usuario puede posiblemente existir de manera predeterminada en VLAN 1.

Permita que la VLAN de administración sea una VLAN distinta de VLAN 1. Mantenga toda la información del usuario fuera de la VLAN de administración. En su lugar, configure una interfaz de bucle de retorno como la interfaz de administración en cada switch.

Nota: Si utiliza el protocolo OSPF, este también se convertirá en la ID del router OSPF.

Asegúrese de que la interfaz de bucle de retorno posee una máscara de subred de 32 bits y configure la interfaz de bucle de retorno como una interfaz pura de Capa 3 en el switch. Aquí tiene un ejemplo:

Switch(config)#interface loopback 0
Switch(config-if)#ip address 10.x.x.x 255.255.255.255
Switch(config-if)#end
Switch# 

VLAN nativa

Configure la VLAN nativa para que sea una VLAN falsa evidente que nunca está habilitada en el router. Cisco recomendaba VLAN 999 en el pasado, pero la elección es netamente arbitraria.

Ejecute estos comandos de interfaz para establecer una VLAN como la nativa (predeterminada) para la conexión troncal 802.1Q en un puerto en particular:

Switch(config)#interface type slot/port
Switch(config-if)#switchport trunk native vlan 999

Para recomendaciones sobre la configuración de conexiones troncales adicionales, consulte la sección Protocolo de conexión troncal dinámica de este documento.

Administración fuera de banda

Propósito

Se puede hacer que la administración de red tenga alta disponibilidad si se construye una infraestructura separada alrededor de la red de producción. Esta configuración habilita a los dispositivos para alcanzarlos de forma remota, a pesar del tráfico o los eventos de plano de control que se produzcan. Estos dos métodos son típicos:

  • Administración fuera de banda con una LAN exclusiva

  • Administración fuera de banda con servidores terminales

Información operativa general

Puede proporcionar a cada router y switch en la red una interfaz de administración fuera de banda Ethernet en una VLAN de administración. Se configura un puerto Ethernet en cada dispositivo en la VLAN de administración y el cable se encuentra fuera de la red de producción hacia una red de administración conmutada separada.

Nota: Los switches Catalyst 4500/4000, poseen una interfaz especial me1 en el Supervisor Engine que se utiliza par ala administración fuera de banda únicamente y no como un puerto de switch.

Además, se puede alcanzar la conectividad del servidor terminal si se configura un router Cisco 2600 o 3600 con cables seriales RJ-45 para acceder al puerto de consola de cada router y switch en el diseño. El uso de un servidor de terminal también evita la necesidad de configurar escenarios de respaldo, como módems o puertos auxiliares para cada dispositivo. Puede configurar un módem único en el puerto auxiliar del servidor terminal. Esta configuración proporciona servicios de marcación manual a otros dispositivos durante el fallo en la conectividad de la red. Consulte Conexión de un módem al puerto de la consola en los switches Catalyst para más información.

Recomendación

Con esta disposición, son posibles dos trayectos fuera de banda a cada switch y router además de los numerosos trayectos en banda. Las disposiciones habilitan la administración de red altamente disponible. Los beneficios son:

  • Las disposiciones separan el tráfico de administración de la información del usuario.

  • La dirección IP de administración se encuentra en una subred, VLAN y switch aparte por seguridad.

  • Existe una garantía más alta para la entrega de información de administración durante los fallos de red.

  • No existe árbol de expansión activo en la VLAN de administración. La redundancia no es crucial aquí.

El diagrama muestra la administración fuera de banda:

185-f.gif

Registro del sistema

Propósito

Los mensajes de syslog son específicos de Cisco y pueden dar información más receptiva y exacta que la SNMP estandarizada. Por ejemplo, las plataformas de administración como Cisco Resource Manager Essentials (RME) y el Kit de herramientas de análisis de red (NATKit) hacen uso de la información de syslog para recolectar los cambios de inventario y configuración.

Recomendación para la configuración Cisco Syslog

El registro del sistema es una práctica operativa común y aceptada. Un syslog Unix puede capturar y analizar la información/eventos en el router como:

  • Estado de la interfaz

  • Seguridad y alertas

  • Condiciones del entorno

  • Proceso CPU hog

  • Otros eventos

El software Cisco IOS puede realizar registro UNIX a un servidor UNIX syslog. El formato Cisco UNIX syslog es compatible con la Distribución estándar 4.3 Berkeley (BSD) UNIX. Utilice estas configuraciones de registro del software Cisco IOS:

  • no logging console: de manera predeterminada, todos los mensajes del sistema se envían a la consola del sistema. El registro de la consola es un tarea de alta prioridad en el software Cisco IOS. Esta función fue diseñada principalmente para proporcionar mensajes de error al operador del sistema ante un fallo del mismo. Deshabilite el registro en la consola en todas las configuraciones de los dispositivos para evitar una situación en la que el router/switch puede bloquearse mientras el dispositivo espera una respuesta de una terminal. Pero los mensajes de la consola pueden ser útiles durante el aislamiento del problema. En estos casos, habilite el registro en la consola. Ejecute el comando logging console level para obtener el nivel deseado de registro de mensajes Los niveles de registro son de 0 a 7.

  • no logging monitor: este comando deshabilita el registro para las líneas terminales que no sea la consola del sistema. El registro de monitoreo puede solicitarse (con el uso de logging monitor debugging u otra opción de comando). En este caso, habilite el registro del monitoreo a un nivel específico de registro necesario para la actividad. Consulte el ítem no logging console en esta lista para más información acerca de los niveles de registro.

  • logging buffered 16384: el comando logging buffered debe agregase al registro de mensajes del sistema en el búfer del registro interno. El búfer del registro es circular. Una vez que el búfer del registro está lleno, las entradas viejas se sobreescriben con las nuevas. El tamaño del búfer del registro es configurable por el usuario y se especifica en bytes. El tamaño del búfer del sistema varía por plataforma. 16384 es un buen valor predeterminado que proporciona un registro adecuado en muchos casos.

  • logging trap notifications: este comando proporciona un nivel de notificación de mensajería (5) al servidor de syslog especificado. El nivel de registro predeterminado para todos los dispositivos (consola, monitor, búfer y trampas) es depuración (nivel 7). Si deja el nivel de registro trampa en 7, se producirán muchos mensajes extraños que son de poca o ninguna de importancia para la salud de la red. Configure el nivel de registro para trampas en 5.

  • logging facility local7: este comando configura el nivel/función de registro predeterminado para UNIX syslogging. Configure el servidor syslog que recibe estos mensajes para la misma función/nivel.

  • logging host: este comando establece la dirección IP del servidor de registro UNIX.

  • logging source-interface loopback 0: este comando establece la IP SA predeterminada para los mensajes de syslog. Predetermine el SA de registro para realizar la identificación del host que envía el mensaje más fácilmente.

  • service timestamps debug datetime localtime show-timezone msec: de manera predeterminada, los mensajes de registro no están marcados con fecha y hora. Puede utilizar este comando para habilitar la marcación de fecha y hora de los mensajes de registro y configurar la marcación de fecha y hora en los mensajes de depuración. La marcación de fecha y hora proporciona la sincronización relativa de los eventos registrados y aumenta la depuración en tiempo real. Esta información es especialmente útil cuando los clientes envían los resultados de la depuración al personal de soporte técnico para asistencia. Para habilitar la marcación de fecha y hora de los mensajes de depuración del sistema, utilice el comando en el modo de configuración global. El comando únicamente tiene efecto cuando la depuración se encuentra habilitada.

Nota: Además, habilite el registro para el estado del enlace y el estado de agrupamiento en todas interfaces de infraestructura Gigabit.

El software Cisco IOS proporciona un mecanismo simple para establecer la función y nivel de registro para todos los mensajes destinado a un servidor de syslog. Configure el nivel de la trampa de registro a notificación (nivel 5). Si establece el nivel de mensaje trampa como notificación, puede minimizar el número de mensajes informativos que se envían al servidor de syslog. Esta configuración puede reducir significativamente la cantidad de tráfico syslog en la red y puede reducir el impacto en los recursos del servidor de syslog.

Agregue estos comando a cada router y switch que ejecuta el software Cisco IOS para habilitar la mensajería de syslog:

  • Comandos de configuración syslog global:

    no logging console
    no logging monitor
    logging buffered 16384
    logging trap notifications
    logging facility local7
    logging host-ip
    logging source-interface loopback 0
    service timestamps debug datetime localtime show-timezone msec
    service timestamps log datetime localtime show-timezone msec
  • Comandos de configuración de interfaz syslog:

    logging event link-status
    logging event bundle-status

SNMP (Protocolo de administración simple de red)

Propósito

Puede utilizar SNMP para recuperar las estadísticas, contadores y tablas que se almacenan en el dispositivo de red de las MIB. Los NMS, como HP OpenView, pueden utilizar la información para:

  • Generar alertas en tiempo real

  • Disponibilidad de medidas

  • Produce información de planificación de capacidad

  • Ayuda a realizar verificaciones de configuración y resolución de problemas

La operación de Interfaces de administración

SNMP es un protocolo de capa de aplicación que proporciona un formato de mensaje de comunicación entre los agentes y administradores SNMP. SNMP proporciona una estructura estandarizada y un idioma común para el monitor y la administración de los dispositivos en la red.

El SNMP framework consta de estas tres partes:

  • Un administrador SNMP

  • Un agente SNMP

  • Una MIB

El administrador SNMP es el sistema que utiliza SNMP para controlar y supervisar las actividades de los host de red. El sistema de administración más común se denomina NMS. Puede aplicar el término NMS tanto a un dispositivo dedicado que se usa para la administración de la red o para las aplicaciones que se usan en dichos dispositivos. Se encuentran disponibles una variedad de aplicaciones de administración de red para utilizar con SNMP. Estas aplicaciones varían desde aplicaciones CLI simple a GUI llenas de funciones como la línea de productos CiscoWorks.

El agente SNMP es el componente de software en el dispositivo de administración que mantiene la información para el dispositivo e informa estos datos, de ser necesario, a los sistemas de administración. El agente y la MIB residen en el dispositivo de enrutamiento (el router, el servidor de acceso o el switch). Para habilitar el agente SNMP en el dispositivo del router de Cisco, debe definir la relación ente el administrador y el agente.

La MIB es área de almacenamiento de información virtual para la información de la administración de la red. La MIB consta de colecciones de objetos administrados. Dentro de la MIB, existen colecciones de objetos relacionados definidos en los módulos MIB. Los módulos MIB se escriben en el módulo SNMP MIB, como lo definen STD 58, RFC 2578leavingcisco.com, RFC 2579leavingcisco.com y RFC 2580 leavingcisco.com.

Nota: Los módulos MIB individuales son también denominados MIB. Por ejemplo, el grupo de interfaces MIB (IF-MIB) es un módulo MIB dentro de la MIB en su sistema.

El agente SNMP contiene variables MIB, que son valores que el administrador SNMP puede solicitar o cambiar a través de operaciones get o set. Un administrador puede obtener un valor de un agente o almacenar un valor en ese agente. El agente recoge información de la MIB, que es el depósito para la información sobre los parámetros del dispositivo e información de la red. El agente puede además responder al pedido del administrador para obtener o configurar información.

El administrador puede enviar los pedidos del administrador para obtener o configurar los valores MIB. El agente puede responder a estos pedidos. Independientemente de esta interacción, el agente puede enviar notificaciones no solicitadas (trampas o informes) al administrador para notificar al administrador de las condiciones de la red. Con algunos mecanismos de seguridad, un NMS puede recuperar la información en las MIB con pedidos de GET y get next y puede ejecutar el comando set para cambiar los parámetros. Además, puede establecer el dispositivo de red para generar mensajes trampa al NMS para alertas en tiempo real. Los puertos IP UDP 161 y 162 se utilizan para trampas.

Información general sobre notificaciones SNMP

Una función clave de SNMP es la habilidad para generar notificaciones desde un agente SNMP. Estas notificaciones no requieren que los pedidos se envíen desde el administrador SNMP. Las notificaciones no solicitadas (asíncronas) pueden generarse como trampas o pedidos de informes. Las trampas son mensajes que alertan al administrador SNMP de una condición en la red. Los pedidos de información (informes) son trampas que incluyen un pedido para la confirmación de la recepción desde el administrador SNMP. Las notificaciones pueden indicar eventos importantes como:

  • Autenticación de uso inapropiado

  • Reinicios

  • El cierre de la conexión

  • La pérdida de la conexión a un router vecino

  • Otros eventos

Las trampas no son menos fiables que los informes porque el receptor no envía acuse de recibo cuando recibe una trampa. El remitente no puede determinar si la trampa fue recibida. Un administrador SNMP que recibe un pedido de informe reconoce el mensaje con una unidad de datos de protocolo de respuesta (PDU) SNMP. Si el administrador no recibe un pedido de informe, el administrador no envía una respuesta. Si el remitente no recibe una respuesta, el remitente puede enviar el pedido de informe nuevamente. Los informes tienen más posibilidades de llegar al destino deseado.

Pero las trampas se prefieren generalmente porque los informes consumen más recursos en el router y en la red. Una trampa se descarta tan pronto como se envía. Pero un pedido de informe debe conservarse en la memoria hasta que se reciba una respuesta o finalice el tiempo del pedido. Asimismo, las trampas se envían sólo una vez, mientras que un informe debe tener varios reintentos. Los reintentos incrementan el tráfico y contribuyen a una sobrecarga mayor en la red. Por lo tanto, los pedidos de trampas e informes proporcionan un equilibrio entre la confiabilidad y los recursos. Si necesita que el administrador SNMP reciba cada notificación, utilice los pedidos de informe. Pero si tiene dudas acerca del tráfico en su red o memoria en el router y no necesita recibir cada notificación, utilice trampas.

Estos diagramas ilustran las diferencias entre los pedidos:

185-g.gif

Este diagrama ilustra cómo el router agente envía con éxito una trampa al administrador SNMP. A pesar que el administrador recibe la trampa, éste no envía ningún acuse de recibo al agente. El agente no tiene manera de saber que la trampa ha llegado al destino.

185-h.gif

Este diagrama ilustra cómo el router agente envía con éxito un pedido de informe al administrador. Cuando el administrador recibe el pedido de informe, éste envía una respuesta al agente. De esta forma, el agente sabe que el pedido de informe llegó al destino. Tenga en cuenta que, en este ejemplo, hay el doble de tráfico. Pero el agente sabe que el administrador recibió la notificación.

185-i.gif

En este diagrama, el agente envía una trampa al administrador, pero la trampa no le llega. El agente no tiene manera de saber que la trampa no llegó al destino y por lo tanto ésta no es enviada nuevamente. El administrador nunca recibe la trampa.

185-j.gif

En este diagrama, el agente envía un pedido de informe al administrador, pero el pedido del informe no le llega. Debido a que el administrador no recibe el pedido de informe, no hay respuesta. Después de un período de tiempo, el agente reenvía el pedido de informe. La segunda vez, el administrador recibe el pedido de informe y contesta con una respuesta. En este ejemplo, hay más tráfico. Pero la notificación alcanza el administrador SNMP.

Referencia MIB y RCF de Cisco

Los documentos RFC definen generalmente los módulos MIB. Los documentos RFC se envían al grupo de trabajo de ingeniería en Internet (IETF), un cuerpo de normas internacionales. Personas o grupos escriben RFC para consideración por parte de la Sociedad de Internet (ISOC) y la comunidad Internet como un todo. Consulte la página de inicio de Internet Societyleavingcisco.com para conocer más acerca del proceso de normas y las actividades de IETF. Consulte la página de inicio de IETFleavingcisco.com para leer el texto completo de todas las RFC, borradores de Internet (I-D) y STD a los que los documentos de Cisco hacen referencia.

La implementación Cisco de SNMP utiliza:

  • Las definiciones de las variables MIB II que describe RFC 1213 leavingcisco.com

  • Las definiciones de trampas SNMP que describe RFC 1215 leavingcisco.com

Cisco proporciona sus propias extensiones MIB privadas con cada sistema. Las MIB de la empresa Cisco cumplen con los lineamientos que las RFC relevantes describen, excepto que la documentación notifique lo contrario. Puede encontrar los archivos de definición del módulo MIB y enumerar las MIB que se soportan en cada plataforma Cisco en la página de inicio de Cisco MIB.

Versiones de SNMP

El software Cisco IOS soporta estas versiones SNMP:

  • SNMPv1: un estándar de Internet completo que define RFC 1157 leavingcisco.com. RFC 1157leavingcisco.com reemplaza las versiones anteriores publicadas como RFC 1067leavingcisco.comy RFC 1098leavingcisco.com. La seguridad se basa en cadenas de la comunidad.

  • SNMPv2c: SNMPv2c es el marco administrativo basado en la administración de cadenas de la comunidad para SNMPv2. SNMPv2c (la c representa comunidad) es un protocolo experimental de Internet que definen RFC 1901leavingcisco.com, RFC 1905leavingcisco.com, y RFC 1906 leavingcisco.com. SNMPv2c es una actualización de las operaciones del protocolo y los tipos de información de SNMPv2p (SNMPv2 Clásico). SNMPv2 utiliza la seguridad basada en el modelo de comunidad de SNMPv1.

  • SNMPv3: SNMPv3 es un protocolo basado en estándares de interoperabilidad que definen RFC 2273leavingcisco.com, RFC 2274 leavingcisco.com, y RFC 2275 leavingcisco.com. SNMPv3 proporciona acceso seguro a los dispositivos con una combinación de autenticación y cifrado de paquetes en la red.

    Las funciones de seguridad que SNMPv3 proporciona son:

    • Integridad del mensaje: asegura que un paquete no haya sido alterado en tránsito.

    • Autenticación: determina que el mensaje proviene de una fuente válida.

    • Cifrado: codifica los contenidos de un paquete, lo que impide el descubrimiento por parte de una fuente no autorizada.

Tanto SNMPv1 como SNMPv2c utilizan una forma de seguridad basada en la comunidad. Una dirección IP ACL y contraseña define la comunidad de administradores capaces de acceder a la MIB agente.

El soporte SNMPv2c incluye un mecanismo de recuperación global y mensajes de error más detallados que informan a las estaciones de administración. El mecanismo de recuperación global soporta la recuperación de tablas y grandes cantidades de información, lo que minimiza el número de viajes de ida y vuelta necesarios. El soporte de manejo de error mejorado de SNMPv2c incluye códigos de error expandidos que distinguen diferentes clases de condiciones de error. Estas condiciones son informadas por medio de un código de error simple en SNMPv1. Los códigos de retorno de error informan ahora el tipo de error.

SNMPv3 proporciona tanto para los modelos de seguridad como para los niveles de seguridad. Un modelo de seguridad es una estrategia de autenticación que se configura para un usuario y el grupo en el que reside el usuario. Un nivel de seguridad es el nivel permitido de seguridad dentro de un modelo de seguridad. La combinación de un modelo de seguridad y un nivel de seguridad determina qué mecanismo de seguridad utilizar cuando se maneja un paquete SNMP.

Configuración general SNMP

Ejecute estos comandos en todos los switches de los clientes para habilitar la administración SNMP:

  • Comando para SNMP ACL:

    Switch(config)#access-list 98 permit ip_address
    !--- Éste es el dispositivo SNMP ACL. 
  • Comandos SNMP globales:

    !--- Estas son muestras de cadenas de la comunidad SNMP.
    Switch(config)#snmp-server community RO-community ro 98
    snmp-server community RW-community rw 98
    snmp-server contact Glen Rahn (Home Number)
    snmp-server location text

Recomendación de notificaciones de trampa de SNMP

SNMP es la base de administración de la red y se encuentra habilitada y en uso en todas las redes.

Un agente SNMP puede comunicarse con varios administradores. Por este motivo, puede configurar el software para soportar comunicaciones con una estación de administración con el uso de SNMPv1 y otra estación de administración con el uso de SNMPv2. La mayoría de los clientes y NMS aun utilizan SNMPv1 y SNMPv2c debido a que el dispositivo de red SNMPv3 que se soporta en las plataformas NMS sufren algún retraso.

Habilite trampas SNMP para todas las funciones en uso. Puede deshabilitar otras funciones, si lo desea. Después de habilitar una trampa, puede ejecutar el comando test snmp y configurar el manejo apropiado en en NMS para el error. Los ejemplos de esos manejos incluyen una alerta de localización o mensajes emergentes.

Todas las trampas se deshabilitan de manera predeterminada. Habilite todas las trampas en los switches del núcleo, como se muestra en este ejemplo:

Switch(config)#snmp trap enable
Switch(config)#snmp-server trap-source loopback0

Además, habilite las trampas de puertos para los puertos claves, como los enlaces de infraestructura a los routers y switches y puertos de servidor claves. La habilitación no es necesaria para otros puertos, como los puertos de host. Ejecute este comando para configurar el puerto y habilite la notificación de enlace activo/inactivo:

Switch(config-if)#snmp trap link-status

A continuación, especifique los dispositivos para recibir las trampas y actuar en las trampas correctamente. Ahora puede configurar cada destino de trampa como un SNMPv1, SNMPv2 o receptor SNMPv3. Para los dispositivos SNMPv3, se pueden enviar informes fiables en lugar de trampas UDP. Esta es la configuración:

Switch(config)#snmp-server host ip_address [traps | informs] [version {1 | 2c | 3}]
community-string
!--- Este comando debe estar en una línea.
!--- Estas son muestras de destinos de host para trampas SNMP e informes.
snmp-server host 172.16.1.27 version 2c public
snmp-server host 172.16.1.111 version 1 public
snmp-server host 172.16.1.111 informs version 3 public
snmp-server host 172.16.1.33 public

Recomendaciones de consulta SNMP

Asegúrese de que estas MIB sean MIB claves consultadas o supervisadas en redes de campus:

Nota: Esta recomendación proviene del grupo del Consultores de administración de la red Cisco.

185-k.gif

185-l.gif

185-m.gif

Network Time Protocol (protocolo de hora de red)

Propósito

El Protocolo de tiempo de red (NTP), RFC 1305leavingcisco.com, sincroniza la hora entre un grupo de servidores de tiempo y clientes distribuidos. NTP permite la correlación de eventos en la creación de registros del sistema y cuando se produce otro tipo de eventos específicos del tiempo.

Información operativa general

RFC 958leavingcisco.comdocumentado NTP primero. Pero NTP ha evolucionado a través de RFC 1119leavingcisco.com(versión NTP). RFC 1305leavingcisco.com ahora define NTP, que se encuentra en la tercera versión.

NTP sincroniza el tiempo de un cliente o servidor de computador a otro servidor o fuente de tiempo de referencia, como una radio, un receptor satelital o un módem. NTP proporciona precisión en el cliente que se encuentra generalmente dentro de un ms en las LAN hasta unas pocas decenas de ms en las WAN, en comparación con un servidor primario sincronizado. Por ejemplo, puede utilizar NTP para coordinar el Tiempo Universal Coordinado (UTC) a través de un receptor de servicio de posicionamiento global (GPS).

Las configuraciones NTP utilizan generalmente servidores redundantes múltiples y diversos trayectos de red para alcanzar alta precisión y confiabilidad. Algunas de las configuraciones incluyen autenticación criptográfica para evitar ataques maliciosos o accidentales al protocolo.

NTP se ejecuta sobre el UDP, que a su vez, se ejecuta sobre el IP. Todas las comunicaciones NTP utilizan UTC, que es el mismo tiempo que la Hora media de Greenwich.

Actualmente, las implementaciones NTP versión 3 (NTPv3) y NTP versión 4 (NTPv4) se encuentran disponibles. La última versión de software en la que se trabaja es NTPv4, pero el estándar oficial de Internet aun es NTPv3. Además, algunos vendedores de sistemas operativos personalizan la implementación del protocolo.

NTP Safeguards (Seguridad NTP)

La implementación NTP también intenta evitar la sincronización con una máquina en la que el tiempo posiblemente pueda no ser preciso. NTP realiza esto de dos maneras:

  • NTP no sincroniza con una máquina que no está sincronizada.

  • NTP siempre compara el tiempo informado por varias maquinas, y no sincroniza con una máquina en la que el tiempo es significativamente diferente a otros, aun si la máquina tiene un estrato más bajo.

Asociaciones

La comunicación ente máquinas que ejecutan NTP, conocidas como asociaciones, generalmente están estadísticamente configuradas. A cada máquina se le otorga una dirección IP de todas las máquinas con las que necesita formar asociaciones. Es posible la hora precisa gracias al intercambio de mensajes NTP entre cada par de máquinas con una asociación. Pero en un entorno LAN, puede configurar NTP para utilizar mensajes de difusión IP. Con esta alternativa, puede configurar la máquina para que envíe y reciba mensajes de difusión pero la precisión de hora se ve reducida marginalmente debido a que el flujo de la información es en una dirección únicamente.

Si la red está aislada de Internet, la implementación Cisco NTP le permite configurar una máquina para que pueda actuar como si estuviera sincronizada con el uso de NTP, cuando haya determinado verdaderamente la hora con el uso de otros métodos. Otras máquinas sincronizan con esa máquina con el uso de NTP.

Una asociación NTP puede ser:

  • Una asociación de pares

    Esto significa que este sistema se puede sincronizar con otro sistema o permitir al otro sistema sincronizarse con este.

  • Una asociación de servidores

    Esto significa que sólo este sistema se sincroniza con el otro sistema. El otro sistema no se sincroniza con este.

Si desea formar una asociación NTP con otro sistema, utilice uno de estos comandos en modo de configuración global:

Comando

Propósito

ntp peer ip-address [normal-sync] [version number] [key key-id] [source interface] [prefer]

Forme una asociación de pares con otro sistema

ntp server ip-address [version number] [key key-id] [source interface] [prefer]

Forme una asociación de pares con otro sistema

Nota: Sólo se debe configurar un final de una asociación. Los demás sistemas establecen automáticamente la asociación.

Acceso a servidores de tiempo público

La subred NTP incluye actualmente más de 50 servidores públicos primarios que están sincronizados directamente a UTC por radio, satélite o módem. Normalmente, las estaciones de trabajo clientes y los servidores con un número de clientes relativamente pequeño no se sincronizan con los servidores primarios. Existen alrededor de 100 servidores públicos secundarios sincronizados con los servidores primarios. Estos servidores proporcionan sincronización con un total que excede los 100.000 clientes y servidores en Internet. La página Servidores NTP públicosleavingcisco.com mantiene las listas actuales y se actualiza con frecuencia.

También existen numerosos servidores privados primarios y secundarios que por lo general no se encuentran disponibles al público. Consulte El Proyecto del protocolo de tiempo de redleavingcisco.com,(Universidad de Delaware) para una lista de servidores NTP públicos e información acerca de cómo utilizarlos. No hay ninguna garantía de que estos servidores NTP de Internet públicos se encuentran disponibles y producen la hora correcta. Por consiguiente, se deben considerar otras opciones. Por ejemplo, utilizar varios dispositivos GPS autónomos que se encuentran directamente conectados a un número de routers.

Otra opción es utilizar varios routers, configurados como Estrato 1 maestro. Sin embargo, no se recomienda el uso de ese router.

Estrato

NTP utiliza un estrato para describir el número de saltos NTP fuera de una máquina desde una fuente de tiempo autorizado. El servidor de tiempo estrato 1 posee una radio o reloj atómico directamente asociado. El servidor de tiempo Stratum 2 recibe su tiempo del servidor de tiempo estrato 1 y demás. Una máquina que ejecuta NTP automáticamente elige como su fuente de tiempo la máquina con el menor número de estratos con el que está configurado para comunicarse a través de NTP. Esta estrategia construye efectivamente un árbol de altavoces NTP de organización automática

NTP evita la sincronización con un dispositivo en el que el tiempo posiblemente no sea preciso. Consulte la sección NTP Safeguards (Seguridad NTP) de Network Time Protocol (Protocolo de tiempo de la red) para más detalles.

Relación de entidad par servidora

  • Un servidor responde a los pedidos del cliente pero no intenta incorporar ninguna información actualizada de la fuente de tiempo del cliente.

  • Un par responde al pedido del cliente e intenta utilizar el pedido del mismo como candidato potencial para una mejor fuente de tiempo y ayudar en la estabilización de la frecuencia del reloj.

  • Para ser pares verdaderos, ambos lados de la conexión deben entrar en una relación de pares, en lugar de en una situación en la que un usuario sirva como par y el otro usuario como servidor. Debe haber intercambio de pares para sólo los hosts fiables puedan hablar con otros como pares.

  • En un pedido del cliente al servidor, el servidor responde al cliente y olvida que el cliente hizo una pregunta.

  • En un pedido del cliente a un par, el servidor responde al cliente. El servidor mantiene al información de estado acerca de la eficiencia del cliente con respecto al rastreo de la hora y qué servidor de estrato ejecuta el cliente.

Un servidor NTP puede manejar miles de clientes sin problemas. Pero cuando un servidor NTP maneja más de unos pocos clientes (hasta unos pocos cientos), existe un impacto en la memoria en la habilidad del servidor para retener información de estado. Cuando el servidor NTP maneja más de la cantidad recomendada , se consumen más recursos CPU y ancho de banda en la casilla.

Modos de comunicación con el servidor NTP

Estos son dos modos separados para comunicarse con el servidor:

  • Modo de difusión

  • Modo cliente/servidor

En el modo de difusión, los clientes escuchan. En el modo cliente/servidor, los clientes consultan al servidor. Puede utilizar la difusión NTP si no se encuentra involucrado ningún enlace WAN debido a su velocidad. Para atravesar un enlace WAN, utilice el modo cliente/servidor (por sondeo). El modo de difusión está diseñado para una LAN, en la que muchos clientes pueden tener que consultar al servidor. Sin el modo de difusión, ese sondeo puede generar un gran número de paquetes en la red. La multidifusión de NTP no se encuentra aun disponible en NTPv3, pero se encuentra disponible en NTPv4.

De manera predeterminada, el software Cisco IOS se comunica con el uso de NTPv3. Pero el software tiene compatibilidad descendente con las versiones anteriores de NTP.

Consulta

El protocolo NTP permite a un cliente realizar una consulta a un servidor en cualquier momento.

Cuando configura por primera vez NTP en una casilla Cisco, NTP envía ocho consultas en rápida sucesión en NTP_MINPOLL (2^4=16 seg) intervalos. La NTP_MAXPOLL es 2^14 segundos (16,384 seg o 4 horas, 33 min, 4 seg). Este período de tiempo, es el período más largo antes de que NTP consulte nuevamente por una respuesta. Actualmente, Cisco no posee un método para permitir al usuario forzar manualmente el tiempo POLL (el tiempo de consulta).

El contador de consultas NTP comienza en 2^6 (64) seg o 1 min, 4 seg. Este aumenta por 2, a medida que los dos servidores se sincronizan entre ellos, hasta 2^10. Puede esperar que los mensajes sync sean enviados en el intervalo de uno de 64, 128, 256, 512 o 1024 seg, según el servidor o la configuración de pares. El tiempo más largo entre los sondeos se produce cuando el reloj actual se torna más estable debido a los bucles con bloqueos de fase. Los bucles con bloqueos de fase recortan el cristal del reloj local hasta 1024 segundos (17 min).

El tiempo varía entre 64 segundos y 1024 segundos como potencia de 2 (que se iguala cada 64, 128, 256, 512 o 1024 seg). El tiempo se basa en el bucle con bloqueo de fase que envía y recibe paquetes. Si hay demasiada fluctuación en el tiempo, el sondeo se producirá con mayor frecuencia. Si el reloj de referencia es preciso y la conectividad de la red es consistente, el tiempo de sondeo converge en 1024 segundos entre cada sondeo.

El intervalo de sondeo NTP cambia a medida que la conexión entre el cliente y el servidor cambia. Con una mejor conexión, el intervalo del sondeo es mayor. En este caso, una mejor conexión significa que el cliente NTP ha recibido ocho respuestas para los últimos ocho pedidos. Luego el intervalo del sondeo se duplica. Una sola respuesta omitida provoca que el intervalo de consulta se reduzca a la mitad. El intervalo de sondeo comienza a los 64 segundos y va hasta un máximo de 1024 seg. En el mejor de los casos, el tiempo necesario del intervalo de sondeo para pasar de 64 a 1024 segundos es un poco más de 2 horas.

Difusiones

Las difusiones NTP nunca se reenvían. Si ejecuta el comando ntp broadcast, el router comienza a originar difusión NTP en la interfaz en la que está configurado.

Generalmente, se ejecuta el comando ntp broadcast para enviar difusiones NTP a una LAN para prestar servicio a estaciones y servidores finales de clientes.

Sincronización horaria

La sincronización de un cliente a un servidor consiste en el intercambio de varios paquetes. Cada intercambio es un par de pedido/respuesta. Cuando un cliente envía un pedido, el cliente almacena su hora local en el paquete enviado. Cuando un servidor recibe el paquete, almacena su propio tiempo estimado actual en el paquete y este es devuelto. Al recibir la respuesta, el receptor registra una vez más su propio tiempo de recepción para estimar el tiempo de viaje del paquete.

Estas diferencias de tiempo pueden utilizarse para estimar el tiempo necesario para que el paquete se transmita desde el servidor al solicitante. Ese tiempo de recorrido se toma en cuenta para un estimado del tiempo actual. Cuanto más corto es el tiempo de recorrido, más preciso es el estimado del tiempo actual.

El tiempo no se acepta hasta que se hayan producido varios paquetes de intercambio de aceptación. Algunos valores esenciales son colocados en filtros multietapa para estimar la calidad de los muestras. Generalmente, se necesitan 5 minutos para que un cliente NTP sincronice con un servidor. Es interesante destacar que esto también se produce con los relojes de referencia local que no poseen retardo en absoluto por definición.

Además, la calidad de la conexión de red también influencia la precisión final. Las redes lentas e impredecibles con retardos variables tienen mal efecto en la sincronización del tiempo.

Se necesita una diferencia de tiempo de menos de 128 ms para que NTP se sincronice. La precisión típica en los rangos de Internet de alrededor de 5 ms a 100 ms, que puede variar con retardos de red.

Niveles de tráfico de NTP

El ancho de banda utilizado por NTP es mínimo. El intervalo entre los mensajes de consulta que intercambian los pares normalmente se remonta a no más de un mensaje cada 17 min (1024 seg). Con una planeamiento cuidadoso, puede mantenerlo dentro de las redes del router en los enlaces WAN. Forme pares entre los clientes NTP locales y los servidores NTP y no en todo el transcurso de WAN a los routers principales de sitio central, que son los servidores Estrato 2.

Un cliente NTP con convergencia utiliza aproximadamente un promedio de 0.6 bits por segundo (bps) por servidor.

Recomendación NTP de Cisco

  • Cisco recomienda tener servidores de tiempo múltiples y diversos trayectos de red para alcanzar alta precisión y confiabilidad. Algunas de las configuraciones incluyen autenticación criptográfica para evitar ataques maliciosos o accidentales al protocolo.

  • En lo que respecta a RFC, NTP está diseñado para permitir el sondeo de varios servidores de tiempo diferentes y utiliza el análisis estadístico complejo para alcanzar un tiempo válido, aun si esta seguro que todos los servidores que consulta están autorizados. NTP estima los errores de todos los relojes. Por lo tanto, todos los servidores NTP devuelven el tiempo con un estimado de error actual. Al utilizar servidores de tiempo múltiples, NTP también quiere que estos servidores coincidan en algún tiempo.

  • La implementación Cisco de NTP no soporta el servicio de estrato 1. No puede conectarse a una radio o reloj atómico. Cisco recomienda que el servicio de tiempo para su red sea derivado de los servidores NTP públicos que se encuentran disponibles en la Internet IP.

  • Habilite todos los switches de clientes para que envíen pedidos de momentos del día a un servidor NTP. Puede configurar hasta 10 direcciones de servidores/pares por cliente para que pueda alcanzar una rápida sincronización.

  • Para reducir la sobrecarga del protocolo, los servidores secundarios distribuyen el tiempo a través de NTP a los host de red local restantes. A fin de mantener la confiabilidad, puede equipar los host seleccionados con relojes menos precisos y menos costosos utilizados como respaldo en caso de fallar los servidores primarios y/o secundarios o los trayectos de comunicación entre ellos.

  • ntp update-calendar: NTP generalmente cambia sólo el reloj del sistema. Este comando permite a NTP actualizar la información de fecha/hora en el calendario. La actualización se produce sólo si el tiempo NTP está sincronizado. De lo contrario, el calendario mantiene su propio tiempo y no está afectado por el tiempo NTP o el reloj del sistema. Siempre utilice esto en routers de mayor capacidad.

  • clock calendar-valid: este comando notifica que la información del calendario es válida y sincronizada. Utilice esta opción en NTP maestro. Si no se configura, el router de mayor capacidad que posee calendario aun piensa que su tiempo no está autorizado, aun si tiene línea NTP maestro.

  • Cualquier número de estrato mayor que 15 se considera no sincronizado. Este es el motivo por el que se ve el estrato 16 en el resultado del comando show ntp status en los routers para los que los relojes no están sincronizados. Si el maestro está sincronizado con un servidor NTP, asegúrese de que el número de estrato en la línea NTP maestro sea uno o dos números más alto que el estrato más alto en los servidores públicos que consulte.

  • Muchos clientes poseen NTP configurado en el modo servidor en sus plataformas de software Cisco IOS, sincronizado a partir de varias entradas fiables de Internet o de un reloj de radio. Internamente, una alternativa más simple para el modo servidor al operar un gran número de switches es habilitar NTP en el modo difusión en la VLAN de administración en un dominio conmutado. Este mecanismo permite a Catalyst recibir un reloj desde mensajes individuales de difusión. Pero la precisión de la hora se ve reducida marginalmente debido a que el flujo de la información es en una dirección.

  • El uso de direcciones de bucle de retorno como fuente de actualizaciones también puede ayudar con la consistencia. Puede dirigir las dudas sobre la seguridad de dos maneras:

    • Con el control de las actualizaciones de servidores, que Cisco recomienda

    • Por autenticación

Comandos de configuración global NTP

Para el cliente:
clock timezone EST  -5  ????
ntp source loopback 0 ?????
ntp server ip_address key 1
ntp peer ip_address
!--- Esto es para una asociación de pares.
ntp authenticate
ntp authentication-key 1 md5 xxxx
ntp trusted-key 1

Para el servidor: 
clock timezone EST -5
clock summer-time EDT recurring 1 Sun Apr 3:00 last Sun Oct 3:00
clock calendar-valid
ntp source loopback0
ntp update-calendar

!--- Esto es opcional:
interface vlan_id ntp broadcast
!--- Esto envía paquetes de difusión NTP.
ntp broadcast client
!--- Esto recibe paquetes de difusión NTP.
ntp authenticate
ntp authentication-key 1 md5 xxxxx
ntp trusted-key 1
ntp access-group access-list
!--- Esto provee más seguridad, si es necesario.

Comando de estado NTP

show ntp status

Clock is synchronized, stratum 8, reference is 127.127.7.1
nominal freq is 250.0000 Hz, actual freq is 249.9974 Hz, precision is 2**18
reference time is C6CF0C30.980CCA9D (01:34:00.593 IST Mon Sep 12 2005)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 0.02 msec, peer dispersion is 0.02 msec

Ésta es la dirección del reloj de referencia para el router de Cisco cuando el router funciona como un NTP maestro. Si el router no fue sincronizado con ningún servidor NTP, el router utiliza esta dirección como la ID de referencia. Para obtener más información acerca de la configuración y los comandos, consulte la sección Configuración de NTP de Administración básica del sistema.

Protocolo de detección de Cisco

Propósito

CDP se ejecuta sobre la Capa 2 (capa del enlace de datos) en todos los servidores de acceso, bridges, switches y routers de Cisco. CDP permite aplicaciones de administración de red para detectar dispositivos Cisco que sean vecinos de dispositivos ya conocidos. En particular, las aplicaciones de administración de red pueden detectar vecinos que ejecutan protocolos transparentes de capas inferiores. Con CDP, las aplicaciones de administración de red pueden obtener el tipo de dispositivo y la dirección del agente SNMP de los dispositivos de vecindad. Esta función permite que las aplicaciones envíen consultas SNMP a los dispositivos de vecindad.

Los comandos show que se asocian con la función CDP permite que el ingeniero de red determine esta información:

  • El número de módulo/puerto de otros dispositivos habilitados de CDP adyacentes

  • Estas direcciones del dispositivo adyacente:

    • Dirección MAC

    • Dirección IP

    • Dirección del canal de puerto

  • La versión del software del dispositivo adyacente

  • Esta información sobre el dispositivo adyacente:

    • Velocidad

    • Dúplex

    • dominio de VTP

    • Configuración de VLAN nativa

La Descripción general del funcionamiento destaca algunas de las mejoras de la versión 2 de CDP (CDPv2) en comparación con la versión 1 de CDP (CDPv1).

Descripción general del funcionamiento

CDP se ejecuta en todos los medios LAN y WAN que soportan SNAP.

Cada dispositivo configurado en CDP envía mensajes periódicos a una dirección gateway predeterminada. Cada dispositivo anuncia al menos una dirección a la que el dispositivo puede recibir mensajes SNMP. Los anuncios también contienen la información sobre el tiempo en espera o el tiempo de vida. Esta información indica la longitud del tiempo para un dispositivo receptor para retener la información CDP antes de eliminarla.

CDP utiliza encapsulación SNAP con código de tipo 2000. En Ethernet, ATM y FDDI, se utiliza la dirección de multidifusión de destino 01-00-0c-cc-cc-cc. En Token Rings, se utiliza la dirección funcional c000.0800.0000. Se envían tramas CDP periódicamente a cada minuto.

Los mensajes CDP contienen uno o más mensajes que permiten que el dispositivo de destino recopile y almacene información sobre cada dispositivo vecino.

Esta tabla proporciona los parámetros que soporta CDPv1:

Parámetro

Tipo

Descripción

1

ID de dispositivo

Nombre de host del número de serie del hardware o dispositivo en ASCII

2

Dirección

La dirección de la Capa 3 de la interfaz que envía la actualización

3

Identificación del puerto

El puerto al que se envía la actualización CDP

4

Capacidades

Describe las capacidades funcionales del dispositivo de esta manera:

  • Router: 0x01

  • Bridge SR1: 0x04

  • Switch: 0x08 (proporciona conmutación de la Capa 2 y/o la Capa 3).

  • Host: 0x10

  • Filtrado condicional de IGMP: 0x20

  • El bridge o switch no reenvía los paquetes de reporte IGMP en los puertos que no son de un router.

5

Versión

Una cadena de caracteres que contiene la versión del software

Nota: El resultado del comando show version muestra la misma información.

6

Plataforma

La plataforma de hardware, por ejemplo, WS-C5000, WS-C6009 y RSP2 de Cisco

1 SR = ruta de origen.

2 RSP = Procesador del switch de ruta.

En CDPv2 se presentaron valores, longitud y tipo (TLV) adicionales. CDPv2 es compatible con cualquier TLV. Pero esta tabla proporciona los parámetros que pueden ser particularmente útiles en entornos conmutados y que utiliza el software Catalyst.

Cuando un switch ejecuta CDPv1, el switch descarta las tramas CDPv2. Cuando un switch ejecuta CDPv2 y recibe una trama CDPv1 en una interfaz, el switch comienza a enviar tramas CDPv1 fuera de esa interfaz, además de las tramas CDPv2.

Parámetro

Tipo

Descripción

9

Dominio de VTP

El dominio VTP, si está configurado en el dispositivo.

10

VLAN nativa

En dot1q, las tramas para la VLAN, en la que se encuentra el puerto si el puerto no se encuentra conectado por una conexión troncal, permanecen sin etiquetado. Esto generalmente se denomina como VLAN nativa.

11

Semidúplex/dúplex completo

Este TLV contiene la configuración dúplex del puerto de envío.

14

Dispositivo VLAN-ID

Permite diferenciar el tráfico VoIP de otro tráfico por medio de una VLAN ID aparte (VLAN auxiliar).

16

Consumo de energía

La cantidad máxima de energía que se espera consumir, en mW, por el dispositivo conectado.

17

MTU (unidad de transmisión básica)

La MTU de la interfaz por la que se transmite el marco CDP.

18

Confianza extendida

Indica los puertos en el modo Confianza extendida.

19

COS para puertos no fiables

La clase de valor de servicio (CoS) para utilizar para marcar todos los paquetes que se reciben en los puertos no fiables de un dispositivo de conmutación conectado.

20

SysName

Nombre de dominio completamente calificado del dispositivo (0, si no se conoce).

25

Energía solicitada

Transmitida por un dispositivo de energía para negociar un nivel de energía apropiado.

26

Energía disponible

Transmitida por un switch Permite que un dispositivo de energía negocie y seleccione una configuración de energía apropiada.

CDPv2/Alimentación por Ethernet

Algunos switches, como Catalyst 6500/6000 y 4500/4000, tienen la habilidad de alimentar a los dispositivos de energía a través de cables par trenzados sin blindaje (UTP). La información recibida a través de CDP (Parámetros 16, 25, 26) asiste en la optimización de un administrador de energía de switch.

CDPv2/Interacción con Teléfono IP de Cisco

Los teléfonos IP de Cisco proporcionan conectividad para dispositivos 100-Mbps Ethernet externamente asociados. Esta conectividad se alcanza a través de integración de un switch interno de Capa 2 de tres puertos dentro del teléfono IP. Los puertos internos del switch son denominados:

  • P0 (dispositivo interno de teléfono IP)

  • P1 (puerto externo 10/100-Mbps)

  • P2 (puerto externo 10/100-Mbps que conecta el switch)

Puede transferir tráfico de voz en una VLAN separada en el puerto del switch si configura los puertos troncales de acceso dot1q. Esta VLAN adicional se conoce como VLAN auxiliar (CatOS) o de voz (software Cisco IOS). En consecuencia, tráfico con etiqueta dot1q del teléfono IP puede ser enviado a la VLAN auxiliar/voz y el tráfico sin etiqueta puede ser enviado a través de el puerto externo 10/100-Mbps del teléfono a través de la VLAN de acceso.

Los switches Catalyst pueden informar a un teléfono IP de las voz VLAN ID a través de CDP (Parámetro-14: Dispositivo VLAN-ID TLV). Como resultado, los teléfono IP designan todos los paquetes relacionados VoIP con la VLAN ID correspondiente y la prioridad 802.1p. Esta adición al protocolo CDP TLV también es utilizada para identificar si un teléfono IP se encuentra conectado a través del parámetro ID.

Este concepto se puede aprovechar cuando desarrolla una política QoS. Es probable que configure el switch Catalyst para que interactúe con el teléfono IP de tres maneras:

  • Teléfono IP de Cisco Dispositivo Fiable

    Confíe condicionalmente en CoS sólo cuando un teléfono IP sea detectado a través de CDP. Siempre que un teléfono IP es detectado a través del parámetro-14 CDP, el estado de fiabilidad del puerto se configura como COS fiable. Si no se detecta ningún teléfono IP, el puerto será no fiable.

  • Confianza extendida

    El switch puede informar al teléfono IP a través de CDP (Parámetro-18) para confiar todas las tramas recibidas en su dispositivo 10/100-Mbps de puerto externo.

  • Reescriba COS para puertos no fiables

    El switch puede informar al teléfono IP a través de CDP (Parámetro-19) para reescribir los valores 802.1p recibidos en su dispositivo 10/100-Mbps de puerto externo.

    Nota: De manera predeterminada, todo el tráfico recibido en los puertos externos 10/100Mbps de los teléfonos IP es no fiable.

Recomendación sobre la configuración de Cisco

La información que CDP proporciona puede ser sumamente útil cuando soluciona problemas sobre temas relacionados con la conectividad de Capa 2. Habilite CDP en todos los dispositivos que soportan su funcionamiento. Ejecute los comandos siguientes:

  • Para habilitar CDP globalmente en el switch:

    Switch(config)#cdp run
  • Para habilitar CDP basado en cada puerto:

    Switch(config)#interface type slot#/port#
    Switch(config-if)#cdp enable

Configuración de lista de control

Comandos globales

Registre, habilite e ingrese el modo de configuración global para comenzar el proceso de configuración del switch.

Switch>enable
Switch#
Switch#configure terminal
Switch(Config)#

Comandos globales genéricos (en toda la empresa)

Este sección de Comandos globales enumera los comandos globales para aplicar a todos los switches en la red de la empresa del cliente.

Esta configuración contiene los comandos globales recomendados para agregar a la configuración inicial. Debe modificar los valores en el resultado antes de copiar y pegar el texto en el CLI. Ejecute estos comandos para definir aplicar la configuración global:

Vto. domain domain_name
vtp mode transparent 
spanning-tree portfast bpduguard
spanning-tree etherchannel guard misconfig
cdp run
no service pad
service password-encryption
enable secret password
clock timezone EST –5 
clock summer-time EDT recurring 1 Sun Apr 3:00 last Sun Oct 3:00
clock calendar-valid
ip subnet-zero
ip host tftpserver your_tftp_server
ip domain-name domain_name
ip name-server name_server_ip_address
ip name-server name_server_ip_address
ip classless
no ip domain-lookup
no ip http server
no logging console
no logging monitor
logging buffered 16384
logging trap notifications
logging facility local7
logging syslog_server_ip_address
logging syslog_server_ip_address
logging source-interface loopback0
service timestamps debug datetime localtime show-timezone msec
service timestamps log datetime localtime show-timezone msec
access-list 98 permit host_ip_address_of_primary_snmp_server
access-list 98 permit host_ip_address_of_secondary_snmp_server
snmp-server community public ro 98
snmp-server community laneng rw 98
snmp-server enable traps entity
snmp-server host host_address traps public
snmp-server host host_address traps public
banner motd ^CCCCC

This is a proprietary system, NOT for public or personal use.  All work products,
communications, files, data or information directly or indirectly created, input
or accessed on this system are and shall become the sole property of the company.
This system is actively monitored and accessed by the company.  By logging onto
this system, the user consents to such monitoring and access.

USE OF THIS SYSTEM WITHOUT OR IN EXCESS OF THE PROPER AUTHORIZATION MAY SUBJECT
THE USER TO DISCIPLINE AND/OR CIVIL AND CRIMINAL PENALTIES

^C
line console 0
exec-timeout 0 0
password cisco
login
transport input none
line vty 0 4
exec-timeout 0 0
password cisco
login
length 25
clock calendar-valid
ntp server ntp_server_ip_address
ntp server ntp_server_ip_address
ntp update-calendar

Los comandos globales que son específicos de cada chasis de switch

Los comandos globales en esta sección son específicos de cada chasis de switch que se inicia en la red.

Variables de configuración específica del chasis

Para configurar el fecha y hora, ejecute este comando:

Switch#clock set hh:mm:ss day month year

Para configurar el nombre del host del dispositivo, ejecute estos comandos:

Switch>enable
Switch#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Switch(config)#hostname Cat6500

Para configurar la interfaz del bucle para administración, ejecute estos comandos:

CbrCat6500(config)#interface loopback 0
Cat6500(config-if)#description Cat6000 - Loopback address and Router ID
Cat6500(config-if)#ip address ip_address subnet_mask
Cat6500(config-if)#exit

Para mostrar la revisión del software Cisco IOS del Supervisor Engine, ejecute los siguientes comandos:

Cbrcat6500#show version | include IOS
IOS (tm) MSFC Software (C6MSFC-DSV-M), Version 12.1(13)E9, EARLY DEPLOYMENT RELE
ASE SOFTWARE (fc1)
cat6500#

Para mostrar la revisión de archivo de arranque MSFC, ejecute este comando:

Cat6500#dir bootflash:
Directory of bootflash:/
 1 -rw- 1879040 Aug 19 2003 19:03:29 c6msfc-boot-mz.121-19.E1a

15990784 bytes total (14111616 bytes free

Para especificar la información de contacto del servidor SNMP y ubicación, ejecute los siguientes comandos:

Cat6500(config)#snmp-server contact contact_information
Cat6500(config)#snmp-server location location_of_device

Comandos de interfaz

Tipos de puertos funcionales Cisco

Los puertos de los switches en el software Cisco IOS son denominados interfaces. Existen dos tipos de modos de interfaces en el software Cisco IOS:

  • Interfaz enrutada de Capa 3

  • Interfaz del switch de Capa 2

La función de interfaz hace referencia a cómo se ha configurado el puerto. La configuración del puerto puede ser:

  • Interfaz enrutada

  • Interfaz virtual conmutada (SVI)

  • Puerto de acceso

  • Troncal

  • EtherChannel

  • Una combinación de estos

El tipo de interfaz hace referencia a un tipo de puerto. El tipo de puerto también puede ser:

  • FE

  • GE

  • Canal de puerto

La lista describe brevemente diferentes funciones de la interfaz del software Cisco IOS:

  • Interfaz física enrutada (predeterminada): cada interfaz en el switch es una interfaz enrutada de Capa 3 de manera predeterminada, similar a cualquier router de Cisco. La interfaz enrutada debe basarse en una subred IP única.

  • Interfaz del puerto del switch de acceso: esta función se utiliza para ubicar las interfaces en al misma VLAN. Los puertos deben pasarse de interfaces enrutadas a interfaces conmutadas.

  • SVI: una SVI puede asociarse con una VLAN que contiene puertos del switch de acceso para enrutamiento interVLAN. Configure la SVI para asociarla con una VLAN cuando quiera un trayecto o bridge entre los puertos del switch de acceso en diferentes VLAN.

  • Interfaz del puerto del switch troncal: esta función se utiliza para transportar múltiples VLAN a otro dispositivo. Los puertos deben pasarse de interfaces enrutadas a un puerto del switch troncal.

  • EtherChannel: el EtherChannel se utiliza para agrupar puertos individuales en un puerto lógico único para redundancia y balance de carga.

Recomendaciones sobre tipos de puertos funcionales Cisco

Utilice la información en esta sección para ayudar a determinar los parámetros para aplicar en las interfaces.

Nota: Algunos comandos específicos de la interfaz se incorporan donde sean posibles.

Negociación automática

No utilice la negociación automática en ninguna de estas situaciones:

  • Para los puertos que soportan dispositivos de infraestructura de red como switches y routers

  • Para otros sistemas finales no transitorios como los servidores e impresoras

Configure manualmente para velocidad y dúplex estas configuraciones de enlaces 10/100-Mbps. Las configuraciones son generalmente 100-Mbps dúplex completo:

  • Enlace 100 MB switch a switch

  • Enlace 100 MB switch a servidor

  • Enlace 100 MB switch a router

Puede configurar estos parámetros de esta manera:

Cat6500(config-if)#interface [type] mod#/port#
Cat6500(config-if)#speed 100
Cat6500(config-if)#duplex full

Cisco recomienda configuraciones de enlaces 10/100-Mbps para usuarios finales. Los trabajadores móviles y los host transitorios necesitan negociación automática, como muestra este ejemplo:

Cat6500(config-if)#interface [type] mod#/port#
Cat6500(config-if)#speed auto

El valor predeterminado en la interfaz Gigabit es negociación automática. Pero ejecute estos comandos para asegurarse que la negociación automática se encuentra habilitada. Cisco recomienda la habilitación de la negociación Gigabit:

Cat6500(config-if)#interface gigabitethernet mod#/port#
Cat6500(config-if)#no speed

Raíz del árbol de expansión

En relación al diseño de la red, identifique el switch que mejor se adapta para ser la raíz de cada VLAN. En general, seleccione un switch potente en el medio de la red. Coloque el bridge raíz en el centro de la red y conecte directamente el punte raíz a los servidores y routers. Esta configuración generalmente reduce la distancia promedio de los clientes a los servidores y routers. Consulte Problemas del protocolo del árbol de expansión y consideraciones de diseño relacionadas para obtener más información.

Para obligar a que un switch sea la raíz para una VLAN designada, ejecute este comando:

Cat6500(config)#spanning-tree vlan vlan_id root primary

Árbol de expansión Portfast

PortFast sortea el funcionamiento normal del árbol de expansión en los puertos de acceso para acelerar los retardos de conectividad inicial que se producen cuando las estaciones finales se conectan a un switch. Consulte Uso de Portfast y otros comandos para solucionar retrasos al iniciar la conectividad de la estación para obtener más información sobre Portfast.

Configure STP PortFast para todos los puertos de acceso habilitados conectados a un único host. Aquí tiene un ejemplo:

Cat6500(config-if)#interface [type] mod#/port#
Cat6500(config-if)#spanning-tree portfast
%Warning: portfast should only be enabled on ports connected to a single
 host. Connecting hubs, concentrators, switches, bridges, etc... to this
 interface  when portfast is enabled, can cause temporary bridging loops.
 Use with CAUTION
%Portfast has been configured on FastEthernet3/1 but will only have effect
when the interface is in a non-trunking mode.

UDLD

Habilite UDLD sólo en los puertos de infraestructura conectados por fibra o los cables de cobre Ethernet para supervisar la configuración física de los cables. Para activar el UDLD, ejecute los siguientes comandos:

Cat6500(config)#interface [type] mod#/port#
Cat6500(config-if)#udld enable

Información de la configuración VLAN

Configure las VLAN con estos comandos:

Cat6500(config)#vlan vlan_number
Cat6500(config-vlan)#name vlan_name
Cat6500(config-vlan)#exit
Cat6500(config)#spanning-tree vlan vlan_id
Cat6500(config)#default spanning-tree vlan vlan_id

Repita los comandos para cada VLAN y después salga. Ejecute este comando:

Cat6500(config)#exit 

Ejecute este comando para verificar todas las VLAN:

Cat6500#show vlan 

SVI enrutadas

Configure las SVI para el enrutamiento de InterVLAN. Ejecute los comandos siguientes:

Cat6500(config)#interface vlan vlan_id
Cat6500(config-if)#ip address svi_ip_address subnet_mask
Cat6500(config-if)#description interface_description
Cat6500(config-if)#no shutdown

Repita estos comandos para cada función de interfaz que contiene una SVI enrutada y luego salga. Ejecute este comando:

Cat6500(config-if)#^Z

Interfaz física simple enrutada

Ejecute estos comandos para configurar la interfaz de Capa 3 enrutada predeterminada:

Cat6500(config)#interface [type] mod#/port#
Cat6500(config-if)#ip address ip_address subnet_mask
Cat6500(config-if)#description interface_description

Repita estos comandos para cada función de interfaz que contiene una interfaz física enrutada y luego salga. Ejecute este comando:

Cat6500(config-if)#^Z

EtherChannel enrutado (L3)

Para configurar EtherChannel en las interfaces de Capa 3, ejecute los comandos en esta sección.

Configure a una interfaz de canal de puerto lógico de esta manera:

Cat6500(config)#interface port-channel port_channel_interface_#
Cat6500(config-if)#description port_channel_description
Cat6500(config-if)#ip address port_channel_ip_address subnet_mask
Cat6500(config-if)#no shutdown

Realice los pasos en esta sección para los puertos que forman un canal particular. Aplique la información restante al canal del puerto, como se muestra en este ejemplo:

Cat6500(config)#interface range [type] mod/port_range
Cat6500(config-if)#channel-group 1-64 mode [active | auto | desirable | on | passive]
Cat6500(config-if)#no shutdown
Cat6500(config-if)#^Z

Nota: Después de configurar un EtherChannel, la configuración que aplique a la interfaz del canal de puerto afecta al EtherChannel. La configuración que aplique a los puertos LAN afectará sólo al puerto LAN donde aplica la configuración.

EtherChannel(L2) con conexión troncal

Configure EtherChannel de Capa 2 para la conexión troncal de esta manera:

Cat6500(config)#interface port-channel port_channel_interface_#
Cat6500(config-if)#switchport
Cat6500(config-if)#switchport encapsulation encapsulation_type
Cat6500(config-if)#switchport trunk native vlan vlan_id
Cat6500(config-if)#no shutdown
Cat6500(config-if)#exit

Realice los pasos en esta sección sólo para los puertos que forman un canal particular.

Cat6500(config)#interface range [type] mod/port_range
Cat6500(config-if)#channel-group 1-64 mode [active | auto | desirable | on | passive]
Cat6500(config-if)#no shutdown
Cat6500(config-if)#exit

Nota: Después de configurar un EtherChannel, la configuración que aplique a la interfaz del canal de puerto afecta al EtherChannel. La configuración que aplique a los puertos LAN afectará sólo al puerto LAN donde aplica la configuración.

Verifique la creación de todos los EtherChannels y enlaces troncales. Éste es un ejemplo:

Cat6500#show etherchannel summary
Cat6500#show interface trunk

Puertos de acceso

Si la función de la interfaz es un puerto de acceso configurado como una interfaz simple, ejecute estos comandos:

Cat6500(config)#interface [type] mod#/port#
Cat6500(config-if)#switchport mode access
Cat6500(config-if)#switchport access vlan vlan_id
Cat6500(config-if)#exit

Repita estos comandos para cada función de interfaz que deba configurar como puerto de switch de Capa 2.

Si el puerto del switch se conecta a una estación final, ejecute este comando:

Cat6500(config-if)#spanning-tree portfast

Puertos troncales (Interfaz física simple)

Si la función de la interfaz es un puerto troncal configurado como una interfaz simple, ejecute estos comandos:

Cat6500(config)#interface [type] mod#/port#
Cat6500(config-if)#switchport
Cat6500(config-if)#switchport trunk encapsulation dot1q
Cat6500(config-if)#switchport trunk native vlan vlan_id
Cat6500(config-if)#no shutdown
Cat6500(config-if)#exit

Repita estos comandos para cada función de interfaz que deba configurar como un puerto troncal.

Información de la contraseña

Ejecute estos comandos para la información sobre la contraseña:

Cat6500(config)#service password-encryption
Cat6500(config)#enable secret password

CbrCat6500(config)#line con 0
Cat6500(config-line)#password password

CbrCat6500(config-line)#line vty 0 4
Cat6500(config-line)#password password
Cat6500(config-line)#^Z

Guarde la configuración

Ejecute este comando para guardar la configuración:

Cat6500#copy running-config startup-config

Nuevas funciones de software en la versión 12.1(13)E del software Cisco IOS

Consulte Configuración del soporte del teléfono IP de Cisco para más información en el soporte del teléfono IP.

Consulte Reconocimiento de aplicaciones basadas en la red y Reconocimiento de aplicaciones basadas en la red distribuidas para obtener más información acerca de Reconocimiento de aplicaciones basadas en la red (NBAR) para los puertos LAN.

Notas:

  • NBAR para los puertos LAN se soporta en el software en la MSFC2.

  • La PFC2 proporciona soporte de hardware para ACL de entrada en los puertos LAN donde configure NBAR.

  • Cuando se habilita PFC QoS, el tráfico a través de los puertos LAN donde haya configurado NBAR pasa a través de las colas de ingreso y egreso y desactiva los umbrales.

  • Cuando se activa PFC QoS, MSFC2 configura la clase de servicio (CoS) de egreso igual a egresar la precedencia IP.

  • Después de que el tráfico pasa a través de las colas de ingreso, todo el tráfico se procesa en el software en la MSFC2 en los puertos LAN donde haya configurado NBAR.

  • NBAR distribuida se encuentra disponible en las interfaces FlexWAN con el software Cisco IOS versión 12.1 (6)E y posteriores.

Las mejoras de la Exportación de datos NetFlow (NDE) incluyen:

  • Interfaz destino-fuente y máscara flujo de interfaz plena

  • NDE versión 5 de PFC2

  • Sampled NetFlow

  • Una opción para poblar estos campos adicionales en los registros NDE:

    • La dirección IP del router de salto siguiente (next hop)

    • Interfaz de ingreso SNMP ifIndex

    • Interfaz de egreso SNMP ifIndex

    • Número de sistema autónomo de origen

Consulte Configuración de NDE para obtener más información sobre las ampliaciones.

Otras ampliaciones de las funciones incluyen:

Estos son comandos son nuevos comandos:

  • standby delay minimum reload

  • link debounce

  • vlan internal allocation policy {ascending | descending}

  • system jumbomtu

  • clear catalyst6000 traffic-meter

Estos comandos son comandos mejorados:

  • show vlan internal usage: este comando fue mejorado para incluir las VLAN que utilizan las interfaces WAN.

  • show vlan id: este comando fue mejorado para soportar la entrada de una variedad de VLAN.

  • show l2protocol-tunnel: este comando fue mejorado para soportar la entrada de una VLAN ID.

La versión 12.1(13)E del software Cisco IOS soporta estas funciones de software que antes eran soportadas en el software Cisco IOS versión 12.1 EX:


Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 24330