Let me start by saying that Superscopes are not a standard mechanism of DHCP, just a “hack” by Microsoft to support networks that don’t understand the concept of “1 IP subnet PER vlan, not 10 IP subnets per VLAN”. The only, and I do mean ONLY, time that you use Superscopes is when you have a network design that has multiple IP subnets inside the same VLAN. Let me explain the ONLY instance where this is needed and WHY you need multiple interfaces configured for this to work…
Superscopes are used when you have one network segment where you want to issue IPs from more than one subnet. IPs from the first scope will be assigned, then when full, the IPs from the next scope will be assigned. For this layout to work, you also have to have (for this scenario) multiple gateway interfaces defined on the router’s interface servicing this network segment.
In today’s modern networks, I think it may be more appropriate to create multiple VLANs, use a relay agent, and set up individual scopes on the DHCP server.
Basically lets say you have VLAN 1 and you want to put 5 subnets inside this VLAN. Here is what the config would look like:
interface vlan101
ip address 10.10.10.1/24
ip address 10.10.11.1/24 secondary
ip address 10.10.12.1/24 secondary
ip address 10.10.13.1/24 secondary
ip address 10.10.14.1/24 secondary
Believe it or not this setup actually works! However, this is NOT optimal due to broadcast storms overriding VLAN 1 and also the lack of segmentation. This also creates a small issue with DHCP because when a client PC broadcasts 255.255.255.255 ALL servers and clients hear this broadcast because it is subnet independent and goes everywhere inside that VLAN. For superscopes to work you would need 5 IP’s associated with 5 interfaces OR have 5 subinterfaces attached to one physical interface. See how this gets rather muddy and can lead to issues? Also, because of the behavior or superscopes being a little “unpredictable” when you have all these domains in there and the nature of how it “rolls over” to the next range you get a mess of issues later on when your network grows.
How do we fix this? Let me introduce you to a simple concept of a VLAN. Each VLAN is its own IP SUBNET! NO EXCEPTIONS! In fact, let me give you the configuration example and I think you’ll understand it a little better. Lets assume your DHCP now exists on VLAN 1 with IP address 10.10.1.2/24 and has 5 different, multiple, scopes configured:
vlan 1
interface vlan1 ip address 10.10.1.1/24
vlan 10
interface vlan10 ip address 10.10.10.1/24
ip helper-address 10.10.1.2
vlan 11
interface vlan11 ip address 10.10.11.1/24
ip helper-address 10.10.1.2
vlan 12
interface vlan12 ip address 10.10.12.1/24
ip helper-address 10.10.1.2
vlan 13
interface vlan13 ip address 10.10.13.1/24
ip helper-address 10.10.1.2
vlan 14
interface vlan14 ip address 10.10.14.1/24
ip helper-address 10.10.1.2
Lets decipher this shall we? VLANS are a layer 2 concept and if we have a Layer 3 switch we can create a “Virtual” interface that is Layer 3 capable inside the VLAN to enable INTER-VLAN routing. Thus, create the Layer 2 VLAN with “vlan #” and the inside that create the Layer 3 virtual interface “interface vlan# ip adddress #.#.#.#/##”. Now, here is the cool part…you can setup the “relay” for DHCP with this command “ip helper-address 10.10.1.2”. Basically what this does is: Receive the Broadcast 255.255.255.255 port 67 and then change the IP from 255.255.255.255 to a unicast address 10.10.1.2 and set the giaddr to the “interface ip” and forward the DHCP request.
The server will receive it and look for a scope within its DHCP database that matches the subnet from the virtual VLAN interface on the router, find an open slot and “Offer” it back to the “interface IP” and then the helper-address relays it back to the client with the unicast address of the server itself (10.10.1.2). After this the “Request” from the client is unicast back to (10.10.1.2) and doesn’t use the helper-address as it knows the IP of the DHCP server and is just routed normally and then the server sends the “Acknowledgement”.
You will want to restrict the range that ip helper-address serves by issuing these commands:
no ip forward-protocol udp tftp
no ip forward-protocol udp nameserver
no ip forward-protocol udp domain
no ip forward-protocol udp time
no ip forward-protocol udp netbios-ns
no ip forward-protocol udp netbios-dgm
no ip forward-protocol udp tacacs
If you don’t do this your server will get all kinds of funky traffic and some things may not work as designed and you could be scratching your head as to why. All in all this is meant to be a brief overview of why superscopes are not a good idea for production use and why you should invest time into properly segmenting your network to ensure predictable and smooth operation.
