Kurt Bales wrote: > Hello All, > > Just a follow up to this post. I got into work this morning and found this > problem occuring in overdrive!
As I believe I mentioned in a previous post, It's normal for the client to do an ARP *request* for the IP it's offered; that is how conflicts are detected before picking the lease. So, a normal process looks like this: client: DISCOVER src=0.0.0.0 dst=255.255.255.255 dmac=ff:ff:ff:ff:ff:ff router: DISCOVER src=gwip dst=serverip <optionally> server: ICMP PING dst=leaseip <then> server: OFFER src=serverip dst=gwip router: OFFER src=gwip dst=255.255.255.255 dmac=? [1] client: ARP request ip=leaseip <if no-one responds to the ARP> client: REQUEST src=0.0.0.0 dst=255.255.255.255 dmac=ff:ff:ff:ff:ff:ff <if someone responds to the ARP> client: DECLINE src=0.0.0.0 dst=255.255.255.255 dmac=ff:ff:ff:ff:ff:ff ...and so forth. The BOOTP broadcast flag in the request (which your MS KB talks about) determines whether the dmac in [1] is * flag=0: dmac=the ether addr of the client * flag=1: dmac=ff:ff:ff:ff:ff:ff I guess I'm not sure how turning on or off the broadcast flag would cause your symptoms; all it will affect is whether the router relays the DHCP/BOOTP reply as a layer2 broadcase or unicast. I suppose if it relays it as a broadcast then *other* broken dhcp clients on that network might see the offer and (even though they have a lease?) do the ARP, but again it's an ARP *request* so shouldn't poison/conflict with anything. And I can tell you for a fact that the DHCP *relay* in IOS supports the bootp broadcast flag just fine (don't know about the server, but I'd be immensely surprised if not) Are you able to expand in more detail on what you're seeing? _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
