Add secondary CSS to DR site for failover

[wilson_1234_2]

I have a CSS configured for web server failover.

We have two servers providing different fuctions that failover to backup servers at the DR site if one or the other server fails.

This is all working fine.

We want to add a second CSS at the DR site to provide access to our web servers if the Main site gets wiped out.

The DR site would also provide connectivty to the web servers if there is a loss of Internet connectivity at the main site.

How much configuration would be needed to my existing config to allow for this?

I would also have to configure the secondary CSS to be the failover unit.

Are there any examples on how to do this?

[acomiskey]

bs6825, the client caching problem should be solved easily by setting the ttl for the records on the css to 0, which is the default. Is this not your experience?

[wilson_1234_2]

ok,

I saw your earlier post.

Thanks for the information.

I wondered if this was a BGP issue with trying to set this up and some of the other guys here said it was not, to use DNS.

I am supposed to go get the DR CSS tomorrow.

Gillis advised not to use this method, maybe why he is not replying to these posts.

When you say round robin, is there any pattern to it (one, then the other, then the first one again)?

or does it seem to be random?

[acomiskey]

No, this scenario does not use bgp. I'm not sure the previous poster read all of this thread.

Anyway, I know gilles has said this is not an advised solution but if you have the equipment and it works, it beats buying more equipment. BTW, cisco just sold us this solution about a year ago.

It is doing 1,2,1,2,1,2,1,2...etc. That is the pattern. If I set the main to be preferlocal I can get the main site to resolve 1,1,1,1,1 but the requests landing at the backup site still go 1,2,1,2,1,2 etc.

[wilson_1234_2]

Hey,

I just got this information from MCI, who hosts our DNS records.

I am beginning to see why gilles is saying not to use this method.

I will post my question and their answer:

The idea is that Verizon DNS would act as a relay to the CSS devices.

The css devices would hold the Zone Data.

The follow up question would be this:

If we have two NS records acting as our DNS, what would determine how they would get hit for requests?

In other words, how would you guys forward the requests to the two devices?

Ideally it would be the primary device would get the requests, and if it was not available, the DR device would then get them.

Is this possible for you to do?

Nope, both devices would get hit at equal rates. There isn't any way to assign a weight/preference to an NS record so if a request came in for host.domain.com and host had two NS records, 50% of the queries would hit one and the other 50% would hit the other. If both devices are handing out different records, this is a problem. There really isn't any way to do this via DNS unless your devices are both up and both handing out the same data...and if one network goes down, both devices automatically start handing out new DNS accordingly. If one of these devices is on the affected circuit, however, your plan won't work and 50% of your queries will fail.

[acomiskey]

Wilson, a few questions/comments...

1. Why the concern about which css the dns query lands at? The whole purpose of this is it doesn't matter which it lands at.

2. "In other words, how would you guys forward the requests to the two devices?"

-It's not about forwarding a request, the ISP just gives the client the NS record, which will be one of the CSS's, if it does not reply, the client will request another NS record, which the ISP will automatically give to the client.

3. "If both devices are handing out different records, this is a problem"

-They aren't.

4. "If one of these devices is on the affected circuit, however, your plan won't work and 50% of your queries will fail."

-Not true. If I try the first NS and it is unavailable, I will request another NS (secondary css).

5. "The idea is that Verizon DNS would act as a relay to the CSS devices."

-Don't think of this as a relay or anything special being performed by the isp, this is how everyone's dns works. The only difference is instead of the NS record for yourdomain.com being NS1.verizon.net it is css1.yourdomain.com.

6. "I am beginning to see why gilles is saying not to use this method."

- You have to do the same with zone based as well.

I can POSSIBLY set up a test subdomain and show you it works. You would need to do some nslookups to a domain and at the same time I would have to bring down the service so you could see the failover.

[acomiskey]

Also, if what they said is true there would be no reason to have multiple ns records for a domain, because if 1 ns server was down, you would still timeout part of the time.

Here's an example from dnsstuff.com on the domain google.com. Notice there are 4 NS servers configured for google.com and 4 corresponding A records for the NS servers.

http://www.dnsstuff.com/tools/lookup.ch?%26name%3Dgoogle.com%26type%3DNS

[wilson_1234_2]

I am having trouble conceptualizing how this is supposed to work I guess.

And I don't really know how DNS works.

But let me make these comments/questions:

1. When we say clients we are talking about end users correct?

