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

[millerv]

what protocols are you running ?

you may be experiencing some broadcast flooding.

take a look at frame relay broadcast queue.

[godblesses]

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.

[rremien]

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

Thanks,

RJ

[MickPhelps]

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.

[rremien]

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

[seilsz]

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.

[rremien]

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

[phampton]

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

[rremien]

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

[seilsz]

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.

[eapenten]

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.

[saridder]

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.

[MickPhelps]

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.

[saridder]

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