Ethernet, hot back up line

[numberwrong]

Hi, is there a way of running a hot back up ethernet line from a lighting desk to a node?

 

Will the desk and node both need 2 ports or can you create some sort of redundancy with a load of switches?

[patrick_keys]

Hi, is there a way of running a hot back up ethernet line from a lighting desk to a node?

 

Will the desk and node both need 2 ports or can you create some sort of redundancy with a load of switches?

 

The short answer is: it depends. Basic Ethernet does not tolerate loops - so simply adding a second cable between two devices like this is likely to result in a bad day until it's unplugged again. The same applies if you were to add a simple, unmanaged switch at each end, and plug two cables into each one.

 

However, there are lots of ways that you can use multiple cables between nodes and not have problems like this. The simplest involves a feature that is present on most managed switches, which checks for loops when a link becomes active. It is usually known as the Spanning Tree Protocol. If it finds a loop (by transmitting a packet on one port, and seeing if it comes back on any other port), it will disable that port, avoiding the loop. Fortunately, if you were to sever the active link, this would result in the standby becoming live after a short delay.

 

Another strategy is to use link aggregation, which is a mechanism usually used to increase bandwidth. In this case, both cables would be live, and you'd effectively have twice the bandwidth between nodes. However, you need to be careful how this is configured - clearly you want it still to work if one of the cables disappears.

 

If this was me, I'd be thinking carefully about the infrastructure. If your current setup involves a lighting board with a direct connection to a node, then adding two switches is increasing the number of potential points of failure. Someone could easily unplug one of the switches, and you'd be completely dead in the water. A cold standby Ethernet cable is likely to give you the most flexibility in the event of a failure, but would obviously require you to be able to get to both ends of it quickly.

 

Ultimately it depends on what you're trying to achieve, what kind of environment you're working in, and how confident you are with networking. None of this is particularly difficult or non-standard, but it is a level above just plugging in a cable and things starting to work.

 

Hope this gives you some food for thought.

[J Pearce]

A cold standby Ethernet cable is likely to give you the most flexibility in the event of a failure, but would obviously require you to be able to get to both ends of it quickly.

 

Not necessarily - if you've already got a switch in (for distribution or buffering) your cold standy could be plugged at the switch end and only need plugging up at the desk end. I agree that if you don't already have the switch its pointless adding it, as it introduces another failure point.

[Tomo]

Note that Spanning Tree Protocol (STP) takes quite a long time to start up.

If you use STP, the link may work for a moment, then shut down for tens of seconds - easily long enough for you to become convinced that the entire system is broken.

 

Nearly all Ethernet 'resilience' protocols are designed for equipment that is running 24x7, in situations where it's perfectly OK for a new device to take half an hour (or longer) to first come online - because it's never going to be turned off.

 

In general, you can only configure these on "managed" switches - standard unmanaged just don't do it - and managed switches also take a long time to boot up, longer if they are running resilience protocols like STP.

A fully-managed switch can easily take two full minutes to completely start up and "map" the network before it's really running your traffic.

 

In live situations a "cold" spare link (connected at the switch end) with "unmanaged" switches is often objectively better.

[Tom_M]

STP takes approx. 120 seconds to converge the network and workout which link(s) to shutdown during this time no traffic except STP flows around the network. Even Rapid Spanning Tree (RSTP) takes 30 - 60 seconds to converge the network. This can be made even more complex is more than 1 network segment is using the Ethernet switch and you need to implement Per-VLAN Spanning Tree Protocol (PVSTP).

 

If I was being paid to build as part of my day job this then I would be using either Cisco or HP Enterprise managed switches at either end and routing the cables different ways around the room / building to create the links. I wouldn't use STP or RSTP on the links between the switches because of the time issue with STP / RSTP / PVSTP. I would build a two port trunk / link aggregation manually between switches as loosing a link from a port trunk will only loose the packets that are traversing that leg of the link at the time of loss.

 

But be aware that managed switches (e.g. Cisco Catalyst 2960X, HPE 5500-HI) take around 5 minutes from turn on to get to a point where they will pass traffic. You can get cheaper smaller managed switches from HPE such as the 1920 which boot in less then 2 minutes but even that is a long time when you are waiting to be able to run a cue.

 

The first question I would be asking you is "do you really need this level of resilience / redundancy for this job as it's going to cost a lot of money to achieve?"

[bruce]

The first question I would ask is “what are you trying to protect yourself from?”

 

At the moment, you have a simple, but robust network. There is a single point of failure - the cable between each end.

 

If that cable is vulnerable, you can make it more robust by installing a couple of switches and doubling up the links - and if you’re doing that, I’d agree with using link aggregation rather than spanning tree. So you have mitigated against cable damage, but at a cost - you’ve now got a much more complex network, and two new single points of failure (the 2 switches).

 

So - unless you’re using high end switches with dual power supplies and UPS, or your cable route is particularly vulnerable, you may actually have increased your risk of failure.