BootP and Many Unhappy Cisco Light weight Access Points
dhcp1 at thehobsons.co.uk
Tue Mar 25 19:01:44 UTC 2008
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
> 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
> 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
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
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
More information about the dhcp-users