“easy” failover home network access..

I just came back from a trip to Singapore and Malaysia. While in Malaysia, we stayed at the Legoland Resort hotel, which was actually pretty cool.

What wasn’t cool, was that its provided wifi blocks outbound TCP except to a couple of well known protocols (http, https, pop3, pop3s, imap, imaps, smtp), and well, my wife and I were nerds and we were working on something on one of our home Linux boxes and we needed to ssh into it, over our wireguard VPN.

So I did what any reasonable person would do… got a friend to give me a temporary account on their box which runs proxied sshd on the same port as https, and then used that setup a reverse tunnel and SSH into our home network.

.. where I then setup an OpenVPN server using a shared port with our home server’s https connection, which is forwarded through the NAT router, and connected to that to finish off what we were doing.

I then wanted to solve another problem – we have failover 4G, for the rare times when the main NBN connection is down. Except, my NBN provider gives me a real IP, and my 4G provider uses CGNAT, so I can’t use the existing home VPN server when the main NBN link is down – not that this has ever come about, but “be prepared”, as the boy scounts say.

I didn’t want an always on connection from my VPS server in California to my home network, so I setup sshd on a second port on my VPS server, and used autossh to establish a tunnel from the VPN server on my home network on that port.. and then used ufw on the VPS to block my main ISP, so it can only connect if the connection fails over to the 4G link.

So for home access – normally I can use OpenVPN or Wireguard (I have both now) directly to my home static IP, or if the NBN is down, the home will tunnel out and expose OpenVPN via my VPS. The functionality is good, it can be explained easily, but the behind the scenes implementation is a little complex, though I think pretty cool.

Counterfeit Cisco SFPs

Probably not news to anyone, but there are counterfeit Cisco SFPs in the market place. It only matters for support purposes – all the SFPs are made to a standard, and it’s just a matter of what the label says past that point. As they say, if it quacks like a duck..

So how can you tell real from fake? Short answer – you can’t easily. If you buy through legit channels, you’re good. If you buy from eBay, there’s a pretty good chance they’re fake. If it’s from AliExpress.. well, I wouldn’t expect real ones.

Going through some old photos, I found this picture from last year from an install job I did – all of these SFPs came directly from Cisco, and they all look different.

Cisco SFP varieties

Arista VLAN assignment, and MLAGs

I have done a few Arista deployments lately – they’re awesome, cheap, 10GbE switches. The EOS config is very similar to Cisco IOS, but there is one really important difference for my purposes, regarding VLAN assignments.

On a Cisco switch, you could run the following command:

switchport mode trunk
switchport trunk allowed vlan add 123,124,125

Aristas will let you run this command, without error, but it won’t do what you expect. As soon as you set a port to be a trunk, it allows all VLANs on it, without being told. So on an EOS switch, the configuration is:

switchport mode trunk
switchport trunk allowed vlan none
switchport trunk allowed vlan add 123,124,125

The recommended way of configuring your VLANs is to define which “trunk groups” a VLAN is in (under vlan configuration), then assign ports to trunk groups, but this IOS like method also works. You can (and should) verify the 802.1q trunking configuration of a port (or port-channel) by adding “trunk” after it:

show interface Eth7 trunk

Arista has this very concise and well written page on how to setup their virtual chassis MLAG configuration (like Cisco vPC, Brocade Trill, etc). One important key point it doesn’t note clearly at least – the MLAG peer link needs to ONLY have the peer-link VLAN on it, and the peer-link VLAN can’t go to the uplink switches, or you will get a spanning tree shutdown.

 

Setting clock from CLI is not allowed in this VDC

If you’re trying to set the time on a brand new out of box Cisco Nexus 5500 and you get the message “Setting clock from CLI is not allowed in this VDC.”, it’s because the clock protocol is set to ntp, even though you didn’t configure NTP. Go into config and type “clock protocol none”, and then it will let you set the time.

Then, when you’ve finished the config, set up NTP!

And while you’re at it, this page from Cisco is awesome for troubleshooting VPC