QOS over multiple GREs with different BW's from core perspective

[gerheauserm]

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.

[mlund]

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

[gerheauserm]

Let me give this a shot, will let you know the results, thanks much.

[gerheauserm]

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?

[gerheauserm]

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

!

[mlund]

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