SFP/Port-channel 9500/ASR1001/3850

Hi Team,

Hope you can you help me? I have some inconsistent behaviour with some connections between switches.

I have two separate scenarios that may or may not be related.

Scenario one

I have a 3850-switch stack Version 16.12.11 stack members up and functional. This has a single connection from switch 1 that connects to a 3750-x and another single connection from switch 2 connecting to another 3750-X both connections are MM fibre.

I can confirm there are no physical issues all links successfully tested all modules tested, all SFPs tested and work. Link one on both ends of the link come UP/UP and I can see packets being sent out from both ends 3850 and 3750 however no packets being received. When I move the link from switch 1 into a free port on switch 2 at the 3850 end traffic passes. I have tried a known working module know working SFPs different ports but this link does not pass traffic on switch 1 from 3850 stack.

I did see that the H/W versions are different within the stack are you aware of any issues that you may have come across that indicates that you need to use different port modules for V05 or V06 or are aware of logic issues mixing switch H/W versions.

sho switch

Switch/Stack

                                         H/W   Current

Switch# Role Mac Address Priority Version State

-------------------------------------------------------------------------------------

*1 Active 15 V05 Ready

2 Standby 14 V06 Ready

Scenario two

I have a 9500 stack wise virtual switch. 9500-40X that connects to two ASR1001 routers. I have two connections going to each ASR1001 router these are configured as LACP Port-channel.

I am using GLC-TE 1g SFP’s these are apparently genuine Cisco SFP’s in the past I have had issues with ASR1001 routers accepting the GLC-TE sfp’s even when they are Cisco braded. Fibre optic SFPs seem to have no issues whatsoever, I have checked Cisco’s compatibility matrix and both 9500 and ASR1001 should support these SFP’s.

The scenario I have on site Is I have 2x 9500-40Xs connected as a stack wise virtual I also have DAD Link configured. I have2x1 GLC-TE copper connection from each switch going to each of the ASR’s these are configured as a PO.

Connection table

ASR1001-r1 Gi 0/0/0 (GLC-TE V A1) ----------------- 9500-40-x 1/0/31 (GLC-TE V01) UP/UP

ASR1001-r1 Gi 0/0/1 (GLC-TE V A) ----------------- 9500-40-x 2/0/31(GLC-TE V03) DOWN/DOWN

I think the ASR is down because of the module and the fact the ASR seem to be fussy.

ASR1001-r2 Gi0/0/0(GLC-TE) ----------------- 9500-40-x 1/0/32(GLC-TE V01) UP/UP

ASR1001-r2 Gi0/0/1(GLC-TE) ----------------- 9500-40-x 2/0/32 (GLC-TE V03) FLAPPING

Again I have a switch H/W mismatch are you aware of PO issues when mixing H/W versions/

sho switch

Switch/Stack Mac Address : Local Mac Address

Mac persistency wait time: Indefinite

                                         H/W   Current

Switch# Role Mac Address Priority Version State

-------------------------------------------------------------------------------------

*1 Active 15 V02 Ready

2 Standby 14 V01 Ready

ASR IOS-XE Version 15.5(3)S2

9500-40x IOS-XE Version 17.12

I have other sites with no issues between the ASR and 9500s the only difference is I use fibre between the connections and the other sites the 9500’s are on the same H/W version all using V01’s

I’m wondering if you are aware of any issues with H/W version mixing within a stack or Copper interoperability connections within Po between the ASRs and 9500

Hello Jason

Thanks for sharing your scenario with such detail, it’s always helpful when there’s enough info to formulate a more complete response. I haven’t had an experience similar to what you describe, in either scenario, but I can share with you what I believe to be the likely causes, and make some suggestions that may lead you in the right direction in your troubleshooting process.

For your first scenario, this is likely a hardware version incompatibility issue with the network modules, not the base switches themselves. Hardware version mixing in stacks (V05/V06) is generally supported, BUT the network modules/uplink modules must be compatible. The 3850 uses optional network module slots, so first check if you’re using different module types:

  • C3850-NM-4-1G
  • C3850-NM-4-10G
  • C3850-NM-2-40G

Next, you can check module details on both switches using:

  • show module
  • show inventory
  • show platform software fed switch 1 port-map
  • show platform software fed switch 2 port-map

Then, check for any error messages specific to switch 1
show log | inc switch 1|%SFP

Finally, verify SFP compatibility

  • show interfaces Te1/x/x transceiver
  • show interface status err-disabled

When you examine these issues:

  • Verify the network module part numbers match between switch 1 and 2
  • Check for any field notices: Search Cisco.com for “3850 hardware version incompatibility”
  • Consider using identical hardware modules across the stack (if available) and examine their behavior to see if those differences are the issue
  • If modules are different, try swapping modules between switch 1 and 2 to isolate if it’s module-specific

Hopefully, this process will help you isolate the specific issue causing this behavior.

For scenario 2, things are somewhat clearer. After doing some research, I have found that although officially the SFP you’re using is supported, the ASR1001-X running IOS-XE 15.5(3)S2 has some issues with certain GLC-TE hardware versions, as seen in this Cisco community post.

Secondly, there may be an IOS version mismatch issue. Note that the IOS-XE 15.5(3)S2 used by the ASR was released in 2016 while the 9500’s IOS-XE 17.12 is current as of today.
This is a 9+ year gap in software versions, which may be a significant risk for interoperability issues, especially undocumented ones.

I don’t have an immediate solution that will not require upgrading or replacing equipment. However, if you do have a Cisco contract, opening a TAC case may be worth it, as the issue may introduce a new bug that Cisco will publish, and they will provide you with a workaround. Hopefully this has helped to nudge you in the right direction. Let us know how you proceed and what your results are!

I hope this has been helpful!

Laz