Cisco – How to fix real time congested network. (JITTER)

To answer your questions:

• RDP traffic should get up to the 25% of the remaining bandwidth. Where the already reserved bandwidth is the 35% ( class-default gets 25% by default and EF get 10% ). So, if i'm right, you assigned ~665Kbps to RDP. Anyway you should check if you're dropping packets issuing the command below:

show policy-map <your wan interface> output class REMOTEDESKTOP

and checking for dropped packets.

• Cisco assign a queue to each user-defined class that includes the bandwidth or police commands. To make a long-story simple those commands define the amount of bandwidth assigned to every queue during congestions.

• In theory every TCP based stream should be OK with drops. In practice some of them aren't. Dropping precedence bits tell the routers what packets should be dropped, within a given class, before congestion happens. Since RDP is the only type of traffic defined in your REMOTEDESKTOP class, you should not worry about it.

• Bandwidth percentage are not in order ( as Jeremy stated ).

That said, there are a lot of things that i would change in your configuration:

• There are no matches between some of classes of the setTos and the useTos policy-map. For instance the one named AF-HIGH is processing no packets since no class in setTos sets DSCP to AF41.

• BE class in setTos is somehow self-defeating since it makes the class-default class useless. Note that class-default is the only system-defined class and get the 25% of the bandwidth by default ( 100 - max-reserved-bandwidth ) .

• bandwidth remaining percent is not the best options ( as Jeremy explained ). I would change it to bandwidth percent.

• I would prefer to mark EF packets by myself and not to rely on the phones' settings.

There are a number of possibilities here, not limited to, but including:

1. The CPE's CPU is maxing out. (CPE=Customer Premesis Device)

   Check the specifications for the router you are using to make sure it can support the level of traffic you're trying to push. Try and graph the CPE's CPU if you are unsure.

2. Bufferbloat in your ISP

   If your ISP has configured traffic shaping for DSL tails (to avoid tail dropping packets) - they may have configured their buffer size too large. A good way to tell is by maxing out your connection in the downstream (download) direction. If your latency goes up by 200ms or more, this is probably a problem with your ISP's shaping configuration for DSL tails, and you should complain. They should reduce their buffer depth.

   I'd suggest >50ms of buffer is harmful.

3. The upstream of your xDSL is being maxed out.

   Remember on most DSL technologies, bandwidth is asymmetric. Thus it takes a much smaller amount of traffic to congest the upstream (upload) on most DSL technologies than the downstream. Make sure you aren't congesting upstream.

4. Remember tools that graph links are usually averaging samples.

   Tools like rrdtool (and cacti and NMIS and...) are usually showing you a 5-minute sample average of your links. This makes them poor for identifying situations where a user congests a link for 10 seconds or so. That'll just appear as a small bump on a 5-minute-sampled graph. Look for tools which can give you a 'high water mark' of the link as well as a rolling average.