CRC error
CRC error are mostly for faulty cable moreover check below for CRC error, farme error and few useful links to trouble shoot these type of problems
The CRC error rate is 1.75915% (greater than 1 in a million packets),
and the collision rate is less than 0.1%.
This can indicate excessive noise or transmission problems on the LAN or the LAN
bus itself. A high number of CRCs is usually the result of collisions or a station
transmitting bad data.
TRY THIS: Check cables to determine whether any are damaged. If 100BaseTX is being
used, ensure Category 5 cabling is being used and not another type, such as Category
3.
There have been 1599 'frame errors' reported.
This indicates the number of packets received incorrectly, having a CRC error
and a non-integer number of octets. On a LAN, this is usually the result of collisions
or a malfunctioning Ethernet device.
TRY THIS: Monitor the level of frame errors over time. If they are increasing,
try swapping interfaces and or ports to identify the problem.
http://www.cisco.com/en/US/customer/products/hw/modules/ps2033/products_tech_note09186a008009446d.shtml
http://www.cisco.com/en/US/docs/internetworking/troubleshooting/guide/tr1904.html
http://www.cisco.com/en/US/docs/internetworking/troubleshooting/guide/tr1904.html
======================================
SPF errors
1.The port is placed in error-disabled state after SFP is inserted.
Possible Cause:
This problem is usually caused by bad or non-Cisco-approved SFP module(ie. the incompatible SFP).
Resolution:
Remove the SFP module from the switch and replace it with a Cisco-approved module. Use the irrdisable recovery cause GBIC-invalid global configuration command to verify the port status, and enter a time interval to recover from the error-disable state. The best advice is to use the Cisco original SFP or 100% Cisco compatible SFP (If you decide to use a third-party SFP, please ensure that your supplier is assured) that is adapted to the switch.
2.Device does not recognize the SFP module.
Possible Cause:
This problem is generally related to the SFP installation. Situations, such as SFP is installed upside dowm or does not snap into the slot can cause this problem.
Resolution:
- Verify that the SFP module is not installed upside down.
- Remove the SFP module. Inspect for physical damage to the connector, the module, and the module slot.
- Replace the SFP module with a known good SFP module.
3.Excessive errors found in port statistics.
Possible Cause:
Bad adapter in attached device or STP checking for possible loops can cause this problem.
Resolution:
Run adapter card diagnostic utility and wait 30 seconds for the port LED to turn green.
===========
BFD timers(ospf)
The BFD protocol is a simple hello mechanism that detects failures in a network. The BFD failure detection timers have shorter timer limits than the OSPF failure detection mechanisms, thereby providing faster detection. BFD is useful on interfaces that are unable to detect failure quickly, such as Ethernet interfaces
http://www.cisco.com/en/US/technologies/tk648/tk365/tk480/technologies_white_paper0900aecd80244005.html
==============
Incremental error
this could be 1 or 2 above or other reasons like faulty port , faulty software too.
Also check this link for incremental error
https://supportforums.cisco.com/document/14776/runts-and-crc-errors-increment-show-interface-command-output-cisco-ios-based-switch
=================================
High bandwidth utilization
Could be many reasons , too much devices a segment has ,too much traffic generally for the device to handle , you need to spec before you buy and make sure your traffic volume will not overload the network
=========================================================
Route-flapping in OSPF Network
A route is said to be flapping when it keeps saying “Now you see me, now you don’t, Now you see me, now you don’t”…many times over…. Its availability keeps going up and down, flapping as it were or fluctuating frequently.
OSPF neighbours exchange hello messages to let each other know, “Hey, am still available, am still reachable, and still a participating member of the OSPF process”. By default, hello messages are sent every 10 Seconds (i.e Hello Interval/Timer) on broadcast networks (e.g Ethernet) and every 40 seconds on Non-Broadcast networks. The Dead Interval will be four times the Hello Interval (40 or 120 seconds) again depending on the interface type.
If a OSPF router doesn’t receive 4 hello packets (e.g in 40seconds) from its neighbour, it will safely assume that its neighbour is unreachable/down and subsequently purges all the routes from its routing table that were once reachable via this neighbour. (Hence the name dead Interval/Timer)
Major causes of route flapping in OSPF are:
• Unstable links within the network
• Unstable neighbor(s) within the network
• Duplicate router ID within the network
Whenever there is a change in topology, (e.g. neighbour goes down, then up again) OSPF will run the SPF algorithm afresh to re-calculate the shortest path to all available destinations.
To detect route flapping, the command “show ip ospf | include SPF algorithm executed” is useful. It will tell you how many times the SPF algorithm has run. When theres a route flap, you’ll see something like:
Router#show ip ospf | include SPF algorithm executed
SPF algorithm executed 15378 times
That’s an insane number of SPF executions.
Another way is by use of the good old show ip route command. The output will be something like this below:
R2#show ip route ospf
O 1.1.1.1 [110/2] via 192.168.12.1, 00:00:43, FastEthernet1/0
You will notice that all OSPF advertised routes are always less than a minute old. (00:00:43 seconds have passed since this route was installed in the Routing table)
Another useful command is debug ip ospf monitor command is also very useful, because it pinpoints exactly where the problem is. Sample output is shown below:
Router# debug ip ospf monitor
OSPF: Schedule SPF in area 0.0.0.0
Change in LS ID 3.3.3.3, LSA type R
3.3.3.3 is the duplicate router ID. This tells you that two routers in Area 0 must be having this same ID of 3.3.3.3
http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/19167-bgp-rec-routing.html
===============
Hope this will be helpful
