ACI redistribution of static route into OSPF with two L3Outs on the same border leaf

[Nik Noltenius]

Hello community,

we have an ACI Multi-Pod fabric connected to a legacy environment:

We have two L3Outs, all four leaf switches are configured in both of them.

Each blue line is a physical connection transporting a green transfer VLAN for OSPF and a different, red VLAN for static routing. The OSPF neighbors are the connected devices, static routes are directed to Firewalls.

During migration we want to advertise the static routes learned in red to the OSPF process in green. Through documentation and the help of this community (https://community.cisco.com/t5/application-centric/static-route-is-not-redistributed-in-aci/td-p/3773906) we figured out that "Export Route Control" is the way to go.

This seems to work, as long as the static route is not configured on the same border leaf switch that also has an OSPF peering to the legacy environment. 

Say we configure the static route only on the left-most leaf switch. Then the three legacy devices on the right learn of the network from the leaf-switch they are peering with. The left-most legacy device, however, learns the route from the other legacy devices. The left-most ACI leaf is NOT redistributing the route into OSPF.

We checked several constellations, it is always the same. Only those leaf switches redistribute the static route, that don't have it themselves, but learned about it via the internal MP-BGP.

This seems a little bit odd, and we cannot find any explanation for this behavior in the documentation.

Does this ring a bell for someone who might have had similar issues? Is this an unsupported design?

Thank you and kind regards,

Nik

[mgual]

Hello,

did you find a fix for that ? Got exactly the same issue 

thanks 

[Nik Noltenius · Accepted solution]

Hello mgual,

yes, after engaging TAC we found a solution.

It turned out that using 0.0.0.0/0 with aggregate export subnet selected does not match any static routes. This seems to be a security mechanism to prevent BD routes (static pervasive routes) from being advertised. To solve this we not only needed to put all of our static routes into the respective configuration on the nodes under the L3Out, we also needed to add every single one of them as a subnet with the "Export Route Control Subnet" flag under the External EPG.

In addition TAC told us that the design wouldn't work with the same VLAN used on all links connecting to the outside world. We had different VLANs already, so I can't say if that is an issue but it might be helpful for you.

I hope this gets you further. Best regards,

Nik

[RedNectar]

@Nik Noltenius ,

Thanks for getting back with the solution. As you can see, it helps others if you publish your solution, even if you had to find it yourself.

It will help others even more if you mark you OWN answer as correct - even if it feels wrong!

[raheel.ejaz]

I also have a similar type of scenario. I need to redistribute static routes to OSPF during the migration from N7K to ACI.

unfortunately, we don't have enough information on static routes because the customer has added 0.0.0.0/0 10.21.7.21 default routes plus a few subnets for static routing in the default VRF on N7K.

Question 1: how can i solve this problem then?

Question 2: Is it mandatory to have a separate pair of switches for the static L3OUT and OSPF L3OUT??

i have used separate interfaces but leaf switches are same. one L3out (OSPF) is connected to CORE Switches . and Second L3out (Static) to External FW.