Por que os switches parcialmente com falha / falha falham ao passar o DHCP?

Question

Eu notei isso várias vezes: um switch começa a se comportar de maneira estranha. Normalmente, se o switch não falhar completamente, o que tende a ser notado é que o DHCP não funciona.

Tivemos uma falha no Linksys SRW-224P hoje. Os sistemas que ainda estavam conectados funcionavam corretamente, até que chegou a hora de renovar sua concessão de DHCP. Quando a concessão expirou, eles pararam de funcionar, mas até então não conseguíamos detectar uma falha. Isso inclui os telefones PoE VoIP - eles funcionam bem até que o contrato de locação esteja terminado, quando já estão prontos.

Eu notei isso nos Linksys acima mencionados, três variedades de 3Com e, possivelmente, meia dúzia de switches mudos.

O que é sobre o DHCP que o torna sensível a switches com falha?

    

Answer 1

Talvez você esteja vendo isso da direção errada, em vez de perguntar por que o DHCP não funciona, talvez você devesse perguntar por que a comunicação baseada em TCP está funcionando em uma rede não confiável, onde há perda ou corrupção de pacotes.

A comunicação baseada em TCP deve ser confiável e o protocolo foi projetado para repetir a comunicação. Outros protocolos, como o UDP, não são confiáveis. DHCP está usando o UDP. Em uma rede típica, a maior parte do que você vê atualmente é baseada em TCP. Suas propriedades de resiliência podem ser o que permite que você continue a ter comunicação sobre hardware com falha.

    

Answer 2

Eu diria que DHCP é um pouco mais complexo do que dizer pedidos de http, mas gostaria de me debater tentando afirmar que uma maneira de descobrir se o seu comutador está quebrando é verificar se os pedidos de DHCP são bem-sucedidos através dele. Tenho certeza de que, se você olhasse para o seu tráfego VOIP real, perceberia a perda de pacotes. A perda de pacotes VOIP (UDP) pode ser perceptível em uma chamada, dependendo da porcentagem que está sendo descartada. Se alguns forem descartados, não é grande coisa, mas com as solicitações DHCP, esses pacotes são realmente importantes e, como não são retransmitidos, eles quebram a solicitação.

Pode ser útil para entender todas as coisas que o DHCP faz por você ( via Cisco ).

    

Answer 3

A capacidade de encaminhar a solicitação de ajuda bootp / dhcp?

EDIT: Ok, uma vez que eles não são switches da camada 3 (provavelmente devem ler isso um pouco mais de perto), eles provavelmente não estão envolvidos no encaminhamento de DHCP.

    

Answer 4

Eu já vi esse comportamento em dois Smart Switches da Netgear. Em ambos os casos, os switches estavam ignorando todo o tráfego de broadcast. Então as solicitações e respostas do DHCP não estavam sendo repassadas.

    

Answer 5

O DHCP não é apenas baseado em transmissão. É "Pedido" com base. Há uma conexão com a rede, depois uma solicitação para um endereço nessa rede e, em seguida, uma resposta enviada do servidor DHCP que mantém uma concessão de endereço ou relata uma falha. A solicitação é repetida no cliente internamente, enviando a solicitação a cada poucos segundos e aguardando uma resposta.

No entanto, se essa resposta não for recebida, se ela for descartada ou se simplesmente não for transmitida pelos dispositivos de comutação corretamente, você não poderá obter um endereço. Verifique se suas sub-redes estão configuradas corretamente. Tenho notado que muitos gostam de usar os bits x.0.x para manter apenas os dispositivos gerenciados estáticos (switches e impressoras), mantendo computadores e servidores no x.1.x ou de outra forma (isso é apenas um exemplo). Se você não incluir o x.0.x em seu mascaramento de sub-rede corretamente, poderá acabar com máscaras de bits que eliminam suas solicitações de dhcp ou desviam-nas.

Lembre-se de incluir essa x.0.x como o endereço inicial principal e, em seguida, prossiga para definir a sub-rede tão ampla quanto você precisar com um mascaramento que corresponda ao seu dhcp por completo; note que sume irá definir a sub-rede em relação ao servidor dhcp real, isso não é útil, ele cria vazamentos de pacotes. Se você definir seu dhcp para não distribuir a porção estática, ainda precisará defini-lo na sua sub-rede.

Se você sub-rede seu dhcp, você deve reconfigurar as máscaras, adicionando 1 à alteração do bitmask. Se você sub-rede 255.255.252.0 para a sua máscara em seu dhcp, você precisa sub-rede 255.255.251.0 em seus switches, para permitir que as solicitações de máscaras de endereço x.0.x (rotas estáticas inseridas no cliente) para levar o sinal dhcp mesmo que o resto da rede. Certifique-se de que o mascaramento de sub-rede permita que as sub-redes que precisam interagir vejam umas as outras, mesmo que apenas para passar as solicitações do DHCP pelo caminho.

Você pode separar serviços de rede em computadores com Windows (e agora com macs) definindo restrições de grupo de trabalho ou de domínio. O acesso aos serviços deve ser feito por login, não por vlan. O login pode controlar o endereço que você recebe se souber como escrever o script em seus servidores, mas isso só deve ser feito quando for absolutamente necessário. A VLAN deve funcionar apenas para ajudar uma rede de tecnologia a rastrear, rastrear e corrigir um problema seguindo o esquema de mascaramento de endereço para um local físico.

Lembre-se de que você pode unir vlans de máscaras completamente diferentes, mas isso só permite que eles se vejam do ponto de vista de rede, não de um nível de acesso. Se eles precisarem de acesso a serviços, as vlans devem ser conectadas a uma interface principal e essa interface deve conter a máscara completa contendo todas as vlans, enquanto as interfaces vlan possuem apenas a máscara principal 255.255.255.0 (ou qualquer sub-rede vlan que você colocar em frente) .

    

Answer 6

A única coisa em que consigo pensar é que o switch pode não ser capaz de atualizar seu cache ARP corretamente para refletir o IP recém-atribuído.