Switches : Switches Cisco Catalyst série 4500

Melhores Práticas para os Catalyst 4500/4000 , 5500/5000 e 6500/6000 Series Switches que Executem a Configuração e Gerenciamento CatOS

22 Maio 2008 - Tradução Manual
Outras Versões: Versão em PDFpdf | Tradução por Computador (29 Julho 2013) | Inglês (29 Novembro 2007) | Feedback


Índice

Introdução
Pré-requisitos
     Requisitos
     Componentes Usados
     Convenções
     Informações Complementares
Configuração Básica
     Protocolos de Plano de Controle de Catalyst
     Protocolo de Entroncamento VLAN
     VLAN Estendida e Redução de Endereço MAC
     Negociação Automática
     Gigabit Ethernet
     Dynamic Trunking Protocol
     Spanning Tree Protocol
     EtherChannel
     UniDirectional Link Detection
     Frame jumbo
Configuração de gerenciamento
     Diagramas de Rede
     Gerenciamento In-Band
     Gerenciamento fora de banda
     Testes de sistema
     Detecção de Erro de Sistema e de Hardware
     EtherChannel/Manipulação de Erros de Link
     Diagnóstico de buffer de pacote de informação do Catalyst 6500/6000
     Registro de sistema
     Protocolo de Gerenciamento de Rede Simples
     Monitoramento Remoto
     Protocolo de Tempo de Rede
     Cisco Discovery Protocol
Configuração de Segurança
     Recursos Básicos de Segurança
     Terminal Access Controller Access Control System
Lista de Verificação de Configuração
Discussões relacionadas da comunidade de suporte da Cisco
Informações Relacionadas

Introdução

Este documento discute a implementação dos Cisco Catalyst Series Switches em sua rede, especificamente as plataformas Catalyst 4500/4000, 5500/5000 e 6500/6000. As configurações e comandos são discutidos sob a suposição de que você está executando o software de Distribuição Geral Catalyst OS (CatOS) versão 6.4(3) ou posterior. Ainda que sejam apresentadas algumas considerações de desenho, este documento não abrange todos os projetos de campus.

Pré-requisitos

Requisitos

Este documento assume familiaridade com a Referências a Comandos da série Catalyst 6500, 7.6.

Ainda que sejam fornecidas referências à material público on-line para posterior leitura pelo documento, há outras referências de base e educacional:

Componentes Usados

Este documento não está restrito a versões específicas de software e de hardware.

Convenções

Consulte Convenções de Dicas Técnicas da Cisco para obter mais informações sobre as convenções de documentos.

Informações Complementares

Estas soluções representam anos de experiência de campo dos engenheiros da Cisco trabalhando com muitos de seus maiores consumidores e redes complexas. 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, negociando alguma flexibilidade para 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.

Este documento está dividido em quatro seções:

Configuração Básica

Os recursos implementados na maioria das redes Catalyst são discutidos nesta seção.

Protocolos de Plano de Controle de Catalyst

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

Tráfego de Supervisor

A maioria dos recursos habilitados em uma rede Catalyst requer dois ou mais switches para cooperar, deve haver então uma troca controlada 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 CDP ou baseado em padrões, como IEEE 802.1d (STP), todos têm determinados elementos em comum quando implementado na série Catalyst.

Na estrutura básica de encaminhamento, os quadros de dados do usuário se originam de sistemas finais, e seu endereço de origem e de destino não são alterados pelos domínios comutados da Camada 2 (L2). As tabelas de consulta do CAM (Content Addressable Memory) em cada switch do Supervisor Engine são preenchidas por um processo de aprendizagem do endereço de origem e indica qual porta de saída deve encaminhar cada quadro recebido. Se o processo de aprendizagem do endereço está incompleto (o destino é desconhecido ou o quadro está destinado a um endereço broadcast ou multicast), ele é encaminhado (inundado) para fora de todas as portas naquele VLAN.

O switch também deve reconhecer que quadros devem ser comutados pelo sistema e quais devem ser direcionados à própria CPU do switch (também conhecida como Processador de Gerenciamento de Redes [NMP]).

O plano de controle de Catalyst é criado utilizando entradas especiais na tabela CAM conhecida como system entries para receber e direcionar o tráfego ao NMP em uma porta de switch interna. Dessa forma, através da utilização 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. Execute o comando show CAM system em um switch para confirmar isso, conforme mostrado:

>show cam system

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

               !--- porta interna NMP.
            
1     01-00-0c-cc-cc-cc  #          1/3

               !--- CDP em diante.
            
1     01-00-0c-cc-cc-cd  #          1/3

               !--- Cisco STP.
            
1     01-80-c2-00-00-00  #          1/3

               !--- IEEE STP.
            
1     01-80-c2-00-00-01  #          1/3

               !--- Controle de fluxo IEEE.
            
1     00-03-6b-51-e1-82 R#          15/1

               !--- Roteador de Cartão de Recursos de Transmissão Multicamada (MSFC).
            
...

Cisco possui uma escala reservada de MAC de Ethernet e de endereços de protocolo, conforme mostrado. Cada um é demonstrado mais à frente neste documento. Entretanto, um sumário é apresentado nesta tabela para exemplo.

Recurso

Tipo de Protocolo HDLC SNAP

MAC Multicast de Destino

Port Aggregation Protocol (PAgP)

0x0104

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

PVSTP+ de Árvore de Abrangência

0x010b

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

Ponte VLAN

0x010c

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

UniDirectional Link Detection (UDLD)

0x0111

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

Cisco Discovery Protocol

0x2000

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

Entroncamento Dinâmico (DTP)

0x2004

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

STP Uplink Fast

0x200a

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

Árvore de Abrangência IEEE 802.1d

N/A - DSAP 42 SSAP 42

01-80-c2-00-00-00

Inter Switch Link (ISL)

N/A

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

Entroncamento VLAN (VTP)

0x2003

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

Pausa IEEE, 802.3x

N/A - DSAP 81 SSAP 80

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

A maioria dos protocolos de controle do Cisco utiliza um encapsulamento IEEE 802.3 SNAP, incluindo LLC 0xAAAA03, OUI 0x00000C, que pode ser visto em um traço do analisador LAN. Outras propriedades comuns desses protocolos incluem:

  • Esses protocolos assumem uma conectividade ponto a ponto. Observe que o uso deliberado de endereços de destino de multicast habilita dois Catalysts para comunicação transparente em switches que não sejam da Cisco, porque os dispositivos que não compreendem e interceptam os quadros simplesmente os inundam. Entretanto, as conexões de ponto a multiponto por ambientes de multi-fornecedores pode resultar em um comportamento inconsistente e deve ser geralmente evitado.

  • Esses protocolos terminam nos roteadores da Camada 3 (L3); eles funcionam apenas dentro do domínio do switch.

  • Esses protocolos recebem prioridade sobre os dados do usuário pela entrada do agendamento e processamento de ASIS (circuitos integrados de aplicativos específicos).

Após introduzir os endereços de destino do protocolo de controle, o endereço de origem também deve ser descrito integralmente. Os protocolos de switch utilizam um endereço MAC retirado de um banco de endereços disponíveis fornecido pelo EPROM no chassi. Execute o comando show module para exibir as escalas de endereços disponíveis para cada módulo quando ele origina tráfego, como os BPDUs (bridge protocol data units) de STP ou quadros de ISL.

>show module

...
Mod MAC-Address(es)                        Hw     Fw         Sw
--- -------------------------------------- ------ ---------- -----------------
1   00-01-c9-da-0c-1e to 00-01-c9-da-0c-1f 2.2    6.1(3)     6.1(1d)
    00-01-c9-da-0c-1c to 00-01-c9-da-0c-1
    00-d0-ff-88-c8-00 to 00-d0-ff-88-cb-ff

               !--- MACs para tráfego de origem.
            
...
VLAN 1

VLAN 1

O VLAN 1 possui um significado especial nas redes de Catalyst.

O Catalyst Supervisor Engine sempre utiliza o VLAN padrão, VLAN 1, para marcar um número de protocolos de gerenciamento e de controle quando fazer entroncamento, como CDP, VTP e PAgP. Todas as portas, incluindo a interface sc0 interna, são configuradas por padrão para serem membros do VLAN 1. Todos os troncos carregam o VLAN 1 por padrão, e nas versões anteriores à 5.4 do software CatOS, não foi possível bloquear os dados do usuário no VLAN 1.

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

  • O gerenciamento de VLAN é onde o sc0 reside; esse VLAN pode ser alterado.

  • O VLAN nativo é definido como o VLAN ao qual uma porta retorna quando não faz entroncamento, e é o VLAN não marcado em um tronco 802.1Q.

Essas são boas razões para ajustar uma rede e alterar o comportamento de portas em VLAN 1:

  • Quando o diâmetro do VLAN 1, como qualquer outro VLAN, aumenta o suficiente para ser um risco à estabilidade (particularmente a partir de uma perspectiva STP) é necessária a retirada. Isso será discutido mais detalhadamente na seção In-Band Management deste documento.

  • Os dados do plano de controle no 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.

  • Os loops de L2 no VLAN 1 devem ser evitados quando as redes de campus de multicamada são programadas sem STP, e o entroncamento ainda é exigido para a camada de acesso se houverem múltiplos Para executar isso, limpe manualmente o VLAN 1 das portas de tronco.

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

  • Atualizações CDP, VTP, e PAgP são sempre encaminhadas em troncos com uma tag de VLAN 1. Esse é o caso mesmo se o VLAN 1 for removido dos troncos e não for o VLAN nativo. Se o VLAN 1 for removido para os dados do usuário, não há impactos no tráfego do plano de controle que ainda envia utilizando o VLAN 1.

  • Em um tronco ISL, os pacotes DTP são enviados em um VLAN1. Esse é o caso mesmo se o VLAN 1 for removido do tronco e não for mais o VLAN nativo. Em um tronco 802.1Q, os pacotes DTP são enviados no VLAN nativo. Esse é o caso mesmo se o VLAN 1 nativo for removido do tronco.

  • No PVST+, os BPDUs 802.1Q IEEE são encaminhados não-rotulados no VLAN 1 da Árvore de Abrangência comum para interoperabilidade com outros fornecedores, a não ser que o VLAN 1 seja removido do tronco. Esse é o caso independente da configuração de VLAN nativa. BPDUs PVST+ do Cisco são enviados e rotulados para todos os outros VLANs. Consulte a seção Spanning Tree Protocol neste documento para mais detalhes.

  • Os BPDUs da Árvore de Abrangência Múltipla (MST) 802.1s são sempre enviados no VLAN 1 nos troncos ISL e 802.1Q. Isso se aplica mesmo quando o VLAN 1 é removido dos troncos.

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

Protocolo de Entroncamento VLAN

Antes de criar VLANs, determine o modo VTP a ser usando na rede. O VTP permite que alterações na configuração da VLAN sejam feitas centralmente em um ou mais switches. Essas alterações são propagadas automaticamente para todos os switches no domínio.

Visão Geral Operacional

O VTP é um protocolo de mensagem L2 que mantém a consistência da configuração do VLAN. O VTP gerencia a adição, a exclusão e a renomeação de VLANs na base de toda a rede. O VTP minimiza configurações incorretas e inconsistentes que podem causar alguns problemas, como nomes de VLAN duplicados, especificações de tipo de VLAN incorretos e violações de segurança. O banco de dados VLAN é um arquivo binário e está armazenado em NVRAM nos servidores VTP separadamente do arquivo de configuração.

O protocolo VTP se comunica entre os switches usando um endereço MAC multicast de destino (01-00-0c-cc-cc-cc) e um protocolo SNAP HDLC tipo Ox2003. Ele não funciona em portas sem tronco (o VTP é uma carga útil de ISL ou 802.1Q), de forma que as mensagens não podem ser enviadas até que o DTP traga o tronco on-line.

Os tipos de mensagem incluem anúncios de sumário a cada cinco minutos, anúncios de subconjunto e anúncios de requisição em que há alterações e se juntam quando a poda de VTP estiver habilitada. O número de revisão da configuração do VTP é aumentado em um número a cada alteração realizada em um servidor, o qual propaga a nova tabela pelo domínio.

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

Esta tabela fornece um sumário de comparação de recurso entre vários modos VTP:

Recurso

Servidor

Cliente

Transparente

Desativado1

Mensagens VTP de origem

Sim

Sim

Não

Não

Ouvir as mensagens VTP

Sim

Sim

Não

Não

Encaminhar mensagens VTP

Sim

Sim

Sim

Não

Criar VLANs

Sim

Não

Sim (significativo apenas localmente)

Sim (significativo apenas localmente)

Lembrar-se dos VLANs

Sim

Não

Sim (significativo apenas localmente)

Sim (significativo apenas localmente)

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

1 A versão 7.1 do software CatOS apresenta a opção de desativar o VTP com o uso do modo off . No modo VTP off , o switch se comporta de maneira muito similar ao VTP transparente , com exceção de que o modo off também suprime o encaminhamento de atualizações VTP.

Esta tabela fornece um sumário da configuração inicial:

Recurso

Valor Padrão

Nome de Domínio VTP

Nulo

Modo de VTP

Servidor

versão de VTP

A versão 1 está habilitada

senha de VTP

Nenhum

Remoção de VTP

Desativado

O VTP versão 2 (VTPv2) inclui esta flexibilidade funcional. Entretanto, não é interoperável com o 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 de versão; o modo transparente não verifica mais o nome de domínio. Isto permite o suporte de mais de um domínio por 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 habilitados pela configuração de um único switch.

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

VTP Versão 3

A versão 8.1 do software CatOS apresenta suporte para o VTP versão 3 (VTPv3). O VTPv3 oferece melhorias em relação às versões existentes. Essas melhorias permitem:

  • Suporte para os VLANs estendidos

  • Suporte para a criação e anúncios de VLANs privados

  • Suporte para as instâncias de VLAN e instâncias de propagação de mapeamento de MST (as quais são suportadas no CatOS versão 8.3)

  • Autenticação de servidor melhorada

  • Proteção contra a inserção acidental do banco de dados "errado" em um domínio VTP

  • Interação com VTPv1 e VTPv2

  • A habilidade de ser configurado por porta.

Uma das principais diferenças entre a implementação do VTPv3 e das versões anteriores é a introdução de um servidor primário VTP. Idealmente, deve haver apenas um servidor primário em um domínio VTPv3, se o domínio não for particionado. Quaisquer alterações feitas ao domínio VTP deve ser executada no servidor primário VTP para ser propagado ao domínio VTP. Pode haver vários servidores dentro de um domínio VTPv3, os quais também são conhecidos como servidores secundários. Quando um switch for configurado para ser um servidor, ele se torna um servidor secundário por padrão. O servidor secundário pode armazenar a configuração do domínio, mas não pode modificar a configuração. Um servidor secundário pode se tornar o servidor primário com um controle bem sucedido do switch.

Os switches que executam o VTPv3 aceitam apenas o banco de dados VTP com um número de revisão maior que o do servidor primário atual. Este processo difere significativamente do VTPv1 e VTPv2, em que um switch sempre aceita uma configuração superior de um vizinho no mesmo domínio. Isso se altera com o oferecimento de proteção ao VTPv3. Um novo switch que é introduzido na rede com um número de revisão VTP mais alto não pode substituir a configuração VLAN de todo o domínio.

O VTPv3 também introduz uma melhoria na maneira pela qual o VTP processa senhas. Se você usar a opção de configuração de senha oculta para configurar uma senha como "oculta", esses itens ocorrem:

  • A senha não aparece em texto simples na configuração. O formato hexadecimal secreto da senha é salvo na configuração.

  • Se você tentar configurar o switch como servidor primário, a senha é solicitada. Se sua senha corresponde à senha secreta, o switch se torna um servidor primário, que permite que se configure o domínio.

Observação: É importante observar que o servidor primário apenas é necessário quando você precisa modificar a configuração VIP por qualquer motivo. Um domínio VTP pode operar sem servidor primário ativo porque o servidor secundário garante persistência das sobrecargas de configuração. Sai-se do estado do servidor primário por estas razões:

  • Uma recarga do switch

  • Uma comutação de alta disponibilidade entre os engines supervisores ativo e redundante.

  • Um controle de outro servidor

  • Uma alteração na configuração de modo

  • Qualquer alteração na configuração do domínio VTP, tal como uma alteração de:

    • Versão

    • Nome de domínio

    • Senha de domínio

O VTPv3 também permite que os switches participem de diversas instâncias.do VTP. Neste caso, o mesmo switch pode ser o servidor VTP para uma instância e um cliente para outra instância porque os modos VTP são específicos para diferentes instância s VTP. Por exemplo, um switch pode operar em transparente modo para uma instância MST enquanto o switch é configurado no modo servidor para uma instância VLAN.

Em termos de interação com o VTPv1 e o VTPv2, o comportamento padrão em todas as versões do VTP tem sido que as versões anteriores do VTP simplesmente descartam as atualizações da nova versão. A não ser que os switches VTPv1 e VTPv2 estejam em modo transparente , todas as atualizações do VTPv3 são descartadas. Por outro lado, depois que os switches VTPv3 recebem um quadro VTPv1 ou VTPv2 legada em um tronco, os switches passam um versão em menor escala de sua atualização de banco de dados para os switches VTPv1 e VTPv2. Entretanto, esta troca de informações é unidirecional no sentido que nenhuma atualização dos switches VTPv1 e VTPv2 é aceita pelos switches VTPv3. Em conexões de tronco, switches VTPv3 continuam a enviar atualizações em menor escala assim como atualizações VTPv3 totalmente cobertas para cuidar da existência de vizinhos VTPv2 e VTPv3 ao longo das portas de tronco.

Para fornecer suporte ao VTPv3 para VLANs estendidas, o formato do banco de dados da VLAN, no qual o VTP atribui 70 bytes por VLAN, é alterado. A alteração permite que a codificação apenas de valores não padrão, em vez do transporte de campos não modificados pelos protocolos legados. Por causa desta alteração, o suporte a 4K VLAN é o tamanho do banco de dados da VLAN resultante.

Recomendação

Não há recomendação específica sobre utilizar ou não VTP modos cliente/servidor ou VTP transparente modo. Alguns clientes preferem a facilidade do gerenciamento de VTP modos cliente/servidor apesar de algumas considerações observadas posteriormente. A recomendação é para ter dois switches de modos servidores em cada domínio para redundância, normalmente os dois switches de camada de distribuição. O restante dos switches no domínio deve ser configurado para o modo cliente. modo. Quando implementar o modo modos cliente/servidor com utilização do VTPv2, fique atento para que um número de revisão superior sempre seja aceito no mesmo domínio VTP. Se um switch que é configurado em no modo VTP cliente. ou servidor é introduzido no domínio VTP e tem um número de revisão superior aos dos servidores VTP existentes, isso substitui o banco de dados da VLAN dentro do domínio VTP. Se a alteração na configuração não é intencional e VLANs são excluídas, a substituição pode causar uma grande interrupção na rede. Para garantir que os switches de cliente. ou servidor sempre tenham um número de revisão de configuração que seja inferior ao do servidor, altere o nome do domínio VTP para outro que não o nome padrão. Em seguida, reverta de volta para o padrão. Esta ação define a revisão de configuração no cliente para 0.

Há prós e contras para a capacidade VTP de fazer alterações facilmente em uma rede. Muitas empresas preferem a abordagem cuidadosa do modo VTP transparente por essas razões:

  • Incentiva a boa prática de controle de alterações, como seu requisito para modificar uma VLAN em um switch ou porta de tronco tem que se considerar um switch por vez

  • Limita o risco de um erro de administração que impacte todo o domínio , como a exclusão de uma VLAN acidentalmente.

  • Não há nenhum risco 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.

  • Estimulas as VLANs a serem removidas de um tronco com dois switches em execução que não têm portas naquelas VLAN. Isto torna a inundação de quadro mais eficiente em relação à largura de banda. A remoção manual também é benéfica porque reduz o diâmetro da árvore de abrangência (consulte a seção DTP deste documento).

  • A faixa de VLAN estendida no CatOS 6.x e CatOS 7, números de 1025 a 4094, só pode ser configurada desta maneira. Para mais informações, consulte a seção VLAN Estendida e Redução de Endereço MAC deste documento.

  • O modo VTP transparente é suportado no Campus Manager 3.1, parte do Cisco Works 2000. A antiga restrição que exigia pelo menos um servidor em um domínio VTP foi removida.

Exemplo de comandos VTP

Comentários

set vtp domain name password x

O CDP verifica os nomes para ajudar a verificar os erros de cabeamento entre domínios. Uma única senha é uma precaução útil contra alterações involuntárias. Lembre-se de nomes ou espaços com distinção entre maiúsculas e minúsculas ao colar.

set vtp mode transparent

 

set vlan vlan number name name

Por switch que possui portas na VLAN.

set trunk mod/port vlan range

Habilita troncos a transportarem VLANs onde necessário – o padrão são todas as VLANs.

clear trunk mod/port vlan range

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.

Observação: Especificando VLANs com o comando set apenas adiciona VLANs e não as limpa. Por exemplo, o comando set trunk x/y 1-10 não configura a lista permitida para somente as VLANs 1-10. Execute o comando clear trunk x/y 11-1005 para alcançar o resultado desejado.

Embora o switching de token ring esteja fora do escopo deste documento, observe que o modo VTP transparente não é recomendado para redes TR-ISL. A base para switching de token ring é que o domínio inteiro forma uma única ponte multiporta distribuída, então cada switch deve ter a mesma informação da VLAN.

Outras Opções

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

O VTPv3 fornece a capacidade de implementar uma autenticação e controle de revisão de configuração mais rígidos. O VTPv3 fornece essencialmente o mesmo nível de funcionalidade, porém com segurança melhorada,como os modos VTPv1/VTPv2 transparente oferecem. Além disso, o VTPv3 é parcialmente compatível com as versões VTP legadas.

Os benefícios de remover VLANs para reduzir inundações de quadro desnecessárias são defendidos neste documento. O comando set vtp pruning enable remove VLANs automaticamente, o que interrompe a inundação ineficiente de quadros onde elas não são necessários. Diferentemente da remoção manual de VLAN, a remoção automática não limita o diâmetro da Árvore de Abrangência.

Do CatOS 5.1, os switches do Catalyst podem mapear números VLAN 802.1Q maiores que 1000 para números ISL VLAN. No CatOS 6.x, os switches Catalyst 6500/6000 suportam VLANs 4096 de acordo com o padrão IEEE 802.1Q. Estas VLANs estão organizadas nestas três intervalos, apenas algumas destes são propagadas para outros switches na rede com VTP:

  • VLANs de intervalo normal: 1–1001

  • VLANs de intervalo estendido: 1025–4094 (só podem ser propagados pelo VTPv3)

  • VLANs de intervalo reservado: 0, 1002—1024, 4095

O IEEE produziu uma arquitetura baseada em padrões para conseguir resultados semelhantes aos de VTP. Com membro do 802.1Q do GARP (Protocolo de Registro de Atributo Genérico), o VLAN o GVRP (Protocolo de Registro de VLAN Genérica) possibilita interoperabilidade de gerenciamento de VLAN entre fornecedores, mas está fora do escopo deste documento.

Observação: O CatOS 7.x introduz a opção de configurar VTP para o modo desligado um modo muito similar ao transparente. Entretanto, o switch não encaminha quadros VTP. Isto pode ser útil em alguns projetos ao fazer entroncamento para switches fora do seu controle administrativo.

VLAN Estendida e Redução de Endereço MAC

O recurso de redução de endereço MAC possibilita identificação de VLAN de intervalo estendido. A habilitação de redução de endereço MAC desativa o pool de endereços MAC que são utilizados para a árvore de abrangência e deixa um único endereço MAC. Este endereço MAC identifica o switch. O software CatOS versão 6.1(1) introduz suporte a redução de endereço MAC para switches Catalyst 6500/6000 e Catalyst 4500/4000 para suportar 4096 VLANs em conformidade com o padrão IEEE 802.1Q.

Visão Geral Operacional

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

Os switches Catalyst com 1024 endereços MAC não habilitam redução de endereço MAC por padrão. Os endereços MAC estão alocados seqüencialmente. O primeiro endereço MAC no intervalo é atribuído a VLAN 1. O segundo endereço MAC no intervalo é atribuído a VLAN 2 e assim por diante. Isto possibilita aos switches suportarem 1024 VLANs com cada VLAN utilizando 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 A redução de endereço MAC é habilitada por padrão por chaves que possuem endereços 64 MAC, e esse recurso não pode ser desativado.

Para Catalyst Series Switches com endereços MAC 1024, uma habilitação de redução de endereço MAC permite suporte a 4096 VLANs que sejam executadas sob PVST+ ou 16 instâncias MISTP (STP de Instâncias Múltiplas) para terem identificadores exclusivos sem um aumento no número de endereços MAC que são necessários para o switch. A redução de endereço MAC 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 que a redução de endereço MAC do identificador de ponte não está habilitada. O identificador de ponte é composto por uma prioridade de ponte de 2 bytes e um endereço MAC de 6 bytes.

103a.gif

A redução de endereço MAC modifica a parte do identificador de ponte STP do BPDU. O campo de prioridade de 2 bytes original é dividido em dois campos. Esta divisão resulta em um campo de prioridade de ponte de 4 bits e uma extensão de ID de sistema de 12 bits possibilita numeração de VLAN de 0 a 4095.

103b.gif

Quando você tem redução de endereço MAC habilitada em switches Catalyst para otimizar as VLANs de intervalo estendido, habilite redução de endereços MAC em todos os switches dentro do mesmo domínio STP. Este passo é necessário para manter os cálculos da raiz STP em todos os switches consistentes. Após habilitar a redução de endereço MAC, a prioridade de ponte de raiz se torna um múltiplo de 4069 mais a ID de VLAN. Os switches sem a redução de endereço MAC podem reclamar raiz inadvertidamente porque estes switches têm uma granularidade mais fina na seleção da ID de ponte.

Diretrizes de Configuração

Você deve seguir determinadas diretrizes ao configurar intervalo de VLAN estendido. O switch pode alocar um bloco de VLANs do intervalo estendido por questões internas. Por exemplo, o switch pode alocar as VLANs para as portas roteadas ou módulos Flex WAN. A alocação do bloco de VLANs sempre começa da VLAN 1006 e continua para cima. Se você tem qualquer VLANs dentro do intervalo que o módulo Flex WAN requere, todas as VLANs requeridas não são alocadas porque as VLANs nunca são alocadas da área de VLAN do usuário. Execute o comando show vlan ou o comando show vlan summary em um switch para exibir o usuário atribuído e as VLANs internas.

>show vlan summary

Current Internal Vlan Allocation Policy - Ascending

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

Internal           7   1006-1011,1016

               !--- Essas são VLANs internas.
            
>show vlan
---- -------------------------------- --------- ------- --------

1    default                          active    7       4/1-48


               !--- Saída suprimida.
            

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

               !--- Essas são VLANs internas.
            
         

Além disso, antes de utilizar as VLANs de intervalo estendido, você deve excluir qualquer mapeamento 802.1Q para ISL existente. Também, em versões anteriores a VTPv3, você deve configurar estaticamente a VLAN estendida em cada switch com a utilização de VTP transparente modo. Consulte a seção Diretrizes de Configuração de VLAN de Intervalo Estendido em Configurando VLANs para mais informações.

Observação: Em software que é anterior a versão 8.1(1) do software, você não pode configurar o nome da VLAN para VLANs de intervalo estendido. Esta capacidade é independente para qualquer versão ou modo

Recomendação

Tente manter uma configuração de redução de endereço MAC consistente dentro do mesmo domínio STP. Entretanto, a aplicação de redução de endereço MAC em todo os dispositivos de rede pode ser impossível quando novos chassis com endereços 64 MAC são introduzidos no domínio STP. A redução de endereço MAC é habilitada por padrão para switches que têm 64 endereços MAC e o recurso não pode ser desabilitado. Entenda que, quando dois sistemas são configurados com a mesma prioridade de árvore de abrangência, o sistema sem redução de MAC tem uma prioridade de árvore de abrangência melhor. Execute este comando para habilitar ou desabilitar redução de endereço MAC:

            set spantree macreduction enable | disable
         

A alocação de VLANs internas é em ordem ascendente e começa VLAN 1006. Atribua 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. Com switches Catalyst 6500 que executam o software Cisco IOS®, você pode configurar a alocação de VLAN interna em ordem decrescente. A CLI (Interface de Linha de Comando) equivalente ao software CatOS não é oficialmente suportada.

Negociação Automática

Ethernet/Fast Ethernet

A negociação automática é uma função opcional do IEEE Fast Ethernet (FE) padrão (802.3u) que possibilita que dispositivos troquem informações automaticamente sobre um link sobre capacidades develocidade e duplex . A negociação automática opera na Camada 1 (L1) e direciona portas de camada de acesso onde usuários transitórios tais como PCs conectados a rede.

Visão Geral Operacional

A causa mais comum de problemas de desempenho nos links de Ethernet 10/100Mbps ocorre quando uma porta no link está operando de forma semi-duplex enquanto a outra está operando de forma full-duplex. Isso acontece ocasionalmente quando uma ou ambas as portas em um link são reinicializadas e o processo de negociação automática não faz com que os parceiros de link tenham a mesma configuração. Também acontece quando os administradores reconfiguram um lado de um link e esquecem de reconfigurar o outro. O sintomas típicos disto são aumento de FCS (seqüência de verificação de quadro), CRC (verificação de redundância cíclica), alinhamento ou contadores de runt no switch.

A negociação automática é discutida em detalhes neste documento. Estes documentos incluem explanações sobre como as negociações automáticas funcionam e 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 não está visualizando os parâmetros de negociação automática do outro parceiro de link e, portanto, está assumindo a configuração half-duplex como padrão.

A maioria dos módulos Catalyst Ethernet suporta 10/100 Mbps e half/full-duplex, mas o comando show port capabilities mod/port confirma isso.

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 é um erro no link que uma estação pode detectar enquanto a outra não pode, como um cabo TX desconectado. Neste exemplo, a estação de envio ainda podia receber dados válidos e detectar que o link é bom através do monitor de integridade de link. Não detecta que sua transmissão não está sendo recebida pela outra estação. Uma 100BASE-FX que detecta uma falha tão remota pode modificar seu fluxo de IDLE transmitido para enviar um padrão de bit especial (chamado de padrão FEFI IDLE) para informar ao vizinho da falha remota, o padrão FEFI-IDLE subseqüentemente ativa uma parada da porta remota (errdisable). Consulte a seção UDLD para mais informações sobre proteção contra falha.

FEFI é suportado por este hardware e estes módulos:

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

  • Catalyst 6500/6000 e 4500 /4000: Todos os módulos 100BASE-FX e GE

Recomendação

Configurar a negociação automática em links 10/100 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 NIC ou fornecedor não são exatamente compatíveis. A incompatibilidade de hardware e outros problemas também podem existir em virtude de recursos avançados específicos do fornecedor, como a polaridade automática ou a integridade do cabeamento, que não são descritos na especificação IEEE 802.3u para negociação automática de 10/100 Mbps. Consulte Field Notice: Problemas de desempenho com NICs Intel Pro/1000T conectados a CAT4K/6K para um exemplo disto.

Antecipe que haverá algumas situações que exigirão configuração de host, velocidade de porta e duplex. Em geral, siga 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 release notes do CatOS para obter as advertências comuns.

  • Verifique a versão do driver da NIC ou sistema operacional que está executando, já que as a versão mais atual do driver ou da correção é geralmente necessária..

Com regra, tente utilizar negociação automática primeiro para qualquer tipo de parceiro de link. Há benefícios óbvios ao configurar a negociação automática para dispositivos transitórios como laptops. Idealmente, a negociação automática também funciona com dispositivos não transitórios tais como servidores e estações de trabalho fixas ou de switch para switch e switch para roteador. Por algumas das razões mencionadas, problemas de negociação podem aparecer. Neste casos, siga os passos de solução de problemas básicos descritos nos links TAC fornecidos.

Se a velocidade de porta está definida para automática em uma porta a Ethernet de 10/100 Mbps, velocidade e duplex são negociados automaticamente. Execute este comando para definir a porta para automática:

            set port speed port range auto
            
               !--- Este é o padrão.
            
         

Ao configurar a porta, execute estes comandos de configuração:

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

No CatOS 8.3 e posteriores, a Cisco introduziu a palavra-chave opcional auto-10-100 . Utilize a palavra-chave auto-10-100 em portas que suportam velocidades de 10/100/1000 Mbps, mas onde a negociação automática para 1000 Mbps é indesejável. Utilização da palavra-chave auto-10-100 faz a porta se comportar da mesma maneira que uma porta de 10/100-Mbps que tem a velocidade definida para auto. A velocidade e duplex são negociados para portas de 10/100 apenas e a velocidade de 1000-Mbps não participa da negociação.

            set port speed port_range auto-10-100
         

Outras Opções

Quando nenhuma negociação automática é utilizada entre switches, a indicação de falha L1 também pode ser perdida para certos problemas. É útil utilizar os protocolos L2 para aumentar a detecção de falhas, tal como UDLD assertivo.

Gigabit Ethernet

A GE (Gigabit Ethernet) tem um processo de negociação automática (IEEE 802.3z) que é mais extensivo que aquele para Ethernet 10/100 Mbps e é utilizado para trocar parâmetros de controle de fluxo, informações sobre falha remota e informações sobre duplex (embora as portas GE da série Catalyst só suportem o modo full-duplex).

Observação: 802.3z foi substituído pelo IEEE 802.3:2000 specs. Consulte Padrões de Assinatura de Padrões IEEE On-Line LAN/MAN: Arquivos leavingcisco.com para obter mais informações.

Visão Geral Operacional

A negociação de porta GE é habilitada por padrão, e as portas de ambas as extremidades de um link GE devem ter a mesma configuração. Ao contrário do FE, o link GE não aparece se a configuração da negociação automática estiver diferente nas portas de cada extremidade do link. Entretanto, a única condição para uma porta com negociação automática desabilitada estabelecer link é um sinal de Gigabit válido da ponta oposta. Esse comportamento não depende da configuração de negociação automática da ponta oposta. Por exemplo, presuma que existam dois dispositivos, A e B. Cada dispositivo pode ter a negociação automática habilitada ou desabilitada. Essa tabela é uma lista das possíveis configurações e os respectivos estados de link:

Negociação

B Habilitado

B Desativada

A Habilitado.

ativa nos dois lados

A desativada, B ativa

A Desabilitado

A ativa, B desativada

ativa 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:

103c.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: A especificação de fibra da 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 atraso 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 set port sync-restart-delay só tem efeito quando a negociação automática está configurada como habilitada.

Recomendação

A habilitação da negociação automática é muito mais importante em um ambiente de GE que em um ambiente 10/100. Na realidade, a negociação automática só deve ser desabilitada em portas de switch que se conectam a dispositivos que não são capazes de suportar negociação ou quando os problemas de conectividade surgem de problemas de interoperabilidade. A Cisco recomenda que a negociação de Gigabit seja habilitada (padrão) em todos os links switch a switch e geralmente em todos os dispositivos GE. Execute este comando para habilitar a negociação automática:

            set port negotiation port range enable
            
               !--- Este é o padrão.
            
         

Uma exceção conhecida é quando existe uma conexão com um Roteador de Switch de Gigabit (GSR) sendo executado versão do Cisco IOS Software mais atual 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 ou a porta de reporta não conectado, e o GSR reporta erros. Este é um exemplo de seqüência de comando :

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

Conexões de switch para servidor devem ser examinadas em cada caso. Os clientes da Cisco tiveram problemas com a negociação Gigabit em servidores Sun, HP e IBM.

Outras Opções

Os controles de fluxo são uma parte opcional da especificação 802.3x e devem ser negociados se usados. Os dispositivos podem ou não podem ser capazes de enviar e/ou responder a um quadro PAUSE (bem conhecido MAC 01-80-C2-00-00-00 0F). Além disso, eles podem não concordar com a solicitação de controle de fluxo do vizinho extremidade oposta. Uma porta com um buffer de entrada que esteja ficando cheio envia um frame PAUSE ao seu parceiro de link, o qual interrompe a transmissão e segura todos os quadros adicionais nos buffers de saída do parceiro de link. Isso não resolve um estado estacionário em problema de assinatura, mas efetivamente torna o buffer de entrada maior em alguma fração do buffer de saída de parceiro durante os bursts.

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

Execute estes comandos para controlar isso nas portas do switch:

            
set port flowcontrol mod/port receive | send off |on | desired
            

>show port flowcontrol

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

Observação: Todos os módulos Catalyst respondem a um quadro PAUSE se negociado. Alguns módulos (por exemplo, WS-X5410, WS-X4306) nunca enviam quadros PAUSE mesmo se for negociado assim, eles são não bloqueados.

Dynamic Trunking Protocol

Tipo de Encapsulamento

Os troncos ampliam as VLANs entre os dispositivos identificando temporariamente e rotulando (link-local) os quadros Ethernet originais, dessa forma habilitando-os para multiplex por um link único. Isto 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.

O entroncamento é suportado em diversos tipos de mídia L2, incluindo ATM LANE, FDDI 802.10 e Ethernet, apesar de apenas o último estar presente aqui.

Visão Geral Operacional do ISL

A identificação proprietária Cisco ou o esquema de rotulação têm sido usados por muitos anos. Padrão 802.1Q IEEE também está disponível.

Encapsulando totalmente o quadro em um esquema de rotulação de dois níveis, o ISL é efetivamente um protocolo e possui o benefício adicional de carregar quadros não-Ethernet. Ele adiciona um cabeçalho de 26 bytes e um FCS de 4 bytes ao quadro Ethernet padrão - os maiores quadros Ethernet são esperados e processados por portas configuradas para serem troncos. O ISL suporta 1024 VLANs.

Formato de Frame ISL

40 bits

4 bits

4 bits

48 bits

16 bits

24 bits

24 bits

15 bits

Bit

16 bits

16 bits

Comprimento variável

32 bits

Dest. End .

Tipo

USER

SA

LEN

SNAP LLC

HSA

VLAN

BPDU

INDEX

Reserve

Estrutura encapsulada

FCS

01-00-0c-00-00

       

AAAA03

00000C

           

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

Visão Geral Operacional do 802.1Q

O padrão IEEE 802.1Q especifica muito mais que os tipos de encapsulamento, incluindo melhorias de Árvore, GARP (consulte a seção VTP desse documento), e rotulação 802.1p Quality of Service (QoS).

O formato da estrutura 802.1Q preserva o endereço fonte original e o endereço de destino da Ethernet, mesmo assim os switches agora podem esperar receber quadros baby-giant, mesmo em portas de acesso onde hosts podem usar tag para expressar prioridade de usuário 802.1p em sinalização de QoS. A tag tem 4 bytes, então os quadros 802.1Q Ethernet v2 têm 1522 bytes, um IEEE 802.3ac trabalhando em realização de grupo. O 802.1Q também suporta espaço de numeração para 4096 VLANs.

Todas os quadros de dados transmitidos e recebidos são marcadas com 802.1Q, exceto aqueles na VLAN nativa (existe uma tag implícita baseada na configuração da porta de switch de ingresso). Os quadros VLAN nativa são sempre transmitidos não-marcados e normalmente recebidos não-marcados. Entretanto, eles também podem ser recebidos marcados.

Consulte a Padronização de VLAN via IEEE 802.10 e Obter IEEE 802 leavingcisco.com para obter mais detalhes.

Formato de Frame 802.1Q/801.1p

 

Cabeçalho de Tag

 

TPID

TCI

48 bits

48 bits

16 bits

3 bits

1 bit

12 bits

16 bits

Comprimento variável

32 bits

DA

SA

TPID

Prioridade

CFI

ID de VLAN

Comprimento/ Tipo

Dados com PAD

FCS

 

0x8100

0 - 7

0-1

0-4095

 

Recomendação

Como todo hardware mais novo suporta 802.1Q (e alguns suportam apenas 802.1Q, como o Catalyst séries 4500/4000 e CSS 11000), a Cisco recomenda que toda nova implementação siga o padrão IEEE 802.1Q e que as redes mais antigas migrem gradualmente do ISL.

O padrão IEEE permite interoperabilidade de fornecedor. Isso é vantajoso em todos os ambientes Cisco já que o novo host 802.1p tem capacidade de NICs e os dispositivos se tornam disponíveis. Apesar das implementações ISL e 802.1Q serem maturas, o padrão IEEE finalmente terá mais exposição de campo e mais suporte de terceiros, como o suporte de analisador de rede. A sobrecarga de encapsulamento mais baixa do 802.1Q comparada ao ISL é um ponto pequeno em favor do 802.1Q também.

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 dot1q:

            
set trunk mod/port mode dot1q
         

Se o VLAN 1 for removido de um tronco, conforme discutido na seção In-Band Management do presente documento, apesar de nenhum dado do usuário ter sido transmitido ou recebido, o NMP continua a passar protocolos de controle como o CDP e VTP em VLAN 1.

Além disso, conforme discutido na seção VLAN 1 deste documento, os pacotes de CDP, VTP e PAgP sempre são enviados no VLAN 1 durante o entroncamento. Ao usar o encapsulamento dot1q, 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 roteador estiver habilitado e a VLAN nativa for alterada no switch, uma subinterface em VLAN 1 é necessária para receber estrutura de CDP marcado e fornecer visibilidade de CDP vizinho no roteador.

Observação: Existe uma consideração de segurança em potencial com o dot1q causada pela marcação implícita da VLAN nativa, já que pode ser possível enviar quadros de uma VLAN para outra sem um roteador. Consulte Existe Vulnerabilidade em Implementações de VLAN? 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. A maioria dos clientes Cisco deixam a VLAN 1 como VLAN nativa em um tronco e atribuem portas de acesso a VLANs diferentes da VLAN 1 para fazer isso de modo simples.

Modo de Entroncamento

O DTP é a segunda geração de ISL Dinâmico (DISL), e existe para garantir que parâmetros diferentes envolvidos no envio de quadros ISL ou 802.1Q, como o tipo de encapsulamento configurado, VLAN nativa e capacidade de hardware, são acordados pelos switches em cada extremidade do tronco. Isso também ajuda a proteger contra portas de não–tronco inundando quadros marcados, um risco de segurança sério em potencial, garantindo que as portas e os vizinhos estejam em estados consistentes.

Visão Geral Operacional

O DTP é um protocolo L2 que negocia parâmetros de configuração entre uma porta de switch e seu vizinho. Ele usa outro endereço MAC multicast (01-00-0c-cc-cc-cc) e um tipo de protocolo SNAP de 0x2004. Essa tabela é um sumário dos modos de configuração:

Modo

Função

Quadros DTP Transmitidos

Estado Final (Porta Local)

Auto (padrão)

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

Sim, periódico.

Entroncamento

Ativado

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 evita que a porta crie quadros de DTP . Você deve configurar a porta vizinha 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

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 ativada, desejávelou automática .

Sim, periódico.

Termina em um estado de entroncamento apenas se o modo remoto for ativada, automáticaou desejável.

Desativado

Coloca a porta em modo de não-entroncamento permanente 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 após a alteração de ativada.

Não-entroncamento

Esses são apenas alguns pontos fortes do protocolo:

  • O DTP presume uma comunicação ponto a ponto, e os dispositivos Cisco apenas suportam as portas de tronco 802.1Q que são ponto a ponto.

  • Durante a negociação DTP, as portas não participam em STP. Apenas após a porta se tornar um dos três tipos de DTP (acesso, ISL ou 802.1Q) a porta é adicionada ao STP. Caso contrário, o PAgP, se configurado, é o processo seguinte a ser executado antes da porta participar no STP.

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

  • No modo desejável Os pacotes de DTP transferem o nome de domínio do VTP (que deve corresponder a um tronco negociado para ser exibido), mais a configuração de tronco e status administrativo.

  • As mensagens são enviadas a todo o segundo durante a negociação e a cada 30 segundos após isso.

  • Certifique-se em entender que os modos ativado, negociaçãoe desligado especificam explicitamente em qual estado a porta termina. Uma configuração inválida pode levar a um estado inconsistente/perigoso no qual um lado está fazendo o entroncamento e o outro não.

  • Uma porta em modo ativado, automáticoou desejável envia quadros de DTP periodicamente. Se uma porta em modo automático ou desejável não ver um pacote DTP em cinco minutos, ela está definida como não tronco.

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.

Recomendação

A Cisco recomenda uma configuração explícita de tronco de desejável em ambas as extremidades. Desse modo, os operadores de rede podem confiar no syslog e nas mensagens de status da linha de comando que a porta está ativada em modo de entroncamento, diferente do modo ativado que faz com que a porta apareça mesmo com os vizinhos desconfigurados. Além disso, o tronco no modo desejável oferece estabilidade em situações onde um lado do link não pode se tornar um tronco ou sai do estado de tronco. Execute este comando para determinar o modo desejável .

            
set trunk mod/port desirable ISL | dot1q
            
         

Observação: Defina o tronco como desligado em todas as portas de não-tronco. Isso ajuda a eliminar o tempo de negociação gasto ao ativar as portas de host. Esse comando também é executado quando o comando set port host é usado; consulte a seção STP para obter mais informações. Execute esse comando para desabilitar um tronco em um intervalo de portas:

            
set trunk port range off
            
               !--- As portas não estão no modo de entroncamento, parte do comando set port host.
            
         

Outras Opções

Outra configuração do cliente comum usa o modo desejável apenas na camada de distribuição e o modo de configuração padrão mais simples (automático ) na camada de acesso.

Alguns switches, como o Catalyst 2900XL, roteadores 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 negociação nos switches Catalyst 4500/4000, 5500/5000 e 6500/6000 para determinar uma porta para fazer o truncamento incondicionalmente com esses dispositivos, que podem ajudar a padronizar em uma configuração comum em todo o campus. Também é possível implementar o modo negociação Para reduzir o tempo de inicialização de link "total".

Observação: Fatores como o modo de canal e a configuração de STP também podem afetar o tempo de inicialização.

Execute este comando para determinar o modo negociação .

            set trunk mod/port nonegotiate ISL | dot1q
            
         

A Cisco recomenda negociação quando existe uma conexão com um roteador Cisco IOS porque quando a ligação é executada, alguns quadro de DTP recebidos do modo on podem voltar para a porta do tronco. Ao receber o quadro de DTP, a porta do switch tenta renegociar (ou liga e desliga o tronco) desnecessariamente. Se negociação estiver habilitado, o switch não envia quadros DTP.

Spanning Tree Protocol

Considerações básicas

O Spanning Tree Protocol (STP) mantém um ambiente L2 livre de circuito em redes redundantes comutadas e ligadas em ponte. Sem STP, os quadros estabeleceriam um loop e/ou se multiplicariam indefinidamente, provocando sobrecarga de rede, pois todos os dispositivos no domínio de broadcast seriam interrompidos continuamente pelo tráfego intenso.

Embora, em alguns aspectos, o STP seja um protocolo maduro desenvolvido inicialmente para especificações de ponte lenta com base em software (IEEE 802.1d), sua implementação em grandes redes comutadas com vários VLANs, diversos switches em um domínio, suporte a vários fornecedores e melhorias de IEEE mais recentes pode ser complexa.

Para referências futuras, o CatOS 6.x continua incorporar novos desenvolvimentos STP, como o MISTP, protetor de loop, protetores de raiz e detecção de desvio de tempo de chegada de BPDU. Além disso,protocolos mais padronizados estão disponíveis no CatOS 7.x, como o protocolo de árvore de abrangência compartilhado IEEE 802.1s e o protocolo de árvore de convergência rápida IEEE 802.1w.

Visão Geral Operacional

A eleição de ligação de raiz por VLAN é ganha pelo switch com o Identificador de ligação de raiz (BID) mais baixo. O BID é a prioridade de ponte combinada com o endereço MAC de switch.

Inicialmente, os BPDUs são enviados de todos os switches, contendo o BID de cada switch e o custo do caminho para alcançar cada switch. Isso habilita a ponte-raiz e o caminho de custo mais baixo para raiz a ser determinada. Outros parâmetros de configuração transportados da raiz em BPDUs anulam aqueles configurados localmente de maneira que toda a rede use cronômetros consistentes.

Em seguida, a topologia é convergida por meio dessas etapas:

  1. Uma única ponte-raiz é eleita para todo o domínio da árvore de abrangência.

  2. Uma porta-raiz (voltada para a ponte-raiz) é selecionada em cada ponte não-raiz.

  3. Uma porta designada é escolhida para encaminhamento de BPDU em cada segmento.

  4. As portas não designadas são bloqueadas.

Consulte Configurando Árvore de Abrangência para obter mais informações.

Padrões básicos do temporizador (segundos)

Nome

Função

2

Saudação

Controla o envio de BPDUs.

15

Forward Delay (Fwddelay)

Controla quanto tempo a porta gasta no estado de escuta e aprendizagem e influencia o processo de alteração de topologia (vide próxima seção).

20

Período máximo

Controla quanto tempo o switch mantém a topologia atual antes de procurar um caminho alternativo. Após os segundos de Maxage, um BPDU é considerado antigo e o switch procura uma nova porta raiz no pool de portas de bloqueio. Se nenhuma porta bloqueada estiver disponível, ela reivindica ser a raiz nas portas designadas.

Estados de Porta

Significado

Cronometragem padrão para o próximo estado

Desativado

Administrativamente desligado

N/A

Bloqueio

Recebendo BPDUs e interrompendo dados do usuário.

Monitora a recepção de BPDUs. Aguarde 20 segundos para a expiração de Maxage ou mudança imediata se for detectada falha de link local/direto.

Escuta

Enviar ou receber BPDUs para verificar se é necessário retornar ao bloqueio.

Temporizador fwddelayer (aguardar 15 segundos)

Aprendizagem

Criando a tabela de topologia/CAM

Temporizador fwddelayer (aguardar 15 segundos)

Encaminhamento

Envio/recepção de dados.

 
 

Alteração de topologia básica total.

20 + 2 (15) = 50 segundos se esperando o Período máximo expirar, ou 30 segundos por falha de link direto

Os dois tipos de BPDUs em STP são BPDUs de configuração e BPDUs de TCN (Notificação de alteração de topologia).

Fluxo de configuração de BPDU

Os BPDUs de configuração são originados de cada intervalo de saudação de todas as portas da ponte-raiz e subsequentemente flui para todos os switches de chapa para manter o estado da Árvore de Abrangência. No estado steady, o fluxo BPDU é unidirecional: portas de raiz e portas de bloqueio somente recebem BPDUs de configuração, enquanto portas designadas somente enviam BPDUs de configuração.

Para cada BPDU recebido por um switch da raiz, um novo é processado pelo NMP central do Catalyst e enviado contendo as informações da raiz. Em outras palavras, se a ponte-raiz se perder ou todos os caminhos da ponte-raiz estiverem perdidos, os BPDUs param de ser recebidos (até que o cronômetro de idade máxima inicie a reeleição).

Fluxo de TCN BPDU

Os TCN BPDUs são originados de switches de chapa e fluem em direção da ponte-raiz quando uma mudança de topologia é detectada na árvore de abrangência. As portas de raiz apenas enviam TCNs, e as portas designadas apenas recebem TCNs.

O BPDU de TCN segue em direção ao sulco de raiz e é reconhecido em cada passo, portanto, esse é um mecanismo confiável. Quando ele chega na ponte-raiz, a ponte-raiz alerta todo o domínio sobre a mudança que ocorreu originando os BPDUs de Configuração com o flag de TCN configurado como período máximo + tempo de fwddelay tempo (35 segundos por padrão). Isso faz com que todos os switches mudem seu tempo de envelhecimento de CAM normal de cinco minutos (por padrão) para o intervalo especificado pelo fwddelay (15 segundos por padrão). Consulte Entendendo as Mudanças de Topologia do Spanning Tree Protocol para obter mais detalhes.

Modos de árvore de abrangência

Existem três modos diferentes de correlacionar VLANs com Árvore de Abrangência:

  • Uma única árvore de abrangência para todas as VLANs, ou Spanning Tree Protocol mono, como o IEEE 802.1Q

  • Uma Árvore de Abrangência por VLAN, ou Árvore de Abrangência compartilhada, como a Cisco PVST

  • Uma Árvore de Abrangência por conjunto de VLANs, ou várias Árvores de Abrangência , como a Cisco MISTP e IEEE 802.1s

Uma árvore de abrangência mono para todas as VLANs permite apenas uma topologia ativa e portanto nenhum balanceamento de carga. Um porta bloqueada STP bloqueia todas as VLANs e não transporta dados.

Uma Árvore de Abrangência por VLAN permite o balanceamento de carga mas requer mos processamento de BPDU CPU, já que o número de VLANs aumenta. As release notes do CatOS fornecem orientação sobre o número de portas lógicas recomendadas por switch na Árvore de Abrangência. Por exemplo, o Catalyst 6500/6000 com Supervisor Engine 1 é assim:

número de portas + (número de troncos * número de VLANs em troncos) < 4000

O Cisco MISTP e o novo padrão 802.1s permite a definição de apenas duas instâncias/topologias de STP ativo, e o mapeamento de todas as VLANs para uma dessas duas árvores. Essa técnica permite que o STP escale para milhares de VLANs enquanto o balanceamento de carga estiver habilitado.

Formatos de BPDU

Para suportar o padrão IEEE 802.1Q, a implementação Cisco STP existente foi ampliada para se tornar PVST+ adicionando suporte para tunelamento na região da Árvore de Abrangência mono IEEE 802.1Q. O PVST+ é portanto compatível com os protocolos IEEE 802.1Q MST e Cisco PVST e não requer comandos ou configurações extras. Além disso, o PVST+ adiciona mecanismos de verificação para garantir que não haja inconsistência de configuração de entroncamento de porta e de IDs de VLAN entre os switches.

Esses são apenas alguns pontos fortes operacionais do protocolo PVST+:

  • O PVST+ interopera com a Árvore de Abrangência mono 802.1Q por meio da chamada Árvore de Abrangência Comum (CST) por meio de um tronco 802.1Q. O CST sempre está habilitado na VLAN 1 e portanto, a VLAN precisa estar habilitada no tronco para interoperar com outros fornecedores. Os CST BPDUs são transmitidos, sempre não-marcados, para o Grupo de Bridge Padrão IEEE (endereço MAC 01-80-c2-00-00-00, DSAP 42, SSAP 42). Para a descrição completa, um conjunto paralelo de BPDUs também é transmitido para o endereço MAC da Árvore de Abrangência compartilhada da Cisco para a VLAN 1.

  • PVST+ túneis PVST BPDUs em regiões 802.1Q VLAN como dados de multicast. Os BPDUs da Árvore de Abrangência compartilhada da Cisco são transmitidos ao endereço MAC 01-00-0c-cc-cc-cd (SNAP HDLC tipo de protocolo 0x010b) para cada VLAN em um tronco. Os BPDUs não estão marcados na VLAN nativa e estão marcados em todas as outras VLANs.

  • O PVST+ verificas as inconsistências de porta e VLAN. O PVST+ bloqueia as portas que recebem BPDUs inconsistentes para impedir loops de encaminhamento. Também notifica os usuários via mensagens de syslog sobre uma combinação mal sucedida de configuração.

  • O PVST+ tem compatibilidade retrógrada com os switches Cisco existentes executados no PVST em troncos ISL. Os BPDUs encapsulados por ISL continuam a ser transmitidos ou recebidos usando o endereço MAC IEEE. Em outras palavras, cada tipo de BPDU é um local de link - não há problemas de conversão.

Recomendação

Todos os switches Catalyst possuem o STP habilitado por padrão. Isso é recomendado mesmo de um projeto for escolhido que não inclua loops L2 de modo que o STP não esteja habilitado no sentido que esteja mantendo ativamente uma porta bloqueada.

            set spantree enable all
            
               !--- Este é o padrão.
            
         

A Cisco recomenda que o STP seja deixado desabilitado por esses motivos:

  • Se houver um loop (induzido por correção errado, cabo danificado, etc.), o STP evita os efeitos prejudiciais causados à rede pelos dados multicast e broadcast.

  • Proteção contra a interrupção de EtherChannel.

  • A maioria das redes está configurada com o STP, fornecendo o máximo de exposição de campo. Mais exposição geralmente equivale a um código estável.

  • Proteção contra erro de comportamento de NICs dual anexo (ou ligação ativada nos servidores).

  • Os softwares para muitos protocolos (como o PAgP, espionagem de IGMP e entroncamento) estão intimamente relacionados ao STP. A execução sem o STP pode levar a resultados indesejados.

Não troque os temporizadores, pois isso pode afetar a estabilidade desfavoravelmente. A maioria das redes implantadas não estão ajustadas. Os cronômetros de STP simples acessíveis por meio da linha de comando, como o intervalo de saudação e o período máximo, são formados por um complexo conjunto de outros cronômetros assumidos e intrínsecos, portanto é difícil ajustar os cronômetros e considerar todas as ramificações. Além disso, existe perigo de acabar com a proteção UDLD.

Idealmente, mantenha o tráfego de Usuário fora do gerenciamento de VLAN. Especialmente com processadores de switch Catalyst dos mais antigos, é melhor evitar problemas com STP mantendo a VLAN de gerenciamento separada dos dados do usuário. Uma estação final que se comporta mal poderia potencialmente manter o processador do engine supervisor tão ocupado com os pacotes broadcast que ele poderia perder um ou mais BPDUs. Entretanto, novos switches com CPUs mais potentes e controles de aceleração aliviam essa consideração. Consulte a seção Gerenciamento In-Band desse documento para obter mais detalhes.

Não projetar demais a redundância. É possível que isso se transforme em um pesadelo - o excesso de portas de bloqueio afetará negativamente a estabilidade a longo prazo. Mantenha o diâmetro total do SPT em sete saltos Tente projetar o modelo multicamada da Cisco, com seus domínios comutados menores, triângulos STP, e portas bloqueadas determinísticas (conforme explicado no Projeto de Rede de Campus de Gigabit — Princípios e Arquitetura) sempre que possível.

