<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Marc<br>
<br>
Thank you for the suggestion. I am currently dumping arp traffic (of
course, now the problem does not show up!)<br>
<br>
I am unable to dump as:<br>
<br>
1) It seems random which clients are affected,<br>
2) I currently have no equipment at hand to dump<br>
<br>
It is a residential network, so people set up a multitude of
equipment, brands, models, configurations etc. so the problem might
come from almost anywhere. I am not aware that any proxy-arp
equipment is installed, but of course someone might have installed
just about anything. Rogue DHCP-servers happens often, but I am
mostly on top of these (one sending NAKs but not OFFERs would be
unusual).<br>
<br>
I will try to get my hands on a two-NIC computer able to run tcpdump
to place between an affected computer and the network.<br>
<br>
If anyone else should have other suggestions in the meantime, I
would be very happy.<br>
<br>
Best regards and thank you<br>
/Rasmus<br>
<br>
Den 20-08-2010 15:57, Marc Perea skrev:
<blockquote cite="mid:4C6E4371.39E4.004A.0@srttel.com" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<meta name="GENERATOR" content="MSHTML 8.00.6001.18812">
<div>Hi Rasmus,</div>
<div>this problem can have a few different causes, but I remember
having a similar issue when we had Vista attached to a Cisco
relay agent on a router. After specific positioning of a packet
capture to identify the behavior, Vista sends a gratuitous arp
after the ACK as one final check to see if anyone else on the
network has that IP before binding it to its interface for use.
Unfortunately for us, our Cisco router was answering that arp
with its own MAC, presumably identifying that the Cisco could
get to that IP so it responded to the arp by proxy. We did a no
ip proxy-arp on that interface and our router stopped responding
to the g-arps, and things were quiet (and working).</div>
<div> </div>
<div>Not sure if this is the case for you or not, but I'd at least
get a sniff going just north of the client to see what situation
is occurring that causes the client to DECLINE - delayed NAK
perhaps from another piece of gear?</div>
<div> </div>
<div>HTH -- Marc</div>
<div><br>
>Over the last months I have suddenly seen a behaviour, that
is new to<br>
>me:<br>
><br>
>1) Client DHCPDISCOVERs<br>
>2) Server DHCPOFFERs<br>
>3) Client DHCPREQUESTs<br>
>4) Server DHCPACKs<br>
>5) Client DHCPDECLINEs<br>
>6) Server abandons IP<br>
>7) Goto 1, with new IP</div>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
dhcp-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dhcp-users@lists.isc.org">dhcp-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/dhcp-users">https://lists.isc.org/mailman/listinfo/dhcp-users</a></pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Rasmus Bøg Hansen || <a class="moz-txt-link-freetext" href="http://www.zz9.dk/">http://www.zz9.dk/</a>
<a class="moz-txt-link-abbreviated" href="mailto:moffe@zz9.dk">moffe@zz9.dk</a> ||</pre>
</body>
</html>