A fleet garage must mark popular SaaS applications for QoS even when clients use ephemeral destination ports. Which approach recognizes those applications beyond static port ACLs?
Select an answer to reveal the explanation.
Short Explanation
SaaS apps hop ports like delivery vans changing lanes. NBAR reads the application fingerprint so you can mark the right traffic without memorizing every ephemeral port. Pair it with MQC and your QoS policy stays honest.
Full Explanation
Fleet-garage SaaS clients often use ephemeral destination ports, so static port ACLs cannot reliably identify applications for QoS marking. NBAR-based application recognition paired with MQC classifies and marks by application identity, letting civic edge routers treat popular SaaS correctly even when ports hop. That is the designed answer when the stem emphasizes recognition beyond static ports.
Permitting only TCP 80/443 unmarked and assuming all SaaS shares one PHB forever abandons differentiated marking. Disabling CEF so process switching can inspect every payload manually is operationally reckless and is not how NBAR/MQC classification works. Shaping the entire uplink to CIR zero during business hours avoids classification by breaking connectivity.
Exam caveat: NBAR signatures and protocol packs evolve; encrypted traffic may need SNI/DNS or SD-AVC enrichment—do not claim deep payload visibility into every TLS flow. Operational check: enable NBAR classification for the target applications, mark via MQC, confirm hits in protocol discovery or policy counters, and validate that ephemeral-port flows still receive the intended DSCP. Garage WAN edges should revisit NBAR protocol packs after major SaaS changes so newly dominant applications do not fall into class-default unmarked.