| BECNs and FECNs aren't just important to know | | | | knows that the congestion occurred when frames |
| for your Cisco CCNA and CCNP certification | | | | were sent from KC to GB. |
| exams - they're an important part of detecting | | | | Frame Relay BECN Adaptive Shaping allows a |
| congestion on a Frame Relay network and | | | | router to dynamically throttle back on its |
| allowing the network to dynamically adjust its | | | | transmission rate if it receives frames from the |
| transmission rate when congestion is encountered. | | | | remote host with the BECN bit set. In this case, |
| The Forward Explicit Congestion Notification | | | | KC sees that the traffic it's sending to GB is |
| (FECN, pronounced "feckon") bit is set to zero by | | | | encountering congestion, because the traffic |
| default, and will be set to 1 if congestion was | | | | coming back from GB has the BECN bit set. If |
| experienced by the frame in the direction in which | | | | BECN Adaptive Shaping is running on KC, that |
| the frame was traveling. A DCE (frame relay | | | | router will adjust to this congestion by slowing its |
| switch) will set this bit, and a DTE (router) will | | | | transmission rate. When the BECNs stop coming in |
| receive it, and see that congestion was | | | | from GB, KC will begin to send at a faster rate. |
| encountered along the frame's path. | | | | BECN Adaptive Shaping is configured as follows: |
| If network congestion exists in the opposite | | | | KC(config)#int s0 |
| direction in which the frame was traveling, the | | | | KC(config-if)#frame-relay adaptive-shaping becn |
| Backward Explicit Congestion Notification (BECN, | | | | To see how many frames are coming in and |
| pronounced "beckon") will be set to 1 by a DCE. | | | | going out with the BECN and FECN bits set, run |
| If this is your first time working with BECNs and | | | | show frame pvc. |
| FECNs, you might wonder why the BECN even | | | | R3#show frame pvc |
| exists - after all, why send a "backwards" | | | | < some output removed for clarity >input pkts |
| notification? The BECN is actually the most | | | | 306 output pkts 609 in bytes 45566out bytes |
| important part of this entire process, since it's the | | | | 79364 dropped pkts 0 in FECN pkts 0in BECN |
| BECN bit that indicates to the sender that it | | | | pkts 0 out FECN pkts 0 out BECN pkts 0in DE |
| needs to slow down! | | | | pkts 0 out DE pkts 0out bcast pkts 568 out |
| For example, frames sent from Kansas City to | | | | bcast bytes 75128pvc create time 01:26:27, last |
| Green Bay encounter congestion in the FR cloud. | | | | time pvc status changed 01:26:27 |
| A Frame Switch sets the FECN bit to 1. In order | | | | Just watch the "in"s and "out"s of BECN, FECN, |
| to alert KC that it's sending data too fast, GB will | | | | and DE in both the exam room and your |
| send return frames with the BECN bit set. When | | | | production networks! |
| KC sees the BECN bit is set to 1, the KC router | | | | |