Solucionando Problemas: DHCP em ambientes com VLANs (PT-BR)

Solucionando Problemas: DHCP em ambientes com VLANs (PT-BR)

Este artigo foi originalmente publicado aqui. O objetivo de disponibilizar este artigo no TechNet Wiki é para que a comunidade contribua com novos cenários e também faça as devidas inclusões para atualizar o mesmo para o Windows Server 2008.



Resumo
Este artigo tem como objetivo abordar cenários comuns de implementações do serviço DHCP em um servidor Windows Server 2003 rodando em um ambiente com VLAN, quais os principais problemas e como fazer o diagnóstico

Observação importante

Este artigo técnico foi escrito por um membro da comunidade brasileira e não é um documento oficial Microsoft. A Microsoft Corporation e a Microsoft Brasil não fornecem quaisquer garantias, explícitas ou expressas, sobre o conteúdo deste documento, nem concorda necessariamente com opiniões pessoais dos colunistas, bem como não se responsabiliza por danos causados por procedimentos técnicos descritos nestas colunas.

Este artigo aplica-se aos seguintes produtos e tecnologias:

  • Windows Server 2003
  • Serviço de DHCP
  • Tecnologia de redes virtuais (VLAN)

Introdução

O tema de DHCP pode parecer algo simples, já maduro e que nunca se terá problemas. Talvez por isso não exista um preocupação maior quando há planos de se fazer uma mudança de infra-estrutura, o que muitas vezes é normal. Muitas vezes também existe a pré-disposição de dizer que o problema está no servidor, muitos clientes ao ligarem para o PSS com problemas de DHCP ficam surpresos com o resultado do diagnóstico

Lembrando Conceitos

Primeiramente é importante lembrar o que é uma VLAN e como funciona.

LANs Virtuais

• Uma VLAN é uma segmentação no nível 3 (camada de rede do modelo OSI), através desta segmentação conseguimos criar vários domínios de broadcast onde um domínio de broadcast não se comunica diretamente com outro.

• Para que uma VLAN se comunique com outra é necessário que exista um equipamento de nível 3 que faça o roteamento dos pacotes. Este equipamento poderá ser um roteador ou uma Switch de nível 3;

Serviço DHCP

Quando temos um DHCP na rede, os clientes irão obter IP inicialmente enviando um broadcast UDP na porta 67 que é chamado de DHCPDISCOVER. O pacote conterá um cabeçalho DHCP semelhante ao mostrado abaixo:

 

Bootstrap Protocol

    Message type: Boot Request (1)

    Hardware type: Ethernet

    Hardware address length: 6

    Hops: 0

    Transaction ID: 0x711eb7fe

    Seconds elapsed: 0

    Bootp flags: 0x0000 (Unicast)

        0... .... .... .... = Broadcast flag: Unicast

        .000 0000 0000 0000 = Reserved flags: 0x0000

    Client IP address: 0.0.0.0 (0.0.0.0)

    Your (client) IP address: 0.0.0.0 (0.0.0.0)

    Next server IP address: 0.0.0.0 (0.0.0.0)

    Relay agent IP address: 0.0.0.0 (0.0.0.0)

    Client MAC address: (00:03:ff:3b:2b:29)

    Server host name not given

    Boot file name not given

    Magic cookie: (OK)

    Option 53: DHCP Message Type = DHCP Discover

    Option 116: DHCP Auto-Configuration (1 bytes)

    Option 61: Client identifier

        Hardware type: Ethernet

        Client MAC address: (00:03:ff:3b:2b:29)

    Option 12: Host Name = "XPCLIENT"

    Option 60: Vendor class identifier = "MSFT 5.0"

    Option 55: Parameter Request List

        1 = Subnet Mask

        15 = Domain Name

        3 = Router

        6 = Domain Name Server

        44 = NetBIOS over TCP/IP Name Server

        46 = NetBIOS over TCP/IP Node Type

        47 = NetBIOS over TCP/IP Scope

        31 = Perform Router Discover

        33 = Static Route

        Unknown Option Code: 249

        43 = Vendor-Specific Information

    End Option

    Padding

 

