Scenario: last-resort circuit for a single application

The tills must keep working, and nothing else needs to

Branches like BR-02 (site 102) have one internet line and a cellular LTE modem configured as a last-resort circuit. The LTE plan is metered. When the internet line fails, the business needs one thing: the point-of-sale terminals in VPN 40 (10.40.2.0/24) must reach the payment gateway behind the hub, here an example address in 10.20.40.0/24. Guest Wi-Fi, software updates and video calls should wait until the line is repaired.

The difficulty is that the last-resort circuit does not know about applications. It brings the LTE tunnels up when the other tunnel interfaces are gone. From then on the router has tunnels to the hub, and every flow that has a route to the hub can take them. A guest laptop starting a large download is treated the same as a till. The restriction is a separate piece of design.

Constraints that decide the design

• The plan has a data cap or a high cost per megabyte. Check the contract: the numbers are not in this lesson.
• LTE is slower and has higher latency than a wired line. A payment is small, but a rejected payment costs more than a slow one.
• Carriers often put a mobile subscriber behind carrier-grade NAT (CGNAT) and drop idle mappings. A tunnel that sends little can lose its mapping, so keepalives matter. Ask the carrier what applies to your plan.
• The terminals are not the only users of the path. Things that look unrelated need a route too, and they are listed below.

The traffic that is easy to forget

Decide for each row where the service lives. A design that permits the till and forgets DNS looks fine in the policy and fails in the shop.

Four ways to keep the link for the till

These options combine. A realistic design for many small sites is B for the sites that can accept it, and A plus C for the rest. D is acceptable when the plan is large and the outages are short, and it should be a decision someone has written down.

Option A: a data policy, described by its intent

A centralised data policy is built in SD-WAN Manager, held by the Controller and applied to a site list. It matches traffic going through the WAN Edge and acts on it. The intent here has two parts:

1. Match the till traffic: VPN 40, source 10.40.2.0/24, destination the payment gateway prefix (or the application, if the router can identify it in your release). Allow it, with no restriction on colours.
2. Match everything else that must stay off the LTE link and tie it to the colours it may use. If its allowed colour is not available, the traffic has no permitted path and is dropped. The data policy actions that pin traffic to local colours are the ones to look for. Some releases have an option that makes the choice strict instead of falling back to any other colour. The name and the exact effect depend on your release, so check the policy builder and the documentation.

The limit to remember is that a data policy matches traffic and picks an action, but it has no built-in notion of "the last-resort circuit is active now". The restriction works by saying which colours a flow may use. When the preferred colour is present, the flow uses it, and when only the LTE colour is left, the flow has either no permitted path or an LTE one, depending on the action. That is why the exact action matters more than the match, and why this option needs the most testing.

Option B: fewer VPNs at the fallback sites

If a site has no VPN 10 or VPN 30, no flow from those VPNs exists to take the LTE path. This is the cheapest restriction and the one least likely to surprise you, because it is configuration at one site instead of a policy decision at runtime. The price is that the site does not get those services, over any transport. It suits very small sites, such as a kiosk with a till and nothing else.

Watch for a default route in the service VPN. If guest or local internet traffic uses a local breakout (direct internet access with NAT) and the LTE interface becomes the only way out, that traffic can leave straight over LTE without any tunnel. This is a second path to the same bill, so check how the local breakout route is built before assuming it is off.

Option C: a rate cap on the interface

A policer drops or re-marks traffic above a rate. A shaper holds the excess in a queue and sends it later, within limits. For a slow link, shaping is normally kinder to TCP: it adds delay but loses fewer packets. Either one limits how much the link carries and not which application gets it, so combine a cap with a queue that gives the till traffic priority. The QoS policy is applied to the LTE interface, and its form depends on the platform and release.

What the router shows during the outage

BR-02#show sdwan bfd sessions
SYSTEM IP     SITE  STATE  SOURCE TLOC   REMOTE TLOC   SOURCE IP     DST PUBLIC IP   UPTIME
10.255.1.1    10    up     lte           biz-internet  100.64.0.20   198.51.100.20   0:00:04:12
10.255.1.2    20    up     lte           biz-internet  100.64.0.20   198.51.100.40   0:00:04:10

Counters on the LTE interface (show interfaces) then show how many bytes cross it. Take a reading before the test and after, and compare with what the till traffic should be.

Test plan

Plan for a lab first and a maintenance window second. Notify the carrier-plan owner before a test that will use real data.

What this design cannot promise

• A policy that blocks traffic cannot be proven in production without an outage. Lab results and one supervised test are the best available evidence, and they should be repeated after any policy or release change.
• Carrier behaviour varies by plan and location. CGNAT, idle timeouts, throttling after a cap and radio coverage are outside the SD-WAN configuration.
• The restriction is only as good as the list of what the till depends on. A forgotten dependency shows up as an application error that looks unrelated to the network.

Test yourself on the last-resort single application