cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1928
Views
0
Helpful
2
Replies

SFP on 3850 became unknown.

We have 2*c3850-48p in stack

ver 03.02.03.SE

We use 8 SFP as one trunk.

Suddenly 4 sfp became unknown, but link was active.

Gi2/1/1                      connected    trunk      a-full a-1000 unknown
Gi2/1/2                      connected    trunk      a-full a-1000 unknown
Gi2/1/3                      connected    trunk      a-full a-1000 unknown
Gi2/1/4                      connected    trunk      a-full a-1000 unknown

As soon as interface was still up and connected - packets were still redirected to this links, but packets were dropped.

So some users lost connection to some services connected to this stack. (4 links out of 8 were still active)

I have disabled these ports and reinserted SFP's, but that helped only for 3 of 4 links.

Gi2/1/1 disabled trunk auto 1000 1000BaseLX SFP
Gi2/1/2 disabled trunk auto auto unknown
Gi2/1/3 connected trunk full 1000 1000BaseLX SFP
Gi2/1/4 connected trunk full 1000 1000BaseLX SFP

After that i have replaced SFP's to NEW, but links are still same.

SFP's can be seen via show int trans det


                                 Optical   Optical
           Temperature  Voltage  Tx Power  Rx Power
Port       (Celsius)    (Volts)  (dBm)     (dBm)
---------  -----------  -------  --------  --------
Gi1/1/1      35.2       3.30      -7.3      -6.6   
Gi1/1/2      34.0       3.30      -7.2      -6.2   
Gi1/1/4      47.1       3.27      -7.4      -4.8   
Gi2/1/1      44.6       3.27      N/A       -6.9   
Gi2/1/2      46.1       3.26      N/A       -7.4   
Gi2/1/3      45.5       3.27      N/A       -7.4   
Gi2/1/4      44.5       3.26      N/A       -6.4  

Switch is broken or what else?

1 Accepted Solution

Accepted Solutions

Marvin Rhoads
Hall of Fame
Hall of Fame

It's hard to say whether that's a bug or a failing network module. You could schedule some downtime and swap the network modules from one stack member to another and see if the issue follows the module.

I didn't find a specific bug I could point to but that IOS is very old in 3850 terms - from the first set of releases that came out in 2013. There are a fair number of SFP-related bugs in the older 3850 code:

https://tools.cisco.com/bugsearch/search?kw=sfp&pf=prdNm&pfVal=284455437&sb=anfr

The current recommended version is 3.6.3E from August 2015.

https://software.cisco.com/download/release.html?mdfid=284455436&flowid=37774&softwareid=282046477&release=3.6.3E&relind=AVAILABLE&rellifecycle=MD&reltype=latest

I''d open a TAC case and/or upgrade the software.

View solution in original post

2 Replies 2

Marvin Rhoads
Hall of Fame
Hall of Fame

It's hard to say whether that's a bug or a failing network module. You could schedule some downtime and swap the network modules from one stack member to another and see if the issue follows the module.

I didn't find a specific bug I could point to but that IOS is very old in 3850 terms - from the first set of releases that came out in 2013. There are a fair number of SFP-related bugs in the older 3850 code:

https://tools.cisco.com/bugsearch/search?kw=sfp&pf=prdNm&pfVal=284455437&sb=anfr

The current recommended version is 3.6.3E from August 2015.

https://software.cisco.com/download/release.html?mdfid=284455436&flowid=37774&softwareid=282046477&release=3.6.3E&relind=AVAILABLE&rellifecycle=MD&reltype=latest

I''d open a TAC case and/or upgrade the software.

Well, reboot restored SFP state, and after IOS upgrade this issue haven't appeared again.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: