Entender como as WLCs AireOS lidam com o protocolo DHCP

Opções de download

  • PDF     (607.6 KB)
    Ver no Adobe Reader em vários dispositivos
  • ePub     (454.0 KB)
    Ver em vários aplicativos no iPhone, iPad, Android, Sony Reader ou Windows Phone
  • Mobi (Kindle)     (732.9 KB)
    Ver no dispositivo Kindle ou no aplicativo Kindle em vários dispositivos
Atualizado:10 de maio de 2022
ID do documento:110865

Linguagem imparcial

O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.

Sobre esta tradução

A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.

    Introdução

    Este documento descreve as diferentes operações DHCP no controlador sem fio Cisco AireOS.

    Servidor DHCP externo

    A controladora Wireless LAN (WLC) oferece suporte a dois modos de operações DHCP, caso um servidor DHCP externo seja usado:

    • modo de proxy DHCP

    • modo de DHCP Bridging

    O modo proxy DHCP serve como uma função de ajuda DHCP para obter melhor segurança e controle sobre as transações DHCP entre o servidor DHCP e os clientes sem fio. O modo de ponte DHCP fornece uma opção para tornar a função de controlador em uma transação DHCP totalmente transparente para os clientes sem fio.

    Comparação entre os modos de proxy e de bridging DHCP

    Lidando com o DHCP do cliente

    Modo de proxy DHCP

    Modo de ponte DHCP
    Modificar giaddr Yes No
    Modificar siaddr Yes No
    Modificar o conteúdo do pacote Yes No
    Ofertas redundantes não encaminhadas Yes No
    Suporte à opção 82 Yes No
    Transmissão para unicast Yes No
    Suporte a BOOTP No Servidor
    RFC não compatível Os agentes de proxy e retransmissão não são exatamente o mesmo conceito. O modo de ponte DHCP é recomendado para conformidade total com RFC. No

    Modo de proxy DHCP

    O proxy DHCP não é ideal para todos os ambientes de rede. O controlador modifica e retransmite todas as transações DHCP para fornecer uma função de ajuda e resolver certos problemas de segurança.

    O endereço IP virtual do controlador é normalmente usado como o endereço IP origem de todas as transações DHCP para o cliente. Como resultado, o endereço IP real do servidor DHCP não é exposto no ar. Esse IP virtual é exibido na saída de depuração para transações DHCP no controlador. No entanto, o uso de um endereço IP virtual pode causar problemas para certos tipos de clientes.

    A operação do modo proxy DHCP mantém o mesmo comportamento para ambos os protocolos de mobilidade simétrica e assimétrica.

    Quando várias ofertas vêm de servidores DHCP externos, o proxy DHCP normalmente seleciona o primeiro que chega e define o endereço IP do servidor na estrutura de dados do cliente. Como resultado, todas as transações subsequentes são executadas através do mesmo servidor DHCP até que uma transação falhe após novas tentativas. Neste ponto, o proxy seleciona um servidor DHCP diferente para o cliente.

    O proxy DHCP é ativado por padrão. Todos os controladores que se comunicam devem ter a mesma configuração de proxy DHCP.

    Observação: o proxy DHCP deve estar habilitado para que a opção de DHCP 82 funcione corretamente.

    Fluxo de pacote de proxy

    Diagram of proxy packet flow

    Captura de pacote de proxy

    Quando o controlador está no modo proxy DHCP, ele não apenas direciona os pacotes DHCP para o servidor DHCP, mas também cria novos pacotes DHCP para encaminhá-los ao servidor DHCP. Todas as opções DHCP presentes nos pacotes DHCP do cliente são copiadas para os pacotes DHCP do controlador. Os próximos exemplos de captura de tela mostram isso para um pacote de solicitação DHCP.

    Perspectiva do cliente

    Esta captura de tela é de uma captura de pacote feita da perspectiva do cliente. Ele mostra uma descoberta DHCP, uma oferta DHCP, uma solicitação DHCP e um DHCP ACK. A solicitação DHCP é realçada e o comando boot p o detalhe do protocolo é expandido, o que mostra as opções DHCP.

    Screenshot of a packet capture from the client perspective

    Perspectiva do servidor

    Esta captura de tela é de uma captura de pacote feita da perspectiva do servidor. Semelhante ao exemplo anterior, ele mostra uma descoberta DHCP, uma oferta DHCP, uma solicitação DHCP e um DHCP ACK. No entanto, esses são pacotes que o controlador construiu como uma função do proxy DHCP. Novamente, a solicitação DHCP é realçada e o comando boot p o detalhe do protocolo é expandido, o que mostra as opções DHCP. Observe que eles são os mesmos do pacote de solicitação DHCP do cliente. Além disso, observe que o proxy da WLC retransmite o pacote e destaca os endereços do pacote.

    Screenshot of a packet capture from the server perspective

    Exemplo de configuração de proxy

    Para usar o controlador como um proxy DHCP, o recurso de proxy DHCP deve ser habilitado no controlador. Por padrão, esse recurso está habilitado. Para habilitar o proxy DHCP, este comando CLI pode ser usado. O mesmo está disponível na GUI na página Controller no menu DHCP.

    (Cisco Controller) >config dhcp proxy enable
