Upgrading from ISC DHCP 3.0.5 to 4.1 or 4.2 appears to break dhcp-overload function

[Patrick Trapp]

I'm new here and don't have any experience outside of our network, so I don't know how you define a "large" network. It is largely static, so changing how it is managed has never made a lot of sense. I am sure how I manage it would be a nightmare if it was more dynamic.

I'll attempt a description, but I'm not sure what aspects of it are pertinent. Remember - this was working before the upgrade and works after the upgrade as long as we reduce the length of the vendor options to the point that overloading is not necessary, so I'm not sure how much the network description matters.

We have several DHCP implementations here. The one I am talking about is providing addresses and configurations for roughly 50 to 60 thousand customer devices. Most of those are set-tops for our video offering (a mix of ten different ADB and Amino models) but a significant number are modem management addresses for Comtrend modems. These devices are spread across roughly 300 subnets and upwards of 60 small communities in our footprint. 

I don't deal much with our core network, so I will have to get someone else for details if necessary. It is not 100% homogeneous because of different tech that was in place when some of the regions were purchased that has not been replaced yet, but the typical model is an MLX chassis serving each community (some smaller ones may share a chassis, of course) and Occam blade systems that are serving the customer premises. Much of the network is fiber-to-the-home and most of the ONTs are Occam models, but we are seeing more Calix models as time goes on.

We implemented option-82 on the Occam blades years ago when we were migrating from one middleware system to another because it allowed us to gradually cut customers over from the old system to the new system. Today, we largely use it to identify which address pool a device should be assigned to. 

The modems get very little configuration from the DHCP system and had no observed issues with the upgrade. The set-tops get several parameters via DHCP, but the ADBs get significantly more and are the ones that were unable to process the DHCPOFFER when the overload function broke after the upgrade. After thinking about this more yesterday, I'm not 100% sure if we determined that the overload only breaks when received via Occam blades or only when it receives a request using option-82. (As I mentioned, there is some variation on our network and in the cases where we tested where there was no Occam blade in place, there was no option-82, either -- and the set-tops rebooted fine.)

Too much information? Not enough? Not the right information?

Patrick
________________________________________
From: dhcp-users-bounces+ptrapp=nex-tech.com at lists.isc.org [dhcp-users-bounces+ptrapp=nex-tech.com at lists.isc.org] on behalf of Simon Hobson [dhcp1 at thehobsons.co.uk]
Sent: Tuesday, March 11, 2014 4:36 AM
To: Users of ISC DHCP
Subject: Re: Upgrading from ISC DHCP 3.0.5 to 4.1 or 4.2 appears to break       dhcp-overload function

Also, a better description of the network.
It's sounding suspiciously like a large network that's being managed the hard way.

_______________________________________________
dhcp-users mailing list
dhcp-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users