Cellular backup connections

Hi All,

I finally got around to setting up a cellular backup device in our new POP. I am currently testing with T-Mobile where the cell signal strength is at 80%. The connection is 4G. When SSH’ing in remotely the connection seems rather slow. Ping times seem to be all over the place (for instance now I am seeing: rtt min/avg/max/mdev = 174.142/336.792/555.574/99.599 ms) . Is that just cellular or is that more related to the provider and the location where I am? I could in theory test with VZ and ATT as well. With Verizon they charge $500.00 just to get a public IP and I want to avoid that if possible.

Thanks and sorry in advance if this is off topic.

I’ve found the antenna choice and placement can make a huge difference in a data center environment. In some cases it required going to a directional high gain antenna pointed towards a desirable tower, which we found by having someone monitor / reload the Opengear web interface while another person moved the antenna around, to figure out where the best signal strength was produced.

Ours are all Verizon units, but in data centers near some VZ towers, the little omnidirectional paddle antennas that come with the Opengear boxes have been sufficient, even if the unit is mounted in a rack. Even with ping times being in the 150-300ms range, normally SSH isn’t too bad, but it’s certainly not snappy. I’d say it’s not quite as bad as trying to use SSH via Wifi on a Southwest flight, but not as good as a serial console connection.

LTE with a good connection on a lightly loaded cell should be significantly less than that in both absolute terms as well as jitter.

I used LTE (Sprint) for a couple years as my primary connectivity when I moved out into an area with zero connectivity (fixing that now). I typically saw ~30-40ms to Chicago, which is the nearest major carrier PoP. Jitter was typically less than 10ms. VoIP was usable. Others in the area on other carriers have reported similar.

Sprint gave me a public IP with no up front charges but did charge $5/mo for it.

As you're probably aware, the "signal strength" ("bars") indicators that are presented to the consumer-facing interfaces are often very cooked. Depending on which RSSI you're looking at, a "very good" signal is probably in the realm of -70dBm to -110dBm (note that there are two RSSI metrics commonly used with LTE, and they tend to differ by ~20dB).

It’s strange. When we use T-Mo on an andriod device the ping times are 30-40 ms. When we try with the modem + raritn console box it jumps to min of 100+ ms (the modem is high up on top of the rack and we test with the phones we are on the floor) - Can 5 feet higher make it that much worse?

In the world of RF of course. Are you on a v6v4 APN as well? Is your v4 taking a longer route to go via CGN while v6 goes native?

- Jared

Check the route your taking when you use the cell phone as a hotspot and when you use the LTE modem. The carrier may be using different paths.

You may want to engage the vendor of your modem as well to make sure everything in it is configured correctly. Depending on the device there are a lot of tricky things that can be done with them.

I only have experience with Cradlepoints and have used AT&T and Verizon. I know VZW used to route their “business grade” modems differently than their cell phones and consumer hotspots. I’ve been told VZW fixed the issue of having to put different tower configurations into the Cradlepoints (I believe the last time I set one up they were able to provision it without me configuring anything).

High pings and high latency (compared to dedicated connections) have always been normal from my experience but with a decent signal it should still be better than a traditional DSL connection for example.


You mention your connection is 4G. On T-Mobile 4G is UMTS whereas LTE is, well, LTE. Are you really on UMTS (which I would expect to have much crazier RTTs and jitter like you report) or did you mean LTE?


I found horrible routing with a static IP setup with T-Mobile. The device was located in Ashburn, outbound routing would go out via Dallas and inbound would come in via Seattle. So ping times and usability was rough. Tried it on the west coast and the same problem. T-Mobile support said this was by design and they couldn’t change it.

I decided to switch to a regular consumer AT&T data sim without a static IP and set up a small router to initiate a VPN tunnel out to wherever I need it. It turns out to be cheaper and reliable for us.

~Jared Geiger

On the topic of static ip… as a Net Eng of an ISP, and seeing the pains that we have to endure with our static ip customers , I wonder if static ip customers actually inadvertently get less optimal treatment than more flexible, agile and dynamic ip customers ?

I’m saying that since over the years as I have migrated from one router to another, from one technology Ethernet/IP, mpls/ip, it’s more difficult to move those static customers subnets around, and sometimes easier just to leave them on an old router where they’ve been for years.


I really can’t believe I’m going to say this, but this has been a good SD-WAN use case for us.

leave them on an old router where they’ve been for years.

I can’t name names obviously, but you’d be astonished how often I see this and who the big names are.

- Ben Cannon, AS15206

I finally got around to setting up a cellular backup device in our new POP.

When SSH'ing in remotely the connection seems rather slow.

Perhaps using MOSH can help make the interactive CLI session less

Verizon they charge $500.00 just to get a public IP and I want to avoid
that if possible.

You might look into have it call out / maintain a connection back to
your infrastructure.



Thanks for all of the feedback. I was on site today and noticed two things.

  1. As someone mentioned it could be for static IP’s they have the traffic going to a specific location. The POP is in NJ there was a min. latency of 120ms which prob had to do with this.
  2. I was watching the ping times and it looked something like this:

It seems to have been coming in “waves”. I assume this has to do with “how cellular work” and the signal. I tried moving it around by putting it down low on the floor, moving it locations etc. and saw the same thing every time. I am going to try Verizon next and see how it goes.

Haven’t looked in a couple of years, but has anybody made mosh work on OpenGear?

Anyone know if Verizon static IP’s over LTE have same issue where they bounce the traffic around before it gets back to the NY metro area?


I finally got around to putting in a Verizon LTE connection and the ping times are pretty good. There is the occasional issue however for the most part ping times are < 50 ms. I have another strange issue though. When I try to ssh or connect via the endpoints web interface it fails. If I first connect via PPTP or SSL VPN then it works. I ruled out it being my IP since if I connect direct from the PPTP or SSL VPN box then it fails as well. It seems the tunnel does something (perhaps lowering the MTU or fragmenting packets) that allows it to work. Any thoughts?


Could be wrong on this but direct SSH on the LTE side may possibly be not allowed(filtered) and might just be something you could discuss in a ticket with Verizon.

I am getting the same for SSH and https traffic. It’s strange. Where the response is something small like:

Moved to this location.

It works But when I try to load pages that are any bigger it fails. Like I said before I assume it’s either an issue with the MTU or window szie. I was just wondering if anyone encountered such an issue before. It’s not easy getting to someone that knows something. When you have some sort of concrete info the level1 techs tend to pass you along faster.

We deploy routers with Verizon LTE failover - for full functionality, make sure your MTU is 1428 or less, per their specifications.

Here’s an example doc from Spirent that talks about it.



I ran into this problem and Verizon told me that they filter ports 22 and 23 to help stem the tide of IoT attacks on their networks by cellular-connected phone and alarm systems. They said their operational model assumes that all traffic will be encrypted via either SSLVPN or IPSec. I’m using IPSec tuned for low traffic volume (i.e., keepalive disabled), and it’s working well for OBM.