monitor traffic doesn’t show any icmp traffic

If you want to capture some icmp traffic destined for a Junos router by using “monitor traffic“, you must re-think what you are doing. For example you issued the following command and you started ping from another host towards this Junos router.

Unfortunately you won’t get any icmp request on this capture. The underlying reason that I know is that ICMP responses are handled by the data plane (PFE) instead of the control plane. In other words, you don’t really receive this traffic and PFE responds to this ICMP.

What I do usually is to create a sample TCP traffic (e.g SSH request) towards the RE to see some packet traffic.

8 thoughts on “monitor traffic doesn’t show any icmp traffic

  1. Bill Hunt

    What platform are you referring to? Are you sure you had traffic destined to ge-0/0/1 at the time of this capture? I do see icmp packets in “monitor traffic interface matching icmp”, on MX and SRX (branch, and 5800).
    matching “icmp or tcp” works as well.

    Reply
  2. rtoodtoo Post author

    Bill,
    I had tested this on branch SRX. I re-tested this in my home SRX100 and behavior is the same. I don’t see ICMP packets on monitor ouput however interface ICMP counter increments. I also tested in Firefly behavior is the same. I have also an EX2200 switch but this behaves differently. I can really see ICMP packets in monitor command output on this switch. Apparently this is a platform dependent behavior. I thought it is the same in all platforms and it seems I was wrong:) thanks for your comment!

    Reply
  3. paul

    As I did this test on VSRX, it shows, when ICMP packet with size less than 1500, the opposite interface can not see any icmp packet coming in. However, when larger than 1500, the interface can see the icmp echo and reply and fragment.

    Reply
  4. paul

    BTW: When I try to do packet capture on the vsrx. I can surely capture the expected icmp packet despite the size by using the method detailed in KB 11709. Can someone share some idea on this.

    Reply
    1. rtoodtoo Post author

      Paul,
      Packet capture feature enables you to take the packet capture as the name implies.
      ICMP behaviour mentioned on this post a specific one hence it is expected that you can see the packets in our capture.

      Genco

      Reply
      1. Paul

        Hi, rtoodtoo
        This is Paul again, I did another test on EX4200 series. Results prove the icmp packet can be captured on targeted interface, you may see the snapshot I did:

        {master:0}
        lab@EX4200-3> monitor traffic matching “icmp” no-resolve detail
        Address resolution is OFF.
        Listening on me0, capture size 1514 bytes

        10:07:34.144715 In IP (tos 0x0, ttl 64, id 26043, offset 0, flags [none], proto: ICMP (1), length: 84) 172.27.101.100 > 172.27.101.102: ICMP echo request, id 34435, seq 28, length 64
        10:07:34.144785 Out IP (tos 0x0, ttl 64, id 40326, offset 0, flags [none], proto: ICMP (1), length: 84) 172.27.101.102 > 172.27.101.100: ICMP echo reply, id 34435, seq 28, length 64
        10:07:35.145701 In IP (tos 0x0, ttl 64, id 26189, offset 0, flags [none], proto: ICMP (1), length: 84) 172.27.101.100 > 172.27.101.102: ICMP echo request, id 34435, seq 29, length 64
        10:07:35.145772 Out IP (tos 0x0, ttl 64, id 40359, offset 0, flags [none], proto: ICMP (1), length: 84) 172.27.101.102 > 172.27.101.100: ICMP echo reply, id 34435, seq 29, length 64
        10:07:36.146700 In IP (tos 0x0, ttl 64, id 26334, offset 0, flags [none], proto: ICMP (1), length: 84) 172.27.101.100 > 172.27.101.102: ICMP echo request, id 34435, seq 30, length 64
        10:07:36.146771 Out IP (tos 0x0, ttl 64, id 40394, offset 0, flags [none], proto: ICMP (1), length: 84) 172.27.101.102 > 172.27.101.100: ICMP echo reply, id 34435, seq 30, length 64
        10:07:37.147706 In IP (tos 0x0, ttl 64, id 26471, offset 0, flags [none], proto: ICMP (1), length: 84) 172.27.101.100 > 172.27.101.102: ICMP echo request, id 34435, seq 31, length 64
        10:07:37.147771 Out IP (tos 0x0, ttl 64, id 40445, offset 0, flags [none], proto: ICMP (1), length: 84) 172.27.101.102 > 172.27.101.100: ICMP echo reply, id 34435, seq 31, length 64
        ^C
        26 packets received by filter
        0 packets dropped by kernel

        the same can also be seen from Junos website output samples:
        http://www.juniper.net/documentation/en_US/junos14.2/topics/reference/command-summary/monitor-traffic.html —-> you are supposed to search icmp on that page to positioning that output.

        Therefore, you post on this page ” ICMP responses are handled by the data plane (PFE) instead of the control plane. ” is not complete. What we confirmed through our test is this monitor command can capture icmp packets on EX4200 at least, but not on SRXbranch VSRX and J series.

        Reply
        1. Paul

          Plus, MX240 confirms the capability of capturing icmp on its interface as well. Therefore, it varies from box to box. I assume only low-end device wrt SRX or J fails to do so.

          Reply

You have a feedback?