(Cisco Controller) >show dhcp proxy

DHCP Proxy Behavior: enabled

    Para que o proxy DHCP funcione, um servidor DHCP primário deve ser configurado em cada interface do controlador que requer serviços DHCP. Um servidor DHCP pode ser configurado na interface de gerenciamento, na interface do gerenciador de aplicativos e em interfaces dinâmicas. Esses comandos CLI podem ser usados para configurar um servidor DHCP para cada interface.

    (Cisco Controller) >config interface dhcp ap-manager primary 
    
    
(Cisco Controller) >config interface dhcp management primary 
    
    
(Cisco Controller) >config interface dhcp dynamic-interface 
    
    
     primary

    O recurso de DHCP Bridging é uma configuração global, portanto afeta todas as transações DHCP dentro do controlador.

    Troubleshooting

    Esta é a saída do comando debug dhcp packet enable comando. A depuração mostra um controlador que recebe uma solicitação DHCP de um cliente com endereço MAC 00:40:96:b4:8c:e1, transmite uma solicitação DHCP ao servidor DHCP, recebe uma resposta do servidor DHCP e envia uma oferta DHCP ao cliente.

    (Cisco Controller) >debug dhcp message enable

Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP received op BOOTREQUEST (1)
     (len 312, port 29, encap 0xec03)    
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP option len (including the magic cookie) 76
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP option: message type = DHCP REQUEST
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP option: 61 (len 7) - skipping
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP option: requested ip = 192.168.4.13
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP option: 12 (len 7) - skipping
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP option: 81 (len 11) - skipping
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP option: vendor class id = MSFT 5.0 (len 8)
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP option: 55 (len 11) - skipping
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP options end, len 76, actual 68
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP selecting relay 1 - control block settings:
                        dhcpServer: 0.0.0.0, dhcpNetmask: 0.0.0.0,
                        dhcpGateway: 0.0.0.0, dhcpRelay: 0.0.0.0  VLAN: 0
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP selected relay 1 - 192.168.3.1
     (local address 192.168.4.2, gateway 192.168.4.1, VLAN 101, port 29)
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP transmitting DHCP REQUEST (3)    
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP   op: BOOTREQUEST, htype: Ethernet,
     hlen: 6, hops: 1
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP   xid: 0xfc3c9979 (4231829881), secs: 0,
     flags: 0
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP   chaddr: 00:40:96:b4:8c:e1
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP   ciaddr: 0.0.0.0,  yiaddr: 0.0.0.0
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP   siaddr: 0.0.0.0,  giaddr: 192.168.4.1
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP   requested ip: 192.168.4.13
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP Forwarding DHCP packet (332 octets)
               -- packet received on direct-connect port requires forwarding to external DHCP
     server. Next-hop is 192.168.4.1    
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP sending REQUEST to 192.168.4.1
     (len 350, port 29, vlan 101)
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP selecting relay 2 - control block settings:
                        dhcpServer: 0.0.0.0, dhcpNetmask: 0.0.0.0,
                        dhcpGateway: 0.0.0.0, dhcpRelay: 192.168.4.1  VLAN: 101
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP selected relay 2 - NONE
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP received op BOOTREPLY (2) (len 316, port 29,
     encap 0xec00)    
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP option len (including the magic cookie) 80
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP option: message type = DHCP ACK
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP option: 58 (len 4) - skipping
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP option: 59 (len 4) - skipping
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP option: lease time = 691200 seconds
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP option: server id = 192.168.3.1
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP option: netmask = 255.255.0.0
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP option: 15 (len 14) - skipping
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP option: gateway = 192.168.4.1
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP option: DNS server, cnt = 1, first = 192.168.3.1
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP option: WINS server, cnt = 1, first = 192.168.3.1
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP options end, len 80, actual 72
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP setting server from ACK (server 192.168.3.1,
     yiaddr 192.168.4.13)
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 Assigning Address 192.168.4.13 to mobile
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP sending REPLY to STA (len 424, port 29,
     vlan 20)
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP transmitting DHCP ACK (5)    
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP   op: BOOTREPLY, htype: Ethernet, hlen: 6,
     hops: 0
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP   xid: 0xfc3c9979 (4231829881), secs: 0,
     flags: 0
