Re: [dhcwg] Failover: transition out of potential-conflict.
Ted Lemon <mellon@fugue.com> Mon, 05 November 2001 19:03 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03164 for <dhcwg-archive@odin.ietf.org>; Mon, 5 Nov 2001 14:03:29 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21956 for dhcwg-archive@odin.ietf.org; Mon, 5 Nov 2001 14:03:31 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21386; Mon, 5 Nov 2001 13:58:04 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21355 for <dhcwg@optimus.ietf.org>; Mon, 5 Nov 2001 13:58:02 -0500 (EST)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02827 for <dhcwg@ietf.org>; Mon, 5 Nov 2001 13:57:59 -0500 (EST)
Received: from green.bisbee.fugue.com (205-140-116-229.ip.theriver.com [205.140.116.229]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id fA5IuRv23408; Mon, 5 Nov 2001 10:56:27 -0800 (PST)
Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id fA5IwfM01426; Mon, 5 Nov 2001 11:58:41 -0700 (MST)
Date: Mon, 05 Nov 2001 11:58:40 -0700
Subject: Re: [dhcwg] Failover: transition out of potential-conflict.
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Mime-Version: 1.0 (Apple Message framework v472)
Cc: dhcwg@ietf.org
To: Kim Kinnear <kkinnear@cisco.com>
From: Ted Lemon <mellon@fugue.com>
In-Reply-To: <4.3.2.7.2.20011105104206.023008c8@funnel.cisco.com>
Message-Id: <20917F43-D21F-11D5-908D-00039317663C@fugue.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.472)
Content-Transfer-Encoding: 7bit
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org
Content-Transfer-Encoding: 7bit
> > But, I think the primary would not actually assign the IP > address to anyone after it goes into NORMAL state. Part > of the work of the primary processing the secondary's > lease database is for the primary to resolve conflicts in > real time while receiving the BNDUPD's. The secondary > cannot send the UPDDONE until the primary has processed > all of the BNDUPD's in some way. I misspoke slightly there - I said "NORMAL" when I meant "CONFLICT-DONE." The primary will think that the address is in the free state until it gets the update from the secondary telling it that the secondary assigned it to a client. So there's a window, potentially fairly long at a large installation, in which the primary can allocate that address, thinking it is free. If it does so, the problem will be discovered during the resolution process, but it'll be too late at that point - two clients will have been assigned the same IP address. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] Failover: poolreq message secondary-only? Ted Lemon
- RE: [dhcwg] Failover: poolreq message secondary-o… steve
- Re: [dhcwg] Failover: poolreq message secondary-o… Ted Lemon
- RE: [dhcwg] Failover: poolreq message secondary-o… steve
- RE: [dhcwg] Failover: poolreq message secondary-o… Bernie Volz (EUD)
- Re: [dhcwg] Failover: poolreq message secondary-o… Ted Lemon
- [dhcwg] Failover: transition out of potential-con… Ted Lemon
- RE: [dhcwg] Failover: poolreq message secondary-o… Kim Kinnear
- Re: [dhcwg] Failover: transition out of potential… Kim Kinnear
- Re: [dhcwg] Failover: poolreq message secondary-o… Ted Lemon
- Re: [dhcwg] Failover: transition out of potential… Ted Lemon