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

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

New Member

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

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


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.


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.


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 1 <-- For service

vrid 2 <-- For service

phy 1/1 <--for physical intf

phy 1/2 <--for physical intf



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 <--just a spare ip.

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

keepalive frequency 2

keepalive maxfailure 2

keepalive retryperiod 2


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

CreatePlease to create content