Venting over BECN and FECN

I just wanted to vent over BECN and FECN. I don't know why I have had so much trouble with these two descriptors, and how they tell what traffic is experiencing congestion and in which direction. Cisco has done a great job of confusing the shi* out of me. I don't think they could have come up with a more ass-backwards way of describing congestion on a link.

OK, I feel better now

Optimus

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

Jammywanks

Were you reading stuff from Cisco Press or off their website?

Slowhand

FECN is Forward Explicit Congestion Notification, and it's sent out by the source Frame-Relay switch. BECN is Backward Explicit Congestion Notification, and is sent by the destination switch. I remember it this way:

FECN is sent forward by the source, (that's you). BECN is sent back by the destination, or remote switch. So, you send congestion signals forward (FECN), and you get them back (BECN).

dpsec_hyd

It is like that becuz the Frame-Relay Switch can not communicate directly to the Routers about the congestion. It modifies the headers of return traffic.

To remember this, consider yourself as the switch with congestion.

The source routerA is sending to destination router B, if it is a TCP then B will acknowledge and the Switch will get the chance to modify the BECN in that packet to inform A that there is congestion. The switch has to inform A cuz it is the one who is sending. BACKWARD

Now suppose A is sending an UDP, the destination will not acknowledge anything, then how the switch will inform A about the congestion. The switch will use FECN in the header to tell B to generate some packets or junks to A, and when the B generates, it adds the BECN to it and A gets the message.
FORWARD.