CSS will not break routed connections just going through it.
Here's what happens:
1) CSS gets a packet directed towards an IP which is not configured as VS. When it does, it creates a connection for that flow even if the packet is not the original SYN of the three way handshake.
2) If no data is received on this connection for 16 seconds, it is moved to the free-flows list. Once it is there, the CSS will continue to use the information located in it to forward traffic but the connection will be removed as soon as we need some room for new entries.
3) Once the connection is removed even from the free-flows list and that we get a new packet for the connection, you got back to point #1. Since the CSS doesn't check for stateful information (AKA doesn't check if the first packet is a SYN).
So even if the idle timeout of the connections going through it are 16 seconds, a routed TCP flow through the CSS *will never time out*.
For changing inctivity timeouts for loabbalanced connnections you can use the below command which needs to be applied to Content rule/source groups.
Note: If you give number as 2, CSS will multiply it by 16 and actual timeout would be 32.
The permanent option is also good one but can be a problem if you have high traffic for that port. You can also use cmd-scheduler along with permanent port to clear the flows periodically.
Topology & Design:
Two ACI fabrics
Stretching VLANs using OTV
Both fabrics are advertising BD subnets into same routing domain
Some BDs(or say VLANs) are stretched, but some are not.
Endpoints can move betwee...
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
Topology &Design:Traffic flow within same fabric:Endpoint moves to Fabric-2Bounce Entry Times OutTraffic Black-holedSummarySolutionAppendix:
In the Previous articles of ACI Automation, we are using Postman/Newman a...