04-04-2013 09:44 AM - edited 03-07-2019 12:38 PM
With the help of forum users, I have a QoS policy in place that is set to reserve/prioritize traffic for my outgoing VoIP traffic. We outsource our voip solution.
I am trying to test my QoS policy by performing multiple file transfers outbound to our remote site over vpn which uses the same interface. You can see by the txload stats below that it should have been high enough to make the voip policy kick in bit it didn't. There were about six phones connected but not being used. They are just doing keepalives for regisration, etc to the main server, which is indicated in the access list below. Any ideas? Thank you,
Serial0/1/0 is up, line protocol is up
Hardware is GT96K with integrated T1 CSU/DSU
Internet address is x.x.x.x/30
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
reliability 255/255, txload 218/255, rxload 19/255
router#sh policy-map interface serial 0/1/0
Serial0/1/0
Service-policy output: VOIPpm
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: VOIPcm (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group 156
Priority: 33% (509 kbps), burst bytes 12700, b/w exceed drops: 0
Class-map: class-default (match-any)
898811 packets, 199817314 bytes
5 minute offered rate 23000 bps, drop rate 3000 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops/flowdrops) 0/81175/0/81175
(pkts output/bytes output) 824273/184794616
Fair-queue: per-flow queue limit 16
router#
CONFIG:
access-list 156 permit ip any host 66.x.x.x.x
class-map match-all VOIPcm
match access-group 156
policy-map VOIPpm
class VOIPcm
priority percent 33
class class-default
fair-queue
interface Serial0/1/0
ip address 150.150.150.150 255.255.255.252
ip access-group 101 in
ip flow ingress
ip flow egress
ip nat outside
ip inspect ISP2-cbac out
ip virtual-reassembly
encapsulation ppp
crypto map vpnmap
service-policy output VOIPpm
end
crypto map vpnmap 21 ipsec-isakmp
set peer x.x.x.x
set transform-set vpn_set
match address 121
crypto map vpnmap 32 ipsec-isakmp
set peer x.x.x.x
set transform-set vpn_set
match address 132
access-list 121 permit gre host 150.150.150.150 host 67.x.x.x.
access-list 132 permit gre host 150.150.150.150 host 57.x.x.x.x
04-05-2013 07:01 AM
Anyone? Any ideas? Keep in mind that I am trying to make the QoS policy work on traffic that is NOT going over the tunnel. This is voip traffic going to my provider. I tried using the qos-preclassify command at the crypto map level and the tunnel interface and then did huge transfers from branch to branch just to saturate my T-1 and it did, but the policy never reserved/prioritized my voip traffic
Serial0/1/0 is up, line protocol is up
Hardware is GT96K with integrated T1 CSU/DSU
Internet address is x.x.x.x/30
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
reliability 255/255, txload 231/255, rxload 16/255
erial0/1/0
Service-policy output: VOIPpm
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: VOIPcm (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group 156
Priority: 33% (509 kbps), burst bytes 12700, b/w exceed drops: 0
Class-map: class-default (match-any)
1437759 packets, 848687414 bytes
From my research, it looks like the qos-preclassify command only affects traffic going over the tunnel.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide