Policy-map & class-map help needed.

Michael Durham · ‎05-20-2013

I have a VPN between my home and office via a HughesNet G4 Internet connection. My most important connection is the VoIP phone. Right now I haee my phone using G729r8 codec and my download RTP stream is perfect! However, my upload RTP stream ends up with paclets being stacked up. If I use G711u coded, my upload packets stack up so bad that the person I am calling cannot even hear me.

I asked for help int the VoIP section of this forum and they suggested that I create a policy-map nad a class-map to priortize my RTP trafffic but no one seems to know how I should write thies mappings or on which interface to apply them.

Below is a diagram of my network and VPN connection. I have a GRE Tunnel that connects me to my office network. I want the RTP traffic to get top priority and the maximum bandwadth of my Internet connection. I do have access to hte cli on my work routers should I need to do any data shaping on that end too. I can provide any config files that you may need.

I am still new to this stuff and willing to learn. But since this is my office phone and I need to contact customers, I need a very quck solution; otherwise, I would do the research and figure this out myself. I am very thankful for any help that you may be able to provide.

My IP phone is on the 192.168.3.0 network and the office CME VoIP router is on the 192.168.2.0 netowrk. The GRE Tunnel is on the 172.30.1.0 netowrk. My office edge router has a public static IP and my edge router has a dynamic public IP.

---Michael

Simon Brooks · ‎05-20-2013

Hi Michael,

Where are you applying your classification? and what type of marking are you doing, IP precedence or DSCP?

I expect the layer 3 device on the inside of your network is classifying the RTP traffic and data, are you using NBAR to classify the traffic or is the cisco phone trusted? When it leaves the layer 3 switch is it being marked in any way?

Personally I would recommend;

On the layer 2 switchport of the layer 3 switch, trust the Cisco phones COS markings and apply a COS-DSCP map (or just apply autoqos to apply a DSCP value of 46 to the RTP stream and AF21 to everything else.

On the router's GRE tunnel you need a service policy, but logical ports do not have the ability to do LLQ as far as I can remember, you need to set it inside a parent policy.

First you need to accept the marking in a class-map

class-map VOICE

match dscp EF

class-map class-default

match dscp AF21

Then apply the policy maps

policy-map GRE_TUNNEL_TRAFFIC_CHILD

class VOICE

priority percent 50

class class-default

bandwidth percent 25

policy-map GRE_TUNNEL_TRAFFIC_PARENT

class class-default

shape average percent 100

service-policy GRE_TUNNEL_TRAFFIC_CHILD

Apply this to your GRE interface;

int tunnel0

service-policy GRE_TUNNEL_TRAFFIC_PARENT out

qos pre-classify

Give that a try mate. Someone else may have a better idea though

Simon

Michael Durham · ‎05-20-2013

Brooks,

I applied your config above but I am still having choppy audio sometimes during a call. Should I increase the percentage? Which one?

Thanks!!

I have uploaded my three condig ifes. Any public IP has been changed to somethin other than the one I am really using for privacy reasons.

Though not shown in my diagram, I have two 3550 switches in my configuration. Also, I have a CUCM server with one IP phone connected to it. However, on my home CUCM setup all calls go out the FXO port at this time. The two VoIP systems do not intermingle.

7970 --> 3550 (home office switch) ----> 3550 (home server switch) ---> 2851 (home CME router) ---? Internet.

Joseph W. Doherty · ‎05-20-2013

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Do you have asymmetrical bandwidth on your Internet connects, i.e. different "down" vs "up"?

Is there any other traffic that crosses either of your Internet connected routers besides the one tunnel's?

How much bandwidth are we working with?

What devices are the Internet connected routers and what IOS version are they using?

You're just using GRE for your tunneling protocol?

Do your phones ToS mark their packets? If so, using what markings? Also if so, anything else with ToS markings crossing the tunnel?

Michael Durham · ‎05-20-2013

Joseph,

My download/upload speed is 12MB/1.5MB +- (HughesNet claims 15/2). I do have a long ping time, 704ms.

Yes other traffice than VoIP goes over the Internet. But at this time I am not connecting to the office's network. There is some EIGRP protocol stuff crossing the tunnel.

The switches are are running IOS: c3550-ipservices-mz.122-44.SE6/c3550-ipservices-mz.122-44.SE6.bin

The rotuers are running IOS: c2800nm-adventerprisek9-mz.151-4.M3.bin

Yes GRE is being used for my tunnel so I can be on the office's CME phone system.

Other than the automatic QoS settings from the switches, I am not doing and data shaping, no ToS no policy-map etc.

Simon Brooks · ‎05-20-2013

Can we see a show run of the switches qos settings?

Also a show int tunnel0 ?

Simon

Michael Durham · ‎05-20-2013

Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 172.30.1.2/30
MTU 17850 bytes, BW 20000 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 110.5.17.22 (GigabitEthernet0/0), destination 55.9.6.90
   Tunnel Subblocks:
      src-track:
         Tunnel0 source tracking subblock associated with GigabitEthernet0/0
          Set of tunnels with source GigabitEthernet0/0, 1 member (includes iterators), on interface
Tunnel protocol/transport GRE/IP
    Key 0x1, sequencing disabled
    Checksumming of packets disabled
Tunnel TTL 255, Fast tunneling enabled
Tunnel transport MTU 1410 bytes
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Tunnel protection via IPSec (profile "WA-FLA")
Last input 00:00:00, output 3w5d, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 39568
Queueing strategy: fifo (QOS pre-classification)
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
     3268881 packets input, 241012139 bytes, 0 no buffer
     Received 0 broadcasts (6 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     3286345 packets output, 480182794 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out

Simon Brooks · ‎05-20-2013

Thanks,

Could you now share a show policy-map ?

Thanks

Simon

Simon Brooks · ‎05-20-2013

Sorry meant show policy-map int tunnel0

Michael Durham · ‎05-20-2013

Tunnel0

Service-policy output: GRE_TUNNEL_TRAFFIC_PARENT

Class-map: class-default (match-any)

11209 packets, 971238 bytes

5 minute offered rate 9000 bps, drop rate 0 bps

Match: any

Queueing

queue limit 64 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 11024/1832952

shape (average) cir 100000000, bc 1000000, be 1000000

target shape rate 100000000

Service-policy : GRE_TUNNEL_TRAFFIC_CHILD

queue stats for all priority classes:

queue limit 64 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 0/0

Class-map: VOICE (match-all)

0 packets, 0 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: dscp ef (46)

Match: dscp af21 (18)

Priority: 50% (50000 kbps), burst bytes 1250000, b/w exceed drops: 0

Class-map: class-default (match-any)

11209 packets, 971238 bytes

5 minute offered rate 9000 bps, drop rate 0 bps

Match: any

Queueing

queue limit 64 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 11024/1832952

bandwidth 25% (25000 kbps)

Joseph W. Doherty · ‎05-20-2013

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

704 ms pings!!! That's a problem. Generally, VoIP recommends one way latency no more than 250ms. Are your two sites on opposite sides of the world? Or is this via satellite?

Sorry, I should have been clearer. Any other traffic on the Internet connected routers besides the tunnel traffic? Just the one tunnel? (In other words, do both [branch and HQ] Internet connected routers traffic comprises only the one tunnel between them?)

Shaping is often a critical component when there's a logical bandwidth restriction that's less than the physical interface bandwidth.

Michael Durham · ‎05-20-2013

Yea I know htat 700+ is a problem. And yes I am using a satellite for my Internet connection. No other options here.

We only have one tunnel in the config. I use the salellite connection for VoIP and web browsing. Right now I am not connected to the corporate network. HQ has no other tunnels to other locations.

HQ has a fast Comcast Internet connection. I would if it were out here. They stop 2 mile form my location.

Joseph W. Doherty · ‎05-20-2013

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Well the 700 ms RTT is likely to be a problem - and with satellite, not much you can do about it.

What we can do, is shape for your upstream bandwidth and prioritize VoIP.

Something like:

class-map match-any voip

match (whatever matches your VoIP packets - might be ToS and/or might use NBAR)

policy-map sampe-qos

class voip

priority percent 99

class class-default

bandwidth percent 1

fair-queue

policy-map sample-shape

class class-default

shape average 1500000

service-policy sample-qos

int tun #

service-policy output sample-shape

Simon Brooks · ‎05-20-2013

Can I see a show int s0 also?

We might need link fragmentation and interleaving applying to the serial interface depending on protocol.

Also can you give me show run int s0

and

show run int tun0

So we can sort out MTU and MSS.

Thanks

Simon

Michael Durham · ‎05-20-2013

Brooks,

I am not using any serial connections. one Gigabit port connects to the HughesNet satellite modem/rotuer amd the other Gigabit port connects to the home server switch.

When on VoIP calls I could care less about browsing at a fast speed.

CME_Router#sh int

GigabitEthernet0/0 is up, line protocol is up

Hardware is MV96340 Ethernet, address is 0021.5527.1340 (bia 0021.5527.1340)

Description: Router - C3524 Port Fa0/23 192.168.70.1

Internet address is 100.75.17.226/29

MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full Duplex, 100Mbps, media type is T

output flow-control is XON, input flow-control is XON

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:00, output 00:00:00, output hang never

Last clearing of "show interface" counters never

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: Class-based queueing

Output queue: 0/1000/0 (size/max total/drops)

5 minute input rate 138000 bits/sec, 22 packets/sec

5 minute output rate 5000 bits/sec, 11 packets/sec

64140659 packets input, 2868238027 bytes, 0 no buffer

Received 27014 broadcasts (0 IP multicasts)

0 runts, 0 giants, 0 throttles

4 input errors, 0 CRC, 4 frame, 0 overrun, 0 ignored

0 watchdog, 0 multicast, 0 pause input

37699636 packets output, 3214265511 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 unknown protocol drops

0 babbles, 0 late collision, 0 deferred

66 lost carrier, 0 no carrier, 0 pause output

0 output buffer failures, 0 output buffers swapped out

GigabitEthernet0/0.69 is deleted, line protocol is down

Hardware is MV96340 Ethernet, address is 0021.5527.1340 (bia 0021.5527.1340)

MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA

ARP type: ARPA, ARP Timeout 04:00:00

Keepalive set (10 sec)

Last clearing of "show interface" counters never

GigabitEthernet0/1 is up, line protocol is up

Hardware is MV96340 Ethernet, address is 0021.5527.1341 (bia 0021.5527.1341)

Description: Router - C3524 Port Fa0/20 Trunk

MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set

Keepalive set (10 sec)

Full Duplex, 100Mbps, media type is T

output flow-control is XON, input flow-control is XON

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:00, output 00:00:00, output hang never

Last clearing of "show interface" counters never

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 95000 bits/sec, 62 packets/sec

5 minute output rate 142000 bits/sec, 26 packets/sec

196240010 packets input, 4116400420 bytes, 0 no buffer

Received 5080090 broadcasts (126576843 IP multicasts)

1 runts, 0 giants, 0 throttles

3 input errors, 1 CRC, 0 frame, 0 overrun, 1 ignored

0 watchdog, 0 multicast, 0 pause input

94149510 packets output, 1799712042 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 unknown protocol drops

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier, 0 pause output

0 output buffer failures, 0 output buffers swapped out

GigabitEthernet0/1.3 is up, line protocol is up

Hardware is MV96340 Ethernet, address is 0021.5527.1341 (bia 0021.5527.1341)

Internet address is 192.168.3.1/24

MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation 802.1Q Virtual LAN, Vlan ID 3.

ARP type: ARPA, ARP Timeout 04:00:00

Keepalive set (10 sec)

Last clearing of "show interface" counters never

GigabitEthernet0/1.30 is deleted, line protocol is down

Hardware is MV96340 Ethernet, address is 0021.5527.1341 (bia 0021.5527.1341)

MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA

ARP type: ARPA, ARP Timeout 04:00:00

Keepalive set (10 sec)

Last clearing of "show interface" counters never

GigabitEthernet0/1.69 is up, line protocol is up

Hardware is MV96340 Ethernet, address is 0021.5527.1341 (bia 0021.5527.1341)

Internet address is 192.168.69.3/24

MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation 802.1Q Virtual LAN, Vlan ID 69.

ARP type: ARPA, ARP Timeout 04:00:00

Keepalive set (10 sec)

Last clearing of "show interface" counters never

GigabitEthernet0/1.100 is deleted, line protocol is down

Hardware is MV96340 Ethernet, address is 0021.5527.1341 (bia 0021.5527.1341)

MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA

ARP type: ARPA, ARP Timeout 04:00:00

Keepalive set (10 sec)

Last clearing of "show interface" counters never

GigabitEthernet0/1.110 is up, line protocol is up

Hardware is MV96340 Ethernet, address is 0021.5527.1341 (bia 0021.5527.1341)

Internet address is 10.110.0.1/24

MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation 802.1Q Virtual LAN, Vlan ID 110.

ARP type: ARPA, ARP Timeout 04:00:00

Keepalive set (10 sec)

Last clearing of "show interface" counters never

GigabitEthernet0/1.115 is up, line protocol is up

Hardware is MV96340 Ethernet, address is 0021.5527.1341 (bia 0021.5527.1341)

Internet address is 10.115.0.1/24

MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation 802.1Q Virtual LAN, Vlan ID 115.

ARP type: ARPA, ARP Timeout 04:00:00

Keepalive set (10 sec)

Last clearing of "show interface" counters never

GigabitEthernet0/1.125 is deleted, line protocol is down

Hardware is MV96340 Ethernet, address is 0021.5527.1341 (bia 0021.5527.1341)

MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA

ARP type: ARPA, ARP Timeout 04:00:00

Keepalive set (10 sec)

Last clearing of "show interface" counters never

NVI0 is up, line protocol is up

Hardware is NVI

Interface is unnumbered. Using address of GigabitEthernet0/0 (110.5.17.226)

MTU 1514 bytes, BW 56 Kbit/sec, DLY 5000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation UNKNOWN, loopback not set

Keepalive set (10 sec)

Last input never, output never, output hang never

Last clearing of "show interface" counters never

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

0 packets input, 0 bytes, 0 no buffer

Received 0 broadcasts (0 IP multicasts)

0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

0 packets output, 0 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 unknown protocol drops

0 output buffer failures, 0 output buffers swapped out

Tunnel0 is up, line protocol is up

Hardware is Tunnel

Internet address is 172.30.1.2/30

MTU 17850 bytes, BW 20000 Kbit/sec, DLY 50000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation TUNNEL, loopback not set

Keepalive not set

Tunnel source 100.75.17.226 (GigabitEthernet0/0), destination 55.9.6.90

Tunnel Subblocks:

src-track:

Tunnel0 source tracking subblock associated with GigabitEthernet0/0

Set of tunnels with source GigabitEthernet0/0, 1 member (includes iterators), on interface

Tunnel protocol/transport GRE/IP

Key 0x1, sequencing disabled

Checksumming of packets disabled

Tunnel TTL 255, Fast tunneling enabled

Tunnel transport MTU 1410 bytes

Tunnel transmit bandwidth 8000 (kbps)

Tunnel receive bandwidth 8000 (kbps)

Tunnel protection via IPSec (profile "WA-FLA")

Last input 00:00:02, output 3w5d, output hang never

Last clearing of "show interface" counters never

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 39753

Queueing strategy: fifo (QOS pre-classification)

Output queue: 0/0 (size/max)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

3275891 packets input, 241499245 bytes, 0 no buffer

Received 0 broadcasts (6 IP multicasts)

0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

3293400 packets output, 481149940 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 unknown protocol drops

0 output buffer failures, 0 output buffers swapped out