Fundo
Eu tenho um servidor DHCP do Windows (Server 2008 R2) distribuindo endereços para vários escopos. Um desses escopos é para alguns Mitel IP Phones. Os telefones são configurados para usar a opção dhcp 125 para obter informações de configuração. Quando um telefone é inicializado, ele não sabe qual vlan usar e, portanto, apenas obtém o vlan padrão (não marcado) de qualquer porta à qual esteja conectado. O servidor dhcp fornece uma resposta que inclui informações da opção 125 e o telefone é capaz de ler qual vlan deve usar a partir dessa resposta. O telefone então libera seu endereço original e solicita uma nova concessão dhcp usando a tag vlan correta. Os telefones também costumam ter computadores conectados a uma porta de passagem. Os pacotes dos computadores nunca são marcados e, portanto, os PCs permanecerão na vlan original (não marcada) da porta. Isso funcionou para nós por anos.
Problema e sintomas
Em algum lugar nas últimas semanas, algo mudou e não tenho certeza do quê. Os telefones continuarão funcionando enquanto não reiniciarem, o que significa que as solicitações de renovação dhcp devem ser processadas corretamente. Os telefones conectados a determinados switches podem até sobreviver a uma reinicialização. Os telefones conectados a outros switches, no entanto, falharão ao concluir o processo quando forem reinicializados. Todos os nossos telefones estão usando PoE com backup por um no-break, por isso já faz muito tempo desde que qualquer um foi reiniciado. Isso significa que não tenho ideia de quando o problema apareceu pela primeira vez. O que sei é que um telefone falhou quando reiniciou ontem e, ao solucioná-lo hoje, redefinimos o armário de distribuição. Agora nenhum dos telefones desse switch está funcionando (felizmente ainda é um número pequeno). Também sei que as coisas estavam funcionando perto do final de janeiro,
Enquanto observo a inicialização de um telefone, posso vê-lo obter o primeiro endereço com sucesso. Em seguida, ele lê com êxito as informações da opção 125, define a tag vlan correta e libera a concessão de IP original. É até capaz de receber e aceitar uma oferta na vlan correta do servidor . No entanto, é aí que as coisas param. O telefone tem uma mensagem na tela que diz " DHCP: Offer 2 ACC", mas o servidor DHCP do Windows não registrou a concessão e o telefone nunca se move. Só posso supor que o pacote DHCP REQUEST nunca chega ao servidor Windows e, portanto, o telefone está aguardando o ACK final do Windows de que está tudo bem para continuar.
Gambiarra
Finalmente consegui fazer um telefone funcionar novamente. Para fazer isso, primeiro tive que desconectar o computador. Em seguida, defino a porta do switch do telefone para ser desmarcada na vlan do telefone, sem associação na vlan do PC. O telefone agora será reinicializado corretamente. Nesse ponto, posso colocar a configuração da porta do switch de volta onde deveria estar e, desde que ninguém tente ligar para esse número enquanto estou redefinindo a porta, o telefone nunca perde o ritmo. Então eu posso reconectar o computador. Obviamente, esse não é um processo ideal, embora, como os telefones reiniciam tão raramente, poderei usá-lo para fazer as pessoas trabalharem novamente até encontrar a causa raiz. Os escritórios estão fechados agora durante a semana e, portanto, esse problema será permitido no fim de semana (não tenho chaves para escritórios individuais onde estão os telefones).
Este telefone que consertei é o telefone de serviço na sala do servidor, conectado diretamente ao nosso switch principal. É possível que o problema seja um problema com tags de roteamento ou processamento no switch central, de modo que a solução alternativa não seja eficaz nos escritórios remotos onde os pacotes são passados (marcados por) outros switches, mas ficarei muito surpreso se isso acontecer, já que sei que deve estar processando renovações dhcp e conversas telefônicas reais corretamente.
Uma diferença é que deixar a porta marcada no PC vlan significa que o telefone falha com a mensagem " DHCP: Offer 1 ACC". Preciso remover totalmente essa vlan para que isso seja bem-sucedido.
Observação: agora confirmei que a solução alternativa é eficaz em edifícios remotos. Isso me leva a suspeitar que meus dispositivos de alguma forma não estão atribuídos à vlan correta. O fato de eu ter experimentado o problema em meu comutador central e de ter ocorrido em vários locais da rede quase ao mesmo tempo indica que o comutador central pode ser o problema. Sem nada específico para ver, estou agendando uma janela de manutenção perto do final da semana para reiniciar o switch. Eu também posso atualizar o firmware.
Meio Ambiente
Nosso switch principal é um HP 5406zl. Este switch lida com o roteamento entre VLANs. O servidor DHCP do Windows está conectado diretamente ao switch. Os switches de endpoint são conectados ao switch principal por meio de SFPs de fibra, e essas portas são marcadas para todas as vlans em ambas as extremidades. O switch central configura cada vlan com uma ip helper-addressconfiguração que aponta para o nosso servidor DHCP e uma dhcp relay-option 82 replacelinha para que o servidor dhcp saiba qual escopo usar. Essas configurações e as configurações de porta nos switches de endpoint não foram alteradas em pelo menos 16 meses. Tivemos outras redefinições de switch e telefone nesse período.
A maioria dos nossos switches de endpoint são da série HP 2530. Esses interruptores parecem funcionar corretamente (telefones em 3 2530 diferentes foram reiniciados corretamente hoje). São os switches mais antigos que apresentam problemas. Temos um 3Com 4200 antigo e um 4210 que não funcionam. O telefone de serviço conectado diretamente ao switch principal mencionado anteriormente também não funcionaria.
Pergunta
Neste ponto, meu melhor palpite é que uma atualização do Windows no servidor dhcp mudou o comportamento, mas não consigo ver como. Ou possivelmente o comutador principal não está lidando com o pacote REQUEST corretamente, mas tenho certeza de que nada mudou lá e não explica por que apenas determinados comutadores de ponto de extremidade são efetuados. Como posso resolver este problema?
Atualizar:
Aqui está um trecho do log dhcp de um telefone com falha:
10,03/06/15,12:40:40,Atribuir,10.1.2.158,,08000F197844,,3189088995,0,,, 11,03/06/15,12:40:40,Renovar,10.1.2.158, ,08000F197844,,3189088995,0,,, 12,03/06/15,12:40:41,Liberação,10.1.2.158,,08000F197844,,3189088995,0,,, 15,03/06/15,12: 40:45,NACK,10.1.2.154,,08000F197844,,0,6,,, 15,03/06/15,12:40:45,NACK,10.1.2.154,,08000F197844,,0,6,,,
Os endereços 10.xxx são a vlan do PC (essa escolha é anterior a mim neste local). Os telefones devem obter esse tipo de endereço primeiro, então isso é esperado. No entanto, após a mensagem de lançamento, também espero encontrar uma oferta para um endereço no intervalo 192.168.16.x, porque posso ver no telefone que uma oferta foi aceita (a menos que eu esteja interpretando mal "ACC"). É interessante que nunca vi o servidor tentar emitir um endereço como esse, mesmo que o telefone pense que recebeu um.
Considerei a ideia de que há um servidor dhcp desonesto na rede (ele fornece um endereço antes do servidor Windows, mas sem as opções dhcp necessárias para o telefone continuar), mas isso não explica por que os telefones funcionam se e somente se Eu removo completamente qualquer caminho para a vlan do PC. Vou testar de qualquer maneira pela manhã conectando meu laptop a uma porta definida para o telefone vlan, mas se alguém tiver uma explicação melhor nesse meio tempo, adoraria ouvi-la.
Aqui está uma cópia da configuração do switch:
Corrigi o problema hoje removendo a tag vlan para o telefone vlan na porta que conecta ao nosso servidor dhcp. É muito estranho para mim que isso tenha funcionado, já que outros sistemas que usam um esquema semelhante (também conhecido como Wifi SSIDs usando 802.1q) exigem a tag ou os clientes não podem obter endereços. Funcionou, então não vou procurar muito, mas estaria interessado em ver respostas com teorias sobre por que é assim.
Você deve considerar a execução de uma captura de pacote em ambos os lados do(s) switch(es) problemático(s) e, em seguida, revisar isso no Wireshark. Isso poderá dizer a você 1) se o tráfego está sendo interceptado por um servidor DHCP não autorizado (com base no endereço MAC) e 2) se algo está sendo danificado ou descartado (por exemplo, talvez você precise de retransmissão DHCP). Isso pode exigir espelhamento de porta ou o 3com pode suportar a captura diretamente no switch.
Se você achar que esse problema aparece novamente, verifique o tamanho do escopo do DHCP e quantas concessões estão em uso. Se as antigas concessões de DHCP não estiverem sendo destruídas, seu servidor pode pensar que não há mais endereços no pool e ser incapaz de atribuir novos endereços. Isso é verdade mesmo se não houver dispositivos respondendo na vlan. Se o escopo do DHCP for de 7 dias, pode levar até 7 dias para que você consiga uma nova concessão. Da mesma forma, alterar sua configuração resolveria o problema porque haveria um novo intervalo de endereços que poderia ser distribuído ou poderia liberar as concessões dependendo das alterações de configuração. Eu sugeriria definir o tempo de duração da concessão para algo muito baixo, como uma hora para esse escopo, se for o caso.