Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

ASR via ISC or Box-to-box

Looking for input as to which way to go for redundancy. Load balancing large data streams with session keepalives for 30-45 minutes. The data streams are initiated from a client that sends 100's (even thousands) of files. This is used in a health care environment so failover and high availability is important.

Thanks,

6 REPLIES
Cisco Employee

Re: ASR via ISC or Box-to-box

hummm... I don't know which redundancy would be better.

It would be interesting to know how many connections per second you expect to hit the CSS.

Also, about your traffic, are you saying you could have a lot TCP connections that could stay idle for 30 - 45 minutes ?

If this is the case, I would strongly recommend to use a CSS11500 since the first generation does not really *like* idle connections.

Gilles.

New Member

Re: ASR via ISC or Box-to-box

Idle connections for 30-45 minutes? Yes that is the case. Reason is that when the client sends the data (imaging) they are stuck to a server. On the backend, it would take some time before that recieved data is moved to storage or a cached server. So if the client wanted to view the data, withing that timeframe, they would return to the server the data was residing on.

As far as what model, we are using 2 11503's with the FE modules, as well as a pair of 2950's for layer 2 traffic.

Thanks

Cisco Employee

Re: ASR via ISC or Box-to-box

good choice for the hardware.

If you get into trouble with your idle connections, you can have a look at

the command 'flow-timeout-multiplier' to extend the timeout value.

Regaring redundancy I woul say box-to-box redundancy offers an easy solution.

Both CSS share the same config.

One is active and the other one is standby.

The CSS can monitor the interfaces and also the services to decide when to failover.

Only requirements is direct connection between both CSS and a L2 switch

to connect the CSS to the servers,.

With interface redundancy, the CSS have a separate config but they share one ip address. The master will own this address until it loses a critical service.

This address is used as the default gateway for the server.

Requirements: L2 switch to interconnect CSS and servers.

Vip redundancy let you do more tricky stuff.

Like active/active configuration or active for 1 Vip and passive for another, ...

box-to-box is nice and easy. But personally I don't like the config sharing.

So I usually select interface redundancy which is the same as box-to-box more or less and less tricky than vip redundancy.

Hope this will help you decide which one to use.

Gilles.

New Member

Re: ASR via ISC or Box-to-box

Here's where I need assistance in the decision....

This setup will be working with redundant L2 switches. Now, for system availability, I am leaning toward ASR in regards to the active/active configuration. I agree with what you have stated in regards to complexity of this compared to box-to-box. This is something that will be rolled out to numerous customers and will be supported by our support staff. Because of that, I have been leaning toward the box-to-box config for simplification purposes - knowing that I would give up a few seconds of system availability if there was a failure. Another factor is that some customers don't want spanning tree on their network, which is needed for the redundancy, but again, in regards to the support side and simplification as well as standardization, I am leaning toward the box-to-box.

Thoughts?

New Member

Re: ASR via ISC or Box-to-box

My 2 cents are that I prefer the Active/Active (non-shared) because I can introduce a new application on the "backup" box for the final testing without impacting the "primary" CSS. Less chance to hose up production by not touching its config. Once it is checked out, you can then copy the good config on the other box and use the priority to make the primary CSS active for the application

It has also been really easy to move the applications between boxes during code upgrades.

Also, I personally like to be able to manage the physical boxes separately and think about the application floating between two equal boxes instead of shadow equipment where the CSS changes its operation depending on the failure state.

Bronze

Re: ASR via ISC or Box-to-box

I started off using box-to-box redundancy on my 11050's and my 11503's.

I am now switching to VIP & Interface redundancy for the reasons mentioned already including configuration flexibility and failover time, but the main reason I'm switching is to eliminate the crossover connection required by box-to-box.

I experienced a hardware failure on my backup 11503 that resulted in the loss of the crossover connection. Both boxes went active which caused major problems with site availability. It has become painfully clear that the crossover connection is an achilles heel for the box-to-box config.

160
Views
5
Helpful
6
Replies