Relay 82, ProCurve switch, IP source-lockdown

David McGaughey mcgoy1 at clearwire.net
Sat Mar 7 02:16:12 UTC 2009


Greetings list!

I'm writing this not so much  to find an answer to my problem, but maybe
instructive advice or at worst just something for the search engines.  I
have a problem where the dhcp server sends an odd DHCPNAK on a DHCP RENEWAL
that breaks IP source-lockdown on my network.  In fact, it actually makes
the port bounce on the switch and the DHCP renewal goes into a loop,
attempting to renew the address over and over.

Good or bad, this is what I am doing:  I am using ProCurve 2650 switches
with flash version H_10_74 installed.  My config for these switches look
something like this:

dhcp-relay option 82 replace
dhcp-snooping
dhcp-snooping vlan 2
interface 49
   dhcp-snooping trust
   exit
ip source-lockdown
ip source-lockdown 1-48

port 49 is my uplink, vlan 2 is the vlan that all ports are in.  My DHPC
servers are several subnets away and forwarding is used to reach them (in my
production install).

You see the option 82.  I am using option 82 to assign a single IP to any
device connected to a port.  The DHCP config looks something like this:

class "ms_rm116_sw2650_hp1.0.1"
{
 match if (
         binary-to-ascii (16,  8, ":", option agent.remote-id ) =
"0:1d:b3:1f:c2:80"
     and
         binary-to-ascii (10, 8, ".",  option agent.circuit-id ) = "0.1"
      );
}
pool {
 failover peer "dhcp-failover";
 max-lease-time 1800;
 range 172.25.254.100;
 allow members of "ms_rm116_sw2650_hp1.0.1";
}

class "ms_rm116_sw2650_hp1.0.2"
{
 match if (
         binary-to-ascii (16,  8, ":", option agent.remote-id ) =
"0:1d:b3:1f:c2:80"
     and
         binary-to-ascii (10, 8, ".",  option agent.circuit-id ) = "0.2"
      );
}
pool {
 failover peer "dhcp-failover";
 max-lease-time 1800;
 range 172.25.254.101;
 allow members of "ms_rm116_sw2650_hp1.0.2";
}
[]

So as you see there is a class for each port from the option 82 and a single
IP for each port in a pool.  A perl script generates the config for the
switch which is included into dhcpd.conf so that dhcpd.conf can be kept
clean and readable.

This works perfectly in the following schemes:

1)	the dhcp server is plugged into the switch and there is only one
switch in the vlan.
2)	The ip helper-address (or multiples of them) are specified on the
switch for which the option 82 classes have been created and that is the
only one switch in the vlan.
3)	IP source-lockdown is disabled and then there can be multiple
switches in the vlan and the ip helper address can be anywhere and on more
than one switch or better - on the router.
4)	Instead of using a single IP pool with option 82 classes for each
port, a whole subnet with a single range for one or more switches in the
vlan with many addresses in the range is used.  The ip helper addresses can
be on the router, or any multiple of the switches and it works.

The problem occurs under the following schemes:
1)	there are multiple switches in the vlan and the router is used with
the helper addresses.
2)	There are multiple switches in the vlan and any one one of the
switches are used with the helper addresses.
3)	There are multiple switches in the vlan and more than one of the
switches are used with the helper addresses.

I say addresses because both the failover peer and the main server are
specified with ip helper-address entries.  I've tried it with and without a
failover peer and the results are the same.  

Using vmware as a HUB with a knoppix and a windows xp virtual (all my
clients are windows XP SP2 with the post SP2 dhcp fixes installed) to
observe the network traffic, I was able to observe the DHCP client server
exchange when things work and when they don't.  When one of the working
schemes is used the wireshark exchange does something like this: Discover,
Offer, Request, Ack, Inform, Ack, Inform, ...

When one of the broken schemes is used, the wireshark exchange does
something like this: Discover, Offer, Request, Nak, Ack, Discover, Offer,
Request, Nak, Ack, Discover, Offer, Request, Nak, Ack, ...

This is in a loop.  It will do it over and over until IP source-lockdown is
disabled or the dhcp server is killed or the client is stopped from doing
the request.

My work around is to use the single IP address with the option 82 class and
to put a single switch into a vlan with the ip helpers on that switch AND
with the ip source-lockdown active.

I would really like to put more than one switch into a vlan, assign single
IP's to a port determined by its option 82 information and use the dynamic
ip source-lockdown.  All my switches are ProCurve.  ProCurve support can't
reproduce this problem (but I don't think they have really tried).

Anything you all can tell me on this list would be very much appreciated!




More information about the dhcp-users mailing list