Joel Coel's questions

Tenho um novo host Server 2022 Hyper-V que terá (inicialmente) 6 convidados. Ele tem duas NICs que quero unir para conectar ao switch físico para desempenho e confiabilidade.

Pelo que entendi, há duas maneiras de fazer isso:

1. A velha e decadente equipe LACP no nível do sistema operacional de 2012.
2. O novo Switch Embedded Teaming para o Server 2016 e versões posteriores.

Consegui fazer ambas as opções funcionarem na configuração e nos testes até agora, mas tudo o que li diz que eu deveria preferir fortemente a opção 2.

Aqui está o problema: pelo que vi para a opção 2, o Hyper-V faz balanceamento de carga vinculando MACs de diferentes convidados a diferentes portas físicas. Isso significa que uma VM nunca terá mais largura de banda do que você veria em uma única porta. E, de fato, a interface visível nos convidados ao usar essa opção parece uma única NIC com a velocidade de uma das NICs de host individuais.

Isso está errado para minha configuração, porque um dos convidados não é como os outros. É a principal razão para o hardware físico existir e deve ver a maior parte do tráfego. Sei que com a maioria das opções de equipe nenhuma sessão pode exceder a velocidade de uma única porta, mas também espero que este servidor suporte muitas sessões.

Então a questão:

Perdi algo para o Switch Embedded Teaming fazer melhor uso das portas disponíveis e, se sim, o que preciso fazer para corrigir isso? Ou, alternativamente, essa é uma situação em que devo usar a opção de teaming mais antiga?

Estou me preparando para enviar um novo conjunto de usuários para autenticação MFA com Entra/AD FS e estou enfrentando alguns problemas (felizmente, ainda durante a fase de testes!)

O ambiente é um servidor AD/AD FS local (2019), sincronizado com Entra com P1 para oferecer suporte a MFA. Isso está funcionando para a maioria dos usuários. Quando os usuários ativam uma nova conta, eles são redirecionados para o processo MS "ProofUp" em mysignins.micrsoft.com/security-info de acordo com a documentação e podem concluir o registro/autenticação. Isso permite que eles inicialmente ignorem o requisito de MFA para acessar a página "mysignins.micrsoft.com/security-info" até que fatores adicionais sejam fornecidos, como deveria.

No entanto, agora temos uma classe de usuários que vêm até nós e já possuem o aplicativo Microsoft Authenticator e já entraram no aplicativo com nossa "conta corporativa ou escolar", mas ainda não terminaram de registrar o aplicativo para MFA com nosso locatário do Azure/Entra. Notavelmente, o aplicativo NÃO aparece na seção Métodos de autenticação para o usuário no console de administração do Entra. Estes são estudantes (somos uma universidade) que usaram o aplicativo para fazer MFA com um serviço externo antes de solicitarmos MFA de estudante, e agora não usamos mais esse serviço.

Esses usuários NÃO conseguem carregar a página mysignins.micrsoft.com/security-inf ProofUp e, em vez disso, entram em um loop de redirecionamento onde voltam continuamente ao nosso site AD FS dizendo que precisam concluir o registro de MFA.

Uma chave é que em nenhum momento o usuário verá uma mensagem de erro real. Eles simplesmente não conseguem passar da página do AD FS solicitando o registro de tokens MFA. Qualquer coisa que fizerem para seguir em frente irá redirecioná-los de volta a este ponto. Além disso, os logs de login para esses usuários no Entra mostrarão apenas resultados de "Sucesso", a menos que eles realmente insiram uma senha incorreta, e mesmo estes são de antes de ativarmos o requisito de MFA para o usuário (ou depois de liberá-los devido a falha).

ATUALIZAR :

Agora posso recriar isso para um novo usuário de teste sob demanda com estas etapas:

1. Crie um usuário no Active Directory local
2. Certifique-se de que o usuário ainda NÃO seja necessário para MFA e deixe-o sincronizar com o Azure AD/Entra
3. Faça um teste de dispositivo móvel que ainda NÃO esteja registrado no Entra
4. Instale o aplicativo MS Authenticator novo no dispositivo (remova-o completamente primeiro e depois reinstale-o se já estiver lá, para que todos os dados locais de testes anteriores sejam apagados)
5. Faça login no aplicativo Authenticator como uma conta de trabalho/escola com as credenciais de usuário criadas na etapa 1
6. Feche e saia do aplicativo.
7. Defina o usuário para exigir MFA para uma de nossas partes confiáveis ​​do AD FS (fazemos isso aqui adicionando uma associação de grupo no AD)
8. Faça com que o usuário tente acessar um aplicativo protegido

O importante foi que as etapas 5 e 6 aconteceram antes da etapa 7.

O AD FS agora determinará corretamente as necessidades do usuário para concluir a MFA; ele mostrará uma mensagem de acordo com a documentação e tentará redirecioná-los para a página Entra ProofUp após 5 segundos. Mas a página de prova não permitirá o acesso e os redirecionará imediatamente de volta ao AD FS para repetir o ciclo. O usuário é impedido de concluir o processo ProofUp.

Usar o botão "Exigir novo registro de autenticação multifator" mostrado abaixo para o usuário no console administrativo não funciona para resolver isso.

Até agora, tenho duas maneiras de levar esses usuários adiante:

1. Insira manualmente um fator adicional para eles (como um telefone celular). Em breve traremos várias centenas de usuários adicionais dessa forma, onde não tenho necessariamente esses números de telefone celular. Eu preciso de algo melhor.
2. Altere a política de controle de acesso do aplicativo Office 365 especificamente para não exigir MFA. Isso não é tão ruim quanto parece à primeira vista, porque usamos o Google Workspace para e-mail e a maioria dos serviços de documentos, mas obviamente também não é bom e não é algo com o qual eu queira viver a longo prazo.

Como posso limpar o registro incompleto do aplicativo Authenticator para esses usuários ou permitir que eles avancem com o registro MFA?

Não posso ser a primeira pessoa a se deparar com isso, porque pode acontecer com qualquer pessoa que pule uma etapa do processo normal e tente adicionar o aplicativo Authenticator muito cedo.

Primeiro, algumas informações básicas.

Hoje, se você estiver em um ambiente AD predominantemente Windows Server com apenas um pequeno número de servidores Linux, você terá a opção de autenticar nos servidores via SSH:

1. Gerencie os servidores Linux via SSH com autenticação de certificado (o modo normal do Linux)
2. Junte os servidores Linux ao seu domínio AD (realm+sssd) e gerencie-os via SSH com autenticação de nome de usuário/senha

O problema é que a opção 1 deixa os administradores gerenciarem um conjunto separado de credenciais do resto do ambiente, e a opção 2 faz com que os administradores forneçam senhas diretamente aos servidores remotos pela rede antes que as máquinas se identifiquem totalmente.

No mundo Windows, isso é resolvido (pelo menos para RDP, que eu sei que deve ser evitado) por meio da autenticação em nível de rede. Uma versão simplificada do processo é assim:

1. O usuário começa a se conectar ao computador remoto
2. O computador remoto responde com token de conta de computador AD
3. O computador local valida o token, vê o suporte do NLA e mostra uma caixa de diálogo de credenciais ao usuário
4. O usuário completa a caixa de diálogo com credenciais
5. O computador local valida credenciais com o controle de domínio (não o computador remoto)
6. O DC fornece ao computador local um token de autenticação
7. O computador local apresenta o token ao computador remoto
8. O computador remoto valida o token no domínio
9. Em caso de sucesso, o usuário terá permissão para acessar o computador remoto.

Na verdade, o processo pode ser ainda mais simples, onde o token de autenticação existente criado para o usuário quando ele fez login pela primeira vez no computador local já pode ser usado.

