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

Introdução

Este documento discute a implementação de switches da série Cisco Catalyst em sua rede, especificamente as plataformas Catalyst 4500/4000, 5500/5000 e 6500/6000. As configurações e os comandos são discutidos sob a suposição de que você está executando o Software de Implementação Geral do Catalyst OS (CatOS) 6.4(3) ou o mais recente. Embora algumas considerações de projeto sejam apresentadas, este documento não cobre todo o projeto de campus.

Pré-requisitos

Requisitos

Este documento pressupõe familiaridade com a Referência de Comandos da Série Catalyst 6500, 7.6.

Embora referências a materiais públicos on-line para posterior leitura sejam fornecidas em todo o documento, estas são outras referências básicas e educacionais:

• Cisco ISP Essentials — recursos essenciais do IOS que todo ISP deve considerar.

• Diretrizes de monitoramento da rede Cisco e de correlação de evento

• Projeto de rede de campus Gigabit - Princípios e arquitetura

• Cisco SAFE: Um projeto de segurança para redes de empresa

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

Conventions

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

Informações de Apoio

Essas soluções representam anos de experiência em campo de engenheiros da Cisco que trabalham com muitos de nossos maiores clientes e redes complexas. Consequentemente, este documento enfatiza as configurações reais que fazem com que as redes sejam bem-sucedidas. Este documento oferece as seguintes soluções:

• Soluções que possuem estatisticamente a mais ampla exposição de campo e, portanto, o menor risco.

• Soluções que são simples, trocando alguma flexibilidade por resultados determinísticos.

• Soluções fáceis de gerenciar e configuradas pelas equipes de operações de rede.

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

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

• Configuração Básica— recursos usados pela maioria das redes, como o Protocolo Spanning Tree (STP) e entroncamento.

• Configuração de gerenciamento — considerações de projeto juntamente com o monitoramento de sistema e eventos usando o Simple Network Management Protocol (SNMP), o Remote Monitoring (RMON), o Syslog, o Cisco Discovery Protocol (CDP) e o Network Time Protocol (NTP).

• Configuração de segurança— senhas, segurança de porta, segurança física e autenticação usando TACACS+.

• Lista de verificação de configuração — resumo dos modelos de configuração sugeridos.

Configuração básica

Os recursos implantados com a maioria das redes Catalyst são discutidos nesta seção.

Protocolos do plano controle Catalyst

Esta seção apresenta os protocolos que são executados entre os Switches em operação normal. Uma compreensão básica desses protocolos é útil para lidar com cada seção.

Tráfego de Supervisor

A maioria dos recursos ativados em uma rede Catalyst exige a cooperação de dois ou mais Switches; portanto, deve haver uma troca controlada de mensagens de manutenção de atividade, parâmetros de configuração e alterações de gerenciamento. Quer esses protocolos sejam proprietários da Cisco, como o CDP, ou baseados em padrões, como o IEEE 802.1d (STP), todos têm certos elementos em comum quando implementados na série Catalyst.

No encaminhamento básico de quadros, os quadros de dados do usuário se originam de sistemas finais e seus endereços de origem e destino não são alterados em todos os domínios comutados da camada 2 (L2). As tabelas de pesquisa de CAM (Content Addressable Memory) em cada Supervisor Engine do switch são preenchidas por um processo de aprendizagem de endereço de origem e indicam qual porta de saída deve encaminhar cada quadro recebido. Se o processo de aprendizagem de endereço estiver incompleto (o destino é desconhecido ou o quadro é destinado a um endereço de broadcast ou multicast), ele será encaminhado (inundado) por todas as portas naquela VLAN.

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

O plano de controle do Catalyst é criado usando entradas especiais na tabela CAM chamadas entradas de sistema para receber e direcionar o tráfego para o NMP em uma porta de switch interno. Portanto, ao usar protocolos com endereços MAC de destino bem-conhecidos, é possível separar o tráfego de controle plano do tráfego de dados. Emita o comando show CAM system em um switch para confirmar isso, como 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

!--- NMP internal port.

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

!--- CDP and so on.

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

!--- Cisco STP.

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

!--- IEEE STP.

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

!--- IEEE flow control.

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

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

...

A Cisco tem uma faixa reservada de endereços MAC Ethernet e de protocolos, como mostrado. Cada um deles será abordado posteriormente neste documento. No entanto, um resumo é apresentado nesta tabela para conveniência.

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

• Esses protocolos supõem conectividade ponto a ponto. Observe que o uso deliberado de endereços de destino multicast permite que dois Catalysts se comuniquem de forma transparente por switches que não sejam da Cisco, pois os dispositivos que não entendem e interceptam os quadros simplesmente os inundam. No entanto, as conexões ponto a multiponto por meio de ambientes de vários fornecedores podem resultar em comportamento inconsistente e devem ser geralmente evitadas.

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

• Esses protocolos recebem priorização sobre os dados do usuário pelo processamento e programação do circuito integrado específico de aplicação (ASIC) de entrada.

Após a introdução dos endereços de destino do protocolo de controle, o endereço de origem também deve ser descrito para ser completo. Protocolos de Switch usam um MAC Address retirado de um banco de endereços disponíveis fornecidos por um EPROM no chassi. Execute o comando show module para exibir os intervalos de endereços disponíveis para cada módulo quando ele origina tráfego, como unidades de dados de protocolo de ponte (BPDUs) STP ou quadros ISL.

>show module

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

!--- MACs for sourcing traffic.

...
VLAN 1

VLAN 1

VLAN 1 possui um significado especial em redes Catalyst.

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

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

• A VLAN de gerenciamento é onde o sc0 reside; essa VLAN pode ser alterada.

• A VLAN nativa é definida como a VLAN à qual uma porta retorna quando não está fazendo entroncamento e é a VLAN não marcada em um tronco 802.1Q. Por padrão, a VLAN 1 é a VLAN nativa.

• Para alterar a VLAN nativa, execute o comando set vlan vlan-id mod/port.

  Observação: crie a VLAN antes de defini-la como a VLAN nativa do tronco.

Estas são várias boas razões para ajustar uma rede e alterar o comportamento das portas na VLAN 1:

• Quando o diâmetro da VLAN 1, como de qualquer outra VLAN, se torna grande o suficiente para representar um risco à estabilidade (particularmente de uma perspectiva de STP), ela precisa ser reduzida. Isso é discutido com mais detalhes na seção In-Band Management deste documento.

• Os dados do plano de controle na 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 na VLAN 1 devem ser evitados quando as redes de campus multicamada são projetadas sem STP e o entroncamento ainda é necessário para a camada de acesso se houver várias VLANs e sub-redes IP. Para fazê-lo, limpe a VLAN 1 manualmente das portas de tronco.

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

• As atualizações de CDP, VTP e PAgP são sempre encaminhadas aos troncos com uma etiqueta VLAN 1. Esse é o caso mesmo se a VLAN 1 for removida dos troncos e não for a VLAN nativa. Se a VLAN 1 for limpa para dados do usuário, isso não afetará o tráfego do plano de controle que ainda é enviado usando a VLAN 1.

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

• No PVST+, os BPDUs IEEE 802.1Q são encaminhados sem marcação na VLAN 1 de árvore de abrangência comum para interoperabilidade com outros fornecedores, a menos que a VLAN 1 seja removida do tronco. Esse é o caso, independentemente da configuração da VLAN nativa. As BPDUs do Cisco PVST+ são enviadas e marcadas para todas as outras VLANs. Consulte a seção Spanning Tree Protocol neste documento para obter mais detalhes.

• As BPDUs do MST (Multiple Spanning Tree) 802.1s são sempre enviadas na VLAN 1 em ambos os troncos ISL e 802.1Q. Isso se aplica mesmo quando a VLAN 1 é removida dos troncos.

• Não limpe ou desative a VLAN 1 nos troncos entre as bridges MST e as bridges PVST+. Mas, no caso de que a VLAN 1 está desabilitada, a ponte MST deve se tornar raiz para que todas as VLANs evitem que a ponte MST coloque suas portas de limite no estado de raiz inconsistente. Consulte Entendendo o Protocolo de Árvore de Abrangência Múltipla (802.1s) para obter detalhes.

Recomendações

Para manter uma VLAN em um estado up/up sem clientes ou hosts conectados a essa VLAN , você precisa ter pelo menos um dispositivo físico conectado a essa VLAN. Caso contrário, a VLAN terá um estado up/down. Atualmente, não há nenhum comando para colocar uma interface VLAN up/up quando não há portas ativas no switch para essa VLAN.

Se você não quiser conectar um dispositivo, conecte um conector de loopback em qualquer porta para essa VLAN. Como alternativa, tente um cabo cruzado que conecte duas portas nessa VLAN no mesmo switch. Esse método força a porta a ficar ativa. Consulte a seção Loopback Plug de Testes de Loopback para Linhas T1/56K para obter mais informações.

Quando uma rede é multihomed para provedores de serviços, a rede atua como uma rede de trânsito entre dois provedores de serviços. Se o número de VLAN recebido em um pacote precisar ser convertido ou alterado quando passado de um provedor de serviços para outro, é aconselhável usar o recurso QinQ para converter o número de VLAN.

Protocolo de truncamento VLAN

Antes de criar VLANs, determine o modo de VTP a ser usado 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 mensagens L2 que mantém a consistência da configuração da VLAN. O VTP gerencia a adição, exclusão e renomeação de VLANs em 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 Ethernet (01-00-0c-cc-cc-cc) e o tipo de protocolo SNAP HDLC Ox2003. Ele não funciona em portas não tronco (o VTP é um payload de ISL ou 802.1Q), portanto, as mensagens não podem ser enviadas até que o DTP coloque o tronco on-line.

Os tipos de mensagem incluem anúncios de resumo a cada cinco minutos, anúncios de subconjunto e anúncios de solicitação quando há alterações e junções quando a remoção de VTP está 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 excluído, as portas que já fizeram parte desse VLAN são colocados em um estado de inatividade. Da mesma forma, se um switch no modo cliente não puder receber a tabela VLAN VTP na inicialização (de um servidor VTP ou de outro cliente VTP), todas as portas em VLANs diferentes da VLAN 1 padrão serão desativadas.

Esta tabela fornece um resumo de comparação de recursos para vários modos de VTP:

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

¹ O CatOS Software Release 7.1 introduz a opção para desativar o VTP com o uso do modo desligado. No modo desligado do VTP, o switch se comporta de uma maneira muito semelhante ao modo transparente do VTP, exceto que o modo desligado também suprime o encaminhamento de atualizações do VTP.

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

O VTP versão 2 (VTPv2) inclui essa flexibilidade funcional. No entanto, não é interoperável com o VTP versão 1 (VTPv1):

• Suporte a Token Ring

• Suporte de informação VTP não reconhecido; os switches agora propagam valores que não podem analisar.

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

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

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

VTP Versão 3

O CatOS Software Release 8.1 introduz suporte para VTP Versão 3 (VTPv3). O VTPv3 fornece melhorias em relação às versões existentes. Esses aprimoramentos permitem:

• Suporte para VLANs estendidas

• Suporte para a criação e anúncio de VLANs privadas

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

• Autenticação de servidor aprimorada

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

• Interação com VTPv1 e VTPv2

• A capacidade de ser configurado por porta

Uma das principais diferenças entre a implementação do VTPv3 e a versão anterior é 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 estiver particionado. Quaisquer alterações feitas no domínio VTP devem ser executadas no servidor primário VTP para serem propagadas para o domínio VTP. Pode haver vários servidores dentro de um domínio VTPv3, que também são conhecidos como servidores secundários. Quando um switch é configurado para ser um servidor, o switch 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 uma transferência bem-sucedida do switch.

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

O VTPv3 também introduz um aprimoramento no modo como o VTP trata as senhas. Se você usar a opção de configuração de senha oculta para configurar uma senha como "oculta", estes itens ocorrerão:

• 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 um servidor primário, será solicitada a senha. Se a senha coincidir com a senha secreta, o switch se tornará um servidor primário, o que permitirá que você configure o domínio.

Observação: é importante observar que o servidor primário só é necessário quando você precisa modificar a configuração do VTP para qualquer instância. Um domínio VTP pode operar sem nenhum servidor primário ativo porque os servidores secundários garantem a persistência da configuração sobre as recargas. O estado do servidor primário é encerrado por estes motivos:

• Uma recarga do switch

• Um switchover de alta disponibilidade entre os mecanismos supervisores ativo e redundante

• Uma transferência de outro servidor

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

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

  • Versão

  • Nome de domínio

  • Senha de domínio

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

Em termos de interação com VTPv1 e VTPv2, o comportamento padrão em todas as versões do VTP tem sido que as versões anteriores do VTP simplesmente descartam as novas atualizações de versão. A menos que os switches VTPv1 e VTPv2 estejam no 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 legado em um tronco, os switches passam uma versão reduzida de sua atualização de banco de dados para os switches VTPv1 e VTPv2. No entanto, essa troca de informações é unidirecional, pois nenhuma atualização dos switches VTPv1 e VTPv2 é aceita pelos switches VTPv3. Em conexões de tronco, os switches VTPv3 continuam a enviar atualizações reduzidas, bem como atualizações VTPv3 completas, a fim de atender à existência de vizinhos VTPv2 e VTPv3 através das portas de tronco.

Para fornecer suporte a VTPv3 para VLANs estendidas, o formato do banco de dados de VLAN, no qual o VTP atribui 70 bytes por VLAN, é alterado. A alteração permite a codificação apenas de valores não padrão, em vez do transporte de campos não modificados para os protocolos herdados. Devido a essa alteração, o suporte a VLAN 4K é do tamanho do banco de dados de VLAN resultante.

Recomendação

Não há nenhuma especificação sobre o uso de modos cliente/servidor de VTP ou do modo transparente de VTP. Alguns clientes preferem a facilidade de gerenciamento do modo cliente/servidor do VTP, apesar de algumas considerações observadas posteriormente. A recomendação é ter dois switches de modo de servidor 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 definido para o modo cliente. Ao implementar o modo cliente/servidor com o uso do VTPv2, tenha em mente que um número de revisão mais alto é sempre aceito no mesmo domínio VTP. Se um switch configurado no modo cliente ou servidor do VTP for introduzido no domínio do VTP e tiver um número de revisão mais alto do que os servidores VTP existentes, isso substituirá o banco de dados da VLAN dentro do domínio do VTP. Se a alteração na configuração não for intencional e as VLANs forem excluídas, a substituição poderá causar uma grande interrupção na rede. Para garantir que os switches cliente ou servidor sempre tenham um número de revisão de configuração inferior ao do servidor, altere o nome de domínio VTP do cliente para algo diferente do nome padrão. Em seguida, reverta para o padrão. Esta ação define a revisão de configuração no cliente como 0.

Há prós e contras na capacidade do VTP de fazer alterações facilmente em uma rede. Muitas empresas preferem a abordagem cautelosa do modo transparente de VTP por estes motivos:

• Ele incentiva uma boa prática de controle de alterações, pois o requisito para modificar uma VLAN em um switch ou porta de tronco deve ser considerado um switch de cada vez.

• Ele limita o risco de um erro de administrador que afeta todo o domínio, como a exclusão de uma VLAN acidentalmente.

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

• Ele estimula as VLANs a serem removidas dos troncos em execução nos switches que não têm portas nessa VLAN. Isso torna a inundação de quadros mais eficiente em termos de largura de banda. A remoção manual também é benéfica porque reduz o diâmetro do spanning tree (consulte a seção DTP deste documento). Antes de remover as VLANs não utilizadas nos troncos do canal de porta, certifique-se de que todas as portas conectadas aos telefones IP estejam configuradas como portas de acesso com VLAN de voz.

• O intervalo de VLAN estendido no CatOS 6.x e no CatOS 7.x, números de 1025 a 4094, só pode ser configurado dessa maneira. Para obter mais informações, consulte a seção VLAN estendida e redução de endereço MAC deste documento.

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

Observação: especificar 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 define a lista permitida apenas para as VLANs 1-10. Execute o comando clear trunk x/y 11-1005 para obter o resultado desejado.

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

Outras opções

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

O VTPv3 oferece a capacidade de implementar autenticação mais rigorosa e controle de revisão de configuração. O VTPv3 fornece essencialmente o mesmo nível de funcionalidade, mas com segurança mais avançada, como o modo transparente VTPv1/VTPv2 oferece. Além disso, o VTPv3 é parcialmente compatível com as versões do VTP legado.

Os benefícios da remoção de VLANs para reduzir a inundação desnecessária de quadros são defendidos neste documento. O comando set vtp pruning enable remove VLANs automaticamente, o que interrompe a inundação ineficiente de quadros onde eles não são necessários. Diferentemente da remoção manual de VLAN, a remoção automática não limita o diâmetro do Spanning Tree.

A partir do CatOS 5.1, os switches Catalyst podem mapear números VLAN 802.1Q maiores que 1000 para números VLAN ISL. No CatOS 6.x, os switches Catalyst 6500/6000 suportam 4096 VLANs de acordo com o padrão IEEE 802.1Q. Essas VLANs são organizadas nesses três intervalos, apenas alguns dos quais são propagados para outros switches na rede com VTP:

• VLANs de intervalo normal: 1–1001

• VLANs de intervalo estendido: 1025-4094 (só pode ser propagado por VTPv3)

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

O IEEE produziu uma arquitetura baseada em padrões para atingir resultados semelhantes aos do VTP. Como membro do 802.1Q Generic Attribute Registration Protocol (GARP), o Generic VLAN Registration Protocol (GVRP) permite 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 o VTP para o modo desligado, um modo muito similar ao transparente. No entanto, o switch não encaminha quadros VTP. Isso pode ser útil em alguns projetos quando o entroncamento para switches estiver fora do controle administrativo.

VLAN estendida e redução de endereço MAC

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

Visão Geral da Operação

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

Os switches Catalyst com endereços MAC 1024 não permitem a redução de endereços MAC por padrão. Os endereços MAC são alocados sequencialmente. O primeiro endereço MAC no intervalo é atribuído à VLAN 1. O segundo endereço MAC no intervalo é atribuído à VLAN 2 e assim por diante. Isso permite que os switches suportem 1024 VLANs com cada VLAN usando um identificador de bridge exclusivo.

¹ 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.

Para os switches da série Catalyst com 1024 endereços MAC, uma habilitação de redução de endereço MAC permite o suporte de 4096 VLANs que são executadas em instâncias de PVST+ ou 16 instâncias de STP de Várias Instâncias (MISTP) para ter identificadores exclusivos sem um aumento no número de endereços MAC que são necessários no switch. A redução de endereços MAC reduz o número de endereços MAC exigidos pelo STP de um por VLAN ou instância MISTP para um por switch.

Esta figura mostra que a redução de endereço MAC do identificador de bridge não está habilitada. O identificador de bridge consiste em uma prioridade de bridge de 2 bytes e um endereço MAC de 6 bytes:

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

Quando você tiver a redução de endereço MAC habilitada nos switches Catalyst para alavancar VLANs de intervalo estendido, habilite a redução de endereço MAC em todos os switches dentro do mesmo domínio STP. Esta etapa é necessária para manter os cálculos da raiz do STP em todos os switches consistentes. Depois de habilitar a redução de endereço MAC, a prioridade da bridge raiz se torna um múltiplo de 4096 mais o ID da VLAN. Os switches sem redução de endereço MAC podem reivindicar a raiz inadvertidamente porque esses switches têm uma granularidade maior na seleção do ID da bridge.

Diretrizes de configuração

Você deve seguir determinadas diretrizes ao configurar o intervalo de VLAN estendido. O switch pode alocar um bloco de VLANs do intervalo estendido para fins internos. Por exemplo, o switch pode alocar as VLANs para as portas roteadas ou os módulos Flex WAN. A alocação do bloco de VLANs sempre começa na VLAN 1006 e aumenta. Se você tiver qualquer VLAN dentro do intervalo exigido pelo módulo Flex WAN, todas as VLANs necessárias não serão alocadas porque as VLANs nunca são alocadas da área da VLAN do usuário. Execute o comando show vlan ou o comando show vlan summary em um switch para exibir as VLANs internas e atribuídas pelo usuário.

>show vlan summary

Current Internal Vlan Allocation Policy - Ascending

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

Internal           7   1006-1011,1016

!--- These are internal VLANs.

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

1    default                          active    7       4/1-48



!--- Output suppressed.


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

!--- These are internal VLANs.

Além disso, antes de usar as VLANs de intervalo estendido, você deve excluir todos os mapeamentos 802.1Q-to-ISL existentes. Além disso, em versões anteriores ao VTPv3, você deve configurar estaticamente a VLAN estendida em cada switch com o uso do modo transparente do VTP. Consulte a seção Diretrizes de Configuração de VLAN de Intervalo Estendido de Configurando VLANs para obter mais informações.

Observação: no software anterior à versão 8.1(1) do software, você não pode configurar o nome da VLAN para VLANs de intervalo estendido. Esse recurso é independente de qualquer versão ou modo do VTP.

Recomendação

Tente manter uma configuração consistente de redução de endereço MAC dentro do mesmo domínio STP. No entanto, a aplicação da redução de endereços MAC em todos os dispositivos de rede pode ser impraticável quando novos chassis com 64 endereços 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 spanning tree, o sistema sem redução de endereço MAC tem uma prioridade de spanning tree melhor. Execute este comando para habilitar ou desabilitar a redução de endereço MAC:

set spantree macreduction enable | disable

A alocação das VLANs internas está em ordem crescente e começa na VLAN 1006. Atribua as VLANs de usuário o mais próximo possível da VLAN 4094 para evitar conflitos entre as VLANs de usuário e as VLANs internas. Com os switches Catalyst 6500 que executam o software do sistema Cisco IOS®, você pode configurar a alocação de VLAN interna em ordem decrescente. O equivalente da Interface de Linha de Comando (CLI) para o software CatOS não é oficialmente suportado.

Negociação automática

Ethernet/Fast Ethernet

A autonegociação é uma função opcional do padrão IEEE Fast Ethernet (FE) (802.3u) que permite que os dispositivos troquem automaticamente informações sobre um link sobre capacidades de velocidade e duplex. A autonegociação opera na Camada 1 (L1) e destina-se às portas da camada de acesso onde usuários transitórios como PCs se conectam à rede.

Visão geral operacional

A causa mais comum de problemas de desempenho em links Ethernet de 10/100 Mbps ocorre quando uma porta no link opera em half-duplex enquanto a outra está em full-duplex. Isso acontece ocasionalmente quando uma ou ambas as portas em um link são redefinidas e o processo de negociação automática não faz com que ambos 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. Os sintomas típicos disso são aumento da sequência de verificação de quadro (FCS), verificação de redundância cíclica (CRC), alinhamento ou contadores runt no switch.

A negociação automática é discutida em detalhes nesses documentos. Esses documentos incluem explicações de como a negociação automática funciona e opções de configuração.

• Configurando e Troubleshooting de Ethernet 10/100Mb Half/Full Duplex Auto-Negotiation

• Troubleshooting de Compatibilidade entre Catalyst Switches e NIC Compatibility Issues

Uma concepção equivocada comum sobre a negociação automática é 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, uma tentativa de fazer isso resulta em uma incompatibilidade duplex. Essa é uma consequência da autonegociação de um parceiro de enlace, da não visualização de nenhum parâmetro de autonegociação do outro parceiro de enlace e do padrão half-duplex.

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

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

Uma falha de extremidade oposta no enlace que uma estação pode detectar enquanto a outra não pode, como um cabo TX desconectado. Neste exemplo, a estação emissora ainda poderia receber dados válidos e detectar que o link é bom através do link-integrity-monitor. Ele não detecta que sua transmissão não está sendo recebida pela outra estação. Uma estação 100BASE-FX que detecta tal falha remota pode modificar seu fluxo IDLE transmitido para enviar um padrão de bits especial (conhecido como padrão FEFI IDLE) para informar o vizinho da falha remota; o padrão FEFI-IDLE dispara em seguida um desligamento da porta remota (ErrDisable). Consulte a seção UDLD deste documento para obter mais informações sobre proteção contra falhas.

A FEFI é suportada 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 autonegociação em links 10/100 ou a velocidade e duplex do código rígido depende do tipo de parceiro de link ou dispositivo final que você conectou a uma porta do switch Catalyst. A autonegociação entre dispositivos finais e switches Catalyst geralmente funciona bem, e os switches Catalyst são compatíveis com a especificação IEEE 802.3u. No entanto, podem ocorrer problemas quando os switches da placa de rede ou do fornecedor não estão exatamente em conformidade. A incompatibilidade de hardware e outros problemas também podem existir como resultado de recursos avançados específicos do fornecedor, como polaridade automática ou integridade de 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: Problema de desempenho com as placas de rede Intel Pro/1000T conectadas a CAT4K/6K para obter um exemplo disso.

Antecipe que haverá algumas situações que exigem que o host, a velocidade da porta e o duplex sejam definidos. Geralmente, execute as seguintes etapas básicas para o Troubleshooting:

• Certifique-se de que a negociação automática esteja configurada em ambos os lados do link ou que a codificação forçada esteja configurada em ambos os lados.

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

• Verifique a versão do driver da placa de rede ou do sistema operacional que você está executando, pois o driver ou patch mais recente é frequentemente necessário.

Como regra, tente usar a negociação automática primeiro para qualquer tipo de parceiro de link. Há benefícios óbvios na configuração da autonegociação para dispositivos transitórios, como laptops. Idealmente, a autonegociação também funciona bem com dispositivos não transitórios, como servidores e estações de trabalho fixas ou de switch para switch e de switch para roteador. Por algumas das razões mencionadas, podem surgir questões de negociação. Nesses casos, siga as etapas básicas de solução de problemas descritas nos links fornecidos para o TAC.

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

set port speed port range auto

!--- This is the default.

Se estiver codificando a porta, emita estes comandos de configuração:

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

No CatOS 8.3 e posterior, a Cisco introduziu a palavra-chave opcional auto10-100. Use a palavra-chave auto10-100 em portas que suportam velocidades de 10/100/1000 Mbps, mas onde a autonegociação para 1000 Mbps é indesejável. O uso da palavra-chave auto10-100 faz com que a porta se comporte da mesma forma que uma porta de 10/100 Mbps que tem a velocidade definida como auto. A velocidade e o duplex são negociados somente para portas de 10/100 Mbps, 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 é usada entre switches, a indicação de falha de L1 também pode ser perdida para determinados problemas. É útil usar protocolos L2 para aumentar a detecção de falhas, como UDLD agressivo.

Gigabit Ethernet

Gigabit Ethernet (GE) tem um procedimento de negociação automática (IEEE 802.3z) que é mais extenso do que o da Ethernet 10/100 Mbps e é usado para trocar parâmetros de controle de fluxo, informações de falha remota e informações duplex (mesmo que as portas GE da série Catalyst suportem apenas o modo full-duplex).

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

Visão geral operacional

A negociação de porta GE é habilitada por padrão, e as portas em ambas as extremidades de um link GE devem ter a mesma configuração. Diferentemente do FE, o link GE não aparece se a configuração de negociação automática diferir nas portas em cada extremidade do link. No entanto, a única condição necessária para que uma porta desabilitada para negociação automática se conecte é um sinal Gigabit válido da extremidade oposta. Esse comportamento é independente da configuração de negociação automática da extremidade oposta. Por exemplo, suponha que haja dois dispositivos, A e B. Cada dispositivo pode ter a negociação automática habilitada ou desabilitada. Esta tabela é uma lista de configurações possíveis e respectivos estados de link:

Na GE, a sincronização e a negociação automática (se estiverem ativadas) são executadas na inicialização do link por meio do uso de uma sequência especial de palavras de código de link reservadas.

Observação: há um dicionário de palavras válidas e nem todas as palavras possíveis são válidas em GE.

A vida útil de uma conexão GE pode ser caracterizada desta maneira:

Uma perda de sincronização significa que o MAC detecta um link inativo. A perda de sincronização se aplica se a negociação automática estiver habilitada ou desabilitada. A sincronização é perdida em determinadas condições de falha, como o recebimento de três palavras inválidas sucessivamente. Se essa condição persistir por 10 ms, uma condição "sync fail" é declarada e o link é alterado para o estado link_down. Após a perda da sincronização, outros três períodos ociosos válidos consecutivos são necessários para ressincronizar. Outros eventos catastróficos, como a perda do sinal de recepção (Rx), causam um evento de link inativo.

A negociação automática faz parte do processo de linkup. Quando o link estiver ativo, a negociação automática estará concluída. No entanto, o switch ainda monitora o status do link. Se a autonegociação estiver desativada em uma porta, a fase de "autonegociação" não será mais uma opção.

A especificação de cobre GE (1000BASE-T) não suporta negociação automática através de uma troca de próxima página. O Next Page Exchange permite a autonegociação para velocidades de 10/100/1000 Mbps em portas de cobre.

Observação: a especificação de fibra GE faz provisões apenas para a negociação de duplex, controle de fluxo e detecção remota de falhas. 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 para obter mais informações sobre negociação automática.

O retardo de reinicialização da sincronização é um recurso de software que controla o tempo total de negociação automática. Se a negociação automática não for bem-sucedida nesse período, o firmware reiniciará a negociação automática caso haja um deadlock. O comando set port sync-restart-delay tem efeito somente quando a negociação automática está definida como enable.

Recomendação

A habilitação da negociação automática é muito mais importante em um ambiente GE do que em um ambiente 10/100. Na verdade, a autonegociação deve ser desabilitada apenas nas portas do switch que se conectam a dispositivos que não suportam negociação ou onde problemas de conectividade surgem de problemas de interoperabilidade. A Cisco recomenda que a negociação de Gigabit seja habilitada (padrão) em todos os enlaces Switch a Switch e em todos os dispositivos GE em geral. Execute este comando para habilitar a autonegociação:

set port negotiation port range enable

!--- This is the default.

Uma exceção conhecida é quando há uma conexão com um Gigabit Switch Router (GSR) executando o Cisco IOS Software anterior à versão 12.0(10)S, a versão que adicionou controle de fluxo e negociação automática. Nesse caso, desligue esses dois recursos ou a porta do switch reporta não conectada, e o GSR reporta erros. Este é um exemplo de sequência de comandos:

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

Switch-to-server connections must be looked at on a case-by-case basis. Os clientes da Cisco tiveram problemas com a negociação Gigabit em servidores Sun, HP e IBM.

Outras opções

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

Esse recurso é melhor usado em links entre portas de acesso e hosts finais, onde o buffer de saída do host é potencialmente tão grande quanto sua memória virtual. O uso Switch a Switch possui 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 de PAUSA, mesmo que negociem para fazê-lo, já que não são de bloqueio.

Protocolo de truncamento dinâmico

Tipo de encapsulamento

Os troncos estendem as VLANs entre os dispositivos, identificando e marcando temporariamente (link local) os quadros Ethernet originais, permitindo assim que eles sejam multiplexados em um único link. This also ensures the separate VLAN broadcast and security domains are maintained between Switches. As tabelas CAM mantêm o mapeamento de quadro para VLAN dentro dos switches.

O entroncamento é suportado em vários tipos de meios L2, incluindo ATM LANE, FDDI 802.10 e Ethernet, embora apenas o último seja apresentado aqui.

Visão geral operacional do ISL

O esquema de identificação ou marcação proprietário da Cisco, ISL, é usado há muitos anos. O padrão IEEE 802.1Q também está disponível.

Ao encapsular totalmente o quadro original em um esquema de marcação de dois níveis, o ISL é efetivamente um protocolo de tunelamento e tem o benefício adicional de transportar quadros não Ethernet. Ele adiciona um cabeçalho de 26 bytes e um FCS de 4 bytes ao quadro Ethernet padrão - os quadros Ethernet maiores são esperados e tratados pelas portas configuradas para serem troncos. O ISL suporta 1.024 VLANs.

Formato de Quadro ISL

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

Visão Geral Operacional do 802.1Q

O padrão IEEE 802.1Q especifica muito mais do que os tipos de encapsulamento, incluindo aprimoramentos de Spanning Tree, GARP (consulte a seção VTP deste documento) e marcação de Qualidade de Serviço (QoS) 802.1p.

O formato de quadro 802.1Q preserva o endereço origem e o endereço destino Ethernet originais, ainda que os switches devam esperar que os quadros baby-giant sejam recebidos, mesmo em portas de acesso onde hosts podem usar marcação para expressar prioridade de usuário 802.1p para sinalização de QoS. A marca é de 4 bytes, portanto os quadros Ethernet v2 802.1Q têm 1522 bytes, uma conquista do grupo de trabalho IEEE 802.3ac. O 802.1Q também suporta espaço de numeração para 4096 VLANs.

Todos os quadros de dados transmitidos e recebidos são marcados com 802.1Q, exceto aqueles na VLAN nativa (existe uma marca implícita baseada na configuração da porta do switch de ingresso). Os quadros na VLAN nativa são sempre transmitidos sem marcas e normalmente recebidos sem marcas. No entanto, eles também podem ser recebidos marcados.

Consulte Padronização de VLAN via IEEE 802.10 e Get IEEE 802 para obter mais detalhes.

Formato de Quadro 802.1Q/801.1p

Recomendação

Como todos os hardwares mais novos suportam 802.1Q (e alguns suportam apenas 802.1Q, como o Catalyst 4500/4000 series e CSS 11000), a Cisco recomenda que todas as novas implementações sigam o padrão IEEE 802.1Q e as redes mais antigas migrem gradualmente do ISL.

O padrão IEEE permite a interoperabilidade entre fornecedores. Isso é vantajoso em todos os ambientes Cisco à medida que novas placas de rede e dispositivos compatíveis com 802.1p se tornam disponíveis. Embora as implementações ISL e 802.1Q sejam maduras, o padrão IEEE terá, em última análise, maior exposição de campo e maior suporte de terceiros, como o suporte de analisador de rede. A menor sobrecarga de encapsulamento de 802.1Q em comparação com ISL é um ponto menor a favor de 802.1Q também.

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

set trunk mod/port mode dot1q

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

Além disso, conforme discutido na seção VLAN 1 deste documento, os pacotes CDP, VTP e PAgP são sempre enviados na VLAN 1 durante o entroncamento. Ao usar o encapsulamento dot1q, esses quadros de controle são marcados com a VLAN 1 se a VLAN nativa do switch for alterada. Se o entroncamento dot1q para um roteador estiver habilitado e a VLAN nativa for alterada no switch, uma sub-interface na VLAN 1 será necessária para receber os quadros CDP marcados e fornecer visibilidade do vizinho CDP no roteador.

Observação: há uma consideração de segurança em potencial com dot1q causada pela marcação implícita da VLAN nativa, pois pode ser possível enviar quadros de uma VLAN para outra sem um roteador. Consulte Há vulnerabilidades nas implementações de VLAN? para obter mais detalhes. A solução é usar um ID de VLAN para a VLAN nativa do tronco que não é usado para o acesso do usuário final. A maioria dos clientes da Cisco deixa a VLAN 1 como a VLAN nativa em um tronco e atribui portas de acesso a VLANs diferentes da VLAN 1 para que isso seja feito de forma simples.

Modo de truncamento

O DTP é a segunda geração de ISL dinâmico (DISL) e existe para garantir que os diferentes parâmetros envolvidos no envio de quadros ISL ou 802.1Q, como o tipo de encapsulamento configurado, VLAN nativa e capacidade de hardware, sejam acordados pelos switches em cada extremidade de um tronco. Isso também ajuda a proteger contra estruturas rotuladas por inundação de portas no modo não truncamento, um possível risco de segurança sério, garantindo que as portas e seus 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. Esta tabela é um resumo dos modos de configuração:

Estes são alguns destaques do protocolo:

• O DTP pressupõe uma conexão ponto a ponto, e os dispositivos Cisco suportam apenas portas de tronco 802.1Q que são ponto a ponto.

• Durante a negociação de DTP, as portas não participam do STP. Somente depois que a porta se tornar um dos três tipos de DTP (acesso, ISL ou 802.1Q) a porta será adicionada ao STP. Caso contrário, o PAgP, se configurado, será o próximo processo a ser executado antes da porta participar do STP.

• Se a porta estiver fazendo entroncamento no modo ISL, os pacotes DTP serão enviados na VLAN 1; caso contrário (para portas de entroncamento 802.1Q ou portas de não entroncamento), eles serão enviados na VLAN nativa.

• No modo desirable, os pacotes de DTP transferem oNome do domínio de VTP (que deve coincidir para que um tronco negociado seja ativado), mais a configuração do tronco e o status admin.

• As mensagens são enviadas a cada segundo durante a negociação e a cada 30 segundos depois disso.

• Certifique-se de entender que os modos on, nonegotiate e off especificam explicitamente em qual estado a porta termina. Uma configuração inadequada pode levar a um estado perigoso/inconsistente em que um lado está truncado e o outro não.

• Uma porta no modo on, auto ou desirable envia quadros de DTP periodicamente. Se uma porta no modo auto ou desirable não vir um pacote de DTP em cinco minutos, ela será definida como non-trunk.

Consulte Configurando o entroncamento de ISL nos Switches das famílias Catalyst 5500/5000 e 6500/6000 para obter mais detalhes de ISL. Consulte Entroncamento entre Catalyst 4500/4000, 5500/5000 e 6500/6000 Series Switches Usando Encapsulamento 802.1Q com o Cisco CatOS System Software para obter mais detalhes sobre 802.1Q.

Recomendação

A Cisco recomenda uma configuração explícita de tronco de desirable em ambas as extremidades. Nesse modo, os operadores de rede podem confiar nas mensagens de status do syslog e da linha de comando que uma porta está ativa e em entroncamento, ao contrário do modo ativo, que pode fazer com que uma porta apareça ativa mesmo que o vizinho esteja configurado incorretamente. Além disso, o tronco do modo desejável fornece estabilidade em situações em que um lado do link não pode se tornar um tronco ou deixa cair o estado do tronco. Execute este comando para definir o modo desirable:

set trunk mod/port desirable ISL | dot1q

Observação: defina o tronco como desativado em todas as portas não tronco. Essa ajuda elimina o tempo de negociação gasto quando as portas de host aparecem. Este comando também é executado quando o comando set port host é usado; consulte a seção STP para obter mais informações. Execute este comando para desabilitar um tronco em um intervalo de portas:

set trunk port range off

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

Outras opções

Outra configuração comum do cliente usa o modo desirable somente na camada de distribuição e a configuração padrão mais simples (auto) na camada de acesso.

Alguns switches, como um Catalyst 2900XL, roteadores Cisco IOS ou dispositivos de outros fornecedores, atualmente não suportam negociação de tronco através do DTP. Você pode usar o modo nonegotiate nos switches Catalyst 4500/4000, 5500/5000 e 6500/6000 para definir uma porta para tronco incondicionalmente com esses dispositivos, o que pode ajudar a padronizar em uma configuração comum no campus. Além disso, você pode implementar o modo nonegotiate para reduzir o tempo de inicialização do link "geral".

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

Execute este comando para definir o modo de não negociação:

set trunk mod/port nonegotiate ISL | dot1q

A Cisco recomenda nonegotiate quando houver uma conexão a um roteador Cisco IOS porque quando o bridging for executado, alguns quadros DTP recebidos do modo on podem voltar para a porta de tronco. Na recepção do quadro DTP, a porta do switch tenta renegociar (ou trazer o tronco para baixo e para cima) desnecessariamente. Se nonegotiate estiver habilitado, o switch não enviará quadros DTP.

Spanning Tree Protocol

Considerações básicas

O Spanning Tree Protocol (STP) mantém um ambiente L2 sem loops em redes comutadas e com bridges redundantes. Sem o STP, os quadros entram em loop e/ou se multiplicam indefinidamente, o que causa um colapso da rede, pois todos os dispositivos no domínio de broadcast são interrompidos continuamente pelo alto tráfego.

Although in some respects STP is a mature protocol initially developed for slow Software-based bridge specifications (IEEE 802.1d), it can be complex to implement well in large Switched networks with many VLANs, many Switches in a domain, multi-vendor support, and newer IEEE enhancements.

Para referência futura, o CatOS 6.x continua a assumir o novo desenvolvimento de STP, como MISTP, protetor de loop, protetores de raiz e detecção de desvio de tempo de chegada de BPDU. Além disso, outros protocolos padronizados estão disponíveis no CatOS 7.x, como o Spanning Tree compartilhado IEEE 802.1s e o Spanning Tree de convergência rápida IEEE 802.1w.

Visão geral operacional

A escolha da bridge raiz por VLAN é ganha pelo switch com o identificador de bridge raiz (BID) mais baixo. O BID é a prioridade da bridge combinada com o endereço MAC do 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 esse switch. Isso permite que a bridge raiz e o caminho de menor custo até a raiz sejam determinados. 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.

A topologia, então, converge através destas etapas:

1. Um único Root Bridge é eleita para todo o domínio do Spanning Tree.

2. Um Root Bridge (voltada para o Root Bridge) é selecionada em cada Non-Root Bridge.

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

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

Consulte Configuração do Spanning Tree para obter mais informações.

Os dois tipos de BPDUs no STP são BPDUs de configuração e BPDUs de TCN (Topology Change Notification, notificação de alteração de topologia).

Fluxo de BPDU de configuração

Os BPDUs de configuração são originados a cada intervalo de Hello de cada porta na bridge raiz e, subsequentemente, fluem para todos os switches leaf para manter o estado do Spanning Tree. No estado steady, o fluxo da 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 bridge raiz for perdida ou todos os caminhos para a bridge raiz forem perdidos, as BPDUs param de ser recebidas (até que o temporizador de maximização inicie a reeleição).

Fluxo de TCN BPDU

Os TCN BPDUs são originados de switches leaf e fluem em direção à bridge raiz quando uma alteração de topologia é detectada na spanning tree. As portas raiz somente enviam TCNs e as portas designadas somente recebem TCNs.

O BPDU do TCN viaja em direção ao sulco raiz e é reconhecido em cada etapa, portanto, esse é um mecanismo confiável. Quando chega à bridge raiz, a bridge raiz alerta o domínio inteiro de que ocorreu uma alteração originando BPDUs de configuração com o flag TCN definido para o tempo máximo + fwddelay (35 segundos por padrão). Isso faz com que todos os switches alterem seu tempo de envelhecimento de CAM normal de cinco minutos (por padrão) para o intervalo especificado por fwddelay (15 segundos por padrão). Consulte Entendendo as alterações de topologia do Spanning Tree Protocol para obter mais detalhes.

Modos de árvore de abrangência

Há três maneiras diferentes de correlacionar VLANs com Spanning Tree:

• Um único Spanning Tree para todas as VLANs, ou Protocolo de Spanning Tree mono, como IEEE 802.1Q

• Uma árvore de abrangência por VLAN ou árvore de abrangência compartilhada, como o Cisco PVST

• Uma árvore de abrangência por conjunto de VLANs, ou várias árvores de abrangência, como 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. Uma porta bloqueada do STP bloqueia todas as VLANs e não transporta dados.

Uma árvore de abrangência por VLAN permite o balanceamento de carga, mas exige mais processamento de CPU de BPDU à medida que o número de VLANs aumenta. As notas de versão do CatOS fornecem orientação sobre o número de portas lógicas recomendadas por Switch na Árvore de Abrangência. Por exemplo, a fórmula do Supervisor Engine 1 do Catalyst 6500/6000 é como tal:

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 permitem a definição de apenas duas instâncias/topologias de STP ativas 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 atual do Cisco STP foi estendida para se tornar PVST+, adicionando suporte para tunelamento através de uma região de á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ção adicionais. 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 IDs de VLAN nos switches.

Estes são alguns destaques operacionais do protocolo PVST+:

• O PVST+ interopera com a árvore de abrangência mono 802.1Q através da chamada árvore de abrangência comum (CST - Common Spanning Tree) sobre um tronco 802.1Q. O CST sempre está ativado na VLAN 1 e portanto, a VLAN precisa estar habilitada no tronco para interoperar com outros fornecedores. Os CST BPDUs são transmitidos, sempre sem marcação, para o Grupo de Bridge Padrão IEEE (Endereço MAC 01-80-c2-00-00-00, DSAP 42, SSAP 42). Para que a descrição fique completa, um conjunto paralelo de BPDUs também é transmitido para o endereço MAC do Spanning Tree compartilhado da Cisco para VLAN 1.

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

• Verificações de porta de PVST+ e inconsistências de VLAN. O PVST+ bloqueia as portas que recebem BPDUs inconsistentes para impedir loops de encaminhamento. Ele também notifica os usuários através de mensagens de syslog sobre qualquer incompatibilidade de configuração.

• O PVST+ é compatível com versões anteriores de switches Cisco existentes que executam o PVST em troncos ISL. BPDUs encapsulados por ISL continuam a ser transmitidos ou recebidos usando o endereço MAC IEEE. Em outras palavras, cada tipo de BPDU é link local; não há problemas de tradução.

Recomendação

Todos os switches Catalyst têm o STP habilitado por padrão. Isso é recomendado mesmo se for escolhido um design que não inclua loops de L2 para que o STP não seja habilitado, no sentido de que esteja mantendo ativamente uma porta bloqueada.

set spantree enable all

!--- This is the default.

A Cisco recomenda que o STP seja deixado ativado pelos seguintes motivos:

• Se houver um loop (induzido por erro de patch, cabo incorreto etc.), o STP evita efeitos prejudiciais à rede causados por dados multicast e de broadcast.

• Proteção contra ruptura do EtherChannel.

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

• Proteção contra mau comportamento de NICs de acessório dual (ou Bridging habilitada em servidores).

• O software para muitos protocolos (como PAgP, rastreamento de IGMP e entroncamento) está intimamente relacionado ao STP. A execução sem STP pode levar a resultados indesejáveis.

Não troque os temporizadores, pois isso pode afetar a estabilidade. A maioria das redes implantadas não está sintonizada. Os temporizadores STP simples acessíveis através da linha de comando, como o intervalo de Hello e o intervalo de Maxage, são eles mesmos compostos de um conjunto complexo de outros temporizadores assumidos e intrínsecos, portanto é difícil ajustar os temporizadores e considerar todas as ramificações. Além disso, há o risco de prejudicar a proteção UDLD.

O ideal é manter o tráfego de usuários fora do VLAN de gerenciamento. 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 mecanismo supervisor tão ocupado com pacotes de broadcast que ele pode perder um ou mais BPDUs. No entanto, switches mais novos com CPUs mais potentes e controles de aceleração aliviam essa consideração. Consulte a seção Gerenciamento In-Band deste documento para obter mais detalhes.

Não sobrecarregue a redundância. Isso pode levar a um pesadelo de solução de problemas - o excesso de portas de bloqueio afeta negativamente a estabilidade a longo prazo. Mantenha o diâmetro total do SPT em sete saltos. Tente projetar de acordo com o modelo multicamada da Cisco, com seus domínios comutados menores, triângulos STP e portas bloqueadas determinísticas (conforme explicado em Projeto de Rede de Campus 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 o Troubleshooting do STP - o que os fez alterar de bloquear para enviar é freqüentemente uma peça chave na análise da causa. Escolha as camadas de distribuição e de núcleo como o local da raiz/raiz secundária, já que essas são consideradas as partes mais estáveis da rede. Verifique a sobreposição ideal de L3 e HSRP com caminhos de encaminhamento de dados de L2. Esse comando é uma macro que configura a prioridade da bridge; a raiz a define muito mais baixa que o padrão (32768), enquanto a raiz secundária a define razoavelmente mais baixa 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 bridge raiz for conhecida) ou a prioridade de raiz atual (se seu endereço MAC for menor que a raiz atual).

Remova as VLANs desnecessárias das portas de tronco (um exercício bidirecional). Isso limita o diâmetro da sobrecarga de processamento de STP e NMP em partes da rede onde determinadas VLANs não são necessárias. A remoção automática de VTP não remove o STP de um tronco. Consulte a seção VTP deste documento para obter mais informações. A VLAN 1 padrão também pode ser removida dos troncos usando o CatOS 5.4 e posterior.

Consulte Problemas do Spanning Tree Protocol e Considerações de Design Relacionadas para obter informações adicionais.

Outras opções

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

Isso é mais útil se houver necessidade de ligar protocolos não roteáveis ou legados entre VLANs sem interferir nas instâncias de Árvore de Abrangência IEEE executadas nessas VLANs. Se as interfaces VLAN para tráfego não transposto ficarem bloqueadas para tráfego L2 (e isso poderia facilmente acontecer se elas participassem do mesmo STP que VLANs IP), o tráfego L3 de sobreposição também será removido inadvertidamente - um efeito colateral indesejado. A ponte VLAN é, portanto, uma instância separada do STP para protocolos transpostos, que fornece uma topologia separada que pode ser manipulada sem afetar o tráfego IP.

A recomendação da Cisco é executar VLAN-bridge, caso o Bridging for necessária entre VLANS em Cisco routers, tais como o MSFC.

PortFast

O PortFast é usado para ignorar a operação Spanning Tree normal nas portas de acesso para acelerar a conectividade entre estações finais e os serviços aos quais elas precisam se conectar após a inicialização do link. Em alguns protocolos, como IPX/SPX, é importante ver a porta de acesso no modo de encaminhamento imediatamente após o estado do link ficar ativo para evitar problemas de GNS.

Consulte Usando Portfast e Outros Comandos para Corrigir Atrasos de Conectividade de Inicialização da Estação de Trabalho para obter mais informações.

Visão geral operacional

O PortFast ignora os estados normais de escuta e reconhecimento do STP movendo uma porta diretamente do modo de bloqueio para o modo de encaminhamento depois de descobrir que o link está em execução. Se esse recurso não estiver habilitado, o STP descartará todos os dados do usuário até decidir que a porta está pronta para ser movida para o modo de encaminhamento. Isso poderia levar até o dobro do tempo de Forward/Delay (um total de 30 segundos como padrão).

O modo PortFast também impede que um TCN de STP seja gerado cada vez que um estado de porta muda de learning para forwarding. Os TCNs não são um problema por si só, mas se uma onda de TCNs atingir a bridge raiz (normalmente pela manhã, quando as pessoas ligam seus PCs), isso poderia estender o tempo de convergência desnecessariamente.

O STP PortFast é particularmente importante em redes CGMP multicast e Catalyst 5500/5000 MLS. Os TCNs nesses ambientes podem fazer com que as entradas estáticas da tabela CAM do CGMP sejam expiradas, o que resulta em perda de pacotes multicast até o próximo relatório IGMP e/ou liberar entradas de cache MLS que precisam ser reconstruídas e podem resultar em um pico de CPU do roteador, dependendo do tamanho do cache. (As implementações de MLS do Catalyst 6500/6000 e as entradas multicast aprendidas do snooping IGMP não são afetadas.)

Recomendação

A Cisco recomenda que o STP PortFast seja habilitado para todas as portas de host ativas e desabilitado para links switch-switch e portas que não estejam em uso.

O entroncamento e a canalização também devem ser desativados para todas as portas de host. Cada porta de acesso é habilitada por padrão para entroncamento e canalização, ainda que os vizinhos do Switch não sejam esperados por design nas portas de host. Se a negociação for deixada para esses protocolos, o retardo 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 essa configuração para portas de acesso e ajuda significativamente a autonegociação e o desempenho da conexão:

set port host port range


!--- Macro command for these commands:

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

Observação: o PortFast não significa que o Spanning Tree não esteja sendo executado nessas portas. Os BPDUs ainda são enviados, recebidos e processados.

Outras opções

O PortFast BPDU-guard fornece uma maneira de evitar loops, movendo uma porta de não entroncamento para um estado errdisable quando um BPDU é recebido naquela porta.

Um pacote de BPDU nunca deve ser recebido em uma porta de acesso configurada para PortFast, já que as portas do host não devem ser conectadas aos 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 BPDU-guard está habilitado, o Spanning Tree desativa as interfaces configuradas com PortFast que recebem BPDUs em vez de colocá-las no estado de bloqueio do STP.

O comando funciona em uma base por switch, não por porta, como mostrado:

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ática para portas errdisabled. Consulte a seção UDLD deste documento para obter mais detalhes. Para obter mais informações, consulte Aprimoramento de Protetor de BPDU Portfast de Spanning Tree.

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

UplinkFast

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

Visão geral operacional

Usando o modelo de design multicamada da Cisco na camada de acesso, se o uplink de encaminhamento for perdido, o uplink de bloqueio será imediatamente movido para um estado de encaminhamento sem esperar pelos estados listening e learning.

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 essa conexão raiz primária falhar por algum motivo, o link raiz de backup é ativado imediatamente sem a necessidade de passar pelos 30 segundos típicos de atraso de convergência.

Como isso efetivamente ignora o processo normal de manipulação de alterações de 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 locais podem ser alcançadas através de um caminho alternativo. O switch de camada de acesso que executa o UplinkFast também gera quadros para cada endereço MAC em seu CAM para um endereço MAC multicast (01-00-0c-cd-cd-cd, protocolo HDLC 0x200a) para atualizar a tabela CAM em todos os switches no domínio com a nova topologia.

Recomendação

Cisco recommends that UplinkFast be enabled for Switches with blocked ports, typically at the access layer. Não use em switches sem o conhecimento de topologia implícito de um link raiz de backup - normalmente switches de distribuição e de núcleo no projeto multicamada da Cisco. Pode ser adicionado a uma rede de produção sem interrupção. Execute este comando para habilitar o UplinkFast:

set spantree uplinkfast enable 

Esse comando também define a prioridade de bridge como alta para minimizar o risco de isso se tornar uma bridge raiz e a prioridade de porta como alta para minimizar o risco de se tornar uma porta designada, o que interrompe a funcionalidade. Quando você restaura um switch que tinha o UplinkFast habilitado, o recurso precisa ser desabilitado, o banco de dados de uplink deve ser limpo com "clear uplink" e as prioridades de bridge devem ser restauradas manualmente.

Observação: a palavra-chave all protocols para o comando UplinkFast é necessária quando o recurso de filtragem de protocolo está habilitado. Como o CAM registra o tipo de protocolo, assim como as informações de MAC e VLAN, quando a filtragem de protocolo está habilitada, um quadro UplinkFast precisa ser gerado para cada protocolo em cada endereço MAC. A palavra-chave rate indica os pacotes por segundo dos quadros de atualização da topologia uplinkfast. O padrão é recomendado. Você não precisa configurar o BackboneFast com Rapid STP (RSTP) ou IEEE 802.1w porque o mecanismo é incluído nativamente e automaticamente habilitado no RSTP.

BackboneFast

O BackboneFast fornece convergência rápida a partir de falhas indiretas de link. Com a funcionalidade adicionada ao STP, os tempos de convergência geralmente podem ser reduzidos do padrão de 50 segundos para 30 segundos.

Visão geral operacional

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

Sob as regras normais do Spanning Tree, o switch receptor ignora BPDUs inferiores para o tempo de envelhecimento máximo configurado, 20 segundos por padrão. No entanto, com o BackboneFast, o switch vê a BPDU inferior como um sinal que a topologia poderia ter alterado e tenta determinar se ela tem um caminho alternativo para a bridge raiz usando BPDUs de Root Link Query (RLQ). Essa adição de protocolo permite que um switch verifique se a raiz ainda está disponível, move uma porta bloqueada para encaminhamento em menos tempo e notifica o switch isolado que enviou a BPDU inferior de que a raiz ainda está lá.

Estes são alguns destaques da operação do protocolo:

• Um switch transmite o pacote RLQ apenas pela porta raiz (ou seja, em direção à bridge raiz).

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

• Se um Switch perdeu a conexão com a raiz, ele deve responder a essa consulta na negativa.

• A resposta deve ser enviada apenas pela porta da qual a consulta chegou.

• 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.

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

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

Recomendação

A recomendação da Cisco é ativar o BackboneFast em todos os switches que executam o STP. Pode ser adicionado a uma rede de produção sem interrupçã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, pois ele adiciona funcionalidade ao protocolo STP que todos os switches precisam entender.

Outras opções

Não há suporte para BackboneFast em 2900XLs e 3500s. Ele não deve ser ativado se o domínio do switch contiver esses switches além dos switches Catalyst 4500/4000, 5500/5000 e 6500/6000.

Você não precisa configurar o BackboneFast com RSTP ou IEEE 802.1w porque o mecanismo é incluído nativamente e automaticamente habilitado no RSTP.

Proteção de loop de árvore de abrangência

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

• Interfaces de rede com mau funcionamento

• CPUs ocupadas

• Qualquer coisa que impeça o encaminhamento normal de BPDUs

Um loop STP ocorre quando uma porta de bloqueio em uma topologia redundante faz a transição erroneamente para o estado de encaminhamento. Essa transição geralmente acontece porque uma das portas em uma topologia fisicamente redundante (não necessariamente a porta de bloqueio) deixa de receber BPDUs.

O protetor de loop só é útil em redes comutadas nas quais os switches estão conectados por links ponto-a-ponto. A maioria das redes modernas de campus e data center são esses tipos de redes. Em um link ponto-a-ponto, uma ponte designada não pode desaparecer, a menos que envie um BPDU inferior ou derrube o link. O recurso protetor de loop STP foi introduzido no CatOS versão 6.2(1) para as plataformas Catalyst 4000 e Catalyst 5000 e na versão 6.2(2) para a plataforma Catalyst 6000.

Consulte Aprimoramentos do Spanning-Tree Protocol usando Recursos de Proteção de Loop e Detecção de Desvio de BPDU para obter mais informações sobre proteção de loop.

Visão geral operacional

O protetor de loop verifica se uma porta raiz ou uma porta raiz alternativa/de backup recebe BPDUs. Se a porta não receber BPDUs, o protetor de loop coloca a porta em um estado inconsistente (bloqueio) até que a porta comece a receber BPDUs novamente. Uma porta no estado inconsistente não transmite BPDUs. Se tal porta receber BPDUs novamente, a porta (e o link) será considerada viável novamente. A condição de loop inconsistente é removida da porta e o STP determina o estado da porta porque essa recuperação é automática.

O protetor de loop isola a falha e permite que o spanning tree convirja para uma topologia estável sem o link ou a ponte com falha. O protetor de loop evita loops de STP com a velocidade da versão de STP em uso. Não há dependência no próprio STP (802.1d ou 802.1w) ou quando os temporizadores do STP sã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 suporta os recursos.

Quando a proteção de loop 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 inconsistente de loop, 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, essa mensagem é registrada.

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

Interação com outros recursos do STP

• Protetor de raiz

  O protetor de raiz força uma porta a ser designada sempre. O protetor de loop só será efetivo se a porta for a porta 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 UplinkFast. Se o protetor de loop colocar uma porta raiz em um estado de bloqueio, o UplinkFast colocará uma nova porta raiz no estado de encaminhamento. Além disso, o UplinkFast não seleciona uma porta de loop inconsistente como uma porta raiz.

• BackboneFast

  O protetor de loop é compatível com o BackboneFast. A recepção de um BPDU inferior que vem de uma ponte designada aciona o BackboneFast. Como os BPDUs são recebidos desse link, o protetor de loop não está ativado, portanto o BackboneFast e o protetor de loop são compatíveis.

• PortFast

  O PortFast faz a transição de uma porta para o estado de encaminhamento designado imediatamente após o linkup. Como uma porta habilitada para PortFast não pode ser uma porta raiz ou 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 de portas lógicas fornecida pelo PAgP. No entanto, para formar um canal, todas as portas físicas 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: estes são avisos quando você configura o protetor de loop em um EtherChannel:

  • O STP sempre escolhe a primeira porta operacional no canal para enviar as BPDUs. Se esse link se tornar unidirecional, o protetor de loop bloqueará o canal, mesmo que outros links no canal funcionem corretamente.

  • Se as portas que já estão bloqueadas pelo protetor de loop forem agrupadas para formar um canal, o STP perderá todas as informações de estado para essas portas. A nova porta de canal pode atingir o estado de encaminhamento com uma função designada.

  • Se um canal for bloqueado pelo protetor de loop e o canal for interrompido, o STP perderá todas as informações de estado. As portas físicas individuais podem atingir o estado de encaminhamento com a função designada, mesmo que um ou mais links que formaram o canal sejam unidirecionais.

  Nos dois últimos casos desta lista, há uma possibilidade de um loop até que o UDLD detecte 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 protetor de loop e a funcionalidade UDLD se sobrepõem parcialmente. Ambos protegem contra falhas de STP causadas por links unidirecionais. Mas esses dois recursos são diferentes na abordagem do problema e também na funcionalidade. Especificamente, há certas falhas unidirecionais que o UDLD não pode detectar, como falhas causadas por uma CPU que não envia BPDUs. Além disso, o uso de temporizadores STP agressivos e o modo RSTP pode 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. Caso o link seja unidirecional desde o linkup, a porta nunca recebe BPDUs e torna-se designada. Esse comportamento pode ser normal, portanto o protetor de loop não cobre esse caso específico. O UDLD realmente oferece proteção contra tal cenário.

