IT Leaders
Hosted by MRCROSSROADS
This is a forum for IT Managers, Directors, VPs of IT, CTOs and CIOs.
- 34
MEMBERS - 47
MESSAGES - 0
POSTS TODAY
Discussions
Troubleshoot folder? Troubleshooting
Started May-24 by WALTER784; 63 views.
From: WALTER784
May-24
Would you consider opening up a Troubleshooting folder?
So those who have overcome certain technical barriers can explain how they overcame them?
FWIW
Host
From: MRCROSSROADS
May-25
Sure. I can repurpose another folder that will probably never get used otherwise. Great suggestion
From: WALTER784
May-26
OK then... so anybody with problems they're currently troubleshooting but can't seem to find the problem should post here.
.OR.
If you have "your most difficult to troubleshoot" story you would like to share... then this is the place to post it. I have quite a few of these that I will post below one at a time. Some of them were real nightmares! But give me a day or two to compile them.
FWIW
From: WALTER784
May-26
Duplicate MAC Address Problem
The problem occurred back in the latter 1980's.
We had just moved CitiCorp headquarters from two buildings into a brand new 17 story single building headquarters.
One of the buildings was installed by IBM and used Token Ring (802.5) network topology (4Mbps).
The other building was installed by DEC (Digital Equipment Corporation) and used Ethernet (802.3) network topology (10Mbps).
The two buildings didn't really communicate much with each other because they both served different purposes and not much need to communicate between the two.
But when the new 17 story building was set up, they used FDDI (100Mbps) as the backbone and had both Token Ring and Ethernet on multiple floors.
All Ethernet systems were tested and were working properly with each other as well were the Token Ring systems also working properly with each other.
After a few weeks of smooth running, the corporate management wanted to start testing communications between Ethernet systems and Token Ring systems. For the most part, those tests too went fairly well.
Then, all of a sudden, one duplicate MAC address error occurred, then another and another and another. We searched all of the subnets... about 34... and recorded all of the MAC addresses, but couldn't find a duplicate on any of them.
So we replaced the Ethernet or Token Ring NIC of the device(s) giving off the Duplicate MAC address error, and one by one, the problems were slowly resolved.
So we worked with the FDDI manufacturer to find out what the cause was and discovered that it was due to an FDDI related issue. We documented the problem from our end and the FDDI manufacturer took the problem up with the IETF.
When the IETF read our reports, they came out with a new RFC based around a new FDDI-2 protocol... but it took about 4 months for that to happen. Until then, we just swapped out NICs when a new Duplicate MAC address error occurred.
Finally, when the new RFC was finally released, we updated all of the FDDI routers and the problem never surfaced again.
The problem was unique to our environment. All other FDDI users had ONLY Token Ring or ONLY Ethernet. And if you only have one or the other... this problem will NOT occur.
The problem was that the original FDDI RFC protocol was based around an "encapsulation" technique such that the original MAC address of the sending device on one end is "encapsulated" and sent to another FDDI device where they "decapsulate" the MAC address and forward it on to the final destination.
So what was the real problem?
Today, nobody uses Token Ring anymore that I'm aware of... so many engineers today probably don't know this, but one of the biggest differences between Token Ring and Ethernet was the way they read the MAC addresses is completely reversed (MSB {Most Significant Bit} vs LSB {Least Significant Bit}). (i.e. left to right or right to left).
Basically put, when the original FDDI encapsulation RFC transported an Ethernet MAC address to a Token Ring device, the MAC address needed to be flipped, but there was no way of knowing whether the sender or receiver was Ethernet or Token Ring and thus no way to know which MAC's to flip and which MAC's not to flip, etc. to resolve the problem.
So when the new FDDI-2 RFC came out, they changed the "encapsulation" method to a "translation" method.
What that did was take what ever MAC address was received (regardless of topology) and change that MAC address to the FDDI device's MAC address like a normal router does (instead of encapsulating the original MAC address). Then that FDDI device forwards it's own MAC address to another FDDI device which then changes the FDDI MAC address to either an Ethernet or Token Ring MAC address of the FDDI device.
That finally resolved the issue and the encapsulation FDDI method ceased to being used there after.
FWIW
- Edited May 26, 2022 5:03 am by WALTER784
Host
From: MRCROSSROADS
May-26
I repurposed another folder and called it Troubleshooting. You can post them there.
At some point we always end up with a rare issue that someone else has already figured out. Looking forward to your tales of woe!
TOP