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.

admin@host> monitor traffic interface ge-0/0/1 matching "icmp or tcp"
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay.
Address resolution timeout is 4s.
Listening on ge-0/0/1, capture size 96 bytes

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.

About: rtoodtoo

Genco has worked for more than 10 years as a Network/Support Engineer. He is also interested in Python, Linux, Security and SD-WAN, currently lives in the Netherlands and works as a Network Support Engineer at Tesla Inc. // JNCIE-SEC #223 / RHCE / PCNSE


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

  1. 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.

  2. 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!

  3. 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.

  4. 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.

    1. 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

      1. 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.

        1. 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.

You have a feedback?

This site uses Akismet to reduce spam. Learn how your comment data is processed.