Can anyone please let me know what causes the following
5.High bandwidth utilization
6.Also one of the most important what causes the route flap in OSPF very often
How to overcome this things, any information or any resources for the above mentioned things would be really appreciable.
1 could be faulty cable
2 faulty sfp
3 ? this is a protocol , do you men by what causes It to flap ? , if you mean BFD flaps there could be multiple reasons you would need to check what happened when it occurs, was it the cable, the device or the timers to aggressive that caused it , interface overloaded etc
4 this could be 1 or 2 above or other reasons like faulty port , faulty software too
5 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
6 Again could be multiple reasons the questions very generic , anything from bad cable bad nic wrong timers , bad config etc
for documentation if you Google any of these issues there are pages of troubleshooting guides available or check the forum here the documents section too
Thank you for replying.
I have tried googling all those things, but didn't find any specific or obvious reason to conclude the search.
Can you please let me know any specific resources or links that could really help me out with these things.
Thanks once again mark. really appreciate your help.
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
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.
1.The port is placed in error-disabled state after SFP is inserted.
This problem is usually caused by bad or non-Cisco-approved SFP module(ie. the incompatible SFP).
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.
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.
3.Excessive errors found in port statistics.
Bad adapter in attached device or STP checking for possible loops can cause this problem.
Run adapter card diagnostic utility and wait 30 seconds for the port LED to turn green.
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
this could be 1 or 2 above or other reasons like faulty port , faulty software too.
Also check this link for incremental error
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
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 126.96.36.199 [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 188.8.131.52, LSA type R
184.108.40.206 is the duplicate router ID. This tells you that two routers in Area 0 must be having this same ID of 220.127.116.11
Hope this will be helpful