Nano Agent / Nano Services in Quantum SD-WAN: the Control Plane

[WiliRGasparetto]

If you use Quantum SD-WAN in the Infinity Portal, the Nano Agent is the component that turns your gateway into a cloud-managed enforcement point: it receives policy, applies Nano services, and sends telemetry back to the portal. Without it, SD-WAN becomes “local config + hope.” (And that’s usually where troubleshooting starts.)

---

1) What is the Nano Agent?

The Nano Agent is a lightweight agent installed on the Security Gateway / Cluster Member that “hosts” and manages Nano Services. In SD-WAN, it is the mechanism for:

• installing/updating SD-WAN policy on the gateway,

• orchestrating the services required for SD-WAN,

• sending events and metrics to the Infinity Portal.

In practice: you install it using a command/script generated in the portal, and from that point on the gateway has a control channel for SD-WAN.
The SD-WAN guide itself lists the Nano Agent as a required workflow item (“on the gateway… SD-WAN interfaces and the Nano Agent”). (sc1.checkpoint.com)

 

2) Fog + iNext: separating control plane vs data plane (Slide 2)

A mental model that avoids 80% of errors:

Data plane

• User traffic (Internet/Overlay/Backhaul) flows over WAN links, VPN, etc.

Control plane (Nano)

• The Nano Agent communicates with the cloud (Fog/iNext), downloads policy, reports state/events, and receives updates.

Your slide captures it well: Fog acts as a mediator between iNext and the agent, transporting policy and collecting gateway information.

Text diagram (flow):
Infinity Portal (SD-WAN app) → iNext/Fog (cloud control) → Nano Agent (GW) → Nano Services (SD-WAN, Logger, Metric Provider)
GW → (events/metrics/status) → Nano Agent → Fog/iNext → Infinity Portal

 

3) “The first command of your life”: cpnano -s

When something “disappears” in the portal or a policy does not install, the first t-shoot step is:

• cpnano -s → shows detailed status of the Nano Agent and Nano Services (versions, last update, registration, etc.)

This becomes your baseline: before hunting for an “SD-WAN bug,” validate connectivity, registration, and service health.

4) Which Nano Services are involved in SD-WAN

In SD-WAN, you typically see:

• Orchestration Nano Service (baseline, not SD-WAN exclusive)

• SD-WAN Nano Service

• SD-WAN Logger Nano Service

• Cpview Metric Provider

The logic is simple: the orchestrator ensures the other services are present, updated, and running with the correct policy.

5) Orchestration Nano Service: the “systemd” of the Nano world

Think of it as the orchestrator that:

• polls cloud control for updates/policy,

• downloads policy and distributes it to the relevant Nano services,

• reports status, versions, and health back to Fog/iNext.

In SD-WAN, when there is applicable policy for a gateway, the orchestrator triggers the flow to download/update services and their artifacts (SD-WAN/Logger/Metric Provider).

 

6) Orchestration t-shoot: logs and communication debugging

If the gateway does not “update” or the portal does not reflect status, focus on the control plane.

Logs

• /var/log/nano_agent/cp-nano-orchestration.log

• /var/log/nano_agent/cp-nano-orchestration.dbg

The main Nano Agent orchestration log is referenced in official documentation (in other Nano contexts, but the file and pattern are consistent). (sc1.checkpoint.com)

Debug/trace (for communication and HTTP)

• cpnano -d --add --flags D_COMMUNICATION=Trace

• cpnano -d --add --flags D_HTTP_REQUEST=Trace

• rollback: cpnano -d -default

What I look for in the .dbg (time-saving order)

1. DNS resolution / outbound route / proxy (if any)

2. TLS/handshake errors, HTTP codes, timeouts

3. Token/registration state (agent “registered” vs “pending”/“disconnected”)

4. “policy fetched” vs “policy applied” (these are different states!)

 

7) SD-WAN Nano Service: where SD-WAN becomes “real” on the gateway

Gateway Sharing and local policy updates:

• collects/updates VPN peer data and local SD-WAN configuration (next hop, ISP, etc.)

• sends updates to the cloud backend (Fog) when something changes

• applies local SD-WAN policy when a relevant change occurs (peers / topology / link attributes)

Practical point: when gateway sharing does not converge, you get “policy in the portal” but inconsistent state across sites.

---

8) Where to validate policy “for real”: sdwan_steering_policy.json

This file is one of the best local validation points:

• $FWDIR/state/local/SDWAN/sdwan_steering_policy.json

The Quantum SD-WAN guide explicitly references this file for inspecting parameters such as Circuit ID and peer/link details. (sc1.checkpoint.com)

Useful sections (from your slide)

• sdwan_steering_vpn_peers

• sdwan_steering_vpn_local

Objective t-shoot
“What the portal thinks I am” vs “what the installed policy says I am.”
If they diverge, it’s not a “link problem”: it’s policy propagation / install / parsing.

---

9) SD-WAN t-shoot: logs and policy-focused debug

When the pain is “policy does not install” / “steering does not happen”:

Logs

• /var/log/nano_agent/cp-nano-sdwan.log

• /var/log/nano_agent/cp-nano-sdwan.dbg

SD-WAN policy trace

• cpnano -d --add --flags D_SDWAN_POLICY=Trace

• rollback (as in the slide): cpnano -d --add --flags D_SDWAN_POLICY=Error

Practical checklist (my sequence)

1. cpnano -s → is the SD-WAN service Running? Which version/policy?

2. Check whether sdwan_steering_policy.json changed after publish/install.

3. Validate whether traffic matches the correct SD-WAN rule (breakout/overlay/backhaul). There are scenarios where traffic matches breakout and disables overlay encryption (documented in troubleshooting). (sc1.checkpoint.com)

4. Validate health-checks/probing (latency/jitter/loss) and whether links are eligible per thresholds (SD-WAN decisions are based on this). (sc1.checkpoint.com)

---

10) SD-WAN Logger Nano Service: why the portal “doesn’t show events”

The SD-WAN Logger is the event pipeline:

• receives events from SD-WAN steering (link swap, ISP status, etc.)

• receives events from the CPSDWAN process (enablement, policy installation events, …)

• sends them to Fog → iNext → and finally the Infinity Portal displays them

Classic symptom: steering works locally, but the portal looks “blind.”
Primary suspects: logger stopped, delivery backlog, or control-plane issues (orchestration/HTTP).

---

Troubleshooting Blueprint in 7 layers (save this)

1. Portal/Profile: is the gateway in the right profile? is policy published? (Infinity Portal) (sc1.checkpoint.com)

2. Nano health: cpnano -s (registered? last update? services running?)

3. Cloud connectivity: route/DNS/proxy/SSL inspection on the outbound path (top “silent” root cause)

4. Orchestration logs: cp-nano-orchestration.log/.dbg (HTTP/TLS/timeouts) (sc1.checkpoint.com)

5. SD-WAN policy install: SD-WAN logs + sdwan_steering_policy.json (sc1.checkpoint.com)

6. Rule/behavior match: breakout vs overlay vs backhaul (avoids wrong diagnosis) (sc1.checkpoint.com)

7. Telemetry/events: logger + portal (if “it works but doesn’t show,” the issue is observability/pipeline)

[WiliRGasparetto]

thank's

[Dom_Galvao]

wonderful

[WiliRGasparetto]

thk's