cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3381
Views
0
Helpful
3
Replies

VOIP over an MPLS

heron98105
Level 1
Level 1

I am trying to determine if the output of my traceroutes signal a problem with my service providers MPLS delivery. We have been having call quality issues and I am wondering if this might be the culprit.

Here are 3 seperate outputs from the same 3825 over the MPLS to another 3825, commands run with about 60 seconds between them:

ORD3825#traceroute 10.30.30.254

Type escape sequence to abort.
Tracing the route to 10.30.30.254

  1 xxx.xxx.xxx.xxx 8 msec 4 msec 8 msec
  2  *  *  *
  3 169.130.82.14 [MPLS: Labels 3360/756 Exp 0] 168 msec 204 msec 204 msec
  4 169.130.82.33 [MPLS: Labels 2599/756 Exp 0] 52 msec 56 msec 52 msec
  5 169.130.80.17 [MPLS: Labels 3268/756 Exp 0] 52 msec 56 msec 52 msec
  6 169.130.82.29 [MPLS: Labels 3531/756 Exp 0] 52 msec 56 msec 52 msec
  7 169.130.80.26 [MPLS: Labels 288/756 Exp 0] 52 msec 56 msec 52 msec
  8 66.251.69.1 [MPLS: Labels 2247/756 Exp 0] 52 msec 52 msec 52 msec
  9 64.80.253.241 [MPLS: Labels 2447/756 Exp 0] 52 msec 64 msec 52 msec
10 64.80.253.234 [MPLS: Labels 977/756 Exp 0] 56 msec 52 msec 52 msec
11  *  *  *
12 64.196.222.153 [MPLS: Label 756 Exp 0] 48 msec 48 msec 48 msec
13 xxx.xxx.xxx.xxx 52 msec *  48 msec
ORD3825#
ORD3825#traceroute 10.30.30.254

Type escape sequence to abort.
Tracing the route to 10.30.30.254

  1 xxx.xxx.xxx.xxx 4 msec 4 msec 8 msec
  2  *  *  *
  3 169.130.82.14 [MPLS: Labels 3360/756 Exp 0] 52 msec 52 msec 56 msec
  4 169.130.82.33 [MPLS: Labels 2599/756 Exp 0] 52 msec 52 msec 52 msec
  5 169.130.80.17 [MPLS: Labels 3268/756 Exp 0] 52 msec 52 msec 52 msec
  6 169.130.82.29 [MPLS: Labels 3531/756 Exp 0] 52 msec 52 msec 52 msec
  7 169.130.80.26 [MPLS: Labels 288/756 Exp 0] 180 msec 204 msec 332 msec
  8 66.251.69.1 [MPLS: Labels 2247/756 Exp 0] 52 msec 52 msec 60 msec
  9 64.80.253.241 [MPLS: Labels 2447/756 Exp 0] 52 msec 52 msec 52 msec
10 64.80.253.234 [MPLS: Labels 977/756 Exp 0] 52 msec 56 msec 52 msec
11  *  *  *
12 64.196.222.153 [MPLS: Label 756 Exp 0] 48 msec 48 msec 48 msec
13 xxx.xxx.xxx.xxx 52 msec *  48 msec
ORD3825#
ORD3825#traceroute 10.30.30.254

Type escape sequence to abort.
Tracing the route to 10.30.30.254

  1 xxx.xxx.xxx.xxx 8 msec 4 msec 4 msec
  2  *  *  *
  3 169.130.82.14 [MPLS: Labels 3360/756 Exp 0] 172 msec 104 msec 180 msec
  4 169.130.82.33 [MPLS: Labels 2599/756 Exp 0] 60 msec 52 msec 52 msec
  5 169.130.80.17 [MPLS: Labels 3268/756 Exp 0] 52 msec 52 msec 56 msec
  6 169.130.82.29 [MPLS: Labels 3531/756 Exp 0] 52 msec 52 msec 52 msec
  7 169.130.80.26 [MPLS: Labels 288/756 Exp 0] 52 msec 56 msec 52 msec
  8 66.251.69.1 [MPLS: Labels 2247/756 Exp 0] 52 msec 56 msec 52 msec
  9 64.80.253.241 [MPLS: Labels 2447/756 Exp 0] 52 msec 56 msec 52 msec
