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.

R1A#ping
Protocol [ip]:
Target IP address: 172.16.0.2
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 172.16.0.2, 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 172.16.0.2

The solution worked quite well; I was able to use the short-form ping 172.16.0.2 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 172.16.0.2 (and default packet size of 100 bytes) had IP precedence value 3, while ICMP packets generated with ping 172.16.0.2 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.