It is generally good idea for this type of cases to get a sniffer trace (in ACE module span 10G backplane interface from supervisor or if ACE appliance take parallel span session of client and server vlan).
This case was investigated in TAC SR and this is a small summary of the traces that may help other users hitting this issue (usually it is good idea to filter by http and client IP) :
This is what we have seen for the non-working scenario.
Packet 1: Client sends HTTP GET to ACE VIP
Packet 2: ACE forwards HTTP GET to RSERVER
Packet 3: RSERVER answers ACE with HTTP 404
Packet 4: ACE forwards the real server response (HTTP 404) to the client
ACE was not changing anything in the packets that were being loadbalanced. And the HTTP 404 error sent from the server that ACE was forwarding indicates that the Web server thinks that the HTTP data stream sent by the client was correct, but simply can not provide the access to the resource specifief by URL.
Bottom line it was found that in this case the server behaves in a different way based on the hostname used to connect to the application, and this should be addressed on the application/server side. An easy way to check this is by using the server name pointing to the vip in local client hostfile.
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...