stepstraight
asked on
False IP Conflict
Ok guys and gals, I've got a good one for you.
Running Exchange 2003 on a Server 2003 Standard box. Periodically we get IP conflicts all over our grid that we think is related to this specific box somehow. Following is the error message we get from this suspected box:
The system detected an address conflict for IP address 192.168.0.99 with the system having network hardware address 00:E0:A6:19:16:64. Network operations on this system may be disrupted as a result.
Now the interesting thing is, the MAC addy for the NIC in this box is 00:0E:A6:19:16:64, which as you'll notice, the third and fourth digits are inversed. No where on our network do we have a MAC addy that matches that. We run PowerConnect 5324 switches primarily. Does anybody have any ideas, bug with Server 2k3? Thanks.
Ryan
Running Exchange 2003 on a Server 2003 Standard box. Periodically we get IP conflicts all over our grid that we think is related to this specific box somehow. Following is the error message we get from this suspected box:
The system detected an address conflict for IP address 192.168.0.99 with the system having network hardware address 00:E0:A6:19:16:64. Network operations on this system may be disrupted as a result.
Now the interesting thing is, the MAC addy for the NIC in this box is 00:0E:A6:19:16:64, which as you'll notice, the third and fourth digits are inversed. No where on our network do we have a MAC addy that matches that. We run PowerConnect 5324 switches primarily. Does anybody have any ideas, bug with Server 2k3? Thanks.
Ryan
ASKER
The are almost identical. So I went and checked the address tables for the offending MAC addy, and as I knew would be the case, it was not found. I really feel this is some sort of Server 2003 bug/glitch. Perhaps I should have put it in a different sections, but what the hey. Anybody have any ideas out there?
RYan
RYan
Do you have a product from Telogy Networks, Inc?
harbor235
harbor235
I used the mac address you listed (00:e0:a6) and looked up the vendoe code.
Here is some additiona information:
www.telogy.com
Telogy Networks, A Texas Instruments Company, develops complete, silicon and software solutions for Voice, Fax, and Data over IP. TI's programmable DSPs with Telogy Software® products are complete Voice over IP (VoIP), Fax over IP (FoIP) and Data over IP solutions for equipment manufacturers who want to integrate voice, fax and data into their products.
harbor235
Here is some additiona information:
www.telogy.com
Telogy Networks, A Texas Instruments Company, develops complete, silicon and software solutions for Voice, Fax, and Data over IP. TI's programmable DSPs with Telogy Software® products are complete Voice over IP (VoIP), Fax over IP (FoIP) and Data over IP solutions for equipment manufacturers who want to integrate voice, fax and data into their products.
harbor235
Ah, I see, the E0's are swapped.
I would think it would be a defective card before a problem with the OS. Maybe try a different network card?
I would think it would be a defective card before a problem with the OS. Maybe try a different network card?
ASKER
Well I put in a phone call to Telogy technical support and they had never seen anything like it either. The offending NIC is onboard so I'll try a different one and get back to yall. Good info!
the first 2 sets of the MAC address are used for vendor identification http://www.iana.org/assignments/ethernet-numbers
multiple MAC addresses can be assigned logically to a physical adapter, however i dont see why it would show the inverse of the 3rd and 4th like yours.
maybe you should change the MAC address of the NIC and see if you still get a inverse conflict problem.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Interesting post rburns50....I'm curious if you tried switching ports on your switch to try and alleviate the issue, or if a firmware upgrade was ultimately what fixed the issue.
I'm not sure what you mean by switching ports on the switch...the issue was not a device- it was the actual switch itself. Switching ports would not help the situation at all, as it was caused by a combination of 2 things: rapid spanning tree and a specific type of traffic load (I think it was multicast traffic, but can't remember which type). The HW vendor fixed the lethal combination with a custom firmware patch. We could have dropped rapid spanning tree, or filtered out the multicast traffic, but the bug was a new one and a patch was released (should have named it after me).
Funny- I thought I was the only guy in the world that had experienced this, but I spoke with a colleague today who also had a similar problem on another vendor's switches. Not exactly the same behavour, but similar munching of MAC addresses. His was also fixed with a firmware upgrade.
Anyway, it's a tough one to pinpoint, so good luck. Mine was on a multi-VLAN environment, with over 7000 active LAN ports...a couple of weeks of head-scratching and snooping/captures for sure.
Funny- I thought I was the only guy in the world that had experienced this, but I spoke with a colleague today who also had a similar problem on another vendor's switches. Not exactly the same behavour, but similar munching of MAC addresses. His was also fixed with a firmware upgrade.
Anyway, it's a tough one to pinpoint, so good luck. Mine was on a multi-VLAN environment, with over 7000 active LAN ports...a couple of weeks of head-scratching and snooping/captures for sure.
ASKER
All our powerconnect switches are running in classic spanning tree, curious what your thoughts are on that.
I wasn't trying to suggest that you have the identical issue that we had, only that similar behaviour has occurred on two different hardware vendors' switches (yours would make 3 different vendors). Each time, it was fixed by a software update. I can't definitively say that will fix the problem- every network is different. However, just trying to tell you what I have experienced.
Spanning tree (or rapid spanning tree) are not bad in themselves. In our case, it was a bug in the firmware- not the technology or protocol chosen.
Spanning tree (or rapid spanning tree) are not bad in themselves. In our case, it was a bug in the firmware- not the technology or protocol chosen.
ASKER
Well I phoned Dell and talked to a level2, they had never heard anything about it. I'm curious if when these custom patches were released if they gave you any release notes that may help in narrowing down the cause of this issue. What other vendors have we seen this in out of curiosity?
We're mostly Nortel with some Cisco. I've never heard of it before.
I was using Foundry Networks (BigIron 15000's in the core and FastIron 15000's in the riser closets). My colleague was using Nortel switches. Both of us saw similar things, although not identical. Both were fixed by firmware updates. In my case, Foundry had also never seen it- that's why I said they should have named it after me. They wrote a custom patch for it, and then included that code in future revs. My colleague didn't get a custom patch- he just went up to the latest firmware rev, and the problem disappeared.
I'm not trying to prove to you that it happened. I'm just offering up my experiences. As I said, what causes it may differ from network to network...and I won't assume that firmware will fix it. But surely some of you guys have to admit that it LOOKS a hell of a lot like a switch somewhere is mashing the MAC addresses....and switches run on software that tell them how to process MACs and manage ARP tables. It could be hardware....but my money is on a software bug.
I'm not trying to prove to you that it happened. I'm just offering up my experiences. As I said, what causes it may differ from network to network...and I won't assume that firmware will fix it. But surely some of you guys have to admit that it LOOKS a hell of a lot like a switch somewhere is mashing the MAC addresses....and switches run on software that tell them how to process MACs and manage ARP tables. It could be hardware....but my money is on a software bug.
When it occurs, could you unplug your server and ping and traceroute to the IP to verify it's alive on the network? Your traceroute should indicate which IP segment it is and go to that default router and look in its ARP table for the MAC and possibly the port (if it's a layer 3 switch). Or you can go into your Forwarding Tables on your switches to find it.