Pacotes enviados indiscriminadamente fora do switch

Question

Os switches só devem enviar tráfego para um sistema se ele for destinado a esse sistema. O nosso parece não: se eu executo "tcpdump não hospeda myhostname", eu posso ver muitos pacotes que são claramente não-broadcast (ssh, nfs) viajando entre outros hosts. Como posso evitar isso? Eu acho que pode estar causando um desempenho ruim (nós temos um uso pesado do NFS; se estiver saindo de todas as portas do switch, isso não pode ser bom).

O switch é uma pilha de três switches gerenciados Netgear GS748TS. A atividade do interruptor acende todos os flash em sincronia continuamente, o que parece errado também.

    

Answer 1

Você pode não estar vendo o que vou descrever, há uma chance de que você esteja. Eu vi os sintomas que você está falando em vários switches Netgear e Linksys low-end e middle-of-the-road. Os switches que eu já vi este comportamento "louco" aconteceram por algum tempo, funcionando bem, mas começam a inundar os frames de todas as portas. A chamada que normalmente obtenho é "a rede está lenta", e o subsequente monitoramento de largura de banda geralmente localiza um único switch que "enlouqueceu", muitas vezes com suas luzes de atividade acesas, bombeando grandes quantidades de tráfego "falso" de tráfego legítimo, outras vezes lixo aparentemente aleatório).

Eu gosto da sugestão de Zypher sobre checar a utilização da CPU, mas eu também considero dividir a "pilha" (nesses switches em particular eu não sei se uma "pilha" opera como uma única unidade lógica ou não) e testando cada switch individualmente.

Parece que este problema piorou nos últimos anos com switches Ethernet sem nome, switches Linksys e Netgear. Eu não sei se há algum silício em comum que tenha um problema entre os switches problemáticos que vi ou não. (Estamos recomendando que nossos clientes comprem switches Dell PowerConnect e ainda não tenham visto esse tipo de problema com seus switches.)

    

Answer 2

Normalmente, um switch não deve retornar ao modo 'hub', a menos que você tenha sobrecarregado sua tabela de endereços MAC (normalmente em torno de 8.000 endereços MAC, mas verifique os detalhes da marca / modelo). Você pode verificar o número de endereços MAC em um determinado switch Cisco com este comando:

sh mac-address-table | inc Total

Os switches tomam todas as decisões com base na tag vlan (se você os estiver usando) e no endereço mac. Se você está ficando inundado, então você precisa olhar porque o switch não está criando uma tabela de endereços mac precisa.

Você pode obter esse comportamento, no entanto, se você receber o que eu chamo de 'sangrar vlan'. Se você tiver duas portas de switch conectadas consecutivamente, mas em vlans diferentes, você poderá ver esse comportamento.

Um dispositivo com várias placas de rede também pode unir as vlans. A Microsoft tinha um "recurso" para interligar as placas de rede, de modo que suas redes sem fio e com fio fossem interligadas por instanência.

Veja a tabela do seu Mac para portas com mais de um endereço que não são uplinks para outro switch. Você também pode seguir o endereço MAC de um dos dispositivos que devem ser unicast através das tabelas MAC dos seus switches.

Nos switches da Cisco, esses comandos podem ser úteis:

sh mac-address-table | ex CPU
sh mac-address-table | ex CPU|<uplink port name>

    

Answer 3

A primeira coisa que eu verificaria seria a carga no seu switch. Se você está rodando com uma carga tão alta que não pode alternar corretamente os pacotes (na maioria dos casos isto começa a acontecer em torno da área de carga da CPU de 80-90%) ele irá falhar de volta a ser um hub, bem como o possibilidade de perder pacotes.

    

Answer 4

Embora as outras respostas pareçam mais prováveis do que você descreveu, verifique se a porta à qual você está conectado não está configurada como porta de espelho .

    

Answer 5

Este tipo de comportamento é normalmente indicativo de o comutador não ter uma entrada na sua tabela de ponte (também conhecida como tabela CAM ou tabela de endereços MAC) para o MAC de destino de uma trama. A Cisco se refere a ele como flooding unicast .

Você pode fornecer mais detalhes sobre sua topologia? Todo o tráfego "inesperado" é destinado ao mesmo host ou a vários hosts? Algum dos seus hosts usa NICs conectadas / agrupadas? É possível que o tráfego de entrada esteja sendo enviado para um endereço MAC, mas que o tráfego de saída do host esteja sendo originado de outra NIC.

EDIT: Como o tráfego espúrio é limitado a alguns MACs, este pode ser um bom lugar para começar. Você pode interrogar a tabela de ponte do switch (mostrar a tabela de endereços MAC em dispositivos Cisco) e descobrir se há uma entrada para os endereços MAC de destino incorretos? Além disso, você pode confirmar qual é o valor de tempo limite para a tabela de ponte do switch?

Um caso em que eu já vi esse comportamento antes é em sub-redes onde o valor de tempo limite do ARP é definido mais alto do que o tempo limite da tabela de endereços MAC. Normalmente, quando uma entrada de ARP envelhece, uma sonda ARP é enviada. A resposta à sonda é notada pelo switch, que armazena o MAC de origem do host em sua tabela de ponte. Quando esses cronômetros são revertidos, a entrada da ponte envelhece antes da entrada do ARP. Isso significa que os roteadores / hosts em uma sub-rede sabem qual endereço MAC possui um determinado IP, mas o switch não sabe a qual porta esse MAC está conectado. Nesse caso, o switch inundará o tráfego para todas as portas dessa VLAN.

    

Answer 6

O switch deve enviar tráfego direcionado, mas nem sempre.
Todos os switches mantêm uma tabela ARP, como todos os hosts da rede.
Um simples ataque -
Se você tiver que farejar um pacote que não pertence a você em uma LAN comutada. O que você faz é gerar muitas solicitações falsas de arp e sobrecarregar a tabela ARP no switch. Quando a tabela ARP está sobrecarregada, o switch opera em um modo de HUB padrão. A superutilização da CPU pode ser responsável por um desempenho ruim, mas quase certamente acho que não para tempestades de pacotes como essa.