FW: one host with multiple concurrent leases from different pools

[Curt Rask]

First and foremost, I'm not trying to suggest that the DHCP server isn't operating as designed.  I believe that it is.  I apologize if you felt like I was trashing the server software.  I thinks it's an awesome piece of software that is extremely flexible, and it is that flexibility that I have come to depend on and need help with.  Second, the implementation I have isn't broken.  It may not be configured according to the design requirements and constraints which produced the DHCP server software in the first place, but it is configured to work in a network outside the typical L3 conventions from back in the day.



In that, what I need to find is a solution for a particular problem where I don't have control over certain elements.



1.  I cannot make the relay agent in this scenario add GIADDR information that is pertinent to the network/VLAN involved.  It is a layer 2 switch, not a layer 3 switch/router.  It cannot support IP's on each VLAN.  It can't route.

2.  The end-point in this case is the same end-point making multiple requests on multiple different VLAN interfaces.  These requests are serviced out of different IP networks.

3.  I cannot set different UID's on the end-point.

4.  The network I describe is a large, service-provider type network where there exists a layer2 access network comprising thousands of customers.  It is imperative, in these types of networks, to distribute as much functionality as possible in order to:

     - reduce load on any individual network component. Ie, if I had a power outage scenario, a single router with 10,000+ endpoints all DHCP'ing simultaneously could cause the router to struggle causing slow processing of requests where it could take 30min or more to fully restore connectivity or even potentially reload.

     - provide user traceability.  By *only* relaying at the router where I have 10000+ devices connecting, my option 82 information would reflect just that.  By pushing the option 82 setting ability further afield, I get more accurate user information regarding the chassis, port, and vlan that DHCP request came from in the event I need to back track and determine what a malicious customer might be up to for law enforcement purposes.



So, I have a configuration where I've "twisted the knobs" to get software that was designed with one set of requirements in mind to work in an entirely different way.  It works and works well.  What I'm hoping to accomplish now, is to find a way to make things work even better.



The server correctly identifies the client's "soft" interfaces based on the agent.circuit-id and assigns the appropriate IP addresses for each pool/network/VLAN.  It also allows the same client to renew all of the IP interfaces at the lease half-life, and allows all of the leases to be "active" concurrently.  My one device with 5 VLAN interfaces eventually succeeds in renewing all 5 addresses, and the server then shows all 5 leases as active.  So, at some level it does allow for my type of network.  It doesn't seem to care whether a particular client with the same UID & same HW address has different IP addresses in many different networks.  This lead to the thought of trying to make the initiation process work by having the server rewrite the UID to include a concatenation of the option 82 Circuit ID and the HW address.



If it's not possible, I can accept that and will take it up with the developers of these devices to try and work out an amenable solution.  However, if the server can do this, or if anyone has another suggestion on how to tweak a knob to accomplish the differentiation, I would very much appreciate the help.



Thanks,

Curt







>I have all of my network (DHCP relay points) and DHCP statements

>configured to hand out IP's to a single device.  The problem I am

>finding is that during the initiation phase (DHCP Discover, Offer,

>Request, ACK), each of the leases negates the previous one.  The

>IP's being handed out are the correct IP's for the VLAN in question,

>it's just the server seems to think that the new "discover"

>supplants the existing lease info.



It is behaving correctly I believe.



>For my configuration, the "host" is a network device that is VLAN

>aware and uses the same MAC address for each of VLAN interface that

>request an IP.   The relay agent is not a router.  It is another

>switch that has some L3 ability.  When it relays, it sets the GIADDR

>to the one and only 1 IP address it uses for management.  It also

>sets option 82 information for Remote-ID, and Circuit-ID.  The

>circuit ID contains physical interface information, as well as VLAN

>information which is unique to the host.  Additionally, the UID of

>the client is the same, regardless of which VLAN it makes a request

>on.



OK, here is what I think is happening :



Firstly, your switch is NOT setup correctly. "... switch that has

some L3 ability.  When it relays, it sets the GIADDR to the one and

only 1 IP address it uses for management ..." does not describe a

proper multi-network relay agent which would set the GI-Addr

correctly to an address appropriate to each physical network to which

it is connected. This means that you have to workaround the issue by

incorrectly using a shared network statement when you do not in fact

have a shared network - each VLAN is a DIFFERENT network.





Then we have this bit - "... the UID of the client is the same,

regardless of which VLAN it makes a request on." This means that the

client is THE SAME CLIENT whichever network it is on - both the MAC

address and Client ID are the same, therefore it is the same client

(not a number of different clients).



My only guess as to why it might be freeing the other leases is this :



Client comes along and matches class "B" but not class "A".

Client previously had a lease in a pool permitted for Class A, but

this time it does NOT match Class A.

Server identifies that client does not match Class A, whilst it IS

currently connected to that physical network, and deletes the active

lease as the client is not entitled to it.



Perhaps someone more intimate with the code could confirm if this is the case.





What I suggest you need to do is fix your broken relay agent - it

needs to correctly set GI-Addr to an address valid for a subnet on

each VLAN. Then remove the incorrect shared-network statements.



If you can fix these two problems then i think you'll find that the

setup will work correctly.



--

Simon Hobson



Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed

author Gladys Hobson. Novels - poetry - short stories - ideal as

Christmas stocking fillers. Some available as e-books.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20081031/2769b20b/attachment.html>