Switches : Switches Cisco Catalyst 6500 Series

Melhores Práticas para Catalyst 6500/6000 Series e Catalyst 4500/4000 Series Switches que Executem o Cisco IOS Software

22 Janeiro 2009 - Tradução Manual
Outras Versões: Versão em PDFpdf | Tradução por Computador (29 Julho 2013) | Inglês (3 Setembro 2006) | Feedback

Índice

Introdução
Antes de Iniciar
     Informações Complementares
     Referências
     Configuração Básica
     Protocolos de Plano de Controle do Catalyst
     VLAN 1
Recursos Padrão
     VLAN Trunk Protocol
     Negociação Automática de Ethernet Rápida
     Negociação Automática de Ethernet Gigabit
     Dynamic Trunking Protocol
     Spanning Tree Protocol
     UniDirectional Link Detection
     Comutação multicamadas
     Frames Jumbo
Recursos de Segurança do Cisco IOS Software
     Recursos Básicos de Segurança
     Serviços de Segurança AAA
     TACACS+
Configuração de Gerenciamento
     Diagramas de Rede
     Interface de Gerenciamento de Switch e VLAN Nativa
     Gerenciamento fora de banda
     Registro de sistema
     SNMP
     Protocolo de Tempo de Rede
     Cisco Discovery Protocol
Lista de Verificação de Configuração
     Comandos Globais
     Comandos da Interface
Discussões relacionadas da comunidade de suporte da Cisco
Informações Relacionadas

Introdução

Este documento fornece as melhores práticas para Catalyst 6500/6000 e 4500/4000 Series Switches que executem o Cisco IOS® Software no Supervisor Engine.

Os Catalyst 6500/6000 e 4500/4000 Series Switches suportam um desses dois sistemas operacionais que são executados no Supervisor Engine:

  • Catalyst OS (CatOS)

  • Cisco IOS Software

Com o CatOS, existe a opção de executar o Cisco IOS Software em placas filhas de router ou módulos tais como:

  • A Multilayer Switch Feature Card (MSFC) no Catalyst 6500/6000

  • O módulo 4232 Layer 3 (L3) no Catalyst 4500/4000

Neste modo, existem duas linhas de comando para configuração:

  • A linha de comando CatOS para roteamento

  • A linha de comando do Cisco IOS Software para roteamento

CatOS é o software do sistema, que é executado no Supervisor Engine. O Cisco IOS Software que é executado no módulo de roteamento é uma opção que requer o software de sistema CatOS.

Para o Cisco IOS Software, existe apenas uma linha de comando para configuração. Neste modo, a funcionalidade do CatOS foi integrada ao Cisco IOS Software. A integração resulta em uma única linha de comando tanto para a configuração de switching como de roteamento. Neste modo, o Cisco IOS Software é o software do sistema, substituindo o CatOS.

Ambos os sistemas operacionais CatOS e Cisco IOS Software são empregados em redes críticas. O CatOS, com a opção Cisco IOS Software para placas filhas de router e módulos, é suportado nestas séries de switch:

  • Catalyst 6500/6000

  • Catalyst 5500/5000

  • Catalyst 4500/4000

O software de sistema Cisco IOS é suportado nestas séries de switch:

  • Catalyst 6500/6000

  • Catalyst 4500/4000

Consulte o documento Melhores Práticas para Catalyst Switches 4500/4000, 5500/5000 e 6500/6000 Series Executando Configuração e Gerenciamento de CatOS para informações sobre o CatOS, porque esse documento abrange o software de sistema Cisco IOS.

O software de sistema Cisco fornece aos usuários algumas dessas vantagens:

  • Uma única interface de usuário

  • Uma plataforma de gerenciamento de rede unificada

  • Recursos aprimorados de QoS

  • Suporte distribuído de switching

Este documento fornece orientações para configuração modular. Portanto, você pode ler cada seção independentemente e fazer as alterações em uma abordagem por fases. Ao ler este documento, supõe-se que você tenha uma compreensão básica e familiaridade com a interface do usuário do Software Cisco IOS. O documento não abrange o projeto geral de rede do campus.

Antes de Iniciar

Informações Complementares

As soluções que este documento oferece representam anos de experiência de campo dos engenheiros da Cisco que trabalham com redes complexas e muitos dos maiores clientes. Conseqüentemente, este documento enfatiza as configurações do mundo real que fazem com que as redes sejam bem-sucedidas. Este documento oferece estas soluções:

  • Soluções que tenham estatisticamente a mais larga exposição de campo e portanto o menor risco

  • Soluções simples e que negociam alguma flexibilidade por resultados determinísticos

  • Soluções fáceis de gerenciar e configuradas por equipes de operação de rede

  • Soluções que promovem alta disponibilidade e alta estabilidade

Referências

Existem muitos sites de referência para as linhas de produto Catalyst 6500/6000 e Catalyst 4500/4000 em Cisco.com. As referências listadas nesta seção fornecem uma maior profundidade em tópicos discutidos neste documento.

Consulte a Página de Suporte de Switching de LAN para mais informações sobre qualquer dos tópicos abordados neste documento. A página de suporte fornece documentação de produtos e também documentos para solução de problemas e configurações.

Este documento fornece referências a material público on-line que você pode ler mais. Mas outras referências fundamentais e educativas são:

Configuração Básica

Esta seção discute os recursos implementados na utilização da maioria das redes Catalyst.

Protocolos de Plano de Controle do Catalyst

Esta seção apresenta os protocolos executados entre os switches em operação normal. Uma compreensão básica destes protocolos é útil na resolução de cada seção.

Tráfego do Supervisor Engine

A maioria dos recursos ativados em uma rede Catalyst requer a cooperação entre dois ou mais switches. Portanto, deve haver um intercâmbio controlado de mensagens de manutenção de atividade, parâmetros de configuração e alterações de gerenciamento. Independente de esses protocolos serem ou não de propriedade da Cisco, como o Cisco Discovery Protocol (CDP) ou baseado em padrões, como IEEE 802.1D (Spanning Tree Protocol [STP]), todos possuem determinados elementos em comum quando os protocolos são implementados na série Catalyst.

No encaminhamento de estrutura básica, as estruturas de dados do usuário se originam de sistemas finais. O endereço de origem (SA) e endereço de destino (DA) das estruturas de dados não são alterados por todos os domínios comutados da Camada 2 (L2). As tabelas de consulta de memória de conteúdo endereçável (CAM) em cada Supervisor Engine de switch são preenchidas por um processo de aprendizado de SA. As tabelas indicam qual porta de saída encaminha cada quadro recebido. Se o destino for desconhecido ou o quadro for destinado a um endereço broadcast ou multicast, o processo de aprendizado de endereços está incompleto. Quando o processo estiver incompleto, o quadro é encaminhado (inundado) para todas as portas naquela VLAN. O switch também deve reconhecer quais quadros devem ser comutados pelo sistema e quais quadros devem ser direcionados à própria CPU do switch. A CPU do switch também é conhecida como Network Management Processor (NMP).

Entradas especiais na tabela CAM são usadas para criar o plano de controle do Catalyst. Essas entradas especiais são chamadas de entradas do sistema. O plano de controle recebe e direciona o tráfego ao NMP em uma porta de switch interna. Dessa forma, com o uso de protocolos com endereços MAC de destino bem conhecidos, o tráfego de plano de controle pode ser separado do tráfego de dados.

A Cisco possui uma escala reservada de endereços Ethernet MAC e de protocolo, conforme mostrado na tabela desta seção. Este documento abrange cada endereço reservado detalhadamente, mas esta tabela mostra um resumo para sua conveniência.

Recurso

SNAP1 HDLC2 Tipo de Protocolo

Destino Multicast MAC

PAgP3

0x0104

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

PVST+, RPVST+4

0x010b

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

Ponte VLAN

0x010c

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

UDLD5

0x0111

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

CDP

0x2000

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

DTP6

0x2004

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

STP UplinkFast

0x200a

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

Árvore de abrangência IEEE 802.1D

N/A—DSAP7 42 SSAP8 42

01-80-c2-00-00-00

ISL9

N/A

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

VTP10

0x2003

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

Pausa IEEE 802.3x

N/A—DSAP 81 SSAP 80

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

1 SNAP = Subnetwork Access Protocol.

2 HDLC = High-Level Data Link Control.

3 PAgP = Port Aggregation Protocol.

4 PVST+ = Per VLAN Spanning Tree+ e RPVST+ = Rapid PVST+.

5 UDLD = UniDirectional Link Detection.

6 DTP = Dynamic Trunking Protocol.

7 DSAP = ponto de acesso do serviço de destino.

8 SSAP = ponto de acesso do serviço de origem.

9 ISL = Inter-Switch Link.

10 VTP = VLAN Trunk Protocol.

A maioria dos protocolos de controle da Cisco utiliza um encapsulamento IEEE 802.3 SNAP, que inclui um Logical Link Control (LLC) 0xAAAA03 e um Organizational Unique Identifier (OUI) 0x00000C. Você pode ver isto em um rastreamento do analisador LAN.

Esses protocolos assumem uma conectividade ponto a ponto. Observe que o uso deliberado de endereços de destino de multicast permite que dois switches Catalyst se comuniquem com transparência por switches que não sejam da Cisco. Dispositivos que não compreendem e interceptam os quadros simplesmente os inundam. Entretanto, as conexões de ponto-a-multiponto por ambientes de fornecedores múltiplos podem resultar em um comportamento inconsistente. No geral, evite conexões de ponto-a-multiponto por ambientes de fornecedores múltiplos. Esses protocolos terminam em routers da Camada 3 e funcionam apenas dentro de um domínio do switch. Esses protocolos recebem prioridade sobre os dados do usuário pela entrada do processamento e agendamento de circuitos integrados de aplicativos específicos (ASIC).

Agora a discussão se volta para SA. Os protocolos de switch utilizam um endereço MAC retirado de um banco de endereços disponíveis. Uma EPROM no chassi fornece o banco de endereços disponíveis. Envie o comando show module para exibir os intervalos de endereços disponíveis a cada módulo para origem do tráfego, como as unidades de dados de protocolo de ponte (BPDUs) ou quadros ISL. Este é um exemplo de saída do comando:

>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 

               !--- Estes são os MACs para tráfego de origem.
            
         

VLAN 1

A VLAN 1 possui um significado especial nas redes Catalyst.

Ao fazer entroncamento, o Catalyst Supervisor Engine sempre utiliza a VLAN padrão, VLAN 1, para marcar um número de protocolos de gerenciamento e de controle. Esses protocolos incluem CDP, VTP e PAgP. Todas as portas de switch, que incluem a interface sc0 interna, são configuradas por padrão para serem membros da VLAN 1. Todos os troncos possuem a VLAN 1 por padrão.

Essas definições são necessárias para ajudar a esclarecer alguns termos muito utilizados na rede Catalyst:

  • A VLAN de gerenciamento é onde o sc0 reside para CatOS e switches low-end. Você pode alterar esta VLAN. Tenha isto em mente quando estiver interconectando tanto switches CatOS como Cisco IOS.

  • A VLAN nativa é a VLAN para a qual uma porta retorna quando não estiver fazendo entroncamento. Além disso, a VLAN nativa é a VLAN não rotulada em um tronco IEEE 802.1Q.

Existem boas razões para ajustar uma rede e alterar o comportamento das portas na VLAN 1:

  • Quando o diâmetro da VLAN 1, como qualquer outra VLAN, aumenta o suficiente para representar um risco à estabilidade, especialmente na perspectiva da STP, é necessário encurtar a VLAN. Consulte a seção Interface de Gerenciamento de Switch e VLAN Nativa para obter detalhes.

  • Os dados do plano de controle da VLAN 1 devem ser mantidos separados dos dados do usuário para simplificar a solução de problemas e maximizar os ciclos de CPU disponíveis. Evite loops de Camada 2 na VLAN 1 quando projetar redes de campus multicamada sem STP. Para evitar os loops de Camada 2, limpe manualmente a VLAN 1 das portas de tronco.

Em resumo, observe essas informações sobre troncos:

  • As atualizações de CDP, VTP e PAgP são sempre encaminhadas nos troncos com uma etiqueta VLAN 1. Isto ocorre mesmo se a VLAN 1 tiver sido removida dos troncos e não for a VLAN nativa. Se a VLAN 1 for liberada para os dados do usuário, a ação não terá impacto sobre o tráfego do plano de controle que ainda for enviado por meio da VLAN 1.

  • Em um tronco ISL, os pacotes DTP são enviados na VLAN1. Isto ocorre mesmo se a VLAN 1 for removida do tronco e não for mais a VLAN nativa. Em um tronco 802.1Q, os pacotes DTP são enviados na VLAN nativa. Isto ocorre mesmo se a VLAN nativa tiver sido removida do tronco.

  • No PVST+, os BPDUs 802.1Q IEEE são encaminhados sem rotulagem no na VLAN 1 da Árvore de Abrangência comum para interoperabilidade com outros fornecedores, a menos que a VLAN 1 tenha sido removida do tronco. Isto ocorre independente da configuração da VLAN nativa. BPDUs PVST+ da Cisco são enviados e rotulados para todas as outras VLANs. Consulte a seção Spanning Tree Protocol para obter mais detalhes.

  • As BPDUs da Árvore de Abrangência Múltipla (MST) 802.1s são sempre enviadas na VLAN 1 tanto nos troncos ISL como 802.1Q. Isso se aplica mesmo quando a VLAN 1 tiver sido removida dos troncos.

  • Não remova ou desative a VLAN 1 nos troncos entre as pontes MST e PVST+. Mas, no caso de desativação da VLAN 1, a ponte MST deve se tornar raiz para que todas as VLANs evitem colocar a ponte MST em estado de raiz inconsistente nas suas portas limítrofes. Consulte Entendendo o Multiple Spanning Tree Protocol (802.1s) para obter detalhes.

Recursos Padrão

Esta seção do documento enfoca os recursos de switching básicos que são comuns a qualquer ambiente. Configure esses recursos em todos os dispositivos de switching de Catalyst do Cisco IOS Software na rede do cliente.

VLAN Trunk Protocol

Finalidade

Um domínio VTP, também chamado de domínio de gerenciamento de VLAN, é composto de um ou mais switches interconectados através de um tronco e que compartilham o mesmo nome de domínio VTP. O VTP é projetado para permitir que os usuários façam alterações de configuração de VLAN centralmente em um ou mais switches. O VTP comunica as alterações automaticamente VTP a todos os outros switches no domínio VTP (da rede). É possível configurar um switch para estar em apenas um domínio VTP. Antes de criar VLANs, determine o modo VTP a ser usado na rede.

Visão Geral Operacional

O VTP é um protocolo de transferência de mensagens de Camada 2. O VTP gerencia a adição, exclusão e renomeação de VLANs em toda a rede para manter a consistência da configuração da VLAN. O VTP minimiza configurações incorretas e inconsistentes que podem causar alguns problemas. Esses problemas incluem nomes de VLAN duplicados, especificações de tipo de VLAN incorretos e violações de segurança.

Por padrão, o switch está em modo de servidor VTP e em estado de domínio sem gerenciamento. Estas configurações padrão se alteram quando o switch recebe um anúncio para um domínio sobre um link de tronco ou quando o domínio de gerenciamento é configurado.

O protocolo VTP se comunica entre os switches usando um MAC multicast de destino Ethernet bem conhecido (01-00-0c-cc-cc-cc) e um protocolo SNAP HDLC tipo Ox2003. De modo similar a outros protocolos intrínsecos, o VTP também usa um encapsulamento IEEE 802.3 SNAP, que inclui LLC 0xAAAA03 and OUI 0x00000C. É possível ver isto em um rastreamento do analisador LAN. O VTP não funciona em portas que não são de tronco. Portanto, as mensagens não podem ser enviadas até que o DTP tenha trazido o tronco. Em outras palavras, o VTP é uma carga do ISL ou 802.1Q.

Os tipos de mensagem incluem:

  • Anúncios resumidos a cada 300 segundos (seg)

  • Anúncios de subconjunto e anúncios de solicitação quando houver alterações

  • Junções quando a poda de VTP estiver ativada

O número de revisão da configuração do VTP é aumentado em um número a cada alteração realizada em um servidor e a tabela se propaga pelo domínio.

Se uma VLAN for excluída, as portas que eram membros do VLAN são colocadas em inativo estado. De maneira semelhante, se um switch no modo de cliente não for capaz de receber a tabela VTP VLAN na inicialização, seja de um servidor VTP ou outro cliente VTP, todas as portas nas VLANs diferentes da VLAN 1 padrão serão desativadas.

É possível configurar a maioria dos switches Catalyst para operarem em um desses modos VTP.

  • Servidor—Em modo de servidor VTP, é possível:

    • Criar VLANs

    • Alterar VLANs

    • Excluir VLANs

    • Especificar outros parâmetros de configuração, como a versão do VTP e poda de VTP, para todo o domínio VTP

    Os servidores VTP anunciam a sua configuração de VLAN aos outros switches no mesmo domínio VTP. Os servidores VTP também sincronizam a sua configuração VLAN com outros switches com base nos anúncios recebidos em outros links de tronco. Servidor VTP é o modo padrão.

  • Cliente—clientes VTP se comportam da mesma maneira que os servidores VTP. Mas não é possível criar, alterar ou excluir VLANs em um cliente VTP. Além disso, o cliente não se lembra da VLAN após uma reinicialização porque nenhuma informação da VLAN é gravada na NVRAM.

  • Transparente—switches VTP transparentes não participam no VTP. Um switch VTP transparente não anuncia as suas configurações de VLAN e não sincroniza a sua configuração de VLAN com base nos anúncios recebidos. Mas, no VTP versão 2, os switches transparentes encaminham anúncios VTP que os switches recebem de suas interfaces de tronco.

Recurso

Servidor

Cliente

Transparente

Desativado1

Mensagens VTP de origem

Sim

Sim

Não

Ouvir as mensagens VTP

Sim

Sim

Não

Criar VLANs

Sim

Não

Sim (apenas localmente significativas)

Lembrar as VLANs

Sim

Não

Sim (apenas localmente significativas)

1 O Cisco IOS Software não possui a opção de desativar VTP usando o desligado modo.

Esta tabela é um resumo da configuração inicial:

Recurso

Valor Padrão

Nome de Domínio VTP

Nulo

Modo VTP

Servidor

Versão VTP

A versão 1 está ativada

Poda de VTP

Desabilitado

No modo VTP transparente, as atualizações de VTP são simplesmente ignoradas. O endereço VTP multicast do MAC bem conhecido é removido do CAM do sistema que é normalmente usado para coletar os quadros de controle e direcioná-los ao Supervisor Engine. Como o protocolo usa um endereço multicast, o switch no modo transparente ou switch de outro fornecedor irá simplesmente inundar o quadro para outros switches Cisco no domínio.

O VTP versão 2 (VTPv2) inclui a flexibilidade funcional que esta lista descreve. Entretanto, VTPv2 não é interoperável com VTP versão 1 (VTPv1):

  • Suporte a Token Ring

  • Informações de suporte a VTP não reconhecidas—os switches agora propagam valores que não podem analisar.

  • Modo transparente dependente da versão—o modo transparente não mais verifica o nome de domínio. Isto permite o suporte de mais de um domínio em um domínio transparente.

  • Propagação do número da versão—se o VTPv2 for possível em todos os switches, todos poderão ser ativados com a configuração de um único switch.

Consulte Entendendo e Configurando o VLAN Trunk Protocol (VTP) para obter mais informações.

Operação VTP em Cisco IOS Software

As configurações alteradas no CatOS são gravadas na NVRAM imediatamente após serem realizadas. De forma contrária, o Cisco IOS Software não salva as alterações de configuração na NVRAM a menos que você emita o comando copy running-config startup-config. Os sistemas de VTP cliente e servidor requerem que atualizações de outros VTPs servidores sejam salvas na NVRAM sem intervenção do usuário. As exigências de atualização do VTP são atendidas pela configuração padrão do CatOS, mas o modelo de atualização do Cisco IOS Software requer uma operação de atualização alternativa.

Para essa alteração, um banco de dados VLAN foi introduzido no Cisco IOS Software para o Catalyst 6500 como um método de salvar imediatamente atualizações de VTP para clientes e servidores de VTP. Em algumas versões do software, esse banco de dados VLAN está na forma de um arquivo separado na NVRAM, conhecido como arquivo vlan.dat. Verifique a sua versão do software para determinar se é necessário o backup do banco de dados da VLAN. Você pode visualizar as informações de VTP/VLAN armazenadas no arquivo vlan.dat para o cliente VTP ou servidor VTP se você emitir o comando show vtp status.

A configuração inteira de VTP/VLAN não é salva no arquivo de configuração de inicialização na NVRAM quando você emite o comando copy run start nesses sistemas. Isso não se aplica a sistemas que funcionam como VTP transparente. Os sistemas de VTP transparente salvam a configuração inteira de VTP/VLAN no arquivo de configuração de inicialização na NVRAM quando você emite o comando copy run start.

Em versões do Cisco IOS Software mais antigas que o Cisco IOS Software Versão 12.1(11b)E, é possível configurar o VTP e as VLANs somente através do modo de banco de dados da VLAN. O modo de banco de dados VLAN é um modo separado do modo de configuração global. A razão para esta exigência de configuração é que quando o dispositivo é configurado no servidor em modo VTP ou cliente em modo VTP, os vizinhos do VTP podem atualizar o banco de dados da VLAN dinamicamente através de anúncios VTP. Não é desejável que essas atualizações se propaguem automaticamente para a configuração. Portanto, o banco de dados da VLAN e as informações do VTP não são armazenados na configuração principal, mas armazenadas na NVRAM em um arquivo chamado vlan.dat.

Este exemplo mostra como criar uma VLAN Ethernet no modo de banco de dados de VLAN.

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

Em versões do Cisco IOS Software 12.1(11b)E e posteriores, é possível configurar o VTP e as VLANs em modo de banco de dados ou através do modo de configuração global. No servidor em modo VTP ou em modo transparente do VTP, a configuração das VLANs ainda atualizam o arquivo vlan.dat na NVRAM. Entretanto, esses comandos não são salvos na configuração. Portanto, os comandos não figuram na configuração em execução.

Consulte a seção Configuração de VLAN em Modo de Configuração Global do documento Configurando VLANs para obter mais informações.

Este exemplo mostra como criar uma VLAN Ethernet no modo de configuração global e como verificar a configuração.

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

Observação: A configuração da VLAN é armazenada no arquivo vlan.dat, que é armazenado em memória não volátil. Para fazer um backup completo da sua configuração, inclua o arquivo vlan.dat no backup juntamente com a configuração. Depois, se o switch inteiro ou o módulo Supervisor Engine necessitarem de substituição, o administrador da rede deve fazer o upload de ambos esses arquivos para restaurar a configuração completa:

  • O arquivo vlan.dat

  • O arquivo de configuração

VTPVTP e VLANs estendidas

O recurso de ID de Sistema Estendido é usado para permitir a identificação de VLAN de intervalo estendido. Quando o ID de Sistema Estendido é ativado, ele desativa o conjunto de endereços MAC que são utilizados para a árvore de abrangência e deixa um único endereço MAC que identifica o switch. O CatOS IOS Software Versão 12.1(11b)EX e 12.1(13)E introduzem suporte a ID de Sistema Estendido para Catalyst 6000/6500 para suportar 4096 VLANs em conformidade com o padrão IEEE 802.1Q. Este recurso é introduzido no Cisco IOS Software Versão 12.1(12c)EW para switches Catalyst 4000/4500. Estas VLANs são organizadas em diversos intervalos, podendo cada um deles ser usado de maneira diferente. Algumas dessas VLANs são propagadas para outros switches na rede quando o VTP é usado. As VLANs de intervalo estendido não são propagadas, então elas devem ser configuradas manualmente em cada dispositivo da rede. Este recurso de ID de Sistema Estendido é equivalente ao recurso de Redução de Endereço MAC no Catalyst OS.

Esta tabela descreve os intervalos de VLAN:

VLANs

Intervalo

Uso

Propagado por VTP?

0, 4095

Reservado

Para uso do sistema apenas. Estas VLANs não podem ser visualizadas ou usadas.

1

Normal

Padrão da Cisco. Esta VLAN pode ser usada, mas não pode ser excluída.

Sim

2–1001

Normal

Para VLANs Ethernet. Estas VLANs podem ser criadas, usadas e excluídas.

Sim

1002–1005

Normal

Padrões da Cisco para FDDI e Token Ring. VLANs 1002–1005 não podem ser excluídas.

Sim

1006–4094

Reservado

Para VLANs Ethernet apenas.

Não

Os protocolos de switch utilizam um endereço MAC que é tirado de um banco de endereços disponíveis que uma EPROM fornece no chassi como parte dos identificadores de ponte para VLANs que são executadas sob PVST+ e RPVST+. Os switches Catalyst 6000/6500 e Catalyst 4000/4500 suportam 1024 ou 64 endereços MAC, que dependem do tipo do chassi.

Os switches Catalyst com 1024 endereços MAC não ativam o ID de Sistema Estendido por padrão. Os endereços MAC são alocados sequencialmente, sendo o primeiro endereço MAC no intervalo atribuído à VLAN 1, o segundo endereço MAC no intervalo atribuído à VLAN 2 e assim por diante. Isto possibilita aos switches suportarem 1024 VLANs e cada VLAN usa um identificador de ponte exclusivo.

Tipo do Chassi

Endereço do Chassi

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 Chassi com 64 endereços MAC ativam o ID de Sistema Estendido por padrão e o recurso não pode ser desativado.

Consulte a seção Entendendo o ID de Ponte em Configurando STP e IEEE 802.1s MST para obter mais informações.

Para Catalyst Series Swithces com endereços MAC 1024, ativar a redução de endereço MAC permite o suporte a 4096 VLANs que são executadas sob PVST+ ou 16 instâncias MISTP para terem identificadores exclusivos sem aumentar o número de endereços MAC que são necessários para o switch. O ID de Sistema Estendido reduz o número de endereços MAC que são exigidos pelo STP de um por instância VLAN ou MISTP a um por switch.