Thu Jun 25 21:48:59 2009: 00:40:96:b4:8c:e1 DHCP   chaddr: 00:40:96:b4:8c:e1
Thu Jun 25 21:48:59 2009: 00:40:96:b4:8c:e1 DHCP   ciaddr: 0.0.0.0,  yiaddr: 192.168.4.13
Thu Jun 25 21:48:59 2009: 00:40:96:b4:8c:e1 DHCP   siaddr: 0.0.0.0,  giaddr: 0.0.0.0
Thu Jun 25 21:48:59 2009: 00:40:96:b4:8c:e1 DHCP   server id: 192.0.2.10  rcvd server id: 192.168.3.1

    Caveats

    • Podem existir problemas de interoperabilidade entre um controlador com proxy DHCP ativado e dispositivos que atuam como firewall e servidor DHCP. Isso ocorre provavelmente devido ao componente de firewall do dispositivo, pois os firewalls geralmente não respondem às solicitações de proxy. A solução alternativa para esse problema é desabilitar o proxy DHCP no controlador.

    • Quando um cliente está no estado DHCP REQ no controlador, o controlador descarta os pacotes de informação DHCP. O cliente não entra em um estado RUN no controlador (isso é necessário para que o cliente passe o tráfego) até receber um pacote de descoberta DHCP do cliente. Os pacotes de informação DHCP são encaminhados pelo controlador quando o proxy DHCP está desativado.

    • Todos os controladores que se comunicam entre si devem ter a mesma configuração de proxy DHCP.

    Modo de ponte DHCP

    O recurso de ponte DHCP foi projetado para tornar a função de controlador na transação DHCP totalmente transparente para o cliente. Com exceção da conversão de 802.11 para Ethernet II, os pacotes do cliente são ligados sem modificação do túnel Light Weight Access Point Protocol (LWAPP) para a VLAN do cliente (ou túnel Ethernet over IP (EoIP) no caso de roaming de L3). Da mesma forma, com exceção das conversões de Ethernet II para 802.11, os pacotes para o cliente são ligados sem modificação da VLAN do cliente (ou túnel EoIP no caso de roaming de L3) para o túnel LWAPP. Pense nisso como cabear um cliente em uma porta de switch e, em seguida, o cliente executa uma transação DHCP tradicional.

    Operações de ponte DHCP - Bridging Packet Flow

    Diagram of DHCP bridging packet flow

    Captura de pacotes de Bridging - Perspectiva do cliente

    Screenshot of bridging packet capture from the client perspective

    Na captura de tela do pacote do lado do cliente, a principal diferença entre a captura do cliente no modo Proxy é o IP real do servidor DHCP, que é visto nos pacotes Offer e Ack em vez do endereço IP virtual do controlador.

    Captura de pacote de ponte - Perspectiva do servidor

    Screenshot of bridging packet capture from the server perspective

    Na captura de tela do pacote com fio, você pode ver que o pacote 40 é o broadcast de solicitação DHCP interligado do cliente de teste 00:40:96:b6:44:51 para a rede com fio.

    Exemplo de configuração de Bridging

    Para habilitar a funcionalidade de ponte DHCP no controlador, você deve desabilitar o recurso de proxy DHCP no controlador. Isso só pode ser realizado no CLI com estes comandos:

    (Cisco Controller) >config dhcp proxy disable
