Cisco 892 interfere with Windows DHCP Server[BAD_ADDRESS]

[Sven Ungerecht]

Hi,

I have trouble with a Cisco 892 Router from my Internet service provider.

Last week we switched from a virtual Router to a hardware Router. But after plugging it in our LAN Switch, the Windows DHCP Server stopped leasing IP's. I got many BAD_ADDRESS with MAC like e1:80:10:ac, e2:80:10:ac, e3:80:10:ac, e4:80:10:ac, e5:80:10:ac, ea:80:10:ac, eb:80:10:ac, ec:80:10:ac and so on.

I do not have access to the Router config, so I can not dump the config to you. We have a flat LAN, single SUB-Net(172.16.0.0/16) and no VLAN, no Spanning Tree. A Keep it Simple, Stupid(KISS) System.

A tech guy from service provider, is telling us, the error is not there fault and my switch is not correctly configured. But this is bullshit. For years we had a another Cisco Router from the precursor ISP and for 2 years the virtual Router from our current ISP. No trouble with my DHCP. But after plugging the new Router in, my DHCP stopped working.

On the 892 is no running DHCP, but something interferences with my Windows Server 2008 R2 SP1 DHCP Server.

I need a tip to confront the tech guy.

Thanks

[cadet alain]

Hi,

I got many BAD_ADDRESS with MAC like e1:80:10:ac, e2:80:10:ac,  e3:80:10:ac, e4:80:10:ac, e5:80:10:ac, ea:80:10:ac, eb:80:10:ac,  ec:80:10:ac and so on.

what do you mean by that ? are these real hardware addresses you've got? because there are some here which are multicast addresses not unicasts.

Regards.

Alain

[Sven Ungerecht]

No real addresses.

[cadet alain]

Hi,

can you run a sniffer on the windows server and post the capture file.

Regards.

Alain

[Sven Ungerecht]

Alain,

I have updated the discussion and attached a ZIP File with 2 Wireshark Captures. First no Cisco Router on the LAN, second with on LAN. I got 3 BAD_ADDRESS (8e:80:10:ac[IP 172.16.128.142], 91:80:10:ac[172.16.128.145]
and ca:80:10:ac[172.16.128.202]
).

I hope this helps.

Sven

[paul.matthews]

I have had a quick skim of the traces, and nothing obviously jumps out.The addresses you are posting do look a little odd - where exactly are they being reported? They look a little short  ec:80:10:ac - I cannot fit those as MAC addresses in any of the common notation formats.  What I note about them though is they may well be IP addresses. ec:80:10:ac if we decode the hex to decimal we get  236.128.16.172 Spin it round and we have an IP address in your network - 172.16.128.236

Looking specifically at the DCHP in your traces, there does not look t be anything obviously amiss.

We need to see what exactly is complaining, and what the details of the report are.

Paul.

[Sven Ungerecht]

I can see them above on the DHCP Management console from Windows.

BAD_ADDRESS piles up and the Network cliets get no IP from my DHCP.

[paul.matthews]

My german is non existent. so I am not sure what the headings are, but the value in the Eindeitige ID fiels is the IP address mentioned in the client IP field. With that frames 9052 and 8436 look relevant - they are DCHP declines for some of those addresses.

Superficially it looks OK. The DHCP specific sequence is:

8351 - discover (client)

8371 - Offer (server)

8375 - request (client)

8376 - Ack (server)

8436 - decline (would expect inform) (client)

I can't see an obvious reason for the decline. Looking at the fuller trace, there is some activity on IPv6 from that PC before the decline.Before the decline we also see the PC arp for the address it has been offered, but see no response at the server. It joins 224.0.0.252 - Link-local Multicast Name Resolution (LLMNR) address, and tries similar on IPv6.

I'd try a wireshark from that PC (Melanie-PC) as we would not necessarily expect to see responses to those from the server.

[Sven Ungerecht]

I think the DHCP problem rests on the build up from the BAD_ADDRESS. On some point, the DHCP Server has

exhausted all his available IP addresses.

Browsing over in Wireshark, I could see Cisco Spanning-tree-(for-bridges)_00. We use HP switches with no Spanning tree. Could this be the culprit of the problem?

[paul.matthews]

Spanning tree is in use pretty much the world over with no ill effect on DHCP. The server is providing an address, so exhaustion unlikely. The client is declining the offer.

I would want to see a trace from the PC itself, and I would be tempted to disable IPv6 on it as a test.

[Sven Ungerecht]

Yes, the server provided an address, but id had only 5 BAD_ADDRESS on that time. But last week it had hundreds of BAD_ADDRESS entry's. The IPv4 scope is 172.16.128.0 to 172.16.129.255. If all used with BAD_ADDRESS, no client can get a IP from the DHCP Server.

So my problem is to get rid from the BAD_ADDRESS in my DHCP, when the Cisco is pluged in my Network.

[Sven Ungerecht]

Any idea how to get rid of the BAD_ADDRESS in the DHCP Server?

[Torsten Jahnke]

Client computers running Windows Server 2003, Windows XP, Windows 2000, Windows NT 4.0, Windows Millennium Edition, and Windows 98 automatically check to determine if an IP address is already in use before using it.

After the DHCP client receives a lease from the DHCP server, the client sends an Address Resolution Protocol (ARP) request to the address that it has been assigned. If a reply to the ARP request is received, the client has detected a conflict and sends a DHCP-Decline message to the DHCP server. The DHCP server attaches a BAD_ADDRESS value to the IP address in the scope for the length of the lease. The client then begins the lease process again, and is offered the next available address in the scope.

Likely an overlapping scope on another DHCP server (maybe authorised or rogue) or a PC with static IP that conflicts.
If you have Dynamic DNS or WINS you can check those for reverse registrations of the IP.

Also nbtstat -a to chase it down. Once you find the conflicting machine, check IPCONFIG /ALL to track down the DHCP server if it's a DHCP client and not statically assigned. Some network monitoring for DHCP traffic will also track it down too.

[Sven Ungerecht]

We have nearly 90% Windows 7. And I get BAD_ADDRESS only with the

Cisco 892 Router attached. And no running DHCP on the Router. Somehow the Cisco interferences with the DHCP process. I have no glue how. Something is fuc[k]ed up.

[paul.matthews]

You need to get a wireshark trace from one of the failing PCs. Torsten's description matches what I see in the traces. That makes it look like as the client is offered an address and tries to ARP it something responds.

It is indeed suspicious that it happens with the provider's router in place. With this information you perhaps need to ask them do they have any secondary addresses, or are they providing DHCP in any way.

An interesting test may be to shut down your DHCP server, and see is something can get an IP address.