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

[Dan Seibel <[e-mail]>]

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.

No that isn’t cold, that would normally be my response to “solve my misconfigured / buggy device by you changing what you are doing”.  I was curious if there is the potential to add another layer of resiliency without obviously making dhcp worse.

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?

Yes thanks for reminding me, this could potentially help a number of situations.

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

Sorry, “MAC ping” should have read ARP/NS.  Which works fine to detect if a client gateway has been disconnected or is unreachable but yes can’t tell you if it has forgotten it’s 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?


BNGs would do more than just relay dhcp traffic.  They would usually need to maintain state of all the dhcp sessions to create forwarding tables etc.  This involves processing all dhcp traffic that passes through them.  They also may do authentication/ accounting on every dhcp request.  Short lease times can also be a major issue if you have some sort of interruption between the relay and the clients causing them to loose their leases.  When the connectivity is restored you end up with a dhcp discovery storm of thousands of clients trying to obtain service all at the same time.  Short and long dhcp leases each have their pros and cons, and trying to find the balance seems to be a bit of an art.

Dan