Este é um processo complexo e certamente cometi erros ao descrevê-lo. A questão é que o token de autenticação substitui o certificado da história do Linux, de modo que o usuário nunca forneça credenciais reais para uma máquina potencialmente desconhecida. Além disso, a confiança de todas as partes no controlador de domínio confiável torna as coisas ainda melhores do que a história do Linux, porque o usuário não precisa gerenciar seus próprios certificados, mesmo através de seu próprio software (em vez disso, é o software fornecido para eles).

Agora, a pergunta. Existe uma maneira de obter algo semelhante para autenticar uma sessão SSH em um servidor Linux associado ao AD, onde o servidor nunca vê as credenciais do usuário, mas a experiência do usuário ainda é a validação de credenciais nativas do Windows?

Temos um domínio AD (ainda no local) que oferece suporte a uma biblioteca, entre outras coisas. Essa biblioteca tem vários computadores públicos e esses computadores públicos estão em sua própria UO no Active Directory. Também temos um publiclogin de convidado genérico que nossos bibliotecários podem usar para dar aos convidados externos acesso às máquinas.

Quero limitar esta conta — e apenas esta conta — para que ela possa acessar apenas computadores na PublicComputersUO.

Temos muitos outros usuários que também devem conseguir fazer login nesses computadores e em outros.

Estou ciente do Log On To...botão em um objeto User no AD, mas este é um ajuste ruim, pois esses computadores vêm e vão. A associação OU é mantida por outros motivos, mas se precisarmos usar esse botão toda vez que um computador se mover, ele rapidamente ficará desatualizado.

As partes relevantes da nossa hierarquia AD são assim:

Domain Root > InstitutionComputers > Library > PublicComputers
            > ServiceAccounts > public
            > Users (group) > {ManyOtherUsers}
            > OtherOU > {ManyOtherUsers}

Como posso fazer isso?

Eu tentei definir uma política Negar Logon no nível do domínio para incluir a conta pública e, em seguida, outra política Negar Logon no nível OU mais específico que não inclui a conta.

Ao testar, isso funciona em algumas máquinas, mas outras bloquearão o login do usuário público. , mas confirmei que a máquina é membro da UO correta. Além disso, gpresultmostra ambas as políticas. (Estou adicionando essas informações à pergunta também), então sei que a política mais específica está correspondendo a esses computadores. Isso continua acontecendo mesmo depois de executar gpupdate /forcee reiniciar o computador.

Acontece que eu tinha uma concepção errada de como "imposto" funciona na Diretiva de Grupo, onde é mais como css !important vs ativado/desativado. Desmarcar "imposto" permitiu que as regras de precedência documentadas funcionassem, enquanto ainda aplicavam todas as políticas.

Temos um funcionário que está prestes a mudar de função. Eles estão se mudando para outro estado, e estamos acomodando isso permitindo que eles mudem para uma posição remota. Após a mudança, o funcionário retornará ao local apenas algumas vezes por ano, com potencialmente até 8 meses entre as visitas.

Gostaríamos de permitir que o funcionário continue usando seu laptop atual associado ao domínio pelo restante de sua vida útil. No entanto, este laptop foi provisionado com o Windows Enterprise. Não tenho nenhuma chave MAK para Enterprise Edition no Volume Licensing Service Center (somente Professional, embora sejamos licenciados para Enterprise) e não fornecemos acesso VPN ou similar para permitir a ativação do KMS remotamente.

Os outros funcionários em funções semelhantes (há apenas dois no momento) foram acomodados instalando manualmente o Professional Edition em seus laptops quando foram contratados pela primeira vez, em vez de provisionar por meio de nossa imagem WIM, para que pudéssemos usar chaves MAK. (Isso já era irritante por si só!) O novo problema está fazendo a transição de um funcionário existente sem a oportunidade de reconstruir a máquina.

Como posso manter o Windows satisfeito durante os três anos restantes de vida útil deste laptop?