Esta figura mostra o identificador de ponte quando o ID de Sistema Estendido não está ativado. O identificador de ponte é composto por uma prioridade de ponte de 2 bytes e um endereço MAC de 6 bytes.

185-t.gif

O ID de Sistema Estendido modifica a parte do Identificador de Ponte do Spanning Tree Protocol (STP) das Bridge Protocol Data Units (BPDU). O campo de prioridade original de 2 bytes é dividido em 2 campos; um campo de prioridade de ponte de 4 bits e uma extensão de ID de sistema de 12 bits que possibilita a numeração de VLAN de 0 a 4095.

185-u.gif

Quando o ID de Sistema Estendido é ativado em switches Catalyst para otimizar as VLANs de intervalo estendido, ele precisa ser ativado em todos os switches dentro do mesmo domínio STP. Isto é necessário para manter consistentes os cálculos da raiz STP em todos os switches. Quando o ID de Sistema Estendido é ativado, a prioridade da ponte de raiz se torna um múltiplo de 4069 mais o ID da VLAN. Os switches sem ID de Sistema Estendido podem reclamar raiz inadvertidamente porque têm uma granularidade mais fina na seleção do seu ID de ponte.

Apesar de ser recomendável manter consistente a configuração do ID de Sistema Estendido dentro do mesmo domínio STP, não é prático aplicar o ID de Sistema Estendido em todos os dispositivos quando se introduz um novo chassi com endereço MAC 64 no domínio STP. Mas é importante entender que quando dois sistemas são configurados com a mesma prioridade de árvore de abrangência, o sistema sem ID de Sistema Estendido tem uma prioridade de árvore de abrangência melhor. Execute este comando para ativar a configuração de ID de Sistema Estendido:

spanning-tree extend system-id

As VLANs internas são alocadas em ordem ascendente, começando pela VLAN 1006. Recomenda-se atribuir as VLANs do usuário o mais próximo possível da VLAN 4094 para evitar conflitos entre as VLANs do usuário e as VLANs internas. Execute o comando show vlan internal usage em um switch para exibir os as VLANs atribuídas internamente.

Switch#show vlan internal usage

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

No IOS Nativo, vlan internal allocation policy descending pode ser configurado para que as VLANs sejam alocadas em ordem decrescente. A CLI equivalente para o software CatOS não é suportada oficialmente.

vlan internal allocation policy descending

Recomendação da Cisco para a Configuração

VLANs podem ser criadas quando um Catalyst 6500/6000 está em modo de servidor VTP, mesmo sem um nome de domínio VTP. Configure o nome de domínio VTP primeiro, antes de configurar as VLANs nos switches Catalyst 6500/6000 que executam o software de sistema Cisco IOS. A configuração nesta ordem mantém a consistência com outros switches Catalyst que exscutam CatOS.

Não há recomendação específica sobre utilizar ou não modos cliente/servidor VTP ou VTP. transparente modo. Alguns clientes preferem a facilidade de gerenciamento do modo cliente/servidor VTP, apesar de algumas considerações anotadas nesta seção. Recomenda-se possuir dois switches de modo servidor em cada domínio para redundância, normalmente os dois switches de camada de distribuição. Configure o restante dos switches no domínio em modo cliente. Quando se implementa o modo cliente/servidor usando VTPv2, lembre-se que um número de revisão superior é sempre aceito no mesmo domínio VTP. Se um switch configurado em modo cliente ou servidor VTP é introduzido no domínio VTP e possui um número de revisão superior aos dos servidores VTP existentes, isto substitui o banco de dados da VLAN dentro do domínio VTP. Se a alteração na configuração não for intencional e as VLANs forem excluídas, essa substituição pode causar uma grande interrupção na rede. Para garantir que os switches cliente ou servidor sempre possuam um número de revisão de configuração inferior ao do servidor, altere o nome do domínio VTP para outro que não o nome padrão e depois retorne ao padrão. Esta ação define a revisão de configuração no cliente para 0.

Há vantagens e desvantagens para a capacidade do VTP de fazer alterações facilmente em uma rede. Muitas empresas preferem uma abordagem cuidadosa e usam VTP transparente por essas razões:

  • Esta prática incentiva um bom controle de alterações, porque a exigência de modificar uma VLAN em um switch ou porta de tronco deve ser considerada um switch por vez

  • O modo VTP transparente limita o risco de um erro de administração, como a exclusão acidental de uma VLAN. Tais erros podem impactar o domínio inteiro.

  • As VLANs podem ser removidas dos troncos para switches que não possuem portas na VLAN. Isto faz da inundação de estrutura mais eficiente para a largura de banda. A remoção manual também possui um diâmetro reduzido de árvore de abrangência. Consulte a seção Dynamic Trunking Protocol para obter mais informações. Uma configuração de VLAN por switch também incentiva esta prática.

  • Não há nenhum risco de que a introdução de um novo switch na rede com um número de revisão de VTP maior possa substituir a configuração VLAN de todo o domínio.

  • O modo transparente de VTP do Cisco IOS Software é suportado no Campus Manager 3.2, que faz parte do CiscoWorks2000. A restrição anterior que exigia pelo menos um servidor em um domínio VTP foi removida.

Comandos VTP

Comentários

vtp domain name

O CDP verifica o nome para ajudar a evitar erros de cabeamento entre domínios. Os nomes de dominio fazem distinção entre maiúsculas e minúsculas.

vtp mode {server | client | transparent}

O VTP opera em um de três modos.

vlan vlan_number

Isto cria uma VLAN com o ID fornecido.

switchport trunk allowed vlan_range

Este é um comando de interface que permite aos troncos transportarem VLANs quando necessário. O padrão é todas as VLANs.

switchport trunk pruning vlan_range

Este é um comando de interface que limita o diâmetro do STP por meio de remoção manual, como em troncos da camada de distribuição para a camada de acesso, onde a VLAN não existe. Por padrão, todas as VLANs estão qualificadas para remoção.

Outras Opções

O VTPv2 é um requisito em ambientes Token Ring, onde o modo cliente/servidor é altamente recomendado.

A seção Recomendações de Configuração da Cisco neste documento defende os benefícios de remover VLANs para reduzir inundação desnecessária de quadros. O comando vtp pruning remove VLANs automaticamente e interrompe a inundação ineficiente de quadros quando eles não são necessários.

Observação: Diferentemente da remoção manual de VLAN, a remoção automática não limita o diâmetro da árvore de abrangência.

O IEEE produziu uma arquitetura baseada em padrões para conseguir resultados semelhantes aos de VTP. Como membro do Generic Attribute Registration Protocol (GARP) 802.1Q, o Generic VLAN Registration Protocol (GVRP) possibilita a interoperabilidade de gerenciamento de VLAN entre fornecedores. No entanto, o GVRP está fora da abrangência deste documento.

Observação: O Cisco IOS Software não possui capacidade de VTP desligada e apenas suporta VTPv1 e VTPv2 com remoção.

Negociação Automática de Ethernet Rápida

Finalidade

A negociação automática é uma função otimizada do padrão IEEE 802.3u Fast Ethernet (FE). A negociação automática permite que os dispositivos automaticamente troquem informações sobre velocidade e capacidades duplex sobre um link. A negociação automática opera na Camada 1 (L1). O alvo da função são portas que estão alocadas em áreas nas quais dispositivos ou usuários transitórios se conectam a uma rede. Exemplos incluem switches e hubs da camada de acesso.

Visão Geral Operacional

A negociação automática utiliza uma versão modificada do teste de integridade do link para que os dispositivos 10BASE-T negociem a velocidade e troquem outros parâmetros de negociação automática. O teste de integridade do link 10BASE-T original é chamado de Normal Link Pulse (NLP). A versão modificada do teste de integridade de link para negociação automática de 10/100 Mbps é chamada de Fast Link Pulse (FLP). Os dispositivos 10BASE-T esperam um pulso de intermitência a cada 16 (+/- 8) milissegundos (ms) como parte do teste de integridade do link. O FLP para a negociação automática de 10/100 Mbps envia esses pulsos intermitentes a cada 16 (+/- 8) ms com pulsos adicionais a cada 62,5 (+/- 7) microssegundos. Os pulsos dentro da seqüência de pulsos intermitentes geram palavras-código usadas para trocas de compatibilidade entre parceiros de link.

Em 10BASE-T, um pulso de link é enviado sempre que surge uma estação. Este é um pulso simples que é enviado a cada 16 ms. Os dispositivos 10BASE-T também enviam um pulso de link a cada 16 ms quando o link está inativo. Esses pulsos de link também são chamados de batida de coração ou NLP.

Um dispositivo 100BASE-T envia FLP. Esse pulso é enviado como intermitência em vez de um pulso. A intermitência é completada dentro de 2 ms, sendo repetida novamente a cada 16 ms. Na inicialização, o dispositivo transmite uma mensagem FLP de 16 bits ao parceiro de link para negociação de velocidade, duplex e controle de fluxo. Essa mensagem de 16 bits é enviada repetidamente até que a mensagem seja confirmada pelo parceiro.

Observação: De acordo com a especificação IEEE 802.3u, não é possível configurar manualmente um parceiro de link para full-duplex de 100 Mbps e ainda realizar a negociação automática para full-duplex com o outro parceiro de link. Tentar configurar um parceiro de link para 100 Mbps full duplex e o outro para negociação automática resultará em incompatibilidade bidirecional. A incompatibilidade bidirecional ocorre porque um parceiro de link realiza a negociação automática e não vê nenhum parâmetro de negociação automática do outro parceiro de link. O primeiro parceiro de link então considera semiduplex.

Todos os módulos de switching da Ethernet do Catalyst 6500 suportam 10/100 MB e semidirecional ou bidirecional. Execute o comando show interface capabilities para verificar este recurso em outros switches Catalyst.

Uma das causas mais comuns de problemas de desempenho nos links de Ethernet 10/100 MB ocorre quando uma porta no link opera de forma half-duplex enquanto a outra opera de forma full-duplex. Esta situação ocorre ocasionalmente quando uma ou ambas as portas em um link são reinicializadas e o processo de negociação automática não resulta na mesma configuração para ambos os parceiros de link. Também acontece quando um lado de um link é reconfigurado e se esquece de reconfigurar o outro. É possível evitar a necessidade de fazer chamadas de suporte relacionadas com o desempenho se você:

  • Criar uma política que requeira a configuração de portas para o comportamento requerido para todos os dispositivos não transitórios

  • Aplicar a política com medidas de controle de mudança adequadas

O sintomas típicos disto são o aumento de seqüência de verificação de estrutura (FCS), verificação de redundância cíclica (CRC), alinhamento ou contadores de runt no switch.

No método half duplex, existe um par de fios de recepção e um de transmissão. Não é possível usar ambos os fios ao mesmo tempo. O dispositivo não consegue transmitir quando existe um pacote no lado da recepção.

No modo half duplex, existe o mesmo par de fios de recepção e de transmissão. No entanto, ambos podem ser usados ao mesmo tempo porque as funções Carrier Sense e Collision Detect foram desativadas. O dispositivo pode transmitir e receber ao mesmo tempo.

Assim, uma conexão half-duplex para full-duplex funciona, mas há um grande número de colisões no lado half-duplex que ocasionam um desempenho fraco. As colisões ocorrem porque o dispositivo que é configurado como full duplex pode transmitir ao mesmo tempo que o dispositivo recebe dados.

Os documentos nesta lista discutem em detalhes a negociação automática. Estes documentos explicam como a negociação automática funciona e discutem diversas opções de configuração:

Um equívoco comum sobre a negociação automática é achar que é possível configurar manualmente um parceiro de link para 100 Mbps full-duplex e negociar automaticamente para full-duplex com o outro parceiro de link. Na verdade, tentar fazer isso vai resultar em uma incompatibilidade duplex. Isso acontece porque um dos parceiros de link realiza a negociação automática, não visualiza os parâmetros de negociação automática do outro parceiro de link e assume a configuração half-duplex como padrão.

A maioria dos módulos Catalyst Ethernet oferecem suporte a 10/100 MB e half/full-duplex. No entanto, é possível confirmar isto executando o comando show interface mod/port capabilities.

FEFI

O FEFI (indicação de falha de extremidade oposta) protege as interfaces 100BASE-FX (fibra) e Gigabit, ao passo que a negociação automática protege a 100BASE-TX (cobre) contra falhas relacionadas à camada física e à sinalização de falhas.

Uma falha de extremidade oposta no enlace que uma estação pode detectar enquanto a outra não pode. Um fio de transmissão desconectado é um exemplo. Neste exemplo, a estação de envio ainda recebe dados válidos e detecta que o link é bom através do monitor de integridade de link. A estação de envio, no entanto, não consegue detectar que a outra estação não recebe a transmissão. Uma estação 100BASE-FX que detecta tal falha remota pode modificar o seu fluxo IDLE transmitido para enviar um padrão de bit especial e informar o vizinho sobre a falha remota. O padrão especial de bits é chamado de padrão FEFI-IDLE . O padrão FEFI-IDLE dispara em seguida um desligamento da porta remota (errDisable). Consulte a seção UniDirectional Link Detection deste documento para obter mais informações sobre proteção contra falhas.

Estes módulos/hardware suportam FEFI:

  • Catalyst 6500/6000 e 4500/4000:

    • Todos os módulos 100BASE-FX e GE

Recomendação da Cisco para Porta de Infra-estrutura

Configurar a negociação automática em links 10/100 Mbps ou codificar a velocidade e duplex depende do tipo de parceiro de link ou dispositivo de extremidade que você conectou a uma porta de switch Catalyst. A negociação automática entre dispositivos de extremidade e dispositivos de switch Catalyst geralmente funciona bem e os switches Catalyst são compatíveis com a especificação IEEE 802.3u. Entretanto, pode haver problemas quando switches de placa de interface de rede (NIC) ou de fornecedor não são exatamente compatíveis. Além disso, a incompatibilidade de hardware e outros problemas também podem existir em virtude de recursos avançados específicos do fornecedor que não são descritos na especificação IEEE 802.3u para negociação automática de 10/100 Mbps. Esses tipos de recursos avançados incluem a polaridade automática e integridade de cabeamento. Este documento fornece um exemplo:

Em algumas situações, será necessário configurar o host, a velocidade de porta e duplex. Em geral, realize estes passos básicos de solução de problemas:

  • Verifique se a negociação automática está configurada em ambos os lados do link ou se a codificação está configurada em ambos os lados.

  • Verifique as notas de versão para obter as advertências comuns.

  • Verifique a versão do driver NIC ou sistema operacional em execução. Frequentemente é necessário o último driver ou patch.

Como regra, primeiramente use a negociação automática para qualquer tipo de parceiro de link. Há benefícios óbvios ao configurar a negociação automática para dispositivos transitórios como laptops. A negociação automática também funciona bem com outros dispositivos, por exemplo:

  • Com dispositivos não transitórios, como servidores e estações de trabalho fixas

  • De switch para switch

  • De switch para router

Mas, por algumas das razões mencionadas nesta seção, podem surgir problemas de negociação. Para obter mais informações sobre os passos de solução de problemas nesses casos, consulte o documento Configurando e Solucionando Problemas de Autonegociação Half/Full Duplex da Ethernet 10/100/1000Mb.

Desativar negociação automática para:

  • Portas que suportam dispositivos de infra-estrutura de rede, como switches e routers

  • Outros sistemas de extremidade não transitórios, como servidores e impressoras

Sempre codifique as configurações de velocidade e duplex para essas portas.

Configure manualmente essas configurações de link de 10/100 Mbps para velocidade e duplex, que normalmente são full-duplex de 100 Mbps:

  • Switch para switch

  • Switch para servidor

  • Switch para router

Se a velocidade da porta estiver configurada para automática em uma porta Ethernet de 10/100 Mbps, tanto a velocidade como o duplex serão negociados automaticamente. Execute este comando de interface para definir a porta como automática:

Switch(config)#interface fastethernet slot/port
            
Switch(config-if)#speed auto
            
               !--- Este é o padrão.
            
         

Execute estes comandos de interface para configurar a velocidade e duplex:

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

Recomendações da Cisco para Porta de Acesso

Usuários finais, trabalhadores móveis e hosts transitórios necessitam de negociação automática para minimizar o gerenciamento desses hosts. Também é possível fazer funcionar a negociação automática em switches Catalyst. Frequentemente são necessários os últimos drivers NIC.

Execute estes comandos globais para ativar a negociação automática de velocidade para a porta:

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

Observação: Se a velocidade da porta estiver configurada para automática em uma porta Ethernet de 10/100 Mbps, tanto a velocidade como o duplex serão negociados automaticamente. Não é possível alterar o modo duplex das portas de negociação automática.

Quando switches de NIC ou fornecedores não são exatamente compatíveis com relação à especificação de IEEE 802.3u, pode haver problemas. Além disso, a incompatibilidade de hardware e outros problemas também podem existir em virtude de recursos avançados específicos do fornecedor que não são descritos na especificação IEEE 802.3u para negociação automática de 10/100 Mbps. Esses tipos de recursos avançados incluem a polaridade automática e integridade de cabeamento.

Outras Opções

Quando a negociação automática entre switches está desativada, a indicação de falha de Camada 1 também pode ser perdida para certos problemas. Use protocolos de Camada 2 para aumentar a detecção de falhas, tal como UDLD assertivo.

A negociação automática não detecta essas situações, mesmo quando ela está ativada:

  • As portas travam e não recebem ou transmitem

  • Um lado do link está ativo mas o outro lado do link se tornou inativo

  • Os cabos de fibra óptica estão conectados incorretamente

A negociação automática não detecta esses problemas porque não estão na camada física. Os problemas podem levar a loops de STP ou buracos negros de tráfego.

UDLD pode detectar todos esses casos e desativar por erro ambas as portas do link, se UDLD estiver configurado em ambas as extremidades. Desta forma, UDLD impede loops de STP e buracos negros de tráfego.

Negociação Automática de Ethernet Gigabit

Finalidade

Gigabit Ethernet (GE) possui um procedimento de negociação automática que é mais extensivo do que o usado para Ethernet de 10/100 Mbps (IEEE 802.3z). Com portas GE ports, a negociação automática é usada para intercambiar:

  • Parâmetros de controle de fluxo

  • Informação de falha remota

  • Informação duplex

    Observação: Portas GE da série Catalyst suportam apenas o modo full-duplex.

IEEE 802.3z foi substituído pelas especificações IEEE 802.3:2000. Consulte Redes Locais e Metropolitanas + Minutas de Assinatura de Padrões (LAN/MAN 802s) leavingcisco.com para obter mais informações.

Visão Geral Operacional

Diferentemente da negociação automática com FE de 10/100 Mbps, a negociação automática de GE não envolve a negociação da velocidade das portas. Também não é possível executar o comando set port speed para desativar a negociação automática. A negociação de porta GE é ativada por padrão, e as portas de ambas as extremidades de um link GE devem ter a mesma configuração. O link não aparece se houver inconsistência na configuração das portas em cada extremidade do link, o que significa que os parâmetros intercambiados são diferentes.

Por exemplo, digamos que existam dois dispositivos, A e B. Cada dispositivo pode ter a negociação automática habilitada ou desabilitada. Esta tabela possui as possíveis configurações e os seus respectivos estados de link:

Negociação

B Habilitado

B Desabilitado

A Habilitado

ativo nos dois lados

A inativo, B ativo

A Desabilitado

A ativo, B inativo

ativo nos dois lados

No GE, a sincronização e a negociação automática (quando habilitadas) são executadas na inicialização do link por meio do uso de uma seqüência especial de palavras de código de link.

Observação: Existe um dicionário de palavras válidas e nem todas as palavras são válidas no GE.

A vida de uma conexão GE pode ser caracterizada dessa forma:

185-n.gif

Uma perda de sincronização significa que o MAC detectou uma queda de o serviço de links. A perda de sincronização se aplica independentemente se a negociação automática está habilitada ou desabilitada. A sincronização é perdida em determinadas condições de falha, como a recepção sucessiva de três palavras inválidas. Se essa condição persistir por 10 ms, uma condição "sync fail" é declarada e o link muda para o estado link_down . Após a perda de sincronização, mais três ociosos válidos consecutivos são necessários para a ressincronização. Outros eventos catastróficos, como a perda do sinal de recebimento (Rx), causam um evento de queda de o serviço de links.

A negociação automática faz parte do processo de linkup. Quando o link está habilitado, a negociação automática acaba. Entretanto, o switch ainda monitora o status do link. Se a negociação automática estiver desabilitada em uma porta, a fase "autoneg" não será mais uma opção.

A especificação de cobre da GE (1000BASE-T) suporta a negociação automática por meio do Next Page Exchange. O Next Page Exchange permite a negociação automática de velocidades 10/100/1000-Mbps em portas de cobre.

Observação: No entanto, a especificação de fibra GE faz provisões apenas para a negociação de duplex, controle de fluxo e detecção de falha remota. As portas de fibra GE não negociam a velocidade da porta. Consulte as seções 28 e 37 da especificação IEEE 802.3-2002 leavingcisco.com para obter mais informações sobre negociação automática.

O retardo de reinício de sincronização é um recurso de software que controla o tempo de negociação automática. Se a negociação automática não for bem sucedida dentro desse período, o firmware reinicia a negociação automática caso exista um bloqueio. O comando sync-restart-delay só tem efeito quando a negociação automática está configurada para habilitar.

Recomendação da Cisco para Porta de Infra-estrutura

A configuração da negociação automática é muito mais importante em um ambiente de GE que em um ambiente 10/100. Apenas desabilite a negociação nessas situações:

  • Nas portas de switch conectadas a dispositivos que não são capazes de suportar negociação

  • Quando surgem questões de conectividade a partir de questões de interoperabilidade

Habilite a negociação de Gigabit em todos os links switch a switch e geralmente em todos os dispositivos GE. O valor padrão em interfaces Gigabit é a negociação automática. Ainda assim, execute este comando para ter certeza que a negociação automática está habilitada:

switch(config)#interface type 
               slot/port
            
switch(config-If)#no speed 
            
               !--- Este comando configura a porta para negociar automaticamente parâmetros Gigabit.
            
         

Uma exceção conhecida é quando existe uma conexão com um Router de Switch de Gigabit (GSR) executando uma versão do Cisco IOS Software mais antiga que 12.0(10)S, versão essa que adicionou o controle de fluxo e a negociação automática. Nesse caso, desligue esses dois recursos. Se você não desativar esses recursos, a porta do switch informa que não está conectada e o GSR informa erros. Este é um exemplo de seqüência de comando de interface:

            flowcontrol receive off
            flowcontrol send off
            speed nonegotiate
         

Recomendações da Cisco para Porta de Acesso

Como FLPs podem variar entre os fornecedores, é necessário verificar as conexões de switch a servidor caso a caso. Os clientes da Cisco tiveram alguns problemas com a negociação Gigabit em servidores Sun, HP e IBM. Faça com que todos os dispositivos usem a negociação automática de Gigabit a menos que o fornecedor NIC declare especificamente o contrário.

Outras Opções

O controle de fluxo é uma parte opcional da especificação 802.3x. O controle de fluxo deve ser negociado se for usado. Os dispositivos podem ou não ser capazes de enviar e/ou responder a um quadro PAUSE (MAC 01-80-C2-00-00-00 0F bem conhecido). Além disso, os dispositivos podem talvez não concordar com a solicitação de controle de fluxo do vizinho da extremidade oposta. Uma porta com um buffer de entrada que comece a ficar cheio envia um quadro PAUSE ao link parceiro. O parceiro de link interrompe a transmissão e segura todos os quadros adicionais nos buffers de saída do parceiro de link. Esta função não resolve nenhum problema de sobreassinatura de estado estacionário. Porém, a função efetivamente torna o buffer de entrada maior em alguma fração do buffer de saída de parceiro durante os bursts.

A função PAUSE foi projetada para evitar o descarte desnecessário de quadros recebidos pelos dispositivos (switches, routers ou estações de extremidade) devido às condições de excesso de buffer causadas pela sobrecarga temporária de tráfego temporário. Um dispositivo com sobrecarga de tráfego impede o excesso de buffer interno quando o dispositivo envia um quadro PAUSE. O quadro PAUSE contém um parâmetro que indica o tempo que o parceiro full-duplex deve aguardar antes de enviar mais quadros de dados. O parceiro que recebe o quadro PAUSE deixa de enviar dados durante o período especificado. Quando esse temporizador expira, a estação começa a enviar quadros de dados novamente, a partir de onde a estação havia parado.

Uma estação que emite um PAUSE pode emitir outro quadro PAUSE que contém um parâmetro de tempo zero. Esta ação cancela o restante do período de pausa. Assim, um quadro novo PAUSE recebido cancela qualquer operação PAUSE que esteja atualmente em progresso. Além disso, a estação que emite o quadro PAUSE pode estender o período de PAUSE. A estação emite outro quadro PAUSE que contém um parâmetro de tempo não-zero antes de expirar o primeiro período de PAUSE.

Esta operação de PAUSE não é um controle de fluxo com base em taxa. A operação é um mecanismo simples de iniciar-parar que permite ao dispositivo sob tráfeto, o que enviou o quadro PAUSE, uma chance de reduzir o seu congestionamento de buffer.

Esse recurso é melhor usado em links entre as portas de acesso e os hosts finais, onde o buffer de saída do host seja potencialmente tão grande quanto a memória virtual. O uso de switch para switch tem benefícios limitados.

Execute estes comandos de interface para controlar isso nas portas do switch:

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


>show port flowcontrol

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

Observação: Todos os módulos Catalyst respondem a um quadro PAUSE se negociado. Alguns módulos (por exemplo, WS-X5410 e WS-X4306) nunca enviam quadros de pausa, mesmo quando negociam para fazê-lo, porque eles são não-blocantes.

Dynamic Trunking Protocol

Finalidade

Para estender as VLANs entre os dispositivos, os troncos identificam e marcam temporariamente (link local) os quadros Ethernet originais. Esta ação permite que os quadros sejam multiplexados sobre um link único. A ação também assegura que os domínios separados de broadcast e segurança da VLAN sejam mantidos entre switches. As tabelas CAM mantêm o mapeamento de quadro para VLAN dentro dos switches.

Visão Geral Operacional

DTP é a segunda geração do Dynamic ISL (DISL). DISL apenas suportava ISL. DTP suporta tanto ISL como 802.1Q. Este suporte garante que os switches em ambas as extremidades de um tronco concordem quanto aos diferentes parâmetros de quadros de entroncamento. Esses parâmetros incluem:

  • Tipo de encapsulamento configurado

  • VLAN Nativa

  • Capacidade de hardware

O suporte a DTP também ajuda a proteger contra portas de não-tronco inundando quadros marcados, que é um sério risco de segurança em potencial. DTP protege contra tal inundação porque garante que as portas e os seus vizinhos estejam em estados consistentes.

Modo de Entroncamento

O DTP é um protocolo de Camada 2 que negocia parâmetros de configuração entre uma porta de switch e seu vizinho. DTP usa outro endereço MAC multicast bem conhecido de 01-00-0c-cc-cc-cc e um tipo de protocolo SNAP de 0x2004. Esta tabela descreve a função de cada um dos modos de negociação DTP possíveis:

Modo

Função

Quadros DTP Transmitidos?

Estado Final (Porta Local)

Auto dinâmico (equivalente ao modo Auto no CatOS)

Faz com que a porta queira converter o link em um tronco. A porta se tornará uma porta de tronco se a porta vizinha for definida para modo ativado ou desejável .

Sim, periódico

Entroncamento

Tronco (equivalente ao modo ON no CatOS)

Coloca a porta em modo de entroncamento permanente e negocia para converter o link em um tronco. A porta se tornará uma porta de tronco mesmo se a porta vizinha não concordar em mudar.

Sim, periódico

Entroncamento, incondicionalmente

Não-negociação

Coloca a porta em modo de entroncamento permanente mas não permite que a porta gere quadros DTP. A porta vizinha deve ser configurada manualmente como uma porta de tronco para estabelecer um link de tronco. Isso é útil em dispositivos que não suportam DTP.

Não

Entroncamento, incondicionalmente

Dinâmico desejável (O comando CatOS comparável é desejável)

Faz com que a porta tente ativamente converter o link em um link de tronco. A porta se tornará uma porta de tronco se a porta vizinha estiver definida no modo ativado, desejável, ou automático .

Sim, periódico

Termina em estado de entroncamento apenas se o modo remoto for ativado, automático, ou desejável.

Acesso

Coloca a porta em modo de não-entroncamento e negocia para converter o link em um link não-tronco. A porta se tornará uma porta de não-tronco mesmo se a porta vizinha não concordar em mudar.

Não em estado steady, mas a transmissão informa para acelerar e detecção da extremidade remota após a alteração de ativado.

Não-entroncamento

Observação: O tipo de encapsulamento ISL e 802.1Q pode ser configurado ou negociado.

Na configuração padrão, o DTP assume estas características no link:

  • Conexões ponto a ponto e dispositivos Cisco apenas suportam as portas de tronco 802.1Q que sejam ponto a ponto.

  • Durante a negociação DTP, as portas não participam em STP. A porta é adicionada ao STP apenas após o tipo de porta se tornar um desses três tipos:

    • Acesso

    • ISL

    • 802.1Q

    O PAgP é o processo seguinte a ser executado antes da porta participar no STP. O PAgP é usado para negociação automática de EtherChannel.

  • VLAN 1 está sempre presente na porta de tronco. Se a porta estiver sendo utilizada como tronco no modo ISL, os pacotes DTP são enviados em VLAN 1. Caso contrário, os pacotes DTP são enviados em VLAN nativa (para portas 802.1Q de entroncamento ou não-entroncamento).

  • Os pacotes de DTP transferem o nome de domínio do VTP mais a configuração de tronco e o status administrativo. O nome de domínio VTP deve coincidir para fazer surgir um tronco negociado. Esses pacotes são enviados a cada segundo durante a negociação e a cada 30 segundos após a negociação. Se uma porta em modo automático ou desejável não detectar um pacote DTP em 5 minutos (min), ela será definida como não-tronco.

cuidado Cuidado: Deve-se compreender que os modos tronco, não negociar, e acesso especificam explicitamente em qual estado a porta termina. Uma configuração inválida pode levar a um estado perigoso/inconsistente no qual um lado está fazendo o entroncamento e o outro não.

Consulte Configurando o Entroncamento ISL no Catalyst 5500/5000 e Switches da Família 6500/6000 para obter mais detalhes de ISL. Consulte o Entroncamento entre Catalyst 4500/4000, 5500/5000 e 6500/6000 Series Switches, Utilizando Encapsulamento 802.1Q com Software de Sistema Cisco CatOS para obter mais detalhes sobre o 802.1Q.

Tipo de Encapsulamento

Visão Geral Operacional do ISL

ISL é um protocolo de entroncamento proprietário da Cisco (esquema de marcação de VLAN) O ISL tem sido usado há muitos anos. Em contraste, 802.1Q é muito mais recente, mas 802.1Q é o padrão IEEE.

O ISL encapsula completamente o quadro originam em um esquema de marcação em dois níveis. Desta forma, o ISL é, na verdade, um protocolo de tunelamento e, como benefício adicional, carrega quadros não-Ethernet. O ISL adiciona um cabeçalho de 26 bytes e um FCS de 4 bytes ao quadro Ethernet padrão. Portas configuradas para serem troncos esperam e processam os quadros Ethernet maiores. O ISL suporta 1024 VLANs.

Formato de Quadro – Etiqueta ISL é Sombreada

185-a.gif

185-b.gif

Consulte o InterSwitch Link e o Formato de Frame IEEE 802.1Q para obter mais informações.

Visão Geral Operacional do 802.1Q

Ainda que o padrão IEEE 802.1Q pertença apenas à Ethernet, o padrão especifica muito mais do que tipos de encapsulamento. 802.1Q inclui, dentre outros Generic Attribute Registration Protocols (GARPs), aperfeiçoamentos de árvore de abrangência e marcação QoS 802.1p. Para obter mais informações, consulte os Padrões IEEE On-line leavingcisco.com.

O formato de quadro 802.1Q preserve os SA e DA Ethernet originais. No entanto, os switches agora esperam receber quadros baby-giant, mesmo em portas de acesso onde hosts podem usar marcação para expressar prioridade de usuário 802.1p para sinalização de QoS. A etiqueta tem 4 bytes. Os quadros 802.1Q Ethernet v2 possuem 1522 bytes, o que é uma conquista do grupo de trabalho IEEE 802.3ac. O 802.1Q também suporta espaço de numeração para 4096 VLANs.

Todos os quadros de dados transmitidos e recebidos são marcados com 802.1Q, exceto os quadros de dados que estão na VLAN nativa. Neste caso, existe uma etiqueta implícita que é baseada na configuração da porta de switch de ingresso. Os quadros da VLAN Nativa são sempre transmitidos não-rotulados e normalmente recebidos não-rotulados. Entretanto, esses quadros também podem ser recebidos marcados.

Consulte estes documentos para obter mais informações:

Formato de Quadro 802.1Q/802.1p

185-c.gif

Recomendação da Cisco para a Configuração

Um dos aspectos principais de projeto da Cisco é buscar a consistência na rede onde a ela for possível. Todos os novos produtos Catalyst suportam 802.1Q e alguns somente suportam 802.1Q, como os módulos antigos nas séries Catalyst 4500/4000 e Catalyst 6500. Assim, todas as novas implementações devem seguir este padrão IEEE 802.1Q e as redes mais antigas precisam migrar gradualmente a partir do ISL.

Execute estes comandos de interface para habilitar o entroncamento 802.1Q em uma porta específica:

Switch(config)#interface type slot#/port#
            
Switch(config-if)#switchport
            
               !--- Configure a interface como uma porta de Camada 2.
            
Switch(config-if)#switchport trunk encapsulation dot1q
         

O padrão IEEE permite interoperabilidade de fornecedor. A interoperabilidade de fornecedor é vantajosa em todos os ambientes Cisco à medida que os novos NICs e dispositivos de host 802.1p se tornam disponíveis. Apesar das implementações ISL e 802.1Q serem sólidas, o padrão IEEE finalmente terá mais exposição de campo e mais suporte de terceiros, incluindo o suporte a analisadores de rede. Além disso, uma consideração menor é que o padrão 802.1Q também possui uma sobrecarga de encapsulação mais baixa do que o ISL.

Para completude, a marcação implícita em VLANs nativas cria uma consideração de segurança. É possível a transmissão dos quadros de uma VLAN, VLAN X, para outra VLAN, VLAN Y, sem um router. A transmissão pode ocorrer sem um router se a porta de origem (VLAN X) estiver na mesma VLAN que a VLAN nativa de um tronco 802.1Q no mesmo switch. A solução é usar uma VLAN fictícia para a VLAN nativa do tronco.

Execute estes comandos de interface para estabelecer uma VLAN como nativa (padrão) para o entroncamento 802.1Q em uma porta específica:

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

Como todos os novos hardwares suportam 802.1Q, faça com que todas as novas implementações sigam o padrão IEEE 802.1Q e migre gradualmente as redes mais antigas a partir do ISL. Até pouco tempo atrás, muitos módulos Catalyst 4500/4000 não suportavam o ISL. Assim, 802.1Q é a única opção para entroncamento de Ethernet. Consulte a saída do comando show interface capabilities ou do comando show port capabilities para CatOS. Como o suporte a entroncamento requer o hardware adequado, um módulo que não suporte 802.1Q nunca poderá suportar 802.1Q. Uma atualização de software não confere suporte a 802.1Q. A maioria dos novos hardwares para os switches Catalyst 6500/6000 e Catalyst 4500/4000 suportam tanto ISL como 802.1Q.

Se a VLAN 1 for removida de um tronco, conforme discutido na seção Interface de Gerenciamento de Switch e VLAN Nativa, apesar de nenhum dado do usuário ter sido transmitido ou recebido, o NMP continua a passar protocolos de controle na VLAN 1. Exemplos de protocolo de controle incluem o CDP e VTP.

Além disso, conforme discutido na seção VLAN 1, os pacotes de CDP, VTP e PAgP sempre são enviados na VLAN 1 durante o entroncamento. Ao usar o encapsulamento dot1q (802.1Q), esses quadros de controle serão marcados com VLAN 1 se a VLAN nativa do switch tiver sido alterada. Se o entroncamento dot1q para um router e a VLAN nativa forem alterados no switch, uma subinterface na VLAN 1 é necessária para receber os quadros CDP marcados e fornecer visibilidade de CDP vizinho no router.

Observação: Existe uma consideração de segurança em potencial com o dot1q causada pela marcação implícita da VLAN nativa. É possível a transmissão dos quadros de uma VLAN para outra sem um router. Consulte Perguntas Freqüentes sobre a Detecção de Intrusos leavingcisco.com para obter mais detalhes. A solução é usar um ID de VLAN para a VLAN nativa do tronco que não é utilizado para acesso de usuário final. Para fazer isso, a maioria dos clientes Cisco simplesmente deixam a VLAN 1 como a VLAN nativa em um tronco e atribuem portas de acesso a VLANs diferentes da VLAN 1.

A Cisco recomenda uma configuração explícita de tronco dinâmico desejável em ambas as extremidades. Este é o modo padrão. Nesse modo, os operadores de rede podem confiar nas mensagens syslog e de status da linha de comando de que a porta está ativa e fazendo entroncamento. Este modo é diferente do modo ativo , que pode fazer com que a porta apareça mesmo com o vizinho desconfigurado. Além disso, os troncos no modo desejável proporcionam estabilidade em situações onde um lado do link não pode se tornar um tronco ou sai do estado de tronco .

Como o tipo de encapsulamento é negociado entre os switches usando o DTP, com ISL selecionado como o vencedor por padrão, se ambas as extremidades o suportarem, é necessário executar esse comando para especificar o dot1q1:

            switchport trunk encapsulation dot1q
            
         

1 Determinados módulos que incluem WS-X6548-GE-TX e WS-X6148-GE-TX não suportam entroncamento ISL. Esses módulos não aceitam o comando switchport trunk encapsulation dot1q .

Observação: Para desabilitar troncos em uma porta, execute o comando switchport mode access. Essa desabilitação ajuda a eliminar a perda de tempo de negociação ao ativar as portas de host.

Switch(config-if)#switchport host
         

Outras Opções

Outra configuração do cliente comum usa o modo dinâmico desejável na camada de distribuição e a configuração padrão mais simples (modo auto dinâmico ) na camada de acesso. Alguns switches, como o Catalyst 2900XL, routers Cisco IOS ou dispositivos de outros fornecedores não suportam atualmente a negociação de tronco por meio do DTP. Você pode usar o modo não-negociação para configurar uma porta para fazer entroncamento incondicionalmente com esses dispositivos. Esse modo pode ajudar a padronizar uma configuração comum por todo o campus.

A Cisco recomenda não-negociação ao se conectar com um router Cisco IOS. Por toda a ligação, alguns quadros DTP recebidos de uma porta configurada com switchport mode trunk podem retornar à porta de tronco. Ao receber o quadro de DTP, a porta do switch tenta renegociar desnecessariamente. Para renegociar, a porta do switch desativa e depois ativa o tronco. Se a não-negociação estiver habilitada, o switch não envia quadros DTP.

switch(config)#interface type slot#/port#
            
switch(config-if)#switchport mode dynamic desirable
            
               !--- Configure a interface como entroncamento no modo desejável 
!--- para links switch para switch com VLANs múltiplas.
            
            
               !--- E...
            
switch(config-if)#switchport mode trunk
            
               !--- Force a interface em modo de tronco sem negociação da conexão de tronco.
            
            
               !--- Ou...
            
switch(config-if)#switchport nonegotiate
            
               !--- Configure o modo de entroncamento para não enviar pacotes de negociação DTP
!--- de troncos para routers.
            
switch(config-if)#switchport access vlan vlan_number
            
            
               !--- Configure uma VLAN de recuo para a interface.
            
switch(config-if)#switchport trunk native vlan 999
            
               !--- Defina a VLAN nativa.
            
switch(config-if)#switchport trunk allowed vlan vlan_number_or_range
            
            
               !--- Configure as VLANs que não são permitidas no tronco.
            
         

Spanning Tree Protocol

Finalidade

A árvore de abrangência mantém um ambiente de Camada 2 livre de circuito em redes comutadas redundantes e pontes. Sem o STP, os quadros entram em loop e/ou se multiplicam indefinidamente. Esta ocorrência provoca sobrecarga de rede, pois todos os dispositivos no domínio de broadcast são interrompidos pelo tráfego intenso.

Em alguns aspectos, o STP é um protocolo antigo que foi inicialmente desenvolvido para especificações de ponte lentas baseadas em software (IEEE 802.1D). No entanto, o STP pode ser complicado para implementá-lo com sucesso em grandes redes comutadas que possuam:

  • Muitas VLANs

  • Muitos switches em um domínio

  • Suporte multifornecedor

  • Novos aperfeiçoamentos IEEE

O Software de Sistema Cisco IOS implementou novos desenvolvimentos de STP. Os novos padrões IEEE que incluem protocolos 802.1w Rapid STP e 802.1s Multiple Spanning Tree proporcionam convergência rápida, compartilhamento de carga e dimensionamento de plano de controle. Adicionalmente, recursos de aperfeiçoamento de STP como RootGuard, filtragem de BPDU filtering, guarda Portfast BPDU e Loopguard proporcionam uma proteção adicional contra loops de encaminhamento de Camada 2.

Visão Geral Operacional do PVST+

Você pode configurar os EtherChannels de LACP de diferentes modos, como resumido nesta tabela:

Modo

Opções Configuráveis

Ativado

A agregação de link é forçada a ser formada sem qualquer negociação LACP. O switch não envia pacote LACP e não processa pacote de LACP recebido. Se a porta do vizinho estiver ativada, está formado um canal

Desativado (ou) Não Está Configurado

A porta não está sendo canalizada, independentemente de como o vizinho está configurado.

Passivo (Padrão)

Isso é semelhante ao modo automático em PAgP. O switch não inicia o canal, mas entende os pacotes de LACP recebidos. O peer (no estado ativo) inicia a negociação (enviando um pacote de LACP) que o switch recebe e ao qual o switch responde, formando, eventualmente, o canal de agregação com o peer.

Active

Isso é semelhante ao modo desejável no PAgP. O switch inicia a negociação para formar um link agregado. O link agregado será formado se a outra extremidade for executada no LACP em modo ativo ou passivo.

O LACP utiliza um cronômetro de intervalo de 30 segundos (Slow_Periodic_Time) depois que os EtherChannels de LACP estiverem estabilizados. O número de segundos antes da invalidação de informações LACPDU recebidas ao usar intervalos longos (3 vezes o Slow_Periodic_Time) é 90. O UDLD é recomendado como um detector mais rápido de links unidirecionais. Não é possível ajustar os temporizadores de LACP e, nesse ponto, não é possível configurar os switches para usar a transmissão de PDU (unidade de dados de protocolo) rápida (cada segundo) para manter o canal depois de o canal ser formado.

A Verificação

A tabela dessa seção fornece um resumo de todos os cenários de modo de canalização LACP possíveis entre dois switches conectados diretamente (Switch A e Switch B). Algumas dessas combinações podem fazer com que o protetor do EtherChannel coloque as portas no lado da canalização no estado errdisable. O recurso de proteção contra erro de configuração no The EtherChannel está habilitado por padrão.

Modo de Canal Switch A

Modo de Canal Switch B

Estado de Canal Switch A

Estado de Canal Switch B

Ativado

Ativado

Canal (não-LACP)

Canal (não-LACP)

Ativado

Desativado

Não Canal (errDisable)

Não Canal

Ativado

Passivo

Não Canal (errDisable)

Não Canal

Ativado

Active

Não Canal (errDisable)

Não Canal

Desativado

Desativado

Não Canal

Não Canal

Desativado

Passivo

Não Canal

Não Canal

Desativado

Active

Não Canal

Não Canal

Passivo

Passivo

Não Canal

Não Canal

Passivo

Active

Canal LACP

Canal LACP

Active

Active

Canal LACP

Canal LACP

Recomendações da Cisco

A Cisco recomenda que o PAgP seja ativado em todos as conexões de canal entre switches da Cisco. Quando a canalização de dispositivos não suporta o PAgP mas suporta o LACP, ative o LACP por meio da configuração de LACP

Em switches que executam o CatOS, todas as portas de um Catalyst 4500/4000 e um Catalyst 6500/6000 usam o protocolo de canal PAgP por padrão. Para configurar as portas para usar o LACP, você deve definir o protocolo do canal nos módulos para LACP. O LACP e o PAgP não podem executar o mesmo módulo em switches que executem o CatOS. Essa limitação não se aplica aos switches que executam o Cisco IOS Software. Os switches que executam o Cisco IOS Software podem suportar o PAgP e o LACP no mesmo módulo. Emita esses comandos para definir o modo de canal do LACP como ativo e atribuir um número de chave administrativa:

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

O comando show etherchannel summary exibe um resumo em uma linha por grupo de canais que inclui estas informações:

  • Números de grupos

  • Números de canais de portas

  • Status das portas

  • As portas que fazem parte do canal

O comando show etherchannel port-channel exibe informações detalhadas sobre o canal de porta para todos os grupos de canais. A saída inclui estas informações:

  • Status do canal

  • Protocolo utilizado

  • O tempo desde que as portas foram agrupadas

Para exibir informações detalhadas para um grupo de canais específico, com os detalhes de cada porta mostrados separadamente, use o comando show etherchannel channel_number detail. A saída de comando inclui os detalhes do parceiro e os detalhes do canal da porta. Consulte Configurando o LACP (802.3ad) entre um Catalyst 6500/6000 e um Catalyst 4500/4000 para obter mais informações.

Outras Opções

Com dispositivos de canal que não suportam PAgP ou LACP, você deverá codificar o canal para em. Esse requisito se aplica a todos os dispositivos:

  • Servidores

  • Diretor Local

  • Switches de conteúdo

  • Routers

  • Switches com software mais antigo

  • Switches Catalyst 2900XL/3500XL

  • Catalyst 8540s

Emita estes comandos:

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

UniDirectional Link Detection

Finalidade

O UDLD é um protocolo leve proprietário da Cisco que foi desenvolvido para detectar instâncias de comunicações unidirecionais entre os dispositivos. Há outros métodos para detectar o estado bidirecional de mídia de transmissão, como o FEFI. Mas, há instâncias nas quais os mecanismos de detecção da Camada 1 não são suficientes. Estes cenários podem resultar em:

  • Operação imprevisível de STP

  • Inundação incorreta ou excessiva de pacotes

  • Buraco negro de tráfego

O recurso UDLD especifica essas condições de falha nas interfaces de Ethernet de fibra e de cobre:

  • Monitora configurações de cabeamento físico – Encerra como errDisabled quaisquer portas com conexão incorreta dos fios.

  • Protege contra enlaces unidirecionais — Na detecção de um enlace unidirecional que ocorre devido a um mau funcionamento da porta/interface, a porta afetada é encerrada como errDisabled. Uma mensagem syslog correspondente é gerada.

  • Além disso, o modo assertivo UDLD verifica se um enlace previamente considerado bidirecional não perde a conectividade no caso de esse enlace se tornar inutilizável devido a uma congestão. O modo assertivo UDLD executa teste contínuos de conectividade em todo o enlace. O objetivo principal do modo assertivo UDLD é evitar o desaparecimento de tráfego em determinadas condições de falha que não são especificadas pelo modo normal UDLD.

Consulte Compreendendo e Configurando o Recurso UDLD (Unidirectional Link Detection Protocol) para obter mais detalhes.

A extensão de árvore tem um fluxo BPDU unidirecional estável e pode ter as falhas relacionadas por esta seção. Uma porta pode repentinamente falhar ao transmitir BPDUs, o que causa uma alteração no estado de STP de bloqueio para encaminhamento no vizinho. Ainda, um loop continua a existir, pois a porta ainda está apta a receber.

Visão Geral Operacional

O UDLD é um protocolo de Camada 2 que funciona acima da camada de LLC (destino MAC 01-00-0c-cc-cc-cc, SNAP HDLC tipo de protocolo 0x0111). Ao executar o UDLD em combinação com o FEFI e os mecanismos de auto-negociação da Camada 1, você pode validar a integridade física (L1) e lógica (L2) de um link.

O UDLD tem provisões para recursos e proteção que o FEFI e a auto-negociação não podem executar. Esses recursos incluem:

  • A detecção e o cache de informações vizinhas

  • O encerramento de quaisquer portas conectadas incorretamente

  • A detecção de mau funcionamentos de interface/porta lógica ou falhas em enlaces que não são ponto a ponto

    Observação: Quando os enlaces não são ponto a ponto, eles atravessam os conversores ou hubs de mídia.

O UDLD utiliza esses dois mecanismos básicos.

  1. O UDLD aprende sobre os vizinhos e mantém as informações atualizadas em um cache local.

  2. O UDLD envia um trem de mensagens de prova/eco (saudação) de UDLD na detecção de um novo vizinho ou sempre que um vizinho solicitar uma ressincronização do cache.

O UDLD envia constantemente mensagens de provas/eco em todas as portas. Na recepção de uma mensagem de UDLD correspondente em uma porta, uma fase de detecção e um processo de validação é acionado. A porta será habilitada se todas as condições válidas forem atendidas. As condições serão atendidas se a porta for bidirecional e estiver corretamente ligada. Se as condições não forem atendidas, a porta será errDisabled, o que aciona esta mensagem do syslog:

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

Para obter uma lista completa de mensagens do sistema por facilidade, o que inclui eventos do UDLD, consulte Mensagens UDLD (Mensagens do Cisco IOS System, Volume 2 de 2).

Após o estabelecimento de um enlace e sua classificação como bidirecional, o UDLD continua a anunciar as mensagens de provas/eco em um intervalo padrão de 15 s.

Esta tabela oferece informações sobre estados de portas:

Estado de Porta

Comentário

Indeterminado

A detecção no UDLD em andamento/vizinhança foi desabilitada.

Não aplicável

O UDLD foi desabilitado.

Shutdown

O enlace unidirecional foi detectado e a porta foi desabilitada.

Bidirecional

Link bidirecional detectado

Manutenção de Cache Vizinho

O UDLD envia periodicamente pacotes de prova/eco de saudação em cada interface ativa, para manter a integridade do cache vizinho de UDLD. Ao receber uma mensagem de saudação, ela é armazenada em cache e mantida na memória por um período máximo definido como tempo de contenção. Quando o tempo de contenção expirar, a entrada de cache respectiva se tornará ultrapassada. Se uma nova mensagem de saudação for recebida dentro do tempo de contenção, a nova substituirá a entrada mais antiga e o cronômetro de duração correspondente será redefinido.

Sempre que uma interface habilitada para UDLD for desabilitada ou sempre que um dispositivo for redefinido, todas as entradas de cache existentes nas interfaces que a alteração na configuração afeta serão eliminadas. Essa liberação mantém a integridade do cache de UDLD. O UDLD transmite pelo menos uma mensagem para informar aos respectivos vizinhos a necessidade de liberar as entradas do cache correspondentes.

Mecanismo de Detecção de Eco

O mecanismo de eco forma a base do algoritmo de detecção. Sempre que um dispositivo UDLD obtiver informações sobre um novo vizinho ou receber uma requisição de ressincronização de um vizinho não sincronizado, ele iniciará ou reiniciará a janela de detecção no lado da conexão e enviará uma intermitência de mensagens de eco como resposta. Como esse comportamento deve ser o mesmo em todos os vizinhos, o emissor de ecos espera receber ecos como resposta. Se a janela de detecção for fechada sem nenhuma recepção de mensagem de resposta válida, o enlace será considerado unidirecional. A partir deste ponto, um processo de restabelecimento de enlace ou de encerramento de porta pode ser acionado. Caso contrário, condições anormais raras as quais o dispositivo verifica são:

  • Fibras Tx (transmissão em loop) para o conector Rx da mesma porta

  • Erros de conexão no caso de uma interconexão de mídia compartilhada (por exemplo, um hub ou dispositivo similar)

Tempo de convergência

Para evitar loops de STP, o Cisco IOS Software Versão 12.1 e posterior reduziram o intervalo da mensagem padrão de UDLD de 60 segundos para 15 segundos. Esse intervalo foi alterado para encerrar um enlace unidirecional antes que uma porta anteriormente bloqueada na árvore de abrangência 802.1D fosse capaz de fazer a transição para um estado de encaminhamento. O valor do intervalo da mensagem determina a taxa em que um vizinho envia provas de UDLD após a fase de linkup ou detecção. O intervalo de mensagem não precisa corresponder as duas extremidades de um link, apesar da configuração consistente ser desejável quando possível. Quando os vizinhos UDLD são estabilizados, o intervalo de mensagens configuradas é enviado ao vizinho e o intervalo de intervalo desse peer é calculado como:

3 * (message interval)

Assim, a relação do peer expira depois de três saudações (ou provas) consecutivas serem perdidas. Como os intervalos de mensagens são diferentes em cada lado, esse valor de intervalo é simplesmente diferente em cada lado e um lado reconhece a falha com mais rapidez.

O tempo aproximado necessário para que o UDLD detecte uma falha unidirecional de um enlace anteriormente estável é de aproximadamente:

2.5 * (message interval) + 4 seconds

Isso é aproximadamente 41 segundos com o intervalo de mensagem padrão de 15 segundos. Esse tempo está bem abaixo dos 50 segundos geralmente necessários para a reconvergência de STP. Se a CPU do NMP tiver algum ciclo sobressalente e se o usuário monitorar cuidadosamente seu nível de utilização (uma prática recomendada), uma redução do intervalo de mensagem (par) para o mínimo de 7 segundos será aceitável. Além disso, essa redução no intervalo da mensagem ajuda a acelerar a detecção por um fator significativo.

Observação: O mínimo é 1 segundo no Cisco IOS Software Versão 12.2(25)SEC.

Portanto, UDLD tem uma dependência assumida em cronômetros de Árvore de Abrangência padrão. Se o STP for ajustado para convergir mais rapidamente que o UDLD, considere um mecanismo alternativo, como o recurso de protetor de loop do STP. Considere também um mecanismo alternativo nesse caso, ao implementar o RSTP (802.1w), pois o RSTP possui características de convergência em ms, dependendo da topologia. Nessas instâncias, use o protetor de loop em conjunto com o UDLD para fornecer a máxima proteção. O protetor de loop evita que o STP faça o loop com a velocidade da versão do STP que está em uso. E o UDLD cuida da detecção de conexões unidirecionais em enlaces de EtherChannel individuais ou em casos em que os BPDUs não fluem ao longo da direção quebrada.

Observação: O UDLD é independente do STP. O UDLD não detecta toda situação de falha de STP, como as falhas causadas por uma CPU que não envia BPDUs por um tempo superior a (2 * Fwddelay + período máximo). Por essa razão, a Cisco recomenda que você implemente o UDLD em conjunto com o protetor de loop em topologias que dependem do STP.

cuidado Cuidado: Cuidados com as versões mais antigas do UDLD dos switches 2900XL/3500XL que usam um intervalo de mensagem padrão não-configurável de 60 segundos. Elas estão sujeitas às condições de circuito de árvore de abrangência.

Modo assertivo de UDLD

O UDLD assertivo foi criado para abordar especificamente esses poucos casos em que um teste contínuo de conectividade bidirecional é necessário. Como tal, o recurso de modo assertivo oferece proteção aprimorada contra condições perigosas de link unidirecional nessas situações:

  • Quando a perda de PDUs de UDLD é simétrica e as duas extremidades expiram. Nesse caso, nenhuma das portas é errdisabled.

  • Um lado de um enlace tem uma porta travada (ambas Tx e Rx).

  • Um lado do link permanece ativo enquanto o outro lado do link se tornou inativo.

  • A negociação automática ou outro mecanismo de detecção de falha da Camada 1, está desabilitada.

  • A redução na confiabilidade em mecanismos da Camada 1 FEFI é desejável.

  • Você precisa de proteção máxima contra falhas de enlace unidirecional em enlaces FE/GE ponto a ponto. Especificamente, onde nenhuma falha entre dois vizinhos é admissível, as provas de UDLD assertivo podem ser consideradas como um “heartbeat”, a presença do qual garante a saúde do link.

O caso mais comum de uma implementação de UDLD assertivo é para executar a verificação de conectividade em um membro de um conjunto quando a negociação automática ou outro mecanismo de detecção de falha da Camada 1 estiver desabilitado ou for não utilizável. Isso é particularmente útil com as conexões de EtherChannel porque o PAgP e o LACP, mesmo se desabilitado, não usam cronômetros de saudação muito baixos no estado steady. Nesse caso, o UDLD assertivo possui benefício adicionado de prevenção de possíveis loops de árvore de abrangência.

É importante entender que o modo normal de UDLD verifica a condição de enlace unidirecional, mesmo depois de um enlace alcançar o status bidirecional. A intenção do UDLD é detectar os problemas da Camada 2 que causam loops de STP, e esses problemas são normalmente unidirecionais (porque os BPDUs fluem em apenas uma direção no estado steady). Portanto, o uso de UDLD normal em conjunto com a negociação automática e o protetor de loop (em redes que dependem do STP) é quase sempre suficiente. Com o modo assertivo UDLD habilitado, depois de todos os vizinhos de uma porta terem sido expirados, seja na fase de anúncio ou de detecção, o modo assertivo UDLD reinicia a seqüência de linkup em um esforço para ressincronizar com todos os vizinhos potencialmente fora de sincronia. Se depois de um rápido treinamento de mensagens (oito tentativas falhas) o enlace ainda for considerado indeterminado, a porta será colocada no estado errdisable.

Observação: Alguns switches não possuem capacidade de UDLD assertivo. Atualmente, o Catalyst 2900XL e o Catalyst 3500XL possuem intervalos de mensagem codificada de 60 segundos. Esse intervalo não é considerado suficientemente rápido para proteger contra os loops de STP em potencial (com os parâmetros de STP padrão assumidos).

Recuperação Automática de Enlaces de UDLD

A recuperação de errdisable é desabilitada globalmente por padrão. Depois de ser globalmente habilitada, se a porta for para o estado errdisable, ela será reabilitada automaticamente após um intervalo de tempo selecionado. O tempo padrão é 300 segundos, que á um cronômetro global e é mantido em todas as portas de um switch. Dependendo da versão do software, você pode evitar manualmente uma reabilitação de porta, caso defina o intervalo de errdisable dessa porta para ser desabilitado com o uso do mecanismo de recuperação de intervalo errdisable para UDLD:

Switch(config)#errdisable recovery cause udld
         

Considere o uso do recurso de intervalo de errdisable ao implementar o modo assertivo UDLD sem capacidades de gerenciamento de rede fora de banda, particularmente na camada de acesso ou em qualquer dispositivo que possa se tornar isolado da rede na eventualidade de uma situação de um errdisable.

Consulte errdisable recovery (Referência de Comandos do Cisco IOS para Catalyst Série 6500, 12.1 E) para obter mais detalhes sobre como configurar um período de intervalo para portas no estado errdisable.

A recuperação de errdisable pode ser especialmente importante para o UDLD da camada de acesso quando os switches de acesso são distribuídos em um ambiente de campus e a visita manual de cada switch para reabilitar os dois uplinks leva um tempo considerável.

A Cisco não recomenda a recuperação de errdisable no centro da rede, pois geralmente há vários pontos de entrada em um centro e a recuperação automática do centro pode levar a problemas recorrentes. Portanto, você deve reabilitar manualmente uma porta no centro se o UDLD a desabilitar.

UDLD em links roteados

Para fins de discussão, um enlace roteado é um desses dois tipos de conexão:

  • Ponto a ponto entre os dois nós do router (configurado com uma máscara de sub-rede de 30 bits)

  • Uma VLAN com várias portas, mas que suporta apenas conexões roteadas, como em uma topologia central de Camada 2 dividida

Cada Interior Gateway Routing Protocol (IGRP) possui características exclusivas com relação a como ela processa as relações do vizinho e a convergência de rota. Esta seção descreve as características que são relevantes para esta discussão, que contrasta dois dos protocolos de roteamento mais predominantes que são usados atualmente, o OSPF (Protocolo Open Shortest Path First) e o IGRP Avançado (EIGRP).

Observação: A falha na Camada 1 ou Camada 2 em todos os resultados de rede roteada ponto a ponto na quase imediata destruição da conexão da Camada 3. Devido a única porta de switch nas transições de VLAN para um estado não conectado mediante a falha da Camada 1/Camada 2, o recurso de auto-estado da interface sincroniza os estados de porta da Camada 2 e da Camada 3 em aproximadamente dois segundos e coloca a interface de VLAN da Camada 3 em um estado ativo/inativo (protocolo de linha como inativo).

Se você supor os valores de cronômetro padrão, o OSPF enviará mensagens de saudação a cada 10 segundos e possuirá um intervalo inoperante de 40 segundos (4 * saudação). Esses cronômetros são consistentes nas redes de ponto a ponto e transmissão de OSPF. Já que o OSPF exige comunicação em dois sentidos para formar uma adjacência, o caso pior de failover será de 40 segundos. Isso será verdadeiro mesmo se a falha da Camada 1/Camada 2 não for pura em uma conexão de ponto a ponto e deixa um cenário meio operacional com o qual o protocolo da Camada 3 deve lidar. Devido ao tempo de detecção de UDLD ser muito semelhante ao tempo de detecção de um cronômetro inoperante de OSPF que expira (aproximadamente 40 segundos), as vantagens da configuração do modo normal de UDLD em um enlace ponto a ponto de OSPF da Camada 3 são limitadas.

Em muitos casos, o EIGRP converge com mais rapidez que o OSPF. Mas, é importante observar que a comunicação em dois sentidos não é um requisito para o intercâmbio de informações de roteamento. Em cenários muito específicos meio operacionais de falha, o EIGRP é vulnerável ao desaparecimento de tráfego que dura até algum outro evento tornar as rotas pelo caminho do vizinho "ativas". O modo normal de UDLD pode amenizar essas circunstâncias, pois detecta a falha de enlace unidirecional e um erro desabilita a porta.

Em conexões roteadas da Camada 3 que usam qualquer protocolo de roteamento, o UDLD normal ainda oferece proteção contra problemas que estão presentes na ativação inicial do enlace, como cabeamento inadequado ou hardware defeituoso. Além disso, o modo assertivo UDLD oferece essas vantagens nas conexões roteadas da Camada 3:

  • Evita o desaparecimento desnecessário de tráfego (com temporizadores mínimos necessários em alguns casos)

  • Coloca um enlace não-sincronizado no estado errdisable

  • Protege contra loops que resultam de configurações EtherChannel da Camada 3

Comportamento padrão de UDLD

O UDLD é desabilitado globalmente e habilitado em prontidão nas portas de fibra por padrão. Devido ao UDLD ser um protocolo de infra-estrutura que é necessário apenas entre os switches, o UDLD é desabilitado por padrão em portas de cobre, que tendem a ser usadas para acesso ao host. Observe que você deve habilitar o UDLD globalmente e no nível da interface, antes que os vizinhos possam atingir o status bidirecional. O intervalo padrão da mensagem é de 15 segundos. Mas, o intervalo padrão da mensagem pode ser mostrado como sete segundos em alguns casos. Consulte o ID de bug da Cisco CSCea70679 (clientes registrados somente) para obter mais informações. O intervalo padrão da mensagem é configurável entre sete e 90 segundos, e o modo assertivo UDLD é desabilitado. O Cisco IOS Software Versão 12.2(25)SEC reduz ainda mais esse temporizador mínimo para um segundo.

Recomendação da Cisco para a Configuração

Na grande maioria dos casos, a Cisco recomenda que você habilite o modo normal de UDLD em todos os enlaces FE/GE ponto a ponto entre os switches Cisco e defina o intervalo de mensagens UDLD como 15 segundos ao usar os cronômetros padrão de árvore de abrangência 802.1D. Além disso, onde as redes dependem do STP para obter redundância e convergência (o que significa que há uma ou mais portas no estado de bloqueio de STP na topologia), use o UDLD em conjunto com os recursos e protocolos apropriados. Esses recursos incluem FEFI, negociação automática, protetor de loop, etc. Normalmente, se a negociação automática estiver habilitada, o modo assertivo não será necessário porque e negociação automática compensa a detecção de falha na Camada 1.

Emita uma destas duas opções de comandos para habilitar o UDLD:

Observação: A sintaxe foi alterada nas várias plataformas/versões.

  •                   udld enable
                      
                         !--- Depois de globalmente habilitadas, todas as portas de fibra FE e GE
    !--- possuem UDLD habilitado por padrão.
                      
                      udld port
                   

    ou

  •                   udld enable
                      
                         !--- As portas de cobre de algumas versões anteriores do Cisco IOS Software
    !--- podem ter o UDLD habilitado por comando de porta individual.
                      
                   

Você deve habilitar manualmente as portas que estão encerradas devido a sintomas de enlace unidirecional. Use um destes métodos:

            udld reset
            
               !--- Redefinir globalmente todas as interfaces que o UDLD encerra.
            
            no udld port
            udld port [aggressive]
            
               !--- Por interface, redefina e reabilite as interfaces que o UDLD encerra.
            
         

Os comandos de configuração global errdisable recovery cause udld e errdisable recovery interval interval podem ser usados para recuperar automaticamente do estado de desabilitado por erro do UDLD.

A Cisco recomenda que você só use o mecanismo de recuperação errdisable na camada de acesso da rede, com cronômetros de recuperação de 20 minutos ou mais, se o acesso físico para o switch estiver difícil. A situação ideal é permitir tempo para a estabilização da rede e a solução de problemas, antes que a porta volte a ficar on-line e cause instabilidade na rede.

A Cisco recomenda que você não use os mecanismos de recuperação no centro da rede, pois isso pode causar instabilidade relacionada a eventos de convergência sempre que for feito backup de um enlace defeituoso. O design redundante de uma rede central fornece um caminho de backup para um enlace defeituoso e permite tempo para uma investigação das razões da falha doUDLD.

Use UDLD Sem Protetor de Loop de STP

Para enlaces ponto a ponto da Camada 3 ou enlaces da Camada 2, em que exista uma topologia de STP sem loop (nenhum bloqueio de portas), a Cisco recomenda que você habilite o UDLD assertivo em links FE/GE ponto a ponto entre os switches Cisco. Nesse caso, o intervalo das mensagens é definido como sete segundos e o STP 802.1D usa cronômetros padrão.

UDLD em EtherChannels

Se o protetor de loop de STP estiver implementado ou não, o modo assertivo UDLD será recomendado para quaisquer configurações EtherChannel, em conjunto com o modo de canal desejável. Em configurações EtherChannel, uma falha no link do canal que transporta os BPDUs da árvore de abrangência e o tráfego de controle do PAgP poderá causar loops imediatos entre os parceiros do canal se os links do canal forem desvinculados. O modo assertivo UDLD encerra uma porta com falha. O PAgP (modo de canal automático/desejável) pode então negociar um novo link de controle e eliminar efetivamente um link com falha do canal.

UDLD with 802.1w Spanning Tree

Para evitar loops ao usar versões mais recentes da árvore de abrangência, use o modo normal do UDLD e o protetor de loop de STP com RSTPs como o 802.1w. O UDLD pode fornecer proteção contra enlaces unidirecionais durante uma fase de linkup, e o protetor de loop de STP pode evitar loops de STP no caso de os enlaces se tornarem unidirecionais depois que o UDLD tiver estabelecido os enlaces como bidirecionais. Como não é possível configurar o UDLD para ficarem abaixo dos cronômetros padrão do 802.1w, o protetor de loop de STP será necessário, a fim de evitar loops em topologias redundantes.

Consulte Compreendendo e Configurando o Recurso UDLD (Unidirectional Link Detection Protocol) para obter mais detalhes.

Teste e Monitore o UDLD

Não é fácil testar o UDLD sem um componente genuinamente defeituoso/unidirecional no laboratório, como o GBIC defeituoso. O protocolo foi designado para detectar os cenários de falha menos comuns que os cenários normalmente empregados no laboratório. Por exemplo, se você executar um teste simples, como desligar um fio de uma fibra para ver o estado desejado desabilitado por erro precisará ter desligado primeiro a negociação automática da Camada 1. Caso contrário, a porta física ficará inativa,o que redefine a comunicação de mensagem UDLD. A extremidade remota se move para o estado indeterminado No modo normal de UDLD e se move para o estado errdisable com o uso do modo assertivo UDLD.

Um método de teste adicional simula a perda do vizinho PDU para UDLD. O método é usar filtros de camada de MAC para bloquear o endereço de hardware de UDLD/CDP enquanto permite que outros endereços passem. Alguns switches não enviam quadros de UDLD quando a porta estiver configurada para ser um destino SPAN (Analisador de Portas Comutadas), o qual simula um vizinho UDLD não responsivo.

Para monitorar o UDLD, use este comando:

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

Além disso, no modo de habilitação de switches do Cisco IOS Software Versão 12.2(18)SXD ou posterior, você pode emitir o comando oculto show udld neighbor para verficiar o conteúdo do cache de UDLD (como faz o CDP). É muito útil comparar o cache de UDLD com o cache do CDP para verificar se existe uma anomalia específica do protocolo. Sempre que o CDP também for afetado, isso geralmente significa que todos os BPDUs/PDUs são afetados. Portanto, verifique também o STP. Por exemplo, verifique alterações de identidade de raiz recentes ou alterações de colocação de raiz/porta designada.

Você pode monitorar o status de UDLD e a consistência de configuração com o uso de variáveis Cisco UDLD SNMP MIB.

Comutação multicamadas

Visão geral

No Cisco IOS System Software, a MLS (comutação multicamadas) é suportada no Catalyst 6500/6000 Series e apenas internamente. Isso significa que o router deve ser instalado no switch. Catalyst 6500/6000 Supervisor Engines mais recentes suportam MLS CEF, nos quais a tabela de roteamento pode ser transferida por download para cada placa. Isso exige hardware adicional, o que inclui a presença de uma DFC (Placa de Encaminhamento Distribuído). As DFCs não são suportadas no software CatOS, mesmo se você optar por usar o Cisco IOS Software na placa do router. As DFCs são suportadas apenas no Cisco IOS System Software.

O cache de MLS que é usado para habilitar as estatísticas de Fluxo de Rede em switches Catalyst é o cache baseado em fluxo que a placa do Supervisor Engine I e os switches legados do Catalyst usam para habilitar a comutação da Camada 3. O MLS é habilitado por padrão no Supervisor Engine 1 (ou Supervisor Engine 1A) com MSFC ou MSFC2. Nenhuma configuração adicional de MLS é necessária para a funcionalidade padrão de MLS. Você pode configurar o cache de MLS em um dos três modos a seguir:

  • destino

  • combinação origem-destino

  • porta de origem-destino

A máscara de fluxo é usada para determinar o modo de MLS do switch. Esses dados são usados subseqüentemente para habilitar os fluxos da Camada 3 nos switches Catalyst provisionados pelo Supervisor Engine IA. As placas do Supervisor Engine II não utilizam o cache de MLS para comutar pacotes, pois essa placa é habilitada por CEF de hardware, o que é uma tecnologia muito mais escalável. O cache de MLS é mantido na placa do Supervisor Engine II para habilitar apenas exportação de estatística do Fluxo da Rede. Portanto, o Supervisor Engine II pode ser habilitado para fluxo total, se for necessário, sem impacto negativo no switch.

Configuração

O tempo de envelhecimento do MLS se aplica a todas as entradas do cache de MLS. O valor do tempo de envelhecimento é aplicado diretamente ao envelhecimento de modo de destino. Você divide o valor do tempo de envelhecimento de MLS por dois para derivar o tempo de envelhecimento do modo de origem para destino. Divida o valor do tempo de envelhecimento de MLS por oito para encontrar o tempo de envelhecimento do fluxo total. O tempo de envelhecimento padrão de MLS é de 256 s.

Você pode configurar o tempo de envelhecimento normal no intervalo de 32 a 4.092 segundos em incrementos de oito segundos. Qualquer valor de tempo de envelhecimento que não seja um múltiplo de oito segundos será ajustado para o múltiplo de 8 s mais próximo. Por exemplo, um valor de 65 será ajustado para 64 e um valor de 127 será ajustado para 128.

Outros eventos podem causar a eliminação de entradas de MLS. Entre eventos incluem:

  • Alterações no roteamento

  • Uma alteração no estado do enlace

    Por exemplo, o enlace PFC está inativo.

Para manter o tamanho do cache de MLS abaixo de 32.000 entradas, habilite estes parâmetros depois de emitir o comando mls aging:

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

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

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

Configuração

Uma entrada de cache típica que é removida é a entrada para fluxos de e para um DNS (Servidor de Nomes de Domínio) ou um servidor TFTP que provavelmente nunca mais será usado depois que a entrada for criada. A detecção e expiração dessas entradas economiza espaço no cache de MLS para o tráfego de outros dados.

Se você precisar habilitar o tempo de envelhecimento rápido do MLS, defina o valor inicial como 128 s. Se o tamanho do cache de MLS cotinuar a crescer acima de 32.000 entradas, diminua a configuração até que o tamanho do cache permaneça abaixo de 32.000. Se o cache continuar a crescer acima de 32.000 entradas, diminua o tempo de envelhecimento normal de MLS.

Configuração Recomendada de MLS pela Cisco

Mantenha o MLS no valor padrão, apenas destino, a menos que a exportação do Fluxo da Rede seja necessária. Se o Fluxo da Rede for necessário, habilite o fluxo total de MLS apenas nos sistemas Supervisor Engine II.

Emite este comando para habilitar o destino do fluxo de MLS:

Switch(config)#mls flow ip destination
         

Frames Jumbo

Unidade Máxima de Transmissão

A MTU (unidade máxima de transmissão) é o maior datagrama ou tamanho de pacote em bytes que uma rede pode enviar ou receber sem a fragmentação do pacote.

Conforme o padrão IEEE 802.3, o tamanho máximo de estrutura de Ethernet é:

  • 1.518 bytes para estruturas regulares (1.500 bytes mais 18 bytes adicionais de cabeçalho de Ethernet e trailer de CRC)

  • 1.522 bytes para estruturas encapsuladas do 802.1Q (1.518 mais 4 bytes de rotulação)

Baby Giant: O recurso Baby Giants permite que o switch passe através/encaminhe pacotes ligeiramente maiores que o IEEE Ethernet MTU, em vez de declarar as estruturas como sendo com excesso de tamanho e descartando-as.

