Tecnología inalámbrica : Productos Cisco Wireless LAN Controller de la serie 4400

DHCP con el WLC

18 Octubre 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

Los clientes que usaban las soluciones del Cisco Unified Wireless han estado señalando los problemas con el soporte del DHCP proporcionado en el regulador del Wireless LAN (WLC). Algunos de estos problemas son bugs de software o problemas de debug. Otros se deben una comprensión inadecuada de la implementación DHCP.

Este documento describe las diversas operaciones DHCP en el regulador inalámbrico, que proporciona constante y la información precisa a los clientes en un esfuerzo para reducir los problemas del cliente y los casos TAC relacionados.

prerrequisitos

Requisitos

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Servidor DHCP externo

El WLC soporta dos modos de operaciones DHCP en caso de que se utilice un servidor DHCP externo:

  • Modo de representación del DHCP

  • Bridging Mode del DHCP

El modo de representación del DHCP sirve como función del ayudante del DHCP alcanzar una mejores Seguridad y control sobre la transacción DHCP entre el servidor DHCP y los clientes de red inalámbrica. El Bridging Mode del DHCP proporciona una opción para hacer el papel del regulador en la transacción DHCP totalmente transparente a los clientes de red inalámbrica.

Comparación del proxy del DHCP y de los modos del bridging

Dirección del DHCP del cliente Modo de representación del DHCP Bridging Mode del DHCP
Modifique el giaddr No
Modifique el siaddr No
Modifique el contenido de paquetes No
Ofertas redundantes no remitidas No
Soporte de la opción 82 No
Broadcast al unicast No
Soporte BOOTP No Servidor
RFC no obediente El proxy y el Agente Relay no son exactamente el mismo concepto. El Bridging Mode del DHCP se recomienda para la conformidad completa RFC. No

Modo de representación del DHCP

El proxy del DHCP no es ideal para todos los entornos de red. El regulador modifica y retransmite todas las transacciones DHCP para proporcionar la función del ayudante, y aborda ciertos problemas de seguridad.

Utilizan a la dirección IP virtual del regulador normalmente como la dirección IP de origen de todas las transacciones DHCP al cliente. Como consecuencia, el IP Address del servidor DHCP real no se expone en el aire. Esto IP virtual se visualiza en la salida de los debugs para las transacciones DHCP en el regulador. Sin embargo, usando la dirección IP virtual puede causar los problemas en los tipos determinados de clientes.

La operación del modo de representación del DHCP mantiene el mismo comportamiento para los protocolos simétricos y asimétricos de la movilidad.

Cuando las ofertas múltiples están viniendo de los servidores DHCP externos, el proxy del DHCP selecciona normalmente primer que viene adentro y fija la dirección IP del servidor en la estructura de datos del cliente. Como consecuencia, todas las transacciones siguientes pasan a través del mismo servidor DHCP hasta que una transacción falle después de las recomprobaciones. En este momento, el proxy selecciona un diverso servidor DHCP para el cliente.

El proxy del DHCP se habilita por abandono. Todos los reguladores que comunicarán deben tener la misma configuración de representación del DHCP.

Nota: El proxy del DHCP se debe habilitar para que la opción DHCP 82 de actuar correctamente.

Flujo de paquetes del proxy

dhcp-wlc-01.gif

Captura de paquetes del proxy

Cuando el regulador está en el modo de representación del DHCP, no sólo está dirigiendo los paquetes DHCP al servidor DHCP, él está construyendo realmente los nuevos paquetes DHCP para remitir al servidor DHCP. Toda la opción DHCP que están presente en los paquetes DHCP del cliente se copia en los paquetes DHCP del regulador. Los ejemplos del tiro de siguiente pantalla muestran esto para un paquete de pedido de DHCP.

Perspectiva del cliente

Este tiro de pantalla está de una captura de paquetes tomada de la perspectiva de los clientes. Muestra que un DHCP descubre, oferta de DHCP, pedido de DHCP, y un DHCP ACK. Se resalta el pedido de DHCP y el detalle del protocolo BOOTP se amplía que muestra la opción DHCP.

dhcp-wlc-02.gif

Perspectiva del servidor

Este tiro de pantalla está de una captura de paquetes tomada de la perspectiva del servidor. Similar al ejemplo anterior, muestra que un DHCP descubre, oferta de DHCP, pedido de DHCP, y un DHCP ACK. Sin embargo, éstos son los paquetes que el regulador construyó en función del proxy del DHCP. Una vez más se resalta el pedido de DHCP y el detalle del protocolo BOOTP se amplía que muestra la opción DHCP. Note que ella es lo mismo que en el paquete de pedido de DHCP de los clientes. También observe que el proxy del WLC está retransmitiendo los direccionamientos del paquete y del paquete del resaltado.

dhcp-wlc-03.gif