2. The end user will request access to www.myserver.com, the MCI DNS server (who hosts my DNS) will forward the requst to either one of the two CSS devices correct?

So the end userr will see the CSS devices as a Name Server just as they see the MCI Name server. correct?

3. So when the client requests name resolution, MCI is actually sending request for name resolution to a different Name Server which is the CSS, is that incorrect?

4. I am having trouble seeing it as not a different record from the CSS, if it has a differnet IP address for the same web server www.myserver.com

5. If Main Site is alive, then BOTH CSS devices return the ip address of 1.2.3.4, correct?

6. If Main Site is down, then DR site will resolve www.myserver.com to 2.3.4.5 ( the DR Site Internet subnet, which is totally different than the Main site internet subnet of 1.2.3.4).

Is the above correct?

[acomiskey]

1. Yes.

2. Technically he is not forwarding the request, he would no longer be authoritative for www.myserver.com. He would rather give the client an NS which was responsible for www.myserver.com. The client then uses that NS record for the request which would be the CSS.

3. Not technically, the client is sending the request to the NS record supplied by the ISP. That NS record is the CSS.

4. What we're saying here is the address given by the CSS's for www.myserver.com will be the same, the CSS's will have different addresses

css1.yourdomain.com=1.1.1.1

css2.yourdomain.com=2.2.2.2

www.youserver.com=1.1.1.100 if main site is up

www.yourserver.com=2.2.2.100 if main site is down and backup site is up.

5. Yes, if 1.2.3.4 is the public ip of the main server.(didn't go back through this thread to find out.)

6. Yes. Also, if only the main site server was down and the main site css was still alive, both css would resolve to backup server 2.3.4.5.

[wilson_1234_2]

Ok,

Here is where I am hung up I think, on #4

1. How can both CSS's give the same address for www.myserver.com?

2. How will the routing take place for both totally differnet IP Address to route to the same address unless BGP is invloved?

3. www.myserver.com can be either:

www.youserver.com=1.1.1.100 if main site is up

www.yourserver.com=2.2.2.100

correct?

[acomiskey]

1. Because you define the records on each css and they talk to eachother through the app session.

2. I think I need to draw it out here...

Client -> tries to go to myserver.com -> request ends up at isp -> isp says hey I've got an NS record for myserver.com -> isp gives this NS record to the client(either one of the css's) -> the client uses this NS record to request resolution of myserver.com -> this request ends up at either css1(1.1.1.1) or css2(2.2.2.2) whichever the isp gave first -> the requests lands at 1.1.1.1 -> the css then says is the main server up? -> if yes the css says hey I've got an A record for myserver.com which = 1.1.1.5 -> if the css say the main server is down it will know whether or not the backup server is up -> if it is it will say hey I've got another A record for myserver.com which is at our backup site 2.2.2.5.

[wilson_1234_2]

Check this drawing and see if it is logical

[acomiskey]

Could you make it a jpeg or something I don't have visio here right now.

[wilson_1234_2]

Here is the drawing.

My thought was the reason to use the CSS devices as DNS servers is that the public IP Address can be different for the same public web server name.

If the HQ site has an Internet subnet of 1.2.3.4 and the DR site has an Internet subnet of 2.3.4.5,

If when you say both devices are handing out the same "record" and by record you mean server name, and the server name could be from either IP address subnet,

Then I understand, if not then I don't see how this will work

[acomiskey]

"My thought was the reason to use the CSS devices as DNS servers is that the public IP Address can be different for the same public web server name."

-Yes, that is true. But at any one particular moment in time, both CSS would return the same ip address for yourdomain.com because 1 server will always be preferred over the other.

"If when you say both devices are handing out the same "record" and by record you mean server name, and the server name could be from either IP address subnet"

-Both devices hand out ip addresses for the names, yes that is correct, and it could be from either subnet, yes.

Your drawing is correct, just get rid of the BGP as it is not needed. I'm also not sure how to go about resolving to the main site server if only the main site internet is down. Mine is not configured that way. If the main site is not reachable via the internet then I use the backup server.

[wilson_1234_2]

Would it be possible for me to see your configs, minus and sensitive information?

If I saw both devices, I mabe would get a better idea of how this works.

As far as the resolving to the main site server, take a look at the config I posed early in this thread.

The one CSS I have is doing that now just from the Main Site only.

The other CSS would be configured the same way using the ip addresses from that Internet subnet and instead of pointing to the local server firat, it would point to the remote (Main Site) server.

I think it should work, it works with the one CSS now.