Changing IP precedence values in router-generated pings

When I was testing QoS behavior in MPLS/VPN-over-DMVPN networks, I needed a traffic source that could generate packets with different DSCP/IP precedence values. If you have enough routers in your lab (and the MPLS/DMVPN lab that was used to generate the router configurations you get as part of the Enterprise MPLS/VPN Deployment and DMVPN: From Basics to Scalable Networks webinars has 8 routers), it’s usually easier to use a router as a traffic source than to connect an extra IP host to the lab network. Task-at-hand: generate traffic with different DSCP values from the router.

Nothing easier you should say: use extended ping. I did, but it has two annoying “qualities”:

  • You cannot specify all the parameters in a single command line (and pressing ENTER 10+ times gets annoying after a few test runs);
  • The Type of service question expects the value for the whole TOS byte; you have to figure out the position of IP precedence in the TOS byte and shift the desired value accordingly (precedence 3 that I was using is actually TOS value 0x60).

Doing a single test with extended ping is thus quite a lengthy adventure. A differently-attentive person like me could easily get bored or lured into the realm of Twitter-and-friends.

Protocol [ip]:
Target IP address:
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]: 0x60
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/8/24 ms

Can we do better (without writing an ugly EEM applet that feeds the values to the ping command)? Of course we can – the ip local policy command can be used to change several attributes of IP packets generated by the router, including DF bit and DSCP value.

I was always pinging the same IP address, so I wrote a very specific PBR policy: only pings to a specific IP address would get IP precedence value 3.

route-map LocalPolicy permit 10
match ip address TestPings
set ip precedence flash
ip access-list extended TestPings
permit icmp any host

The solution worked quite well; I was able to use the short-form ping and the ICMP packets were sent with IP precedence set to three.

Next I wanted to test multiple IP precedence values. I could have created several pingable IP addresses on the remote end, but decided to test something else: route maps used in policy-based routing can also match on a range of packet lengths. I made shorter pings more important than longer ones:

route-map LocalPolicy permit 10
match ip address ExtraPings
match length 1 200
set ip precedence flash
route-map LocalPolicy permit 20
match ip address ExtraPings
set ip precedence immediate

After I modified the route-map, ICMP packets generated with ping (and default packet size of 100 bytes) had IP precedence value 3, while ICMP packets generated with ping size 300 had IP precedence value 2. Exactly what I needed ... but of course you can extend the solution to generate even more varied IP precedence or DSCP values.


  1. I've used rtr or ip-sla or whatever
    it's called this week to do this.
  2. We just use the Anritsu traffic generator/sniffer/load tester that we have in our lab :-D
  3. For windows machines in a test-lab, I've made this little app:

  4. One word - awesome! )
  5. For different (Type of service) value in extended ping, can you show me other value for different IP precedence. Thanks !!! ;)
  6. Newbie, take a look at
  7. I would have configured different local (loopback) interfaces for differentially sourcing the pings.
    ...And, depending on your needs, don't forget to mention ip sla ;)
  8. @Newbie
    This should come in handy:
  9. It's available now :

    GAV#ping tos ?
    <1-255> Type of service

    thanks to CSCtn94681 Ability to apply the priority markings in the Ping command
    finally resolved in 2012.
Add comment