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.
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.
can you run a sniffer on the windows server and post the capture file.
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]
I hope this helps.
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 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.
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 184.108.40.206 - 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.
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?
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.
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.
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
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.
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.
By the way, restoring the DHCP server from the DHCP console will fix everything. I've discovered that if I stopped the dhcp service while tinkering with the router it prevents the bad_address issue. Like I said I returned the router so I can't do an analysis as to what the issue was, unless the new one does the same thing :(
Hi, I know that this is pretty old, but I'm wondering if you ever discovered the issue?
We recently received a "new" 1941/k9 but had problems with it because it took cisco/cisco for logging in, but were unable to get into CCP. Cisco wouldn't give us any support at all because they said the seller wasn't authorized.
While I was t/s that issue, the exact problem you referenced sprung up. It took me a while to figure out what was doing it, but it was absolutely the Cisco.
Basically the issue is that it is causing many if not all of the IP addresses to be detected as duplicates on the network. Not only was it screwing up my DHCP reservations (with the short mac addresses) and causing it to give BAD_ADDRESS, but it also would prevent us from assigning a static IP to a client. Any attempt to do so would result in the IP address being listed as "(Duplicate) instead of (Preferred) in ipconfig /all.
It was affecting Windows clients, server, and hardware devices... Pretty much everything.
I disabled the switch port it was connected to and had to restore my dhcp database (as it had permanently ruined my reservations) and everything returned to normal.
This was a bit terrifying because I could have probably plugged this beast into anybodies network and brought it down...
We had to return the router because of the support issue, but I would like to find the cause of this issue in case it ever happens again, as it would be a real bear to track down had I not known that the Cisco was "new".
I gave up. The router has a few Ports, so everything that needed access to the WAN got it directly. A complete autarkic network.
I cold give it a new try. My DHCP is now 2012 R2 and I have a new Alcatel OmniSwitch 6900 as core.