Arp issues with L2 failover

[rds]

Hi guys,

We have a new PAN insatllation with a requirement for resilient links to two Cisco core switches running HSRP.

We have configured the 2 interfaces on the PAN as L2 interfaces and assigned a VLAN which acts as the layer 3 IP. (see diag attached)

When we shut one of the interfaces on the switch connectivity is lost and until we manually clear the arp table on the PAN.

So even though the interface on the PA goes down it retains the arp entry for that interface?

show arp all

vlan.100           192.168.1.4      00:00:0c:07:ac:61 ethernet1/6    c      1603

after running "clear arp all" it begings to work again and it learns the arp on the correct L2 interface.

vlan.100           192.168.1.4      00:00:0c:07:ac:61 ethernet1/5    c      1776

Any ideas?

[itnsystem]

I had same problem.
I asked support team to explain the reason of this.

They said this is normal in PA.

But I don't understand why Paloalto desgned their Firewall not to clear the mac or arp entry after interface goes down.

I think it could be critical problem in some case.

[rds]

I got this reply from support:

The problem appears to be in our L2/L3 code. There are several issues contributing to the behavior.

The first is we do not flush a MAC entry when the L2 link is brought down. Instead we rely on aging for the removal. The 2nd issue is when the MAC entry is manually removed or moves to a new port, the ARP cache entry does not update it's interface link, so when we originate a packet it egresses the wrong the interface.

I've filed a bug with Palo's development and will be working with them on the resolution.

[rds]

itnsystem, as a matter of interest what version of PANOS were you running when you had this issue?

[nettobe]

Any updates on that setup ? we are planning to implememt a similar solution but cannot afford to have down-time, this will be a full voice business.

[rds]

Upgrading to PANOS 4.x did not fix the problem. After further discussion with support it seems this is in fact normal behaviour and it's the fact that PA doesn't participate in Spanning-tree. It simply passes the traffic so from the Switch point of view it was blocking the backup port going to the PA which means when a failover occured the gratuious arp was not being received while STP converges. To get this to work it meant tweaking the STP cost to make sure the port that's in blocking state is on the link between the switches and not on any of the links going to the PA's.