When PBR activated on firewall - Firewall does not accept ARP

[Blason_R]

Hi All,

I am facing this weird issue and looks like this is a bug in R80.40. I am working on 3800 platform and when I activate PBR on firewall the firewall refused to accept ARP from clients connected. I tried experimenting. T a lot many things like connected laptop directly to firewall interface, change cable, change switch but I observer firewall responds very late to ARP requests and lot many packets are dropped initially. After 6-8 packets we receive no response and suddenly firewall starts pinging to destination IP addresses. The same behavior observer using tcpdump arp filter. laptops keeps sending arp requests to firewall but firewall does not respond for few 10-15 arp requests and it suddenly responds after so many packets however drops in between.

Again, I tried deleting PBR rules and everything is back to normal. This is same thing I repeated almost four to five times and same behavior is noticed.

Can someone help or shall I file a bug?

TIA

Blason R

[Wolfgang]

@Blason_R some more information needed to answer. Show us your PBR rules. 
Sounds like a misconfiguration with PBR active and maybe the gateway is under fire with some traffic?

Normally PBR will working fine.

[Blason_R]

Well the same is verified on virtual firewall and it works fine. However when I am implementing it on appliance I am facing the arp issue. 

set ip-reachability-detection ping address 1.1.1.1 enable-ping on
set ip-reachability-detection ping address 8.8.8.8 enable-ping on
set ip-reachability-detection ping address 9.9.9.9 enable-ping on
set ip-reachability-detection ping address 192.203.230.10 enable-ping on
set pbr table DefaultInternet static-route default nexthop gateway address 103.90.xx.xx priority 1
set pbr table DefaultInternet static-route default nexthop gateway address 103.90.xx.xx monitored-ip 1.1.1.1 on
set pbr table DefaultInternet static-route default nexthop gateway address 103.90.xx.xx monitored-ip 192.203.230.10 on
set pbr table DefaultInternet static-route default nexthop gateway address 103.90.xx.xx monitored-ip-option fail-all
set pbr table DefaultInternet static-route default nexthop gateway address 103.90.xx.xx monitored-ip-option force-if-symmetry on
set pbr table DefaulttoMelnox static-route default nexthop gateway address 10.0.26.1 priority 1
set pbr table DefaulttoMelnox static-route default nexthop gateway address 10.0.26.1 monitored-ip 8.8.8.8 on
set pbr table DefaulttoMelnox static-route default nexthop gateway address 10.0.26.1 monitored-ip 9.9.9.9 on
set pbr table DefaulttoMelnox static-route default nexthop gateway address 10.0.26.1 monitored-ip-option fail-all
set pbr table DefaulttoMelnox static-route default nexthop gateway address 10.0.26.1 monitored-ip-option force-if-symmetry on
set pbr table CustLAN static-route 10.0.0.0/8 nexthop gateway address 10.0.26.1 priority 1
set pbr table CustLAN1 static-route 192.168.0.0/16 nexthop gateway address 10.0.26.1 priority 1
set static-route default nexthop gateway address 103.90.xx.xx on
set static-route 1.1.1.1/32 nexthop gateway address 103.90.xx.xx on
set static-route 8.8.8.8/32 nexthop gateway address 10.0.26.1 on
set static-route 9.9.9.9/32 nexthop gateway address 10.0.26.1 on
set static-route 10.0.0.0/8 nexthop gateway address 10.0.26.1 on
set static-route 192.168.0.0/16 nexthop gateway address 10.0.26.1 on
set static-route 192.203.230.10/32 nexthop gateway address 103.90.xx.xx on

[PhoneBoy]

Can’t think of a reason why PBR would affect arp like that.
Definitely TAC case territory.

[Blason_R]

Yes we already reached. I implemented so many PBR scenarios and this is pretty unique to me hence its my gut feeling could be a bug.