single dhcp server with multiple subnets

Simon Hobson dhcp1 at thehobsons.co.uk
Thu Jul 31 12:06:52 UTC 2014


"Senko, Mike" <Mike.Senko at seattle.gov> wrote:

> I was thinking or perhaps assuming too much, the Relay Agent allowed the dhcp request packet flood pass to the configured dhcp server.

Sort of. It picks up the broadcast packets, adds information to show where it came from, and then forwards it to the server(s).

> With the server directly connected to the switch, no further hops would be made. If the packet had to be transported to another switch, then the router would be needed to get it there.

You appear not to understand the difference between L2 and L3.

A router is NOT required just because client and server are on different switches. If we leave out VLANs for a bit, you can build a large network with loads of switches and any device can talk to any other device regardless of which switches they are connected to. This is your layer 2 switching - the switches simply handle packets based on the MAC address and regardless of protocol. Also, all the ports are part of the same broadcast domain - as in if you send a broadcast packet, it will be seen by every device on the network.

Now add a separate bunch of switches, as a separate and unconnected broadcast domain. If you want packets to pass between them, you either connect them directly making a bigger single network, or you use a layer 3 device (aka router) to pick up packets from one network and forward them. With IP, you'd refer to these as being separate IP subnets.

Introducing VLANs does **NOT** change this. It simply merges the two sets of switches into one bigger box with virtual LANs. Simple case would be a 24 port switch, no trunks, and 12 ports on one VLAN and the other 12 ports on another VLAN. The switch would behave just like two separate 12 port switches. You could extend it to another switch by using two network cables - just as you'd do if you were using multiple 12 port switches.
Trunking merely allows you to merge these two cables into one - just as the VLAN support allows you to roll up the separate switches into one bit of hardware.
If done properly, the VLANs are still completely separate and packets sent by a device in one VLAN cannot be seen by a device on another VLAN.

So you still need a router (L3 device) to pass (route) packets between the virtual networks. Many higher end switches include routing capabilities - so logically these are multiple switches, plus a router, all rolled up into one box. If you aren't clear in your mind what does what, then you will probably struggle.



> I'll have to read the Option 82 pages  again. How it functions may also depend on Rugged Com's implementation too. That old phrase regarding standards, -" there's so many of them!"

Option 82 isn't a fundamental part of the relay operation - it's an optional extra. The only fundamental bit is that the relay agent fills in teh GI-Addr field which tells the server a) that the packet has been relayed, and b) which network it came from.
Option 82 is an optional feature that also adds information on the physical port the device is attached to. This may be of use to network admins - particularly if they need to "lock down" certain devices to certain ports.

> I usually capitalize L-3 Vlans to help differentiate between L-2 and L-3.

VLANs are a layer 2 function

> What is interesting is the DHCP Relay Agent config parameter is on a layer 2 switch

It probably indicates that it's a layer 2.5 device - it's nominally a L2 switch, but includes a minimal set of L3 functions. However, bear in mind that a DHCP relay agent can be *anywhere* in the broadcast domain - it does not have to be on a router or switch.

> The router I have (also RuggedCom) also has the DHCP Relay Agent parameter so it become a bit confusing if both are needed or just one.

I would suggest disabling all IP functions in the switch other than an IP address for it's management interface. Then trunk the VLANs to the router.
That way, it removes (almost) all the confusion about what is happening where.
Once you have it working, you can start to move functions - one at a time and see if anything breaks !



More information about the dhcp-users mailing list