Ejemplo de la configuración de representación

Para utilizar el regulador como proxy del DHCP, la característica del proxy del DHCP se debe habilitar en el regulador. Por abandono, se habilita esta característica. Para habilitar el proxy del DHCP, el comando CLI siguiente debe ser utilizado. También, en los códigos 4.2.x.x, esto se puede lograr solamente en el CLI.

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

DHCP Proxy Behavior: enabled

Para que el proxy del DHCP trabaje, un servidor DHCP primario se debe configurar en cada interfaz del regulador que requiera los servicios del DHCP. Un servidor DHCP se puede configurar en la interfaz de administración, interfaz del ap-administrador, y en las interfaces dinámicas. Los comandos CLI siguientes pueden ser utilizados para configurar un servidor DHCP para cada interfaz.

(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>

El DHCP que interliga la característica es una configuración global, así que afecta a todas las transacciones DHCP dentro del regulador.

Resolución de problemas

Ésta es la salida del comando debug dhcp packet enable. El debug muestra un regulador que recibe un pedido de DHCP de un cliente con la dirección MAC 00:40:96:b4:8c:e1, transmitiendo un pedido de DHCP al servidor DHCP, recibiendo una contestación del servidor DHCP, y enviando una oferta de DHCP al 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 = 50.101.2.7
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 - 11.0.0.11 (local address 50.101.0.11, gateway 50.101.0.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: 50.101.0.11
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP   requested ip: 50.101.2.7
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 50.101.0.1
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP sending REQUEST to 50.101.0.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: 50.101.0.11  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 = 11.0.0.11
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 = 50.101.0.1
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP option: DNS server, cnt = 1, first = 11.0.0.11
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 DHCP option: WINS server, cnt = 1, first = 11.0.0.11
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 11.0.0.11, yiaddr 50.101.2.7)
Thu Jun 25 21:48:55 2009: 00:40:96:b4:8c:e1 Assigning Address 50.101.2.7 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: 50.101.2.7
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: 1.1.1.1  rcvd server id: 11.0.0.11

Advertencias

  • Los problemas de interoperabilidad pueden existir entre un regulador con el proxy del DHCP habilitado y los dispositivos que actúa como un Firewall y servidor DHCP. Esto es muy probablemente debido al componente del Firewall del dispositivo pues los Firewall no responden generalmente a las peticiones del proxy. La solución alternativa para este problema es inhabilitar el proxy del DHCP en el regulador.

  • Cuando un cliente está en el estado del REQ del DHCP en el regulador, el regulador cae los paquetes del DHCP inform. El cliente no entrará un estado de FUNCIONAMIENTO en el regulador (éste se requiere para que al cliente pase el tráfico) hasta que reciba un DHCP descubra el paquete del cliente. Los paquetes del DHCP inform son remitidos por el regulador cuando se inhabilita el proxy del DHCP.

  • Todos los reguladores que comunicarán deben tener la misma configuración de representación del DHCP.

Bridging Mode del DHCP

El DHCP que interliga la característica se diseña para hacer el papel del regulador en la transacción DHCP totalmente transparente al cliente. A excepción del 802.11 a la conversión del Ethernet II, los paquetes del cliente se interligan sin modificar del túnel del LWAPP al VLA N del cliente (o del túnel de EoIP en el caso de itinerancia L3). Semejantemente, a excepción del Ethernet II a la conversión del 802.11, los paquetes al cliente se interligan sin modificar del VLA N del cliente (o del túnel de EoIP en el caso de itinerancia L3) al túnel del LWAPP. Piense en esto como conexión de un cliente en un switchport y del cliente que realiza una transacción DHCP tradicional.

Operaciones de bridging del DHCP - Interligar el flujo de paquetes

dhcp-wlc-04.gif

Interligando a la captura de paquetes - Perspectiva del cliente

dhcp-wlc-05.gif

En el tiro de pantalla de la captura de paquetes del lado del cliente arriba, la diferencia principal entre el cliente que la captura en el modo de representación es el IP real del servidor DHCP se considera en los paquetes de la oferta y Ack en vez de la dirección IP virtual del regulador.

Interligando a la captura de paquetes - Perspectiva del servidor

dhcp-wlc-06.gif

En la captura de paquetes atada con alambre el tiro de pantalla sobre usted puede ver que el paquete 40 es el pedido de DHCP interligado transmitido del probar cliente 00:40:96:b6:44:51 a la red alámbrica.

Ejemplo del configuración de Bridging

Para habilitar la funcionalidad de Bridging del DHCP en el regulador, usted debe inhabilitar la característica del proxy del DHCP en el regulador. En el 4.2.x.x cifra esto puede ser logrado solamente en el CLI usando estos comandos:

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

Si el servidor DHCP no existe en la misma red de la capa 2 que el cliente entonces el broadcast necesitará ser remitido al servidor DHCP en el gateway del cliente usando ayuda IP. Esto es una muestra de esta configuración:

Switch#conf t
Switch(config)#interface vlan <client vlan #>
Switch(config-if)#ip helper-address <dhcp server IP>

El DHCP que interliga la característica es una configuración global, así que afecta a todas las transacciones DHCP dentro del regulador. Usted necesita agregar ayuda IP las declaraciones en la infraestructura cableada para todos los VLA N necesarios en el regulador.

Resolución de problemas

Esto es un ejemplo de salida del debug de un regulador en el código de 4.2.205.0. Los debugs enumerados aquí fueron habilitados en el regulador CLI y la porción del DHCP de la salida fue 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

En esta salida de los debugs del DHCP, hay algunas indicaciones dominantes que el interligar del DHCP es funcionando en el regulador:

“del DHCP paquete Bridged con éxito al DS” — esto significa que el paquete DHCP original del cliente fue interligado, inalterado al sistema de distribución (DS). El DS es la infraestructura cableada.

“del DHCP paquete Bridged con éxito al STA” — este mensaje indica que el paquete DHCP fue interligado, inalterado a la estación (STA). El STA es la máquina del cliente que pide el DHCP.

También, usted ve el IP del servidor real enumerado en los debugs, que es 192.168.10.1. Si el proxy del DHCP fuera funcionando en vez del DHCP que interligaba, usted vería a la dirección IP virtual del regulador enumerada para IP del servidor.

Advertencias

  • Por abandono, se habilita el proxy del DHCP.

  • Todos los reguladores que comunicarán deben tener la misma configuración de representación del DHCP.

  • El proxy del DHCP se debe habilitar para la opción DHCP 82 de trabajar.

DHCP que interliga antes de la versión 4.2

Antes de la versión de código 4.2 usted podría inhabilitar el proxy del DHCP en el regulador. Sin embargo, esto no interligó realmente los paquetes DHCP a la red alámbrica. Qué ocurrió antes de que 4.2 fueran que el regulador todavía proxied la comunicación del DHCP al servidor DHCP, no obstante el cliente sí mismo era informado del IP Address real del servidor DHCP en vez del envío la dirección IP virtual del regulador.

Servidor DHCP interno

El servidor DHCP interno fue introducido inicialmente para las sucursales donde no está disponible un servidor DHCP externo. Se diseña para soportar un pequeño con menos de la red inalámbrica diez AP que estén en la misma subred. El servidor interno proporciona los IP Addresses a los clientes de red inalámbrica, directo-conecta los AP, dispositivo-MODE AP en la interfaz de administración, y los pedidos de DHCP que se retransmiten de los AP. No es verdadero servidor DHCP de fines generales. Soporta solamente las funciones limitadas y no las escalará en un despliegue más grande.

Comparación del DHCP y de los modos internos del bridging

Los dos modos principales del DHCP en el regulador son proxy del DHCP o el interligar del DHCP. Con el DHCP interligando el regulador actúa más bién una parte posterior del DHCP con los AP autónomos. Un paquete DHCP entra en el AP vía una asociación del cliente a un SSID que se conecte a un VLA N. Entonces, el paquete DHCP sale ese VLA N. Si ayuda IP se define en el gateway de la capa 3 de ese VLA N, el paquete se remite a ese servidor DHCP vía el unicast dirigido. El servidor DHCP entonces responde detrás directamente a la interfaz de la capa 3 que remitió ese paquete DHCP. Con el proxy del DHCP, es la misma idea, pero toda la expedición se hace directamente en el regulador en vez de la interfaz de la capa 3 del VLA N. Por ejemplo, un pedido de DHCP viene adentro a la red inalámbrica (WLAN) del cliente, la red inalámbrica (WLAN) entonces cualquier uso que el servidor DHCP definió en el *or* de la interfaz del VLA N utilizará la función de la invalidación del DHCP de la red inalámbrica (WLAN) para remitir un paquete DHCP del unicast al servidor DHCP con el campo GIADDR de los paquetes DHCP completado para ser la dirección IP de la interfaz VLAN.

Servidor DHCP interno - Flujo de paquetes

dhcp-wlc-07.gif

Ejemplo interno de la configuración del servidor DHCP

Usted debe permitir al proxy del DHCP en el regulador para permitir que el servidor DHCP interno funcione. Esto se puede hacer vía el GUI bajo esta sección:

Controller->Advanced->DHCP  
(Note: Setting the DHCP proxy via the GUI is not available in all versions)

/image/gif/paws/110865/dhcp-wlc-08.gif

O vía el CLI:

Config dhcp proxy enable
Save config

Para habilitar el servidor DHCP interno, complete estos pasos:

  1. Defina un alcance que usted utilice para tirar de los IP Addresses (alcance de Server->DHCP del DHCP de Controller->Internal). Haga clic en New.

    dhcp-wlc-09.gif

  2. Señale cualquier su invalidación del DHCP a la dirección IP de la interfaz de administración de su regulador:

    dhcp-wlc-10.gif

    O, usted puede utilizar la opción DHCP de la configuración de la interfaz del regulador para la interfaz que usted desea utilizar el servidor DHCP interno.

    dhcp-wlc-11.gif

  3. Aseegurese que el proxy del DHCP está habilitado:

    dhcp-wlc-12.gif

Resolución de problemas

Hacer el debug del servidor DHCP interno es típicamente una cuestión de encontrar a un cliente que esté teniendo un problema que consigue una dirección IP. Usted necesita ejecutar estos debugs:

debug client <MAC ADDRESS OF CLIENT>

El cliente del debug es una macro que habilita estos debugs para usted mientras que se centra el debug hacia fuera solamente en el MAC Address del cliente que usted ha ingresado:

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

El principal por problemas de DHCP es el comando debug dhcp packet enable que es habilitado automáticamente por el comando client del debug.

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 = 1.1.1.1 
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 

Borrar los arriendos del DHCP en el servidor DHCP interno WLC

Con la versión 7.0.98 del regulador del Wireless LAN, usted puede publicar este comando para borrar los arriendos del DHCP en el servidor DHCP interno del WLC:

config dhcp clear-lease <all/IP Address>

Aquí tiene un ejemplo:

config dhcp clear-lease all

Advertencias

  • El proxy del DHCP se debe habilitar para que el servidor DHCP interno funcione.

  • Uso del DHCP al puerto 1067 al usar el servidor DHCP interno, que es afectado por el CPU ACL.

  • El servidor DHCP interno escucha en el Loopback Interface del regulador vía el puerto 67 UDP de 127.0.0.1.

Interfaz del usuario final

  • El comando disable del proxy DHCP de los config implica el uso de la función de Bridging del DHCP. Esto es comando global (no un comando de la por-red inalámbrica (WLAN)).

  • Para que los clientes experimenten el comportamiento constante con los despliegues existentes, el proxy del DHCP seguirá habilitado por abandono.

  • Cuando se inhabilita el proxy del DHCP, el servidor DHCP interno no se puede utilizar por los WLAN locales. El Bridging Operation no es constante con las operaciones requeridas para reorientar un paquete al servidor interno. El interligar realmente significa el bridging, a excepción del 802.11 a la conversión del Ethernet II, los paquetes DHCP se pasa sin modificar del túnel del LWAPP al VLA N del cliente (y viceversa).

  • Cuando se habilita el proxy, un servidor DHCP se debe configurar en la interfaz de la red inalámbrica (WLAN) (o en la red inalámbrica (WLAN) sí mismo) para que la red inalámbrica (WLAN) sea habilitada. Ningún servidor necesita ser configurado cuando se inhabilita el proxy pues estos servidores no se utilizan.

  • Cuando un usuario intenta habilitar el proxy del DHCP, usted internamente verifica que todos los WLAN (o las interfaces asociadas) tengan un servidor DHCP configurado. Si no, la operación del permiso falla.

DHCP requerido

La configuración del avance de la red inalámbrica (WLAN) tiene una opción que requiera a los usuarios pasar el DHCP antes de entrar el estado de FUNCIONAMIENTO (un estado donde estará capaz el cliente de pasar el tráfico a través del regulador). Esta opción requiere al cliente hacer un pedido de DHCP completo o medio. El punto principal que el regulador está mirando del cliente es un pedido de DHCP y un ACK que se vuelven del servidor DHCP. Mientras el cliente haga estos pasos, el cliente pasará el paso obligatorio del DHCP y se trasladará al estado de FUNCIONAMIENTO.

dhcp-wlc-13.gif

L2 y L3 que vagan por

L2 - Vague por — Si el cliente tiene un arriendo válido del DHCP y realiza un L2 vaga por entre dos diversos reguladores en la misma red L2, el cliente no debe necesitar el re-DHCP y la entrada del cliente se debe mover totalmente al nuevo regulador desde el regulador original. Entonces, si el cliente necesita el DHCP otra vez, el interligar del DHCP o el proceso del proxy en el regulador actual transparente interligaría el paquete otra vez.

L3 – Vague por — En un L3 vague por el escenario que el cliente se está moviendo entre 2 diversos reguladores en diversas redes L3. En esta situación aseguran al regulador original y se enumeran al cliente en la tabla del cliente en el nuevo regulador no nativo. Durante asegurar el escenario el DHCP del cliente es dirigido por el regulador del ancla pues los datos del cliente son tunneled dentro de un túnel de EoIP entre los reguladores no nativos y del ancla.

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 110865