Project

General

Profile

Scénario #17296

Le service de relay DHCP doit démarrer après le réseau

Added by Karim Ayari about 7 years ago. Updated over 5 years ago.

Status:
Nouveau
Priority:
Normal
Assigned To:
force indigo
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Story points:
-
Remaining (hours):
0.00 hour
Velocity based estimate:

Description

Problème

Si le réseau met trop de temps à démarrer, il est possible que le service isc-dhcp-relay démarre avant qu’une ou plusieurs des interfaces qu’ils utilisent ne soient démarrées.

Notre gestion des services upstart ne permet pas d’utiliser le fichier .override pour corriger ce problème (python-pyeole:source:pyeole/service/module/upstart.py@acb5a09#L73) : si le fichier .override est présent, l’activation du service le supprime.

Proposition

Pour la 2.5.2.3.

Fournir un fichier de configuration upstart pour isc-dhcp-relay qui attende que le réseau soit réellement configuré pour démarrer (#17296#note-7) :

  1. Le fichier upstart est fourni dans /usr/share/doc/eole-dhcrelay/examples/
  2. En postinst :
    1. Sauvegarde du fichier upstart actuellement installé (dans /var/backup/eole-dhcrelay/)
    2. Écrasement de la configuration upstart par le script fourni dans /usr/share/doc/eole-dhcrelay/examples/
    3. Rechargement de la configuration upstart
  3. En prerm :
    1. Déplacer le fichier upstart depuis la sauvegarde /var/backup/eole-dhcrelay/ dans /etc/init/
    2. Suppression de /var/backup/eole-dhcrelay/ (qui doit être vide) en cas de purge

Demande initiale

nous constatons des problèmes avec le relai dhcp qui à priori surviennent toujours après une MAJ auto + reconfigure + reboot

En effet pour une raison qui nous est encore inconnue il ne fait plus son travail jusqu'à un restart du service.

Au moment où le problème se pose :

  • le process tourne toujours :
root@lacotiere:~# ps aux |grep relay
root      3467  0.0  0.1   5408  2696 ?        Ss   03:14   0:00 /usr/sbin/dhcrelay -d -q -4 -i eth2 -i eth3 192.168.220.10
root     20530  0.0  0.0   6176   840 pts/0    S+   08:45   0:00 grep --color=auto relay
root@lacotiere:~#
  • le port udp 67 est bien en écoute :
root@lacotiere:~# netstat -tanpu |grep relay
udp        0      0 0.0.0.0:67              0.0.0.0:*                           3467/dhcrelay   
udp        0      0 0.0.0.0:7103            0.0.0.0:*                           3467/dhcrelay   
udp6       0      0 :::22070                :::*                                3467/dhcrelay
  • rien dans les logs à part ce message qui apparait qu'une seule fois : probablement lié au reboot de la machine
2016-09-27T03:46:25.134112+02:00 lacotiere.0011326l.local dhcrelay: Discarding packet received on eth3 interface that has no IPv4 address assigned.
  • il ne répond plus aux requêtes
          Static-Route, Classless-Static-Route, Classless-Static-Route-Microsoft, Vendor-Option
08:52:02.290054 IP (tos 0x0, ttl 128, id 840, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 2c:44:fd:1b:4a:f0, length 300, xid 0x6260157b, secs 3328, Flags [none]
      Client-Ethernet-Address 2c:44:fd:1b:4a:f0
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Discover
        Client-ID Option 61, length 7: ether 2c:44:fd:1b:4a:f0
        Hostname Option 12, length 7: "A13-P01" 
        Vendor-Class Option 60, length 8: "MSFT 5.0" 
        Parameter-Request Option 55, length 12: 
          Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server
          Netbios-Name-Server, Netbios-Node, Netbios-Scope, Router-Discovery
          Static-Route, Classless-Static-Route, Classless-Static-Route-Microsoft, Vendor-Option
08:52:03.185808 IP (tos 0x0, ttl 128, id 805, offset 0, flags [none], proto UDP (17), length 329)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:1b:fc:80:29:56, length 301, xid 0xb7721b78, Flags [Broadcast]
      Client-Ethernet-Address 00:1b:fc:80:29:56
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Discover
        NOAUTO Option 116, length 1: Y
        Client-ID Option 61, length 7: ether 00:1b:fc:80:29:56
        Requested-IP Option 50, length 4: 172.18.108.13
        Hostname Option 12, length 10: "tbilen-P07" 
        Vendor-Class Option 60, length 8: "MSFT 5.0" 
        Parameter-Request Option 55, length 11: 
          Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server
          Netbios-Name-Server, Netbios-Node, Netbios-Scope, Router-Discovery
          Static-Route, Classless-Static-Route-Microsoft, Vendor-Option
        Vendor-Option Option 43, length 2: 220.0
  • dés que je relance le service :
08:59:45.547385 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 333)
    172.18.111.252.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 305, hops 1, xid 0x8e5f663a, secs 3072, Flags [Broadcast]
      Your-IP 172.18.109.158
      Server-IP 172.18.111.16
      Gateway-IP 172.18.111.252
      Client-Ethernet-Address 00:01:6c:cf:4b:5f
      file "/pxelinux.0" 
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: ACK
        Server-ID Option 54, length 4: 192.168.220.10
        Lease-Time Option 51, length 4: 36000
        Subnet-Mask Option 1, length 4: 255.255.252.0
        Domain-Name Option 15, length 20: "lycee-la-cotiere.lan" 
        Default-Gateway Option 3, length 4: 172.18.111.252
        Domain-Name-Server Option 6, length 4: 172.18.111.252
        Netbios-Name-Server Option 44, length 4: 192.168.220.10
        Netbios-Node Option 46, length 1: h-node

boot.log View (1.48 KB) Olivier FEBWIN, 12/05/2016 09:45 AM

Subtasks

Tâche #20787: AMon 2.5.2 : VLAN et dhcp-relayNouveau

Related issues

Related to Distribution EOLE - Tâche #17879: Étude de l’anomalie DHCP-Relay sur Amon Fermé 11/15/2016
Related to Distribution EOLE - Tâche #22719: dhcrelay échoue à se lancer au boot quand il y a beaucoup de vlans (amon 2.5.2) Fermé 11/27/2017

History

#1 Updated by Karim Ayari about 7 years ago

je viens de me rendre compte qu'il y a une mise à jour du paquet isc-dhcp-relay...

#2 Updated by Karim Ayari about 7 years ago

Le serveur qui a posé problème ce matin s'est mis à jour cette nuit mais n'a pas mis à jour le paquet isc-dhcp-relay alors qu'il apparait bien dans le Query-Auto

Paquets à mettre à jour : 
    isc-dhcp-client (4.2.4-7ubuntu12.7) (root)
    isc-dhcp-common (4.2.4-7ubuntu12.7) (root)
    isc-dhcp-relay (4.2.4-7ubuntu12.7) (root)

Dernière mise à jour :
2016-09-27 03:04:35,210: INFO - Mise à jour le mardi 27 septembre 2016 03:04:35
2016-09-27 03:04:35,210: INFO - Mise à jour le mardi 27 septembre 2016 03:04:35
2016-09-27 03:04:35,402: INFO - *** amon 2.5.2 (0011326L) ***
2016-09-27 03:04:35,451: INFO - Configuration du dépôt Ubuntu avec la source eole.ac-dijon.fr
2016-09-27 03:04:35,561: INFO - Configuration du dépôt EOLE avec la source eole.ac-dijon.fr
2016-09-27 03:05:07,398: INFO - Action list-upgrade pour root
2016-09-27 03:05:07,751: INFO - 4 nouveaux, 14 mis à jour, 0 à enlever
2016-09-27 03:05:07,752: INFO - Nouveaux paquets :
2016-09-27 03:05:07,752: INFO - linux-headers-3.13.0-96 (3.13.0-96.143) (root)
2016-09-27 03:05:07,752: INFO - linux-headers-3.13.0-96-generic (3.13.0-96.143) (root)
2016-09-27 03:05:07,752: INFO - linux-image-3.13.0-96-generic (3.13.0-96.143) (root)
2016-09-27 03:05:07,752: INFO - linux-image-extra-3.13.0-96-generic (3.13.0-96.143) (root)
2016-09-27 03:05:07,752: INFO - Paquets à mettre à jour :
2016-09-27 03:05:07,752: INFO - libgdk-pixbuf2.0-0 (2.30.7-0ubuntu1.6) (root)
2016-09-27 03:05:07,752: INFO - libgdk-pixbuf2.0-common (2.30.7-0ubuntu1.6) (root)
2016-09-27 03:05:07,752: INFO - libpython3.4-minimal (3.4.3-1ubuntu1~14.04.4) (root)
2016-09-27 03:05:07,753: INFO - libpython3.4-stdlib (3.4.3-1ubuntu1~14.04.4) (root)
2016-09-27 03:05:07,753: INFO - libssl1.0.0 (1.0.1f-1ubuntu2.21) (root)
2016-09-27 03:05:07,753: INFO - linux-generic (3.13.0.96.104) (root)
2016-09-27 03:05:07,753: INFO - linux-generic-lts-trusty (3.13.0.96.104) (root)
2016-09-27 03:05:07,753: INFO - linux-headers-generic (3.13.0.96.104) (root)
2016-09-27 03:05:07,753: INFO - linux-headers-generic-lts-trusty (3.13.0.96.104) (root)
2016-09-27 03:05:07,753: INFO - linux-image-generic (3.13.0.96.104) (root)
2016-09-27 03:05:07,753: INFO - linux-image-generic-lts-trusty (3.13.0.96.104) (root)
2016-09-27 03:05:07,753: INFO - openssl (1.0.1f-1ubuntu2.21) (root)
2016-09-27 03:05:07,754: INFO - python3.4 (3.4.3-1ubuntu1~14.04.4) (root)
2016-09-27 03:05:07,754: INFO - python3.4-minimal (3.4.3-1ubuntu1~14.04.4) (root)
2016-09-27 03:05:07,754: INFO - Action download-upgrade pour root
2016-09-27 03:06:04,810: INFO - Action dist-upgrade pour root
2016-09-27 03:07:26,500: INFO - Mise à jour OK
  • ce serveur a pour noyau
root@lacotiere:~# uname -a
Linux lacotiere 3.13.0-96-generic #143-Ubuntu SMP Mon Aug 29 20:15:47 UTC 2016 i686 i686 i686 GNU/Linux
root@lacotiere:~#

#3 Updated by Karim Ayari almost 7 years ago

encore cette semaine des serveurs mis à jour avec reboot
avec encore une mise à jour du noyau
le lendemain le relai dhcp ne fonctionne pas
pour le dernier en date il n'y a strictement rien dans les logs du relai dhcp

root@bejuit:/var/log/rsyslog/local/dhcrelay# ll dhcrelay.err.log
-rw-r----- 1 syslog adm 0 avril 18  2016 dhcrelay.err.log
root@bejuit:/var/log/rsyslog/local/dhcrelay# ll dhcrelay.info.log
-rw-r----- 1 syslog adm 0 nov.  15 06:28 dhcrelay.info.log
root@bejuit:/var/log/rsyslog/local/dhcrelay#

#4 Updated by Karim Ayari almost 7 years ago

pour celui de ce matin j'ai trouvé finalement la même chose dans le log info qui a tourné :

2016-11-15T03:05:40.181031+01:00 bejuit.0690105p.local dhcrelay: Discarding packet received on eth3 interface that has no IPv4 address assigned.

est-ce que nous ne retombons pas dans le même genre de phénomène que bastion et l'agent rvp, à savoir qu'il y a beaucoup d'interface (vlan) et que le relai dhcp se met en route au mauvais moment où les interfaces clientes et serveurs ne sont pas encore montées?!
sachant que j'utilise le relai dhcp sur les interfaces physiques eth2 et eth3

#5 Updated by Karim Ayari almost 7 years ago

nous avons 20 interfaces (en comptant lo)
dont 16 interfaces vlans

#6 Updated by Olivier FEBWIN almost 7 years ago

Nous rencontrons également un problème de dhcp-replay même sans maj...
Pourtant, comme pour Karim, le service tourne bien :

    root@amon25-0601407d:~# service isc-dhcp-relay status
    isc-dhcp-relay start/running, process 30350
    root@amon25-0601407d:~# ps fax|grep relay
    30350 ?        Ss     0:00 /usr/sbin/dhcrelay -d -q -4 -i eth3.30 -i eth0.160 10.160.238.2

Après un simple "service isc-dhcp-relay restart" ; le dhcp relai fait de nouveau bien son job.

#7 Updated by Daniel Dehennin almost 7 years ago

Je confirme le problème au démarrage avec 100 interfaces VLANs :

  1. le système démarre
  2. les interfaces sont configurées en parallèles, le script /etc/network/if-up.d/upstart est chargé d’envoyer le signal static-network-up une fois que toutes les interfaces sont configurées
  3. Au bout de deux fois 60 secondes, upstart démarre le reste du système sans attendre la fin du réseau

Le service isc-dhcp-relay démarre sur runlevel [2345], il fait donc parti des services qui démarre alors que le réseau n’est pas fini de démarré.

J’ai ajouté un fichier /etc/init/isc-dhcp-relay.override pour redéfinir la condition de démarrage :

root@amon:~# cat > /etc/init/isc-dhcp-relay.override <<EOF
start on (runlevel [2345] and static-network-up)
EOF

Et cela fonctionne.

#8 Updated by Daniel Dehennin almost 7 years ago

  • Assigned To set to Daniel Dehennin

#9 Updated by Olivier FEBWIN almost 7 years ago

le correctif n'a pas résolu le problème de relai dhcp que nous rencontrons sur Amiens.
Voir https://youtu.be/Kkbf4zNUeb0
Les requêtes dhcp ne sont visibles sur eth0.160 qu'après relance du démon isc-dhcp-relay

#10 Updated by Karim Ayari almost 7 years ago

pour ma part je ne parviens même pas à reproduire le problème sur ma plateforme :/ pour espérer tester.

#11 Updated by Karim Ayari almost 7 years ago

du coup j'ai posé le fichier sur un serveur qui n'a pas encore rebooté et qui n'est pas complétement à jour, à suivre

#12 Updated by Emmanuel GARETTE almost 7 years ago

J'ai rouvert la demande liée. Il vaut mieux mettre les commentaires dans la demande en court.

#13 Updated by Daniel Dehennin almost 7 years ago

Est-il possible de voir l’état des interfaces juste avant le démarrage du service ?

Ce script permet d’enregistrer l’état des interfaces avec leur IP dans /tmp/ips.txt :

root@amon:~# cat > /etc/init/isc-dhcp-relay.override <<EOF
pre-start script
    if [ ! -f /etc/default/isc-dhcp-relay ]; then
        echo "/etc/default/isc-dhcp-relay does not exist! - Aborting..." 
        echo "Run 'dpkg-reconfigure isc-dhcp-relay' to fix the problem." 
        stop
        exit 0
    fi
    ip addr > /tmp/ips.txt
end script

start on (runlevel [2345] and static-network-up)
EOF

#14 Updated by Olivier FEBWIN almost 7 years ago

C'est en place sur l'Amon 2.5.2 qui pose problème.
À suivre demain ;)

#15 Updated by Gérald Schwartzmann almost 7 years ago

Bonjour,

Demain est passé :-), la demande est-elle toujours d'actualité ?

