RED FRAMES / Traffic Shaping 2

[chagme]

I have a 384k Frame Relay with a PVC mapped to my ISP configured CIR 192 BC 192 BE 192

The ISP's Frame is a full T1.

Performance is poor, even at times when we know the network is not busy. Download tests often come in under 200k. I know it's not a capacity problem because my DSL link that is served by the same T1 often gets over 900k.

Techs at the telco (Verizon) are seeing RED FRAMES on the traffic from the T1 to our 384k and say this will result in poor performance. They say that traffic shaping should be done by the ISP on their T1.

Is it true that traffic shaping should be required in this case? If so, can somone suggest how it is done?
Thank you.

 

[svermill]

CIR is committed information rate
Bc is committed burst rate
be is excess burst rate

So you don't have a 384k frame circuit if those are your parameters (all 192k). Normally, you might see something like:

CIR: 128k
Bc: 256k
Be: 384k (normally limitted to the line rate of the physical connection)

Obviously, those are just to show the relationship sometimes seen between numbers. Your config could just as easily be:

CIR: 384k
Bc: 384k
Be: 384k

I have no idea what RED Frames are.

 

[chagme]

I know what the acronyms stand for and I assure you we do have a 384k Frame Circuit. There are only three levels you can get in the Northeast: 56k, 384k, and T1.

I have been told by the people at Verizon who are direclty involved with provisioning and configuring the PVC that they cannot give us 384,384,384 because if you have a BC of 384 and a BE of 384 you would be able to get 768k and that's not what we're contracting for with Verizon.

The ISP's frame port is discarding frames when sending to us. The Verizon techs call these Red Frames.

 

[jeter]

traffic shaping is required when
1. when a full T1 is connected to a lower remote speed 56k

2.When a network is constructed with many VC'sto different locations on a single physical line.

3.Network congestion

4.When you have several differnt types of traffic ( ip,ipx,SNA ).

What is the channel rate set to on your serial interface?
I work for a telco company and I have not heared of this so called RED frame error. We all now that a RED alarm is a problem on the far end....
Jeter@LasVegas.com
J.Fisher CCNA

 

[chagme]

The channel rate on the serial port of TSU serving the 384k is set to 6. As I understand it, we couldn't get *anything* if that weren't set right.

The T1 the 384k is mapped to is, in fact, serving quite a few PVCs.

The ISP's frame port is discarding frames when sending to us. The Verizon techs call these Red Frames.

 

[svermill]

You may very well know what the acronyms stand for, but do you really know how they function? I think you should sit down with your service provider and let them explain what they are selling to you. Clearly they are selling you a CIR of only 192k (that is why your download speed is "under 200k&quot. Your peak rate is calculated as CIR(1+Bc/Be). In your case, that obviously amounts to CIR(2). So you can burst to 384k in any Tc, but your COMMITTED information rate (read: over time) is still only 192k. Also, when your Bc matches your CIR, your Tc = 1. Since Tc =1, any burst above 192k in any single second will be marked as DE. Hence, your discarded frames. You are getting exactly what they set you up for. There is, technically, nothing wrong with your circuit.

All of this is fundamental to Frame Relay. If you just wanted raw fixed bandwidth you would have just bought dedicated point-to-point leased lines, right? Your discounted tarrif for FR reflects the fact that your data flow over time will/can not consistently equal the full line rate.

 

[svermill]

I should have mentioned that if you are only moving traffic between sites that you have control over, you can implement traffic shaping at the site where you are accessing data. In that way, the router at that site will be informed not to send data consistently at a rate above 192k towards your site that is suffering dropped frames. This prevents the whole issue of retransmissions due to dropped frames, but, of course, does nothing to directly improve your throughput. It is very easy to set up and I can post some links or commands if this applies to your situation (assuming your routers are Cisco and have current IOS).

 

[chagme]

1. We are sometimes getting over 200k. I've been on the the phone with Verizon several times on this, and they tell me the CIR, BC, BE is 192,192,192.

I did ask Verizon to set it to 384,384,384, but they refuse to do it because they -- the Verizon techs who program the switch -- say that if they did that I would get more than 384k.

The problem is not with my ISP. They *want* to give us 384k. What I've been relating to you about CIR, etc. is what the Verizon techs have been telling us.

 

[chagme]

Verizon is willing to set it to the following:
CIR 384
BC 384
BE 0

Would I get a throughput of 384k with those settings?

 

[svermill]

Yes, I believe that you would. You were sometimes getting above 192 earlier because you had a Be of 192. This is the amount of bandwidth, in excess of Bc, that you are allowed to burst to, with the DE set. Sometimes frames with DE set get through, sometimes they don't. It depends on the policy of the service provider and also the congestion level of the switch at any given time. With a CIR and Bc of 384k, you should consistently get access to that rate, with no ability (Be = 0) to burst beyond that rate.

Please post back and let us know if this works out (I think that almost certainly it will but you can never be certain that something else won't creep up).

Regards,

Scott

 

[chagme]

Maybe I should have added that in Vermont (and New Hampshire and upstate New York) 384k Frame Relay is comprised of a T1 to the Frame Relay switch where you can have either a 384k or full T1 Frame port.

 

[svermill]

I wasn't aware of that. I had assumed that your organization had contracted for a CIR of only 192k for cost reasons. FYI: A CIR of 384k may end up costing you more if the marketing side of the house becomes aware that they priced one CIR and that a tech later provisioned the circuit for something different. This is the whole basis for FR being cheaper than standard leased lines. You get a commitment of some rate (CIR) and are occasionally allowed to burst beyond that (Be), but realizing that there is no guarantee of delivery beyond CIR. In assigning some CIR and a Be of 0, you have effectively turned the FR circuit into a run-of-the-mill leased line. I'm not in any way suggesting that there is anything wrong with that. Just making the observation.

Again, let us all know how it pans out when you have had a chance to do some testing. I dont' know if you can get out today (I saw all that snow coming down on the playoff game at New England last night!)

 

[chagme]

Thanks for your responses. And I *will* let you know how it pans out.

My understanding has always been (I've been a channel for ordering Frame Relay for four years now and sometimes help with installing Cisco routers for customers) that when you contract with Verizon for a 384k circuit you should be getting 384k at least some of the time, depending on network congestion, either at the ISP's POP or congestion at the ISP's backbone provider. The weird thing is, that until recently, Verizon used to accept orders with the 384,384,384 setting.

Hopefully, I'll clear this up with Verizon the next few days and will let you know.

Thanks again for your help.

 

[chagme]

Managed to find a helpful Verizon tech this morning and had him change the PVC to:
CIR 384
BC 384
BE 384

I'm now getting download speeds up to 372k -- pretty good for a Monday morning, though it is a holiday for the schools on the ISP's network. Anyway, looks like a big improvement.

Thank you Scott for your help and taking the time to have some back and forth with me.

 

[chagme]

CORRECTION! There was a mistake in my last post.

The BE is set to 0.

CIR 384
BC 384
BE 0

 

[svermill]

I am very glad to hear that Verison came up with something that works for you.

Best regards,

Scott

 

[TTND]

For those who read these for technical infomation, allow me to explain these parameters. These are from a Lucent switch. Lucent CBX500 as an example. This is the way it does traffic shaping:
CIR= green traffic -gauranteed
Bc= amber traffic -Over CIR, under Be
Be= red traffic - Over CIR, Over Bc
This is a way that Lucent prioritizes DE packets. There are two levels of DE. Anything over CIR is marked DE, it will be put in the Amber or Red traffic category based on how much over CIR it goes. When congestion occurs, Red frames are dropped first. If congestions continues and all Red frames have been dropped, then the switch drops Amber frames.
The tricky part about this is that when you configure this on the switch it all depends on if graceful discard is turned on as to what it will do.
With the setting set as discussed in the earlier messages: CIR-192, Bc-192, Be-192
all traffic over 192k would be discarded if graceful discard was turned off. If graceful discard was turned on it would allow the PVC to burst above the 192 regaurdless and only drop frames (red first, then amber) if congestion occurs.
So, by changing the configs to CIR=384, Bc=384, Be=0 and must have had graceful discard on, he is able to go up to 384k gauranteed (green) and anything over that would be marked as Amber frames and discarded only when congestion occurs. The Be function was not doing any function because graceful discard was on and it was set to 0.

Happy Day