Ative o UDLD e o protetor de loop para fornecer o nível mais alto de proteção. Consulte a seção Proteção de Loop vs. Detecção de Link Unidirecional de Melhorias do Spanning-Tree Protocol usando Recursos de Proteção de Loop e Detecção de Desvio BPDU para obter uma comparação de recursos de protetor de loop e UDLD,.

Recomendação

A Cisco recomenda que você ative o protetor de loop globalmente em uma rede de switch com loops físicos. Na versão 7.1(1) do software Catalyst e posterior, você pode ativar o protetor de loop globalmente em todas as portas. Efetivamente, o recurso é ativado em todos os links ponto-a-ponto. O status duplex do link detecta o link ponto a ponto. Se o duplex estiver cheio, o link será considerado ponto a ponto. Execute este comando para habilitar o protetor de loop global:

set spantree global-default loopguard enable

Outras opções

Para switches que não suportam configuração de protetor de loop global, habilite o recurso em todas as portas individuais, o que inclui portas de canal de porta. Embora não haja benefícios na habilitação do protetor de loop em uma porta designada, essa habilitação não é um problema. Além disso, uma reconvergência de spanning tree válida pode realmente transformar uma porta designada em uma porta raiz, o que torna o recurso útil nessa porta. Execute este comando para habilitar o protetor de loop:

set spantree guard loop mod/port

As redes com topologias sem loops ainda podem se beneficiar do protetor de loop no caso de loops serem introduzidos acidentalmente. No entanto, a habilitação do protetor de loop nesse tipo de topologia pode levar a problemas de isolamento de rede. Para criar topologias sem loops e evitar problemas de isolamento de rede, emita estes comandos para desabilitar o protetor de loop global ou individualmente. Não ative o protetor de loop em links compartilhados.

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

  or

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

Protetor de Raiz de Spanning Tree

O recurso de protetor de raiz fornece uma maneira de aplicar a colocação da bridge raiz na rede. O protetor de raiz garante que a porta na qual o protetor de raiz está habilitado seja a porta designada. Normalmente, as portas da bridge raiz são todas as portas designadas, a menos que duas ou mais portas da bridge raiz estejam conectadas juntas. Se a ponte recebe BPDUs STP superiores em uma porta habilitada para protetor de raiz, a ponte move essa porta para um estado STP de raiz inconsistente. Esse estado de raiz inconsistente é efetivamente igual a um estado de escuta. Nenhum tráfego é encaminhado através dessa porta. Dessa forma, o protetor de raiz reforça a posição da bridge raiz. O protetor de raiz está disponível no CatOS para Catalyst 29xx, 4500/4000, 5500/5000 e 6500/6000 na versão de software 6.1.1 e posterior.

Visão geral operacional

O protetor de raiz é um mecanismo incorporado ao STP. O protetor de raiz não tem um temporizador próprio e depende apenas da recepção de BPDU. Quando o protetor de raiz é aplicado a uma porta, o protetor de raiz não permite que uma porta se torne uma porta de raiz. Se o recebimento de uma BPDU acionar uma convergência de spanning tree que faça com que uma porta designada se torne uma porta raiz, a porta será colocada em um estado de raiz inconsistente. Esta mensagem de syslog mostra a ação:

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

Depois que a porta deixa de enviar BPDUs superiores, a porta é desbloqueada novamente. Através do STP, a porta passa do estado de escuta para o estado de aprendizagem e, eventualmente, passa para o estado de encaminhamento. A recuperação é automática e não é necessária nenhuma intervenção humana. Esta mensagem de syslog fornece um exemplo:

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

O protetor de raiz força uma porta a ser designada e o protetor de loop só é eficaz se a porta for a porta 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 Aprimoramento de Protetor de Raiz do Spanning Tree Protocol para obter mais informações.

Recomendação

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

set spantree guard root mod/port

EtherChannel

As tecnologias EtherChannel permitem a multiplexação inversa de vários canais (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 uma porta lógica para que uma única instância do STP possa ser executada

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

Multiplexação de quadros

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 nos algoritmos por plataforma surgem da capacidade de cada tipo de hardware extrair informações de cabeçalho de quadros para tomar a decisão de distribuição.

O algoritmo de distribuição de carga é uma opção global para ambos os protocolos de controle de canal. PAgP e LACP usam o algoritmo de distribuição de quadros porque o padrão IEEE não exige nenhum algoritmo de distribuição específico. No entanto, qualquer algoritmo de distribuição garante que, quando os quadros são recebidos, o algoritmo não cause a má ordenação dos quadros que fazem parte de qualquer conversação ou duplicação de quadros dada.

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

• O Catalyst 6500/6000 tem um hardware de comutação mais recente que o Catalyst 5500/5000 e pode ler informações da Camada 4 (L4) IP em velocidade de cabo para tomar uma decisão de multiplexação mais inteligente do que informações MAC L2 simples.

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

Consulte esta tabela, que ilustra o algoritmo de distribuição de quadros em detalhes para cada plataforma listada:

¹ FEC = Fast Etherchannel

² UDP = User Datagram Protocol (Protocolo de Datagrama de Usuário)

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

Observação: com a distribuição L4, o primeiro pacote fragmentado usa a distribuição L4. Todos os pacotes subsequentes usam a distribuição L3.

Mais detalhes do suporte EtherChannel em outras plataformas e como configurá-las e solucioná-las podem ser encontrados nestes documentos:

• Entendendo o equilíbrio de carga de EtherChannel e redundância em Switches Catalyst

• Configuração EtherChannel entre switches Catalyst 4500/4000, 5500/5000 e 6500/6000 que executam o software do sistema CatOS.

• Configurando LACP (802.3ad) entre um Catalyst 6500/6000 e um Catalyst 4500/4000

• Configurando EtherChannel de Camada 3 e Camada 2

Recomendação

Os Catalyst 6500/6000 Series Switches executam o balanceamento de carga por endereço 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

!--- This is the default.

A distribuição de quadros das séries Catalyst 4500/4000 e 5500/5000 pelo endereço MAC de L2 é aceitável na maioria das redes. No entanto, o mesmo link é usado para todo o tráfego se houver apenas dois dispositivos principais que se comunicam 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 agregada lógica (agport) possa ser gerenciada pelo SNMP como uma instância separada e agregar estatísticas de throughput coletadas, a Cisco ainda recomenda que você gerencie cada uma das interfaces físicas separadamente para verificar como os mecanismos de distribuição de quadros estão funcionando e se o balanceamento de carga estatístico está sendo alcançado.

Um novo comando, o comando show channel traffic, no CatOS 6.x, pode exibir estatísticas de distribuição percentual mais facilmente do que se você verificasse contadores de porta individuais com o comando show counters mod/port ou o comando show mac mod/port no CatOS 5.x. Outro novo comando, o comando show channel hash, no CatOS 6.x permite que você verifique, com base no modo de distribuição, qual porta seria selecionada como a porta de saída para determinados endereços e/ou números de porta. Os comandos equivalentes para canais LACP são show lacp-channel traffic e show lacp-channel hash .

Outras opções

Estas são as etapas possíveis a serem seguidas se as limitações relativas dos algoritmos baseados em MAC do Catalyst 4500/4000 ou do Catalyst 5500/5000 forem um problema e um bom balanceamento de carga estatístico não for alcançado:

• Switches Catalyst 6500/6000 de implantação pontual

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

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

• Provisione links/VLANs dedicados para dispositivos de alta largura de banda

Diretrizes e restrições de configuração do EtherChannel

O EtherChannel verifica as propriedades da porta 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 variam de acordo com as diferentes plataformas de switch. Siga as diretrizes para evitar problemas de empacotamento. Por exemplo, se a QoS estiver habilitada, os EtherChannels não se formam quando os módulos de switching da série Catalyst 6500/6000 são empacotados com diferentes capacidades de QoS. No Cisco IOS Software, você pode desabilitar a verificação de atributo de porta QoS no empacotamento EtherChannel com o comando de interface de canal de porta no mls qos channel-consistency. Um comando equivalente para desabilitar 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 plataformas diferentes para evitar problemas de configuração:

• A seção Diretrizes de Configuração do EtherChannel de Configuração do EtherChannel (Catalyst 6500/6000)

• A seção Diretrizes e Restrições de Configuração do EtherChannel de Configuração do Fast EtherChannel e do Gigabit EtherChannel (Catalyst 4500/4000)

• A seção Diretrizes e Restrições de Configuração do EtherChannel de Configuração do Fast EtherChannel e do Gigabit EtherChannel (Catalyst 5000)

Observação: o número máximo de port channels que o Catalyst 4000 suporta é 126. Com as versões de software 6.2(1) e anteriores, os switches da série Catalyst 6500 de seis e nove slots suportam um máximo de 128 EtherChannels. No software versão 6.2 (2) e versões posteriores, o recurso de spanning tree lida com a ID da porta. Portanto, o número máximo de EtherChannels com suporte é 126 para um chassi de seis ou nove slots e 63 para um chassi de 13 slots.

Protocolo de agregação de porta

PAgP é um protocolo de gerenciamento que verifica a consistência de parâmetros em cada extremidade do link e ajuda o canal a se adaptar a falhas ou acréscimos de link. Observe estes fatos sobre o PAgP:

• O PAgP requer que todas as portas no canal pertençam à mesma VLAN ou 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 truncamento), todas as portas do pacote são modificadas para corresponderem à configuração existente.

• O PAgP não agrupa portas que operem em velocidades diferentes e porta bidirecional. Se a velocidade e o duplex forem alterados quando um pacote existir, o PAgP muda a velocidade e o duplex da porta para todas as portas do pacote.

Visão geral operacional

A porta PAgP controla cada porta física (ou lógica) individual a ser agrupada. Os pacotes PAgP são enviados usando o mesmo endereço MAC de grupo multicast usado para pacotes CDP, 01-00-0c-cc-cc-cc. O valor do protocolo é 0x0104. Este é um resumo 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, mas não pacotes PAgP, supõe-se que a porta esteja 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 de PAgP pararem durante um período, o estado de PAgP será cortado.

Processamento normal

Esses conceitos devem ser definidos para auxiliar na compreensão do comportamento do protocolo:

• Agport — uma porta lógica composta de todas as portas físicas na mesma agregação, que 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 satisfaz os critérios de formação; portanto, pode conter portas não operacionais (agports são um subconjunto de 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 de capacidade do 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 atinge os estados UpData ou UpPAgP, ela é conectada a uma agport apropriada. Quando ele deixa qualquer um desses estados para outro estado, ele é desconectado da agport.

As definições dos estados e dos procedimentos de criação são apresentadas no quadro seguinte:

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 atinge o estado UpPAgP, ela é atribuída à 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. (Todas as portas BiDir são movidas para o estado UpPAgP ao mesmo tempo.) 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.

Um intervalo de PAgP pode ocorrer no último vizinho conhecido na porta física. O intervalo de parada da porta é removido do agport. Ao mesmo tempo, todas as portas físicas na mesma agport cujos cronômetros também têm intervalos são removidas. Esse item habilita um agport cuja outra extremidade foi moldada para ser cortada simultaneamente, em vez de uma porta física de cada vez.

Comportamento em falha

Se um link em um canal existente falhar (por exemplo, porta desconectada, Gigabit Interface Converter [GBIC] removido ou fibra quebrada), a agport será atualizada e o tráfego será dividido nos links restantes dentro de um segundo. Qualquer tráfego que não precise ser submetido a novo hash após a falha (tráfego que continua a enviar no mesmo link) não sofre nenhuma perda. A restauração do link com falha aciona outra atualização para a agport e o tráfego é submetido a hash novamente.

Observação: o comportamento quando um link falha em um canal devido a um desligamento ou à remoção de um módulo pode ser diferente. Por definição, precisa haver duas portas físicas para 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 à Spanning Tree. Isso significa que o tráfego pode ser descartado até que o STP permita que a porta se torne disponível para os dados novamente.

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

Essa diferença nos dois modos de falha é importante quando a manutenção de uma rede é planejada, pois pode haver um TCN de STP a ser considerado ao executar uma remoção on-line ou inserção de um módulo. Como mencionado , é importante gerenciar cada link físico no canal com o NMS, já que a agport pode permanecer intacta devido a uma falha.

Estas são etapas sugeridas para mitigar uma alteração de topologia indesejada no Catalyst 6500/6000:

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

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

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

• Atualize para o CatOS 6.3, que trata 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:

As configurações silenciosa/não silenciosa afetam como as portas reagem a situações que causam tráfego unidirecional ou como elas alcançam failover. Quando uma porta não consegue transmitir (devido a uma falha na subcamada física [PHY] ou a uma fibra ou cabo quebrado, por exemplo), isso ainda pode deixar a porta vizinha em um 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 levar a porta a uma condição não operacional quando perde seu sinal de recepção (FEFI). Isso faz com que a porta do parceiro fique não operacional e efetivamente faz com que as portas em ambas as extremidades do link fiquem inativas.

Ao usar dispositivos que transmitem dados (como BPDUs) e não podem 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 estejam presentes e o link seja verificado como bidirecional. O tempo que o PAgP leva para detectar um link unidirecional é de cerca de 3,5 * 30 segundos = 105 segundos, onde 30 segundos é o tempo entre duas mensagens sucessivas de PAgP. O UDLD é recomendado como um detector mais rápido para enlaces unidirecionais.

Ao usar dispositivos que não transmitem dados, deve-se usar o modo silencioso. Isso força a porta a se tornar conectada e operacional, independentemente de os dados recebidos estarem presentes ou não. Além disso, para as portas que podem detectar a presença de uma condição unidirecional, como plataformas mais novas usando L1 FEFI e UDLD, o modo silencioso é usado por padrão.

Verificação

Esta tabela descreve um resumo 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 (isto é, algumas das combinações fecham as portas no lado da canalização).

Recomendação

A Cisco recomenda que o PAgP seja ativado em todas as conexões de canal de switch para switch, evitando o modo on. O método preferido é definir o modo desirable em ambas as extremidades de um link. A recomendação adicional é deixar a palavra-chave silent/non-silent como padrão - silent nos switches Catalyst 6500/6000 e 4500/4000, non-silent nas portas de fibra Catalyst 5500/5000.

Conforme discutido neste documento, a configuração explícita de canalização desligada em todas as outras portas é útil para o encaminhamento rápido de dados. Deve ser evitado esperar até 15 segundos pelo tempo limite do PAgP em uma porta que não deve ser usada para canalização, especialmente porque a porta é transferida para o STP, que pode levar 30 segundos para permitir o encaminhamento de dados, mais potencialmente 5 segundos para o DTP, num total de 50 segundos. O comando set port host é discutido com mais detalhes na seção STP deste documento.

set port channel port range mode desirable

set port channel port range mode off

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

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

Outras opções

Outra configuração comum para clientes que têm um modelo de administração mínima na camada de acesso é definir o modo como desirable nas camadas de distribuição e de núcleo, e deixar os switches da camada de acesso na configuração auto padrão.

Ao canalizar para dispositivos que não suportam PAgP, o canal precisa ser codificado em. Isso se aplica a dispositivos como servidores, Local Diretor, switches de conteúdo, roteadores, switches com software mais antigo, switches Catalyst XL e Catalyst 8540s. Emita 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 a longo prazo, pois ele traz o benefício da interoperabilidade entre plataformas e fornecedores.

Link Aggregation Control Protocol (Protocolo de Controle de Agregação de Links)

O LACP é um protocolo que permite que portas com características semelhantes formem um canal por meio de negociação dinâmica com switches adjacentes. PAgP é um protocolo proprietário da Cisco que pode ser executado apenas em switches da Cisco e nos switches que são lançados por fornecedores licenciados. Mas o LACP, que é definido no IEEE 802.3ad, permite que os switches Cisco gerenciem a canalização Ethernet com dispositivos que estejam em conformidade com a especificação 802.3ad. As versões do software CatOS 7.x introduziram o suporte LACP.

Há muito pouca diferença entre LACP e 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 pacote. Essas propriedades de porta incluem:

• Velocidade

• Duplex

• VLAN nativo

• Tipo de entroncamento

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

• O LACP pode ser executado somente em portas full-duplex e o LACP não suporta portas half-duplex.

• O LACP oferece suporte a portas em espera ativas. 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 puder agregar todas as portas compatíveis, todas as portas que não puderem ser incluídas ativamente no canal serão colocadas em estado de espera ativa e usadas somente se uma das portas usadas falhar. Um exemplo de uma situação em que o LACP não pode agregar todas as portas compatíveis é se o sistema remoto tem 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 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). Outras oito portas podem ser configuradas como portas em espera ativa.

Visão geral operacional

O LACP controla cada porta física (ou lógica) individual que deve ser agrupada. Os pacotes LACP são enviados com o uso do endereço MAC do grupo multicast, 01-80-c2-00-00-02. O valor do tipo/campo é 0x8809 com um subtipo de 0x01. Aqui está um resumo da operação do protocolo:

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

• Desde que a porta física esteja ativa, os pacotes LACP sã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 enviadas dentro do protocolo e decidem quais ações tomar.

• 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 pela troca regular e oportuna de informações de estado atualizadas entre os parceiros de link. Se a configuração for alterada (devido a uma falha de link, por exemplo), os parceiros de protocolo atingirão o tempo limite e tomarão as medidas apropriadas com base no novo estado do sistema.

• Além das transmissões de unidade de dados LACP periódicas (LACPDU), se houver uma alteração nas informações de estado, o protocolo transmitirá um LACPDU orientado por evento ao parceiro. Os parceiros do protocolo tomam as medidas apropriadas com base no novo estado do sistema.

Parâmetros LACP

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

• Um identificador globalmente exclusivo para cada sistema que participa da agregação de links

  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 associadas a cada porta e a cada agregador, à medida que um determinado sistema as compreende

  Cada porta no sistema deve receber uma prioridade 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 links e seu agregador associado

  A capacidade de uma porta de agregar com outra é resumida por um parâmetro inteiro simples de 16 bits que é estritamente maior que zero. Esse parâmetro é chamado de "chave". Diferentes fatores determinam cada chave, como:

  • As características físicas da porta, que incluem:

    • Taxa de dados

    • Duplexidade

    • Ponto a ponto ou meio compartilhado

  • Restrições de configuração estabelecidas pelo administrador da rede

  Duas chaves estão associadas a cada porta:

  • Uma chave administrativa—Esta chave permite a manipulação de valores de chave pelo gerenciamento. 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 alterar diretamente essa chave.

    Diz-se que o conjunto de portas em um sistema que compartilha o mesmo valor de chave operacional é membro do mesmo grupo de chaves.

Se você tiver dois sistemas e um conjunto de portas com a mesma chave administrativa, cada sistema tentará agregar as portas. Cada sistema inicia na porta com a prioridade mais alta no sistema de prioridade mais alta. Esse comportamento é possível porque cada sistema sabe sua própria prioridade, que o usuário ou o sistema atribuiu, e sua prioridade de parceiro, que foi descoberta através de pacotes LACP.

Comportamento em falha

O comportamento de falha do LACP é o mesmo comportamento do PAgP. Se um link em um canal existente falhar, a agport será atualizada e o tráfego será submetido a hash nos links restantes em um segundo. Um link pode falhar por estes e outros motivos:

• Uma porta está desconectada

• Um GBIC é removido

• Uma fibra está quebrada

• Falha de hardware (interface ou módulo)

Qualquer tráfego que não precise ser submetido a novo hash após a falha (tráfego que continua a enviar no mesmo link) não sofre nenhuma perda. A restauração do link com falha aciona outra atualização para a agport e o tráfego é submetido a hash novamente.

Opções de configuração

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

Verificação (LACP e LACP)

A tabela nesta seção descreve um resumo de todos os cenários de modo de canalização de 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. Isso significa que algumas das combinações fecham as portas no lado de canalização.

Verificação (LACP e PAgP)

A tabela nesta seção descreve um resumo 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. Isso significa que algumas das combinações fecham as portas no lado de canalização.

Recomendação

A Cisco recomenda que você ative o PAgP nas conexões de canal entre os switches Cisco. Quando você canaliza para dispositivos que não suportam PAgP, mas suportam LACP, ative o LACP através da configuração do LACP ativo em ambas as extremidades dos dispositivos. Se uma das extremidades dos dispositivos não suportar LACP ou PAgP, você precisará aplicar um código fixo ao canal para ligar.

• 
  set channelprotocol lacp module 
  
  

  Nos switches que executam o CatOS, todas as portas em um Catalyst 4500/4000 e um Catalyst 6500/6000 usam o protocolo de canal PAgP por padrão e, como tal, não executam o LACP. Para configurar as portas para usar o LACP, você precisa definir o protocolo de canal nos módulos como LACP. LACP e PAgP não podem ser executados no mesmo módulo em switches que executam CatOS.

• set port lacp-channel port_range admin-key
  
  

  Um parâmetro admin key (chave administrativa) é trocado no pacote LACP. Um canal se forma apenas entre portas que têm a mesma chave de administrador. O comando set port lacp-channel port_range admin-key atribui aos canais um número de chave de administrador. O comando show lacp-channel group mostra o número. O comando set port lacp-channel port_range admin-key atribui a mesma chave admin a todas as portas no intervalo de portas. A chave admin é atribuída aleatoriamente se uma chave específica não estiver configurada. Em seguida, você pode consultar a chave admin, se desejar, para gerenciar a adição e a remoção de portas de canalização para a mesma agport.

• set port lacp-channel port_range mode active
  

  O comando set port lacp-channel port_range mode ative altera o modo de canal para ative para um conjunto de portas que foram anteriormente atribuídas à mesma chave de administrador.

Além disso, o LACP utiliza um temporizador de intervalo de 30 segundos (Slow_Periodic_Time) depois que os EtherChannels de LACP forem estabelecidos. O número de segundos antes da invalidação de informações LACPDU recebidas com o uso de timeouts longos (3 x Slow_Periodic_Time) é 90. Use UDLD, que é um detector mais rápido de links unidirecionais. Você não pode ajustar os temporizadores do LACP e hoje não pode configurar os switches para usar a transmissão rápida de PDU (a cada segundo) a fim de manter o canal após o canal ser formado.

Outras opções

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

Detecção de link unidirecional

O UDLD é um protocolo leve e proprietário da Cisco que foi desenvolvido para detectar instâncias de comunicações unidirecionais entre dispositivos. Embora existam outros métodos para detectar o estado bidirecional dos meios de transmissão, como o FEFI, há certas instâncias em que os mecanismos de detecção L1 não são suficientes. Esses cenários podem resultar em qualquer uma destas ocorrências:

• A operação imprevisível do STP

• Inundação incorreta ou excessiva de pacotes

• O buraco negro do tráfego

O recurso UDLD destina-se a abordar estas condições de falha nas interfaces Ethernet de fibra e cobre:

• Monitore as configurações de cabeamento físico e desligue todas as portas com fio incorretas como errdisable.

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

• Além disso, o modo assertivo UDLD verifica se um link anteriormente considerado bidirecional não perde conectividade durante o congestionamento e se torna inutilizável. O UDLD executa testes de conectividade contínuos através do link. A finalidade principal do modo assertivo UDLD é evitar o buraco negro de tráfego em certas condições de falha.

A árvore de abrangência, com seu fluxo de BPDU unidirecional estável, foi uma vítima grave dessas falhas. É fácil ver como uma porta pode de repente ser incapaz de transmitir BPDUs, causando uma mudança de estado de STP de blocking para forwarding no vizinho. Essa alteração cria um loop, já que a porta ainda pode receber.

Visão geral operacional

O UDLD é um protocolo L2 que funciona acima da camada LLC (destino MAC 01-00-0c-cc-cc-cc, tipo de protocolo SNAP HDLC 0x0111). Ao executar o UDLD em combinação com o FEFI e os mecanismos de autonegociação 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 autonegociação não podem executar, ou seja, a detecção e o armazenamento em cache de informações de vizinhos, a capacidade de encerrar quaisquer portas conectadas incorretamente e detectar defeitos de interface/porta lógica ou falhas em links que não são ponto a ponto (aqueles que atravessam conversores de mídia ou hubs).

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

O UDLD envia constantemente mensagens de sondagem em todas as portas nas quais o UDLD está habilitado. Sempre que uma mensagem específica de "disparo" de UDLD é recebida em uma porta, uma fase de detecção e um processo de validação são iniciados. Se, ao final desse processo, todas as condições válidas forem atendidas, o estado da porta não será alterado. Para atender às condições, a porta deve ser bidirecional e estar corretamente cabeada. Caso contrário, a porta é errdisable e uma mensagem de syslog é exibida. A mensagem de syslog é semelhante a estas mensagens:

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

• UDLD-4-ONEWAYPATH: Um link unidirecional da porta [dec]/[dec] para a porta

  [dec]/[dec] do dispositivo [chars] detectado

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

Depois que um link é estabelecido e classificado como bidirecional, o UDLD continua a anunciar mensagens de prova/eco em um intervalo padrão de 15 segundos. Esta tabela representa os estados de link UDLD válidos conforme reportados na saída do comando show udld port:

• Manutenção do 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 for recebida, ela será armazenada em cache e mantida na memória por um período máximo definido como período de hold-time. Quando o hold-time expira, a entrada do cache respectiva é excluída. Se uma nova mensagem de saudação for recebida dentro do período de hold-time, a entrada nova substituirá a antiga e o cronômetro de tempo de vida correspondente será reiniciado.

• 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 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 encerrada e nenhuma mensagem de resposta válida tiver sido recebida, o link será considerado unidirecional e um processo de restabelecimento de link ou de encerramento de porta poderá ser acionado.

Tempo de convergência

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

Observação: o valor do intervalo da mensagem determina a taxa na qual um vizinho envia testes UDLD após a fase de linkup ou detecção. O intervalo de mensagem não precisa corresponder em ambas as extremidades de um link, embora a configuração consistente seja desejável onde possível. Quando os vizinhos UDLD são estabelecidos, o intervalo de mensagem configurado é enviado e o intervalo de tempo limite para esse peer é calculado como sendo (3 * message_interval). Portanto, uma relação de peer expira depois que três saudações (ou testes) consecutivas são perdidas. Com os intervalos de mensagem diferentes em cada lado, esse valor de tempo limite é diferente em cada lado.

O tempo aproximado necessário para que o UDLD detecte uma falha unidirecional é de aproximadamente (2,5 * intervalo_da_mensagem + 4 segundos) ou aproximadamente 41 segundos com o uso do intervalo de mensagem padrão de 15 segundos. Isso está bem abaixo dos 50 segundos que geralmente são necessários para a reconvergência do STP. Se a CPU NMP tiver alguns ciclos sobressalentes e se você monitorar cuidadosamente seu nível de utilização, poderá reduzir o intervalo de mensagens (par) para o mínimo de 7 segundos. Esse intervalo de mensagens ajuda a acelerar a detecção por um fator significativo.

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

Observação: o UDLD não detecta todas as situações de falha do STP, como falhas causadas por uma CPU que não envia BPDUs por um tempo maior que (2 * FwdDelay + Maxage). Por esse motivo, 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 com as versões anteriores do UDLD que usam um intervalo de mensagem padrão não configurável de 60 segundos. Essas versões são susceptíveis a condições de loop de spanning tree.

Modo Agressivo de UDLD

O UDLD agressivo foi criado para abordar especificamente aqueles (poucos) casos em que um teste contínuo de conectividade bidirecional é necessário. Como tal, o recurso de modo agressivo fornece proteção avançada contra condições de link unidirecional perigosas nestas situações:

• Quando a perda de PDUs UDLD é simétrica e ambas as extremidades atingem o tempo limite, nenhuma porta é errdisabled.

• Um lado de um link tem uma porta travada (ambos transmitem [Tx] e Rx).

• Um lado de um link permanece ativo enquanto o outro lado foi desativado.

• A negociação automática, ou outro mecanismo de detecção de falhas L1, está desabilitada.

• É desejável uma redução da dependência dos mecanismos de L1 FEFI.

• 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, os testes agressivos de UDLD podem ser considerados como um "heartbeat", cuja presença garante a integridade do link.

O caso mais comum para uma implementação de UDLD assertivo é executar a verificação de conectividade em um membro de um pacote quando a negociação automática ou outro mecanismo de detecção de falhas de L1 estiver desabilitado ou não utilizável. Isso é particularmente verdadeiro com as conexões EtherChannel porque o PAgP/LACP, mesmo se habilitado, não usa temporizadores de saudação muito baixos no estado steady. Nesse caso, o UDLD agressivo tem o benefício adicional de prevenção de possíveis loops de spanning-tree.

As circunstâncias que contribuem para a perda simétrica de pacotes de prova UDLD são mais difíceis de caracterizar. Você deve entender que o UDLD normal verifica uma condição de link unidirecional, mesmo depois que um link atinge o status bidirecional. A intenção do UDLD é detectar problemas de L2 que causam loops de STP, e esses problemas são geralmente unidirecionais porque os BPDUs fluem apenas em 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 (para redes que dependem do STP) é quase sempre suficiente. No entanto, o modo assertivo UDLD é benéfico em situações em que o congestionamento é igualmente afetado em ambas as direções, o que causa a perda de provas UDLD em ambas as direções. Por exemplo, essa perda de testes UDLD pode ocorrer se a utilização da CPU em cada extremidade do link for elevada. Outros exemplos de perda bidirecional de conectividade incluem a falha de um destes dispositivos:

• Um transponder DWDM (Dense Wavelength Division Multiplexing, multiplexação densa por divisão de comprimento de onda)

• Um conversor de mídia

• Um hub

• Outro dispositivo L1

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

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

Depois que todos os vizinhos de uma porta tiverem expirado, o modo assertivo UDLD (se estiver habilitado) reinicia a sequência de linkup em um esforço para ressincronizar com quaisquer vizinhos potencialmente fora de sincronia. Esse esforço ocorre no anúncio ou na fase de detecção. Se, após uma rápida sequência de mensagens (oito tentativas com falha), o link ainda for considerado "indeterminado", a porta será colocada no estado errdisable.

Observação: alguns switches não são compatíveis com UDLD assertivo. Atualmente, o Catalyst 2900XL e o Catalyst 3500XL têm intervalos de mensagem codificados de 60 segundos. Esse intervalo não é considerado suficientemente rápido para proteger contra loops de STP em potencial (com o uso dos parâmetros de STP padrão).

UDLD em links roteados

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

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

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

• Uma VLAN com várias portas, mas que suporta apenas conexões roteadas

  Um exemplo é uma topologia de núcleo de L2 dividida.

Cada Interior Gateway Routing Protocol (IGRP) tem características exclusivas com relação à maneira como ele lida com relações de vizinhança e convergência de rota. As características discutidas nesta seção são relevantes ao comparar dois dos protocolos de roteamento mais comuns usados atualmente, o protocolo OSPF (Open Shortest Path First) e o EIGRP (Enhanced IGRP).

Primeiro, observe que uma falha de L1 ou L2 em qualquer rede roteada ponto-a-ponto resulta na destruição quase imediata da conexão L3. Como a única porta do switch nessa VLAN passa para um estado não conectado após a falha de L1/L2, o recurso de estado automático MSFC sincroniza os estados das portas L2 e L3 em aproximadamente dois segundos. Essa sincronização coloca a interface VLAN L3 em um estado ativo/inativo (com o protocolo de linha inativo).

Suponha valores de temporizador padrão. O OSPF envia mensagens hello a cada 10 segundos e tem um intervalo dead de 40 segundos (4 * hello). Esses temporizadores são consistentes para redes ponto-a-ponto e de broadcast OSPF. Como o OSPF requer comunicação bidirecional para formar uma adjacência, o pior caso de tempo de failover é de 40 segundos. Esse failover é o caso mesmo se a falha de L1/L2 não for pura em uma conexão ponto a ponto, o que deixa um cenário semioperacional com o qual o protocolo L3 deve lidar. Como o tempo de detecção do UDLD é muito semelhante ao tempo de um temporizador dead do OSPF que expira (cerca de 40 segundos), as vantagens da configuração do modo normal do UDLD em um link ponto a ponto do OSPF L3 são limitadas.

Em muitos casos, o EIGRP converge mais rápido que o OSPF. No entanto, você deve observar que a comunicação bidirecional não é necessária para que os vizinhos troquem informações de roteamento. Em cenários de falha semioperacional muito específicos, o EIGRP é vulnerável ao buraco negro de tráfego que dura até que algum outro evento torne as rotas por meio desse vizinho "ativas". O modo normal de UDLD pode aliviar as circunstâncias observadas nesta seção. O modo normal de UDLD detecta a falha de link unidirecional e o erro desabilita a porta.

Para conexões roteadas por L3 que usam qualquer protocolo de roteamento, o UDLD normal ainda oferece proteção contra problemas na ativação inicial do link. Tais problemas incluem cabeamento incorreto ou hardware defeituoso. Além disso, o modo assertivo UDLD oferece as seguintes vantagens nas conexões roteadas de L3:

• Evita o buraco negro desnecessário do tráfego

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

• Coloca um link não sincronizado no estado errdisable

• Protege contra loops resultantes das configurações do EtherChannel L3

Comportamento Padrão do UDLD

O UDLD é desabilitado globalmente e habilitado em prontidão nas portas da fibra, por padrão. Como o UDLD é um protocolo de infraestrutura necessário apenas entre switches, o UDLD é desabilitado por padrão nas portas de cobre. As portas de cobre tendem a ser usadas para acesso ao host.

Observação: o UDLD deve ser habilitado globalmente e no nível da interface antes que os vizinhos possam alcançar o status bidirecional. No CatOS 5.4(3) e posterior, o intervalo de mensagens padrão é de 15 segundos e é configurável entre 7 e 90 segundos.

A recuperação errdisable é desabilitada globalmente por padrão. Depois de ser habilitada globalmente, se uma porta entrar no estado errdisable, ela será reabilitada automaticamente após um intervalo de tempo selecionado. O tempo padrão é de 300 segundos, que é um temporizador global mantido para todas as portas de um switch. Você pode impedir manualmente a reativação de uma porta se definir o tempo limite de errdisable dessa porta como disable. Emita o comando set port errdisable-timeout mod/port disable .

Observação: o uso desse comando depende da versão do software.

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

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

Recomendação

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

• FEFI

• Negociação automática

• Protetor de loop

Ao implantar o UDLD, considere se um teste contínuo de conectividade bidirecional (modo agressivo) é necessário. Geralmente, se a negociação automática estiver habilitada, o modo assertivo não será necessário porque a negociação automática compensa a detecção de falhas em 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 em que o intervalo de mensagens UDLD é definido como o padrão de 15 segundos. Essa configuração pressupõe os temporizadores de spanning tree 802.1d padrão. 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 nas quais há uma ou mais portas no estado de bloqueio STP na topologia.

Execute estes comandos para habilitar o UDLD:

set udld enable

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


set udld enable port range


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

Você deve habilitar manualmente as portas que estão desabilitadas por erro devido a sintomas de link unidirecional. Emita o comando set port enable.

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

Outras opções

Para máxima proteção contra sintomas que resultam de links unidirecionais, configure o modo assertivo UDLD:

set udld aggressive-mode enable port_range

Além disso, você pode ajustar o valor do intervalo de mensagem UDLD entre 7 e 90 segundos em cada extremidade, onde houver suporte, para uma convergência mais rápida:

set udld interval time

Considere o uso do recurso de tempo limite errdisable em qualquer dispositivo que possa se tornar isolado da rede no caso de uma situação errdisable. Essa situação é geralmente verdadeira na camada de acesso e quando você implementa o modo assertivo UDLD sem recursos de gerenciamento de rede fora de banda.

Se uma porta for colocada no estado errdisable, a porta permanecerá inativa por padrão. Você pode emitir este comando, que reabilita as portas após um intervalo de tempo limite:

Observação: o intervalo de timeout é de 300 segundos por default.

>set errdisable-timeout enable ?
bpdu-guard

!--- This is BPDU port-guard.


channel-misconfig

!--- This is a channel misconfiguration.


duplex-mismatch
udld
other

!--- These are other reasons.


all

!--- Apply errdisable timeout to all reasons.

Se o dispositivo parceiro não for compatível com UDLD, como um host final ou roteador, não execute o protocolo. Emita este comando:

set udld disable port_range

Testar e monitorar o UDLD

O UDLD não é fácil de ser testado sem um componente genuinamente defeituoso/unidirecional no laboratório, como, por exemplo, um GBIC com defeito. O protocolo foi projetado para detectar cenários de falha menos comuns do que os cenários que são normalmente empregados em um laboratório. Por exemplo, se você executar um teste simples e desconectar um cabo de fibra para ver o estado errdisable desejado, será necessário desativar a negociação automática de L1. Caso contrário, a porta física é desativada, o que redefine a comunicação da mensagem UDLD. A extremidade remota passa para o estado indeterminado em UDLD normal. Se você usar o modo assertivo UDLD, a extremidade remota se moverá para o estado errdisable.

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

Para monitorar o UDLD, execute estes 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 no modo enable, você pode executar o comando oculto show udld neighbor para verificar o conteúdo do cache de UDLD (como faz o CDP). Uma comparação do cache UDLD com o cache CDP para verificar se há uma anomalia específica do protocolo é frequentemente útil. Sempre que o CDP também é afetado, todas as PDUs/BPDUs são tipicamente afetadas. Portanto, verifique também STP. Por exemplo, verifique se há alterações recentes na identidade da raiz ou alterações no posicionamento da porta raiz/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, você pode monitorar o status e a consistência da configuração do UDLD com o uso das variáveis UDLD SNMP MIB da Cisco.

Quadro jumbo

O tamanho padrão do quadro da Unidade Máxima de Transmissão (MTU - Maximum Transmission Unit) é de 1518 bytes para todas as portas Ethernet, o que inclui GE e 10 GE. O recurso de quadro jumbo permite que as interfaces comutem quadros maiores que o tamanho de quadro Ethernet padrão. O recurso é útil para otimizar o desempenho de servidor para servidor e para suportar aplicações como Multi-Protocol Label Switching (MPLS), tunelamento 802.1Q e L2 Tunneling Protocol Versão 3 (L2TPv3), que aumentam o tamanho dos quadros originais.

Visão geral operacional

A especificação do padrão IEEE 802.3 define um tamanho máximo de quadro Ethernet de 1518 bytes para quadros regulares e de 1522 bytes para quadros encapsulados 802.1Q. Os quadros encapsulados 802.1Q às vezes são chamados de "baby giants". Em geral, os pacotes são classificados como quadros gigantes quando excedem o comprimento máximo de Ethernet especificado para uma conexão Ethernet específica. Os pacotes gigantes também são conhecidos como quadros jumbo.

Há várias razões pelas quais o tamanho de MTU de determinados quadros pode exceder 1518 bytes. Estes são alguns exemplos:

• Requisitos específicos do fornecedor—Os aplicativos e determinadas NICs podem especificar um tamanho de MTU que esteja fora do padrão de 1500 bytes. A tendência de especificar tais tamanhos de MTU é devido a estudos que foram realizados, que provam que um aumento no tamanho de um quadro Ethernet pode aumentar o throughput médio.

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

• MPLS—Depois que o MPLS é ativado em uma interface, ele tem o potencial de aumentar o tamanho do quadro de um pacote. Esse aumento depende do número de rótulos na pilha de rótulos para um pacote marcado como MPLS. O tamanho total de um rótulo é 4 bytes. O tamanho total de uma pilha de rótulos é n x 4 bytes. Se uma pilha de rótulos for formada, os quadros podem exceder a MTU.

• Encapsulamento 802.1Q—Os pacotes de encapsulamento 802.1Q contêm duas tags 802.1Q, das quais apenas uma tag de cada vez é geralmente visível para o hardware. Portanto, a tag interna adiciona 4 bytes ao valor de MTU (tamanho de payload).

