04-23-2008 10:58 AM
We use gre over ipsec, to connect multiple sites to our core. Many of the site have different BW based on remote site carrier limitations. The BW of some are symetrical, some are DSL.
I have started deploying VOIP at some of these sites, and have begun playing with QOS. I only want to insure voice traffic, and control are passed accordingly, all other traffic can fall into default queue during times of high link usage.
For the remote sites, I have settled on the below config:
class-map match-any AutoQoS-VoIP-RTP-Trust
match ip dscp ef
class-map match-any AutoQoS-VoIP-Control-Trust
match ip dscp cs3
match ip dscp af31
!
policy-map AutoQoS-Policy-Trust
class AutoQoS-VoIP-RTP-Trust
priority percent 70
class AutoQoS-VoIP-Control-Trust
bandwidth percent 5
class class-default
fair-queue
!
interface Tunnel17
bandwidth 5000
ip address 192.168.1.66 255.255.255.252
ip mtu 1500
ip tcp adjust-mss 1436
qos pre-classify
keepalive 10 3
tunnel source x.x.x.x
tunnel destination x.x.x.x
!
interface GigabitEthernet0/0
bandwidth 5000
ip address x.x.x.x 255.255.255.240
service-policy output AutoQoS-Policy-Trust
(only the part of the config related to QOS is included to protect the innocent!)
My question is, how do I apply a similiar config at the core end, where I have multiple GRE interfaces, with different corresponding bandwidths? I tried to apply the service-policy to the tunnel interface, but it does not accept the command because of the queuing type.
Thanks in advance.
04-24-2008 05:56 AM
Hi
I will try to get this out of my brain, I did this config a couple of years ago but just now can't find the config, it can be some errors, but it will be something like this.
access-list extended siteA permit gre host 192.168.1.65 host 192.168.1.66
access-list extended siteB permit gre host 192.168.1.61 host 192.168.1.62
access-list extended siteC permit gre host 192.168.1.57 host 192.168.1.58
class-map siteA-class
match address siteA
class-map siteB-class
match address siteB
class-map siteC-class
match address siteC
policy-map Shaper
class siteA-class
shape average 1000000
service-policy AutoQoS-Policy-Trust
class siteB-class
shape average 2000000
service-policy AutoQoS-Policy-Trust
class siteC-class
shape average 5000000
service-policy AutoQoS-Policy-Trust
interface GigabitEthernet0/0
service-policy output Shaper
This way siteA will be shaped to 1M and in case of more traffic than 1M your already configured map will kick in.
siteB will get 2M and siteC 5M
/Mikael
04-24-2008 05:58 AM
Let me give this a shot, will let you know the results, thanks much.
04-24-2008 09:55 AM
One quick question, considering the inability of carriers to always deliver the "guaranteed" BW on a far end ckt, should I consider reducing the shape average figure to a smaller number than the "guaranteed BW? For instance, paying for a 5MB up/down link at the remote site end (I have a 200MB link on my end, that is not over subscribed, so no issues on my core end), should I reduce the shaper to 4MB to kick in qos a bit earlier just to be safe, or will that cause issues I am not aware of?
04-24-2008 10:36 AM
Another update, I have applied the follwoing config to my core ipsec router, on which 2 of the 19 gre tunnels have a VOIP solution at the far end. I am not seeing matches to the associated access lists, should I only see matches when the limit hits the shaper figure in the policy map?
class-map match-all hmh-class
match access-group name hmh-qos
!
class-map match-all hampwellness-class
match access-group name hampwellness-qos
!
class-map match-any AutoQoS-VoIP-RTP-Trust
match ip dscp ef
!
class-map match-any AutoQoS-VoIP-Control-Trust
match ip dscp cs3
match ip dscp af31
!
policy-map AutoQoS-Policy-Trust
class AutoQoS-VoIP-RTP-Trust
priority percent 70
class AutoQoS-VoIP-Control-Trust
bandwidth percent 5
class class-default
fair-queue
!
policy-map qos-shaper
class hmh-class
shape average 4000000
service-policy AutoQoS-Policy-Trust
class hampwellness-class
shape average 4000000
service-policy AutoQoS-Policy-Trust
!
interface GigabitEthernet0/1
service-policy output qos-shaper
!
ip access-list extended hampwellness-qos
permit gre host 192.168.1.69 host 192.168.1.70
ip access-list extended hmh-qos
permit gre host 192.168.1.65 host 192.168.1.66
!
interface Tunnel10
description GRE to Hampshire Wellness Center
bandwidth 5000
ip address 192.168.1.69 255.255.255.252
ip mtu 1500
ip tcp adjust-mss 1436
load-interval 30
qos pre-classify
keepalive 10 3
tunnel source x.x.x.x
tunnel destination x.x.x.x
!
interface Tunnel17
description GRE to Hampshire Memorial
bandwidth 5000
ip address 192.168.1.65 255.255.255.252
ip mtu 1500
ip tcp adjust-mss 1436
load-interval 30
qos pre-classify
keepalive 10 3
tunnel source x.x.x.x
tunnel destination x.x.x.x
!
04-27-2008 11:47 PM
Hi
For the question of bying more bandwidth then you use.
I think that that must be a question of how important is your traffic and how often does it happens. If the carrier doesn't have 5M to transmit under a short time, and you under the same timeslot does not transmit full rate, then you will probably not recognise it as a problem.
If you decide to go for a lower shaper than then the actual speed, I can't see any drawbacks of that, other than a happy provider that can charge you for more than you use ;-)
I saw that you already have shaped to 4M at the 5M line, and that's very good. Because I forgot to tell you that the bandwidth you shape to is calculated without layer2-information, which is added to the bandwidth after shapers, so the bandwidth is actually a bit more than 4M.
Second question about matches on access-lists.
I think it's better to look at the policy-map instead, you can see offered rate and matches and drops there, use
show policy-map interface for a list of all interfaces, or
show policy-map interface gig0/1
/Mikael
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: