Switches : Switches Cisco Catalyst de la serie 4500

Mejores prácticas para los switches de la Serie del Catalyst 4500/4000, 5500/5000, y 6500/6000 que ejecutan a la configuración y a la gerencia de CatOS

20 Mayo 2008 - Traducción manual
Otras Versiones: PDFpdf | Traducción Automática (31 Julio 2013) | Inglés (29 Noviembre 2007) | Comentarios

Contenidos

Introducción
Requisitos previos
      Requisitos
      Componentes utilizados
      Convenciones
      Antecedentes
Configuración básica
      Protocolos de planos de control de Catalyst
      Protocolo de troncal de VLAN
      Reducción extendida del VLAN y del MAC address
      Autonegotiation
      Ethernet de Gigabites
      Protocolo de concentración de enlace troncal dinámico
      Spanning Tree Protocol
      EtherChannel
      Detección de enlace unidireccional
      Trama Jumbo
Configuración de la administración
      Diagramas de la red
      Administración en banda
      Administración fuera de banda
      Pruebas del sistema
      Detección del sistema y del Error de hardware
      EtherChannel/dirección de los errores de enlace
      Diagnósticos de memoria intermedia del paquete del Catalyst 6500/6000
      Registro del sistema
      Protocolo de administración de red simple
      Supervisión remota
      Network Time Protocol (protocolo de hora de red)
      Protocolo de detección de Cisco
Configuración de seguridad
      Funciones de seguridad básicas
      Terminal Access Controller Access Control System
Configuración de lista de control
Discusiones relacionadas de la comunidad de soporte de Cisco
Información relacionada

Introducción

Este documento discute la implementación de los switches serie del Catalyst de Cisco en su red, específicamente el Catalyst 4500/4000, 5500/5000, y 6500/6000 de las plataformas. Las configuraciones y los comandos se discuten bajo asunción que usted está ejecutando el software General Deployment 6.4 (3) del OS del catalizador (CatOS) o más adelante. Aunque se presentan algunos aspectos del diseño, este documento no cubre el diseño para oficinas centrales total.

Requisitos previos

Requisitos

Este documento asume la familiaridad con la Referencia de comandos de la serie del Catalyst 6500, 7.6.

Aunque las referencias al material en línea público para la lectura adicional se proporcionan a través del documento, éstas son otras referencias foundational y educativas:

Componentes utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

Convenciones

Referir a las convenciones de los consejos técnicos de Cisco para más información sobre las convenciones sobre documentos.

Antecedentes

Estas soluciones representan los años de la experiencia de campo de los ingenieros de Cisco que trabajan con muchas de nuestros clientes y redes complejas más grandes. Por lo tanto, este documento acentúa las configuraciones del mundo real que hacen las redes acertadas. Este papel ofrece estas soluciones:

  • Soluciones que tienen estadístico la exposición de campo más amplio, y así el riesgo más bajo.

  • Soluciones que son simples, negociando una cierta flexibilidad para los resultados deterministas.

  • Soluciones que son fáciles de manejar y configurado por los equipos de las operaciones de la red.

  • Soluciones que promueven la alta disponibilidad y la alta estabilidad.

Este documento se divide en estas cuatro secciones:

  • Características de la configuración básica usadas por una mayoría de las redes tal como protocolo del árbol de expansión (STP) y trunking.

  • Aspectos del diseño de la configuración de la gerencia junto con el sistema y el monitoreo de evento que usa el Protocolo de administración de red simple (SNMP), el Supervisión remota (RMON), el syslog, el protocolo cisco discovery (CDP), y el protocolo Network Time Protocol (NTP).

  • Contraseñas, seguridad de puerto, seguridad física, y autentificación de la configuración de la seguridad usando el TACACS+.

  • Resúmenes de plantillas de configuración sugeridas de la lista de comprobación de la configuración.

Configuración básica

Las características desplegadas con las mayorías de las redes Catalyst se discuten en esta sección.

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. Una comprensión básica de estos protocolos es provechosa en abordar cada sección.

Tráfico de Supervisor

La mayoría de las funciones activadas en una red Catalyst requieren la cooperación de dos o más switches, de modo que debe haber un intercambio controlado de mensajes de mantenimiento, parámetros de configuración y cambios de administración. Si estos protocolos son propietario del Cisco, como el CDP, o los estándares basados, como el IEEE 802.1D (STP), todos tener ciertos elementos en el campo común cuando está implementado en la serie Catalyst.

En el reenvío de tramas básico, las tramas de datos del usuario originan de los sistemas extremos, y no cambian a su dirección de origen y dirección destino a través de los dominios conmutados de la capa 2 (L2). Los operación de búsqueda-vectores del Content Addressable Memory (CAM) en cada motor del supervisor del interruptor son poblados por un proceso de determinación de dirección de origen e indican qué puerto de salida debe remitir cada trama recibida. Si el proceso de aprendizaje de direcciones es incompleto (la destinación es desconocida o la trama es destinada a un broadcast o a una dirección Multicast), se remite (inundado) hacia fuera todos los puertos en ese VLAN.

El switch debe también reconocer qué tramas deben ser conmutadas a través del sistema y cuáles se deben dirigir al switch CPU sí mismo (también conocido como el [NMP] del Procesador de administración de red).

Se crea el plano del control del Catalyst usando las entradas especiales en la tabla CAM llamada las entradas del sistema para recibir y tráfico directo al NMP en un puerto de switch interno. De esta manera, al utilizar protocolos con direcciones de destino MAC conocidas, el tráfico de planos de control puede separarse del tráfico de datos. Publicar el comando show CAM system en un switch de confirmar esto, como se muestra:

>show cam system

* = Static Entry. + = Permanent Entry. # = System Entry. R = Router Entry.
X = Port Security Entry
VLAN  Dest MAC/Route Des    [CoS]  Destination Ports or VCs / [Protocol Type]
----  ------------------    -----  -------------------------------------------
1     00-d0-ff-88-cb-ff  #          1/3

!--- NMP internal port.

1     01-00-0c-cc-cc-cc  #          1/3

!--- CDP and so on.

1     01-00-0c-cc-cc-cd  #          1/3

!--- Cisco STP.

1     01-80-c2-00-00-00  #          1/3

!--- IEEE STP.

1     01-80-c2-00-00-01  #          1/3

!--- IEEE flow control.

1     00-03-6b-51-e1-82 R#          15/1

!--- Multilayer Switch Feature Card (MSFC) router.

...

Cisco tiene un rango reservado del MAC Ethernet y de las direcciones de protocolo, como se muestra. Cada uno se cubre más adelante en este documento. Sin embargo, un resumen se presenta en este vector para la conveniencia.

Función

Tipo de protocolo SNAP HDLC

MAC de multidifusión de destino

Protocolo de agrupamiento de puertos (PAgP)

0x0104

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

Árbol de expansión PVSTP+

0x010b

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

Bridge VLAN

0x010c

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

Detección de enlace unidireccional (UDLD)

0x0111

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

Protocolo de detección de Cisco

0x2000

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

Concentración de enlaces dinámica (DTP)

0x2004

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

Uplink Fast de STP

0x200a

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

Árbol de expansión IEEE 802.1d

N/A - DSAP 42 SSAP 42

01-80-c2-00-00-00

Enlace entre switches(ISL)

N/A

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

Red virtual con conexión troncal (VTP)

0x2003

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

Pausa IEEE 802.3x

N/A - DSAP 81 SSAP 80

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

Las mayorías de los protocolos de control Cisco utilizan un encapsulado SNAP de IEEE 802.3, incluyendo LLC 0xAAAA03, el OUI 0x00000C, que se puede ver en un rastro del analizador LAN. Otras propiedades en común de estos protocolos incluyen:

  • Estos protocolos suponen conectividad de punto a punto. Observar que el uso deliberado de las direcciones de destino de Multicast habilita dos Catalyst transparente para comunicarse sobre los switches del no Cisco, como dispositivos que no entiendan e interceptar las tramas las inunda simplemente. Sin embargo, las conexiones de punto a multipunto a través de los ambientes multi-vendor pueden dar lugar a la conducta incoherente y deben ser evitadas generalmente.

  • Estos protocolos terminan en el routers de la capa 3 (L3); funcionan solamente dentro de un dominio conmutado.

  • Estos protocolos reciben el prioritization sobre los datos del usuario por el circuito específico de la aplicación del ingreso (ASIC) que procesa y programar.

Después de la introducción de las direcciones destino del protocolo de control, la dirección de origen debe también ser descrita para lo completo. Los protocolos de switches utilizan una dirección MAC tomada de un banco de direcciones suministradas por EPROM en el chasis. Publicar el comando show module para visualizar los intervalos de direcciones disponibles para cada módulo cuando las fuentes trafica por ejemplo el Bridge Protocol Data Units del STP (BPDU) o las tramas del ISL.

>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

!--- MACs for sourcing traffic.

...
VLAN 1

VLAN 1

VLAN 1 tiene un significado especial en las redes Catalyst.

El Motor de Supervisor de Catalyst utiliza siempre el VLAN predeterminado, VLAN1, para marcar un número de control y de protocolos de administración con etiqueta cuando trunking, tal como CDP, VTP y PAgP. Todos los puertos, incluyendo la interfaz interna del sc0, son configurados por el valor por defecto para ser los miembros de VLAN 1. Todos los troncales llevan el VLAN1 por el valor por defecto, y en las versiones del software CatOS anterior de 5.4, él no eran posibles bloquear los datos del usuario en el VLAN1.

Estas definiciones son necesarias para ayudar a clarificar algunos términos bien-usados en las Conexiones de redes Catalyst:

  • El VLAN de administración es donde reside el sc0; esta VLAN se puede cambiar.

  • El VLAN nativo se define como el VLAN a el cual un puerto vuelve cuando no trunking, y es el VLAN sin etiqueta en un tronco 802.1q.

Éstas son varias buenas razones para ajustar una red y para alterar el comportamiento de los puertos en el VLAN1:

  • Cuando el diámetro del VLAN1, como cualquier otro VLAN, consigue bastante grande ser un riesgo a la estabilidad (determinado de una perspectiva del STP) necesita ser podada detrás. Esto se discute más detalladamente en la sección de la administración en la banda de este documento.

  • Los datos planos del control sobre el VLAN1 se deben guardar a parte de los datos del usuario para simplificar la localización de averías y maximizar los ciclos de la CPU disponibles.

  • Los bucles L2 en el VLAN1 deben ser evitados cuando las redes del de múltiples capas-campus se diseñan sin el STP, y el trunking todavía se requiere a la capa de acceso si hay VLAN múltiples y subredes del IP. Para esto, verifique VLAN 1 desde los puertos de enlace troncal.

Resumiendo, observar esta información sobre los troncales:

  • Actualizaciones CDP, VTP, y PAgP son siempre reenviadas en enlaces troncales con un indicador VLAN 1 Éste es el caso aunque VLAN1 está borró de los troncales y no es el VLAN nativo. Si es el VLAN1 borró para los datos del usuario, éstos no es ningún impacto en el tráfico del plano del control que todavía se envía usando el VLAN1.

  • En un troncal ISL, los paquetes DTP se envían en el VLAN1. Éste es el caso aunque VLAN1 está borró del troncal y es no más el VLAN nativo. En un tronco 802.1q, los paquetes DTP se envían en el VLAN nativo. Éste es el caso aunque que el VLAN nativo está borró del troncal.

  • En el PVST+, los 802.1Q IEEE BPDU se remiten untagged en el Common Spanning Tree VLAN1 para la interoperabilidad con los otros vendedores, a menos que sea el VLAN1 borrara del troncal. Éste es el caso sin importar la configuración de VLAN nativa. Cisco PVST+ BPDU se envía y se marca con etiqueta para el resto de los VLAN. Referir a la sección de protocolo del árbol de expansión en este documento para más detalles.

  • el árbol de expansión múltiple 802.1s (MST) BPDU se envía siempre en el VLAN1 en los troncales ISL y 802.1Q. Esto aplica aun cuando el VLAN1 está borró de los troncales.

  • No claro o invalidar el VLAN1 en los troncales entre los bridges del MST y los bridges del PVST+. Pero, en el caso que el VLAN1 es lisiado, el bridge del MST debe convertirse en raíz para que todos los VLAN para evitar el bridge del MST que pone sus puertos del límite en el estado de la raíz contraria. Referir al protocolo múltiple del árbol de expansión que entiende (802.1s) para los detalles.

Protocolo de troncal de VLAN

Antes de que usted cree los VLAN, determinar a modo VTP que se utilizará en la red. VTP permite que los cambios de configuración de VLAN se realicen centralmente en uno o más switches. Todos esos cambios se distribuyen automáticamente a todos los otros switches en el dominio.

Información operativa general

El VTP es un protocolo de mensajería L2 que mantiene la congruencia en la configuración de VLAN. El VTP maneja la adición, la cancelacíon, y la retitulación de los VLAN en a en función de toda la red. VTP minimiza los errores e inconsistencias de configuración que pueden provocar una cantidad de problemas, tales como nombres de VLAN duplicados, especificaciones incorrectas del tipo de VLAN y violaciones de seguridad. La base de datos de la VLAN es un archivo binario y se almacena en la NVRAM en servidores VTP de forma separada al archivo de configuración.

El protocolo VTP se comunica entre switches por medio de una dirección MAC de multidifusión de destino Ethernet (01-00-0c-cc-cc-cc) y el protocolo SNAP HDLC tipo Ox2003. No trabaja sobre los puertos no troncales (el VTP es un payload del ISL o de 802.1Q), así que los mensajes no pueden ser enviados hasta que el DTP ha traído el troncal en línea.

Los Tipos de mensaje incluyen los anuncios de resumen cada cinco minutos, anuncios del subconjunto y anuncios de la petición cuando hay cambios, y ensamblan cuando los recortes VTP son habilitados. El número de revisiones de la configuración VTP se incrementa de uno en uno con cada cambio en un servidor, que a su vez propaga la nueva tabla en todo el dominio.

Si se elimina una VLAN, los puertos que alguna vez fueron miembros de esa VLAN se colocan en estado de inactividad. Semejantemente, si un switch en el modo cliente no puede recibir la tabla de VLAN del VTP en el arranque inicial (de un servidor VTP o de otro vtp client), todos los puertos en los VLAN con excepción del VLAN predeterminado 1 se desactivan.

Este vector proporciona a un resumen comparativo de la característica para los varios modos VTP:

Función

Servidor

Cliente

Transparente

Off1

Mensajes VTP fuente

No

No

Escuchar mensajes VTP

No

No

Mensajes VTP delanteros

No

Crear VLAN

No

Sí (sólo de importancia local)

Sí (sólo de importancia local)

Recordar VLAN

No

Sí (sólo de importancia local)

Sí (sólo de importancia local)

En el modo transparente de VTP, se no hacen caso las actualizaciones del VTP (quitan a la dirección MAC de multidifusión del VTP del CAM del sistema que se utiliza normalmente para tomar las tramas de control y para dirigirlas al Supervisor Engine). Pues el protocolo utiliza a dirección Multicast, un switch en el modo transparente (u otro switch de proveedor) inunda simplemente la trama a otros switches Cisco en el dominio.

1 versión del software CatOS 7.1 introduce la opción para invalidar el VTP con el uso del modo desconectado. En el modo desconectado del VTP, el switch se comporta de una manera que sea muy similar al modo transparente de VTP, salvo que el modo desconectado también suprime la expedición de las actualizaciones del VTP.

Este vector proporciona a un resumen de la configuración inicial:

Función

Valor predeterminado

Nombre de dominio de VTP

Nulo

modo VTP

Servidor

Versión de VTP

La versión 1 es habilitada

Contraseña VTP

Ninguno

Recorte VTP

desactivado

La versión de VTP 2 (VTPv2) incluye esta flexibilidad funcional. Sin embargo, no es interoperable con la versión de VTP 1 (VTPv1):

  • Soporte Token Ring

  • Soporte VTP desconocido; los switches ahora propagan los valores que no pueden analizar.

  • modo transparente Versión-dependiente; el modo transparente controla no más el Domain Name. Esto habilita el soporte de más de un dominio a través de un dominio transparente.

  • Propagación del número de versión; si el VTPv2 es posible en todos los switches, todo puede ser habilitado con la configuración de un un solo switch.

Referir al protocolo de troncal VLAN que entiende y de configuración (VTP) para más información.

Versión de VTP 3

La versión del software CatOS 8.1 introduce el soporte para la versión de VTP 3 (VTPv3). El VTPv3 proporciona a los realces sobre las versiones existentes. Estos realces permiten:

  • Soporte para los VLAN extendidos

  • Soporte para la creación y anuncio de los VLAN privados

  • El soporte para los casos del VLAN y el MST que asocian la propagación cita como ejemplo (que se soportan en la versión 8.3 de CatOS)

  • Autenticación de servidor mejorada

  • Protección contra la inserción accidental de la base de datos “incorrecta” en un dominio VTP

  • Interacción con el VTPv1 y el VTPv2

  • La capacidad de ser configurado sobre una base por puerto

Una de las diferencias principales entre la implementación del VTPv3 y la versión anterior es la introducción de un servidor primario del VTP. Idealmente, debe haber solamente un servidor primario en un dominio del VTPv3, si el dominio no se reparte. Cualquier cambio que usted realice al dominio VTP se debe ejecutar en el servidor primario del VTP para para ser propagado al dominio VTP. Puede haber los servidores múltiples dentro de un dominio del VTPv3, que también se conocen como servidores secundarios. Cuando un switch se configura para ser un servidor, el switch se convierte en servidor secundario por el valor por defecto. El servidor secundario puede salvar la configuración del dominio pero no puede modificar la configuración. Un servidor secundario puede convertirse en el servidor primario con una adquisición exitosa del switch.

Los switches que ejecutan el VTPv3 validan solamente las bases de datos VTP con un número de revisión más alto que el servidor del primario actual. Este proceso diferencia perceptiblemente del VTPv1 y del VTPv2, en los cuales un switch valida siempre una configuración superior de un vecino en el mismo dominio. Este cambio con el VTPv3 proporciona a la protección. Un nuevo switch que se introduce en la red con un número de la revisión VTP mayor no puede sobregrabar la configuración de VLAN del dominio entero.

El VTPv3 también introduce un realce a cómo el VTP maneja las contraseñas. Si usted utiliza la opción ocultada de la configuración de la palabra de paso para configurar una contraseña según lo “ocultado”, estos elementos ocurren:

  • La contraseña no aparece en el sólo texto en la configuración. El formato hexadecimal secreto de la contraseña se salva en la configuración.

  • Si usted intenta configurar el switch como servidor primario, le incitan para la contraseña. Si la su contraseña corresponde con la contraseña secreta, el switch se convierte en un servidor primario, que permite que usted configure el dominio.

Nota: Es importante observar que el servidor primario es solamente necesario cuando usted necesita modificar la configuración VTP para cualquier caso. Un dominio VTP puede funcionar sin el servidor primario activo porque los servidores secundarios aseguran la persistencia de las recargas del excedente de la configuración. El estado del servidor primario se sale por estas razones:

  • Una recarga del switch

  • Una alta disponibilidad del intercambio entre el activo y los motores del supervisor redundante

  • Una toma de posesión de otro servidor

  • Un cambio en la configuración del modo

  • Cualquier cambio de configuración del dominio VTP, tal como un cambio en:

    • Versión

    • Domain Name

    • Contraseña de dominio

El VTPv3 también permite que los switches participen en las instancias múltiples del VTP. En este caso, el mismo switch puede ser el servidor VTP para un caso y un cliente para otro caso porque los modos VTP son específicos a diversos casos del VTP. Por ejemplo, un switch puede funcionar en el modo transparente para un caso del MST mientras que el switch se configura en el modo de servidor para un caso del VLAN.

En términos de interacción con el VTPv1 y el VTPv2, el comportamiento predeterminado en todas las versiones del VTP ha sido que las versiones anteriores del VTP caen simplemente las actualizaciones de la nueva versión. A menos que los switches del VTPv1 y del VTPv2 estén en el modo transparente, se caen todas las actualizaciones del VTPv3. Por otra parte, después de que los switches del VTPv3 reciban una trama del VTPv1 o del VTPv2 de la herencia en un troncal, el paso de los switches una versión scaled-down de su actualización de base de datos a los switches del VTPv1 y del VTPv2. Sin embargo, este intercambio de información es unidireccional en que no se valida ningunas actualizaciones de los switches del VTPv1 y del VTPv2 por los switches del VTPv3. En las conexiones de tronco, los switches del VTPv3 continúan enviando las actualizaciones scaled-down tan bien como las actualizaciones hechas y derechas del VTPv3 para abastecer a la existencia de los vecinos del VTPv2 y del VTPv3 a través de los puertos troncales.

Para proporcionar al soporte del VTPv3 para los VLAN extendidos, el formato del VLAN database, en las cuales el VTP asigna 70 bytes por el VLAN, se cambia. El cambio permite la codificación de los valores no predeterminados solamente, en vez de llevar de los campos sin modificar para los protocolos heredados. Debido a este cambio, el soporte a VLAN 4K es los tamaños del VLAN database que resulta.

Recomendación

No hay una recomendación específica acerca de si se debe utilizar los modos cliente/servidor de VTP o el modo transparente de VTP. Algunos clientes prefieren la facilidad de administración del modo cliente/servidor VTP a pesar de algunas consideraciones conocidas más adelante. La recomendación es tener dos switches en cada dominio para redundancia, típicamente los dos switches de capa de distribución del modo de servidor. El resto de los switches en el dominio se debe fijar al modo cliente. Cuando usted implementa a modo cliente/servidor con el uso del VTPv2, ser atento que un número de revisión más alto está validado siempre en el mismo dominio VTP. Si un switch que se configura en el vtp client o el modo de servidor se introduce en el dominio VTP y tiene un número de revisión más alto que los servidores VTP existentes, éste sobregraba el VLAN database dentro del dominio VTP. Si el cambio de configuración es inintencional y se borran los VLAN, el sobregrabar puede causar una interrupción importante en la red. Para asegurarse de que el cliente o los switches del servidor tenga siempre un número de revisión de la configuración que sea más bajo que el del servidor, cambiar el Domain Name del cliente VTP algo con excepción del nombre estándar. Entonces invertir de nuevo al estándar. Esta acción fija la revisión de la configuración en el cliente a 0.

Hay pros y contra a la capacidad de VTP de realizar los cambios fácilmente en una red. Muchas empresas prefieren el método cauteloso de modo transparente de VTP por estas razones:

  • Anima la buena práctica del control de cambios, pues el requisito para modificar un VLAN en un switch o un puerto troncal tiene que ser considerado un switch al mismo tiempo.

  • Limita el riesgo de un error del administrador que afecte el dominio entero, tal como la cancelacíon de un VLAN por el accidente.

  • No hay riesgo que un nuevo switch introdujo en la red con un número de la revisión VTP mayor puede sobregrabar la configuración de VLAN entera del dominio.

  • Anima a los VLAN que sean podados de los troncales que se ejecutan a los switches que no tienen puertos en ese VLAN. Esto hace la inundación de trama anchura de banda-más eficiente. Los recortes manuales son también beneficiosos porque reducen el diámetro del árbol de expansión (véase la sección del DTP de este documento).

  • El rango extendido del VLAN en CatOS 6.x y CatOS 7.x, números 1025 a 4094, se puede configurar solamente de esta manera. Para más información, ver el VLAN y la sección extendidos de la reducción del MAC address de este documento.

  • El modo transparente de VTP se soporta en el Campus Manager 3.1, Cisco Works 2000 de la parte de. Se ha quitado la vieja restricción que requirió por lo menos un servidor en un dominio VTP.

Ejemplos de comandos de VTP

Comentarios

set vtp domain name password x

El CDP controla los nombres para ayudar a controlar para saber si hay miscabling entre los dominios. El mero uso de una contraseña sirve para prevenir cambios involuntarios. Tenga cuidado con la mayúsculas y minúsculas en los nombres y con los espacios al copiar y pegar.

set vtp mode transparent

 

set vlan vlan number name name

Por cada switch que tiene puertos en la VLAN.

set trunk mod/port vlan range

Habilita al tronco para llevar los VLAN cuando sea necesario - el valor por defecto es todos los VLAN.

clear trunk mod/port vlan range

Limita a diámetro STP por los recortes manuales, por ejemplo en los troncales de la capa de distribución a la capa de acceso, donde no existe el VLAN.

Nota: Especificar los VLAN con el comando set agrega solamente los VLAN, y no claro ellos. Por ejemplo, el comando set trunk x/y 1-10 no fija la lista permitida apenas a VLAN 1-10. Publicar el comando clear trunk x/y 11-1005 para alcanzar el resultado deseado.

Aunque la conmutación de Token Ring está fuera del alcance de este documento, observar que el modo transparente de VTP no está recomendado para las redes del TR-ISL. La base para la conmutación de Token Ring es que la totalidad del dominio forma un solo bridge distribuido del purto múltiple, así que cada switch debe tener la misma información de VLAN.

Otras opciones

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

El VTPv3 proporciona a la capacidad de implementar un control más apretado de la autentificación y de la revisión de la configuración. El VTPv3 esencialmente proporciona al mismo nivel de funciones, pero con más seguridad mejorada, como ofertas del modo transparente VTPv1/VTPv2. Además, el VTPv3 es parcialmente compatible con las versiones de VTP de la herencia.

Las ventajas de podar los VLAN para reducir inundar de la trama innecesaria se abogan en este documento. El comando enable de poda del vtp de Theset poda los VLAN automáticamente, que para la inundación de trama no efectiva donde él no está necesario. El distinto al manual VLAN Pruning, los recortes automáticos no limita el diámetro del árbol de expansión.

De CatOS 5.1, los switches de Catalyst pueden asociar 802.1Q los números VLAN 1000 mayor que a los números del ISL VLAN. En CatOS 6.x, el Catalyst 6500/6000 conmuta el soporte 4096 VLAN de acuerdo con el estándar del IEEE 802.1Q. Estos VLAN se ordenan en estos tres rangos, sólo algunos de los cuales se propagan a otros switches en la red con el VTP:

  • normal-rango VLAN: 1-1001

  • alcance extendido VLAN: 1025-4094 (puede ser propagado solamente por VTPv3)

  • reservado-rango VLAN: 0, 1002-1024, 4095

El IEEE ha producido una arquitectura basada en estándares para lograr los resultados similares como VTP. Como miembro del protocolo generic attribute registration 802.1Q (GARP), el protocolo generic vlan registration (GVRP) permite la interoperabilidad de la administración de VLAN entre los vendedores, pero está fuera del alcance de este documento.

Nota: CatOS 7.x introduce la opción para fijar VTP al modo desconectado, un modo muy similar a transparente. Sin embargo, el switch no remite las tramas del VTP. Esto puede ser útil en algunos diseños cuando trunking a los switches fuera de su control administrativo.

Reducción extendida del VLAN y del MAC address

La característica de reducción del MAC address habilita la identificación del VLAN del alcance extendido. El enablement de la reducción del MAC address invalida el pool de los direccionamientos del MAC que se utilizan para el árbol de expansión del VLAN y deja un solo MAC address. Este MAC address identifica el switch. La versión del software CatOS 6.1 (1) introduce el soporte de la reducción del MAC address para que los switches del Catalyst 6500/6000 y del Catalyst 4500/4000 soporten 4096 VLAN de acuerdo con el estándar del IEEE 802.1Q.

Información general de funcionamiento

Los protocolos del switch utilizan un MAC address que se tome de una batería de las direcciones disponibles a que un EPROM en el chasis proporciona como parte de los identificadores de bridge para los VLAN que se ejecutan bajo el PVST+. El Catalyst 6500/6000 y el Catalyst 4500/4000 conmuta los direccionamientos del MAC del soporte 1024 o 64, que depende del tipo del chasis.

Los switches de Catalyst con los direccionamientos 1024 del MAC no habilitan la reducción del MAC address por el valor por defecto. Los direccionamientos del MAC se afectan un aparato secuencialmente. El primer MAC address en el rango se asigna al VLAN1. El segundo MAC address en el rango se asigna al VLAN 2, y así sucesivamente. Esto habilita los switches para soportar 1024 VLAN con cada VLAN usando un identificador de bridge único.

Tipo de chasis

Direccionamiento del 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, CISCO7613

641

1 reducción del MAC address es habilitada por el valor por defecto para los switches que tienen 64 direccionamientos del MAC, y la característica no puede ser lisiada.

Para los switches del Serie Catalyst con los direccionamientos 1024 del MAC, un enablement de la reducción del MAC address permite el soporte de 4096 VLAN que se ejecuten bajo el PVST+ o 16 casos de la Multiple Instance STP (MISTP) para tener Identificadores únicos sin un aumento en el número de los direccionamientos del MAC que se requieren en el switch. La reducción del MAC address reduce el número de los direccionamientos del MAC que son requeridos por el STP a partir del uno por el caso del VLAN o del MISTP a uno por el switch.

Esta figura muestra que la reducción del MAC address del identificador de bridge no es habilitada. El identificador de bridge consiste en la prioridad de bridge del byte del a2 y un MAC address de 6 bytes:

103a.gif

La reducción del MAC address modifica la porción del identificador de bridge del STP del BPDU. El campo de los bytes de prioridad de la original 2 está partido en dos campos. Esta fractura da lugar a un campo de la prioridad de bridge de 4 dígitos binarios y a una extensión del ID del sistema de 12 dígitos binarios que permita la enumeración del VLAN de 0 a 4095.

103b.gif

Cuando usted tiene reducción del MAC address habilitada en los switches de Catalyst para leverage los VLAN de alcances extendidos, habilitar la reducción del MAC address en todos los switches dentro del mismo dominio STP. Este paso de progresión es necesario para mantener los cálculos de raíz STP en todos los switches constantes. Después de que usted habilite la reducción del MAC address, la prioridad de bridge de raíz se convierte en un múltiplo de 4096 más el VLAN ID. Los switches sin la reducción del MAC address pueden demandar la raíz inadvertidamente porque estos switches tienen una granularidad más fina en la selección de la identificación del bridge

Pautas de configuración

Usted debe seguir ciertas guías de consulta cuando usted configura el rango extendido del VLAN. El switch puede afectar un aparato un bloque de los VLAN del alcance extendido para los propósitos internos. Por ejemplo, el switch puede afectar un aparato los VLAN para los puertos enrutados o doblar los módulos de WAN. La asignación del bloque de los VLAN empieza con VLAN 1006 y va siempre para arriba. Si usted tiene algunos VLAN dentro del rango que el módulo de WAN de la flexión requiere, todos los VLAN requeridos no se afectan un aparato porque los VLAN nunca se afectan un aparato del área del VLAN de usuario. Publicar el comando show vlan o el comando show vlan summary en un switch para visualizar los VLAN user-assigned e internos.

>show vlan summary

Current Internal Vlan Allocation Policy - Ascending

Vlan status    Count  Vlans
-------------  -----  ------------------------------------------
VTP Active         7   1,17,174,1002-1005

Internal           7   1006-1011,1016

!--- These are internal VLANs.

>show vlan
---- -------------------------------- --------- ------- --------

1    default                          active    7       4/1-48


!--- Output suppressed.


1006 Online Diagnostic Vlan1          active    0       internal
1007 Online Diagnostic Vlan2          active    0       internal
1008 Online Diagnostic Vlan3          active    0       internal
1009 Voice Internal Vlan              active    0       internal
1010 Dtp Vlan                         active    0       internal
1011 Private Vlan Internal Vlan       suspend   0       internal
1016 Online SP-RP Ping Vlan           active    0       internal

!--- These are internal VLANs.

Además, antes de que usted utilice el alcance extendido VLAN, usted debe borrar cualquier mappings existente 802.1Q-to-ISL. También, en las versiones anterior que el VTPv3, usted debe configurar estáticamente el VLAN extendido en cada switch con el uso del modo transparente de VTP. Referir a la sección de las guías de consulta de la configuración de VLAN del Alcance Extendido de configurar los VLAN para más información.

Nota: En el software que es anterior que la versión de software 8.1 (1), usted no puede configurar el nombre del VLAN para el alcance extendido VLAN. Esta capacidad es independiente de cualquier versión de VTP o modo.

Recomendación