Merci d'avance

#16 Updated by Daniel Dehennin almost 7 years ago

  • Status changed from Nouveau to En attente d'informations

#17 Updated by Olivier FEBWIN almost 7 years ago

Le problème ne se produit plus avec un cron qui redémarre le relai dhcp tous les jours à 7h00.
Voici ce que l'on a au niveau de l'état des interfaces dans /tmp/ips.txt suite à la mise en place de la manip de Daniel :

root@amon25-0601407d:~# diff  /tmp/ips_OK.txt /tmp/ips.txt 
29c29
< 58: eth0.160@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
---
> 64: eth0.160@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
33c33
< 59: eth3.30@eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
---
> 65: eth3.30@eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default

#18 Updated by Daniel Dehennin almost 7 years ago

Olivier FEBWIN a écrit :

Le problème ne se produit plus avec un cron qui redémarre le relai dhcp tous les jours à 7h00.
Voici ce que l'on a au niveau de l'état des interfaces dans /tmp/ips.txt suite à la mise en place de la manip de Daniel :

Donc à priori, aucune interface n’est DOWN lors du démarrage, le diff ne montre qu’une différence dans l’ordre d’apparition des interfaces.

Par contre cela ne dis pas si le relay est fonctionnel ou non.

Pouvez-vous joindre le fichier /var/log/boot.log afin d’avoir une idée de l’ordre de démarrage ?

