about concept "group", "shared-network", and "subnet", thanks.
marccp at srttel.com
Wed Apr 20 20:12:49 UTC 2011
Bruce, Andrew, and Simon - thanks, I appreciate your responses. It's _almost_ clear to me!
If this drawing show up un-mangled, I'll be amazed...
---------| | | | | | Opn 82
DHCPD |-- Server Vlan2 --| Switch |-----| Router |-----| Access
---------| | | | L3 relay | | L2 relay
So yes, what it looks like to me is that I have several subnets that are all in 1 shared network - vlan2. On vlan2, I only see DHCP broadcasted discovers from other vlan2 servers, something I don't want to answer for, hence my lack of authoritative on that subnet. There are actually 4 L3 relay routers, handling from /18 down to /26 networks, and all of these unicast DHCP discovers to the dhcpd server host on vlan2.
> The "shared-network" is meant to handle a case where you have two
>or more IP subnets sharing a single broadcast domain (aka VLAN, etc).
>In Cisco terms, you want a shared-network when-ever you have an
>"ip address ... secondary" on an interface.
That is not the case here. So does that mean I should have 0 shared-networks and only have subnet declarations?
>There isn't enough information to say whether your setup is right or wrong.
How about now? ;-)
>The key test is this. Can you unplug a device in the 10.1.0.0
>network, and plug into the same socket a device in the 10.170.0.0
>network and have it work correctly WITH NO OTHER CHANGES ? If not
>then they are not the same network and the subnets should not be in a
It's a little different than that, we are also using QinQ and all of our dhcp is relayed, so depending on where your encapsulation dot1q and second dot1q are defined (which particular router performing L3 relay) terminates the QinQ is which giaddr your discover will be forwarded with to dhcpd.
>As an example of what is NOT a shared network. Suppose 10.1.0.0 is on
>a network in one building, and 10.170.0.0 is on a completely separate
>network in another building - but connected via one or more routers,
>links etc. Taking a device to the first building and configuring it
>with a 10.170.0.0 address won't work, and vice versa.
>You definitely must NOT use shared-network in this case. If you do,
>then the DHCP server could assign either a 10.1.0.0 or a 10.170.0.0
>address to a device in either network, and of course, it's going to
>be pot luck whether the device gets a usable address or not. This is
>because when the server gets a relayed request via (say) 10.1.0.1 as
>the relay agent, it looks in the config and you've told it that
>10.170.0.0 is available there as well.
This seems to indicate to me that I shouldn't have any shared-networks. I thought I was clear on this, but now I'm not again ;-(
I think this explains why we've seen some devices get wrong IPs in some weird ways in the past. We also take steps to ensure that we only receive properly relayed dhcp filled in with valid option 82 info, by which we statically assign the host an address, but a few times we've seen unexpected dhcp from something else get an unexpected IP.
>As an aside, I'm fairly certain you cannot mix authoritative and
>not-authoritative in a shared network. The DHCP server is either
>authoritative or it isn't for a PHYSICAL network. So you probably
>only want to put authoritative at the shared-network level.
So 0 shared-networks then?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dhcp-users