A branch receives an OMP route for an Azure prefix whose only TLOC is one this site is not allowed to use. A centralized control policy sets that TLOC. Traffic fails, and firewall counters stay at zero. What made the route unusable?
Select an answer to reveal the explanation.
Short Explanation
You were handed a route that points at a door your site is not allowed to open. The control policy set that TLOC, so the Azure prefix cannot forward and the firewall counter never moves. A usable TLOC was never installed.
Full Explanation
OMP can install a prefix whose TLOC the site is not permitted to use. Forwarding then fails even though the route is visible and no firewall counter moves, because the traffic never gets a legal next hop. The centralized control policy is what set that TLOC. Change the policy so this site receives a TLOC it is allowed to use. A zone-based firewall would increment a drop counter after a usable TLOC was installed. That is not the evidence. Application-aware routing strict mode does not delete a TLOC because loss is zero. Zero loss is a healthy measurement, and strict is not an OMP edit. A SIG credential does not replace an Azure TLOC with a default route. Exam caveat: the route can look valid in a summary and still be unusable. Check the TLOC column, not only the prefix. Operational check: show sdwan omp routes for the Azure prefix should show a TLOC this site is allowed to use after the policy change, and a host should then reach Azure.