Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Frame Relay PVC

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

21 REPLIES
New Member

Re: Frame Relay PVC

what protocols are you running ?

you may be experiencing some broadcast flooding.

take a look at frame relay broadcast queue.

New Member

Re: Frame Relay PVC

As a general rule, this is caused by the port size on the hub being much larger than the port size on the spokes. This is easy to fix with traffic shaping at the HUB router. You may find your life much less painful if you went to sub-interfaces as well.

New Member

Re: Frame Relay PVC

What do you mean by port size? How do I go about setting up traffic shaping?

Thanks,

RJ

New Member

Re: Frame Relay PVC

BECNs and FECNs are notifications sent by the frame provider. BECNs (backwards) are notifications sent by the telco in the reverse direction of the congestion. FECNs (forwards) are notifications sent in the same direction as the congestion. The congestion is on the provider's frame switch and it is notifying you that if you send over your CIR, you run the risk of having dropped frames.

DE (disgard eligible) mean that you *have* exceeded your CIR with those frames and those frames ran the risk of being dropped.

Both are used to shape your frame traffic on your routers so that frames aren't dropped due to congestion.

Mick.

New Member

Re: Frame Relay PVC

I am graphing the bandwidth with mrtg and many of the sites are consistently above the CIR. We are in the process of upgrading some sites with t1 and using vpn tunnels over the Internet for LAN access. What can I do in the meantime to reduce congestion?

Thanks,

RJ

Bronze

Re: Frame Relay PVC

Receipt of FECN's and BECN's simply indicates that your traffic experienced congestion "somewhere" in the network. However, this doesn't necessarily mean that it was YOUR traffic that caused the congestion.

If you are concerned about excessive network delay, or loss of data in the network, have your service provider check the statistics on their switches. They will be able to tell you whether or not they are discarding your data.

New Member

Re: Frame Relay PVC

So, if I receive several fecn and becn packets, does that mean that my provider has something wrong with their circuits? Or, does it mean that because my traffic is consistently above my CIR, that my service provider will allow my traffic to experience congetion because the data rate is not guaranteed.

Thanks,

RJ

New Member

Re: Frame Relay PVC

This conversation definitely caught my attention. I am a provider running DSL over pvc's on a bridge group. When I checked my frame pvc's, I find some of my clients have many BECN, virtually no FECN packets and some have a lot of DE packets(What are DE packets?). There is not any correlation between total packets and either of the others. Only a few of the clients have drops.

I am really in the learning stages of managing these DSL connections. Any insight into how I can interpret this data to be able to offer my clients better service would be appreciated.

Pat

New Member

Re: Frame Relay PVC

For DE, check out Mick Phelps reply to this conversation. As an example for fecn and becn, all my pvcs on my hub router have "in becn" and "in de" packets. That means that the frame provider is sending these notifications to tell me that there is congested traffic from my hub router to all my remote sites. I have "in fecn" and "in de" notifications from the provider on my remote routers basically saying the same thing. There is congetion going towards the remote sites. Are these the same notifications on your router?

Also, to the post of seilez,

Since there is a large range between my burst and CIR on many sites, the only way to reduce network delay in most cases is to increase the CIR if the frame relay cloud is consistently congested (several fecn and becn notifications daily) Any traffic shaping config I can do without changing the CIR?

Thanks,

RJ

Bronze

Re: Frame Relay PVC

Is your transport provider reporting to you (well, you might have to ask) that they are discarding your data in the network? If not, frame-relay traffic shaping will just move the point of congestion back to your router.

New Member

Re: Frame Relay PVC

Experiencing increasing fecns and becns on ones network

will require that you request your ISP to check your traffic statistics on your bandwidth utilization over a period of time.

Yes, excessive becns, becns, and DEs suggest you may be bursting over your CIR or being subjected to flooding from

elsewhere.

The last solution is to increase the bandwidth to allow for more

bursty traffic.

Thanks.

New Member

Re: Frame Relay PVC

FECN and BECN has nothing to do with you and your speed, it has to do with the frame switch as a whole being backed up. Not just you are travelling over the frame cloud.

DE has to do with you going over the CIR.

New Member

Re: Frame Relay PVC

DE (disgard eligable) see above thread.

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.

New Member

Re: Frame Relay PVC

DE packets are Discard Eligible packets that are eligible to be dropped first by your frame relay providers frame switches.

Remember that when you order circuits, you can get a CIR which is what they try to guarantee you data rate at, and you can get a burstable rate which is what the frame relay provider tries to carry if they aren't busy. But if you burst, the frame switch can mark your packets with DE, meaning that if it has to drop packets (remember there are many other people using the frame cloud besides you) it will drop yours first since it has other customers that it has to honor their CIR's as well. The CIR is what they guarantee to carry.

Since data traffic is usually TCP based, no big deal if it get's dropped, right? TCP is connecton-oriented and will retransmit. DE's aren't anything to worry about, and neither is BECN and FECN (the time to worry is when you have voice over the links, but you wouldn't order burstable links for that anyway).

New Member

Re: Frame Relay PVC

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

New Member

Re: Frame Relay PVC

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.

New Member

Re: Frame Relay PVC

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...

Bronze

Re: Frame Relay PVC

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".

New Member

Re: Frame Relay PVC

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

New Member

Re: Frame Relay PVC

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?

New Member

Re: Frame Relay PVC

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.

290
Views
0
Helpful
21
Replies