I have a 2 context scenario. In the first one the ACE loadbalances client requests (any ip any protocol) to the internal firewalls and in the second one the ACE routes the traffic to the external firewalls to reach the servers in a distant network. IOS is A1_6_3. When I reload the ACE with A2_1_3 or A2_1_4 there is just one server that becomes unreachable for the clients just on ports 80 and 443...It can be reached on any other TCP port and the rest of servers are still available on these ports (80 and 443). The client receives a RST and wireshark states that is coming from the server's ip but I have checked it in the external firewalls and they don't even receive the client's SYN packet, the connection stablishes in the first context as with the former IOS so I presume is the second context the one that is generating the RST... any idea?
First of all I must say I was wrong in that it wasn't true that the server was available on some ports and not on others (80 and 443), it couldn't be reached on any port.
I have found that this is a problem in the routing in the second context. I have a generic static route pointing at 10/8 through the gateway and one loadbalancing service defined with this server in this context (linked to a policy-map with a class-default and a forward action).
The issue is that with the A1_6_3 IOS version the generic static route 10/8 works fine for the traffic destined to this server, but with the A2_1_3 IOS version the ACE doesn't know where to forward the traffic (I guess it is a bug and the fact that this server has one service configured makes its ip known to the ACE in some way that generates a conflict in the routing decision).
I have overcome the issue by installing a static host route pointing to the server with the same next-hop the 10/8 route has.
VMware Trunk Port Group is supported from ACI version 2.1
VMM integration must be configured properly
ASA device package must be uploaded to APIC
ASAv version must be compatible with ACI and device package version
In the Previous articles of ACI Automation, we are using Postman/Newman as the Rest API tool to automate the ACI Configuration.
In this article I’m going to discuss on usin...
One of the first steps in building your ACI Fabric is to go through Fabric Discovery. While Fabric Discovery is usually a straightforward process, there are various issues that may prevent you from discovering an ACI switch. This article wil...