CSS 11503 VIP Redundancy - Link State Redundancy/Keepalive

[john.pepper]

I'm using 2 * CSS11503 Content Switches and I've configured VIP & Interface Redundacy as per the documentation. I have also configured a critical service (ping of Layer 3 interface) for the circuit fail-over.

I am using 2 * Vlans (1 & 2). The VIP is on Vlan 1 and the Proxy servers on Vlan 2. Failover works fine when I shut down the main CSS-1 and the Proxy services are accessible via the CSS-2 which then shows as Master for the relevant redundant interfaces.

However, the problem I'm having is when I try and disable just 'one' Interface on the CSS.. Using the 'type redundancy-up' in my 'up-down' critical service invokes a fail-over if VLAN 1 interface is shut down but NOT when I shut the Vlan 2 interface... I believe this needs some sort of 'link redundancy' and I've tried enabling the 'redundancy-phy' on the physical interface but it tells me to use VIP redundancy. Not sure if this makes sense. Anyone help..?

Here's my config...

!************ INTERFACE *********************

interface 2/2

bridge vlan 2

!**************** CIRCUIT **************************

circuit VLAN1

ip address 13.156.127.41 255.255.255.128

ip virtual-router 101 priority 101 preempt

ip redundant-interface 101 13.156.127.43

ip redundant-vip 101 13.156.127.53

ip critical-service 101 up-down

circuit VLAN2

ip address 13.156.127.151 255.255.255.128

ip virtual-router 102 priority 101 preempt

ip redundant-interface 102 13.156.127.153

ip critical-service 102 up-down

!************************** SERVICE

service up-down

keepalive frequency 2

keepalive maxfailure 2

keepalive retryperiod 2

ip address 13.156.127.15

type redundancy-up

active

Cheers...John

[d.parks]

I had the same design issue with my 11503's when I switched to VIP/Interface redundancy.

The way I see it, there are a couple of options.

1. Create critical services for each virtual router that monitor the opposite VLAN. Ping next hop router, hosts on the VLAN, etc. Perhaps a service with a scripted keepalive could monitor both sides?

2. Create a trunk and run both VLAN's over a single physical connection. That way, if you lose the connection, both VLAN's drop and you eliminate the possibility of an asynchronous route.

I chose to use a trunk since one gig connection is adequate for my traffic volumes.

[john.pepper]

d,

Cheers.. Trunk seems the way to go as option 1. is not really feasible in my environment.

Thanks.. I'll give the trunk a go..

[Gilles Dufour]

what I saw somebody doing successfully is a critical service with a keepalive ap-kal-pinglist and it was pinging all the circuit vlan's ip address on the CSS itself (the CSS was pinging its own IP's).

When one interface goes down, the ping fails, the KAL fails and the service goes down so the CSS fails over.

Gilles.

[john.pepper]

Gents,

Thanks for all the responses.

* Gilles - I managed to fix this problem using a combination of the ap-kal-pinglist and ACL's on the 3550 switch that contained both Van's.

Using a layer 3 interfaces on my connecting switch (3550 Vlan 1 & Vlan 2), I set up the CSS with a Critical Service (type script ap-kal-pinglist) to ping both interfaces. If either ping fails the service goes down and both interfaces failover which is what you would want to stop geting into an Asymetric loop.

However, I had to setup ACL's on the 3550 to only permit the relevant CSS interface as being the only host allowed to ping it's relevant interface (Vlan 1 or 2 - ICMP type 8). This was required beacuse the CSS acts like a router. If one interface goes down, the other still thinks it has a directtly connected interface to the other network and the CSS will try and ping the other Vlan interface. The ACL on the 3550 (vlan 1 & 2) stops this from happening and the issue of individual interace failure is sorted...

Here's the relevant config bits:

CSS

===

circuit VLAN1

ip address 15.156.127.41 255.255.255.128

ip virtual-router 101 priority 101 preempt

ip redundant-interface 101 15.156.127.43

ip redundant-vip 101 15.156.127.53

ip critical-service 101 vlans-up-or-down

circuit VLAN2

ip address 15.156.127.151 255.255.255.128

ip virtual-router 102 priority 101 preempt

ip redundant-interface 102 15.156.127.153

ip critical-service 102 vlans-up-or-down

service vlans-up-or-down

ip address 15.156.127.15

keepalive type script ap-kal-pinglist "15.156.127.155 15.156.127.15"

active

3550 Switch

============

Extended IP access list 102

permit icmp host 15.156.127.41 host 15.156.127.15 echo

Extended IP access list 103

permit icmp host 15.156.127.151 host 15.156.127.155 echo

interface Vlan1

ip address 15.156.127.15 255.255.255.128

ip access-group 102 in

interface Vlan2

ip address 15.156.127.155 255.255.255.128

ip access-group 103 in

end

Hope this helps anyone else having this problem.

Cheer...JP

[Gilles Dufour]

JP,

just a remark :

my suggestion in your example was to do

keepalive type script ap-kal-pinglist "15.156.127.151 15.156.127.41"

So, I ping the interface of the CSS itself.

Therefore, no need for special ACL on the next hop.

This also allow you to have multiple next hop and only failover when the CSS interface goes down and not when one of the nexthop does go down.

Gilles.

[john.pepper]

* Gilles,

After looking at this in a bit more i decided to simplify the solution and take your advice and use the ap-kal-pinglist to ping the CSS' own interfaces.

Initially, I tried including on of these addresses in the 'IP Address' parameter of the Crtitical Service and it wouldn't let me define the CSS' own address. However, you CAN put the CSS' own interface IP addresses in the ap-kal-pinglist. Therefore, eliminating the need for the ACL's on the 3550 which makes for a cleaner solution..

All fixed - Thanks again..JP