dhcp3 failover

Support Debian
#1

Bonjour à tous,

j’ai, dans mon entreprise, un serveur dhcp (dhcp3+bind9) sous lenny. Le serveur commence à montrer des signes de faiblesses au niveau materiel. Je cherche donc à faire un serveur secondaire (failover).

Les adresses attribuées aux clients sont statiques. Les fichiers se trouvant dans /etc/dhcp3/ sont répliqués depuis le serveur principal vers le secondaire.

Lorsque je stoppe dhcp3 sur le primaire, j’ai ce type de réponse dans le syslog du secondaire:

DHCPDISCOVER from 00:1d:d9:55:e5:e4 via eth4: peer holds all free leases DHCPREQUEST for 172.30.14.112 from 00:13:ce:33:b7:8c via eth4: not responding (recovering) DHCPDISCOVER from 00:0b:ac:6e:27:40 via eth2: network pedagogie: no free leases

Rien à faire, il n’attribue pas d’adresses ip aux clients…

Si quelqu’un peut m’aider svp… merci d’avance

#2

Salut,

DHCPDISCOVER, and cie, sont des messages que tu vois quand la machine fait une requêtes dhcp… Quand il demande une adresse, si tu veux.

DHCPDISCOVER (pour localiser les serveurs DHCP disponibles)
DHCPOFFER (réponse du serveur à un paquet DHCPDISCOVER, qui contient les premiers paramètres)
DHCPREQUEST (requête diverse du client pour par exemple prolonger son bail)
DHCPACK (réponse du serveur qui contient des paramètres et l’adresse IP du client)
DHCPNAK (réponse du serveur pour signaler au client que son bail est échu ou si le client annonce une mauvaise configuration réseau)
DHCPDECLINE (le client annonce au serveur que l’adresse est déjà utilisée)
DHCPRELEASE (le client libère son adresse IP)
DHCPINFORM (le client demande des paramètres locaux, il a déjà son adresse IP)

Toi, tu as :
DHCPDISCOVER from 00:1d:d9:55:e5:e4 via eth4: peer holds all free leases
DHCPREQUEST for 172.30.14.112 from 00:13:ce:33:b7:8c via eth4: not responding (recovering)
DHCPDISCOVER from 00:0b:ac:6e:27:40 via eth2: network pedagogie: no free leases

Ton secondaire recoit une demande de localisation de serveur disponible de la part de la machine dont la carte à pour adresse MAC 00:1d:d9:55:e5:e4.
La machine dont la carte réseau est 00:13:ce:33:b7:8c fait une autre demande à partir de son interface eth4. Il n’obtient pas de réponse.
La machine dont la carte est 00:0b:ac:6e:27:40 emet un dhcpdiscover via son interface eth2.
Il n’y a pas d’autres messages? Si les clients émettent leurs requêtes vers le secondaire, c’est qu’au moins la redirection fonctionne et le serveur dhcp répond (sinon tu n’aurais rien dans le log, n’est ce pas?). S’il n’attribue pas d’adresse, c’est qu’il y a peut-être un problème avec ton fichier de configuration?

#3

Merci pour ta reponse.

je remettrai demain lorsque je serai à mon travail une partie du log. Quand tu parles de fichiers de conf, tu parles des fichiers où sont déclarés les adresses mac et ip ou de la conf du serveur dhcp?

Dans ceux des différents réseaux, c’est une copie du primaire et dans la conf du serveur, il est pratiquement identique sauf que l’on déclare qu’il est le secondaire. Je mettrai également le fichiers de conf des 2 serveurs.

merci encore pour ta réponse.

#4

mmmmm Dans ce cas, si les deux fichiers sont identiques, essaie d’inverser les deux serveurs - uniquement à des fins de tests.

Je m’explique : Le serveur primaire fonctionne, d’après ce que je comprends. Le secondaire a une configuration qui normalement fonctionne, mais qui ne renvoie pas de réponse (c’est comme ça que je l’interprète : je n’ai pas la prétention d’être the best of the best). Et tu dis que le secondaire à quasiment la même configuration, à ceci près qu’il est déclaré comme secondaire. Donc, autant en profiter : déclare le secondaire comme primaire et le primaire comme secondaire - c’est provisoire, bien sûr - Et refait les mêmes tests.

Si le primaire réponds correctement : alors le fichier de configuration du serveur dhcp est ok sur les deux machines, ce qui sera utile puisque tu auras ça de moins à checker. Dans le cas contraire, il doit y manquer quelque chose (fatalitas!), ce qui t’aura déjà permit de cerner l’origine du problème.

Après vois ce que ça donne avec la bascule dans ce sens et donnne nous le résultat.

C’est juste une idée :slightly_smiling:

#5

Hi,

Au fait, je ne sais pas à quoi tu penses quand tu déclares : “des fichiers où sont déclarés les adresses mac et ip”, mais pour moi, ça, c’est le cache ARP:

sh-3.1# arp -a
(regarde le résultat)

Via ce cache, l’adresse MAC (adresse de la carte réseau) est bindée avec l’interface, qui elle-même trouve sa correspondance dans le fichier /etc/network/interfaces : la couche arp, utilisée par le protocole du même nom, est une sous-couche qui fait la liaison entre la couche liaison et réseau du modèle OSI.

Ce n’est pas un “fichier”.
:slightly_smiling:

#6

salut,

il est difficile de faire le test que tu me proposes car il y a de nombreuses personnes qui travaillent… et ce serait plus qu’une flagellation pour moi… lol

dans le dossier /etc/dhcp3/ figure les fichiers concernant chaque réseau. dans ces fichiers sont déclarés les hosts. exemple:

host crocus { hardware ethernet 00:0b:db:96:b0:77; fixed-address xxx.xx.xx.xx; }

dans le dossier /etc/dnshosts/ on retrouve les hosts :

#7

dans le primaire, j’ai rajouté dans le fichier dhcpd.conf :

[code]#failover peer “dhcp” {

primary;

address xxx.xx.xx.xx; //du primaire

port 519;

#            peer address xxx.xx.xx.xx; du secondaire
 #           peer port 520;
  #          max-response-delay 60;
   #         max-unacked-updates 10;
#	mclt 600;
#	split 128;
#	}

[/code]
les lignes sont commentées puisque ça ne fonctionnait pas

et dans le secondaire :

failover peer "dhcp" { secondary; address xxx.xx.xx.xx; //du secondaire port 520; peer address xxx.xx.xx.xx; //du primaire peer port 519; max-response-delay 60; max-unacked-updates 10; }

#8

hi,

Evidemment, si y a du monde dessus muarf, tu ne peux pas faire tout et n’importe quoi.
(J’en connais pourtant, au boulot, qui ne se gênent pas, de mon côté… lol)

Questions cons :
-Les ports sont ouverts sur les clients pour que le serveur puissent leur répondre?
-Si tu fais un traceroute vers les machines clientes à partir du secondaire, tu atteints tes machines? (les requêtes arrivent sur ton secondaire, ok, mais dans l’autre sens?)
-Tu n’as rien d’autres dans tes logs?

Ensuite, en fouinant sur le web :

J’ai trouvé cette doc (peut-être pourrais-tu déjà comparer avec ce que tu as?)

(ça, c’est juste pour la détente:)
cafenware.com/la-rache/index … 5af973a16b

Tiens, y a peut-être aussi des trucs utiles :
dthconnex.com/dns_dhcp.html

Tu as un fichier logs? Y a quoi dedans?

#9

Ma configuration sur dthconnex est fonctionnelle en production. Si tu as des remarques, elles sont les bienvenues.

Il me semble qu’il peut y avoir un soucis si les versions des serveur DHCPs ne sont pas les mêmes (à vérifier).

#10

Ah!!!

Attention à ça, en effet. J’ai déjà croisé des cas où des différences de versions de serveurs pouvaient jouer. Dans le cas du serveur DHCP je ne sais pas.

Par contre, on peut déjà vérifier les versions en effet.

Si tu fais un dpkg -l sur les serveurs, tu obtiens quels résultats?

#11

merci pour toutes ces infos… je vois ça aujourd’hui.

Sinon, en effet : le serveur primaire était sous etch et le secondaire sous lenny… dans ce cas, ça ne marche pas. j’ai du faire une mise à jour du primaire (les utilisateurs étaient heureux…

#12

:slightly_smiling:

Et ton secondaire? L’important, c’est qu’il soit heureux, lui aussi :slightly_smiling:

Quand tu auras downgradé, n’hésite pas à nous faire savoir ce que ça donne.