ACI Routing Problem (Transit routing)

[DanDan]

Hello ACI people,

I would like to kindly ask for a second opinion.

I have a internal Firewall pair connected thru the L3Out_1, running OSPF area 150.

This L3Out_1 is implemented in Pod1 and Pod2 on a pair of leaves 101 and 102, then the same L3Out_1 is

also implemented in Pod2 on another pair of leaves 201 and 202.

I now implemented a new L3Out_2 (same VRF) in Pod2 on a same pair of leaves 201 and 202.

The second L3Out_2 is used for a private connection to the Cloud.

Running as well OSPF, area 250.

The goal is to have a VPN tunnel between internal Firewall and Firewall in the Cloud.

Loopback of the internal Firewall 10.10.10.10 .

Loopback of the Firewall in the Cloud 20.20.20.20 .

Configuration for the transit routing:

L3Out_1

External EPG

10.10.10.10 external subnet

20.20.20.20 export

L3Out_2

External EPG

20.20.20.20 external subnet

10.10.10.10 export

Then contract between the external EPGs.

The problem is that the internal Firewall loopback 10.10.10.10 is never advertised to the Cloud.

It also never shows in the routing table under L3Out_2, only under L3Out_1, I assume this would be a bad design decision and this cannot work.

However when I check routing table of L3Out_1, I can see the advertised loopback of the Firewall in the Cloud, which is correct.

Learned by the L3Out_2, then redistributed into MP-BGP, then to leaves 101-102.

Seems like I cannot have those two L3Out_1 and L3Out_2 with different areas on the same pair of leaves.

Proposal would be to move this new L3Out to a new pair of leaves then this would work, however this is not an option because the other leaves are not suitable (HW not supporting needed bandwith).

Is there anything I can do to advertise the loopback of the internal Firewall 10.10.10.10 from the new L3Out_2 to the Cloud?

Diagram:

Thank you!

[Remi-Astruc · Accepted solution]

Hi @DanDan ,

Try to set L3Out 1 with area 0 instead of 150 (or L3Out 2 if not possible).

Regards

[DanDan]

Hi Remi,

Thank you for your reply.

I will test it.

I wonder why does this not work as it is, is this a loop prevention?

For example I learned from a host route on L3Out_1 10.10.10.10 on leaves 101-102 and since that L3Out_1 is also deployed on the leaves 201-202, I am not able to advertise it from another L3Out_2 on the same leaves 201-202?

If this is how it works, then changing the area would make a difference?

I was thinking to maybe completely delete the new L3Out_2 and just make that Cloud connection to be part of the existing L3Out_1, but then we are losing some benefits by having that new L3Out.

Thank you.

[DanDan]

Hi Remi,

this actually works, thank you so much!

Dan.

[Remi-Astruc]

Thanks for the feedback.

To answer your previous question, the problem here was not really specific to ACI, but to OSPF design. You cannot have inter-area routing between 2 adjacent areas without area0 in between.

Regards

[DanDan]

Hi Remi,

I sadly missed the point and ended up focusing on everything else but that.

Thank you again for your help.

Best,

Dan.