#19 Updated by Olivier FEBWIN almost 7 years ago

#20 Updated by Gérald Schwartzmann almost 7 years ago

  • Status changed from En attente d'informations to Nouveau

#21 Updated by Karim Ayari over 6 years ago

et ça continue... on va déployer un cron
où en êtes vous sur ce dossier ? merci.

#22 Updated by Daniel Dehennin over 6 years ago

Karim Ayari a écrit :

et ça continue... on va déployer un cron
où en êtes vous sur ce dossier ? merci.

Je ne comprends pas ce qu’il se passe.

Ceux qui te posent problème ont-il le .override ?

#23 Updated by Olivier FEBWIN over 6 years ago

De notre côté, le cron fait bien son job. "Pas de déconnexion des téléphones pendant les vacances" selon mon contact technique.
Par contre, la collectivité qui rencontre ce problème vient de me mettre à dispo aujourd’hui un serveur de test sur lequel ils reproduisent le problème. Je viens de mettre en place le .override

#24 Updated by Karim Ayari over 6 years ago

le correctif n'a pas résolu le problème de relai dhcp que nous rencontrons sur Amiens.
Voir https://youtu.be/Kkbf4zNUeb0
Les requêtes dhcp ne sont visibles sur eth0.160 qu'après relance du démon isc-dhcp-relay

