Switching

H:\>ping 10.10.2.65 -l 1600

Pinging 10.10.2.65 with 1600 bytes of data:
Reply from 10.10.2.65: bytes=1600 time=3ms TTL=58
Reply from 10.10.2.65: bytes=1600 time=3ms TTL=58
Reply from 10.10.2.65: bytes=1600 time=3ms TTL=58
Reply from 10.10.2.65: bytes=1600 time=3ms TTL=58

master:0}
ex4200> monitor traffic interface ae0.0 matching "host 172.21.21.62 and not tcp port 22" no-resolve
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is OFF.
Listening on ae0.0, capture size 96 bytes

10:20:39.945247 In IP truncated-ip - 1440 bytes missing! 172.21.21.62 > 10.10.2.65: ICMP echo request, id 1, seq 849, length 1480
10:20:39.945272 In IP truncated-ip - 88 bytes missing! 172.21.21.62 > 10.10.2.65: icmp
10:20:39.945345 Out IP truncated-ip - 1440 bytes missing! 10.10.2.65 > 172.21.21.62: ICMP echo reply, id 1, seq 849, length 1480
10:20:39.945390 Out IP truncated-ip - 88 bytes missing! 10.10.2.65 > 172.21.21.62: icmp
10:20:40.950871 In IP truncated-ip - 1440 bytes missing! 172.21.21.62 > 10.10.2.65: ICMP echo request, id 1, seq 850, length 1480
10:20:40.950898 In IP truncated-ip - 88 bytes missing! 172.21.21.62 > 10.10.2.65: icmp
10:20:40.950974 Out IP truncated-ip - 1440 bytes missing! 10.10.2.65 > 172.21.21.62: ICMP echo reply, id 1, seq 850, length 1480
10:20:40.951021 Out IP truncated-ip - 88 bytes missing! 10.10.2.65 > 172.21.21.62: icmp
10:20:41.956501 In IP truncated-ip - 1440 bytes missing! 172.21.21.62 > 10.10.2.65: ICMP echo request, id 1, seq 851, length 1480
10:20:41.956529 In IP truncated-ip - 88 bytes missing! 172.21.21.62 > 10.10.2.65: icmp
10:20:41.956605 Out IP truncated-ip - 1440 bytes missing! 10.10.2.65 > 172.21.21.62: ICMP echo reply, id 1, seq 851, length 1480
10:20:41.956666 Out IP truncated-ip - 88 bytes missing! 10.10.2.65 > 172.21.21.62: icmp
10:20:42.961358 In IP truncated-ip - 1440 bytes missing! 172.21.21.62 > 10.10.2.65: ICMP echo request, id 1, seq 852, length 1480
10:20:42.961387 In IP truncated-ip - 88 bytes missing! 172.21.21.62 > 10.10.2.65: icmp
10:20:42.961462 Out IP truncated-ip - 1440 bytes missing! 10.10.2.65 > 172.21.21.62: ICMP echo reply, id 1, seq 852, length 1480
10:20:42.961509 Out IP truncated-ip - 88 bytes missing! 10.10.2.65 > 172.21.21.62: icmp
^C
148 packets received by filter
0 packets dropped by kernel

1-)When sending icmp with size 1600 from windows machine to the ex4200 in VC, ae0 -10.10.2.65. Real time monitor traffic interface on ex4200
showing a few things:
It says ip truncated-ip - 1440 bytes missing.... What does missing mean? what are 1440 and 1480 bytes and 88 bytes?

2-)Can we understand from the output with "truncated-ip - XXXX or XX bytes missing" fragmentation is definitely happening?
3-)From windows machine sending size -l 1600, is it mss or not mss, if it is not what is it?

Note: All network path mtu size is 1500 bytes. and I did ssh to ex4200 in vc.

Thx,

Ar

add "size 9999" option to monitor command, by default tcpdump capture only first 64 bytes of packet

H:\>ping 10.10.2.65 -l 1600

Pinging 10.10.2.65 with 1600 bytes of data:
Reply from 10.10.2.65: bytes=1600 time=3ms TTL=58
Reply from 10.10.2.65: bytes=1600 time=3ms TTL=58
Reply from 10.10.2.65: bytes=1600 time=3ms TTL=58
Reply from 10.10.2.65: bytes=1600 time=3ms TTL=58


