Frame Relay monitoring

[tuks]

I once read that on a frame relay network, a high number of dropped packets in conjunction with rapidly increasing FECN and BECN values could be a warning sign of saturated connection.

What commands should I run so that I can get a result of FECN and BECN values ?

 

[wybnormal]

Actually you are dealing with two issues. Dropped packets can be from an oversubcribed link, too small of buffer on the router, underpowered router for the link/traffic and so on.

The BECN is where the router will attempt to throttle back the traffic by 25%. When traffic permits it will let it increment back to the CIR.

Here is a link to Cisco with an explantion of this and some other sources of info.

http://www.cisco.com/warp/public/125/21.shtml

Complete list of Frame Relay commands

http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113ed_cr/wan_r/wrfrelay.htm

Mike S.
"Diplomacy; the art of saying 'nice doggie' till you can find a rock" Wynn Catlin

 

[jeter]

Show frame-relay pvc will give you the FECN and BECN values.
You may also want to check to see if there are any CRC errors. You can check for crc's errors by typing ( sh int ser 0 or 1 depending were the circuit resides ). #-) Jeter@LasVegas.com The best answer I could ever give is the one to maintain my Sanity

 

[cdheer]

Keep in mind that the router will only react to FECN/BECN values if you are running Frame-Relay Traffic Shaping.

By default, the router does nothing at all, other than display the values for you.

Nevertheless, wybnormal's point was a good one: many things can cause dropped frames. Sometimes it can even be intentional. Example:

A client I support has a large frame-based network. They have a number of internal critical business apps as well as Internet access. They did not want Internet traffic impacting their critical business apps.

At the time, some of the queueing strategies were a bit new, and this client is scared of the bleeding edge. So we put in a second set of PVCs just for Internet access. In our network, PVCs by default have a feature called Graceful Discard enabled, which means that red frames aren't dropped unless there is congestion. On their Internet PVCs, however, we disabled graceful discard, so the switches dropped red frames regardless, thus capping bandwidth at CIR (actually CIR+Be).

They're no longer scared of fancy-shmancy queueing schemes, however, so we'll be eliminating the second set of PVCs and implementing CBWFQ.

There go my evenings this summer.

--chris

 

[cpace]

What type of traffic shaping do I need to set up for Frame Relay ?

 

[alex72]

show frame-relay pvc <pvc number>

 

[cpace]

What I mean is, what qos and policy mapping do I need to implement for frame-relay? The only traffic shaping I have in place is throttling http traffic back to 128k.

 

[cpace]

Sorry, I was really vague earlier. What qos and policy mapping do I need to implement for frame-relay? The only traffic shaping I have in place is throttling http traffic back to 128k.