Frank,

Strictly speaking, whether or not a packet is marked DE has nothing to do
with whether or not you will see FECN and BECN.  Marking a packet DE simply
means that you are exceeding the amount of bw that your are "guaranteed".
It doesn't mean that a packet will be dropped, it only means that that
packet is more likely to be dropped in the event of congestion.  If the FR
network is never congested, no packets will ever be dropped, regardless of
whether they are marked DE.  Some providers, Sprint for example, typically
sell their circuits for 0k CIR, so _every_ packet is marked DE. (Sprint says
"we don't oversubscribe our network, so we can mark everything DE")

FECN and BECN on the other hand, mean that somewhere in the FR cloud, a port
on a switch reached a buffer threshold at which it needed to drop packets.
Doesn't mean it was your packets, doesn't mean that the packets that got
dropped were marked DE, it only means that some packets were dropped.  If a
buffer on a switch port fills up, it must drop packets, regardless of DE or
non-DE markings.  If the switch happens to have some packets marked DE and
some not marked DE, the ones marked DE _should_ get dropped first. (I say
_should_ because different switch vendors implement their discard algorithms
differently, it may depend on where the DE packets are in the queue, how
fast the switch is receiving packets, etc. etc)

So, to answer your question, your seeing DE packets because your exceeding
the CIR for that PVC.  You aren't seeing FECN/BECN because no FR switches
are seeing congestion on any ports.  Essentially, your getting more than
your paying for, congratulations.  :-)

Typically, you will only run into trouble when many customers are
consistently bursting above their CIR.  Generally, you won't see FECN/BECN
if your not above CIR, but just because you are above CIR doesn't mean you
_will_ see FECN/BECN.

If you see FECN/BECN and you are below CIR, it probably means the carrier is
experiencing an outage, they are oversubscribed on their backbone, or you
are sending from a high bandwidth site to a low bandwidth site. (like T1 to
128kbps)  I would say you only need to look at FR traffic shaping if you are
seeing a lot of traffic from a high bandwidth site to a low bandwidth site
and you are over-running the FR switch port at the low bandwidth site end.
(you would see FECN's on the low bandwidth site router and BECN on the high
bandwidth site router)

Simply seeing DE packets is not a reason to implement traffic shaping.  As I
said, seeing DE packets is actually somewhat of a good thing since it means
your getting more than your paying for.  If you continually see lots of DE
packets, you might think about whether your CIR is high enough, but if your
not seeing FECN/BECN and your performance is fine, it's probably not worth
worrying about.

HTH,
Kent



-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
DAGENHARDT Frank
Sent: Wednesday, December 19, 2001 11:43 AM
To: [EMAIL PROTECTED]
Subject: Fame Relay FECN BECN [7:29675]


Group,

I thought I had FECN and BECN down in regards to frame relay setup. Recently
I have come across some router output that doesn't make sence to me.
I don't understand why I have DE pkts when I don't have and FECN or BECN
errors. Or for that matter how I can have so many DE pks and no of them were
dropped. I was thinking of implementing traffic shaping, but I don't know if
that will help if I am not receiving any BECN errors. On top of that I
understand that when your CIR is reached packets get marked DE but at what
point do they actually get dropped. Can someone try to make a little sence
out of this for me?

DLCI = 131, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
Serial0/1.131

  input pkts 29103083      output pkts 23370364     in bytes 3538537810
  out bytes 941866396      dropped pkts 13          in FECN pkts 0
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0
  in DE pkts 1154469       out DE pkts 0
  out bcast pkts 1379364    out bcast bytes 110300947
  pvc create time 10w2d, last time pvc status changed 3w2d

Thank you,
Frank




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=29693&t=29675
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to