Doesn't look like windows does auto-failover in any way considered graceful - at least not in desktop flavor. Need to see if the situation is different for win10, but I doubt it. Is this a desktop OS or server? Keyword to aid you in googling is "multihomed".

 

Both are Win 7 machines. Desktop.

It occurs to me that I can do a simple test on Monday, by simply pulling a cable across the floor into my office and connecting my desktop PC, via a USB NIC, to the .156 VLAN which I already have available at the proto desk outside.

Solution #2, assuming this doesn't work, will be to put a new PC in the room which is connected to the secondary network on one side, and 192.168.x.x on the other, with 192.168 also connecting to second NICs on the critical machines, with no gateway. The new machine will be VNC'd into from the outside, and then used to connect via VNC to the critical machines.

 

You're IT dept is going to lose it's **** if you're exposing an internal machine to an external network without hardening the **** out if it. I understand you might be IT here, but this is very bad security.

 

Both networks are "internal," in that they are both part of our corporate WAN

One goes to the 98th floor of Sears Tower on a Verizon fiber circuit, via our main data center in Texas.

The other is a different VLAN, which is normally used only at the studio, that I have extended out to Sears via a 7Ghz radio link.

The idea is that if the primary fiber circuit fails, or if the studio loses connectivity with the outside world, or the corporate data center goes down (all three have happened over the past two years) I will still have a direct link to the critical machines via the microwave circuit.

Why not make the microwave link the primary? Because it's old, and has also failed in the past.

I want two physically separate paths to communicate with my transmitter.




And don't get me started on IT security. We broadcast our internal network to WiFi hotspots all over this city. I've raised that flag more than once, but the convenience of the remote crews being able to use their laptops to access internal systems when deployed trumps all other concerns.

 

I'd make an argument for better network edge design to thwart fiber seeking backhoes, but it sounds like you're in the classic OOB gateway conundrum. Auto failover between two interfaces should be easy less messy.

 

It's not just backhoes. The primary fiber circuit goes through multiple COs and several data closets at the building itself. Sometimes, field techs do stupid ****. My longest outage was nearly three days. We stayed on the air (the video feed auto-fails over to the microwave) but I had no control over the transmitter other than a phone call (we still have physical POTS lines at the transmitter sites) to the engineers stationed at the site on shifts during the emergency.

That was a lot of overtime...

 

Ugh.. so no doubt inherited monolithic network segmentation. So the first solution may work for you, but it won't be automatic. You'd need to down the primary iface and bring up the second manually to keep the routing happy-ish. Then I think it might work.

 

Got my girl repping the MTnet

 

It will consult the routing table for each prefix to decide which interface to use. Generally speaking, hosts are configured with a "default route", which points to the single network interface on the device. If it's a multi-homed host like the one you're describing then you need to populate some more sophisticated routes in order to use both interfaces. This can be done statically, or by running a routing protocol of some description. However, the machine will have two IP addresses, one for each interface, and the network will not know that it's possible to reach one of the addresses by going through the other.

What you are really asking for is to have a network of your own that has multiple paths to reach it. To do this you need to run BGP to peer with your providers -- it's a fairly sophisticated (and expensive) network setup.

--Ian

 

Joe,
Would it be possible to have two different computers and be able to switch from one to another in case of a signal going down?

 

Not remotely. The machine in question is connected to a piece of equipment via an RS-232 port.

But have another idea- involve a third PC. Put it on the second network, then establish a private (192.168) network connection between it and the machines I care about. VNC into the new machine, then VNC from it to the machines of interest. It's a tad sloppy, but should work.

 

Does the rs232 connection run software? Or is it just a terminal needed?

Cuz my initial thought might be a bit overkill but tried and true.

https://opengear.com/products/im7200...ucture-manager

 

There are two separate machines in question here, with two separate PCs.

Both require a Windows software application, not just a terminal.

One is a Harris Diamond UHF transmitter, built in 2001. The other is a Genetner VRC-3000 site-control system, which is slightly older.


On the plus side, I just got capital approval to replace the transmitter next year. And I already have the replacement for the Gentner system in the warehouse.

 

Virtual com ports encapsulated over tcpip aren't uncommon, though a bit hacky, but I get it if you the engineering cycles aren't worth it for a stopgap. But those devices (or similar to) are what we usually stuff in network pops - with a yearly pots audit and test.

 

I think I'm just going to do option B. Put a dedicated midway machine on Network 2, and a private network so it can reach the other machines. Since this is a "for use in emergencies" problem, I prefer an architecturally simple solution.


Unrelated:

You gotta love it when, as a society, we have reached such a level of technological sophistication and economic surplus that offering to launch the cremated remains of your dead cat into space is a viable business model: https://www.space.com/first-cat-****...-celestis.html

 

Wifi will automatically connect to two hotspots at will... do you need a copper wire connection?

 

Yes. Two of them, on separate VLANs.

Even if I were to put the services onto wifi, the trouble is that the access point itself would still be online after the line upstream of it failed. This is the basic problem I have with the existing copper system.

 

oh right, computer dumb because network still there.

how about if you set up a periodic task to ping a speicfic server somewhere on the internet and if you get no response, switch to the other interface. then every x hours (when nobody is logged on or whatever) fire up the primary interface, ping, decide if it's time to revert.

or have a tiny little raspberry pi machine do it on the primary interface and remotely notify your machine the primary connection is up.
or maybe a virtual machine that keeps an eye on one of the connections?

incidentally, Windows 10 does know when it's connected to the internet or not. perhaps you can use that "feature" to determine which network you should be using.

 

.. but by the time you get into doing that, you're probably no better off doing the static routes codrus mentioned above. But I'm not sure how well windows handles service: port bindings multihomed.

 

IMHO the right way to do it is build the network to be reliable, rather than running two unreliable networks to one machine and hacking up a shell script to have it try to figure it out which one is up.

VRRP is a protocol that allows two upstream routers to offer redundant service to a given wired network in a fashion that's invisible to the end host. The two routers share a virtual IP and MAC adress, with the currently elected master device forwarding traffic destined to the virtual MAC. If the master fails, the standby device(s) detect that and elect a new master, who then takes over the virtual addresses. The hosts are configured with the virtual address as their next-hop, and thus don't need to know anything about it.

--Ian