[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1579
  • Last Modified:

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
0
stepstraight
Asked:
stepstraight
  • 5
  • 4
  • 3
  • +2
1 Solution
 
pseudocyberCommented:
Am I blind or are those two MAC addresses identical?

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.
0
 
stepstraightAuthor Commented:
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
0
 
harbor235Commented:
Do you have a product from Telogy Networks, Inc?

harbor235
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
harbor235Commented:
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
0
 
pseudocyberCommented:
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?
0
 
stepstraightAuthor Commented:
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!
0
 
ViRoyCommented:

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.
0
 
rburns50Commented:
I saw this on our network once, and it was a bug in the SW on the LAN switches, not in any server. When rapid spanning tree was enabled on the switches, occasionally traffic load would cause one of the switches to start crunching MAC's and  corrupting its' arp tables. It would then report that a certain IP was at a corrupted MAC address, while another switch reported that IP at the real MAC address- hence, it looked as if there was an IP conflict between two hosts, but there really wasn't a conflict.

FYI, it was exactly the same behavior- one or two characters in the MAC address would be off. I would report the bug to the switch manufacturer- we got a patch and it fixed the problem.
0
 
stepstraightAuthor Commented:
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.
0
 
rburns50Commented:
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.
0
 
stepstraightAuthor Commented:
All our powerconnect switches are running in classic spanning tree, curious what your thoughts are on that.
0
 
rburns50Commented:
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.
0
 
stepstraightAuthor Commented:
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?
0
 
pseudocyberCommented:
We're mostly Nortel with some Cisco.  I've never heard of it before.
0
 
rburns50Commented:
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.
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 5
  • 4
  • 3
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now