Failover Ethernet

[weylin.piegorsch]

I remember reading some time ago about "Failover Ethernet" on Catalyst switchports.  This was kinda like a port-channel in "mode on" except that it was not a port-channel, but still bound two interfaces together so that only one ever was active, with the other going active if the first wee to go offline.

This is distinct from other approaches, like STP, in that it's only locally-significant, ie there's no negotiation with the peer.  This would basiclaly Linux's bonding "mode 1."

Note that I'm not looking to implement this in production - this will become a internal discussion point for certain architectural endeavors, where I know some folks will bring this up. I know this capability exists somewhere, and I'm looking to have an understanding of this to be able to argue against it (including references... if any still exist).

weylin

[Ramblin Tech · Accepted solution]

Are you perhaps thinking of Flexlink ?

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-2/configuration_guide/lyr2/b_172_lyr2_9300_cg/configuring_flexlink_.html

Flexlink has its place in network design, so I would not necessarily “argue against it”.

[Joseph W. Doherty · Accepted solution]

FlexLink is what came to my mind too.

Personally, I recommend avoiding proprietary features unless you really, really need them and/or they are much, much better than non-proprietary features.

[weylin.piegorsch]

thanks @Ramblin Tech and @Joseph W. Doherty, this is exactly what I was looking for. I like the concept of Flex Links in principle, it does solve some problems.  But our organization has a long history of architecting-away the cases where Flex Links would benefit.  The case under discussion related to clients that were connecting in Linux Bonding "mode 1", and who were adamant it was their operational requirement - and therefor, matching the network to the client.  I'm trying to argue that:

1. it's not needed and isn't intended for this case
2. is Cisco "kinda proprietary" (though admitedly without foundationally breaking IEEE standards)
3. is a complexity that doesn't really help in a meaningful way (and therefor adds operational burden without easing anything else operationally or architectecturally).

Appreciate the assist.