SPORTHAWKS
asked on
Network loop and duplicate IP detected
Someone caused a network loop and all workstatons and servers became unuseable at a customer site. There was a message in the system tray of each workstation and server that said duplicate IP detected. It ended up being a desktop switch which created the loop.
There are main switches that are stacked from Netgear and some departments beyond 200 feet have edge switches uplinked using fiber. One server 2003 DHCP server giving IP's. Unfortunately there are also desktop switches.
My question is are there any hardware devices that can query all the computers and show what computer name and IP is causing the loop or desktop switch as in this case?
There are main switches that are stacked from Netgear and some departments beyond 200 feet have edge switches uplinked using fiber. One server 2003 DHCP server giving IP's. Unfortunately there are also desktop switches.
My question is are there any hardware devices that can query all the computers and show what computer name and IP is causing the loop or desktop switch as in this case?
ASKER
I do not see how this software will show which workstation / server / switch is causing the network loop. Also, I was inquiring about a hardware device.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Mysidia: What you are saying is planning ahead before creating the network and I agree but we were stuck with that situation at the time. I am learning about enabling spanning tree on the core switches so I can look into that but is BPDU a cisco specific feature or if the Netgear has spanning tree then it is something that the spanning tree supports be default?
In regards to "turn on the feature that monitors non-switch ports for BPDUs", does this mean there are 2 ports that needs to be dedicated for this BPDU traffic? I am trying to understand how it is physically set up at the core switches and how it links down to the edge switches, would you mind describing it?
You also mentioned: "you would actually need physical segmentation of switches
for each department, and dedicated physical Layer 3 devices", does this mean getting Layer 3 switches for each department (as you mentioned) and put each department on a different network? For example, the main office is 192.168.0.x and these different departments should be 192.168.1.x and another department needs to be 192.168.2.x and so on?
khaledf: Thanks for the input. I am sure EE readers can benefit from the steps to take which you described above. In fact, that is the exact steps we took so it will definitely work but a laborious way that is why I was initially looking for a hardware device.
mgonullu: You are suggesting the fluke device because you personally know that it shows the device that is causing the duplicate IP?
In regards to "turn on the feature that monitors non-switch ports for BPDUs", does this mean there are 2 ports that needs to be dedicated for this BPDU traffic? I am trying to understand how it is physically set up at the core switches and how it links down to the edge switches, would you mind describing it?
You also mentioned: "you would actually need physical segmentation of switches
for each department, and dedicated physical Layer 3 devices", does this mean getting Layer 3 switches for each department (as you mentioned) and put each department on a different network? For example, the main office is 192.168.0.x and these different departments should be 192.168.1.x and another department needs to be 192.168.2.x and so on?
khaledf: Thanks for the input. I am sure EE readers can benefit from the steps to take which you described above. In fact, that is the exact steps we took so it will definitely work but a laborious way that is why I was initially looking for a hardware device.
mgonullu: You are suggesting the fluke device because you personally know that it shows the device that is causing the duplicate IP?
yes for my question, to make sure you can contact them
Spanning tree protocol is defined as an additional part of an IETF standard (802.1d) that is implemented as an option supported by many managed switches, and in many managed units it is enabled by default. Switches that support spanning tree protocol send BPDUs, when it is enabled.
Most such switches support an option to transition "workstation" (non-trunk-link) ports to forwarding state rapidly; as soon as the connection comes up, rather than having to wait 60 seconds after plugging in/powering up a device attached to a switch port, before the port may be taken out ouf "blocking state".
An option Cisco calls "portfast".
It is a vendor-specific matter as to whether these "workstation" / "non-trunk" ports send BPDUs.
Also, the ability to automatically shutdown a port when a BPDU is received over it is a vendor specific feature:
but check your specific Netgear switch's documents to see if they provide a similar feature, or if there are any netgear upgrades with a feature like that
described in release notes....
The key is: Desktop switches don't support spanning tree protocol.
They don't originate BPDUs.
However, since they are so ignorant, chances are very good, that they
forward BPDUs from _your_ switches just like any other frame.
So say someone attaches a desktop switch and plugs a port into itself.
When the desktop switch receives a BPDU from your switch, if there is
a loop, it should repeat the BPDU back out to your managed switch.
When your smart managed switch sees the BPDU, if it is a switch
with the bpdu guard function enabled for that port, then your managed
switch kills the port...
That is the ideal response to a loop.
Another situation that would kill the port is if they plugged another switch
in that actually did support spanning tree protocol
(so there is a need to explicitly configure authorized inter-switch links).
Most such switches support an option to transition "workstation" (non-trunk-link) ports to forwarding state rapidly; as soon as the connection comes up, rather than having to wait 60 seconds after plugging in/powering up a device attached to a switch port, before the port may be taken out ouf "blocking state".
An option Cisco calls "portfast".
It is a vendor-specific matter as to whether these "workstation" / "non-trunk" ports send BPDUs.
Also, the ability to automatically shutdown a port when a BPDU is received over it is a vendor specific feature:
but check your specific Netgear switch's documents to see if they provide a similar feature, or if there are any netgear upgrades with a feature like that
described in release notes....
The key is: Desktop switches don't support spanning tree protocol.
They don't originate BPDUs.
However, since they are so ignorant, chances are very good, that they
forward BPDUs from _your_ switches just like any other frame.
So say someone attaches a desktop switch and plugs a port into itself.
When the desktop switch receives a BPDU from your switch, if there is
a loop, it should repeat the BPDU back out to your managed switch.
When your smart managed switch sees the BPDU, if it is a switch
with the bpdu guard function enabled for that port, then your managed
switch kills the port...
That is the ideal response to a loop.
Another situation that would kill the port is if they plugged another switch
in that actually did support spanning tree protocol
(so there is a need to explicitly configure authorized inter-switch links).
This is a good discovery tool