Host declarations

[Alex Moen]

> Alex Moen wrote:
> 
> >We're in a situation where we have DSLAMs scattered throughout 5 
> >different towns.  The relay-agent IP addresses are all on different 
> >subnets.  Each DSLAM has a set of DHCP addresses assigned to the 
> >customers on that DSLAM.
> >
> >However, we would like to use a common pool for customers paying for 
> >DHCP-assigned static (some say "persistent") addresses, as the areas 
> >are small enough and the requests are few enough to warrant sharing 
> >between these towns for ease of administration and also more 
> efficient 
> >address use. Normally we just put a mac address reservation for the 
> >client into the DHCP server and it works. However, since the 
> >relay-agent IP addresses are on different networks, and each system 
> >already has subnet declarations, how do we share a pool 
> between them?  
> >Is there a key phrase in the config that forces the server 
> to hand out 
> >an address based on MAC address, bypassing the 
> checks-and-balances that 
> >the shared-subnet statements give?
> 
>  From the basic IP networking point of view, you are wrong. It would 
> be absolutely wrong for the dhcp server to allocate an address to a 
> client which was not in the subnet served by the clients network - to 
> do so would be to misconfigure the client so that it could not 
> operate on that network.
> 
> >It seems to make sense to me that if a MAC reservation has 
> been made, 
> >it should take precedence (based on the "most specific" rules that 
> >apply to other IP addressing things) over anything else that 
> the server 
> >knows about.
> 
> No, see above. The client must be given an address which is actually 
> usable by it.
> 
> >Does anyone have any ideas on how I can make this work?  I can put 
> >actual examples of subnets and VLAN info up here, but it is way 
> >complex, possibly more complex than is needed to solve the problem.
> 
> Well the only way I could see of doing it would be to create a large 
> subnet bridges across all five 'sites', and get the relay agents to 
> use an address from that subnet for those clients. What you won't be 
> able to do is use a shared subnet because the server doesn't support 
> the complexity required to deal with subnets A-E all sharing cable 
> with subnet X, but NOT shared between each other.
> 
> 
> I think it's a case of the software being used in situations 
> (cable/dsl installations) which were simply not envisaged when the 
> design was first layed out, and which are sufficiently different from 
> "ethernet and serial links" networks which were the norm until only a 
> few years ago.
> 
> 
> What you could probably do is treat the whole network as one big 
> network and assign addresses by option 82 (ie level 2 port id instead 
> of level 3 Ip address) - but again, the current software 
> implementation is not good at that and requires some messy config 
> hacks to work.


The problem has been solved.  My router guys found the solution.  I failed
to include some important information in my description, in particular, the
location of the relay agent.

First and foremost, you are right, there were some things in the original
design of the network that were flawed.  These DSLAMs should all have been
on the same subnet, to facilitate this.  New deployments are taking this
into consideration and the problem does not exist.  It is just extremely
difficult to change the DSLAM IP addresses now, once they are in production.
On to the solution:

Currently, the DSLAMs themselves are the relay agents for the VLANs that
they have on them.  The trick in sharing a VLAN between our DSLAMs is to
bring the relay agent to a centralized location, in this case, the router
interface that is hosting the actual subnet itself.  We lose the Option 82
information that the DSLAMs normally provide, but it is not a problem in the
static IP address allocations, because we know who is using each IP address.
Basically, we bridge this particular VLAN back to the router.

Since the normal, non-static customers are using a different VLAN (not
stated above, but kind of implied, another oversight on my part), and the
DSLAM is the relay agent for that subnet, it is not affected and will
continue to get it's IP address from the pool assigned to the VLAN.

Sorry about the confusion, and the long post, but I figured I should at
least post our resolution in case it helps someone else.  Thanks also to
Niall O'Reilly, who also commented on this, and pretty much intuited the
solution.

Alex