(Cisco Controller) >show dhcp proxy
DHCP Proxy Behaviour: disabled

    Se o servidor DHCP não existir na mesma rede de Camada 2 (L2) que o cliente, o broadcast deverá ser encaminhado ao servidor DHCP no gateway cliente através do uso de um IP helper. Este é um exemplo desta configuração:

    Switch#conf t
Switch(config)#interface vlan 
    
    
Switch(config-if)#ip helper-address

    O recurso de DHCP Bridging é uma configuração global, portanto afeta todas as transações DHCP dentro do controlador. Você deve adicionar instruções IP helper na infraestrutura com fio para todas as VLANs necessárias no controlador.

    Troubleshooting

    As depurações listadas aqui foram ativadas na CLI da controladora e a parte DHCP da saída foi extraída para este documento.

    (Cisco Controller) >debug client 00:40:96:b6:44:51
(Cisco Controller) >debug dhcp message enable

00:40:96:b6:44:51 DHCP received op BOOTREQUEST (1) (len 308, port 1, encap 0xec03) 
00:40:96:b6:44:51 DHCP option len (including the magic cookie) 72 
00:40:96:b6:44:51 DHCP option: message type = DHCP DISCOVER 
00:40:96:b6:44:51 DHCP option: 116 (len 1) - skipping 
00:40:96:b6:44:51 DHCP option: 61 (len 7) - skipping 
00:40:96:b6:44:51 DHCP option: 12 (len 12) - skipping 
00:40:96:b6:44:51 DHCP option: vendor class id = MSFT 5.0 (len 8)
00:40:96:b6:44:51 DHCP option: 55 (len 11) - skipping 
00:40:96:b6:44:51 DHCP options end, len 72, actual 64 
00:40:96:b6:44:51 DHCP processing DHCP DISCOVER (1) 
00:40:96:b6:44:51 DHCP   op: BOOTREQUEST, htype: Ethernet, hlen: 6, hops: 0 
00:40:96:b6:44:51 DHCP   xid: 0x224dfab6 (575535798), secs: 0, flags: 0 
00:40:96:b6:44:51 DHCP   chaddr: 00:40:96:b6:44:51 
00:40:96:b6:44:51 DHCP   ciaddr: 0.0.0.0,  yiaddr: 0.0.0.0 
00:40:96:b6:44:51 DHCP   siaddr: 0.0.0.0,  giaddr: 0.0.0.0 
00:40:96:b6:44:51 DHCP successfully bridged packet to DS 
00:40:96:b6:44:51 DHCP received op BOOTREPLY (2) (len 308, port 1, encap 0xec00) 
00:40:96:b6:44:51 DHCP option len (including the magic cookie) 72
00:40:96:b6:44:51 DHCP option: message type = DHCP OFFER 
00:40:96:b6:44:51 DHCP option: server id = 192.168.10.1 
00:40:96:b6:44:51 DHCP option: lease time = 84263 seconds 
00:40:96:b6:44:51 DHCP option: 58 (len 4) - skipping 
00:40:96:b6:44:51 DHCP option: 59 (len 4) - skipping 
00:40:96:b6:44:51 DHCP option: netmask = 255.255.255.0
00:40:96:b6:44:51 DHCP option: gateway = 192.168.10.1 
00:40:96:b6:44:51 DHCP options end, len 72, actual 64 
00:40:96:b6:44:51 DHCP processing DHCP OFFER (2) 
00:40:96:b6:44:51 DHCP   op: BOOTREPLY, htype: Ethernet, hlen: 6, hops: 0 
00:40:96:b6:44:51 DHCP   xid: 0x224dfab6 (575535798), secs: 0, flags: 0 
00:40:96:b6:44:51 DHCP   chaddr: 00:40:96:b6:44:51 
00:40:96:b6:44:51 DHCP   ciaddr: 0.0.0.0,  yiaddr: 192.168.10.104 
00:40:96:b6:44:51 DHCP   siaddr: 0.0.0.0,  giaddr: 0.0.0.0 
00:40:96:b6:44:51 DHCP   server id: 192.168.10.1  rcvd server id: 192.168.10.1 
00:40:96:b6:44:51 DHCP successfully bridged packet to STA 
00:40:96:b6:44:51 DHCP received op BOOTREQUEST (1) (len 328, port 1, encap 0xec03) 
00:40:96:b6:44:51 DHCP option len (including the magic cookie) 92 
00:40:96:b6:44:51 DHCP option: message type = DHCP REQUEST 
00:40:96:b6:44:51 DHCP option: 61 (len 7) - skipping 
00:40:96:b6:44:51 DHCP option: requested ip = 192.168.10.104 
00:40:96:b6:44:51 DHCP option: server id = 192.168.10.1 
00:40:96:b6:44:51 DHCP option: 12 (len 12) - skipping 
00:40:96:b6:44:51 DHCP option: 81 (len 16) - skipping 
00:40:96:b6:44:51 DHCP option: vendor class id = MSFT 5.0 (len 8) 
00:40:96:b6:44:51 DHCP option: 55 (len 11) - skipping 
00:40:96:b6:44:51 DHCP options end, len 92, actual 84 
00:40:96:b6:44:51 DHCP processing DHCP REQUEST (3) 
00:40:96:b6:44:51 DHCP   op: BOOTREQUEST, htype: Ethernet, hlen: 6, hops: 0 
00:40:96:b6:44:51 DHCP   xid: 0x224dfab6 (575535798), secs: 0, flags: 0 
00:40:96:b6:44:51 DHCP   chaddr: 00:40:96:b6:44:51
00:40:96:b6:44:51 DHCP   ciaddr: 0.0.0.0,  yiaddr: 0.0.0.0 
00:40:96:b6:44:51 DHCP   siaddr: 0.0.0.0,  giaddr: 0.0.0.0 
00:40:96:b6:44:51 DHCP   requested ip: 192.168.10.104 
00:40:96:b6:44:51 DHCP   server id: 192.168.10.1  rcvd server id: 192.168.10.1 
00:40:96:b6:44:51 DHCP successfully bridged packet to DS
00:40:96:b6:44:51 DHCP received op BOOTREPLY (2) (len 308, port 1, encap 0xec00) 
00:40:96:b6:44:51 DHCP option len (including the magic
cookie) 72 00:40:96:b6:44:51 DHCP option: message type = DHCP ACK 
00:40:96:b6:44:51 DHCP option: server id = 192.168.10.1 
00:40:96:b6:44:51 DHCP option: lease time = 86400 seconds 
00:40:96:b6:44:51 DHCP option: 58 (len 4) - skipping 
00:40:96:b6:44:51 DHCP option: 59 (len 4) - skipping 
00:40:96:b6:44:51 DHCP option: netmask = 255.255.255.0 
00:40:96:b6:44:51 DHCP option: gateway = 192.168.10.1 
00:40:96:b6:44:51 DHCP options end, len 72, actual 64 
00:40:96:b6:44:51 DHCP processing DHCP ACK (5) 
00:40:96:b6:44:51 DHCP   op: BOOTREPLY, htype: Ethernet, hlen: 6, hops: 0
00:40:96:b6:44:51 DHCP   xid: 0x224dfab6 (575535798), secs: 0, flags: 0 
00:40:96:b6:44:51 DHCP   chaddr: 00:40:96:b6:44:51 
00:40:96:b6:44:51 DHCP   ciaddr: 0.0.0.0,  yiaddr: 192.168.10.104 
00:40:96:b6:44:51 DHCP   siaddr: 0.0.0.0,  giaddr: 0.0.0.0 
00:40:96:b6:44:51 DHCP   server id: 192.168.10.1  rcvd server id: 192.168.10.1
00:40:96:b6:44:51 Assigning Address 192.168.10.104 to mobile  
00:40:96:b6:44:51 DHCP successfully bridged packet to STA
00:40:96:b6:44:51 192.168.10.104 Added NPU entry of type 1

    Nesta saída de depuração de DHCP, há algumas indicações importantes de que o DHCP Bridging está em uso no controlador:

    • O DHCP fez a ponte do pacote com êxito para o DS - Isso significa que o pacote DHCP original do cliente foi colocado em ponte, sem alterações para o sistema de distribuição (DS). O DS é a infraestrutura com fio.
    • O DHCP fez a ponte do pacote com êxito para o STA - Essa mensagem indica que o pacote DHCP foi colocado em ponte, sem alterações para a estação (STA). O STA é a máquina cliente que solicita DHCP.

    Além disso, você vê o endereço IP do servidor real listado nas depurações, que é 192.168.10.1. Se o proxy DHCP estiver em uso em vez do DHCP Bridging, você poderá ver o endereço IP virtual do controlador listado para o endereço IP do servidor.

    Caveats

    • Por padrão, o proxy DHCP está habilitado.

    • Todos os controladores que se comunicam entre si devem ter a mesma configuração de proxy DHCP.

    • O proxy DHCP deve ser ativado para que a opção 82 do DHCP funcione.

    Servidor DHCP interno

    O servidor DHCP interno foi introduzido inicialmente para filiais onde um servidor DHCP externo não está disponível. Ele foi projetado para suportar uma pequena rede sem fio com menos de dez pontos de acesso (APs) que estejam na mesma sub-rede. O servidor interno fornece endereços IP para clientes sem fio, APs de conexão direta, APs de modo de dispositivo na interface de gerenciamento e solicitações DHCP que são retransmitidas de APs. Não é um servidor DHCP completo de uso geral. Ele suporta apenas funcionalidade limitada e não é escalável em uma implantação maior.

    Comparação dos Modos DHCP e Bridging Internos

    Os dois modos principais do DHCP no controlador são proxy DHCP ou DHCP Bridging. Com o DHCP Bridging, a controladora age mais como um DHCP de volta com APs autônomos. Um pacote DHCP entra no AP por meio de uma associação de cliente a um SSID (Service Set Identifier) vinculado a uma VLAN. Em seguida, o pacote DHCP sai dessa VLAN. Se um auxiliar de IP for definido no gateway de Camada 3 (L3) dessa VLAN, o pacote será encaminhado a esse servidor DHCP via unicast direcionado. Em seguida, o servidor DHCP responde diretamente à interface L3 que encaminhou esse pacote DHCP. Com o proxy DHCP, é a mesma ideia, mas todo o encaminhamento é feito diretamente no controlador, em vez da interface L3 da VLAN. Por exemplo, uma solicitação DHCP chega à WLAN do cliente, a WLAN usa o servidor DHCP definido na interface da VLAN *ou* usa a função de substituição DHCP da WLAN para encaminhar um pacote DHCP unicast ao servidor DHCP com o campo DHCP packets GIADDR preenchido para ser o endereço IP da interface VLAN.

    Servidor DHCP interno - Fluxo de pacotes

    Diagram of internal DHCP server packet flow

    Exemplo de configuração de servidor DHCP interno

    Você deve habilitar o proxy DHCP no controlador para permitir que o servidor DHCP interno funcione. Isso pode ser feito por meio da GUI nesta seção:

    Observação: você não pode definir o proxy DHCP através da GUI em todas as versões.

    Controller->Advanced->DHCP

    Select the checkbox to enable DHCP proxy on the DHCP Parameters screen

    Ou pelo CLI:

    Config dhcp proxy enable
