Hi !
Yesterday we discovered that on out two routers 9702E which joined via VRRP sent traps alaVrrp3TrapProtoError permanently.
command "show vrrp statistics" show that counter VRID Errors is increasing on both routers.
I set swlog appid vrrp debug3 and see following messages:
VRRP debug1 vrrpRcvPkt: Invalid VRID 51
VRRP debug2 vrrp3MipSendProtoErrorTrap: trap sent
VRRP debug3 vrrpTimeEpiredHelper:
There is no VRID 51 on both routers, so may be someone send such VRID but why our routers generating these messages and traps ?
VRID Errors
Re: VRID Errors
Maybe some other VRRP device in the network?
packet-capture to see the origin?
packet-capture to see the origin?
Re: VRID Errors
Yeap, I tried today, but it's not simple because of a lot of 10GB interfaces. So, I will try anyway.
VRID Errors
OK, I found server (cluster) that send vrrp announces with vrid 51.
So, the main question: Is it normal behaviour when our router recieve announce with unknown vrid (that doesn't exist on router) and begin send traps about invalid vrid ?
So, the main question: Is it normal behaviour when our router recieve announce with unknown vrid (that doesn't exist on router) and begin send traps about invalid vrid ?
Re: VRID Errors
Ok, root cause of problem found.
Out routers genereated such traps (about vrid error) because of server (cluster) that used vrrp protocol in the same network and sent announces to the same multicast group 224.0.0.18 Our routers also has VRRP gateway in that network but doesn't have this vrid. As result out routers got announces from server and did not find this vrid in own vrrp configuration.
Solution:
We advised administrator of server change multicast group from 224.0.0.18 to another one. As result vrrp announces of routers and servers will be separated.
Out routers genereated such traps (about vrid error) because of server (cluster) that used vrrp protocol in the same network and sent announces to the same multicast group 224.0.0.18 Our routers also has VRRP gateway in that network but doesn't have this vrid. As result out routers got announces from server and did not find this vrid in own vrrp configuration.
Solution:
We advised administrator of server change multicast group from 224.0.0.18 to another one. As result vrrp announces of routers and servers will be separated.
Re: VRID Errors
This is not how VRRP should work.
Normally every VRRP Instance sents to the same Multicast Adress (244.0.0.18) and the routers check whether the Message is relevant by validating that the VRID matches the own config.
If it is relevant (same VRID) it checks whether parameters are same (Advertisment interval, version, .. ..) and gives an error if wrong.
Two distinct vrrp clusters in a L2 network (using different vrid) should not give an error.
Normally every VRRP Instance sents to the same Multicast Adress (244.0.0.18) and the routers check whether the Message is relevant by validating that the VRID matches the own config.
If it is relevant (same VRID) it checks whether parameters are same (Advertisment interval, version, .. ..) and gives an error if wrong.
Two distinct vrrp clusters in a L2 network (using different vrid) should not give an error.
Re: VRID Errors
The OmniSwitch will report other VRRP speakers in the same segment if they mismatch the local VRRP (VRID) configuration.
In AOS Release 6 you may ignore VRIDs that don't belong to the local system via some debug commands.
In your case you'll need to issue vrrpIgnoreVrid 51 in dshell, which will return a value for bucket 1 of the IgnoreVrid function.
You need to put the resulting "debug set" commands into your AlcatelDebug.cfg to ensure that the settings survive a reboot.
In AOS Release 6 you may ignore VRIDs that don't belong to the local system via some debug commands.
In your case you'll need to issue vrrpIgnoreVrid 51 in dshell, which will return a value for bucket 1 of the IgnoreVrid function.
Code: Select all
OS6450-P10-> dshell
Certified: [Kernel]->vrrpIgnoreVrid 51
debug set vrrpIgnoreVrid1 524288
value = 524288 = 0x80000
Regards,
Benny
Benny