LLQ on Gre Tunnel Interface with Traffic Shaping

[bapi_italy]

I have the following requirement. My HQ Hub router has 20 Mbps of BW having several GRE tunnels to branches with 512 Kbps, for each branch except two  branches, having 2 Mbps of BW each. Some branches are using IP phones and also accessing critical resources from the HQ. Now, instead of applying the policy-map on the egress physical interface of the the HQ router, I have applied it on the tunnel interface with Nested QOS,( Parent and Child policy as per Cisco Documents). However, I am unsuccessful in limiting the email traffic through the tunnel to the branches, They consume the entire BW of the 512 tunnel. When I issue the command show policy-map interface tunnel x, I clearly see the email traffic  hitting  the class-map confiration, but I can not limit the email flow. I do not want to apply the policy-map command on the physical interface because all my tunnels are not using uniform BW of 512 Kbps.Can anybody share his experience.

[Joseph W. Doherty]

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

I've found shapers a bit "quirky" when supporting VoIP.  Some things that might help include insuring the shaper's Tc is 10ms or less, and often allowing for L2 overhead in your shaped for bandwidth (512 Kbps L2 isn't the same as 512 Kbps of L3).

If you post your policies (HQ and branch), I might be able to offer additional suggestions.  (Also note IOS version(s) being used.)

[bapi_italy]

Hi Joseph

Please find the configuration

!        

class-map match-all VOICE

match protocol rtp audio

class-map match-any LowPriority

match access-group name LowPriority-Traffic-ACL

match access-group name EMAIL-Traffic-LnG

!        

!        

policy-map TRAFFIC-SHAPING

class VOICE

    priority percent 15

class LowPriority

    bandwidth 96

policy-map WAN-EGRESS

class class-default

    shape average 512000

  service-policy TRAFFIC-SHAPING

interface Tunnel36

bandwidth 512

ip nbar protocol-discovery

service-policy output WAN-EGRESS

interface GigabitEthernet0/1

description 20 MB MPLS towards service provider

bandwidth 20000

ip nbar protocol-discovery

#show ip access-lists EMAIL-Traffic-LnG

Extended IP access list EMAIL-Traffic-LnG

    10 permit ip host 172.20.12.31 10.32.0.0 0.0.255.255 (6530 matches)

#show ip access-lists LowPriority-Traffic-ACL

Extended IP access list LowPriority-Traffic-ACL

    10 permit ip host 192.168.200.86 any (451939 matches)

    20 permit ip host 192.168.200.137 any (104342 matches)

    30 permit ip host 192.168.200.128 any (193038 matches)

#show policy-map interface tun 36

  Service-policy output: WAN-EGRESS

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

      1025886 packets, 193365310 bytes

      5 minute offered rate 90000 bps, drop rate 0 bps

      Match: any

      Queueing

      queue limit 64 packets

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

      (pkts output/bytes output) 1013777/196897525

      shape (average) cir 512000, bc 2048, be 2048

      target shape rate 512000

      Service-policy : TRAFFIC-SHAPING

        queue stats for all priority classes:

          queue limit 64 packets

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

          (pkts output/bytes output) 2424/228424

        Class-map: VOICE (match-all)

          2424 packets, 194488 bytes

          5 minute offered rate 0 bps, drop rate 0 bps

          Match: protocol rtp audio

          Priority: 15% (76 kbps), burst bytes 1900, b/w exceed drops: 0

        Class-map: LowPriority (match-any)

          194813 packets, 18812918 bytes

          5 minute offered rate 7000 bps, drop rate 0 bps

          Match: access-group name LowPriority-Traffic-ACL

            187868 packets, 14329125 bytes

            5 minute rate 0 bps

          Match: access-group name EMAIL-Traffic-LnG

            6945 packets, 4483793 bytes

            5 minute rate 7000 bps

          Queueing

          queue limit 64 packets

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

          (pkts output/bytes output) 194696/21361226

          bandwidth 96 kbps

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

          828649 packets, 174357904 bytes

          5 minute offered rate 76000 bps, drop rate 0 bps

          Match: any

          queue limit 64 packets

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

          (pkts output/bytes output) 816657/175307875

[bapi_italy]

Hi Joseph

I forgot to put the IOS version which is c3900-universalk9-mz.SPA.150-1.M1.bin in HQ. What I want is that during congestion or anytime, the email traffic or any other low priority traffic should not take more than 96 Kbps out of 512 and meanwhile, for voice, at present I have deployed only one phone for testing to consume only 76 Kbps including layer 2 and 3 payloads for a codec of G.729. As you can see from my previous post, I am able to capture the voice and low priority traffic in the service policy, however, the entire BW is consumed when the user starts to download email attachement from the branch over the WAN link. My question is whether  servie policy is  able to shape  the email traffic which enters the tunnel and gets encapsulated by GRE

Thanks

[Joseph W. Doherty]

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

The bandwidth statement provides a miminal bandwidth guarantee, not a maximum restriction.  If you want to restrict your low priority traffic, you migh try:

policy-map TRAFFIC-SHAPING

class VOICE

    priority percent 15

class LowPriority

    bandwidth 96

    police 96000

[bapi_italy]

Dear Joseph

Thanks a lot for your suggestion. I will apply it on monday and get back to you

[bapi_italy]

Dear Joseph

I would sincerely thank you very much for the above solution, it worked, however, I have the following doubts need to be clarified if you do not mind.

1. Since, traffic shaping is not possible on child policy under Parent Policy  applied on the tunnel interface,  therefore, we are  Policing. Now, while  policing, the excess traffic is dropped unlike traffic shaping where access traffic is buffered. Will the dropped packets be resent ? and I also see lot of output drops on the tunnel interface

2. I am lillte confused many a times with QOS, may be due to lack of understanding of the concept. As per my scenario, the branch users require to connect to citrix servers in the HQ for example, in this scenario should I apply QOS with some bandwidth allocation on the egress tunnel interface of the HQ Router 512 Kps link or also on the BR Router's either tunnel or physical interface with qos pre-classified confiured on the branch tunnel, as per my logic resources lie on the HQ so I may only need to apply the QOS on the HQ tunnel interface unless I have some voip traffic from both end.

[Joseph W. Doherty]

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

Will the dropped packets be resent ?

Depends on the nature of the traffic.  TCP should resend, others vary.

#2 Generally you want to apply QoS where there is likely to be congestion.  In your topology, most likely bottleneck is the branch link.  On the HQ side we shape to match the bandwidth only because we're unable to place QoS on provider's side of branch link.  On branch, assuming 512 is the physical bandwidth, we apply to physical interface.  If logical cap, we would need to shape there too.

Pre-classify is needed if we have QoS applied on physical interface, supporting tunneled traffic, which we want to "examine".

Since you now mention working with Citrix, for that traffic (especially for the screen scraping, subtype 1), for good performance, you often want to provide it better priority than normal traffic.

Here's a generic policy that works well if you direct traffic to the correct class.

policy-map Generic

class real-time

priority percent 30

class foreground

bandwidth remaining 81

fair-queue

class background

bandwidth remaining 1

fair-queue

class default

bandwidth remaining 9

fair-queue

In the above, you might place Citrix in "foreground" and email in "background".

The bandwidth percentages are chosen for scheduling priority, actual bandwidth usage should be the inverse.

[bapi_italy]

Thank you joseph

[bapi_italy]

Dear Joseph. I have another doubt to be cleared. Please look at this example below

Class-map   Priority-CM

match access group name Foreground-ACL

ip access-list extended Foreground-ACL

10 permit ip host 10.70.1.12 host 192.168.241.2

20 permit ip host 10.20.14.3 host 192.168.217.4

30 permit ip host 10.21.15.100 host 192.168.218.10

Policy-Map WAN-QOS

class Priority-CM

bandwidth percent 40

In the above ACL suppose I have a match for the line 10,20,30 then which line will execute first ? is it the line 10 first because it is matched first ? however, I want all the traffic matched in line 10,20 and 30 needs to be affected

[Joseph W. Doherty]

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

Each of your ACLs are against specific src/dest hosts.  Matching against one precludes matching against another.  Logically all three will be effective, and also logically, their sequence doesn't matter.  (Physically, there may better to sequence them in match count order.)

[bapi_italy]

In one of the tunnel interface, when I apply the QOS command it gives the following message.

MAIN-R1(config-if)#service-policy output WAN-QOS
Insufficient bandwidth 1024 kbps for bandwidth guarantee
please remove queuing feature from child policy first

I need the hierarchical policy for tunnel interface which is working fine for other tunnels in the same router

[Joseph W. Doherty]

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

The error message tells us that the device believe you're over allocating bandwidth.  As you didn't provide a complete posting of your configuration, difficult to be more helpful.