Influencia e sabe onde a funcionalidade Root e as portas bloqueadas residem, além de documentá-las no diagrama de topologia. As portas bloqueadas estão onde começa a solução dos problemas do STP - o que os fez alterar de bloquear para enviar é freqüentemente uma peça chave na análise da causa. Escolha a distribuição e as camadas principais como o local da raiz /Raiz secundária, já que essas são consideradas as partes mais estáveis da rede. Verifique L3 ótimo e sobreposição de HSRP com caminhos de encaminhamento de dados L2. Esse comando é uma macro que configura a prioridade de bridge; a raiz configura muito mais baixo que o padrão (32768), enquanto que a raiz secundária define razoavelmente mais baixo que o padrão:

            set spantree root secondary vlan range
         

Observação: Essa macro define a prioridade de raiz como 8192 (por padrão), a prioridade de raiz atual menos 1 (se outra ponte-raiz for conhecida), ou a prioridade de raiz atual (se o endereço MAC for menor que a raiz atual).

Remova os VLANs desnecessários das portas de tronco (um exercício bidirecional). Isso limita o diâmetro do STP e a sobrecarga de processamento de NMP em porções da rede onde determinadas VLANs não são necessárias. A poda de VTP automática não remove o STP de um tronco. Consulte a seçãoVTP desse documento para obter mais informações. O padrão VLAN 1 também pode ser removido de troncos usando o CatOS 5.4 e mais atual.

Consulte Problemas no Spanning Tree Protocol e Considerações Relacionadas ao Desenho para obter mais informações.

Outras Opções

A Cisco tem outro STP conhecido como bridge VLAN. Esse protocolo opera usando um endereço MAC de destino 01-00-0c-cd-cd-ce e tipo de protocolo 0x010c.

Isso é mais útil quando existe a necessidade de ligar protocolos não roteáveis ou legado entre VLANs sem interferir com a(s) instância(s) de Árvore de Abrangência IEEE executadas nessas VLANs. Se a interface VLAN com o tráfego sem ligação ficar bloqueado para o tráfego L2 (e isso pode acontecer facilmente se tiverem participado no mesmo STP como IP VLANs), a tráfego L3 de sobreposição é removido inadvertidamente também – um efeito colateral indesejado. A ponte de VLAN é, portanto, uma instância separada do STP para protocolos transpostos, fornecendo uma topologia separada que pode ser manipulada sem afetar o tráfego de IP.

A recomendação da Cisco é executar uma ponte de VLAN, caso a conexão por ponte for necessária entre VLANS em roteadores Cisco, tais como o MSFC.

PortFast

O PortFast é usado para desviar a operação da Árvore de Abrangência normal nas portas de acesso para acelerar a conectividade entre as estações finais e os serviços necessários para conectar após a inicialização do link. Em alguns protocolos, como o IPX/SPX, é importante ver a porta de acesso em modo de encaminhamento imediatamente após o estado de link ter sido ativado para evitar problemas com GNS.

ConsulteUsando Portfast e Outros Comandos para Consertar Atrasos de Conectividade de Inicialização de Estação de Trabalho para obter mais informações.

Visão Geral Operacional

O PortFast pula o estado normal escuta e aprendizagem do STP movendo uma porta diretamente do modo bloqueio para encaminhamento após saber que o link está sendo executado. Se esse recurso não estiver habilitado, o STP descarta todos os dados do usuário até decidir que a porta está pronta para ser movida para o modo encaminhamento . Isso pode levar até o dobro do tempo do ForwardDelay (um total de 30 segundos por padrão).

O modo PortFast também evita que um STP TCN seja gerado sempre que um estado de porta muda de aprendizagem para encaminhamento. Os TCNs não representam problema sozinhos, mas se uma onda de TCNs atingir a ponte-raiz (normalmente de manhã quando as pessoas ligam os PCs), isso poderia aumentar o tempo de convergência desnecessariamente.

O STP PortFast é particularmente importante nas redes CGMP multicast e Catalyst 5500/5000 MLS. Os TCNs nesses ambientes podem fazer com que as entradas de tabela CGMP CAM estáticas fiquem desatualizadas, resultando na perda de pacote de multicast até o próximo registro de IGMP e/ou a descarga de entradas de cache de MLS que então precisam ser reconstruídas e podem resultar em um aumento de CPU de roteador, dependendo do tamanho de cada cache. (implementações do Catalyst 6500/6000 MLS e entradas de multicast aprendidas do IGMP Snooping não são afetadas.)

Recomendação

A Cisco recomenda que a STP PortFast seja habilitada e todas as portas de host ativas e desabilitadas em todos as portas de link switch-switch que não estejam em uso.

O Entroncamento e a canalização também devem ser desativados em todas as portas de host. Cada porta de acesso é desativada por padrão para o entroncamento e canalização, mesmo assim vizinhos do switch não são esperados pelo desenho das portas de host. Se a negociação for deixada para esses protocolos, o atraso subseqüente na ativação das portas poderá gerar situações indesejáveis em que os pacotes iniciais das estações de trabalho, como requisições DHCP, não são encaminhados.

O CatOS 5.2 introduziu um comando macro, set port host port range , que implementa a seguinte configuração recomendada para portas de acesso e ajudará significativamente na negociação automática e no desempenho de conexão:

            set port host port range
            
            
               !--- Comando de macro para esses comandos:
            
            set spantree portfast port range enable
set trunk port range off
set port channel port range mode off
         

Observação: O PortFast não significa que a Árvore de Abrangência não está sendo executada nessas portas. Os BPDUs ainda são enviados, recebidos e processados.

Outras Opções

O protetor de BPDU de portfast oferece um modo de evitar loops movendo uma porta não-entroncamento para um estado errdisable quando um BPDU é recebido nessa porta.

Um pacote BPDU nunca deve ser recebido em uma porta de acesso configurada para PortFast, já que portas de host não devem ser anexadas a switches. Se um BPDU for observado, isso significa que uma configuração inválida e talvez perigosa necessite de uma ação administrativa. Quando o recurso protetor de BPDU é habilitado, a Árvore de Abrangência fecha as interfaces configuradas do PortFast que recebem BPDUs em vez de colocá-las no STP bloqueio .

O comando funciona em uma base por switch, e não por porta, conforme demonstrado:

            set spantree portfast bpdu-guard enable
         

O gerenciador de redes é notificado por um desvio de SNMP ou mensagem syslog, caso a porta se torne inativa. Também é possível configurar um tempo de recuperação automático para cada porta errdisable. Consulte a seçãoUDLD desse documento para obter mais detalhes. Para obter mais informações, consulte Melhoria de Protetor de BPDU Portfast de Árvore de Abrangência

Observação: O PortFast para portas de tronco foi introduzido no CatOS 7.x e não tem efeito nas portas de tronco das versões anteriores. O PortFast para portas de tronco foi projetado para aumentar os tempos de convergência das redes L3. Para complementar esse recurso, o CatOS 7.x também introduz a possibilidade de configuração do protetor de BPDU de portfast em uma base por porta.

UplinkFast

O UplinkFast fornece convergência rápida de STP após uma falha de link direto na camada de acesso da rede. Ele não modifica o STP, e sua finalidade é acelerar o tempo de convergência em um circunstância específica para menos de três segundos, em vez de o atraso típico de 30 segundos. Consulte Entendendo e Configurando o Recurso UplinkFast da Cisco para obter mais informações.

Visão Geral Operacional

Usando o modelo de desenho multicamada da Cisco na camada de acesso, se o encaminhamento de uplink se perder, o bloqueio de uplink é imediatamente movido para um estado de encaminhamento sem aguardar os estados escuta e aprendizagem .

Um grupo de uplink é um conjunto de portas por VLAN que podem ser considerados uma porta de raiz e porta de raiz de backup. Em condições normais, as portas de raiz estão assegurando conectividade a partir do acesso à raiz. Se a conexão de raiz primária falhar por algum motivo, o link raiz de backup é ativado imediatamente sem ter que passar pelos 30 segundos típicos de atraso.

Como isso efetivamente ignora o processo normal de processamento de alteração da topologia do STP (escuta e aprendizagem), um mecanismo alternativo de correção de topologia é necessário para atualizar os switches no domínio em que as estações finais possam ser alcançadas através de um caminho alternativo. Switch de camada de acesso executando o UplinkFast também gera quadros para cada endereço MAC do seu CAM para um endereço MAC de multicast (01-00-0c-cd-cd-cd, protocolo HDLC 0x200a) para atualizar a tabela CAM em todos os switches do domínio com a nova topologia.

Recomendação

A Cisco recomenda que o UplinkFast esteja habilitado para switches com portas bloqueadas, normalmente na camada de acesso. Não use switches ativados sem conhecimento da topologia implícita de um link raiz de backup (geralmente para distribuição) e dos switches de núcleo em desenhos multicamadas da Cisco. Ele pode ser adicionado sem interromper uma rede de produção. Execute este comando para ativar o UplinkFast:

            set spantree uplinkfast enable 
         

Este comando também define a prioridade da ligação como alta, para minimizar o risco de esta se tornar uma ponte raiz, e a prioridade de porta como alta, para minimizar o risco de se tornar uma porta designada, o que interromperia a funcionalidade. Ao restaurar um switch que teve o UplinkFast habilitado, o recurso deve ser desabilitado, os bancos de dados de uplink devem ser limpos com clear uplink e as prioridades de ponte devem ser restauradas manualmente.

Observação: A palavra-chave all protocols do comando UplinkFast é necessária quando o recurso de filtragem de protocolo é habilitado. Como o CAM irá registrar o tipo de protocolo, assim como as informações de MAC e VLAN, quando o filtro de protocolo estiver habilitado, um quadro de UplinkFast precisará ser gerado para cada protocolo em cada endereço MAC. A palavra-chaverate indica os pacotes por segundo dos quadros de atualização da Topologia UplinkFast. O padrão é recomendado. Não é necessário configurar o BackboneFast com o Rapid STP (RSTP) ou IEEE 802.1w já que o mecanismo é incluído nativamente e automaticamente habilitado no RSTP.

BackboneFast

O BackboneFast oferece convergência rápida das falhas de link indiretas. Com o funcionalidade adicionada para STP, os tempos de convergência podem ser normalmente reduzidos do padrão de 50 segundos para 30 segundos.

Visão Geral Operacional

O mecanismo é iniciado quando uma porta de raiz ou porta bloqueada de um switch recebe BPDUs inferiores da ponte designada. Isso pode acontecer quando um switch de downstream perde sua conexão com a raiz e começa a enviar seus próprios BPDUs para eleger uma nova raiz. Um BPDU inferior identifica um switch como ponte-raiz e como ponte designada.

Sob as regras normais de Árvore de Abrangência, o switch de recebimento ignora os BPDUs inferiores para o tempo de envelhecimento máximo configurado, 20 segundos por padrão. Entretanto, com o Backbone Fast, o switch vê o BPDU inferior como um sinal de que a topologia pode ter mudado e tenta determinar se existe um caminho alternativo para a ponte-raiz usando BPDUs de consulta RLQ. Essa adição de protocolo permite que um switch verifique se a raiz ainda está disponível, move uma porta bloqueado para encaminhamento em menos tempo, e notifica o switch isolado que enviou o BPDU inferior que a raiz ainda está lá.

Esses são apenas alguns pontos fortes do protocolo de operação

  • Um switch transmite o pacote de RLQ para a porta de raiz apenas (ou seja, em direção à ponte-raiz).

  • Um switch que recebe um RLQ pode responder se é um switch-raiz, ou se sabe se perdeu a conexão com a raiz. Se ele não souber esses fatos, ele deve encaminhar a consulta para a porta de raiz.

  • Se um switch tiver perdido a conexão com a raiz, ele deve responder a consulta negativamente.

  • A resposta deve ser enviada apenas para a porta de onde veio a consulta.

  • O switch-raiz deve sempre responder a essa consulta com uma resposta positiva.

  • Se a resposta for recebida em uma porta que não seja de raiz, ela será descartada.

Tempos de convergência STP podem portanto ser reduzidos em até 20 segundos, já que o período máximo não precisa expirar.

Consulte o documento Entendendo e Configurando o Backbone Fast em Switches Catalyst para obter mais informações.

Recomendação

A recomendação da Cisco é habilitar o BackboneFast em todos os switches que estiverem executando o STP. Ele pode ser adicionado sem interromper uma rede de produção. Execute este comando para habilitar o BackboneFast:

            set spantree backbonefast enable
         

Observação: Esse comando de nível global precisa ser configurado em todos os switches de um domínio , já que ele adiciona funcionalidade ao protocolo STP que todos os switches precisam entender.

Outras Opções

O BackboneFast não é suportado no 2900XLs e 3500s. Ele não deve ser habilitado se o domínio do switch tiver esses switches além dos switches Catalyst 4500/4000, 5500/5000 e 6500/6000.

Não é necessário configurar o BackboneFast com o Rapid RSTP ou IEEE 802.1w, já que o mecanismo é incluído nativamente e automaticamente habilitado no RSTP.

Protetor de Loop de Árvore de Abrangência

O protetor de loop é uma otimização proprietária da Cisco para o STP. O protetor de loop protege as redes L2 de loops que são causados por:

  • Mau funcionamento de interfaces de rede

  • CPUs ocupados

  • Qualquer coisa que evite o encaminhamento normal de BPDUs

Um circuito de STP ocorre quando uma porta bloqueada de STP de uma topologia redundante faz a transição erroneamente para o estado de encaminhamento. Essa transição costuma acontecer porque uma das portas de uma topologia fisicamente redundante (não necessariamente a porta de bloqueio de STP) parou de receber BPDUs de STP.

O protetor de loop só é útil em redes comutadas onde switches estão conectados por links de ponto a ponto. A maioria das redes de campus e centros de dados modernos usa esses tipos de rede. Em um link de ponto a ponto, uma bridge designada não pode desaparecer exceto se enviar um BPDU inferior ou ocorrer a queda de serviço de links. O recurso protetor de loop STP foi introduzido na versão 6.2.1 do CatOS do software Catalyst para as plataformas Catalyst 4000 e Catalyst 5000, e na versão 6.2.2 para a plataforma Catalyst 6000.

Consulte Melhorias do Spanning-Tree Protocol usando o Protetor de Circuito e Recursos de Detecção de Desvio de BPDU para obter mais informações sobre a proteção de loop.

Visão Geral Operacional

O protetor de loop verifica para determinar to determine se uma porta de raiz ou uma porta de raiz alternativa/de backup recebe BPDUs. Se a porta não receber os BPDUs, o protetor de loop coloca a porta em um estado inconsistente (bloqueio) até que a porta comece a receber BPDUs de novo. Uma porta em estado inconsistente não transmite BPDUs. Se uma porta como essa receber BPDUs de novo, a porta (e o link) são considerados viáveis de novo. A condição de inconsistência de loop é removida da porta, e o STP determina o estado da porta já que tal recuperação é automática.

O protetor de loop isola a falha e permite que a árvore de abrangência faça a convergência para uma topologia estável sem um link falho ou ponte. O protetor de loop evita que STP faça o loop com a velocidade da versão de STP em uso. Não existe dependência no STP (802.1d ou 802.1w) ou quando o os cronômetros de STP estão ajustados. Por esses motivos, implemente o protetor de loop em conjunto com o UDLD nas topologias que dependem do STP e onde o software suporte esses recursos.

Quando o protetor de circuito bloqueia uma porta inconsistente, esta mensagem é registrada:

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

Quando a BPDU é recebida em uma porta em um estado de STP de circuito inconsistente, a porta passa para outro estado de STP. De acordo com a BPDU recebida, a recuperação é automática e nenhuma intervenção é necessária. Após a recuperação, esta mensagem é registrada:

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

Interação com outros recursos de STP

  • Protetor de raiz

    O protetor de raiz força uma porta a ser designada sempre. O protetor de loop é efetivo apenas se a porta for a porta de raiz ou uma porta alternativa. Essas funções são mutuamente exclusivas. O protetor de loop e o protetor de raiz não podem ser habilitados em uma porta ao mesmo tempo.

  • UplinkFast

    O protetor de loop é compatível com o UplinkFast. Se o protetor de loop colocar uma porta de raiz em um estado de bloqueio, o UplinkFast coloca uma nova porta de raiz no estado de encaminhamento. Além disso, o UplinkFast não seleciona uma porta de loop inconsistente como porta de raiz.

  • BackboneFast

    O protetor de loop é compatível com o BackboneFast. O recebimento de um BPDU inferior enviado pela ponte designada aciona o BackboneFast. Já que os BPDUs são recebidos desse link, o protetor de loop não é ativado, então o BackboneFast e o protetor de loop são compatíveis.

  • PortFast

    O Portfast faz a transição de uma porta para o estado designado de encaminhamento imediatamente na criação do link. Já que a porta habilitada com um PortFast não pode ser uma raiz ou uma porta alternativa, o protetor de loop e o PortFast são mutuamente exclusivos.

  • PAgP

    O protetor de loop usa as portas conhecidas do STP. Portanto, o protetor de loop pode aproveitar a abstração das portas lógicas oferecidas pelo PAgP. Entretanto, para formar um canal, todas as portas físicas que estão agrupadas no canal devem ter configurações compatíveis. O PAgP reforça a configuração uniforme do protetor de loop em todas as portas físicas para formar um canal.

    Observação: Essas são advertências ao configurar um protetor de loop em um EtherChannel:

    • O STP sempre escolhe a primeira porta operacional do canal para enviar os BPDUs. Se esse link se tornar unidirecional, o protetor de loop bloqueia o canal, mesmo se os outros links do canal funcionarem adequadamente.

    • Se as portas que já estão bloqueadas pelo protetor de loop estiverem agrupadas para formar um canal, o STP perde todos as informações de estado dessas portas. A nova porta do canal pode obter o estado de encaminhamento com uma função designada.

    • Se o canal estiver bloqueado pelo protetor de loop e o canal for interrompido, o STP perde todos as informações de estado. As portas físicas individuais podem obter o estado de encaminhamento com a função designada, mesmo se um ou mais links que formaram o canal forem unidirecionais.

    Nos dois últimos casos da lista, existe uma possibilidade de um loop até o UDLD detectar a falha. Mas o protetor de loop não é capaz de detectar o loop.

Comparação de Recursos de Protetor de Loop e UDLD

A funcionalidade do protetor de loop e a funcionalidade UDLD se sobrepõem parcialmente: Os dois protegem contra falhas do STP provocadas por links unidirecionais. Mas esses dois recursos são diferentes quanto à abordagem do problema e à funcionalidade. Especificamente, determinadas falhas unidirecionais que o UDLD não pode detectar, como as falhas causadas por um CPU que não envia BPDUs. Adicionalmente, o uso de cronômetros assertivos de STP e modo RSTP podem resultar em loops antes que o UDLD possa detectar as falhas.

O protetor de loop não funciona em links compartilhados ou em situações nas quais o link é unidirecional desde a conexão. No caso do link ser unidirecional desde o linkup, a porta nunca recebe BPDUs e se torna designada. Esse comportamento pode ser normal, portanto , esse caso particular não é coberto pelo protetor de loop. O UDLD realmente oferece proteção contra tal cenário.

A ativação do protetor do UDLD e de loop proporciona o mais alto nível de proteção. Consulte a seção Protetor de loop vs. UniDirectional Link Detection de Aprimoramentos de Spanning-Tree Protocol usando Protetor de Loop e Recursos de Detecção de Desvio BPDU para uma comparação de recurso de protetor de loop e UDLD,.

Recomendação

A Cisco recomenda que você habilite o protetor de loop globalmente em uma rede de comutação com loops físicos. Na versão 7.1(1) do software Catalyst e mais atuais, é possível habilitar a proteção de circuito globalmente em todas as portas. De fato, o recurso é habilitado em todos os links de ponto a ponto. O link de ponto a ponto é detectado pelo status duplex do link. Se o duplex estiver cheio (full), o link é considerado de ponto a ponto. Execute este comando para habilitar o protetor de circuito globalmente:

            set spantree global-default loopguard enable
         

Outras Opções

Em switches que não suportam a configuração do protetor de loop global, habilite o recurso em todas as portas individuais, as quais incluem portas de canal de porta. Apesar de não haver benefícios em habilitar o protetor de loop em uma porta designada, essa habilitação não é um problema. Além disso, uma reconvergência de árvore de abrangência válida pode realmente fazer com que uma porta designada se torne uma porta de raiz, que torna o recurso útil nessa porta. Execute esse comando para habilitar o protetor de loop:

            set spantree guard loop mod/port
            
         

As redes com topologias sem loop ainda podem se beneficiar do protetor de loop caso os loops sejam introduzidos acidentalmente. Entretanto, a habilitação do protetor de loop nesse tipo de topologia pode levar a problemas de isolamento de rede. Para construir topologias sem loop e evitar problemas de isolamento de rede, execute esses comandos para desabilitar o protetor de loop globalmente ou individualmente. Não habilitar o protetor de loop em links compartilhados.

  •                   set spantree global-default loopguard disable
                      
                         !--- Esse é o padrão global.
                      
                   

    ou

  •                   set spantree guard none mod/port
                      
                      
                         !--- Essa é a configuração de porta padrão.
                      
                   

Protetor de Raiz de Árvore de Abrangência

O recurso de protetor de raiz oferece uma maneira de aplicar a colocação da ponte-raiz na rede. O protetor de raiz garante que a porta na qual o protetor de raiz está habilitado é a porta designada. Em geral, as portas de ponte raiz são todas as portas designadas, a menos que duas ou mais portas da ponte raiz estejam conectadas juntas. Se a ponte receber unidades de dados de protocolo de ponte (BPDUs) de STP em uma porta habilitada com protetor de raiz, a ponte moverá essa porta para um estado de STP com raiz inconsistente. Esse estado de raiz inconsistente é praticamente igual a um estado de escuta. Nenhum tráfego é encaminhado por essa porta. Dessa forma, o protetor de raiz estabelece a posição da ponte raiz. O root guard está disponível no CatOS para Catalyst 29xx, 4500/4000, 5500/5000 e 6500/6000 em versão 6.1.1 e posteriores.

Visão Geral Operacional

O protetor de raiz é um mecanismo de STP embutido. O protetor de raiz não tem um cronômetro próprio e depende da recepção do BPDU apenas. Quando o protetor de raiz é aplicado a uma porta e o protetor de raiz não permite que uma porta se torne uma porta de raiz. Se o recebimento de um BPDU acionar uma convergência de árvore de abrangência que faça uma porta designada se tornar uma porta de raiz, a porta é colocada em um estado de estado inconsistente de raiz. Essa mensagem de syslog exibe a ação:

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

Após a porta parar de enviar BPDUs superiores, a porta é desbloqueada novamente. Por meio do STP, a porta vai do estado de escuta para o estado de reconhecimento e, por fim, transita para o estado de encaminhamento. A recuperação é automática; não é necessária nenhuma intervenção humana. Essa mensagem de syslog fornece um exemplo:

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

O protetor de loop força uma porta a ser designada e o protetor de loop é efetivo apenas se a porta for a porta de raiz ou uma porta alternativa. Portanto, as duas funções são mutuamente exclusivas. O protetor de loop e o protetor de raiz não podem ser habilitados em uma porta ao mesmo tempo.

Consulte Melhoria de Protetor de Raiz do Spanning Tree Protocol para obter mais informações.

Recomendação

A Cisco recomenda que você ative o recurso de protetor de raiz nas portas que se conectam aos dispositivos de rede que não estão sob controle administrativo direto. Para configurar o protetor de raiz, execute esse comando:

            set spantree guard root mod/port
            
         

EtherChannel

As tecnologias EtherChannel permitem multiplexação inverso de canais múltiplos (até oito no Catalyst 6500/6000) em um único link lógico. Embora cada plataforma se diferencie da próxima em implementação, é importante entender os requisitos em comum:

  • Um algoritmo para fazer a multiplexação estatística de quadros em vários canais.

  • Criação de portas lógicas para que uma instância única de STP possa ser executada

  • Um gerenciamento de protocolo de canal, como o PAgP ou Link Aggregation Control Protocol (LACP)

Multiplexação de Estrutura

O EtherChannel inclui um algoritmo de distribuição de quadros que multiplexa eficazmente os quadros entre o componente 10/100 ou links Gigabit. As diferenças de algoritmos por plataforma surgem da capacidade de cada tipo de hardware em extrair informações do cabeçalho de quadro para fazer a decisão de distribuição.

O algoritmo de distribuição de carga é uma opção global para os protocolos de canal-controle. O PAgP e o LACP usam o algoritmo de distribuição de quadro porque o padrão IEEE não obriga qualquer algoritmo de distribuição em particular. Entretanto, todo algoritmo de distribuição garante que, quando as estruturas são recebidas, o algoritmo não causa ao má ordenação dos quadros que são parte de qualquer determinada conversação ou duplicação de quadros.

Observação: Essas informações devem ser consideradas:

  • O Catalyst 6500/6000 possui hardware de switching mais recente que o Catalyst 5500/5000 e pode lêr as informações do IP Camada 4 (L4) em taxa de fios para fazer uma decisão de multiplexação mais inteligente que as informações MAC L2 simples.

  • As capacidades do Catalyst 5500/5000 dependem da presença de um Ethernet Bundling Chip (EBC) no módulo. O comandoshow port capabilities mod/port confirma o que é possível para cada porta.

Consulte essa tabela, a qual ilustra o algoritmo de distribuição de quadro no detalhe de cada plataforma listada:

Plataforma

Algoritmo de Balanceamento de Carga de Canal

Catalyst séries 5500/5000

Um Catalyst 5500/5000 com os módulos necessários permite que dois a quatro links estejam presentes por FEC1, mas terão que estar no mesmo módulo. Os pares de endereços MAC de origem e de destino determinam o link escolhido para o encaminhamento de quadros. Uma operação X-OR é executada nos dois bits menos significativos do endereço de origem MAC e do endereço de destino MAC. Essa operação resulta um dos quatro resultados: (0 0), (0 1), (1 0), ou (1 1). Cada um desses valores aponta para um link no pacote FEC. No caso de um canal de duas portas Fast EtherChannel, apenas um único bit é usado na operação X-OR. Podem ocorrer circunstâncias onde um endereço no par origem/destino é uma constante. Por exemplo, o destino pode ser um servidor ou, mais provavelmente, um roteador. Nesse caso, você ainda verá o balanceamento de carga estatístico, já que o endereço de origem é sempre diferente.

Catalyst séries 4500/4000

O EtherChannel Catalyst 4500/4000 distribui quadros ao longo dos links em um canal (em um módulo único) com base nos bits de ordem baixa da origem dos endereços MAC (Controle de acesso de mídia) de origem e destino de cada quadro. Em comparação com o Catalyst 5500/5000, o algoritmo é mais envolvido e usa um hash determinístico desses campos do MAC DA (bytes 3, 5, 6), SA (bytes 3, 5, 6), porta de ingresso e VLAN ID. O método de distribuição de quadro não é configurável.

Catalyst 6500/6000 Series

Existem dois possíveis algoritmos de hashing, dependendo do hardware do Supervisor Engine. O hash é um polinômio de décimo sétimo grau implementado no hardware que, em todos os casos, pega o número de porta do endereço MAC, endereço IP, ou IP TCP/UDP2 e aplica o algoritmo para gerar um valor de três bits. Isso é feito separadamente nos endereços de origem e destino. Os resultados são então XORd para gerar outro valor de três bits usado para determinar qual porta no canal é usada para encaminhar o pacote. Os canais do Catalyst 6500/6000 podem ser formados entre as portas de qualquer módulo e podem ter até 8 portas.

1 FEC = Fast EtherChannel

2 UDP = Protocolo de Datagrama de Usuário

Essa tabela indica os métodos de distribuição suportados nos vários modelos do Catalyst 6500/6000 Supervisor Engine e seu comportamento padrão.

Hardware

Descrição

Métodos de Distribuição

WS F6020 (Engine L2)

Supervisor Engine Antecipado 1

L2 MAC: SA; DA; SA e DA

WS F6020A (Engine L2)

WS-F6K-PFC (Engine L3)

Supervisor Engine Antecipado 1 e Supervisor Engine 1A/PFC1

L2 MAC: SA; DA; SA e DA

L3 IP: SA; DA; SA e DA (padrão)

WS-F6K-PFC2

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

L2 MAC: SA; DA; SA e DA

L3 IP: SA; DA; SA e DA (padrão)

Sessão L4: Porta S; porta D; porta S e D (padrão)

WS-F6K-PFC3BXL

WS-F6K-PFC3B

WS-F6K-PFC3A

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

Supervisor Engine 720/Supervisor Engine 32/PFC3B (necessita CatOS 8.4.x)

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

L2 MAC: SA; DA; SA e DA

L3 IP: SA; DA; SA e DA (padrão)

Sessão L4: Porta S; porta D; porta S e D

Sessão IP-VLAN-L4: Porta SA e VLAN e S; porta DA e VLAN e D; porta SA e DA e VLAN e S e porta D

Observação: Com a distribuição L4, o primeiro pacote fragmentado usa a distribuição L4. Todos os pacotes subseqüentes usam distribuição L3.

Maiores detalhes do suporte EtherChannel em outras plataformas e como configurar e solucionar problemas podem ser encontrados nestes documentos:

Recomendação

Os Catalyst 6500/6000 Series Switches realizam balanceamento de carga por endereço de IP por padrão. Isso é recomendado no CatOS 5.5, supondo que o IP seja o protocolo dominante. Execute este comando para definir o balanceamento de carga:

            set port channel all distribution ip both
            
               !--- Este é o padrão.
            
         

A distribuição de quadro das séries Catalyst 4500/4000 e 5500/5000 por endereço L2 MAC é aceitável na maioria das redes. No entanto, o mesmo link é usado para todo o tráfego se houver somente dois dispositivos principais conversando em um canal (como SMAC e DMAC são constantes). Isso pode ser tipicamente um problema para backup de servidor e outras grandes transferências de arquivos ou para um segmento de transição entre dois roteadores.

Embora a porta lógica agregada (agport) possa ser gerenciada pelo SNMP como uma instância separada e agregar estatísticas de throughput coletadas, a Cisco ainda recomenda o gerenciamento de cada uma das interfaces físicas separadamente para verificar como os mecanismos de distribuição de quadro estão funcionando e se o número de carregamentos está equilibrado.

Um novo comando, o comando show channel traffic, no CatOS 6.x, pode exibir as estatísticas de distribuição em porcentagem de maneira mais fácil do que ocorre com a verificação de contadores de porta individualmente com o comando show counters mod/port ou o comando show mac mod/port no CatOS 5.x. Um outro novo comando, o comando show channel hash, no CatOS 6.x permite a verificação, baseado no modo de distribuição, de qual porta seria selecionada como a porta de saída de certos endereços e/ou números de porta. Os comandos equivalentes para os canais LACP são os comandos show lacp-channel traffic e show lacp-channel hash.

Outras Opções

Há alguns passos possíveis para seguir se as limitações relativas do Catalyst 4500/4000 ou Catalyst 5500/5000 MAC baseados em algoritmos forem um problema e se o balanceamento de carga estatístico não for alcançado:

  • Switches de ponto de distribuição Catalyst 6500/6000

  • Aumentar a largura de banda sem canalização por switching, por exemplo, de várias portas FE a uma porta GE, ou de várias portas GE a uma porta 10 GE

  • Endereçar novamente pares de estações finais com grandes fluxos de volume

  • Provisão de links dedicados/VLANs para dispositivos de alta largura de banda

Restrições e Diretrizes de Configuração de EtherChannel

O EtherChannel verifica as propriedades de portas em todas as portas físicas antes de agregar portas compatíveis em uma única porta lógica. As diretrizes e restrições de configuração se diferenciam para as diversas plataformas de comutação. Siga as diretrizes para evitar problemas de empacotamento. Por exemplo, se o QoS estiver habilitado, os EtherChannels não serão formados quando os módulos de switching do Catalyst 6500/6000 Series forem empacotados com diferentes capacidades de QoS. No Cisco IOS Software, você pode desativar a verificação de atributo de porta QoS no empacotamento de EtherChannel com o comando de interface de canal de porta no mls qos channel-consistency. Um comando equivalente para desativar a verificação de atributo de porta de QoS não está disponível no CatOS. Você pode executar o comando show port capability mod/port para exibir a capacidade da porta QoS e determinar se as portas são compatíveis.

Siga estas diretrizes para diferentes plataformas para evitar problemas de configuração:

Observação: O número máximo de canais da porta que o Catalyst 4000 suporta é 126. Com as versões 6.2(1) e anteriores, os switches de seis e nove slots da série Catalyst 6500 suporta um máximo de 128 EtherChannels. Na versão 6.2(2) e posteriores do software, o recurso árvore de abrangência processa o ID da porta. Portanto, o número máximo de EtherChannels com suporte é 126 para chassi com seis ou nove slots e 63 para um chassi com 13 slots.

Port Aggregation Protocol

PAgP é um protocolo de gerenciamento que verifica a consistência de parâmetro em cada fim de link e ajuda o canal a adaptar a falha ou adição de link. Observe estes fatos sobre o PAgP:

  • O PagP exige que todas as portas no canal pertençam ao mesmo VLAN ou que estejam configuradas como portas de tronco. (Como os VLANs dinâmicos podem forçar a alteração de uma porta em um VLAN diferente, eles não estão incluídos na participação EtherChannel).

  • Quando um pacote já existe e a configuração em uma porta é modificada (por exemplo, alterando a VLAN ou o modo de entroncamento), todas as portas do pacote são modificadas para corresponderem à configuração existente.

  • O PagP não agrupa portas que operam em diferentes velocidades ou em portas bidirecionais. Se a velocidade e a porta bidirecional forem alteradas quando houver um pacote, o PAgP altera a velocidade e a porta bidirecional no pacote.

Visão Geral Operacional

A porta de PAgP controla cada porta física individual (ou lógica) a ser agrupada. Os pacotes de PagP são enviados usando o mesmo grupo de endereço MAC multicast usado pelos pacotes, 01-00-0c-cc-cc-cc. O valor do protocolo é 0x0104. Este é um sumário da operação do protocolo:

  • Desde que a porta física esteja ativa, os pacotes de PAgP serão transmitidos a cada segundo durante a detecção e a cada 30 segundos no estado steady.

  • O protocolo ouve pacotes PAgP que provam que a porta física tem uma conexão bidirecional com outro dispositivo com capacidade para PAgP.

  • Se forem recebidos pacotes de dados em vez dos pacotes PAgP, supõe-se que a porta está conectada a um dispositivo sem capacidade para PAgP.

  • Assim que dois pacotes PAgP tenham sido recebidos em um grupo de portas físicas, ele tenta formar uma porta agregada.

  • Se os pacotes PAgP forem interrompidos por um período, o estado do PAgP será desativado.

Processamento Normal

Este conceitos devem ser definidos para ajudar a entender o comportamento do protocolo:

  • Agport—uma porta lógica composta de todas as portas físicas na mesma agregação, pode ser identificada por seu próprio SNMP ifIndex. Portanto, uma agport não contém portas não-operacionais.

  • Canal—uma agregação que cumpre o critério de formação; ele pode conter, portanto, portas não-operacionais (as agports são um subconjunto dos canais). Protocolos, incluindo o STP e o VTP, mas excluindo o CDP e o DTP, executam o PAgP acima por meio das agports. Nenhum desses protocolos poderá enviar ou receber pacotes até que o PAgP conecte as respectivas agports a uma ou mais portas físicas.

  • Capacidade do Grupo—cada porta física e agport possui um parâmetro de configuração chamado a capacidade de grupo. Uma porta física poderá ser agregada a outra porta física se e somente se essas portas tiverem a mesma capacidade de grupo.

  • Procedimento de Agregação—quando uma porta física alcança os estados UpData ou UpPAgP , ela é anexada a uma agport apropriada. Quando ela deixa um desses estados para um outro estado, ela é separada da agport.

As definições dos estados e os procedimentos de criação são dados nesta tabela:

Estado

Significado

UpData

Não foram recebidos pacotes PAgP. Foram enviados pacotes PAgP A porta física é a única conectada à agport. Os pacotes não-PAgP foram passados pela porta física e a agport.

BiDir

Foi recebido exatamente um pacote PAgP, o que prova que existe uma conexão bidirecional com exatamente um vizinho. A porta física não está conectada a uma agport. Os pacotes PAgP são enviados e podem ser recebidos.

UpPAgP

Esta porta física, talvez em associação com outras portas físicas, é conectada a uma agport. Os pacotes PAgP são enviados e recebidos na porta física. Os pacotes não-PAgP foram passados pela porta física e a agport.

As duas extremidades das conexões devem concordar sobre que agrupamento será definido como o maior grupo de portas do agport permitido pelas duas extremidades da conexão.

Quando uma porta física alcança o estado UpPAgP , é atribuída a agport que tem portas físicas membros que correspondem à capacidade de grupo da nova porta física e que estão nos estados BiDir ou UpPAgP . (As portas BiDir são movidas para o estado UpPAgP na mesma hora.) Se não houver nenhum agport cujos parâmetros de porta física do componente sejam compatíveis com a porta física recém-preparada, será atribuído a um agport com parâmetros adequados e que não esteja associado a portas físicas.

Pode ocorrer uma expiração de PAgP no último vizinho conhecido na porta física. O intervalo da porta é removido da agport. Ao mesmo tempo, todas as portas físicas na mesma agport cujos temporizadores que também tem intervalos forem removidos. Isso ativa uma agport cuja extremidade tenha sido desativada de uma vez só, em vez de uma porta física por vez.

Comportamento de Falha

Se um link em um canal existente falhar, (por exemplo, port desconectada, Conversor de Interface de Gigabit [GBIC] removido ou filamento quebrado), a agport é atualizada e o tráfego é misturado nos links remanescentes dentro de um segundo. Qualquer tráfego que não necessite ser misturado novamente após a falha (o tráfego que continua a enviar no mesmo link) não sofre qualquer perda. A restauração do link com falha dispara outra atualização à agport e o tráfego é misturado novamente.

Observação: O comportamento quando um link falha em um canal devido a um desligamento ou remoção do módulo pode ser diferente. Por definição, há a necessidade da existência de duas portas em um canal. Se uma porta for perdida no sistema em um canal de duas portas, o agport lógico cai e a porta física original é reinicializada com relação à árvore de abrangência. Isso significa que o tráfego pode ser descartado até que o STP permita que a porta se torne disponível para dados novamente.

Há uma exceção a esta regra no Catalyst 6500/6000. Em versões anteriores a CatOS 6.3, uma agport não é desativada durante a remoção do módulo se o canal for composto de portas apenas nos módulos 1 e 2.

Esta diferença nos dois modos de falha é importante quando a manutenção de uma rede é planejada, já que pode haver um STP TCN a considerar na realização de uma remoção e inserção on-line de um módulo. Como declarado, é importante gerenciar cada link físico no canal com o NMS desde que a agport possa permanecer sem perturbação durante uma falha.

Os passos sugeridos para mitigar uma alteração de topologia não desejada no Catalyst 6500/6000 são os seguintes:

  • Se uma porta simples for usada por módulo para formar um canal, três ou mais módulos deverão ser usados (total de três ou mais portas).

  • Se o canal abranger dois módulos, duas portas em cada módulo deverão ser utilizadas (total de quatro portas).

  • Se um canal de duas portas for necessário por duas placas, use apenas as portas do Supervisor Engine.

  • Atualize para o CatOS 6.3, que processa a remoção de módulo sem o recálculo de STP para canais divididos por módulos.

Opções de configuração

Os EtherChannels podem ser configurados em diferentes modos, como resumido nesta tabela:

Modo

Opções Configuráveis

Ativado

O PAgP não está funcionando. A porta está sendo canalizada independente de como a porta do vizinho está configurada. Se a porta do vizinho estiver ativada, está formado um canal

Desativado

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

Auto (padrão)

A agregação está sob controle do protocolo PAgP. Coloca uma porta do estado de negociação passiva, e nenhum pacote PAgP é enviado à interface até que pelo menos um pacote PAgP seja recebido de volta indicando que o remetente está operando em um modo. desejável .

Desejável

A agregação está sob controle do protocolo PAgP. Coloca uma porta do estado de negociação ativa, no qual a porta inicia negociações com outras portas pelo envio de pacotes PAgP. Um canal é formado com outro grupo que esteja no modo desejável ou auto.

Não-silencioso (padrão nas portas de fibra FE e GE do Catalyst 5500/5000)

Uma palavra-chave de modo auto ou desejável . Se não forem recebidos pacotes de dados na interface, esta nunca será anexada a uma agport e não pode ser usada para dados. Esta verificação de bidirecionalidade foi fornecida para o hardware do Catalyst 5500/5000 específico já que algumas falhas de link resultam em separação do canal. Como o modo não-silencioso está habilitado, uma porta do vizinho de recuperação nunca é permitida a voltar e separar o canal desnecessariamente. O empacotamento mais flexível e as verificações de bidirecionalidade aperfeiçoadas são apresentadas por padrão no hardware da série Catalyst 4500/4000 e 6500/6000.

Silencioso (padrão em todas as portas do Catalyst 6500/6000e 4500/4000 e nas portas de cobre 5500/5000)

Uma palavra-chave de modo auto ou desejável . Se não forem recebidos pacotes de dados na interface, após um período de expiração de 15 segundos, a interface será anexada sozinha a uma agport e poderá ser usada para transmissão de dados. O modo Silencioso também permite a operação de canais quando o parceiro puder ser um analisador ou servidor que nunca envie PAgP.

As configurações silencioso/não-silencioso afetam como as portas reagem às situações que causam tráfego unidirecional ou como eles alcançam failover. Quando uma porta não consegue transmitir (por causa de uma camada subfísica com falha [PHY] ou um filamento ou cabo quebrado, por exemplo), isso ainda pode deixar a porta do vizinho em estado operacional. O parceiro continua a transmitir dados, mas eles são perdidos, pois o tráfego de retorno não pode ser recebido. Também podem ser formados loops da árvore de abrangência devido à natureza unidirecional do link.

Algumas portas de fibra têm a capacidade desejada de colocar a porta em um estado não-operacional quando ela perde seu sinal de recepção (FEFI). Isso faz com que a porta do parceiro fique em estado não-operacional e causa efetivamente a desativação das portas em ambas as extremidades.

Quando usar dispositivos que transmitem dados (como BPDUs) e não puder detectar condições unidirecionais, o modo não-silencioso deve ser usado para permitir que as portas permaneçam não-operacionais até que os dados recebidos sejam apresentados e o link seja verificado como sendo bidirecional. O tempo gasto pelo PAgP para detectar um link unidirecional fica por volta de 3,5 * 30 segundos = 105 segundos é o tempo entre duas mensagens sucessivas de PAgP. O UDLD é recomendado como um detector mais rápido para links unidirecionais.

Quando usar dispositivos que não transmitam dados, o modo silencioso deve ser usado. Isto força a porta a se tornar conectada e operacional independente de se dos dados recebidos foram apresentados ou não. Adicionalmente, para as portas que podem detectar a presença de uma condição unidirecional, como as plataformas mis novas usando L1 FEFI e UDLD, o modo silencioso será usado por padrão.

A Verificação

é uma tabela que representa um sumário de todos os cenários de modo de canalização PAgP possíveis entre dois switches diretamente conectados (Switch A e Switch B). Algumas dessas combinações podem fazer com que o STP coloque as portas no lado da canalização no estado errdisable (ou seja, algumas dessas combinações fecham as portas no lado da canalização).

Modo de Canal Switch-A

Modo de Canal Switch-B

Estado de Canal

Ativado

Ativado

Canal (não-PAgP)

Ativado

Desativado

Não Canal (errdisable)

Ativado

Auto

Não Canal (errdisable)

Ativado

Desejável

Não Canal (errdisable)

Desativado

Ativado

Não Canal (errdisable)

Desativado

Desativado

Não Canal

Desativado

Auto

Não Canal

Desativado

Desejável

Não Canal

Auto

Ativado

Não Canal (errdisable)

Auto

Desativado

Não Canal

Auto

Auto

Não Canal

Auto

Desejável

Canal PAgP

Desejável

Ativado

Não Canal (errdisable)

Desejável

Desativado

Não Canal

Desejável

Auto

Canal PAgP

Desejável

Desejável

Canal PAgP

Recomendação

A Cisco recomenda que o PAgP seja habilitado em todas as conexões de canal switch a switch, evitando o modo ativado . O método preferido é definir o modo desejável em ambas as extremidades de um link. A recomendação adicional é deixar a palavra-chave silencioso/não-silencioso no padrão - silencioso nos switches Catalyst 6500/6000 e 4500/4000, não-silencioso nas portas de fibra do Catalyst 5500/5000.

Conforme discutido neste documento, a configuração explícita de canalização desligada em todas as outras portas é útil para o rápido encaminhamento de dados. Tente evitar aguardar até 15 segundos pela expiração de PAgP em uma porta que não será usada para canalização, especialmente porque a porta será transferida ao STP, que por si só pode levar 30 segundos para possibilitar o encaminhamento de dados, além de 5 segundos potenciais para DTP, somando um total de 50 segundos. O comando set port host será discutido mais detalhadamente na seção STP deste documento.

            set port channel port range mode desirable
            
set port channel port range mode off
            
               !--- Portas não canalizadas; parte do comando set port host.
            
         

Esse comando atribui aos canais um número de grupo de administração que pode ser visto com um comando show channel group. A inclusão e a remoção de portas de canalização na mesma agport podem então ser gerenciadas com a consulta ao número de administração, se desejado.

Outras Opções

Uma outra configuração comum para os clientes que tenham um modelo de administração mínima no camada de acesso tem o modo definido para desejável nas camadas de distribuição e de centro e deixa os switches da camada de acesso na configuração padrão auto .

Quando a canalização de dispositivos não suporta o PAgP, o canal não necessita estar com a codificação ativada. Isso se aplica a dispositivos como servidores, Local Director, switches de conteúdo, roteadores, switches com software mais antigo, switches Catalyst XL e Catalyst 8540s. Execute este comando:

            set port channel port range mode on
         

O novo padrão LACP 802.3ad IEEE, disponível no CatOS 7.x, provavelmente substituirá o PAgP no longo prazo, pois ele oferece o benefício da interoperabilidade entre plataformas e fornecedores.

Link Aggregation Control Protocol

O LACP é um protocolo que permite que as portas com características similares formem um canal pela negociação dinâmica com switches adjacentes. O PAgP é um protocolo de propriedade da Cisco que só pode ser executado nos switches da Cisco vendidos por fornecedores licenciados. Mas o LACP, que é definido no IEEE 802.3ad, permite que os switches da Cisco gerenciem a canalização de Ethernet com dispositivos que cumprem a especificação 802.3ad. As versões do software CatOs 7.x introduziram o suporte a LACP.

Há pouca diferença entre o LACP e o PAgP de uma perspectiva funcional. Ambos os protocolos suportam um máximo de oito portas em cada canal e as mesmas propriedades de porta são verificadas antes da formação do conjunto. Estas propriedades de porta incluem:

  • Velocidade

  • Duplex

  • VLAN nativo

  • Tipo de Entroncamento

As diferenças notáveis entre o LACP e o PAgP são:

  • O LACP só pode ser executado em portas full-duplex e o LACP não suporta portas meio-duplex.

  • O LACP suporta portas em standby recente. O LACP sempre tenta configurar o número máximo de portas compatíveis em um canal, até o número máximo permitido pelo hardware (oito portas). Se o LACP não for capaz de agregar todas as portas compatíveis, todas as portas que não podem ser ativamente incluídas no canal são colocadas no estado de standby recente e usadas apenas se uma das portas usadas falhar. Um exemplo de situação em que um LACP não pode agregar todas as portas compatíveis é se o sistema remoto tiver limitações de hardware mais restritivas.

Observação: No CatOS, o número máximo de portas que a mesma chave administrativa pode ser atribuída é oito. No Cisco IOS Software, O LACP sempre tenta configurar o número máximo de portas compatíveis em um EtherChannel, até o número máximo permitido pelo hardware (oito portas). Oito portas adicionais podem ser configuradas como portas em espera recente.

Visão Geral Operacional

O LACP controla cada porta física individual (ou lógica) a ser empacotada. Os pacotes de LACP são enviados usando o mesmo grupo de endereço MAC multicast usado pelos pacotes, 01-80-c2-00-00-02. O valor do tipo/campo é 0x8809 com um sub-tipo de 0x01. Aqui está um sumário da operação de protocolo:

  • O protocolo depende dos dispositivos para anunciar as capacidades de agregação e as informações de estado. As transmissões são enviadas com base regular e periódica em cada link "agregável".

  • Desde que a porta física esteja ativa, os pacotes de LACP serão transmitidos a cada segundo durante a detecção e a cada 30 segundos no estado steady.

  • Os parceiros em um link "agregável" escutam as informações que são enviadas dentro do protocolo e decidem as ações a serem adotadas.

  • As portas compatíveis são configuradas em um canal, até o número máximo permitido pelo hardware (oito portas).

  • As agregações são mantidas pelo intercâmbio regular, em tempo hábil, de informações atualizadas entre os parceiros de link. Se a configuração mudar (devido à falha de link, por exemplo),os parceiros de protocolo expiram e adotam a ação com base no novo estado do sistema.

  • Além das transmissões da unidade de dados de LACP periódico (LACPDU), se houver uma mudança nas informações de estado, o protocolo transmite um LACPDU orientado por evento ao parceiro. Os parceiros de protocolo adotam as ações necessárias com base no novo estado do sistema.

Parâmetros de LACP

Para permitir que o LACP determine se um conjunto de links se conectem ao mesmo sistema e se esses links são compatíveis do ponto de vista de agregação, a capacidade de estabelecer esses parâmetros é necessária:

  • Um identificador mundialmente exclusivo para cada sistema que participa da agregação de link

    A cada sistema que executa o LACP deve ser atribuída uma prioridade que pode ser escolhida automaticamente ou pelo administrador. A prioridade padrão do sistema é 32768. A prioridade do sistema é usada principalmente em conjunto com o endereço MAC do sistema para formar o identificador do sistema.

  • Um meio de identificação do conjunto de capacidades que são associadas a cada porta e a cada agregador, conforme entendido por um determinado sistema

    A cada porta do sistema deve ser atribuída uma prioridade que pode ser escolhida automaticamente ou pelo administrador. O padrão é 128. A prioridade é usada em conjunto com o número da porta para formar o identificador da porta.

  • Um meio de identificação de um grupo de agregação de link e seu agregador associado

    A capacidade de uma porta em agregar a outra é resumida por um simples parâmetro de 16-bits inteiros estritamente maior que zero. Esse parâmetro é chamado de "chave". Fatores diferentes determinam cada chave, como:

    • Características físicas da porta, que incluem:

      • Taxa de dados

      • Duplexidade

      • Ponto-a-ponto ou meio compartilhado

    • Restrições de configuração que o administrador da rede determina.

    Duas chaves estão associadas a cada porta:

    • Uma chave administrativa—Essa chave permite a manipulação dos valores de chave pela gerência. Um usuário pode escolher essa chave.

    • Uma chave operacional—O sistema usa essa chave para formar agregações. Um usuário não pode escolher ou mudar essa chave diretamente.

      O conjunto de portas em um sistema que compartilha o mesmo valor de chave operacional é considerado membro do mesmo grupo de chave.

Se você tem dois sistemas e um conjunto de portas com a mesma chave administrativa, cada sistema tenta agregar as portas. Cada sistema inicia da porta com a prioridade mais alta no sistema de prioridade mais alto. Esse comportamento é possível porque cada sistema sabe a sua própria prioridade, a qual o usuário ou sistema atribuiu, e a prioridade do seu parceiro, a qual foi descoberta por meio de pacotes LACP.

Comportamento de Falha

O comportamento de falha do LACP é igual ao comportamento de falha do PAgP. Se um link em um canal existente falhar, a agport é atualizada e o tráfego é misturado nos links remanescentes dentro de um segundo. Um link pode falhar por esses e por outros motivos:

  • Uma porta é desconectada.

  • Um GBIC é removido

  • Uma fibra é quebrada

  • Falha de hardware (interface ou módulo)

Qualquer tráfego que não necessite ser misturado novamente após a falha (o tráfego que continua a enviar no mesmo link) não sofre qualquer perda. A restauração do link com falha dispara outra atualização à agport e o tráfego é misturado novamente.

Opções de configuração

Os LACP EtherChannels podem ser configurados em 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 o modo da porta vizinha for on, um canal é formado

Desativado

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

Passivo (padrão)

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

Ativo

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

Verificação (LACP e LACP)

A tabela dessa seção representa um sumário de todos os cenários de modo de canalização LACP possíveis entre dois switches diretamente conectados (Switch A e Switch B). Algumas dessas combinações podem fazer com que o STP coloque as portas no lado da canalização no estado errdisable . Ou seja, algumas dessas combinações fecham as portas no lado da canalizaçã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

Ativo

Não Canal (errdisable)

Não Canal

Desativado

Desativado

Não Canal

Não Canal

Desativado

Passivo

Não Canal

Não Canal

Desativado

Ativo

Não Canal

Não Canal

Passivo

Passivo

Não Canal

Não Canal

Passivo

Ativo

Canal LACP

Canal LACP

Ativo

Ativo

Canal LACP

Canal LACP

Verificação (LACP e PAgP)

A tabela seguinte representa um sumário de todos os cenários de modo de canalização LACP para PAgP possíveis entre dois switches diretamente conectados (Switch A e Switch B). Algumas dessas combinações podem fazer com que o STP coloque as portas no lado da canalização no estado errdisable . Ou seja, algumas dessas combinações fecham as portas no lado da canalizaçã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-PAgP)

Ativado

Desativado

Não Canal (errdisable)

Não Canal

Ativado

Auto

Não Canal (errdisable)

Não Canal

Ativado

Desejável

Não Canal (errdisable)

Não Canal

Desativado

Ativado

Não Canal

Não Canal (errdisable)

Desativado

Desativado

Não Canal

Não Canal

Desativado

Auto

Não Canal

Não Canal

Desativado

Desejável

Não Canal

Não Canal

Passivo

Ativado

Não Canal

Não Canal (errdisable)

Passivo

Desativado

Não Canal

Não Canal

Passivo

Auto

Não Canal

Não Canal

Passivo

Desejável

Não Canal

Não Canal

Ativo

Ativado

Não Canal

Não Canal (errdisable)

Ativo

Desativado

Não Canal

Não Canal

Ativo

Auto

Não Canal

Não Canal

Ativo

Desejável

Não Canal

Não Canal

Recomendação

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 active em ambas as extremidades do dispositivo. Se uma extremidade dos dispositivos não suportar LACP ou PAgP, você precisa codificar o canal para ativado.

  •                   set channelprotocol lacp module
                      
                   

    Em switches que executam o CatOS, todas as portas de um Catalyst 6500/6000 utilizam o protocolo de canal PAgP por padrão e, dessa forma, não estão executando o LACP. Para configurar as portas para usar o LACP, você precisa 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.

  •                   set port lacp-channel port_range
                         admin-key
                      
                   

    Um parâmetro chave admin (chave administrativa) é intercambiado no pacote LACP. Um canal se forma somente entre portas que possuem a mesma chave de administrador. O comando set port lacp-channel port_range admin-key atribui aos canais a um número de chave admin. O comando show lacp-channel group exibe o número. O comando set port lacp-channel port_range admin-key atribui a mesma chave admin a todas as portas do intervalo de porta. A chave admin é atribuída aleatoriamente se uma chave específica não estiver configurada. Portanto, é possível se referir à chave admin, se desejado, para gerenciar a inclusão e a remoção de portas de canalização na mesma agport.

  •                   set port lacp-channel port_range mode active
                   

    O comando set port lacp-channel port_range mode active altera o modo de canal para ativo para um conjunto de portas que foram previamente atribuídas à mesma chave admin.

Além disso, o LACP utiliza um cronômetro de intervalo de 30 segundos (Slow_Periodic_Time) após os EtherChannels de LACP estarem estabilizados. O número de segundos antes da invalidação de informação LACPDU recebida com o uso de expirações longas (3 x Slow_Periodic_Time) é 90. Use UDLD, que é um detector mais rápido de links unidirecionais. Não é possível ajustar os temporizadores de LACP, a atualmente não é possível configurar os switches para usar a transmissão de PDU rápida (cada segundo) para manter o canal após o canal estar formado.

Outras Opções

Se você tem um modelo de administração mínima da camada de acesso, uma configuração comum é definir o modo como ativo nas camadas de distribuição e central. Deixe os switches da camada de acesso na configuração padrão passivo .

UniDirectional Link Detection

O UDLD é um protocolo leve proprietário da Cisco que foi desenvolvido para detectar instâncias de comunicações unidirecionais entre os dispositivos. Apesar de haver outros métodos para detectar o estado bidirecional da mídia de transmissão, como o FEFI, existem algumas instâncias onde os mecanismos de detecção de L1 não são suficientes. Esses cenários podem resultar em qualquer dessas ocorrências:

  • Operação imprevisível de STP

  • Inundação incorreta ou excessiva de pacotes

  • Buraco negro de tráfego

O recurso UDLD tem o objetivo de endereçar essas condições de falha nas interfaces de Ethernet de fibra e cobre:

  • As configurações de cabeamento físico e interrupção de portas com conexão incorreta com fios como errdisable.

  • Proteger contra links unidirecionais. Quando um link unidirecional é detectado devido ao mau funcionamento de mídia ou porta/interface, a porta afetada é interrompida como errdisablee a mensagem syslog correspondente é gerada

  • Além disso, o modo assertivo UDLD verifica se um link que foi previamente considerado bidirecional não perde a conectividade durante o congestionamento e torna-se não utilizável. O UDLD executa teste contínuos de conectividade em todo o link. O objetivo principal do modo assertivo UDLD é evitar o desaparecimento de tráfego em determinadas condições de falha.

