bandwidth restriction

[Anukalp S]

Hi.

i am looking for applying bandwidth restriction on tunnel interface. I have two location,  in one location servers are running and users are sitting on another locations to access servers. I have 20mb MPLS circuit on both locations and configured GRE tunnel over MPLS.

Now i want to assign 10mb bandwidth to mail (SMTP traffic) server and rest for others(default).

Pls do help me how could i do this on tunnel interface.

[Akash Agrawal]

Hi,

You may have already gone through this link but if not FYR. Try to apply CBWFQ on tunnel interface. Create class to match SMTP traffic and do bandwidth allocation. Since on tunnel interface, traffic would be encapsulated with GRE header, to match traffic based on IP header configure "qos pre-classify" on tunnel interface.

http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-policing/10106-qos-tunnel.html

--Pls dont forget to rate helpful posts--

Regards,

Akash

[Anukalp S]

Hi Akash..

Thanks for sharing this info, could you pls confirm also, should i need to apply QoS on both end tunnel interfaces or only tunnel interface at user end.

Since i am running OSPF on tunnel interfaces and configured bandwidth for path preference so will it make impact on any kind of QoS setup.

and my configuration should be like below--correct ?? pls review.

class-map match-any tcp

match protocol smtp

policy-map child
class tcp
  bandwdth 10000

policy-map tunnel
class class-default
  shape average 20000000
  service-policy child

interface tunnel0
 service-policy tunnel out

qos pre-classify

[Akash Agrawal]

Hi,

I have not any practical experience with QOS on GRE tunnel. But i think applying on tunnel interface should be sufficient. 

Configuration looks ok. Instead of matching SMTP traffic using NBAR, you can also go for ACL with matching SMTP port (port 25). You can refer below discussion for NBAR vs ACL option.

https://supportforums.cisco.com/discussion/10559521/how-limit-smtp-traffic-trough-router

Yes, policy-map needs to be applied on both direction.

Regards,

Akash

[Anukalp S]

Hi Aksah.. both direction means on both locations router tunnel interfaces in out direction.??

pls clarify.

[Akash Agrawal]

Yes. Say suppose topology is Router-A -------GRE tunnel -------Router-B. We have to apply shaping on outbound direction on tunnel on both routers. Shaping applied on router-A will limit traffic from rtr-A to rtr-B, similarly we need to limit traffic from rtr-B to rtr-A.

[Anukalp S]

  Hi Akash, its really very helpful but i have a bit confusion that what ACL i need to place for class map on server end.

on users location it shoule be like below--

access-list class_smtp extended per tcp any any eq smtp

but on server side how it would be.??

Also is it not possible to limit bandwidth on server side only, will this not going to work.

[Anukalp S]

Sorry , ACL should be like below on users side location..

access-list 120 permit tcp any any eq smtp.

could you pls advice ACL configuration on server side..??

[Akash Agrawal]

User side : Traffic destined to port 25 (SMTP)

access-list 120 permit tcp any any eq smtp.

Server side: Traffic is sourced from port 25 (SMTP)

access-list 120 permit tcp any eq smtp any

-- Pls dont forget to rate helpful posts --

Regards,

Akash

[Anukalp S]

Thanks much Akash..

Actually  users sitting on hub location where we have 40mb MPLS and here router has tunnel inerfaces for another different locations also along with this server locations. Server location has 20mb MPLS through GRE tunnel is setup.

I am looking to configure  badwidth limitation on only server side tunnel interface to have SMTP traffic assigned to 10mb.

Can this method limit SMTP traffic on server side tunnel  interface and ACL to match traffic would be same as you mentioned above.

Also could you pls confirm that above configuration would match criteria that if bandwidth is free for class SMTP then class-default will get available bandwidh from class SMTP. On the other hand i want 10mb bandwidth assigned for SMTP traffic and if bandwidth get full for this class packets should get start dropping instead of starving bandwidth of class default.

Pls help.

[Akash Agrawal]

Yes, i guess inter cos bursting should be allowed on the router. So if SMTP class is not utilizing its complete bandwidth, class-default can utilize remaining bandwidth. 

Bandwidth allocation does not do any rate-limit but just decide which packet to be sent first at time of congestion. If there is no congestion, queuing does not come in to picture. If you have any doubt, you can safely deploy service-policy on production router. We are doing any policing just bandwidth allocation. 

matching traffic through class-map will be same as mentioned above.

[Anukalp S]

Hi Akash ..Thanks again.. But here my scenaio is different.

Actually at server side location SMTP traffic is occupying whole bandwidth to 20mb which is causing other applications issue. So want to allocate 10mb to SMTP traffic so that this traffic could not occupy all bandwidh.

I guess we need to police here. What you suggest.

[Akash Agrawal]

policing is not required. Bandwidth allocation should be sufficient. Try with BW allocation and share result

[Anukalp S]

Thanks Akash.. I will be setting up bandwidh allocation on server side only , not on user side and will see result. I am using below ACL on server side.

access-list 120 permit tcp any eq smtp any

[Anukalp S]

Hi Akash,

I applied policy map on tunnel inteface on server side but i am not see packets getting match. I also applied preclassify on it also.

 Service-policy output: police

    Class-map: class-default (match-any)
      172453 packets, 46115738 bytes
      5 minute offered rate 950000 bps, drop rate 0 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 172043/48898022
      shape (average) cir 20000000, bc 80000, be 80000
      target shape rate 20000000

      Service-policy : police-smtp

        Class-map: smtp (match-all)
          0 packets, 0 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: access-group 120
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0
          bandwidth 15000 kbps

        Class-map: class-default (match-any)
          172453 packets, 46115738 bytes
          5 minute offered rate 950000 bps, drop rate 0 bps
          Match: any

          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 172043/48898022