• Universal Transport Interface (UTI)/L2TPv3—UTI/L2TPv3 encapsula dados L2 que devem ser encaminhados pela rede IP. O encapsulamento pode aumentar o tamanho original do quadro em até 50 bytes. O novo quadro inclui um novo cabeçalho IP (20 bytes), um cabeçalho L2TPv3 (12 bytes) e um novo cabeçalho L2. O payload L2TPv3 consiste no quadro L2 completo, que inclui o cabeçalho L2.

A capacidade dos diferentes switches Catalyst de suportar vários tamanhos de quadro depende de muitos fatores, que incluem o hardware e o software. Determinados módulos podem suportar quadros maiores do que outros, mesmo dentro da mesma plataforma.

• Os switches Catalyst 5500/5000 fornecem 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 para 9.216 bytes. Em placas de linha baseadas em par trançado não blindado (UTP - Unshielded Twisted Pair) de 10/100 Mbps, o tamanho máximo de quadro suportado é de apenas 8092 bytes. Essa limitação é uma limitação ASIC. Geralmente, não há restrições na ativação do recurso de tamanho de quadro jumbo. Você pode usar esse recurso 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 de ASIC. No entanto, a exceção é o entroncamento 802.1Q.

• A plataforma da série Catalyst 6500 pode suportar tamanhos de quadro jumbo no CatOS versão 6.1(1) e posterior. No entanto, esse suporte depende do tipo de placa de linha que você usa. Geralmente, não há restrições na ativação do recurso de tamanho de quadro jumbo. Você pode usar esse recurso com entroncamento/não entroncamento e canalização/não canalização. O tamanho de MTU padrão é de 9.216 bytes depois que o suporte a quadro jumbo tiver sido habilitado na porta individual. O MTU padrão não é configurável com o uso do CatOS. No entanto, o Cisco IOS Software Release 12.1(13)E introduziu o comando system jumbomtu para substituir o MTU padrão.

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

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

Observação: o tamanho da MTU ou o tamanho do pacote se refere apenas ao payload Ethernet.

Suporte a quadros jumbo da camada 3

Com o CatOS executado no Supervisor Engine e o Cisco IOS Software executado no MSFC, os switches Catalyst 6500/6000 também fornecem suporte a quadro jumbo L3 no Cisco IOS® Software Release 12.1(2)E e posterior com o uso de PFC/MSFC2, PFC2/MSFC2 ou hardware posterior. Se as VLANs de entrada e saída estiverem configuradas para quadros jumbo, todos os pacotes serão comutados por hardware pelo PFC na velocidade de cabo. Se a VLAN de entrada estiver configurada para quadros jumbo e a VLAN de saída não estiver configurada, há dois cenários:

• Um quadro jumbo que é enviado pelo host final com o bit Don't Fragment (DF) definido (para descoberta de MTU de caminho)—O pacote é descartado e um Internet Control Message Protocol (ICMP) inalcançável é enviado ao host final com o fragmento de código de mensagem necessário e DF definido.

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

Esta tabela resume o suporte jumbo L3 para várias plataformas:

¹ RSM = módulo de switch de rota

² RSFC = Route Switch Feature Card

Consideração de desempenho de rede

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

• O Tamanho Máximo de Segmento (MSS), que é o comprimento da MTU menos o comprimento dos cabeçalhos TCP/IP

• O Tempo de Ida e Volta (RTT)

• A perda de pacotes

De acordo com essa fórmula, o throughput máximo de TCP que pode ser obtido é diretamente proporcional ao MSS. Com RTT constante e perda de pacotes, você pode dobrar o throughput de TCP se dobrar o tamanho do pacote. Da mesma forma, quando você usa quadros jumbo em vez de quadros de 1.518 bytes, um aumento de seis vezes no tamanho pode resultar em uma possível melhoria de seis vezes no throughput de TCP de uma conexão Ethernet.

Em segundo lugar, as demandas de desempenho cada vez maiores dos server farms exigem meios mais eficientes para garantir taxas de dados mais altas com datagramas UDP do NFS (Network File System). O NFS é o mecanismo de armazenamento de dados mais amplamente implantado para transferir arquivos entre servidores baseados em UNIX e apresenta datagramas de 8.400 bytes. Considerando o MTU estendido de 9 KB da Ethernet, um único quadro jumbo é grande o suficiente para transportar um datagrama de aplicativo de 8 KB (por exemplo, NFS) mais a sobrecarga do cabeçalho do pacote. Esse recurso, incidentalmente, permite transferências mais eficientes de acesso direto à memória (DMA) nos hosts porque o software não precisa mais para fragmentar blocos NFS em datagramas UDP separados.

Recomendação

Quando você quiser suporte a quadros jumbo, restrinja o uso de quadros jumbo a áreas da rede onde todos os módulos de switch (L2) e interfaces (L3) suportam 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 quadro suportado no caminho elimina quaisquer ganhos obtidos com o uso do recurso, pois a fragmentação é necessária. Como mostram as tabelas desta seção Quadro jumbo, diferentes plataformas e placas de linha podem variar com relação aos tamanhos máximos de pacotes suportados.

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

set port jumbo mod/port enable

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

interface vlan vlan#
mtu 9216

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

Configuração de gerenciamento

Considerações para ajudar a controlar, provisionar e solucionar problemas de uma rede Catalyst são discutidas nesta seção.

Diagramas de rede

Diagramas de rede claros são uma parte fundamental das operações de rede. Eles se tornam críticos durante a solução de problemas e são o veículo mais importante para a comunicação de informações quando encaminhados a fornecedores e parceiros durante uma interrupção. Sua preparação, prontidão e acessibilidade não devem ser subestimadas.

Recomendação

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

• Diagrama Geral — mesmo para as redes maiores, um diagrama que mostre a conectividade física e lógica fim-a-fim é importante. Pode ser comum para empresas que implementaram um design hierárquico documentar cada camada separadamente. Durante o planejamento e a solução de problemas, no entanto, muitas vezes é importante ter um bom conhecimento de como os domínios se conectam.

• Diagrama Físico—mostra todo o hardware e cabeamento do switch e do roteador. Troncos, links, velocidades, grupos de canais, números de porta, slots, tipos de chassi, software, domínios VTP, bridge raiz, prioridade de bridge raiz de backup, endereço MAC e portas bloqueadas por VLAN devem ser rotulados. Geralmente, é mais claro descrever dispositivos internos, como o MSFC do Catalyst 6500/6000, como um roteador em um bastão conectado por meio de um tronco.

  

• Diagrama Lógico — mostra somente a funcionalidade L3 (roteadores como objetos, VLANs como segmentos Ethernet). Endereços IP, sub-redes, endereçamento secundário, HSRP ativo e em espera, camadas de distribuição do núcleo de acesso e informações de roteamento devem ser rotulados.

  

Gerenciamento associado

Dependendo da configuração, a interface de gerenciamento em banda (interna) do switch (conhecida como sc0) pode ter que lidar com estes dados:

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

• Dados do usuário, como broadcasts e multicasts

• Protocolos de controle de switch como BPDUs de STP, VTP, DTP, CDP e assim por diante

É prática comum no design multicamada da Cisco configurar uma VLAN de gerenciamento que abrange um domínio comutado e contém 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 do switch. Esta seção descreve a importância e os problemas potenciais do uso da VLAN 1 padrão e da execução do tráfego de gerenciamento para o switch na mesma VLAN que o tráfego do usuário.

Visão geral operacional

A principal preocupação com o uso da VLAN 1 para dados de usuário é que o Supervisor Engine NMP em geral não precisa ser interrompido por grande parte do tráfego multicast e broadcast que é gerado pelas estações finais. Hardware mais antigo do Catalyst 5500/5000, o Supervisor Engine I e o Supervisor Engine II em particular, têm recursos limitados para lidar com esse tráfego, embora o princípio se aplique a todos os Supervisor Engines. Se a CPU, o buffer ou o canal em banda do Supervisor Engine no painel traseiro estiver totalmente ocupado escutando tráfego desnecessário, é possível que os quadros de controle possam ser perdidos. Na pior das hipóteses, isso poderia levar a um loop de Spanning Tree ou falha de EtherChannel.

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

Uma verificação de integridade adicional para hardware Catalyst 5500/5000 mais antigo é examinar a saída de show inband | biga (comando oculto) para erros de recursos (RscrcErrors), semelhantes a quedas de buffer em um roteador. Se esses erros de recurso aumentarem continuamente, a memória não estará disponível para receber pacotes do sistema, talvez devido a uma quantidade significativa de tráfego de broadcast na VLAN de gerenciamento. Um único erro de recurso pode significar que o Supervisor Engine não é capaz de processar um pacote, como BPDUs, o que pode rapidamente se tornar um problema porque protocolos como spanning tree não reenviam BPDUs perdidas.

Recomendação

Como destacado na seção Controle Cat deste documento, a VLAN 1 é uma VLAN especial que marca e trata a maior parte do tráfego do plano de controle. A VLAN 1 está habilitada em todos os troncos por padrão. Com redes de campus maiores, é necessário tomar cuidado com o diâmetro do domínio STP da VLAN 1; a instabilidade em uma parte da rede pode afetar a VLAN 1, influenciando assim a estabilidade do plano de controle e, portanto, a estabilidade do STP para todas as outras VLANs. No CatOS 5.4 e posterior, foi possível limitar a VLAN 1 de transportar dados de usuário e executar o STP com este comando:

clear trunk mod/port vlan 1

Isso não impede que os pacotes de controle sejam enviados de Switch para Switch em VLAN 1, como ocorre com um analisador de rede. No entanto, nenhum dado é encaminhado e o STP não pode ser executado nesse link. Portanto, essa técnica pode ser usada para dividir o VLAN 1 em domínios de falha menores.

Note:  Atualmente, não é possível limpar troncos VLAN 1 em 3500s e 2900XLs.

Mesmo que tenha sido tomado cuidado com o projeto do campus para restringir as VLANs de usuário a domínios de switch relativamente pequenos e limites de L3/falha correspondentemente pequenos, alguns clientes ainda são tentados a tratar a VLAN de gerenciamento de forma diferente e tentar cobrir toda a rede com uma única sub-rede de gerenciamento. Não há nenhuma razão técnica para que um aplicativo NMS central deva ser L2 adjacente aos dispositivos que gerencia, nem esse é um argumento de segurança qualificado. A Cisco recomenda que você limite o diâmetro das VLANs de gerenciamento para a mesma estrutura de domínio roteado que as VLANs de usuário e considere o gerenciamento fora de banda e/ou o suporte a CatOS 6.x SSH como uma forma de aumentar a segurança do gerenciamento de rede.

Outras opções

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

Não há uma resposta fácil para a questão de se uma VLAN de gerenciamento separada deve ser criada e o entroncamento habilitado para transportá-la entre as camadas de acesso L2 e de distribuição L3. Estas são duas opções para revisão do projeto com o engenheiro da Cisco:

• Opção 1: entroncar duas ou três VLANs exclusivas 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 que o STP está inativo. Observe que se a VLAN 1 for removida dos troncos, haverá uma etapa de configuração extra. Nessa solução, também há pontos de projeto a serem considerados para evitar o buraco negro temporário do tráfego roteado durante a recuperação de falhas: STP PortFast para troncos (CatOS 7.x e posterior) ou sincronização de estado automático de VLAN com encaminhamento de STP (posterior a CatOS 5.5[9]).

• Opção 2: uma única VLAN para dados e gerenciamento poderia ser aceitável. Com hardware de switch mais recente, como CPUs mais potentes e controles de limitação de taxa de plano de controle, além de um design com domínios de broadcast relativamente pequenos como defendido pelo design multicamada, a realidade para muitos clientes é que manter a interface sc0 separada dos dados do usuário é menos um problema do que era antes. Uma decisão final é provavelmente melhor tomada com o exame do perfil de tráfego de broadcast para essa VLAN e uma discussão sobre os recursos do hardware do switch com seu engenheiro da Cisco. Se a VLAN de gerenciamento realmente contiver todos os usuários naquele switch da camada de acesso, o uso de filtros de entrada IP é altamente recomendado para proteger o switch dos usuários, conforme discutido na seção Configuração de Segurança deste documento.

Gerenciamento fora de banda

Levando os argumentos da seção anterior um passo adiante, o gerenciamento de rede pode se tornar mais altamente disponível com a construção de uma infraestrutura de gerenciamento separada em torno da rede de produção, de modo que os dispositivos estejam sempre acessíveis remotamente, independentemente dos eventos do plano de controle ou acionados pelo tráfego que ocorram. Essas duas abordagens são típicas:

• Gerenciamento fora da banda com uma LAN exclusiva

• Gerenciamento fora da banda com servidores de terminal

Visão geral operacional

Cada roteador e cada Switch da rede podem ser fornecidos com uma interface de gerenciamento Ethernet fora de banda em uma VLAN de gerenciamento. Uma porta Ethernet em cada dispositivo é configurada na VLAN de gerenciamento e cabeada fora da rede de produção para uma rede de gerenciamento comutada separada através da interface sc0. Observe que os switches Catalyst 4500/4000 têm uma interface me1 especial no Supervisor Engine que deve ser usada somente para gerenciamento fora de banda, não como uma porta de switch.

Além disso, a conectividade do servidor de terminal pode ser obtida através da configuração de um Cisco 2600 ou 3600 com cabos RJ-45 para serial para acessar a porta de console de cada roteador e switch no layout. Um servidor terminal também evita a necessidade de configuração de cenários de backup, como modems em portas auxiliares para cada dispositivo. Um único modem pode ser configurado na porta auxiliar do servidor terminal para fornecer serviço de discagem para os outros dispositivos durante uma falha de conectividade de rede.

Recomendação

Com essa disposição, dois caminhos fora de banda para cada switch e roteador são possíveis, além de vários caminhos dentro da banda, permitindo assim o gerenciamento de rede altamente disponível. O out-of-band é responsável por:

• O out-of-band separa o tráfego de gerenciamento dos dados do usuário.

• Out-of-band tem o endereço IP de gerenciamento em uma sub-rede, VLAN e switch separados para maior segurança.

• O out-of-band fornece maior garantia para a entrega de dados de gerenciamento durante falhas de rede.

• Out-of-band não tem Spanning Tree ativo na VLAN de gerenciamento. A redundância não é crítica.

Testes do sistema

Diagnóstico de inicialização

Durante uma inicialização do sistema, vários processos são executados para garantir que uma plataforma confiável e operacional esteja disponível para que o hardware defeituoso não interrompa a rede. Os diagnósticos de inicialização do Catalyst são divididos entre POST (Power-On Self Test) e diagnósticos on-line.

Visão geral operacional

Dependendo da plataforma e da configuração de hardware, diagnósticos diferentes são realizados na inicialização e quando uma placa é trocada e removida do chassi. Um nível mais alto de diagnóstico resulta em um número maior de problemas detectados, mas em 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 e o tamanho da DRAM, da RAM e do cache e inicializam-nos):

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 no Supervisor Engine em standby e novamente no Supervisor Engine primário. A duração do diagnóstico depende da configuração do sistema (número de slots, módulos, portas). Há três categorias de testes:

• Teste de loopback—os pacotes do NMP do Supervisor Engine são enviados para cada porta, retornados ao NMP e examinados quanto a erros.

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

• Teste de Lógica de Reconhecimento de Endereço Avançado (EARL - Enhanced Address Recognition Logic)—os mecanismos de regravação do Supervisor Engine central e do módulo Ethernet em linha L3 são testados. As entradas de encaminhamento de hardware e as portas roteadas são criadas antes que os pacotes de exemplo sejam enviados (para cada tipo de encapsulamento de protocolo) do NMP através do hardware de switching em cada módulo e de volta para o NMP. Isso é para os módulos PFC do Catalyst 6500/6000 e mais recentes.

O diagnóstico online completo pode levar aproximadamente dois minutos. Os diagnósticos mínimos não executam testes de empacotamento ou regravação em módulos diferentes do Supervisor Engine e podem levar aproximadamente 90 segundos.

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

>show test 9

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

!--- Configuration setting.

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

!--- Faulty.

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

Recomendação

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

Observação: essa alteração não terá 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 de inicialização rápido pode ser preferível ao tempo de espera para executar o diagnóstico completo. Há outros fatores e temporizações envolvidos na ativação de um sistema, mas no geral, o POST e os diagnósticos on-line somam cerca de um terço novamente no tempo. Em testes com um chassi de nove slots do Supervisor Engine único totalmente preenchido com um Catalyst 6509, o tempo total de inicialização foi de cerca de 380 segundos com diagnósticos completos, cerca de 300 segundos com diagnósticos mínimos e apenas 250 segundos com diagnósticos ignorados. Emita este comando para configurar o desvio:

set test diaglevel bypass

Observação: o Catalyst 4500/4000 aceita ser configurado para diagnósticos mínimos, embora isso ainda resulte em um teste completo sendo realizado. O modo mínimo poderá ser suportado futuramente nesta plataforma.

Diagnóstico de tempo de execução

Quando o sistema estiver operacional, o Supervisor Engine do switch executa vários monitoramentos dos outros módulos. Se um módulo não estiver acessível através das mensagens de gerenciamento (Protocolo de Controle Serial [SCP] em execução no barramento de gerenciamento fora de banda), o Supervisor Engine tentará reiniciar a placa ou executar outra ação conforme apropriado.

Visão geral operacional

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

• NMP através de um watchdog

• Erros de chip EARL aprimorados

• Canal dentro da banda do Supervisor Engine para o painel traseiro

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

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

Detecção de erro de sistema e hardware

Visão geral operacional

No CatOS 6.2 e posterior, uma funcionalidade adicional foi adicionada para monitorar componentes críticos do sistema e no nível do hardware. Há suporte para estes três componentes de hardware:

• Inband

• Contador de porta

• Memória

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

Inband

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

• Inband stuck

• Erros de recursos

• Falha de Inband durante a inicialização

Na detecção de uma falha de ping inband, o recurso também relata uma mensagem syslog adicional com um instantâneo da taxa atual de Tx e Rx na conexão inband, CPU e carga de backplane do switch. Essa mensagem permite determinar corretamente se a inband está presa (sem Tx/Rx) ou sobrecarregada (Tx/Rx excessivo). Essas informações adicionais podem ajudá-lo a determinar a causa de falhas de ping inband.

Contador de porta

Quando você habilita esse recurso, ele cria e inicia um processo para depurar contadores de porta. O contador de porta monitora periodicamente os contadores de erro de porta interna selecionados. A arquitetura da placa de linha, 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 podem usar essas informações para solucionar problemas. Esse recurso não sonda contadores de erro como FCS, CRC, alinhamento e runts que estão diretamente associados à conectividade do parceiro de link. Consulte a seção EtherChannel/Link Errors Handling deste documento para incorporar esse recurso.

A pesquisa é executada a cada 30 minutos e é executada em segundo plano nos contadores de erros selecionados. Se a contagem for ativada entre duas pesquisas subsequentes na mesma porta, uma mensagem de syslog reportará o incidente e fornecerá os detalhes do contador de erros e do módulo/porta.

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

Memória

A habilitação deste recurso executa a monitoração de segundo plano e a detecção de condições de corrupção de DRAM. Tais condições de corrupção de memória incluem:

• Alocação

• Liberação

• Out of range

• Bad alignment

Recomendação

Ative todos os recursos de detecção de erros, que incluem inband, contadores de porta e memória, onde forem suportados. A habilitação desses recursos melhora o sistema pró-ativo e os diagnósticos de advertência de hardware para a plataforma do switch Catalyst. Execute estes comandos para habilitar todos os três recursos de detecção de erros:

set errordetection inband enable

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


set errordetection portcounters enable

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


set errordetection memory enable

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

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

>show errordetection

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

Tratamento de Erros de EtherChannel/Link

Visão geral operacional

No CatOS 8.4 e posterior, 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 no canal excede um limite de erro configurável dentro do intervalo especificado. O failover da porta ocorre somente se houver uma porta operacional deixada no EtherChannel. Se a porta com falha for a última porta no EtherChannel, a porta não entrará no estado port-failover. Essa porta continua a transmitir tráfego, independentemente do tipo de erro recebido. As portas únicas não canalizadas não entram no estado port-failover. Essas portas entram no estado errdisable quando o limite de erro é excedido dentro do intervalo especificado.

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

• InErrors

• RxCRCs (CRCAlignErrors)

• CDCs Tx

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

>show counters 4/48

.......

32 bit counters

0  rxCRCAlignErrors           =          0
.......

