Sans fil : Contrôleurs de réseau local sans fil de la gamme Cisco 4400

DHCP avec contrôleur de réseau local sans fil

16 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Les clients utilisant des solutions de Cisco Unified Wireless avaient signalé des questions avec le support DHCP fourni sur le contrôleur LAN Sans fil (WLC). Certains de ces problèmes sont des erreurs de programmation ou des problèmes de débogage. D'autres sont causés par un manque de compréhension de la mise en oeuvre de DHCP.

Ce document décrit les différents fonctionnements de DHCP sur le contrôleur sans-fil, qui fournit cohérent et les informations précises aux clients dans un effort de réduire les questions relatives de client et des cas TAC.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Serveur DHCP externe

Le WLC prend en charge deux modes des fonctionnements de DHCP au cas où un serveur DHCP externe serait utilisé :

  • Mode proxy DHCP

  • DHCP jetant un pont sur le mode

Le mode proxy DHCP sert de fonction d'aide DHCP pour réaliser une meilleurs Sécurité et contrôle de transaction DHCP entre le serveur DHCP et les clients sans fil. Le DHCP jetant un pont sur le mode fournit une option de rendre le rôle du contrôleur dans la transaction DHCP entièrement transparent aux clients sans fil.

Comparaison de proxy DHCP et de modes de transition

Manipulation du DHCP de client Mode proxy DHCP DHCP jetant un pont sur le mode
Modifiez le giaddr Oui Non
Modifiez le siaddr Oui Non
Modifiez le contenu de paquet Oui Non
Offres redondantes non expédiées Oui Non
Support de l'option 82 Oui Non
Émission à Unicast Oui Non
Support de Protocole BOOTP Non Serveur
RFC Non-conforme Le proxy et l'agent de relais ne sont pas exactement le même concept. Le DHCP jetant un pont sur le mode est recommandé pour la totale conformité RFC. Non

Mode proxy DHCP

Le proxy DHCP n'est pas idéal pour tous les environnements de réseau. Le contrôleur modifie et transmet par relais toutes les transactions DHCP pour fournir la fonction d'aide, et aborde certains problèmes de sécurité.

L'adresse IP virtuelle du contrôleur est normalement utilisée comme adresse IP source de toutes les transactions DHCP au client. En conséquence, la vraie adresse IP de serveur DHCP n'est pas exposée dans le ciel. Cet IP virtuel est affiché dans la sortie de débogage pour des transactions DHCP sur le contrôleur. Cependant, utilisant l'adresse IP virtuelle peut entraîner des questions sur certains types de clients.

L'exécution de mode proxy DHCP met à jour le même comportement pour des protocoles symétriques et asymétriques de mobilité.

Quand les plusieurs offres proviennent des serveurs DHCP externes, le proxy DHCP sélectionne normalement le premier qui entre et place l'adresse IP du serveur dans la structure de données de client. En conséquence, toutes les transactions suivantes passent par le même serveur DHCP jusqu'à ce qu'une transaction échoue après des relances. En ce moment, le proxy sélectionne un serveur DHCP différent pour le client.

Le proxy DHCP est activé par défaut. Tous les contrôleurs qui communiqueront doivent avoir le même paramètre de proxy DHCP.

Remarque: Le proxy DHCP doit être activé afin de l'option 82 DHCP de fonctionner correctement.

Écoulement de paquet de proxy

dhcp-wlc-01.gif

Capture de paquet de proxy

Quand le contrôleur est dans le mode proxy DHCP, il dirige non seulement des paquets DHCP vers le serveur DHCP, il construit réellement de nouveaux paquets DHCP pour expédier au serveur DHCP. Toutes les options DHCP qui sont présentes dans des paquets DHCP du client sont copiées dans des paquets DHCP du contrôleur. Les exemples de tir d'écran suivant affichent ceci pour un paquet de requête DHCP.

Point de vue de client

Ce tir d'écran est d'une capture de paquet prise du point de vue de clients. Il affiche qu'un DHCP les découvrent, offre DHCP, requête DHCP, et un DHCP ACK. La requête DHCP est mise en valeur et le détail de protocole de BOOTP est développé affichant les options DHCP.

dhcp-wlc-02.gif

Point de vue de serveur

Ce tir d'écran est d'une capture de paquet prise du point de vue du serveur. Semblable à l'exemple précédent, il affiche qu'un DHCP les découvrent, offre DHCP, requête DHCP, et un DHCP ACK. Cependant, ce sont des paquets que le contrôleur a construits en fonction du proxy DHCP. De nouveau, la requête DHCP est mise en valeur et le détail de protocole de BOOTP est développé affichant les options DHCP. Notez qu'ils sont identiques que dans le paquet de requête DHCP de clients. Notez également que le proxy WLC transmet par relais des adresses de paquet et de paquet de point culminant.