Intentar mantener una configuración de reducción constante del MAC address dentro del mismo dominio STP. Sin embargo, la aplicación de la reducción del MAC address en todos los dispositivos de red puede ser impráctica cuando los chasis nuevos con 64 direccionamientos del MAC se introducen al dominio STP. La reducción del MAC address es habilitada por el valor por defecto para los switches que tienen 64 direccionamientos del MAC, y la característica no puede ser lisiada. Entender que, cuando dos sistemas se configuran con la misma prioridad del atravesar-árbol, el sistema sin la reducción del MAC address tiene una prioridad mejor del atravesar-árbol. Publicar este comando para habilitar o invalidar la reducción del MAC address:

set spantree macreduction enable | disable

La asignación de los VLAN internos está en el orden ascendente y empieza VLAN 1006. Asignar los VLAN de usuarios como cerca de VLAN 4094 como posible para evitar los conflictos entre los VLAN de usuarios y los VLAN internos. Con el Catalyst 6500 switches que ejecuta el software del sistema de Cisco IOS®, usted puede configurar la asignación de VLAN interna en el orden descendente. El equivalente de la interfaz de la línea de comandos (CLI) para el software CatOS no se soporta oficialmente.

Autonegotiation

Ethernet/Fast Ethernet

El autonegotiation es una función optativa del estándar del Fast Ethernet (FE) de IEEE (802.3u) que habilita los dispositivos para intercambiar automáticamente la información sobre una conexión con las capacidades de la velocidad y dúplex. El autonegotiation funciona en el Layer 1 (L1), y apunta los puertos de capa de acceso en donde el transient users tal como PC conecta con la red.

Información operativa general

La mayoría de la causa común de los problemas de desempeño en las conexiones de 10/100 ethernet mbps ocurre cuando un puerto en la conexión funciona en half-duplex mientras que el otro está en full-duplex. Esto sucede de vez en cuando cuando un o ambo puertos en una conexión se reajustan y el proceso de negociación automática no hace a ambos socios de enlace tener la misma configuración. También sucede cuando los usuarios vuelven a configurar sólo un lado de un enlace y se olvidan de volver a configurar el otro lado. Los síntomas típicos de esto están aumentando la Secuencia de verificación de tramas (FCS), la verificación por redundancia cíclica (CRC), la alineación, o los contadores de fragmentos de tramas minúsculos en el switch.

El autonegotiation se discute detalladamente en estos documentos. Estos documentos incluyen las explicaciones de cómo el autonegotiation trabaja y opción de configuración.

Un concepto erróneo común sobre el autonegotiation es que es posible configurar manualmente a un socio de enlace para 100 Mbps full-duplex y autonegociar a full-duplex con el otro socio de enlace. De hecho, una tentativa de hacer esto da lugar a una discordancia dúplex. Ésta es una consecuencia de un autonegotiating del socio de enlace, no viendo ningunos parámetros de negociación automáticas del otro socio de enlace, y omitiendo half-duplex.

La mayoría de los módulos de los Catalyst de Ethernet soportan 10/100 Mbps y mitad/del full-duplex, pero el comando show port capabilities mod/port confirma esto.

FEFI

El Far End Fault Indication (FEFI) protege 100BASE-FX (fibra) y las interfaces Gigabit, mientras que el autonegotiation protege 100BASE-TX (cobre) contra las fallas relacionadas con capa física/señalización.

Una falla extrema es un error en el enlace que una estación puede detectar mientras que la otra no; por ejemplo, el cable TX desconectado. En este ejemplo, la estación remitente podría inmóvil recibir los datos válidos y detectar que la conexión es buena con el link-integrity-monitor. No detecta que su transmisión no está siendo recibida por la otra estación. Una estación 100BASE-FX que detecta a tal falla remota puede modificar su secuencia ociosa transmitida para enviar un dígito-modelo especial (designado el patrón ocioso del FEFI) para informar al vecino la falla remota; el modelo FEFI-IDLE acciona posteriormente un apagar del puerto remoto (errdisable). Referir a la sección del UDLD de este documento para más información sobre la protección contra fallas.

El FEFI es soportado por este hardware y estos módulos:

  • Catalyst 5500/5000: WS-X5201R, WS-X5305, WS-X5236, WS-X5237, WS-U5538 y WS-U5539

  • Catalyst 6500/6000 y 4500/4000: Todos los módulos 100BASE-FX y módulos del GE

Recomendación

Si configurar el autonegotiation en 10/100 de las conexiones o a la velocidad y dúplex dura del código depende en última instancia del tipo de socio de enlace o de dispositivo extremo usted ha conectado con un puerto del switch Catalyst. El autonegotiation entre los dispositivos finales y los switches de Catalyst trabaja generalmente bien, y los switches de Catalyst son obedientes con la especificación de IEEE 802.3u. Sin embargo, los problemas pueden resultar cuando no se conforma el NIC o los switches de proveedor exactamente. La incompatibilidad del hardware y otras ediciones pueden también existir como resultado de las funciones avanzadas específicas del proveedor, tales como automóvil-polaridad o integridad del cableado, que no se describen en la especificación de IEEE 802.3u para 10/100 autonegotiation del Mbps. Referir al aviso importante: Problema de desempeño con Intel Pro/1000T NIC que conecta con el CAT4K/6K por un ejemplo de esto.

Anticipar que habrá algunas situaciones que requieren el ordenador principal, la velocidad de puerto, y el duplex que se fijará. En general, siga estos pasos básicos de solución de problemas:

  • Aseegurarse que o el autonegotiation está configurado en los ambos lados de la conexión o la codificación dura está configurada en los ambos lados.

  • Controlar las release notes de CatOS para saber si hay advertencias comunes.

  • Verificar la versión del controlador NIC o el sistema operativo que usted se está ejecutando, como el controlador más último o la corrección se requiere a menudo.

En general, intento para utilizar el autonegotiation primero para cualquier tipo de socio de enlace. Hay beneficios evidentes al autonegotiation de configuración para los dispositivos transitorios como los laptopes. Idealmente, el autonegotiation también trabaja bien con los dispositivos no-transitorios tales como servidores y sitios de trabajo fijos o del switch a switch y del switch-a-router. Por algunas de las razones mencionadas, las ediciones de la negociación pueden presentarse. En estos casos, seguir los pasos para la resolución de problemas básicos delineados en las conexiones del TAC proporcionadas.

Si la velocidad de puerto se fija al automóvil en un ethernet mbps de 10/100 portuario, ambo se autonegocia la velocidad y dúplex. Publicar este comando para fijar el puerto al automóvil:

set port speed port range auto

!--- This is the default.

Si es duro la codificación el puerto, publica estos comandos configuration:

set port speed port range 10 | 100
set port duplex port range full | half

En CatOS 8.3 y posterior, Cisco ha introducido auto-10-100 la palabra clave opcional. Utilizar auto-10-100 la palabra clave en los puertos que soportan las velocidades de 10/100/1000 Mbps pero donde está indeseable el autonegotiation al Mbps 1000. El uso auto-10-100 de la palabra clave hace que el puerto se comporta de la misma forma que un puerto 10/100-Mbps que tenga la velocidad fijada al automóvil. La velocidad y dúplex se negocia para los puertos 10/100-Mbps solamente, y la velocidad 1000-Mbps no participa en la negociación.

set port speed port_range auto-10-100

Otras opciones

Cuando no se utiliza ningún autonegotiation entre los switches, la indicación de falla L1 se puede también perder para ciertos problemas. Es provechoso utilizar los protocolos L2 para aumentar la detección de falla, tal como UDLD agresivo.

Ethernet de Gigabites

El Gigabit Ethernet (GE) tiene un procedimiento de autonegociación (el IEEE 802.3Z) que sea más extenso que ése para 10/100 ethernet mbps y se utiliza para intercambiar los parámetros, la información de falla remota, y la información reguladores de corriente del duplex (aunque la serie Catalyst GE vira solamente a modo dúplex completo del soporte hacia el lado de babor).

Nota: 802.3z ha sido reemplazado por espec. del 802.3:2000 de IEEE. Referir a las normas IEEE en la línea suscripción de normas del LAN/MAN: Archivosleavingcisco.com para más información.

Información operativa general

La negociación de puerto del GE es habilitada por el valor por defecto, y los puertos en los ambos extremos de una conexión del GE deben tener la misma configuración. Desemejante del FE, la conexión del GE no sube si el fijar del autonegotiation diferencia en los puertos en cada final de la conexión. Sin embargo, la única condición que se requiere para que un puerto autonegotiation-lisiado conecte para arriba es una señal válida del gigabit del extremo lejano. Este comportamiento es independiente de la configuración de la negociación automática del extremo lejano. Por ejemplo, asumir que hay dos dispositivos, A y B. Cada dispositivo puede tener autonegotiation habilitado o invalidado. Este vector es una lista de las configuraciones posibles y de los estados respectivos de la conexión:

Negociación

B habilitada

B inhabilitada

A habilitado

encima en de los ambos lados

Una llanura, B para arriba

A desactivado

Un ascendente, B abajo

encima en de los ambos lados

En el GE, la sincronización y el autonegotiation (si son habilitados) se realizan sobre el lanzamiento de la conexión con el uso de una secuencia especial de las palabras del código reservadas de la conexión.

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

La vida de una conexión del GE se puede caracterizar de esta manera:

103c.gif

Una pérdida de sincronización significa que el MAC detecta una conexión abajo. La pérdida de sincronización se aplica si el autonegotiation es habilitado o lisiado. La sincronización se pierde bajo ciertas condiciones falladas, tales como el recibo de tres palabras inválidas en la sucesión. Si esta condición persiste para el ms 10, “sincronizar una condición del fall” se afirma y la conexión se cambia al estado del link_down. Después de que se pierda la sincronización, otro tres válidos consecutivos huelgan son necesarios para resincronizar. Otros eventos catastróficos, tales como una pérdida de reciben la señal (del Rx), causan un acontecimiento de la conexión abajo.

El autonegotiation es una parte de el proceso de la conexión. Cuando la conexión está para arriba, el autonegotiation encima. Sin embargo, el switch todavía monitorea el estatus de la conexión. Si el autonegotiation es lisiado en un puerto, la fase del “autoneg” es no más una opción.

La especificación de cobre del GE (1000BASE-T) soporta el autonegotiation con un intercambio siguiente de la paginación. El intercambio siguiente de la paginación permite el autonegotiation para las velocidades 10/100/1000-Mbps en los puertos de cobre.

Nota: La especificación de fibra del GE hace solamente las provisiones para la negociación del duplex, del control de flujo, y de la detección de la falla remota. Los puertos de fibra del GE no negocian la velocidad de puerto. Referir a las secciones 28 y 37 de la especificación de IEEEleavingcisco.com 802.3-2002 para más información sobre el autonegotiation.

El retardo del relanzar de la sincronización es una función del software que controla el tiempo total del autonegotiation. Si el autonegotiation no es acertado dentro de este tiempo, el firmware recomienza el autonegotiation en caso de que haya un bloqueado del tratamiento. El comando set port sync-restart-delay tiene solamente un efecto cuando el autonegotiation se fija para habilitar.

Recomendación

Habilitar el autonegotiation es mucho más crítico en un ambiente del GE que en un ambiente de 10/100. De hecho, el autonegotiation debe solamente ser lisiado en los puertos del switch que asocian a los dispositivos no capaces de soportar la negociación o donde los problemas de conectividad se presentan de los problemas de interoperabilidad. Cisco recomienda activar la negociación Gigabit (opción predeterminada) en todos los enlaces entre switches y generalmente todos los dispositivos GE. Publicar este comando para habilitar el autonegotiation:

set port negotiation port range enable

!--- This is the default.

Una excepción conocida es cuando hay una conexión a un software del IOS de Cisco corriente del router de switch Gigabit (GRS) anterior que 12.0 (10) S, la versión que agregó el control de flujo y el autonegotiation. En este caso, dar vuelta apagado a esas dos características, o los informes del puerto del switch no conectados, y los errores de los informes del GSR. Esto es una secuencia del ejemplo de comando:


set port flowcontrol receive port range off
set port flowcontrol send port range off
set port negotiation port range disable

Las conexiones de switch a servidor deben revisarse de a un caso por vez. Los clientes de Cisco se han encontrado con problemas en la negociación de Gigabit respecto de los servidores Sun, HP e IBM.

Otras opciones

El control de flujo es una parte optativa de la especificación 802.3x y debe ser negociado si está utilizado. Los dispositivos pueden o no pueden ser capaces de enviar y/o de responder a una trama de pausa (MAC bien conocido 01-80-C2-00-00-00 0F). También, no pueden convenir la petición de control de flujo del vecino en el extremo lejano. Un puerto con una memoria intermedia de entrada que esté llenando para arriba envía una trama de pausa a su socio de enlace, que para la transmisión, y lleva a cabo cualquier trama adicional en los búferes de salida del socio de enlace. Esto no soluciona ningún problema de sobresuscripción de estado detenido, sino con eficacia hace la memoria intermedia de entrada más grande por alguna fracción del buffer de la salida del socio durante las explosiones.

Esta característica se utiliza lo más mejor posible en las conexiones entre los accesso-puertos y los host finales, donde está potencialmente tan grande el búfer de salida del ordenador principal como su memoria virtual. El uso switch-a-switch tiene ventajas limitadas.

Publicar estos comandos para controlar esto en los puertos del switch:


set port flowcontrol mod/port 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 están negociados. Algunos módulos (por ejemplo, WS-X5410, WS-X4306) nunca envían las tramas de pausa aunque que negocian para hacer así pues, pues son no bloqueando.

Protocolo de concentración de enlace troncal dinámico

‘Tipo de encapsulación’

Los enlaces troncales amplían los VLAN entre los dispositivos temporalmente identificando y marcando (local de la conexión) las tramas del Ethernet original con etiqueta, así las habilitan que se multiplexarán sobre un solo enlace. Esto también asegura que la transmisión VLAN separada y los dominios de seguridad se mantengan entre los switches. Las tablas CAM mantienen el mapeo de trama a VLAN dentro de los switches.

El Trunking se soporta en varios tipos de los media L2, incluyendo LANE ATM, FDDI 802.10, y Ethernet, aunque solamente es el último se presente aquí.

Información general sobre el funcionamiento de ISL

La identificación o el esquema de etiquetado propietaria, ISL de Cisco, ha sido funcionando por muchos años. La norma IEEE 802.1Q está también disponible.

Totalmente encapsulando la trama original en un esquema de etiquetado de dos niveles, el ISL es con eficacia un protocolo de tunelización y tiene el beneficio adicional de llevar las tramas de los no Ethernetes. Agrega 26 un encabezado del byte y 4 el byte FCS a la trama Ethernet estándar - las tramas Ethernet más grandes esperan y son manejadas por los puertos configurados para ser truncales. ISL soporta 1024 VLAN.

Formato del ISL frame

40 bits

4 Bits

4 Bits

48 bits

16 bits

24 bits

24 bits

15 bits

Bit

16 bits

16 bits

Longitud variable

32 bits

Dest. Addr

Tipo

USUARIO

SA

Largo

SNAP LLC

HSA

VLAN

BPDU

Índice

Reserva

Trama encapsulada

FCS

01-00-0c-00-00

       

AAAA03

00000C

           

Referir al InterSwitch Link y al formato de trama del IEEE 802.1Q para más información.

Información general sobre el funcionamiento de 802.1Q

El estándar del IEEE 802.1Q especifica mucho más que los tipos de encapsulación, incluyendo los realces del árbol de expansión, marcar con etiqueta de la Calidad de Servicio (QoS) GARP (véase la sección del VTP de este documento), y 802.1p.

El formato de trama 802.1Q preserva a la dirección original Ethernet de origen y a dirección destino, con todo los switches deben ahora esperar que las tramas del Baby Giant sean recibidas, incluso en los puertos de acceso en donde los ordenadores principal pueden utilizar marcar con etiqueta para expresar la prioridad de usuario 802.1p para la señalización QoS. La etiqueta es 4 bytes, así que las tramas del v2 de Ethernet 802.1Q son 1522 bytes, un logro del grupo de trabajo de IEEE 802.3ac. 802.1Q también soporta el espacio de numeración para 4096 VLAN.

Todo el marco de datos transmitido y recibido es 802.1Q-tagged a excepción de ésos en el VLAN nativo (hay un indicador implícito basado en la configuración del puerto del switch de ingreso). Los capítulos en el VLAN nativo son siempre untagged untagged y normalmente recibido transmitido. Sin embargo, pueden también ser recibidos marcaron con etiqueta.

Referir a la estandarización de VLAN mediante IEEE 802.10 y conseguir el IEEE 802leavingcisco.com para más detalles.

formato de trama 802.1Q/801.1p

 

Encabezado de etiqueta

 

TPID

TCI

48 bits

48 bits

16 bits

3 bits

1 bit

12 bits

16 bits

Longitud variable

32 bits

DA

SA

TPID

Prioridad

CFI

ID de VLAN

Tipo de la longitud

Datos con PAD

FCS

 

0x8100

0 - 7

0-1

0-4095

 

Recomendación

Como todos los más nuevos soportes del hardware 802.1Q (y algo soporta solamente 802.1Q, tal como el Catalyst 4500/4000 serie y CSS 11000), el Cisco recomienda que todas las nuevas implementaciones siguen el IEEE 802.1Q estándar y más viejas redes emigran gradualmente del ISL.

La norma IEEE permite la interoperabilidad entre vendedores. Esto es ventajoso en todos los entornos de Cisco pues el nuevo ordenador principal 802.1p NIC capaces y los dispositivos llegan a estar disponibles. Aunque el ISL y las implementaciones 802.1Q son maduros, la norma IEEE tendrá en última instancia la mayor exposición al campo y mayor soporte del otro vendedor, tal como soporte de analizador de red. La tara de encapsulación más baja de 802.1Q comparado al ISL es un punto casi insignificante a favor de 802.1Q también.

Como negocian al tipo de encapsulación entre los switches usando el DTP, con el ISL elegido como el ganador por el valor por defecto si el soporte de los ambos finales él, él es necesario publicar este comando para especificar el dot1q:


set trunk mod/port mode dot1q

Si es el VLAN1 borró de un troncal, como discutido en la sección de la administración en la banda de este documento, aunque no se transmite ni se recibe ningunos datos del usuario, el NMP continúa pasando los protocolos de control tales como CDP y VTP en el VLAN1.

También, según lo discutido en la sección VLAN1 de este documento, el CDP, el VTP, y los paquetes PAgP se envían siempre en el VLAN1 cuando trunking. Al usar la encapsulación del dot1q, estas tramas de control se marcan con etiqueta con el VLAN1 si el VLAN nativo del switch se cambia. Si el trunking del dot1q a un router es habilitado y el VLAN nativo se cambia en el switch, un submarino interface en el VLAN1 es necesario recibir las tramas CDP con etiqueta y proporcionar a la visibilidad de vecinos CDP en el router.

Nota: Hay una potencial consideración de seguridad con el dot1q causado por marcar con etiqueta implícito del VLAN nativo, pues puede ser posible enviar las tramas a partir de un VLAN a otro sin un router. ¿Referirse están allí las vulnerabilidades en las implementaciones de VLAN?leavingcisco.com para otros detalles. El workaround es utilizar un VLAN ID para el VLAN nativo del troncal que no se utiliza para el acceso del usuario final. La mayoría de los clientes de Cisco deja el VLAN1 como el VLAN nativo en un troncal y asigna los puertos de acceso a los VLAN con excepción del VLAN1 para alcanzar esto simplemente.

Modo de concentración de enlaces

El DTP es la segunda generación del ISL dinámico (DISL), y existe para asegurarse de que los diversos parámetros implicados en enviar las tramas ISL o 802.1Q, tales como el tipo de encapsulación configurada, el VLAN nativo, y la capacidad del hardware, son convenidos en por los switches en cualquier extremo de un troncal. Esto también ayuda a proteger contra inundaciones de puertos no troncales en tramas con etiquetas, un riesgo de seguridad posiblemente grave, al asegurar que los puertos y sus vecinos se encuentren en estados coherentes.

Información operativa general

El DTP es un protocolo L2 que negocia los parámetros de la configuración entre un puerto del switch y su vecino. Usa otra dirección MAC multidifusión MAC (01-00-0c-cc-cc-cc) y un tipo de protocolo SNAP de 0x2004. Este vector es un resumen de los modos de configuración:

Modo

Función

Tramas DTP transmitidas

Etapa final (Puerto local)

automático (default)

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

Sí, periódico.

Conexión troncal

Activado

Pone el puerto en modo troncal permanente y negocia para convertir el enlace en troncal. El puerto se convierte en puerto de troncal aunque el puerto de vecindad no acepte el cambio.

Sí, periódico.

Tronco, sin condiciones.

no negociación

Coloca el puerto en modo de concentración de enlace permanente pero evita que éste genere 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

Tronco, sin condiciones.

Deseable

Hace que el puerto intente convertir el enlace en un enlace troncal. El puerto se convierte en un puerto troncal si el puerto vecino está en modo encendido, deseable o automático.

Sí, periódico.

Termina para arriba en el estado de troncal solamente si el modo remoto está encendido, el automóvil, o deseable.

Desactivado

Pone el puerto en modo no troncal permanente y negocia para convertir el enlace en un enlace no troncal. El puerto se transforma en un puerto no troncal incluso en el caso de que el puerto de vecindad no acepte el cambio.

No en el estado constante, pero transmite informa para acelerar la detección de extremo remoto después del cambio de encendido.

No-trunking

Éstos son algunos resaltados del protocolo:

  • El DTP asume una conexión punto a punto, y los dispositivos de Cisco soporta solamente los puertos del tronco 802.1q que son Point-to-Point.

  • Durante la negociación DTP, los puertos no participan en el STP. Solamente después que se convierte el puerto uno de los tres tipos del DTP (accesso, ISL, o 802.1Q) hace el portuario se agregue al STP. Si no el PAgP, si está configurado, es el proceso siguiente a ejecutarse antes de que el puerto participe en el STP.

  • Si el puerto es trunking en el modo ISL, los paquetes DTP se envían en el VLAN1, si no (para los puertos del trunking 802.1Q o del no-trunking) se envían en el VLAN nativo.

  • En el desirable mode, los paquetes DTP transfieren al Domain Name del theVTP (que debe corresponder con para que suba un enlace troncal negociado), a la configuración del tronco y a estado del administrador más.

  • Los mensajes se envían cada segundo durante la negociación, y cada 30 segundos después eso.

  • Ser seguro entender que los modos encendido, nonegocian, y apagado especificar explícitamente en qué estado termina el puerto para arriba. Una configuración incorrecta puede generar un estado peligroso/incoherente en el que un lado es troncal y el otro no.

  • Un puerto adentro encendido, el automóvil, o el desirable mode envía las tramas del DTP periódicamente. Si un puerto en el modo deseado o automático no ve un paquete DTP en cinco minutos, se fija al no-troncal.

Referir a la conexión troncal de ISL de configuración en el Catalyst 5500/5000 y 6500/6000 de los switches de la familia para más detalles del ISL. Referir al Trunking entre los switches de la Serie del Catalyst 4500/4000, 5500/5000, y 6500/6000 usando la encapsulación 802.1Q con el software del sistema del Cisco CatOS para más detalles 802.1Q.

Recomendación

Cisco recomienda una configuración del tronco explícita de deseable en los ambos extremos. En este modo, los operadores de la red pueden confiar en los mensajes de estado del syslog y de la línea de comando que un puerto es ascendente y trunking, desemejante en del modo, que puede hacer que aparece un puerto para arriba aunque el vecino es mal configurado. Además, el modo troncal deseable proporciona a la estabilidad en las situaciones donde un lado de la conexión no puede convertirse en un troncal o cae a estado del tronco. Publicar este comando para fijar el desirable mode:


set trunk mod/port desirable ISL | dot1q

Nota: Fijar el tronco a apagado en todos los puertos no troncales. Esto ayuda a eliminar el tiempo de negociación perdido al encender los puertos host. Este comando también se ejecuta cuando se utiliza el comando set port host; referir a la sección del STP para más información. Publicar este comando para invalidar un troncal en un rango de puertos:


set trunk port range off

!--- Ports are not trunking; part of the set port host command.

Otras opciones

Otra configuración del cliente común utiliza el desirable mode solamente en la capa de distribución y la configuración predeterminada más simple (modo automático) en la capa de acceso.

Algunos switches, tales como routers de un Catalyst 2900XL, del Cisco IOS, o dispositivos del otro vendedor, no soportan actualmente la negociación de tronco con el DTP. Usted puede utilizar al modo de no negociación en el Catalyst 4500/4000, 5500/5000, y 6500/6000 de los switches para fijar un puerto al troncal incondicional con estos dispositivos, que pueden ayudar a estandardizar en una configuración común a través del campus. También, usted puede implementar al modo de no negociación para reducir la hora de inicialización de la conexión del “guardapolvo”.

Nota: Los factores tales como el modo del canal y la configuración de STP pueden también afectar la hora de inicialización.

Publicar este comando para fijar al modo de no negociación:

set trunk mod/port nonegotiate ISL | dot1q

El Cisco recomienda nonegocia cuando allí ia una conexión a un router del Cisco IOS porque cuando se realiza el bridging, algunas tramas del DTP recibidas en del modo pueden conseguir nuevamente dentro del puerto troncal. Sobre la recepción del bastidor del DTP, el puerto del switch intenta renegociar (orbring el troncal abajo y subir) innecesariamente. Si nonegociar es habilitado, el switch no envía las tramas del DTP.

Spanning Tree Protocol

Consideraciones básicas

El protocolo del árbol de expansión (STP) mantiene un ambiente libre de bucle L2 en conmutada redundante y las redes conectadas con bridge. Sin el STP, las tramas colocan y/o se multiplican indefinidamente, que causa un que SE funda la red mientras que todos los dispositivos en el dominio de broadcast son interrumpidos continuamente por el mucho tráfico.

Si bien en algunos aspectos STP es un protocolo madure inicialmente desarrollado para especificaciones de bridge basado en software lento (IEEE 802.1d), puede resultar difícil su implementación en redes grandes conmutadas con muchas VLAN, muchos switches en un dominio, soporte de varios proveedores y mejoras IEEE más recientes.

Para la referencia futura, CatOS 6.x continúa adquiriendo el nuevo desarrollo de STP, tal como MISTP, protección de bucle, protecciones raíz, y detección oblicua del tiempo de llegada BPDU. Además, otros protocolos estandarizados están disponibles en CatOS 7.x, tal como árbol de expansión de convergencia rápida compartida IEEE 802.1S del árbol de expansión y del IEEE 802.1W.

Información operativa general

La elección de bridge raíz por el VLAN es ganada por el switch con el identificador más bajo del bridge de la raíz (OFERTA). La OFERTA es la prioridad de bridge combinada con el MAC address del interruptor.

Inicialmente, los BPDU se envían de todos los switches, conteniendo la OFERTA de cada switch y del costo del trayecto para alcanzar ese switch. Esto habilita el bridge de la raíz y el trayecto de costo más bajo a la raíz que se determinará. Los parámetros adicionales de configuración transportados en las BPDU desde la raíz invalidan a aquellos que están configurados localmente para que la red entera use temporizadores consistentes.

La topología entonces converge con estos pasos de progresión:

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

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

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

  4. Los puertos no designados se vuelven bloqueadores.

Referir al árbol de expansión de configuración para más información.

Opciones básicas predeterminadas del temporizador (segundos)

Nombre

Función

2

Hola

Controla el envío de BPDU.

15

Retardo de reenvío (Fwddelay)

Los controles cuánto tiempo un puerto pasa en el estados de escucha y de aprendizaje e influencian el proceso del cambio de la topología (véase la siguiente sección).

20

Maxage

Controles cuánto tiempo el switch mantiene la topología actual antes de que busque un trayecto alternativo. Después de los segundos del Maxage, un BPDU se considera añejo y el switch busca un puerto raíz nuevo del pool de los puertos de bloqueo. Si no hay puerto bloqueado disponible, demanda ser la raíz sí mismo en los puertos señalados.

Estados de puertos

Significado

Sincronización predeterminada al siguiente estado.

desactivado

Administratively down.

N/A

Bloqueo

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

Monitoree la recepción de BPDU. Esperar 20 segundos la expiración de Maxage o el cambio inmediato si la falla de enlace directa/local detectó.

Escucha

Enviar o recibir BPDU para controlar si se necesita volver al bloqueo.

Temporizador de retardo de reenvío (espere 15 segundos)

Aprendizaje

Vector del edificio topology/CAM.

Temporizador de retardo de reenvío (espere 15 segundos)

Reenvío

El enviar/recepción de los datos.

 
 

Cambio de la topología básica total:

20 + 2 (15) = 50 segundos si espera el Maxage para expirar, o 30 segundos para la falla de enlace directo

Los dos tipos de BPDU en el STP son los BPDU de configuraciones y el Topology Change Notification (TCN) BPDU.

Flujo del BPDU de configuración

Los BPDU de configuraciones son originados cada intervalo de saludo de cada puerto en el bridge de la raíz y fluyen posteriormente a todos los switches de la hoja para mantener el estado del árbol de expansión. En el estado constante, el flujo de BPDU es unidireccional: los puertos raíz y los puertos de bloqueo sólo reciben configuraciones de BPDU, mientras que los puertos designados sólo envían configuraciones de BPDU.

Para cada BPDU recibido por un switch de la raíz, un nuevo es procesado por NMP central de Catalyst y enviado que contiene la información de la raíz. Es decir si se pierde el bridge de la raíz o todos los caminos al bridge de la raíz se pierden, interrupción de BPDU que es recibida (hasta que el temporizador de mediciones máximas comienza la reelección).

Flujo de BPDU del TCN

El TCN BPDU es originado de los switches de la hoja y fluye hacia el bridge de la raíz en que un cambio de la topología se detecta en el árbol de expansión. Los puertos raíz envían solamente los TCN, y los puertos señalados reciben solamente los TCN.

El TCN BPDU viaja hacia el borde de la raíz y se reconoce en cada paso de progresión, así que esto es un mecanismo confiable. Una vez que llegue el bridge de la raíz, el bridge de la raíz alerta el dominio entero que un cambio ha ocurrido por los BPDU de configuraciones del sourcing con el conjunto del indicador del TCN para el maxage + tiempo de fwddelay (Retraso de reenvío) (35 segundos por el valor por defecto). Esto hace todos los switches cambiar su tiempo de envejecimiento CAM normal a partir de cinco minutos (por el valor por defecto) al intervalo especificado por fwddelay (15 segundos por el valor por defecto). Referir a los cambios de la topología del protocolo del árbol de expansión que entienden para más detalles.

Modos del árbol de expansión

Hay tres diversas maneras de correlacionar los VLAN con el árbol de expansión:

  • Un solo árbol de expansión para todos los VLAN, o mono protocolo del árbol de expansión, tal como IEEE 802.1Q

  • Un árbol de expansión por el VLAN, o árbol de expansión compartido, tal como Cisco PVST

  • Un árbol de expansión por el conjunto de VLAN, o árbol de expansión múltiple, tal como Cisco MISTP y IEEE 802.1S

Un mono árbol de expansión para todos los VLAN permite solamente una topología activa y por lo tanto ningún load balancing. Los bloques de un puerto bloqueado del STP para todos los VLAN y no llevan ningún dato.

Un árbol de expansión por el VLAN permite el load balancing pero requiere MÁS BPDU CPU el proceso mientras que el número de los VLAN aumenta. Las release notes de CatOS brindan pautas sobre el número de puertos lógicos recomendados en el Árbol de expansión por switch. Por ejemplo, el fórmula del Supervisor Engine 1 del Catalyst 6500/6000 está como tal:

número de los puertos + (número de los troncales * número de los VLAN en los troncales) < 4000

Cisco MISTP y el nuevo estándar 802.1s permite la definición de solamente dos casos activos/de las topologías del STP, y asociar de todos los VLAN a cualquiera de estos dos árboles. Esta técnica permite que el STP escale a muchos millares de VLAN mientras que el load balancing es habilitado.

Formatos BPDU

Para soportar el estándar del IEEE 802.1Q, la implementación de STP existente del Cisco fue ampliada para convertirse en PVST+ agregando el soporte para el tunneling a través de una mono región del árbol de expansión del IEEE 802.1Q. El PVST+ es por lo tanto compatible con el IEEE 802.1Q MST y los protocolos de Cisco PVST y no requiere los comandos o la configuración adicionales. Además, el PVST+ agrega los mecanismos de verificación para asegurarse de que no hay incoherencia de configuración del enlace troncal de puerto y de las identificaciones de VLAN a través de los switches.

Éstos son algunos aspectos operacionales destacados del protocolo del PVST+:

  • El PVST+ interopera con el mono árbol de expansión 802.1Q con el Common Spanning Tree supuesto (CST) sobre un tronco 802.1q. El CST se encuentra siempre en la VLAN 1, por lo que esta VLAN debe estar habilitada en el tronco para interactuar con otros proveedores. El CST BPDU se transmite, siempre untagged, al Bridge-Grupo de la norma IEEE (MAC address 01-80-c2-00-00-00, DSAP 42, SSAP 42). Para la integridad de la descripción, un conjunto paralelo de BPDU también se transmite al MAC address compartido Cisco del árbol de expansión para el VLAN1.

  • El PVST+ hace un túnel PVST BPDU a través de las regiones de VLAN 802.1Q como datos de multidifusión. El árbol de expansión compartido Cisco BPDU se transmite al MAC address 01-00-0c-cc-cc-cd (tipo RÁPIDO 0x010b del Protocolo HDLC.) para cada VLAN en un troncal. Las BPDU no están etiquetadas en la VLAN de origen y sí están etiquetadas en las demás VLAN.

  • PVST+ verifica incoherencias de VLAN y puertos. PVST+ bloquea aquellos puertos que reciben BPDU inconsistentes a fin de impedir bucles de reenvío. También notifica a usuarios a través de los mensajes de Syslog sobre cualquier discrepancia de configuración.

  • El PVST+ es backward-compatible con los switches de Cisco existentes que ejecutan el PVST en los troncales ISL. Los BPDU encapsulados ISL aún se transmiten o reciben mediante una dirección IEEE MAC. Es decir cada tipo de BPDU es local de la conexión; no hay ediciones de la traducción.

Recomendación

Todos los switches de Catalyst tienen STP habilitado por el valor por defecto. Se recomienda esto incluso si se elige un diseño que no incluye los bucles L2 para no habilitar el STP en el sentido que está manteniendo activamente un puerto bloqueado.

set spantree enable all

!--- This is the default.

El Cisco recomienda que el STP está dejado habilitado por estas razones:

  • Si hay un bucle (inducido por el cable mispatching, mal, y así sucesivamente.), el STP previene los efectos perjudiciales a la red causada por el multicast y los datos del broadcast.

  • Protección frente a averías de EtherChannel.

  • La mayoría de las redes se configuran con el STP, que le da la exposición máxima de campo. Más exposición se compara generalmente al código estable.

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

  • El software para muchos protocolos (tales como PAgP, IGMP Snooping, y trunking) se relaciona de cerca con el STP. El ejecutarse sin el STP puede conducir a los resultados no deseables.

No cambiar los temporizadores, como esto puede afectar al contrario la estabilidad. La mayoría de las redes implementadas no está ajustada. Los temporizadores STP simples accesibles a través de la línea de comando, tal como intervalo de saludo y Maxage, ellos mismos se abarcan de los complejos conjuntos de otros temporizadores intrínsecos y supuestos, así que es difícil ajustar los temporizadores y considerar todas las ramificaciones. Por otra parte, hay el peligro de desautorización de la protección UDLD.

Lo ideal es que mantenga el trafico de los usuarios fueran de la VLAN de administración. Especialmente con los procesadores de switches Catalyst más antiguos, es mejor evitar problemas con STP y, para hacerlo, debe mantener la VLAN de administración separada de los datos del usuario. Una estación terminal que misbehaves podría potencialmente mantener el procesador del Supervisor Engine tan ocupado con los paquetes de broadcast que puede faltar unos o más BPDU. Sin embargo, más nuevos switches con CPU más de gran alcance y los controles que sofocan relevan esta consideración. Ver la sección de la administración en la banda de este documento para más detalles.

No sobre-diseñan la redundancia. Esto puede conducir a una pesadilla de la resolución de problemas - demasiados puertos de bloqueo afectan al contrario la estabilidad a largo plazo. Mantenga el diámetro STP total por debajo de siete saltos. Intentar diseñar a Cisco el modelo de multicapa, con sus dominios conmutados más pequeños, los triángulos STP, y los puertos bloqueados deterministas (según lo explicado en Gigabit Campus los Diseñar-Principios y la configuración de la red) donde sea posible.

Controle y conozca dónde reside la funcionalidad Raíz y los puertos bloqueados y documéntelos en un diagrama de topología. La solución de problemas de STP comienza en los puertos bloqueados: lo que los hizo cambiar de bloqueo o reenvío a menudo es la parte clave del análisis de causas raíz. Elegir la distribución y las capas del núcleo como la ubicación de ruta/subruta, puesto que éstos se consideran las partes de más estables la red. Controlar para saber si hay el L3 óptimo y recubrimiento del HSRP con los caminos del reenvío de datos L2. Este comando es una macro que configura la prioridad de bridge; la raíz fija mucho más bajo que el valor por defecto (32768), mientras que los conjuntos secundarios de la raíz él razonablemente más bajo que el valor por defecto:

set spantree root secondary vlan range

Nota: Esta macro fija la prioridad raíz para ser 8192 (por el valor por defecto), la prioridad raíz actual menos 1 (si se sabe otro bridge de la raíz), o la prioridad raíz actual (si su MAC address es más bajo entonces la raíz actual).

Vlanes innecesaria de la pasa de los troncal-puertos (un ejercicio bidireccional). Esto limita el diámetro del STP y NMP que procesan la tara en las porciones de la red donde ciertos VLAN no se requieren. Los recortes automáticos del VTP no quitan el STP de un troncal. Referir a la sección del VTP de este documento para más información. El VLAN predeterminado 1 se puede también quitar de los troncales usando CatOS 5.4 y posterior.

Referir a los problemas de protocolo y a las consideraciones de diseño relacionadas del árbol de expansión para la información adicional.

Otras opciones

Cisco tiene otro asVLAN-bridge sabido STP. Este protocolo funciona con una dirección MAC de destino de 01-00-0c-cd-cd-ce y el Tipo de protocolo de 0x010c.

Esto es la más útil si hay una necesidad de puentear no routable o los protocolos heredados entre los VLAN sin interferir con los casos del árbol de expansión de IEEE que se ejecutan en esos VLAN. Si las interfaces VLAN para el tráfico sin bridge se bloquean para el tráfico L2 (y éste podría suceder fácilmente si participaron en el mismo STP que IP VLAN), el tráfico de sobreposición L3 consigue inadvertidamente podado apagado también - un efecto colateral no deseado. El Bridge del VLAN es por lo tanto un caso de STP aparte para los protocolos en bridge, que proporciona a una topología distinta que pueda ser manipulada sin afectar el tráfico IP.

La recomendación de Cisco es ejecutar el bridge de VLAN si se requiere una conexión en bridge entre las VLAN en los routers de Cisco tal como las MSFC.

PortFast

PortFast se utiliza para desviar la operación normal del árbol de expansión en los puertos de acceso para acelerar la conectividad entre las estaciones finales y los servicios que necesitan conectar con después de la inicialización de la conexión. En algunos protocolos, tales como IPX/SPX, es importante ver el puerto de acceso en el modo de reenvío inmediatamente después que el estado de la conexión ha ido encima de para evitar los problemas GNS.

Referirse con Portfast y otros comandos de fijar los retardos de la conectividad de inicialización de la estación de trabajo para más información.

Información operativa general

PortFast omite los estados de escucha y aprendizaje normales del STP moviendo un puerto directamente del modo del bloqueo al modo de reenvío luego de haber detectado que el enlace se está ejecutando. Si esta característica no es habilitada, el STP desecha todos los datos del usuario hasta que decide a que el puerto es listo ser movido al modo de reenvío. Esto podrá llevar hasta dos veces el tiempo de retraso de envío (un total de 30 segundos de forma predeterminada).

El modo Portfast también evita que un STP TCN sea generado cada vez que un estado de puerto cambia de aprender a la expedición. Los TCN no son un problema por sí mismos, sino que si una onda de los TCN golpeó el bridge de la raíz (típicamente por la mañana en que la gente gira sus PC), podría prolongar el tiempo de convergencia innecesariamente.

El STP portfast es determinado importante en multicast CGMP y las redes MLS del Catalyst 5500/5000. Los TCN en estos ambientes pueden hacer las entradas de tabla de CAM CGMP estática ser envejecido hacia fuera, que da lugar a la pérdida de paquete de multidifusión hasta el informe siguiente del IGMP, y/o las entradas de memoria caché de MLS rasantes que después necesitan ser reconstruidas y podrían dar lugar a a pico de la CPU del router, dependiendo de los tamaños de la memoria inmediata. (Las implementaciones de MLS y las entradas de multidifusión del Catalyst 6500/6000 aprendidas del IGMP Snooping no se afectan.)

Recomendación

El Cisco recomienda que el STP portfast sea habilitado para todos los puertos del host activo y esté invalidado para las conexiones del switch switch y vira parado hacia el lado de babor.

El Trunking y el acanalar deben también ser lisiados para todos los puertos de host. Cada puerto de acceso está habilitado de manera predeterminada para enlaces troncales y canales, aunque los vecinos de conmutación no están previstos por diseño en los puertos del host. Si se deja negociar a estos protocolos, el retraso subsiguiente en la activación del bridge puede conducir a situaciones indeseables en las cuales los paquetes iniciales desde las estaciones de trabajo, como por ejemplo las peticiones DHCP, no son reenviados.

CatOS 5.2 introdujo un comando macro, set port host port range que implementa esta configuración para los puertos de acceso y ayuda al autonegotiation y al desempeño de la conexión perceptiblemente:

set port host port range


!--- Macro command for these commands:

set spantree portfast port range enable
set trunk port range off
set port channel port range mode off

Nota: PortFast no significa que el árbol de expansión no está ejecutado en todos en esos puertos. Aún se envían, se reciben y se procesan BDPU.

Otras opciones

La Protección BPDU de PortFast proporciona a una manera de prevenir los bucles moviendo un puerto del no-trunking en un estado de errDisable cuando un BPDU se recibe en ese puerto.

Un paquete BPDU se debe nunca recibir en un puerto de acceso configurado para PortFast, puesto que los puertos de host no se deben asociar a los switches. Si se observa una BPDU, indica una configuración no válida y posiblemente peligrosa que necesita una acción administrativa. Cuando la característica de protección BPDU es habilitada, el árbol de expansión apaga las interfaces del Portfast configurado que reciben los BPDU en vez de ponerlos en el estado de bloqueo del STP.

El comando trabaja en por switch, no por puerto, como se muestra:

set spantree portfast bpdu-guard enable

Si el puerto deja de funcionar, el administrador de la red es notificado mediante una trampa SNMP o un mensaje syslog. Es también posible configurar un tiempo de recuperación automática para los puertos errdisabled. Referir a la sección del UDLD de este documento para más detalles. Para más información, referir a la mejora del protector Portfast BPDU del árbol de expansión.

Nota: PortFast para los puertos troncales fue introducido en CatOS 7.x y no tiene ningún efecto en los puertos troncales en las versiones anteriores. PortFast para los puertos troncales se diseña para aumentar el tiempo de convergencia para las redes L3. Para complementar esta característica, CatOS 7.x también introdujo la posibilidad de la configuración de la Protección BPDU de PortFast sobre una base por puerto.

UplinkFast

UplinkFast provee una rápida convergencia STP luego de una falla de enlace directo en la capa de acceso de la red. No modifica el STP, y su propósito es acelerar el tiempo de convergencia en una circunstancia específica menos de tres segundos, más bien que el segundo retardo 30 típicos. Referir a entender y configurando el enlace ascendente de Cisco rápidamente ofrecer para más información.

Información operativa general

Usando diseño multicapa de Cisco el modelo en la capa de acceso, si se pierde el enlace ascendente de reenvío, el enlace ascendente de bloqueo se mueve inmediatamente a un estado de reenvío sin para el estados de escucha y de aprendizaje que espera.

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. Bajo condiciones normales, el puerto raíz está asegurando la conectividad del accesso hacia la raíz. Si esta raíz-conexión primaria falla por cualquier razón, los retrocesos del enlace de raíz de respaldo adentro inmediatamente sin tener que pasar con los 30 segundos típicos de la convergencia retrasan.

Porque esto desvía con eficacia la topología de STP normal cambiar-que dirige el proceso (escuchando y aprendiendo), un mecanismo de corrección de topología alternativa es necesario para poner al día los switches en el dominio que las estaciones del extremo local son accesibles a través de un trayecto alterno. El switch de capa de acceso que ejecuta UplinkFast también genera las tramas para cada MAC address en su CAM a una dirección MAC de multidifusión (01-00-0c-cd-cd-cd, Protocolo HDLC. 0x200a) para poner al día la tabla CAM en todos los switches en el dominio con la nueva topología.

Recomendación

Cisco recomienda que se active UplinkFast para los switches con puertos bloqueados, típicamente en la capa de acceso. No utilizar en los switches sin los conocimientos de topología implícita de un enlace de raíz de respaldo - típicamente distribución y los switches del núcleo en diseño multicapa de Cisco. Puede ser agregado sin interrupciones a una red de producción. Publicar este comando para habilitar UplinkFast:

set spantree uplinkfast enable 

Este comando también fija la prioridad de bridge alta para reducir al mínimo el riesgo de esto que se convierte en un bridge de la raíz y la prioridad de puerto altos para reducir al mínimo convertirse en un Designated Port, que rompe las funciones. Cuando usted restablece un switch que tenía UplinkFast habilitado, la característica tiene que ser lisiada, la base de datos del uplink borrada con el “uplink claro,” y las prioridades de bridge restablecidas manualmente.

Nota: La palabra clave del all protocols para el comando uplinkfast es necesaria cuando la característica del filtrado de protocolo es habilitada. Pues el CAM registra a Tipo de protocolo así como el MAC y la información de VLAN cuando el filtrado de protocolo es habilitado, una trama de UplinkFast necesita ser generada para cada protocolo en cada MAC address. La palabra clave de la tarifa indica los paquetes por segundo de los bastidores de la actualización de la topología del uplinkfast. Se recomienda el valor por defecto. Usted no necesita configurar el BackboneFast con STP rápido (RSTP) o el IEEE 802.1W porque el mecanismo se incluye nativo y se habilita automáticamente en el RSTP.

BackboneFast

El BackboneFast proporciona a la convergencia rápida de las fallas de enlace indirecto. Con las funciones agregadas al STP, el tiempo de convergencia se puede reducir típicamente del valor por defecto de 50 segundos a 30 segundos.

Información operativa general

Se inicia el mecanismo cuando un puerto raíz o un puerto bloqueado en un switch recibe los BPDU inferiores de su bridge designado. Esto puede suceder cuando un switch en sentido descendiente ha perdido su conexión a la raíz y comienza a enviar sus propios BPDU para elegir una nueva raíz. Un BPDU inferior identifica a un switch como el bridge raíz y el bridge designado.

Bajo reglas normales del árbol de expansión, el switch de recepción no hace caso de los BPDU inferiores por el tiempo de envejecimiento máximo configurado, 20 segundos por el valor por defecto. Sin embargo, con el BackboneFast, el switch considera el BPDU inferior como una señal que la topología habría podido cambiar, e intentos de determinar si tiene un trayecto alterno al bridge de la raíz usando el Root Link Query (RLQ) BPDU. Esta adición al protocolo permite que un switch controle si la raíz todavía esté disponible, mueve un puerto bloqueado a la expedición en menos tiempo, y notifica el switch aislado que envió el BPDU inferior que la raíz todavía está allí.

Éstos son algunos resaltados de la operación de protocolo:

  • Un switch transmite el paquete RLQ hacia fuera el puerto raíz solamente (es decir, hacia el bridge de la raíz).

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

  • Si un switch pierde conexión con la raíz, 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.

Los tiempos de la convergencia de STP se pueden por lo tanto reducir por hasta 20 segundos, pues el maxage no necesita expirar.

Referir al Backbone Fast que entiende y de configuración en los switches de Catalyst para más información.

Recomendación

La Recomendación de Cisco es habilitar el BackboneFast en todos los switches que ejecutan el STP. Puede ser agregado sin interrupciones a una red de producción. Publicar este comando para habilitar el BackboneFast:

set spantree backbonefast enable

Nota: Este comando llano global necesita ser configurado en todos los switches en un dominio mientras que agrega las funciones al protocolo STP que todos los switches necesitan entender.

Otras opciones

El BackboneFast no se soporta en 2900XLs y 3500s. No debe ser habilitado si el dominio del switch contiene estos switches además del Catalyst 4500/4000, 5500/5000, y 6500/6000 de los switches.

Usted no necesita configurar el BackboneFast con el RSTP o el IEEE 802.1W porque el mecanismo se incluye nativo y se habilita automáticamente en el RSTP.

Protección de bucle del árbol de expansión

La protección de bucle es una optimización propietaria de Cisco para el STP. La protección de bucle protege las redes L2 contra los bucles que se causan cerca:

  • Interfaces de la red que funcionan incorrectamente

  • CPU ocupados

  • Cualquier cosa que previene la expedición normal de los BPDU

Un STP loop ocurre cuando un puerto de bloqueo en las transiciones erróneas de una topología redundante al estado de reenvío. Esta transición sucede generalmente porque uno de los puertos en una topología redundante (no no necesariamente el puerto de bloqueo) deja físicamente de recibir los BPDU.

La protección de bucle es solamente útil en las redes de switch en donde los switches son conectados por los vinculos punto a punto. La mayoría de las redes modernas del campus y del centro de datos son estos tipos de red. En un vinculo punto a punto, un bridge designado no puede desaparecer a menos que envíe un BPDU inferior o traiga la conexión abajo. La característica de la protección de bucle de STP fue introducida en la versión CatOS 6.2 (1) para las plataformas del Catalyst 4000 and Catalyst 5000, y en la versión 6.2 (2) para la plataforma del catalizador 6000.

Referir a los realces del protocolo de árbol transversal usando la protección de bucle y las características de detección oblicuas BPDU para más información sobre la protección de bucle.

Información operativa general

La protección de bucle controla para determinar si un puerto raíz o un suplente/puerto raíz de respaldo recibe los BPDU. Si el puerto no recibe los BPDU, la protección de bucle pone el puerto en un estado incoherente (bloqueo) hasta que el puerto comienza a recibir los BPDU otra vez. Un puerto en el estado incoherente no transmite los BPDU. Si tal puerto recibe los BPDU otra vez, el puerto (y la conexión) se juzga viable otra vez. La condición del bucle contrario se quita del puerto, y el STP determina a estado de puerto porque tal recuperación es automática.

La protección de bucle aísla el incidente y deja el árbol de expansión converger a una topología estable sin el enlace fallido o el bridge. La protección de bucle previene los bucles del STP con la velocidad de la versión de STP funcionando. No hay dependencia en el STP sí mismo (802.1d o 802.1w) o cuando se ajustan los temporizadores STP. Por estas razones, implementar a protección de bucle conjuntamente con el UDLD en las topologías que confían en el STP y donde el software soporta las características.

Cuando la protección de bucle bloquea un puerto contrario, se registra este mensaje:

%SPANTREE-2-ROOTGUARDBLOCK: Port 1/1 tried to become non-designated
in VLAN 77. Moved to root-inconsistent state.

Cuando el BPDU se recibe en un puerto en un estado del bucle contrario STP, las transiciones de puerto en otro estado del STP. De acuerdo con el BPDU recibido, la recuperación es automática, y no hay intervención necesaria. Después de la recuperación, se registra este mensaje.

SPANTREE-2-LOOPGUARDUNBLOCK: port 3/2 restored in vlan 3.

Interacción con otras características del STP

  • Protección raíz

    La protección raíz fuerza un puerto para ser señalada siempre. La protección de bucle es eficaz solamente si el puerto es el puerto raíz o un puerto alternativo. Estas funciones son mutuamente exclusiva. La protección de bucle y la protección raíz no pueden ser habilitadas 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 un estado de bloqueo, UplinkFast pone un puerto raíz nuevo en el estado de reenvío. También, UplinkFast no selecciona un puerto del bucle contrario como puerto raíz.

  • BackboneFast

    La protección de bucle es compatible con el BackboneFast. La recepción de un BPDU inferior que viene de un BackboneFast de los disparadores del bridge designado. Porque los BPDU se reciben de esta conexión, no activan a la protección de bucle, así que el BackboneFast y la protección de bucle son compatibles.

  • PortFast

    Las PortFast cambias un puerto en la expedición señalaron el estado inmediatamente sobre la conexión. Porque un puerto activado por Portfast no puede ser una raíz o un puerto alternativo, la protección de bucle y PortFast son mutuamente exclusiva.

  • PAgP

    La protección de bucle utiliza los puertos que se conocen al STP. Por lo tanto, la protección de bucle puede aprovecharse de la abstracción de los puertos lógicos a que el PAgP proporciona. Sin embargo, para formar un canal, todos los puertos físicos que se agrupan en el canal deben tener configuraciones compatibles. El PAgP hace cumplir la configuración uniforme de la protección de bucle en todos los puertos físicos para formar un canal.

    Nota: Éstas son advertencias cuando usted configura a protección de bucle en un EtherChannel:

    • El STP escoge siempre el primer puerto operacional en el canal para enviar los BPDU. Si esa conexión llega a ser unidireccional, la protección de bucle bloquea el canal, aunque otras conexiones en la función del canal correctamente.

    • Si los puertos que son bloqueados ya por la protección de bucle se agrupan juntos para formar un canal, los STP pierdes toda la información del estado para esos puertos. El puerto nuevo del canal puede lograr al estado de reenvío con un papel señalado.

    • Si un canal es bloqueado por la protección de bucle y el canal se rompe, los STP pierdes toda la información del estado. Los puertos de los físicos individuales pueden lograr al estado de reenvío con el papel señalado, aunque uno o más de las conexiones que formaron el canal son unidireccionales.

    En los dos casos más más recientes de esta lista, hay una posibilidad de un bucle hasta que el UDLD detecta el incidente. Pero la protección de bucle no puede detectar el bucle.

Protección de bucle y comparación de UDLD

Funciones de la protección de bucle y de la funcionalidad de UDLD traslapo parcialmente. Ambos protegen contra las fallas del STP a que los enlaces unidireccionales causan. Pero estas dos características son diferentes en el acercamiento al problema y también en las funciones. Específicamente, hay ciertas fallas unidireccionales a que el UDLD no puede detectar, por ejemplo los incidentes que son causados por un CPU que no envíe los BPDU. Además, el uso de los temporizadores STP agresivos y el modo RSTP pueden dar lugar a los bucles antes de que el UDLD pueda detectar los incidentes.

La protección de bucle no trabaja en los enlaces compartidos o en las situaciones en las cuales la conexión ha sido unidireccional desde la conexión. En el caso que la conexión ha sido unidireccional desde la conexión, el puerto nunca recibe los BPDU y se señala. Este comportamiento puede ser normal, así que la protección de bucle no cubre este caso particular. UDLS brinda protección contra tal escenario.

Habilitar al UDLD y a protección de bucle para proporcionar al del más alto nivel de la protección. Referir a la protección de bucle contra la sección de la detección de enlace unidireccional de los realces del protocolo de árbol transversal usando la protección de bucle y las características de detección oblicuas BPDU para una protección de bucle y una comparación de UDLD.

Recomendación

El Cisco recomienda que usted habilita a protección de bucle global en una red de switch con los bucles físicos. En la versión 7.1 (1) del software Catalyst y posterior, usted puede habilitar a la protección de bucle global en todos los puertos. Con eficacia, la característica es habilitada en todos los vinculos punto a punto. El estado dúplex de la conexión detecta el vinculo punto a punto. Si el duplex es lleno, la conexión se considera Point-to-Point. Publicar este comando para habilitar a la protección de bucle global:

set spantree global-default loopguard enable

Otras opciones

Para los switches que no soportan la configuración global de la protección de bucle, habilitar la característica en todos los puertos individuales, que incluye los puertos del canal de puerto. Aunque no hay ventajas al enablement de la protección de bucle en un Designated Port, este enablement no es una edición. Además, un reconvergence válido del árbol de expansión puede dar vuelta realmente a un Designated Port en un puerto raíz, que hace la característica útil en este puerto. Publicar este comando para habilitar a la protección de bucle:

set spantree guard loop mod/port

Las redes con las topologías sin bucles pueden todavía beneficiar de la protección de bucle en el caso que los bucles están introducidos accidentalmente. Sin embargo, el enablement de la protección de bucle en este tipo de topología puede conducir a los problemas del Aislamiento de la red. Para construir las topologías sin bucles y evitar los problemas del Aislamiento de la red, publicar estos comandos de invalidar a la protección de bucle global o individualmente. No habilitar a protección de bucle en los enlaces compartidos.

  • set spantree global-default loopguard disable
    
    !--- This is the global default.
    
    

    o

  • set spantree guard none mod/port
    
    
    !--- This is the default port configuration.
    
    

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

La función de protección de raíz proporciona a una manera de hacer cumplir la colocación del bridge de la raíz en la red. La protección raíz se asegura de que el puerto en el cual la protección raíz es habilitada sea el Designated Port. Normalmente, los puertos son todos del bridge de la raíz puertos señalados, a menos que dos o más puertos del bridge de la raíz estén conectados juntos. Si el bridge recibe STP superior BPDU en un puerto guardar-habilitado de la raíz, el bridge mueve este puerto a un estado de la raíz contraria STP. Este estado de la raíz contraria es con eficacia igual a un estado de escucha. No se remite ningún tráfico a través de este puerto. De esta manera, la protección raíz hace cumplir la posición del bridge de la raíz. La protección raíz está disponible en CatOS para el Catalyst 29xx, 4500/4000, 5500/5000, y 6500/6000 en la Versión del software 6.1.1 y posterior.

Información operativa general

La protección raíz es un mecanismo del built-in del STP. La protección raíz no tiene un temporizador sus el propios, y confía en la recepción del BPDU solamente. Cuando aplican a la protección raíz a un puerto, la protección raíz no permite que un puerto se convierta en un puerto raíz. Si la recepción de un BPDU acciona una convergencia del árbol de expansión que haga que un Designated Port se convierte en un puerto raíz, el puerto se pone en un estado de la raíz contraria. Este mensaje de Syslog muestra la acción:

%SPANTREE-2-ROOTGUARDBLOCK: Port 1/1 tried to become non-designated
in VLAN 77. Moved to root-inconsistent state

Después de que el puerto deje de enviar los BPDU superiores, el puerto se desbloquea otra vez. Con el STP, el puerto va del estado de escucha al estado de aprendizaje, y eventual de las transiciones al estado de reenvío. La recuperación es automática, y no hay intervención humana necesaria. Este mensaje de Syslog proporciona a un ejemplo:

%SPANTREE-2-ROOTGUARDUNBLOCK: Port 1/1 restored in VLAN 77

La protección raíz fuerza un puerto para ser señalada y la protección de bucle es eficaz solamente si el puerto es el puerto raíz o un puerto alternativo. Por lo tanto, las dos funciones son mutuamente exclusiva. La protección de bucle y la protección raíz no pueden ser habilitadas en un puerto al mismo tiempo.

Referir al realce de la protección raíz del protocolo del árbol de expansión para más información.

Recomendación

El Cisco recomienda que usted habilita la función de protección de raíz en los puertos que conectan con los dispositivos de red que no son debajo control administrativo directo. Para configurar a la protección raíz, publicar este comando:

set spantree guard root mod/port

EtherChannel

Las Tecnologías EtherChanneles permiten la multiplexión inversa de los múltiples canales (hasta ocho en el Catalyst 6500/6000) en un solo enlace lógico. Si bien la implementación de cada plataforma es diferente, es importante comprender los requisitos comunes:

  • Un algoritmo para multiplexar estadístico las tramas sobre los múltiples canales

  • Creación de un puerto lógico para poder ejecutarse una instancia única del STP

  • Un protocolo de la administración de canal tal como PAgP o protocolo link aggregation control (LACP)

Multiplexión de trama

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

El algoritmo de la distribución de carga es una opción global para ambos protocolos del canal-control. El PAgP y el LACP utilizan el algoritmo de distribución de trama porque la norma IEEE no asigna ninguna algoritmos de distribución por mandato determinada. Sin embargo, cualquier algoritmo de distribución se asegura de que, cuando se reciben las tramas, el algoritmo no cause misordering de los bastidores que son parte de cualquier conversación dada o duplicación de los bastidores.

Nota: Esta información debe ser considerada:

  • El Catalyst 6500/6000 tiene hardware de conmutación más reciente que el Catalyst 5500/5000 y puede leer la información de la capa IP 4 (L4) en la tarifa del alambre para tomar una más decisión de multiplexión inteligente que la información del MAC simple L2.

  • Las capacidades del Catalyst 5500/5000 dependen de la presencia de un Ethernet Bundling Chip (EBC) en el módulo. El comando show port capabilities mod/port confirma cuál es posible para cada puerto.

Referir a este vector, que ilustra el algoritmo de distribución de trama detalladamente para cada plataforma de la lista:

Plataforma

Algoritmo de equilibrio de carga del canal

Serie del Catalyst 5500/5000

Un Catalyst 5500/5000 con los módulos necesarios permite dos a cuatro conexiones a estar presentes por FEC1, aunque deben estar en el mismo módulo. Los pares de dirección de origen y destino de MAC determinan el enlace elegido para el reenvío de tramas. Se realiza una operación X-OR en los dos bits menos significativos de la dirección MAC de origen y la dirección MAC de destino. Esta operación rinde uno de cuatro resultados: (0 0), (0 1), (1 0), ó (1 1). Cada uno de estas puntas de los valores a una conexión en el conjunto del FEC. En el caso de un Fast EtherChannel de dos puertos, únicamente se utiliza un bit en la operación X-OR. Pueden surgir problemas cuando una de las direcciones en el par origen/destino es constante. Por ejemplo, la destinación puede ser un servidor o, aún más probable, un router. En ese caso, se ve el load balancing estadístico porque la dirección de origen es siempre diferente.

Series Catalyst 4500/4000

El EtherChannel del Catalyst 4500/4000 distribuye las tramas a través de las conexiones en un canal (en un solo módulo) basado en los bits de orden bajos de la dirección MAC de origen y destino de cada bastidor. En comparación con el Catalyst 5500/5000, el algoritmo está más implicado y utiliza un picadillo determinista de estos campos del MAC DA (bytes 3, 5, 6), de SA (bytes 3, 5, 6), del puerto de ingreso, y del VLAN ID. El método de distribución de tramas no es configurable.

Serie del Catalyst 6500/6000

Hay dos algoritmos de troceo posibles, dependiendo del hardware del motor supervisor. El picadillo es un polinomio de decimoséptimo grado implementado en hardware que, en todos los casos, tome el MAC address, la dirección IP, o el número del puerto del IP TCP/UDP2 y aplique el algoritmo para generar un valor en bits tres. Esto se realiza de manera separada para las direcciones de origen y destino. Los resultados son entonces XORd para generar otro valor de tres bits que se utilice para determinar qué puerto en el canal se utiliza para remitir el paquete. Los canales en el Catalyst 6500/6000 se pueden formar entre los puertos en cualquier módulo y pueden ser hasta 8 puertos.

1 FEC = Fast EtherChannel

2 UDP = Protocolo de datagrama de usuario

Este vector indica los métodos de distribución soportados en los varios modelos de Supervisor Engine del Catalyst 6500/6000 y su comportamiento predeterminado.

Hardware

Descripción

Métodos de distribución

WS-F6020 (motor L2)

Supervisor Engine 1 temprano

L2 MAC: SA; DA; SA &DA

WS-F6020A (motor L2)

(L3 Engine) del WS-F6K-PFC

Un Supervisor Engine 1 más último y Supervisor Engine 1A/PFC1

L2 MAC: SA; DA; SA &DA

L3 IP: SA; DA; SA y DA (valor por defecto)

WS-F6K-PFC2

Supervisor Engine 2/PFC2 (necesidades CatOS 6.x)

L2 MAC: SA; DA; SA &DA

L3 IP: SA; DA; SA &DA (valor por defecto)

Sesión L4: Puerto de S; Puerto de D; Puerto de S y de D (valor por defecto)

WS-F6K-PFC3BXL

WS-F6K-PFC3B

WS-F6K-PFC3A

Supervisor Engine 720/PFC3A (necesidades CatOS 8.1.x)

Motor 32/PFC3B (necesidades CatOS 8.4.x) del Supervisor Engine 720/Supervisor

Supervisor Engine 720/PFC3BXL (necesidades CatOS 8.3.x)

L2 MAC: SA; DA; SA &DA

L3 IP: SA; DA; SA &DA (valor por defecto)

Sesión L4: Puerto de S; Puerto de D; Puerto de S y de D

IP-VLAN-L4 sesión: SA y VLAN y puerto de S; DA y VLAN y puerto de D; Puerto del SA &DA y del VLAN y de S y puerto de D

Nota: Con la distribución L4, el primer paquete fragmentado utiliza la distribución L4. Todos los paquetes subsiguientes utilizan la distribución L3.

Más detalles del soporte EtherChannel en otras plataformas y cómo configurarlas y localizar averías se pueden encontrar en estos documentos:

Recomendación

El switch del Serie Catalyst 6500/6000 realiza el load balancing de la dirección IP por el valor por defecto. Esto se recomienda en CatOS 5.5, si se asume que el IP es el protocolo dominante. Publicar este comando para fijar el load balancing:

set port channel all distribution ip both

!--- This is the default.

De la distribución de tramas del Catalyst 4500/4000 y 5500/5000 la serie por el MAC address L2 es aceptable en la mayoría de las redes. Sin embargo, la misma conexión se utiliza para todo el tráfico si hay solamente dos dispositivos principal que hablan sobre un canal (pues el S AC y el DMAC son constantes). Esto normalmente puede ser un problema para la copia de respaldo del servidor y otras transferencias de archivos grandes o para un segmento en tránsito entre dos routers.

Aunque el puerto lógico sumado (agport) se puede manejar por el SNMP mientras que un caso distinto y las estadísticas de desempeño total recolectaron, Cisco todavía recomienda que usted maneja cada uno de las interfaces físicas por separado para controlar cómo los mecanismos de distribución de tramas están funcionando y si se está alcanzando el load balancing estadístico.

Un comando new, el comando show channel traffic, en CatOS 6.x puede visualizar los porcentajes de estadística de distribución más fácilmente que si usted controla los contadores de puerto individual con el comando show counters mod/port o el comando show mac mod/port en CatOS 5.x. Otro comando new, el comando show channel hash, en CatOS 6.x permite que usted controle, basado en el modo de distribución, a que el puerto sería seleccionado como el puerto saliente para ciertos direccionamientos y/o los números del puerto. Los comandos equivalentes para los canales del LACP son el comando show lacp-channel traffic y el comando show lacp-channel hash.

Otras opciones

Éstos son pasos de progresión posibles a tomar si las limitaciones relativas de Catalyst 4500/4000 o los algoritmos MAC basados del Catalyst 5500/5000 son una edición, y el buen load balancing estadístico no se alcanza:

  • Switches del Catalyst point-deploy 6500/6000

  • Aumentar la anchura de banda sin acanalar en conmutar, por ejemplo, de varios puertos del FE a un GE portuario, o de varios puertos del GE a un puerto de 10 GE

  • Re-tratar los pares de las estaciones terminales con los flujos de gran capacidad

  • Enlaces dedicados/VLAN de la disposición para los dispositivos de ancho de banda altos

Guías de consulta y restricciones de la configuración de etherchannel

El EtherChannel verifica las características portuarias en todos los puertos físicos antes de que agregue los puertos compatibles en un solo puerto lógico. Las pautas de configuración y las restricciones varían para diversas plataformas del switch seleccionar. Seguir las guías de consulta para evitar de liar los problemas. Por ejemplo, si QoS es habilitado, el EtherChannels no forma al liar los switch modules de la serie del Catalyst 6500/6000 con diversas capacidades de Calidad de Servicio (QoS). En software del IOS de Cisco, usted puede invalidar el cheque del atributo del puerto de QoS en la agrupación de EtherChannel con el comando de la interfaz de canal de puerto del no mls qos channel-consistency. Un comando equivalente para invalidar el cheque del atributo del puerto de QoS no está disponible en CatOS. Usted puede publicar el comando show port capability mod/port para visualizar la capacidad de puerto de QoS y determinarla si los puertos son compatibles.

Seguir estas guías de consulta para diversas plataformas para evitar los problemas de configuración:

Nota: El número máximo de canales de puerto que el catalizador 4000 soporte es 126. Con las versiones de software 6.2 (1) y anterior, los seises y los switches del Serie Catalyst 6500 del nueve slot soportan un máximo del EtherChannels 128. En las versiones de la versión de software 6.2 (2) y posterior, la característica del árbol de expansión dirige el ID del puerto. Por lo tanto, el número máximo de EtherChannels con el soporte es 126 para seises o chasis del nueve slot y 63 para los 13 chasis de la ranura.

Protocolo de agrupamiento de puertos

El PAgP es un protocolo de administración que las comprobaciones para la coherencia de parámetros en cualquier final de la conexión y asisten al canal en adaptarse a la falla de enlace o a la adición. Observar estos hechos sobre el PAgP:

  • PAgp requiere que todos los puertos del canal pertenezcan a la misma VLAN o estén configurados como puertos troncales. (Como las VLAN dinámicas pueden forzar el cambio de un puerto a una VLAN diferente, no están incluidas en la participación EtherChannel).

  • Cuando un agrupamiento ya existe y se modifica la configuración de un puerto (como la modificación del modo de la concentración de enlaces o de la VLAN), todos los puertos del agrupamiento se modifican para coincidir con dicha configuración.

  • El PagP no agrupa puertos que operan a velocidades diferentes ni dúplex de puerto. Si se modifica la velocidad y dúplex cuando existe un agrupamiento, PAgP modifica la velocidad del puerto y el dúplex para todos los puertos del agrupamiento.

Información operativa general

El puerto del PAgP controla cada puerto de los físicos individuales (o lógico) que se agrupará. Se envían los paquetes PAgP usando a la misma dirección MAC de grupo de multidifusión que se utiliza para los paquetes CDP, 01-00-0c-cc-cc-cc. El valor del protocolo es 0x0104. Éste es un resumen de la operación de protocolo:

  • Siempre que el puerto físico está en funcionamiento, los paquetes PAgP son transmitidos cada segundo durante la detección y cada 30 segundos en estado estable.

  • El protocolo espera a escuchar los paquetes PAgP que prueban que el puerto físico tiene una conexión bidireccional a otro dispositivo PAgP capaz.

  • Si se reciben paquetes de datos pero no paquetes PAgp, se asume que el puerto está conectado a un dispositivo no habilitado para Pagp.

  • En cuanto un grupo de puertos físicos reciben dos paquetes PAgP, trata de formar un puerto agregado.

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

Procesamiento normal

Estos conceptos se deben definir para ayudar a la comprensión del comportamiento del protocolo:

  • Puerto lógico integrado por todos los puertos físicos en la misma agregación, del Agport-uno puede ser identificado por su propio ifIndex SNMP. Por lo tanto, un puerto agregado no contiene puertos no operativos.

  • Agregación del Canal-uno que satisface los criterios de formación; por lo tanto podría contener los puertos no operativos (el agports es un subconjunto de los canales). Los protocolos, incluyendo STP y VTP incluidos, pero no CDP y DTP, se ejecutan en PAgP sobre los agports (puertos ag). Ninguno de estos protocolos puede enviar o recibir paquetes hasta que PAgP adjunte sus agports a uno o más puertos físicos.

  • Agrupar Capacidad-cada puerto físico y el agport posee un parámetro de la configuración llamado la cpacidad de grupo. Un puerto físico puede ser agregado a otro puerto físico sólo si tienen la misma capacidad de grupo.

  • Agregación Procedimiento-cuando un puerto físico alcanza al UpData o a estado UpPAgP, se asocia a un agport apropiado. Cuando deja cualquiera de esos estados para pasar a otro, se separa del puerto agregado.

Las definiciones de los estados y de los procedimientos de creación se dan en este vector:

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. Los paquetes Non-PAgP (Protocolo de puerto agregado) entran y salen entre el puerto físico y el puerto agregado.

BiDir

Un paquete PAgP se ha recibido exactamente que prueba que una conexión bidireccional existe a exactamente un vecino. El puerto físico no está conectado a ningún puerto agregado. Los paquetes PAgP se envían y pueden ser recibidos.

UpPAgP

Este puerto físico, tal vez en asociación con otros puertos físicos, está conectado a un puerto agregado. 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 puerto agregado.

Los dos extremos de las dos conexiones deben coincidir sobre lo que será el agrupamiento, definido como el mayor grupo de puertos en el puerto agregado que está permitido por los dos extremos de la conexión.

Cuando un puerto físico alcanza a estado UpPAgP, se asigna al agport que tiene puertos físicos del miembro que correspondan con la cpacidad de grupo del puerto físico nuevo y que estén en el BiDir o el estado UpPAgP. (Cualesquiera puertos del BiDir se mueven al estado UpPAgP al mismo tiempo.) Si no existe un agport cuyos parámetros de puerto físico constituyentes sean compatibles con el puerto físico recientemente activo, éste se asigna a un agport con parámetros adecuados que no tengan puertos físicos asociados.

El tiempo de espera PAgP puede producirse en el último vecino conocido del puerto físico. El intervalo de espera del puerto se elimina del puerto agregado. Al mismo tiempo, se eliminarán todos los puertos físicos en el mismo agport (puerto agregado) cuyos temporizadores también hayan agotado el tiempo de espera. Esto activa un puerto agregado cuyo otro extremo ha muerto para ser derribado al mismo tiempo, en lugar de un puerto físico por vez.

Comportamiento en caso de fallas

Si una conexión en un canal existente se falla, (por ejemplo, el [GBIC] desenchufado, del convertidor de la interfaz de Gigabite portuario quitado, o fibra rota), el agport es actualizado y el tráfico hashed sobre las conexiones restantes dentro del segundo. Ningún tráfico que no necesite rehashed después de que el incidente (el tráfico que continúa enviando encendido la misma conexión) no sufre ninguna pérdida. La restauración del enlace fallido acciona otra actualización al agport, y el tráfico hashed otra vez.

Nota: El comportamiento cuando una conexión falla en un canal debido a una potencia-apagado o al retiro de un módulo puede ser diferente. Por la definición, necesitan ser dos puertos físicos a un canal. Si se pierde un puerto del sistema en un canal de dos puertos, el puertoag (agport) es desmontado y se reinicia el puerto físico original teniendo en cuenta el árbol de expansión. Esto significa el tráfico puede ser desechado hasta que el STP permite que el puerto llegue a estar disponible para los datos otra vez.

Hay una anomalía a esta regla en el Catalyst 6500/6000. En las versiones anterior que CatOS 6.3, un agport no se rasga abajo durante la extracción del módulo si el canal se abarca de los puertos en los módulos 1 y 2 solamente.

Esta diferencia en los dos modos de la falla es importante cuando el mantenimiento de una red se planea, pues puede haber un STP TCN a considerar al realizar una eliminación en línea o una inserción de un módulo. Según lo indicado, es importante manejar cada vículo físico en el canal con el NMS puesto que el agport puede seguir siendo imperturbado con un incidente.

Éstos son pasos sugeridos para atenuar un cambio de topología no deseado en el Catalyst 6500/6000:

  • Si un solo puerto se utiliza por el módulo para formar un canal, tres o más módulos deben ser utilizados (tres puertos o más totales).

  • Si el canal atraviesa dos módulos, dos puertos en cada módulo deben ser utilizados (cuatro puertos totales).

  • Si un canal con dos puertos es necesario a través de dos tarjetas, utilizar solamente los puertos del Supervisor Engine.

  • La actualización a CatOS 6.3, que administra la renovación de módulos sin recálculo de STP para la división de canales a través de los módulos.

Opciones de configuración

El EtherChannels se puede configurar en diversos modos, según lo resumido en este vector:

Modo

Opciones configurables

Activado

PAgP fuera de funcionamiento. El puerto está canalizando independientemente de la configuración del puerto vecino. Si el puerto del vecino está encendido se forma un canal.

Desactivado

El puerto no está acanalando sin importar cómo configuran al vecino.

automático (default)

El agrupamiento está bajo el control del protocolo PAgP. Se coloca un puerto en estado de negociación pasivo y no se envían paquetes PAgP a la interfaz hasta que se reciba al menos un paquete PAgP que indique que el remitente opera en modo deseable.

Deseable

El agrupamiento está bajo el control del protocolo PAgP. Coloca a un puerto en un estado de negociación activa, en el que el puerto inicia negociaciones con otros puertos al enviar paquetes PagP. Un canal está formado con otro grupo de puertos, ya sea en modo deseable o automático.

No silencioso (valor por defecto en la fibra FE del Catalyst 5500/5000 y los puertos del GE)

Un modo de palabra clave automático o deseable. Si no se recibe ningunos paquetes de datos en la interfaz, después la interfaz nunca se asocia a un agport y no se puede utilizar para los datos. Este cheque del bidirectionality fue proporcionado para el hardware específico del Catalyst 5500/5000 como algunas fallas de enlace dan lugar al canal que es roto aparte. Porque el modo no silencioso es habilitado, un puerto de vecino de recuperación nunca se permite venir respaldo y romper el canal aparte innecesariamente. Más agrupación flexible y cheques mejorados del bidirectionality están presentes por el valor por defecto en hardware de la serie del Catalyst 4500/4000 y 6500/6000.

Silencioso (valor por defecto en todo el Catalyst 6500/6000 y 4500/4000 de los puertos y 5500/5000 de los puertos de cobre)

Un modo de palabra clave automático o deseable. Si no se recibe ningunos paquetes de datos en la interfaz, después de un segundo período de agotamiento del tiempo de espera 15, la interfaz son asociados por sí mismo a un agport y se pueden utilizar así para la Transmisión de datos. El modo silencioso además permite la operación del canal en el caso de un socio que puede ser un analizador o un servidor que nunca envía PAgP.

Los parámetros de silencio o de no silencio afectan cómo los puertos reaccionan a las situaciones que causan el tráfico unidireccional o dejar-sobre cómo alcanzan. Cuando un puerto no puede transmitir (debido a un [PHY] fallado de la subcapa física o una fibra dañada o un cable, por ejemplo), éste puede todavía salir del puerto de vecino en un estado operacional. El socio sigue transmitiendo datos, pero éstos se pierden porque no se puede recibir al tráfico de retorno. También pueden formarse bucles en el árbol de expansión a causa de la naturaleza unidireccional del enlace.

Algunos puertos de fibra tienen la capacidad de llevar al puerto a un estado no funcional cuando pierde la señal de recepción (FEFI). Esto hace el puerto del socio ir no operacional y hace con eficacia los puertos en los ambos extremos de la conexión ir abajo.

Al usar los dispositivos que transmiten los datos (tales como BPDU) y no pueden detectar las condiciones unidireccionales, el modo no silencioso debe ser utilizado para permitir que los puertos sigan siendo no operacionales hasta que recibir los datos es presente y la conexión se verifica para ser bidireccional. El tiempo que toma para que el PAgP detecte un enlace unidireccional es alrededor 3.5 * 30 segundos = 105 segundos, donde están el tiempo 30 segundos entre dos mensajes PAgP sucesivos. Se recomienda el UDLD como un detector más rápido de enlaces unidireccionales.

Al usar los dispositivos que no transmiten ningunos datos, el modo silencioso debe ser utilizado. Esto fuerza el puerto para llegar a ser conectado y operacional sin importar si los datos recibidos están presentes o no. Además, para esos puertos que puedan detectar la presencia de una condición unidireccional, tal como más nuevas plataformas usando L1 FEFI y UDLD, el valor por defecto utiliza al modo silencioso.

Verificación

es el vector representa un resumen de todos los escenarios de modo de canalización posibles del PAgP entre dos directamente switches conectados (Switch-a y Switch-b). Algunas de estas combinaciones pueden hacer el STP poner los puertos en el lado de canalización en el estado de errDisable (es decir, algunas de las combinaciones apagan los puertos en el lado de canalización).

Modo de canal de Switch-A

Modo de canal del switch B

Estado del canal

Activado

Activado

Canal (no PAgP)

Activado

Desactivado

Sin canal (puerto errdisable)

Activado

Auto

Sin canal (puerto errdisable)

Activado

Deseable

Sin canal (puerto errdisable)

Desactivado

Activado

Sin canal (puerto errdisable)

Desactivado

Desactivado

Sin canal

Desactivado

Auto

Sin canal

Desactivado

Deseable

Sin canal

Auto

Activado

Sin canal (puerto errdisable)

Auto

Desactivado

Sin canal

Auto

Auto

Sin canal

Auto

Deseable

Canal PAgP

Deseable

Activado

Sin canal (puerto errdisable)

Deseable

Desactivado

Sin canal

Deseable

Auto

Canal PAgP

Deseable

Deseable

Canal PAgP

Recomendación

El Cisco recomienda ese PAgP sea habilitado en todas las conexiones de canal del switch a switch, evitando en el modo. El método preferido es fijar el desirable mode en los ambos extremos de una conexión. La recomendación adicional es dejar el silencioso/la palabra clave no silenciosa en el valor por defecto - silencioso en el Catalyst 6500/6000 y 4500/4000 de los switches, no silenciosos en los puertos de fibra del Catalyst 5500/5000.

Según lo discutido en este documento, la Configuración explícita de acanalar apagado en el resto de los puertos es provechosa para la expedición de los rápidos de datos. Esperar hasta 15 segundos el PAgP al descanso en un puerto que no deba ser utilizado para acanalar se debe evitar, especialmente puesto que el puerto entonces se entrega al STP, que sí mismo pueden tomar a 30 segundos para permitir el reenvío de datos, más potencialmente 5 segundos para el DTP para un total de 50 segundos. El comando set port host se discute más detalladamente en la sección del STP de este documento.

set port channel port range mode desirable

set port channel port range mode off

!--- Ports not channeled; part of the set port hostcommand.

Este comando asigna a los canales un número de grupo de administradores, que puede verse mediante la ejecución del comando show channel group. La adición y el retiro del puerto de canalización al mismo agport se pueden entonces manejar por el número de administrador si está deseada.

Otras opciones

Otra configuración común para los clientes que tienen un modelo de administración mínima en la capa de acceso es fijar el modo a deseable en la distribución y las capas del núcleo, y deja los switches de capa de acceso en la configuración automática predeterminada.

Al acanalar a los dispositivos que no soportan el PAgP, el canal necesita ser hard-coded encendido. Esto se aplica a los dispositivos tales como servidores, Local Director, Content Switches, routers, switches con un más viejo software, Catalyst XL switches, y Catalyst 8540s. Ejecutar este comando:

set port channel port range mode on

La norma IEEE para LACP nueva 802.3ad, disponible en CatOS 7.x, reemplazará probablemente el PAgP al largo plazo porque trae la ventaja de la cruz-plataforma y de la interoperabilidad entre vendedores.

Protocolo link aggregation control

El LACP es un protocolo que permite que los puertos con las características similares formen un canal con la negociación dinámica con los switches contiguos. El PAgP es un protocolo de propiedad de Cisco que se puede ejecutar solamente en los switches Cisco y esos switches que son liberados por los vendedores licenciados. Pero el LACP, que se define en IEEE 802.3ad, permite que los switches Cisco manejen Ethernet que acanala con los dispositivos que se conforman con la especificación 802.3ad. Las versiones de software de CatOS 7.x introdujeron el soporte del LACP.

Hay diferencia muy pequeña entre el LACP y el PAgP de una perspectiva funcional. Ambos protocolos soportan un máximo de ocho puertos en cada canal, y las características del mismo puerto se controlan antes de la formación del conjunto. Estas características portuarias incluyen:

  • Velocidad

  • Dúplex

  • VLAN nativa

  • Tipo del Trunking

Las diferencias notables entre el LACP y el PAgP son:

  • El LACP puede ejecutarse solamente en los puertos dúplex completos, y el LACP no soporta los puertos semi dúplexes.

  • El LACP soporta los puertos de la espera en caliente. El LACP intenta siempre configurar el número máximo de puertos compatibles en un canal, hasta el número máximo que el hardware permite (ocho puertos). Si el LACP no puede agregar todos los puertos que sean compatibles, todos los puertos que no se pueden incluir activamente en el canal se ponen en el estado de la espera en caliente y se utilizan solamente si uno de los puertos usados falla. Un ejemplo de una situación en la cual el LACP no pueda agregar todos los puertos compatibles es si el sistema remoto tiene limitaciones del hardware más-restrictivas.

Nota: En CatOS, el número máximo de puertos que el mismo clave administrativo pueda ser asignado es ocho. En software del IOS de Cisco, el LACP intenta configurar el número máximo de puertos compatibles en un EtherChannel, hasta el número máximo que el hardware permite (ocho puertos). Los ocho puertos adicionales se pueden configurar como puertos de la espera en caliente.

Información operativa general

El LACP controla cada puerto de los físicos individuales (o lógico) que sea ser unido. Los paquetes LACP se envían con el uso de la dirección MAC de grupo de multidifusión, 01-80-c2-00-00-02. El tipo/el valor de campo es 0x8809 con un subtipo de 0x01. Aquí está un resumen de la operación de protocolo:

  • El protocolo confía en los dispositivos para anunciar sus Capacidades de agrupamiento y información del estado. Las transmisiones se envían en un regular, forma periódica en cada conexión “aggregatable”.

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

  • Los socios en una conexión “aggregatable” escuchan la información que se envía dentro del protocolo y deciden qué acciones a tomar.

  • Los puertos compatibles se configuran en un canal, hasta el número máximo que el hardware permite (ocho puertos).

  • Las agregaciones son mantenidas por el intercambio regular, oportuno de la información del estado actualizada entre los socios de enlace. Si los cambios de configuración (debido a una falla de enlace, por ejemplo), los socios del protocolo miden el tiempo hacia fuera y toman la acción apropiada en base del nuevo estado del sistema.

  • Además de las transmisiones periódicas de la unidad de datos del LACP (LACPDU), si hay un cambio a la información del estado, el protocolo transmite un LACPDU event-driven al socio. Los socios del protocolo toman la acción apropiada en base del nuevo estado del sistema.

Parámetros LACP

Para permitir que el LACP determine si un conjunto de las conexiones conecta con el mismo sistema y si esas conexiones son compatibles desde el punto de vista de la agregación, la capacidad de establecer estos parámetros es necesaria:

  • Global un Identificador único para cada sistema que participa en la agregación de la conexión

    Cada sistema que ejecute el LACP se debe asignar una prioridad que se puede elegir automáticamente o por el administrador. La prioridad del sistema predeterminado es 32768. La prioridad del sistema se utiliza principalmente conjuntamente con el MAC address del sistema para formar el identificador del sistema.

  • Medios de la identificación del conjunto de las capacidades que se asocian a cada puerto y a cada aggregator, como un sistema dado las entiende

    Cada puerto en el sistema se debe asignar una prioridad automáticamente o por el administrador. El valor por defecto es 128. La prioridad se utiliza conjuntamente con el número del puerto para formar el identificador de puerto.

  • Medios de la identificación de un grupo de la agregación de la conexión y de su aggregator asociado

    La capacidad de un puerto de agregar con otro es resumida por un parámetro simple del número entero de 16 dígitos binarios que sea terminantemente cero mayor que. Este parámetro se llama el “clave”. Diversos factores determinan cada clave, por ejemplo:

    • Las características físicas portuarias, que incluyen:

      • Data rate

      • Duplexity

      • Point-to-Point o medio compartido

    • Restricciones de configuración que el administrador de la red establece

    Dos claves se asocian a cada puerto:

    • Un administrativo clave-Este clave permite la manipulación de los valores de la clave de la gerencia. Un usuario puede elegir este clave.

    • Un sistema operacional del clave- utiliza este dominante para formar las agregaciones. Un usuario no puede elegir o cambiar directamente este clave.

      El conjunto de puertos en un sistema que comparte el mismo valor de la clave operacional serían a miembros del mismo grupo dominante.

Si usted tiene dos sistemas y un conjunto de puertos con el mismo clave administrativo, los intentos de cada sistema para agregar los puertos. Cada sistema empieza en el puerto con la prioridad más alta en el sistema de la prioridad más alta. Este comportamiento es prioridad posible porque cada sistema sabe su propia prioridad, que el usuario o el sistema ha asignado, y la su del socio, que fue descubierta a través de los paquetes LACP.

Comportamiento en caso de fallas

El comportamiento de falla para el LACP es igual que el comportamiento para el PAgP. Si una conexión en un canal existente se falla, el agport es actualizado y el tráfico hashed sobre las conexiones restantes dentro del segundo. Una conexión puede fallar por éstos y otras razones:

  • Se desenchufa un puerto

  • Se quita Un GBIC

  • Una fibra está quebrada

  • Falla de hardware (interfaz o módulo)

Ningún tráfico que no necesite rehashed después de que el incidente (el tráfico que continúa enviando encendido la misma conexión) no sufre ninguna pérdida. La restauración del enlace fallido acciona otra actualización al agport, y el tráfico hashed otra vez.

Opciones de configuración

Los EtherChanneles LACP se pueden configurar en diversos modos, pues este vector resume:

Modo

Opciones configurables

Activado

La agregación de la conexión se fuerza para ser formada sin ninguna negociación LACP. El switch ni envía el paquete LACP ni procesa cualquier paquete LACP entrante. Si el puerto del vecino está encendido se forma un canal.

Desactivado

El puerto no está acanalando, sin importar cómo configuran al vecino.

Voz pasiva (valor por defecto)

Esto es similar al modo automático en PagP. El switch no inicia el canal, sino entiende los paquetes LACP entrantes. El par (en el estado activo) inicia la negociación enviando un paquete LACP. El switch recibe y contestó al paquete, y forma eventual el canal de la agregación con el par.

Activo

Esto es similar al desirable mode en el PAgP. El switch inicia la negociación para formar un aglink. Se forma el agregado de la conexión si el otro extremo se ejecuta en el LACP activo o el modo pasivo.

Verificación (LACP y LACP)

El vector en esta sección representa un resumen de todos los escenarios de modo de canalización posibles del LACP entre dos directamente switches conectados (Switch-a y Switch-b). Algunas de estas combinaciones pueden hacer el STP poner los puertos en el lado de canalización en el estado de errDisable. Esto significa que algunas de las combinaciones apagan los puertos en el lado de canalización.

Modo de canal de Switch-A

Modo de canal del switch B

Estado del canal del Switch-a

Estado del canal del 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

Verificación (LACP y PAgP)

El vector en esta sección representa un resumen de todos los escenarios de modo de canalización posibles del LACP-a-PAgP entre dos directamente switches conectados (Switch-a y Switch-b). Algunas de estas combinaciones pueden hacer el STP poner los puertos en el lado de canalización en el estado de errDisable. Esto significa que algunas de las combinaciones apagan los puertos en el lado de canalización.

Modo de canal de Switch-A

Modo de canal del switch B

Estado del canal del Switch-a

Estado del canal del Switch-b

Activado

Activado

Canal (no-LACP)

Canal (no PAgP)

Activado

Desactivado

Sin canal (puerto errdisable)

Sin canal

Activado

Auto

Sin canal (puerto errdisable)

Sin canal

Activado

Deseable

Sin canal (puerto errdisable)

Sin canal

Desactivado

Activado

Sin canal

Sin canal (puerto errdisable)

Desactivado

Desactivado

Sin canal

Sin canal

Desactivado

Auto

Sin canal

Sin canal

Desactivado

Deseable

Sin canal

Sin canal

pasivo

Activado

Sin canal

Sin canal (puerto errdisable)

pasivo

Desactivado

Sin canal

Sin canal

pasivo

Auto

Sin canal

Sin canal

pasivo

Deseable

Sin canal

Sin canal

Activo

Activado

Sin canal

Sin canal (puerto errdisable)

Activo

Desactivado

Sin canal

Sin canal

Activo

Auto

Sin canal

Sin canal

Activo

Deseable

Sin canal

Sin canal

Recomendación

El Cisco recomienda que usted habilita el PAgP en las conexiones de canal entre los switches Cisco. Cuando usted acanala a los dispositivos que no soportan el PAgP sino el soporte LACP, habilitar el LACP con la configuración del LACP activa en los ambos extremos de los dispositivos. Si el extremo de los dispositivos no soporta el LACP o el PAgP, usted necesita cifrar difícilmente el canal a encendido.

  • set channelprotocol lacp module
    
    

    En los switches que ejecutan CatOS, todos los puertos en un Catalyst 4500/4000 y un PAgP del protocolo del canal del uso del Catalyst 6500/6000 por el valor por defecto y, como tal, no ejecutar el LACP. Para configurar los puertos para utilizar el LACP, usted necesita fijar el protocolo del canal en los módulos al LACP. El LACP y el PAgP no pueden ejecutarse en el mismo módulo en los switches que ejecutan CatOS.

  • set port lacp-channel port_range admin-key
    
    

    Un parámetro de la clave de administración (clave administrativo) se intercambia en el paquete LACP. Un canal forma solamente entre los puertos que tienen la misma clave de administración. El comando set port lacp-channel port_range admin-key asigna a canales un número de la clave de administración. El comando show lacp-channel group muestra el número. El comando set port lacp-channel port_range admin-key asigna la misma clave de administración a todos los puertos en el rango de puertos. La clave de administración se asigna aleatoriamente si un clave específico no se configura. Entonces, usted puede referir a la clave de administración, si está deseado, para manejar la adición y el retiro del puerto de canalización al mismo agport.

  • set port lacp-channel port_range mode active
    

    El comando set port lacp-channel port_range mode active cambia a modo del canal a activo para un conjunto de puertos que fue asignada previamente la misma clave de administración.

Además, el LACP utiliza un segundo temporizador por intervalos 30 (Slow_Periodic_Time) después de que se establezcan los EtherChanneles LACP. El número de los segundos antes de la invalidación de información de LACPDU recibida con el uso de los descansos largos (3 x Slow_Periodic_Time) es 90. Utilizar el UDLD, que es un más detector rápido de los enlaces unidireccionales. Usted no puede ajustar los temporizadores del LACP, y usted no puede configurar hoy los switches para utilizar la transmisión rápida del PDU (cada segundo) para mantener el canal después de que se forme el canal.

Otras opciones

Si usted tiene un modelo de administración mínima en la capa de acceso, una configuración común es fijar el modo a activo en la distribución y las capas del núcleo. Dejar los switches de capa de acceso en la configuración pasiva predeterminada.

Detección de enlace unidireccional

El UDLD es un propietario del Cisco, el protocolo liviano que fue desarrollado para detectar los casos de las comunicaciones unidireccionales entre los dispositivos. Aunque hay otros métodos para detectar el estado bidireccional de los medios de transmisión, como el FEFI, hay ciertos casos en los cuales los mecanismos de detección L1 no son suficientes. Estos escenarios pueden dar lugar a ninguno de estos ocurrencias:

  • La operación impredecible del STP

  • Incorrecto o Inundación excesiva de los paquetes

  • Los envíos a agujeros negros del tráfico

La característica del UDLD se piensa para tratar estas condiciones de falla en las interfaces de Ethernet de la fibra y del cobre:

  • Monitorear las configuraciones del cableado físico y apagar cualquier puerto del miswired como errdisable.

  • Proteger contra los enlaces unidireccionales. Cuando se detecta un enlace unidireccional, debido a los media o al funcionamiento incorrecto de puerto/interfaz, el puerto afectado se apaga como errdisable, y se genera un mensaje de Syslog correspondiente.

  • Además, el modo agresivo del UDLD controla que una conexión que previamente era juzgada bidireccional no pierde la conectividad durante la congestión y no llega a ser inutilizable. El UDLD realiza las pruebas de conectividad en curso a través de la conexión. El propósito primario del modo agresivo del UDLD es evitar los envíos a agujeros negros del tráfico en ciertas condiciones falladas.

El árbol de expansión, con su flujo BPDU unidireccional del estado constante, era una víctima importante de estos incidentes. Es fácil ver cómo un puerto puede repentinamente no poder transmitir los BPDU, causando un cambio de estado del STP del bloqueo a la expedición en el vecino. Este cambio crea un bucle, puesto que el puerto todavía puede recibir.

Información operativa general

El UDLD es un protocolo L2 que trabaja sobre la capa del LLC (MAC de destino 01-00-0c-cc-cc-cc, tipo RÁPIDO 0x0111 del Protocolo HDLC.). Al ejecutar el UDLD conjuntamente con los mecanismos del FEFI y del autonegotiation L1, es posible validar la integridad física (L1) y lógica (L2) de una conexión.

El UDLD tiene provisiones para las características y la protección que el FEFI y el autonegotiation no pueden realizarse, a saber la detección y el almacenamiento en memoria inmediata de la información de vecino, la capacidad de apagar cualquier puerto inadecuadamente conectado, y detectó los malos funcionamientos de puerto/interfaz lógica o los incidentes en las conexiones que no son Point-to-Point (ésos que atraviesan los conversores de medios o los cubos).

El UDLD emplea dos mecanismos básicos; aprende sobre los vecinos, y mantiene la información actualizada a caché local, y envía un tren de los mensajes de la sonda/de la generación de eco del UDLD (hola) siempre que detecte a nuevo vecino o siempre que un vecino solicita una resincronización de la memoria inmediata.

El UDLD envía constantemente los mensajes de la sonda en todos los puertos en los cuales el UDLD sea habilitado. Siempre que un específico “que acciona” el mensaje UDLD se reciba en un puerto, una fase y un proceso de validación de la detección comienza. Si en el final de este proceso se resuelven todas las condiciones válidas, no alteran al estado de puerto. Para resolver las condiciones, el puerto debe ser bidireccional y ató con alambre correctamente. Si no, el puerto es errdisable, y visualizaciones de un mensaje de Syslog. El mensaje de Syslog es similar a estos mensajes:

  • UDLD-3-DISABLE: Enlace unidireccional detectado en [dec]/[dec] del puerto. Lisiado portuario

  • UDLD-4-ONEWAYPATH: Un enlace unidireccional de [dec]/[dec] del puerto para virar [dec] hacia el lado de babor/[dec] del dispositivo [chars] fue detectado

Referir a los mensajes y a los Procedimientos de recuperación (switches del Serie Catalyst, 7.6) para una lista completa de mensajes del sistema por el recurso, que incluye los eventos UDLD.

Después de que una conexión se establezca y se clasifique como bidireccional, el UDLD continúa anunciando los mensajes de sonda/eco en un intervalo predeterminado de 15 segundos. Este vector representa los estados válidos de la conexión del UDLD según lo señalado en la salida del comando show udld port:

Estado de puerto

Comentario

Indeterminado

La detección en marcha, o una entidad de UDLD de vecindad ha estado invalidada o se ha bloqueado su transmisión.

No aplicable

El UDLD ha estado invalidado.

Cierre

Se ha detectado el enlace unidireccional y el puerto ha estado invalidado.

Bidireccional

Se ha detectado la conexión bidireccional.

  • La memoria caché de vecino Mantenimiento-UDLD envía periódicamente hola la sonda/los paquetes de eco en cada interfaz activa, para mantener la integridad de la memoria inmediata del vecino UDLD. Toda vez que reciba un mensaje de saludo, éste se guardará en memoria y se almacenará por un período de tiempo máximo definido como período de inactividad. Cuando finaliza la retención de tiempo, caduca la entrada de memoria caché correspondiente. Si se recibe un nuevo mensaje de saludo dentro del período de inactividad, la nueva entrada reemplaza a la anterior y el temporizador de tiempo de vida correspondiente se reinicia.

  • Con el objeto de mantener la integridad de la memoria caché UDLD, cada vez que una interfaz habilitada para UDLD se inhabilita o se reinicia un dispositivo, todas las entradas de memoria caché existentes para las interfaces afectadas por el cambio de configuración se borran y el UDLD transmite por lo menos un mensaje para informar a sus respectivos vecinos que purguen las entradas de memoria caché correspondientes.

  • Producir eco las formas del mecanismo del Mecanismo- de la detección que producen eco la base del algoritmo de detección. Cada vez que un dispositivo UDLD detecta un nuevo vecino o recibe una solicitud de resincronización de un vecino desincronizado, inicia/reinicia la ventana de detección en su lado de la conexión y envía una ráfaga de mensajes eco como respuesta. Debido a que este comportamiento debe ser el mismo en todos los vecinos, el emisor de eco espera recibir ecos como respuesta. Si no se ha recibido los fines de la ventana de detección y ningún mensaje de respuesta válido, la conexión se considera unidireccional, y un reestablecimiento o un proceso de cierre de puerto de la conexión puede ser accionado.

Tiempo de convergencia

Para prevenir los bucles del STP, CatOS 5.4 (3) redujo el intervalo de mensajes predeterminado del UDLD a partir de 60 segundos a 15 segundos para apagar un enlace unidireccional antes de que un puerto bloqueado pudiera a la transición a un estado de reenvío.

Nota: El valor del intervalo entre mensajes determina la tarifa en la cual un vecino envía las sondas del UDLD después de la fase de la conexión o de la detección. El intervalo entre mensajes no necesita corresponder con en los ambos extremos de una conexión, aunque la configuración coherente es deseable en lo posible. Cuando establecen a los vecinos UDLD, se envía el intervalo entre mensajes configurado y el intervalo de tiempo de espera para ese par se calcula para ser (3 * message_interval). Por lo tanto, una relación de pares mide el tiempo hacia fuera después de que se falten tres hellos consecutivos (o las sondas). Con los intervalos entre mensajes diferentes en cada lado, este valor de agotamiento del tiempo es diferente en cada lado.

La hora aproximada que es necesaria para que el UDLD detecte a una falla unidireccional está aproximadamente (2.5 * message_interval + 4 segundos), o cerca de 41 segundos con el uso del intervalo de mensajes predeterminado de 15 segundos. Esto es bien debajo de los 50 segundos que son generalmente necesarios para el STP al reconverge. Si el NMP CPU tiene algunos ciclos de repuesto y si usted monitorea cuidadosamente su nivel de utilización, usted puede reducir el intervalo entre mensajes (incluso) al mínimo de 7 segundos. Este intervalo entre mensajes ayuda a acelerar la detección por un factor importante.

Por lo tanto, el UDLD tiene un supuetsta dependencia en los temporizadores predeterminados del árbol de expansión. Si usted ajusta el STP para converger más rápidamente que el UDLD, considerar un mecanismo alternativo, tal como la característica de la protección de bucle de CatOS 6.2. También considerar un mecanismo alternativo cuando usted implementa RSTP (IEEE 802.1W) porque el RSTP tiene características de convergencia en los milisegundos, que depende de la topología. Para estos casos, protección de bucle del uso conjuntamente con el UDLD, que proporciona a la mayoría de la protección. La protección de bucle previene los bucles del STP con la velocidad de la versión de STP que es funcionando, y el UDLD detecta las conexiones unidireccionales en los enlaces EtherChanneles individuales o en los casos en los cuales los BPDU no fluyen a lo largo de la dirección quebrada.

Nota: El UDLD no coge cada situación de la falla del STP, tal como incidentes que sean causados por un CPU que no envíe los BPDU por una época mayor que (2 * FwdDelay + Maxage). Por esta razón, el Cisco recomienda que usted implementa el UDLD conjuntamente con la protección de bucle (que fue introducida en CatOS 6.2) en las topologías que confían en el STP.

precaución Precaución: Guardarse de las versiones anteriores del UDLD que utilizan un segundo intervalo de mensajes predeterminado del nonconfigurable 60. Estas versiones son susceptibles a las condiciones del bucle del árbol de expansión.

Modo agresivo del UDLD

El UDLD agresivo fue creado para tratar específicamente esos casos (pocos) en los cuales una prueba en curso de la conectividad bidireccional es necesaria. Como tal, la característica del modo agresivo proporciona a la protección mejorada contra las condiciones peligrosas de enlace unidireccional en estas situaciones:

  • Cuando la pérdida de UDLD PDU es simétrica y los ambos extremos miden el tiempo hacia fuera, ninguno de los dos puertos errdisabled.

  • Un lado de una conexión tiene un puerto pegado (ambos transmiten el [Tx] y el Rx).

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

  • El autonegotiation, u otro mecanismo de la detección de falla L1, es lisiados.

  • Una reducción de la confianza en los mecanismos FEFI L1 es deseable.

  • La protección máxima contra los Errores de enlace unidireccional en las conexiones del Point-to-Point FE/GE es necesaria. Específicamente, donde no hay admisible incidente entre dos vecinos, las sondas UDLD-agresivas se pueden considerar como “latido del corazón”, la presencia de el cual garantiza la salud de la conexión.

El caso más común para una implementación del UDLD agresivo es para realizar el cheque de la conectividad en un miembro de un conjunto cuando el autonegotiation u otro mecanismo de la detección de falla L1 es lisiado o inutilizable. Esto es determinado verdad con las conexiones EtherChanneles porque PAgP/LACP, incluso si están habilitados, no utilizan los temporizadores de saludo muy bajos en el estado constante. En este caso, el UDLD agresivo tiene la ventaja agregada de la prevención de los bucles del árbol de expansión posibles.

Las circunstancias que contribuyen a la pérdida simétrica de los paquetes de sondeo del UDLD son más difíciles de caracterizar. Usted debe entender que el UDLD normal controla para saber si hay una condición del enlace unidireccional, incluso después una conexión alcance a estado bidireccional. La intención del UDLD es detectar los problemas L2 que causan los bucles del STP, y esos problemas son generalmente unidireccionales porque los BPDU fluyen solamente en una dirección en el estado constante. Por lo tanto, el uso del UDLD normal conjuntamente con el autonegotiation y la protección de bucle (para las redes que confían en el STP) es casi siempre suficiente. Sin embargo, el modo agresivo del UDLD es beneficioso en las situaciones en las cuales la congestión se afecta igualmente en las ambas direcciones, que causa la pérdida de sondas del UDLD en las ambas direcciones. Por ejemplo, esta pérdida de sondas del UDLD puede ocurrir si la utilización de la CPU en cada final de la conexión se eleva. Otros ejemplos de la pérdida de conectividad bidireccional incluyen el incidente de uno de estos dispositivos:

  • Un transpondor de la multiplexión de división de longitud de onda denso (DWDM)

  • Un conversor de medios

  • Un cubo

  • Otro dispositivo L1

    Nota: El incidente no se puede detectar por el autonegotiation.

El error del UDLD agresivo invalida el puerto en estas situaciones de falla. Considerar las ramificaciones cuidadosamente cuando usted habilita a modo agresivo del UDLD en las conexiones que no son Point-to-Point. Las conexiones con los conversores de medios, los cubos, o los dispositivos similares no son Point-to-Point. Los dispositivos intermedios pueden prevenir la expedición de los paquetes UDLD y forzar una conexión ser apagado innecesariamente.

Después de que todos los vecinos de un puerto hayan envejecido hacia fuera, el modo agresivo del UDLD (si es habilitado) recomienza la secuencia de la conexión en un esfuerzo de resincronizar con potencialmente hacia fuera-de-sincroniza a vecinos. Este esfuerzo ocurre en el anuncio o la fase de la detección. Si después de que un tren rápido de los mensajes (ocho recomprobaciones falladas) la conexión todavía se juzgue “indeterminado”, el puerto entonces se pone en el estado de errDisable.

Nota: Algunos switches no son UDLD capaces agresivo. Actualmente, el Catalyst 2900XL and Catalyst 3500XL tiene intervalos entre mensajes hard-coded de 60 segundos. Este intervalo no se considera suficientemente rápido proteger contra los bucles potenciales del STP (con el uso de los parámetros del STP predeterminado).

UDLD en los enlaces enrutados

Con el fin de esta discusión, un enlace enrutado es uno de dos Tipos de conexión:

  • Point-to-Point entre dos nodos del router

    Esta conexión se configura con una máscara de subred de bits 30.

  • Un VLAN con los puertos múltiples pero ése soporta solamente las conexiones de ruteo

    Un ejemplo es una topología partida de la base L2.

Interior Gateway Routing Protocol (IGRP) tiene características únicas con respecto a cómo maneja las relaciones de vecino y la convergencia de rutas. Las características, que esta sección discute, son relevantes cuando usted pone en contraste dos de los protocolos de ruteo más frecuentes que se utilizan hoy, Open Shortest Path First (OSPF) el protocolo y el IGRP mejorado (EIGRP).

Primero, observar que un incidente L1 o L2 en cualquier red enrutada del Point-to-Point casi da lugar al desmembramiento inmediato de la conexión L3. Porque el único puerto del switch en ése los VLAN cambios a un estado no-conectado sobre el incidente L1/L2, la característica del estado Auto del MSFC sincroniza a estado de puerto L2 y L3 en aproximadamente dos segundos. Esta sincronización pone la interfaz VLAN L3 en un estado encendido/apagado (con el protocolo de línea abajo).

Asumir los valores de temporizador predeterminado. El OSPF envía los mensajes Hello Messages cada 10 segundos y tiene un Intervalo muerto de 40 segundos (4 * hola). Estos temporizadores son constantes para el Point-to-Point del OSPF y las redes de broadcast. Porque el OSPF requiere la comunicación bidireccional para formar una adyacencia, el tiempo a lo peor del failover es 40 segundos. Este failover es el caso aunque que el incidente L1/L2 no es puro en una conexión punto a punto, que sale de un escenario mitad-operacional de el cual el protocolo L3 deba ocuparse. Porque el tiempo de detección del UDLD es muy similar a la época de un temporizador de emergencia del OSPF que expire (cerca de 40 segundos), las ventajas de la configuración del modo del UDLD normal en un vinculo punto a punto del OSPF L3 son limitadas.

En muchos casos, el EIGRP converge más rápidamente que el OSPF. Sin embargo, usted debe observar que la comunicación bidireccional no es necesaria para que los vecinos intercambiar la información de ruteo. En los escenarios de falla mitad-operacionales muy específicos, el EIGRP es vulnerable a los envíos a agujeros negros del tráfico que dura hasta que un cierto otro acontecimiento hace rutea por ese “activo vecino”. El modo del UDLD normal puede aliviar las circunstancias las notas de esa esta sección. El modo del UDLD normal detecta a Error de enlace unidireccional y el error invalida el puerto.

Para las conexiones de L3-routed que utilizan cualquier protocolo de ruteo, el UDLD normal todavía proporciona a la protección contra las ediciones sobre la activación del enlace inicial. Tales ediciones incluyen el miscabling o el Hardware defectuoso. Además, el modo agresivo del UDLD proporciona a estas ventajas en las conexiones de L3-routed:

  • Previene los envíos a agujeros negros innecesarios del tráfico

    Nota: Los temporizadores mínimos se requieren en algunos casos.

  • Pone un enlace inestable en el estado de errDisable

  • Protege contra los bucles que resultan de las configuraciones de etherchannel L3

Comportamiento predeterminado del UDLD

El UDLD está globalmente desactivado y preparado para la habilitación en puertos de fibra de manera predeterminada. Porque el UDLD es un protocolo de infraestructura que es necesario entre los switches solamente, el UDLD es invalidado por el valor por defecto en los puertos de cobre. Los puertos de cobre tienden para ser utilizados para el acceso del host.

Nota: El UDLD se debe habilitar global y en el nivel de la interfaz antes de que los vecinos puedan alcanzar al estado bidireccional. En CatOS 5.4 (3) y posterior, el intervalo de mensajes predeterminado es 15 segundos y es configurable entre 7 y 90 segundos.

La recuperación errDisable global es invalidada por el valor por defecto. Después de que se habilite global, si un puerto entra el estado de errDisable, el puerto se vuelve a permitir automáticamente después de un intervalo de tiempo seleccionado. El tiempo predeterminado es 300 segundos, que es un temporizador global y mantenido para todos los puertos en un switch. Usted puede prevenir manualmente un re-enablement portuario si usted fija el tiempo de espera errdisable para que ese puerto invalide. Publicar el comando set port errdisable-timeout mod/port disable.

Nota: El uso de este comando depende de su Versión del software.

Considerar el uso de la característica del tiempo de espera errdisable cuando usted implementa a modo agresivo del UDLD sin las capacidades de administración de red out-of-band, determinado en la capa de acceso o en cualquier dispositivo que pueda aislarse de la red en caso de una situación de errdisable.

Referir a Ethernet de configuración, al Fast Ethernet, a los Ethernetes de Gigabites, y a la conmutación de Ethernet 10-Gigabit para más detalles en cómo configurar un período de agotamiento del tiempo de espera para los puertos que están en el estado de errDisable.

Recomendación

El modo normal UDLD es suficiente en el amplia mayoría de de los casos si usted lo utiliza correctamente y conjuntamente con las características y los protocolos apropiados. Estas características/protocolos incluyen:

  • FEFI

  • Autonegotiation

  • Protección de bucle

Cuando usted despliega el UDLD, considerar si una prueba en curso de la conectividad bidireccional (modo agresivo) es necesaria. Típicamente, si el autonegotiation es habilitado, el modo agresivo no es necesario porque el autonegotiation compensa la detección de falla en el L1.

Cisco recomienda el enablement del modo del UDLD normal en todas las conexiones del Point-to-Point FE/GE entre los switches Cisco en los cuales el intervalo de mensaje de UDLD se fija al segundo valor por defecto 15. Esta configuración asume los temporizadores del árbol de expansión del valor por defecto 802.1d. Además, uso UDLD conjuntamente con la protección de bucle en las redes que confían en el STP para la redundancia y la convergencia. Esta recomendación se aplica a las redes en las cuales hay uno o más puertos en el estado de bloqueo del STP en la topología.

Publicar estos comandos para habilitar el UDLD:

set udld enable

!--- After global enablement, all FE and GE fiber
!--- ports have UDLD enabled by default.


set udld enable port range


!--- This is for additional specific ports and copper media, if needed.

Usted debe habilitar manualmente los puertos que son error invalidado debido a los síntomas del enlace unidireccional. Publicar el comando set port enable.

Referir a entender y a configurar la característica del protocolo de detección de enlace unidireccional (UDLD) para más detalles.

Otras opciones

Para la protección máxima contra los síntomas que resultan de los enlaces unidireccionales, configurar el UDLD de modo agresivo:

set udld aggressive-mode enable port_range

Además, usted puede ajustar el valor del intervalo de mensaje de UDLD entre 7 y 90 segundos en cada extremo, donde soportado, para una convergencia más rápida:

set udld interval time

Considerar el uso de la característica del tiempo de espera errdisable en cualquier dispositivo que pueda aislarse de la red en caso de una situación de errdisable. Esta situación es típicamente verdad de la capa de acceso y cuando usted implementa a modo agresivo del UDLD sin las capacidades de administración de red out-of-band.

Si un puerto se coloca en el estado de errDisable, el puerto permanece abajo por el valor por defecto. Usted puede publicar este comando, que vuelve a permitir los puertos después de un intervalo de tiempo de espera:

Nota: El intervalo de tiempo de espera es 300 segundos por el valor por defecto.

>set errdisable-timeout enable ?
bpdu-guard

!--- This is BPDU port-guard.


channel-misconfig

!--- This is a channel misconfiguration.


duplex-mismatch
udld
other

!--- These are other reasons.


all

!--- Apply errdisable timeout to all reasons.

Si el dispositivo asociado no es UDLD capaz, por ejemplo un host extremo o el router, no ejecutar el protocolo. Ejecutar este comando:

set udld disable port_range

Prueba y monitor UDLD

No es fácil probar UDLD sin un componente genuinamente defectuoso/unidireccional en el laboratorio, como GBIC defectuoso. El protocolo fue diseñado para detectar los escenarios de falla menos-comunes que esos escenarios que se emplean generalmente en un laboratorio. Por ejemplo, si usted realiza una prueba simple y desenchufa un hilo de una fibra para ver al estado de errDisable deseado, usted necesita haber dado vuelta apagado al autonegotiation L1. Si no, el puerto físico va abajo, que reajusta la comunicación de mensaje UDLD. El extremo remoto se mueve al estado indeterminado en el UDLD normal. Si usted utiliza a modo agresivo del UDLD, el extremo remoto se mueve al estado de errDisable.

Hay un método adicional de la prueba para simular la pérdida de PDU vecino para el UDLD. Utilizar los filtros de la Capa MAC para bloquear UDLD/CDP a la dirección de hardware sino permitir que otros direccionamientos pasen.

Para monitorear el UDLD, publicar estos comandos:

>show udld

UDLD              : enabled
Message Interval  : 15 seconds


>show udld port 3/1

UDLD              : enabled
Message Interval  : 15 seconds
Port      Admin Status  Aggressive Mode  Link State
--------  ------------  ---------------  ----------------
	3/1      enabled       disabled         bidirectional

También del enable mode, usted puede publicar el comando show udld neighbor ocultado para controlar el contenido de la memoria inmediata del UDLD (de la manera que lo hace el CDP). Una comparación de la memoria inmediata del UDLD a la memoria caché CDP para verificar si hay una anomalía del protocol específico es a menudo útil. Siempre que el CDP también se afecte, todos los PDUs/BPDUs se afectan típicamente. Por lo tanto, controlar el STP también. Por ejemplo, controlar para saber si hay cambios recientes de la identidad de la raíz o la colocación de la raíz/del Designated Port cambia.

>show udld neighbor 3/1

Port  Device Name            Device ID    Port-ID OperState
----- ---------------------  ------------ ------- ----------
	3/1   TSC07117119M(Switch)   000c86a50433 3/1     bidirectional

Además, usted puede monitorear el estado UDLD y la coherencia de la configuración con el uso de las variables del SNMP MIB del Cisco UDLD.

Trama Jumbo

Los tamaños de trama predeterminados de la Unidad máxima de transmisión (MTU) (MTU) son 1518 bytes para todos los accesos de Ethernet, que incluye GE y 10 GE. La función de trama jumbo habilita las interfaces a los conmutares tramas que son más grandes que los tamaños de la trama Ethernet estándar. La característica es útil para optimizar el funcionamiento del servidor-a-servidor y a las aplicaciones de soporte tales como Conmutación de la etiqueta de protocolos múltiples (MPLS), tunneling 802.1Q, y protocolo de tunelización L2 versión 3 (L2TPv3), que aumentan los tamaños de los bastidores originales.

Información operativa general

La especificación estándar de IEEE 802.3 define los tamaños de trama Ethernet máximos de 1518 bytes para las tramas regulares y de 1522 bytes para las tramas encapsuladas 802.1Q. Las tramas encapsuladas 802.1Q se refieren a veces como “gigantes del bebé”. Los paquetes se clasifican generalmente como tramas gigantes cuando los paquetes exceden el Largo máximo especificado de Ethernet para una conexión de Ethernet específica. Los paquetes gigantes también se conocen como tramas Jumbo.

Hay varias razones por las que la talla del MTU de ciertos bastidores puede exceder 1518 bytes. Éstos son algunos de los ejemplos:

  • Las requisito-Aplicaciones Específicas del Vendedor y ciertos NIC pueden especificar una talla del MTU que sea fuera del estándar 1500 bytes. La tendencia a especificar tales tallas del MTU está debido a los estudios se han emprendido que, que prueban que un aumento en los tamaños de una trama Ethernet puede aumentar el desempeño de procesamiento medio.

  • Trunking-En la orden para llevar la información del VLAN ID entre los switches u otros dispositivos de red, el trunking se ha empleado para aumentar la trama Ethernet estándar. Hoy, dos la mayoría de las formas comunes de conexión troncales son la encapsulación ISL propietaria y IEEE 802.1Q de Cisco.

  • MPLS-Después del MPLS es habilitado en una interfaz, él tiene el potencial de aumentar los tamaños de trama de un paquete. Este aumento depende del número de las escrituras de la etiqueta en la pila de etiquetas para un paquete MPLS-marcado con etiqueta. Los tamaños totales de una escritura de la etiqueta son 4 bytes. Los tamaños totales de una pila de etiquetas son n x 4 bytes. Si se forma una pila de etiquetas, es posible que las tramas excedan la MTU.

  • los paquetes del tunneling de 802.1Q tunneling-802.1Q contienen dos etiquetas 802.1Q, de las cuales solamente una etiqueta al mismo tiempo es generalmente visible al hardware. Por lo tanto, la etiqueta interna agrega 4 bytes al valor del MTU (Tamaños de carga útiles).

  • El Universal Transport Interface (UTI) /L2TPv3-UTI/L2TPv3 encapsula los datos L2 que deben ser remitidos sobre la red del IP. La encapsulación puede aumentar los tamaños de trama originales en hasta 50 bytes. La nueva trama incluye un encabezado IP nuevo (20-byte), una cabecera del L2TPv3 (12-byte), y una cabecera nueva L2. El payload del L2TPv3 consiste en la trama completa L2, que incluye la cabecera L2.

La capacidad de los diversos switches de Catalyst de soportar los varios tamaños de trama depende de muchos factores, que incluyen el hardware y software. Los módulos determinados pueden soportar tamaños de trama más grandes que otros, incluso dentro de la misma plataforma.

  • Los switches del Catalyst 5500/5000 proporcionan al soporte para la trama Jumbo en la versión de CatOS 6.1. Cuando la característica de las tramas Jumbo es habilitada en un puerto, la talla del MTU aumenta a 9216 bytes. En el twisted pair sin blindaje 10/100-Mbps (UTP) - tarjetas de línea basadas, los tamaños máximos del marco se soportan que son solamente 8092 bytes. Esta limitación es una limitación ASIC. No hay generalmente restricciones en el enablement de la característica de los tamaños de trama Jumbo. Usted puede utilizar esta característica con el trunking/nontrunking y acanalar/nonchanneling.

  • El Catalyst 4000 switches (Supervisor Engine 1 [WS-X4012] y Supervisor Engine 2 [WS-X4013]) no soporta las tramas Jumbo debido a una limitación ASIC. Sin embargo, la anomalía es el trunking 802.1Q.

  • La Plataforma de la serie del Catalyst 6500 puede soportar los tamaños de trama Jumbo en la versión 6.1 (1) de CatOS y posterior. Sin embargo, este soporte es dependiente en el tipo de tarjetas de línea que usted utilice. No hay generalmente restricciones en el enablement de la característica de los tamaños de trama Jumbo. Usted puede utilizar esta característica con el trunking/nontrunking y acanalar/nonchanneling. Los tamaños de MTU predeterminados son 9216 bytes después de que el soporte de Trama Jumbo se haya habilitado en el puerto individual. El MTU predeterminado no es configurable con el uso de CatOS. Sin embargo, la Versión 12.1(13)E del software del IOS de Cisco introdujo el comando system jumbomtu para reemplazar el MTU predeterminado.

Referir al soporte de tramas enorme/gigante en el ejemplo de configuración de los switches de Catalyst para más información.

Este vector describe las tallas del MTU que son soportadas por diversas tarjetas de línea para el switch del Serie Catalyst 6500/6000:

Nota: La talla del MTU o los tamaños de paquetes se refiere solamente al payload de Ethernet.

Tarjeta de línea

Talla del MTU

Valor predeterminado

9216 bytes

WS-X6248-RJ-45, WS-X6248A-RJ-45 WS-X6248-TEL, WS-X6248A-TEL WS-X6348-RJ-45 (V), WS-X6348-RJ-21 (V)

8092 bytes (limitados por el chip del PHY)

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

9100 bytes (@ 100 Mbps)

9216 bytes (@ 10 Mbps)

WS-X6148A-RJ-45, WS-X6148A-45AF, WS-X6148-FE-SFP

9216 bytes

WS-X6324-100FX-MM, - S, WS-X6024-10FL-MT

9216 bytes

WS-X6548-RJ-45, WS-X6548-RJ-21, WS-X6524-100FX-MM WS-X6148X2-RJ-45, WS-X6148X2-45AF WS-X6196-RJ-21, WS-X6196-21AF WS-X6408-GBIC, WS-X6316-GE-TX, WS-X6416-GBIC WS-X6516-GBIC, uplinks WS-X6516A-GBIC, del WS-X6816-GBIC del Supervisor Engine 1, 2, 32 y 720

9216 bytes

WS-X6516-GE-TX

8092 bytes (@ 100 Mbps)

9216 bytes (@ Mbps 10 o 1000)

WS-X6148-GE-TX, WS-X6148V-GE-TX, WS-X6148-GE-45AF, WS-X6548-GE-TX, WS-X6548V-GE-TX, WS-X6548-GE-45AF

1500 bytes (trama Jumbo no soportada)

WS-X6148A-GE-TX, WS-X6148A-GE-45AF, WS-X6502-10GE, serie de WS-X67xx

9216 bytes

OS ATM (OC12c)

9180 bytes

OS CHOC3, CHOC12, CHOC48, CT3

9216 bytes (OCx y DS3)

7673 bytes (T1/E1)

Flexión WAN

7673 bytes (CT3 T1/DS0)

9216 bytes (OC3c POS)

7673 bytes (T1)

CS (WS-X6066-SLB-APC)

9216 bytes (en fecha CS 3.1 (5) y 3.2 (1))

OSM POS OC3c, OC12c, OC48c; OS DPT OC48c, OS GE WAN

9216 bytes

Soporte de Trama Jumbo de la capa 3

CatOS que se ejecute en el Supervisor Engine y el software del IOS de Cisco que se ejecuta en el MSFC, los switches del Catalyst 6500/6000 también proveen del soporte de Trama Jumbo L3 en la versión de software 12.1 (2) E del Cisco IOS® y posterior con el uso de PFC/MSFC2, el PFC2/MSFC2, o un hardware más último. Si el ingreso y la salida VLAN se configuran para las tramas Jumbo, todos los paquetes son hardware conmutado por el PFC en la velocidad de cable. Si el ingreso VLAN se configura para las tramas Jumbo y la salida VLAN no se configura, hay dos escenarios:

  • Se cae una trama Jumbo que se envía para el final ordenador principal con el conjunto de bits del don't fragment (DF) (para la detección de MTU de trayecto) - el paquete y un protocolo Protocolo de control de mensajes de Internet (ICMP) (ICMP) inalcanzable se envía al host extremo con el fragmento del código del mensaje necesitado y conjunto del DF.

  • Una trama Jumbo que se envía para el final ordenador principal con el dígito binario del DF no los fijar-Paquetes punted a MSFC2/MSFC3 para ser hecho fragmentos y para ser conmutado en el software.

Este vector resume el soporte de Jumbo L3 para las varias plataformas:

Switch L3 o módulo

Talla del MTU máxima L3

Catalyst serie 2948G-L3/4908G-L3

Las tramas Jumbo no se soportan.

Catalizador 5000 RSM1/RSFC2

Las tramas Jumbo no se soportan.

Catalyst 6500 MSFC1

Las tramas Jumbo no se soportan.

Catalyst 6500 MSFC2 y posterior

Versión 12.1(2)E del software del IOS de Cisco: 9216 bytes

1 RS = módulo del switch de ruta

2 RSFC = Route Switch Feature Card

Consideración del desempeño de la red

El funcionamiento de TCP WAN excesivos (el Internet) se ha estudiado extensivamente. Esta ecuación explica cómo el desempeño de procesamiento de TCP tiene un límite superior que se base encendido:

  • El Maximum Segment Size (MSS), que es la longitud del MTU menos la longitud de los encabezados TCP/IP

  • El Round Trip Time (RTT)

  • La pérdida del paquete

103d.gif

Según este fórmula, el desempeño de procesamiento de TCP máximo que es realizable es directamente proporcional al MSS. Con el RTT constante y la pérdida del paquete, usted puede doblar el desempeño de procesamiento de TCP si usted los tamaños de paquetes dobles. Semejantemente, cuando usted utiliza las tramas Jumbo en vez de 1518 marcos de xxx bytes, seis-plegable el aumento de tamaño puede rendir un potencial seis-plegable la mejora en el desempeño de procesamiento de TCP de una conexión de Ethernet.

En segundo lugar, las demandas cada vez mayores del funcionamiento de los bloques de servidores requieren los medios más eficientes de asegurar velocidades de datos más altas con los datagramas de UDP del Network File System (NFS). El NFS es el mecanismo lo más extensamente posible desplegado del almacenamiento de datos para transferir los ficheros entre los servidores UNIX-basados, y ofrece 8400 datagramas de bytes. Dado los 9 KB extendidos MTU de Ethernet, una sola trama Jumbo es bastante grande llevar un datagrama de aplicación de 8 KB (por ejemplo, NFS) más el incremento del encabezado de paquete. Esta capacidad incidentemente permite las transferencias más eficientes del Acceso directo a la memoria (DMA) en los ordenadores principal porque el software no necesita más para hacer fragmentos de los bloques del NFS en los datagramas de UDP separados.

Recomendación