vu cette réponse je n'ai pas encore déployé le override

#25 Updated by Olivier FEBWIN over 6 years ago

Voici une nouvelle capture vidéo (https://youtu.be/2ecEEPSM29s) de ce matin mettant en évidence le problème sur la maquette dont je parlais hier sur laquelle nous reproduisons le problème.
Les requêtes dhcp ne sont visibles sur eth0.160 qu'après relance du démon isc-dhcp-relay

#26 Updated by Daniel Dehennin over 6 years ago

Olivier FEBWIN a écrit :

Voici une nouvelle capture vidéo (https://youtu.be/2ecEEPSM29s) de ce matin mettant en évidence le problème sur la maquette dont je parlais hier sur laquelle nous reproduisons le problème.
Les requêtes dhcp ne sont visibles sur eth0.160 qu'après relance du démon isc-dhcp-relay

La capture vidéo n’éclaire pas beaucoup sur la raison du problème, ici nous nous sommes rendu compte du problème avec le démarrage des interfaces, si l’interface eth0.160 n’est pas fonctionnelle lors du démarrage du service isc-dhcp-relay, ce dernier ne l’utilise pas.

Le fichier .override (#17296#note-7) permet de ne pas démarrer le service tant que le réseau n’est pas fonctionnel, j’ai testé avec 100 interfaces VLAN qui prennent beaucoup de temps à démarrer et cela corrige le dysfonctionnement.

Je ne comprends pas pourquoi cela ne corrige pas le dysfonctionnement chez vous.

#27 Updated by Karim Ayari over 6 years ago

ok Daniel on va retenter avec le fichier .override

#28 Updated by Daniel Dehennin over 6 years ago

Karim Ayari a écrit :

ok Daniel on va retenter avec le fichier .override

Merci, et Olivier ?

#29 Updated by Olivier FEBWIN over 6 years ago

le .override n'a pas apporté d'amélioration, on a mis un cron qui relance démon isc-dhcp-relay tous les matins :(

#30 Updated by Karim Ayari over 6 years ago

j'ai recréé le fichier et on patiente. le problème se posait à la suite d'un reboot provoqué par une maj
le serveur n'a pas rebooté depuis ~60 jours et ils nous ont pas remonté de problème.

#31 Updated by Olivier FEBWIN over 6 years ago

En revanche, ce dysfonctionnement n'est pas présent en 2.4.2

#32 Updated by Karim Ayari over 6 years ago

le fichier .override disparait ! comment faire pour le rendre définitif ?
je ne sais toujours pas si il évite le problème ou pas

#33 Updated by Karim Ayari over 6 years ago

le reconfigure supprime le fichier

#34 Updated by Daniel Dehennin over 6 years ago

  • Tracker changed from Demande to Proposition Scénario
  • Subject changed from relai dhcp qui se met en vrac to Le service de relay DHCP doit démarrer après le réseau
  • Description updated (diff)
  • Assigned To deleted (Daniel Dehennin)

Karim Ayari a écrit :

le reconfigure supprime le fichier

Je comprend d’où cela vient, c’est notre gestion des services upstart (python-pyeole:source:pyeole/service/module/upstart.py@acb5a09#L73) : si le fichier .override est présent, l’activation du service le supprime.

Gérer une modification du service par .override n’est donc pas possible, il faut fournir un fichier upstart remplaçant celui du paquet isc-dhcp-relay.

#35 Updated by Daniel Dehennin over 6 years ago

  • Project changed from Distribution EOLE to eole-dhcrelay

#36 Updated by Gilles Grandgérard over 5 years ago

  • Tracker changed from Proposition Scénario to Scénario

#37 Updated by Joël Cuissinat over 5 years ago

  • Related to Tâche #22719: dhcrelay échoue à se lancer au boot quand il y a beaucoup de vlans (amon 2.5.2) added

#38 Updated by Joël Cuissinat over 5 years ago

  • Assigned To set to force indigo

Also available in: Atom PDF