6  ifInErrors                 =          0
.......

12 txCRC                      =          0

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

Se o recurso estiver habilitado e a contagem de erros de uma porta atingir o valor alto do limite configurável dentro do período de contagem de amostragem especificado, a ação configurável será desativar erros ou failover de porta. A ação desativar erro coloca a porta no estado errdisable. Se você configurar a ação de failover da porta, o status do port channel será considerado. A porta é desativada por erro somente se a porta estiver em um canal, mas essa porta não for a última porta operacional no canal. Além disso, se a ação configurada for failover de porta e a porta for uma única porta ou não canalizada, a porta será colocada no estado errdisable quando a contagem de erros de porta atingir o valor alto do limite.

O intervalo é uma constante do temporizador para ler os contadores de erro de porta. O valor padrão do intervalo de erros de link é de 30 segundos. O intervalo permitido está entre 30 e 1800 segundos.

Há um risco de erro acidental na desativação de uma porta devido a um evento único inesperado. Para minimizar esse risco, as ações em uma porta são tomadas somente quando a condição persiste por esse número de amostragens consecutivas. O valor de amostragem padrão é 3 e o intervalo permitido é de 1 a 255.

O limite é um número absoluto a ser verificado com base no intervalo de erros de link. O limite inferior de erro de link padrão é 1000 e o intervalo permitido é de 1 a 65.535. O limite superior de erro de link padrão é 1001. Quando o número consecutivo de tempos de amostragem atinge o limite baixo, um syslog é enviado. Se os tempos de amostragem consecutivos atingirem o limite alto, um syslog será enviado e uma ação de desabilitação de erro ou de failover de porta será acionada.

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

• A seção Configuração de Tratamento de Erros de EtherChannel/Link de Verificação de Status e Conectividade

• A seção Configurando a Detecção de Erro de Porta de Configurando Ethernet, Fast Ethernet, Gigabit Ethernet e 10-Gigabit Ethernet Switching

Recomendações

Como o recurso usa mensagens SCP para gravar e comparar os dados, números altos de portas ativas podem ser de uso intensivo da CPU. Este cenário é ainda mais intensivo de CPU quando o intervalo de limite é definido para um valor muito pequeno. Habilite esse recurso com discrição para portas designadas como enlaces críticos e que transportam tráfego para aplicativos sensíveis. Execute este comando para habilitar globalmente a detecção de erros de link:

set errordetection link-errors enable

Além disso, comece com o limite padrão, o intervalo e os parâmetros de amostragem. E use a ação padrão, failover de porta.

Execute estes comandos para aplicar os parâmetros de erro de link global a 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 estes comandos para verificar a configuração de erros de link:

show errordetection

show port errordetection {mod | mod/port}

Diagnósticos de buffer de pacote do Catalyst 6500/6000

Nas versões 6.4(7), 7.6(5) e 8.2(1) do CatOS, os diagnósticos de buffer de pacote do Catalyst 6500/6000 foram apresentados. Os diagnósticos de buffer de pacotes, que são ativados por padrão, detectam falhas no buffer de pacotes causadas por falhas transitórias da RAM estática (SRAM). A detecção ocorre 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 a condição de falha ocorre, 12 das 48 portas de 10/100 Mbps continuam conectadas e podem apresentar problemas de conectividade aleatórios. A única maneira de se recuperar dessa condição é desligar e religar o módulo de linha.

Visão geral operacional

Os diagnósticos de buffer de pacote verificam os dados armazenados em uma seção específica do buffer de pacote para determinar se ele está corrompido por falhas SRAM transitórias. Se o processo ler algo diferente do que escreveu, ele executará duas opções de recuperação configuráveis possíveis:

1. A ação padrão é desabilitar por erro as portas da placa de linha que são afetadas pela falha do buffer.

2. A segunda opção é desligar e religar a placa de linha.

Duas mensagens de syslog foram adicionadas. As mensagens fornecem um aviso da desabilitação por erro das portas ou do ciclo de alimentação do módulo devido a 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 de ciclo de energia da placa de linha está 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 do firmware para as placas de linha instaladas durante o processo de inicialização inicial 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 o menor impacto no serviço de rede durante as horas de produção. Se possível, mova a conexão afetada pelas portas desativadas por erro para outras portas de switch disponíveis para restaurar o serviço. Programe um ciclo de alimentação manual da placa de linha durante a janela de manutenção. Execute o comando reset module mod para se recuperar totalmente da condição de buffer de pacote corrompido.

Observação: se os erros continuarem após o módulo ser redefinido, tente recolocar o módulo.

Execute este comando para habilitar a opção errdisable:

set errordetection packet-buffer errdisable

!--- This is the default.

Outra opção

Como um ciclo de energia da placa de linha é necessário para recuperar completamente todas as portas que encontraram uma falha de SRAM, uma ação de recuperação alternativa é configurar a opção de ciclo de energia. Essa opção é útil em circunstâncias em que 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 que um módulo de linha execute o ciclo completo de energia e volte a funcionar sem o recurso de inicialização rápida. O recurso de inicialização rápida pode reduzir o tempo de interrupção nos serviços de rede para 10 segundos com a opção de ciclo de energia. Execute este comando para habilitar a opção de ciclo de energia:

set errordetection packet-buffer power-cycle

Diagnóstico de Buffer de Pacotes

Este teste é somente para switches Catalyst 5500/5000. Este teste é projetado para encontrar hardware com falha nos switches Catalyst 5500/5000 que estão usando módulos Ethernet com hardware específico que fornecem conectividade de 10/100 Mbps entre as portas do usuário e o painel traseiro do switch. Como não podem executar a 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 pode levar à propagação de quadros defeituosos para a rede ISL do Catalyst 5500/5000, o que potencialmente causa interrupção no plano de controle e tempestades de broadcast nos piores cenários.

Os módulos Catalyst 5500/5000 mais recentes e outras plataformas atualizaram a verificação de erros de hardware incorporada e não precisam de testes de buffer de pacotes, portanto, não há opção para configurá-lo.

Os módulos de linha que precisam do diagnóstico 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-X5214 223, WS-X524, 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 do que escreveu, ele desliga a porta no modo falha, uma vez que a porta poderia corromper os dados. Não há necessidade de limite de erros. As portas com falha não podem ser ativadas novamente até que o módulo seja redefinido (ou substituído).

Há dois modos para testes de buffer de pacotes: programado e sob demanda. Quando um teste é iniciado, mensagens de syslog são geradas para indicar a duração esperada do teste (arredondada para o minuto mais próximo) e o fato de que o teste foi iniciado. O comprimento exato do teste varia por tipo de porta, tamanho do buffer e tipo de execução de teste.

Os testes sob demanda são agressivos a fim de serem concluídos em poucos minutos. Como esses testes interferem ativamente na memória do pacote, as portas devem ser desativadas administrativamente antes dos testes. Execute este comando para desligar 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 programados são muito menos agressivos do que os testes sob demanda e são executados em segundo plano. 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. No entanto, como o teste é de gravações na memória de buffer, ele bloqueia os pacotes recebidos por alguns milissegundos e causa alguma perda em links ocupados. Por padrão, há uma pausa de oito segundos entre cada teste de gravação de buffer para minimizar qualquer perda de pacotes, mas isso significa que um sistema cheio de módulos que precisam do teste de buffer de pacotes pode levar mais de 24 horas para que o teste seja concluído. Este teste agendado é ativado por padrão para ser executado semanalmente às 03:30 de domingo a partir do CatOS 5.4 ou posterior, e o status do teste pode ser confirmado com este comando:

>show test packetbuffer status


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

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

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

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

Recomendação

A Cisco recomenda que você use o recurso de teste de buffer de pacote programado para sistemas Catalyst 5500/5000, pois o benefício de descobrir problemas em módulos supera o risco de baixa perda de pacotes.

Um horário padronizado semanal deve ser agendado em toda a rede, permitindo que o cliente altere os links de portas defeituosas ou módulos de RMA, conforme necessário. Como esse teste pode causar alguma perda de pacotes, dependendo da carga da rede, ele deve ser programado para horários de rede mais silenciosos, como o padrão de 3:30 da manhã de domingo. Execute este comando para definir a hora do teste:

set test packetbuffer Sunday 3:30

!--- This is the default.

Uma vez habilitado (como quando o CatOS é atualizado para 5.4 e posterior pela primeira vez), há uma chance de que um problema de memória/hardware anteriormente oculto seja exposto, e uma porta é desativada automaticamente como resultado. Você pode ver esta mensagem:

%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 este comando para iniciar este recurso manualmente em uma base por intervalo (embora a porta deva 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 proativo. Uma gama mais ampla de condições de rede e protocolo são relatadas usando syslog do que é possível através de SNMP padronizado. Plataformas de gerenciamento, como o Cisco Resource Manager Essentials (RMEs) e o Network Analysis Toolkit (NATkit), fazem uso avançado das informações de syslog porque executam estas tarefas:

• Apresentar a análise por gravidade, mensagem, dispositivo e assim por diante

• Habilitar filtragem de mensagens que chegam para análise

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

Recomendação

Um ponto importante de foco é o nível de informações de registro que devem ser geradas localmente e mantidas no buffer do switch, em oposição ao que é enviado a um Servidor 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 para o próprio switch para examinar os registros mais detalhados de um evento ou permitem um nível mais alto 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 em uma base por sessão com set logging session enable sem alterar o que é registrado por padrão.

A Cisco geralmente recomenda que você eleve o spantree e os recursos de syslog do sistema para o nível 6, já que esses são recursos de estabilidade importantes a serem rastreados. Além disso, para ambientes multicast, é recomendável elevar o nível de registro do recurso mcast para 4, de modo 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 as listas de entrada IP forem usadas, um nível mínimo de registro de 4 é recomendado para capturar tentativas de login não autorizadas. Execute estes comandos para definir estas opções:

set logging buffer 500

!--- This is the default.

set logging server syslog server IP address
set logging server enable

!--- This is the default.

set logging timestamp enable
set logging level spantree 6 default

!--- Increase default STP syslog level.

set logging level sys 6 default

!--- Increase default system syslog level.

set logging server severity 4

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

set logging console disable

Desligue as mensagens do console para se proteger contra o risco do switch travar enquanto espera por uma resposta de um terminal lento ou inexistente quando o volume da mensagem estiver alto. O registro de console é uma prioridade alta no CatOS e é usado principalmente para capturar as mensagens finais localmente durante o Troubleshooting ou em um cenário de travamento de switch.

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

¹ No CatOS 7.x e posterior, o código de recurso ethc substitui o código de recurso pagp para refletir o suporte LACP.

Observação: atualmente, os switches Catalyst registram uma mensagem de alteração de configuração do syslog nível-6 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ê precisar que os RMEs façam backup das configurações em tempo real nesse disparo, essas mensagens também precisarão ser enviadas ao servidor syslog de RMEs. Para a maioria dos clientes, backups periódicos de configuração para switches Catalyst são suficientes e não é necessária nenhuma alteração da gravidade de registro do servidor padrão.

Se você ajustar os alertas NMS, consulte o Guia de mensagens do sistema.

Protocolo simples de gestão de rede

O SNMP é usado para recuperar estatísticas, contadores e tabelas armazenados nas bases de gerenciamento de informações (MIBs) do dispositivo de rede. As informações coletadas podem ser usadas pelos NMSs (como o HP Openview) para gerar alertas em tempo real, medir a disponibilidade e produzir informações de planejamento de capacidade, bem como para ajudar a executar verificações de configuração e solução de problemas.

Visão geral operacional

Com alguns mecanismos de segurança, uma estação de gerenciamento de rede é capaz de recuperar informações nas MIBs com o protocolo SNMP get e get próximas solicitações, e de 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 oferece suporte a estas versões do SNMP:

• SNMPv1: RFC 1157 Internet Standard, usando segurança de string de comunidade de texto claro. Uma lista de controle de acesso e uma senha de endereço IP definem a comunidade de gerentes capazes de acessar a MIB do agente.

• SNMPv2C: uma combinação de SNMPv2, um padrão de Internet de rascunho definido nas RFCs 1902 a 1907, e SNMPv2C, uma estrutura administrativa baseada em comunidade para SNMPv2 que é um rascunho experimental definido na RFC 1901. Os benefícios incluem um mecanismo de recuperação em massa que suporta a recuperação de tabelas e grandes quantidades de informações, minimiza o número de round trips necessários e melhora o tratamento de erros.

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

  • Integridade da mensagem: garante que um pacote não foi adulterado em trânsito

  • Autenticação: determina que a mensagem é de uma origem válida

  • Criptografia: mistura o conteúdo de um pacote para evitar que ele seja facilmente visualizado por uma origem não autorizada

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

Observação: lembre-se destas informações sobre 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, gravar 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 para seus usuários.

Recomendação de armadilha 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 usa o SNMPv2C hoje nesta configuração:

set snmp community read-only string


!--- Allow viewing of variables only.


set snmp community read-write string


!--- Allow setting of variables.


set snmp community read-write-all string

!--- Include setting of SNMP strings. 

A Cisco recomenda que as interceptações SNMP sejam habilitadas para todos os recursos em uso (os recursos não usados podem ser desabilitados, se desejado). Quando uma interceptação é ativada, ela pode ser testada com o comando test snmp e a configuração de tratamento apropriada no NMS para o erro (como um alerta de pager ou pop-up).

Todas as interceptações são desativadas por padrão e precisam ser adicionadas à configuração, individualmente ou com o 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:

Observação: a armadilha de syslog também envia todas as mensagens de syslog geradas pelo switch para o NMS como uma armadilha de SNMP. Se o alerta de syslog já estiver sendo executado por um analisador como Cisco Works 2000 RMEs, não será necessariamente útil receber essas informações duas vezes.

Diferentemente do Cisco IOS Software, as interceptações SNMP no nível da porta são desativadas por padrão, pois os switches podem 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. Outras portas, como portas de host do usuário, não são exigidas, o que ajuda a simplificar o gerenciamento de redes.

set port trap port range enable

!--- Enable on key ports only.

Recomendação de pesquisa SNMP

Recomenda-se uma revisão do gerenciamento de rede para discutir as necessidades específicas em detalhes. No entanto, algumas filosofias básicas da Cisco para o gerenciamento de grandes redes estão listadas:

• 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 com apenas algumas ferramentas, como o 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 CGI como uma forma de publicar na Web.

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

• Descubra o que está funcionando bem na rede e deixe-a em paz. Concentre-se naquilo que não está funcionando.

A primeira fase da implementação do NMS deve ser a linha de base do hardware de 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 painel traseiro em Switches. Somente após uma linha de base de hardware, a carga de tráfego L2 e L3, o pico e as linhas de base médias tornam-se totalmente significativos. As linhas de base são normalmente estabelecidas ao longo de vários meses para obter visibilidade de tendências diárias, semanais e trimestrais - de acordo com o ciclo de negócios da empresa.

Muitas redes sofrem problemas de desempenho e capacidade de NMS causados por polling excessivo. Portanto, recomenda-se, uma vez estabelecida a linha de base, definir limites de RMON de alarme e evento nos próprios dispositivos para alertar o NMS sobre alterações anormais e, assim, remover a interrogação. 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 do NMS é pesquisar áreas específicas da rede com mais detalhes com o SNMP. Isso inclui áreas de dúvida, áreas antes de uma alteração ou áreas que devem ser caracterizadas como funcionando bem. Use os sistemas NMS como um holofote para examinar a rede em detalhes e iluminar os pontos de acesso (não tente ligar toda a rede).

O grupo Cisco Network Management Consulting sugere que essas MIBs de falha principais sejam analisadas ou monitoradas nas redes de campus. Consulte Monitoramento de rede Cisco e Diretrizes de correlação de evento para obter mais informações (sobre MIBs de desempenho para pesquisar, por exemplo).

Consulte Cisco Network Management Toolkit - MIBs para obter mais informações sobre o suporte a MIB da Cisco.

Observação: alguns MIBs padrão supõem que uma determinada entidade SNMP contenha apenas uma instância do MIB. Assim, a MIB padrão não tem nenhum índice que permita aos usuários acessar diretamente uma instância específica da MIB. Nesses casos, a indexação de sequência de caracteres de comunidade é fornecida para 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 espera-se que seu uso ultrapasse o SNMPv2 no tempo. A Cisco recomenda que os clientes se preparem para esse novo protocolo como parte de sua estratégia de NMS. Os benefícios são que os dados podem ser coletados seguramente dos dispositivos SNMP sem medo de falsificação ou corrupção. Informações confidenciais, como pacotes do comando SNMP set que alteram a configuração de um switch, podem ser criptografadas para evitar que 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 da linha de comando do SNMPv2, e é de se esperar um aumento na carga da CPU no Supervisor Engine.

Monitoramento remoto

O RMON permite que os dados da MIB sejam pré-processados pelo próprio dispositivo de rede, em preparação para usos comuns ou aplicação dessas informações pelo gerenciador de rede, como a realização de determinação de linha de base histórica e 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.

Visão geral operacional

Os switches Catalyst suportam minirrMON no hardware em cada porta, que consiste em quatro grupos RMON-1 básicos: 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. Conforme discutido, a configuração dos limiares de RMON permite que o switch envie uma interceptação SNMP quando ocorre uma condição anômala. Depois que as portas principais forem identificadas, o SNMP pode ser usado para pesquisar contadores ou grupos de histórico RMON e criar linhas de base que registrem a atividade normal de tráfego para essas 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 executada com um pacote de gerenciamento RMON, já que a criação bem-sucedida das linhas de parâmetros nas tabelas de Alarmes e Eventos é entediante. Pacotes RMON NMS comerciais, como o Cisco Traffic Diretor, parte do Cisco Works 2000, incorporam GUIs que tornam a configuração de limiares de RMON muito mais simples.

Para fins de linha de base, o grupo etherStats fornece um intervalo útil de estatísticas de tráfego L2. Os objetos nesta tabela podem ser usados para obter estatísticas sobre tráfego unicast, multicast e broadcast, bem 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. Os históricos de RMON podem fornecer linhas de base precisas sem sobrecarga substancial de interrogação. No entanto, quanto mais históricos forem coletados, mais recursos de switch serão usados.

Embora os switches forneçam apenas quatro grupos básicos de RMON-1, é importante não esquecer o resto de RMON-1 e RMON-2. Todos os grupos são definidos no RFC 2021, incluindo o UserHistory (grupo 18) e o ProbeConfig (grupo 19). As informações de L3 e superiores podem ser recuperadas de switches com a porta SPAN ou os recursos de redirecionamento de ACL de VLAN que permitem copiar o tráfego para um SwitchProbe RMON externo ou um Network Analysis Module (NAM) interno.

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

Você pode usar uma porta SPAN e uma sonda de switch para capturar um fluxo de pacote para uma porta, tronco ou VLAN específica e carregar os pacotes para decodificação com um pacote de gerenciamento RMON. A porta de SPAN é controlada por SNMP através do grupo de SPAN no CISCO-STACK-MIB, portanto esse processo é fácil de automatizar. O Traffic Diretor utiliza esses recursos com o recurso de agente móvel.

Existem caveats para abranger toda uma VLAN. Mesmo que você use uma sonda de 1 Gbps, todo o fluxo de pacotes de uma VLAN ou até mesmo uma porta full-duplex de 1 Gbps pode exceder a largura de banda da porta SPAN. Se a porta de SPAN estiver sendo executada continuamente com a largura de banda total, há chances de que os dados sejam perdidos. Consulte Configurando o recurso Catalyst Switched Port Analyzer (SPAN) para obter mais detalhes.

Recomendação

A Cisco recomenda que os limiares de RMON e alertas sejam implementados para ajudar o gerenciamento de rede de uma maneira mais inteligente do que a interrogação de SNMP sozinha. Isso reduz a sobrecarga de tráfego de gerenciamento de rede e permite que a rede alerte inteligentemente quando algo foi alterado a partir da linha de base. O RMON precisa ser acionado por um agente externo, como o Traffic Diretor; não há suporte CLI. Execute estes comandos para habilitar o RMON:

set snmp rmon enable
set snmp extendedrmon netflow enable mod


!--- For use with NAM module only.

É 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, ao configurar históricos e limites em várias portas para várias 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 da regra de porta crítica: somente sonde e defina limites nas portas identificadas como importantes na etapa de planejamento.

Requisitos de memória

O uso da memória RMON é constante em todas as plataformas de switching em relação a estatística, históricos, alarmes e eventos. O RMON usa um bucket para armazenar históricos e estatísticas no agente RMON (o switch, nesse caso). O tamanho do bucket é definido na prova RMON (prova do switch) ou na aplicação RMON (diretor de tráfego) e, em seguida, enviado ao switch para ser definido. Normalmente, as restrições de memória são apenas uma consideração em Supervisor Engines mais antigos com menos de 32 MB de DRAM. Consulte estas diretrizes:

• Aproximadamente 450K de espaço de código são adicionados à imagem NMP para oferecer suporte a minirrMON (que são quatro grupos de RMON: estatísticas, históricos, 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 RMON em tempo de execução para cada grupo minirrMON são explicadas aqui:

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

  • Grupo de histórico—Para a interface Ethernet, cada entrada de controle de histórico configurada com 50 buckets ocupa aproximadamente 3,6KB de 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 evento correspondentes.

• Para salvar a configuração relacionada ao RMON, é necessário aproximadamente 20K de espaço de NVRAM se o tamanho total de NVRAM do sistema for 256K ou mais e 10K de espaço de NVRAM se o tamanho total de NVRAM for 128K.

Protocolo de tempo de rede

O NTP, RFC 1305, sincroniza a cronometragem entre um conjunto de servidores de tempo e clientes distribuídos e permite que os eventos sejam correlacionados quando os logs do sistema são criados ou outros eventos específicos de tempo 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 caminhos de rede para obter uma alta precisão e confiabilidade. Algumas configurações incluem autenticação criptográfica para evitar ataques acidentais ou maliciosos ao protocolo.

Visão geral operacional

O NTP foi documentado pela primeira vez no RFC 958, mas evoluiu através do RFC 1119 (NTP versão 2) e está agora em sua terceira versão, conforme definido no RFC 1305. Ele é executado na porta UDP 123. Toda a comunicação NTP usa UTC, que é o mesmo horário do Horário de Greenwich.

Acessando servidores de tempo públicos

A sub-rede NTP inclui no momento mais de 50 servidores primários públicos sincronizados diretamente com o UTC por rádio, satélite ou modem. Normalmente, estações de trabalho de cliente e servidores com um número relativamente pequeno de clientes não sincronizam com servidores primários. 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 normalmente não disponíveis para o público. Para obter uma lista de servidores NTP públicos e informações sobre como usá-los, consulte o site Time Synchronization Server da Universidade de Delaware.

Como não há garantia de que esses servidores NTP de Internet pública estarão disponíveis ou que eles produzirão a hora correta, é altamente recomendável que outras opções sejam consideradas. Isso pode incluir o uso de vários dispositivos GPS (Global Positioning Service) independentes diretamente conectados a vários roteadores.

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

Stratum

Cada servidor NTP adota um estrato que indica a distância de uma fonte externa de tempo em que o servidor está. Os servidores de estrato 1 possuem acesso a algum tipo de origem de tempo externa, tal como um relógio de rádio. Os servidores Stratum 2 obtêm detalhes de tempo de um conjunto determinado de servidores Stratum 1, enquanto os servidores Stratum 3 obtêm detalhes de tempo de servidores Stratum 2, e assim por diante.

Relacionamento de peer de servidor

• Um servidor é aquele que responde às solicitações do cliente, mas não tenta incorporar nenhuma informação de data de uma fonte de tempo do cliente.

• Um peer é aquele que responde às solicitações do cliente, mas tenta usar as solicitações do cliente como um candidato potencial para uma fonte de tempo melhor e para ajudar na estabilização de sua frequência de relógio.

• Para ser um peer verdadeiro, ambos os lados da conexão devem entrar em uma relação de peer, em vez de ter um usuário como peer e o outro como servidor. Também é recomendável que os peers troquem chaves para que somente os hosts confiáveis se comuniquem entre si como peers.

• Em uma solicitação do cliente a um servidor, o servidor responde ao cliente e esquece que o cliente já fez uma pergunta; em uma solicitação de cliente para um peer, o servidor responde ao cliente e mantém informações de estado sobre o cliente para rastrear como ele está se saindo na cronometragem e que servidor de estrato está sendo executado.

  Observação: o CatOS só pode atuar como um cliente NTP.

Não é problema para um servidor NTP tratar de milhares de clientes. No entanto, lidar com centenas de peers tem um impacto na memória, e a manutenção do estado consome mais recursos da CPU na caixa, assim como a largura de banda.

Quantidade de interrogações

O protocolo NTP permite que um cliente consulte um servidor a qualquer momento. Na verdade, quando o NTP é configurado pela primeira vez em um dispositivo Cisco, ele envia oito consultas em rápida sucessão em 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 que o NTP faça polls novamente para obter uma resposta. No momento, a Cisco não tem um método para forçar manualmente que o tempo de POLL seja definido pelo usuário.

O contador de sondagem de NTP inicia em 2⁶ (64) segundos e é incrementado por potências de dois (conforme os dois servidores são sincronizados um com o outro), para 2¹⁰. 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 par 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 instabilidade no tempo, ele fará pesquisas com mais frequência. Se o relógio de referência for 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, maior o intervalo de pesquisa, o que significa que o cliente NTP recebeu oito respostas para suas últimas oito solicitações (o intervalo de pesquisa é então duplicado). Uma única resposta perdida faz com que o intervalo de pesquisa seja dividido. O intervalo de pesquisa começa em 64 segundos e vai até um máximo de 1024 segundos. Nas melhores circunstâncias, leva um pouco mais de duas horas para que o intervalo de pesquisa vá de 64 segundos a 1024 segundos.

Transmissões

As transmissões de NTP nunca foram encaminhadas. O comando ntp broadcast faz com que o roteador origine broadcasts NTP na interface em que está configurado. O comando ntp broadcastclient faz com que o roteador ou o switch ouça os broadcasts NTP na interface em que 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, isso pode ser mantido em redes de roteadores em enlaces de WAN. Os clientes NTP devem fazer a correspondência com os servidores NTP locais, não através da WAN até os roteadores centrais da estação central, que serão os servidores de estrato 2.

Um cliente NTP convergido usa 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 que um domínio inteiro de Catalysts receba um relógio de uma única mensagem de broadcast. No entanto, a precisão da cronometragem é reduzida marginalmente porque o fluxo de informações é unidirecional.

O uso de endereços de loopback como origem das atualizações também pode ajudar na consistência. As preocupações com segurança podem ser abordadas destas duas maneiras:

• Filtrando atualizações do servidor

• Autenticação

A correlação de tempo de eventos é extremamente valiosa em dois casos: solução de problemas e auditorias de segurança. Deve-se tomar cuidado para proteger as fontes de tempo e os dados, e a criptografia é recomendada para que eventos-chave não sejam apagados intencionalmente ou não.

A Cisco recomenda estas configurações:

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

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

set ntp timezone 
set ntp summertime 

!--- This more traditional configuration creates !--- more configuration work and NTP peerings.

set ntp client enable
set ntp server IP address of time server
set timezone zone name
set summertime date change details

!--- This is a sample router configuration to distribute !--- NTP broadcast information to the Catalyst broadcast clients.

ntp source loopback0
ntp server IP address of time server
ntp update-calendar
clock timezone zone name
clock summer-time date change details ntp authentication key key
ntp access-group access-list


!--- To filter updates to allow only trusted sources of NTP information.

Interface to campus/management VLAN containing switch sc0
        ntp broadcast

Protocolo Cisco Discovery

O CDP troca informações entre dispositivos adjacentes na camada de enlace de dados e é extremamente útil na determinação da topologia de rede e da configuração física fora da camada lógica ou IP. Supported devices are mainly Switches, routers, and IP phones. Esta seção destaca alguns dos aprimoramentos do CDP versão 1 comparados à versão 1.

Visão geral operacional

O CDP usa 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 é usado. Em Token Rings, é usado o endereço funcional c000.0800.0000. Quadros de CDP são enviados periodicamente a cada minuto por padrão.

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

O CDP versão 1 suporta estes parâmetros:

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

Note:  Quando um switch executa o CDPv1, ele descarta quadros v2. Quando um switch que executa o CDPv2 recebe um quadro CDPv1 em uma interface, ele começa a enviar quadros CDPv1 para fora dessa interface, além dos quadros CDPv2.

Recomendação

O CDP é ativado por padrão e é essencial para obter visibilidade de dispositivos adjacentes e para a solução de problemas. Ele também é usado por aplicativos de gerenciamento de rede para criar mapas de topologia de L2. Execute estes comandos para configurar o CDP:

set cdp enable

!--- This is the default.

set cdp version v2

!--- This is the default.

Em partes da rede onde um alto nível de segurança é necessário (como DMZs para a Internet), o CDP deve ser desativado dessa forma:

set cdp disable port range

O comando show cdp neighbors exibe a tabela CDP local. As entradas marcadas com uma estrela (*) indicam uma incompatibilidade de VLAN; as entradas marcadas com um # indicam uma incompatibilidade duplex. 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, têm a capacidade de fornecer energia por meio de cabos UTP para telefones IP. As informações recebidas através do CDP auxiliam no gerenciamento de energia no switch.

Como os telefones IP podem ter um PC conectado a eles e ambos os dispositivos se conectam à mesma porta no Catalyst, o switch tem a capacidade de colocar o telefone VoIP em uma VLAN separada, a auxiliar. Isso permite que o switch aplique facilmente uma Qualidade de Serviço (QoS) diferente para o tráfego VoIP.

Além disso, se a VLAN auxiliar for modificada (por exemplo, para forçar o telefone a usar uma VLAN específica ou um método de marcação específico), essas informações serão enviadas ao telefone por meio do CDP.

Observação: os switches Catalyst 2900 e 3500XL atualmente não suportam CDPv2.

Configuração de segurança

O ideal é que o cliente já tenha estabelecido uma política de segurança para ajudar a definir quais ferramentas e tecnologias da Cisco são qualificadas.

Observação: a segurança do Cisco IOS Software, ao contrário do CatOS, é tratada em muitos documentos, como Cisco ISP Essentials.

Recursos básicos de segurança

Senhas

Configure uma senha de nível de usuário (login). As senhas diferenciam maiúsculas de minúsculas no CatOS 5.x e posterior e podem ter de 0 a 30 caracteres de comprimento, incluindo espaços. Defina a senha de ativação:

set password password
set enablepass password

Todas as senhas devem atender aos padrões de comprimento mínimo (por exemplo, mínimo de seis caracteres, uma mistura de letras e números, letras maiúsculas e minúsculas) para logon e habilitar senhas quando usadas. Essas senhas são criptografadas usando o algoritmo de hash MD5.

Para permitir mais flexibilidade no gerenciamento da segurança de senha e do acesso ao dispositivo, a Cisco recomenda o uso de um servidor TACACS+. Consulte a seção TACACS+ deste documento para obter mais informações.

Secure Shell

Utilize a criptografia SSH para fornecer segurança para sessões Telnet e outras conexões remotas com o switch. A criptografia SSH é suportada apenas para logons remotos no switch. Não é possível criptografar sessões Telnet iniciadas a partir do switch. A versão 1 do SSH é suportada no CatOS 6.1, e o suporte à versão 2 foi adicionado no CatOS 8.3. A versão 1 do SSH suporta os métodos de criptografia DES (Data Encryption Standard) e DES Triplo (3-DES), e a versão 2 do SSH suporta os métodos de criptografia AES (Advanced Encryption Standard) e 3-DES. Você pode usar a criptografia SSH com autenticação RADIUS e TACACS+. Este recurso é suportado com imagens SSH (k9). Consulte Como Configurar SSH em Switches Catalyst Executando CatOS para obter detalhes.

set crypto key rsa 1024

Para desabilitar o fallback da versão 1 e aceitar conexões da versão 2, execute este 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 de porta:

set ip permit enable
set ip permit IP address mask Telnet|ssh|snmp|all

No entanto, se o acesso Telnet for restrito com esse comando, o acesso aos dispositivos CatOS só poderá ser obtido por meio de algumas estações finais confiáveis. Essa configuração pode ser um obstáculo na solução de problemas. Lembre-se de que é possível falsificar endereços IP e enganar o acesso filtrado, portanto, essa é apenas a primeira camada de proteção.

Segurança da porta

Considere a utilização da segurança de porta para permitir que apenas um ou vários endereços MAC conhecidos passem dados em uma porta específica (para impedir que estações finais estáticas sejam trocadas por novas estações sem controle de alterações, por exemplo). Isso é possível com endereços MAC estáticos.

set port security mod/port enable MAC address

Isso também é possível aprendendo dinamicamente endereços MAC restritos.

set port security port range enable 

Estas opções podem ser configuradas:

• set port security mod/port age time value —especifica a duração pela qual os endereços na porta são protegidos antes que um novo endereço possa ser aprendido. O tempo válido em minutos é de 10 a 1440. O padrão é sem envelhecimento.

• set port securitymod/port maximum value —palavra-chave que especifica o número máximo de endereços MAC a serem protegidos na porta. Os valores válidos são (padrão) - 1025.

• set port security mod/port violation shutdown —fecha a porta (padrão) se a violação ocorrer, bem como envia mensagem de syslog (padrão) e descarta o tráfego.

• set port security mod/port shutdown time value — duração pela qual uma porta permanece desativada. Os valores válidos são 10 a 1440 minutos. O padrão é desligado permanentemente

Com o CatOS 6.x e posterior, a Cisco introduziu a autenticação 802.1x, que permite que os clientes se autentiquem em um servidor central antes que as portas possam ser habilitadas para dados. Esse recurso está nos estágios iniciais de suporte em plataformas como Windows XP, mas pode ser considerado uma direção estratégica por muitas empresas. Consulte Configuração da Segurança de Porta para obter informações sobre como configurar a segurança de porta em switches que executam o Cisco IOS Software.

Banners de login

Crie banners de dispositivo adequados para declarar especificamente as ações realizadas para acesso não autorizado. Não anuncie o nome do site ou dados de rede que possam fornecer informações a usuários não autorizados. Esses banners fornecem recursos caso um dispositivo seja comprometido e o autor do crime seja pego:.

# set banner motd ^C
*** Unauthorized Access Prohibited ***
***  All transactions are logged   ***
------------- Notice Board -------------
----Contact Joe Cisco at 1 800 go cisco for access problems----
^C

Segurança física

Os dispositivos não devem estar fisicamente acessíveis sem a devida autorização, portanto o equipamento deve estar em um espaço controlado (bloqueado). para garantir que a rede permaneça operacional e não seja afetada por adulteração mal-intencionada de fatores ambientais, todos os equipamentos devem ter no-break (UPS) adequado (com fontes redundantes sempre que possível) e controle de temperatura (ar condicionado). Lembre-se de que, se o acesso físico for violado por uma pessoa com intenção mal-intencionada, a interrupção por meio da recuperação de senha ou outros métodos será muito mais provável.

Sistema de controle de acesso do controlador de acesso do terminal

Por padrão, as senhas do modo não privilegiado e privilegiado são globais e se aplicam a todos os usuários que acessam o switch ou roteador, seja pela porta de console ou por uma sessão Telnet na rede. A implementação em dispositivos de rede é demorada 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. Eles usam arquiteturas cliente/servidor para colocar 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 os seguintes recursos:

• Autenticação—o processo de identificação e verificação para um usuário. Vários métodos podem ser usados 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 concedida uma vez que um usuário é autenticado.

• Contabilização—a gravação do que um usuário está fazendo ou fez no dispositivo.

Consulte Configuração de TACACS+, RADIUS e Kerberos em Cisco Catalyst Switches para obter 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). Usa a porta TCP 49 como seu protocolo de transporte; isso oferece as seguintes vantagens sobre o UDP (usado pelo RADIUS):

• Transporte orientado a conexão

• Confirmação separada de que uma solicitação foi recebida (TCP ACK), independentemente de quão carregado o mecanismo de autenticação de back-end está atualmente

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

Durante uma sessão, se for necessária uma verificação adicional de autorização, o Switch verifica com o TACACS+ para determinar se o usuário tem permissão de usar um comando específico. Isso melhora o controla sobre os comandos que podem ser executados no Switch durante o desacoplamento do mecanismo de autenticação. Usando a contabilização de comandos, é possível auditar os comandos que um usuário específico emitiu enquanto estava conectado a um dispositivo de rede específico.

Quando um usuário tenta um login ASCII simples autenticando-se em um dispositivo de rede com TACACS+, este processo normalmente ocorre:

• Quando a conexão é estabelecida, o switch entra em contato com o daemon TACACS+ para obter um prompt de nome de usuário, que é exibido para o usuário. O usuário digita um nome de usuário e o switch entra em contato com o daemon TACACS+ para obter um prompt de senha. O switch exibe o prompt de senha para o usuário, que, em seguida, digita uma senha que também é enviada para o daemon TACACS+.

• O dispositivo de rede finalmente recebe uma destas respostas do daemon TACACS+:

  • ACEITAR—o usuário é autenticado e o serviço pode começar. Se o dispositivo de rede estiver configurado para exigir autorização, a autorização será iniciada neste momento.

  • REJEITAR—o usuário não foi autenticado. O usuário pode ter acesso negado ou é solicitado a tentar novamente a sequência de login, dependendo do daemon TACACS+.

  • ERRO—ocorreu um erro em algum momento durante a autenticação. Isso pode ser no daemon ou na conexão da rede entre o daemon e o Switch. Se uma resposta ERROR for recebida, o dispositivo de rede geralmente tenta usar um método alternativo para autenticar o usuário.

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

• Os usuários devem primeiro concluir com êxito a autenticação TACACS+ antes de prosseguir para a autorização TACACS+.

• Se a autorização de TACACS+ for necessária, o daemon TACACS+ será contatado e retornará uma resposta de autorização ACCEPT ou REJECT. Se uma resposta ACCEPT for retornada, a resposta conterá dados na forma de atributos usados para direcionar a sessão EXEC ou NETWORK para esse usuário e determinará os comandos que o usuário pode acessar.

Recomendação

A Cisco recomenda o uso do TACACS+, pois ele pode ser facilmente implementado usando o CiscoSecure ACS para NT, Unix ou outro software de terceiros. Os recursos TACACS+ incluem relatório detalhado 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. Essa é uma porta dos fundos importante a ser deixada na maioria das redes. Execute estes comandos para configurar o TACACS+:

set tacacs server server IP primary
set tacacs server server IP


!--- Redundant servers are possible.

set tacacs attempts 3

!--- This is the default.

set tacacs key key


!--- MD5 encryption key.

set tacacs timeout 15

!--- Longer server timeout (5 is default).

set authentication login tacacs enable
set authentication enable tacacs enable
set authentication login local enable
set authentication enable local enable

!--- The last two commands are the default; they allow fallback !--- to local if no TACACS+ server available.

Outras opções

É possível usar a 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 têm requisitos individuais nessa área. Consulte Controlando o Acesso ao Switch Usando Autenticação, Autorização e Contabilização 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 que usa 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

Essa configuração tem os seguintes recursos:

• O comando connect permite a contabilização de eventos de conexão de saída no Switch, como o Telnet.

• O comando exec habilita o relatório de sessões de login no Switch como da equipe de operações.

• O comando system permite a contabilização de eventos do sistema no switch, como reload ou reset.

• The commands command enables accounting of what was entered on the Switch, for both show and configuration commands.

• Atualizações periódicas a cada minuto para o 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 resumo das configurações recomendadas, excluindo detalhes de segurança.

É extremamente útil rotular todas as portas. Execute este comando para rotular as portas:

set port description descriptive name

Use esta tecla em conjunto com as tabelas de Comando listadas:

Comandos de configuração global

Comandos de configuração das portas de host

Comandos de configuração do servidor

Comandos de configuração de portas não utilizados

Portas de infraestrutura (switch-switch, switch-roteador)

Informações Relacionadas

• Mensagens de Erro CatOS Comuns nos Catalyst 4500/4000 Series Switches
• Mensagens de erro comuns de CatOS em Switches da série Catalyst 5500 ou 5000
• Mensagens de Erro CatOS Comuns nos Catalyst 6500/6000 Series Switches
• Suporte ao Produto - Switches
• Suporte de tecnologia de switching de LAN
• Suporte Técnico e Documentação - Cisco Systems