1. Should the GSS need a public IP? Which is recommended?
2. The A response is created in GSS. But the Sniffer shows that the GSS is sending the response to the DNS and then DNS forwards it to the browser. Is this the valid behaviour. Or should the GSS forward the A response directly to the client.
1. Main purpose of GSS is to Globally loadbalance Data centers (provide Geo Redundancy).You delegate your domain to the GSS and then GSS makes intelligent decisions based on DNS requests it recieves. In order to delegate your domain to it, you definitely want a public IP.
2.IF you are not using GSS as a full fledge DNS Server (CNR functionality-- meaning your clients have GSS IP as the DNS Server) then GSS should never recieve any DNS request from client directly. Client ask its configured DNS Server for name resolution and then Client's DNS server contacts GSS to get the answer. So in a nut shell DNS servers are the actual GSS clients.
1. There is no global loadbalancing happening here. Cause both the sites are in the same country(just physically seperate locations).
The customer wants only some specific requests(such as a billing server request eq: bill.rapid.com) to be forwarded from the DNS to the GSS. For any other request other than bill.rapid.com, within the same domain(rapid.com) the DNS will act as the autorised NS. The client tis configured with the IP of the DNS. Hence any request for bill.rapid.com finally hits the GSS(delegation done in DNS) and the GSS returns the A record to the DNS, The DNS sends the A-record to the client.Its a recursive lookup.In this scenario the reply from GSS,for a request to bill.rapid.com goes to the DNS, which inturn forwards to the client. So do we need a public IP for the GSS?
We need the same setup running in the other site. This is where the database synch factor comes into picture. So if they can use a private IP, then the synchronisation can happen through a private link between the two locations and doesnt have to happen over the internet, this again rules out the need for the public IP.
We are not using a CNR in this setup since we are not planning to make the GSS a fully fledged DNS. It will act as DNS only for some specific subdomains.
In step 3 : The authoritative DNS for "rapid.com" is configurd with a delegation for the subdomain bill.rapid.com. Hence the DNS just forwards the request to the GSS. This is recyrsive mode of operation.
Your traffic flow assumes that DNS is working in iterative mode. IN that case the GSS requires a public IP. If it works in recursive mode , private IP should work..
Have you done any implementations???
and their is a link between the two locations. If we use private IP the GSS synchronisation can happen through this link and doesnt need to go through the internet.
DNS request is recursive from client's perspective only,i.e. when client hits its local DNS server its a recursive query.(Hence Local DNS server will respond back with the final answer).
Local DNS Server of the client then use iterative requests on behalf of client.
"Source address lists" in the GSS rules represent the Client's D-proxy. Using which you can make rules to serve A records close to the source DNS ( Take people in ASIA to Data center in ASIA and people in US to US data center logic) . If "Domain's Authoritative DNS server was the GSS client then you couldn't achieve that.
You cannot enter interface commands while the GSS software is running.Enter the gss stop command to stop the GSS software before executing any interface level command.
Both Interfaces can be active at at a time. You can configure these interfaces such that GSS uses one interface for Inter-GSS management traffic and other interface for Keepalive traffic.This can be done using "gss-communication" and "gss-tcp-keepalive" interface level commands.
Why do you need native HA: The native HA feature allows two Cisco DCNM
appliances to run as active and standby applications, with their
embedded databases synchronized in real time. Therefore, when the active
DCNM is not functioning, the standby DCNM will...
This document will provide screenshots to outline the steps to setup
TACACS+ configuration to ACI and also the configuration required on
Cisco ACS server. Please find the official Cisco guide for configuring
TACACS+ Authentication to ACI:
Is it supported or NOT supported? It's a frequently asked question.
Before APIC, release 2.3(1f), transit routing was not supported within a
single L3Out profile. In APIC, release 2.3(1f) and later, you can
configure transit routing with a single L3Out pr...