The difference of bridge-ha soft failover

[Jeff_Gao]

Dear

Pls see the screenshot:

I have a failover question，as below:

Before:

The bridge ha system version are R80.10,I did failover test with command "clusterXL_admin down; clusterXL_admin up",everything is ok,business traffic is working when failover active to FW2.

After:

I upgrade R80.10 to R80.40,then did failover test with command "clusterXL_admin down; clusterXL_admin up",after active faiover to FW2,business traffic interruption, i see the arp and mac table in switch ,i found arp and mac table out interface no flush,so the traffic interruption.

For example: I use source ip 1.1.1.1 under core_sw to ping dest 1.1.1.2 above (sw1&sw2).When fw1 is active,core_sw1&sw2 disply the 1.1.1.2 arp and mac out interface is port-channel1,but i failover active to fw2 with command "clusterXL_admin down; clusterXL_admin up",i see the 1.1.1.2 arp and mac out interface still is port-channel1,so traffic interruption.

The same  environment of R80.10 and R80.40 ,just upgrade R80.10 to R80.40,R80.10 failover ok,but R80.40 failover not working,I want to know the difference between R80.10 and R80.40.

I also have the same problem in R80.30. I comfirm that R77.30 and R80.10 is working.

[PhoneBoy]

What JHF level for R80.40?
There are many, many differences between R80.10 and R80.40, most of which are probably not relevant to this issue.

First, I recommend checking this with the latest GA JHF installed, if only because I see a couple fixes related to bonds and/or Layer 2 configurations.
If it still doesn't work, I recommend a TAC case.

[Jeff_Gao]

R80.10    JHF 155

R80.40    Latest JHF

the same problem in R80.30, JHF 196

[MartinTzvetanov]

Use Virtual MAC. No need to clear arp tables on switches to make the traffic flow continue to work.

[Timothy_Hall]

If using the Virtual MAC option, be sure that portfast is set on all switchports where the firewall is connected, as I've seen STP get upset about seeing that VMAC on more than one switchport (even if just briefly) which can cause what I call a  10-12 second "slow" failover in my book.  Note that enabling portfast is NOT the same thing as disabling STP entirely which you should never do...

[Jeff_Gao]

vmac is not working(according to my test) and nothing to do with vmac(bridge mode ha).switch arp&mac table have out interface,when failover,arp&mac table out interface no change，for example:

Before failover,the arp table as follow:

mac                                   IP                      Interface

12:34:ed:56:78:23                      1.1.1.2                          port-channel1

After failover,the arp table should as follow:

mac                                   IP                      Interface

12:34:ed:56:78:23                      1.1.1.2                          port-channel2

but after failover,the arp table still as follow:

mac                                   IP                      Interface

12:34:ed:56:78:23                      1.1.1.2                          port-channel1

so the traffic interruption.

[Yair_Shahar]

Hi,

This is Known Limitations since R80.30 Kernel 3.10

This is listed in sk166717

[Jeff_Gao]

@Yair_Shahar  Are you talking about this:

[Yair_Shahar]

Yes.

[Jeff_Gao]

Thanks,But i think it is nothing to do with this.

It said that connections do not survive failover,i think it refers to connections synchronize between ha device.

in my environment,after failover,arp&mac out interface no change,so traffic interruption,did not reach the firewall.

[Jeff_Gao]

Tac tell me that i should change firewall bond from 802.3ad mode to A/B mode.

I need to verify it in my lab.

[Yair_Shahar]

Hi Jeff,

The root cause of this issue reside on the missing of shadow_table (mac table) in the FW.

This means upon a failover cluster does not send updates to its broadcast domain, this affect the switches which does not update its mac address table with new ports.

[Jeff_Gao]

@Yair_Shahar  Yes,you are right. but i want to know why r80.10 is working well  and r80.30&r80.40 not working,what are the difference.I am very confused,I met more than once

[Yair_Shahar]

The origin of this issue reside on kernel 3.10.

so all releases which have kernel 2.6 have this functionality working.

Yair

[Jeff_Gao]

I encountered this problem for the first time on，system version  R80.30,kernel 2.6

[Yair_Shahar]

OK - This will require investigation not related to what I mentioned for kernel 3.10.

In general, you should see updates coming out from the new Active Member toward the network.

Look on 'fw tab –t fdb_shadow –f' it should include mac address it learns.