Skip to main content

LTE Peering

It is quite common for SSRs to use LTE interfaces as a "last resort" transport when primary circuits are down, congested, or experiencing issues. This document recommends various configuration settings to strike a balance between performance and bandwidth usage for LTE interfaces, to get the most benefit from them when peering over LTE.


This document is intended for customers that use LTE interfaces as a last resort transport, not for those using it as a primary transport.


LTE interfaces have two material differences when compared to most wireline interfaces:

  1. Most wireless providers employ Carrier-Grade NAT equipment on their LTE network, which can cause impact to long-lived sessions between peers if there are periods of inactivity. Furthermore, it typically results in a private IP address being issued via DHCP to the LTE modem, which affects the directionality of session setup.
  2. LTE services are typically sold using bandwidth-based service plans. Thus, additional overhead used for machine-to-machine communications costs real money.

In this document, we provide a configuration fragment that illustrates how to tune your LTE interface to provide connectivity with minimal overhead.

Configuration Sample

    neighborhood           LTE
name LTE
peer-connectivity outbound-only
topology spoke
vector lte

state enabled
desired-tx-interval 60000
authentication-type sha256
multiplier 3
link-test-interval 120
link-test-length 10
dscp 0

mode always-transform
nat-keep-alive-mode enabled
nat-keep-alive-timeout 30

enabled true
interval 600

Notes about the Configuration

A Carrier-grade NAT, which is indistinguishable from an enterprise-grade (or consumer) NAT from an SSR configuration perspective, requires certain configuration considerations. First, as seen in the configuration fragment above, it is important to set the peer-connectivity to outbound-only. This will guarantee that any traffic originating at a peer and destined for the LTE device will be created "inside out" from the NAT's perspective.

The bfd configuration is dilated to use 60000 milliseconds as its interval. This configuration is empirically observed to work on most U.S. LTE provider networks – the Carrier-grade NAT devices present in the United States typically use NAT bindings longer than one minute. This value may need adjustment in your local region, if you experience difficulties in establishing sessions toward SSRs over LTE networks.


These BFD keepalive messages are small and therefore do not consume much bandwidth. However, on interfaces where every byte counts against your monthly bandwidth allocation, it is important to keep these settings as conservative as you can to maintain a stable connection.

Last, the udp-transform configuration element in the neighborhood is configured with its mode set to always-transform. Because we can presume that the Carrier-grade NAT exists, we do not need to test for it using our detection mechanism. This reduces unnecessary overhead on the path.