In an EVPN-VXLAN Campus Fabric, the border leafs can run OSPF inside a VRF toward a firewall and toward WAN/SD-WAN routers. If all of these neighbors are in the same OSPF area, and the OSPF export policy accepts 0.0.0.0/0 without matching a protocol, the border leaf can send a default route toward the WAN routers.

This can stay hidden until a change makes all the IRBs go down and come back up at the same time, for example an MTU change on the IRBs. When that happens, every OSPF session is reset and the routes are shared again with all neighbors, including the WAN routers. If the WAN routers pass that default route into the WAN, other sites can lose connectivity.

• Right after a commit that changes the IRBs, all OSPF neighbors on both border leafs go down at the same time:

rpd[<pid>]: RPD_OSPF_NBRDOWN: OSPF neighbor <neighbor-ip> (realm ospf-v2 irb.<unit> area 0.0.0.0) state changed from Full to Down due to KillNbr (event reason: interface went down)

• The IRB MTU change has no real effect, because the IRB cannot use a higher MTU than its member ports:

dcd[<pid>]: DCD_PARSE_CFG_WARNING: irb.<unit> iff's config mtu <value> is bigger than member link <interface>.0 iff's mtu 1500 for family inet

user@border-leaf> show interfaces irb.<unit> extensive | match "Protocol inet"

Protocol inet, MTU: 1500

• Switches show as disconnected in Mist, and the Mist commit is rolled back because it could not be confirmed:

mgd[<pid>]: UI_COMMIT_NOT_CONFIRMED: Commit was not confirmed; automatic rollback in process

The issue comes back once OSPF with the WAN routers is up again, even after the rollback. It stops only when the links to the WAN routers are disconnected.

Cause

The VRF has the WAN routers and the firewall in the same OSPF area, with an export policy like this:

routing-instances <vrf-name> {

   protocols {

       ospf {

           area 0.0.0.0 {

               interface irb.<wan-unit-1>;

               interface irb.<wan-unit-2>;

               interface irb.<firewall-unit>;

           }

           export <export-policy>;

       }

   }

}

policy-statement <export-policy> {

   term 01_default {

       from route-filter-list <default-route-list>;    ## 0.0.0.0/0 exact, no protocol match

       then accept;

   }

   term 02 {

       from route-filter-list <site-aggregate-list>;

       then accept;

   }

   term 03 {

       then reject;

   }

}

With this setup, the default route can reach the WAN routers in two ways:

1. The border leaf passes it along. OSPF routers in the same area share their routes with each other. A default route learned from the firewall is passed to the WAN routers, and import/export policies cannot block this.
2. The border leaf creates it. Term 01_default accepts the default route from any source. If the border leaf learns it from the other border leaf through EVPN Type-5, this term turns it into an OSPF external route and sends it to all neighbors in the area.

This is expected OSPF and policy behavior. It is not a software defect.

Check

Run on each border leaf to see if the border leaf is creating a default route:

user@border-leaf> show ospf database instance <vrf-name> advertising-router self extensive

user@border-leaf> show route table <vrf-name>.inet.0 0.0.0.0/0 extensive

If the first command shows a 0.0.0.0 external route, the border leaf is creating it, and it will be sent to every OSPF neighbor in that area.

Fix

1. Remove term 01_default from the export policy (or limit it so it does not match routes learned through EVPN), and keep the final reject term.
2. If the site summary should come from the firewall, remove the aggregate route and its export term from the border leaf.
3. Make sure the firewall does not send a default route into the same OSPF area as the WAN routers.
4. Make the changes in Mist. Changes made directly on the switch CLI are replaced on the next Mist push.
5. Avoid pushing IRB changes (such as MTU) on both border leafs at the same time, as this resets all OSPF sessions at once.

After the change, confirm the border leaf no longer creates the route:

user@border-leaf> show ospf database instance <vrf-name> advertising-router self extensive

The output should not show any 0.0.0.0/0 or site summary route created by the border leaf.