Os campos em vermelho são campos que fiz questão de enfatizar para que tenhamos em mente que já no primeiro pacote existe uma identificação do lado do cliente, porém o pacote é um broadcast. O cabeçalho IP tem como endereço de destino o IP 255.255.255.255.

O servidor ao ouvir esta requisição vai então fazer uma oferta, neste momento teremos um envio em formato de broadcast UDP na porta 68 chamado de DHCPOFFER. Este pacote vai conter as opções que foram configuradas no servidor DHCP de forma que as mesmas sejam oferecidas para o cliente, conforme mostrado abaixo:

 

Bootstrap Protocol

    Message type: Boot Reply (2)

    Hardware type: Ethernet

    Hardware address length: 6

    Hops: 0

    Transaction ID: 0x711eb7fe

    Seconds elapsed: 0

    Bootp flags: 0x0000 (Unicast)

        0... .... .... .... = Broadcast flag: Unicast

        .000 0000 0000 0000 = Reserved flags: 0x0000

    Client IP address: 0.0.0.0 (0.0.0.0)

    Your (client) IP address: 192.168.0.220 (192.168.0.220)

    Next server IP address: 192.168.0.10 (192.168.0.10)

    Relay agent IP address: 0.0.0.0 (0.0.0.0)

    Client MAC address: 00:03:ff:3b:2b:29

    Server host name not given

    Boot file name not given

    Magic cookie: (OK)

    Option 53: DHCP Message Type = DHCP Offer

    Option 1: Subnet Mask = 255.255.255.0

    Option 58: Renewal Time Value = 4 days

    Option 59: Rebinding Time Value = 7 days

    Option 51: IP Address Lease Time = 8 days

    Option 54: Server Identifier = 192.168.0.10

    Option 3: Router = 192.168.0.1

    Option 6: Domain Name Server = 192.168.0.10

    Option 44: NetBIOS over TCP/IP Name Server = 192.168.0.10

    Option 46: NetBIOS over TCP/IP Node Type = H-node

    End Option

    Padding

 

Observe que o número de cada opção é algo de extrema importância, pois é através dele que é possível identificar o que tal opção significa.

OBS: Para uma lista completa  das opções DHCP disponíveis, ver o site do IANA.

O cliente então vai enviar um DHCPREQUEST que neste primeiro momento continua sendo através de broadcast (pois o cliente ainda não tem ainda um IP). Note que caso exista vários servidores DHCP na mesma rede todos os servidores iram receber este pacote, mas apenas o servidor contido na opção 54 é que poderá enviar o próximo pacote, que é a confirmação do aluguel.

 

Bootstrap Protocol

    Message type: Boot Request (1)

    Hardware type: Ethernet

    Hardware address length: 6

    Hops: 0

    Transaction ID: 0x711eb7fe

    Seconds elapsed: 0

    Bootp flags: 0x0000 (Unicast)

        0... .... .... .... = Broadcast flag: Unicast

        .000 0000 0000 0000 = Reserved flags: 0x0000

    Client IP address: 0.0.0.0 (0.0.0.0)

    Your (client) IP address: 0.0.0.0 (0.0.0.0)

    Next server IP address: 0.0.0.0 (0.0.0.0)

    Relay agent IP address: 0.0.0.0 (0.0.0.0)

    Client MAC address: 00:03:ff:3b:2b:29

    Server host name not given

    Boot file name not given

    Magic cookie: (OK)

    Option 53: DHCP Message Type = DHCP Request

    Option 61: Client identifier

        Hardware type: Ethernet

        Client MAC address: 00:03:ff:3b:2b:29

    Option 50: Requested IP Address = 192.168.0.220

    Option 54: Server Identifier = 192.168.0.10

    Option 12: Host Name = "XPCLIENT"

    Option 81: FQDN

        Flags: 0x00

            0000 .... = Reserved flags: 0x00

            .... 0... = Server DDNS: Some server updates

            .... .0.. = Encoding: ASCII encoding

            .... ..0. = Server overrides: No override

            .... ...0 = Server: Client

        A-RR result: 0

        PTR-RR result: 0

        Client name: XPCLIENT.ctest.com

    Option 60: Vendor class identifier = "MSFT 5.0"

    Option 55: Parameter Request List

        1 = Subnet Mask

        15 = Domain Name

        3 = Router

        6 = Domain Name Server

        44 = NetBIOS over TCP/IP Name Server

        46 = NetBIOS over TCP/IP Node Type

        47 = NetBIOS over TCP/IP Scope

        31 = Perform Router Discover

        33 = Static Route

        Unknown Option Code: 249

        43 = Vendor-Specific Information

    End Option

 

