[c-nsp] Windows Vista, Gratuitous ARP and DHCP conflicts

[Phil Mayers]

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?