pa-fe-fx crc errors [7:72067]
Got a friend messing with a couple of these, I cant find a lot of info on these cards really, anyone got a good troubleshooting site? Brian Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=72067t=72067 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Acceptable Amount of CRC Errors [7:59477]
I remember looking at a link on Cisco's web site that stated an acceptable threshold for CRC errors on an interface. I believe it was something like CRCs could not exceed .001% of the total input packets on the interface. Has anyone else seen this link, or one like it? I am trying to determine the threshold for an alarm notification when polling for iferrors. Guy H. Lupi Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=59477t=59477 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Acceptable Amount of CRC Errors [7:59477]
I found the following paragraph at http://www.cisco.com/en/US/customer/tech/tk39/tk48/technologies_tech_note09186a00800c93ef.shtml Note: The input errors counter tracks the total number of CRCs, no buffers, runts, giants, frames, overruns, ignored, aborts and other input-related errors. The input errors counter is therefore either the same as, or higher than, the CRC counter. The occurence of errors and the input and output difference should not exceed one percent (1.0 %) of traffic on the interface. Hope this helps. Andrew -Original Message- From: Lupi, Guy [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 12:28 PM To: [EMAIL PROTECTED] Subject: Acceptable Amount of CRC Errors [7:59477] I remember looking at a link on Cisco's web site that stated an acceptable threshold for CRC errors on an interface. I believe it was something like CRCs could not exceed .001% of the total input packets on the interface. Has anyone else seen this link, or one like it? I am trying to determine the threshold for an alarm notification when polling for iferrors. Guy H. Lupi Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=59480t=59477 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Acceptable Amount of CRC Errors [7:59477]
On shared Ethernet, CRC errors are often the result of a collision. Let's leave that aside, however, and assume that you are referring to CRC errors on full-duplex Ethernet or serial links. CRC errors are caused by noise, signal reflections, impedance mismatches, improperly installed demarcs, faulty hardware, and other bad things that really shouldn't happen. The number should be really low. That's helpful, eh? :-) CRC errors should be less on fiber-optic cabling compared to copper cabling. According to industry standards, fiber-optic cabling should not experience more than one bit error per 10^11 bits. Copper cabling should not experience more than one bit error per 10^6 bits. Some documents from Cisco and other vendors specify a threshold of one bad frame per megabyte of data. In other words, an interface should not experience more than one CRC error per megabyte of data received. (The megabyte of data threshold comes from the industry standards that state that copper cables should not have a bit error rate that exceeds 1 in 10^6.) This method is better than simply calculating a percentage of bad frames compared to good frames, which does not account for the variable size of frames. (If you have a constant flow of 64-byte frames, for example, and a percentage of them is getting damaged, that probably represents a more serious problem than the same percentage of 1500-byte frames getting damaged. So, it's better to use a total number of bytes rather than a total number of frames in the calculation.) When troubleshooting at the Data Link Layer, which deals with frames rather than bits, you can't actually determine a bit error rate, but you can at least get a rough estimate by considering the number of CRC errors compared to the number of megabytes received. Some Cisco documentation simply states that a problem exists if input errors are in excess of 1 percent of total interface traffic. This is easier to remember, but it's actually just as hard to comprehend. The documents don't specify whether you should compare the input errors to the number of frames or the number of bytes received. If they means frames, then we have the problem already mentioned (no accounting for variable frame sizes). If they mean bytes, then 1 percent is very high. On a loaded network, 1 percent of total bytes represents a very high bit-error rate. You may want to use a number less than 1 percent. When troubleshooting input errors, you should also consider a timeframe and whether there's been a burst of errors and how long the burst has lasted. The telco practice is to report total errors along with errored seconds, for example. ___ Priscilla Oppenheimer www.troubleshootingnetworks.com www.priscilla.com Lupi, Guy wrote: I remember looking at a link on Cisco's web site that stated an acceptable threshold for CRC errors on an interface. I believe it was something like CRCs could not exceed .001% of the total input packets on the interface. Has anyone else seen this link, or one like it? I am trying to determine the threshold for an alarm notification when polling for iferrors. Guy H. Lupi Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=59493t=59477 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Acceptable Amount of CRC Errors [7:59477]
I would also reset the counters on hourly intervals when I'm tracking a big ish problem this way and keep track of the statistics. You might find that errors peak at certain times of the day. Counters that are very old is not really very useful. -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: 18 December 2002 22:35 To: [EMAIL PROTECTED] Subject: RE: Acceptable Amount of CRC Errors [7:59477] On shared Ethernet, CRC errors are often the result of a collision. Let's leave that aside, however, and assume that you are referring to CRC errors on full-duplex Ethernet or serial links. CRC errors are caused by noise, signal reflections, impedance mismatches, improperly installed demarcs, faulty hardware, and other bad things that really shouldn't happen. The number should be really low. That's helpful, eh? :-) CRC errors should be less on fiber-optic cabling compared to copper cabling. According to industry standards, fiber-optic cabling should not experience more than one bit error per 10^11 bits. Copper cabling should not experience more than one bit error per 10^6 bits. Some documents from Cisco and other vendors specify a threshold of one bad frame per megabyte of data. In other words, an interface should not experience more than one CRC error per megabyte of data received. (The megabyte of data threshold comes from the industry standards that state that copper cables should not have a bit error rate that exceeds 1 in 10^6.) This method is better than simply calculating a percentage of bad frames compared to good frames, which does not account for the variable size of frames. (If you have a constant flow of 64-byte frames, for example, and a percentage of them is getting damaged, that probably represents a more serious problem than the same percentage of 1500-byte frames getting damaged. So, it's better to use a total number of bytes rather than a total number of frames in the calculation.) When troubleshooting at the Data Link Layer, which deals with frames rather than bits, you can't actually determine a bit error rate, but you can at least get a rough estimate by considering the number of CRC errors compared to the number of megabytes received. Some Cisco documentation simply states that a problem exists if input errors are in excess of 1 percent of total interface traffic. This is easier to remember, but it's actually just as hard to comprehend. The documents don't specify whether you should compare the input errors to the number of frames or the number of bytes received. If they means frames, then we have the problem already mentioned (no accounting for variable frame sizes). If they mean bytes, then 1 percent is very high. On a loaded network, 1 percent of total bytes represents a very high bit-error rate. You may want to use a number less than 1 percent. When troubleshooting input errors, you should also consider a timeframe and whether there's been a burst of errors and how long the burst has lasted. The telco practice is to report total errors along with errored seconds, for example. ___ Priscilla Oppenheimer www.troubleshootingnetworks.com www.priscilla.com Lupi, Guy wrote: I remember looking at a link on Cisco's web site that stated an acceptable threshold for CRC errors on an interface. I believe it was something like CRCs could not exceed .001% of the total input packets on the interface. Has anyone else seen this link, or one like it? I am trying to determine the threshold for an alarm notification when polling for iferrors. Guy H. Lupi Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=59509t=59477 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Catalyst 2950 CRC Errors [7:51419]
John Neiberger wrote: We've had nothing but bad luck with the 3C905C NICs. We've purchased a *bunch* of low-end Dell PCs that have that NIC and they tend to get the blue screen of death and then reboot if they're connected to Cisco switches, especially when STP is turned on. Very odd behavior and we haven't found a solution yet. We'd better come up with something fast because we're getting more of those pieces of junk soon. Here's an old Cat 5000 bug report that I saved: BugID: CSCdt68700 Title: Switch reports FCS, Alignment, Runts when 3C905C connected at FD Feature: counters Version: 5.5(6) Integrated: Severity: 5 State: C Release Notes: Under normal traffic conditions, a 100 Megabit, Full-duplex connection between any Cisco Catalyst Switch and a 3Com 3C905C will result in Layer 2 errors. The Catalyst Switch will report these Layer 2 errors as FCS, Alignment and Runt Packets. Troubleshoot this issue by reviewing the below guidelines and documentation. 1. Verify that both the 3Com 3C905C and Catalyst Switch are both set for auto-negotiate or both are manually set for 100 MB, Full-Duplex. A duplex mismatch will cause a higher rate of Layer 2 (physical) layer errored frames. 2. Load the lastest 3Com 3C905C driver available from www.3com.com 3. Load the diagnostic utility available with the lastest 3Com 3C905C driver. update.exe /diag) 4. Connect 2 test workstations with 3Com 3C905Cs back-to-back using a crossover cable. 5. Test Connectivity initiating a large file transfer between the workstations and noting the following counters with the 3Com Diag Utility. This test, the back-to-back between the PCs with 3C905C(s), will give a benchmark for performance and physical layer errors. According to the 3Com documentation, the details of the following counters are significant: Receive Overruns: Receive Overrun is the number of lost packets that cannot be stored in the receive buffer because the PC''s buffer is already full. Carrier Sense Lost: Carrier Sense Lost is the number of packets transmitted with a carrier sense loss. This normally occurs as a result of collisions. Transmit Underrun: Transmit underrun is the number of times a packets was transmitted without adequate data by the NIC. In respective the Catalyst Switch Counters, a packet transferred that results in the Carrier Sense Lost or Transmit Underrun incrementing on the 3Com NIC will cause at least one of the following counters to increase on the Switch: Alignment, FCS, CRC, Input Errors, Receive Errors, and/or Runts. Noting the errors and performance back-to-back between 2 PCs with the 3C905C NIC will give a minimum baseline for the number of errors reported by the switch and a generally baseline for performance. 6. Repeat step 5 with the PCs connected to the switch and baseline the number of errors to the errors recorded in Step 5. Expect a higher number of errors when the workstation is connected to the network as there will be higher load of traffic including multicast, unicast-flood, and broadcast traffic. Note: It has been noted that increasing CPU/BUS Speed on the workstation increases the number of Transmit Underrun packets recorded on the NIC and Runt Packets on the Catalyst Switches. In conclusion, this issue is not a Switch specific issue nor an issue with compatability. Please contact 3Com Tech Support for resolution. - Marty Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=51543t=51419 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Catalyst 2950 CRC Errors [7:51419]
I haven't tried disabling pwrmngmt yet. I'll give it a shot and post the results. Thanks, Dain. Frank Jimenez wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Might want to review this: http://www.cisco.com/warp/public/473/46.html Power management was causing a bunch of issues at one of my customer's sites. Might want to disable it and see if it helps any. Frank Jimenez, CCIE #5738 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dain Deutschman Sent: Wednesday, August 14, 2002 10:26 PM To: [EMAIL PROTECTED] Subject: Re: Catalyst 2950 CRC Errors [7:51419] Also...I have tested the wiring(basic tester...no NEXT/FEXT or other factors...but lengths of cable are under 50ft) and replaced patch cables...still no luck. Dain. Dain Deutschman wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hello Everyone, I have a Cat2950 in a small office throwing up thousands of CRCs, input errors and several runts on the port connected to the server. Clients are getting disconnected and database on server is constantly having to be repaired. The errors always follow the server no matter which port I move it to. Have replaced NIC in server and a few key Wkst. Have also updated the NIC drivers. ( Win2000 w/3C905C-TX-M Nics ). I have forced speed and duplex settings and disabled spanning-tree. I'm suspecting dirty power...but it is connected to a UPS ( that only has limited EMI/RFI Filtering ). I connect a 3Com unmanaged 8 port switch to the key clients and the server...no more problems. Any ideas?!? It's driving me nuts! Thanks in advance... -- Dain Deutschman CNA, MCP, CCNA Data Communications Manager New Star Sales and Service, Inc. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=51556t=51419 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Catalyst 2950 CRC Errors [7:51419]
We've had nothing but bad luck with the 3C905C NICs. We've purchased a *bunch* of low-end Dell PCs that have that NIC and they tend to get the blue screen of death and then reboot if they're connected to Cisco switches, especially when STP is turned on. Very odd behavior and we haven't found a solution yet. We'd better come up with something fast because we're getting more of those pieces of junk soon. John Dain Deutschman 8/14/02 9:26:02 PM Also...I have tested the wiring(basic tester...no NEXT/FEXT or other factors...but lengths of cable are under 50ft) and replaced patch cables...still no luck. Dain. Dain Deutschman wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hello Everyone, I have a Cat2950 in a small office throwing up thousands of CRCs, input errors and several runts on the port connected to the server. Clients are getting disconnected and database on server is constantly having to be repaired. The errors always follow the server no matter which port I move it to. Have replaced NIC in server and a few key Wkst. Have also updated the NIC drivers. ( Win2000 w/3C905C-TX-M Nics ). I have forced speed and duplex settings and disabled spanning-tree. I'm suspecting dirty power...but it is connected to a UPS ( that only has limited EMI/RFI Filtering ). I connect a 3Com unmanaged 8 port switch to the key clients and the server...no more problems. Any ideas?!? It's driving me nuts! Thanks in advance... -- Dain Deutschman CNA, MCP, CCNA Data Communications Manager New Star Sales and Service, Inc. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=51445t=51419 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Catalyst 2950 CRC Errors [7:51419]
Hello Everyone, I have a Cat2950 in a small office throwing up thousands of CRCs, input errors and several runts on the port connected to the server. Clients are getting disconnected and database on server is constantly having to be repaired. The errors always follow the server no matter which port I move it to. Have replaced NIC in server and a few key Wkst. Have also updated the NIC drivers. ( Win2000 w/3C905C-TX-M Nics ). I have forced speed and duplex settings and disabled spanning-tree. I'm suspecting dirty power...but it is connected to a UPS ( that only has limited EMI/RFI Filtering ). I connect a 3Com unmanaged 8 port switch to the key clients and the server...no more problems. Any ideas?!? It's driving me nuts! Thanks in advance... -- Dain Deutschman CNA, MCP, CCNA Data Communications Manager New Star Sales and Service, Inc. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=51419t=51419 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Catalyst 2950 CRC Errors [7:51419]
Also...I have tested the wiring(basic tester...no NEXT/FEXT or other factors...but lengths of cable are under 50ft) and replaced patch cables...still no luck. Dain. Dain Deutschman wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hello Everyone, I have a Cat2950 in a small office throwing up thousands of CRCs, input errors and several runts on the port connected to the server. Clients are getting disconnected and database on server is constantly having to be repaired. The errors always follow the server no matter which port I move it to. Have replaced NIC in server and a few key Wkst. Have also updated the NIC drivers. ( Win2000 w/3C905C-TX-M Nics ). I have forced speed and duplex settings and disabled spanning-tree. I'm suspecting dirty power...but it is connected to a UPS ( that only has limited EMI/RFI Filtering ). I connect a 3Com unmanaged 8 port switch to the key clients and the server...no more problems. Any ideas?!? It's driving me nuts! Thanks in advance... -- Dain Deutschman CNA, MCP, CCNA Data Communications Manager New Star Sales and Service, Inc. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=51426t=51419 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Help with huge amount of Input/Frame and some CRC errors [7:21811]
Thanks for the input Les, This isn't the case here, because if I get them around the wrong way, there is no link at all. I do get some traffic down this connection, probably about equivalent to 14.4k... Symon --- Hi people, I have experienced a similar problem using G703 cards in a cisco 2620, in this case it was a transposed pair in the building wiring. That is the transmit and receive pairs were transmit to transmit and receive to receive rather than transmit to receive. Works fine with a loopback plug at either end but doesn't play when interconnected. HTH Les Symon Thurlow wrote: Hi Stephen, There are almost no resets all day, only 1 per router. that FUNNY you know ...al the BT CSU/DSU (for there 2 meg leased) have an X21 port built in The ones we have are only BNC, we have fibre coming in. [EMAIL PROTECTED] Cheers, Symon Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=21811t=21811 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Help with huge amount of Input/Frame and some CRC errors [7:21825]
Hi , i still think it From: Symon Thurlow Reply-To: Symon Thurlow To: [EMAIL PROTECTED] Subject: Re: Help with huge amount of Input/Frame and some CRC errors [7:21811] Date: Wed, 3 Oct 2001 04:01:58 -0400 Thanks for the input Les, This isn't the case here, because if I get them around the wrong way, there is no link at all. I do get some traffic down this connection, probably about equivalent to 14.4k... Symon --- Hi people, I have experienced a similar problem using G703 cards in a cisco 2620, in this case it was a transposed pair in the building wiring. That is the transmit and receive pairs were transmit to transmit and receive to receive rather than transmit to receive. Works fine with a loopback plug at either end but doesn't play when interconnected. HTH Les Symon Thurlow wrote: Hi Stephen, There are almost no resets all day, only 1 per router. that FUNNY you know ...al the BT CSU/DSU (for there 2 meg leased) have an X21 port built in The ones we have are only BNC, we have fibre coming in. [EMAIL PROTECTED] Cheers, Symon _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=21825t=21825 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Help with huge amount of Input/Frame and some CRC errors [7:21826]
Hi , i still think it`s the link..i have been told loads of times links are fine but they arn`t get THEM to run and END-to-END test... if you got an int resetand you didn`t touch the box the line is up the stuff.. from memory.. last 9 times .(ove 6mths...we have about 300 lines)...7 times BT line.once bad configHDLC-SDLC once fauly port on cisco switch. let us know how you get on From: Symon Thurlow Reply-To: Symon Thurlow To: [EMAIL PROTECTED] Subject: Re: Help with huge amount of Input/Frame and some CRC errors [7:21811] Date: Wed, 3 Oct 2001 04:01:58 -0400 Thanks for the input Les, This isn't the case here, because if I get them around the wrong way, there is no link at all. I do get some traffic down this connection, probably about equivalent to 14.4k... Symon --- Hi people, I have experienced a similar problem using G703 cards in a cisco 2620, in this case it was a transposed pair in the building wiring. That is the transmit and receive pairs were transmit to transmit and receive to receive rather than transmit to receive. Works fine with a loopback plug at either end but doesn't play when interconnected. HTH Les Symon Thurlow wrote: Hi Stephen, There are almost no resets all day, only 1 per router. that FUNNY you know ...al the BT CSU/DSU (for there 2 meg leased) have an X21 port built in The ones we have are only BNC, we have fibre coming in. [EMAIL PROTECTED] Cheers, Symon _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=21826t=21826 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Help with huge amount of Input/Frame and some CRC errors [7:21835]
Hi Stephen, NTL came back to me after more thorough testing, and acknowledged that there is a problem between their pop and BT. They have logged a trouble ticket with BT. I'll let you know the problem. Symon --- Hi , i still think it`s the link..i have been told loads of times links are fine but they arn`t get THEM to run and END-to-END test... if you got an int resetand you didn`t touch the box the line is up the stuff.. from memory.. last 9 times .(ove 6mths...we have about 300 lines)...7 times BT line.once bad configHDLC-SDLC once fauly port on cisco switch. let us know how you get on From: Symon Thurlow Reply-To: Symon Thurlow To: [EMAIL PROTECTED] Subject: Re: Help with huge amount of Input/Frame and some CRC errors [7:21811] Date: Wed, 3 Oct 2001 04:01:58 -0400 Thanks for the input Les, This isn't the case here, because if I get them around the wrong way, there is no link at all. I do get some traffic down this connection, probably about equivalent to 14.4k... Symon --- Hi people, I have experienced a similar problem using G703 cards in a cisco 2620, in this case it was a transposed pair in the building wiring. That is the transmit and receive pairs were transmit to transmit and receive to receive rather than transmit to receive. Works fine with a loopback plug at either end but doesn't play when interconnected. HTH Les Symon Thurlow wrote: Hi Stephen, There are almost no resets all day, only 1 per router. that FUNNY you know ...al the BT CSU/DSU (for there 2 meg leased) have an X21 port built in The ones we have are only BNC, we have fibre coming in. [EMAIL PROTECTED] Cheers, Symon [EMAIL PROTECTED] _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Cheers, Symon Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=21835t=21835 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Help with huge amount of Input/Frame and some CRC errors [7:21647]
Hi All, I have a 2MB leased line (UK Megastream) line between two sites. One site has a 3640, the other a 2621. The line is presented as G703 both ends. I have PDA DC2020 G703 to X21 converters at both ends. so connection is: SITE A Cisco 3640 (WIC-1T) PDA DC2020 X21 to G703 Converter Megastream box (CSU/DSU) Carriers network Megastream Box (CSU/DSU) PDA DC2020 X21 to G703 Converter Cisco 2621 (WIC-1T) When I do local and remote loopback tests, using extended pings, there are no errors. This is true from both ends. As soon as I take the line off loopback, the activity light on the 2621 goes crazy, and I get about 500 input errors per second on one end, and about 300 or so per second on the other end. Keepalives are incrementing, I have tried invert txclock, although probably didn't need to. Here is a sh int from each end, ip addresses changed: 2621 end: sh int s0/0 Serial0/0 is up, line protocol is up Hardware is PowerQUICC Serial Description: Internet address is 10.10.10.2/30 MTU 1500 bytes, BW 2048 Kbit, DLY 2 usec, reliability 157/255, txload 1/255, rxload 1/255 Encapsulation HDLC, loopback not set Keepalive set (10 sec) Last input 00:00:08, output 00:00:00, output hang never Last clearing of show interface counters 17:21:37 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 7055 packets input, 433584 bytes, 0 no buffer Received 7055 broadcasts, 0 runts, 0 giants, 0 throttles 30613034 input errors, 4438685 CRC, 26174345 frame, 0 overrun, 0 ignored, 4 abort 8850 packets output, 838333 bytes, 0 underruns 0 output errors, 0 collisions, 3 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up 3640 end: sh int s0/0 Serial0/0 is up, line protocol is up Hardware is QUICC Serial Description: Internet address is 10.10.10.1/30 MTU 1500 bytes, BW 2048 Kbit, DLY 2 usec, rely 161/255, load 1/255 Encapsulation HDLC, loopback not set, keepalive set (10 sec) Last input 00:00:00, output 00:00:00, output hang never Last clearing of show interface counters 17:22:15 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 1 packets/sec 5 minute output rate 0 bits/sec, 1 packets/sec 8485 packets input, 778380 bytes, 0 no buffer Received 7961 broadcasts, 0 runts, 0 giants, 0 throttles 18292244 input errors, 5169 CRC, 18287064 frame, 0 overrun, 0 ignored, 11 a bort 7324 packets output, 462192 bytes, 0 underruns 0 output errors, 0 collisions, 10 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up Carrier (NTL) say that line is fine. Remote loopback test sort of point to this as being true (to my limited knowledge). Any assistance greatly appreciated. Cheers, Symon Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=21647t=21647 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Help with huge amount of Input/Frame and some CRC errors [7:21649]
in your config what is your LMI.(autosence) have you set the encapsulation command on the int`s see this link http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/wan_c/wcdfrely.htm#xtocid221854 input errors usually mean that there is some kind of encap error...(int doesn`t understand the packet/frame it`s recieving) CU steve From: Symon Thurlow Reply-To: Symon Thurlow To: [EMAIL PROTECTED] Subject: Help with huge amount of Input/Frame and some CRC errors [7:21647] Date: Tue, 2 Oct 2001 04:47:46 -0400 Hi All, I have a 2MB leased line (UK Megastream) line between two sites. One site has a 3640, the other a 2621. The line is presented as G703 both ends. I have PDA DC2020 G703 to X21 converters at both ends. so connection is: SITE A Cisco 3640 (WIC-1T) PDA DC2020 X21 to G703 Converter Megastream box (CSU/DSU) Carriers network Megastream Box (CSU/DSU) PDA DC2020 X21 to G703 Converter Cisco 2621 (WIC-1T) When I do local and remote loopback tests, using extended pings, there are no errors. This is true from both ends. As soon as I take the line off loopback, the activity light on the 2621 goes crazy, and I get about 500 input errors per second on one end, and about 300 or so per second on the other end. Keepalives are incrementing, I have tried invert txclock, although probably didn't need to. Here is a sh int from each end, ip addresses changed: 2621 end: sh int s0/0 Serial0/0 is up, line protocol is up Hardware is PowerQUICC Serial Description: Internet address is 10.10.10.2/30 MTU 1500 bytes, BW 2048 Kbit, DLY 2 usec, reliability 157/255, txload 1/255, rxload 1/255 Encapsulation HDLC, loopback not set Keepalive set (10 sec) Last input 00:00:08, output 00:00:00, output hang never Last clearing of show interface counters 17:21:37 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 7055 packets input, 433584 bytes, 0 no buffer Received 7055 broadcasts, 0 runts, 0 giants, 0 throttles 30613034 input errors, 4438685 CRC, 26174345 frame, 0 overrun, 0 ignored, 4 abort 8850 packets output, 838333 bytes, 0 underruns 0 output errors, 0 collisions, 3 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up 3640 end: sh int s0/0 Serial0/0 is up, line protocol is up Hardware is QUICC Serial Description: Internet address is 10.10.10.1/30 MTU 1500 bytes, BW 2048 Kbit, DLY 2 usec, rely 161/255, load 1/255 Encapsulation HDLC, loopback not set, keepalive set (10 sec) Last input 00:00:00, output 00:00:00, output hang never Last clearing of show interface counters 17:22:15 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 1 packets/sec 5 minute output rate 0 bits/sec, 1 packets/sec 8485 packets input, 778380 bytes, 0 no buffer Received 7961 broadcasts, 0 runts, 0 giants, 0 throttles 18292244 input errors, 5169 CRC, 18287064 frame, 0 overrun, 0 ignored, 11 a bort 7324 packets output, 462192 bytes, 0 underruns 0 output errors, 0 collisions, 10 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up Carrier (NTL) say that line is fine. Remote loopback test sort of point to this as being true (to my limited knowledge). Any assistance greatly appreciated. Cheers, Symon _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=21649t=21649 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Help with huge amount of Input/Frame and some CRC errors [7:21657]
symon... sorryi am asleep i don`t like the amount of interface resets you are getting... can you clear counters and watch the amount you are gettingon both sides.. int resets cum from the line bieng dropped (g703/line) i have smds/leased lines and you should not get ANY int resets on a good line. the last time i had this problem it was the BT CSU/DSU that was at fault that FUNNY you know ...al the BT CSU/DSU (for there 2 meg leased) have an X21 port built in you could also try swapping the ints (S0-S1)on both sides to see if that makes a difference... Is this a new install?? it IS possible that the G703 converter is stuffedwe use BlackBox ones...and they SHOULD work straight out of the box... HTH steve From: Symon Thurlow To: [EMAIL PROTECTED] Subject: Re: Help with huge amount of Input/Frame and some CRC errors [7:21647] Date: Tue, 02 Oct 2001 23:05:07 +1130 It is a straight leased line, not Frame Cheers, Symon --- in your config what is your LMI.(autosence) have you set the encapsulation command on the int`s see this link http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgc r/wan_c/wcdfrely.htm#xtocid221854 input errors usually mean that there is some kind of encap error...(int doesn`t understand the packet/frame it`s recieving) CU steve From: Symon Thurlow Reply-To: Symon Thurlow To: [EMAIL PROTECTED] Subject: Help with huge amount of Input/Frame and some CRC errors [7:21647] Date: Tue, 2 Oct 2001 04:47:46 -0400 Hi All, I have a 2MB leased line (UK Megastream) line between two sites. One site has a 3640, the other a 2621. The line is presented as G703 both ends. I have PDA DC2020 G703 to X21 converters at both ends. so connection is: SITE A Cisco 3640 (WIC-1T) PDA DC2020 X21 to G703 Converter Megastream box (CSU/DSU) Carriers network Megastream Box (CSU/DSU) PDA DC2020 X21 to G703 Converter Cisco 2621 (WIC-1T) When I do local and remote loopback tests, using extended pings, there are no errors. This is true from both ends. As soon as I take the line off loopback, the activity light on the 2621 goes crazy, and I get about 500 input errors per second on one end, and about 300 or so per second on the other end. Keepalives are incrementing, I have tried invert txclock, although probably didn't need to. Here is a sh int from each end, ip addresses changed: 2621 end: sh int s0/0 Serial0/0 is up, line protocol is up Hardware is PowerQUICC Serial Description: Internet address is 10.10.10.2/30 MTU 1500 bytes, BW 2048 Kbit, DLY 2 usec, reliability 157/255, txload 1/255, rxload 1/255 Encapsulation HDLC, loopback not set Keepalive set (10 sec) Last input 00:00:08, output 00:00:00, output hang never Last clearing of show interface counters 17:21:37 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 7055 packets input, 433584 bytes, 0 no buffer Received 7055 broadcasts, 0 runts, 0 giants, 0 throttles 30613034 input errors, 4438685 CRC, 26174345 frame, 0 overrun, 0 ignored, 4 abort 8850 packets output, 838333 bytes, 0 underruns 0 output errors, 0 collisions, 3 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up 3640 end: sh int s0/0 Serial0/0 is up, line protocol is up Hardware is QUICC Serial Description: Internet address is 10.10.10.1/30 MTU 1500 bytes, BW 2048 Kbit, DLY 2 usec, rely 161/255, load 1/255 Encapsulation HDLC, loopback not set, keepalive set (10 sec) Last input 00:00:00, output 00:00:00, output hang never Last clearing of show interface counters 17:22:15 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 1 packets/sec 5 minute output rate 0 bits/sec, 1 packets/sec 8485 packets input, 778380 bytes, 0 no buffer Received 7961 broadcasts, 0 runts, 0 giants, 0 throttles 18292244 input errors, 5169 CRC, 18287064 frame, 0 overrun, 0 ignored, 11 a bort 7324 packets output, 462192 bytes, 0 underruns 0 output errors, 0 collisions, 10 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up Carrier (NTL) say that line is fine. Remote loopback test sort of point to this as being true (to my limited knowledge). Any assistance greatly appreciated. Cheers, Symon [EMAIL PROTECTED
Re: Help with huge amount of Input/Frame and some CRC errors [7:21698]
Hi Stephen, There are almost no resets all day, only 1 per router. that FUNNY you know ...al the BT CSU/DSU (for there 2 meg leased) have an X21 port built in The ones we have are only BNC, we have fibre coming in. you could also try swapping the ints (S0-S1)on both sides to see if that makes a difference... Yeah, they are both wic-1t's, I could try the NM slots, but thats about it. Yeah, it's a new install. it IS possible that the G703 converter is stuffedwe use BlackBox ones...and they SHOULD work straight out of the box... Yes, that is what I was thinking, but the loopback tests are fine!? Symon HTH steve From: Symon Thurlow To: [EMAIL PROTECTED] Subject: Re: Help with huge amount of Input/Frame and some CRC errors [7:21647] Date: Tue, 02 Oct 2001 23:05:07 +1130 It is a straight leased line, not Frame Cheers, Symon --- in your config what is your LMI.(autosence) have you set the encapsulation command on the int`s see this link http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cg c r/wan_c/wcdfrely.htm#xtocid221854 input errors usually mean that there is some kind of encap error...(int doesn`t understand the packet/frame it`s recieving) CU steve From: Symon Thurlow Reply-To: Symon Thurlow To: [EMAIL PROTECTED] Subject: Help with huge amount of Input/Frame and some CRC errors [7:21647] Date: Tue, 2 Oct 2001 04:47:46 -0400 Hi All, I have a 2MB leased line (UK Megastream) line between two sites. One site has a 3640, the other a 2621. The line is presented as G703 both ends. I have PDA DC2020 G703 to X21 converters at both ends. so connection is: SITE A Cisco 3640 (WIC-1T) PDA DC2020 X21 to G703 Converter Megastream box (CSU/DSU) Carriers network Megastream Box (CSU/DSU) PDA DC2020 X21 to G703 Converter Cisco 2621 (WIC-1T) When I do local and remote loopback tests, using extended pings, there are no errors. This is true from both ends. As soon as I take the line off loopback, the activity light on the 2621 goes crazy, and I get about 500 input errors per second on one end, and about 300 or so per second on the other end. Keepalives are incrementing, I have tried invert txclock, although probably didn't need to. Here is a sh int from each end, ip addresses changed: 2621 end: sh int s0/0 Serial0/0 is up, line protocol is up Hardware is PowerQUICC Serial Description: Internet address is 10.10.10.2/30 MTU 1500 bytes, BW 2048 Kbit, DLY 2 usec, reliability 157/255, txload 1/255, rxload 1/255 Encapsulation HDLC, loopback not set Keepalive set (10 sec) Last input 00:00:08, output 00:00:00, output hang never Last clearing of show interface counters 17:21:37 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 7055 packets input, 433584 bytes, 0 no buffer Received 7055 broadcasts, 0 runts, 0 giants, 0 throttles 30613034 input errors, 4438685 CRC, 26174345 frame, 0 overrun, 0 ignored, 4 abort 8850 packets output, 838333 bytes, 0 underruns 0 output errors, 0 collisions, 3 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up 3640 end: sh int s0/0 Serial0/0 is up, line protocol is up Hardware is QUICC Serial Description: Internet address is 10.10.10.1/30 MTU 1500 bytes, BW 2048 Kbit, DLY 2 usec, rely 161/255, load 1/255 Encapsulation HDLC, loopback not set, keepalive set (10 sec) Last input 00:00:00, output 00:00:00, output hang never Last clearing of show interface counters 17:22:15 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 1 packets/sec 5 minute output rate 0 bits/sec, 1 packets/sec 8485 packets input, 778380 bytes, 0 no buffer Received 7961 broadcasts, 0 runts, 0 giants, 0 throttles 18292244 input errors, 5169 CRC, 18287064 frame, 0 overrun, 0 ignored, 11 a bort 7324 packets output, 462192 bytes, 0 underruns 0 output errors, 0 collisions, 10 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up Carrier (NTL) say that line is fine. Remote loopback test sort of point to this as being true (to my limited knowledge). Any assistance greatly appreciated. Cheers, Symon [EMAIL
Re: Help with huge amount of Input/Frame and some CRC errors [7:21725]
10/2/2001 4:10pm Tuesday Stephen Skinner wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... symon... sorryi am asleep i don`t like the amount of interface resets you are getting... can you clear counters and watch the amount you are gettingon both sides.. int resets cum from the line bieng dropped (g703/line) i have smds/leased lines and you should not get ANY int resets on a good line. the last time i had this problem it was the BT CSU/DSU that was at fault that FUNNY you know ...al the BT CSU/DSU (for there 2 meg leased) have an X21 port built in you could also try swapping the ints (S0-S1)on both sides to see if that makes a difference... Is this a new install?? it IS possible that the G703 converter is stuffedwe use BlackBox ones...and they SHOULD work straight out of the box... HTH steve From: Symon Thurlow To: [EMAIL PROTECTED] Subject: Re: Help with huge amount of Input/Frame and some CRC errors [7:21647] Date: Tue, 02 Oct 2001 23:05:07 +1130 It is a straight leased line, not Frame Cheers, Symon --- in your config what is your LMI.(autosence) have you set the encapsulation command on the int`s see this link http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgc r/wan_c/wcdfrely.htm#xtocid221854 input errors usually mean that there is some kind of encap error...(int doesn`t understand the packet/frame it`s recieving) CU steve From: Symon Thurlow Reply-To: Symon Thurlow To: [EMAIL PROTECTED] Subject: Help with huge amount of Input/Frame and some CRC errors [7:21647] Date: Tue, 2 Oct 2001 04:47:46 -0400 Hi All, I have a 2MB leased line (UK Megastream) line between two sites. One site has a 3640, the other a 2621. The line is presented as G703 both ends. I have PDA DC2020 G703 to X21 converters at both ends. so connection is: SITE A Cisco 3640 (WIC-1T) PDA DC2020 X21 to G703 Converter Megastream box (CSU/DSU) Carriers network Megastream Box (CSU/DSU) PDA DC2020 X21 to G703 Converter Cisco 2621 (WIC-1T) When I do local and remote loopback tests, using extended pings, there are no errors. This is true from both ends. As soon as I take the line off loopback, the activity light on the 2621 goes crazy, and I get about 500 input errors per second on one end, and about 300 or so per second on the other end. Keepalives are incrementing, I have tried invert txclock, although probably didn't need to. Here is a sh int from each end, ip addresses changed: 2621 end: sh int s0/0 Serial0/0 is up, line protocol is up Hardware is PowerQUICC Serial Description: Internet address is 10.10.10.2/30 MTU 1500 bytes, BW 2048 Kbit, DLY 2 usec, reliability 157/255, txload 1/255, rxload 1/255 Encapsulation HDLC, loopback not set Keepalive set (10 sec) Last input 00:00:08, output 00:00:00, output hang never Last clearing of show interface counters 17:21:37 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 7055 packets input, 433584 bytes, 0 no buffer Received 7055 broadcasts, 0 runts, 0 giants, 0 throttles 30613034 input errors, 4438685 CRC, 26174345 frame, 0 overrun, 0 ignored, 4 abort 8850 packets output, 838333 bytes, 0 underruns 0 output errors, 0 collisions, 3 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up 3640 end: sh int s0/0 Serial0/0 is up, line protocol is up Hardware is QUICC Serial Description: Internet address is 10.10.10.1/30 MTU 1500 bytes, BW 2048 Kbit, DLY 2 usec, rely 161/255, load 1/255 Encapsulation HDLC, loopback not set, keepalive set (10 sec) Last input 00:00:00, output 00:00:00, output hang never Last clearing of show interface counters 17:22:15 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 1 packets/sec 5 minute output rate 0 bits/sec, 1 packets/sec 8485 packets input, 778380 bytes, 0 no buffer Received 7961 broadcasts, 0 runts, 0 giants, 0 throttles 18292244 input errors, 5169 CRC, 18287064 frame, 0 overrun, 0 ignored, 11 a bort 7324 packets output, 462192 bytes, 0 underruns 0 output errors, 0 collisions, 10 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions DCD=up DSR=up DTR=up
Re: Help with huge amount of Input/Frame and some CRC errors [7:21743]
Hi people, I have experienced a similar problem using G703 cards in a cisco 2620, in this case it was a transposed pair in the building wiring. That is the transmit and receive pairs were transmit to transmit and receive to receive rather than transmit to receive. Works fine with a loopback plug at either end but doesn't play when interconnected. HTH Les Symon Thurlow wrote: Hi Stephen, There are almost no resets all day, only 1 per router. that FUNNY you know ...al the BT CSU/DSU (for there 2 meg leased) have an X21 port built in The ones we have are only BNC, we have fibre coming in. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=21743t=21743 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
CRC Errors OID [7:11639]
Hi All I need to monitor the CRC errors on one of my Cisco Routers interface using SNMP. Can any one provide me the OID for the same ? The one that I knew about is locIfInCRC OID which has value 1.3.6.1.4.1.9.2.2.1.1.12 . Is it correct ? Also I wanted to ask that if I need to monitor the Errors on a particular Interface can I use IfInErrors and IfOutErrors OID. Thanks Regards Swapnil Shah Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=11639t=11639 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
CRC Errors OID [7:11638]
Hi All I need to monitor the CRC errors on one of my Cisco Routers interface using SNMP. Can any one provide me the OID for the same ? The one that I knew about is locIfInCRC OID which has value 1.3.6.1.4.1.9.2.2.1.1.12 . Is it correct ? Also I wanted to ask that if I need to monitor the Errors on a particular Interface can I use IfInErrors and IfOutErrors OID. Thanks Regards Swapnil Shah Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=11638t=11638 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
crc errors
CAn anyone help me with a small problem I face. I am using a 2621 router 2900xl switch and a 2610 router. the purpose of the exercise is to have the 2621 as the main router trunking vlans from the switch using isl when I use the 2610 as a backup router and configure hsrp all seems fine the hsrp works great as in the multicast packets hsrp uses don't get drop but all other input traffic has crc errors. can any one help with this little problem as in is it a hardware incompatiblity a proble with the ios (using version 12.0.10) or is it just not possible. D'Wayne Saunders _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: crc errors
2610 only support 802.1q. "Dwayne Saunders" [EMAIL PROTECTED] ? 1B3C3C1C7A05D511A5B50001025312BC08CA9C@aspmail">news:1B3C3C1C7A05D511A5B50001025312BC08CA9C@aspmail... CAn anyone help me with a small problem I face. I am using a 2621 router 2900xl switch and a 2610 router. the purpose of the exercise is to have the 2621 as the main router trunking vlans from the switch using isl when I use the 2610 as a backup router and configure hsrp all seems fine the hsrp works great as in the multicast packets hsrp uses don't get drop but all other input traffic has crc errors. can any one help with this little problem as in is it a hardware incompatiblity a proble with the ios (using version 12.0.10) or is it just not possible. D'Wayne Saunders _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
CRC errors on Catalyst 3500 XL port
Hi,
I have a 3640 ("router1") with IOS v11.2 which is routing between IP subnets
(class "c" with a one bit subnet mask - using "IP subnet-zero"). There are
two Ethernet ports on the router, each is connected to a separate Catalyst
3500 XL switch. The two switch ports are hard set to 10 MBS, duplex
autonegotiate, spanning-tree on, portfast on. I am seeing collisions and
crc errors on the switch ports that are connected to "router1". The
remainder of the switch ports ( with the exception of a few ports which I'll
explain shortly ) are connected to 100 MBS fastethernet desktops and don't
show any collisions...I understand why.
I also have another 3640 ("router2") connected to the same switches, in the
same manner...for redundancy, I'm told. There are a couple of other 3500 XL
switches cascaded from these...to accommodate the number users. The LAN
size is about 125 nodes with about equal number of nodes connected to each
subnet. I'm new here...I have recommended getting rid of the subnetting
scheme in favor of a classful LAN. Anyway, the switch ports that are
connected to "router2" don't show any collisions/crc errors.
This all started 2 weeks ago. The network has been designed this way for
about a year.
In short, I can't determine whether routing loops are causing the collisions
(and if so, why only on "router1"), or whether there's a port configuration
mismatch between "router1"s Ethernet ports and the switch. Or, maybe some
piece of hardware has just failed? Any suggestions are welcome.
Jim McDowell
Cisco Certified Network Professional
Network Administrator
Copley Information Systems
858.729.8028
_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: CRC errors on Catalyst 3500 XL port
everything else notwithstanding, I would nail the duplex setting.
I think I heard from this list - autonegotiate... "auto" means "ought not
to"
I just finished up a long lab experiment where I had problems with our ISP.
In the end the ISP had the duplex setting wrong on their eqpt. They didn't
tell me if it was autonegotiate or just the wrong setting but I get rid of
all autonegotiation now unless the circuit doesn't work without it. (haven't
found one of those yet)
Kevin Wigle
- Original Message -
From: "Jim McDowell" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, March 27, 2001 2:00 PM
Subject: CRC errors on Catalyst 3500 XL port
Hi,
I have a 3640 ("router1") with IOS v11.2 which is routing between IP
subnets
(class "c" with a one bit subnet mask - using "IP subnet-zero"). There
are
two Ethernet ports on the router, each is connected to a separate Catalyst
3500 XL switch. The two switch ports are hard set to 10 MBS, duplex
autonegotiate, spanning-tree on, portfast on. I am seeing collisions and
crc errors on the switch ports that are connected to "router1". The
remainder of the switch ports ( with the exception of a few ports which
I'll
explain shortly ) are connected to 100 MBS fastethernet desktops and don't
show any collisions...I understand why.
I also have another 3640 ("router2") connected to the same switches, in
the
same manner...for redundancy, I'm told. There are a couple of other 3500
XL
switches cascaded from these...to accommodate the number users. The LAN
size is about 125 nodes with about equal number of nodes connected to each
subnet. I'm new here...I have recommended getting rid of the subnetting
scheme in favor of a classful LAN. Anyway, the switch ports that are
connected to "router2" don't show any collisions/crc errors.
This all started 2 weeks ago. The network has been designed this way for
about a year.
In short, I can't determine whether routing loops are causing the
collisions
(and if so, why only on "router1"), or whether there's a port
configuration
mismatch between "router1"s Ethernet ports and the switch. Or, maybe some
piece of hardware has just failed? Any suggestions are welcome.
Jim McDowell
Cisco Certified Network Professional
Network Administrator
Copley Information Systems
858.729.8028
_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: CRC errors on Catalyst 3500 XL port
First, collisions are no big deal. They are to be expected when running
half duplex. However, you may not be intending to run half duplex from
the sounds of it. Try hard setting the router and switch ports for both
speed and duplex. It's possible that something caused router1 to
renegotiate, or perhaps the switches renegotiated and both of them
picked the wrong settings. It's difficult to say, but I do know that
it's best not to leave that sort of thing to chance.
Autonegotiation = "A Bad Thing"
There may be other causes but that would be the very first thing I
would check.
HTH,
John
"Jim McDowell" [EMAIL PROTECTED] 3/27/01 12:00:20 PM
Hi,
I have a 3640 ("router1") with IOS v11.2 which is routing between IP
subnets
(class "c" with a one bit subnet mask - using "IP subnet-zero"). There
are
two Ethernet ports on the router, each is connected to a separate
Catalyst
3500 XL switch. The two switch ports are hard set to 10 MBS, duplex
autonegotiate, spanning-tree on, portfast on. I am seeing collisions
and
crc errors on the switch ports that are connected to "router1". The
remainder of the switch ports ( with the exception of a few ports which
I'll
explain shortly ) are connected to 100 MBS fastethernet desktops and
don't
show any collisions...I understand why.
I also have another 3640 ("router2") connected to the same switches, in
the
same manner...for redundancy, I'm told. There are a couple of other
3500 XL
switches cascaded from these...to accommodate the number users. The
LAN
size is about 125 nodes with about equal number of nodes connected to
each
subnet. I'm new here...I have recommended getting rid of the
subnetting
scheme in favor of a classful LAN. Anyway, the switch ports that are
connected to "router2" don't show any collisions/crc errors.
This all started 2 weeks ago. The network has been designed this way
for
about a year.
In short, I can't determine whether routing loops are causing the
collisions
(and if so, why only on "router1"), or whether there's a port
configuration
mismatch between "router1"s Ethernet ports and the switch. Or, maybe
some
piece of hardware has just failed? Any suggestions are welcome.
Jim McDowell
Cisco Certified Network Professional
Network Administrator
Copley Information Systems
858.729.8028
_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: CRC errors on Catalyst 3500 XL port
First off, I'd say you are dealing with a poor design. You're most likely
dealing with a bandwidth issue on that 10 Meg link. Check the show
interface @ the 3600 (I think R1 router). I would venture to say the
broadcasts valid traffic together are causing the 10/half to saturate. I
wish I wasn't knee deep in OSPF, or I'm sure I could conger a few design
ideas (I'm sure the list will help ;-). I know you're looking @ a candidate
for clusters ISL. It wouldn't hurt to implement a better IP addressing
scheme, even 10.0.0.0's (but that's not the issue here). I had a similar
problem months back, a fellow had installed a 6509 using a 10/ half
connection to a 7507 for routing between VLAN's as the access link out.
What a waste of expensive equipment. His only reply was that it worked-
sorta...
I'll watch this thread for your progress
Phil
- Original Message -
From: "Jim McDowell" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, March 27, 2001 6:00 PM
Subject: CRC errors on Catalyst 3500 XL port
Hi,
I have a 3640 ("router1") with IOS v11.2 which is routing between IP
subnets
(class "c" with a one bit subnet mask - using "IP subnet-zero"). There
are
two Ethernet ports on the router, each is connected to a separate Catalyst
3500 XL switch. The two switch ports are hard set to 10 MBS, duplex
autonegotiate, spanning-tree on, portfast on. I am seeing collisions and
crc errors on the switch ports that are connected to "router1". The
remainder of the switch ports ( with the exception of a few ports which
I'll
explain shortly ) are connected to 100 MBS fastethernet desktops and don't
show any collisions...I understand why.
I also have another 3640 ("router2") connected to the same switches, in
the
same manner...for redundancy, I'm told. There are a couple of other 3500
XL
switches cascaded from these...to accommodate the number users. The LAN
size is about 125 nodes with about equal number of nodes connected to each
subnet. I'm new here...I have recommended getting rid of the subnetting
scheme in favor of a classful LAN. Anyway, the switch ports that are
connected to "router2" don't show any collisions/crc errors.
This all started 2 weeks ago. The network has been designed this way for
about a year.
In short, I can't determine whether routing loops are causing the
collisions
(and if so, why only on "router1"), or whether there's a port
configuration
mismatch between "router1"s Ethernet ports and the switch. Or, maybe some
piece of hardware has just failed? Any suggestions are welcome.
Jim McDowell
Cisco Certified Network Professional
Network Administrator
Copley Information Systems
858.729.8028
_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: CRC errors on Catalyst 3500 XL port
Hi,
I have a 3640 ("router1") with IOS v11.2 which is routing between IP subnets
(class "c" with a one bit subnet mask - using "IP subnet-zero").
More accurately, you have a /25 subnet. Classful is dead.
There are
two Ethernet ports on the router, each is connected to a separate Catalyst
3500 XL switch. The two switch ports are hard set to 10 MBS, duplex
autonegotiate, spanning-tree on, portfast on. I am seeing collisions and
crc errors on the switch ports that are connected to "router1". The
remainder of the switch ports ( with the exception of a few ports which I'll
explain shortly ) are connected to 100 MBS fastethernet desktops and don't
show any collisions...I understand why.
I also have another 3640 ("router2") connected to the same switches, in the
same manner...for redundancy, I'm told. There are a couple of other 3500 XL
switches cascaded from these...to accommodate the number users. The LAN
size is about 125 nodes with about equal number of nodes connected to each
subnet. I'm new here...I have recommended getting rid of the subnetting
scheme in favor of a classful LAN.
Why? What's wrong with subnetting? Classful or classless, you still
have subnetting when you have IP.
Anyway, the switch ports that are
connected to "router2" don't show any collisions/crc errors.
This all started 2 weeks ago. The network has been designed this way for
about a year.
Probably a difference in duplex. But is there a problem?
In short, I can't determine whether routing loops are causing the collisions
(and if so, why only on "router1"), or whether there's a port configuration
mismatch between "router1"s Ethernet ports and the switch. Or, maybe some
piece of hardware has just failed? Any suggestions are welcome.
Jim McDowell
Cisco Certified Network Professional
Network Administrator
Copley Information Systems
858.729.8028
_
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
_
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
CRC errors on ISDN Interface
I have a problem with an ISDN circuit that keeps on dropping off. When I look at the BRI interface I see CRC errors. I have swapped out the patch cable going to the providers jack, I swapped out the router and the ISDN WIC but I still keep on getting the CRC errors. The provider has checked the line and they said the line is ok. This router keeps on dropping off and the customer is now getting upset. Any idea have any ideas what I can check or try next? Thanks _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: CRC errors on ISDN Interface
are you using voice modems or is it strickly isdn data? -Original Message- From: Stephen Robichaud [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, March 06, 2001 1:39 PM To: [EMAIL PROTECTED] Subject:CRC errors on ISDN Interface I have a problem with an ISDN circuit that keeps on dropping off. When I look at the BRI interface I see CRC errors. I have swapped out the patch cable going to the providers jack, I swapped out the router and the ISDN WIC but I still keep on getting the CRC errors. The provider has checked the line and they said the line is ok. This router keeps on dropping off and the customer is now getting upset. Any idea have any ideas what I can check or try next? Thanks _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: CRC errors on ISDN Interface
When you say the provider has checked the line, are you saying the ISP ??? The Telco's CLEC's have a lot of expensive equipment to test these lines. I worked for a CLEC that used Harris Turnstone line testers from the CO (copper termination) to the Demark. @ the prem there are testers called the Sunrise Sidekick ( not all techs know how to use them). Unless you've had the Telco out to stress the line, I don't think you could rule it out. Ultimately you may have a bad copper pair on the F1, F2, or inside wiring. Also- there is a situation dealing with too many "High Cap" circuits in a bundle. ISDN (like DSL) is very susceptible to noise or bleed. Good Luck Phil - Original Message - From: "Stephen Robichaud" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 06, 2001 4:38 PM Subject: CRC errors on ISDN Interface I have a problem with an ISDN circuit that keeps on dropping off. When I look at the BRI interface I see CRC errors. I have swapped out the patch cable going to the providers jack, I swapped out the router and the ISDN WIC but I still keep on getting the CRC errors. The provider has checked the line and they said the line is ok. This router keeps on dropping off and the customer is now getting upset. Any idea have any ideas what I can check or try next? Thanks _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: CRC errors on ISDN Interface
You don't say what type of IDSN connection you have. Is the customer connecting from one site to another (internal) site? Are they connecting to an ISP? Do you have control of both sides of the BRI (calling site and called site)? Just off the cuff, I'd suspect that there's a bad line card at the CO. If this is the case, it's totally possible for the telco tech guy to stress the line and still not see the problem. Unfortunately, I've encountered it several times and it's often not easy to get a resolution. The usual telco response is "We don't have a problem...we've tested the line and it has to be your equipment." If you press them on the issue, they usually admit that they're testing the B channels, but not really looking at what the D channel is doingand sometimes it's an error that doesn't appear until the line has been operational for some time. Ask them if it could be a problem at one of the COs (either at the calling site or the called site) and escalate it until you get someone willing to listen and actually check into your problem. Good luckexperience says that you'll need it. ;-) Let the group know how you make out. Craig At 01:38 PM 3/6/2001 -0500, you wrote: I have a problem with an ISDN circuit that keeps on dropping off. When I look at the BRI interface I see CRC errors. I have swapped out the patch cable going to the providers jack, I swapped out the router and the ISDN WIC but I still keep on getting the CRC errors. The provider has checked the line and they said the line is ok. This router keeps on dropping off and the customer is now getting upset. Any idea have any ideas what I can check or try next? Thanks _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: CRC errors on ISDN Interface
Hi, There are several places this can break. IF the line tests ok I can understand this. Here is a couple of things you might look at. Are the CRC's seen on both ends of the link. (If so then there is a chance it is on the line side) If not then almost certainly the problem will be at the end with the CRC's between the NT1 and the router. My experience has been most often this is a cable and/or the comb in the RJ45 socket. Another common problem is dry joints in the building wiring. Often these are not picked up in tests as the voltages used by test equipment 'blows trhe dust out'. In one case I had it was indeed water. We are really trying to identfy is it in the two wire cct between the sites or the 4 wire cct within a site. Just some thoughts. Teunis Hobart, Tasmania Australia On Tuesday, March 06, 2001 at 01:38:35 PM, Stephen Robichaud wrote: I have a problem with an ISDN circuit that keeps on dropping off. When I look at the BRI interface I see CRC errors. I have swapped out the patch cable going to the providers jack, I swapped out the router and the ISDN WIC but I still keep on getting the CRC errors. The provider has checked the line and they said the line is ok. This router keeps on dropping off and the customer is now getting upset. Any idea have any ideas what I can check or try next? Thanks _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] -- www.tasmail.com _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: CRC errors on ISDN Interface
I read you original post and just kinda scratched my head. But now that Teunis brought up the building wiring I remember a colleague with the same problem that boiled to an oxidized terminal block in the damp basement of his building. Tim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tony van Ree Sent: Tuesday, March 06, 2001 11:06 PM To: Stephen Robichaud; [EMAIL PROTECTED] Subject: Re: CRC errors on ISDN Interface Hi, There are several places this can break. IF the line tests ok I can understand this. Here is a couple of things you might look at. Are the CRC's seen on both ends of the link. (If so then there is a chance it is on the line side) If not then almost certainly the problem will be at the end with the CRC's between the NT1 and the router. My experience has been most often this is a cable and/or the comb in the RJ45 socket. Another common problem is dry joints in the building wiring. Often these are not picked up in tests as the voltages used by test equipment 'blows trhe dust out'. In one case I had it was indeed water. We are really trying to identfy is it in the two wire cct between the sites or the 4 wire cct within a site. Just some thoughts. Teunis Hobart, Tasmania Australia On Tuesday, March 06, 2001 at 01:38:35 PM, Stephen Robichaud wrote: I have a problem with an ISDN circuit that keeps on dropping off. When I look at the BRI interface I see CRC errors. I have swapped out the patch cable going to the providers jack, I swapped out the router and the ISDN WIC but I still keep on getting the CRC errors. The provider has checked the line and they said the line is ok. This router keeps on dropping off and the customer is now getting upset. Any idea have any ideas what I can check or try next? Thanks _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] -- www.tasmail.com _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
CRC Errors
What are CRC errors on a fiber link indicative of? The fiber tests pass on both channels. _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