dhcp-wlc-03.gif

Exemple de configuration de proxy

Pour utiliser le contrôleur comme proxy DHCP, la caractéristique de proxy DHCP doit être activée sur le contrôleur. Par défaut, cette caractéristique est activée. Pour activer le proxy DHCP, la commande suivante CLI doit être utilisée. En outre, dans les codes 4.2.x.x, ceci peut seulement être accompli dans le CLI.

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

DHCP Proxy Behavior: enabled

Pour que le proxy DHCP fonctionne, un serveur DHCP primaire doit être configuré sur chaque interface de contrôleur qui exige des services DHCP. Un serveur DHCP peut être configuré sur l'interface de gestion, interface d'AP-gestionnaire, et sur des interfaces dynamiques. Les commandes suivantes CLI peuvent être utilisées pour configurer un serveur DHCP pour chaque 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>

Le DHCP jetant un pont sur la caractéristique est un paramètre général, ainsi il affecte toutes les transactions DHCP dans le contrôleur.

Dépannage

C'est la sortie de la commande d'enable de paquet de debug dhcp. Le débogage affiche un contrôleur recevant une requête DHCP d'un client avec l'adresse MAC 00:40:96:b4:8c:e1, transmettant une requête DHCP au serveur DHCP, recevant une réponse du serveur DHCP, et envoyant une offre DHCP au client.

(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

Mises en garde

  • Les problèmes d'interopérabilité peuvent exister entre un contrôleur avec le proxy DHCP activé et les périphériques agissant en tant que Pare-feu et serveur DHCP. C'est très probablement dû au composant de Pare-feu du périphérique car les Pare-feu généralement ne répondent pas aux demandes de proxy. Le contournement pour cette question est de désactiver le proxy DHCP sur le contrôleur.

  • Quand un client est dans l'état DHCP REQ sur le contrôleur, le DHCP de baisses de contrôleur informent des paquets. Le client n'entrera pas dans un état de PASSAGE sur le contrôleur (ceci est exigé pour que le client passe le trafic) jusqu'à ce qu'il reçoive un DHCP découvrent le paquet du client. Le DHCP informent des paquets sont expédiés par le contrôleur quand le proxy DHCP est désactivé.

  • Tous les contrôleurs qui communiqueront doivent avoir le même paramètre de proxy DHCP.

DHCP jetant un pont sur le mode

Le DHCP jetant un pont sur la caractéristique est conçu pour rendre le rôle du contrôleur dans la transaction DHCP entièrement transparent au client. Excepté le 802.11 à la conversion d'Ethernet II, des paquets du client pont non modifiés du tunnel LWAPP au VLAN du client (ou du tunnel d'EoIP dans le cas d'itinérance L3). De même, excepté Ethernet II à la conversion de 802.11, des paquets en client pont non modifiés du VLAN du client (ou du tunnel d'EoIP dans le cas d'itinérance L3) au tunnel LWAPP. Pensez à ceci en tant que câblage d'un client dans un switchport et du client exécutant une transaction traditionnelle DHCP.

Exécutions de transition DHCP - Transition de l'écoulement de paquet

dhcp-wlc-04.gif

Jetant un pont sur la capture de paquet - Point de vue de client

dhcp-wlc-05.gif

Dans le tir d'écran de capture de paquet de côté client ci-dessus, la principale différence entre le client que la capture dans le mode proxy est le vrai IP du serveur DHCP est vue dans les paquets d'offre et ACK au lieu de l'adresse IP virtuelle du contrôleur.

Jetant un pont sur la capture de paquet - Point de vue de serveur

dhcp-wlc-06.gif

Dans la capture de câble de paquet le tir d'écran au-dessus de vous peut voir que le paquet 40 est l'émission traversière de requête DHCP du client 00:40:96:b6:44:51 de test au réseau câblé.

Transition de l'exemple de configuration

Pour activer le DHCP jetant un pont sur la fonctionnalité sur le contrôleur, vous devez désactiver la configuration de proxy DHCP sur le contrôleur. Dans le 4.2.x.x code ceci peut seulement être accompli dans le CLI utilisant ces commandes :

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

Si le serveur DHCP n'existe pas sur le même réseau de la couche 2 que le client alors l'émission devra être expédié au serveur DHCP à la passerelle de client utilisant une aide d'IP. C'est un échantillon de cette configuration :

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

Le DHCP jetant un pont sur la caractéristique est un paramètre général, ainsi il affecte toutes les transactions DHCP dans le contrôleur. Vous devez ajouter des déclarations d'aide d'IP dans l'infrastructure câblée pour tous les VLAN nécessaires sur le contrôleur.

Dépannage

C'est un exemple de sortie de débogage d'un contrôleur sur le code de 4.2.205.0. Met au point répertorié ici ont été activés sur le contrôleur CLI et la partie DHCP de la sortie a été extraite pour ce document.

(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

Dans cette sortie de débogage DHCP, il y a quelques indications principales que la transition DHCP est en service sur le contrôleur :

Le « DHCP a avec succès jeté un pont sur le paquet au DS » — ceci signifie que le paquet DHCP d'origine du client pont, inchangé au système de distribution (DS). Le DS est l'infrastructure câblée.

« Paquet avec succès traversier DHCP à STA » — ce message indique que le paquet DHCP pont, inchangé à la station (STA). Le STA est la machine cliente demandant le DHCP.

En outre, vous voyez que l'IP réel de serveur répertorié dans met au point, qui est 192.168.10.1. Si le proxy DHCP était en service au lieu du DHCP jetant un pont sur, vous verriez l'adresse IP virtuelle du contrôleur répertoriée pour l'IP de serveur.

Mises en garde

  • Par défaut, le proxy DHCP est activé.

  • Tous les contrôleurs qui communiqueront doivent avoir le même paramètre de proxy DHCP.

  • Le proxy DHCP doit être activé pour l'option 82 DHCP de fonctionner.

DHCP jetant un pont sur avant version 4.2

Avant que la release de 4.2 codes vous pourrait désactiver le proxy DHCP sur le contrôleur. Cependant, ceci n'a pas jeté un pont sur réellement les paquets DHCP au réseau câblé. Ce qui s'est produit avant que 4.2 aient été que le contrôleur proxied toujours la transmission DHCP au serveur DHCP, toutefois le client lui-même était au courant de la vraie adresse IP du serveur DHCP au lieu de l'envoi l'adresse IP virtuelle du contrôleur.

Serveur DHCP interne

Le serveur DHCP interne a été introduit au commencement pour des succursales où un serveur DHCP externe n'est pas disponible. Il est conçu pour prendre en charge un petit réseau Sans fil à moins de dix aps qui sont sur le même sous-réseau. Le serveur interne fournit des adresses IP aux clients sans fil, les aps liés directement, l'appliance-mode aps sur l'interface de gestion, et les requêtes DHCP qui sont transmises par relais des aps. Ce n'est pas un véritable serveur DHCP d'usage universel. Il prend en charge seulement la fonctionnalité limitée et ne la mesurera pas dans un plus grand déploiement.

Comparaison des modes internes DHCP et de transition

Les deux modes principaux DHCP sur le contrôleur sont proxy DHCP ou transition DHCP. Avec le DHCP jetant un pont sur le contrôleur agit plutôt un DHCP de retour avec AP autonomes. Un paquet DHCP entre dans AP par l'intermédiaire d'une association de client à un SSID qui est lié à un VLAN. Puis, le paquet DHCP sort ce VLAN. Si une aide IP est définie sur la passerelle de la couche 3 de ce VLAN, le paquet est expédié à ce serveur DHCP par l'intermédiaire de l'unicast dirigé. Le serveur DHCP répond alors de retour directement à l'interface de la couche 3 qui a expédié ce paquet DHCP. Avec le proxy DHCP, c'est la même idée, mais tout les expédition est fait directement au contrôleur au lieu de l'interface de la couche 3 du VLAN. Par exemple, une requête DHCP entre au WLAN du client, le WLAN alors l'un ou l'autre d'utilisation que le serveur DHCP défini sur le *or* de l'interface du VLAN emploiera la fonction de priorité DHCP du WLAN pour expédier un paquet DHCP d'unicast au serveur DHCP avec le champ GIADDR de paquets DHCP complété pour être l'adresse IP de l'interface VLAN.

Serveur DHCP interne - Écoulement de paquet

dhcp-wlc-07.gif

Exemple interne de configuration du serveur DHCP

Vous devez permettre au proxy DHCP sur le contrôleur de permettre au serveur DHCP interne pour fonctionner. Ceci peut être fait par l'intermédiaire du GUI sous cette section :

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

Ou par l'intermédiaire du CLI :

Config dhcp proxy enable
Save config

Pour activer le serveur DHCP interne, terminez-vous ces étapes :

  1. Définissez une portée que vous utiliserez pour tirer des adresses IP (portée DHCP Server->DHCP de Controller->Internal). Cliquez sur New.

    dhcp-wlc-09.gif

  2. Indiquez l'un ou l'autre de votre dépassement DHCP l'adresse IP d'interface de gestion de votre contrôleur :

    dhcp-wlc-10.gif

    Ou, vous pouvez utiliser l'option DHCP de la configuration d'interface de contrôleur pour l'interface que vous souhaitez utiliser le serveur DHCP interne.

    dhcp-wlc-11.gif

  3. Assurez-vous que le proxy DHCP est activé :

    dhcp-wlc-12.gif

Dépannage

Le débogage du serveur DHCP interne est typiquement une question de trouver un client qui a un problème obtenant une adresse IP. Vous devez exécuter ces derniers met au point :

debug client <MAC ADDRESS OF CLIENT>

Le client de débogage est une macro-instruction qui active ces derniers met au point pour vous tout en concentrant le débogage seulement sur l'adresse MAC de client que vous avez écrite :

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

Le principal pour des problèmes de DHCP est la commande d'enable de paquet de debug dhcp qui est activée automatiquement par l'ordre de client de débogage.

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 

Effacer les baux DHCP sur le serveur DHCP interne du WLC

Avec la version 7.0.98 Sans fil de contrôleur LAN, vous pouvez émettre cette commande afin d'effacer les baux DHCP sur le serveur interne DHCP du WLC :

config dhcp clear-lease <all/IP Address>

Voici un exemple :

config dhcp clear-lease all

Mises en garde

  • Le proxy DHCP doit être activé pour que le serveur DHCP interne fonctionne.

  • Utilisation de DHCP au port 1067 à l'aide du serveur DHCP interne, qui est affecté par l'ACL CPU.

  • Le serveur DHCP interne écoute sur l'interface de bouclage de contrôleur par l'intermédiaire du port 67 d'UDP de 127.0.0.1.

Interface d'utilisateur final

  • La commande de débronchement de config dhcp proxy implique l'utilisation du DHCP jetant un pont sur la fonction. C'est une commande globale (pas une commande par-WLAN).

  • Pour que les clients éprouvent à comportement cohérent avec des déploiements existants, le proxy DHCP demeurera activé par défaut.

  • Quand le proxy DHCP est désactivé, le serveur DHCP interne ne peut pas être utilisé par les gens du pays WLAN. L'exécution de transition n'est pas compatible aux exécutions exigées pour réorienter un paquet au serveur interne. La transition vraiment signifie la transition, excepté le 802.11 à la conversion d'Ethernet II, des paquets DHCP sont passées non modifié du tunnel LWAPP au VLAN du client (et vice-versa).

  • Quand le proxy est activé, un serveur DHCP doit être configuré sur l'interface du WLAN (ou dans le WLAN lui-même) pour que le WLAN soit activé. Aucun serveur ne doit être configuré quand le proxy est désactivé car ces serveurs ne sont pas utilisés.

  • Quand les tentatives d'un utilisateur d'activer le proxy DHCP, vous vérifient intérieurement que tous les WLAN (ou interfaces associées) ont un serveur DHCP configuré. Sinon, l'exécution d'enable échoue.

DHCP requis

La configuration à l'avance WLAN a une option qui exige des utilisateurs de passer le DHCP avant d'aller dans l'état de PASSAGE (un état où le client pourra passer le trafic par le contrôleur). Cette option exige du client de faire une pleine ou demi requête DHCP. La principale chose que le contrôleur regarde du client est une requête DHCP et un ACK revenant du serveur DHCP. Tant que le client fait ces étapes, le client passera l'étape priée par DHCP et se déplacera à l'état de PASSAGE.

dhcp-wlc-13.gif

Itinérance L2 et L3

L2 - Errez — Si le client a un bail valide DHCP et exécute un L2 errent entre deux contrôleurs différents sur le même réseau L2, le client ne devrait pas avoir besoin de re-DHCP et l'entrée de client devrait être complètement déplacée au nouveau contrôleur du contrôleur d'origine. Puis, si le client a besoin de DHCP de nouveau, le processus de transition DHCP ou de proxy sur le contrôleur en cours jetterait un pont sur d'une manière transparente le paquet de nouveau.

L3 ? Errez — Dans un L3 errez le scénario que le client se déplace entre 2 contrôleurs différents dans différents réseaux L3. Dans cette situation le client est ancré au contrôleur d'origine et répertorié dans la table de client sur le nouveau contrôleur étranger. Pendant l'ancrage du scénario le DHCP du client est manipulé par le contrôleur d'ancre pendant que les données de client sont percées un tunnel dans un tunnel d'EoIP entre les contrôleurs étrangers et d'ancre.

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 110865