Hack74.Audit a Network s QoS Capabilities

Hack 74. Audit a Network's QoS Capabilities

Networks without Quality of Service (QoS) measures aren't always suitable to carry voice traffic. So how do you know whether a network path supports QoS?

Using pathping and traceroute during peak traffic periods, you'll be able to establish whether a particular IP route is a good place for time-sensitive traffic like VoIP media streams. You'll know the jitter and latency qualities of the network, you'll have identified problem routers and potential traffic bottlenecks, you'll know whether each router supports Resource Reservation Protocol (RSVP, a QoS standard that allows network bandwidth to be reserved for each call), and you'll know how well the network supports 802.1p precedence tagging. (I explain what 802.1p is in this hack; keep going!)

Though Linux is better equipped to provide VoIP services and to serve as a base for troubleshooting, Windows does have a nifty command-line tool that you can use to determine if IP routing supports basic class-of-service measures. pathping, which ships with Windows 2000 and Windows XP, lets you see how well your Internet provideror your corporate networksupports 802.1p and RSVP. This makes pathping a particularly useful Windows-only VoIP networking tool.

On non-Windows boxes, though, you still have traceroute, of course. While not implicitly a QoS measurement tool, traceroute can gather useful performance data from the VoIP network.

6.4.1. Using pathping

pathping is similar to traceroute. It first determines the IP route along all hops from the host where it's running to the host at which it's targeted. Then, it collects information from each hop along the way, like latency times, and displays what information it has collected. The following command returns the hostname and IP address from each hop along the route to the destination, if each hop provides an ICMP response:

 C:\> pathping www.broadvoxdirect.com 

The output shows the route to the destination, similar to traceroute:

 Tracing route to www.bigvoxdirect.com [65.67.129.23] over a maximum of 30 hops:   0   kelly-6aizy9qd1.ce1.client2.attbi.com [10.1.1.202]   1  10.1.1.1   2  10.248.164.1   3  bic01.elyehe1.oh.attbb.net [24.131.64.38]   4  12.244.65.61   5  12.125.176.121   6  gbr2-p70.phlpa.ip.att.net [12.123.137.26]   7  tbr1-p012601.phlpa.ip.att.net [12.122.12.101]   8  tbr1-cl8.n54ny.ip.att.net [12.122.2.17]   9  ggr2-p300.n54ny.ip.att.net [12.123.3.58]  10  so-1-0-0.gar4.NewYork1.Level3.net [4.68.127.5]  11  ge-2-1-0.bbr1.NewYork1.Level3.net [64.159.4.145]  12  so-0-0-0.mpls1.Cleveland1.Level3.net [209.247.11.134]  13  ge-6-0.hsa1.Cleveland1.Level3.net [209.244.22.98]  14  BIGVOX-DIS.hsa1.Level3.net [64.156.66.10]  15  penguin.bigvoxdirect.com [65.67.129.23] 

The following example, which uses the T option, checks to see whether each router along the path supports 802.1p precedence tags. These tags are used by routers and switches to prioritize real-time, delay-sensitive packets such as the UDP datagrams commonly used in VoIP. The more hops along a route that support 802.1p, the better off your VoIP quality on that route is likely to be, because those routers can prioritize voice data over nonvoice data.

 C:\> pathping www.bigvoxdirect.com T Checking for connectivity with Layer-2 tags.   1  10.1.1.1 OK.   2  10.248.164.1 OK.   3  24.131.64.38 OK.   4  12.244.65.61 OK.   5  12.125.176.121  OK.   6  12.123.137.26 General failure. 

The output from pathping first shows the route, like the previous example, but also adds the 802.1p feedback as far along the route as possible. Not all devices along every route support 802.1p. In this example, the sixth hop does not, because the router isn't configured for IP Type of Service (ToS) and 802.1p. Since the 802.1p header can't be carried past the sixth hop, subsequent hops cannot be tested for 802.1p support.

The -R option will do a similar check for RSVP support, in a similar fashion. You aren't nearly as likely to find RSVP-supporting hops on the public Internet as you are 802.1-aware hops. But, if RSVP is configured on a private network, you can use pathping to help you evaluate that network's hardware readiness for QoS. It will tell you which routers support RSVP and which routers need to be either reprogrammed or upgraded to support it.

6.4.2. Measure the Latency Time and Jitter on a Call Path

The cumulative latency on a route is a good indicator of how latent it is and, therefore, how well it will work as a VoIP call path. An easy way to record latency between hops (routers) on a route is by using traceroute (on Windows, tracert).

Using traceroute, you can discover the route to the host at the specified address, send several ICMP packets to each hop on the route, and then be shown the following:

• The highest round-trip latency to each router, in milliseconds

• The lowest round-trip latency to each router

• The average round-trip latency to each router

• The IP address and/or hostname of each router

• Whether an ICMP ping response was received from each router

The syntax for traceroute is very simple:

 # traceroute www.macvoip.com  Tracing route to www.macvoip.com [65.31.69.11] over a maximum of 30 hops:  1   1 ms   1 ms   1 ms  10.1.1.1  2  14 ms  13 ms  18 ms  10.248.164.1  3  18 ms  16 ms  12 ms  bic01.elyehe1.oh.attbb.net [24.131.64.38]  4  19 ms  21 ms  34 ms  12.244.65.61  5  31 ms  23 ms  24 ms  12.244.72.70  6  25 ms  26 ms  28 ms  tbr1-p012401.phlpa.ip.att.net [12.123.137.45]  7  32 ms  27 ms  27 ms  tbr1-cl8.n54ny.ip.att.net [12.122.2.17]  8  28 ms  28 ms  34 ms  ggr2-p300.n54ny.ip.att.net [12.123.3.58]  9  31 ms  30 ms  28 ms  att-gw.ny.aol.net [192.205.32.218] 10  32 ms  28 ms  43 ms  bb2-nye-P1-0.atdn.net [66.185.151.66] 11  29 ms  47 ms  34 ms  bb2-vie-P12-0.atdn.net [66.185.152.201] 12  64 ms  48 ms  62 ms  bb2-chi-P6-0.atdn.net [66.185.152.214] 13  60 ms  60 ms  62 ms  RR-DET.atdn.net [66.185.141.98] 14  59 ms  54 ms  66 ms  os0-0.fmhlmi1-rtr1.twmi.rr.com [24.169.225.65] 15  57 ms  53 ms  63 ms  ig0-1.fmhlmi1-ubr5.twmi.rr.com [24.169.225.22] 16  64 ms  66 ms  68 ms  www.thelinuxfix.com  [65.31.69.11] 

Whether on Linux, Windows, or Mac, traceroute's output tends to be the same. This sample output is from Windows, but all traceroutes show you the minimum, average, and maximum latency to each hop along the route.

Not all IP networks permit ICMP trafficor traceroutes in particularbecause some system operators prohibit them for security reasons. Most routes across the Internet should provide a valid response when using the traceroute command. As you examine the output from the traceroute command, pay special attention to the variance in highest and lowest latency times (not the average latency time). This variance is a good, rough estimate of jitter between each hop. (If you don't know what jitter is, don't freak out! Just refer to "Sniff Out Jittery Calls with Ethereal" [Hack #83].)

Keep in mind, though, that the latency and jitter patterns of VoIP traffic (which is UDP and very consistent in nature) can vary from your readings here, since traceroute uses ICMP packets that are very bursty in nature. The routers along the route that you're evaluating might already be configured to treat VoIP traffic with greater precedence, but at least you'll get an idea of the general service conditions along the route.

6.4.3. See Also

• http://www.microsoft.com/ technet for more information on pathping