Re: [dhcwg] WG Adoption call for draft-gandhewar-dhc-relay-initiated-release and draft-gandhewar-dhc-v6-relay-initiated-release (Expires Oct 27, 2015)

[Ted Lemon <[e-mail]>]

On Oct 16, 2015, at 4:28 PM, Dan Seibel <[e-mail]> wrote:
> Dhcp relay agent on a edge router (BNG) has two dhcp servers that it relays requests to (Server 1, Server 2).  These servers “should" be maintaining state between them for a given address pool.
> 
> Client A comes online and gets IP address 10.1.1.1 from Server 1.
> Client B comes online and gets IP address 10.1.1.1 from Server 2.  The BNG sees this duplication and drops the request.  Client B is not able to get an address, and as far as Server 2 is concerned Client B just hasn’t responded back to it’s offer and continues to offer this same address out to Client B with each discover that it gets.
> 
> Now in theory the above issue shouldn’t happen if the dhcp servers are operating like they should etc.  However these types of issues do come up more often than I would care to see and if there is some other way to provide more resiliency in the whole process I would like to see that.

To paraphrase, "The DHCP server software I am using does not have a working failover implementation, and consequently I would like the DHCP protocol to be changed in order to address the failings of that server."   I’m sorry, I know that’s a bit cold, but seriously, this is a solved problem.   A protocol extension that makes DHCP less reliable in order to address a lack of reliability in a server seems like the wrong thing to do.

> The reality is that BNGs using dhcp relay will usually maintain dhcp state of the active clients as this is used for creating forwarding tables, providing anti-spoofing protection etc.  If there is an enhancement to the dhcp protocol that will enable the dhcp relay agent to communicate with the server to help solve some out of sync issues I think that is a good idea.

DHCP leasequery?

> "I do believe that some places are already doing this by generating Releases messages (though perhaps the authors can confirm) and likely have not seen issues in that setting because it meets the criteria I mentioned above.”
> 
> I know of a couple vendors that do the above already (usually do a mac ping/ NS to the client and if there is no response then the relay sends a release).  One enhancement to this process the drafts would add is a way to see how many releases are happening from the actual client release vs releases from the dhcp relay do to other reasons.

A ping test tells you that the client is unreachable at the time of the test.   It doesn’t tell you whether it is actually offline, nor whether it has forgotten its lease.

> "why this particular solution is a better solution than using shorter lease times”
> 
> Shorter lease times can help in some situations, but when operating networking equipment that has 10s of thousands of leases to maintain and deal with lowering lease times can only go so far before you start to hit resource / scalability issues on the BNG.

Scalability on the BNG?   This is the first I’ve heard of that.   Can you expand on this?   The BNG is just a relay agent, right?   Where’s the scalability issue there?