Recently, I had to troubleshoot an issue where users moving between floors with different subnets/vlans were not getting the correct LAN IP address (i.e. first floor was 192.168.1.0/24 and second was 192.168.2.0/24).
Verified the network devices had IP Helpers, even temporarily disabled DHCP failover (2012R2+ feature) to rule that out – nothing.
Whenever the machine switched from one floor to another, even running IPCONFIG /RELEASE & RENEW did not help. Checking the logs on the DHCP server indicated that the traffic was making it there and the DHCP server saw it as renewing the lease, which it allowed – rather than rejecting handing out that IP address and assigning one for the correct range.
It turned out to be DHCP Superscoping that was causing this issue. Many people set up Superscoping because they think it is just another layer of administrative abstraction/consolidation. You know, grouping multiple VLANs by physical location into one Superscope.
The problem with that is MS’s Superscope only works when you have multiple subnets sharing the same underlying VLAN – in which case, it works fine, and users would be OK maintaining their previous IP address, because the default gateway would continue to route traffic properly. However, because of the way that subnets and vlans work, every network administrator is going to assign only one subnet to vlan, instead of multiple.
I have never seen a network environment where this was being done, therefore I have never seen a network where Superscoping was appropriate. Unfortunately, there is not good documentation (at least that I have ever seen) for this functionality. And depending on the type of devices in use and the frequency of moving subnets, users and admins may not even notice.
Because this was an environment where each floor of the building was assigned a different subnet for each floor + users are assigned laptops and often switch jacks, we noticed the issue fairly quickly. If this there an environment where there was only one LAN subnet for all floors and/or desktops in use instead, then the issue would take awhile to manifest (only if moving desktops frequently between floors or outside building).
So yeah, lesson learned. Don’t ever use Superscoping for DHCP because it does not help you out in anyway functionally, and there are almost no scenarios where a network would be deployed in such a way that Superscoping made sense.
Never A Null Moment 
Actually there’s one very very common network I see time and time again where you’ll find multiple subnets smashed into one VLAN. It’s the “one big flat untagged VLAN 1” found at any operation with zero clueful network people, so they keep daisy chaining switches together and hoping it works.
LikeLiked by 1 person
That’s interesting. I have never seen that. I come from a background where there were always multiple departments or business units that were separated by VLAN (sometimes too much), so it’s hard for me to imagine that. I’m more of an AD as opposed to network guy, but I have seen equivalent amateur mistakes – like creating an OU with the name of the company and then putting all groups, computers and users in that single OU – and years laters it’s a total mess. I guess I have always had the pleasure of at least working with competent network people!
LikeLike