Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2067
  • Last Modified:

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?
  • 3
  • 2
  • 2
  • +1
3 Solutions

This is a good discovery tool
SPORTHAWKSAuthor Commented:
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.
ok man your need a hardware device,
Maybe this is what you are searching for:
Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

actually this is one of the hardest problems a network administrator will face in his career.
if there is a network loop then the best thing to do is to isolate main switches one by one.
wait for 5 minutes see if the loop ends. If not go to the other switch

once you find the switch causing problems go to each port and disconnect half the cables.
see which half is causing the loop.

put all cables back. disconnect half the half cables. repeat this till you find the cable causing the loop.

don't forget to give at least 2 minutes before putting the cables back. this will give time for the network card on that PC to reconnect and cause the loop again.

this is the approach I've used to resolve the same problem in a large network.

and guess what was the cause!!, a janitor found a cable lying down and put it back on the wall socket thinking it should be there, creating a loop without knowing.
Ideal would be elimination of the unmanaged desktop switches.

Or replace the netgear switches with Cisco Catalyst 29xxs or a 35xx
turn on spanning tree protocol so BPDUs are sent out all ports.

Select and turn on the feature that monitors non-switch ports for BPDUs,
and if a BPDU is received on the port, the port is automatically disabled, and
a message is logged
(other than the ports you use to connect managed switches together)

This prevents one user from accidentally creating a broadcast storm:
when they plug two of your switch ports into their dumb desktop switch,
a BPDU  received from your managed switch will be forwarded out the
other port connected to the managed switches, and cause the shutdown
event  and alerting you.

Additionally, if you can eliminate the desktop switches, turn on the feature called port security, limit  every  port to a small number of MAC addresses.
Disable permanent dynamic selection of the first few MACs seen..

Make sure all unused switchports are turned off, and wiring closets are kept
under lock and key.

Loops are so hard to detect without a plan in place, that it is better to take measures to prevent them in the first place.

You may be able to contain loops to some extent by dividing different segments
into VLANs.

But in practice, in broadcast storms a loop causes can take down the entire switch, so it doesn't matter that the storm occured in a different VLAN and was
isolated from the rest of the network.

So that's a case where you would actually need physical segmentation of switches
for each department, and dedicated physical Layer 3 devices, if you wanted to limit the potential scope of broadcast storms.

SPORTHAWKSAuthor Commented:
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?
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).

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

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