I've inherited two CSS's in a one-armed design configuration and am after a bit of help:
Currently they perform source NAT, which is not what we want as our Web-Servers need to track/log the Source-Addresses.
My question relates to whether this source nat behaviour is the default or whether I can change it by altering the design:
If I change the design by creating a new VLAN, new circuit, attach the Load Balancer and the new web_servers to this VLAN, set the web_servers' default gateway to be the load balancer. Will this achieve the desired result?
Source NAT is not required for a one-arm deployment. Source NAT is being leveraged to guarantee symmetric traffic patterns to and from the server farm. Another option is to employ Policy Based Routing (PBR) to achieve symmetric flows.
One-arm designs are typically deployed to maintain the throughput between servers, meaning only traffic requiring load balancing will cross the LB device. I would suggest you determine if the server/application requirements that drove the initial design still exist before making any modifications.
I am/was slightly confused as I was under the impression that source nat was the default behaviour of the CSS - I didn't see any commands in the config, which seem to have been entered in order to configure it.
However, since posting I've upgraded the secondary CSS unit we have from 3.10 to 6.10 and it works as I was hoping for. Only the 'type nci-direct-return' command has been removed from all the services.
Is it possible that the default behaviour of the previous version was to source nat, but this is no longer the case in the newer version?
As for server/application behaviour, logging the source address is what we need to do. In order to achieve this, all I've had to do so far is upgrade the unit and change the default gateway of the web servers to be the CSS.
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...