Comware Based
cancel
Showing results for 
Search instead for 
Did you mean: 

IRF Bridge MAC Address

3ParUser
Occasional Contributor

IRF Bridge MAC Address

Hi guys,

I've just set up a two switch (5940) IRF fabric, and I'm wondering how the bridge MAC address affects connectivity after its default 6 minute timeout? I have 2 x 40Gb QSFP from each side of the chassis in an ether channel (cisco term I know) using the stp edged-port command. So this is a total of 4 40gb QSFP's. I also have one cable running directly between both switches for BFD MAD which is in a default configuration.

I can see from a blade in a directly connected chassis, I drop 6 packets while pinging the mgt IP address of the IRF fabric and then it comes back again. But I have a trunk to a cisco switch, and that took 1min 23secs in a failover scenario after the 6min timeout.

Can someone please explain to me why this is? In the 5940 IRF configuration manual (which I've read umpteen times), I don't seem to be able to find the answer. Any help, or discussion on this greatly appreciated :)

Ideally I want to get the 1min 23secs down in the event of a switch failure of the master. I havent tested yet, but I assume if I was to fail the subordinate I wouldn't get any timeouts.

2 REPLIES
3ParUser
Occasional Contributor

Re: IRF Bridge MAC Address

I've answered my own question. There's not a lot online about this, so I'll post my findings here in case it helps anyone else out. This may be obvious to others, but I didn't realise the bridge MAC address was used when establishing LACP trunks. So when the 6 minute timer is up, the bridge MAC address of the IRF fabric changes, so LACP needs to renegotiate. This is where the Cisco timeout comes in since there is a LACP trunk between my 5940 fabric and my Cisco stack.

What is interesting is I found old H3C IRF documentation, and back then IRF defaulted to a permanent bridge MAC address setting. Now HPE own it, its changed it to default to a 6 minute timer. As we all know, when an IRF fabric splits, the subordinate switch uses the current bridge MAC address for 6 minutes (by default), and once that timer is up it changes to using the subordinates MAC address as the new IRF bridge MAC address. It’s that change in the bridge MAC address which was causing the 90 second failover delay while the LACP trunk between the HPE fabric and the Cisco world renegotiated. 

It’s strange that is now the default IRF behaviour, but I suspect this is due to scenarios like the below when using a permanent bridge MAC addresses: 

  1.  You have an IRF fabric (Switch 1 = master, Switch 2  = subordinate).
  2. Switch 1 has a hardware failure. In this scenario the IRF bridge MAC address is set to permanent, so Switch 2 permanently takes on Switch 1’s bridge MAC address.

  3. Switch 1 is sent away for repair, and is replaced with another switch (Switch 3), which is joined the current IRF fabric. Switch 3 now takes on the IRF bridge MAC address that Switch 2 has, which was originally Switch 1’s MAC address.

  4. You could then have a scenario where Switch 1 is repaired and returned to the environment with the MAC address as Switch 2 & 3's bridge MAC address.  

Now, I’m just theorising here though. Can some confirm this?

Also, to get around the above theorhetical problem we're planning on assigning local MAC addres ranges to our DC locations and setting a bridge MAC address which is crafted by us, and not an actual MAC address of one of our switches.

bamaskas
Advisor

Re: IRF Bridge MAC Address

Comware provides configuration control of the IRF mac-address.  Yes, the default is "irf mac-address persistent timer" for the reason you have outlined for switch replacement.  Use of "irf mac-address persistent alwaysr" can be considered, bearing in mide the not so often switch  replacement issue with a locked down switch MAC address.

#
 irf domain 1
 irf mac-address persistent always
 irf auto-update enable
 undo irf link-delay
 irf member 1 priority 32
 irf member 2 priority 30
#

<sw17>system
System View: return to User View with Ctrl+Z.
[sw17]display irf
MemberID    Role    Priority  CPU-Mac         Description
   1        Standby 32        00e0-fc0f-8c02  ---
 *+2        Master  30        00e0-fc0f-8c03  ---
--------------------------------------------------
 * indicates the device is the master.
 + indicates the device through which the user logs in.

 The bridge MAC of the IRF is: 7848-5938-082a
 Auto upgrade                : yes
 Mac persistent              : always
 Domain ID                   : 1
[sw17]