A extensão de árvore, com seu fluxo BPDU unidirecional estável, foi uma vítima grave dessas falhas. É fácil ver como uma porta pode repentinamente ficar incapaz de transmitir o BPDUs, causando uma alteração do estado de STP de bloqueio para encaminhamento no vizinho. Essa alteração cria um loop, desde que a porta ainda está apta a receber.

Visão Geral Operacional

O UDLD é um protocolo L2 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 de L1, é possível 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 negociação automática não podem realizar, ou seja, a detecção e o armazenamento em cache de informações vizinhas, o desligamento de todas as portas conectadas incorretamente e a detecção de funcionamentos incorretos de interface lógica ou de portas ou falhas em links que não são ponto a ponto (conversores de mídia transversal ou hubs).

O UDLD emprega dois mecanismos básicos; ele aprende sobre os vizinhos, e mantém as informações atualizadas em um cache local, e envia um trem de mensagens de prova/eco (saudação) de UDLD sempre que detecta um novo vizinho ou sempre que um vizinho solicita uma re-sincronização de cache.

O UDLD envia constantemente mensagens de prova em todas as portas onde o UDLD está habilitado. Sempre que uma mensagem específica de "acionamento" de UDLD é recebido em uma porta, inicia uma fase de detecção e o processo de validação. Se no fim desse processo todas as condições válidas forem atendidas, o estado da porta não é alterado. Para atender as condições, a porta deve ser bidirecional e a conexão ligada com fio. Caso contrário, a porta é errdisablee a mensagem de syslog é exibida. A mensagem de syslog é semelhante a essas mensagens:

  • UDLD-3-DISABLE: Link unidirecional detectado na porta [dec]/[dec]. Porta desativada

  • UDLD-4-ONEWAYPATH Um link unidirecional da porta [dec]/[dec] para porta [dec]/[dec] do dispositivo [chars] foi detectada

Consulte Mensagens e Procedimentos de Recuperação (Catalyst 7.6 Series Switches) para obter uma lista completa das mensagens de sistema por instalação, que inclui os eventos UDLD.

Após um link ser estabelecido e classificado como bidirecional, o UDLD continua a anunciar as mensagens de prova/eco no intervalo padrão de 15 segundos. Essa tabela representa os estados de links UDLD válidos conforme registrados na saída do comando show udld port:

Estado de Porta

Comentário

Indeterminado

Detecção em progresso,ou uma entidade UDLD de vizinhança foi desabilitada ou sua transmissão foi bloqueada.

Não aplicável

O UDLD foi desabilitado.

parada

Link unidirecional detectado e porta 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. Sempre que uma mensagem de saudação é recebida, ela é ocultada e mentida na memória pelo período máximo definido como tempo de contenção. Quando o tempo de contenção expira, a entrada de cache respectiva é se torna antiga. Se uma nova mensagem de saudação for recebida dentro do tempo de contenção, a nova substitui a entrada mais antiga e o cronômetro de duração correspondente é redefinido.

  • Para manter a integridade do cache UDLD, sempre que uma interface UDLD habilitada torna-se desabilitada ou um dispositivo é configurado novamente, todas as entradas de cache existentes para as interfaces afetadas pela alteração da configuração são eliminadas e a UDLD transmite no mínimo uma mensagem para informar os respectivos vizinhos da necessidade de descarregarem as entradas de cache correspondentes.

  • Mecanismo de Detecção de Eco—o mecanismo de detecção de eco forma a base do algoritmo de detecção. Sempre que um dispositivo UDLD obtém informações sobre um novo vizinho ou recebe uma solicitação de nova sincronização de um vizinho não sincronizado, ele inicia/reinicia a janela de detecção no lado da conexão e envia um burst de mensagens de eco como resposta. Na medida em que esse comportamento deve ser o mesmo em todos os vizinhos, o emissor de eco espera receber ecos como resposta. Se a janela de detecção for fechada é nenhuma mensagem de resposta válida for recebida, o link será considerado unidirecional e talvez tenha início um processo de restabelecimento de link ou de fechamento de porta.

Tempo de convergência

Para evitar loops de STP, o CatOS 5.4(3) reduziu o intervalo da mensagem padrão de UDLD de 60 segundos para 15 segundos para interromper um link unidirecional antes que uma porta bloqueada tenha sido capaz de fazer a transição para o estado de encaminhamento.

Observação: 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 estabelecidos, o intervalo de mensagem configurada é enviado e o intervalo de expiraão desse correspondente é calculado para ser (3 * message_interval). Portanto, a relação de peer expira após três saudações (ou provas) consecutivas serem perdidas. Com os intervalos de mensagem diferentes em cada lado, esse valor de expiração é diferente em cada lado.

O tempo aproximado que o UDLD leva para detectar uma falha unidirecional fica por volta de (2,5 * intervalo de mensagens + 4 segundos) ou cerca de 41 segundos usando o intervalo de mensagens padrão de 15 segundos. Isso está bem abaixo dos 50 segundos geralmente necessários para a reconvergência de STP. Se o NMP CPU tiver algum ciclo sobressalente e se você monitorar cuidadosamente o nível de utilização, é possível reduzir o intervalo de mensagem (par) para o mínimo de 7 segundos. Esse intervalo de mensagem ajuda a acelerar a detecção por um fator significativo.

Portanto, UDLD tem uma dependência assumida em cronômetros de Árvore de Abrangência padrão. Se você ajustar o STP para convergir mais rapidamente que o UDLD, considere um mecanismo alternativo, como o recurso de protetor de loop do CatOS 6.2. Considere também um mecanismo alternativo ao implementar o RSTP (IEEE 802.1w) porque o RSTP possui características de convergência em milissegundos, que depende da topologia. Nessas instâncias, use o protetor de loop em conjunto com o UDLD, o qual oferece a maior proteção. O protetor de loop evita que os loops de STP com a velocidade da versão de STP em uso, o UDLD detecta as conexões unidirecionais dos links de EtherChannel individuais ou em casos em que os BPDUs não fluem ao longo da direção quebrada.

Observação: O UDLD não detecta toda situação de falha de STP, como as falhas causadas por um CPU que não envia BPDUs por um tempo superior a (2 * FwdDelay + Período máximo). Por esses motivos, a Cisco recomenda que você implemente o UDLD em conjunto com o protetor de loop (que foi introduzido no CatOS 6.2) nas topologias que dependem do STP.

cuidado Cuidado: Cuidados com as versões mais antigas do UDLD que usam um intervalo de mensagem padrão não-configurável de 60 segundos. Esses versões 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, nenhuma porta é errdisabled.

  • Um lado do link tem uma porta travada (as duas transmitem [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 de L1, está desabilitada.

  • A redução de confiabilidade nos mecanismos de L1 FEFI é desejável.

  • A proteção máxima contra falhas de link unidirecional em links FE/GE ponto a ponto é necessária. 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 de L1 estiver desabilitado ou for não utilizável. Isso é verdadeiro particularmente com as conexões de EtherChannel porque o PAgP/LACP, mesmo se habilitado, 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.

As circunstâncias que contribuem com a perda simétrica dos pacotes de prova de UDLD são mais difíceis de caracterizar. Você deve entender que o UDLD normal não verifica a condição de link unidirecional, mesmo após um link alcançar a condição bidirecional. A intenção do UDLD é detectar os problemas de L2 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 do UDLD normal em conjunto com a negociação automática e o protetor de loop (em redes que dependem do STP) é quase sempre suficiente. Entretanto, o modo assertivo UDLD é benéfico em situações em que o congestionamento é igualmente afetado nas duas direções, que causam a perda de provas de UDLD nas duas direções. Por exemplo, essas perda de provas de UDLD pode ocorrer se a utilização do CPU em cada extremidade do link ser elevado. Outros exemplos de perda bidirecional de conectividade inclui a falha de um desses dispositivos:

  • Um transponder de Dense Wavelength Division Multiplexing (DWDM)

  • Um conversor de mídia

  • Um Hub

  • Outro dispositivo de L1.

    Observação: A falha não pode ser detectada pela negociação automática.

O erro de UDLD assertivo desabilita a porta nessas situações de falha. Considere as ramificações cuidadosamente ao habilitar o modo assertivo UDLD em links que não sejam ponto a ponto. Os links com conversores de mídia, hubs ou dispositivos semelhantes não são ponto a ponto. Os dispositivos intermediários podem evitar o encaminhamento de pacotes de UDLD e forçam um link a ser fechado desnecessariamente.

Após todos os vizinhos de uma porta ter expirado, o modo assertivo UDLD (se habilitado) reiniciar na seqüência de linkup é um esforço para ressincronizar todos os vizinhos potencialmente fora de sincronia. Esse esforço ocorre em qualquer anúncio da fase de detecção. Se após um rápido treinamento de mensagens (oito tentativas falhas) o link ainda é considerado "indeterminado", a porta é então colocada 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 de STP em potencial (com o uso dos parâmetros de STP padrão).

UDLD em links roteados

Para fins de discussão, um link roteado é um dos dois tipos de conexão:

  • Ponto a ponto entre os dois nós do roteador

    Esse link é configurado com uma máscara de sub-rede de 30-bits.

  • Uma VLAN com portas múltiplas mas que suporta apenas conexões roteadas

    Um exemplo é uma topologia central de L2 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. As características discutidas nessa seção são relevantes quando você contrasta dois ou mais protocolos de roteamento prevalecentes que são usados atualmente, Protocolo Open Shortest Path First (OSPF) e IGRP Avançado (EIGRP).

Primeiro, observe que a falha de L1 ou L2 em todos os resultados de rede roteada ponto a ponto na quase imediata destruição do conexão L3. Devido a única porta de switch nas transições de VLAN para um estado não conectado mediante a falha de L1/L2, o recurso de auto-estado de MSFC sincroniza os estados de porta L2 e L3 em aproximadamente dois segundos. Essa sincronização coloca a interface L3 VLAN em um estado up/down (com o protocolo de linha desativado).

Suponhamos os valores de cronômetro padrão O OSPF envia mensagens de saudação a cada 10 segundos e possui um intervalo inoperante de 40 segundos (4 * saudação). Esses cronômetros são consistentes nas redes de ponto a ponto e broadcast de OSPF. Já que o OSPF exige comunicação em dois sentidos para formar uma adjacência, o caso pior de failover é de 40 segundos. Esse failover é o caso mesmo se a falha de L1/L2 não for pura em uma conexão de um ponto a ponto, o que deixa um cenário meio operacional com o qual o protocolo L3 deve lidar. Devido ao tempo de detecção de UDLD ser muito semelhante ao tempo de um cronômetro inoperante de OSPF que expira (aproximadamente 40 segundos), as vantagens de configuração do modo normal de UDLD em um link ponto a ponto de OSPF L3 são limitadas.

Em muitos casos, o EIGRP converge mais rápido que o OSPF. Entretanto, você deve observar que a comunicação em dois sentidos não é necessária 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 fazer as rotas pelo caminho do vizinho "ativo". O modo normal de UDLD pode aliviar as circunstâncias observadas nessa seção. O modo normal de UDLD detecta uma falha de link unidirecional e um erro desabilita a porta.

Em conexões L3-roteadas que usam qualquer protocolo de roteamento, o UDLD normal ainda oferece proteção contra problemas durante a ativação do link inicial. Esse problemas incluem cabeamento inadequado ou hardware defeituoso. Além disso, o modo assertivo UDLD oferece essas vantagens nas conexões L3 roteadas:

  • Evita buraco negro de tráfego desnecessário

    Observação: Temporizadores mínimos são necessários em alguns casos.

  • Coloca um link não-sincronizado em estado errdisable .

  • Protege contra o resultado de configurações EtherChannel de L3

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. As portas de cobre tendem a serem usadas em acessos de host.

Observação: O UDLD deve ser desabilitado globalmente e o nível de interface antes dos vizinhos pode alcançar a condição bidirecional. No CatOS 5.4(3) e nas versões mais atuais, o intervalo de mensagem padrão é 15 segundos e é configurável entre 7 e 90 segundos.

A recuperação de errdisable é desabilitada globalmente por padrão. Após ser habilitado globalmente, se uma porta entrar em estado errdisable a porta é automaticamente reabilitada após um intervalo selecionado. O tempo padrão é 300 segundos, que á um cronômetro global e é mantido em todas as portas de um switch. É possível evitar manualmente a reabilitação de uma porta se você definir a expiração de errdisable da porta como desabilitado. Execute o comando set port errdisable-timeout mod/port disable.

Observação: O uso desse comando dependa da versão de seu software.

Considere o uso do recurso de expiração 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.

ConsulteConfigurando Ethernet, Fast Ethernet, Gigabit Ethernet, e 10-Gigabit Ethernet Switching para obter mais detalhes sobre como configurar um período de expiração para portas no estado errdisable .

Recomendação

O modo UDLD normal é suficiente na grande maioria dos casos se você usá-lo adequadamente e em conjunto com os recursos e protocolos adequados. Esses recursos/protocolos incluem:

  • FEFI

  • Negociação Automática

  • Protetor de Loop

Ao empregar o UDLD, considere se um teste contínuo de conectividade bidirecional (modo assertivo) é necessário. Normalmente, se a negociação automática estiver habilitada, o modo assertivo não é necessário porque a negociação automática compensa a detecção de falha no L1.

A Cisco recomenda a habilitação do modo normal de UDLD em todos os links FE/GE ponto a ponto entre os switches Cisco onde o intervalo de mensagem UDLD é definido com o padrão de 15 segundos. Esse configuração presume o padrão dos cronômetros de árvore de abrangência de 802.1d. Além disso, use o UDLD em conjunto com o protetor de loop em redes que dependem do STP para redundância e convergência. Essa recomendação se aplica a redes onde existe uma ou mais portas no estado de bloqueio de STP na topologia.

Eexecute os comandos na ordem para habilitar o UDLD:

            set udld enable
            
               !--- Após a habilitação global, todas as portas de fibra FE e GE
!--- possuem UDLD habilitado por padrão.
            

            set udld enable port range
            
            
               !--- Isso é para portas específicas adicionais e mídia de cobre, se necessário.
            
         

Você deve habilitar manualmente as portas que estão desativadas por erro devido aos sintomas de link unidirecional. Execute o comando set port enable.

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

Outras Opções

Para uma proteção máxima contra sintomas que resultem de link unidirecional , configure o modo assertivo UDLD.

            set udld aggressive-mode enable port_range
            
         

Além disso, é possível ajustar o valor do intervalo de mensagem UDLD entre 7 e 90 segundos em cada extremidade, quando suportado, para uma convergência mais rápida:

            set udld interval time
            
         

Considere o uso do recurso de expiração de errdisable em qualquer dispositivo que possa se tornar isolado da rede na eventualidade de uma situação errdisable. Essa situação é normalmente verdadeira da camada de acesso e quando se implementa o modo assertivo UDLD sem capacidades de gerenciamento de rede sem banda.

Se uma porta é colocada no estado errdisable a porta permanece desativada por padrão. Você pode executar este comando, o qual reabilita as portas após um intervalo de expiração:

Observação: O intervalo de expiração padrão é de 300 segundos.

>set errdisable-timeout enable ?
bpdu-guard

               !--- Esse é um protetor de porta BPDU.
            

channel-misconfig

               !--- Essa é uma configuração incorreta de canal.
            

duplex-mismatch
udld
other

               !--- Esses são outros motivos.
            

all

               !--- Aplicar a expiração de errdisable a todos os motivos.
            
         

Se um dispositivo de sócio não for UDLD capaz, como um host final ou roteador, não execute o protocolo. Execute este comando:

            set udld disable port_range
            
         

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 e desligar um fio de fibra para ver o estado desejado errdisable você precisará ter desligado a negociação automática L1. Caso contrário, a porta física não é desativada, que reinicializa a comunicação da mensagem UDLD. A extremidade remota se move para o estado indeterminado no UDLD normal. Se você usar o modo assertivo UDLD, a extremidade remota se move para o estado errdisable .

Existe um método de teste adicional para simular a perda do vizinho PDU para UDLD. Use filtros de camada de MAC para bloquear o endereço de hardware de UDLD/CDP mas permita que outros endereços passem.

Para monitorar o UDLD, execute esses comandos:

>show udld

UDLD              : enabled
Message Interval  : 15 seconds


>show udld port 3/1

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

Também do modo habilitado É possível executar o comando oculto show udld neighbor para verificar os conteúdos de cache de UDLD (da mesma forma que faz o CDP). Uma comparação do cache de UDLD com o cache de CDP para verificar se existe uma anomalia específica do protocolo é sempre útil. Sempre que o CDP também for afetado, todos os PDUs/BPDUs são tipicamente afetados. Portanto, verifique o STP também. Por exemplo, verifique alterações de identidade de raiz recentes ou alterações de colocação de raiz/porta designada.

>show udld neighbor 3/1

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

Além disso, é possível monitorar o status de UDLD e a consistência de configuração com o uso de variáveisUDLD SNMP MIB.

Frame jumbo

O tamanho do quadro da Unidade de Transmissão Máxima (MTU) é de 1518 bytes para todas as portas Ethernet que incluem GE e 10 GE. O recurso quadro jumbo habilita interfaces para comutar estruturas que sejam maiores que o tamanho de quadro de Ethernet padrão. O recurso é útil para otimizar o desempenho servidor para servidor e suportar aplicações como o Switching de Etiquetas de Multi-Protocolos (MPLS), tunelamento de 802.1Q e tunelamento de protocolo L2 Versão 3 (L2TPv3), que aumenta o tamanho dos quadros originais.

Visão Geral Operacional

A especificação padrão IEEE 802.3 define um tamanho de quadro de Ethernet máximo de 1518 bytes para estruturas regulares e 1522 bytes para quadros encapsulados 802.1Q. Os quadros encapsulados às vezes são chamadas de "baby giants". Em geral, os pacotes são classificados como quadros gigantes quando o pacote ultrapassa 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.

Existem vários motivos pelos quais o tamanho MTU de certos quadros pode ultrapassar 1518 bytes. Estes são alguns exemplos:

  • Requisitos específicas do fornecedor - Os aplicativos e certas Placas de Interface de Rede (NICs) podem especificar um tamanho de MTU fora do padrão de 1500 bytes. A tendência em especificar esses tamanhos de MTU se devem a estudos que provaram que um aumento no tamanho de um quadro de Ethernet pode aumentar a média de throughput.

  • Entroncamento - Para transportar informações do VLAN-ID entre switches ou outros dispositivos de rede, o entroncamento foi empregado para aumentar o quadro de Ethernet padrão. Atualmente, as duas formas mais comuns de entroncamento são o encapsulamento InterSwitch Link (ISL) proprietário da Cisco e o IEEE 802.1Q.

  • MPLS—Após o MPLS ser habilitado em uma interface, ele tem o potencial de aumentar o tamanho do quadro de um pacote. Esse aprimoramento depende dos números de rótulos da pilha de rótulo de um pacote marcado por MPLS. O tamanho total do rótulo é 4 bytes. O tamanho total da pilha de rótulo é n x 4 bytes. Se uma pilha de rótulos for formada, os quadros podem exceder a MTU.

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

  • Universal Transport Interface (UTI)/L2TPv3—UTI/L2TPv3 dados de L2 encapsulados que são encaminhados pela rede IP. O encapsulamento pode aumentar o tamanho do quadro original em até 50 bytes. O novo quadro inclui um novo cabeçalho de IP (20-byte), um cabeçalho de L2TPv3 (12-byte), e um novo cabeçalho de L2. A carga útil de L2TPv3 consiste no quadro de L2 completo, que inclui o cabeçalho de L2.

A capacidade de diferentes switches Catalyst de suportar vários tamanhos de quadros depende de muitos fatores, incluindo de hardware e software. Certos módulos podem suportar quadros de tamanho maior que outros, mesmo dentro da mesma plataforma.

  • Os switches Catalyst 5500/5000 oferecem suporte para quadro jumbo na versão CatOS 6.1. Quando o recurso de quadros jumbo é habilitado em uma porta, o tamanho de MTU aumenta em até 9216 bytes. Em pares não-blindados (UTP) de 10/100-Mbps, o tamanho máximo de quadro suportado é apenas 8092 bytes. Esta é uma limitação ASIC. Em geral não há restrições ao ativar o recurso de tamanho de quadro jumbo. Esse recurso pode ser utilizado com entroncamento/não-entroncamento e canalização/não-canalização.

  • Os switches Catalyst 4000 (Supervisor Engine 1 [WS-X4012] e Supervisor Engine 2 [WS-X4013]) não suportam quadros jumbo devido a uma limitação ASIC. Entretanto, a exceção é o entroncamento 802.1Q.

  • A plataforma do Catalyst séries 6500 pode suportar tamanho de quadro jumbo no CatOS versão 6.1(1) e mais recente. Todavia, esse suporte depende dos tipos de placa de linha que são utilizados. Em geral não há restrições ao ativar o recurso de tamanho de quadro jumbo. Esse recurso pode ser utilizado com entroncamento/não-entroncamento e canalização/não-canalização. O tamanho padrão do MTU é 9.216 bytes, uma vez que o suporte para quadro jumbo foi habilitado na porta individual. O padrão para MTU não é configurável com o uso do CatOS. Entretanto, o Cisco IOS Software versão 12.1(13)E introduziu o comando system jumbomtu para sobrescrever o padrão de MTU.

Consulte Suporte a Quadro Jumbo/Gigante em Exemplo de Configuração de Switches Catalyst para obter mais informações.

Essa tabela descreve os tamanhos de MTU que são suportados por diferentes placas de linha nos Catalyst 6500/6000 Series Switches:

Observação: O tamanho de MTU ou tamanho de pacote se refere apenas a carga útil de Ethernet.

Placa de Linha

Tamanho da MTU

Padrão

9216 bytes

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

8092 bytes (limitado pelo chip PHY)

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

9100 bytes (@ 100 Mbps)

9216 bytes (@ 10 Mbps)

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

9216 bytes

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

9216 bytes

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

9216 bytes

WS-X6516-GE-TX

8092 bytes (@ 100 Mbps)

9216 bytes (@ 10 ou 1000 Mbps)

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

1500 bytes (não suporta quadro jumbo)

WS-X6148A-GE-TX, WS-X6148A-GE-45AF, WS-X6502-10GE, WS-X67xx Series

9216 bytes

OSM ATM (OC12c)

9180 bytes

OSM CHOC3, CHOC12, CHOC48, CT3

9216 bytes (OCx e DS3)

7673 bytes (T1/E1)

Flex WAN

7673 bytes (CT3 T1/DS0)

9216 bytes (OC3c POS)

7673 bytes (T1)

CSM (WS-X6066-SLB-APC)

9216 bytes (a partir de CSM 3.1(5) e 3.2(1))

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

9216 bytes

Suporte a Frame Jumbo Camada 3

Com o CatOS executado no Supervisor Engine e o Cisco IOS Software executado no MSFC, os switches Catalyst 6500/6000 também oferecem suporte de quadro jumbo L3 do Cisco IOS® Software Versão 12.1(2)E e mais recentes com o uso do hardware PFC/MSFC2, PFC2/MSFC2, ou mais recente. Se as VLANs de ingresso e saída estiverem configuradas para quadro jumbo, todos os pacotes estarão comutados por hardware pelo PFC a uma velocidade de fio. Se as VLANs de ingresso estiverem configuradas para quadro jumbo e as VLANs de saída não estiverem configuradas, dois cenários existem:

  • Um quadro jumbo que é enviado pelo host final com Don't Fragment (DF) bit definido (para descoberta de caminho MTU) — O pacote é descartado e um protocolo de ICMP inalcançável é enviado para o host final com o código de mensagem fragmentação necessária e DF definido.

  • Um quadro jumbo que é enviado pelo host final com o DF bit não definido—Os pacotes são direcionados para o MSFC2/MSFC3 para serem fragmentados e comutados em software.

Esta tabela resume o suporte ao Jumbo L3 de várias plataformas:

Módulo ou Switch L3

Tamanho de MTU L3 Máximo

Catalyst série 2948G-L3/4908G-L3

Não suporta quadros jumbo.

Catalyst 5000 RSM1/RSFC2

Não suporta quadros jumbo.

Catalyst 6500 MSFC1

Não suporta quadros jumbo.

Catalyst 6500 MSFC2 e mais recentes

Cisco IOS Software versão 12.1(2)E: 9216 bytes

1 RSM = Módulo de Switch de roteador da Cisco

2 RSFC = Placa de Recursos de Comutação de Rota

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

103d.gif

De acordo com essa fórmula, o throughput de TCP máximo atingível é diretamente proporcional ao MSS. Com RTT constante e perda de pacote, é 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 1518 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.

Em segundo lugar, as crescentes demandas de desempenho dos server farms exigem um meio mais eficiente de garantir taxas de dados mais levadas com os datagramas de UDP Network File System (NFS). O NFS é o mecanismo de armazenamento de dados mais usado mundialmente para transferir arquivos entre servidores com base em UNIX, e ele possui recursos de datagramas de 8400 bytes. Devido ao estendido NTU de 9 KB da Ethernet, um único quadro jumbo é grande o suficiente para executar um datagrama de aplicativo de 8 KB (por exemplo, NFS) mais a sobrecarga do cabeçalho do pacote. Essa capacidade incidentalmente permite transferências mais eficientes ao acesso à memória direta (DMA) nos hosts porque o software não precisa mais para fragmentar os bloqueios de NFS em datagramas de UDP separados.

Recomendação

Quando você quiser o suporte de quadro, bloqueie o uso de quadros jumbo em áreas de rede onde todos os módulos do switch (L2) e interfaces (L3) suportem quadros jumbo. Essa configuração evita a fragmentação em qualquer lugar do caminho. A configuração de quadros jumbo maiores que o comprimento de frame suportado no caminho elimina todos os ganhos obtidos pelo uso do recurso já que a fragmentação é necessária. Conforme exibido pela tabela dessa seçãoFrame Jumbo, diferentes plataformas e placas de linha podem variar com relação aos tamanhos máximos de pacote que são suportados.

Configure dispositivos de host que identifiquem quadro jumbo com um tamanho de MTU que seja o mínimo denominador comum suportado pelo hardware da rede, em toda a VLAN L2 onde o dispositivo do host reside. Para habilitar o suporte do quadro jumbo para os módulos com suporte de quadro jumbo, execute esse comando:

            set port jumbo mod/port enable
         

Além disso, se você desejar suporte de quadro jumbo em todos os limites de L3, configure o maior valor de MTU de 9216 bytes em todas as interfaces VLAN aplicáveis. Execute o comando mtu nas interfaces de VLAN:

            interface vlan vlan#
mtu 9216
         

Essa configuração garante que o MTU do quadro jumbo de L2 que é suportado pelos módulos seja sempre menor ou igual ao valor configurado para as interfaces de L3 que o tráfego atravessa. Isso a fragmentação quando o tráfego é roteado da VLAN pela interface de L3.

Configuração de gerenciamento

Considerações para ajudar o controle, provisão e solução de problemas de uma rede Catalyst são discutidas nessa seção.

Diagramas de Rede

Os diagramas de rede claros compõem uma parte fundamental das operações de rede. 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. A preparação, prontidão e acessibilidade não podem ser desconsideradas.

Recomendação

A Cisco recomenda que você crie esses três diagramas:

  • Diagrama Total—mesmo nas maiores redes, um diagrama que exibe a conectividade lógica e física de extremidade a extremidade é importante. Pode ser comum para empresas que implementaram um design hierárquico documentem cada camada separadamente. Durante o planejamento e a resolução de problemas, entretanto, é sempre bom saber como os domínios importantes estão ligados.

  • Diagrama Físico—exibe todo o hardware e cabeamento de switch e roteador. Troncos, links, velocidades, grupos de canal, números de porta, slots, tipos de chassis, software, domínios de VTP, ponte-raiz, backup de prioridade de ponte-raiz, endereço MAC, e portas bloqueadas por VLAN devem ser rotuladas. É sempre mais claro retratar dispositivos internos, como o Catalyst 6500/6000 MSFC, como um roteador em um cabo conectado por um tronco.

    103e.gif

  • Diagrama Lógico — exibe apenas a funcionalidade L3 (roteadores como objetos, VLANs como segmentos de Ethernet). Endereços IP, sub-redes, endereçamento secundário, HSRP ativo e de standby, camadas de access-core-distribution, informações de roteamento devem ser identificados.

    103f.gif

Gerenciamento In-Band

Dependendo da configuração, a interface de gerenciamento em banda (interno) do switch (conhecida como sc0) pode ter que processa esses dados:

  • Protocolos de gerenciamento de switch, como o SNMP, Telnet, Secure Shell Protocol (SSH), e syslog

  • Dados do usuário como broadcasts e multicasts

  • Protocolos de controle de switch como o STP BPDUs, VTP, DTP, CDP, etc

É uma prática comum do projeto de multicamada da Cisco configurar uma VLAN de gerenciamento que espalhe domínios comutados e tenha todas as interfaces sc0. Isso ajuda a separar o tráfego de gerenciamento do tráfego do usuário e aumenta a segurança das interfaces de gerenciamento de switch. Essa seção descreve o significado e os problemas em potencial do uso da VLAN 1 padrão e da execução do tráfego de gerenciamento para o switch na mesma VLAN como tráfego do usuário.

Visão Geral Operacional

Essa preocupação primária sobre o uso da VLAN 1 para dados de usuário é que o Supervisor Engine NMP em geral não precisa ser interrompida pela maioria do tráfego multicast e broadcast que é gerado pelas estações finais. Hardwares Catalyst 5500/5000 mais antigos, o Supervisor Engine I e o Supervisor Engine II em particular, possuem recursos limitados para lidar com esse tráfego, apesar do princípio se aplicar a todos os Supervisor Engines. Se o Supervisor Engine CPU, buffer, ou canal in-band para o backplane estiver totalmente ocupado escutando tráfego desnecessário, é possível que os quadros de controle possam ser perdidos. No cenário do pior caso, isso poderia levar a um Circuito de Árvore de Abrangência ou falha de EtherChannel.

Se os comandos show interface e show ip stats forem emitidos no Catalyst, eles podem dar alguma indicação da transmissão para tráfego de unicast e a proporção de IP para tráfego não-IP (não visto tipicamente em gerenciamento de VLANs).

Uma outra verificação de saúde de hardware Catalyst 5500/5000 mais antigo é examinar a saída do (comando oculto) show inband | biga para erros de recurso (RscrcErrors), semelhante a descartes de buffer em um roteador. Se esses erros de recurso aumentarem continuamente, a memória não está disponível para receber pacotes de sistema, talvez devido ao montante significativo de tráfego de transmissão na VLAN de gerenciamento. Um único erro de recurso pode significar que o Supervisor Engine não é capaz de processar um pacote como os BPDUs, que poderiam rapidamente se tornar um problema já que os protocolos como a árvore de abrangência não reenviam BPDUs perdidos.

Recomendação

Conforme realçado na seção Cat Control desse documento, a VLAN 1 é uma VLAN especial que marca e processa a maior parte do tráfego de controle de plano. A VLAN 1 está habilitado em todos os troncos por padrão. Com maiores redes de campus, é preciso tomar cuidado com o Diâmetro da VLAN 1 domínio STP; a instabilidade em uma parte da rede poderia afetar a VLAN 1, influenciando portanto a estabilidade do plano de controle e a instabilidade de STP em todas as outras VLANs. No CatOS 5.4 e versões mais recentes, foi possível limitar a VLAN 1 em carregar dados do usuário e executar o STP com esse comando:

            clear trunk mod/port vlan 1
         

Isso não impede que os pacotes de controle sejam enviados de switch para switch na VLAN 1, conforme visto com um analisador de rede. Entretanto, nenhum dado é encaminhado e o STP não é executado nesse link. Portanto, essa técnica pode ser usada para quebrar a VLAN 1 em domínios de falha menores.

Observação:  Não é atualmente possível limpar os troncos VLAN 1 em 3500s e 2900XLs.

Mesmo tomando-se cuidado com o projeto do campus para bloquear as VLANs de usuário para domínios de switch relativamente pequenos e limites de L3/falhas pequenos correspondentes, alguns clientes ainda tentam tratar o gerenciamento de VLAN de forma diferente e tentam cobrir toda as rede com uma sub-rede de gerenciamento única. Não há motivo técnico para que uma aplicação NMS central deva ser L2 adjacente ao dispositivo que gerencia, tampouco esse é um argumento de segurança qualificado. A Cisco recomenda que você limite o diâmetro das VLANs de gerenciamento para a mesma estrutura do domínio roteado que as VLANs do usuário e considerando o gerenciamento fora de banda e/ou suporte CatOS 6.x SSH como um modo de aumentar a segurança do gerenciamento de rede.

Outras Opções

Entretanto, há considerações de design para essas recomendações da Cisco em algumas topologias. Por exemplo, um projeto Cisco multicamada comum e desejável é um que evita o uso de uma árvore de abrangência ativa. Isso exige que você bloqueie cada sub-rede IP/VLAN para um único switch de camada de acesso única, ou cluster de switches. Nesses projetos, não pode haver entroncamento configurado para a camada de acesso.

Não existe resposta fácil para a pergunta de se uma VLAN de gerenciamento separada pode ser criada e um entroncamento habilitado para executar entre as camadas de acesso L2 e de distribuição L3. Essas são duas opções de revisão de projeto com o seu engenheiro Cisco:

  • Opção 1:: VLANs únicas de dois ou três troncos da camada de distribuição até cada switch da camada de acesso. Isso permite uma VLAN de dados, uma VLAN de voz e uma VLAN de gerenciamento, por exemplo, e ainda tem o benefício de STP inativo. (Observe que a VLAN 1 é apagada dos troncos, existe uma etapa de configuração extra.) Nessa solução, também existem os pontos de projeto a serem considerados para evitar o buraco negro temporário de tráfego roteado durante e recuperação de falha: Sincronização de STP PortFast em troncos (CatOS 7.x e mais atual) ou VLAN Autostate com encaminhamento de STP (versões posteriores a CatOS 5.5[9]).

  • Opção 2:: uma VLAN única para dados e gerenciamento poderia ser aceitável. Com os hardwares de switch mais modernos, como as CPUs mais potentes e os controles de limitação de taxa do plano de controle, mais um projeto com domínios de broadcast relativamente pequenos conforme defendidos pelo projeto de multicamada, a realidade de muitos clientes é que manter a interface sc0 separada dos dados do usuário não é mais um problema como costumava ser. Uma decisão final é provavelmente melhor tomada com o exame do perfil de tráfego de broadcast da VLAN e uma discussão das capacidades do hardware de switch com o seu engenheiro da Cisco. Se o gerenciamento de VLAN realmente tiver todos os usuários naquele switch de camada de acesso, a utilização de filtros de entrada de IP altamente recomendada para garantir o switch dos usuários, conforme discutido na seção Configuração de Segurança deste documento.

Gerenciamento fora de banda

Considerando uma etapa além os argumentos da seção anterior, o gerenciamento de rede pode se tornar mais altamente viável com a construção de uma infra-estrutura de gerenciamento separada ao redor da rede de produção para que os dispositivos possam sempre ser alcançados remotamente independentemente da ocorrência de eventos no plano de controle ou acionado por tráfego. 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

Todo roteador e switch da rede pode ser fornecido com uma interface de gerenciamento de Ethernet fora de banda em uma VLAN. Uma porta de Ethernet em cada dispositivo é configurada na VLAN de gerenciamento e cabeada fora da rede de produção para uma rede de gerenciamento comutada separada por meio de uma interface sc0. Observe que os switches Catalyst 4500/4000 possuem uma interface especial me1 no Supervisor Engine que é usada para o gerenciamento fora de banda apenas, e não como uma porta de switch.

Além disso, a conectividade do servidor terminal pode ser alcançada pela configuração de um Cisco 2600 ou 3600 com RJ-45-para-cabos seriais, para que haja acesso à porta de console de todos os roteadores e switches na disposição. Um servidor terminal também evita a necessidade de configurar cenários de backup, tais como modems em portas auxiliares para cada dispositivo. Um único modem pode ser configurado na porta auxiliar do servidor terminal para oferecer serviço dialup ao outro dispositivo durante uma falha de conectividade de rede.

Recomendação

Com essa disposição, dois caminhos fora de banda para cada e roteador são possíveis além dos vários caminhos in-band, habilitando assim um gerenciamento de rede altamente disponível. O caminho Fora de banda é responsável por:

  • O caminho Fora de banda separa o tráfego de gerenciamento dos dados do usuário.

  • O caminho Fora de banda possui o endereço IP de gerenciamento em uma sub-rede, VLAN e switch separados para maior segurança.

  • O caminho Fora de banda oferece maior garantia de gerenciamento de entrega de dados durante as falhas de rede.

  • O caminho Fora de banda não tem Árvore de abrangência ativa na VLAN de gerenciamento. A redundância não é crítica.

103g.gif

Testes de sistema

Diagnóstico de inicialização

Durante uma inicialização de sistema, diversos processos são executados para garantir que uma plataforma operacional e confiável esteja disponível para que um hardware com defeito não interrompa a rede. O diagnóstico de inicialização do Catalyst é dividido em Auto-Teste de Energia (POST) e diagnósticos on-line.

Visão Geral Operacional

Dependendo da plataforma e a configuração do hardware, diagnósticos diferentes são executados na inicialização e quando um cartão é swap recente no chassi. Um nível mais alto de diagnóstico em uma número mais amplo de problemas detectados, mas um ciclo de inicialização mais longo. Esses três níveis de diagnósticos POST podem ser selecionados (todos os testes verificam a presença de DRAM, RAM e cache e os mede e inicializa):

Visão Geral Operacional

Desvio

N/A

3

Não disponível na série 4500/4000 usando CatOS 5.5 ou versões anteriores.

Mínimo

Teste de padrão de escrita no primeiro MB de DRAM apenas.

30

Padrão nas séries 5500/5000 e 6500/6000, não disponível na série 4500/4000.

Completo

Testes de padrão de escrita para todas as memórias.

60

O padrão é a série 4500/4000.

Diagnósticos on-line

Estes testes verificam os caminhos dos pacotes internamente no switch. É importante observar que diagnósticos on-line são, portanto, testes em todo o sistema, não simplesmente testes de porta. Nos switches Catalyst 5500/5000 e 6500/6000, os testes são executados primeiro do Supervisor Engine em standby, e de novo do Supervisor Engine principal. O comprimento do diagnóstico depende da configuração do sistema (número de slots, módulos, portas). Existem três categorias de testes.

  • Teste de circuito de retorno — pacotes do Supervisor Engine NMP são enviados para cada porta e retornados ao NMP e examinados com relação a erros.

  • Teste de empacotamento — canais de até oito portas são criados e testes de loopback executados para o agport verificar o hashing de links específicos (consulte a seção EtherChannel desse documento para obter mais informações).

  • Teste de Lógica de Reconhecimento de Endereço Codificado (EARL) — os mecanismos de regravação do Supervisor Engine e o módulo L3 de Ethernet in-line são testados. As entradas de encaminhamento de hardware e as portas roteadas são criadas antes do envio dos pacotes de exemplo (para cada tipo de encapsulamento de protocolo) do NMP por meio do hardware de switching de cada módulo, e de volta até o NMP. Isto é para os módulos de PFC Catalyst 6500/6000 e mais recentes.

Diagnósticos on-lines completos podem levar aproximadamente dois minutos. Diagnósticos mínimos não realizam testes de reescrita ou de conjunto em módulos que não o Supervisor Engine, e podem levar aproximadamente 90 segundos.

Durante um teste de memória, quando uma diferença é encontrada na leitura padrão comparada à escrita padrão, o estado da porta é alterado para defeituoso . Os resultados desses testes podem ser consultados se o comando show test for executado, seguido pelo número do módulo a ser examinado:

>show test 9

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

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

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

Recomendação

A Cisco recomenda que todos os switches sejam configurados para utilizar diagnósticos completos para fornecer detecção de defeito máxima e evitar interrupções durante as operações normais.

Observação: Esta alteração não tem efeito até a próxima vez que o dispositivo for inicializado. Execute este comando para definir diagnósticos completos:

            set test diaglevel complete 
         

Outras Opções

Em algumas situações, um tempo rápido de inicialização pode ser preferível em relação à espera pela execução completa dos diagnósticos. Há outros fatores e cronometragens envolvidos para ativar o sistema, mas no total, os diagnósticos POST e on-line aumentam aproximadamente um terço ao tempo. Em testes com chassi de nove slots do Supervisor Engine único completamente preenchido com um Catalyst 6509, o tempo de reinicialização total foi de aproximadamente 380 segundos com diagnóstico completo, aproximadamente 300 segundos com diagnóstico mínimo, e apenas 250 segundos com diagnóstico de desvio. Execute este comando para configurar o desvio:

            set test diaglevel bypass
         

Observação: O Catalyst 4500/4000 aceita ser configurado para diagnóstico mínimo, embora isto ainda resulte em um teste completo sendo realizado. O modo mínimo poderia ser suportado no futuro na sua plataforma.

Diagnóstico de Run Time

Uma vez que o sistema está operacional, o switch Supervisor Engine realiza vários monitoramentos dos outros módulos. Se um módulo não é alcançável através de mensagens de gerenciamento (Protocolo de Controle Serial [SCP] sendo executado pelo barramento de gerenciamento fora de banda), o Supervisor Engine tenta reiniciar a placa ou tomar outras ações conforme apropriado.

Visão Geral Operacional

O Supervisor Engine realiza vários monitoramentos automaticamente; isto não exige qualquer configuração. Para o Catalyst 5500/5000 e 6500/6000, estes componentes do switch são monitorados:

  • NMP através de um vigilante

  • Erros de chip EARL aprimorados

  • Canal de inband do Supervisor Engine para backplane

  • Módulos através de keepalives sobre canais fora de banda (Catalyst 6500/6000)

  • O Supervisor Engine Ativo é monitorado pelo Supervisor Engine em standby para status (Catalyst 6500/6000)

Detecção de Erro de Sistema e de Hardware

Visão Geral Operacional

No CatOS 6.2 e posteriores, mais funcionalidades foram adicionadas para monitorar componentes de sistema crítico e nível de hardware. Estes três componentes de hardware são suportados:

  • Inband

  • Contador de porta

  • Memória:

Quando o recurso é habilitado e uma condição de erro é detectada, o switch gera uma mensagem de syslog. A mensagem informa ao administrador que existe um problema antes de ocorrer uma degradação de desempenho notável. No CatOS versões 6.4(16), 7.6(12), 8.4(2) e posteriores, o modo padrão para todos os três componentes foram alterados de desabilitados para habilitados.

Inband

Se for detectado um erro de inband, uma mensagem syslog o informará sobre a existência de um problema antes que haja degradação perceptível de desempenho. O erro exibe o tipo de ocorrência de defeito de inband. Alguns exemplos são:

  • Travamento de inband

  • Erros de recurso

  • Defeito de inband durante inicialização

Na detecção de uma falha de ping de inband, o recurso também relata uma mensagem de syslog adicional com um snapshot da taxa atual de Tx e de Rx na conexão de inband, no CPU, e no carregamento de backplane do switch. Esta mensagem permite que você defina apropriadamente se o inband está travado (sem Tx/Rx) ou sobrecarregado (excessivo Tx/Rx). Esta informação adicional pode ajudar a determinar a causa das falhas ping de inband.

Contador de porta

Quando você habilita este recurso, ele cria e inicia um processo para depurar contadores de porta. O contador de porta periodicamente monitora contadores de erro de porta internos de seleção. A arquitetura da line card, e mais especificamente os ASICs no módulo, determina quais contadores o recurso consulta. O Suporte Técnico da Cisco ou a engenharia de desenvolvimento pode então utilizar esta informação para solucionar problemas. Este recurso não apura contadores de erros como FCS, CRC, alinhamento, e runts que são diretamente associados com conectividade de parceiro de link. Consulte a seção EtherChannel/Manipulação de Erros de Link deste documento para incorporar esta capacidade.

A pesquisa é realizada a cada 30 minutos e é executada no fundo dos contadores de erros selecionados. Se o contador é ativado entre duas pesquisas subseqüentes na mesma porta, uma mensagem de syslog relata o incidente e fornece o módulo/porta e detalhes dos contadores de erros.

A opção do contador de porta não é suportada na plataforma do Catalyst 4500/4000.

Memória:

A habilitação deste recurso executa o monitoramento e detecção de background de condições de corrompimento de DRAM. Tais condições de corrompimento de memória incluem:

  • Alocação

  • Liberação

  • Fora de intervalo

  • Mal alinhamento

Recomendação

Habilita todos os recursos de detecção de erros, que incluem inband, contadores de porta, e memória, onde são suportados. A habilitação destes recursos alcançam sistemas proativos aprimorados e diagnóstico de advertência de hardware para a plataforma de switch Catalyst. Execute estes comandos para habilitar todos os três recursos de detecção de erros:

            set errordetection inband enable
            
               !--- Este é o padrão no CatOS 6.4(16), 7.6(12), 8.4(2), e mais recentes.
            

            set errordetection portcounters enable
            
               !--- Este é o padrão no CatOS 6.4(16), 7.6(12), 8.4(2), e mais recentes.
            

            set errordetection memory enable
            
               !--- Este é o padrão no CatOS 6.4(16), 7.6(12), 8.4(2), e mais recentes.
            
         

Execute este comando para confirmar que a detecção de erros está habilitada:

>show errordetection

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

EtherChannel/Manipulação de Erros de Link

Visão Geral Operacional

No CatOS 8.4 e mais recentes, um novo recurso foi introduzido para fornecer um failover automático de tráfego de uma porta em um EtherChannel para outra porta no mesmo EtherChannel. O failover de porta ocorre quando uma das portas do canal excede um limiar de erro configurável dentro do intervalo especificado. O failover de porta apenas ocorre se houver uma porta operacional deixada no EtherChannel. Se a porta falhada for a última porta no EtherChannel, a porta não insere o failover de porta . Esta porta continua a passar o tráfego, independente do tipo de erros que são recebidos. Portas únicas, não-canalizadas não vão para o estado de failover de porta . Essas portas vão para o errdisable quando o limite de erro é excedido dentro do intervalo especificado.

Este recurso é apenas eficaz quando você habilita set errordetection portcounters. Os erros de link a serem monitorados são baseados em três contadores:

  • InErrors

  • RxCRCs (CRCAlignErrors)

  • TxCRCs

Execute o comando show counters em um switch para exibir o número de contadores de erros. Este é um exemplo:

>show counters 4/48

.......

32 bit counters

0  rxCRCAlignErrors           =          0
.......

6  ifInErrors                 =          0
.......

12 txCRC                      =          0

Esta tabela é uma lista dos parâmetros de configuração possíveis e a configuração padrão respectiva:

Parâmetros

Padrão

Global

Desabilitado

Monitor de porta para RxCRC

Desabilitado

Monitor de porta para InErrors

Desabilitado

Monitor de porta para TxCRC

Desabilitado

Ação

Failover de porta

Intervalo

30 segundos

Contagem de exemplos

3 consecutivos

Limiar baixo

1000

Limiar alto

1001

Se o recurso está habilitado e o contador de erros de uma porta alcança o valor alto do limiar configurável dentro do período de contagem de exemplo especificado, a ação configurável é desabilitada de erro ou de failover de porta. A ação desativar erro coloca a porta no estado errdisable . Se você configurar a ação failover de porta, o status canal de porta é considerado. A porta é desativada por erro apenas se a porta estiver em um canal mas a porta não for a última porta operacional do canal. Além disso, se a ação configurada for failover d porta e a porta for uma porta única ou não-canalizada, a porta é colocada em estado errdisable quando a contagem de erro de porta atingir um valor alto com relação ao limite.

O intervalo é uma constante do cronômetro de leitura dos contadores de erro de porta. O valor padrão é o intervalo de erros de link de 30 segundos. A faixa permitida é entre 30 e 1800 segundos.

Existe um risco de erro de desabilitação acidental de uma porta devido a um evento isolado inesperado. Para minimizar esse risco, são adotadas medidas na porta apenas quando a condição persistir através desse números de vezes de amostras consecutivas. O valor de amostragem padrão é 3 e a faixa permitida é de 1 a 255.

O limite é um número absoluto a ser verificado com base no intervalo de erros de link. O percentual mínimo de erro de link padrão é 1000 e a faixa permitida é de 1 a 65.535. O limiar alto de erro de link padrão é 1001. Quando o número consecutivo de vezes de amostragem atinge o limiar baixo, um syslog é enviado. Se o número de vezes de amostragem consecutiva atingir o limiar alto, um syslog é enviado e uma ação de desativar erro ou de failover de porta é ativada.

Observação: Use a mesma configuração de detecção de erro de porta em todas as portas de um canal. Consultar essas seções do guia de configuração do software série Catalyst 6500 para obter mais informações:

Recomendações

Já que o recurso usa mensagens de SCP para registrar e comparar os dados, números altos de portas ativas podem ter processo intensivo de CPU. Esse cenário é até mais intensivo de CPU quando o intervalo de limiar é definido com um valor muito baixo. Habilite esse recurso com discrição nas portas designadas como links críticos e com tráfego de aplicações sensíveis. Execute este comando para ativar a detecção de erro de link globalmente:

            set errordetection link-errors enable
         

Além disso, inicie o limiar padrão, intervalo e parâmetros de amostragem. E use a ação padrão failover de porta.

Execute esses comandos para aplicar os parâmetros de erro de link global nas portas individuais:

            set port errordetection mod/port inerrors enable

            set port errordetection mod/port rxcrc enable

            set port errordetection mod/port txcrc enable
         

Você pode executar esses comandos e para verificar a configuração dos erros de link.

            show errordetection

            show port errordetection {mod | mod/port}
         

Diagnóstico de buffer de pacote de informação do Catalyst 6500/6000

No CatOS versões 6.4(7), 7.6(5) e 8.2(1), foi introduzido o diagnóstico de buffer de pacote Catalyst 6500/6000. Os diagnósticos de buffer de pacote, que são habilitados por padrão, detectam as falhas de buffer de pacote causadas pelas falhas transitórias de RAM estática (SRAM). A detecção acontece nesses módulos de linha de 48-portas 10/100-Mbps

  • WS-X6248-RJ45

  • WS-X6248-RJ21

  • WS-X6348-RJ45

  • WS-X6348-RJ21

  • WS-X6148-RJ45

  • WS-X6148-RJ21

Quando ocorre a condição de falha, 12 das 48 portas de 10/100-Mbps continuam conectadas e podem experimentar problemas aleatórios de conectividade. A única forma de se recuperar dessa condição é reinicializando o módulo de linha.

Visão Geral Operacional

Os diagnósticos de buffer de pacote verificam os dados que são armazenados em uma seção especifica do buffer de pacote para determinar se ele foi corrompido pelas falhas de SRAM transitórios. Se o processo ler de volta algo diferente de o que escreveu, ele então executa duas opções possíveis de recuperação configurável:

  1. A ação padrão é desativar o erro nas portas da line card que são afetadas pela falha de buffer.

  2. A segunda opção é reinicializar a line card.

Duas mensagens do syslog foram adicionadas. Essas mensagens fornecem um aviso de desativação de erro das portas ou do ciclo de energia do módulo devido aos erros de buffer de pacote:

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

Nas versões do CatOS anteriores às versões 8.3 e 8.4, o tempo do ciclo de energia da line card é entre 30 e 40 segundos. Um recurso de inicialização rápida foi introduzido nas versões 8.3 e 8.4 do CatOS. O recurso faz o download automático de firmware nas line cards instaladas durante o processo de inicialização para minimizar o tempo de inicialização. O recurso de inicialização rápida reduz o tempo de ciclo de energia para aproximadamente 10 segundos.

Recomendação

A Cisco recomenda a opção padrão de errdisable. Essa ação tem pouco impacto no serviço de rede durante as horas de produção. Se possível, mova a conexão afetada pelas portas desativadas para erro para outras portas de switch disponíveis para restaurar o serviço. Programe um ciclo de reinicialização da line card durante a janela de manutenção. Execute o comando reset module mod para se recuperar totalmente da condição de pacote corrupto de buffer. Execute este comando para ativar a opção errdisable:

            set errordetection packet-buffer errdisable
            
               !--- Este é o padrão.
            
         

Outra Opção

Já que o ciclo de reinicialização da line card é necessário para recuperar totalmente todas as portas que encontraram uma falha de SRAM, uma ação de recuperação alternativa é configurar a opção ciclo de reinicialização. Essa opção é útil em circunstâncias onde uma interrupção nos serviços de rede que pode durar entre 30 e 40 segundos é aceitável. Esse período é o tempo necessário para um módulo de linha executar completamente o ciclo de reinicialização e voltar ao serviço sem o recurso de inicialização rápida. O recurso de inicialização rápida pode reduzir o tempo de interrupção dos serviços de rede para 10 segundos com a opção ciclo de reinicialização. Execute este comando para ativar a opção ciclo de reinicialização:

            set errordetection packet-buffer power-cycle
         

Diagnósticos de buffer de pacote

Esse teste é apenas para switches Catalyst 5500/5000. Esse teste foi projetado para encontrar o hardware com falha nos switches Catalyst 5500/5000 que usam módulos de Ethernet com hardware específico que fornecem conectividade de 10/100-Mbps entre as portas de usuário e a placa mãe do switch. Como não é possível executar uma verificação CRC para quadros truncados, se um buffer de pacote de porta se tornar defeituoso durante o tempo de execução, os pacotes podem ser corrompidos e causar erros de CRC. Infelizmente, isso poderia levar a propagação de quadros inadequados na rede ISL do Catalyst 5500/5000, que potencialmente causa rompimento no plano de controle e transmite tempestades nos cenários de pior caso.

Os módulos Catalyst 5500/5000 mais recentes e outras plataformas atualizaram a verificação de erro de hardware interna e não precisam de testes de buffer de pacote, então não há opção para configurar.

Os módulos de linha que precisam de diagnósticos de buffer de pacote são WS-X5010, WS-X5011, WS-X5013, WS-X5020, WS-X5111, WS-X5113, WS-X5114, WS-X5201, WS-X5203, WS-X5213/a, WS-X5223, WS-X5224, WS-X5506, WS-X5509, WS-U5531, WS-U5533 e WS-U5535.

Visão Geral Operacional

Esse diagnóstico verifica se os dados armazenados em uma seção específica do buffer de pacote não foi acidentalmente corrompida por um hardware defeituoso. Se o processo ler de volta algo diferente de o que escreveu, ele encerra a porta no modo failed já que a porta poderia corromper dados. Não há necessidade de limite de erros. As portas com falha não podem ser habilitadas de novo até que o módulo tenha sido reinicializado (ou substituído).

Existem dois modos de testes de buffer de pacote: programado e sob demanda Quando um teste começa, mensagens de syslog são geradas para indicar o comprimento esperado do teste (arredondado para o minuto mais próximo) e o fato do teste ter começado. O comprimento exato do teste varia por tipo de porta, tamanho de buffer e tipo de execução de teste.

Os testes sob demanda são assertivos a fim de serem concluídos em poucos minutos. Já que os teste interferem ativamente com a memória de pacote, as portas devem ser encerradas administrativamente antes do teste. Execute este comando para encerrar as portas:

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

Os testes agendados são muito menos assertivos que os testes sob demandam e eles são executados ao fundo. Os testes são realizados em paralelo em vários módulos, mas em apenas uma porta por módulo por vez. O teste preserva, escreve e lê pequenas seções de memória de buffer de pacote antes de restaurar os dados de pacote do usuário, e assim não gera erros. Entretanto, como o teste está gravando na memória de buffer, ele bloqueará os pacotes recebidos por alguns milésimos de segundo, causando, assim algumas perdas em links ocupados. Por padrão, há uma pausa de oito segundos entre cada teste de escrita de buffer para minimizar a perda de pacote, mas isso significa que um sistema cheio de módulos que precisa de um teste de buffer de pacote pode levar mais de 24 horas para concluir o teste. Esse teste agendado é habilitado por padrão para ser executado semanalmente as 03:30 de domingo no CatOS 5.4 e versões mais recentes, e o status do teste pode ser confirmado com esse comando:

>show test packetbuffer status

            
               !--- Quando o teste é executado, o comando retorna
!--- essa informação:
            
Current packet buffer test details
Test Type           : scheduled
Test Started        : 03:30:08 Jul 20 2001
Test Status         : 26% of ports tested
Ports under test    : 10/5,11/2
Estimated time left : 11 minutes

               !--- Quando o teste não está sendo executado,
!--- o comando retorna essa informação:
            
Last packet buffer test details
Test Type           : scheduled
Test Started        : 03:30:08 Jul 20 2001
Test Finished       : 06:48:57 Jul 21 2001

Recomendação

A Cisco recomenda que você use o recurso de teste de buffer de pacote agendado dos sistemas Catalyst 5500/5000, já que o benefício de descobrir problemas nos módulos é maior que o risco de pequena perda de pacote.

Um horário padronizado semanal deve, então, ser programado na rede, o que permitirá ao cliente mudar os links de portas defeituosas ou modelos de RMA, conforme a necessidade. Já que esse teste pode causar alguma perda de pacote, dependendo da carga da rede, ele deve ser agendado em horários mais calmos da rede, como o horário padrão de 3:30 da manhã de domingo. Execute este comando para definir o horário do teste:

            set test packetbuffer Sunday 3:30
            
               !--- Este é o padrão.
            
         

Uma vez habilitado (como quando o CatOS é atualizado para 5.4 e mais recente pela primeira vez), existe uma chance que uma memória oculta/problema de hardware anterior seja exposto, e uma porta é encerrada automaticamente como resultado. Essa mensagem poderá ser exibida:

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

Outras Opções

Se não for aceitável arriscar um nível baixo de perda semanal de pacotes por porta, é recomendável usar o recurso sob demanda durante as interrupções agendadas. Execute esse comando para iniciar o recurso manualmente com base por faixa (apesar da porta dever ser desabilitada administrativamente primeiro):

            test packetbuffer port range
            
         

Registro de sistema

As mensagens do Syslog são específicas da Cisco e parte do gerenciamento de falhas proativas. Uma ampla gama de condições de protocolo e rede é reportada usando o e portanto é possível padronizar o SNMP. As plataformas de gerenciamento, como o Cisco Resource Manager Essentials (RMEs) e o kit de ferramentas de gerenciamento de rede (NATkit) potencializam o uso de informações do syslog já que executam essas tarefas:

  • Apresenta análise por gravidade, mensagem, dispositivo, etc

  • Habilita filtragem de mensagens entrando para análise

  • Aciona alerta, como pagers ou coleta sob demanda de inventário e alterações de configuração

Recomendação

Um ponto importante a ser focado é o nível de informações de registro a serem geradas localmente e mantidas no buffer do switch em oposição ao que é enviado a um servidor de syslog (usando o comando set logging server severity value ). Algumas organizações registram um alto nível de informações centralmente, enquanto outras vão ao switch para olhar os registros de eventos mais detalhados ou ativam um alto nível de captura de syslog apenas durante a solução de problemas.

A depuração é diferente nas plataformas CatOS do que no Cisco IOS Software, mas o registro detalhado do sistema pode ser habilitado por sessão com set logging session enable sem alterar o que foi registrado por padrão.

A Cisco geralmente recomenda que você coloque a árvore de abrangência e as facilidades de syslog de sistema no nível 6, uma vez que são recursos de estabilidade para rastrear. Além disso, para os ambientes de multicast, a definição do nível de registro da facilidade de mcast para 4 é recomendada para que as mensagens de syslog sejam produzidas se as portas do roteador forem excluídas. Infelizmente, antes do CatOS 5.5(5), isso resultava no registro de mensagens de syslog para associações e licenças de IGMP, que são muito ruidosas para serem monitoradas. Finalmente, se forem usadas as listas de entrada de IP, o nível 4 é recomendado como nível de registro mínimo para capturar as tentativas de logon não autorizadas. Execute estes comandos para configurar estas opções:

            set logging buffer 500
            
               !--- Este é o padrão.
            
            set logging server syslog server IP address
set logging server enable
            
               !--- Este é o padrão.
            
            set logging timestamp enable
set logging level spantree 6 default
            
               !--- Aumente o nível de syslog STP padrão.
            
            set logging level sys 6 default
            
               !--- Aumente o nível padrão do syslog do sistema.
            
            set logging server severity 4
            
               !--- Este é o padrão;
!--- ele limita as mensagens exportadas ao servidor syslog.
            
            set logging console disable
         

Desative as mensagens do console para proteger contra o risco do switch suspender enquanto espera por uma reposta de um terminal lento ou não-existente quando o volume de mensagens é alto. O registro do console tem um alta prioridade no CatOS e é usado principalmente para capturar as mensagens finais localmente quando há a solução de problemas ou em uma situação de quebra de switch.

Esta tabela fornece as facilidades de registro individual, níveis padrão e alterações recomendadas para o Catalyst 6500/6000. Cada plataforma tem facilidades um pouco diferentes, dependendo dos recursos suportados.

Facilidade

Nível Padrão

Ação Recomendada

acl

5

Despreze.

cdp

4

Despreze.

cops

3

Despreze.

dtp

8

Despreze.

earl

2

Despreze.

ethc1

5

Despreze.

filesys

2

Despreze.

gvrp

2

Despreze.

ip

2

Altere para 4 se forem usadas as listas de entrada de IP.

núcleo

2

Despreze.

1d

3

Despreze.

mcast

2

Altere para 4 se for usado o multicast (CatOS 5.5[5] e superior) .

mgmt

5

Despreze.

mls

5

Despreze.

pagp

5

Despreze.

protfilt

2

Despreze.

remoção

2

Despreze.

Privatevlan

3

Despreze.

qos

3

Despreze.

radius

2

Despreze.

rsvp

3

Despreze.

segurança

2

Despreze.

snmp

2

Despreze.

spantree

2

Altere para 6.

sys

5

Altere para 6.

tac

2

Despreze.

tcp

2

Despreze.

telnet

2

Despreze.

Tftp

2

Despreze.

UDLD

4

Despreze.

VMPS

2

Despreze.

VTP

2

Despreze.

1 No CatOS 7.x e superior, o código de facilidade ethc substitui o código de facilidade pagp para mostrar o suporte LACP.

Observação: Atualmente, os switches Catalyst registram uma mensagem de syslog de alteração do nível 6 de configuração para cada comando set ou clear executado, ao contrário do Cisco IOS Software, que dispara a mensagem somente depois que você sai do modo de configuração. Se você necessitar de RMEs para fazer backup de configurações em tempo real neste disparo, estas mensagens também necessitarão ser enviadas ao servidor de syslog RMEs. Para a maioria dos clientes, os backups de configuração periódica dos switches Catalyst são suficientes e não será necessária a alteração da gravidade de registro do servidor padrão.

Se você ajustar seus alertas NMS, consulte o Guia de Mensagens do Sistema.

Protocolo de Gerenciamento de Rede Simples

O SNMP é usado para recuperar estatísticas, contadores e tabelas armazenados no dispositivo de rede das Bases de Informações de Gerenciamento (MIBs). As informações coletadas podem ser usadas pelo NMSs (como HP Openview) para gerar alertas em tempo real, para a medição de disponibilidade e para produzir informações de planejamento de capacidade, assim como realizar verificações de configuração e de solução de problemas.

Visão Geral Operacional

Com alguns mecanismos de segurança, uma estação de gerenciamento de rede consegue recuperar informações nas MIBs com a obtenção do protocolo SNMP e das próximas solicitações e para alterar parâmetros com o comando set. Além disso, um dispositivo de rede pode ser configurado para gerar uma mensagem de armadilha para o NMS para alertas em tempo real. O polling SNMP utiliza a porta 161 do IP UDP e os desvios de SNMP utilizam a porta 162.

A Cisco suporta estas versões de SNMP:

  • SNMPv1: RFC 1157 Internet Standard, usando a segurança da série de comunidade de texto sem formatação. Uma lista de controle de acesso de endereço de IP e a senha definem a comunidade de gerentes aptos a acessar o agente da MIB.

  • SNMPv2C: uma combinação de SNMPv2, um padrão de rascunho da Internet definido em RFCs 1902 por 1907 e SNMPv2C, um quadro administrativo baseado na comunidade para o SNMPv2 que é um projeto experimental definido em RFC 1901. Os benefícios incluem um mecanismo de recuperação em massa que oferece suporte para a recuperação de tabelas e de amplas quantidades de informações, minimizando o número de round trips necessários e melhorando o manejo de erros.

  • SNMPv3: O esboço proposto do RFC 2570 fornece acesso seguro a dispositivos por meio da combinação de autenticação e criptografia de pacotes na rede. Os recursos de segurança fornecidos no SNMPv3 são:

    • Integridade de mensagem: assegura 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 para evitar que seja visto facilmente por uma origem não autorizada

Esta tabela identifica as combinações dos modelos de segurança:

Nível de Modelo

Autenticação

Criptografia

Resultado

v1

noAuthNoPriv, Série de Comunidade

Não

Usa uma verificação de repetição série de comunidade na autenticação.

v2c

noAuthNoPriv, Série de Comunidade

Não

Usa uma verificação de repetição série de comunidade na autenticação.

v3

noAuthNoPriv, Nome de usuário

Não

Usa uma compatibilidade de nome de usuário de autenticação.

v3

authNoPriv, MD5 ou SHA

Np

Fornece autenticação baseada nos algoritmos HMAC-MD5 ou HMAC-SHA.

v3

authPriv, MD5 ou SHA

DES

Fornece autenticação baseada nos algoritmos HMAC-MD5 ou HMAC-SHA. Fornece a criptografia de 56 bits DES juntamente com a autenticação baseada no padrão CBC-DES (DES-56).

Observação: Lembre-se destas informações sobre os objetos SNMPv3:

  • Cada usuário pertence a um grupo.

  • Um grupo define a política de acesso para um conjunto de usuários.

  • Uma política de acesso define quais objetos SNMP podem ser acessados para ler, escrever e criar.

  • Um grupo determina a lista de notificações que seus usuários podem receber.

  • Um grupo também define o modelo de segurança e o nível de segurança de seus usuários.

Recomendação de Desvios de SNMP

O SNMP é a base de todo o gerenciamento da rede, sendo habilitado e usado em todas as redes. O agente SNMP no switch deve estar definido para usar a versão do SNMP compatível com a estação de gerenciamento. Já que um agente pode comunicar-se com múltiplos gerenciadores, é possível configurar o software para suportar comunicação com uma estação de gerenciamento usando o protocolo SNMPv1 e outra usando o protocolo SNMPv2 por exemplo.

A maioria das estações NMS usam o SNMPv2C atualmente sob esta configuração:

            set snmp community read-only string
            
            
               !--- Permite a visualização apenas de variáveis.
            

            set snmp community read-write string
            
            
               !--- Permite a configuração de variáveis.
            

            set snmp community read-write-all string<string>
            
               !--- Inclui a configuração de séries SNMP. 
            
         

A Cisco recomenda habilitar as armadilhas de SNMP para todos os recursos em uso (os recursos não usados podem ser desabilitados, se desejável). Assim que o desvio for habilitado, ele poderá ser testado com o comando test snmp e da configuração adequada de processamento do NMS para o erro (como um alerta instantâneo ou de pager).

Todos os desvios são desativados por padrão e necessitam ser adicionados à configuração, mesmo individualmente ou pelo parâmetro all, como mostrado:

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

Os desvios disponíveis no CatOS 5.5 incluem:

Armadilha

Descrição

auth

Autenticação

bridge

Bridge

chassi

Chassi

config

Configuração

entidade

Entidade

ippermit

IP permit

módulo

Módulo

repetidor

Repetidor

stpx

Extensão de Árvore de Abrangência

syslog

Notificação de syslog

vmps

Servidor de política de associação de VLAN

vtp

VLAN Trunk Protocol

Observação: A armadilha de SYSLOG envia todas as mensagens do syslog geradas pelo switch para NMS também como um desvio de SNMP. Se o alerta de syslog já estiver sendo realizado por um analisador como o Cisco Works 2000 RMEs, não será necessariamente útil receber esta informação duas vezes.

Ao contrário do Cisco IOS Software, os desvios de SNMP do nível de porta são desativados porque os switches pode ter centenas de interfaces ativas. Portanto, a Cisco recomenda que as portas de chaves, como os links de infra-estrutura para os roteadores, switches e servidores principais, tenham armadilhas SNMP em nível de porta habilitadas. Não são necessárias outras portas, como portas de host do usuário, o que ajuda a simplificar o gerenciamento da rede.

            set port trap port range enable
            
               !--- Ativada apenas em portas de chave.
            
         

Recomendações de Chamada Seletiva de SNMP

É recomendada uma revisão de gerenciamento de rede para discutir as necessidades específicas em detalhes. Entretanto, são listadas algumas filosofias básicas da Cisco para o gerenciamento de grandes redes:

  • Faça algo simples e faça bem.

  • Reduza a sobrecarga do grupo de trabalho devida a dados de eleição, coleção, ferramentas e análise manual.

  • O gerenciamento de rede é possível apenas com poucas ferramentas, como HP Openview como um NMS, Cisco RMEs como uma configuração, syslog, inventário e gerenciador de software, Microsoft Excel como um analisador de dados NMS e o CGI como uma maneira de publicar na web.

  • A publicação de relatórios na web permite que usuários, como o gerenciamento sênior e os analistas, se ajudem a obter informações sem sobrecarregar a equipe de operações com várias solicitações especiais.

  • Descubra o que está funcionando bem na rede e deixe-o de lado. Concentre-se naquilo que não está funcionando.

A primeira fase da implementação de NMS deve ser a linha de base do hardware da rede. Podem ser inferidas muitas informações sobre a integridade do dispositivo e do protocolo a partir da utilização de CPU simples, memória e buffer em roteadores, e da utilização de CPU de NMP, memória e backplane em switches. Apenas depois da linha de base de hardware faça a carga de tráfego L2 e L3, pico e as linhas de base se tornam completamente significativas. As linhas de base são geralmente estabelecidas sobre vários meses para obter visibilidade de tendências diárias, semanais e trimestrais – de acordo com o ciclo comercial da companhia.

Várias redes sofrem problemas de desempenho de NMS e capacidade causados por sobrecarga. É então recomendado, já que a linha de base foi estabelecida, configurar os limiares de RMON de alarme e evento RMON nos dispositivos para alertar o NMS sobre alterações anormais e remover a pesquisa. Isso permite que a rede informe aos operadores quando há algo anormal em vez de fazer chamadas seletivas constantemente para ver se tudo está funcionando normalmente. Os limiares podem ser definidos com base em várias regras, como o valor máximo mais uma porcentagem ou desvio padrão de um meio, e estão fora do escopo deste documento.

A segunda fase da implementação de NMS é apurar as áreas particulares da rede mais detalhadamente com o SNMP. Isso inclui as áreas de dúvida, as áreas antes de uma alteração ou as áreas que serão caracterizadas pelo bom funcionamento. Use os sistemas NMS como um farol para verificar a rede detalhadamente e iluminar os pontos ativos (não tente acender toda a rede).

O grupo de Consulta de Gerenciamento de Rede da Cisco sugere que esta chave apresenta falha nas MIBs quando é analisada ou monitorada nas redes de campus. Consulte Monitoração de Rede Cisco e Diretrizes de Correlação de Eventos para mais informações (sobre o desempenho das MIBs em pesquisas, por exemplo).

Nome de Objeto

Descrição de Objeto

OID

Intervalo de Pesquisa

Limiar

MIB-II

sysUpTime

uptime do sistema em 1/100 de segundo

1.3.6.1.2.1.1.3

5 min.

< 30000

Nome de Objeto

Descrição de Objeto

OID

Intervalo de Pesquisa

Limiar

CISCO-PROCESS-MIB

cpmCPUTotal5min

A porcentagem total de ocupação do CPU nos últimos 5 minutos.

1.3.6.1.4.1.9.9.109.1.1.1.1.5

10 min.

Linha da base

Nome de Objeto

Descrição de Objeto

OID

Intervalo de Pesquisa

Limiar

CISCO-STACK-MIB

sysEnableChassisTraps

Indica se as armadilhas chassisAlarmOn e chassisAlarmOff nesse MIB devem ser geradas.

1.3.6.1.4.1.9.5.1.1.24

24 hrs

1

sysEnableModuleTraps

Indica se os desvios moduleUp e moduleDown nesse MIB devem ser gerados.

1.3.6.1.4.1.9.5.1.1.25

24 hrs

1

sysEnableBridgeTraps

Indica se as armadilhas newRoot e topologyChange em BRIDGE-MIB (RFC 1493) devem ser gerados.

1.3.6.1.4.1.9.5.1.1.26

24 hrs

1

sysEnableRepeaterTraps

Indica se as armadilhas em REPEATER-MIB (RFC1516) devem ser geradas.

1.3.6.1.4.1.9.5.1.1.29

24 hrs

1

sysEnableIpPermitTraps

Indica se as armadilhas IP permit nesse MIB devem ser geradas.

1.3.6.1.4.1.9.5.1.1.31

24 hrs

1

sysEnableVmpsTraps

Indica se deve ser gerada a armadilha vmVmpsChange definida no CISCO- VLAN-MEMBERSHIP-MIB.

1.3.6.1.4.1.9.5.1.1.33

24 hrs

1

sysEnableConfigTraps

Indica se a armadilha sysConfigChange nesta MIB deve ser gerada.

1.3.6.1.4.1.9.5.1.1.35

24 hrs

1

sysEnableStpxTrap

Indica se a armadilha stpxInconsistencyUpdate em CISCO-STP-EXTENSIONS-MIB deve ser gerada.

1.3.6.1.4.1.9.5.1.1.40

24 hrs

1

chassisPs1status

Status do fonte de alimentação 1.

1.3.6.1.4.1.9.5.1.2.4

10 min.

2

chassisPs1TestResult

Informações detalhadas sobre o status do fonte de alimentação 1.

1.3.6.1.4.1.9.5.1.2.5

Conforme necessário.

 

chassisPs2Status

Status da fonte de alimentação 2.

1.3.6.1.4.1.9.5.1.2.7

10 min.

2

chassisPs2TestResult

Informações detalhadas sobre o status da fonte de alimentação 2

1.3.6.1.4.1.9.5.1.2.8

Conforme necessário.

 

chassisFanStatus

Status da Ventoinha do Chassi.

1.3.6.1.4.1.9.5.1.2.9

10 min.

2

chassisFanTestResult

Informações detalhadas sobre o status da ventoinha do chassi.

1.3.6.1.4.1.9.5.1.2.10

Conforme necessário.

 

chassisMinorAlarm

Status do Alarme Secundário do Chassi.

1.3.6.1.4.1.9.5.1.2.11

10 min.

1

MajorAlarm do chassi

Status do Alarme Principal do Chassi

1.3.6.1.4.1.9.5.1.2.12

10 min.

1

chassisTempAlarm

Status do Alarme de Temperatura do Chassi

1.3.6.1.4.1.9.5.1.2.13

10 min.

1

moduleStatus

Status Operacional do módulo.

1.3.6.1.4.1.9.5.1.3.1.1.10

30 min.

2

moduleTestResult

Informações detalhadas sobre a condição dos módulos.

1.3.6.1.4.1.9.5.7.3.1.1.11

Conforme necessário.

 

moduleStandbyStatus

Status de um módulo redundante.

1.3.6.1.4.1.9.5.7.3.1.1.21

30 min.

=1 ou =4

Nome de Objeto

Descrição de Objeto

OID

Intervalo de Pesquisa

Limiar

CISCO-MEMORY-POOL-MIB

dot1dStpTimeSinceTopologyChange

O tempo (em 1/100 seg) desde a última alteração de topologia detectada pela entidade.

1.3.6.1.2.1.17.2.3

5 min.

< 30000

dot1dStpTopChanges

O número total de alterações de topologia detectadas por esta ponte desde a última redefinição ou inicialização da entidade de gerenciamento.

1.3.6.1.2.1.17.2.4

Conforme necessário.

 

dot1dStpPortState [1]

O estado atual da porta como definido pela aplicação do protocolo do Spanning Tree Protocol. O valor de retorno pode ser um desses: desativado (1), bloqueado (2), escuta (3), aprendizagem (4), encaminhamento (5), ou quebrado (6).

1.3.6.1.2.1.17.2.15.1.3

Conforme necessário.

 

Nome de Objeto

Descrição de Objeto

OID

Intervalo de Pesquisa

Limiar

CISCO-MEMORY-POOL-MIB

ciscoMemoryPoolUsed

Indica o maior número de bytes do pool de memória que estão sendo usados atualmente por aplicativos no dispositivo gerenciado.

1.3.6.1.4.1.9.9.48.1.1.1.5

30 min.

Linha da base

ciscoMemoryPoolFree

Indica o número de bytes do pool de memória atualmente não utilizados no dispositivo gerenciado.

Observação: A soma de ciscoMemoryPoolUsed e ciscoMemoryPoolFree é o valor total da memória no pool.

1.3.6.1.4.1.9.9.48.1.1.1.6

30 min.

Linha da base

ciscoMemoryPoolLargestFree

Indica o maior número de bytes contíguos do pool de memória que não estão usados atualmente no dispositivo gerenciado.

1.3.6.1.4.1.9.9.48.1.1.1.7

30 min.

Linha da base

Consulte o Kit de Ferramentas de Gerenciamento de Redes Cisco - MIBs para obter mais informações sobre o suporte Cisco MIB.

Observação: Alguns MIBs padrão consideram que uma entidade SNMP em particular contém apenas uma instância de MIB. Portanto, o padrão MIB não possui qualquer índice que permita aos usuários acessar diretamente uma determinada instância de MIB. Nesses casos, é fornecida a indexação da série de comunidade para que se possa acessar cada instância do MIB padrão. A sintaxe é [série de comunidade]@[número da instância], em que instância é em geral um número de VLAN.

Outras Opções

Os aspectos de segurança do SNMPv3 significam que o seu uso é esperado a ultrapassar o SNMPv2 em temo. A Cisco recomenda que os clientes se preparem para esse novo protocolo como parte da estratégia NMS. Os benefícios são que os dados podem ser coletados seguramente dos dispositivos SNMP sem medo de falsificação ou corrompimento. Informações confidenciais, como os pacotes de comando SNMP set que alteram uma configuração de switch, podem ser criptografadas para evitar que o seu conteúdo seja exposto na rede. Além disso, diferentes grupos de usuários podem ter privilégios diferentes.

Observação: A configuração do SNMPv3 é significativamente diferente que a linha de comando SNMPv2, e espera-se uma carga de CPU maior no Supervisor Engine.

Monitoramento Remoto

O RMON permite que os dados da MIB sejam pré-processados pelo dispositivo de rede, em preparação aos usos comuns ou aplicação da informação pelo gerente da rede, como a realização da determinação da linha de base histórica e a análise de limiar.

Os resultados do processamento RMON são armazenados em MIBs de RMON para coleta subseqüente por um NMS, como definido no RFC 1757 leavingcisco.com.

Visão Geral Operacional

Os switches Catalyst suportam o mini-RMON no hardware em cada porta, o que consiste em quatro grupos básicos RMON-1: Estatísticas (grupo 1), Histórico (grupo 2), Alarmes (grupo 3) e Eventos (grupo 9).

A parte mais forte do RMON-1 é o mecanismo de limiar fornecido pelos grupos de eventos e alarmes. Como discutido na seção anterior, a configuração dos limiares de RMON permite que o switch envie um desvio SNMP quando ocorre uma condição anômala. Uma vez que as portas-chave forem identificadas, o SNMP pode ser usado para consultar contadores ou grupos de histórico de RMON e criar linhas de base que registram a atividade normal de tráfego dessas portas. Em seguida, é possível definir os limiares de RMON surgindo e caindo e os alarmes configurados para quando houver uma variação definida da linha de base.

A configuração de limiares é mais bem feita com o uso de um pacote de gerenciamento RMON, pois a criação bem-sucedida de linhas de parâmetros nas tabelas de Alarmes e Eventos é uma tarefa cansativa. Pacotes RMON NMS comerciais, como o Cisco Traffic Director, parte do Cisco Works 2000, incorporam GUIs que tornam a configuração de limiares de RMON muito mais simples.

Para fins da linha de base, o grupo etherStats oferece um intervalo útil de estatísticas de tráfego L2. Os objetos nesta tabela podem ser utilizados para obter estatísticas de tráfego unicast, multicast, e broadcast, assim como uma variedade de erros L2. O agente RMON no switch também pode ser configurado para armazenar esses exemplos de valores no grupo de histórico. Esse mecanismo permite que a quantidade de interrogações seja reduzida sem reduzir a taxa de amostra. A utilização de históricos do RMON pode fornecer linhas de base precisas, sem a sobrecarga substancial da apuração. Entretanto, quanto mais históricos coletados, mas recursos de switch são utilizados.

Enquanto os switches fornecem apenas quatro grupos básicos de RMON-1, é importante não esquecer dos outros RMON-1 e RMON-2. Todos os grupos são definidos em RFC 2021, incluindo UsrHistory (grupo 18) e ProbeConfig (grupo 19). L3 e maiores informações podem ser recuperados de switches com a porta SPAN ou com os recursos de redirecionamento VLAN ACL que permitem copia o tráfego para um RMON SwitchProbe externo ou para um Módulo de Análise de Rede interna (NAM).

Os NAMs suportam todos os grupos RMON e podem examinar aos dados de camada de aplicação, incluindo os dados de Fluxo de Rede exportados de Catalysts quando o MLS está habilitado. A execução do MLS significa que o roteador não comuta todos os pacotes de um fluxo, portanto, somente a exportação de dados do Netflow, e não os contadores de interface, propiciam contabilidade VLAN confiável.

Você pode utilizar uma porta SPAN e uma prova de switch para capturar um fluxo de pacote para uma porta, tronco, ou VLAN particular e realizar o upload dos pacotes para decodificar com um pacote de gerenciamento RMON. A porta SPAN é controlada pelo SNMP por meio do grupo SPAN no CISCO-STACK-MIB, de modo que este processo é fácil de automatizar. O Traffic Director (Diretor de Tráfego) utiliza esses recursos com seu recurso de agente itinerante.

Existem advertência para abranger toda uma VLAN. Mesmo que você utilize uma prova de 1Gbps, todo o fluxo de pacotes de um VLAN ou mesmo uma porta bidirecional de 1Gbps pode exceder a largura de banda de uma porta SPAN. Se a porta SPAN estiver sendo executada continuamente na largura de banda total, há chances de que os dados sejam perdidos. Consulte Configurando o Recursos Catalyst Switched Port Analyzer (SPAN) para mais detalhes.

Recomendação

A Cisco recomenda que os limiares de RMON e alertas sejam distribuídos para ajudar no gerenciamento da rede de uma forma mais inteligente que a chamada seletiva de SNMP sozinha. Isso reduz a sobrecarga de tráfego de gerenciamento de redes e permite que a rede alerte inteligentemente quando algo foi alterado a partir da linha de base. O RMON necessita ser acionado por uma gente externo como o Traffic Director (Diretor de Tráfego); não há suporte para CLI. Execute os comandos na ordem para habilitar o RMON:

            set snmp rmon enable
set snmp extendedrmon netflow enable mod
            
            
               !--- Para utilizar apenas com o módulo NAM.
            
         

É importante lembrar que a função principal de um switch é encaminhar quadros, e não atuar como uma grande sondagem de RMON com várias portas. Portanto, conforme você configura os históricos e limiares em várias portas para diversas condições, lembre-se de que os recursos estão sendo consumidos. Considere um módulo NAM se você estiver redimensionando um RMON. Lembre-se também das regras de porta crítica: Apenas teste e defina os limiares nas portas identificadas como importantes no estágio de planejamento.

Requisitos de Memória

A utilização da memória RMON está constantemente por todas as plataformas de switch relacionadas a estatísticas, históricos, alarmes, e eventos. O RMON utiliza um bucket para armazenar históricos e estatísticas no agente RMON (o switch, nesse caso). O tamanho do bucket é definido na prova do RMON (Prova do switch) ou no aplicativo RMON (Diretor de Tráfego) e, em seguida, enviado ao switch para ser configurado. Geralmente, os confinamentos de memória são apenas uma consideração dos Supervisor Engines mais antigos com menos de 32MB de DRAM. Consulte essas diretrizes:

  • Aproximadamente 450K de espaço de código é adicionado à imagem NMP para suportar mini-RMON (que são quatro grupos de RMON: estatísticas, histórico, alarmes, e eventos). O requisito de memória dinâmica para RMON varia porque depende da configuração do tempo de execução. As informações de uso de memória de RMON de tempo de execução para cada grupo de mini-RMON são explicadas aqui:

    • Grupo de Estatísticas Ethernet—Ocupa 800 bytes para cada interface Ethernet/FE comutada.

    • Grupo histórico—Para a interface de Ethernet, cada entrada de controle de histórico configurado com 50 buckets ocupa aproximadamente 3.6KB do espaço de memória e 56 bytes para cada bucket adicional.

    • Grupos de Alarmes e Eventos—Ocupa 2.6KB para cada alarme configurado e suas entradas de eventos correspondentes.

  • Salvar a configuração relacionada a RMON ocupa aproximadamente 20K de espaço NVRAM se o tamanho total de NVRAM do sistema for 256K ou superior e 10K de espaço NVRAM se o tamanho total de NVRAM do sistema for 128K.

Protocolo de Tempo de Rede

O NTP, RFC 1305 leavingcisco.com, sincroniza a cronometragem entre um conjunto de servidores de tempo e clientes distribuídos e permite que eventos sejam correlacionados quando registros de sistema são criados ou quando outros eventos de tempo específico ocorrem.

O NTP fornece exatidões de tempo de cliente, tipicamente dentro de um milissegundo em LANs e até alguns dez de milissegundos em WANs, relativos ao servidor primário sincronizado com o tempo universal coordenado (UTC). 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.

Visão Geral Operacional

O NTP foi primeiramente documentado em RFC 958 leavingcisco.com, mas evoluiu pelo RFC 1119 (NTP versão 2) e está agora na sua terceira versão, conforme definido em RFC 1305 leavingcisco.com. Ele é executado através da porta 123 UDP. Toda a comunicação NTP utiliza UTC, que é ao mesmo tempo igual ao Horário do Meridiano de Greenwich.

Acessando Servidores de Tempo Público

A sub-rede de NTP inclui mais de 50 servidores principais públicos 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. Existem aproximadamente 100 servidores públicos secundários sincronizados com os servidores primários que fornecem a sincronização para mais de 100.000 clientes e servidores na Internet. As listas vigentes são mantidas na página List of Public NTP Servers (Lista de Servidores NTP Públicos), que é atualizada com regularidade. Há vários servidores primários e secundários privados não disponíveis normalmente ao público. Para uma lista de servidores NTP públicos e informações sobre como utilizá-los, consulte o site da Universidade de Delaware Servidor de Sincronização de Tempo leavingcisco.com.

Como não há garantias de que esses servidores Internet NTP públicos estarão disponíveis, ou que eles produzirão o tempo correto, aconselhamos que as outras opções sejam consideradas. Isso pode incluir a utilização de vários dispositivos GPS (Global Positioning Service) diretamente conectados a vários roteadores.

Outra opção possível é o uso de vários roteadores configurados como mestres de Estrato 1, mesmo que isso não seja recomendado.

Estrato

Cada servidor de NTP adota um estrato que indica a distância que o servidor está da origem de tempo externo. Os servidores do Estrato 1 têm acesso a alguns tipos de origens de tempo externos, como o relógio de rádio. Os servidores do Estrato 2 obtêm detalhes de tempo de um conjunto nomeado de servidores do Estrato 1, enquanto os servidores do Estrato 3 obtêm detalhes de tempo dos servidores do Estrato 2, e assim sucessivamente.

Relacionamento de Correspondente de Servidor

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

  • Um peer é o que responde aos pedidos do cliente, mas 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 um verdadeiro peer, ambos os lados da conexão devem entrar num relacionamento de peer, em vez de se ter um usuário como peer e o outro como servidor. Também é recomendado que peers troquem chaves para que somente hosts confiáveis comuniquem-se entre si como peers.

  • Em um pedido do cliente para um servidor, este responde ao cliente e esquece que o cliente fez uma pergunta; em um pedido de um cliente para um peer, o servidor responde ao cliente e mantém as informações de estado sobre o cliente para rastrear o quão bem está a manutenção de horas e qual servidor de estrato está sendo executado.

    Observação: O CatOS pode apenas atuar com um cliente NTP.

Não é problema para um servidor NTP processar milhares de clientes. Entretanto, manusear centenas de peers tem um impacto na memória, e a manutenção do estado consome mais recursos de CPU na caixa, como também na largura de banda.

Eleição

O protocolo NTP permite que um cliente consulte um servidor a qualquer momento. De fato, quando o NTP é primeiramente configurado em um dispositivo da Cisco, ele envia oito consultas em rápidas sucessões nos intervalos NTP_MINPOLL (24 = 16 segundos). O NTP_MAXPOLL é 214 segundos (que é 16.384 segundos ou 4 horas, 33 minutos, 4 segundos), o tempo máximo que leva antes de NTP requisitar novamente por uma resposta. No momento, a Cisco não tem um método para forçar manualmente a definição do tempo de POLL pelo usuário.

O contador de pesquisas do NTP inicia em 26 (64) segundos e é incrementado pela energia de dois (uma vez que os dois servidores entram em sincronia), a 210. Ou seja, você pode esperar que as mensagens de sincronização sejam enviadas em um intervalo de 64, 128, 256, 512 ou 1024 segundos por servidor ou correspondente configurado. O tempo varia entre 64 e 1024 segundos como uma potência de dois baseada no circuito bloqueado de fase, que envia e recebe pacotes. Se houver muita variação no tempo, ele pesquisa mais vezes. Se o relógio de referência estiver preciso e a conectividade de rede for consistente, você verá os horários de poll convergirem em 1024 segundos entre cada poll.

No mundo real, isso significa que o Intervalo das chamadas seletivas NTP é alterado à medida que a conexão entre o cliente e o servidor é alterada. Quanto melhor a conexão, mais longo será o intervalo de apuração, o que significa que o cliente NTP recebeu oito respostas para as suas oito últimas solicitações (o intervalo de apuração será então duplicado). Uma única resposta perdida faz com que o intervalo da pesquisa seja dividido. O intervalo da pesquisa começa em 64 segundos e vai no máximo até 1024 segundos. No melhor dos casos, levará um pouco mais de 2 horas para que o intervalo de eleição vá de 64 segundos até 1024 segundos.

Broadcasts

Os broadcasts de NTP nunca são encaminhadas. O comando ntp broadcast faz com que o roteador origine transmissões de NTP na interface que está configurado. O comando ntp broadcast client faz com que o roteador ou o switch escute as transmissões de NTP na interface na qual está configurado.

Níveis de Tráfego NTP

A largura de banda utilizada pelo NTP é mínima, uma vez que o intervalo entre as mensagens de chamada seletiva trocadas entre os peers normalmente retém não mais do que uma mensagem a cada 17 minutos (1.024 segundos). Com um planejamento cuidadoso, isto pode ser mantido dentro das redes do roteador através dos links de WAN. Os clientes NTP devem estabelecer correspondência de discagem com servidores NTP locais, e não por toda a WAN com os roteadores base da estação central que serão os servidores de estrato 2.

Um cliente convergido de NTP usará aproximadamente 0,6 bits/segundo por servidor.

Recomendação

Hoje, muitos clientes possuem o NTP configurado no modo cliente em suas plataformas CatOs, sincronizado com diversas alimentações confiáveis da Internet ou de um relógio de rádio. Entretanto, uma alternativa mais simples para modo de servidor, quando se está operando um grande número de switches, é ativar NTP no modo de cliente de broadcast na VLAN de gerenciamento em um domínio comutado. Esse mecanismo permite um domínio total de Catalysts para receber um relógio de uma mensagem de broadcast única. Entretanto, a precisão da cronometragem é reduzida marginalmente porque o fluxo de informações é unidirecional.

A utilização de endereços de loopback como fonte de atualizações pode também auxiliar com consistência. As preocupações de segurança podem ser endereçadas desses duas maneiras:

  • Atualizações de servidores de filtragens

  • Autenticação

A correlação de tempo de eventos é extremamente valiosa nesses dois casos: exame de solução de problemas e de segurança É preciso tomar cuidado para proteger os dados e as origens de tempo. Recomenda-se criptografia para que eventos-chave não sejam apagados por engano ou de propósito.

A Cisco recomenda essas configurações:

Configuração do Catalyst

                  set ntp broadcastclient enable
set ntp authentication enable
set ntp key key
                  
                  
                     !--- Este é um hash de Sumário de Digest 5 (MD5).
                  
                  set ntp timezone <zone name>
set ntp summertime <date change details>
               

Configuração Alternativa do Catalyst

                  
                     !--- Esta configuração mais tradicional cria
!--- mais trabalhos de configuração e peerings de NTP.
                  
                  set ntp client enable
set ntp server IP address of time server
set timezone zone name
set summertime date change details
                  
               

Configuração do roteador

                  
                     !--- Esta é uma configuração de exemplo de roteador para distribuir
!--- informações de transmissão de NTP para os clientes de broadcast de Catalyst.
                  
                  ntp source loopback0
ntp server IP address of time server
ntp update-calendar
clock timezone zone name
clock summer-time date change details ntp authentication key key
ntp access-group access-list
                  
                  
                     !--- Para filtrar atualizações para permitir apenas origens confiáveis de informações de NTP.
                  
                  Interface to campus/management VLAN containing switch sc0
        ntp broadcast
               

Cisco Discovery Protocol

CDP troca informações entre dispositivos adjacentes sobre a camada de link de dados e é extremamente útil para determinar a configuração física e topológica da rede fora da camada lógica ou de IP. Os dispositivos suportados são principalmente switches, roteadores e telefones IP. Esta seção destaca algumas das melhorias do CDP versão 1 comparados à versão 1.

Visão Geral Operacional

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

As mensagens de CDP contêm uma ou mais sub-mensagens que permitem que os dispositivos de destino coletem e armazenem informações sobre todos os dispositivos vizinhos.

CDP versão 1 suporta estes parâmetros:

Parâmetro

Tipo

Descrição

1

Dispositivo ID

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

2

Endereço

O endereço L3 da interface que enviou a atualização.

3

ID de porta

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

4

Recursos

Descreve os recursos funcionais do dispositivo:

Router: Ponte 0x01 TB: Ponte 0x02 SR: Switch-0x04 0x08 (Fornece switching de L2 e/ou L3) Host: Filtragem condicional de IGMP 0x10: 0x20 A ponte ou o switch não encaminha os pacotes de relatório IGMP em portas sem roteador. Repetidor: 0x40

5

Versão

Uma seqüência de caracteres contendo a versão do software (o mesmo em show version).

6

Plataforma

Plataforma de hardware, como WS-C5000, WS-C6009, ou Cisco RSP.

No CDP versão 2, os campos de protocolo adicionais foram introduzidos. O CDP versão 2 suporta qualquer campo, mas os listados podem ser particularmente úteis em ambientes comutados e são utilizados no CatOS.

Observação:  Quando um switch executa CDPv1, ele descarta quadros v2. Quando um switch que executa o CDPv2 receber um quadro CDPv1 em uma interface, ele começará 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 configurado no dispositivo.

10

VLAN Nativo

Em dot1Q, esta é a VLAN não marcada.

11

Bidirecional/Semi-duplex

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

Recomendação

CDP está habilitado por padrão e é essencial para ganhar visibilidade de dispositivos adjacentes e para a solução de problemas. É também utilizado por aplicativos de gerenciamento de redes para construir mapas de topologia L2. Execute este comando para configurar CDP:

            set cdp enable
            
               !--- Este é o padrão.
            
            set cdp version v2
            
               !--- Este é o padrão.
            
         

Nas partes da rede onde um nível alto de segurança é exigido (como na face Internet DMZs), o CDP deve ser desativado:

            set cdp disable port range
            
         

O comando show cdp neighbors exibe a tabela CDP local. As entradas marcadas com um asterisco (*) indicam uma incompatibilidade de VLAN; as entradas marcadas com # indicam uma incompatibilidade duplex (bidirecional). Isso pode ser uma ajuda valiosa para a solução de problemas.

>show cdp neighbors

* - indicates vlan mismatch.
# - indicates duplex mismatch.
Port  Device-ID          Port-ID Platform
----- ------------------ ------- ------------
 3/1  TBA04060103(swi-2) 3/1     WS-C6506
 3/8  TBA03300081(swi-3) 1/1     WS-C6506
15/1  rtr-1-msfc         VLAN 1  cisco    Cat6k-MSFC
16/1  MSFC1b             Vlan2   cisco    Cat6k-MSFC

Outras Opções

Alguns switches, como o Catalyst 6500/6000, possuem a capacidade de fornecer energia por meio de cabos UTP para telefones IP. As informações recebidas através de CDP auxiliam no gerenciamento de potência do switch.

Como os telefones IP podem ter um PC conectado a eles, e ambos os dispositivos se conectam na mesma porta do Catalyst, o switch tem a capacidade de colocar o telefone VoIP em uma VLAN separada, a auxiliar. Isto permite que o switch aplique facilmente outra Quality of Service (QoS) ao tráfego VoIP.

Além disso, se a VLAN auxiliar for modificada (por exemplo, para forçar um telefone a usar uma VLAN específica ou um método de rotulação específico), essas informações são enviadas para o telefone por meio do CDP.

Parâmetro

Tipo

Descrição

14

Ferramenta de ID

Permite que o tráfego de VoIP seja diferenciado de outro tráfego, como uma VLAN-id (VLAN auxiliar).

16

Consumo de Energia

Total de energia que um telefone VoIP consume, em milliwatts.

Observação: Os switches Catalyst 2900 e 3500XL não suportam atualmente o CDPv2.

Configuração de Segurança

Idealmente, o cliente já estabeleceu uma política de segurança para ajudar a definir quais ferramentas e tecnologias da Cisco estão qualificadas.

Observação: A segurança do Cisco IOS Software, ao contrário do CatOS, é abordada em muitos documentos, como o Cisco ISP Essentials.

Recursos Básicos de Segurança

Senhas

Configure o nível de usuário e a senha (login). As senhas diferenciam maiúscula e minúscula no CatOS 5.x e nas versões mais recentes e podem ter de 0 a 30 caracteres de comprimento, incluindo os espaços. Configure a habilitação de senha secreta:

            
set password password
set enablepass password
            
         

Todas as senhas devem atender os padrões mínimos de comprimento (por exemplo, mínimo de seis caracteres, uma mistura de letras e números, letras maiúsculas e minúsculas) para login e ativação de senhas quando usadas. Essas senhas são criptografadas usando o algoritmo MD5 hashing.

Para permitir mais flexibilidade no gerenciamento de segurança de senha e acesso a dispositivos, a Cisco recomenda o uso de um servidor TACACS+. Consulte a seção TACACS+ desse documento para obter mais informações.

Secure Shell

Utilize criptografia SSH para fornecer segurança para as sessões de Telnet e outras conexões remotas para o switch. A criptografia SSH é suportada apenas em logins remotos para o switch. Não é possível criptografar as sessões Telnet iniciadas do switch. A versão 1 do SSH é suportada no CatOS 6.1, e o suporte da versão 2 foi adicionado no CatOS 8.3. A versão 1 do SSH suporta os métodos de criptografia Padrão de Criptografia de Dados (DES) e DES triplo (3-DES), e a versão 2 do SSH suporta os métodos de criptografia 3-DES e Padrão de Criptografia Avançado (AES). Você pode utilizar a criptografia SSH com autenticação RADIUS e TACACS+. Este recurso é suportado com imagens SSH (k9). Consulte Como Configurar SSH em Switches Catalyst Executados em CatOS para obter mais detalhes.

            set crypto key rsa 1024
         

Para desabilitar o recuo da versão 1 e aceitar as conexões da versão 2, execute estse comando:

            set ssh mode v2
         

IP Permite Filtros

Esses são filtros para proteger o acesso à interface sc0 de gerenciamento por meio de Telnet e outros protocolos. Esses filtros são particularmente importantes quando o VLAN utilizado para gerenciamento também contém usuários. Execute estes comandos para habilitar o endereço IP e a filtragem da porta:

            
set ip permit enable
set ip permit IP address
               mask
               Telnet|ssh|snmp|all
            
         

Entretanto, se o acesso Telnet for restringido com esse comando, o acesso a dispositivos do CatOS só poderá ser feito por meio de poucas estações finais confiáveis. Essa configuração pode ser um obstáculo para a solução de problemas. Lembre-se que é possível falsificar endereços IP e enganar o acesso filtrado, de modo que esta é apenas a primeira camada de proteção.

Segurança da Porta

Pense em utilizar segurança de porta para permitir que apenas um ou vários endereços MAC conhecidos passem dados em uma determinada porta (para impedir que estações finais estáticas sejam trocadas por novas estações sem controle de alteração, por exemplo). Isto é possível através de endereços MAC estáticos.

            set port security mod/port enable MAC address
            
         

Isto também é possível através do aprendizado dinâmico de endereços MAC restritos.

            set port security port range enable 
         

Essas opções podem ser configuradas:

  • set port security mod/port age time value —especifica a duração para qual endereços na porta são assegurados antes que um novo endereço seja aprendido. O tempo válido em minutos é 10 - 1440. O padrão não tem envelhecimento.

  • set port securitymod/port maximum value —palavra-chave que especifica o número máximo de endereços MAC para assegurar a porta. Os valores válidos são 1 (padrão) - 1025.

  • set port security mod/port violation shutdown—fecha a porta (padrão) se ocorre violação, como também envia mensagens de syslog (padrão) e descarta o tráfego.

  • set port security mod/port shutdown time value —duração para a qual uma porta se mantém desativada. Os valores válidos são 10 a 1440 minutos. O padrão é permanentemente desligado

Com o CatOS 6.x e posteriores, a Cisco introduziu uma autenticação 802.1x que permite aos clientes se autenticarem a um servidor central antes que as portas sejam habilitadas para os dados. Esse recurso está nos estágios iniciais de suporte em plataformas como Windows XP, mas pode ser considerado como uma orientação estratégica por muitas empresas.

Banner de Login

Cria banners de dispositivos apropriados para relatar especificamente as ações realizadas por acessos não-autorizados. Não anuncie nome de site ou dados de rede que possam fornecer informações a usuários não autorizados. Esses banners fornecem recursos no caso de um dispositivo estar comprometido e o perpetrador for pego:.

# set banner motd ^C
            *** Proibido Acesso Não-Autorizado***
***  Todas as transações são registradas   ***
------------- Placa de Notas -------------
----Contacte Joe Cisco em 1 800 go cisco para problemas de acesso----
^C
         

Segurança Física

Os dispositivos não devem ser acessados fisicamente sem autorização própria, então o equipamento deve estar em um espaço controlado (lacrado) para garantir que a rede se mantenha operacional e não seja afetada por ocupação maliciosa de fator ambiental, todos os equipamentos devem ter UPS próprio (com origens redundantes onde possível) e controle de temperatura (ar condicionado). Lembre-se de que, se o endereço físico for violado por uma pessoa com má intenção, será muito mais provável a interrupção via recuperação de senha ou outros métodos.

Terminal Access Controller Access Control System

Por padrão, nenhuma senha de modo privilegiado ou não é global e aplica-se a todos os usuários que acessam o switch ou o roteador, seja a partir da porta do console ou via uma sessão de Telnet na rede. A implementação nos dispositivos de rede consome tempo e não é centralizada. Também é difícil implementar as restrições de acesso usando listas de acesso que podem estar sujeitas a erros de configuração.

Três sistemas de segurança estão disponíveis para ajudar a controlar e vigiar o acesso a dispositivos de rede. Esses utilizam arquiteturas de clientes/servidores para localizar todas as informações de segurança em um único banco de dados central. Esses três sistemas de segurança são:

  • TACACS+

  • radius

  • Kerberos

O TACACS+ é uma implementação comum em redes Cisco e é o foco deste capítulo. Ele fornece esses recursos:

  • Autenticação—o processo de identificação e verificação para um usuário. Diversos métodos podem ser utilizados para autenticar um usuário, mas o mais comum inclui uma combinação de nome de usuário e senha.

  • Autorização—de vários comandos pode ser concedido uma vez que o usuário é autenticado.

  • Contabilidade — o registro do que o usuário está fazendo ou fez no dispositivo.

Consulte Configurando TACACS+, RADIUS, e Kerberos em Switches de Catalyst Cisco para mais detalhes.

Visão Geral Operacional

O protocolo TACACS+ encaminha nomes de usuário e senhas para o servidor centralizado, criptografados sobre a rede, usando hashing MD5 de sentido único (RFC 1321 leavingcisco.com). Utiliza a porta TCP 49 como protocolo de transporte; oferece essas vantagens sobre o UDP (utilizado pelo RADIUS):

  • Transporte orientado por conexão

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

  • 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 comando particular. Isso melhora o controle sobre os comandos que podem ser executados no switch durante o desacoplamento do mecanismo de autenticação. Utilizando o comando de contabilidade, é possível registrar os comandos que um usuário particular executou enquanto anexado a um dispositivo de rede particular.

103h.gif

Quando um usuário tenta fazer um login simples ASCII pela autenticação a um dispositivo de rede com TACACS+, este processo geralmente ocorre:

  • Quando a conexão é estabelecida, o switch contacta o daemon TACACS+ para obter um alerta de nome de usuário, o qual é exibido ao 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 alerta de senha ao usuário, que então insere uma senha que é enviada ao daemon TACACS+.

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

    • ACEITAR—o usuário é autenticado e o serviço pode ser iniciado. Se o dispositivo de rede está configurado para requerer uma autorização, a autorização inicia neste momento.

    • REJEITAR—o usuário falhou na autenticação. Poderá ser negado acesso ao usuário, ou ele é solicitado a tentar novamente a seqüência de login, dependendo do daemon TACACS+.

    • ERROR—ocorreu um erro em algum momento durante a autenticação. Isto pode ser no daemon ou na conexão de rede entre o daemon e o switch. Se uma resposta de ERRO é recebida, o dispositivo de rede tenta naturalmente utilizar um método alternativo para autenticar o usuário.

    • CONTINUAR—o usuário é solicitado por informações de autenticação adicionais.

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

  • Se a autorização TACACS+ for exigida, o daemon TACACS+ é contactado novamente e retorna uma resposta de autorização ACEITA ou REJEITA. Se uma resposta ACCEPT retornar, a resposta contém os dados na forma de atributos usados para direcionar a sessão EXEC ou NETWORK para esse usuário, e determina os comandos que o usuário pode acessar.

Recomendação

A Cisco recomenda a utilização de TACACS+, uma vez que pode ser facilmente implementado utilizando o CiscoSecure ACS para NT, Unix, ou outros softwares de terceiros. Os recursos TACACS+ incluem contabilidade detalhada para fornecer estatísticas sobre uso de comandos e do sistema, algoritmo de criptografia MD5 e controle administrativo dos processos de autenticação e de autorização.

Neste exemplo, faça login e permita que os modos usem o servidor TACACS+ para Autenticação e possam se enquadrar na autenticação local se o servidor não estiver disponível. Esta é uma importante back door a ser deixada na maior parte das redes. Execute este comando para configurar TACACS+:

            set tacacs server server IP primary
set tacacs server server IP
            
            
               !--- Servidores redundantes são possíveis.
            
            set tacacs attempts 3
            
               !--- Este é o padrão.
            
            set tacacs key key
            
            
               !--- Chave de criptografia MD5.
            
            set tacacs timeout 15
            
               !--- Expiração de servidor mais longo (5 é o padrão).
            
            set authentication login tacacs enable
set authentication enable tacacs enable
set authentication login local enable
set authentication enable local enable
            
               !--- Os dois últimos comandos são o padrão; eles permitem recuo
!--- para o local se não houverem servidores TACACS+ disponíveis.
            
         

Outras Opções

É possível usar autorização TACACS+ para controlar os comandos que cada usuário ou grupo de usuários pode executar no switch, mas é difícil fazer uma recomendação, porque todos os clientes possuem requisitos específicos nessa área. Consulte Controlando o Acesso ao Switch Utilizando Autenticação, Autorização e Contabilidade para obter mais informações.

Finalmente, os comandos de contabilidade fornecem uma trilha de auditoria do que cada usuário digitou e configurou. Este é um exemplo utilizando a prática comum de receber as informações de auditoria no final do comando:

            set accounting connect enable start-stop tacacs+
set accounting exec enable start-stop tacacs+
set accounting system enable start-stop tacacs+
set accounting commands enable all start-stop tacacs+
set accounting update periodic 1
         

Esta configuração tem estes recursos:

  • O comando connect permite a contabilidade de eventos de conexão de saída no switch, como o Telnet.

  • O comando exec habilita a contabilidade de sessões de login no switch como da equipe de operações.

  • O comando system habilita a contabilidade dos eventos do sistema no switch como recarga ou reinicialização.

  • O comando commands habilita a contabilidade do que foi inserido no switch, para os comandos show e configuration.

  • As atualizações periódicas a cada minuto no servidor são úteis para registrar se os usuários ainda estão conectados.

Lista de Verificação de Configuração

Esta seção fornece um sumário das configurações recomendadas, excluindo detalhes de segurança.

Ela é extremamente útil para identificar todas as portas. Execute este comando para identificar as portas:

            set port description descriptive name
            
         

Use esta tecla juntamente com as tabelas de Comando listadas:

Tecla:

Texto em negrito - alteração recomendada

Texto normal - padrão, configuração recomendada

Comandos de Configuração Global

Comando

Comentário

set vtp domain name passwordx

Protege contra atualizações de VTP não autorizadas dos novos switches.

set vtp mode transparent

Selecione o modo VTP promovido neste documento. Consulte a seção Protocolo de Entroncamento VLAN deste documento para mais detalhes.

definir habilitação de árvore de abrangência todos

Assegure que o STP está habilitado em todos os VLANs.

set spantree root vlan

Recomendada para posição das pontes-raiz (e a raiz secundária) por VLAN.

set spantree backbonefast enable

Permite a convergência rápida STP das falhas indiretas (apenas se todos os switches no domínio suportarem o recurso).

set spantree uplinkfast enable

Permite a convergência rápida STP das falhas diretas (apenas para os switches da camada de acesso).

set spantree portfast bpdu-guard enable

Permite que a porta seja fechada automaticamente se houver uma extensão da Árvore de Abrangência não autorizada.

set udld enable

Permite a detecção de link unidirecional (necessita também da configuração do nível de porta).

set test diaglevel complete

Permite diagnósticos completos na inicialização (padrão no Catalyst 4500/4000).

set test packetbuffer sun 3:30

Permitir verificação de erro do buffer da porta (se aplica apenas ao Catalyst 5500/5000).

Define buffer de registro 500

Mantém buffer de syslog interno máximo.

set logging server IP address

Configure servidor de syslog de destino para registro de mensagens externas do sistema.

set logging server enable

Permite o servidor de registro externo.

set logging timestamp enable

Permite rótulos de tempo das mensagens no registro.

set logging level spantree 6 default

Aumente o nível de syslog STP padrão.

set logging level sys 6 default

Aumente o nível padrão do syslog do sistema.

set logging server severity 4

Permite a exportação apenas do maior syslog de severidade.

set logging console disable

Desabilita o console a menos que a solução de problemas.

set snmp community read-only string

Configure a senha para permitir a coleta de dados remotos.

set snmp community read-write string

Configure a senha para permitir a configuração remota.

set snmp community read-write-all string

Configure a senha para permitir a configuração remota incluindo senhas.

set snmp trap enable all

Habilita os desvios de SNMP ao servidor NMS para os alertas de falha e de eventos.

set snmp trap server address string

Configure o endereço do receptor do desvio de NMS.

set snmp rmon enable

Permite que o RMON acumule estatísticas locais. Consulte a seção Monitoramento Remoto deste documento para mais detalhes.

set ntp broadcastclient enable

Permite a recepção do relógio de sistema preciso por um roteador de upstream.

set ntp timezone zone name

Define o fuso horário local do dispositivo.

set ntp summertime date change details

Configure o horário de verão se aplicável no fuso horário.

set ntp authentication enable

Configure a informação de hora criptografada das finalidades de segurança.

set ntp key key

Configure a chave de criptografia.

set cdp enable

Assegure-se que a descoberta vizinha está habilitada (habilitada nas portas por padrão).

set tacacs server IP address primary

Configure o endereço do servidor AAA.

set tacacs server IP address

Servidores redundantes AAA se possível.

definir 3 tentativas de TACACS

Permita 3 tentativas de senha para a conta de usuário AAA.

set tacacs key key

Configure a chave de criptografia AAA MD5.

set tacacs timeout 15

Permite uma maior expiração de servidor (cinco segundos é o padrão).

set authentication login tacacs enable

Use AAA para autenticar o logon.

set authentication enable tacacs enable

Use AAA para autenticar o modo ativado.

set authentication login local enable

Padrão; permite o recuo para o local se não houver servidor AAA disponível.

set authentication enable local enable

Padrão; permite o recuo para o local se não houver servidor AAA disponível.

Comandos de Configuração de Portas de Host

Comando

Comentário

set port host port range

Remove o processamento desnecessário de portas. Este macro configura a habilitação do PortFast de árvore de abrangência, canal desligado, tronco desligado.

set udld disable port range port range

Remove o processamento desnecessário de porta (desativado na porta de cobre por padrão).

set port speed port range auto

Use a negociação automática com os drivers de NIC atualizados.

set port trap port range disable

Sem necessidade de desvios de SNMP para usuários gerais; rastrear apenas portas de chave.

Comandos de Configuração do Servidor

Comando

Comentário

set port host port range

Remove o processamento desnecessário de portas. Este macro configura a habilitação do PortFast de árvore de abrangência, canal desligado, tronco desligado.

set udld disable port range port range

Remove o processamento desnecessário de porta (desativado na porta de cobre por padrão).

set port speed port range 10 | 100

Geralmente configure portas estáticas/de servidor; caso contrário, use a negociação automática.

set port duplex port range full | half

Geralmente portas estáticas/de servidor; caso contrário, use a negociação automática.

set port trap port range enable

As portas de serviço da chave devem enviar desvios ao NMS.

Comandos de Configuração de Portas Não Usadas

Comando

Comentário

set spantree portfast port range disable

Ativar o processamento de porta necessário e a proteção ao STP.

set port disable port range

Desativa as portas não usadas.

set vlan unused dummy vlan port range

Direciona o tráfego não autorizado para o VLAN não usado se a porta for habilitada.

set trunk port range off

Desabilita o entroncamento da porta até que seja administrada.

set port channel port range mode off

Desabilita a canalização da porta até que seja administrada.

Portas de Infra-estrutura (switch-switch, switch-roteador)

Comando

Comentário

set udld enable port range

Habilita a detecção de link unidirecional (não padrão nas portas de cobre).

set udld aggressive-mode enable port range

Habilita o modo assertivo (para dispositivos que o suportam).

set port negotiation port rangeenable

Habilita a negociação automática GE padrão dos parâmetros de link.

set port trap port range enable

Habilita os desvios de SNMP nestas portas de chave.

set trunk port range off

Desabilita o recurso se não estiver usando troncos.

set trunk mod/port desirable ISL | dot1q | negotiate

Se usar troncos, o dot1q é preferível.

clear trunk mod/port vlan range

Limita o diâmetro STP podando VLANs dos troncos onde não são mais necessários.

set port channel port range mode off

Desativa o recurso se não forem usados canais.

set port channel port range mode desirable

Se usar canais, isto habilita o PAgP.

set port channel all distribution ip both

Permite o balanceamento de carga de origem/destino L3 se forem usados canais (padrão no Catalyst 6500/6000).

set trunk mod/port nonegotiate ISL | dot1q

Desativa o DTP se houver entroncamento ao roteador, Catalyst 2900XL, 3500, ou outro fornecedor.

set port negotiation mod/port disable

A negociação pode ser incompatível em alguns dispositivos GE antigos.

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: 13414