Supondo que seu servidor DHCP e cliente DHCP estejam conectados ao mesmo segmento de ethernet, e supondo que esse segmento de ethernet abranja vários switches L2 interconectados com vários "trunk" ( 802.1q , encontrei problemas semelhantes quando havia uma incompatibilidade entre a configuração de pelo menos um link de tronco.
Em detalhe, o ciclo interminável de DHCP-DISCOVER / DHCP-OFFER (visto do lado do servidor DHCP), deixe-me pensar que o cliente DHCP é NOT recebendo a DHCP-OFFER e, portanto, colocando novamente a mensagem DHCP-DISCOVER. Tal DHCP-DISCOVER (visto do lado do cliente DHCP) é corretamente recebido do DHCP-SERVER.
Considerando o seguinte cenário:
aconfiguraçãoincorreta/incorretadasduasportasdetroncosignificaque:
- OtráfegodaVLANXenviadopeloSWAparaoSWBaolongodotronco(oudoservidorDHCPparaoclienteDHCP)éUNTAGGED;
- OtráfegodeVLANXenviadopeloSWBparaoSWAaolongodotronco(oudoDHCP-ClientparaoservidorDHCP),éTAGGED.
- devidoàconfiguraçãodeVLANnativadaportadetroncodoSWB,oclienteDHCPnãoreceberápacotesdoservidorDHCP.
Issoémuitofácildesolucionar,sevocê"controla" o host DHCP-Client. Nesse caso, supondo eth0 é a interface de rede usada pelo host do cliente DHCP, um simples:
tcpdump -n -i eth0 ether-host <dhcp-server-mac-address>
mostrará se o cliente receber ou não a DHCP-OFFER do DHCP-SERVER.
As coisas são mais difíceis de solucionar se você puder não controlar o lado do cliente.
PS: Obviamente, os problemas acima, assim como outros argumentos relacionados, podem ser facilmente evitados usando tecnologias apropriadas (como
GVRP ,
VTP ou outra abordagem que não seja estritamente manual-config), mas ... isto está fora do escopo desta resposta