Hello, I've seen something similar with Corero. Have a look at their SmartWall NETWORK BYPASS APPLIANCE. Roel On Wed, Jun 17, 2020 at 10:16 PM Dovid Bender <dovid@telecurve.com> wrote:

Hi,

I am sorry if this is off topic.I was once demoed a network device that had two interfaces. The traffic would go through the device. If there was a power cut or some other malfunction there would be a relay that would physically bridge the two network interfaces so the traffic would flow as if it was just a network cable. Is anyone aware of such a network card or device?

TIA.

something like https://www.chelsio.com/wp-content/uploads/2012/02/B420-021412.pdf ? On Wed, Jun 17, 2020 at 1:16 PM Dovid Bender <dovid@telecurve.com> wrote:

Hi,

I am sorry if this is off topic.I was once demoed a network device that had two interfaces. The traffic would go through the device. If there was a power cut or some other malfunction there would be a relay that would physically bridge the two network interfaces so the traffic would flow as if it was just a network cable. Is anyone aware of such a network card or device?

TIA.

I have significant experience with these. Chelsio was the brand we used for an IPS/IDS device. They cost a fortune and they caused just as much pain as they saved. Unless you really think you're likely to go days without power and for some reason the things on the other end of those copper 300 ft max ethernet cables will have power but you won't, I do not recommend it. If you're close enough to use copper ethernet you're close enough to run another circuit from the UPS. A major headache is for example, the relays click a couple different times during boot. They might also click when you reload the networking stack, say, to change an IP address on another nic. Every time, the ethernet carrier signal is lost and takes a few seconds to come back. If you're using stp if could be upwards of 30-40 seconds outage for each flip. Then think about all the ways that the software on the server could stop forwarding packets and the relays wouldn't save you because power is still on. The problem with these cards is they are sought on the premise that someone knows what ethernet is, and they know what a relay does, and ethernet uses wires, and relays switch wires, so relays can switch ethernet.... It's just more nuanced than that. Instead, use VLANs: Get cheap gig nics for the server, any off the shelf managed switch, and a monitoring node with ssh access to conf the switch. Designate vlan 100 as the left side vlan, and 101 as the right side vlan. (for example) put ports 1 and 2 in vlan 100; 3 and 4 in vlan 101. Connect the server to ports 2 and 3, and connect the two things you're wanting to bridge through the server to ports 1 and 4. The monitoring node should run an arp ping or icmp ping through the server every 10ms or 1ms or whatever interval you like. If that ping fails twice in a row, then it immediately connects to the switch and issues 'switchport access vlan 100 to port 4, and then shutdown to port 3 Congrats you just created a make-before-break transfer switch for ethernet. For extra credit, send an alert when this triggers. You can also put port 3 in vlan 102 instead of shutting it down, and use a second host in vlan 102 to test that it's really bridging again before you switch port 4 back to vlan 101. Because the switching is done with vlans, there is no STP delay, and because nothing's futzing with the electrical signals, no ethernet carrier signal loss/re-establishment either. Remember ethernet takes time to detect if its got gigabit on both sides, or 10/half or 100/full. Frankly that was a huge problem we had with these relay cards. Our servers were normally set to auto auto (and negotiated to gig) but some ISP CPE would be hard coded to 100/full so we configured to match that. Then the ISP upgrades their gear and the customer is told to just upgrade their router. They ignore our server because these magic relays just push all traffic through right? Well when they're bypassing it works fine, then switch in the server, and after the outage, it works like crap because it can't go full duplex when the isp cpe isn't negotiating. And yet another problem, 568a or 568b my friend. which way are each of the ports and relays configured. Typically switches are one way and servers are the opposite right? So when you bypass, the server and switch are fine. But when you takeit out of bypass the switchto your intermediary server are fine, but the cable between your server and the other host should use a crossover ethernet cable, or crossover adapter I hear you. Yeah, things usually autonegotiate and figure it out. It takes longer though. And it doesn't always work at all. I've been down this road and it took me a year of pain to come to this conclusion. Don't do it. Use VLANs. On Wed, Jun 17, 2020 at 3:15 PM Dovid Bender <dovid@telecurve.com> wrote:

Hi,

I am sorry if this is off topic.I was once demoed a network device that had two interfaces. The traffic would go through the device. If there was a power cut or some other malfunction there would be a relay that would physically bridge the two network interfaces so the traffic would flow as if it was just a network cable. Is anyone aware of such a network card or device?

TIA.

On Wed, Jun 17, 2020 at 1:15 PM Dovid Bender <dovid@telecurve.com> wrote:

I am sorry if this is off topic.I was once demoed a network device that had two interfaces. The traffic would go through the device. If there was a power cut or some other malfunction there would be a relay that would physically bridge the two network interfaces so the traffic would flow as if it was just a network cable. Is anyone aware of such a network card or device?

You can also do this with any routing protocol by including a bypass link and declaring the bypass higher cost than the one through your potentially malfunctioning device. This has the benefit of not having to care about whether the nature of the failure will affirmatively trigger the bypass since it'd negatively triggered on the absence of packets. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/