11-06-2001 12:35 PM - edited 03-01-2019 07:15 PM
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
11-06-2001 01:53 PM
what protocols are you running ?
you may be experiencing some broadcast flooding.
take a look at frame relay broadcast queue.
11-06-2001 02:08 PM
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.
11-06-2001 08:49 PM
What do you mean by port size? How do I go about setting up traffic shaping?
Thanks,
RJ
11-06-2001 08:06 PM
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.
11-06-2001 08:47 PM
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
11-06-2001 10:08 PM
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.
11-07-2001 10:15 AM
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
11-07-2001 01:23 PM
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
11-07-2001 05:34 PM
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
11-08-2001 02:56 PM
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.
11-08-2001 07:14 AM
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.
11-16-2001 09:24 AM
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.
11-08-2001 08:36 AM
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:
Mick.
11-16-2001 09:20 AM
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).
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide