What is the best to simulate an RJ45 cable failure without changing switch configuration or removing the cable?

Question

I am looking at an automation element for a training environment.

We would like to be able to fail a cable without doing a shutdown on the interface or having an engineer physically remove the cable from the switch.

I would like this to be as transparent as possible. I've thought of the following:

1) Using a switch with Fa0/1 as input interface and Fa0/2 as end device. Put them on the same VLAN. These ports can both be shutdown which would simulate a cable failure at the switch and end device. The downside of this method is that both ports need shutdown otherwise you will black hole the traffic. Similarly the MAC Address seen by the original switch will see the MAC Address of the secondary switch, rather than the end device.

2) L2 Protocol Tunnelling. I looked at this on the Cisco switches but it seems to suffer from the same problems as 1). The MAC Address would not match.

3) Using a Linux box with multiple ethernet interfaces and forwarding traffic at a L2 level between two interfaces. Using some basic scripting the MAC Address could be spoofed such that the original switch would see the same MAC Address as if it were directly connected. I'm not clear on the details for this method but believe it would work but it is not an off the shelf solution.

4) Alternatively a simple mechanical on/off switch would suffice but I have yet to find one easily available. The only solution that I've found is on Youtube here: https://www.youtube.com/watch?v=u9Etvk5CnqM

Answer 1

I would very frequently use an unplugged cable as an interview test, but never had an automated one.

Just a couple of ideas, presuming your wires can be short (a metre or two)

• Use a switch as in that video -- any switch which interrupts both wires of a pair will cause faults. Endless variety on ebay ("dpdt toggle switch latching screw terminal"), just chop a patch cable and wire it up.
• Use a network controlled relay for scripted control. I see 16-relay units on ebay ("ethernet relay") for about £25 with screw-terminals, wire same as switch. You normally control it with web fetches, manually or by curl or similar.

Alternatively you have an old hub you can power that up and down, perhaps with a remote controlled power strip (eg from APC). Hubs won't be visible in CDP or similar.

I'd do it with the relay as you'll be able to generate interesting faults.

EDIT: Per comments to question, this kind of mechanical contactor is pretty much guaranteed to fail CAT5 tests. It will, nevertheless, work with short cables and I'd not expect it to generate errors detectable from the diagnostics available in a typical router. Given this is for generating problems for training courses, I'd regard it as acceptable. Indeed, now I'm thinking about how to automate a known-defective cable.

Answer 2

I have a suggestion that mixes your option 1) and 3), and might remain affordable, since QinQ capable switches should be readily available on the second hand market.

QinQ tunnels

If your test lab devices need to see each other as transparently as possible, and if your intended test cases/failure scenarios are more geared towards that stretch of ethernet between my two lab devices is somehow broken instead of reacting to line protocol down (which is more trivial to handle for L2 and L3 protocols), then something like this might help:

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/5_x/nx-os/interfaces/configuration/guide/if_cli/if_qinq_tunnel.html2 (well ok, that's for the big Nexus 7000 series).

smaller/older switches can do QinQ too: https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/12-2_55_se/configuration/guide/3750xscg/swtunnel.html

Rephrased/abbreviated:

• add a pair of QinQ capable switches to your setup, and enable them for jumbo frames, and interlink them with a jumbo frame enabled "backbone". In Cisco QinQ speak, these would be called service provider switches
• on the service provider switches, configure one VLAN per Ethernet Link you want to be able to play with.
• on both serive provider switches configure one switchpot per service provider VLAN as switchport access vlan <service-provider-vlan> and switchport mode tunnel, and be sure to enable all L2-transport features for these port (CDP, STP, VTP).

This way, any device connected to a QinQ enabled port should see it's peer at the other end of the QinQ tunnel pretty much transparently - with one exception: line protocol. If one end shuts down its port, the other end won't notice by line protocol, but eventually by upper layer protocols detecting a change in their view of the network topology. Of course, if you shut down both ports from the service provider switch, you can simulate unplugging of the cables for both end devices.

I've never done QinQ on a single service provider switch, but it might work just as well. Depending on switch platform chosen, you might be able to use tracking or scripting features to bring down the respective "other" port of the given service provider vlan. That would add the some form of line protocol signaling to the QinQ approach.

By intentionally misconfiguring the service provider switch(es) and their switchports, you can simulate failures that the lab devices have to react to.

Other ideas to investigate, requiring more advanced setups and hardware:

• EoMPLS (a.ka. pseudowires or xconnect) - needs routers with enough phyiscal ports to host all the links you want to manipulate, and needs a minimal MPLS setup to start with. They transport 802.1q, STP, VTP, CDP, and I believe even LACP transparently.
• L2TP tunnels, also needs devices capable thereof. I have no practical experience with L2TP.