RtoDto.net
Network/Security/Programming

monitor traffic doesn’t show any icmp traffic

rtoodtoo junos January 23, 2013

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  or  for full protocol decode
Address resolution is ON. Use  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

Worked for more than 10 years as a Network/Support Engineer and also interested in Python, Linux, Security and SD-WAN // JNCIE-SEC #223 / RHCE / PCNSE

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

    Reply

  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!

    Reply

  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.

    Reply

  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.

    Reply

    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

      Reply

      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.

        Reply

        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.

          Reply

  5. I’m able to see ICMP on SRX300

    root@srx-1> monitor traffic interface ge-0/0/1 no-resolve detail matching “host 192.168.255.3” | grep “echo request echo request”
    Address resolution is OFF.
    Listening on ge-0/0/1, capture size 1514 bytes

    15:10:53.955214 Out IP (tos 0x0, ttl 64, id 35726, offset 0, flags [none], proto: ICMP (1), length: 84) 192.168.255.1 > 192.168.255.3: ICMP echo request, id 16711, seq 0, length 64
    15:10:53.957340 In IP (tos 0x0, ttl 63, id 35726, offset 0, flags [none], proto: ICMP (1), length: 84) 192.168.255.3 > 192.168.255.1: ICMP echo reply, id 16711, seq 0, length 64
    15:10:53.957983 Out IP (tos 0x0, ttl 64, id 35729, offset 0, flags [none], proto: ICMP (1), length: 84) 192.168.255.1 > 192.168.255.3: ICMP echo request, id 16711, seq 1, length 64
    15:10:53.959010 In IP (tos 0x0, ttl 63, id 35729, offset 0, flags [none], proto: ICMP (1), length: 84) 192.168.255.3 > 192.168.255.1: ICMP echo reply, id 16711, seq 1, length 64
    15:10:53.959598 Out IP (tos 0x0, ttl 64, id 35731, offset 0, flags [none], proto: ICMP (1), length: 84) 192.168.255.1 > 192.168.255.3: ICMP echo request, id 16711, seq 2, length 64
    15:10:53.960491 In IP (tos 0x0, ttl 63, id 35731, offset 0, flags [none], proto: ICMP (1), length: 84) 192.168.255.3 > 192.168.255.1: ICMP echo reply, id 16711, seq 2, length 64
    15:10:53.960842 Out IP (tos 0x0, ttl 64, id 35732, offset 0, flags [none], proto: ICMP (1), length: 84) 192.168.255.1 > 192.168.255.3: ICMP echo request, id 16711, seq 3, length 64
    15:10:53.961987 In IP (tos 0x0, ttl 63, id 35732, offset 0, flags [none], proto: ICMP (1), length: 84) 192.168.255.3 > 192.168.255.1: ICMP echo reply, id 16711, seq 3, length 64
    15:10:53.962561 Out IP (tos 0x0, ttl 64, id 35735, offset 0, flags [none], proto: ICMP (1), length: 84) 192.168.255.1 > 192.168.255.3: ICMP echo request, id 16711, seq 4, length 64
    15:10:53.963573 In IP (tos 0x0, ttl 63, id 35735, offset 0, flags [none], proto: ICMP (1), length: 84) 192.168.255.3 > 192.168.255.1: ICMP echo reply, id 16711, seq 4, length 64

    Reply

  6. actually this command is what I used…

    root@srx-1> monitor traffic interface ge-0/0/1 no-resolve detail matching “host 192.168.255.3”

    Reply

Leave a Reply to PaulCancel reply

Discover more from RtoDto.net

Subscribe now to keep reading and get access to the full archive.

Continue reading