Description

Versa SD-WAN appliances place a defined set of control-plane traffic — tunnel establishment, keepalives, routing protocols, telemetry export, and SLA probes to Controllers — into forwarding class FC0 (fc_nc, Network Control) by default. This happens independent of any configured QoS policy, rewrite rule, or copy-from-inner setting, which is why this traffic is frequently mistaken for a misconfiguration when it shows up unexplained in a WAN capture. This article explains the mechanism, lists what lands in FC0 and why, and shows how to confirm it in a packet capture.

Symptom

A WAN interface shows a steady baseline of traffic carrying the DSCP/TOS value associated with FC0 (commonly CS6, TOS byte 0xC0), even though there's no obvious explanation for it in the configuration:

• No policy on the appliance places traffic into FC0
• No LAN-side traffic arrives already marked with that DSCP value
• copy-from-inner is disabled, so LAN marking can't be the source
• No rewrite rule maps any other forwarding class to that DSCP value on egress — FC0 is the only one that produces it

Because the marking can't be traced to anything in the LAN-side or policy configuration, it's easy to assume something is being mis-tagged. A quick way to confirm the traffic is genuinely FC0 rather than something else riding the same DSCP value: change the FC0 rewrite target on that WAN interface to a different value. If the traffic in question moves with it, it confirms the traffic originates in FC0 internally — the DSCP value on the wire was just a rewrite artifact, not a classification.

Expected By Design

This is expected behavior, not a defect. fc_nc is Versa's forwarding class for network control traffic, and VOS enforces it through three independent mechanisms that all sit outside the normal policy/rewrite pipeline a customer would configure. Because none of these three paths touch the rules we write, there's nothing in the policy configuration that will explain the traffic.

Traffic placed into FC0 (fc_nc) by default:

Hard-coded by the system, regardless of DSCP or policy:

• IKE / IKEv2, including rekey
• BFD
• HA redundancy keepalives
• OSPF, VRRP

Self-marks CS6, which VOS maps to FC0 (CS6 and CS7 are the only two code points that map to fc_nc):

• BGP — both the overlay session to the Controller and LAN peers
• NTP
• SSH / management CLI
• ICMP circuit monitors

Lands in FC0 because it's host-originated out of the Control VR:

• SD-WAN tunnel (VXLAN-GPE) establishment and keepalives
• LEF / IPFIX log export to Analytics
• Remote syslog
• Director NETCONF / management
• In practice, anything else the appliance sources out of the Control VR

Set by SLA path configuration:

• SLA / path monitoring to Controllers → fc_nc (FC0), via term To_Controller { specific-config { fc_nc; } } (For contrast: SLA/path monitoring to branches uses fc_ef (EF), not FC0 — the same subsystem assigns a different forwarding class depending on whether the probe target is a Controller or a branch.)
  
  
  

This traffic is expected fabric overhead and is not something a rewrite or classification rule can redirect — it's enforced ahead of the policy pipeline. If it's causing a practical problem (e.g., saturating a low-bandwidth WAN circuit):

• Confirm the destinations match Controller/Director/Analytics/peer-appliance addresses to rule out unrelated traffic sharing the same DSCP value.
• Review Analytics/IPFIX export intervals and syslog verbosity — these are the two elements in this list that are actually tunable in volume, since everything else (BFD, IKE, BGP, tunnel keepalives) is protocol-driven and largely fixed overhead.
• Size FC0 queue/shaper capacity on constrained WAN links to accommodate this baseline rather than attempting to reclassify it — reclassifying control-plane traffic out of fc_nc is not supported and risks the stability issues the pinning exists to prevent.