Rate-limiting & frame-relay...

[abatson]

My network was at the margin before, but I think more and more of my traffic is above the configured PVC bandwidth, and is being flagged as discard-eligable. Later today, I'll be in touch with AT&T for some testing, so I don't have hard numbers yet.

Question: Can I use the rate-limit command to ensure my router never sends more than 192Kbit/sec worth of traffic onto my ckt? My port size is 384K and PVC is 192K. This sort of restriction won't have any ill affects, but I just don't want any packets being flagged as discard-eligable in the frame-relay cloud.

Can I ommit the burst-rate numbers, and just tell the interface to never send traffic faster than 192Kbit/sec?

I'm at a customer's site today, and need to know this quickly. I can always come back though :-)

[Joseph W. Doherty]

Could you post the stats you're looking at, and the numbers you're concerned with. Want to make sure we're looking at the right numbers.

PS:

fyi: Just leaving, so likely be unable to respond before tonight.

[abatson]

Working night-shift on the West coast I see? :-)

Anyway, when I do a "show int s0/0/0", I get the following line:

Input queue: 30/75/187/0 (size/max/drops/flushes) ; Total output drops: 5045

During periods where the router is handling alot of traffic (close to port-speed), this number counts up by about 500 every 5 seconds or so. --It calms down when the traffic goes down.

I'll have to check this, but I think I'm process-switching my multicast traffic (a bad thing...) The router's CPU is 2-4% all the time (it's a 2610 router from 1999) that would drive up the CPU a bit, and cause the queues to stay more full then they have to be.

[Joseph W. Doherty]

"number counts up by about 500 every 5 seconds or so" -- if you mean the output drop counter, drops are often to be expected when you path doesn't support the sender's bandwidth. (Quite common LAN to WAN.)

TCP uses drops to self regulate its speed, so TCP drops alone aren't bad although too high a percentage can be. (I recall a rule of thumb that up to 1 or 2% is okay; don't hold me to it.)

Non-TCP traffic usually doesn't self regulate and there drops just indicate insufficient bandwidth. How bad the drops impacts the non-TCP traffic depends on the non-TCP app.

Input queue: 30/75/187/0 (size/max/drops/flushes) - don't often see packets queued on the input size; only 187 drops though. A couple of links for troubleshooting this issue are: http://www.cisco.com/en/US/products/hw/routers/ps133/products_tech_note09186a0080094791.shtml#topic2 and http://www.cisco.com/en/US/products/hw/modules/ps2643/products_tech_note09186a0080094a8c.shtml

I'm surprised that you're seeing such input queue stats with such a low CPU usage.

Since you're also doing multicast, you might insure fast switching for it hasn't been disabled. Check for no ip mroute-cache commands.

[abatson]

just to state the statistics I'm seeing, which make me think I'm having problems, here they are. They *all* count up by leaps and bounds together. When traffic calms down, they stop counting up:

After issuing, "show int s0/2"

Input queue: 1/75/0/0 (size/max/drops/flushes); Total output drops: 5609

After issuing, "show frame pvc" in Alaska:

out pkts dropped: 1016

out bytes dropped: 256,990

After issuing "show frame pvc" in Baltimore:

in DE pkts: 5708

[Joseph W. Doherty]

From reading your prior information, you might be working under some misunderstandings.

The drop counts you're seeing registered on the routers are local to the routers and have nothing to do with drops within the frame-relay cloud. You will see output drops if you overflow the router's queues.

Drops within the cloud are not directly visible to your routers. You can infer them by "in" packet count on far side should match "out" packet count on near side for same time interval. Local "Out" minus far "In" equals cloud path drops.

On your routers, you might see additional (and counted) drops as you shape bandwidth because you've reduced the bandwidth, or not. The latter because the shaper might change the default's queue size or queuing strategy.

Multicast is more likely to cause a bigger jump in drops, with bandwidth reduction, because it doesn't normally respond to backing off its transmit rate when there's drops; as TCP should.

With traffic shaping set to your CIR, you should not see any DE marked frames. If you do, either shaper's parameters don't agree with the provider's, or CIR is incorrectly configured on DLCI by provider (rare, but does happen). (If few, often not worth the time to resolve.)

As you correctly note, DE packets are the first candidates for discard, within the frame-relay cloud, if there's congestion. At CIR, none of your packets should be dropped within the frame-relay cloud (providers can though, but then it's time to see what your SLA really provides). Also, when there's congestion, frame-relay starts marking FECNs, which if you reflect as BECNs, allows some shapers to dynamically decrease transmission speed. (I.e. initially transmit at port speed, if BECNs, back speed off to CIR.)

[abatson]

Given the following conditions / requirements, can someone write me traffic-shaping command I'd need, to accomplish it?

1.) My CIR is 192K, and port is 384K

2.) I'd like to always send data at 192K, but never burst above ~300K

3.) Don't ever send data any slower than 192K (paying attention to mincir value...)

4.) I'd like the traffic-shaping to pay attention to, and respond to BECNs and FECNs. When encountering congestion, back down to the CIR (192K) and no lower. Never burst above 300K.

5.) In order the hold the packets that can't be put on the wire, should I increase the hold-queue from its default of 75, to maybe 150 or so? What's the best value here?

6.) Will Multicast traffic fare well with this setup. I realize that if multicast can't throttle its rate, then traffic-shaping can't do much, and I'm looking at a bandwidth upgrade...

[Mohamed Sobair]

Hi,

Configuration as follows:-

map class frame-relay (X)

frame relay cir 192000

frame relay micir 192000

frame relay bc 108000

frame relay holdqueu (maximum number)

fram relay adaptive shaping becn

fram relay fecn adapt

int Serialx

frame relay traffic shaping

fram relay class x

Try the above config,

HTH

Mohamed

[abatson]

I'll give the suggested config a try. Thanks!

[Mohamed Sobair]

Hi,

As Edison stated on the previous post, you can implement traffic shaping at you end points to shape your frames at the 192Kbps.

One point to add that, ensure that your (mincir) is equal to your (CIR), the frame relay switch will mark any frames above mincir as discard elegible (DE) at the frame header, but it wont be dropped unless there is a congestion on the Frame relay cloud (SP experience congestion). by making mincir equals to your cir , you will ensure that your frames within 192kb speed is not dropped.

Note: Mincir defaults to half value of the CIR.

HTH

Mohamed

[Mohamed Sobair]

Hi,

How could you burst above your CIR value?

Pls double check these values..

HTH

Mohamed

[abatson]

CIR is 192K. "Port Speed" is 384K. I'm garunteed the CIR, but can burst up to port speed, depending on network congestion.