>monitor traffic interface ae0.0 no-resolve matching "host 172.21.21.62 and icmp" size 9999
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is OFF.
Listening on ae0.0, capture size 9999 bytes

12:35:07.693220 In IP 172.21.21.62 > 10.10.2.65: icmp
12:35:07.693244 In IP 172.21.21.62 > 10.10.2.65: ICMP echo request, id 1, seq 1432, length 1480
12:35:07.693331 Out IP 10.10.2.65 > 172.21.21.62: ICMP echo reply, id 1, seq 1432, length 1480
12:35:07.693376 Out IP 10.10.2.65 > 172.21.21.62: icmp
12:35:08.706459 In IP 172.21.21.62 > 10.10.2.65: ICMP echo request, id 1, seq 1433, length 1480
12:35:08.706490 In IP 172.21.21.62 > 10.10.2.65: icmp
12:35:08.706563 Out IP 10.10.2.65 > 172.21.21.62: ICMP echo reply, id 1, seq 1433, length 1480
12:35:08.706610 Out IP 10.10.2.65 > 172.21.21.62: icmp
12:35:09.719541 In IP 172.21.21.62 > 10.10.2.65: ICMP echo request, id 1, seq 1434, length 1480
12:35:09.719574 In IP 172.21.21.62 > 10.10.2.65: icmp
12:35:09.719647 Out IP 10.10.2.65 > 172.21.21.62: ICMP echo reply, id 1, seq 1434, length 1480
12:35:09.719693 Out IP 10.10.2.65 > 172.21.21.62: icmp
12:35:10.730452 In IP 172.21.21.62 > 10.10.2.65: ICMP echo request, id 1, seq 1435, length 1480
12:35:10.730483 In IP 172.21.21.62 > 10.10.2.65: icmp
12:35:10.730553 Out IP 10.10.2.65 > 172.21.21.62: ICMP echo reply, id 1, seq 1435, length 1480
12:35:10.730600 Out IP 10.10.2.65 > 172.21.21.62: icmp
12:35:11.740802 In IP 172.21.21.62 > 10.10.2.65: ICMP echo request, id 1, seq 1436, length 1480
12:35:11.740834 In IP 172.21.21.62 > 10.10.2.65: icmp
12:35:11.740907 Out IP 10.10.2.65 > 172.21.21.62: ICMP echo reply, id 1, seq 1436, length 1480
12:35:11.740956 Out IP 10.10.2.65 > 172.21.21.62: icmp
12:35:12.752536 In IP 172.21.21.62 > 10.10.2.65: ICMP echo request, id 1, seq 1437, length 1480
12:35:12.752569 In IP 172.21.21.62 > 10.10.2.65: icmp
12:35:12.752643 Out IP 10.10.2.65 > 172.21.21.62: ICMP echo reply, id 1, seq 1437, length 1480
12:35:12.752689 Out IP 10.10.2.65 > 172.21.21.62: icmp
12:35:13.764154 In IP 172.21.21.62 > 10.10.2.65: ICMP echo request, id 1, seq 1438, length 1480
12:35:13.764196 In IP 172.21.21.62 > 10.10.2.65: icmp
12:35:13.764269 Out IP 10.10.2.65 > 172.21.21.62: ICMP echo reply, id 1, seq 1438, length 1480
12:35:13.764316 Out IP 10.10.2.65 > 172.21.21.62: icmp
^C
80 packets received by filter
0 packets dropped by kernel

{master:0}

Why do we add this size 9999 there?  Is this reason that we are seeing "IP truncated-ip - 1268 bytes missing! " when not using size 9999?

On certain interfaces we may see messages for Out IP truncated-ip when running monitor traffic interface. These are non-impacting in nature; this article describes how to eliminate them by increasing the default capture-size.

This is because the default capture size in Junos is 96.  Packets exceeding this default capture-size will be truncated.

from your output.

Listening on ae0.0, capture size 96 bytes

Here are a couple of KBs, with detailed explanation.

https://kb.juniper.net/InfoCenter/index?page=content&id=KB13662&actp=search&searchid=1234338892059&act=login

https://kb.juniper.net/InfoCenter/index?page=content&id=KB31448&cat=REPORTING&actp=LIST

Increasing the default-size of the capture will stop those messages.