O servidor então vai enviar um DHCPACK (via broadcast também), concordando com o aluguel de endereço IP e reservando aquele IP na sua tabela de endereços.

 

Bootstrap Protocol

    Message type: Boot Reply (2)

    Hardware type: Ethernet

    Hardware address length: 6

    Hops: 0

    Transaction ID: 0x711eb7fe

    Seconds elapsed: 0

    Bootp flags: 0x0000 (Unicast)

        0... .... .... .... = Broadcast flag: Unicast

        .000 0000 0000 0000 = Reserved flags: 0x0000

    Client IP address: 0.0.0.0 (0.0.0.0)

    Your (client) IP address: 192.168.0.220

    Next server IP address: 0.0.0.0 (0.0.0.0)

    Relay agent IP address: 0.0.0.0 (0.0.0.0)

    Client MAC address: 00:03:ff:3b:2b:29

    Server host name not given

    Boot file name not given

    Magic cookie: (OK)

    Option 53: DHCP Message Type = DHCP ACK

    Option 58: Renewal Time Value = 4 days

    Option 59: Rebinding Time Value = 7 days

    Option 51: IP Address Lease Time = 8 days

    Option 54: Server Identifier = 192.168.0.10

    Option 1: Subnet Mask = 255.255.255.0

    Option 81: FQDN

        Flags: 0x00

            0000 .... = Reserved flags: 0x00

            .... 0... = Server DDNS: Some server updates

            .... .0.. = Encoding: ASCII encoding

            .... ..0. = Server overrides: No override

            .... ...0 = Server: Client

        A-RR result: 255

        PTR-RR result: 255    Option 3: Router = 192.168.0.1

    Option 6: Domain Name Server = 192.168.0.10

    Option 44: NetBIOS over TCP/IP Name Server = 192.168.0.10

    Option 46: NetBIOS over TCP/IP Node Type = H-node

    End Option

 

Como você pode ver, todos pacotes são em formato de broadcast, desta forma, quando temos uma segmentação no nível 3, tais pacotes não são transmitidos para o outro lado da rede, daí vem a necessidade do uso de um DHCP Relay Agent. O DHCP Relay Agent é responsável por ouvir estes broadcasts em um lado da rede e encaminhar para o outro lado da rede. Esta função pode ser feita por um servidor Windows que esteja sendo utilizado como um roteador, ou também pode ser feita pelo roteador em si. Para isso o roteador precisa ser compatível com a RFC 1542.

 

Super Escopo

O super escopo permite que você tenha múltiplos endereçamentos IPs dentro do mesmo segmento físico. Veja bem: vários IPs (independente de serem ou não da mesma classe) dentro do mesmo segmento de nível 3. Algumas empresas tiram proveito do uso do super escopo para expandir a quantidade de computadores existentes no mesmo segmento porém usando diferente intervalos de endereçamento IP.

Agora que temos estes conceitos definidos será possível ir adiante e explicar o cenário.

 

Cenário

O cenário para este artigo é baseado no ambiente abaixo:



Veja que temos um servidor DHCP na VLAN1, este servidor está conectado diretamente na porta da Switch de nível 3. A VLAN 1 por sua vez pertence a faixa de IP 192.168.0.0/24, alguns clientes também estão localizados na VLAN 1 porém estão conectados em uma switch de nível 2. Temos estações clientes nas VLAN 3 (faixa de IP 192.168.2.0/24) e na VLAN 2 (192.168.1.0/24).

A partir deste cenário iremos desenvolver cinco possíveis problemas que podem ocorrer neste ambiente caso a configuração não esteja 100% correta.

 

Problema 1 – Clientes da VLAN 2 não obtém Endereço IP

O problema 1 diz respeito a clientes da VLAN 2 que não conseguem receber IP de maneira alguma. Este problema não acontece nas VLANs 1 nem na 3.

 

Obtendo Dados

O plano de ação para coleta dos dados neste caso é:

  • Instalar o network monitor no servidor e no cliente da VLAN 2;
  • Iniciar a captura em ambos lados e no lado do cliente executar o comando ipconfig /renew

Neste momento o comportamento esperado é que o servidor ouça a requisição de IP vinda através da Switch de nível 3, pois neste caso a switch está configurada para ser o DHCP Relay Agent. Então o pacote de DHCP Offer teria que conter a informação correta do relay, que neste caso é:

 

    Your (client) IP address: 192.168.1.200

    Next server IP address: 192.168.0.10

    Relay agent IP address: 192.168.1.1

 

 

Analisando

Porém após a captura de pacotes no lado do servidor e do cliente é possível verificar que no lado do cliente o IP ofertado é:

 

    Your (client) IP address: 0.0.0.0

    Next server IP address: 0.0.0.0

    Relay agent IP address: 0.0.0.0

 

Analisando o resultado do network monitor no lado do servidor podemos ver que não existe nenhum pacote DHCPDISCOVER vindo daquele segmento.

 

Conclusão

Bem, neste está fácil de deduzir que a Switch de nível 3 não está fazendo corretamente o papel de relay. Em alguns casos o cliente diz: “Mais eu configurei correto, tanto é que as outras VLANs estão funcionando”. Para este tipo de questionamento nada melhor que o resultado da captura, se o servidor não está ouvindo discover que vem daquele segmento ele não conseguira ofertar. Isso poderá sim ser a Switch, vejamos como o exemplo uma configuração básica de relay em um equipamento Cisco:

interface Ethernet2

ip address 192.168.1.1 255.255.255.0

ip helper-address 192.168.0.10

 

Observe que o comando IP helper-address reside na interface Ethernet2, a interface 2 é justamente a interface que está ligada a VLAN2. A configuração de relay aponta para o servidor 192.168.0.10 como DHCP. Em suma, se este comando não for digitado em cada interface da Switch de nível 3 não haverá relay para aquele segmento.

 

OBS: Os comandos e sintaxe para configuração de roteadores/switches deste exemplo podem variar de acordo com o equipamento, modelo e versão de sistema operacional do fabricante. Para maiores exemplos de configuração de Switches Cisco como DHCP Relay utilize o artigo “Cisco IOS DHCP Relay Agent Support”.

Problema 2 – Clientes da VLAN 2 obtém Endereço IP Incorreto

O problema 2 diz respeito a clientes da VLAN 2 não conseguirem obter endereço IP designados para VLAN 2. Como você pode ver na figura anterior o endereçamento da VLAN 2 é 192.168.1.0/24. Os clientes da VLAN 2 recebem IP designados para a VLAN 1, que por sua vez é 192.168.0.0/24.

 

Obtendo Dados

O plano de ação para coleta dos dados neste caso é:

  • Instalar o network monitor no servidor e no cliente da VLAN 2;
  • Iniciar a captura em ambos lados e no lado do cliente executar o comando ipconfig /renew

 

Neste momento o comportamento esperado é que o servidor ouça a requisição de IP vinda através da Switch de nível 3, pois neste caso a switch está configurada para ser o DHCP Relay Agent. Então o pacote de DHCP Offer teria que conter a informação correta do relay, que neste caso é:

    Your (client) IP address: 192.168.1.200

    Next server IP address: 192.168.0.10

    Relay agent IP address: 192.168.1.1

 

 

Analisando

Porém após a captura de pacotes no lado do servidor e do cliente é possível verificar que no lado do cliente o IP ofertado é:

    Your (client) IP address: 192.168.0.200

    Next server IP address: 192.168.0.10

    Relay agent IP address: 192.168.0.1

 

 

Conclusão

Bem, neste caso o problema não é do servidor, o problema é da Switch. Quando o servidor DHCP recebe um DISCOVER vindo da Switch é necessário que o campo DHCP Relay contenha o IP correspondente de onde a Switch ouviu o DISCOVER. Neste caso a Switch ouviu o DISCOVER do segmento 192.168.1.0/24, mas erroneamente encaminhou o pacote com a informação de relay errada. O servidor DHCP por sua vez só fez verificar este endereço e olhar nos escopos presentes qual iria satisfazer tal requisição.

 

