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.
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...