Re: ospf bandwidth question
Well, actually, I was referring to sending data from a larger *access speed* (or access rate, or port speed - whatever term you prefer) to a smaller one. Not CIR. For example, a frame relay service with 1Mbps access speed at one end, connected to a service with 256 Kbps access speed at the other end. Unless you implement traffic shaping or some other throttling mechanism, your router could try to send date at 1 Mbps - it will never fit through the 256 Kbps pipe at the other end. In this situation, the telco switch will toss away anything above 256 Kbps on that PVC when it first enters the cloud at the 1 Mbps end, regardless of what the CIR is. Anything above the CIR but below 256 Kbps will get the DE bit set. And no, Worldcom isn't very big in this part of the world - it wasn't them :-) JMcL -- Forwarded by Jenny Mcleod/NSO/CSDA on 04/10/2000 08:34 am --- [EMAIL PROTECTED] on 03/10/2000 03:36:40 pm Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: JENNY MCLEOD/NSO/CSDA) Subject: Re: ospf bandwidth question In a message dated 10/3/00 12:16:20 AM Eastern Daylight Time, [EMAIL PROTECTED] writes: > 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. > In this scenario of a larger bandwidth side trying to send into a smaller CIR you would have DE bits inbound on the smaller side router. DE (discard eligable) is any data sent over the line that is higher than the CIR because it is "eligable for discard". Let me guess...Worldcom told you that ;) On a side note. It's amazing how many new terms the telco can introduse into the field when trying to think of an RFO, haha My 0.2 cents... Mark Zabludovsky ~ CCNA, CCDA, 1/4-NP [EMAIL PROTECTED] "If you need luck, apparently you're not prepared...Go study!" ~Mark Zabludovsky~ **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]
RE: ospf bandwidth question
CRC errors are a layer one issue, so I would work on them first. Since they are layer one, you need to check physical things like cabling and DSUs. A call to your frame provider (Bellwhatever, MCI, BTI, etc) might help since they can do a lot of testing remotely. Good luck, Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: Monday, October 02, 2000 11:57 PM To: [EMAIL PROTECTED] Subject: RE: ospf bandwidth question "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] **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]
Re: ospf bandwidth question
In a message dated 10/3/00 12:16:20 AM Eastern Daylight Time, [EMAIL PROTECTED] writes: > 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. > In this scenario of a larger bandwidth side trying to send into a smaller CIR you would have DE bits inbound on the smaller side router. DE (discard eligable) is any data sent over the line that is higher than the CIR because it is "eligable for discard". Let me guess...Worldcom told you that ;) On a side note. It's amazing how many new terms the telco can introduse into the field when trying to think of an RFO, haha My 0.2 cents... Mark Zabludovsky ~ CCNA, CCDA, 1/4-NP [EMAIL PROTECTED] "If you need luck, apparently you're not prepared...Go study!" ~Mark Zabludovsky~ **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]
RE: ospf bandwidth question
"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]
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] **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]
Re: ospf bandwidth question
If you don't have the information that OSPF uses to calculate it's metrics set properly, then OSPF may be overutilizing this link when other paths are available. With that said, are you getting a lot of CRC errors? CRC errors are not normal, and may indicate a problem with your CSU/DSU, or the quality of the local loop. BECN's and FECN's are indicators that the frame cloud you are connecting to is experiencing congestion. It could be oversubscribed, or you may be pushing more traffic that it can handle. If you are staying within your CIR, then you may want to ask your Frame service provider to reroute your PVC's. If you are regularly exceeding your CIR, you may want to add more bandwidth or look into prioritization/filtering. Lastly, research Traffic shaping on www.cisco.com. On reciept of a FECN, the sender is supposed to slow down by ~25%, and gradually increase speed until it finds a balance. By default, this isn't enabled on Cisco routers. Good Luck Ejay Hire [EMAIL PROTECTED] CCNA,MCSE,A+ Seeking Internetworking Employment Original Message Follows From: "Stull, Cory" <[EMAIL PROTECTED]> Reply-To: "Stull, Cory" <[EMAIL PROTECTED]> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> Subject: ospf bandwidth question Date: Thu, 28 Sep 2000 10:24:27 -0500 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] _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. **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]
