A performance SLA monitors port2 with both a link-status check and a service SLA target for latency. port2 keeps physical link, its static route stays in the routing table, and it can still browse the internet, but the SLA reports it as not meeting the SLA target. How does this state affect SD-WAN rules and ordinary routing for port2?
- Aport2 is removed from both the routing table and every SD-WAN rule, so neither SD-WAN traffic nor independently routed traffic can use it until the target is met again.
- Bport2 remains fully eligible for SD-WAN rules because only a dead link-status result excludes a member, and a missed latency target is recorded for reporting but never changes selection.
- Cport2 stays in the routing table and can still carry independently routed traffic, but it is treated as not meeting SLA, so SLA-aware SD-WAN rules exclude it from member selection. Correct
- Dport2 is declared dead immediately, which both removes its route and triggers an HA failover of the whole device to its cluster peer.
Why A is wrong: Tempting because failover feels total, but failing the service SLA target does not withdraw the route. Independently routed traffic can still use port2; only SD-WAN rule eligibility is affected.
Why B is wrong: Tempting because link status is the harder failure, but a missed service SLA target does change selection in SLA-aware rules. It is not merely cosmetic; it makes the member ineligible for Lowest Cost (SLA) and SLA-mode rules.
Why C is correct: Correct. Service SLA status and link status are distinct. A member that keeps link and route but misses the latency target is alive yet not meeting SLA. SLA-aware rules drop it from the eligible set, while normal routing over that interface is unaffected because the route remains installed.
Why D is wrong: Tempting because it chains failover ideas together, but missing a service SLA target neither makes the member dead nor triggers HA failover. Link-status detection, service SLA detection, and HA are independent mechanisms.