Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Jeff_Gao
Advisor

The difference of bridge-ha soft failover

Dear

Pls see the screenshot:

Bridge-HA.png

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.

0 Kudos
15 Replies
PhoneBoy
Admin
Admin

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.

0 Kudos
Jeff_Gao
Advisor

R80.10    JHF 155

R80.40    Latest JHF

the same problem in R80.30, JHF 196

0 Kudos
MartinTzvetanov
Advisor

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

0 Kudos
Timothy_Hall
Champion
Champion

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...

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
Jeff_Gao
Advisor

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.

 

0 Kudos
Yair_Shahar
Employee
Employee

Hi,

This is Known Limitations since R80.30 Kernel 3.10

This is listed in sk166717

0 Kudos
Jeff_Gao
Advisor

@Yair_Shahar  Are you talking about this:

WX20201109-221737@2x.png

0 Kudos
Yair_Shahar
Employee
Employee

Yes.

0 Kudos
Jeff_Gao
Advisor

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.

0 Kudos
Jeff_Gao
Advisor

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.

0 Kudos
Yair_Shahar
Employee
Employee

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.

0 Kudos
Jeff_Gao
Advisor

@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

0 Kudos
Yair_Shahar
Employee
Employee

The origin of this issue reside on kernel 3.10.

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

 

Yair

0 Kudos
Jeff_Gao
Advisor

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

WX20201109-232514@2x.png

0 Kudos
Yair_Shahar
Employee
Employee

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.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events