RE: [dhcwg] Failover: transition out of potential-conflict.

"Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se> Mon, 05 November 2001 19:36 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 OAA04213 for <dhcwg-archive@odin.ietf.org>; Mon, 5 Nov 2001 14:36:53 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA22765 for dhcwg-archive@odin.ietf.org; Mon, 5 Nov 2001 14:36:55 -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 OAA22683; Mon, 5 Nov 2001 14:31:22 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22655 for <dhcwg@optimus.ietf.org>; Mon, 5 Nov 2001 14:31:20 -0500 (EST)
Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04043 for <dhcwg@ietf.org>; Mon, 5 Nov 2001 14:31:15 -0500 (EST)
Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id fA5JUlP16813 for <dhcwg@ietf.org>; Mon, 5 Nov 2001 13:30:47 -0600 (CST)
Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id fA5JUk504105 for <dhcwg@ietf.org>; Mon, 5 Nov 2001 13:30:46 -0600 (CST)
Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Mon Nov 05 13:30:45 2001 -0600
Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <W1L4S0HD>; Mon, 5 Nov 2001 13:30:45 -0600
Message-ID: <66F66129A77AD411B76200508B65AC697B3868@eambunt705.ena-east.ericsson.se>
From: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
To: 'Ted Lemon' <mellon@fugue.com>, Kim Kinnear <kkinnear@cisco.com>
Cc: dhcwg@ietf.org
Subject: RE: [dhcwg] Failover: transition out of potential-conflict.
Date: Mon, 05 Nov 2001 13:30:45 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C16630.5D29FA20"
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

I'm a bit confused as to what the problem really is. When both servers contact
each other, the primary will request the secondary to send it full details. Once
the primary has done that, why can it not lease out addresses? It has all of the
information in order to do this.

In your message Ted, you state:

"Since the network partition has healed, the primary can hear requests
from all networks, and one of the first leases it assigns happens to be
the same free lease that the secondary reclaimed and assigned.   This
creates a needless conflict.   The conflict will be caught during the
secondary's update, but this is cold comfort, since we potentially have
an address conflict at this point."


The primary doesn't leave Potential-Conflict until it has received ALL BNDUPDs
from the secondary. And, it can't do any leasing in the Potential-Conflict state.
So, how possibly can the primary assign "the same free lease that the secondary
reclaimed and assigned"? Since the secondary sent that BNDUPD to the primary
before the primary entered NORMAL, why would the primary give that
address to any other client?

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@fugue.com]
Sent: Monday, November 05, 2001 1:59 PM
To: Kim Kinnear
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] Failover: transition out of potential-conflict.


>
>         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