using QoS to control traffic over gre tunnel

[yeow28]

my user have an application server that is resided in my data centre.

this server is used to push data/content to windows client machine.

my site router for ipvpn gre tunnel have a 20Mb bandwidth circuit.

every time the user start publishing his content to the clients at the sites machines, the 20Mb link get congested, affecting other traffic like inhouse application and web traffic.

the application uses port http, https, tcp 555111 and tcp 55513.

how can i control the traffic to around 75%-80% to prevent the link from getting congested. 

i have around 11 sites, all have 20Mb circuit for ipvpn. all except 1 uses cisco 1941 router. 

[Georg Pauwen]

Hello,

the below should work. Make sure you configure 'qos pre-classify' on the tunnel. This example polices traffic from the server with IP address 192.168.1.1 to host 10.10.10.1. The policed limit is 16MB:

access-list 101 permit tcp host 192.168.1.1 host 10.10.10.1 eq 55511
access-list 101 permit tcp host 192.168.1.1 host 10.10.10.1 eq 55513
access-list 101 permit tcp host 192.168.1.1 host 10.10.10.1 eq 80
access-list 101 permit tcp host 192.168.1.1 host 10.10.10.1 eq 443

class-map match-all POLICE_PUSH
 match access-group 101

policy-map POLICE_16MB
 class POLICE_PUSH
  police cir 16000000
  conform-action transmit
  exceed-action drop
 class class-default
  fair-queue

int tunnel0
 service-policy output POLICE_16MB
 qos pre-classify

[Joseph W. Doherty]

BTW, you only need qos pre-classify if you need to "see" a copy of the pre-encapsulate packet's header at the physical interface the tunnel is using for egress.

[yeow28]

do i configure it on the site router or my core router at data centre?

[Joseph W. Doherty]

Do you have an IP for the server that pushes data/content?  Does it otherwise "talk" to your remote hosts?  If answers are yes, and no, you should be able to just match on the server's source IP.

What Georg shows will work, but I suggest using shaping and a hierarchal policy that gives little priority to the push traffic.  This will help insure a push has very little impact on your other traffic but will also allow it to use all "available/excess" bandwidth.

For example:

pollicy-map ParentShaper
 class class-default
  shape average 20000000
  service-policy Child

policy-map Child
 class fromPushServer
  banwidth remainig percent 1
 class class-default
  bandidth remaining percent 99
  fair-queue

int tunnel #
 service-policy output ParentShaper

[yeow28]

i do have the server ip addres.

it push content to clients on different subnets

each subnet have a number of clients getting the content from the server.

ranging from 10 to 20++

[Joseph W. Doherty]

Having multiple remote subnets doesn't matter.  As long as you get the client update traffic into its assigned queue, you'll avoid that traffic being adverse to other network traffic.

Something we haven't addressed is return traffic for the client updates.  If you have enough site clients that are having traffic pushed to them, and they do something like a TCP ACK, enough of that could be adverse to the remote to hub traffic.  If it is, you could implement QoS on the remote side too.