Frame relay traffic shaping

[bsternfield]

I have the following frame relay setup:

Corporate hub, with a 2811 router and a full T1 w/4 PVCs configured on the interface.

Four remote sites with 1700 routers and full T1s at each site. Traffic is very light at these sites--they're small offices with a couple of PCs; two of the offices have about a dozen PCs and one Windows server doing active directory replication, DNS, etc.

I'm trying to configure traffic shaping on the routers and have a couple of questions.

Since the bandwidth is identical at all sites, I assume I should set mincir to 768000 on each interface. With this configuration, isn't it still possible for the interface on the hub router to be overrun?

Since the cir and bandwidth on each interface are identical, should be=0?

Eventually, we'll want to run VoIP over these connections--again, pretty light traffic, with only about 2-8 phones at each site. Should QoS be implemented separately from traffic shaping, or is there a better way to set this up?

Thanks.

[scottmac]

Since it sounds like your CIR equals your port speed / access rate, I don't think traffic shaping would do anything for you. There is no need to pace traffic, since you can't violate CIR (there is no "burst").

You may want instead to implement "Dynamic" traffic shaping - when the router sees a FECN or BECN (an indication of congestion in the path) it will drop the rate temporarily.

I'm not even sure that will help you, since your frames shouldn't be tagged with a "Discard Eligible," because you can never exceed CIR.

As long as each endpoint is running @ full T1 speeds, with T1 CIR, your traffic should be guaranteed to the level of your SLA, even without traffic shaping.

Good Luck

Scott

[zakymar77]

I think there's a bandwidth allocation adjustment needed.I assume that major application is accessed on corporate hub with T1.You have four remote site with T1.For example that during normal operation, each of your remote site will use only 512kbps to access corporate hub,you can see that your four remote sites has consumed the bandwidth on your corporate hub (4 * 512kbps=2048kbps).The bandwidth of your corporate hub is equal to the sum of your remote sites so that whatever amount of traffic on one site can not oversubcribed the whole/other site.You can apply traffic shaping so not to oversubscribe T1 of your corporate hub at any time..Hope it helps.

[bsternfield]

Right--the remote sites are accessing a client/server database app at the corporate site . So while the hub can't overload a remote site because they're both full T1, my concern was that the remote sites could theoretically overload the hub site.

So what should the configuration be to prevent this? Should mincir be set at each remote site to a level that could never overload the hub (mincir = 1540000/# of remote sites)? I assume mincir is reached only when becn frames are received (when there's congestion), otherwise full bandwidth is available.

[scottmac]

If your server is Fast Ethernet connected to your 2811, there is _no way_ that four T1s inbound could swamp the router.

You could enable the Firewall, IDS/IPS, and (probably) VoIP on that router concurrently and still take input from four T1s and still not come close to swamping the router. It has considerable processing power for its size.

Setting dynamic traffic shaping will probably be of no benefit - all of your frames are below CIR (access rate & CIR both = T1). Your frames should never be tagged with DE, so your frames are never a candidate for being dropped (or at least dropped as part of a policing action).

Anyone else that happens to be passing traffic on that physical pipe that is operating at or above Bc (and/or Be) that has DE set would be the candidate for losing the frame.

You paid for all that bandwidth, the full pipe is your CIR ... the carrier (usually) has to pass your traffic according to the SLA .... which means "anything under CIR bandwidth is subject to the SLA" - your traffic will pass. Anything above CIR (impossible in your case) is subject to DE and policing.

Good Luck

Scott

[bsternfield]

What I was concerned about was that if traffic across each of the remote PVCs used all of the bandwidth on each T, then the hub router, which has a single T, could be overrun. Or am I misunderstanding something?

[mheusinger]

Hi, I would implement traffic shaping at the remote sites with a nested policy. The advantage is, that you still have the possibility to give bandwidth to your important applications. F.e. someone sending a large email it should not interfere with your database, citrix, etc. traffic.

It could look like this:

class match-any Important

match protocol citrix

match protocol sqlnet

policy-map PrioApp

class Important

bandwidth percent 90

class class-default

fair-queue

random-detect

policy-map Shape500

class class-default

shape average 500000

service-policy output PrioApp

interface Serial0.100

frame-relay interface-dlci 100

class FRclass

map-class frame-relay FRclass

frame-relay cir 500

service-policy output Shape500

You can also omit the service-policy PrioApp in case you do not give priority to any application.

The 500 kbps is overbooking your central T1 to some extent. The idea is that it is unlikely that all 4 T1 in the remote sites will send simultaneously. In case you want to be absolutely sure reduce this to 380 kbps, which would always ensure no overloaded T1.

Hope this helps! Please rate all posts.

Regards, Martin

[bsternfield]

So, if I understand this correctly, since I'm not interested in classifying traffic on an application basis then this is my configuration for the remote routers:

policy-map Shape500

class class-default

shape average 500000

interface Serial0.100

frame-relay interface-dlci 100

class FRclass

map-class frame-relay FRclass

frame-relay cir 500

service-policy output Shape500

Doesn't this limit traffic to 500kbps at all times? If so, would it be better to use adaptive shaping?

[mheusinger]

Hi,

you could try frame-relay adaptive shaping. The prerequisite is however, that the FR switch sends FECN/BECN and your routers are configured to create a BECN, when a FECN is received. In other words: FR adaptive traffic shaping depends on your FR provider equipment and its configuration as well as your FR router and its configuration.

If all of them do report congestion correctly it could work.

One problem though: the FR provider can not prioritize your VoIP traffic on the interface to your router because a FR switch can not detect different applications inside FR. The general recommendation with VoIP over FR is: avoid congestion at all.

Hope this helps! Please rate all posts.

Regards, Martin

[bsternfield]

When I do a show frame relay pvc x I see FECN and BECN packets, so it looks like the provider is sending them. I'll try adaptive shaping and see what happens.

Thanks.