We have configured policy based redirect to an ASA in one arm mode. The ASA has a single default route towards ACI using its outside interface.
ASA sourced traffic cannot reach any other endpoint in the fabric like NTP, DNS, etc. After doing some ELAM captures we noticed that traffic reaches the endpoint but returning traffic matches the default external EPG subnet 0.0.0.0/0 because the service subnet is not present in the routing table. All the traffic belongs to the same VRF.
How can we tune ACI to inject that subnet into the routing table?
Hi @Antonio Macia,
I believe what you are looking for is the "Direct Connect" feature.
This setting, when enabled in the service graph, enables communication (individually):
For additional details about this option can be found in the ACI PBR white paper: https://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-739971.html
Thanks for the reply. I tried this but still not work. Per the documentation, this flag takes effect when there is contract between two EPGs and traffic is being redirected to the L4/L7 device. In my case, the ASA is not participating in any communication towards the EPG where the corporate endpoints are running. It is a fresh-install and it needs to communicate with the licensing satellite server among others like TACACS+, NTP, etc.
As we all know, in order for the communication to be possible, it needs a contract. So try creating a contract for this purpose (communication with NTP/DNS EPG) and simply provide the contract in the NTP/DNS EPG, while having the Direct Connect option enabled. Verify the zoning rules before and after providing the contract.
Need to test that.
It would have some implications, because that would mean that I need a contract with PBR enabled just to let the L4/L7 device reach the endpoint and another regular contract to be consumed by the rest of the EPGs because I don't want that DNS, NTP, TACACS traffic go through PBR....
In addition, I not fully sure that it is a contract issue... In my lab I have the same PBR setup and it works, no contracts for those services. The difference is that, in my lab both, the firewall and corporate services endpoints are connected to the same leafs and the L4/L7 service subnet is programmed in hardware and the returning traffic is routed. However, in production the leafs are different and the route is not programmed.
I will try to add those contracts during a maintenance window to see if the workaround works and I will contact the TAC to see whether there is something wrong on my config or not. Will update the post with the outcome.
For a pervasive route (BD subnet pointing to Spine) to be programmed on a leaf where the BD does not exists, a contract is required.