Support Support Downloads Knowledge Base Juniper Support Portal Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[QFX] How to check if ARP/IGMP queries are sent to CPU from an interface or Vlan level



Article ID: KB37415 KB Last Updated: 24 Sep 2021Version: 1.0

This article explains how to collect PFE level outputs to validate whether ARP or IGMP packets are punted to the RE from Interface or VLAN level. 


Juniper switches are not sending responses to ARP request or IGMP request. Confirm this behavior by using the following two commands.

  1. Monitor traffic interface matching arp
  2. show igmp snooping membership

Isolate the following three points:

  1. Check whether the request is reaching the switch by taking a packet capture on the end node and the switch.

    Example: Monitor traffic interface xe-0/0/3 matching arp extensive
  2. Confirm whether the ARP or IGMP request is being dropped at PFE level using the below HW filter. The following example shows commands for IGMP. The same can be altered for ARP (Family must be set to ethernet-switching).


    set firewall family inet filter igmphit term 1 from source-address <ip address/subnet>
    set firewall family inet filter igmphit term 1 from protocol igmp
    set firewall family inet filter igmphit term 1 then count igmphitstart
    set firewall family inet filter igmphit term 2 then accept
  3. Check whether the PFE has been configured to send ARP or IGMP requests towards the RE.

    Steps to confirm whether PFE is configured correctly at interface level:

    1. Get the port number of affected interface at the VTY  level.

      %  cprod -A fpc0 -c 'show dcbcm ifd all' | grep xe-0/0/0 (we are using xe-0/0/0 as an example)
      ifd name     global-dev  local-dev   port-num   port-name 
      Xe-0/0/0              4          0         1       xe0
    2. To cross check, get the details of the port at BCM level.

      %  cprod -A fpc0 -c 'set dc bc "phy info"' | grep xe0
        xe0(  1)  600d  8500     0    8d                BCM84328     250000 
    3. Get the PROTOCOL_PKT_INDEX value using the following command:

      TFXPC0(vty)# set dcbcm bcmshell "dump port 1"  <--- value 1 is obtained from output of step 1 and 2. 
      HW (unit 0)
    4. Get the IGMP related Registry values using the PROTOCOL_PKT_INDEX.

      TFXPC0(vty)# set dcbcm bcmshell "getreg IGMP_MLD_PKT_CONTROL[1]" <--- value 1 is obtained from protocol_pkt_index output on step 6.
      HW (unit 0)
      IGMP_MLD_PKT_CONTROL(1).ipipe0[1][0x3a006100]=0x3209240: <PFM_RULE_APPLY=0,

      In this output, look for IGMP_REP_LEAVE_TO_CPU. This indicates whether IGMP reports/leaves received on this port to be sent to CPU.

    Steps to confirm whether PFE is configured correctly at VLAN level:

    1. Get HW token for the affected VLAN.

      vlaninfo -a
      Index Name            Inst  Tag   Flags              HW-Token L3-ifl MST Index 
      10    V333---qfabric  0     0     0x100              148      107    0                 <--- using VLAN333 as an example.
    2. Dump the VLAN information using HW token.

      TFXPC0(vty)# set dcbcm bcmshell "dump vlan 148"
      HW (unit 0)
    3. Look for VLAN_PROFILE_POINTER value from the previous output and run the following command:

      TFXPC0(vty)# set dcbcm bcmshell "dump vlan_profile 5"
      HW (unit 0)
    4. Get the PROTOCOL_PKT_INDEX value from the previous output and run the following command:

      TFXPC0(vty)# set dcbcm bcmshell "getreg IGMP_MLD_PKT_CONTROL[0]"
      HW (unit 0)
      IGMP_MLD_PKT_CONTROL(0).ipipe0[1][0x3a006000]=0: <PFM_RULE_APPLY=0,
    5. If troubleshooting an ARP issue, then replace the 'getreg' option using the following command:

      TFXPC0(vty)# set dcbcm bcmshell "getreg PROTOCOL_PKT_CONTROL[1]"
      HW (unit 0)
      PROTOCOL_PKT_CONTROL(1).ipipe0[1][0x3a002100]=0x54: <SRP_PKT_TO_CPU=0,
    6. Ukern traces are needed to check the reason behind the issue. Collect Ukern trace for RT-HALP and NH-HALP.

      TFXPC0(vty)# show ukern_trace handles
      23     RT-HALP          terse      Off    On     524288      1
      24     RT               none       Off    Off        0      0
      25     BRCM-FC          terse      Off    On     65536      0
      26     NH-HALP          terse      Off    On     524288      1
      cprod -A fpc0 -c "set ukern_trace 23 level extensive"
      cprod -A fpc0 -c "set ukern_trace 23 logging enable"
      cprod -A fpc0 -c "set ukern_trace 23 printf enable"
      cprod -A fpc0 -c "set ukern_trace 26 level extensive"
      cprod -A fpc0 -c "set ukern_trace 26 logging enable"
      cprod -A fpc0 -c "set ukern_trace 26 printf enable"

      Command to collect the output:

      cprod -A fpc0 -c "show ukern_trace 23" >> /var/tmp/FPC0 fpc-ukern_trace_id_23_FPC0.txt
      cprod -A fpc1 -c "show ukern_trace 23" >> /var/tmp/FPC1 fpc-ukern_trace_id_23_fpc1.txt
      cprod -A fpc0 -c "show ukern_trace 26" >> /var/tmp/FPC0 fpc-ukern_trace_id_26_FPC0.txt
      cprod -A fpc1 -c "show ukern_trace 26" >> /var/tmp/FPC1 fpc-ukern_trace_id_26_fpc1.txt

      Collect all of the above listed output, then contact your JTAC Representative for further troubleshooting.

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search