Bad LAN connection between a cisco 2811 and a switch

[Philidor]

A Cisco 2811 Fa0/0 is connected to a Cisco WS-C4507R Gig 3/11 through one Km of mono-modal optical fiber and 2 copper-fiber converter (one near the router and the other one near the switch).

We very very often get the following alarms. We've already unsuccessfully tried to replace the cisco 2811. We moved to another switch and switch port. We've replaced all the cables and the copper-fiber converter.

Jan 26 12:17:48.460: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
Jan 26 12:17:48.480: %PIM-5-NBRCHG: neighbor 172.31.88.220 DOWN on interface FastEthernet0/0 non DR
Jan 26 12:17:48.480: %PIM-5-NBRCHG: neighbor 172.31.88.222 DOWN on interface FastEthernet0/0 non DR
Jan 26 12:17:50.200: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
Jan 26 12:17:52.036: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
Jan 26 12:17:53.668: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 172.31.88.218 on interface FastEthernet0/0
Jan 26 12:17:53.692: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
Jan 26 12:17:54.460: %SYS-6-LOGGINGHOST_STARTSTOP: Logging to host 172.28.1.7 port 514 started - reconnection
Jan 26 12:17:56.620: %PIM-5-NBRCHG: neighbor 172.31.88.220 UP on interface FastEthernet0/0
Jan 26 12:17:56.628: %PIM-5-DRCHG: DR change from neighbor 172.31.88.218 to 172.31.88.220 on interface FastEthernet0/0
Jan 26 12:17:56.636: %PIM-5-NBRCHG: neighbor 172.31.88.222 UP on interface FastEthernet0/0

Here is it the Fa0/0 and the Gig3/11 configuration:

interface FastEthernet0/0
ip address 172.31.88.218 255.255.255.248
ip helper-address 10.130.0.135
ip pim sparse-dense-mode
ip virtual-reassembly
duplex auto
speed auto
no mop enabled
end

interface GigabitEthernet3/11
logging event link-status
power inline never
spanning-tree portfast

end

[Leo Laohoo]

---

@Philidor wrote:

We've replaced all the cables and the copper-fiber converter.

---

What about an OTDR?

[bondock]

do you mean the command show cable-diagnostics tdr?

[Squozen_EU]

I believe Leo means a real cable testing unit. https://www.flukenetworks.com/expertise/learn-about/otdr

[Leo Laohoo]

---

@bondock wrote:

do you mean the command show cable-diagnostics tdr?

---

TDR diagnoses copper cable. 

OTDR diagnoses fibre optic path.

[Philidor]

Fiber has been tested and certified. The few meters of UTP cables have been replaced. We still need to check if the media converters are just a piece of iron or if it is for example possible on them to force the speed to 100 or leave it in auto mode (router fa0/0 setup is auto mode).

We could also try to eliminate the media converter near the switch and enter into the switch directly with the optical fiber cable or, as last chance, change the whole router with a new one with a Giga eth interface.

[Leo Laohoo]

---

@Philidor wrote:

Fiber has been tested and certified.

---

When where the fibre tested and certified?  Was the entire fibre path tested and certified around the time this issue started?

Post the complete output to the command "sh interface F0/0".

[Philidor]

The fiber path has been successfully tested after that we detected the problem to ensure its integrity.

Please note after this show I've cleared the interface counters

sh int fa0/0
FastEthernet0/0 is up, line protocol is up
Hardware is MV96340 Ethernet, address is 0026.9992.f858 (bia 0026.9992.f858)
Internet address is 172.31.88.218/29
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4946
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 1 packets/sec
5 minute output rate 0 bits/sec, 1 packets/sec
850144901 packets input, 176614315 bytes
Received 13163312 broadcasts, 1 runts, 0 giants, 0 throttles
47 input errors, 36 CRC, 10 frame, 0 overrun, 0 ignored
0 watchdog
0 input packets with dribble condition detected
789545737 packets output, 56792453 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out

[Leo Laohoo]

---

@Philidor wrote:

The fiber path has been successfully tested after that we detected the problem to ensure its integrity.

---

Depends on the budget, there are several ways to test the fibre path, however, there is only one way to really test it and it is an OTDR.  We still do not know WHAT testing method was used.  Was the test a OTDR or something else (like a loopback plug)?

[Philidor]

I can't be fully sure but I believe an OTDR has been run. Fiber attenuation is fine and equal to 3,697 dB/km (Fiber 1) and 4,263 dB/km (Fiber 2)

[Leo Laohoo · Accepted solution]

---

@Philidor wrote:

I can't be fully sure but I believe an OTDR has been run. 

---

That is a very dangerous and time-delaying presumption.  

When in doubt, get it done.  Again, if necessary.