Contourner les limites DHCP de certains routeurs Cisco

• Imprimer

Un problème de protocole de configuration dynamique de l'hôte empêche les utilisateurs sans fil de se connecter. Si l'absence de solution permanente oblige à recourir à une méthode de contournement, elle évite cependant de revenir à une configuration manuelle.

Le protocole de configuration dynamique de l'hôte (Dynamic Host-Configuration Protocol, DHCP) présente de nombreux avantages. En particulier, il fait gagner du temps en attribuant des adresses IP et d'autres attributs aux périphériques en réseau, évitant aux professionnels de l'IT à le faire manuellement. Cependant, d'autres problèmes peuvent parfois survenir et faire perdre du temps autrement. C'est le cas des commutateurs de châssis Layer 3 Catalyst 6500 et 9600 de Cisco utilisés comme commutateurs de distribution pour le réseau et reliant différents groupes de bâtiments. En général, le DHCP est déployé sur un serveur pour fournir des adresses IP, des masques de sous-réseau, des passerelles par défaut et des informations sur le serveur DNS. Mais le DHCP peut également être déployé sur des commutateurs et des routeurs, y compris ceux de Cisco, et c'est une méthode utilisée dans notre réseau. Plus précisément, les capacités de serveur DHCP des commutateurs Cisco sont utilisées pour distribuer des adresses IP aux appareils du réseau sans fil afin de segmenter le trafic sans fil de l'infrastructure câblée, qui utilise un serveur DHCP distinct.

Exploiter ce support du DHCP sur les commutateurs présente d'autres avantages, en particulier dans les petits réseaux : il permet en effet de réduire les coûts puisque le commutateur fait double emploi, ce qui évite l'achat d'un serveur distinct pour le DHCP et sa gestion. Pendant de nombreuses années, le commutateur de châssis Catalyst 6500 de Cisco de notre réseau a servi à cela. Mais, comme notre entreprise a décidé d'adopter un réseau défini par logiciel (SDN), le temps était venu de passer au commutateur Catalyst 9600, qui a succédé au Catalyst 6500, et de profiter de ses capacités d'automatisation et de ses vitesses de port plus élevées. Sauf que, les deux commutateurs présentaient le même problème : les pools d'adresses DHCP se figeaient. Les appareils qui essayaient de se joindre au réseau ne pouvaient pas le faire parce qu'ils ne recevaient pas d'adresses IP, si bien que les utilisateurs finaux généraient des tickets de panne en disant que le réseau sans fil était hors service.

Une solution temporaire

Les commutateurs peuvent fournir des informations sur les adresses IP DHCP disponibles à l'aide de la commande « show ip dhcp pool ». Cette commande renvoie une réponse qui peut ressembler à cela :

Routeur# show ip dhcp pool 1

Pool 1 :

Utilization mark (high/low)  : 85 / 15

Subnet size (first/next)        : 24 / 24 (autogrow)

VRF name                           : abc

Total addresses                  : 28

Leased addresses              : 11

Pending event                    : none

Current index           IP address range                Leased addresses

10.1.1.12                  10.1.1.1 - 10.1.1.14            11

10.1.1.17                  10.1.1.17 - 10.1.1.30          0

Interface Ethernet0/0 address assignment

10.1.1.1 255.255.255.248

10.1.1.17 255.255.255.248 secondary

Au fil du temps, nos ingénieurs réseau ont remarqué que quand les utilisateurs avaient des difficultés à obtenir des adresses IP, l'affichage de la commande « show ip dhcp pool » montrait que l'index actuel Current address était de 0.0.0.0, mais qu'il y avait aussi des adresses encore disponibles dans le pool. Cela pourrait ressembler à quelque chose du genre :

Current index  IP address range                   Leased/Excluded/Total

0.0.0.0             172.30.52.97 - 172.30.53.128    0   /   7    / 30

Les pools fonctionnaient correctement au moment de leur mise en place il y a trois ans environ, puis le problème est apparu périodiquement sans événement déclencheur apparent. Il n'affectait pas tous les commutateurs en même temps, mais plutôt certains commutateurs de façon sporadique sur le réseau. Pendant cette période, de nouveaux bâtiments et de nouvelles zones ont été ajoutés au réseau sans fil, et de nouveaux terminaux se sont connectés. Le problème était suffisamment courant pour que, chaque fois que le service d'assistance nous contactait au sujet d'un problème de connexion au réseau sans fil, nos étapes de dépannage consistaient à vérifier que les points d'accès Wi-Fi étaient actifs et que le pool DHCP n'était pas gelé. Si c'était le cas, nous suivions les conseils du centre d'assistance technique Technical Assistance Center (TAC) de Cisco, supprimions le pool DHCP et le réactivions. Le pool était ainsi réinitialisé et le DHCP recommençait à distribuer des adresses. Ce protocole permettait de corriger le problème pendant un certain temps.

Cette solution de contournement était effectuée à distance et ne prenait que quelques secondes, car nous avions copié et collé les commandes delete et readd dans le commutateur afin de gagner du temps. Nous avons souvent dû supprimer les pools et exécuter la commande readd sur les Catalyst 6500, et nous attendions avec impatience les Catalyst 9600 de remplacement pour voir s'ils allaient résoudre le problème. Mais ce ne fut pas le cas. Le problème a continué à se produire, pas tous les jours, mais de temps en temps, généralement signalé comme une panne de réseau. D'autres entreprises ont remonté des problèmes similaires qu'elles ont résolus en utilisant la même solution de contournement. Malgré ce bogue, le DHCP permet de segmenter le réseau sans fil et, même s'il est nécessaire d'exécuter une commande readd périodiquement sur les pools DHCP, cette méthode est beaucoup plus efficace qu'une gestion manuelle du DHCP.