Save config

    Para habilitar o servidor DHCP interno, execute estas etapas:

    1. Defina um escopo que você usa para receber endereços IP (Controller > Internal DHCP Server > DHCP Scope). Clique em New.

    DHCP Scope - Edit screen

    2. Aponte a sua substituição de DHCP para o endereço IP da interface de gerenciamento do seu controlador.

    Select the Override checkbox for the DHCP Server and enter the DHCP Server IP Address

    3. Verifique se o proxy DHCP está habilitado.

    Confirm that the Enable DHCP Proxy option is selected on the DHCP Parameters screen

    Troubleshooting

    Uma depuração do servidor DHCP interno geralmente exige encontrar um cliente que tenha problemas para obter um endereço IP. Você deve executar essas depurações.

    debug client <MAC ADDRESS OF CLIENT>

    O cliente de depuração é uma macro que ativa essas depurações para você enquanto focaliza a depuração somente no endereço MAC do cliente que você inseriu.

    debug dhcp packet enable
debug dot11 mobile enable
debug dot11 state enable
debug dot1x events enable
debug pem events enable
debug pem state enable
debug cckm client debug enable

    O principal problema do DHCP é o debug dhcp packet enable que é ativado automaticamente pelo debug client comando.

    00:1b:77:2b:cf:75 dhcpd: received DISCOVER 