Eu tenho uma VM CentOS 6.9 existente em execução no Hyper-V no Windows Server 2008 R2. Desejo migrar esta máquina para uma nova instalação do Windows Server 2016. Esta é a última VM que me permitirá desligar o servidor antigo.

Meu problema é que o adaptador de rede eth0 não foi encontrado no novo servidor. O problema é ainda mais complicado porque a VM para durante a inicialização tentando montar um compartilhamento cifs. A verificação do Google mostra outras reclamações sobre os drivers do adaptador de rede ausentes, mas as soluções alternativas normais não são úteis para mim devido aos problemas de inicialização.

Esperei mais de 8 minutos para que a montagem cifs chegasse ao tempo limite e a VM continuasse a inicializar. Nesse ponto, eu estava correndo contra o final da minha janela de manutenção e, portanto, tive que desistir e reiniciar a VM no servidor antigo.

Receio ter que esperar até poder planejar uma janela de manutenção mais longa que permita tempo para desabilitar a montagem cifs na VM existente, para que eu possa solucionar o problema do adaptador de rede na VM migrada antes de reativar a montagem cifs. Pode levar vários meses até que uma janela como essa se abra para mim.

Alguma ideia para uma correção que eu possa realizar durante uma janela semanal de 1 hora, lembre-se de que precisarei permitir cerca de 20 minutos para apenas copiar o arquivo vhd de 180 GB para o novo servidor?

Estou redefinindo um servidor Dell T430. Possui um H730 conectado a alguns discos para o SO e armazenamento. Ele também tem um H330, que estou tentando usar para conectar uma unidade de fita Tandberg HH LTO4 mais antiga.

Infelizmente não estou tendo muita sorte.

Não consigo ver a unidade no Gerenciador de dispositivos do Windows (Server 2012 R2). Não há nada listado em "Outros dispositivos". Além disso, se eu entrar no UEFI/BIOS na inicialização, posso acessar a configuração do controlador H330, mas também não consigo encontrar nenhuma evidência de que ele veja a unidade.

A unidade tem poder. A unidade de fita possui um conector SAS e um conector molex de 4 pinos mais antigo. Se eu usar apenas o conector SAS (que inclui as partes de dados e energia, e posso rastrear toda a energia até a fonte de alimentação), a unidade parece não ligar quando eu inicializo a máquina. Esta fonte de alimentação neste servidor não possui conectores de alimentação molex, mas se eu usar um adaptador de um conector de alimentação SATA, posso fazer com que a unidade seja ligada quando ligo a máquina. A luz verde "pronto" pisca por um tempo e depois fica sólida.

Esta unidade estava funcionando bem há apenas duas semanas, mas estou prestes a arrancar os cabelos para que este servidor a reconheça. Alguma ideia?

Atualização: agora também tentei conectar diretamente ao controlador S130 na placa-mãe, usando todos os três modos (AHCI, RAID e ATA), e nenhum desses modos detectará a unidade.

Estou tentando usar o System Center Configuration Manager 2012 para atualizar um programa existente instalado na maioria dos nossos computadores. O programa usa um instalador InstallShield. Somos novos no SCCM aqui, e este programa existe desde muito antes de termos o SCCM disponível.

A nova versão do programa e o instalador não têm nada embutido que eu possa encontrar para detectar ou remover versões antigas. Se você apenas executar o novo instalador sem remover a versão antiga do programa, as coisas parecem boas por um tempo, mas eventualmente você começa a encontrar coisas que não estão certas. O fornecedor recomenda remover manualmente a versão antiga antes de instalar a nova.

Já posso usar o SCCM para implantar a nova versão em uma estação de trabalho limpa. No entanto, neste momento não consigo remover com êxito a versão antiga.

Depois de fazer muita pesquisa, cheguei ao ponto em que gravei um arquivo de resposta para o InstallShield. Usei um arquivo MSI fictício para criar um modelo de instalação para o programa antigo. Em seguida, editei as propriedades de detecção no SCCM para localizar com precisão o programa antigo. Alterei o programa de instalação para um comando fictício que apenas sai e procurei o comando de desinstalação do programa no registro do Windows.