Cuando usted desea el soporte de Trama Jumbo, obligar el uso de las tramas Jumbo a las áreas de la red donde todos los módulos del switch (L2) y las interfaces (L3) soportan las tramas Jumbo. Esta configuración previene la fragmentación dondequiera en el camino. La configuración de las tramas Jumbo que son más grandes que la longitud de trama soportada en el camino elimina cualquier aumento que sea alcanzado por el uso de la característica porque se requiere la fragmentación. Como los vectores en esta demostración de la sección de la trama Jumbo, las diversas plataformas y tarjetas de línea pueden variar con respecto a los tamaños máximos de paquete se soportan que.

Configurar los dispositivos hostes enmarcar-enterados del jumbo con una talla del MTU que sea el denominador común mínimo que es soportado por el hardware de red, para el L2 entero VLAN donde reside el dispositivo host. Para habilitar el soporte de Trama Jumbo para los módulos con el soporte de Trama Jumbo, publicar este comando:

set port jumbo mod/port enable

Además, si usted desea el soporte de Trama Jumbo a través de los límites L3, configurar el valor disponible más grande del MTU de 9216 bytes en todas las interfaces VLAN aplicables. Publicar el comando mtu bajo interfaces VLAN:

interface vlan vlan#
mtu 9216

Esta configuración se asegura de que L2 la trama Jumbo MTU que es soportada por los módulos sea siempre menos que, o igual a, el valor que se configura para las interfaces L3 que el tráfico atraviesa. Esto previene la fragmentación cuando el tráfico se rutea del VLAN a través de la interfaz L3.

Configuración de la administración

Las consideraciones a ayudar a controlar, la disposición, y a localizar averías una red Catalyst se discuten en esta sección.

Diagramas de la red

Los diagramas de redes limpios son fundamentales en el funcionamiento de las redes. Llegan a ser críticos durante la localización de averías y son el solo vehículo más importante para la comunicación de información cuando están extendidos a los vendedores y socios durante una interrupción. Su preparación, preparación, y accesibilidad no deben ser subestimadas.

Recomendación

Cisco recomienda que usted crea estos tres diagramas:

  • Cabalmente Diagrama-uniforme para las redes más grandes, un diagrama que muestre la comprobación end-to-end y la conectividad lógica es importante. Puede ser frecuente para las empresas que han implementado un diseño jerárquico para documentar cada capa por separado. Durante las hojas de operación (planning) y la resolución de problema, sin embargo, es a menudo un buen conocimiento de cómo los dominios conectan juntos que las materias.

  • La comprobación Diagrama-muestra todo el switch y hardware de router y cableado. Los enlaces troncales, las conexiones, las velocidades, los grupos de canal, los números del puerto, las ranuras, los tipos del chasis, el software, los dominios VTP, el bridge de la raíz, la prioridad de bridge raíz de respaldo, el MAC address, y los puertos bloqueados por el VLAN deben ser etiquetados. Está a menudo más claro representar los dispositivos internos, tales como el Catalyst 6500/6000 MSFC, como router en un palillo conectado por un troncal.

    103e.gif

  • Lógico Diagrama-muestra solamente las funciones L3 (routers como objetos, VLAN como segmentos Ethernet). Las direcciones IP, las subredes, el direccionamiento secundario, las capas activas y espera, del access-core-distribution del HSRP, y la información de ruteo deben ser etiquetados.

    103f.gif

Administración en banda

Dependiendo de la configuración, la interfaz de administración (interna) in-band del switch (conocida como sc0) podría tener que manejar estos datos:

  • El administrador de switches protocola por ejemplo el SNMP, el telnet, el protocolo secure shell (SSH), y el syslog

  • Datos del usuario tales como broadcastes y multicasts

  • Conmutar los protocolos de control tales como STP BPDU, VTP, DTP, CDP, etcétera

Es práctica común en diseño multicapa de Cisco configurar un VLAN de administración que atraviese un dominio conmutado y contenga todas las interfaces del sc0. Esto ayuda al tráfico de administración separado del tráfico de usuarios y aumenta la seguridad de las interfaces del administrador de switches. Esta sección describe la significación y los problemas potenciales de usar el VLAN predeterminado 1 y de ejecutar el tráfico de administración al switch en el mismo VLAN que el tráfico de usuarios.

Información operativa general

El problema principal sobre el uso del VLAN1 para los datos del usuario es que el Supervisor Engine NMP en general no necesita ser interrumpido por mucho del multicast y del tráfico de broadcast que es generado por las estaciones finales. Un hardware más viejo del Catalyst 5500/5000, el Supervisor Engine I y el Supervisor Engine II particularmente, tiene recursos limitados para ocuparse de este tráfico, aunque el principio se aplica a todos los motores del supervisor. Si la CPU del supervisor Engine, el buffer, o el canal dentro de la banda al backplane es completamente el escuchar ocupado el tráfico innecesario, es posible que las tramas de control pueden ser faltadas. En un escenario de caso peor, esto podía conducir a un bucle o a una falla de EtherChannel del árbol de expansión.

Si los comandos show interface y show ip stats se publican en el Catalyst, pueden dar una cierta indicación de la proporción del broadcast al tráfico de unidifusión y de la proporción de IP al tráfico no IP (visto no típicamente en los VLAN de administraciones).

Otra comprobación para de salud un hardware más viejo del Catalyst 5500/5000 es examinar la salida del show inband | biga (comando oculto) para los errores de recurso (RscrcErrors), similar a las caídas del búfer en un router. Si van estos errores de recurso para arriba continuamente, la memoria no está disponible para recibir los paquetes del sistema, quizás debido a una cantidad significativa de tráfico de broadcast en el VLAN de administración. Un solo error de recurso puede significar que el Supervisor Engine no puede procesar un paquete tal como BPDU, que podrían convertirse en rápidamente un problema porque los protocolos tales como árbol de expansión no vuelven a enviar los BPDU faltados.

Recomendación

Según lo resaltado en la sección de control del gato de este documento, el VLAN1 es un VLAN especial que marca y maneja la mayoría con etiqueta del tráfico del plano del control. El VLAN1 es habilitado en todos los troncales por el valor por defecto. Con redes de oficinas centrales más grandes, el cuidado necesita ser tomado sobre el diámetro del dominio STP VLAN1; la inestabilidad en una parte de la red podía afectar el VLAN1, de tal modo influenciando la estabilidad de plano de control y por lo tanto la estabilidad del STP para el resto de los VLAN. En CatOS 5.4 y posterior, ha sido posible limitar el VLAN1 de los datos del usuario que llevaban y el STP corriente con este comando:

clear trunk mod/port vlan 1

Esto no hace que se detengan los paquetes de control enviados de switch a switch en la VLAN 1, tal como se ve con un analizador de red. Sin embargo, no se remite ningunos datos, y el STP no debe ser ejecutado sobre esta conexión. Por lo tanto, esta técnica se puede utilizar para dividir la VLAN 1 en dominios de fallas más pequeños.

Nota:  No es actualmente posible borrar los troncales de VLAN 1 en 3500s y 2900XLs.

Aunque el cuidado se ha tomado con el diseño para oficinas centrales para obligar los VLAN de usuarios relativamente a los dominios del switch pequeño y correspondientemente los límites pequeños failure/L3, algunos clientes todavía se tientan para tratar el VLAN de administración diferentemente y para intentar cubrir la red completa con una sola subred de administración. No hay motivo técnico que una aplicación NMS central debe ser L2-adjacent a los dispositivos que maneja, ni está éste un argumento de seguridad calificado. El Cisco recomienda que usted limita el diámetro de los VLAN de administraciones a la misma estructura de dominio enrutada que los VLAN de usuarios y administración fuera de banda y/o de CatOS 6.x SSH soporte de la consideración como manera de aumentar la seguridad de la administración de la red.

Otras opciones

Sin embargo, hay aspectos del diseño para estas Recomendaciones de Cisco en algunas topologías. Por ejemplo, un deseable y un campo común diseño multicapa de Cisco es uno que evita el uso de un árbol de expansión activo. Esto requiere que usted obligue cada IP subnet/VLAN a un solo switch de capa de acceso, o cluster de los switches. En estos diseños, no podía haber trunking configurado abajo a la capa de acceso.

No hay respuesta fácil a la cuestión de si un VLAN de administración aparte esté creado y el trunking está habilitado para llevarla entre el accesso L2 y las capas de distribución L3. Éstas son dos opciones para la revisión del diseño con su ingeniero de Cisco:

  • Opción 1: VLAN únicos del troncal dos o tres de la capa de distribución abajo a cada switch de capa de acceso. Esto permite un VLAN de dato, una voz VLAN, y un VLAN de administración, por ejemplo, y todavía tiene la ventaja que el STP es inactivo. (Nota que si es el VLAN1 borró de los troncales, hay un paso de progresión de la configuración extra.) En esta solución, hay también puntas del diseño a considerar para evitar la confección de agujeros negros temporarios del tráfico enrutado durante la recuperación de errores: STP portfast para los truncales (CatOS 7.x y posterior) o sincronización Autostate del VLAN con el reenvío STP (más adelante que el [9] de CatOS 5.5).

  • Opción 2: un solo VLAN para los datos y la gerencia podía ser aceptable. Con un hardware más nuevo del switch, tal como CPU y limitación de la tarifa más de gran alcance de la controle de plano controla, más un diseño con los dominios de broadcast relativamente pequeños como abogado por el diseño multicapa, la realidad para muchos clientes es ésa que guarda la interfaz del sc0 a parte de los datos del usuario es menos de una edición que estaba una vez. Una decisión final es probablemente la mejor tomada con la examinación del perfil del tráfico emitido para ese VLAN y una discusión de las capacidades del hardware del switch con su ingeniero de Cisco. Si el VLAN de administración contiene de hecho a todos los usuarios en ese switch de capa de acceso, el uso de los filtros de entrada del IP se recomienda altamente para asegurar el switch de los usuarios, según lo discutido en la sección de la Configuración de seguridad de este documento.

Administración fuera de banda

Tomando los argumentos del paso más de la sección anterior, la administración de la red se puede hacer más altamente disponible con la construcción de una infraestructura de administración aparte alrededor de la red de producción de modo que los dispositivos sean siempre accesibles remotamente no importa qué ocurren los acontecimientos tráfico-conducido o de la controle de plano. Estos dos acercamientos son típicos:

  • Administración fuera de banda con un LAN exclusivo

  • Administración fuera de banda con los servidores terminales

Información operativa general

Los routers y switches de la red pueden incluir una interfaz de administración de Ethernet fuera de banda en una VLAN de administración. Un acceso de Ethernet en cada dispositivo se configura en el VLAN de administración y se cablegrafía fuera de la red de producción a una red de administración conmutada distinta a través de la interfaz del sc0. Observar que los switches del Catalyst 4500/4000 tienen una interfaz especial del me1 en el Supervisor Engine que deba ser utilizada para la administración fuera de banda solamente, no como puerto del switch.

Además, la conectividad del servidor terminal se puede alcanzar con la configuración un Cisco 2600 o 3600 con los cables de RJ-45-to-serial para acceder el puerto de la consola de cada router y switch en la disposición. Un servidor terminal también evita la necesidad de la configuración de los escenarios de respaldo, tales como módems en los puertos auxiliares para cada dispositivo. Un solo módem se puede configurar en el puerto auxiliar del servidor terminal para proporcionar al servicio de marcación manual a los otros dispositivos durante una falla de conectividad de red.

Recomendación

Con este arreglo, dos trayectos fuera de banda a cada switch y el router son posibles además de los trayectos dentro de la banda numerosos, así habilitando la administración de red de gran disponibilidad. Out-of-band es responsable de:

  • Out-of-band separa el tráfico de administración de los datos del usuario.

  • Out-of-band tiene dirección IP de administración en una subred distinta, un VLAN, y un switch para la mayor seguridad.

  • Out-of-band proporciona a la garantía más alta para la entrega de datos de administración durante los desperfectos de la red.

  • Out-of-band no tiene ningún árbol de expansión activo en el VLAN de administración. La redundancia no es crítica.

103g.gif

Pruebas del sistema

Diagnósticos de arranque

Durante un arranque inicial del sistema, un número de procesos se realizan para asegurarse de que un confiable y una plataforma en funcionamiento está disponibles de modo que el Hardware defectuoso no interrumpa la red. Los diagnósticos de arranque de Catalyst están partidos entre el Power-On Self Test (POSTE) y los diagnósticos en línea.

Información operativa general

Dependiendo de la plataforma y de la configuración del hardware, diverso diagnóstico se realiza en el arranque inicial y cuando una tarjeta es caliente intercambiada en el chasis. Un de alto nivel del resultado del diagnóstico en un número más amplio de los problemas detectados pero de un ciclo de inicio más largo. Estos tres niveles de diagnóstico del POSTE pueden ser seleccionados (todas las pruebas controlan el DRAM, LO PEGARON, y presencia de caché y los tamaños y los inicializan):

Información operativa general

Bridge

N/A

3

No disponible en 4500/4000 serie usando CatOS 5.5 o anterior.

Mínima

Pruebas de escritura de patrones en el first MB del DRAM solamente.

30

Valor por defecto en 5500/5000 y 6500/6000 serie; no disponible en 4500/4000 serie.

Complete

Pruebas de escritura de patrones para toda la memoria.

60

Valor por defecto en 4500/4000 serie.

Diagnóstico en línea

Estas pruebas verifican los trayectos de paquetes internamente en el switch. Es importante tener en cuenta que los diagnósticos en línea son, en consecuencia, pruebas de todo el sistema, no sólo de los puertos. En el Catalyst 5500/5000 y 6500/6000 de los switches, las pruebas se realizan primero del motor del Supervisor en espera, y otra vez del motor del supervisor principal. La longitud de los diagnósticos depende de la configuración del sistema (cantidad de ranuras, módulos y puertos). Hay tres categorías de prueba:

  • Los prueba-paquetes del loopback del Supervisor Engine NMP se envían a cada puerto, entonces vuelto al NMP y examinado para los errores.

  • Liándose los prueba-canales de hasta ocho puertos se crean y las pruebas de bucle de retorno se realizan al agport para verificar el hashing a las conexiones específicas (referir a la sección del EtherChannel de este documento para la Más información).

  • El Enhanced Address Recognition Logic (EARL) prueba-ambo el motor de la central supervisor y las reescrituras de motor en línea del módulo Ethernet L3 se prueba. Se crean las entradas y los puertos enrutados del hardware que reenvía antes de que los paquetes de la muestra se envíen (para cada tipo de la encapsulación de protocolo) del NMP a través del hardware de conmutación en cada módulo y de nuevo al NMP. Esto está para los módulos PFC del Catalyst 6500/6000 y más nuevo.

Los diagnósticos en línea completos pueden tomar aproximadamente dos minutos. Los diagnósticos mínimos no realizan el conjunto o la reescritura que prueba en los módulos otro entonces el Supervisor Engine, y pueden tomar aproximadamente 90 segundos.

Durante una Prueba de memoria, cuando una diferencia se encuentra en el modelo leído detrás comparado al modelo escrito, cambian al estado de puerto a defectuoso. Los resultados de estas pruebas se pueden considerar si se publica el comando show test, seguido por el número de módulo que se examinará:

>show test 9

Diagnostic mode: complete (mode at next reset: complete)

!--- Configuration setting.

Module 9 : 4-port Multilayer Switch
Line Card Status for Module 9 : PASS
Port Status :
  Ports 1  2  3  4
  -----------------
        .  .  .  .
Line Card Diag Status for Module 9 (. = Pass, F = Fail, N = N/A)
 Loopback Status [Reported by Module 1] :
  Ports 1  2  3  4
  -----------------
        .  . F  .

!--- Faulty.

 Channel Status :
  Ports 1  2  3  4
  -----------------
        .  .  .  .

Recomendación

El Cisco recomienda que todos los switches estén fijados para utilizar el diagnóstico completo para proporcionar a la máxima detección de desperfectos y para prevenir las interrupciones durante los funcionamientos normales.

Nota: Este cambio no toma el efecto hasta que la próxima vez que se anuda el dispositivo. Publicar este comando para fijar el diagnóstico completo:

set test diaglevel complete 

Otras opciones

En algunas situaciones, un tiempo rápido de reinicio puede ser excedente preferible que espera para ejecutar el diagnóstico completo. Hay otros factores y sincronizaciones implicados en traer encima de un sistema, pero el guardapolvo, el POSTE y los diagnósticos en línea agregan alrededor de un tercero otra vez a tiempo. En la prueba con un solo chasis completamente poblado del nueve slot del Supervisor Engine con un Catalyst 6509, el tiempo total de inicio era alrededor 380 segundos con el diagnóstico completo, alrededor 300 segundos con los diagnósticos mínimos, y solamente 250 segundos con el diagnóstico desviaron. Publicar este comando de configurar bridge:

set test diaglevel bypass

Nota: El Catalyst 4500/4000 valida el configuración para los diagnósticos mínimos, aunque éste todavía da lugar a una prueba completa que es emprendida. El modo mínimo podría ser soportado en el futuro en esta plataforma.

Diagnósticos en tiempo de ejecución

Una vez que el sistema sea operacional, el motor del supervisor del interruptor realiza vario monitorear de los otros módulos. Si un módulo no es accesible a través de los mensajes de administración ([SCP] del protocolo serial control que se ejecuta sobre el megabus de la administración fuera de banda), el Supervisor Engine procura recomenzar la tarjeta o tomar la otra acción como apropiada.

Información operativa general

El Supervisor Engine realiza vario monitorear automáticamente; esto no requiere ninguna configuración Para el Catalyst 5500/5000 y el 6500/6000, estos componentes del switch se monitorean:

  • NMP a través de un perro guardián

  • Errores realzados del chip del EARL

  • Canal dentro de la banda del Supervisor Engine al backplane

  • Módulos a través del canal fuera de banda excesivo del keepalives (Catalyst 6500/6000)

  • El motor del Supervisor activo es monitoreado por el motor para el estado del Supervisor en espera (el Catalyst 6500/6000)

Detección del sistema y del Error de hardware

Información operativa general

En CatOS 6.2 y posterior, otras funciones se han agregado para monitorear los componentes del sistema crítico y del nivel del hardware. Se soportan estos tres componentes de hardware:

  • Inband

  • Contador de puerto

  • Memoria

Cuando la característica es habilitada y se detecta una condición de error, el switch genera un mensaje de Syslog. El mensaje informa al administrador que existe un problema antes de que ocurra la notable degradación del desempeño. En las versiones CatOS 6.4 (16), 7.6 (12), 8.4 (2) y posterior, el modo predeterminado para los tres componentes cambiaron de lisiado a habilitado.

Inband

Si se detecta un error dentro de la banda, un mensaje de Syslog le informa que existe un problema antes de que ocurra la notable degradación del desempeño. Los errores apareces el tipo de ocurrencia de una falla dentro de la banda. Algunos ejemplos son:

  • Inband pegada

  • Errores de recurso

  • Fall Inband durante el bootup

En la detección de una falla de ping inband, la característica también señala un mensaje de Syslog adicional con una foto de la tarifa actual del Tx y del rx en conexión dentro de la banda, el CPU, y la carga del backplane del switch. Este mensaje le habilita para determinar correctamente si se pega (ningún Tx/Rx) o se sobrecarga el inband (Tx/Rx excesivo). Esta información adicional puede ayudarle a determinar la causa de las fallas de ping inband.

Contador de puerto

Cuando usted habilita esta característica, crea y comienza un proceso para hacer el debug de los contadores de puerto. Los monitores del contador de puerto seleccionan periódicamente los contadores de errores del puerto interno. La configuración de la tarjeta de línea, y más específicamente los ASIC en el módulo, determina que contradice las interrogaciones de la característica. El soporte técnico o la ingeniería de desarrollo de Cisco puede entonces utilizar esta información para localizar averías los problemas. Esta característica no vota los contadores de errores tales como FCS, el CRC, la alineación, y los runts que se asocian directamente a la conectividad del socio de enlace. Ver el EtherChannel/los errores de enlace que manejan la sección de este documento para incorporar esta capacidad.

La interrogación se ejecuta cada 30 minutos y se ejecuta en el fondo de los contadores de errores seleccionados. Si la cuenta va para arriba entre dos encuestas subsecuentes sobre el mismo puerto, los informes de un mensaje de Syslog el incidente y dan el /port del módulo y los detalles del contador de errores.

La opción del contador de puerto no se soporta en la plataforma del Catalyst 4500/4000.

Memoria

El Enablement de esta característica realiza monitorear del fondo y la detección de las condiciones de la corrupción del DRAM. Tales condiciones de la corrupción de la memoria incluyen:

  • Asignación

  • El liberar

  • Fuera del rango

  • Mala alineación

Recomendación

Habilitar todas las características de la detección de error, que incluye inband, los contadores de puerto, y la memoria, donde se soportan. El Enablement de estas características alcanza el sistema y el diagnóstico de advertencia de hardware proactive mejorados para la plataforma del switch Catalyst. Publicar estos comandos para habilitar las tres características de la detección de error:

set errordetection inband enable

!--- This is the default in CatOS 6.4(16), 7.6(12), 8.4(2), and later.


set errordetection portcounters enable

!--- This is the default in CatOS 6.4(16), 7.6(12), 8.4(2), and later.


set errordetection memory enable

!--- This is the default in CatOS 6.4(16), 7.6(12), 8.4(2), and later.

Publicar este comando para confirmar que la detección de error es habilitada:

>show errordetection

Inband error detection:                   enabled
Memory error detection:                   enabled
Packet buffer error detection:            errdisable
Port counter error detection:             enabled
Port link-errors detection:               disabled
Port link-errors action:                  port-failover
Port link-errors interval:                30 seconds

EtherChannel/dirección de los errores de enlace

Información operativa general

En CatOS 8.4 y posterior, una nueva función se ha introducido para proporcionar a una falla automática del tráfico a partir de un puerto en un EtherChannel a otro puerto en el mismo EtherChannel. El failover portuario ocurre cuando uno de los puertos en el canal excede un umbral de error configurable dentro del intervalo especificado. El failover portuario ocurre solamente si hay una izquierda portuaria operacional en el EtherChannel. Si el puerto fallado es el puerto más más reciente del EtherChannel, el puerto no ingresa el estado del puerto-failover. Este puerto continúa pasando el tráfico, sin importar el tipo de errores se reciban que. Los puertos solos, nonchanneling no entran el estado del puerto-failover. Estos puertos entran el estado de errDisable cuando el umbral de error se excede dentro del intervalo especificado.

Esta característica es solamente eficaz cuando usted habilita el set errordetection portcounters. Los errores de enlace que se monitorearán se basan en tres contadores:

  • InErrors

  • RxCRCs (CRCAlignErrors)

  • TxCRCs

Publicar el comando show counters en un switch para visualizar el número de los contadores de errores. Aquí tiene un ejemplo:

>show counters 4/48

.......

32 bit counters

0  rxCRCAlignErrors           =          0
.......

6  ifInErrors                 =          0
.......

12 txCRC                      =          0

Este vector es una lista de los parámetros de la configuración posible y de la configuración predeterminada respectiva:

Parámetros

Valor predeterminado

Global

desactivado

Monitor de puerto para RxCRC

desactivado

Monitor de puerto para InErrors

desactivado

Monitor de puerto para TxCRC

desactivado

Acción

Puerto-failover

Intervalo

30 segundos

Muestreo de la cuenta

3 consecutivos

Umbral bajo

1000

Umbral elevado

1001

Si la característica es habilitada y la cuenta de errores de los alcances de un puerto el valor alto del umbral configurable dentro del período especificado de la cuenta del muestreo, la acción configurable es cualquier error invalida o vira el failover hacia el lado de babor. El error invalida los lugares de la acción el puerto en el estado de errDisable. Si usted configura la acción portuaria del failover, se considera el estatus del canal de puerto. El puerto es error invalidado solamente si el puerto está en un canal pero ese puerto no es el puerto operacional más más reciente del canal. Además, si la acción configurada es failover portuario y el puerto es un solo puerto o nonchanneled, el puerto se coloca en el estado de errDisable cuando la cuenta del error de puerto alcanza el valor alto del umbral.

El intervalo es un temporizador constante para leer el port error counters. El valor predeterminado del intervalo de los errores de enlace es 30 segundos. El rango permitido es entre 30 y 1800 segundos.

Hay un riesgo de la inutilización de error accidental de un puerto debido a un acontecimiento de una sola vez inesperado. Para reducir al mínimo este riesgo, las acciones a un puerto se toman solamente cuando la condición persiste a través de esta cantidad de veces consecutiva del muestreo. El valor predeterminado del muestreo es 3 y el rango permitido es a partir la 1 a 255.

El umbral es un número absoluto que se controlará basó en el intervalo de los errores de enlace. El umbral bajo predeterminado del error de enlace es 1000 y el rango permitido es 1 a 65.535. El umbral elevado predeterminado del error de enlace es 1001. Cuando el número consecutivo de muestreo mide el tiempo de los alcances el umbral bajo, se envía un syslog. Si el muestreo consecutivo mide el tiempo de los alcances el umbral elevado, se envía un syslog y un error invalida o se acciona la acción del failover del puerto.

Nota: Utilizar la configuración de la detección de error del mismo puerto para todos los puertos en un canal. Referir a estas secciones de la guía de la configuración de la serie del software del Catalyst 6500 para más información:

Recomendaciones

Porque la característica utiliza los mensajes SCP para registrar y comparar los datos, los números altos de puertos activos pueden ser Uso intensivos de la CPU. Este escenario es aún más Uso intensivo de la CPU cuando el intervalo del umbral se fija a un valor muy pequeño. Habilitar esta característica con la discreción para los puertos que se señalan como conexiones críticas y llevar el tráfico para las aplicaciones sensibles. Publicar este comando para habilitar la detección del error de enlace global:

set errordetection link-errors enable

También, comienzo con el umbral, el intervalo, y los parámetros predeterminados del muestreo. Y utilizar la acción predeterminada, failover portuario.

Publicar estos comandos para aplicar los parámetros globales del error de enlace a los puertos individuales:

set port errordetection mod/port inerrors enable

set port errordetection mod/port rxcrc enable

set port errordetection mod/port txcrc enable

Usted puede publicar estos comandos para verificar la configuración de los errores de enlace:

show errordetection

show port errordetection {mod | mod/port}

Diagnósticos de memoria intermedia del paquete del Catalyst 6500/6000

En las versiones CatOS 6.4 (7), 7.6 (5), y 8.2 (1), los diagnósticos de memoria intermedia del paquete del Catalyst 6500/6000 fueron introducidos. Los diagnósticos de memoria intermedia del paquete, que son habilitados por el valor por defecto, detectaron los incidentes del almacén intermedio del paquete que son causados por los incidentes del transeúnte RAM estática (SRAM). La detección está en estos 48 módulos de la línea portuarios 10/100-Mbps:

  • WS-X6248-RJ45

  • WS-X6248-RJ21

  • WS-X6348-RJ45

  • WS-X6348-RJ21

  • WS-X6148-RJ45

  • WS-X6148-RJ21

Cuando ocurre la condición de error, 12 fuera de los 48 puertos 10/100-Mbps continúan permaneciendo conectados y pueden experimentar los problemas de conectividad al azar. La única manera de recuperarse de esta condición es accionar el ciclo el módulo de la línea.

Información operativa general

Los diagnósticos de memoria intermedia del paquete controlan los datos que se salvan en una sección específica del almacén intermedio del paquete para determinar si es corrompido por las Fallas SRAM transitorias. Si el proceso lee detrás algo diferente que qué escribió, entonces realiza dos opción de recuperación configurable posible:

  1. La acción predeterminada está al error invalida los puertos de la tarjeta de línea que son afectados por la falla del almacén intermedio.

  2. La segunda opción es accionar el ciclo la tarjeta de línea.

Se han agregado dos mensajes de Syslog. Los mensajes proporcionan a una alerta de la inutilización de error de los puertos o del ciclo de la potencia del módulo debido a los errores del almacén intermedio del paquete:

%SYS-3-PKTBUFFERFAIL_ERRDIS:Packet buffer failure detected. Err-disabling port 5/1.
%SYS-3-PKTBUFFERFAIL_PWRCYCLE: Packet buffer failure detected. Power cycling module 5.

En las versiones CatOS que son anteriores de 8.3 y 8.4, el tiempo del ciclo de la potencia de la tarjeta de línea es entre 30 y 40 segundos. Una característica rápida del cargador del programa inicial fue introducida en las versiones CatOS 8.3 y 8.4. La característica descarga automáticamente el firmware a las tarjetas de línea instaladas durante el proceso del primer reinicio para reducir al mínimo la hora de inicio. La característica rápida del cargador del programa inicial reduce el tiempo del ciclo de la potencia a aproximadamente 10 segundos.

Recomendación

Cisco recomienda la opción predeterminada del errdisable. Esta acción tiene el menos impacto en el servicio de red durante las horas de producción. Si es posible, mover la conexión que es afectada por los puertos desactivados debidos a error a otros puertos del switch disponibles para restablecer el servicio. Programar un ciclo manual de la potencia de la tarjeta de línea durante la ventana de mantenimiento. Publicar el comando reset module mod para recuperarse completamente de la condición del buffer del paquete corrupto. Publicar este comando para habilitar la opción errdisable:

set errordetection packet-buffer errdisable

!--- This is the default.

Otra opción

Porque un ciclo de la potencia de la tarjeta de línea es necesario para recuperar completamente todos los puertos que han encontrado a Falla SRAM, una acción de recuperación alternativa es configurar la opción del ciclo de la potencia. Esta opción es útil en las circunstancias en las cuales una interrupción en los servicios de red que pueden durar entre 30 y 40 segundos es aceptable. Esta longitud del tiempo es el tiempo que es necesario para que un módulo de la línea accione completamente el ciclo y se coloque nuevamente dentro del servicio sin la característica rápida del cargador del programa inicial. La característica rápida del cargador del programa inicial puede reducir la época de la interrupción en los servicios de red a 10 segundos con la opción del ciclo de la potencia. Publicar este comando para habilitar la opción del ciclo de la potencia:

set errordetection packet-buffer power-cycle

Diagnósticos de memoria intermedia del paquete

Esta prueba está para los switches del Catalyst 5500/5000 solamente. Esta prueba se diseña para encontrar el hardware defectuoso en los switches del Catalyst 5500/5000 que están utilizando los módulos Ethernet con el hardware específico que proporcionan a la conectividad 10/100-Mbps entre los puertos de usuario y el backplane del switch. Pues no pueden realizar la Verificación CRC para las tramas trunked, si una memoria intermedia de paquetes de puerto llega a ser defectuosa durante el tiempo de pasada, los paquetes podrían conseguir corrompidos y causar el CRC errors. Desafortunadamente, esto podría conducir a la propagación de los malos bastidores más lejos en la red ISL del Catalyst 5500/5000, que potencialmente causa a control la interrupción y las tormentas de broadcast planas en los escenarios de caso peores.

Módulos más nuevos del Catalyst 5500/5000 y otras plataformas han puesto al día controlar del Error de hardware construido adentro y no necesitan las pruebas de memoria intermedia del paquete, tan allí no son ninguna opción para configurarlo.

Los módulos de la línea que necesitan los diagnósticos de memoria intermedia del paquete son WS-X5010, WS-X5011, WS-X5013, WS-X5020, WS-X5111, WS-X5113, WS-X5114, WS-X5201, WS-X5203, WS-X5213/a, WS-X5223, WS-X5224, WS-X5506, WS-X5509, WS-U5531, WS-U5533, y WS-U5535.

Información operativa general

Este diagnóstico controla que los datos guardados en una sección específica de la memoria intermedia de paquete no se dañen accidentalmente debido al hardware defectuoso. Si el proceso lee detrás algo diferente que escribió, apaga el puerto en el modo fallado, desde entonces que el puerto podría corromper los datos. No se requiere umbral de errores. Los puertos fallados no pueden ser habilitados otra vez hasta que se ha reajustado el módulo (o substituido).

Hay dos modos para las pruebas de memoria intermedia del paquete: programar y a pedido. Cuando una prueba comienza, los mensajes de Syslog se generan para indicar la longitud prevista de la prueba (redondeada hasta el minuto más cercano) y del hecho que la prueba ha comenzado. La longitud exacta de la prueba varía por el tipo de puerto, los tamaños del buffer, y el tipo de prueba ejecutada.

Las pruebas a pedido son dinámicas a fin de completarse en pocos minutos. Puesto que estas pruebas interfieren activamente con la memoria del paquete, los puertos deben administrativo ser apagados antes de probar. Publicar este comando para apagar los puertos:

> (enable) test packetbuffer 4/1
Warning: only disabled ports may be tested on demand - 4/1 will be skipped.
> (enable) set port disable 4/1
> (enable) test packetbuffer 4/1
Packet buffer test started. Estimated test time: 1 minute.
%SYS-5-PKTTESTSTART:Packet buffer test started
%SYS-5-PKTTESTDONE:Packet buffer test done. Use 'show test' to see test results

Las pruebas programadas son mucho menos agresivas que las pruebas a pedido, y se ejecutan en el fondo. Las pruebas se realizan en paralelo cuando hay varios módulos pero de a un puerto por módulo a la vez. La prueba conserva, escribe y lee secciones pequeñas de la memoria intermedia de los paquetes antes de restaurar la información de memoria intermedia de los paquetes de usuario y, por lo tanto, no genera errores. Sin embargo, puesto que es la prueba escribe a la memoria intermedia, él bloquea los paquetes entrantes por algunos milisegundos y causa una cierta pérdida en las conexiones ocupadas. Por el valor por defecto hay una ocho-segunda pausa entre cada prueba de grabación en memoria intermedia para reducir al mínimo cualquier pérdida del paquete, pero éste significa que un sistema por completo de los módulos que la necesidad la prueba de memoria intermedia del paquete puede asumir el control 24 horas para que la prueba termine. Esta prueba programada es habilitada por el valor por defecto para ejecutarse semanalmente en el 03:30 el domingo de CatOS 5.4 o más adelante, y el estado de la prueba puede ser confirmado con este comando:

>show test packetbuffer status


!--- When test is running, the command returns
!--- this information:

Current packet buffer test details
Test Type           : scheduled
Test Started        : 03:30:08 Jul 20 2001
Test Status         : 26% of ports tested
Ports under test    : 10/5,11/2
Estimated time left : 11 minutes

!--- When test is not running,
!--- the command returns this information:

Last packet buffer test details
Test Type           : scheduled
Test Started        : 03:30:08 Jul 20 2001
Test Finished       : 06:48:57 Jul 21 2001

Recomendación

Cisco recomienda que usted utiliza la característica del prueba de memoria intermedia del paquete programada para los sistemas del Catalyst 5500/5000, pues la ventaja de descubrir los problemas en los módulos compensa el riesgo de la poca pérdida de paquetes.

Un rato semanal estandardizado se debe entonces programar a través de la red que permite a cliente a las conexiones de cambio de los puertos defectuosos o de los módulos RMA cuanto sea necesario. Mientras que esta prueba puede causar una cierta pérdida del paquete, dependiendo de la carga de la red, la debe programar por un tiempo de la red más reservado, tal como el valor por defecto del 3:30 en un domingo a la mañana. Publicar este comando para fijar el tiempo de prueba:

set test packetbuffer Sunday 3:30

!--- This is the default.

Una vez que esté habilitado (como cuando CatOS se actualiza a 5.4 y posterior por primera vez), hay una ocasión que una memoria oculta/problema de hardware está expuesta previamente, y un puerto se apaga automáticamente consecuentemente. Usted podría ver este mensaje:

%SYS-3-PKTBUFBAD:Port 1/1 failed packet buffer test

Otras opciones

Si no es aceptable arriesgar un nivel bajo de pérdida de paquetes por puerto semanalmente, se recomienda utilizar la función a pedido durante las interrupciones planificadas. Publicar este comando para comenzar esta característica manualmente en a por la base del rango (aunque el puerto se debe administrativo invalidar primero):

test packetbuffer port range

Registro del sistema

Los mensajes de syslog son específicos de Cisco y constituyen una parte clave de la administración proactiva de fallas. Una gama más amplia de las condiciones de la red y del protocolo está señalada usando el syslog que posible con el SNMP estandardizado. Las plataformas de administración, tales como fundamentos del Resource Manager de Cisco (RME) y las herramientas de análisis de red (NATkit) hacen el uso de gran alcance de la Información de syslog porque realizan estas tareas:

  • Actual análisis por la severidad, mensaje, dispositivo, y así sucesivamente

  • Habilitar la filtración de los mensajes que vienen adentro para el análisis

  • Accionar alertar, tal como paginadores, o a pedido recoger del inventario y de los cambios de configuración

Recomendación

Un punto importante del foco es cuál debe el nivel de información de ingreso al sistema ser generado localmente y ser sostenido en el buffer del switch en comparación con el que se envíe a un servidor de Syslog (que usa el comando set logging server severity value). Algunas organizaciones registran un nivel elevado de información centralmente, mientras que otras van al switch sí mismo a mirar los registros más detallados para un acontecimiento o a habilitar un de alto nivel de la captura del syslog solamente durante la localización de averías.

El debugging es diferente en las plataformas de CatOS que el software del IOS de Cisco, pero el Registro del sistema detallado puede ser habilitado sobre una base de la por session con el set logging session enable sin cambiar qué es registrada por el valor por defecto.

Cisco recomienda generalmente que usted trae al spantree y a recursos de syslog del sistema hasta el nivel 6, como éstos es características claves de estabilidad a seguir. Además, para los ambientes del multicast, traer el nivel de registro de las instalaciones mcastes hasta 4 se recomienda para producir los mensajes de Syslog si se borran los puertos de router. Desafortunadamente, antes de CatOS 5.5(5), esto podría hacer que se registren mensajes de syslog para incorporaciones y retiros de IGMP, lo cual es demasiado ruidoso para monitorear. Finalmente, si se utilizan las listas de entrada del IP, un nivel de registro mínimo de 4 se recomienda para capturar los intentos de inicio de sesión desautorizados. Publicar estos comandos para fijar estas opciones:

set logging buffer 500

!--- This is the default.

set logging server syslog server IP address
set logging server enable

!--- This is the default.

set logging timestamp enable
set logging level spantree 6 default

!--- Increase default STP syslog level.

set logging level sys 6 default

!--- Increase default system syslog level.

set logging server severity 4

!--- This is the default;
!--- it limits messages exported to syslog server.

set logging console disable

Dar vuelta apagado a los mensajes de la consola para proteger contra el riesgo del switch que cuelga como espera una respuesta de una terminal lenta o no existente cuando el volumen de mensajes es alto. El registro de la consola es un CatOS inferior prioritario y se utiliza principalmente capturar los últimos mensajes localmente al localizar averías o en un escenario de la caída del switch.

Este vector proporciona a los recursos de registro individual, a los niveles predeterminados, y a los cambios recomendados para el Catalyst 6500/6000. Cada plataforma tiene recursos levemente diversos, dependiendo de las características soportadas.

Instalación

Nivel predeterminado

Acción recomendada

acl

5

Dejar solo.

cdp

4

Dejar solo.

polis

3

Dejar solo.

dtp

8

Dejar solo.

earl

2

Dejar solo.

ethc1

5

Dejar solo.

filesys

2

Dejar solo.

gvrp

2

Dejar solo.

ip

2

Cambiar a 4 si las listas de entrada del IP utilizaron.

kernel

2

Dejar solo.

1d

3

Dejar solo.

mcast

2

Cambiar a 4 si el multicast utilizó (CatOS 5.5 [5] y posterior).

mgmt

5

Dejar solo.

mls

5

Dejar solo.

pagp

5

Dejar solo.

protfilt

2

Dejar solo.

poda

2

Dejar solo.

Privatevlan

3

Dejar solo.

qos

3

Dejar solo.

radius

2

Dejar solo.

rsvp

3

Dejar solo.

security

2

Dejar solo.

snmp

2

Dejar solo.

spantree

2

Cambiar a 6.

sys

5

Cambiar a 6.

tac

2

Dejar solo.

tcp

2

Dejar solo.

telnet

2

Dejar solo.

tftp

2

Dejar solo.

UDLD

4

Dejar solo.

vmps

2

Dejar solo.

VTP

2

Dejar solo.

1 en CatOS 7.x y posterior, el código de recurso del ethc substituye el código de recurso del pagp para reflejar el soporte del LACP.

Nota: Actualmente, los switches de Catalyst registran un mensaje del cambio de configuración syslog level-6 para cada comando set o clear ejecutado, desemejante del software del IOS de Cisco, que acciona el mensaje solamente después que usted da salida al modo de configuración. Si usted necesita los RME a las configuraciones de respaldo en el tiempo real sobre este disparador, entonces estos mensajes también necesitan ser enviados al servidor de Syslog de los RME. Para la mayoría de los clientes, las copias de respaldo periódicas de la configuración para los switches de Catalyst son bastantes, y no hay cambio de la severidad de registración del servidor predeterminado necesario.

Si usted ajusta sus alarmas del NMS, consultar la guía de mensajes del sistema.

Protocolo de administración de red simple

El protocolo SNMP se utiliza para recuperar estadísticas, contadores y tablas almacenados en bases de información para administración (MIB) de dispositivos de red. La información recopilada se puede utilizar por los NMS (tales como HP OpenView) para generar las alertas en tiempo real, medir la disponibilidad, y producir la información sobre planificación de capacidad, tan bien como ayudar a realizar la verificación de configuración y de resolución de problemas.

Información operativa general

Con algunos mecanismos de seguridad, una estación de administración de red puede extraer la información en los MIB con el protocolo SNMP consigue y consigue las peticiones siguientes, y cambiar los parámetros con el comando set. Además, un dispositivo de red se puede configurar para generar un mensaje trampa para el NMS para la alerta en tiempo real. El sondeo de SNMP utiliza el puerto 161 UDP IP y las trampas SNMP utilizan el puerto 162.

El Cisco soporta estas versiones del SNMP:

  • SNMPv1: Norma de Internet 1157 del RFC, usando la seguridad de la identificación de comunidad del texto claro. Un Access Control List y una contraseña de la dirección IP definen a comunidad de administradores capaz de acceder el MIB de agente.

  • SNMPv2C: una combinación de SNMPv2, una norma de Internet del bosquejo definida en RFC 1902 a 1907, y SNMPv2C, un marco administrativo basado en la comunidad para SNMPv2 que es un borrador experimental definió en RFC 1901. Las ventajas incluyen un mecanismo de recuperación global que soporte la extracción de los vectores y de las cantidades de información grandes, reduzca al mínimo el número de los viajes de ida y vuelta requeridos, y mejore el manejo de error.

  • SNMPv3: El borrador propuesto del RFC 2570 proporciona al acceso seguro a los dispositivos con la combinación de autenticación y el cifrado de paquetes sobre la red. Las funciones de seguridad proporcionaron en el SNMPv3 son:

    • Integridad del mensaje: se asegura de que un paquete no se haya tratado de forzar con in-transit

    • Autenticación: determina que el mensaje es de una fuente válida

    • Cifrado: revuelve el contenido de un paquete para evitar que sea visto fácilmente por una fuente no autorizada

Este vector identifica las combinaciones de los modelos de seguridad:

Nivel de modelo

Autenticación

Cifrado

‘Resultado’

v1

noAuthNoPriv, identificación de comunidad

No

Usa una correspondencia de identificaciones de comunidad para autenticación.

v2c

noAuthNoPriv, identificación de comunidad

No

Usa una correspondencia de identificaciones de comunidad para autenticación.

v3

noAuthNoPriv, Username

No

Utiliza las coincidencias de nombre de usuario para autenticar.

v3

authNoPriv, MD5 o SHA

Np

Proporciona autenticación sobre la base de algoritmos HMAC-MD5 o HMAC-SHA.

v3

authPriv, MD5 or SHA

DES

Proporciona autenticación sobre la base de algoritmos HMAC-MD5 o HMAC-SHA. Proporciona al cifrado de bits del DES 56 además de la autentificación basada en el estándar del CBC-DES (DES-56).

Nota: Tener esta información presente sobre los objetos del SNMPv3:

  • Cada usuario pertenece a un grupo.

  • Un grupo define la política de acceso para un conjunto de usuarios.

  • Una política de acceso define qué objetos del SNMP se pueden acceder para leer, para escribir, y para crear.

  • Un grupo determina la lista de las notificaciones que sus usuarios pueden recibir.

  • Un grupo también define el modelo de seguridad y el nivel de seguridad para sus usuarios.

Recomendación de notificaciones de trampa de SNMP

SNMP es la base de toda la administración de la red y se encuentra habilitado y en uso en todas las redes. El agente SNMP del switch se debe establecer de manera que utilice la versión de SNMP soportada por la estación de administración. Dado que un agente se puede comunicar con varios administradores, es posible configurar el software para soportar la comunicación con una estación de administración mediante el uso del protocolo SNMPv1 y con otra, por ejemplo, mediante el uso del protocolo SNMPv2.

La mayoría de las estaciones NMS utilizan el SNMPv2C hoy bajo esta configuración:

set snmp community read-only string


!--- Allow viewing of variables only.


set snmp community read-write string


!--- Allow setting of variables.


set snmp community read-write-all string<string>

!--- Include setting of SNMP strings. 

El Cisco recomienda que el SNMP traps sea habilitado para todas las características funcionando (las características no usadas pueden ser lisiadas si están deseadas). Un desvío es una vez habilitado, puede ser probado con el comando test snmp y apropiarse de dirigir la configuración en el NMS para el error (tal como una alerta de radiolocalizador o pop-up).

Todos los desvíos son invalidados por el valor por defecto y necesitan ser agregados a la configuración, individualmente o cerca con todo el parámetro, como se muestra:


set snmp trap enable all
set snmp trap server address read-only community string

Los desvíos disponibles en CatOS 5.5 incluyen:

Trampa

Descripción

autenticación

Autenticación

bridge

Bridge

chasis

Chasis

config

Configuración

entidad

entidad

ippermit

IP permit

módulo

Módulo

repetidor

repetidor

stpx

Extensión del árbol de expansión

syslog

Notificación de syslog

vmps

VLAN Membership Policy Server

vtp

Protocolo de troncal VLAN

Nota: La trampa de Syslog envía todo el syslog messaged generado por el switch a los NM como SNMP trap también. Si el alertar del syslog está siendo realizado ya por un analizador tal como Cisco Works 2000 RME, entonces no es necesariamente útil recibir esta información dos veces.

Desemejante del software del IOS de Cisco, el SNMP traps llano del puerto es invalidado por el valor por defecto porque los switches pueden tener centenares de las interfaces activas. Cisco recomienda que los puertos clave, como por ejemplo los enlaces de infraestructura hacia los routers, switches y servidores principales tengan habilitadas las trampas SNMP de nivel de puerto. Otros puertos, como los puertos host del usuario, no son necesarios, lo cuál ayuda a simplificar la administración de la red.

set port trap port range enable

!--- Enable on key ports only.

Recomendación de la Consulta SNMP

Una revisión de la administración de la red se recomienda para discutir las necesidades específicas detalladamente. Sin embargo, algunas filosofías básicas de Cisco para la gerencia de las Redes grandes se enumeran:

  • Haga algo simple, y hágalo correctamente.

  • Reduzca la sobrecarga del personal debido excesivos análisis manuales, herramientas, recopilación y datos de sondeo.

  • La administración de la red es posible con apenas algunas herramientas, tales como HP OpenView como los NM, Cisco RME como configuración, syslog, inventario, y administrador de software, Microsoft Excel como analizador de datos del NMS, y CGI como manera de publicar al Web.

  • Publicar los informes al Web permite que los usuarios, tales como gerencia general y analistas, se ayuden a la información sin cargar al personal de las operaciones con muchas peticiones especiales.

  • Descubrir qué está trabajando bien en la red y dejarlo solo. Concéntrese en lo que no está funcionando.

La primera fase de la implementación del NMS debe ser a la línea de fondo el hardware de red. Puede inferirse mucho acerca del estado de los dispositivos y protocolos a partir del mero uso de CPU, memoria y búfer en routers y del uso de NMP CPU, memoria y placa de interconexiones en switches. Solamente después que una línea de base del hardware hace la carga de tráfico L2 y L3, el pico, y las líneas de fondo medias llegan a ser completamente significativos. Las líneas de fondo se establecen generalmente sobre varios meses para conseguir la visibilidad de las tendencias diarias, semanales, y trimestrales - según el ciclo comercial de la compañía.

Muchas redes sufren el desempeño NMS y los problemas de capacidad causados por la sobre-interrogación. Por lo tanto se recomienda, una vez que se establezca la línea de fondo, para fijar los umbrales RMON en los dispositivos ellos mismos del alarmar y del acontecimiento para alertar el NMS en los cambios anormales, y quita así la interrogación. Habilita a la red para decirles a los operadores cuando algo no es normal, en lugar de sondear de manera continua para ver que todo esté normal. Los umbrales pueden establecerse en base a diversas reglas, como valor máximo más un porcentaje o desviación estándar a partir de una media, y están fuera del alcance de este documento.

La segunda fase de la implementación del NMS es votar las áreas determinadas de la red más detalladamente con el SNMP. Esto incluye las áreas de duda, áreas antes de un cambio, o las áreas que son se caractericen como trabajando bien. Utilizar los sistemas NMS como reflector para explorar la red detalladamente y para iluminar los puntos calientes (no procurar encender para arriba la red completa).

El grupo consultor de administración de red de Cisco sugiere éstos el incidente dominante MIB que se analizará o monitoreado en las redes de oficinas centrales. Referir a monitorear y a las guías de consulta de correlación de eventos de la red de Cisco para más información (en el funcionamiento MIB a votar, por ejemplo).

‘Nombre del objeto

Descripción del objeto

OID (ID del objeto)

Intervalo de consulta

Umbral

MIB-II

sysUpTime

tiempo de actividad del sistema en 1/100 centésimas de segundo

1.3.6.1 .2.1.1.3

5 min

< 30000

‘Nombre del objeto

Descripción del objeto

OID (ID del objeto)

Intervalo de consulta

Umbral

CISCO-PROCESS-MIB

cpmCPUTotal5min

El porcentaje de ocupación total de la CPU en el último período de 5 minutos

1.3.6.1 .4.1.9.9.109.1.1.1.1.5

10 minutos

Línea de base

‘Nombre del objeto

Descripción del objeto

OID (ID del objeto)

Intervalo de consulta

Umbral

CISCO-STACK-MIB

sysEnableChassisTraps

Indica si el chassisAlarmOn y los desvíos del chassisAlarmOff en este MIB deben ser generados.

1.3.6.1 .4.1.9.5.1.1.24

24 hs

1

sysEnableModuleTraps

Indica si el moduleUp y los desvíos del moduleDown en este MIB deben ser generados.

1.3.6.1 .4.1.9.5.1.1.25

24 hs

1

sysEnableBridgeTraps

Indica si el newRoot y los desvíos del topologyChange en el BRIDGE-MIB (RFC 1493) deben ser generados.

1.3.6.1 .4.1.9.5.1.1.26

24 hs

1

sysEnableRepeaterTraps

Indica si los desvíos en el REPEATER-MIB (RFC1516) deben ser generados.

1.3.6.1 .4.1.9.5.1.1.29

24 hs

1

sysEnableIpPermitTraps

Indica si los desvíos del permiso del IP en este MIB deben ser generados.

1.3.6.1 .4.1.9.5.1.1.31

24 hs

1

sysEnableVmpsTraps

Indica si el desvío del vmVmpsChange definido en el CISCO-VLAN-MEMBERSHIP-MIB debe ser generado.

1.3.6.1 .4.1.9.5.1.1.33

24 hs

1

sysEnableConfigTraps

Indica si el desvío del sysConfigChange en este MIB debe ser generado.

1.3.6.1 .4.1.9.5.1.1.35

24 hs

1

sysEnableStpxTrap

Indica si el desvío del stpxInconsistencyUpdate en el CISCO-STP-EXTENSIONS-MIB debe ser generado.

1.3.6.1 .4.1.9.5.1.1.40

24 hs

1

chassisPs1status

Estado del suministro de energía 1.

1.3.6.1 .4.1.9.5.1.2.4

10 minutos

2

chassisPs1TestResult

Información detallada en el estado del suministro de energía 1.

1.3.6.1 .4.1.9.5.1.2.5

Según lo necesitado.

 

chassisPs2Status

Estado del suministro de energía 2.

1.3.6.1 .4.1.9.5.1.2.7

10 minutos

2

chassisPs2TestResult

Información detallada en el estado del suministro de energía 2

1.3.6.1 .4.1.9.5.1.2.8

Según lo necesitado.

 

chassisFanStatus

Estado del ventilador del chasis.

1.3.6.1 .4.1.9.5.1.2.9

10 minutos

2

chassisFanTestResult

Información detallada en el estado del ventilador del chasis.

1.3.6.1 .4.1.9.5.1.2.10

Según lo necesitado.

 

chassisMinorAlarm

Estado de alarma leve del chasis.

1.3.6.1 .4.1.9.5.1.2.11

10 minutos

1

chassis MajorAlarm (alarma principal del chasis)

Estado de la alarma principal del chasis

1.3.6.1 .4.1.9.5.1.2.12

10 minutos

1

chassisTempAlarm

Estado de alarma de temperatura del chasis.

1.3.6.1 .4.1.9.5.1.2.13

10 minutos

1

moduleStatus

Estado operacional del módulo.

1.3.6.1 .4.1.9.5.1.3.1.1.10

30 minutos

2

moduleTestResult

Información detallada en la condición de los módulos.

1.3.6.1 .4.1.9.5.7.3.1.1.11

Según lo necesitado.

 

moduleStandbyStatus

Estatus de un módulo redundante.

1.3.6.1 .4.1.9.5.7.3.1.1.21

30 minutos

=1 ó =4

‘Nombre del objeto

Descripción del objeto

OID (ID del objeto)

Intervalo de consulta

Umbral

CISCO-MEMORY-POOL-MIB

dot1dStpTimeSinceTopologyChange

El tiempo (en 1/100 de los secs) desde la última vez un cambio de la topología fue detectado por la entidad.

1.3.6.1 .2.1.17.2.3

5 min

< 30000

dot1dStpTopChanges

El número total de cambios de la topología detectados por este bridge puesto que la entidad de administración era la restauración más más reciente o inicializados.

1.3.6.1 .2.1.17.2.4

Según lo necesitado.

 

dot1dStpPortState [1]

El estado actual del puerto según lo definido por la aplicación del protocolo del árbol de expansión. El valor de vuelta puede ser uno de éstos: lisiado (1), bloqueo (2), el escuchar (3), el aprender (4), expedición (5), o roto (6).

1.3.6.1 .2.1.17.2.15.1.3

Según lo necesitado.

 

‘Nombre del objeto

Descripción del objeto

OID (ID del objeto)

Intervalo de consulta

Umbral

CISCO-MEMORY-POOL-MIB

ciscoMemoryPoolUsed

Indica la cantidad de bytes del agrupamiento de memoria que es actualmente funcionando por las aplicaciones en el dispositivo administrado.

1.3.6.1 .4.1.9.9.48.1.1.1.5

30 minutos

Línea de base

ciscoMemoryPoolFree

Indica la cantidad de bytes del agrupamiento de memoria que es Currently Unused en el dispositivo administrado.

Nota: La suma de ciscoMemoryPoolUsed y de ciscoMemoryPoolFree es la cantidad total de memoria en el pool.

1.3.6.1 .4.1.9.9.48.1.1.1.6

30 minutos

Línea de base

ciscoMemoryPoolLargestFree

Indica el número más grande de los bytes contiguos del agrupamiento de memoria que son Currently Unused en el dispositivo administrado.

1.3.6.1 .4.1.9.9.48.1.1.1.7

30 minutos

Línea de base

Referir al conjunto de herramientas de administración de red de Cisco - MIB para más información sobre el soporte de Cisco MIB.

Nota: Algunos MIB estándars asumen que una entidad SNMP determinada contiene solamente un caso del MIB. Así, el MIB estándar no tiene ningún índice que permita que los usuarios accedan directamente un caso particular del MIB. En estos casos, la indexación de identificaciones de comunidad se proporciona para acceder cada caso del MIB estándar. La sintaxis es [identificación de comunidad]@[número ejemplo], donde el ejemplo es típicamente un número de VLAN.

Otras opciones

Los aspectos de seguridad del SNMPv3 significan que su uso espera de alcanzar SNMPv2 a tiempo. Cisco recomienda que los clientes se preparan para este nuevo protocolo como parte de su estrategia NMS. Los beneficios son que se pueden recolectar los datos de forma segura desde los dispositivos SNMP sin temor a que se corrompan o se alteren. La información confidencial, tal como paquetes del comando snmp set que cambien una configuración del switch, se puede cifrar para evitar que su contenido sea expuesto en la red. Además, diversos grupos de usuarios pueden tener diversos privilegios.

Nota: La configuración del SNMPv3 es perceptiblemente diferente que la línea del comando snmpv2, y mayor carga de la CPU en el Supervisor Engine está esperar.

Supervisión remota

El RMON permite que los datos MIB sean preprocesados por el dispositivo de red sí mismo, con objeto de las aplicaciones o de la aplicación comunes de esa información del administrador de la red, tal como ejecución de la determinación histórica de la línea de base y de la análisis del umbral.

Los resultados del procesamiento RMON están almacenados en MIB RMON para una posterior recopilación por parte de un NMS, como se define en RFC 1757.leavingcisco.com

Información operativa general

Mini RMON del soporte de los switches de Catalyst en hardware en cada puerto, que consiste en cuatro grupos básicos RMON-1: Estadísticas (grupo 1), Historial (grupo 2), Alarmas (grupo 3) y Eventos (grupo 9).

La parte más potente de RMON-1 es el mecanismo de umbral provisto por los grupos de eventos y la alarma. Según lo discutido, la configuración de los umbrales RMON permite que el switch envíe un SNMP trap cuando ocurre un estado anómalo. Una vez que se hayan identificado los puertos claves, el SNMP puede ser para contadores del sondeo o grupos usados del historial de RMON y crear la actividad del tráfico de las líneas de base por medio del registro una normal para esos puertos. Luego, pueden configurarse los umbrales RMON ascendentes y descendentes y las alarmas configuradas para cuando existe una variación definida desde la línea de base.

El La configuración de umbrales se realiza lo más mejor posible con un paquete de administración de RMON, puesto que la creación exitosa de las filas de los parámetros en el alarmar y las tablas de eventos es aburrida. El RMON comercial NMS empaqueta, por ejemplo el Cisco Traffic Director, Cisco Works 2000 de la parte de, incorpora los GUI que hacen la configuración de los umbrales RMON mucho más simple.

Para los propósitos de la línea de fondo, el grupo de los etherStats proporciona a un rango útil de las estadísticas de tráfico L2. Los objetos en este vector se pueden utilizar para conseguir la estadística sobre el unicast, el multicast, y el tráfico de broadcast así como una variedad de los errores L2. El agente RMON en el switch también puede configurarse para almacenar estos valores de ejemplo en el grupo de historial. Este mecanismo permite reducir la cantidad de consultas sin disminuir la velocidad de muestreo. Los historiales de RMON pueden dar las líneas de base precisas sin el incremento substancial de la interrogación. Sin embargo, más historias recogidas, más recursos del switch se utilizan.

Mientras que los switches proporcionan a solamente cuatro grupos básicos de RMON-1, es importante no olvidarse del resto de RMON-1 y de RMON-2. Definen a todos los grupos en RFC 2021, incluyendo UsrHistory (grupo 18) y ProbeConfig (grupo 19). El L3 y la información superior se pueden extraer de los switches con el puerto SPAN o el VLAN ACL vuelve a dirigir las características que le habilitan para copiar el tráfico a un SwitchProbe RMON externo o a un Módulo de análisis de red (NAM) interno.

Los NAM soportan a todos los grupos del RMON y pueden incluso examinar el application layer data, incluyendo los datos de NetFlow exportados de los Catalyst cuando el MLS es habilitado. El MLS que se ejecuta significa que el router no conmuta todos los paquetes en un flujo, tan solamente netflow dato-exporta y no los contadores de la interfaz dan la contabilidad de VLAN confiable.

Usted puede utilizar un puerto SPAN y un Switch Probe para capturar una secuencia de paquetes para un puerto determinado, un troncal, o un VLAN y para cargar los paquetes para decodificar con un paquete de administración de RMON. El puerto SPAN es SNMP-controlable a través del grupo del SPAN en el CISCO-STACK-MIB, así que este proceso es fácil de automatizar. El Traffic Director hace uso estas características con su característica del agente nómade.

Hay advertencias para expandir una VLAN entera. Aunque usted utiliza 1Gbps una sonda, la secuencia de paquetes entera a partir de un VLAN o aún un puerto dúplex completo 1Gbps puede exceder la anchura de banda del puerto SPAN. Si el puerto SPAN se está ejecutando continuamente en el ancho de banda completa, se están perdiendo las ocasiones son datos. Referir a configurar la Función Analizador de puerto conmutado (SPAN) Catalyst para más detalles.

Recomendación

Cisco recomienda que los umbrales RMON y el alertar estén desplegados para ayudar a la administración de la red en un más modo inteligente que la Consulta SNMP solamente. Esto reduce el incremento del tráfico de administración de red y permite que la red alerte inteligente cuando algo ha cambiado de la línea de fondo. El RMON necesita ser conducido por un agente externo tal como Traffic Director; no hay soporte del CLI. Publicar estos comandos para habilitar el RMON:

set snmp rmon enable
set snmp extendedrmon netflow enable mod


!--- For use with NAM module only.

Es importante recordar que la función principal de un switch es la de reenviar tramas, no desempeñarse como una gran sonda RMON de varios puertos. Por lo tanto, como usted configurar las historias y los umbrales en los puertos múltiples para las condiciones múltiples, tienen presente que se están consumiendo los recursos. Considere un módulo NAM si ampliará RMON. También recordar la regla del puerto crítico: votar y fijar solamente los umbrales en los puertos identificados como importantes en la etapa de planificación.

Requisitos de memoria

El uso de memoria de RMON es constante en todas las plataformas de switches en relación con estadísticas, historiales, alarmas y eventos. El RMON utiliza un compartimiento para salvar las historias y la estadística en el agente RMON (el switch, en este caso). Los tamaños del compartimiento se definen en la sonda del RMON (Switch Probe) o la aplicación RMON (Traffic Director), entonces enviada al switch para para ser fijado. Típicamente, las restricciones de memoria son solamente una consideración en un con menos de más viejo 32MB de los motores del supervisor del DRAM. Referir a estas guías de consulta:

  • 450K del espacio de códigos se agrega aproximadamente a la imagen NMP para soportar el mini RMON (que es cuatro grupos de RMON: estadística, historia, alarmar, y acontecimientos). El requisito de memoria dinámica para RMON varía dado que depende de la configuración del tiempo de ejecución. La información sobre el uso de la memoria RMON run-time para cada grupo del mini RMON se explica aquí:

    • La estadísticas Ethernet grupo-Toma 800 bytes para cada interfaz conmutada de Ethernet/FE.

    • La historia grupo-Para la interfaz de Ethernet, cada entrada de control de historial configurada con 50 compartimientos toma el espacio de memoria aproximadamente 3.6KB y 56 bytes para cada compartimiento adicional.

    • Los alarmar y los acontecimientos grupo-Toman 2.6KB para cada alarma configurada y sus entradas de evento correspondiente.

  • Para salvar las tomas aproximadamente 20K NVRAM del espacio si los tamaños de NVRAM totales del sistema son 256K o más y 10K NVRAM de la configuración relacionada a RMON del espacio si los tamaños de NVRAM totales son 128K.

Network Time Protocol (protocolo de hora de red)

El NTP, RFC 1305leavingcisco.com , sincroniza el timekeeping entre un conjunto de los servidores de tiempo y de los clientes distribuidos y permite que los acontecimientos sean correlacionados cuando se crean los registros del sistema u ocurren otros acontecimientos tiempo-específicos.

NTP le brinda precisiones en los tiempos de cliente, normalmente dentro de un milisegundos en redes LAN y hasta unas pocas decenas de milisegundos en redes WAN, en comparación con un servidor primario sincronizado con el Tiempo universal coordinado (UTC). Las configuraciones NTP típicas utilizan servidores redundantes múltiples y diversos trayectos de red para alcanzar una elevada precisión y confiabilidad. Algunas configuraciones incluyen la autenticación criptográfica para prevenir accidental o los ataques maliciosos al protocolo.

Información operativa general

El NTP primero fue documentado en RFC 958leavingcisco.com , pero se ha desarrollado con RFC 1119 (NTP versión 2) y ahora está en su tercera versión según lo definido en RFC 1305leavingcisco.com . Se ejecuta sobre el puerto 123 del UDP. Toda la comunicación NTP utiliza el UTC, que es el mismo tiempo que la hora media de Greenwich.

Acceso a servidores de tiempo público

