Prioritise rdp traffic

[pcromwell]

We have a 2900 router and currently has 10mb download limit. It is a remote site ( The MD's home)This has internet connection and also a site to site vpn. The VPN traffic is very light and is used for RDP sessions with the office. The problem we have is that every day at random intervals the connection is saturated and it appears to be coming form apple devices doing updates etc. this is getting in the way of RDP traffic. I assume the best thing to do is to prioritise the RDP packets? Or should I police all other traffic?

I have read similar posts, but what I don't understand is that the policy is applied outbound from router.

don't I need to prioritise both inbound and outbound on the routers external interface?

[Joseph W. Doherty]

What you need to do is have separate links for site-to-site VPN and general Internet traffic. Unless you can get your ISP to provide a QoS policy on their device to you (unlikely), you're going to find it very, very, very difficult to guarantee your RDP traffic the bandwidth it needs.

[pcromwell]

Is it not possible to rate limit all non RDP traffic from external
source to say 8mb?

[Joseph W. Doherty]

Yep, you can do that. Unfortunately, it often doesn't work too well.
First, an ingress rate limiter is on the downside of the potentially congested link. So, traffic that bursts above the configured limit will congest the link before it hits the rate limiter.
Second, traffic that's being rate limit needs to slow its transmission rate. Not all traffic does, and the traffic that does slow, often lags its slow down such that something like RDP is still impacted.
From experience I can tell you if you really, really slow the non-RDP traffic, often enough bandwidth is made available that RDP meets its service needs. (How much to slow? You might limit your non RDP traffic to 1 Mbps of the 10 Mbps and carefully adjust from there.)

[rasmus.elmholt]

Hi

You need to create a shaping policy for 10mbit, and then guarante bandwidth for the RDP session, using an ACL or NBAR. You can only shape outgoing, so do it on you WAN and LAN interface.
This is a crude mockup:
ip access-list extended MS-RDP-ACL
permit tcp any any eq 3389
permit udp any any eq 3389
permit udp any eq 3389 any
permit tcp any eq 3389 any
!
class-map match-all cmap-RDP
match access-group name MS-RDP-ACL
!
policy-map Gi0-IN
class cmap-RDP
bandwidth 5000
set dscp af21
policy-map g0-shaping
class class-default
shape average 10000000
service-policy Gi0-IN

Regards,
Rasmus

[Joseph W. Doherty]

Yea, unfortunately, you would want to apply a policy like this on the ISP's interface.
If you apply it on the OP's 2900 LAN interface, it will be even slower that a rate limit to control ingress bandwidth on the WAN interface.

[rasmus.elmholt]

Hi Joseph
Why would it be slower? Could you please explain?
You just need to make you shaper 2-5% lower than the shaper/policer at the ISP PE and OPs shaper will always be the one in control...

[Joseph W. Doherty]

Because a shaper buffers over rate, unlike a rate limiter which immediately drops. I.e. if your sender is relying on drops for it to slow down, a shaper will delay there being drops and hence delay the sender from slowing. (NB: some modern TCP stack will slow if they see an increase in latency, which often indicates queuing.)
As to control, yes if you were controlling egress traffic, but again, OP's issue is ingress Internet traffic. The problem is how to insure sufficient bandwidth to ingress RDP traffic when your control point is on the downstream end of the link you're trying to manage.

[pcromwell]

Thanks Joseph and Rasmus for your suggestions and thoughts. I might just give it a try and see how it works. will let you know how it goes