Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Anyone implementing QoS on a 1710?

Status
Not open for further replies.

hunterdw

Technical User
Joined
Oct 25, 2002
Messages
345
Location
US
I'm having a weird issue with QoS on a 1710 VPN router.

I create the following

class-map match-any voice
match ip dscp ef
match ip precedence 5
class-map match-any sig
match ip precedence 3
match ip dscp af31
match ip dscp cs3

policy-map voip
class voice
priority percent 30
class sig
bandwidth percent 5
class class-default
fair-queue

Then apply the policy map to the EXTERNAL interface of the 1710... eth0

conf t
int eth0
service-policy output voip

When I make phone calls across the 1710, I want to make sure the packets are marked and being handled correctly when the link becomes saturated.

I look at "show policy-map int eth0" and my RTP traffic (voice above) increments. My Control traffic (sig above) does not.

Strange.

So, for fun, I apply the policy-map to my INSIDE interface to watch the packets...

they BOTH increment correctly

looks like something is lost in translation.

I've tried every 1710 IOS that exists on the 12.2, 12.3 and 12.4 trains. No difference.

Any ideas what I'm missing?
 
I should add... the same config works just fine on a 1760V router with the VPN module. No change in class-map, policy-map or service-policy...

What's so different between how the 1760V and 1710 handles QoS?
 
Post your whole config.
 
Current configuration : 4672 bytes
!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname CEN-COX-1710
!
boot-start-marker
boot-end-marker
!
logging buffered 4096 critical
enable secret 5 **
!
no aaa new-model
!
resource policy
!
memory-size iomem 25
clock timezone CST -6
clock summer-time CDT recurring
ip subnet-zero
!
!
no ip dhcp use vrf connected
no ip dhcp conflict logging
!
!
ip tcp synwait-time 5
ip cef
no ip domain lookup
no ip ips deny-action ips-interface
!
no ftp-server write-enable
!
!
!
class-map match-any voice
match ip dscp ef
match ip precedence 5
class-map match-any sig
match ip precedence 3
match ip dscp af31
match ip dscp cs3
!
policy-map voip
class voice
priority percent 30
class sig
bandwidth percent 5
class class-default
fair-queue
!
!
crypto isakmp policy 21
encr 3des
authentication pre-share
group 2
crypto isakmp key ocsic address *
!
!
crypto ipsec transform-set red esp-3des esp-sha-hmac
crypto ipsec transform-set blue esp-3des esp-md5-hmac
mode transport
!
crypto map map 60 ipsec-isakmp
set peer *
set transform-set blue
match address 161
qos pre-classify
!
!
!
interface Ethernet0
description Outside VPN Interface
ip address * 255.255.255.224
half-duplex
crypto map map
service-policy output voip
!
interface FastEthernet0
description Inside VPN Interface
ip address 192.168.1.19 255.255.255.0
speed 100
full-duplex
!
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.1.254
ip route * 255.255.255.255 *
ip route 172.16.6.0 255.255.255.0 *
ip route 172.18.6.0 255.255.255.0 *
ip route 192.168.6.0 255.255.255.0 *
no ip http server
no ip http secure-server
!
access-list 161 permit gre host * host *
access-list 161 permit ip any 192.168.6.0 0.0.0.255
access-list 161 permit ip any 172.16.6.0 0.0.0.255
access-list 161 permit ip any 172.18.6.0 0.0.0.255
snmp-server community public RO
!
!
control-plane
!
!
line con 0
password 7 *
logging synchronous
login
line aux 0
line vty 0 4
password 7 *
logging synchronous
login
line vty 5 15
password 7 *
logging synchronous
login
!
end

CEN-COX-1710#
CEN-COX-1710#show policy-map int eth0

Ethernet0

Service-policy output: voip

Class-map: voice (match-any)
99078 packets, 7331772 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp ef (46)
99078 packets, 7331772 bytes
5 minute rate 0 bps
Match: ip precedence 5
0 packets, 0 bytes
5 minute rate 0 bps
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 30 (%)
Bandwidth 4200 (kbps) Burst 105000 (Bytes)
(pkts matched/bytes matched) 8/1008
(total drops/bytes drops) 0/0

Class-map: sog (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp cs3 (24)
0 packets, 0 bytes
5 minute rate 0 bps
Match: ip dscp af31 (26)
0 packets, 0 bytes
5 minute rate 0 bps
Match: ip precedence 3
0 packets, 0 bytes
5 minute rate 0 bps
Queueing
Output Queue: Conversation 265
Bandwidth 5 (%)
Bandwidth 300 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0

Class-map: class-default (match-any)
586166 packets, 189218971 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 256
(total queued/total drops/no-buffer drops) 0/0/0
 
I don't see a lot wrong with what you're doing.

All I can recommend is you review the Big Toolkit on the CCO (you'll need a login). Failing that, log a TAC case perhaps.
 
I've logged a TAC case 10 days ago. I've gone through 4 engineers. No solution. It's not P1 - I'm not down... I won't cry wolf...

I need it solved though.

I've already searched the Bug Toolkit.

Oh well... I guess it's more reason to get rid of my 1710 routers for VPN...
 
Not really certain how you are connecting site to site. I see some statements in regards to GRE tunnels, but do not see any tunnels in your config.

The qos pre-classify statement does not need to be used if you tie the policy map to a GRE tunnel.

Create a GRE tunnel, take off the qos pre-classify from your crypto map, then apply the output policy on the GRE tunnel itself.

Give that a shot. That is, in essence, what I am doing and it works fine.
 
We connect via IPSec... see the crypto map section?

The GRE thing is because at one time I ran EIGRP across a different GRE tunnel. I no longer do that across this particular tunnel, but I haven't updated access-list 161 yet to get rid of the GRE stuff.

having the GRE statement in there has no effect.

--DW
 
Yes, I understand that. All I was recommending was to try the GRE tunnels, removing the qos pre-classify statements, and tying your policy maps to the GRE's.

It obviously looks like, for whatever reason, the qos pre-classify is not correctly "classifying" the traffic prior to encapsulation for the sig traffic only...though, as you have noted, it is odd that it sees the voice traffic correctly...you'd think that it would see them both the same, either working or not.

 
I agree. I wasn't trying to be snippy. The whole "tone over web posting" thing is horrible. :)

I also think it is odd. I saw your "sample" config on a different thread and I'll adapt accordingly and try it.

Thanks again. I'll report back with what I find

--DW
 
Well, CBWFG doesn't work on a tunnel0 interface.

So, looking at my class-map / policy-map above, how do you suggest I apply my service-policy to the GRE tunnel?

--DW
 
Simply turn off the qos pre-classify on the crypto map, then create your tunnels as noted in the config that I posted in the other thread.

Then simply tie the policy map to the tunnel with a service-policy output <policy-name> statement.

Easy as pie. :-)
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top