Frame Relay PVC

[rremien]

I have a Frame relay network with 14 remote sites (PVCs). The frame is a full T1 link. 12 sites have a 16 Kb CIR, 1 with 64 Kb and 1 with a 128 Kb CIR. They are all burstable anywhere from 64Kb to 256 Kb. The hub router for the frame network is a 3640 with no subinterfaces. The cloud is all on one subnet. All sites come through the 3640 for LAN access between the sites and Internet access through the 3640 to the gateway router. On the 3640, when I do a "sh frame-relay pvc", all the PVCs have a fair amount of "in BECN" and "in DE" packets. All the other congestion packet counters are 0. When I do a "sh frame-relay pvc" on a remote 2610, there are "in FECN" and "in DE" packets. Where is the congetion occuring? If I have a lot of congetion packets, is it the lack of bandwidth available or could it be a problem with our frame relay provider?

Thanks,

RJ

[rremien]

Well I have two other frame connections that I administer and they run fine without any BECN or FECN packets. If they have to retransmit, then that would cause delay. It would be better to throttle back the transmission around the CIR and go at a slower pace then to send at a higher rate and having to retransmit 30-50% of the packets, right?

Thanks,

RJ

[MickPhelps]

from previous post re CIR and traffic shaping:

You can use frame-relay traffic shaping so that you don't send above your CIR when you receive BECNs (not sure about FECNs as I don't know if it would matter).

This would allow the router to throttle back its transmission rate while there was congestion on the frame cloud. This would keep you from sending past your CIR and reducing your DE frames.

see the following:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/fqcprt4/qcfpolsh.htm#xtocid1633029

Mick.

[duckhuntr]

I would also STRONGLY recommend going to Subinterfaces, using VLSM to subnet out the individual sites, thus allowing you to control the bandwidth for each site. We have a similar setup, and are using subinterfaces for All sites. It works like a champ...I also agree with one of the other responses on the problems being with your carrier...I experienced the same thing not too long ago, and it ended up being a problem at the CO...

[seilsz]

The importance of FECN, BECN and DE really depends on the transport carrier you are using. Generally all data sent above CIR is marked as DE. While receipt of a packet with the FECN bit set indicates congestion, you obviously still received the data, so the important of a FECN is arguable. Receipt of packets with the BECN bit set should get the most attention. How much attention, really depends on your carrier. Your best bit is to sit down with your transport provider and discuss how their network handles "burst".

[rremien]

So just to be completely clear, let me summarize. "IN BECN" packets from all the pvcs into my hub router means that there is congestion in the frame cloud going from my hub router to all the remote sites. "IN DE" packets into my hub router means that those packets were eligible to be discarded because they were packets that were sent during the time that my data stream exceeded the CIR. But it does not necessarily mean that any data was discarded. Is the only way to tell if data is discarded is to talk to the frame provider?

Thanks,

RJ

[l-arthur]

I am having an issue with CIR. For some strange reason although my PVC is configured for full CIR, I am being told by my provider that I am only allowed an aggregrate of Input/Output that equates to my CIR. I was under the impression as due to full duplex that i would be able to generate data trnasmission speeds of 1.536 input as well as 1.536 output at the same time. Any suggestions or comments on this issue. I also sometimes see my web stats indicating that I acheived more that 1.536 of bandwidth in one direction, if a T1 speed maxes out at 1.536 how is this possible?

[saridder]

It's not posible physically to go above the port speed. And I believe CIR is aggregate speed of both ways, not 1554 in and 1554 out.