OPERATIONAL DEFECT DATABASE
...
...
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
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)
- 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)
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
Click on a version to see all relevant bugs
Cisco Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.