La subred NTP actualmente incluye a más de 50 servidores públicos primarios sincronizados directamente con 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 sincronizan con los servidores primarios. Existen alrededor de 100 servidores secundarios públicos sincronizados al servidor principal, que brinda sincronización a más de 100.000 clientes y servidores en Internet. Las listas actuales se mantienen en la página de Lista de servidores NTP públicos, que se actualiza habitualmente. También existen numerosos servidores privados primarios y secundarios que por lo general no se encuentran disponibles al público. Para las listas del servidor público NTP y la información sobre cómo utilizarlos, consultan el Web site del servidor de la sincronización horarialeavingcisco.com de la Universidad de Delaware.

Puesto que no hay garantía que estos servidores NTP de Internet públicas estarán disponibles, o que producen la hora correcta, está aconsejado fuertemente que la otra opción esté considerada. Esto podría incluir el uso de los varios dispositivos independientes del Global Positioning Service (GPS) conectados directamente con un número de routers.

Otra solución posible es el uso de varios routers configurados como principales en el estrato 1, aunque no se recomienda.

Estrato

Cada servidor NTP adopta un estrato que indique cómo es lejano de una fuente externa de tiempo es el servidor. Los servidores Stratum 1 tienen acceso a algún tipo de fuente temporal externa, por ejemplo, un reloj de radio. Los servidores del nivel 2 obtienen detalles de tiempo de un conjunto designado de servidores del nivel 1, mientras que los servidores del nivel 3 obtienen detalles de tiempo de los servidores del nivel 2 y así sucesivamente.

Relación de entidad par servidora

  • Un servidor es uno que responde a las peticiones de cliente, pero no intenta incorporar ninguna información de la fecha de una fuente del tiempo de cliente.

  • Un par es uno que responde a las peticiones de cliente, pero intenta utilizar las peticiones de cliente como siendo un candidato potencial para una fuente horaria mejor y ayudarlas en la estabilización de su frecuencia del reloj.

  • Para ser una entidad par verdadera, los ambos lados de la conexión deben ingresar en una relación de pares más bien que tienen el un usuario un par y el otro usuario un servidor. También se recomienda que los pares intercambian los claves de modo que solamente los host confiables hablen el uno al otro como pares.

  • En una petición de cliente a un servidor, el servidor contesta al cliente y se olvida de que el cliente hizo siempre una pregunta; en una petición de cliente a un par, el servidor contesta al cliente y información del estado de los mantienes sobre el cliente para seguir como de bien está haciendo en el timekeeping y qué servidor Stratum está ejecutando.

    Nota: CatOS puede actuar solamente como cliente NTP.

Un servidor NTP no tiene problema en manejar muchos miles de clientes. Sin embargo, la manipulación de los centenares de los pares tiene un impacto en la memoria, y el mantenimiento del estado consume a más recursos de la CPU en el rectángulo así como la anchura de banda.

Consulta

El protocolo NTP permite a un cliente realizar una consulta a un servidor cuando lo desee. De hecho, cuando el NTP primero se configura en un dispositivo de Cisco, envió ocho interrogaciones en la sucesión rápida en NTP_MINPOLL (24 = 16 segundos) los intervalos. NTP_MAXPOLL son 214 segundos (que son 16.384 segundos o 4 horas, 33 minutos, 4 segundos), el tiempo máximo que toma antes de las encuestas del NTP otra vez para una respuesta. Actualmente, Cisco no tiene un método para forzar manualmente la época de la ENCUESTA de ser fijado por el usuario.

El contador de la interrogación del NTP empieza 26 (64) segundos y es incrementado por las potencias de dos (como los servidores sincronizan dos con uno a), a 210. Es decir, usted puede esperar que los mensajes síncronos sean enviados en un intervalo de los segundos de 64, del 128, del 256, 512, o 1024 por el servidor configurado o el par. El tiempo varía entre 64 segundos y 1024 segundos como una potencia de dos basada en el bucle con bloqueo de fase que envía y recibe paquetes. Si hay muchos de jitter en el tiempo, votan más a menudo. Si el reloj de referencia es exacto y la conectividad de red constante, usted ve los encuesta-tiempos converger en 1024 segundos entre cada encuesta.

En el mundo real, esto significa que el intervalo de consulta NTP cambia a medida que cambia la conexión entre el cliente y el servidor. Cuanto mejor es la conexión, cuanto más largo es el intervalo de la encuesta, significando que el cliente NTP ha recibido ocho respuestas para sus ocho peticiones más más recientes (el intervalo de la encuesta es entonces se doble). Una sola respuesta equivocada hace el intervalo de la encuesta ser partida en dos. El intervalo de la encuesta comienza hacia fuera en 64 segundos y va a un máximo de 1024 segundos. En las mejores circunstancias, toma un poco sobre dos horas para que el intervalo de la encuesta entre a partir 64 segundos a 1024 segundos.

‘Difusiones

Las difusiones NTP nunca se reenvían. El comando ntp broadcast hace el router originar los broadcastes del NTP en la interfaz en la cual se configura. El comando ntp broadcast client hace el router o el switch escuchar los broadcastes del NTP en la interfaz en la cual se configura.

Niveles de tráfico de NTP

El ancho de banda utilizado por NTP es mínimo, ya que el intervalo entre los mensajes de consulta intercambiados por los pares normalmente se remonta a no más de un mensaje cada 17 minutos (1024 segundos). Con una planificación apropiada, esto se puede mantener dentro de redes de router en los enlaces WAN. Los clientes NTP deben mirar con fijeza a los servidores NTP locales, no hasta el final a través del WAN a los routeres principales de sitio centrales que serán los servidores del estrato 2.

Un cliente de NTP en convergencia utiliza aproximadamente 0.6 dígitos por segundo por el servidor.

Recomendación

Muchos clientes tienen hoy NTP configurado en modo cliente en sus plataformas CatOS, sincronizadas a partir de varias entradas confiables de Internet o de un reloj de radio. Sin embargo, una alternativa más simple para el modo de servidor cuando opera una gran cantidad de switches es habilitar NTP en el modo de cliente de difusión en la VLAN de administración en un dominio conmutado. Este mecanismo permite que un dominio de Catalysts entero reciba un reloj de un mensaje del broadcast único. Sin embargo, la precisión en el mantenimiento de la hora marginal se reduce porque el flujo de información es unidireccional.

El uso de direcciones de bucle de retorno como fuente de actualizaciones también puede ayudar con la consistencia. Los problemas de seguridad se pueden tratar de estas dos maneras:

  • Actualizaciones del servidor de filtrado

  • Autenticación

La correlación de tiempo entre acontecimientos es extremadamente valioso en dos casos: resoluciones de problemas y auditoría de seguridad. El cuidado se debe tomar para proteger las fuentes horarias y los datos, y se recomienda el cifrado para no borrar los acontecimientos dominantes intencionalmente o inintencionalmente.

Cisco recomienda estas configuraciones:

Configuración de Catalyst

set ntp broadcastclient enable
set ntp authentication enable
set ntp key key    

!--- This is a Message Digest 5 (MD5) hash.

set ntp timezone <zone name>
set ntp summertime <date change details>

Configuración alternativa de Catalyst


!--- This more traditional configuration creates
!--- more configuration work and NTP peerings.

set ntp client enable
set ntp server IP address of time server
set timezone zone name
set summertime date change details

Configuración del router


!--- This is a sample router configuration to distribute
!--- NTP broadcast information to the Catalyst broadcast clients.

ntp source loopback0
ntp server IP address of time server
ntp update-calendar
clock timezone zone name
clock summer-time date change details ntp authentication key key
ntp access-group access-list


!--- To filter updates to allow only trusted sources of NTP information.

Interface to campus/management VLAN containing switch sc0
        ntp broadcast

Protocolo de detección de Cisco

CDP intercambia información entre los dispositivos adyacentes sobre la capa del enlace de datos y es extremadamente provechoso en la determinación de la topología de red y de la configuración física fuera del lógico o de la capa IP. Los dispositivos soportados son principalmente switches, routers y teléfonos IP. Esta sección destaca algunas de las mejoras de la versión 2 de CDP en comparación con la versión 1.

Información operativa general

El CDP utiliza el encapsulado SNAP con el código 2000 del tipo. En Ethernet, se utiliza el ATM, y el FDDI, la dirección de multidifusión de destino 01-00-0c-cc-cc-cc, el tipo 0x2000 del Protocolo HDLC. En Token Rings, se utiliza la dirección funcional c000.0800.0000. Las tramas CDP se envían periódicamente cada minuto de manera predeterminada.

Los mensajes CDP contienen unos o más secundario-mensajes que permitan que los dispositivos de destino recopilen y salven la información sobre cada dispositivo vecino.

La versión de CDP 1 soporta estos parámetros:

Parámetro

Tipo

Descripción

1

Id. del dispositivo

Hostname del dispositivo o del número de serie del hardware en el ASCII.

2

Dirección

El direccionamiento L3 de la interfaz que ha enviado la actualización.

3

ID del puerto

El puerto en el cual se ha enviado la actualización de CDP.

4

Capacidades

Describe las capacidades funcionales del dispositivo:

Router: Bridge de 0x01 TB: Bridge SR 0x02: switch 0x04: (proporciona al L2 y/o al L3 que conmutan) ordenador principal 0x08: Filtrado condicional 0x10 IGMP : 0x20 El bridge o switch no reenvía los paquetes de reporte IGMP en los puertos que no son de un router. Repetidor: 0x40

5

Versión

Una cadena de carácter que contiene la Versión del software (igual que en la versión de la demostración).

6

Plataforma

Plataforma de hardware, tal como WS-C5000, WS-C6009, o Cisco RSP.

En la versión de CDP 2, se han introducido los campos adicionales del protocolo. La versión de CDP 2 soporta cualquier campo, pero los que está enumerados pueden ser determinado útiles en los entornos conmutados y se utilizan en CatOS.

Nota:  Cuando un switch ejecuta el CDPv1, cae las tramas del v2. Cuando un CDPv2 corriente del switch recibe una trama del CDPv1 en una interfaz, comienza a enviar las tramas del CDPv1 fuera de esa interfaz además de las tramas del CDPv2.

Parámetro

Tipo

Descripción

9

Dominio de VTP

El dominio VTP, si está configurado en el dispositivo.

10

VLAN nativa

En el dot1q, éste es el VLAN sin etiqueta.

11

Dúplex medio/total

Este campo contiene la configuración dúplex del puerto de envío.

Recomendación

El CDP es habilitado por el valor por defecto y es esencial ganar la visibilidad de dispositivo adyacente y para localizar averías. También es utilizado por las aplicaciones de administración de red para construir las correlaciones de topología L2. Publicar estos comandos para configurar el CDP:

set cdp enable

!--- This is the default.

set cdp version v2

!--- This is the default.

En las partes de la red donde se requiere un alto nivel de seguridad (por ejemplo los Revestimientos del Internet DMZ), CDP se debe dar vuelta apagado como tal:

set cdp disable port range

El comando show cdp neighbors visualiza la tabla CDP local. Las entradas marcadas con una estrella (*) indican una discrepancia de VLAN; las entradas marcadas con un # indican una discordancia dúplex. Esto puede ser ayuda valiosa para localizar averías.

>show cdp neighbors

* - indicates vlan mismatch.
# - indicates duplex mismatch.
Port  Device-ID          Port-ID Platform
----- ------------------ ------- ------------
 3/1  TBA04060103(swi-2) 3/1     WS-C6506
 3/8  TBA03300081(swi-3) 1/1     WS-C6506
15/1  rtr-1-msfc         VLAN 1  cisco    Cat6k-MSFC
16/1  MSFC1b             Vlan2   cisco    Cat6k-MSFC

Otras opciones

Algunos switches, como el Catalyst 6500/6000, tienen la capacidad de proveer la potencia por los cables del UTP a los teléfonos del IP. La información recibida por el CDP asiste a la administración de la energía en el switch.

Mientras que los teléfonos del IP pueden tener un PC conectado con ellos, y ambos dispositivos conectan con el mismo puerto en el Catalyst, el switch tiene la capacidad de poner el teléfono VoIP en un VLAN distinto, el auxiliar. Esto permite que el switch aplique fácilmente una diversa Calidad de Servicio (QoS) para el tráfico de VoIP.

Además, si se modifica el VLAN auxiliar (por ejemplo, para forzar el teléfono para utilizar un VLAN específico o un método que marca con etiqueta específico), esta información se envía al teléfono por el CDP.

Parámetro

Tipo

Descripción

14

ID del aparato

Permite que el tráfico de VoIP sea distinguido del otro tráfico, como por la Identificación de VLAN separada (VLAN auxiliar).

16

Consumo de energía

La cantidad de energía que un teléfono VoIP consume, en los milivatios.

Nota: El Catalyst 2900 y los switches 3500XL no soportan actualmente el CDPv2.

Configuración de seguridad

Idealmente, el cliente ha establecido ya una política de seguridad para ayudar a definir qué herramientas y tecnologías de Cisco se califican.

Nota: La seguridad del software del IOS de Cisco, en comparación con CatOS, se ocupa en de muchos documentos, tales como esencial del ISP de Cisco.

Funciones de seguridad básicas

Contraseñas

Configurar una contraseña del nivel del usuario (login). Las contraseñas son caso sensible en CatOS 5.x y posterior, y pueden ser a partir 0 a 30 caracteres en la longitud, incluyendo los espacios. Fijar el enable password:


set password password
set enablepass password

Todas las contraseñas deben resolver los estándares de la longitud mínima (por ejemplo, seis caracteres como mínimo, una mezcla de las cartas y de las cartas de los números, superiores y minúsculas) para el login y los enables passwords cuando están utilizadas. Se cifran estas contraseñas usando el algoritmo de troceo MD5.

Para permitir más flexibilidad en la seguridad de la contraseña y el acceso del dispositivo de manejo, Cisco recomienda el uso de un servidor del TACACS+. Referir a la sección del TACACS+ de este documento para más información.

Secure Shell

Utilizar el cifrado SSH para proporcionar a la seguridad para las sesiones Telnet y otras conexiones remotas al switch. El cifrado SSH se soporta para los registros remotos al switch solamente. Usted no puede cifrar a las sesiones Telnet que se inician del switch. El SSH versión 1 se soporta en CatOS 6.1, y versión 2 el soporte fue agregado en CatOS 8.3. El SSH versión 1 soporta los métodos de cifrado de la Norma de cifrado de datos (DES) y del DES triple (3-DES), y el SSH versión 2 soporta el 3-DES y los métodos de cifrado del Advanced Encryption Standard (AES). Usted puede utilizar el cifrado SSH con el RADIO y autenticación de TACACS+. Esta característica se soporta con las imágenes del SSH (k9). Referirse a cómo configurar el SSH en los switches de Catalyst que ejecutan CatOS para los detalles.

set crypto key rsa 1024

Para invalidar el retraso de la versión 1 y validar versión 2 las conexiones, publicar este comando:

set ssh mode v2

Filtros de permiso de IP

Éstos son filtros para salvaguardar el accesso a la interfaz del sc0 de la gerencia con el telnet y otros protocolos. Este son especialmente importantes cuando la VLAN que se utilizó para la administración también contiene usuarios. Publicar estos comandos para habilitar la dirección IP y la filtración portuaria:


set ip permit enable
set ip permit IP address mask Telnet|ssh|snmp|all

Sin embargo, si el accesso del telnet se restringe con este comando, el accesso a los dispositivos CatOS se puede alcanzar solamente a través de algunas estaciones extremas confiables. Esta disposición puede ser un obstáculo en la localización de averías. Tener presente que es posible a las direcciones IP del spoof y al acceso filtrado del tonto, así que ésta es solamente la primera capa de protección.

Seguridad del puerto

Considerar el utilizar de la seguridad de puerto para permitir que solamente una o varias los direccionamientos sabidos del MAC pase los datos sobre un puerto determinado (para parar las estaciones terminales estáticas del intercambio por las nuevas estaciones sin el control de cambios, por ejemplo). Esto es posible cerca con las direcciones estáticas MAC.

set port security mod/port enable MAC address

Esto es también posible aprendiendo los direccionamientos restrictos del MAC dinámicamente.

set port security port range enable 

Estas opciones pueden ser configuradas:

  • set port security mod/port age time value - especifica la duración para la cual los direccionamientos en el puerto se aseguran antes de que un nuevo direccionamiento pueda ser aprendido. El tiempo válido en los minutos es 10 - 1440. El valor por defecto no es ningún envejecimiento.

  • set port securitymod/port maximum value - palabra clave que especifica el número máximo de direcciones MAC para asegurar en el puerto. Los valores válidos son 1 (predeterminado) - 1025.

  • la set port security mod/port violation apagar-cierra abajo del puerto (valor por defecto) si ocurre la violación tan bien como envía el mensaje de Syslog (valor por defecto) y los descartes el tráfico.

  • set port security mod/port shutdown time value - duración para la cual un puerto sigue siendo lisiado. Los valores válidos son 10 - 1440 minutos. El valor por defecto es apaga permanentemente

Con CatOS 6.x y posterior, el Cisco ha introducido la autentificación 802.1x que permite que los clientes authentiquen a un servidor central antes de que los puertos puedan ser habilitados para los datos. Esta característica está en las fases tempranas de soporte en las plataformas tales como Windows XP, pero se puede considerar una dirección estratégica por muchas empresas.

Mensajes de registro

Cree anuncios de dispositivos apropiados para indicar específicamente las acciones del acceso no autorizado. No anunciar el nombre del sitio o los datos de red que podrían proporcionar a la información a los usuarios no autorizados. Estas banderas proporcionan al recurso en caso de que se comprometa un dispositivo y se coge el autor:.

# set banner motd ^C
*** Unauthorized Access Prohibited ***
***  All transactions are logged   ***
------------- Notice Board -------------
----Contact Joe Cisco at 1 800 go cisco for access problems----
^C

Seguridad física

Los dispositivos no deben ser accesibles físicamente sin la autorización apropiada, así que el equipo debe estar en un espacio (bloqueado) controlado. para asegurarse de que las estancias de la red operacionales e inafectadas por la alteración malintencionada del factor ambiental, todo el equipo deban tener la UPS apropiada (con las fuentes redundantes en lo posible) y control de temperatura (aire acondicionado). Recordar, si el acceso físico es practicado una abertura por una persona con el intento malicioso, interrupción con la recuperación de contraseña u otros métodos es mucho más probable.

Terminal Access Controller Access Control System

Por el valor por defecto, sin privilegios y las contraseñas de modo de privilegio ser global y aplicarse a cada usuario que acceda el switch o el router, del puerto de la consola o a través de una sesión Telnet a través de la red. Su implementación en los dispositivos de red es desperdiciadora de tiempo y no-centralizada. También es difícil implementar restricciones sobre el acceso mediante listas de acceso que pueden ser propensas a errores de configuración.

Existen tres sistemas de seguridad disponibles para ayudar a controlar y a regular el acceso a los dispositivos de red. Éstos utilizan el cliente/las arquitecturas del servidor para poner toda la información sobre seguridad en las solas bases de datos centrales. Estos tres sistemas de seguridad son:

  • TACACS+

  • RADIUS

  • Kerberos

TACACS+ es una implementación común en las redes de Cisco y es el aspecto central de este capítulo. Proporciona a estas características:

  • Identificación y proceso de verificación de la Autentificación- para un usuario. Se pueden utilizar varios métodos para autenticar un usuario, pero el más habitual incluye una combinación de nombre de usuario y contraseña.

  • Autorización-de los varios comandos puede ser concedido una vez que authentiquen a un usuario.

  • Registración de las Estadísticas- un qué usuario está haciendo o ha hecho en el dispositivo.

Referir al TACACS+ de configuración, al RADIO, y al Kerberos en los switches del Catalyst de Cisco para más detalles.

Información operativa general

El protocolo TACACS+ reenvía nombres de usuario y contraseñas al servidor centralizado, cifrados en la red mediante el troceo unidireccional MD5 (RFC 1321).leavingcisco.com Utiliza el puerto TCP 49 como su protocolo de transporte; esto ofrece estas ventajas sobre el UDP (usado por RADIUS):

  • Transporte orientado conexión

  • Acuse de recepción separado que se ha recibido una petición (TCP ACK), sin importar cómo está cargado el mecanismo de autenticación de extremo posterior está actualmente

  • Indicación inmediata de una caída del servidor (paquetes RST)

Durante una sesión, si se necesita verificación adicional de la autorización, el switch verifica con TACACS+ para determinar si el usuario tiene permiso para usar un comando determinado. Esto brinda un mayor control sobre los comandos que pueden ejecutarse en el switch mientras se desconecta del mecanismo de autenticación. Usando las estadísticas del comando, es posible revisar los comandos que un usuario determinado ha publicado mientras que está asociado a un dispositivo de red determinado.

103h.gif

Cuando un usuario procura un acceso ASCII simple al sistema authenticando a un dispositivo de red con el TACACS+, este proceso ocurre típicamente:

  • Cuando se establece la conexión, el switch entra en contacto a demonio del TACACS+ para obtener un mensaje de solicitud de nombre de usuario, que entonces se visualiza al usuario. El usuario ingresa un nombre de usuario, y el switch entra en contacto a demonio del TACACS+ para obtener una solicitud de contraseña. El switch visualiza la solicitud de contraseña al usuario, que entonces ingresa una contraseña que también se envíe al demonio del TACACS+.

  • El dispositivo de red recibe eventual una de estas respuestas del demonio del TACACS+:

    • Validar- a usuario se authentica y el servicio puede comenzar. Si el dispositivo de red se configura para requerir la autorización, la autorización comienza ahora.

    • Rechazar- a usuario no ha podido authenticar. El usuario puede ser negado el accesso adicional o se incita para revisar la secuencia de inicio de sesión dependiendo del demonio del TACACS+.

    • El error del Error-uno ocurrió en algún momento durante la autentificación. Éste puede existir en el daemon o en la conexión de red entre el daemon y el switch. Si se recibe una respuesta de error, el dispositivo de red intenta típicamente utilizar un método alternativo para authenticar al usuario.

    • Continuar- a usuario se incita para la información de autenticación adicional.

  • Los usuarios deben primero terminar con éxito autenticación de TACACS+ antes de que procedan a autorización TACACS+.

  • Si se pide autenticación TACACS+, el daemon de TACACS+ se contacta nuevamente y devuelve una respuesta de autorización ACCEPT o REJECT. Si se vuelve una respuesta ACCEPT, la respuesta contiene los datos bajo la forma de atributos que se utilicen para dirigir al EXEC o a la sesión de red para ese usuario, y determina los comandos que el usuario puede acceder.

Recomendación

El Cisco recomienda el uso del TACACS+, pues puede ser implementado fácilmente usando el CiscoSecure ACS para el NT, el Unix, o el otro software de tercero. Las funciones TACACS+ incluyen una contabilidad detallada para proporcionar estadísticas sobre el uso de comandos y el uso de sistemas, el algoritmo de cifrado MD5, y el control administrativo de los procesos de autenticación y autorización.

En este ejemplo, los modos login y enable (inicio de sesión y activación) utilizan el servidor TACACS+ para autenticación y pueden replegarse para autenticación local si el servidor no está disponible. Esto es una entrada posterior importante a irse en la mayoría de las redes. Publicar estos comandos para configurar el TACACS+:

set tacacs server server IP primary
set tacacs server server IP


!--- Redundant servers are possible.

set tacacs attempts 3

!--- This is the default.

set tacacs key key


!--- MD5 encryption key.

set tacacs timeout 15

!--- Longer server timeout (5 is default).

set authentication login tacacs enable
set authentication enable tacacs enable
set authentication login local enable
set authentication enable local enable

!--- The last two commands are the default; they allow fallback
!--- to local if no TACACS+ server available.

Otras opciones

Es posible utilizar autorización TACACS+ controlar los comandos cada usuario o el grupo de usuarios puede ejecutarse en el switch, pero es difícil hacer una recomendación porque todos los clientes tienen requisitos individuales en esta área. Referir al accesso que controla al switch usando la autentificación, la autorización, y explicar más información.

Por último, los comandos de contabilidad proporcionan una pista de auditoría de lo que cada usuario ha escrito y configurado. Esto es un ejemplo usando la práctica común de recibir la información de auditoría en el final del comando:

set accounting connect enable start-stop tacacs+
set accounting exec enable start-stop tacacs+
set accounting system enable start-stop tacacs+
set accounting commands enable all start-stop tacacs+
set accounting update periodic 1

Esta configuración tiene estas características:

  • El comando conectado permite la contabilización de los eventos de conexión de salida en el switch, como Telnet.

  • El comando exec habilita la contabilidad de las sesiones de inicio en el switch como, por ejemplo, el personal de operaciones.

  • El comando system habilita la contabilidad de eventos del sistema en el switch tal como recarga o restauración.

  • El comando commands permite contabilizar lo que se ingresó en el switch, tanto para los comandos show como los comandos de configuración.

  • Las actualizaciones periódicas cada minuto al servidor son provechosas para registrar si todavía acceden a los usuarios.

Configuración de lista de control

Esta sección proporciona a un resumen de las configuraciones recomendadas, excepto los detalles de seguridad.

Es extremadamente provechoso etiquetar todos los puertos. Publicar este comando para etiquetar los puertos:

set port description descriptive name

Utilizar este clave conjuntamente con los vectores del comando enumerados:

Clave:

Texto en negrita - cambio recomendado

Texto normal - valor por defecto, configuración recomendada

Comandos global configuration

Comando

Comentario

set vtp domain name passwordx

Proteger contra las actualizaciones desautorizadas del VTP contra los nuevos switches.

set vtp mode transparent

Seleccionar a modo VTP promovido en este documento. Referir a la sección del protocolo VLAN trunking de este documento para más detalles.

set spantree enable all

Asegurarse de que el STP sea habilitado en todos los VLAN.

set spantree root vlan

Recomendó colocar los bridges de la raíz (y raíz secundaria) por el VLAN.

set spantree backbonefast enable

Habilitar la convergencia de STP rápida de las Fallas indirectas (solamente si todos los switches en el dominio soportan la característica).

set spantree uplinkfast enable

Habilitar la convergencia de STP rápida de los incidentes directos (para los switches de capa de acceso solamente).

set spantree portfast bpdu-guard enable

Habilitar el puerto que se apagará automáticamente si hay una extensión desautorizada del árbol de expansión.

set udld enable

Habilitar la detección de enlace unidireccional (configuración del nivel del puerto de la necesidad también).

set test diaglevel complete

Habilitar el diagnóstico completo en el cargador del programa inicial para arriba (valor por defecto en el Catalyst 4500/4000).

fijar el 3:30 del sol del packetbuffer de la prueba

Habilitar la verificación de errores de la memoria intermedia de puerto (se aplica al Catalyst 5500/5000 solamente).

set logging buffer 500

Mantener el buffer interno máximo del syslog.

set logging server IP address

Configurar la blanco syslog separan para el registro de mensaje del sistema externo.

set logging server enable

Permitir el servidor de registro externo.

set logging timestamp enable

Habilitar las horas de los mensajes en el registro.

set logging level spantree 6 default

Incremente el nivel predeterminado de syslog STP.

set logging level sys 6 default

Incremente el nivel predeterminado de registro de sistema.

set logging server severity 4

Permitir la exportación del syslog de mayor nivel de gravedad solamente.

set logging console disable

Invalidar la consola a menos que localice averías.

set snmp community read-only string

Configurar la contraseña para permitir la colección de los datos remotos.

set snmp community read-write string

Configurar la contraseña para permitir la configuración remota.

set snmp community read-write-all string

Configurar la contraseña para permitir la configuración remota incluyendo las contraseñas.

set snmp trap enable all

Habilitar el SNMP traps al servidor NMS para las alarmas del incidente y del acontecimiento.

set snmp trap server address string

Configurar el direccionamiento del receptor de trampa del NMS.

set snmp rmon enable

Habilitar el RMON para la recolección de estadística local. Referir a la sección de la supervisión remota de este documento para más detalles.

set ntp broadcastclient enable

Habilitar la recepción exacta del reloj del sistema de un router ascendente.

set ntp timezone zone name

Fijar las Zonas horarias locales para el dispositivo.

set ntp summertime date change details

Configurar el verano si fuera aplicable para el timezone.

set ntp authentication enable

Configurar la información de tiempo cifrada para los propósitos de la seguridad.

set ntp key key

Configurar la clave cifrada.

set cdp enable

Asegurar la detección de vecino es habilitado (habilitado en los puertos por el valor por defecto también).

set tacacs server IP address primary

Configurar el direccionamiento del servidor de AAA.

set tacacs server IP address

Servidores de AAA redundantes si es posible.

set tacacs attempts 3

Permitir 3 tentativas de la contraseña para la cuenta de usuario del AAA.

set tacacs key key

Fijar el clave del AAA Cifrado de MD5.

set tacacs timeout 15

Permitir un tiempo de espera del servidor más largo (cinco segundos son predeterminados).

set authentication login tacacs enable

Utilizar el AAA para la autentificación para el login.

set authentication enable tacacs enable

Utilizar el AAA para la autentificación para el enable mode.

set authentication login local enable

Valor por defecto; permite el retraso al local si ningún servidor de AAA disponible.

set authentication enable local enable

Valor por defecto; permite el retraso al local si ningún servidor de AAA disponible.

Comandos Configuration de los puertos de host

Comando

Comentario

set port host port range

Quitar el proceso portuario innecesario. Esta macro fija el spantree PortFast habilita, canal apagado, troncal apagado.

set udld disable port range

Quitar el proceso innecesario del puerto (invalidado en el puerto de cobre por el valor por defecto).

set port speed port range auto

Utilizar la negociación automática con los controladores NIC actualizados del ordenador principal.

set port trap port range disable

Ninguna necesidad del SNMP traps para los usuarios generales; puertos claves de la pista solamente.

Comandos de la Configuración del servidor

Comando

Comentario

set port host port range

Quitar el proceso portuario innecesario. Esta macro fija el spantree PortFast habilita, canal apagado, troncal apagado.

set udld disable port range

Quitar el proceso innecesario del puerto (invalidado en el puerto de cobre por el valor por defecto).

fijar el rango de puertos portuario 10 de la velocidad | 100

Configurar generalmente los parásitos atmosféricos/los puertos de servidor; si no, utilizar el autonegotiation.

fijar el rango de puertos a dos caras portuario lleno | semi

Generalmente parásitos atmosféricos/puertos de servidor; si no, utilizar el autonegotiation.

set port trap port range enable

Los puertos del servicio fundamental deben enviar el desvío al NMS.

Comandos Configuration de los puertos sin utilizar

Comando

Comentario

set spantree portfast port range disable

Habilitar el proceso y la protección del puerto necesario para el STP.

set port disable port range

Invalidar los puertos sin utilizar.

set vlan unused dummy vlan port range

Tráfico directo no autorizado al VLAN inusitado si el puerto es habilitado.

set trunk port range off

Invalidar el puerto del trunking hasta administrado.

desactive el modo intervalo de puerto del canal de puerto

Invalidar el puerto de acanalar hasta administrado.

Puertos de infraestructura (switch switch, switch router)

Comando

Comentario

set udld enable port range

Habilitar la detección de enlace unidireccional (no valor por defecto en los puertos de cobre).

set udld aggressive-mode enable port range

Habilitar a modo agresivo (para los dispositivos que lo soportan).

rangeenable portuario del set port negotiation

Permitir el autonegotiation predeterminado del GE de los parámetros de la conexión.

set port trap port range enable

Permitir el SNMP traps para estos puertos claves.

set trunk port range off

Invalidar la característica si no que usa los troncales.

set trunk mod/port desirable ISL | dot1q | negociar

Si usa los troncales, se prefiere el dot1q.

clear trunk mod/port vlan range

Limitar a diámetro STP por los VLAN de poda de los troncales donde no están necesarios.

desactive el modo intervalo de puerto del canal de puerto

Invalidar la característica si no que usa los canales.

set port channel port range mode desirable

Si usa los canales, esto habilita el PAgP.

set port channel all distribution ip both

Permitir la fuente L3/la carga de destino que balancean si usa los canales (valor por defecto en el Catalyst 6500/6000).

fijar la Mod del tronco/el acceso nonegocian el ISL | dot1q

Invalidar el DTP si trunking al router, al Catalyst 2900XL, a 3500, o al otro vendedor.

set port negotiation mod/port disable

La negociación puede ser incompatible para algunos viejos dispositivos del GE.


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: 13414