OK, so assume you have a topology like:
SW1
/ \
/ \
/ \
PC A--SW2-----SW3--PC B
For some reason there is a bridging loop, STP is disabled or someone applied a filter in the wrong place or such.
PC A wants to communicate with PC B. It first ARPs for the MAC of PC B, the destination is a broadcast with MAC ffff.ffff.ffff. So the frame goes to both SW1 and SW3. The SRC MAC is PC A. SW1 then floods the frame towards SW3 and SW3 will flood the frame coming from SW2 to SW1.
SW1 and SW3 learned the MAC of PC A when the first frame came in. When the second one comes in from the opposite direction it has to relearn it. Because these events occur so fast and repeatedly you will see log messages complaining about MAC flapping. Something like "MAC FLAP 0000.0000.0001 is flapping between Gi0/24 and Gi0/23". This is a good sign that you have a loop.
What you could do then is to try to trace this MAC. Try looking in the ARP cache of a device in the same subnet and see what IP this device has. So with the MAC you could try to trace it with sh mac-address-table or with the IP maybe you have a list with all IPs and where they are connected.
If the host gets a IP address from a DHCP server you could also try there to find where the host is coming from. If you have option 82 enabled that would be a great help.
Other signs are that the CLI will be very sluggish. CPU load will be very high. Switches do almost everything in ASICs so if a switch has a CPU load over 50% it's probably not good. You should implement SNMP monitoring and watch for high CPU load. Also look for the MAC flap messages. If the switches have a loop the LEDs will probably be blinking like crazy.
Things you could do to protect against loops:
- Enable STP! (duh)
- SNMP monitoring of CPU load
- Enable SNMP traps for certain events like STP topology changes
- Enable storm control on the ports to limit broadcast
- Don't span your VLANs too much in your L2 topology
- Enable port security and limit number of MAC addresses per port
- Enable Option82 if you run DHCP
Your thought process is based on faulty assumptions. By splicing 1 to 3 and 2 to 6 (which is what you have done), this does not put them in the same collision domain. Nor does this cause the devices to autonegotiate into half-duplex mode. Connect only one side of your main cable to one device and what you have now created is basically a "loopback."
Look at a hubbed 10BaseT or 100BaseTX environment. While they are in the same collision domain, they still have separate TX and RX pairs, they don't transmit in both directions on the same pair.
The reason for the collision domain is that a hub is ultimately a repeating device, which takes a signal in one port and repeats it out all other ports. If it receives traffic on two ports and repeats it out the other ports, the signal that is repeated will be a "collision" of the two signals creating an unusable signal. Thus the need for CSMA/CD and half-duplex operation.
By having three devices all spliced together in this fashion, you have merely created an environment that won't work. If you want to do this, simply put a hub between your two devices and connect a "listening" device to it. No need for a tap.
Best Answer
Detecting link on a port is not done using ethernet frames, but with electrical pulses known as normal link pulses. If no frames are being sent, a device puts these on the wire every 16 ms (+/- 8 ms). They are also used for autonegotiation.
A link is considered down if no frames and no pulses are received. Receiving the pulses will make a Cisco tell you the port is up, but as we all know, it is perfectly possible to have "
FastEthernet0/0 is up, line protocol is down".The normal link pulses are not frames, and will not be forwarded by hubs or switches.
Keepalive frames are forwarded or switched, and can be used to detect a loop.