BootP and Many Unhappy Cisco Light weight Access Points

[Simon Hobson]

Martin McCormick wrote:

>	We set up several private networks to put our Cisco
>wireless Access points in. None of these networks have DHCP
>lease pools so each AP has a bootP entry.

Do you really mean bootp entry, of host statement with fixed address 
- they are about as similar as an orange and a banana !

>  When an AP does a
>DHCPDISCOVER, we see a "no free leases" message from the DHCP
>server even though there is a bootP entry for the AP. This may
>be due to the fact that we are also using HSRP or Hot Stable
>Routing Protocol on these networks.

<pedant mode>It's "Hot Standby Routing Protocol", a Cisco proprietry 
protocol</pedant mode>

>  As it stands now, we have
>one address listed in each network as a router
>
>option routers 10.196.83.254;
>
>	The DHCP server sees packets randomly on 2 or 3
>different addresses for the DHCPDISCOVER and may be getting
>confused on how to answer.

No, it doesn't care as long as the address is valid for the subnet.

>	The address we list as the router is a virtual address
>that is occupied by which ever of the 2 real routers is
>available.

That's OK

>	Eventually, and we are not sure how this happens, the
>bootP lookup works and the AP is on for a while. A few minutes
>later, it has gotten its download from the AP controller and
>reboots again only to get lost and so on and so forth.
>
>	Do we need to put all the routers in the
>option routers statement? This kind of defeats the redundancy in
>the HSRP.

No. The routers statement only tells the CLIENT what device to use to 
route packets outside of it's local subnet. It has no part whatsoever 
in the client initially getting it's lease.

When a client cold starts, it will broadcast it's DHCP Discover. Each 
relay agent (not the same as a router, but typically in the same 
device) will forward the request after putting in it's own local 
address in the Gateway Interface Address field - that is why you can 
see packets from each interface address. The DHCP server uses the 
GIAddr field to determine the clients subnet.

The server sends any offer to the address specified in the GIAddr 
field - it is then up to the relay agent to broadcast it on the local 
network for the client to receive it.

The same process is followed for the following Request-Ack exchange.

When a client comes to renew an existing, active, lease - it will 
(normally) send a unicast packet directly to the server from which it 
got the lease, and the server will unicast the response. These 
unicast packets are routed in the same way as any other unicast IP 
packets and the relay agent takes no part in the exchange.



The first step I would take is the check the contents of the packets 
on the wire and make sure that you really are matching the 
configuration.

After that, I would try adding a pool temporarily and see what 
happens. If the clients then get addresses you can study the lease 
entries and packets to see what's not quite right with your fixed 
addressing setup.