00:1b:77:2b:cf:75 dhcpd: Sending DHCP packet (giaddr:192.168.100.254)to 127.0.0.1:67
      from 127.0.0.1:1067     
00:1b:77:2b:cf:75 sendto (548 bytes) returned 548
00:1b:77:2b:cf:75 DHCP option len (including the magic cookie) 312 
00:1b:77:2b:cf:75 DHCP option: message type = DHCP OFFER 
00:1b:77:2b:cf:75 DHCP option: server id = 192.168.100.254 
00:1b:77:2b:cf:75 DHCP option: lease time = 86400 seconds 
00:1b:77:2b:cf:75 DHCP option: gateway = 192.168.100.1 
00:1b:77:2b:cf:75 DHCP option: 15 (len 13) - skipping 
00:1b:77:2b:cf:75 DHCP option: netmask = 255.255.255.0 
00:1b:77:2b:cf:75 DHCP options end, len 312, actual 64 
00:1b:77:2b:cf:75 DHCP option len (including the magic cookie) 81 
00:1b:77:2b:cf:75 DHCP option: message type = DHCP REQUEST 
00:1b:77:2b:cf:75 DHCP option: 61 (len 7) - skipping 
00:1b:77:2b:cf:75 DHCP option: requested ip = 192.168.100.100 
00:1b:77:2b:cf:75 DHCP option: server id = 192.0.2.10
00:1b:77:2b:cf:75 DHCP option: 12 (len 14) - skipping 
00:1b:77:2b:cf:75 DHCP option: vendor class id = MSFT 5.0 (len 8) 
00:1b:77:2b:cf:75 DHCP option: 55 (len 11) - skipping 
00:1b:77:2b:cf:75 DHCP option: 43 (len 3) - skipping 
00:1b:77:2b:cf:75 DHCP options end, len 81, actual 73 
00:1b:77:2b:cf:75 DHCP Forwarding packet locally (340 octets) from 192.168.100.254 to
     192.168.100.254
