I recently ran into an issue with Class of Service on an SRX device where DSCP markings on traffic we not being seen on an upstream router when going through an SRX. After running packet captures showing the DSCP-marked traffic leaving the SRX the customer still wanted to proceed with troubleshooting the SRX as being at fault.

Because of this, I wanted to generate traffic with the DSCP markings directly from the SRX. In order to do this we can use a simple ping in order to generate a Type of Service (TOS) value. The command to do so is below:

ping tos <value> <host>

The <value> is where we set a TOS value, and <host> is the destination address we want to ping.

In the example below, we will use a TOS value of 46, and ping the host 1.2.3.4:

ping tos 46 1.2.3.4

From here we can open a second CLI window and can monitor traffic coming in and out of the SRX.

root@SRX> monitor traffic interface ge-0/0/0.0 detail matching "host 1.2.3.4" no-resolve   
Address resolution is OFF.
Listening on ge-0/0/0.0, capture size 1514 bytes

14:09:15.098657 Out IP (tos 0x2e,ECT(0), ttl  64, id 57053, offset 0, flags [none], proto: ICMP (1), length: 84) 1.1.1.1 > 1.2.3.4: ICMP echo request, id 56818, seq 0, length 64
14:09:15.163678  In IP (tos 0x0, ttl  60, id 43312, offset 0, flags [none], proto: ICMP (1), length: 84) 1.2.3.4 > 1.1.1.1: ICMP echo reply, id 56818, seq 0, length 64

Note how the packets are tagged with the TOS 0x2e going out, but the ICMP replies are coming back with the DSCP marker stripped! In this case, an intermediary switch the SRX was connected to was not trusting the DSCP markings. After that issue was corrected here is what we saw instead:

root@SRX> monitor traffic interface ge-0/0/0.0 detail matching "host 1.2.3.4" no-resolve   
Address resolution is OFF.
Listening on ge-0/0/0.0, capture size 1514 bytes

14:09:15.098657 Out IP (tos 0x2e,ECT(0), ttl  64, id 57053, offset 0, flags [none], proto: ICMP (1), length: 84) 1.1.1.1 > 1.2.3.4: ICMP echo request, id 56818, seq 0, length 64
14:09:15.163678  In IP (tos 0x2e,ECT(0), ttl  60, id 43312, offset 0, flags [none], proto: ICMP (1), length: 84) 1.2.3.4 > 1.1.1.1: ICMP echo reply, id 56818, seq 0, length 64

I hope this neat little trick helps someone else out in the future!

Tags: , , ,

Clay is a recovering server guy that has learned how networks and security worked and used it to his advantage. He is always eager to learn a new technology or technique as there are never enough tools in the toolbox for solving problems in modern networking and server environment. Clay is always striving to make the "more perfect" network available to peers and users. He currently an active Juniper Ambassador, and has contributed to multiple Juniper Day One guides to solve both old and new problems that engineers face in their networks. Clay is a talented individual that enjoys the new challenges that are facing next generation networks, both large and small.

Clay has achieved two of the highest certifications from Juniper Networks: the JNCIE-SEC (Certification Number #69) for his proficiency in Juniper Networks security platforms, and the JNCIE-ENT (Certification Number #492) for his proficiency in Juniper Networks enterprise routing and switching platforms. He is also certified as a Pulse Secure Certified Instructor and Palo Alto Networks Certified Network Security Instructor. Outside of the of the certifications above, Clay also has experience with securing cloud-provider networks while ensuring the highest levels of performance to serve its users.

Leave a comment

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