10.176.56.113 and 10.176.56.114 are 2 x DNS servers in Site 1.
We are planning to put in 10.188.56.49 and 10.188.56.50 which are Site 2 DNS servers as standby realserver because there was a time when 2 of the Site 1 DNS servers went dead and there was no DNS server running in Site 1.
We do not want the DNS vip to route to Site 2 DNS unless both of the .113 and .114 are dead. Can you advice if 'inservice standby' can be used?
"If a client making a request is stuck to an out-of-service server (using a cookie, SSL ID, source IP, etc), this connection is balanced to an in-service server in the farm. If you want to be stuck to an out-of-service server, enter the inservice standby command. When you enter the inservice standby command, no connections are sent to the standby real server with the exception of those connections that are stuck to that server and those servers with existing connections. After the specified standby time, you can use the no inservice command to allow only existing sessions to be sent to that real server. Sticky connections are then sent to an in-service real server in the server farm. "
The explanation above is rather vague and confusing. Hence I would like to seek your advice whether the usage of 'inservice standby' can serve the purpose that we required, which is to failover to .49 and .50 when .113 and .114 became "out of service" in the CSM.
"no inservice" and "inservice standby" are used to gracefully shutdown the real servers. "Inservice standby" is used for shutting down (taking out of LB logic) a real server when stickiness is configured.
You can use Backup server farm for your requirement. A sample config
virtual z.z.z.z tcp
serverfarm SITE1 backup SITE2
If all the servers in SITE1 goes down then the real of SITE2 will be used. If a single server of SITE1 comes back then all connections will go to that server in SITE1.
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...