Problema 3 – Clientes de uma Nova VLAN não Obtém Endereço IP Correto

O problema 3 nasce a partir de uma mudança de estrutura na rede. O servidor DHCP tinha a seguinte configuração:

 

  • Super Escopo Rede Principal
    • Escopo A      
      • 192.168.0.10 – 192.168.0.254
      • Escopo B
        • 10.10.10.0 – 10.10.10.254
  • Escopo VLAN 2
    • 192.168.1.10 – 192.168.1.254
  • Escopo VLAN 3
    • 192.168.2.10 – 192.168.2.254

 

Como pode ser visto na VLAN 1 há um super escopo que contém dois tipos distintos de endereçamento IP. Isso estava funcionando normal até o dia em que o administrador de rede resolveu dividir a VLAN 1 em VLAN 1 e VLAN 4. A idéia dele era que a VLAN 1 continuasse com a faixa de endereçamento 192.168.0.0/24 e a nova VLAN 4 ficasse com a faixa 10.10.10.0/24.

Porém  que estava acontecendo na prática era que clientes das VLANs 1 e 4 estavam todos obtendo IPs da faixa 192.168.0.0/24.

 

Obtendo Dados

O plano de ação para coleta dos dados neste caso é:

  • Instalar o network monitor no servidor e no cliente da VLAN 2;
  • Iniciar a captura em ambos lados e no lado do cliente executar o comando ipconfig /renew

 

Analisando

Bem, neste caso a análise dos pacotes vai mostrar o seguinte comportamento:

    Your (client) IP address: 192.168.0.200

    Next server IP address: 192.168.0.10

    Relay agent IP address: 10.10.10.1

 

Bem, aqui é possível verificar que o endereço IP do relay está correto, então a pergunta é: porque mesmo estando correto o endereço do Relay o servidor DHCP ofereceu o IP referente ao segmento errado?

 

Conclusão

A resposta vem nos conceitos passados no início deste artigo, ou seja, para ambientes com múltiplas VLANs devemos usar um escopo por VLAN. Endereços contidos em superescopos irão atender apenas o mesmo segmento de nível 3. Neste caso, para resolver o problema basta clicar com o botão direito no Escopo B e escolher a opção “Remove from Superscope”. Ao fazer isso você estará colocando aquele escopo de forma independente e quando o servidor receber um DISCOVER vindo do segmento 10.10.10.0/24 ele poderá consultar o escopo correto e fazer a oferta correta.

 

Problema 4 – Clientes de todas VLANs param de Receber Endereço IP

O problema 4 nasceu durante a troca do servidor DHCP para um novo hardware. Foi feito um backup geral da máquina e restaurada em um novo hardware. Após isso nenhuma estação conseguia mais obter endereço IP. Nem os segmentos locais nem os segmentos remotos.

 

Obtendo Dados

Antes mesmo de coletar dados é importante obter a resposta para a pergunta: colocando um cabo cruzado entre o servidor e uma estação, a estação consegue obter IP?

Caso a resposta seja sim, então o problema já fica claro que é na Switch. Para eliminar a hipótese de ser um problema generalizado na Switch faça o teste de apenas trocar o servidor de porta. Se funcionar então podemos estar entrando em um cenário de segurança por porta de Switch.

Se os seguintes comandos forem digitados em uma porta de Switch Cisco, teremos então tal comportamento:

switchport port-security maximum 1

switchport port-security mac-address 0003fff1389b

 

Neste caso estamos “amarrando” esta porta para permitir apenas que este MAC seja permitido.

 

OBS: Os comandos e sintaxe para configuração de roteadores/switches deste exemplo podem variar de acordo com o equipamento, modelo e versão de sistema operacional do fabricante. Para mais informações sobre estes comandos ver o artigo “Configuring Port Security”.

 

 

Problema 5 – Apenas clientes da VLAN 1 Conseguem Obter Endereçamento IP