dhcpd: Received 340 byte dhcp packet from 0xfe64a8c0 192.168.100.254:68
00:1b:77:2b:cf:75 dhcpd: packet 192.168.100.254 -> 192.168.100.254 using scope "User Scope" 
00:1b:77:2b:cf:75 dhcpd: received REQUEST 
00:1b:77:2b:cf:75 Checking node 192.168.100.100  Allocated 1246985143, Expires 1247071543
     (now: 1246985143) 
00:1b:77:2b:cf:75 dhcpd: server_id = c0a864fe 
00:1b:77:2b:cf:75 dhcpd: server_id = c0a864fe adding option 0x35 adding option 0x36
     adding option 0x33 adding option 0x03 adding option 0x0f adding option 0x01 
00:1b:77:2b:cf:75 dhcpd: Sending DHCP packet (giaddr:192.168.100.254)to 127.0.0.1:67
      from 127.0.0.1:1067     
00:1b:77:2b:cf:75 sendto (548 bytes) returned 548
00:1b:77:2b:cf:75 DHCP option len (including the magic cookie) 312 
00:1b:77:2b:cf:75 DHCP option: message type = DHCP ACK 
00:1b:77:2b:cf:75 DHCP option: server id = 192.168.100.254 
00:1b:77:2b:cf:75 DHCP option: lease time = 86400 seconds 
00:1b:77:2b:cf:75 DHCP option: gateway = 192.168.100.1 
00:1b:77:2b:cf:75 DHCP option: 15 (len 13) - skipping 
00:1b:77:2b:cf:75 DHCP option: netmask = 255.255.255.0 
00:1b:77:2b:cf:75 DHCP options end, len 312, actual 64

    Limpe as concessões de DHCP no servidor DHCP interno da WLC

    Você pode executar este comando para limpar as concessões de DHCP no servidor DHCP interno da WLC:

    config dhcp clear-lease

    Aqui está um exemplo:

    config dhcp clear-lease all

    Caveats

    • O proxy DHCP deve ser ativado para que o servidor DHCP interno funcione

    • Uso de DHCP para a porta 1067 quando você usa o servidor DHCP interno, que é afetado pela ACL da CPU

    • O servidor DHCP interno escuta na interface de loopback do controlador via 127.0.0.1 porta UDP 67

    Interface de usuário final

    • O config dhcp proxy disable implica o uso da função de ponte DHCP. Esse é um comando global (não um comando por WLAN).

    • O proxy DHCP permanece habilitado por padrão.

    • Quando o proxy DHCP é desativado, o servidor DHCP interno não pode ser usado por WLANs locais. A operação de bridging não é consistente com as operações necessárias para redirecionar um pacote para o servidor interno. Bridging realmente significa bridging, com exceção de 802.11 para conversão Ethernet II. Os pacotes DHCP são passados sem modificação do túnel LWAPP para a VLAN cliente (e vice-versa).

    • Quando o proxy estiver habilitado, um servidor DHCP deverá ser configurado na interface da WLAN (ou na própria WLAN) para que a WLAN seja habilitada. Nenhum servidor precisa ser configurado quando o proxy está desabilitado, pois esses servidores não são usados.

    • Quando um usuário tenta habilitar o proxy DHCP, você verifica internamente se todas as WLANs (ou interfaces associadas) têm um servidor DHCP configurado. Caso contrário, a operação de ativação falhará.

    DHCP necessário

    A configuração avançada da WLAN tem uma opção que exige que os usuários passem o DHCP antes de entrarem no estado RUN (um estado onde o cliente pode passar o tráfego através da controladora). Esta opção exige que o cliente faça uma solicitação DHCP completa ou metade. A principal coisa que o controlador procura do cliente é uma solicitação DHCP e um ACK que volta do servidor DHCP. Enquanto o cliente executar essas etapas, ele passará a etapa necessária do DHCP e passará para o estado RUN.

    Optional - Select the Required checkbox for DHCP Address Assignment

    Roaming de L2 e L3

    L2 Roam - Se o cliente tiver um aluguel de DHCP válido e executar um roam de L2 entre dois controladores diferentes na mesma rede L2, o cliente não precisará reDHCP e a entrada do cliente deverá ser completamente movida do controlador original para o novo controlador. Em seguida, se o cliente precisar executar o DHCP novamente, a ponte DHCP ou o processo proxy no controlador atual fará a ponte transparente do pacote novamente.

    L3 em roaming - Em um cenário de roaming L3, o cliente se move entre dois controladores diferentes em redes L3 diferentes. Nessa situação, o cliente é ancorado na controladora original e listado na tabela de clientes na nova controladora estrangeira. Durante o cenário de âncora, o DHCP do cliente é tratado pelo controlador de âncora à medida que os dados do cliente são encapsulados em um túnel EoIP entre os controladores externo e de âncora.

    Informações Relacionadas

    Histórico de revisões

    Revisão Data de publicação Comentários
    3.0
    10-May-2022
    Alguns endereços IP foram atualizados. Texto editado para maior clareza.
    1.0
    07-Feb-2014
    Versão inicial
    TAC Authored

    Colaborado por engenheiros da Cisco

    • Nicolas Darchis
      TAC da Cisco

    Este documento lhe foi útil?

    FeedbackFeedback

    Contate a Cisco

    Este documento se refere a estes produtos