LACP betweeb PA3400 and Cisco Switch

[GantaphonW]

I have config LACP between PA3400 and Cisco Switch everything work fine implement test on standalone mode

Cisco eth1/1 (po1)<----> PA eth1/1 (ae1)

Cisco eth1/2 (po1)<----> PA eth1/2 (ae1)

All traffic can use normally until we test shutdown or unplug one of member on firewall .

Result : traffic is dropped 1 timeout 

My question : this is expected behavior of Palo Alto or am i misconfigure something but this should not happen once we config Aggregate link

Ps. We try change new switch already , Have try to change mode Active / Passive already

[BPry]

@GantaphonW,

Enable Fast Failover

[GantaphonW]

I have already try that feature but it still have 1 timeout for ping 

[BPry]

@GantaphonW,

What does your configuration on the switch side of things look like? Layer3 interfaces or Layer2 interfaces? 

[GantaphonW]

For the switch side

it is layer2 trunk interface , 

For firewall

we do ae with 2 subinterface separate into 2 zone 

[TomYoung]

Hi @GantaphonW ,

To be clear, you are dropping 1 ping?  I would say that is normal.  If the NGFW or the switch is transmitting 1 packet onto the interface as you unplug it, then that packet is lost.

Thanks,

Tom

[BPry]

@GantaphonW,

On a layer2 connection I would say that you're likely as good as you'll get. On a Layer3 connection I don't reliably drop any requests during a failover of the uplink, but it will show increased latency during the uplink failover (this is because the packets on the wire at the time of failure need to be retransmitted). 

[Alin.Scarlat]

@GantaphonW ,

I would also enable Fast Failover like @BPry suggested and add check the Enable in HA Passive State (in case you have HA) due to the fact that the standby unit will be down unless it's checked and, in case you Cisco switch does not have spanning-tree portfast trunk enabled it will go through all the STP states. Another thing would be the LACP Fast transmission rate that might force the Cisco side to suspend the port-channel faster (1s compared with 30s).

From my point of view, it depends on how you've decided that one ICMP timeout happened during the failover. Is it from the outside interface (which could be different from the port-channel) or from a subinterface of that port-channel?

I hope this helps.

[GantaphonW]

Thank you for your suggest,  For the Question 

Is it from the outside interface (which could be different from the port-channel) or from a subinterface of that port-channel?

we test from different subinterface on the same port-channel. But the result is just only 1 ping timeout when shutdown some member on switch or firewall Once we re-enable port back again, 1 ping timeout is back  and everything work fine . That is the normal behavior or something misconfig 

[Alin.Scarlat]

@GantaphonW 

I would say this is expected to have 1 ping timeout (that would be 1-2 seconds depending on how you test). You have to keep in mind on what's going on the the background like the GARP that the firewall is sending plus the CAM tables being updated on the switches to follow the new path.

From my point of view I could try with LACP Fast + Fast Failover + STP Portfast Trunk on the Cisco side to make sure STP does not come into play.

If the ICMP test was done from a Windows machine try using "-w 1" as parameters which will decrease the ICMP timeout from the default 2s to 1ms (which actually is still 1 second since Microsoft cannot go below 1second). If you still have a timeout then you know it's a "downtime" of maximum 1 second.

I wouldn't consider this as a major impact since TCP has it's own retransmission timers and most of UDP applications have the retransmission inside the application. The voice itself will have a subtle glitch in my opinion.

I hope this helps.