Neste ponto, se eu criar uma implantação de desinstalação do SCCM para este aplicativo fictício, ele detectará corretamente se o programa está instalado ou não. O Centro de Software em minhas estações de trabalho mostrará se está instalado ou não, e a porcentagem de conclusão mostrada no SCCM é precisa. Também posso fazer com que o desinstalador execute scripts arbitrários, desde que todo o script caiba no Uninstall program:campo da guia Programas do tipo de implantação do SCCM para esse aplicativo. Eu só tenho que colocar o comando com algo como cmd /d /c"command goes here".

Se eu editar o comando de desinstalação para o programa não precisar de aspas e colocá-lo dentro dessa sintaxe de comando, posso ver pelo Process Explorer que o desinstalador inicia, mas está oculto em uma área de trabalho privada para a conta do sistema local, onde será espere pela entrada que nunca vem. Parece que preciso informar sobre o arquivo de resposta para concluir a instalação. No entanto, isso apresenta dois problemas.

O primeiro problema é que, se não usar a cmd /d /c"..."sintaxe, não consigo ver se o programa de desinstalação é iniciado, mas se eu usar a sintaxe, não posso incluir o arquivo de resposta, porque ele deve ser colocado entre aspas. Não há como escapar das aspas no programa de desinstalação: campo que preciso usar.

Mesmo se eu contornar esse problema, agora preciso saber como enviar o arquivo de resposta para sistemas individuais. Pelo que vi, não posso usar um compartilhamento de rede para isso, porque o desinstalador será executado como uma conta do sistema local que não terá permissões para nenhum recurso de rede. Se eu pudesse enviar arquivos aleatórios para os computadores, também poderia enviar um script de desinstalação mais complicado... mas isso também deixaria artefatos que ainda preciso de uma maneira de remover.

Já gastei muito tempo com isso e pareço estar batendo em uma parede de tijolos. InstallShield e SCCM são amplamente usados. Certamente não é tão difícil? o que estou perdendo?

Eu tenho uma VM convidada em uma máquina Windows Server 2012 R2 executando o Hyper-V. Atualmente, o convidado está usando a vlan nativa (vlan ID 1). Posso me comunicar com o convidado do host e da rede. No entanto, o convidado é um controlador de wlan Zebra/Motorola VX9000 que também precisará lidar com o tráfego nas IDs de vlan 10 e 15. A porta do switch usada pelo host não está marcada na vlan 1 e atualizei a porta para também ser marcada nas vlans 10 e 15. Também emito o seguinte comando via powershell:

Set-VMNetworkAdapterVlan -VMName MyGuest -Trunk -AllowedVlanIdList "10,15" -NativeVlanId 1

Infelizmente, depois de executar este comando, perco minha capacidade de me comunicar com o convidado. Se eu abrir o console do Hyper-V para o convidado, ele não terá acesso à rede. Tentar fazer ping do convidado do host ou de outros locais na rede resulta em uma Destination host unreachablemensagem.

Posso "consertar" retornando o adaptador ao modo não marcado:

Set-VMNetworkAdapterVlan -VMName MyGuest -Untagged

Agora posso me comunicar com o hóspede novamente, mas isso não resolve nada. Eu ainda preciso desse convidado para poder lidar com o tráfego nas vlans 10 e 15.

Não entendo porque isso acontece. Os pacotes não marcados eram vlan ID 1 antes de alternar para o modo de tronco. Não deveria ainda ser assim agora? Como posso fazer com que esse convidado se comunique em todas as vlans de que preciso?

O melhor que recebo da mensagem de erro que vejo ao executar o ping é semelhante ao que eu veria se não houvesse rota. Preciso emitir um comando separado para criar uma rota para essas redes depois de definir a porta como tronco (talvez no host)?

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:

http://pastebin.com/veXjCRXu