Inundação de Unicast em Redes de Campus Comutadas

Inundação de Unicast em Redes de Campus Comutadas
Índice
Introdução
Pré-requisitos
Requisitos
Componentes Utilizados
Convenções
Definição do Problema
Causas da Inundação
Causa 1: Roteamento Assimétrico
Causa 2: Alterações na Topologia do Spanning-Tree Protocol
Causa 3: Estouro da Tabela de Encaminhamento
Como Detectar a Inundação em Excesso
Introdução
Este documento discute as possíveis causas e implicações da inundação de pacotes de unicast em redes comutadas.
Pré-requisitos
Requisitos
Não existem requisitos específicos para este documento.
Componentes Utilizados
Este documento não se restringe a versões de software e hardware específicas.
Convenções
Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.
Definição do Problema
Os switches de LAN utilizam tabelas de encaminhamento (tabelas da Camada 2 (L2), tabelas CAM [Memória de Conteúdo Endereçável]) para
direcionar o tráfego a portas específicas com base no número da VLAN e no endereço MAC de destino do frame. Quando não há nenhuma
entrada correspondente ao endereço MAC de destino do frame na VLAN de entrada, o frame (unicast) é enviado a todas as portas de
encaminhamento na respectiva VLAN, ocasionando uma inundação.
Uma inundação limitada faz parte do processo de switching normal. No entanto, há situações em que uma inundação contínua poderá provocar
efeitos adversos no desempenho da rede. Este documento explica os problemas que podem surgir devido à inundação e as causas mais comuns de
certos tráfegos serem constantemente inundados.
Observe que a maioria dos switches modernos, incluindo os Catalyst 2900 XL, 3500 XL, 2940, 2950, 2970, 3550, 3750, 4500/4000, 5000 e
6500/6000 Series Switches, mantém tabelas de encaminhamento L2 por VLAN.
Causas da Inundação
A principal causa da inundação é a inexistência do endereço MAC de destino do pacote na tabela de encaminhamento L2 do switch. Nesse caso,
o pacote será inundado a partir de todas as portas de encaminhamento na respectiva VLAN (com exceção da porta em que foi recebido). Os casos
práticos a seguir mostram os motivos mais comuns para que o switch desconheça o endereço MAC de destino.
Causa 1: Roteamento Assimétrico
Grandes quantidades de tráfego inundado podem saturar os links de largura de banda baixa, ocasionando problemas de desempenho da rede ou
uma falha total da conectividade com dispositivos conectados por meio desses links. Considere o seguinte diagrama:
No diagrama acima, o servidor S1 na VLAN 1 está executando um backup (transferência de dados em massa) no servidor S2 da VLAN 2. O
gateway padrão do servidor S1 aponta para a interface VLAN 1 do roteador A. O gateway padrão do servidor S2 aponta para a interface VLAN2
do roteador B. Os pacotes de S1 para S2 seguirão este caminho:
S1--VLAN 1--switch A--roteador A--VLAN 2--switch B--VLAN 2--S2 (linha azul)
Os pacotes de S2 para S1 seguirão este caminho:
S2--VLAN 2--switch B--roteador B--VLAN 1--switch A--inundado para VLAN 1--S1 (linha vermelha)
Observe que, com essa disposição, o switch A não "verá" o tráfego do endereço MAC de S2 na VLAN 2 (uma vez que o endereço MAC de
origem será gravado novamente pelo roteador B, e o pacote chegará apenas na VLAN 1). Isso significa que, toda vez que o switch A precisar
enviar o pacote para o endereço MAC de S2, o pacote inundará a VLAN 2. A mesma situação ocorrerá com o endereço MAC de S1 no switch B.
Esse comportamento é denominado roteamento assimétrico. Os pacotes seguem caminhos diferentes dependendo da direção. O roteamento
assimétrico é uma das duas causas mais comuns de inundação.
Impacto da Inundação de Unicast
Voltando ao exemplo anterior, o resultado é que a maioria dos pacotes da transferência de dados entre S1 e S2 inundará a VLAN 2 no switch A e
a VLAN 1 no switch B. Isso significa que todas as portas conectadas (estação de trabalho W neste exemplo) na VLAN 1 no switch B receberão
todos os pacotes de conversação entre S1 e S2. Suponha que o backup do servidor ocupe 50 Mbps da largura de banda. Essa quantidade de
tráfego saturará os links de 10 Mbps. Isso causará uma falha total da conectividade com os PCs ou uma considerável redução de sua velocidade.
Essa inundação se deve ao roteamento assimétrico e poderá parar quando o servidor S1 enviar um pacote de broadcast (por exemplo, ARP
[Address Resolution Protocol]). O switch A inundará a VLAN 1 com esse pacote e o switch B receberá e aprenderá o endereço MAC de S1.
Como o switch não recebe tráfego constantemente, essa entrada de encaminhamento acabará expirando e a inundação recomeçará. O mesmo
processo se aplica a S2.
Há diferentes abordagens para limitar a inundação causada pelo roteamento assimétrico. Para obter mais informações, consulte os seguintes
documentos:
Roteamento Assimétrico com Grupos de Bridges em Catalyst 2948G-L3 e 4908G-L3 Switches
Roteamento Assimétrico e HSRP (Inundação Excessiva de Tráfego de Unicast na Rede com Roteadores que Executam o HSRP)
Geralmente, a abordagem é definir o timeout ARP do roteador e o tempo de validade da tabela de encaminhamento dos switches com valores
próximos. Isso ocasionará o broadcast dos pacotes ARP. A reaprendizagem deverá ocorrer antes da expiração da entrada da tabela de
encaminhamento L2.
Um cenário típico em que esse tipo de problema pode ser observado é quando existem switches da Camada 3 (L3) redundantes (como um
Catalyst 6000 com uma MSFC [Mutilayer Switch Feature Card]) configurado para balanceamento de carga com o HRSP (Hot Standby Router
Protocol). Nesse caso, um switch estará ativo para VLANs pares e outro para VLANs ímpares.
Causa 2: Alterações na Topologia do Spanning-Tree Protocol
Outro problema comum causado pela inundação é a TCN (Notificação de Alteração de Topologia) do STP (Spanning-Tree Protocol). A TCN tem
como objetivo corrigir as tabelas de encaminhamento após uma alteração na topologia de encaminhamento. Isso é necessário para evitar uma
falha de conectividade, visto que, após uma alteração de topologia, alguns destinos acessíveis anteriormente por meio de determinadas portas
podem se tornar acessíveis por meio de outras portas. A TCN opera diminuindo o tempo de validade da tabela de encaminhamento, de modo que,
se o endereço não for reaprendido, ele expirará e a inundação ocorrerá.
As TCNs são disparadas por uma porta durante a sua transição de/para o estado de encaminhamento. Após a TCN, mesmo que o endereço MAC
de destino específico tenha expirado, não deverá ocorrer inundação por muito tempo na maioria dos casos, já que o endereço será reaprendido. O
problema poderá surgir quando as TCNs ocorrerem repetidamente em intervalos curtos. Os switches farão com que suas tabelas de
encaminhamento expirem de forma rápida constantemente, de modo que a inundação será quase constante.
Normalmente, uma TCN é rara em redes configuradas de forma adequada. Quando a porta de um switch for ativada ou desativada, poderá ocorrer
uma TCN, uma vez que o estado STP da porta muda para/do modo de encaminhamento. Quando a porta está oscilando, isso resulta em TCNs
repetitivas e inundação.
As portas com o recurso portfast do STP ativado não gerarão TCNs quando mudarem para/do estado de encaminhamento. A configuração de
portfast em todas as portas de dispositivos finais (como impressoras, PCs, servidores etc.) deve limitar as TCNs a uma quantidade mínima. Para
obter mais informações sobre TCNS, consulte o seguinte documento:
Entendendo as Alterações de Topologia do Spanning-Tree Protocol
Nota: Na MSFC IOS, há uma otimização que disparará as interfaces VLAN para preencherem novamente suas tabelas ARP quando houver uma
TCN na respectiva VLAN. Isso limitará a inundação no caso de TCNs, pois haverá um broadcast ARP e o endereço MAC dos hosts será
reaprendido à medida que eles responderem ao ARP.
Causa 3: Estouro da Tabela de Encaminhamento
Outra possível causa de inundação é o estouro da tabela de encaminhamento do switch. Nesse caso, novos endereços não poderão ser aprendidos,
e os pacotes destinados a esses endereços serão inundados até que haja espaço disponível na tabela de encaminhamento. Depois disso, novos
endereços serão aprendidos. Embora seja possível, isso raramente ocorre uma vez que a maioria dos switches modernos possui tabelas de
encaminhamento grandes o suficiente para acomodar endereços MAC na maioria dos designs.
A exaustão da tabela de encaminhamento também pode ser ocasionada por um ataque à rede, no qual um host começa a gerar frames, cada um
tendo como origem um endereço MAC diferente. Isso bloqueará todos os recursos da tabela de encaminhamento. Quando essas tabelas ficarem
saturadas, outro tráfego será inundado porque não poderá ocorrer nova aprendizagem. Para detectar esse tipo de ataque, examine a tabela de
encaminhamento do switch. A maioria dos endereços MAC apontará para a mesma porta ou grupo de portas. Esses ataques podem ser evitados
com o recurso de segurança de portas, limitando-se o número de endereços MAC aprendidos nas portas não confiáveis.
Os Guias de Configuração dos Catalyst Switches que executam o Cisco IOS® ou o CatOS software têm uma seção chamada Configuração da
Segurança de Portas ou Configuração do Controle de Tráfego Baseado em Porta. Consulte a Documentação Técnica do seu switch nas páginas
dos produtos Cisco Switches para obter mais informações.
Como Detectar a Inundação Excessiva
A maioria dos switches não implementa nenhum comando especial para detectar a inundação. O Catalyst 6500/6000 Supervisor Engine 2 e os
switches de séries superiores que executam o Cisco IOS System software (Nativo) versão 12.1(14)E e superior ou o Cisco CatOS System
Software versão 7.5 ou superior implementam o recurso 'unicast flood protection'. Em resumo, esse recurso permite que o switch monitore a
quantidade de inundação de unicast por VLAN e tome a ação especificada se ela exceder a quantidade definida. As ações podem ser efetuar
syslog, limitar ou encerrar a VLAN - sendo que syslog é a de maior utilidade para a detecção de inundação. Quando a inundação exceder a taxa
configurada e a ação configurada for syslog, uma mensagem semelhante à seguinte será impressa:
%UNICAST_FLOOD-4-DETECTED: Host 0000.0000.2100 on vlan 1 is flooding
to an unknown unicast destination at a rate greater than/equal to 1 Kfps
O endereço MAC indicado é o endereço MAC de origem a partir do qual os pacotes são inundados nesse switch. Geralmente é necessário saber
os endereços MAC de destino que estão sendo inundados pelo switch (porque o switch faz o encaminhamento com base no endereço MAC de
destino). O Cisco IOS (Nativo) versões 12.1(20)E para o Catalyst 6500/6000 Supervisor Engine 2 e posterior implementará um recurso para a
exibição dos endereços MAC nos quais a inundação está ocorrendo:
cat6000#sh mac-address-table unicast-flood
Unicast Flood Protection status: enabled
Configuration:
vlan
Kfps
action
timeout
------+----------+-----------------+---------55
1
alert
none
Mac filters:
No.
vlan
souce mac addr.
installed on
time left (mm:ss)
-----+------+-----------------+------------------------------+-----------------Flood details:
Vlan
souce mac addr.
destination mac addr.
------+----------------+------------------------------------------------55
0000.2222.0000
0000.1111.0029, 0000.1111.0040, 0000.1111.0063
0000.1111.0018, 0000.1111.0090, 0000.1111.0046
0000.1111.006d
Uma investigação mais detalhada poderá ser feita para verificar se o endereço MAC 0000.2222.0000 supostamente deve enviar o tráfego para os
endereços MAC listados na seção de endereços MAC de destino. Se o tráfego for legítimo, será necessário determinar por que o switch
desconhece os endereços MAC de destino.
Para obter informações sobre a configuração da proteção contra inundação de unicast, consulte os seguintes documentos:
Configuração
Monitoração
É possível detectar se a inundação está ocorrendo capturando-se um rastreamento dos pacotes vistos em uma estação de trabalho quando há uma
queda de velocidade ou uma interrupção do funcionamento. Normalmente, pacotes de unicast que não envolvem a estação de trabalho não devem
ser vistos repetidamente na porta. Se isso estiver acontecendo, é provável que esteja ocorrendo inundação. Os rastreamentos de pacotes podem ter
uma aparência diferente quando existem várias causas de inundação.
Com o roteamento assimétrico, é provável que continue a ocorrer uma inundação de pacotes para endereços MAC específicos mesmo depois que
o destino responder. Com TCNs, a inundação incluirá vários endereços diferentes, mas deverá parar e, em seguida, reiniciar.
Com o estouro da tabela de encaminhamento L2, é provável que você observe o mesmo tipo de inundação que ocorre com o roteamento
assimétrico. A diferença é que provavelmente haverá uma grande quantidade de pacotes estranhos ou pacotes normais em quantidade anormal
com um endereço MAC de origem diferente.
© 1992-2014 Cisco Systems Inc. Todos os direitos reservados.
Data da Geração do PDF: 1 Julho 2009
http://www.cisco.com/cisco/web/support/BR/106/1067/1067650_143.html