topic Re: CSS WEBNS 7.4 critical reporters in Application Networking

CSS WEBNS 7.4 critical reporters

jfoerster — Wed, 31 Aug 2005 04:48:52 GMT

Hi,

I've two CSS configured to run VIP-Redundancy. To cover critical phy outage I configured a reporter type all-phy-up. This works fine, both VR (one in front of the CSS and one behind - as this is inline configuritation) are changing the status if one of the links fails. But, if let's say the link in front of the CSS recovers the VR behind of CSS swaps back (preemption is configured) but the VR in front needs some time due to the VRRP-Timers. That's fine so far. Therefore I configured a second critical service VRID-Peering (2 reporters in each circuit) and tried the same. I found out, that the fall back is not working neverthess preemption is still configured. In other words VR are changing if a link fails but do not swap back to the wanted position after the link recovers. I did not find any explanation why this is happening or what I'm doing wrong.

Any advices is appreciated.

TIA.

Kind Regards,

Joerg

Re: CSS WEBNS 7.4 critical reporters

Gilles Dufour — Wed, 31 Aug 2005 12:42:45 GMT

Joerg,

your main problem is spanning tree probably.

When the link comes back, it will take up to 30 sec for spanning tree to converge and the CSS to take VRRP mastership.

Could you try to disable spanning-tree on the CSS and enable portfast on the switch interface.

Regarding the combination of interface-reporter and vrid reporter, once an interface goes down, the VRID will go down as well.

When the interface comes back up, the VRID is still down, so the vrid-reporter keeps VRRP down and there is no way to recover.

I don't think you're supposed to use both at the same time.

Regards,

Gilles.

Re: CSS WEBNS 7.4 critical reporters

jfoerster — Wed, 31 Aug 2005 13:40:02 GMT

Hi Gilles,

Thanks for your reply. Spanning-Tree is out of the game . The problem is that the VR remains on the original backup CSS and does not return to the active one. I waited for almost 5 minutes and it did not return.

The config looks like this:

circuit VLAN30 /VLAN3 (in VLAN3 is VRID 3)

description "to backbone eFCS"

ip address 10.242.8.41 255.255.255.240

ip virtual-router 30 priority 180 preempt

ip redundant-interface 30 10.242.8.43

ip redundant-vip 30 10.242.8.33

ip critical-reporter 30 eFCS

ip critical-reporter 30 eFCS-VRRP

reporter eFCS

type critical phy-all-up

reporter eFCS

type vrid-peering and the VRIP settings

The reporters are only configured on the active CSS (guess this should be okay).

Kind Regards,

Joerg

Re: CSS WEBNS 7.4 critical reporters

Gilles Dufour — Wed, 31 Aug 2005 14:27:42 GMT

Joerg,

what I meant to say is that the first issue is due to spanning-tree [probably] and the 2nd issue, with 2 reporters, is due to design issue.

If you have 1 interface reporter and 1 vrrp reporter, you will always end up in the situation you described.

1/ CSS-A is active all interfaces up

2/ CSS-A interface goes down

3/ CSS-B becomes active

4/ CSS-A VRRP reporter will go down

5/ CSS-A interface goes up

6/ because the VRRP reporter is down, it will keep the VRRP down --> some kind of loop.

So, remove the VRRP reporter and apply the spanning-tree config to solve your initial problem.

Gilles.

Re: CSS WEBNS 7.4 critical reporters

jfoerster — Thu, 01 Sep 2005 03:46:01 GMT

Gilles,

if I understood it right there is no way to have a vrid critical reporter to fail back when everything is fine again?

Is there a way to have the CSS act as having configure spanning-tree portfast? I only found a command for totaly disabling the spanning tree. This shouldn't be a problem as I do not have redundant layer2 links connecting to the CSS (only one link per circuit and the ISC).

TIA

Joerg

Re: CSS WEBNS 7.4 critical reporters

Gilles Dufour — Thu, 01 Sep 2005 08:11:17 GMT

on the CSS, you should disable spanning-tree completely.

But you also need to activate portfast on the device the CSS is connected to.

Gilles.