HP 5950 switch level redundancy getting failed. Need support

[gaurav038]

We have HP 5950 Switch 1 and Switch 2 confiigured in Stack/IRF. They are connected to HP Synergy (virtual connector) at south bound interface.  Bridge-aggregation 1 is configured between them. Total 6 interfaces are part of BA 1 (3 from Switch 1 and 3 from switch 2). 

When we make hp 5950 sw-1 power off, everything works fine on hp 5950 sw-2 for around 12 - 13 minutes and then bridge-aagregations start to gets fluctuate due to below error.

%Sep 20 17:03:30:591 2019 LDPPPSW LAGG/6/LAGG_INACTIVE_PARTNER: Member port FGE1/2/3 of aggregation group BAGG1 changed to the inactive state, because the aggregation configuration of its peer port is incorrect.

and it all works fine if we reset (shut/unshut) Bridge-aggregation 1.

Can somebody put some light on this and help me out here. 

Thank you very much in advance !

[parnassus]

Hi!

If I were you I would do a quick pre-check by validating your configurations with those provided in the example available on the Implementing Multi-Chassis Link Aggregation Groups (MC-LAG) - HPE Synergy Virtual Connect SE 40Gb F8 Module and HPE FlexFabric 59xx Series Switch - Technical Whitepaper document...that just to be sure the basics are OK.

Do you have a MAD mechanism already setup on your IRF deployment?

[gaurav038]

Thank you so much  for this document.  Yes, we have followed exact same configuration.

Also, MAD configuration is there exactly like it mentioned in document.

But i have found something, in our case Bridge-aggregations are getting fluctuated after 12 minutes on TOR-2 when TOR -1 is already switched off and I can see mac-persistance timer is 12 minutes.

<XXXXSW>display irf
MemberID Role Priority CPU-Mac Description
*+1 Master 32 00e0-fc0f-8c02 ToR1
2 Standby 30 00e0-fc0f-8c03 ToR2
--------------------------------------------------
* indicates the device is the master.
+ indicates the device through which the user logs in.

The bridge MAC of the IRF is: ec9b-8b1e-8b67
Auto upgrade : yes
Mac persistent : 12 min
Domain ID : 10
<XXXXSW>

Do you think  irf mac-address persistent always can resolve this issue ? What are your suggestions.

Also what would happen incase master devices comes back online (let say after 45 minutes).

[parnassus]

Hi, it's strange...I received a mail about your reply but I don't see it on the thread...no matter, you replied (I redacted MAC Addresses for privacy):

"Thank you so much  for this document.  Yes, we have followed exact same configuration.

Also, MAD configuration is there exactly like it mentioned in document.

But i have found something, in our case Bridge-aggregations are getting fluctuated after 12 minutes on TOR-2 when TOR -1 is already switched off and I can see mac-persistance timer is 12 minutes.

<LDPPPSW>display irf
MemberID Role Priority CPU-Mac Description
*+1 Master 32 00e0-fc0f-XXXX ToR1
2 Standby 30 00e0-fc0f-XXXX ToR2
--------------------------------------------------
* indicates the device is the master.
+ indicates the device through which the user logs in.

The bridge MAC of the IRF is: ec9b-8b1e-8b67
Auto upgrade : yes
Mac persistent : 12 min
Domain ID : 10
<LDPPPSW>

Do you think irf mac-address persistent always can resolve this issue ? What are your suggestions."

Yes, it can...but there some particular case scenarios that should be considered (read this thread).

It's also interesting to discover that MAC address persistent time parameter's default value, along the time, changed from 6' to 10' (F6123 Software Release) then, lately, from 10' to 12' (F6205 Software Release). See latest HPE 5950 Release Notes about Comware 7.1.070 R6301 Software release.

[gaurav038]

We changed mac-persistance to always. Although it seems it fixed the flapping issue but observed another one.

When any member reboot, even after booting-up we noticed all interfaces from that switch/slot remain in down state. We have to reset (shut/unshut) them manually to make them up.

I am suspecting this as a bug. not sure if anyone has encountered this issue before.