Le renouvellement d'un bail Dhcp s'effectue sur deux trames. Ces trames sont
du type unicast et la première est plus particulièrement destinée au serveur
Dhcp qui a alloué le bail que le client tente de renouveler.
La Rfc 1541 relate au chapitre 4.4.3 (page 34) :
---------------------
4.4.3 Initialization with a known DHCP server address
When the DHCP client knows the address of a DHCP server, in either
INIT or REBOOTING state, the client may use that address in the
DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address. If
the client receives no response to DHCP messages sent to the IP
address of a known DHCP server, the DHCP client reverts to using the
IP broadcast address.
---------------------
Que je traduit par :
---------------------
4.4.3 Initialisation avec la connaissance de l'adresse IP du serveur Dhcp
Quand le client Dhcp connaît l'adresse du serveur Dhcp, que ce soit à l'état
Init ou reboot, le client doit utiliser l'adresse DhcpDiscover ou
DhcpRequest plutôt que l'adresse Ip de braodcast. .........
---------------------
Pour le moment, ça me va et surtout, ça ne chamboule pas mes vieilles bases.
Cependant, dans le chapitre 3.2 de cette même Rfc, figure le schéma 4 en
page 18. Il reflète le renouvellement d'un bail Dhcp. On peut se remarquer
le processus sur deux trames.
Je ne comprend pas pourquoi, dans ce schéma, le client s'adresse à touts les
serveurs Dhcp ? Il devrait plutôt s'adresser en Unicast à son Dhcp d'origine
comme le stipule le chapitre 4.4.3.
Qu'en pensez-vous ?
Cordialement,
--
_SebF
http://www.frameip.com
Un site pour les spécialistes IP
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Angelot
Bonsoir Sèb,
Je passe par là avant dodo, vois ton excellente question.
Je chercherai, mais je cours après le temps actuellement.
Je crois pourtant me souvenir que le renouvellement au bout du 1er temps se fait explicitement à l'adresse du serveur.
Si la demande échoue, le renouvellement au bout du 2ème temps (3/4 du bail) s'effectue en broadcast car le serveur initial est peut être indisponible. Plusieurs tentatives peuvent exister.
Si elles échouent, au bout du temps global la procédure de découverte repart à zéro. Tout ceci est à confirmer, mais c'est en gros avant dodo.
Cordialement, Angelot
Bonsoir Sèb,
Je passe par là avant dodo, vois ton excellente question.
Je chercherai, mais je cours après le temps actuellement.
Je crois pourtant me souvenir que le renouvellement au bout du 1er temps se
fait explicitement à l'adresse du serveur.
Si la demande échoue, le renouvellement au bout du 2ème temps (3/4 du bail)
s'effectue en broadcast car le serveur initial est peut être indisponible.
Plusieurs tentatives peuvent exister.
Si elles échouent, au bout du temps global la procédure de découverte repart
à zéro.
Tout ceci est à confirmer, mais c'est en gros avant dodo.
Je passe par là avant dodo, vois ton excellente question.
Je chercherai, mais je cours après le temps actuellement.
Je crois pourtant me souvenir que le renouvellement au bout du 1er temps se fait explicitement à l'adresse du serveur.
Si la demande échoue, le renouvellement au bout du 2ème temps (3/4 du bail) s'effectue en broadcast car le serveur initial est peut être indisponible. Plusieurs tentatives peuvent exister.
Si elles échouent, au bout du temps global la procédure de découverte repart à zéro. Tout ceci est à confirmer, mais c'est en gros avant dodo.
Cordialement, Angelot
Angelot
La première limite doit être la moitié du bail par défaut. Les seuils doivent être paramétrables.
Angelot
La première limite doit être la moitié du bail par défaut. Les seuils
doivent être paramétrables.
La première limite doit être la moitié du bail par défaut. Les seuils doivent être paramétrables.
Angelot
_SebF - www.frameip.com
"Angelot" a écrit dans le message de news: cho4ev$i3c$
La première limite doit être la moitié du bail par défaut.
L'un des paragraphe du chapitre 4.4.4 relate les veleur des deux limites appelées T1 et T1 :
--------------------- Times T1 and T2 are configurable by the server through options. T1 defaults to (0.5 * duration_of_lease). T2 defaults to (0.875 * duration_of_lease). ---------------------
Les seuils doivent être paramétrables.
Ce même paragraphe confirme aussi clairement que l'on peut les modifier dans le serveur.
--
_SebF
http://www.frameip.com Un site pour les spécialistes IP
"Angelot" <OnSePame@KesceKonSePame.fr> a écrit dans le message de news:
cho4ev$i3c$1@news-reader1.wanadoo.fr...
La première limite doit être la moitié du bail par défaut.
L'un des paragraphe du chapitre 4.4.4 relate les veleur des deux limites
appelées T1 et T1 :
---------------------
Times T1 and T2 are configurable by the server through options. T1
defaults to (0.5 * duration_of_lease). T2 defaults to (0.875 *
duration_of_lease).
---------------------
Les seuils doivent être paramétrables.
Ce même paragraphe confirme aussi clairement que l'on peut les modifier dans
le serveur.
--
_SebF
http://www.frameip.com
Un site pour les spécialistes IP
"Angelot" a écrit dans le message de news: cho4ev$i3c$
La première limite doit être la moitié du bail par défaut.
L'un des paragraphe du chapitre 4.4.4 relate les veleur des deux limites appelées T1 et T1 :
--------------------- Times T1 and T2 are configurable by the server through options. T1 defaults to (0.5 * duration_of_lease). T2 defaults to (0.875 * duration_of_lease). ---------------------
Les seuils doivent être paramétrables.
Ce même paragraphe confirme aussi clairement que l'on peut les modifier dans le serveur.
--
_SebF
http://www.frameip.com Un site pour les spécialistes IP
_SebF - www.frameip.com
"Angelot" a écrit dans le message de news: cho49i$hd2$
Bonsoir Sèb,
Salut,
Je passe par là avant dodo, vois ton excellente question.
Alors, bien dormis ?
Je chercherai, mais je cours après le temps actuellement.
Court plus vite, tu gagneras du temps et tu pourras alors rattraper le temps actuel. :)
Si la demande échoue, le renouvellement au bout du 2ème temps (3/4 du bail)
s'effectue en broadcast car le serveur initial est peut être indisponible. Plusieurs tentatives peuvent exister.
Oui, tu as raison Angelot, cela ce confirme par l'un des paragraphes
--------------------- If no DHCPACK arrives before time T2 (T2 > T1) before the expiration of the client's lease on its network address, the client moves to REBINDING state and sends (via broadcast) a DHCPREQUEST message to extend its lease. The client sets the 'ciaddr' field in the DHCPREQUEST to its current network address. The client MUST NOT include a 'server identifier' in the DHCPREQUEST message. --------------------- Je traduis par : --------------------- Si aucun DhcpAck arrive avant T2, avant l'expiration, le client bascule dans l'état Rebinding et envoi (via un broadcast) un message DhcpRequest pour renouveler le bail. ..... ---------------------
--
_SebF
http://www.frameip.com Un site pour les spécialistes IP
"Angelot" <OnSePame@KesceKonSePame.fr> a écrit dans le message de news:
cho49i$hd2$1@news-reader1.wanadoo.fr...
Bonsoir Sèb,
Salut,
Je passe par là avant dodo, vois ton excellente question.
Alors, bien dormis ?
Je chercherai, mais je cours après le temps actuellement.
Court plus vite, tu gagneras du temps et tu pourras alors rattraper le temps
actuel. :)
Si la demande échoue, le renouvellement au bout du 2ème temps (3/4 du
bail)
s'effectue en broadcast car le serveur initial est peut être indisponible.
Plusieurs tentatives peuvent exister.
Oui, tu as raison Angelot, cela ce confirme par l'un des paragraphes
---------------------
If no DHCPACK arrives before time T2 (T2 > T1) before the expiration
of the client's lease on its network address, the client moves to
REBINDING state and sends (via broadcast) a DHCPREQUEST message to
extend its lease. The client sets the 'ciaddr' field in the
DHCPREQUEST to its current network address. The client MUST NOT
include a 'server identifier' in the DHCPREQUEST message.
---------------------
Je traduis par :
---------------------
Si aucun DhcpAck arrive avant T2, avant l'expiration, le client bascule dans
l'état Rebinding et envoi (via un broadcast) un message DhcpRequest pour
renouveler le bail. .....
---------------------
--
_SebF
http://www.frameip.com
Un site pour les spécialistes IP
"Angelot" a écrit dans le message de news: cho49i$hd2$
Bonsoir Sèb,
Salut,
Je passe par là avant dodo, vois ton excellente question.
Alors, bien dormis ?
Je chercherai, mais je cours après le temps actuellement.
Court plus vite, tu gagneras du temps et tu pourras alors rattraper le temps actuel. :)
Si la demande échoue, le renouvellement au bout du 2ème temps (3/4 du bail)
s'effectue en broadcast car le serveur initial est peut être indisponible. Plusieurs tentatives peuvent exister.
Oui, tu as raison Angelot, cela ce confirme par l'un des paragraphes
--------------------- If no DHCPACK arrives before time T2 (T2 > T1) before the expiration of the client's lease on its network address, the client moves to REBINDING state and sends (via broadcast) a DHCPREQUEST message to extend its lease. The client sets the 'ciaddr' field in the DHCPREQUEST to its current network address. The client MUST NOT include a 'server identifier' in the DHCPREQUEST message. --------------------- Je traduis par : --------------------- Si aucun DhcpAck arrive avant T2, avant l'expiration, le client bascule dans l'état Rebinding et envoi (via un broadcast) un message DhcpRequest pour renouveler le bail. ..... ---------------------
--
_SebF
http://www.frameip.com Un site pour les spécialistes IP
_SebF - www.frameip.com
Avec toutes ces bases, je précise et reformule ma question :
Dans le chapitre 3.2 de la Rfc 1541, figure le schéma 4 en page 18. Il reflète le renouvellement d'un bail Dhcp. On peut se remarquer le processus sur deux trames. Je ne comprend pas pourquoi, dans ce schéma, le client s'adresse à touts les serveurs Dhcp ?
Ceci signifierait que l'on se trouve dans un cas où à T2, le client à essayé de renouveler sans succès et que par la suite, il envoi un broadcast, où désormais, le serveur Dhcp est de nouveau disponible. C'est techniquement vrai, mais pas explicite dans la Rfc, je n'ai pas lu de mise en situation du schéma aussi précise indiquant ce cas. Qu'en pensez-vous ?
Le second point qui me chagrine et qui me donne donc envie de comprendre, c'est au sujet des réponses. Dans ce même schéma, on part donc sur le cas précédent lié à la demande de renouvellement via un broadcast. Je comprends que le serveur ayant attribué le bail original puisse répondre en une seule trame l'accord du renouvellement. Cependant Pourquoi et comment le second serveur, qui n'est pas celui qui a attribué le bail, peut renouveler un bail qu'il ne gère pas ?
Et une troisième interrogation me vient, imaginons que les deux serveurs (ou plus) répondent à la demande de renouvellement émis en broadcast. Le clients va alors recevoir plusieurs renouvellements, mais comment les serveurs vont ils savoir quel serveur sera choisit par le client (car nous ne somme pas en système 4 trames) ?
Cordialement,
--
_SebF
http://www.frameip.com Un site pour les spécialistes IP
Avec toutes ces bases, je précise et reformule ma question :
Dans le chapitre 3.2 de la Rfc 1541, figure le schéma 4 en page 18. Il
reflète le renouvellement d'un bail Dhcp. On peut se remarquer le processus
sur deux trames. Je ne comprend pas pourquoi, dans ce schéma, le client
s'adresse à touts les serveurs Dhcp ?
Ceci signifierait que l'on se trouve dans un cas où à T2, le client à essayé
de renouveler sans succès et que par la suite, il envoi un broadcast, où
désormais, le serveur Dhcp est de nouveau disponible. C'est techniquement
vrai, mais pas explicite dans la Rfc, je n'ai pas lu de mise en situation du
schéma aussi précise indiquant ce cas. Qu'en pensez-vous ?
Le second point qui me chagrine et qui me donne donc envie de comprendre,
c'est au sujet des réponses. Dans ce même schéma, on part donc sur le cas
précédent lié à la demande de renouvellement via un broadcast. Je comprends
que le serveur ayant attribué le bail original puisse répondre en une seule
trame l'accord du renouvellement. Cependant Pourquoi et comment le second
serveur, qui n'est pas celui qui a attribué le bail, peut renouveler un bail
qu'il ne gère pas ?
Et une troisième interrogation me vient, imaginons que les deux serveurs (ou
plus) répondent à la demande de renouvellement émis en broadcast. Le clients
va alors recevoir plusieurs renouvellements, mais comment les serveurs vont
ils savoir quel serveur sera choisit par le client (car nous ne somme pas en
système 4 trames) ?
Cordialement,
--
_SebF
http://www.frameip.com
Un site pour les spécialistes IP
Avec toutes ces bases, je précise et reformule ma question :
Dans le chapitre 3.2 de la Rfc 1541, figure le schéma 4 en page 18. Il reflète le renouvellement d'un bail Dhcp. On peut se remarquer le processus sur deux trames. Je ne comprend pas pourquoi, dans ce schéma, le client s'adresse à touts les serveurs Dhcp ?
Ceci signifierait que l'on se trouve dans un cas où à T2, le client à essayé de renouveler sans succès et que par la suite, il envoi un broadcast, où désormais, le serveur Dhcp est de nouveau disponible. C'est techniquement vrai, mais pas explicite dans la Rfc, je n'ai pas lu de mise en situation du schéma aussi précise indiquant ce cas. Qu'en pensez-vous ?
Le second point qui me chagrine et qui me donne donc envie de comprendre, c'est au sujet des réponses. Dans ce même schéma, on part donc sur le cas précédent lié à la demande de renouvellement via un broadcast. Je comprends que le serveur ayant attribué le bail original puisse répondre en une seule trame l'accord du renouvellement. Cependant Pourquoi et comment le second serveur, qui n'est pas celui qui a attribué le bail, peut renouveler un bail qu'il ne gère pas ?
Et une troisième interrogation me vient, imaginons que les deux serveurs (ou plus) répondent à la demande de renouvellement émis en broadcast. Le clients va alors recevoir plusieurs renouvellements, mais comment les serveurs vont ils savoir quel serveur sera choisit par le client (car nous ne somme pas en système 4 trames) ?
Cordialement,
--
_SebF
http://www.frameip.com Un site pour les spécialistes IP
Angelot
Bonjour Sèb,
Quelques léménts de réflexion
Dans le chapitre 3.2 de la Rfc 1541
RFC2131 remplace RFC1541 et, en outre, une traduction française existe sur abcdrfc.free.fr.
Dans le chapitre 3.2 de la Rfc 1541figure le schéma 4 en page 18. Il reflète le renouvellement d'un bail Dhcp.
Je ne vois pas cela. Par contre, j'observe une demande de réutilisation d'une adresse précédemment attribuée, donc, peut-être, après expiration du bail, après restitution de la configuration par DHCPRELEASE (ce qui devrait être assez rare, restitution élégante).
On peut se remarquer le processus sur deux trames. Je ne comprend pas pourquoi, dans ce schéma, le client s'adresse à touts les serveurs Dhcp ?
Le processus est à 2 trames car le client dispose d'une adresse qui a été valide à un moment donné. Et le broadcast a lieu car le serveur a peut être changé, le client est peut être passé sur un autre réseau en conservant la procédure automatique de réutilisation. Il faut donc peut être traverser des réseaux qui ne sont pas ceux d'origine, en passant par les routeurs agents relais. De toute manière un serveur DHCP n'est pas obligatoirement sur le même réseau que le client.
Si dans ce cas la configuration du client n'est reconnue par aucun serveur, DHCPNACK est reçu, et la procédure d'attribution a 4 messages débute.
Ceci signifierait que l'on se trouve dans un cas où à T2...
Ce n'est pas ce cas-ci.
Le second point qui me chagrine et qui me donne donc envie de comprendre, c'est au sujet des réponses. Dans ce même schéma, on part donc sur le cas précédent lié à la demande de renouvellement via un broadcast.
Donc, demande de réattribution et non de renouvellement.
Et une troisième interrogation me vient, imaginons que les deux serveurs (ou
plus) répondent à la demande de renouvellement émis en broadcast. Le clients
va alors recevoir plusieurs renouvellements, mais comment les serveurs vont
ils savoir quel serveur sera choisit par le client (car nous ne somme pas en
système 4 trames) ?
Le point ci-dessous doit permettre d'avancer.
En préambule, le passage de T1 entraîne l'état de Renouvellement, alors que le passage de T2 entraîne l'état de Réaffectation.
"Le DHCPREQUEST d'un client en REAFFECTATION est destiné à satisfaire les sites qui possèdent plusieurs serveurs DHCP et un mécanisme pour maintenir une certaines cohésion entre les différents baux contrôlés par les divers serveurs. Un serveur DHCP PEUT étendre le bail d'un client seulement s'il à l'autorisation locale de le faire".
Un autre serveur peut répondre à condition qu'un mécanisme de cohérence globale puisse exister, donc alignement des base de données (sans doute à la manière de SNMP qui peut maintenir en local une copie de la base de données MIB d'un équipement).
Ces éléments rapides t'aident-ils un peu ? Cordialement, Angelot
Bonjour Sèb,
Quelques léménts de réflexion
Dans le chapitre 3.2 de la Rfc 1541
RFC2131 remplace RFC1541 et, en outre, une traduction française existe sur
abcdrfc.free.fr.
Dans le chapitre 3.2 de la Rfc 1541figure le schéma 4 en page 18. Il
reflète le renouvellement d'un bail Dhcp.
Je ne vois pas cela. Par contre, j'observe une demande de réutilisation
d'une adresse précédemment attribuée, donc, peut-être, après expiration du
bail, après restitution de la configuration par DHCPRELEASE (ce qui devrait
être assez rare, restitution élégante).
On peut se remarquer le processus
sur deux trames. Je ne comprend pas pourquoi, dans ce schéma, le client
s'adresse à touts les serveurs Dhcp ?
Le processus est à 2 trames car le client dispose d'une adresse qui a été
valide à un moment donné. Et le broadcast a lieu car le serveur a peut être
changé, le client est peut être passé sur un autre réseau en conservant la
procédure automatique de réutilisation. Il faut donc peut être traverser des
réseaux qui ne sont pas ceux d'origine, en passant par les routeurs agents
relais. De toute manière un serveur DHCP n'est pas obligatoirement sur le
même réseau que le client.
Si dans ce cas la configuration du client n'est reconnue par aucun serveur,
DHCPNACK est reçu, et la procédure d'attribution a 4 messages débute.
Ceci signifierait que l'on se trouve dans un cas où à T2...
Ce n'est pas ce cas-ci.
Le second point qui me chagrine et qui me donne donc envie de comprendre,
c'est au sujet des réponses. Dans ce même schéma, on part donc sur le cas
précédent lié à la demande de renouvellement via un broadcast.
Donc, demande de réattribution et non de renouvellement.
Et une troisième interrogation me vient, imaginons que les deux serveurs
(ou
plus) répondent à la demande de renouvellement émis en broadcast. Le
clients
va alors recevoir plusieurs renouvellements, mais comment les serveurs
vont
ils savoir quel serveur sera choisit par le client (car nous ne somme pas
en
système 4 trames) ?
Le point ci-dessous doit permettre d'avancer.
En préambule, le passage de T1 entraîne l'état de Renouvellement, alors que
le passage de T2 entraîne l'état de Réaffectation.
"Le DHCPREQUEST d'un client en REAFFECTATION est destiné à satisfaire les
sites qui possèdent plusieurs serveurs DHCP et un mécanisme pour maintenir
une certaines cohésion entre les différents baux contrôlés par les divers
serveurs. Un serveur DHCP PEUT étendre le bail d'un client seulement s'il à
l'autorisation locale de le faire".
Un autre serveur peut répondre à condition qu'un mécanisme de cohérence
globale puisse exister, donc alignement des base de données (sans doute à la
manière de SNMP qui peut maintenir en local une copie de la base de données
MIB d'un équipement).
Ces éléments rapides t'aident-ils un peu ?
Cordialement,
Angelot
RFC2131 remplace RFC1541 et, en outre, une traduction française existe sur abcdrfc.free.fr.
Dans le chapitre 3.2 de la Rfc 1541figure le schéma 4 en page 18. Il reflète le renouvellement d'un bail Dhcp.
Je ne vois pas cela. Par contre, j'observe une demande de réutilisation d'une adresse précédemment attribuée, donc, peut-être, après expiration du bail, après restitution de la configuration par DHCPRELEASE (ce qui devrait être assez rare, restitution élégante).
On peut se remarquer le processus sur deux trames. Je ne comprend pas pourquoi, dans ce schéma, le client s'adresse à touts les serveurs Dhcp ?
Le processus est à 2 trames car le client dispose d'une adresse qui a été valide à un moment donné. Et le broadcast a lieu car le serveur a peut être changé, le client est peut être passé sur un autre réseau en conservant la procédure automatique de réutilisation. Il faut donc peut être traverser des réseaux qui ne sont pas ceux d'origine, en passant par les routeurs agents relais. De toute manière un serveur DHCP n'est pas obligatoirement sur le même réseau que le client.
Si dans ce cas la configuration du client n'est reconnue par aucun serveur, DHCPNACK est reçu, et la procédure d'attribution a 4 messages débute.
Ceci signifierait que l'on se trouve dans un cas où à T2...
Ce n'est pas ce cas-ci.
Le second point qui me chagrine et qui me donne donc envie de comprendre, c'est au sujet des réponses. Dans ce même schéma, on part donc sur le cas précédent lié à la demande de renouvellement via un broadcast.
Donc, demande de réattribution et non de renouvellement.
Et une troisième interrogation me vient, imaginons que les deux serveurs (ou
plus) répondent à la demande de renouvellement émis en broadcast. Le clients
va alors recevoir plusieurs renouvellements, mais comment les serveurs vont
ils savoir quel serveur sera choisit par le client (car nous ne somme pas en
système 4 trames) ?
Le point ci-dessous doit permettre d'avancer.
En préambule, le passage de T1 entraîne l'état de Renouvellement, alors que le passage de T2 entraîne l'état de Réaffectation.
"Le DHCPREQUEST d'un client en REAFFECTATION est destiné à satisfaire les sites qui possèdent plusieurs serveurs DHCP et un mécanisme pour maintenir une certaines cohésion entre les différents baux contrôlés par les divers serveurs. Un serveur DHCP PEUT étendre le bail d'un client seulement s'il à l'autorisation locale de le faire".
Un autre serveur peut répondre à condition qu'un mécanisme de cohérence globale puisse exister, donc alignement des base de données (sans doute à la manière de SNMP qui peut maintenir en local une copie de la base de données MIB d'un équipement).
Ces éléments rapides t'aident-ils un peu ? Cordialement, Angelot
_SebF - www.frameip.com
"Angelot" a écrit dans le message de news: chplf2$hdu$
Bonjour Sèb,
Bonsoir Angelot,
RFC2131 remplace RFC1541
Juste par curiosité, la Rfc 2131 n'était pas un complément de la 1541 à une époque ?
Ouf, heureusement pour moi, elle reprend la plupart des paragraphes cités. J'ai de la chance sur ce coup là
et, en outre, une traduction française existe sur abcdrfc.free.fr.
Merci
Je ne vois pas cela. Par contre, j'observe une demande de réutilisation d'une adresse précédemment attribuée, donc, peut-être, après expiration du bail, après restitution de la configuration par DHCPRELEASE (ce qui devrait
être assez rare, restitution élégante).
Ok, je ne connaissais pas cet état. La éxplique ma confusion que l'on rerouvera dans la suite du Post.
Le processus est à 2 trames car le client dispose d'une adresse qui a été valide à un moment donné. Et le broadcast a lieu car le serveur a peut être
changé, le client est peut être passé sur un autre réseau en conservant la procédure automatique de réutilisation.
Oui ça parrait évident maintennant que mes yeux sont ouverts
Il faut donc peut être traverser des réseaux qui ne sont pas ceux d'origine, en passant par les routeurs agents relais. De toute manière un serveur DHCP n'est pas obligatoirement sur le même réseau que le client.
Oui, la mobilité, un vaste sujet qui va rester à la surface pour encore des années.
Si dans ce cas la configuration du client n'est reconnue par aucun serveur,
DHCPNACK est reçu, et la procédure d'attribution a 4 messages débute.
Ok
Donc, demande de réattribution et non de renouvellement.
Ok
Le point ci-dessous doit permettre d'avancer.
En préambule, le passage de T1 entraîne l'état de Renouvellement, alors que
le passage de T2 entraîne l'état de Réaffectation.
Oui
"Le DHCPREQUEST d'un client en REAFFECTATION est destiné à satisfaire les sites qui possèdent plusieurs serveurs DHCP et un mécanisme pour maintenir une certaines cohésion entre les différents baux contrôlés par les divers serveurs.
Oui
Un serveur DHCP PEUT étendre le bail d'un client seulement s'il à l'autorisation locale de le faire".
Ok
Un autre serveur peut répondre à condition qu'un mécanisme de cohérence globale puisse exister, donc alignement des base de données
Of course
(sans doute à la manière de SNMP qui peut maintenir en local une copie de la base de données
MIB d'un équipement).
C'est marrant, Snmp ne me vient pas à l"esprit dans ce cas de synchronisation de base. Tu raisonnes peux être équipementier pour l'imaginer, non ?
Mon imagination étant basé plus sur du système (c'est pas bien ça plante toujours, lol) je pensais plus à du Nfs, Rsync
Ces éléments rapides t'aident-ils un peu ?
Oui beaucoup, Merci
Cependant, heu rien en fait, j'allais dire que la situation du schéma 4 du chapitre 3.2 de la Rfc 2131 n'est pas très claire. Mais outrage aux Rfc ... je retire ce que j'ai dit, il suffit simplement de bien lire le titre 3.2 pour tout comprendre d'un coup.
_SebF
http://www.frameip.com Un site pour les spécialistes IP
"Angelot" <OnSePame@KesceKonSePame.fr> a écrit dans le message de news:
chplf2$hdu$1@news-reader4.wanadoo.fr...
Bonjour Sèb,
Bonsoir Angelot,
RFC2131 remplace RFC1541
Juste par curiosité, la Rfc 2131 n'était pas un complément de la 1541 à une
époque ?
Ouf, heureusement pour moi, elle reprend la plupart des paragraphes cités.
J'ai de la chance sur ce coup là
et, en outre, une traduction française existe sur
abcdrfc.free.fr.
Merci
Je ne vois pas cela. Par contre, j'observe une demande de réutilisation
d'une adresse précédemment attribuée, donc, peut-être, après expiration du
bail, après restitution de la configuration par DHCPRELEASE (ce qui
devrait
être assez rare, restitution élégante).
Ok, je ne connaissais pas cet état. La éxplique ma confusion que l'on
rerouvera dans la suite du Post.
Le processus est à 2 trames car le client dispose d'une adresse qui a été
valide à un moment donné. Et le broadcast a lieu car le serveur a peut
être
changé, le client est peut être passé sur un autre réseau en conservant la
procédure automatique de réutilisation.
Oui ça parrait évident maintennant que mes yeux sont ouverts
Il faut donc peut être traverser des
réseaux qui ne sont pas ceux d'origine, en passant par les routeurs agents
relais. De toute manière un serveur DHCP n'est pas obligatoirement sur le
même réseau que le client.
Oui, la mobilité, un vaste sujet qui va rester à la surface pour encore des
années.
Si dans ce cas la configuration du client n'est reconnue par aucun
serveur,
DHCPNACK est reçu, et la procédure d'attribution a 4 messages débute.
Ok
Donc, demande de réattribution et non de renouvellement.
Ok
Le point ci-dessous doit permettre d'avancer.
En préambule, le passage de T1 entraîne l'état de Renouvellement, alors
que
le passage de T2 entraîne l'état de Réaffectation.
Oui
"Le DHCPREQUEST d'un client en REAFFECTATION est destiné à satisfaire les
sites qui possèdent plusieurs serveurs DHCP et un mécanisme pour maintenir
une certaines cohésion entre les différents baux contrôlés par les divers
serveurs.
Oui
Un serveur DHCP PEUT étendre le bail d'un client seulement s'il à
l'autorisation locale de le faire".
Ok
Un autre serveur peut répondre à condition qu'un mécanisme de cohérence
globale puisse exister, donc alignement des base de données
Of course
(sans doute à la
manière de SNMP qui peut maintenir en local une copie de la base de
données
MIB d'un équipement).
C'est marrant, Snmp ne me vient pas à l"esprit dans ce cas de
synchronisation de base. Tu raisonnes peux être équipementier pour
l'imaginer, non ?
Mon imagination étant basé plus sur du système (c'est pas bien ça plante
toujours, lol) je pensais plus à du Nfs, Rsync
Ces éléments rapides t'aident-ils un peu ?
Oui beaucoup, Merci
Cependant, heu rien en fait, j'allais dire que la situation du schéma 4 du
chapitre 3.2 de la Rfc 2131 n'est pas très claire. Mais outrage aux Rfc ...
je retire ce que j'ai dit, il suffit simplement de bien lire le titre 3.2
pour tout comprendre d'un coup.
_SebF
http://www.frameip.com
Un site pour les spécialistes IP
"Angelot" a écrit dans le message de news: chplf2$hdu$
Bonjour Sèb,
Bonsoir Angelot,
RFC2131 remplace RFC1541
Juste par curiosité, la Rfc 2131 n'était pas un complément de la 1541 à une époque ?
Ouf, heureusement pour moi, elle reprend la plupart des paragraphes cités. J'ai de la chance sur ce coup là
et, en outre, une traduction française existe sur abcdrfc.free.fr.
Merci
Je ne vois pas cela. Par contre, j'observe une demande de réutilisation d'une adresse précédemment attribuée, donc, peut-être, après expiration du bail, après restitution de la configuration par DHCPRELEASE (ce qui devrait
être assez rare, restitution élégante).
Ok, je ne connaissais pas cet état. La éxplique ma confusion que l'on rerouvera dans la suite du Post.
Le processus est à 2 trames car le client dispose d'une adresse qui a été valide à un moment donné. Et le broadcast a lieu car le serveur a peut être
changé, le client est peut être passé sur un autre réseau en conservant la procédure automatique de réutilisation.
Oui ça parrait évident maintennant que mes yeux sont ouverts
Il faut donc peut être traverser des réseaux qui ne sont pas ceux d'origine, en passant par les routeurs agents relais. De toute manière un serveur DHCP n'est pas obligatoirement sur le même réseau que le client.
Oui, la mobilité, un vaste sujet qui va rester à la surface pour encore des années.
Si dans ce cas la configuration du client n'est reconnue par aucun serveur,
DHCPNACK est reçu, et la procédure d'attribution a 4 messages débute.
Ok
Donc, demande de réattribution et non de renouvellement.
Ok
Le point ci-dessous doit permettre d'avancer.
En préambule, le passage de T1 entraîne l'état de Renouvellement, alors que
le passage de T2 entraîne l'état de Réaffectation.
Oui
"Le DHCPREQUEST d'un client en REAFFECTATION est destiné à satisfaire les sites qui possèdent plusieurs serveurs DHCP et un mécanisme pour maintenir une certaines cohésion entre les différents baux contrôlés par les divers serveurs.
Oui
Un serveur DHCP PEUT étendre le bail d'un client seulement s'il à l'autorisation locale de le faire".
Ok
Un autre serveur peut répondre à condition qu'un mécanisme de cohérence globale puisse exister, donc alignement des base de données
Of course
(sans doute à la manière de SNMP qui peut maintenir en local une copie de la base de données
MIB d'un équipement).
C'est marrant, Snmp ne me vient pas à l"esprit dans ce cas de synchronisation de base. Tu raisonnes peux être équipementier pour l'imaginer, non ?
Mon imagination étant basé plus sur du système (c'est pas bien ça plante toujours, lol) je pensais plus à du Nfs, Rsync
Ces éléments rapides t'aident-ils un peu ?
Oui beaucoup, Merci
Cependant, heu rien en fait, j'allais dire que la situation du schéma 4 du chapitre 3.2 de la Rfc 2131 n'est pas très claire. Mais outrage aux Rfc ... je retire ce que j'ai dit, il suffit simplement de bien lire le titre 3.2 pour tout comprendre d'un coup.
_SebF
http://www.frameip.com Un site pour les spécialistes IP
