The Article provides details on how to disable QFX5200 device from adding its own IP in options filed when in transit path

On transit (forwarded) traffic, the QFX5200 is honoring IPv4 header options and inserting its own IP address into the packet:

• Packets carrying an IPv4 Timestamp option (type 68, flag=1 = record IP address + timestamp) enter the network with the option slots zeroed.
• As they transit the QFX5200, the device writes its own internal IP into an option slot and advances the option pointer.

We used below lab setup to test the behaviour on QFX5200

Topology:

Ubuntu----------QFX5200-A-------------QFX5200-B----------QFX5200-C-------------QFX[l0=172.16.0.1] 

10.1.1.2      10.1.1.1    10.2.2.1     10.2.2.2   10.3.3.1     10.3.3.2     10.4.4.1    10.4.4.2

Case1: without " no-ping-time-stamp" under system Hierarchy 

When we tried ping from ubuntu [10.1.1.2 ] to destination lo0 in qfx110 172.16.0.1 without " no-ping-time-stamp". configuration, we see the timestamp and the hops are recorded .

ubuntu18:~$ ping -c 1 -T tsandaddr 172.16.0.1

PING 172.16.0.1 (172.16.0.1) 56(124) bytes of data.

64 bytes from 172.16.0.1: icmp_seq=1 ttl=61 time=5.76 ms

TS:  10.1.1.2    16985542 absolute

    10.2.2.1    287

    10.3.3.1    1

    10.4.4.1    0

Unrecorded hops: 5

--- 172.16.0.1 ping statistics ---

1 packets transmitted, 1 received, 0% packet loss, time 0ms

rtt min/avg/max/mdev = 5.761/5.761/5.761/0.000 ms

All transit devices egress IP was captured and recorded as seen from above output.

Case2: With " no-ping-time-stamp" under system Hierarchy 

All transit devices QFX5200-A, QFX5200-B, and QFX5200-c are configured as below 

set system no-ping-time-stamp

We see the transit hops are not recorded 

@ubuntu18:~$ ping -c 1 -T tsandaddr 172.16.0.1

PING 172.16.0.1 (172.16.0.1) 56(124) bytes of data.

64 bytes from 172.16.0.1: icmp_seq=1 ttl=61 time=7.68 ms

TS:  10.1.1.2    21241071 absolute

    172.16.0.1 319

    10.1.1.2    -311

--- 172.16.0.1 ping statistics ---

1 packets transmitted, 1 received, 0% packet loss, time 0ms

rtt min/avg/max/mdev = 23.638/23.638/23.638/0.000 ms

From the above testing we can confirm the "no-ping-time-stamp" is applicable for the transit traffic .

Note:  We cannot filter out any single IP options, 

When we try to filter just record-route or time stamp , we see below error while configuration , 

error: value_keyword: 'route-record': Only ip-options 'any' is supported

error: statement creation failed: route-record

This confirms we cannot filter one particular field in IP options, if we need to block, we need to block all the ip-options.