"Whenever you have BECNS or FECNS it could be that a powerful link is sending
data down a not so powerful link , e.g. a T1 link sending data down a 56 K
link and when packets reaches the 56 K side the link may not be able to take
it and hence the BECNS bit is set"
Hmm... not so sure about that. I'm told by an unreliable source (my telco :-)
that if you're sending from a large access speed to a smaller access speed,
traffic exceeding the CIR + EIR (i.e traffic that won't 'fit' once it gets to
the smaller end) will be dropped as soon as it enters the telco network. It
isn't transmitted across the telco cloud at all, and thus doesn't produce
F/BECNs (or congestion).
This may be telco-dependant behaviour, I guess.
JMcL
---------------------- Forwarded by Jenny Mcleod/NSO/CSDA on 03/10/2000 02:33 pm
---------------------------
"Yee, Jason" <[EMAIL PROTECTED]> on 29/09/2000 06:05:13 pm
Please respond to "Yee, Jason" <[EMAIL PROTECTED]>
To: "'Stull, Cory'" <[EMAIL PROTECTED]>
"'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc: (bcc: JENNY MCLEOD/NSO/CSDA)
Subject: RE: ospf bandwidth question
CRC errors could be due to modem clocking rate not configured properly etc.
FECNs are generated when data is sent out a congested interface; they
indicate to a DTE that congestion was encountered. Traffic is marked with
BECN if the queue for the opposite direction is deep enough to trigger FECNs
at the current time.
BECNs notify the sender to decrease the transmission rate. If the traffic is
one-way only (such as multicast traffic), there is no reverse traffic with
BECNs to notify the sender to slow down. Thus, when a DTE receives an FECN,
it first determines if it is sending any data in return. If it is sending
return data, this data will get marked with a BECN on its way to the other
DTE. However, if the DTE is not sending any data, the DTE can send a Q.922
TEST RESPONSE message with the BECN bit set.
Whenever you have BECNS or FECNS it could be that a powerful link is sending
data down a not so powerful link , e.g. a T1 link sending data down a 56 K
link and when packets reaches the 56 K side the link may not be able to take
it and hence the BECNS bit is set
You may want to implement adaptive traffic-shaping based on BECNS
Jason
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Stull, Cory
Sent: Thursday, September 28, 2000 11:24 PM
To: '[EMAIL PROTECTED]'
Subject: ospf bandwidth question
If I am getting many CRC errors and FECNs and BECNs on the frame-relay
network what would be a cause of that? Could it be that I didn't have the
bandwidth statement set to the CIR of the PVC???
Thanks
Cory R. Stull
MCSE, Bay Router Specialist, CCNA,CCDA
Communications Concepts Unlimited
262-814-7214
**NOTE: New CCNA/CCDA List has been formed. For more information go to
http://www.groupstudy.com/list/Associates.html
_________________________________
UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
FAQ, list archives, and subscription info: http://www.groupstudy.com
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
