Symptom
When OSPF L3Out is configured with "Default Route Leak Policy" with "Leak Default Route Only" set, the "deny-all" route map is expected to be in the OSPF process, but another route map was pushed to the OSPF process:
show ip ospf vrf TN:EXAMPLE
Routing Process default with ID 192.0.2.185 VRF TN:EXAMPLE
Stateful High Availability enabled
Supports only single TOS(TOS0) routes
Supports opaque LSA
Table-map using route-map exp-ctx-2850816-deny-external-tag
Redistributing External Routes from
static route-map exp-ctx-st-2850816
direct route-map exp-ctx-st-2850816
bgp route-map exp-ctx-proto-2850816
eigrp route-map exp-ctx-proto-285081
Conditions
More than one OSPF L3Out is configured within the same VRF and deployed on the same Border Leaf:
- One L3Out contains "Default Route Leak Policy" with "Leak Default Route Only" set
- Another L3Out has different configuration (e.g. it allows redistribution of some prefixes into OSPF)
Workaround
- Remove and apply back "default leak policy" - it will trigger policy re-population (on the next upgrade/clean-reload the problem might occur again, provided the upgrade is not to the fixed release)
- Configure consistent policy (either both L3Outs have "Default Route Leak Policy" with "Leak Default Route Only" set, or both don't have it)
- Deploy OSPF L3Outs on different leafs (such that no BL has the two or more OSPF L3Outs in the same VRF)
Further Problem Description
Inconsistency can be observed among different leafs:
- One leaf can have "deny-all" policy (expected)
- Another leaf can have non "deny-all" - as per example exp-ctx-proto-2850816
Inconsistency can occur after leaf clean reload/software upgrade due to timing issue - which policy will be pushed to leafs first is going to be the one that's applied