Jumbo: A definição do tamanho da estrutura depende do fornecedor, pois os tamanhos de estruturas não fazem parte do padrão IEEE. As estruturas Jumbo são maiores do que o tamanho da estrutura de Ethernet padrão (que é de 1.518 bytes, o que inclui o cabeçalho da Camada 2 e a FCS [seqüência de verificação de estrutura].

O tamanho padrão da MTU é 9.216 bytes, uma vez que o suporte para jumbo frame foi habilitado na porta individual.

Quando Esperar Pacotes com Mais de 1.518 Bytes

Para transportar tráfego em redes comutadas, assegure-se de que a MTU do tráfego transmitido não exceda a que é suportada nas plataformas de comutação. Há várias razões para que o tamanho da MTU de determinadas estruturas possa ser truncado:

  • Requisitos específicos do fornecedor - Os aplicativos e determinadas NICs (Placas de Interface de Rede) podem especificar um tamanho de MTU fora do padrão de 1.500 bytes. Essa alteração deve-se a estudos que provam que um aumento no tamanho de um estrutura de Ethernet pode aumentar a média de throughput.

  • Entroncamento - Para transportar informações de ID da VLAN entre switches ou outros dispositivos de rede, o entroncamento foi empregado para aumentar a estrutura de Ethernet padrão. Atualmente, as duas formas mais comuns de entroncamento são:

    • Encapsulamento de ISL de proprietário da Cisco

    • 802.1Q

  • MPLS (Multiprotocol Label Switching) - Depois que você habilita o MPLS em uma interface, o MPLS também pode aumentar o tamanho da estrutura de um pacote, dependendo do número de rótulos na pilha de rótulos de um pacote marcado como MPLS. O tamanho total do rótulo é 4 bytes. O tamanho total da pilha de rótulos é.

    n * 4 bytes

    Se uma pilha de rótulos for formada, as estruturas podem exceder a MTU.

  • Tunelamento 802.1Q - Os pacotes de tunelamento 802.1Q contêm duas tags 802.1Q, das quais apenas uma por vez é normalmente visível para o hardware. Portanto, uma tag interna adiciona 4 bytes ao valor do MTU (tamanho de virulência).

  • UTI (Universal Transport Interface)/Layer 2 Tunneling Protocol Versão 3 (Camada 2TPv3) - O UTI/Camada L2TPv3 encapsula dados da Camada 2 a serem encaminhados pela rede IP. O UTI/Camada 2TPv3 pode aumentar o tamanho da estrutura original em até 50 bytes. A nova estrutura inclui um novo cabeçalho de IP (20 bytes), um cabeçalho de Camada 2TPv3 (12 bytes) e um novo cabeçalho da Camada 2. A carga útil da Camada 2TPv3 consiste na estrutura completa da Camada 2, que inclui o cabeçalho da Camada 2.

Finalidade

O switch baseado em hardware de alta velocidade (1 Gbps e 10 Gbps) tornou as estruturas jumbo uma solução muito concreta para problemas de throughput subótimos. Mesmo que não haja nenhum padrão oficial para o tamanho da estrutura jumbo, um valor bastante comum que é normalmente adotado no campo é de 9.216 bytes (9 KB).

Consideração da Eficiência da Rede

Você pode calcular a eficiência da rede para um encaminhamento de pacote se dividir seu payload pela soma do valor de sobrecarga e o tamanho do payload.

Mesmo se o aumento da eficiência de rede com quadros jumbo for modesta e passar de 94,9 por cento (1.500 bytes) para 99,1 por cento (9.216 bytes), a sobrecarga de processamento (utilização da CPU) dos dispositivos de rede nos hosts de extremidade hosts diminuirá proporcionalmente ao tamanho do pacote. Por isso as tecnologias de redes LAN e WAN de alto desempenho tendem a preferir tamanhos máximos de quadros relativamente grandes.

O melhoramento do desempenho só é possível quando são realizadas longas transferências de dados. Os exemplos de aplicativos incluem:

  • Comunicação back-to-back entre servidores (por exemplo, transações de Network File System [NFS])

  • Clusters de servidores

  • Backups de dados de alta velocidade

  • Interconexão de supercomputadores em alta velocidade

  • Transferências de dados de aplicativos gráficos

Consideração de Desempenho de Rede

O desempenho do TCP em WANs (Internet) foi estudado extensivamente. Essa equação explica como o throughput de TCP possui um limite superior baseado em:

  • Maximum Segment Size (MSS), que é o comprimento do MTU menos o comprimento dos cabeçalhos TCP/IP

  • Tempo fixo de round trip (RTT)

  • Perda de pacotes

185-s.gif

De acordo com essa fórmula, o throughput de TCP máximo atingível é diretamente proporcional ao MSS. Isso significa que, com RTT constante e perda de pacotes, é possível duplicar o throughput de TCP se você duplicar o tamanho do pacote. Igualmente, quando você usa quadros jumbo em vez de quadros de 1.518 bytes, um aumento de seis vezes no tamanho pode resultar em um aprimoramento em potencial de seis vezes no throughput de TCP de uma conexão de Ethernet.

Visão Geral Operacional

A especificação do padrão IEEE 802.3 define o tamanho de quadro Ethernet máximo como 1518. Os quadros encapsulados em 802.1Q, com tamanho entre 1.519 e 1.522 bytes, foram adicionados à especificação 802.3 posteriormente por meio do adendo IEEE Std 802.3ac-1998. Às vezes, eles são chamados na literatura técnica de baby giants.

Em geral, os pacotes são classificados como quadros gigantes quando ultrapassam o comprimento máximo de Ethernet especificado para uma conexão de Ethernet específica. Os pacotes gigantes também são conhecidos como quadros jumbo.

O principal ponto de confusão sobre quadros jumbo é a configuração: diferentes interfaces suportam diferentes tamanhos de pacote máximos e, às vezes, tratam pacotes grandes de maneiras ligeiramente diferentes.

Catalyst 6500 Series

Esta tabela tenta resumir os tamanhos de MTU que são suportados atualmente por diferentes placas na plataforma Catalyst 6500:

Placa de Linha

Tamanho de MTU

Padrão

9216 bytes

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

8092 bytes (limitado pelo chip PHY)

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

9100 bytes (a 100 Mbps)

9216 bytes (a 10 Mbps)

WS-X6516-GE-TX

8092 bytes (a 100 Mbps)

9216 bytes (a 10 ou 1000 Mbps)

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

1500 bytes

OSM ATM (OC12c)

9180 bytes

OSM CHOC3, CHOC12, CHOC48 e CT3

9216 bytes (OCx e DS3)

7673 bytes (T1/E1)

FlexWAN

7673 bytes (CT3 T1/DS0)

9216 bytes (OC3c POS)

7673 bytes (T1)

WS-X6148-GE-TX e WS-X6548-GE-TX

Sem suporte

Consulte Configurando Ethernet, Fast Ethernet, Gigabit Ethernet, e 10-Gigabit Ethernet Switching para obter mais informações.

Suporte a Jumbo na Camada 2 e na Camada 3 no Catalyst 6500/6000 Cisco IOS Software

Existe suporte a jumbo na Camada 2 e na Camada 3 com PFC/MSFC1, PFC/MSFC2 e PFC2/MSFC2 em todas as portas GE configuradas como interfaces físicas de Camada 2 e Camada 3. O suporte existe independentemente de essas portas estarem fazendo entroncamento ou canalização. Esse recurso está disponível no Cisco IOS Software Release 12.1(12c)E e posteriores.

  • Os tamanhos de MTU de todas as portas habilitadas para jumbo são vinculados. Uma mudança em um deles afeta todos os outros. Eles sempre mantêm o mesmo tamanho de MTU de quadros jumbo depois de serem habilitados.

  • Durante a configuração, habilite todas as portas na mesma VLAN como habilitadas para jumbo ou não habilite nenhuma delas como habilitada para jumbo.

  • O tamanho de MTU da interface virtual comutada (SVI) (interface VLAN) é definido separadamente da MTU das portas físicas. Uma alteração na MTU das portas físicas não altera o tamanho de MTU da SVI. Além disso, uma alteração na MTU da SVI não afeta a MTU das portas físicas.

  • O suporte a quadros jumbo na Camada 2 e na Camada 3 nas interfaces FE começou no Cisco IOS Software Release 12.1(8a) EX01. O comando mtu 1500 desabilita o jumbo na FE e o comando mtu 9216 habilita o jumbo na FE. Consulte o ID de bug da Cisco CSCdv90450 (clientes registrados somente) .

  • Os quadros jumbo da Camada 3 em interfaces VLAN são suportados apenas em:

    • PFC/MSFC2 (Cisco IOS Software Release 12.1(7a)E e posteriores)

    • PFC2/MSFC2 (Cisco IOS Software Release 12.1(8a)E4 e posteriores)

  • Não é recomendado usar quadros jumbo com PFC/MSFC1 para interfaces VLAN (SVIs) porque a MSFC1 talvez não consiga processar a fragmentação como desejado.

  • Nenhuma fragmentação é suportada para pacotes dentro da mesma VLAN (jumbo da Camada 2).

  • Os pacotes que precisam de fragmentação entre VLANs/sub-redes (jumbo da Camada 3) são enviados para o software para fragmentação.

Compreenda o Suporte a Quadros Jumbo no Catalyst 6500/6000 Cisco IOS Software

Um quadro jumbo é maior do que o tamanho de quadro Ethernet padrão. Para habilitar o suporte a quadros jumbo, você configura um tamanho de MTU maior do que o padrão em uma porta ou interface VLAN e, com o Cisco IOS Software Release 12.1(13)E e posteriores, configura o tamanho de MTU da porta LAN global.

Verificação de Tamanho de Tráfego Roteado e de Ponte no Cisco IOS Software

Placa de Linha

Ingresso

Egresso

Portas de 10, 10/100, 100 Mbps

A verificação de tamanho de MTU está concluída.

O suporte a quadros jumbo compara o tamanho de tráfego de ingresso ao tamanho de MTU de porta LAN global nas portas LAN de ingresso de 10, 10/100 e 100 Mbps Ethernet e 10 GE que têm um tamanho de MTU não-padrão configurado. A porta descarta tráfego que seja de tamanho superior.

A verificação de tamanho de MTU não está concluída.

As portas configuradas com um tamanho de MTU não-padrão transmitem quadros que contêm pacotes de qualquer tamanho maior do que 64 bytes. Com um tamanho de MTU não padrão, as portas LAN Ethernet de 10, 10/100 e 100 Mbps não verificam quadros de ingresso de tamanho superior.

Portas GE

A verificação de tamanho de MTU não está concluída.

As portas configuradas com um tamanho de MTU não-padrão aceitam quadros que contêm pacotes de qualquer tamanho maior do que 64 bytes e não verificam quadros de ingresso de tamanho superior.

A verificação de tamanho de MTU está concluída.

O suporte a quadros jumbo compara o tamanho de tráfego de egresso ao tamanho de MTU de porta LAN de egresso global nas portas LAN GE e 10 GE que têm um tamanho de MTU não-padrão configurado. A porta descarta tráfego que seja de tamanho superior.

Portas 10 GE

A verificação de tamanho de MTU está concluída.

A porta descarta tráfego que seja de tamanho superior.

A verificação de tamanho de MTU está concluída.

A porta descarta tráfego que seja de tamanho superior.

SVI

A verificação de tamanho de MTU não está concluída.

A SVI não verifica o tamanho de quadros no lado de ingresso.

A verificação de tamanho de MTU está concluída.

O tamanho de MTU é verificado no lado de egresso da SVI.

 

PFC

Todo o tráfego roteado

Para tráfego que deva ser roteado, o suporte a quadros jumbo no PFC compara tamanhos de tráfego aos tamanhos de MTU configurado e fornece switching da Camada 3 para tráfego jumbo entre interfaces configuradas com tamanho de MTU grandes o suficiente para acomodar o tráfego.

Entre interfaces não configuradas com tamanhos de MTU grandes o suficiente:

  • Se o bit Don't Fragment (DF) não estiver definido, a PFC enviará o tráfego para a MSFC a fim de ser fragmentado e roteado no software.

  • Se o bit DF estiver definido, a PFC descartará o tráfego.

Recomendações da Cisco

Se estiverem implementados corretamente, os quadros jumbo poderão fornecer um aperfeiçoamento potencial de 6 vezes no throughput de TCP de uma conexão Ethernet, com sobrecarga de fragmentação reduzida (além de menor sobrecarga de CPU em dispositivos de extremidade).

Você deve se certificar de que não há nenhum dispositivo no meio que não possa processar o tamanho de MTU especificado. Se esse dispositivo fragmentar e encaminhar os pacotes, ele anulará todo o processo. Isso poderá resultar em maior sobrecarga no dispositivo para fragmentação e remontagem de pacotes.

Em tais casos, a descoberta de MTU do caminho IP ajuda os remetentes a encontrar o tamanho de pacote mínimo comum adequado para transmitir tráfego ao longo de cada caminho. Como alternativa, você pode configurar dispositivos hosts cientes dos quadros jumbo com um tamanho de MTU que seja o mínimo de todos os suportados na rede.

Você deve verificar cuidadosamente cada dispositivo para garantir que eles possam suportar o tamanho de MTU. Consulte a tabela de tamanho de MTU nesta seção.

O suporte para quadros jumbo pode ser habilitado nestes tipos de interface:

  • Interface de canal de porta

  • SVI

  • Interface física (Camada 2/Camada 3)

Você pode habilitar quadros jumbo no canal de porta ou nas interfaces físicas que participam do canal de porta. É muito importante ter certeza de que a MTU em todas as interfaces físicas seja a mesma. Caso contrário, o resultado poderá ser uma interface suspensa. Você deve alterar a MTU de uma interface de canal de porta porque ela altera a MTU de todas as portas membro.

Observação: Se a MTU de uma porta membro não puder ser alterada para o novo valor por ser a porta de bloqueio, o canal de porta será suspenso.

Sempre certifique-se de que todas as interfaces físicas em uma VLAN estejam configuradas para quadros jumbo antes de configurar o suporte a quadros jumbo em uma SVI. A MTU de um pacote não é verificada no lado de ingresso de uma SVI. Porém, o tamanho de MTU é verificado no lado de egresso de uma SVI. Se a MTU do pacote for maior do que a MTU da SVI de egresso, o pacote será fragmentado por software (se o bit DF não estiver definido), o que resulta em desempenho fraco. A fragmentação de software só ocorre para switching da Camada 3. Quando um pacote é encaminhado para uma porta da Camada 3 ou uma SVI com uma MTU menor, ocorre a fragmentação de software.

A MTU de uma SVI precisa sempre ser menor do que a menor MTU entre todas as portas do switch na VLAN.

Catalyst 4500 Series

Os quadros jumbo são suportados principalmente nas blocas não bloqueadoras das placas de linha do Catalyst 4500. Essas portas GE não bloqueadoras têm conexão direta com a estrutura de switching do Supervisor Engine e suporta quadros jumbo:

  • Supervisor Engines

    • WS-X4515, WS-X4516 — Duas portas GBIC de uplink no Supervisor Engine IV ou V

    • WS-X4516-10GE — Dois uplinks 10-GE e os quatro uplinks SFP 1-GE

    • WS-X4013+ — Dois uplinks 1-GE

    • WS-X4013+10GE — Dois uplinks 10-GE e os quatro uplinks SFP 1-GE

    • WS-X4013+TS — 20 portas 1-GE

  • Placas de linha

    • WS-X4306-GB — Módulo GE 1000BASE-X (GBIC) com seis portas

    • WS-X4506-GB-T — SFP com seis portas e 10/100/1000 Mbps com seis portas

    • WS-X4302-GB — Módulo GE 1000BASE-X (GBIC) com duas portas

    • As duas primeiras portas GBIC de um módulo GE de switching de servidor de 18 portas (WS-X4418-GB) e portas GBIC do módulo WS-X4232-GB-RJ

  • Switches de configuração fixa

    • WS-C4948 — Todas as 48 portas 1-GE

    • WS-C4948-10GE — Todas as 48 portas 1-GE e duas portas 10-GE

Você pode usar essas portas GE não bloqueadoras para suportar quadros de 9 KB ou compressão de broadcast por hardware (apenas Supervisor Engine IV). Todas as outras placas de linha suportam quadros baby giant. Você pode usar baby giants para criar pontes de MPLS ou para passthrough Q in Q com um payload máximo de 1.552 bytes.

Observação: O tamanho de quadro aumenta com tags ISL/802.1Q.

Os quadros baby giants e jumbo são transparentes para outros recursos do Cisco IOS com Supervisor Engines IV e V.

Recursos de Segurança do Cisco IOS Software

Recursos Básicos de Segurança

Em certa época, a segurança era freqüentemente secundária em desenhos de campus. Porém, agora a segurança é uma parte essencial de toda rede corporativa. Normalmente, o cliente já estabeleceu uma política de segurança para ajudar a definir quais ferramentas e tecnologias da Cisco se aplicam. Consulte ISP Cisco Essencial leavingcisco.com para obter mais informações sobre os fundamentos do Cisco IOS Software, que incluem a segurança do Cisco IOS Software.

Proteção de Senha Básica

A maioria dos dispositivos com Cisco IOS Software são configurados com dois níveis de senhas. O primeiro nível é para acesso de Telnet ao dispositivo, que também é conhecido como acesso de vty. Depois que o acesso de vty é concedido, você deve obter acesso para modo habilitado ou modo exec privilegiado.

Proteger o Modo Habilitado do Switch

A senha habilitada permite que um usuário obtenha acesso completo ao dispositivo. Forneça a senha habilitada somente a pessoas confiáveis.

Switch(config)#enable secret password
            
         

Certifique-se de que a senha obedeça a estas regras:

  • A senha deve conter entre um e 25 caracteres alfanuméricos em maiúsculas e minúsculas.

  • A senha não deve conter um número como primeiro caractere.

  • Você pode usar espaços no início, mas eles serão ignorados. Os espaços intermediários e no fim são reconhecidos.

  • A verificação de senha faz distinção entre maiúsculas e minúsculas. Por exemplo, a senha Segredo é diferente da senha segredo.

Observação: O comando enable secret usa uma função de hashing Message Digest 5 (MD5) criptográfica unidirecional. Se você executar o comando show running-config, poderá ver a senha criptografada. O uso do comando enable password é outra maneira de definir a senha habilitada. Porém, o algoritmo de criptografia usado com o comando enable password é fraco e pode ser facilmente revertido para se obter a senha. Portanto, não use o comando enable password. Use o comando enable secret para obter melhor segurança. Consulte Fatos sobre Criptografia de Senha do Cisco IOS para obter mais informações.

Acesso Telnet/VTY Seguro ao Switch

Por padrão, o Cisco IOS Software suporta cinco sessões Telnet ativas. Essas sessões são chamadas de vty 0 a 4. Você pode habilitar essas linhas para acesso. Porém, para habilitar o logon, você também precisa definir a senha para essas linhas.

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

O comando login configura essas linhas para acesso de Telnet. O comando password configura uma senha. Certifique-se de que a senha obedeça a estas regras:

  • O primeiro caractere não deve conter um número.

  • A série pode conter todos os caracteres alfanuméricos, até 80 caracteres. Isso inclui espaços.

  • Você não pode especificar a senha no formato número-espaço-caractere. O espaço após o número causa problemas. Por exemplo, bomdia 21 é uma senha válida, mas 21 bom dia não é.

  • A verificação de senha faz distinção entre maiúsculas e minúsculas. Por exemplo, a senha Segredo é diferente da senha segredo.

Observação: Com essa configuração de linha vty, o switch armazena a senha em texto sem puro. Se alguém executar o comando show running-config, essa senha será vista. Para evitar essa situação, utilize o comando service password-encryption. Ele criptografa livremente a senha. O comando só criptografa a senha da linha vty e a senha habilitada configurada com o comando enable password. A senha habilitada configurada cm o comando enable secret usa uma criptografia mais forte. A configuração com o comando enable secret é o método recomendado.

Observação: Para ter mais flexibilidade no gerenciamento de segurança, certifique-se de que todos os dispositivos Cisco IOS Software implementam o modelo de segurança autenticação, autorização e contabilidade (AAA - authentication, authorization, and accounting). O AAA pode usar bancos de dados locais, RADIUS e TACACS+. Consulte a seção Configuração de Autenticação TACACS+ para obter mais informações.

Altere a frase acima para como era antes.

Serviços de Segurança AAA

Visão Geral Operacional do AAA

O controle de acesso controla quem tem permissão para acessar o switch e que serviços esses usuários podem usar. Os serviços de segurança de rede AAA fornecem a estrutura principal para configurar o controle de acesso no switch.

Esta seção descreve os diversos aspectos do AAA em detalhes:

  • Autenticação — Este processo valida a suposta identidade de um usuário final ou dispositivo. Primeiramente, são especificados os diversos métodos que podem ser usados para autenticar o usuário. Esses métodos definem o tipo de autenticação a ser realizada (por exemplo, TACACS+ ou RADIUS). A seqüência de tentativa desses métodos de autenticação também é definida. Os métodos são então aplicados às interfaces adequadas, o que ativa a autenticação.

  • Autorização — Este processo concede direitos de acesso a um usuário, a grupos de usuários, a sistemas ou a processos. O processo AAA é capaz de realizar autorização única ou autorização com base em tarefas. O processo define atributos (no servidor AAA) em que o usuário tem permissão para executar. Sempre que o usuário tenta iniciar um serviço, o switch consulta o servidor AAA e solicita permissão para autorizar o usuário. Se o servidor AAA aprovar, o usuário será autorizado. Se o servidor AAA não aprovar, o usuário não obterá permissão para executar o serviço. Você pode usar este processo para especificar que alguns usuários só podem executar determinados comandos.

  • Contabilidade — Este processo permite controlar os serviços que os usuários acessam e a quantidade de recursos da rede que estão consumindo. Quando a contabilidade está habilitada, o switch relata as atividades do usuário para o servidor AAA na forma de registros de contabilidade. Os exemplos de atividades do usuário relatadas incluem o tempo de sessão e as horas de início e de fim. Em seguida, a análise dessas atividades é feita para propósitos de gerenciamento e cobrança.

Embora o AAA seja o método principal e recomendado de controle de acesso, o Cisco IOS Software fornece recursos adicionais para controle de acesso simples que estão fora do escopo do AAA. Esses recursos adicionais incluem:

  • Autenticação de nome de usuário local

  • Autenticação de senha simples de linha

  • Autenticação de senha habilitada

Mas esses recursos não fornecem o mesmo grau de controle de acesso possível com o AAA.

Para compreender melhor o AAA, consulte estes documentos:

Esses documentos não necessariamente mencionam switches. Porém, os conceitos de AAA que os documentos descrevem se aplicam a switches.

TACACS+

Finalidade

Por padrão, senhas de modos privilegiado e não privilegiado são globais. Essas senhas se aplicam a cada usuário que acessa o switch ou router, seja pela porta console ou por meio de uma sessão Telnet pela rede. A implementação dessas senhas nos dispositivos de rede consome tempo e não é centralizada. Além disso, você pode ter dificuldade com a implementação de restrições de acesso com o uso de listas de controle de acesso (ACLs) que podem estar sujeitas a erros de configuração. Para contornar esses problemas, siga uma abordagem centralizada quando configurar nomes de usuários, senhas e políticas de acesso em um servidor central. Este servidor pode ser o Cisco Secure Access Control Server (ACS) ou qualquer software de terceiros. Os dispositivos são configurados para usar esses bancos de dados centralizados para funções de AAA. Neste caso, os dispositivos são switches com Cisco IOS Software. O protocolo usado entre os dispositivos e o servidor central podem ser:

  • TACACS+

  • RADIUS

  • Kerberos

O TACACS+ é uma implementação comum em redes Cisco e é o foco desta seção. O TACACS+ fornece estes recursos:

  • Autenticação — O processo que identifica e verifica um usuário. Diversos métodos podem ser usados para autenticar um usuário. Mas o método mais importante inclui uma combinação de nome de usuário e senha.

  • Autorização — Quando o usuário tenta executar um comando, o switch pode consultar o servidor TACACS+ para determinar se o usuário tem permissão concedida para utilizar tal comando.

  • Contabilidade — O processo registra o que um usuário está fazendo ou fez no dispositivo.

Consulte Comparação entre TACACS+ e RADIUS para obter uma comparação entre o TACACS+ e o RADIUS.

Visão Geral Operacional

O protocolo TACACS+ encaminha nomes de usuários e senhas para o servidor centralizado. As informações são criptografadas na rede com hash unidirecional MD5. Para obter mais informações, consulte RFC 1321 leavingcisco.com. O TACACS+ utiliza a porta TCP 49 como protocolo de transporte, o que oferece estas vantagens sobre o UDP:

Observação: O RADIUS usa UDP.

  • Transporte orientado por conexão

  • Reconhecimento separado de que um pedido foi recebido (TCP ACK), independentemente do quanto está carregado o mecanismo de autenticação de backend

  • Indicação imediata de um travamento de servidor (pacotes RST)

Durante uma sessão, se for necessária verificação de autorização adicional, o switch verifica com TACACS+ para determinar se o usuário tem permissão concedida para utilizar um determinado comando. Essa etapa melhora o controle sobre os comandos que podem ser executados no switch e permite o desacoplamento do mecanismo de autenticação. Com o uso do comando de contabilidade, você pode auditar os comandos que um determinado usuário executou enquanto estava conectado a um dispositivo de rede em particular.

O diagrama mostra o processo de autorização envolvido:

185-d.gif

Quando um usuário se autentica em um dispositivo de rede com TACACS+ em uma tentativa de logon ASCII simples, este processo geralmente ocorre:

  • Quando a conexão é estabelecida, o switch contacta o daemon TACACS+ para obter um prompt de nome de usuário. O switch é então exibe o prompt para o usuário. O usuário insere o nome de usuário, e o switch contacta o daemon TACACS+ para obter um alerta de senha. O switch exibe o prompt de senha ao usuário, que então insere uma senha que também é enviada ao daemon TACACS+.

  • O dispositivo de rede eventualmente recebe uma dessas respostas do daemon TACACS+:

    • ACCEPT— O usuário é autenticado e o serviço pode começar. Se o dispositivo de rede está configurado para exigir autorização, a autorização inicia nesse momento.

    • REJECT— O usuário falhou na autenticação. Poderá ser negado acesso ao usuário, ou ele será solicitado a tentar novamente a seqüência de logon. O resultado depende do daemon TACACS+.

    • ERROR— Ocorreu um erro em algum momento durante a autenticação. O erro pode ser no daemon ou na conexão de rede entre o daemon e o switch. Se um erro ERROR de resposta for recebido, o dispositivo de rede normalmente tentará utilizar um método alternativo para autenticar o usuário.

    • CONTINUE— O usuário é solicitado a fornecer informações de autenticação adicionais.

  • Os usuários devem primeiro completar com sucesso a autenticação TACACS+ antes de continuar a autorização TACACS+.

  • Se a autorização TACACS+ for necessária, o daemon TACACS+ será contatado novamente. O daemon TACACS+ retorna uma resposta de autorização ACCEPT ou REJECT . Se um erro ACCEPT for retornado como resposta, a resposta conterá dados na forma de atributos que serão usados para direcionar a sessão EXEC ou NETWORK do usuário. Isso determina quais comandos o usuário pode acessar.

Etapas de Configuração AAA Básicas

A configuração de AAA é relativamente simples depois que você compreende o processo básico. Para configurar a segurança em um servidor de acesso ou router Cisco com uso de AAA, siga estas etapas:

  1. Para habilitar o AAA, execute o comando de configuração global aaa new-model.

    Switch(config)#aaa new-model
                   

    Dica: Salve a configuração antes de configurar os comandos AAA. Salve a configuração novamente somente após ter concluído todas as configurações do AAA e estar certo de que a configuração funciona corretamente. Em seguida, você poderá recarregar o switch para recuperar os bloqueios imprevistos (antes de salvar a configuração), se necessário.

  2. Se decidir usar um servidor de segurança separado, os parâmetros do protocolo de segurança, como RADIUS, TACACS+ ou Kerberos.

  3. Use o comando aaa authentication para definir as listas de métodos de autenticação.

  4. Use o comando login authentication para aplicar as listas de métodos a uma determinada interface ou linha.

  5. Execute o comando opcional aaa authorization para configurar a autorização.

  6. Execute o comando opcional aaa authorization para configurar a contabilidade.

  7. Configure o servidor externo AAA para processar as solicitações de autenticação e de autorização do switch.

    Observação:  Consulte a documentação do servidor AAA para obter mais informações.

Configuração de Autenticação TACACS+

Siga estas setas etapas para configurar a autenticação TACACS+:

  1. Execute o comando de configuração global aaa new-model para habilitar o AAA no switch.

  2. Defina o servidor TACACS+ e a chave associada.

    Essa chave é usada para criptografar o tráfego entre o servidor TACACS+ e o switch. No comando tacacs-server host 1.1.1.1 key mysecretkey o servidor TACACS+ está no endereço IP 1.1.1.1 e a chave de criptografia é mysecretkey. Para verificar se o switch pode alcançar o servidor TACACS+, inicie um ping de Internet Control Message Protocol (ICMP) pelo switch.

  3. Defina uma lista de métodos.

    Uma lista de métodos define a seqüência de mecanismos de autenticação a serem tentados para diversos serviços. Os diversos serviços podem ser, por exemplo:

    • Habilitar

    • Logon (para acesso vty/Telnet)

      Observação: Consulte a seção Recursos Básicos de Segurança deste documento para obter informações sobre o acesso vty/Telnet.

    • Console

    Este exemplo considera apenas logon. Aplique a lista de métodos às interfaces/linha:

    Switch(config)#aaa authentication login METHOD-LIST-LOGIN group tacacs+ line
    Switch(config)#line vty 0 4
    Switch(config-line)#login authentication METHOD-LIST-LOGIN
    Switch(config-line)#password hard_to_guess
                      
                   

    Nesta configuração, o aaa authentication login comando usa o nome de lista fictícia METHOD-LIST-LOGIN e usa o método tacacs+ antes de usar o método linha. Os usuários são autenticados com uso do servidor TACACS+ (o primeiro método). Se o servidor TACACS+ não responder ou enviar uma mensagem de erro, a senha configurada na linha será usada como segundo método. Mas se o servidor TACACS+ negar o usuário e responder com uma mensagem REJECT, o AAA considerará a transação bem-sucedida e não usará o segundo método.

    Observação: A configuração só estará completa depois que você aplicar a lista (METHOD-LIST-LOGIN) à linha vty. Execute o comando login authentication METHOD-LIST-LOGIN no modo de configuração de linha, como mostra o exemplo.

    Observação: O exemplo cria uma porta dos fundos quando o servidor TACACS+ não está disponível. Os administradores de segurança podem ou não podem implementar uma porta dos fundos. Certifique-se de que a decisão de implementar tais portas dos fundos esteja de acordo com as políticas de segurança do local.

Configuração de Autenticação RADIUS

A configuração RADIUS é praticamente idêntica à configuração TACACS+. Basta substituir a palavra RADIUS por TACACS na configuração. Este é um exemplo de configuração RADIUS para acesso à porta COM:

Switch(config)#aaa new-model
Switch(config)#radius-server host 1.1.1.1 key mysecretkey
Switch(config)#aaa authentication login METHOD-LIST-LOGIN group radius line
Switch(config)#line con 0
Switch(config-line)#login authentication METHOD-LIST-LOGIN
Switch(config-line)#password hard_to_guess
            
         

Banners de Login

Crie banners de dispositivos apropriados que relatem especificamente as ações realizadas por acessos não-autorizados. Não anuncie o nome de site ou dados de rede a usuários não autorizados. Os banners fornecem recursos no caso de um dispositivo estar comprometido e o perpetrador for pego. Execute este comando para criar banners de logon:

Switch(config)#banner motd ^C
*** Unauthorized Access Prohibited ***
^C

Segurança Física

Certifique-se de que a autorização adequada seja necessária para acessar fisicamente os dispositivos. Mantenha o equipamento em um espaço controlado (trancado). Para garantir que a rede permaneça operacional e não afetada por interferências mal-intencionadas ou fatores ambientais, certifique-se de que o equipamento tenha:

  • Uma fonte de alimentação ininterrupta (UPS) com fontes redundantes onde for possível

  • Controle de temperatura (ar condicionado)

Lembre-se de que, se uma pessoa mal-intencionada violar o acesso físico, será muito mais provável a interrupção via recuperação de senha ou outros métodos.

Configuração de Gerenciamento

Diagramas de Rede

Finalidade

Os diagramas de rede claros compõem uma parte fundamental das operações de rede. Os diagramas tornam-se críticos durante a solução de problemas e são o veículo mais importante para comunicar informações a fornecedores e parceiros durante uma interrupção. Não subestime a preparação, a prontidão e a acessibilidade que os diagramas de rede fornecem.

Recomendação

Estes três tipos de diagramas de rede são necessários:

  • Diagrama Total — Mesmo nas maiores redes, um diagrama que exibe a conectividade lógica e física de extremidade a extremidade é importante. Freqüentemente, as empresas que implementaram um desenho hierárquico documentam cada camada separadamente. Quando você planeja e soluciona problemas, o que importa é um bom conhecimento de como os domínios se ligam.

  • Diagrama Físico — Este diagrama mostra todo o hardware e cabeamento de switches e routers. Certifique-se de que o diagrama rotule cada um destes aspectos:

    • Troncos

    • Links

    • Velocidades

    • Grupos de canais

    • Números de porta

    • Slots

    • Tipos de chassi

    • Software

    • Domínios VTP

    • Ponte raiz

    • Prioridade de backup de ponte raiz

    • Endereço MAC

    • Portas bloqueadas por VLAN

    Para maior clareza, ilustre dispositivos internos, como o router MSFC Catalyst 6500/6000 como um router em cabo conectado por meio de um tronco.

  • Diagrama Lógico — Este diagrama mostra somente a funcionalidade da Camada 3, o que significa que ele mostra routers como objetos e VLANs como segmentos de Ethernet. Certifique-se de que o diagrama rotule estes aspectos:

    • Endereços IP

    • Sub-redes

    • Endereçamento secundário

    • HSRP ativo e standby

    • Camadas de acesso núcleo-distribuição

    • Informações de roteamento

185-e.gif

Interface de Gerenciamento de Switch e VLAN Nativa

Finalidade

Esta seção descreve o significado e os possíveis problemas do uso da VLAN 1 padrão. Além disso, ela aborda os possíveis problemas da execução do tráfego de gerenciamento para o switch na mesma VLAN do tráfego de usuário em switches de série 6500/6000.

Os processadores de Supervisor Engines e MSFCs do Catalyst 6500/6000 Series usam a VLAN 1 para vários protocolos de gerenciamento e de controle. Alguns exemplos:

  • Protocolos de controle de switch:

    • BPDUs do STP

    • VTP

    • DTP

    • CDP

  • Protocolos de gerenciamento:

    • SNMP

    • Telnet

    • Secure Shell Protocol (SSH)

    • Syslog

Quando a VLAN é usada dessa maneira, ela é chamada de VLAN nativa. A configuração de switch padrão define a VLAN 1 como a VLAN nativa padrão nas portas de tronco Catalyst. Você pode manter a VLAN 1 como a VLAN padrão. No entanto, lembre-se de que, por padrão, os switches que executam o Cisco IOS Software na rede definem como portas de acesso na VLAN 1 todas as interfaces configuradas como portas de switch de Camada 2. É provável que um switch de algum local da rede use a VLAN 1 como uma VLAN para tráfego de usuário.

A maior preocupação sobre o uso da VLAN 1 é que, em geral, o Supervisor Engine NMP não precisa ser interrompido pela maioria do tráfego multicast e broadcast gerado pelas estações finais. Aplicativos multicast em particular tendem a enviar muitos dados entre servidores e clientes. O Supervisor Engine não precisa ver esses dados. Se os recursos ou os buffers do Supervisor Engine estiverem completamente ocupados enquanto o Supervisor Engine escuta tráfego desnecessário, é possível que o Supervisor Engine não perceba os pacotes de gerenciamento que causam loop de árvore de abrangência ou falha no EtherChannel (no pior cenário).

Os comandos show interfaces interface_type slot/port counters e show ip traffic podem fornecer alguma indicação sobre:

  • A proporção entre tráfego broadcast e unicast

  • A proporção entre tráfego IP e não-IP (que geralmente não é visto em VLANs de gerenciamento)

A VLAN 1 marca e processa a maior parte do tráfego de plano de controle. Por padrão, a VLAN 1 está habilitada em todos os troncos. Com redes de campus maiores, é preciso ter cuidado com o diâmetro do domínio STP da VLAN 1. Se houver instabilidade em uma parte da rede, a VLAN 1 poderá ser afetada e a estabilidade do plano de controle e do STP de todas as outras VLANs poderá ser influenciada. Você pode limitar a transmissão de dados de usuário da VLAN 1 e a operação do STP em uma interface. Basta não configurar a VLAN na interface de tronco.

Essa configuração não impede a transmissão de pacotes de controle de switch para switch na VLAN 1, conforme visto com um analisador de rede. Porém, nenhum dado é encaminhado e o STP não é executado nesse link. Portanto, você pode usar essa técnica para quebrar a VLAN 1 em domínios de falha menores.

Observação: Você não pode eliminar da VLAN 1 troncos para o Catalyst 2900XL/3500XLs.

Mesmo se você tiver o cuidado de restringir as VLANs de usuário para domínios de switch relativamente pequenos e limites de L3/falhas igualmente pequenos, alguns clientes ainda tentarão tratar o gerenciamento de VLAN de forma diferente. Esses clientes tentam cobrir a rede inteira com uma única sub-rede de gerenciamento. Não há motivo técnico para que um aplicativo NMS central deva ser de Camada 2 adjacente em relação aos dispositivos que gerencia; tampouco esse é um argumento de segurança qualificado. Limite o diâmetro das VLANs de gerenciamento para a mesma estrutura de domínio roteada da estrutura de VLANs de usuário. Considere gerenciamento fora de banda e/ou suporte a SSH como forma de melhorar a segurança do gerenciamento de rede.

Outras Opções

Há considerações de desenho para essas recomendações da Cisco em algumas topologias. Por exemplo, um desenho multicamada comum e desejável da Cisco é um desenho que evita o uso de uma árvore de abrangência ativa. Dessa forma, o desenho requer a restrição de cada sub-rede IP/VLAN para um switch (ou cluster de switches) com uma única camada de acesso. Nesses desenhos, nenhum entroncamento pode ser configurado para a camada de acesso.

É preciso criar uma VLAN de gerenciamento separada e habilitar truncamento para transmitir entre as camadas de acesso da Camada 2 e de distribuição da Camada 3? Não há resposta fácil para essa pergunta. Considere estas duas opções de revisão de desenho com o engenheiro da Cisco:

  • Opção 1 — Realize o entroncamento de duas ou três VLANs exclusivas da camada de distribuição até cada switch da camada de acesso. Essa configuração permite uma VLAN de dados, uma VLAN de voz e uma VLAN de gerenciamento, e ainda oferece o benefício de STP inativo. É necessário executar uma etapa extra de configuração para eliminar entroncamentos da VLAN 1. Nessa solução, também existem pontos de desenho a serem considerados para que seja possível evitar temporariamente o buraco negro de tráfego roteado durante a recuperação de falha. Use STP PortFast em troncos (no futuro) ou sincronização de autostate VLAN com encaminhamento de STP.

  • Opção 2 — Uma VLAN única para dados e gerenciamento pode ser aceitável. Se você desejar manter a interface sc0 separada dos dados de usuário, um novo hardware de switch tornará o cenário menos problemático. O novo hardware fornece:

    • CPUs mais avançadas e controles de limitação de taxa de control-plane

    • Um desenho com domínios de broadcast relativamente pequenos como defendidos pelo desenho multilayer

    Para tomar a decisão final, examine o perfil de tráfego de broadcast da VLAN e consulte o engenheiro da Cisco sobre os recursos do hardware de switch. Se o gerenciamento de VLAN contiver todos os usuários desse switch de camada de acesso, use filtros de entrada IP para proteger o switch contra usuários, conforme abordado na seção Recursos de Segurança do Cisco IOS Software.

Interface de Gerenciamento da Cisco e Recomendações sobre a VLAN Nativa

Interface de Gerenciamento

O Cisco IOS Software oferece a você a opção de configurar interfaces como interfaces de Camada 3 ou portas de switch de Camada 2 em uma VLAN. Quando você usar o comando switchport no Cisco IOS Software, todas as portas de switch serão, por padrão, portas de acesso na VLAN 1. Portanto, a menos que você defina outra configuração, os dados de usuário também poderão existir por padrão na VLAN 1.

Transforme a VLAN de gerenciamento em uma VLAN que não seja a VLAN 1. Mantenha todos os dados de usuário fora da VLAN de gerenciamento. Em vez disso, configure uma interface loopback0 como a interface de gerenciamento de cada switch.

Observação: Se você usar o protocolo OSPF, ele também se tornará a ID do router do OSPF.

Certifique-se de que a interface loopback possua uma máscara de sub-rede de 32 bits e configure a interface loopback como uma interface pura de Camada 3 no switch. Exemplo:

Switch(config)#interface loopback 0
Switch(config-if)#ip address 10.x.x.x 255.255.255.255
Switch(config-if)#end
Switch# 

VLAN Nativo

Configure a VLAN nativa para ser uma VLAN de teste óbvia que nunca será habilitada no router. No passado, a Cisco recomendava a VLAN 999, mas a escolha é totalmente arbitrária.

Execute estes comandos de interface para estabelecer uma VLAN como nativa (padrão) para o entroncamento 802.1Q em uma porta específica:

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

Para obter recomendações adicionais sobre configurações de entroncamento, consulte a seção Dynamic Trunking Protocol neste documento.

Gerenciamento fora de banda

Finalidade

Você poderá tornar o gerenciamento de rede mais disponível se construir uma infra-estrutura de gerenciamento separada ao redor da rede de produção. Essa configuração permite que os dispositivos possam ser acessados de modo remoto, independentemente do tráfego ou dos eventos do control-plane. Essas duas abordagens são típicas:

  • Gerenciamento fora de banda com LAN exclusiva

  • Gerenciamento fora de banda com servidores de terminal

Visão Geral Operacional

Você pode fornecer a cada router e switch da rede uma interface de gerenciamento de Ethernet fora de banda em uma VLAN de gerenciamento. Configure uma porta de Ethernet em cada dispositivo da VLAN de gerenciamento e faça o cabeamento fora da rede de produção para uma rede de gerenciamento comutada separada.

Observação: Os switches Catalyst 4500/4000 possuem uma interface especial me1 no Supervisor Engine que é usada apenas para o gerenciamento fora de banda, e não como uma porta de switch.

Além disso, você poderá obter conectividade do servidor terminal se configurar um router Cisco 2600 ou 3600 com cabos seriais RJ-45 para acessar a porta de console de todos os routers e switches da disposição. O uso de um servidor terminal também evita a necessidade de configurar cenários de backup, como modems em portas auxiliares para cada dispositivo. Você pode configurar um único modem na porta auxiliar do servidor terminal. Essa configuração fornece serviço dialup aos outros dispositivos durante uma falha de conectividade de rede. Consulte Conectando um Modem à Porta do Console em Switches Catalyst para obter mais informações.

Recomendação

Com essa organização, é possível ter dois caminhos fora de banda para cada switch e para cada router, além dos vários caminhos em banda. Essa organização também habilita o gerenciamento de rede altamente disponível. Estes são os benefícios:

  • A organização separa o tráfego de gerenciamento dos dados do usuário.

  • Por motivos de segurança, o endereço IP de gerenciamento fica em uma sub-rede, uma VLAN e um switch separados.

  • Há uma maior garantia para a entrega de dados de gerenciamento durante falhas de rede.

  • Não há árvores de abrangência ativas na VLAN de gerenciamento. A redundância aqui não é crítica.

Este diagrama mostra o gerenciamento fora de banda:

185-f.gif

Registro de sistema

Finalidade

As mensagens do syslog são específicas da Cisco e podem fornecer informações mais precisas e acessíveis do que o SNMP padronizado. Por exemplo, as plataformas de gerenciamento, como o Cisco Resource Manager Essentials (RME) e o kit de ferramentas de gerenciamento de rede (NATkit), potencializam o uso de informações do syslog para coletar alterações de inventário e configuração:

Recomendação de Configuração do Syslog Cisco

O registro do sistema é uma prática operacional comum e amplamente aceita. O syslog UNIX pode capturar e analisar informações/eventos no router. Por exemplo:

  • Status da interface

  • Alertas de segurança

  • Condições ambientais

  • Hog de processo da CPU

  • Outros eventos

O Cisco IOS Software pode fazer registro de UNIX em um servidor syslog UNIX . O formato syslog Cisco UNIX é compatível com 4.3 Berkeley Standard Distribution (BSD) UNIX. Use as configurações de registro do Cisco IOS Software:

  • no logging console — Por padrão, todas as mensagens do sistema são enviadas para o console do sistema. O registro em console é uma tarefa de alta prioridade no Cisco IOS Software. Essa função foi inicialmente desenhada para fornecer mensagens de erro ao operador do sistema antes que ocorressem falhas. Desabilite o registro em console nas configurações de todos os dispositivos para evitar uma situação na qual possa haver falha no router/switch enquanto o dispositivo aguarda uma resposta do terminal. No entanto, as mensagens do console podem ser úteis durante o isolamento de problemas. Nessas instâncias, habilite o registro em console. Execute o comando logging console level para obter o nível desejado de registro de mensagens. Os níveis de registro vão de 0 a 7.

  • no logging monitor — Esse comando desabilita o registro em linhas de terminal que não sejam o console do sistema. Talvez o registro de monitor seja necessário (com o uso de logging monitor debugging ou de outra opção de comando). Nesse caso, habilite o registro de monitor no nível de registro específico exigido pela atividade. Consulte o item no logging console nesta lista para obter mais informações sobre níveis de registro.

  • logging buffered 16384 — O comando logging buffered precisa ser adicionado a mensagens do sistema de registro no buffer de registro interno. O buffer de registro é circular. Depois que o buffer de registro é preenchido, entradas antigas são substituídas por entradas mais recentes. O tamanho do buffer de registro é especificado em bytes e pode ser configurado pelo usuário. Esse tamanho varia de acordo com a plataforma. Na maioria dos casos, 16384 é um bom padrão, que fornece registro adequado.

  • logging trap notifications — Este comando fornece mensagens de nível de notificação (5) para o servidor syslog especificado. O nível de registro padrão de todos os dispositivos (console, monitor, buffer e armadilhas) é de depuração (nível 7). Se você deixar o nível de registro de armadilhas definido como 7, serão produzidas muitas mensagens irrelevantes, que nada ou pouco têm a ver com a integridade da rede. Defina como 5 o nível de registro padrão de armadilhas.

  • logging facility local7 — Esse comando define a facilidade/nível de registro de informações de syslog UNIX. Configure o servidor syslog que recebe essas mensagens com a mesma facilidade/nível.

  • O comando logging host — Esse comando define o endereço IP do servidor de registro UNIX.

  • logging source-interface loopback 0 — Esse comando define o SA IP padrão das mensagens syslog. Codifique o SA de registro para facilitar a identificação do host que enviou a mensagem.

  • service timestamps debug datetime localtime show-timezone msec — Por padrão, as mensagens de registro não possuem registro de data e hora. Você pode usar esse comando para habilitar o registro de data e hora de mensagens de registro e configurar o registro de data e hora de mensagens de depuração do sistema. O registro de data e hora fornece o tempo relativo de eventos registrados e melhora a depuração em tempo real. Essas informações são úteis principalmente quando clientes enviam saída de depuração ao suporte técnico para obter ajuda. Para habilitar o registro de data e hora de mensagens de depuração do sistema, use o comando no modo de configuração global. O comando só tem um efeito quando a depuração é habilitada.

Observação: Além disso, habilite a criação de registros para status de links e de pacotes em todas as interfaces Gigabit da infra-estrutura.

O Cisco IOS Software contém um único mecanismo para definir a facilidade e o nível de registro de todas as mensagens do sistema destinadas a um servidor syslog. Defina o nível de armadilha de registro para notificação (nível 5). Se definir o nível de mensagem de armadilha como notificação, você poderá minimizar o número de mensagens informativas encaminhadas para o servidor syslog. Essa configuração pode diminuir significativamente a quantidade de tráfego de syslog na rede e reduzir o impacto em recursos do servidor syslog.

Adicione estes comandos a cada router e switch que execute o Cisco IOS Software para habilitar mensagens syslog:

  • Comandos de configuração syslog global:

                      no logging console
                      no logging monitor
                      logging buffered 16384
                      logging trap notifications
                      logging facility local7
                      logging host-ip
                      logging source-interface loopback 0
                      service timestamps debug datetime localtime show-timezone msec
                      service timestamps log datetime localtime show-timezone msec
                   
  • Comandos de configuração syslog de interface:

                      logging event link-status
                      logging event bundle-status
                   

SNMP

Finalidade

Você pode usar o SNMP para recuperar estatísticas, contadores e tabelas armazenados em MIBs de dispositivo de rede. NMSs, como o HP OpenView, podem usar informações para:

  • Gerar alertas em tempo real

  • Medir disponibilidade

  • Produzir informação de planejamento de recursos

  • Ajudar a realizar verificações de configuração e de solução de problemas

Operação de interface de gerenciamento SNMP

O SNMP é um protocolo de camada de aplicativo que fornece um formato de mensagem para comunicação entre agentes e gerenciadores de SNMP. O SNMP oferece uma estrutura padronizada e uma linguagem comum para o gerenciamento e a monitoração dos dispositivos de uma rede.

A estrutura SNMP consiste nestas três partes:

  • Um gerenciador de SNMP

  • Um agente de SNMP

  • Um MIB

O gerenciador de SNMP é o sistema que usa o SNMP para controlar e monitorar as atividades de hosts de rede. O sistema de gerenciamento mais comum é chamado de NMS. Você pode aplicar o termo NMS a um dispositivo dedicado usado no gerenciamento de rede ou aos aplicativos usados em um dispositivo desse tipo. Há vários aplicativos de gerenciamento de rede disponíveis para serem usados com o SNMP. Esses aplicativos vão de simples aplicativos CLI a GUIs ricas em recursos, como a linha de produtos CiscoWorks.

O agente SNMP é o componente de software do dispositivo gerenciado que mantém os dados do dispositivo e reporta esses dados, conforme necessário, a sistemas de gerenciamento. O agente e o MIB residem no dispositivo de roteamento (o router, o servidor de acesso ou o switch). Para habilitar o agente SNMP em um dispositivo de roteamento Cisco, defina a relação entre o gerenciador e o agente.

O MIB é uma área virtual de armazenamento de informações de gerenciamento de rede. O MIB consiste em coleções de objetos gerenciados. Dentro do MIB, há coleções de objetos relacionados definidos em módulos MIB. Módulos MIB são escritos na linguagem do módulo MIB de SNMP, como STD 58, RFC 2578 leavingcisco.com, RFC 2579 leavingcisco.com e RFC 2580 leavingcisco.com definem.

Observação: Módulos MIB individuais também são chamados de MIBs. Por exemplo, o MIB de grupo de interfaces (IF-MIB) é um módulo MIB dentro do MIB do seu sistema.

O agente SNMP contém variáveis de MIB, os valores do que o gerenciador SNMP pode solicitar ou alterar por meio de operações get ou set. Um gerenciador pode obter um valor de um agente ou armazenar um valor nesse agente. O agente reúne dados do MIB, que é o repositório de informações sobre parâmetros de dispositivo e dados de rede. O agente também pode responder a solicitações do gerenciador para obter ou definir dados.

O gerenciador pode enviar as solicitações do agente para obter e definir valores de MIB. O agente pode responder a essas solicitações. Independentemente dessa interação, o agente pode enviar notificações não solicitadas (armadilhas ou informes) para informar o gerenciador sobre condições da rede. Com alguns mecanismos de segurança, um NMS pode recuperar informações nos MIBs usando solicitações get e get next, e também podem executar o comando set para alterar parâmetros. Além disso, você pode configurar um dispositivo de rede para gerar uma mensagem de armadilha para o NMS para alertas em tempo real. Portas 161 e 162 UDP IP são usadas para armadilhas.

Visão Geral Operacional de Notificações do SNMP

Um importante recurso do SNMP é a capacidade de gerar notificações de um agente SNMP. Essas notificações não exigem que solicitações sejam enviadas do gerenciador SNMP. Notificações não solicitadas (assíncronas) podem ser geradas como armadilhas ou solicitações de informes. Armadilhas são mensagens que alertam o gerenciador SNMP sobre uma condição na rede. Solicitações de informe (informes) são armadilhas que incluem uma solicitação de confirmação de recebimento do gerenciador SNMP. As notificações podem indicar eventos significativos, como:

  • Autenticação de usuário inadequada

  • Reinicializações

  • O fechamento de uma conexão

  • A perda de conexão com um router vizinho

  • Outros eventos

Armadilhas são menos confiáveis do que informes, pois o receptor não envia nenhuma confirmação quando recebe a armadilha. O remetente não pode determinar se a armadilha foi recebida. Um gerenciador SNMP que recebe uma solicitação de informe confirma o recebimento da mensagem com uma unidade de dados de protocolo de resposta (PDU) SNMP. Se não receber uma solicitação de informe, o gerenciador não enviará uma resposta. Se nunca receber uma resposta, o remetente poderá enviar a solicitação de informe novamente. Informes têm maior probabilidade de alcançar o destino pretendido.

No entanto, as armadilhas são quase sempre preferíveis, pois os informes consumem mais recursos no router e na rede. A armadilha é descartada assim que é enviada. No entanto, a solicitação de informe deve ser mantida na memória até que uma resposta seja recebida ou a solicitação expire. Além disso, as armadilhas são enviadas apenas uma vez, enquanto os informes podem ser enviado várias vezes. As tentativas aumentam o tráfego e contribuem para uma maior sobrecarga da rede. Portanto, as armadilhas e as solicitações de informe fornecem uma troca entre confiabilidade e recursos. Se quiser que o gerenciador SNMP receba todas as notificações, use solicitações de informe. Mas, se tiver problemas em relação ao tráfego de rede ou à memória do router e não precisar receber todas as notificações, use armadilhas.

Estes diagramas ilustram as diferenças entre armadilhas e solicitações de informe:

185-g.gif

Esse diagrama ilustra como o router do agente envia de forma bem-sucedida uma armadilha ao gerenciado SNMP. Embora receba a armadilha, o gerenciador não envia uma confirmação ao agente. O agente não tem como saber que a armadilha atingiu seu destino.

185-h.gif

Esse diagrama ilustra como o router do agente envia de forma bem-sucedida uma informação requisitada para o gerenciador. Quando o gerenciador recebe uma informação requisitada, o gerenciador envia uma resposta ao agente. Dessa forma, o agente sabe que a informação requisitada atingiu o destino. Observe que, neste exemplo, há o dobro do tráfego. Mas o agente sabe que o gerenciador recebeu a notificação.

185-i.gif

Neste diagrama, o agente envia uma armadilha para o gerenciador, mas a armadilha não chega ao gerenciador. O agente não tem como saber que a armadilha não chegou ao destino, e assim a armadilha não é enviada novamente. O gerenciador nunca recebe a armadilha.

185-j.gif

Nesse diagrama, o agente envia uma informação requisitada ao gerenciador, mas a informação requisitada não chega ao gerenciador. Como o gerenciador não recebeu a informação requisitada, não há resposta. Depois de um período de tempo, o agente reenvia a informação requisitada. Da segunda vez, o gerenciador recebe a informação requisitada e envia uma resposta. Neste exemplo, há mais tráfego. Mas a notificação chegou ao gerenciador de rede.

Referência de Cisco MIBs e RFCs

Os documentos de RFC geralmente definem módulos de MIB. Os documentos de RFC são enviados para o Internet Engineering Task Force (IETF), um corpo de padrões internacional. Indivíduos ou grupos gravam RFCs para consideração pelo Internet Society (ISOC) e a comunidade da Internet como um todo. Consulte a home page da Internet Society leavingcisco.com para saber sobre o processo de padrões e as atividades do IETF. Consulte a home page do IETF leavingcisco.com para ler o texto completo de todos os RFCs, Internet Drafts (I-Ds) e STDs aos quais os documentos da Cisco fazem referência.

A implementação de SNMP da Cisco usa:

  • As definições de variáveis de MIB II que o RFC 1213 leavingcisco.com descreve

  • As definições de armadilhas SNMP que o RFC 1215 leavingcisco.com descreve

A Cisco fornece suas próprias extensões de MIB privadas com cada sistema. Os MIBs corporativos da Cisco atendem às diretrizes que os RFCs relevantes descrevem, a menos que a documentação indique o contrário. Você pode encontrar os arquivos de definição de módulo de MIB e uma lista dos MIBs que tem suporte em cada plataforma Cisco na home page de MIB da Cisco.

Versões SNMP

Cisco IOS Software oferece suporte a estas versões de SNMP:

  • SNMPv1 — Um padrão de Internet completo que o RFC 1157 leavingcisco.com define. RFC 1157 leavingcisco.com substitui as versões anteriores que foram publicadas como RFC 1067 leavingcisco.com e RFC 1098 leavingcisco.com. A segurança é baseada nos strings da comunidade.

  • SNMPv2c — SNMPv2c é a estrutura administrativa baseada em string da comunidade para SNMPv2. SNMPv2c (o c representa comunidade) é um protocolo de Internet experimental que RFC 1901 leavingcisco.com, RFC 1905 leavingcisco.com e RFC 1906 leavingcisco.com definem. O SNMPv2c é um melhoramento das operações de protocolo e os tipos de dados de SNMPv2p (SNMPv2 Classic). O SNMPv2c usa o modelo de segurança baseado em comunidade do SNMPv1.

  • SNMPv3 — SNMPv3 é um protocolo baseado em padrões interoperável que RFC 2273 leavingcisco.com, RFC 2274 leavingcisco.com e RFC 2275 leavingcisco.com definem. O SNMPv3 fornece acesso seguro a dispositivos com uma combinação de autenticação e criptografia de pacotes na rede.

    Os recursos de segurança fornecidos pelo SNMPv3 são:

    • Integridade de mensagem — Garante que um pacote não foi alterado em trânsito.

    • Autenticação — Determina se a mensagem é de uma origem válida.

    • Criptografia — Mistura o conteúdo de um pacote, o que evita a descoberta por uma origem não autorizada.

O SNMPv1 e o SNMPv2c usam uma forma de segurança baseada em comunidade. Uma ACL de endereço de IP e a senha definem a comunidade de gerenciadores aptos a acessar o agente de MIB.

O suporte a SNMPv2c inclui um mecanismo de recuperação de grande escala e um relatório de mensagem de erro mais detalhado para estações de gerenciamento. O mecanismo de recuperação de grande escala oferece suporte à recuperação de tabelas e grandes quantidades de informações, que minimizam o número de round trips necessários. O suporte a manipulação de erros melhorada do SNMPv2c inclui códigos de erro expandidos que diferenciam tipos diferentes de condições de erro. Essas condições são relatadas por um único código de erro no SNMPv1. Os códigos de retorno de erro agora relatam o tipo de erro.

O SNMPv3 fornece os modelos de segurança e os níveis de segurança. Um modelo de segurança é uma estratégia de autenticação que é configurada para um usuário e o grupo em que o usuário reside. Um nível de segurança é o nível permitido de segurança dentro de um modelo de segurança. A combinação de um modelo de segurança e um nível de segurança determina qual mecanismo de segurança usar quando um pacote SNMP é processado.

Configuração geral do SNMP

Execute estes comandos em todos os switches de cliente para habilitar o gerenciamento de SNMP:

  • Comando para ACLs de SNMP:

    Switch(config)#access-list 98 permit ip_address
                      
                      
                         !--- Esta é a ACL de dispositivo SNMP.
                       
                   
  • Comandos SNMP Globais:

                      
                         !--- Esses são os exemplos de strings de comunidade SNMP.
                      
    Switch(config)#snmp-server community RO-community ro 98
                      snmp-server community RW-community rw 98
                      snmp-server contact Glen Rahn (Home Number)
                      snmp-server location text
                      
                   

Recomendação de Desvios de SNMP

O SNMP é a base de todo o gerenciamento da rede, sendo habilitado e usado em todas as redes.

Um agente SNMP pode comunicar-se com vários gerenciadores. Por esse motivo, você pode configurar o software para oferecer suporte a comunicações com uma estação de gerenciamento com uso de SNMPv1, e outra estação de gerenciamento com uso de SNMPv2. A maior parte dos clientes e NMSs ainda usam SNMPv1 e SNMPv2c porque o suporte a dispositivo de rede de SNMPv3 em plataformas é um pouco demorado.

Habilite armadilhas SNMP para todos os recursos que estão em uso. Você pode desabilitar outros recursos, se desejar. Depois de habilitar uma armadilha, você poderá executar o comando test snmp e configurar a manipulação apropriada no NMS para o erro. Exemplos dessa manipulação incluem um alerta de pager ou um pop-up.

Todas as armadilhas são desabilitadas por padrão. Habilitar todas as armadilhas em switches centrais, como mostra este exemplo:

Switch(config)#snmp trap enable 
Switch(config)#snmp-server trap-source loopback0
         

Além disso, habilitar armadilhas de porta para portas de chave, como os links de infra-estrutura para os routers e switches, e portas de servidor de chave. A habilitação não é necessária para outras portas, como portas de host. Execute este comando para configurar a porta e habilitar a notificação de ativação/desativação de link:

Switch(config-if)#snmp trap link-status
         

Em seguida, especifique os dispositivos que receberão as armadilhas e atue nas armadilhas de forma apropriada. Você pode agora configurar cada destino de armadilha como receptor de SNMPv1, SNMPv2 ou SNMPv3. Para dispositivos SNMPv3, informações confiáveis podem ser enviadas em vez de armadilhas de UDP. Esta é a configuração:

Switch(config)#snmp-server host ip_address [traps | informs] [version {1 | 2c | 3}] 
community-string
            
            
               !--- Este comando precisa estar em uma só linha.
!--- Estes são destinos de host de exemplo para armadilhas SNMP e informações.
            
            snmp-server host 172.16.1.27 version 2c public
            snmp-server host 172.16.1.111 version 1 public
            snmp-server host 172.16.1.111 informs version 3 public
            snmp-server host 172.16.1.33 public
         

Recomendações de Eleição SNMP

Certifique-se de que esses MIBs são os MIBs de chave que são pesquisados ou monitorados nas redes do campus:

Observação: Essa recomendação é do grupo de consulta de gerenciamento de rede Cisco.

185-k.gif

185-l.gif

185-m.gif

Protocolo de Tempo de Rede

Finalidade

O Protocolo de Tempo de Rede (NTP), RFC 1305 leavingcisco.com, sincroniza a manutenção de horas entre um conjunto de servidores e clientes de tempo distribuído. O NTP permite a correlação de eventos na criação dos logs de sistema e quando outros eventos específicos do tempo ocorrerem.

Visão Geral Operacional

RFC 958 leavingcisco.com documentou o NTP primeiro. Mas o NTP evoluiu por meio do RFC 1119 leavingcisco.com (NTP Versão 2). RFC 1305 leavingcisco.com agora define NTP, que está em sua terceira versão.

O NTP sincroniza o tempo de um cliente ou servidor de computador para outro servidor ou origem de tempo de referência, como um rádio, receptor de satélite ou modem. O NTP fornece precisão de cliente que está tipicamente dentro de um ms ou LANs e até algumas dezenas de milissegundos em WANs, relativos ao servidor primário sincronizado. Por exemplo, você pode usar o NTP para coordenar Coordinated Universal Time (UTC) por meio de um receptor de GPS (Global Positioning Service).

As configurações de NTP típicas utilizam vários servidores redundantes e diversos caminhos de rede para alcançar uma alta precisão e confiabilidade. Algumas configurações incluem autenticação criptográfica para evitar ataques de protocolos maliciosos ou acidentais.

O NTP é executado pelo UDP, que por sua vez, é executado por IP. Toda a comunicação NTP utiliza UTC, que é o mesmo que o Horário do Meridiano de Greenwich.

Atualmente, implementações de NTP Versão 3 (NTPv3) e NTP Versão 4 (NTPv4) estão disponíveis. A versão de software mais recente que está sendo trabalhada é NTPv4, mas o padrão da Internet oficial ainda é NTPv3. Além disso, alguns fornecedores de sistema operacionais personalizam a implementação do protocolo.

Proteções de NTP

A implementação de NTP tenta evitar a sincronização com uma máquina em que o tempo talvez não possa ser preciso. O NTP faz isso de duas formas:

  • O NTP não é sincronizado com uma máquina que não está sincronizada.

  • O NTP sempre compara o tempo que é relatado por várias máquinas e não é sincronizado com uma máquina em que o tempo seja significativamente diferente do tempo de outras, mesmo que a máquina tenha um estrato mais baixo.

Associações

As comunicações entre máquinas que executam NTP, que são conhecidas como associações, são geralmente configuradas estaticamente. A cada máquina são dados os endereços IP de todas as máquinas com as quais é necessário formar associações. A manutenção de horas precisa é possível por meio do intercâmbio de mensagens NTP entre cada par de máquinas com uma associação. Mas em um ambiente de LAN, você pode configurar NTP para usar mensagens de broadcast de IP. Com essa alternativa, você pode configurar a máquina para enviar ou receber mensagens de broadcast, mas a precisão da manutenção de horas é reduzida marginalmente porque o fluxo de informações é apenas unidirecional.

Se a rede é isolada da Internet, a implementação de NTP Cisco permite que você configure uma máquina para que ela atue como se fosse sincronizada com o uso do NTP, quando na verdade ela determinou o tempo com o uso de outros métodos. Outras máquinas foram sincronizadas com essa máquina com o uso de NTP.

Uma associação NTP pode ser:

  • Uma associação correspondente

    Isso significa que esse sistema pode ser sincronizado com o outro sistema ou permitir que o outro sistema seja sincronizado com ele.

  • Uma associação de servidor

    Isso significa que somente esse sistema é sincronizado com o outro sistema. O outro sistema não é sincronizado com esse sistema.

Se você desejar formar uma associação NTP com outro sistema, use um desses comandos no modo de configuração global:

Comando

Finalidade

ntp peer ip-address [normal-sync] [version number] [key key-id] [source interface] [prefer]

Forma uma associação correspondente com outro sistema

ntp server ip-address [version number] [key key-id] [source interface] [prefer]

Forma uma associação de servidor com outro sistema

Observação: Apenas uma parte de uma associação precisa ser configurada. O outro sistema estabelece automaticamente a associação.

Acesso a Servidores de Tempo Público

A sub-rede de NTP inclui atualmente mais de 50 servidores principais públicos que são sincronizados diretamente ao UTC por rádio, satélite ou modem. Geralmente, as estações de trabalho de clientes e servidores com um número pequeno de clientes não são sincronizados aos servidores principais. Há cerca de 100 servidores secundários públicos que são sincronizados aos servidores primários. Esses servidores fornecem sincronização sincronização a mais de 100.000 clientes e servidores na Internet. A página Servidores NTP Públicos leavingcisco.com mantém as listas atuais e é atualizada com freqüência.

Além disso, há vários servidores primários e secundários privados que não estão disponíveis normalmente ao público. Consulte O Projeto Protocolo de Tempo de Rede leavingcisco.com (Universidade de Delaware) para obter uma lista de servidores NTP públicos e informações sobre como usá-los. Não há garantias de que esses servidores de Internet NTP públicos estejam disponíveis e que produzam o tempo correto. Portanto, aconselhamos considerar outras opções. Por exemplo, use vários dispositivos GPS (Global Positioning Service) independentes diretamente conectados a vários routers.

Uma outra opção é o uso de vários routers configurados como um mestre de Estrato 1. Mas o uso desse router não é recomendado.

Estrato

O NTP usa um estrato para descrever o número de saltos NTP de distância que uma máquina está de uma origem de tempo autoritária. Um servidor de tempo do estrato 1 possui um relógio atômico ou de rádio que está conectado diretamente. Um servidor de tempo do estrato 2 recebe seu tempo de um servidor de tempo do estrato 1, etc. Uma máquina que executa o NTP automaticamente escolhe como sua origem de tempo a máquina com o menor número de estratos com o qual ela está configurada para se comunicar por meio do NTP. Essa estratégia cria efetivamente uma árvore organizada automaticamente de alto-falantes NTP.

O NTP evita a sincronização com um dispositivo em que o tempo provavelmente não é preciso. Consulte a seção Proteções de NTP do Protocolo de Tempo de Rede para obter detalhes.

Relacionamento de Peer do Servidor

  • Um servidor responde aos pedidos do cliente, mas não tenta incorporar qualquer informação de dados de uma origem de tempo do cliente.

  • Um peer responde aos pedidos do cliente e tenta utilizar esses pedidos como um candidato potencial para uma origem de tempo melhor e para auxiliar na estabilização da freqüência do relógio.

  • Para ser peers verdadeiros, os dois lados da conexão devem entrar num relacionamento de peer, em vez de em uma situação na qual um usuário serve como peer e o outro como servidor. Faça com que os peers troquem chaves para que somente hosts confiáveis possam se comunicar entre si como peers.

  • Em um pedido do cliente a um servidor, o servidor responde ao cliente e esquece que o cliente fez uma pergunta.

  • Em um pedido do cliente a um peer, o servidor responde ao cliente. O servidor mantém informações de estado sobre o cliente para controlar com que eficiência o cliente está executando e qual servidor de estrato está sendo executado.

Um servidor NTP pode processar milhares de clientes sem nenhum problema. Mas quando um servidor NTP processa mais de alguns poucos clientes (até algumas centenas), há um impacto de memória na capacidade do servidor para reter informações de estado. Quando um servidor NTP processa uma quantidade maior do que a recomendada, mais recursos de CPU e largura de banda são consumidos na caixa.

Modos de Comunicação com o Servidor NTP

Há dois modos separados para se comunicar com o servidor:

  • Modo de transmissão

  • Modo cliente/servidor

No modo de transmissão, os clientes ouvem. No modo cliente/servidor, os clientes pesquisam o servidor. Você poderá usar transmissão de NTP se nenhum link de WAN estiver envolvido devido à sua velocidade. Para atravessar um link de WAN, use o modo cliente/servidor (por pesquisa). O modo de transmissão é projetado para uma LAN, na qual vários clientes provavelmente precisarão pesquisar o servidor. Sem o modo de transmissão, essa pesquisa provavelmente gerará um grande número de pacotes na rede. A transmissão múltipla de NTP ainda não está disponível no NTPv3, mas está disponível no NTPv4.

Por padrão, o Cisco IOS Software se comunica com o uso de NTPv3. Mas o software tem compatibilidade retrógrada com versões anteriores do NTP.

Pesquisa

O protocolo NTP permite que um cliente consulte um servidor a qualquer momento.

Quando o NTP é primeiramente configurado em uma caixa Cisco, ele envia oito consultas em rápidas sucessões nos intervalos NTP_MINPOLL (2^4=16 s). O estado NTP_MAXPOLL é 2^14 segundos (16.384 s ou 4 horas, 33 minutos, 4 segundos). Esse período de tempo é o período mais longo antes de o NTP requisitar novamente uma resposta. Atualmente, a Cisco não tem um método para permitir que o usuário force manualmente a definição de tempo de PESQUISA .

O contador de pesquisas do NTP inicia em 2^6 (64) s ou 1 minuto, 4 segundos. Esse tempo é elevado à potência de 2, à medida que os dois servidores se sincronizam entre si, a 2^10. Você pode esperar que as mensagens de sincronização sejam enviadas em um intervalo de um de 64, 128, 256, 512 ou 1024 segundos, como por servidor ou configuração de peer. O tempo mais longo entre as pesquisas ocorre à medida que o relógio atual se torna mais estável, devido aos circuitos bloqueados de fase. Os circuitos bloqueados de fase cortam o cristal do relógio local, em até 1.024 segundos (17 min).

O tempo varia entre 64 e 1.024 segundos como uma potência de 2 (o que é igual a uma vez a cada 64, 128, 256, 512 ou 1.024 segundos). O tempo baseia-se no circuito bloqueado de fase que envia e recebe pacotes. Se houver muita variação no tempo, a pesquisa ocorrerá com mais freqüência. Se o relógio de referência estiver preciso e a conectividade de rede for consistente, os horários de pesquisa convergirão em 1.024 segundos entre cada pesquisa.

O intervalo de pesquisa do NTP é alterado à medida que a conexão entre o cliente e o servidor é alterada. Com uma conexão melhor, o intervalo de pesquisa é mais longo. Nesse caso, uma melhor conexão significa que o cliente NTP recebeu oito respostas para as suas oito últimas solicitações. O intervalo de pesquisa será então duplicado. Uma única resposta perdida faz com que o intervalo de pesquisa seja reduzido pela metade. O intervalo de pesquisa inicia em 64 segundos e chega até um máximo de 1.024 segundos. Na melhor das circunstâncias, o tempo necessário para que o intervalo de pesquisa vá de 64 segundos a 1.024 segundos é pouco mais de 2 horas.

Transmissões

As transmissões de NTP nunca são encaminhadas. Se você emitir o comando ntp broadcast, o router começará a originar transmissões de NTP na interface na qual ele está configurado.

Geralmente, você emite o comando ntp broadcast para enviar transmissões de NTP em uma LAN para atender as estações finais e servidores do cliente.

Sincronização de Tempo

A sincronização de um cliente para um servidor consiste em várias trocas de pacotes. Cada troca é um par de pedido/resposta. Quando um cliente envia um pedido, ele armazena seu tempo local no pacote enviado. Quando um servidor recebe o pacote, ele armazena sua própria estimativa do tempo atual no pacote e o pacote é retornado. Quando a resposta é recebida, o receptor mais uma vez registra o seu próprio tempo de recepção para estimar o tempo de trajeto do pacote.

Essas diferenças de tempo podem ser usadas para estimar o tempo que seria necessário para que o pacote fosse transmitido do servidor para o solicitante. Esse tempo do percurso de ida e volta é levado em consideração para uma estimativa do tempo atual. Quanto mais curto for o percurso de ida e volta, mais precisa será a estimativa do tempo atual.

O tempo não é aceito até que ocorram várias trocas de pacotes de comum acordo. Alguns valores essenciais são colocados em filtros de vários estágios para estimar a qualidade das amostras. Geralmente, cerca de 5 minutos são necessários para que um cliente NTP seja sincronizado a um servidor. Curiosamente, isso também é verdadeiro para relógios de referência local que não tenham retardo por definição.

Além disso, a qualidade da conexão da rede também influencia a precisão final. Redes lentas e imprevisíveis com retardos variados têm um efeito ruim na sincronização de tempo.

Uma diferença de tempo de menos de 128 ms é necessária para que o NTP seja sincronizado. A precisão típica na Internet varia de cerca de 5 ms a 100 ms, a qual pode variar com retardos na rede.

Níveis de Tráfego NTP

A largura de banda que o NTP utiliza é mínima. O intervalo entre as mensagens de pesquisa que os peers trocam normalmente retém não mais do que uma mensagem a cada 17 minutos (1.024 segundos). Com um planejamento cuidadoso, você pode mantê-lo dentro das redes do router por meio dos links de WAN. Faça com que os clientes NTP correspondam a servidores NTP locais e não a toda a WAN com os routers centrais da estação central que serão os servidores de Estrato 2.

Um cliente convergido de NTP usará em média 0,6 bits por segundo por servidor.

Recomendação NTP Cisco

  • A Cisco recomenda que você tenha vários servidores de tempo e diversos caminhos de rede para alcançar uma alta precisão e confiabilidade. Algumas configurações incluem autenticação criptográfica para evitar ataques de protocolos maliciosos ou acidentais.

  • Como no RFC, o NTP é realmente projetado para permitir pesquisas em vários servidores de tempo diferentes e uso de análise estatística complicada para que ocorram dentro de um tempo válido, mesmo que você não tenha certeza de que todos os servidores que você pesquisa sejam de autoridade. O NTP estima os erros de todos os relógios. Portanto, todos os servidores NTP retornam o tempo junto com uma estimativa do erro atual. Quando você usa vários servidores de tempo, o NTP também deseja que esses servidores se combinem em algum momento.

  • A implementação da Cisco de NTP não suporta serviço de estrato 1. Você não pode conectar com um relógio atômico ou de rádio. A Cisco recomenda que o serviço de tempo de sua rede seja derivado dos servidores NTP públicos que estão disponíveis na Internet IP.

  • Habilite todos os switches clientes para enviar regularmente pedidos de saudação para um servidor NTP. Você pode configurar até 10 endereços de servidor/peer por cliente para que possa obter uma sincronização rápida.

  • Para reduzir a carga adicional de protocolo, os servidores secundários distribuem o tempo pelo NTP entre os hosts de rede local restantes. Para fins de confiabilidade, você pode equipar os hosts selecionados com relógios de menor precisão, mas mais baratos, a serem usados para backup, no caso de uma falha dos servidores primários e/ou secundários ou dos caminhos de comunicação entre eles.

  • ntp update-calendar—O NTP geralmente altera apenas o relógio do sistema. Esse comando permite que o NTP atualize as informações de data/hora no calendário. A atualização será feita apenas se o tempo de NTP estiver sincronizado. Caso contrário, o calendário manterá seu próprio tempo e não será afetado pelo tempo do NTP ou relógio do sistema. Use sempre isso nos routers avançados.

  • clock calendar-valid - Esse comando declara que as informações do calendário são válidas e sincronizadas. Use essa opção no mestre de NTP. Se isso não estiver configurado, o router avançado que possui o calendário continuará a achar que seu tempo não é de autoridade, mesmo se ele tiver a linha mestre de NTP.

  • Qualquer número de estrato superior a 15 será considerado não sincronizado. É por isso que você vê o estrato 16 na saída do comando show ntp status em routers nos quais os relógios não estão sincronizados. Se o mestre estiver sincronizado com o servidor NTP público, assegure-se de que o número do estrato na linha mestre de NTP seja um ou dois números maiores do que o maior número de estrato nos servidores públicos pesquisados.

  • Muitos clientes possuem o NTP configurado no modo servidor em suas plataformas Cisco IOS Software, sincronizado com diversas alimentações confiáveis da Internet ou de um relógio de rádio. Internamente, uma alternativa mais simples para modo de servidor, quando você opera um grande número de switches, é ativar o NTP no modo de transmissão na VLAN de gerenciamento em um domínio comutado. Esse mecanismo permite que o Catalysts receba um relógio de mensagens de transmissão única. Mas a precisão da cronometragem é reduzida marginalmente porque o fluxo de informações é unidirecional.

  • O uso de endereços de loopback como fonte de atualizações pode também auxiliar com consistência. Você pode determinar as preocupações de segurança de duas maneiras:

    • Com o controle de atualizações do servidor, o qual a Cisco recomenda

    • Por autenticação

Comandos de Configuração Global NTF

            
               !--- Para o cliente:
            
            clock timezone EST  -5  ????
            ntp source loopback 0 ?????
            ntp server ip_address key 1
            
            ntp peer ip_address
            
            
               !--- Esse é para uma associação correspondente.
            
            ntp authenticate
            ntp authentication-key 1 md5 xxxx
            
            ntp trusted-key 1
            

            
               !--- Para o servidor:
            
            clock timezone EST -5
            clock summer-time EDT recurring 1 Sun Apr 3:00 last Sun Oct 3:00
            clock calendar-valid
            ntp source loopback0
            ntp update-calendar

            
               !--- Esse é opcional:
            
            interface vlan_id ntp broadcast 
            
               !--- Esse envia pacotes de transmissão NTP.
            
            ntp broadcast client 
            
               !--- Esse recebe pacotes de transmissão NTP.
            
            ntp authenticate
            ntp authentication-key 1 md5 xxxxx
            
            ntp trusted-key 1
            
            ntp access-group access-list 
            
               !--- Esse fornece segurança adicional, se for necessário.
            
         

Comando de Status NTP

            show ntp status

Clock is synchronized, stratum 8, reference is 127.127.7.1
nominal freq is 250.0000 Hz, actual freq is 249.9974 Hz, precision is 2**18
reference time is C6CF0C30.980CCA9D (01:34:00.593 IST Mon Sep 12 2005)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 0.02 msec, peer dispersion is 0.02 msec

Esse é o endereço do relógio de referência para o router da Cisco quando ele atua como um mestre de NTP. Se o router não foi sincronizado com nenhum servidor NTP, ele usará esse endereço como o ID de referência. Para obter detalhes sobre a configuração e os comandos, consulte a seção Configuração de NTP em Execução do Gerenciamento Básico do Sistema.

Cisco Discovery Protocol

Finalidade

O CDP é executado na Camada 2 (camada de links de dados) em todos os routers, pontes, servidores de acesso e switches Cisco. O CDP permite que aplicativos de gerenciamento de rede descubram dispositivos Cisco que sejam vizinhos de dispositivos já conhecidos. Em particular, aplicativos de gerenciamento de rede podem descobrir vizinhos que executem protocolos transparentes de camadas inferiores. Com o CDP, os aplicativos de gerenciamento de rede podem identificar o tipo de dispositivo e o endereço do agente SNMP de dispositivos vizinhos e enviar consultas SNMP a esses dispositivos. Esse recurso permite que aplicativos enviem consultas SNMP para dispositivos vizinhos.

Os comandos show que estão associados ao recurso CDP permitem que o engenheiro de rede determine essas informações:

  • O número do módulo/porta de outros dispositivos adjacentes habilitados para CDP

  • Estes são os endereços do dispositivo adjacente:

    • Endereço de MAC

    • Endereço IP

    • Endereço de canal de porta

  • A versão de software do dispositivo adjacente.

  • Estas são informações sobre o dispositivo adjacente:

    • Velocidade

    • Dúplex

    • Domínio de VTP

    • Definindo o VLAN nativo

A seção Visão Geral Operacional destaca alguns dos aprimoramentos de CDP versão 2 (CDPv2) sobre o CDP versão 1 (CDPv1).

Visão Geral Operacional

O CDP é executado em todas as mídias LAN e WAN que suportam SNAP.

Cada dispositivo configurado para CDP envia mensagens periódicas para um endereço de multicast. Cada dispositivo anuncia pelo menos um endereço no qual o dispositivo pode receber mensagens de SNMP. Os anúncios contêm também as informações sobre a duração ou o tempo de contenção. Essas informações indicam por quanto tempo um dispositivo de recebimento deve manter informações de CDP antes de descartá-las.

O CDP usa encapsulamento SNAP com código de tipo 2000. Em Ethernet, ATM e FDDI é usado o endereço multicast de destino 01-00-0c-cc-cc-cc. Em Token Rings, é usado o endereço funcional c000.0800.0000. Quadros de CDP são enviados periodicamente a cada minuto.

As mensagens de CDP contêm uma ou mais submensagens que permitem que o dispositivo de destino colete e armazene informações sobre todos os dispositivos vizinhos.

Esta tabela oferece os parâmetros que o CDPv1 suporta:

Parâmetro

Tipo

Descrição

1

ID do Dispositivo

Nome de host do dispositivo ou número de série do hardware em ASCII

2

Endereço

O endereço da Camada 3 da interface que envia a atualização

3

ID de Porta

A porta para a qual a atualização de CDP é enviada

4

Recursos

Descreve os recursos funcionais do dispositivo dessa maneira:

  • Router: 0x01

  • Ponte SR1: 0x04

  • Switch: 0x08 (fornece comutação da Camada 2 e/ou da Camada 3)

  • Host: 0x10

  • Filtragem condicional de IGMP: 0x20

  • A ponte ou o switch não encaminha os pacotes de relatório IGMP em portas sem router.

5

Versão

Uma seqüência de caracteres que contém a versão do software

Observação: A saída do comando show version mostra as mesmas informações.

6

Plataforma

A plataforma de hardware, por exemplo, WS-C5000, WS-C6009 e Cisco RSP2

SR 1 = rota de origem.

2 RSP = Processador de Switch da Rota.

No CDPv2, os TLVs (valores, comprimento, tipo) adicionais foram introduzidos. O CDPv2 suporta qualquer TLV. Mas esta tabela fornece os parâmetros que podem ser particularmente úteis em ambientes comutados e que o software Catalyst utiliza.

Quando um switch executa o CDPv1, ele descarta quadros CDPv2. Quando um switch executa o CDPv2 e recebe um quadro CDPv1 em uma interface, ele começa a enviar para fora dessa interface quadros CDPv1 além de quadros CDPv2.

Parâmetro

Tipo

Descrição

9

Domínio VTP

O domínio VTP, se estiver configurado no dispositivo

10

VLAN Nativa

Em dot1q, os quadros da VLAN, nos quais a porta estará se não estiver fazendo entroncamento, permanecerão não rotulados. Isso é geralmente chamado de VLAN nativa.

11

Bidirecional/Semi-dúplex

Esse TLV contém a configuração de dúplex da porta de envio.

14

Ferramenta de ID da VLAN

Permite que o tráfego de VoIP seja diferenciado de outro tráfego por meio de um ID da VLAN separado (VLAN auxiliar).

16

Consumo de Energia

A quantidade máxima de energia que se espera que seja consumida, em mW, pelo dispositivo conectado.

17

MTU

A MTU da interface pela qual o quadro de CDP é transmitido.

18

Confiança Estendida

Indica que a porta está no modo Confiança Estendida.

19

COS para Portas Não Confiáveis

O valor de CoS (classe de serviço) a ser usado para marcar todos os pacotes que são recebidos na porta não confiável de um dispositivo comutado conectado.

20

SysName

Nome de domínio totalmente qualificado do dispositivo (0, se for desconhecido).

25

Energia Necessária

Transmitido por um dispositivo ativado para negociar um nível de energia adequado.

26

Energia Disponível

Transmitida por um switch. Permite que um dispositivo ativado negocie e selecione uma configuração de energia adequada.

CDPv2/Energia por Ethernet

Alguns switches, como o Catalyst 6500/6000 e 4500/4000, possuem a capacidade de fornecer energia por meio de cabos UTP (par trançado não blindado) para dispositivos ativados. As informações recebidas por meio do CDP (Parâmetros 16, 25, 26) auxiliam na otimização de gerenciamento de potência do switch.

Interação de Telefone IP CDPv2/Cisco

Os telefones IP da Cisco oferecem conectividade para um dispositivo Ethernet 10/100-Mbps conectado externamente. Essa conectividade é obtida por meio da integração de um switch de Camada 2 de três portas internas com o telefone IP. As portas internas do switch são chamadas de:

  • P0 (dispositivo interno de telefone IP)

  • P1 (porta externa de 10/100-Mbps)

  • P2 (porta external de 10/100-Mbps que se conecta ao switch)

Você pode transferir tráfego de voz em uma VLAN separada na porta do switch se configurar portas de tronco de acesso dot1q. Essa VLAN adicional é conhecida como uma VLAN auxiliar (CatOS) ou de voz (Cisco IOS Software). Conseqüentemente, o tráfego identificado como dot1q a partir do telefone IP pode ser enviado pela VLAN auxiliar/de voz e o tráfego não identificado pode ser enviado pela porta externa de 10/100 Mbps do telefone pela VLAN de acesso.

Os switches do Catalyst podem informar um telefone IP do ID da VLAN de voz por meio do CDP (Parâmetro-14: Ferramenta TLV do ID da VLAN). Como resultado, o telefone IP identifica todos os pacotes relacionados a VoIP com o ID da VLAN apropriado e a prioridade 802.1p. Esse TLV do CDP também é usado para identificar se um telefone IP está conectado por meio do parâmetro de ID da ferramenta.

Esse conceito pode ser utilizado ao desenvolver uma política de QoS. Você pode configurar o switch do Catalyst para interagir com o telefone IP de três maneiras:

  • Telefone IP Cisco de Dispositivo Confiável

    CoS condicionalmente confiável apenas quando um telefone IP for detectado por meio do CDP. Sempre que um telefone IP for detectado por meio do Parâmetro-14 do CDP, o estado confiável da porta será definido como COS Confiável. Se nenhum telefone IP for detectado, a porta será Não Confiável.

  • Confiança Estendida

    O switch pode informar o telefone IP por meio do CDP (Parâmetro-18) para confiar todos os quadros recebidos em sua porta externa do dispositivo de 10/100 Mbps.

  • COS de Regravação para Portas Não Confiáveis

    O switch pode informar o telefone IP por meio do CDP (Parâmetro-19) para regravar os valores do CoS 802.1p recebidos em sua porta externa do dispositivo de 10/100 Mbps.

    Observação: Por padrão, todo o tráfego recebido nas portas externas de 10/100 Mbps do telefone IP é Não Confiável.

Recomendação da Cisco para a Configuração

As informações que o CDP fornece podem ser extremamente úteis ao solucionar problemas de conectividade da Camada 2. Habilita o CDP em todos os dispositivos que suportam sua operação. Emita estes comandos:

  • Para habilitar o CDP globalmente no switch:

    Switch(config)#cdp run
                   
  • Para habilitar o CDP em uma base por porta:

    Switch(config)#interface type slot#/port#
                       
    Switch(config-if)#cdp enable
                   

Lista de Verificação de Configuração

Comandos Globais

Faça logon, habilite e entre no modo de configuração global para iniciar o processo de configuração do switch.

Switch>enable
Switch#
Switch#configure terminal
Switch(Config)#

Comandos Globais Genéricos (Nível Empresarial)

Esta seção de Comandos Globais lista os comandos globais que se aplicam a todos os switches da rede corporativa do cliente.

Essa configuração contém os comandos globais recomendados para adicionar a configuração inicial. Você deve alterar os valores da saída antes de copiar e colar o texto no CLI. Emita estes comandos para aplicar a configuração global:

            vtp domain domain_name
            
            vtp mode transparent 
            spanning-tree portfast bpduguard
            spanning-tree etherchannel guard misconfig
            cdp run
            no service pad
            service password-encryption
            enable secret password
            
            clock timezone EST –5 
            clock summer-time EDT recurring 1 Sun Apr 3:00 last Sun Oct 3:00
            clock calendar-valid
            ip subnet-zero
            ip host tftpserver your_tftp_server
            
            ip domain-name domain_name
            
            ip name-server name_server_ip_address
            
            ip name-server name_server_ip_address
            
            ip classless
            no ip domain-lookup
            no ip http server
            no logging console
            no logging monitor
            logging buffered 16384
            logging trap notifications
            logging facility local7
            logging syslog_server_ip_address
            
            logging syslog_server_ip_address
            
            logging source-interface loopback0
            service timestamps debug datetime localtime show-timezone msec
            service timestamps log datetime localtime show-timezone msec
            access-list 98 permit host_ip_address_of_primary_snmp_server
            
            access-list 98 permit host_ip_address_of_secondary_snmp_server
            
            snmp-server community public ro 98
            snmp-server community laneng rw 98
            snmp-server enable traps entity
            snmp-server host host_address traps public
            snmp-server host host_address traps public
            banner motd ^CCCCC

This is a proprietary system, NOT for public or personal use.  All work products,
communications, files, data or information directly or indirectly created, input
or accessed on this system are and shall become the sole property of the company.
This system is actively monitored and accessed by the company.  By logging onto
this system, the user consents to such monitoring and access.
 
USE OF THIS SYSTEM WITHOUT OR IN EXCESS OF THE PROPER AUTHORIZATION MAY SUBJECT
THE USER TO DISCIPLINE AND/OR CIVIL AND CRIMINAL PENALTIES

^C
            line console 0
            exec-timeout 0 0
            password cisco
            login
            transport input none
            line vty 0 4
            exec-timeout 0 0
            password cisco
            login
            length 25
            clock calendar-valid
            ntp server ntp_server_ip_address
            
            ntp server ntp_server_ip_address
            
            ntp update-calendar
         

Comandos Globais Específicos para Cada Chassi do Switch

Os comandos globais desta seção são específicos para cada chassi do switch que está instalado na rede.

Variáveis de Configuração Específicas do Chassi

Para definir a data e a hora, emita este comando:

Switch#clock set hh:mm:ss 
               day 
               month 
               year
            
         

Para definir o nome do host do dispositivo, emita estes comandos:

Switch>enable
Switch#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Switch(config)#hostname Cat6500
         

Para configurar a interface de loopback para gerenciamento, emita estes comandos:

CbrCat6500(config)#interface loopback 0
Cat6500(config-if)#description Cat6000 - Loopback address and Router ID
Cat6500(config-if)#ip address ip_address 
               subnet_mask
            
Cat6500(config-if)#exit
         

Para mostrar a revisão ao Engenheiro Supervisor do Cisco IOS Software, emita estes comandos:

Cbrcat6500#show version | include IOS
IOS (tm) MSFC Software (C6MSFC-DSV-M), Version 12.1(13)E9, EARLY DEPLOYMENT RELE
ASE SOFTWARE (fc1)
cat6500#

Para mostrar a revisão de arquivo de inicialização de MSFC, emita este comando:

Cat6500#dir bootflash:
Directory of bootflash:/
 1 -rw- 1879040 Aug 19 2003 19:03:29 c6msfc-boot-mz.121-19.E1a

15990784 bytes total (14111616 bytes free

Para especificar as informações de contato e o local do servidor SNMP, emita estes comandos:

Cat6500(config)#snmp-server contact contact_information
            
Cat6500(config)#snmp-server location location_of_device
            
         

Comandos da Interface

Tipos de Porta Funcionais da Cisco

As portas do switch no Cisco IOS Software são chamadas de interfaces. Há dois tipos de modos de interface no Cisco IOS Software:

  • Interface roteada da Camada 3

  • Interface de switch da Camada 2

A função de interface refere-se a como você configurou a porta. A configuração da porta pode ser:

  • Interface roteada

  • SVI (Interface Virtual Comutada)

  • Porta de acesso

  • Tronco

  • EtherChannel

  • Uma combinação desses

O tipo de interface refere-se a um tipo de porta. O tipo de porta pode ser:

  • FE

  • GE

  • Canal de porta

Esta lista descreve resumidamente as diferentes funções da interface do Cisco IOS Software:

  • Interface Física Roteada (padrão) – Cada interface no switch é uma interface roteada da Camada 3 por padrão, o que é semelhante a qualquer router Cisco. A interface roteada deve ficar em uma única sub-rede IP.

  • Interface de porta do switch de acesso – Essa função é usada para colocar interfaces na mesma VLAN. As portas devem ser convertidas de uma interface roteada para uma interface comutada.

  • SVI - Um SVI pode ser associado a uma VLAN que contenha porta do switch de acesso para roteamento interVLAN. Configure o SVI para ser associado a uma VLAN quando desejar uma rota ou uma ponte entre as portas do switch de acesso em VLANs diferentes.

  • Interface de porta do switch de tronco – Essa função é usada para transportar várias VLANs para outro dispositivo. As portas devem ser convertidas de uma interface roteada para uma porta do switch de tronco.

  • EtherChannel - Um EtherChannel é usado para agrupar portas individuais em uma única porta lógica para obter redundância e equilíbrio de carga.

Recomendações de Tipo de Porta Funcional da Cisco

Use as informações desta seção para ajudar a determinar os parâmetros que se aplicam às interfaces.

Observação: Alguns comandos específicos da interface são incorporados quando possível.

Negociação Automática

Não use a negociação automática em nenhuma destas situações:

  • Para portas que suportam dispositivos de infra-estrutura de rede, como switches e routers

  • Para outros sistemas finais não transitórios, como servidores e impressoras

Configure manualmente essas configurações de link de 10/100 Mbps para velocidade e dúplex. As configurações são normalmente full-dúplex de 100 Mbps:

  • enlace switch a switch de 10 MB

  • enlace switch a servidor de 100 MB

  • enlace switch a router de 100 MB

Você pode configurar estas definições desta maneira:

Cat6500(config-if)#interface [type] mod#/port#
            
Cat6500(config-if)#speed 100
Cat6500(config-if)#duplex full
         

A Cisco recomenda configurações de enlace de 10/100 Mbps para usuários finais. Trabalhadores móveis e hosts transitórios precisam de negociação automática, como mostrado neste exemplo:

Cat6500(config-if)#interface [type] mod#/port#
            
Cat6500(config-if)#speed auto
         

O valor padrão em interfaces Gigabit é autonegociação. Mas execute estes comandos para ter certeza que a autonegociação encontra-se habilitada. A Cisco recomenda que a negociação de Gigabit seja habilitada.

Cat6500(config-if)#interface gigabitethernet mod#/port#
            
Cat6500(config-if)#no speed
         

Raiz da Árvore de Abrangência

Dependendo do desenho da rede, identifique qual switch é mais adequado para ser a raiz de cada VLAN. De modo geral, escolha uma switch potente no meio da rede. Coloque a ponte raiz no centro da rede e conectada diretamente à ponte raiz dos servidores e routers. Esta configuração geralmente reduz a distância média entre clientes e servidores e routers. Consulte Problemas no Spanning Tree Protocol e Considerações de Desenho Relacionadas para obter mais informações.

Para forçar um switch a ser raiz de uma VLAN designada, execute este comando:

Cat6500(config)#spanning-tree vlan vlan_id root primary
         

Portfast de Árvore de Abrangência

O PortFast contorna a operação da árvore de abrangência normal nas portas de acesso para acelerar os retardos da conectividade inicial que ocorrem quando as estações finais estão conectadas a um switch. ConsulteUsando Portfast e Outros Comandos para Corrigir Atrasos de Conectividade de Inicialização de Estações de Trabalho para obter mais informações.

Defina o STP PortFast para todas portas de acesso habilitado conectadas a um único host. Veja o exemplo a seguir:

Cat6500(config-if)#interface [type] mod#/port#
            
Cat6500(config-if)#spanning-tree portfast
%Warning: portfast should only be enabled on ports connected to a single
 host. Connecting hubs, concentrators, switches, bridges, etc... to this
 interface  when portfast is enabled, can cause temporary bridging loops.
 Use with CAUTION
%Portfast has been configured on FastEthernet3/1 but will only have effect 
when the interface is in a non-trunking mode.

UDLD

Habilite a UDLD (Detecção Unidirecional de Links) somente nas portas da infra-estrutura conectadas por fibra ou cabos Ethernet de cobre para monitorar a configuração física dos cabos. Emita os comandos para habilitar a UDLD:

Cat6500(config)#interface [type] mod#/port#
            
Cat6500(config-if)#udld enable
         

Informação de Configuração de VLAN

Configure VLANS com estes comandos:

Cat6500(config)#vlan vlan_number
            
Cat6500(config-vlan)#name vlan_name
            
Cat6500(config-vlan)#exit
Cat6500(config)#spanning-tree vlan vlan_id
            
Cat6500(config)#default spanning-tree vlan vlan_id
            
         

Repita os comandos para cada VLAN e saia. Execute o comando seguinte:

Cat6500(config)#exit 
         

Execute o comando seguinte para verificar todas as VLANs:

Cat6500#show vlan 
         

SVIs Roteadas

Configure as SVIs para roteamento interVLAN. Execute estes comandos:

Cat6500(config)#interface vlan vlan_id
            
Cat6500(config-if)#ip address svi_ip_address 
               subnet_mask
            
Cat6500(config-if)#description interface_description
            
Cat6500(config-if)#no shutdown
         

Repita esses comandos para todas as funções de interface que contenham uma SVI roteada e saia. Execute o comando seguinte:

Cat6500(config-if)#^Z
         

Interface Física Única Roteada

Emita os comandos a seguir para configurar a interface da Camada 3 roteada padrão:

Cat6500(config)#interface [type] mod#/port#
            
Cat6500(config-if)#ip address ip_address 
               subnet_mask
            
Cat6500(config-if)#description interface_description
            
         

Repita esses comandos para todas as funções de interface que contenham uma interface física roteada e saia. Execute o comando seguinte:

Cat6500(config-if)#^Z
         

EtherChanne Roteado (L3)

Para configurar o EtherChannel nas interfaces da Camada 3, execute os comandos que constam desta seção.

Configure a interface de canal/porta lógica desta maneira:

Cat6500(config)#interface port-channel port_channel_interface_#
            
Cat6500(config-if)#description port_channel_description
            
Cat6500(config-if)#ip address port_channel_ip_address 
               subnet_mask
            
Cat6500(config-if)#no shutdown
         

Siga as etapas desta seção para as portas que formam o canal em particular. Aplique a informação restante ao canal da porta, como este exemplo mostra:

Cat6500(config)#interface range [type] mod/port_range
            
Cat6500(config-if)#channel-group 1-64 mode [active | auto | desirable | on | passive]
Cat6500(config-if)#no shutdown
Cat6500(config-if)#^Z
         

Observação: Depois de configurar um EtherChannel, a configuração que você aplica à interface do canal da porta afeta o EtherCannel. A configuração que você aplicar às portas da LAN afetará apenas a porta LAN onde você aplicou a configuração.

EtherChannel (L2) com Entroncamento

Configure o EtherChannel da Camada 2 para entrocamento desta maneira:

Cat6500(config)#interface port-channel port_channel_interface_#
            
Cat6500(config-if)#switchport
Cat6500(config-if)#switchport encapsulation encapsulation_type
             
Cat6500(config-if)#switchport trunk native vlan vlan_id
             
Cat6500(config-if)#no shutdown
Cat6500(config-if)#exit
         

Siga as etapas desta seção apenas para as portas que formam o canal em particular.

Cat6500(config)#interface range [type] mod/port_range
            
Cat6500(config-if)#channel-group 1-64 mode [active | auto | desirable | on | passive]
Cat6500(config-if)#no shutdown
Cat6500(config-if)#exit
         

Observação: Depois de configurar um EtherChannel, a configuração que você aplica à interface do canal da porta afeta o EtherCannel. A configuração que você aplicar às portas LAN afetará apenas a porta LAN onde você aplicou a configuração.

Verifique a criação de todos os EtherChannels e troncos. Veja o exemplo a seguir:

Cat6500#show etherchannel summary
Cat6500#show interface trunk
         

Portas de Acesso

Se a função de interface é uma porta de acesso configurada como interface única, execute os comandos seguintes:

Cat6500(config)#interface [type] mod#/port#
            
Cat6500(config-if)#switchport mode access
Cat6500(config-if)#switchport access vlan vlan_id
             
Cat6500(config-if)#exit
         

Repita estes comandos para todas as interfaces que precisam ser configuradas como porta de switch de Camada 2.

Se a porta de switch deve ser conectada às estações finais, execute o comando a seguir:

Cat6500(config-if)#spanning-tree portfast
         

Porta de Tronco (Interface Física Única)

Se a função de interface é uma porta de tronco configurada como interface única, execute os comandos a seguir:

Cat6500(config)#interface [type] mod#/port#
            
Cat6500(config-if)#switchport
Cat6500(config-if)#switchport trunk encapsulation dot1q
Cat6500(config-if)#switchport trunk native vlan vlan_id
            
Cat6500(config-if)#no shutdown
Cat6500(config-if)#exit
         

Repita estes comandos para todas as funções de interface que precisam ser configuradas como porta de tronco.

Informação de Senha

Execute os comandos a seguir para informações de senha:

Cat6500(config)#service password-encryption
Cat6500(config)#enable secret password
             

CbrCat6500(config)#line con 0
Cat6500(config-line)#password password
             

CbrCat6500(config-line)#line vty 0 4
Cat6500(config-line)#password password
             
Cat6500(config-line)#^Z
         

Salve a Configuração

Execute o comando a seguir para salvar a configuração:

Cat6500#copy running-config startup-config
         

Novos Recursos do Software no Cisco IOS Software Release 12.1[13]E)

Para obter mais informações sobre suporte a IP phone, consulte Configurando o Suporte a IP Phone.

Consulte Reconhecimento de Aplicativos Baseados em Rede e Reconhecimento de Aplicativos Baseados em Rede Distribuída para obter mais informações sobre Reconhecimento de Aplicativos Baseados em Rede (NBAR) para portas LAN.

Observações:

  • NBAR para portas LAN tem suporte no software na MSFC2.

  • A PFC2 fornece suporte de hardware para ACLs de entrada em portas LAN onde você configura NBAR.

  • Quando o QoS de PFC é habillitado, o tráfego pelas portas LAN onde você configura o NBAR passa pelas filas de ingresso e de egresso e pelos limites de descarte.

  • Quando o QoS de PFC está habilitado, a MSFC2 define a classe de serviço (CoS) de egresso igual à precedência de IP de egresso.

  • Depois do tráfego passar pela fila de entrada, todo o tráfego será processado pelo software na MSFC2 nas portas LAN onde o NBAR está configurado.

  • O NBAR Distribuído está disponível nas interfaces FlexWAN com o Cisco IOS Software Release 12.1(6)E e posteriores.

As melhorias do NetFlow Data Export (NDE) incluem:

  • Máscaras de fluxo destino-origem-interface e interface total

  • NDE versão 5 da PFC2

  • NetFlow de Exemplo

  • Uma das opções para preencher esses campos adicionais em regisros NDE:

    • Endereço IP do router do próximo nó

    • interface de ingresso SNMP ifIndex

    • Interface de egresso SNMP ifIndex

    • Número de sistema independente da origem

Consulte Configuração de NDE para obter mais informações sobre melhorias.

Outras melhorias de recursos são:

Os comandos a seguir são comandos novos:

  • standby delay minimum reload

  • link debounce

  • vlan internal allocation policy {ascending | descending}

  • system jumbomtu

  • clear catalyst6000 traffic-meter

Os comandos a seguir são comandos melhorados:

  • show vlan internal usage — Esse comando foi melhorado para incluir VLANs que as interfaces WAN usam.

  • show vlan id — Esse comando foi melhorado para suportar a entrada de uma faixa de VLANs.

  • show l2protocol-tunnel — Este comando foi aprimorado para dar suporte à entrada de uma ID de VLAN.

O software Cisco IOS Software Release 12.1(13)E suporta esses recursos de software, que anteriormente eram suportados nas versões do Cisco IOS Software Release 12.1 EX:

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 24330