10 64.80.253.234 [MPLS: Labels 977/756 Exp 0] 68 msec 52 msec 52 msec
11  *  *  *
12 64.196.222.153 [MPLS: Label 756 Exp 0] 48 msec 48 msec 48 msec
13 xxx.xxx.xxx.xxx 48 msec *  48 msec
ORD3825#

1 Accepted Solution

Accepted Solutions

This wont give you a lot of clues. Traceroute works very differently in MPLS network, as MPLS Core is unaware about your internal prefixes, once MPLS TTL will reach 0, the ICMP error is forwarded to the destination PE router, as only he knows how to get to the source of packet. So all your traceroute packets are go all the way across the ISP network (http://www.cisco.com/en/US/tech/tk436/tk428/technologies_tech_note09186a008020a42a.shtml).

BTW, your ISP shouldn't let you have visibility into his network. Also don't forget that routers in ISP network might be of different platform, and as they have to handle traceroute packets by CPU, and not in HW, their results may vary (CPU load, platform specific behavior - usually ICMP is of low priority when it comes to CPU serving,..)

Much accurate tool would be to configure IP SLA between your's 3825s (http://www.cisco.com/en/US/docs/ios/ipsla/configuration/guide/12_4t/sla_12_4t_book.html).

It will give you detailed info about jitter, delay, etc. but use proper ToS setting, same as you use for voice. Also check contract with your ISP how is handled & defined priority traffic - you might send more priority traffic then in contract, maybe you are using wrong ToS,.. .. ..

View solution in original post

3 Replies 3

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Heron,

you should use extended traceroute in order to mark the traceroute probe packets

here you are using unmarked (EXP=00)  packets that are treated differently.

generally VOIP packets use DSCP EF ( decimal 46  ip precedence 5)

the missing hops in the traceroute have no ip unreachables set on interface towards ping source

However, your test is telling us that packets with TOS = 0x00 are experiencing congestion on third hop

3 169.130.82.14 [MPLS: Labels 3360/756 Exp 0] 168 msec 204 msec 204 msec

3 169.130.82.14 [MPLS: Labels 3360/756 Exp 0] 172 msec 104 msec 180 msec

But, this does not imply that voice packets suffer the same

repeat the test using extended traceroute providing a TOS byte of 160 decimal.

Hope to help

Giuseppe

Sorry for my newbie status but how do I enter the commands for the extended tracerou

te? To mark as voip?

Traceroute:

Ip:

etc... etc..

This wont give you a lot of clues. Traceroute works very differently in MPLS network, as MPLS Core is unaware about your internal prefixes, once MPLS TTL will reach 0, the ICMP error is forwarded to the destination PE router, as only he knows how to get to the source of packet. So all your traceroute packets are go all the way across the ISP network (http://www.cisco.com/en/US/tech/tk436/tk428/technologies_tech_note09186a008020a42a.shtml).

BTW, your ISP shouldn't let you have visibility into his network. Also don't forget that routers in ISP network might be of different platform, and as they have to handle traceroute packets by CPU, and not in HW, their results may vary (CPU load, platform specific behavior - usually ICMP is of low priority when it comes to CPU serving,..)

Much accurate tool would be to configure IP SLA between your's 3825s (http://www.cisco.com/en/US/docs/ios/ipsla/configuration/guide/12_4t/sla_12_4t_book.html).

It will give you detailed info about jitter, delay, etc. but use proper ToS setting, same as you use for voice. Also check contract with your ISP how is handled & defined priority traffic - you might send more priority traffic then in contract, maybe you are using wrong ToS,.. .. ..

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: