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

CSS- 11503 - redundency - stickiness - config - verify

Good Day,

I am soon going to implement CSS 11503's in redundancy with session stickiness. Request the experts review on the configuration.

The config with a diagram is enclosed in the attached document.

Many Thanks,

gagan sethi

4 REPLIES
New Member

Re: CSS- 11503 - redundency - stickiness - config - verify

sorry.. missed the correct attachment in the initial post.

Thanks,

gagan sethi

New Member

Re: CSS- 11503 - redundency - stickiness - config - verify

I shall appreciate a review from the experts.

I have to soon put this in production.

Thanks,

gagan sethi

Cisco Employee

Re: CSS- 11503 - redundency - stickiness - config - verify

A1: it really depends what you want to do.

Do you want to failover if a particular interface of the CSS goes down ?

Do you want to failover if a service or a gateway is unreachable ?

You can also use both - that's what most people do.

A2: The ip address is the real address of a gateway or host. No need to create a different address. The purpose here is to make sure that a gateway or host important to your setup is reachable.

A3: You go for trunk only if you need to use multiple vlans. If you have only 1 vlan for the servers and 1 vlan for the client side, I do not see the need for trunking.

Some people implement tunkning with one vlan when they know they will add more vlans in the future, so it make it easier if it is already configured as a trunk.

A4: You only need it if you plan to configure static route on your front-end gateway pointing at the CSS

I hope this helps.

Gilles.

New Member

Re: CSS- 11503 - redundency - stickiness - config - verify

Good Day Gilles,

Thanks a lot for the explainations.

1. I intend to do failover if any srvice/Gw/intf goes down.

Is this config correct for Intf/srv.

********************

reporter both-int

type vrid-peering

vrid 192.168.1.200 1 <-- For service

vrid 192.168.5.200 2 <-- For service

phy 1/1 <--for physical intf

phy 1/2 <--for physical intf

active

***************

can i use both, vrid-peeer and criticla -phy in the same critical reporter... an example wil be very helpfull..

2. The ip of the service shud be the g/w or critical host address ? so can i put the ip of my uplink device or the server serving for l/b ? if yes, then what should i put in the keepalive aka-... ping list... the same ip?

service upstream-downstream

ip address 192.168.5.7 <--just a spare ip.

keepalive type script ap-kal-pinglist ?192.168.5.1" <-- uplink L3 ip

keepalive frequency 2

keepalive maxfailure 2

keepalive retryperiod 2

active

Can you give me a example for the critical service..

3. you are right , i think trunk is not my option till i dont have a complex case..

Many thanks,

Gagan sethi

293
Views
4
Helpful
4
Replies
CreatePlease to create content