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.
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.
Este documento descreve as diferentes operações DHCP no controlador sem fio Cisco AireOS.
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.
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 |
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.
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.
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 detalhe doboot p protocolo é expandido, o que mostra as opções DHCP.
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 os detalhes do
boot p protocolo são expandidos, 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.
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 <primary-server> (Cisco Controller) >config interface dhcp management primary <primary-server> (Cisco Controller) >config interface dhcp dynamic-interface <interface-name>
primary <primary-server>
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
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
Captura de pacotes de Bridging - Perspectiva do cliente
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
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 <client vlan #> Switch(config-if)#ip helper-address <dhcp server IP>
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
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
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.
2. Aponte a sua substituição de DHCP para o endereço IP da interface de gerenciamento do seu controlador.
3. Verifique se o proxy DHCP está habilitado.
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 para problemas de DHCP é o
debug dhcp packet enable comando 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 <all/IP Address>
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 comando implica o uso da função de DHCP Bridging. 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.
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
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 |