Projet

Général

Profil

Scénario #17296

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

Ajouté par Karim Ayari il y a plus de 7 ans. Mis à jour il y a environ 6 ans.

Statut:
Nouveau
Priorité:
Normal
Assigné à:
Catégorie:
-
Version cible:
-
Début:
Echéance:
% réalisé:

0%

Points de scénarios:
-
Restant à faire (heures):
0.00 heure
Estimation basée sur la vélocité:

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 Voir (1,48 ko) Olivier FEBWIN, 05/12/2016 09:45


Sous-tâches

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


Demandes liées

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

Historique

#1 Mis à jour par Karim Ayari il y a plus de 7 ans

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

#2 Mis à jour par Karim Ayari il y a plus de 7 ans

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 Mis à jour par Karim Ayari il y a plus de 7 ans

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 Mis à jour par Karim Ayari il y a plus de 7 ans

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 Mis à jour par Karim Ayari il y a plus de 7 ans

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

#6 Mis à jour par Olivier FEBWIN il y a plus de 7 ans

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 Mis à jour par Daniel Dehennin il y a plus de 7 ans

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 Mis à jour par Daniel Dehennin il y a plus de 7 ans

  • Assigné à mis à Daniel Dehennin

#9 Mis à jour par Olivier FEBWIN il y a plus de 7 ans

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 Mis à jour par Karim Ayari il y a plus de 7 ans

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

#11 Mis à jour par Karim Ayari il y a plus de 7 ans

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 Mis à jour par Emmanuel GARETTE il y a plus de 7 ans

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

#13 Mis à jour par Daniel Dehennin il y a plus de 7 ans

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 Mis à jour par Olivier FEBWIN il y a plus de 7 ans

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

#15 Mis à jour par Gérald Schwartzmann il y a plus de 7 ans

Bonjour,

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

Merci d'avance

#16 Mis à jour par Daniel Dehennin il y a plus de 7 ans

  • Statut changé de Nouveau à En attente d'informations

#17 Mis à jour par Olivier FEBWIN il y a plus de 7 ans

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 Mis à jour par Daniel Dehennin il y a plus de 7 ans

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 Mis à jour par Olivier FEBWIN il y a plus de 7 ans

#20 Mis à jour par Gérald Schwartzmann il y a plus de 7 ans

  • Statut changé de En attente d'informations à Nouveau

#21 Mis à jour par Karim Ayari il y a environ 7 ans

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

#22 Mis à jour par Daniel Dehennin il y a environ 7 ans

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 Mis à jour par Olivier FEBWIN il y a environ 7 ans

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 Mis à jour par Karim Ayari il y a environ 7 ans

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 Mis à jour par Olivier FEBWIN il y a environ 7 ans

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 Mis à jour par Daniel Dehennin il y a environ 7 ans

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 Mis à jour par Karim Ayari il y a environ 7 ans

ok Daniel on va retenter avec le fichier .override

#28 Mis à jour par Daniel Dehennin il y a environ 7 ans

Karim Ayari a écrit :

ok Daniel on va retenter avec le fichier .override

Merci, et Olivier ?

#29 Mis à jour par Olivier FEBWIN il y a environ 7 ans

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 Mis à jour par Karim Ayari il y a presque 7 ans

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 Mis à jour par Olivier FEBWIN il y a presque 7 ans

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

#32 Mis à jour par Karim Ayari il y a presque 7 ans

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 Mis à jour par Karim Ayari il y a presque 7 ans

le reconfigure supprime le fichier

#34 Mis à jour par Daniel Dehennin il y a presque 7 ans

  • Tracker changé de Demande à Proposition Scénario
  • Sujet changé de relai dhcp qui se met en vrac à Le service de relay DHCP doit démarrer après le réseau
  • Description mis à jour (diff)
  • Assigné à Daniel Dehennin supprimé

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 Mis à jour par Daniel Dehennin il y a presque 7 ans

  • Projet changé de Distribution EOLE à eole-dhcrelay

#36 Mis à jour par Gilles Grandgérard il y a environ 6 ans

  • Tracker changé de Proposition Scénario à Scénario

#37 Mis à jour par Joël Cuissinat il y a environ 6 ans

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

#38 Mis à jour par Joël Cuissinat il y a environ 6 ans

  • Assigné à mis à force indigo

Formats disponibles : Atom PDF