Você disse que "o relé do dhcp não está habilitado" ... mas claramente é, com base na saída do show dhcp-relay.
Tente desativá-lo explicitamente; com base nos comentários acima, eu suspeito que seu problema irá embora:)
Estamos lentamente começando a implementar o dhcp-snooping em nossos switches HP ProCurve série 2610, todos executando o firmware R.11.72. Estou vendo um comportamento estranho em que os pacotes dhcp-request ou dhcp-renew são descartados quando originados de switches "downstream" devido a "informações de relé não confiáveis do cliente".
O erro completo:
Received untrusted relay information from client <mac-address> on port <port-number>
Mais detalhadamente, temos um HP2610 de 48 portas (Switch A) e um HP2610 de 24 portas (Switch B). O switch B é "downstream" do Switch A em virtude de uma conexão DSL para uma das portas do Switch A. O servidor dhcp está conectado ao Comutador A. Os bits relevantes são os seguintes:
Alternar A
dhcp-snooping
dhcp-snooping authorized-server 192.168.0.254
dhcp-snooping vlan 1 168
interface 25
name "Server"
dhcp-snooping trust
exit
Comutador B
dhcp-snooping
dhcp-snooping authorized-server 192.168.0.254
dhcp-snooping vlan 1
interface Trk1
dhcp-snooping trust
exit
Os comutadores estão configurados para confiar tanto na porta à qual o servidor DHCP autorizado está conectado quanto no endereço IP. Isso tudo é bom para os clientes conectados ao Switch A, mas os clientes conectados ao Switch B são negados devido ao erro "information relay não confiável". Isso é estranho por algumas razões: 1) o dhcp-relay não está configurado em nenhum dos switches, 2) a rede da camada 3 aqui é plana, a mesma sub-rede. Os pacotes DHCP não devem ter um atributo modificado da opção 82.
O dhcp-relay parece estar ativado por padrão, no entanto:
SWITCH A# show dhcp-relay
DHCP Relay Agent : Enabled
Option 82 : Disabled
Response validation : Disabled
Option 82 handle policy : append
Remote ID : mac
Client Requests Server Responses
Valid Dropped Valid Dropped
---------- ---------- ---------- ----------
0 0 0 0
SWITCH B# show dhcp-relay
DHCP Relay Agent : Enabled
Option 82 : Disabled
Response validation : Disabled
Option 82 handle policy : append
Remote ID : mac
Client Requests Server Responses
Valid Dropped Valid Dropped
---------- ---------- ---------- ----------
40156 0 0 0
E, curiosamente, o agente dhcp-relay parece estar muito ocupado no Switch B, mas por quê? Tanto quanto eu posso dizer, não há razão para que os pedidos de dhcp precisem de um relay com essa topologia. E, além disso, não posso dizer por que o switch upstream está soltando solicitações dhcp legítimas para informações de relé não confiáveis quando o agente de retransmissão em questão (no Switch B) não está modificando os atributos da opção 82 de qualquer maneira.
A adição do no dhcp-snooping option 82 no Comutador A permite que o tráfego dhcp do Comutador B seja aprovado pelo Comutador A, em virtude de simplesmente desativar esse recurso. Quais são as repercussões de não validar a opção 82 do tráfego modificado de dhcp? Se eu desabilitar a opção 82 em todos os meus switches "upstream" - eles passarão o tráfego DHCP de qualquer switch downstream, independentemente da legitimidade do tráfego?
Esse comportamento é agnóstico do sistema operacional do cliente. Eu vejo isso com clientes Windows e Linux. Nossos servidores DHCP são máquinas do Windows Server 2003 ou do Windows Server 2008 R2. Eu vejo esse comportamento, independentemente do sistema operacional dos servidores DHCP.
Alguém pode lançar alguma luz sobre o que está acontecendo aqui e me dar algumas recomendações sobre como devo prosseguir com a configuração da opção 82? Eu sinto como se eu não tivesse grokked completamente os atributos de retransmissão de dhcp e opção 82.
Na verdade, o pacote no comutador A está ficando caído porque você recebeu um pacote de cliente DHCP com a opção 82 em uma porta não confiável. Esta opção-82 é inserida pelo switchB.
Acho que abaixo deve funcionar -
Ligado, comutador B - desabilite a opção 82 para que isso não insira essas opções. marque a interface-25 como confiança para permitir que o pacote do servidor DHCP flua para baixo.
Ligado, SwitchA- Você pode manter a opção 82 ativada / desativada aqui. não deveria importar. marque a porta que está conectada ao switchB como não confiável. marque a porta que está conectada ao dhcp-server como confiável.
Acho que você pode estar interpretando mal a ideia de uma porta confiável. Eu concordo que confiar apenas nas portas das quais as ofertas estão chegando é intuitivo, mas eu entendo que você precisa confiar na porta do tronco no Switch A também. Você marca as portas confiáveis que estão conectadas ao equipamento que você conhece e confia. Só porque você marca o tronco no Switch A como confiável não significa que você vai permitir que um servidor DHCP não autorizado exista no switch B. Se a configuração estiver correta, o switch B não confiará em nenhuma outra porta que o seu trunk, bem como você ainda impediu que um servidor DHCP não autorizado se sentasse no comutador B e enviava ofertas para clientes no comutador A.
Em resumo, você deve confiar em portas conectadas a seus próprios servidores DHCP e portas conectadas a outros switches que você gerencia (assim, você pode ter certeza de que não há outras portas confiáveis).Tags networking dhcp hp-procurve