O problema 5 começou a acontecer depois da equipe de segurança aplicar políticas de segurança nos equipamentos ativos de rede, mas especificamente após aplicarem filtros na switch de núcleo (nível 3).

 

Obtendo Dados

Existem alguns casos que nem é necessário ir muito afundo na análise e obtenção dos dados, tudo parte do pressuposto que: antes estava funcionando, então o que mudou? Bem, neste o que mudou foi as regras de acesso da switch de nível 3, então recordemos que:

 

  • Precisamos que as portas UDP 67 e UDP 68 estejam abertas;
  • Em regra geral precisamos que o DHCP Relay Agente possa conversar com o DHCP Server nestas portas;

 

Segue abaixo um exemplo de como deveria estar configurado a lista de acesso para um o DHCP Relay Agent em em equipamento Cisco. Neste caso iremos utilizar a interface que está indo para a VLAN 2:

access-list 100 permit udp host 192.168.1.1 host 192.168.0.10 eq 67

access-list 100 permit udp host 192.168.0.10 host 192.168.1.1 eq 67

access-list 100 permit udp host 192.168.1.1 host 192.168.0.10 eq 68

access-list 100 permit udp host 192.168.0.10 host 192.168.1.1 eq 68

 

Neste caso estamos liberando o acesso indo e voltando entre estes dois hosts. Com isso a comunicação no que diz respeito a permitir ou não poderá ocorrer sem problemas.

OBS: Os comandos e sintaxe para configuração de roteadores/switches deste exemplo podem variar de acordo com o equipamento, modelo e versão de sistema operacional do fabricante. Para maiores informações sobre lista de acesso ver o artigo “IP Access Lists”.

 

Algumas vezes acontece o efeito “EU TENHO CERTEZA”, esse efeito geralmente acontece em usuários que dizem ter certeza que tal coisa foi realizada e não aceitam sequer a idéia de que possa ser aquilo que está se sugerindo. Neste caso ao apresentarmos tal solução ao administrador da Switch de nível 3 ele disse: “Eu tenho certeza que tais portas não estão sendo filtradas, o problema não é na Switch”. Bem, quando nos deparamos com este tipo de comportamento precisamos então provar a nossa teoria, neste caso poderíamos provar nossa teoria através dos testes abaixo:

 

  • Iniciar a captura com o network monitor no lado do cliente e no lado do servidor. Forçar a renovação do IP (ipconfig /renew) e verificar se chega algum DHCPOFFER vindo daquele segmento para o servidor. Caso não chegue isso seria suficiente para provar que a Switch está bloqueando o acesso;
  • Um outro teste seria pedir para o administrador da Switch fazer um telnet na porta 67 e 68 do servidor DHCP a partir da console da Switch. Este teste mostraria se a Switch pode comunicar-se com o DHCP nestas portas;
  • Rodar um Port Scan a partir do servidor tendo como destino a porta da switch que se conecta a VLAN que não recebe IP. Através deste scan das portas será possível verificar quais estão abertas para comunicação e quais estão fechadas. Para efetuar um Port Scan você poderá utilizar a ferramenta Microsoft Port Query. Esta ferramenta está disponível em linha de comando e também em interface gráfica. Faça o download a partir dos links abaixo:

 

 

Conclusão Final

Com base nos cenários vistos é importante ter em mente que nem sempre o problema é no servidor DHCP. Ficou claro nos cenários que a Switch de nível 3 tem um papel fundamental no aluguel de IP em um ambiente com múltiplas VLANs, caso a switch não esteja corretamente configurada é possível se deparar com problemas desta natureza.

Leave a Comment
  • Please add 2 and 8 and type the answer here:
  • Post
Wiki - Revision Comment List(Revision Comment)
Sort by: Published Date | Most Recent | Most Useful
Comments
  • Luciano Lima [MVP] Brazil edited Revision 1. Comment: Alterado o título para padronização.

  • Flávio Honda edited Original. Comment: adição TOC,adição tags

Page 1 of 1 (2 items)
Wikis - Comment List
Sort by: Published Date | Most Recent | Most Useful
Posting comments is temporarily disabled until 10:00am PST on Saturday, December 14th. Thank you for your patience.
Comments
Page 1 of 1 (4 items)