Strange VRRP behaviour

[jfoerster]

HI,

I found some strange behaviour on two CSSes running WEBNS 7.4.04.

So far I did not find any explantation what is happening here and why it is happening. I checked the switch ports where the CSS is connected to and the status of the cirtical services applied to the VRRP but nothing indicates that VRRP has to do something or initiate some negotiations.

Could you tell me if my interpretation of the following error messages is correct:

20 JUN 23:43:48 1/1 23310 VRRP-4: Virtual router 4: master on interface 10.0.0.29

20 JUN 23:43:49 1/1 23311 VRRP-4: Virtual router 4 on interface 10.0.0.29 entering into VRRP negotiation

20 JUN 23:43:49 1/1 23312 VRRP-4: Virtual router 4: backup on interface 10.0.0.29

20 JUN 23:43:49 1/1 23313 VRRP-4: Master is 10.0.0.28, VRID:4

20 JUN 23:43:53 1/1 23314 VRRP-4: Virtual router 4 on interface 10.0.0.29 exiting out of VRRP negotiation

date and time is mentiond (okay that's obvious)

1/1 is the interface

Next figure is sort of a sequence number

VRRP-4 is the error code stating that VRRP has a problem and the severity level which is 4

Last the explanation what is happening.

Thanks in advance for shading light on this.

Any hint why this can happen is appreciated.

Kind regards,

Joerg

[Gilles Dufour]

first let me say that 1/1 does not refer to the port but the processor.

This processor in slot 1 - subslot 1.

This is your SCM.

Check your config to see where you have defined virtual router id 4 to identify the interface.

What the message indicates is that both CSS became master and a negotiation was required to identify which one should go into backup state.

From the log, the CSS where you got these messages became backup.

This can happen if the 2 CSS can't see each other, which could be a switch issue, a cable issue, or if you rebooted one of the CSS and you still have spanning tree enabled.

If you only got this message once, this is no big concern.

You can however verify switch, link and your design to make sure spanning-tree is disabled to speed-up convergence after a reboot.

Regards,

Gilles.

[jfoerster]

HI Gilles,

thanks a lot for the explanation. I've the feeling that it has to deal with Layer2 but from the stats of the involved the interfaces there is nothing unusual. Nevertheless I'll double check every port on the connecting layer2 switches.

One think I can defentivly get out of the game is reboots as the two boxes have a quite long uptime.

In terms of the occurencs of these messages I have in mind that they happen every now and than so it seems to me that it might be traffic related. Might this happen due to one-armed config on the FE Ports (the GIGE are right now not used...)

Kind Regards,

Joerg

[Gilles Dufour]

This could indeed be traffic related.

I believe there is a vrrp-timeout or something similar command to increase or decrease VRRP timeout.

You could increase the timeout to avoid the problem.

The only drawback is that it will increase the time for real failover.

Something you can also do is configure a service on each CSS with a keepalive that pings the other CSS.

You can then verify if this service is also flapping at the time you have the problem.

You will have to set the frequency to 1 sec and 3 retries.

Regards,

Gilles.

[jfoerster]

Hi Gilles,

I'll check with my customer if and when we implement that new dummy service.

Regards,

Joerg