The unicast arp request won't get up to CPU

[roooockwell]

Hi,
I'm gongjian.
I‘m working on arp of sonic recently. I came across a problem as follows.
Here is the topo: SwitchA-----SwitchB.
It is known that kernel arp will send unicast arp request periodly to confirm the reachability of the neighbor.
I found that when SwitchB received the unicast arp request from SwitchA , the chip will drop them instead of sending them to CPU, which leads to the arp state machine of SwitchA change the state of the neigh from NUD_PROBE to NUD_FAILED.

The attached picture shows the unicast arp request SwitchA send to SwitchB.
I think it's abnormal since the arp entry turns to FAILED when it is still reachable.
ps: I also found a method to resolve this problem.
bcmcmd 's PROTOCOL_PKT_CONTROL(0) 16'
After I set this register. all the arp packet will go to CPU.
pps: I'm using the commit of the sonic_buildimage:
b097492b8fd15c4b9eb67b1046a1d31f8d687a34 [thrift]: Disable auto test in the package build (#545).
I'm using the commit of sonic-swss:
2f594c75036dfd41b6b40dd5b92f4fda7ebb7a68 [aclorch]: Temporarily disable ACL thread of collecting counters (#202)

[stcheng]

Thanks for submitting the issue. I doubt if the switch will automatically dropping the ARP packets. Here is the file that we use to configure the ARP traps. swssconfig is used to read this file and set the rules so that all the ARP packets are get trapped.

Could you confirm that the rules are being applied? I will check the Broadcom's register to see if after applying the rules, the corresponding registers are correctly configured.

[roooockwell]

I've checked the rules in DB:
root@sonic:/home/admin# redis-cli
127.0.0.1:6379>
127.0.0.1:6379> keys COPP

1. "COPP_TABLE:trap.group.lldp.dhcp"
2. "COPP_TABLE_KEY_SET"
3. "COPP_TABLE:trap.group.ip2me"
4. "COPP_TABLE:trap.group.arp"
5. "COPP_TABLE:trap.group.bgp.lacp"
6. "COPP_TABLE:default"
   127.0.0.1:6379> HGETALL "COPP_TABLE:trap.group.arp"
7. "cbs"
8. "600"
9. "cir"
10. "600"
11. "meter_type"
12. "packets"
13. "mode"
14. "sr_tcm"
15. "queue"
16. "4"
17. "red_action"
18. "drop"
19. "trap_action"
20. "trap"
21. "trap_ids"
22. "arp_req,arp_resp,neigh_discovery"
    127.0.0.1:6379>
    127.0.0.1:6379> select 1
    OK
    127.0.0.1:6379[1]>
    127.0.0.1:6379[1]> keys COPP
    (empty list or set)
    127.0.0.1:6379[1]> keys ARP
23. "ASIC_STATE:SAI_OBJECT_TYPE_HOSTIF_TRAP:SAI_HOSTIF_TRAP_TYPE_ARP_REQUEST"
24. "ASIC_STATE:SAI_OBJECT_TYPE_HOSTIF_TRAP:SAI_HOSTIF_TRAP_TYPE_ARP_RESPONSE"
    127.0.0.1:6379[1]> HGETALL "ASIC_STATE:SAI_OBJECT_TYPE_HOSTIF_TRAP:SAI_HOSTIF_TRAP_TYPE_ARP_REQUEST"
25. "SAI_HOSTIF_TRAP_ATTR_PACKET_ACTION"
26. "SAI_PACKET_ACTION_TRAP"
27. "SAI_HOSTIF_TRAP_ATTR_TRAP_GROUP"
28. "oid:0xf00000000057a"
29. "SAI_HOSTIF_TRAP_ATTR_TRAP_CHANNEL"
30. "SAI_HOSTIF_TRAP_CHANNEL_NETDEV"
    127.0.0.1:6379[1]> HGETALL "ASIC_STATE:SAI_OBJECT_TYPE_HOSTIF_TRAP:SAI_HOSTIF_TRAP_TYPE_ARP_RESPONSE"
31. "SAI_HOSTIF_TRAP_ATTR_PACKET_ACTION"
32. "SAI_PACKET_ACTION_TRAP"
33. "SAI_HOSTIF_TRAP_ATTR_TRAP_GROUP"
34. "oid:0xf00000000057a"
35. "SAI_HOSTIF_TRAP_ATTR_TRAP_CHANNEL"
36. "SAI_HOSTIF_TRAP_CHANNEL_NETDEV"
    127.0.0.1:6379[1]>
    The rules are being applied.
    ps: I'm using Tomhalk. please confirm that.

[roooockwell]

@stcheng Hi ,are you still looking at this problem?

[stcheng]

@roooockwell on our side, we cannot reproduce your issue. could you provide the information about your platform? show version will help.

also could you check the Broadcom FieldProcessor to see if there are field entries matching EtherType 0x0806? There should be two entries: ARP_REQUEST and ARP_RESPONSE.

[stcheng]

I use arping on the DUT and I could get ARP reply with destination MAC is my DUT.

arping -I Ethernet64 10.0.0.33 -c 1
22:39:58.531765 90:b1:1c:f4:9d:40 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.33 tell 10.0.0.32, length 28
22:39:58.531982 4a:e8:20:9e:cc:db > 90:b1:1c:f4:9d:40, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 10.0.0.33 is-at 4a:e8:20:9e:cc:db, length 46

[roooockwell]

Hi stcheng,
Sorry about the codes.
You've misunderstand my question.
I mean the unicast arp request won't trap to CPU.
You just show me the broadcast arp request.
In the old version codes of SAI , I found that only arp request with dstmac==ff:ff:ff:ff:ff:ff will trap to cpu.
I'm using tomahawk . So I guess it should be the SAI implemention problem of tomahawk.
You can check the SAI codes: brcm_sai_host_intf.c. case SAI_HOSTIF_TRAP_ID_ARP_REQUEST:

regards,
gongjian

[stcheng]

I see. My second entry was a unicast ARP reply. I will check unicast ARP request.