Cisco 3850 with C3850-NM-2-10G Module - Te1/1/3 and Te1/1/4 Intermittent Bouncing

[chefwearer]

Anyone else out there have any Cisco WS-C3850-24XU-L switches deployed with the C3850-NM-2-10G module and experiencing Te1/1/3 and Te1/1/4 going up/down every so often? In my scenario, Te1/1/3 and Te1/1/4 are in a PAGP port-channel. My environment has a slew of new 3850's that are doing this, though some are not. There is no consistency to the time frame between interface up/down events. Code on most of the 3850's is 03.07.04E. I have tried upgrading one to 03.07.05E, and rebooting others but the issue persists. I'm using SFP-10G-LRM optics on all links over multi mode fiber runs of up to roughly a hundred meters or so. 

Here's a sample of the interface configs on the 3850:

interface TenGigabitEthernet1/1/3
switchport mode trunk
channel-protocol pagp
channel-group 1 mode auto
end

interface TenGigabitEthernet1/1/4
switchport mode trunk
channel-protocol pagp
channel-group 1 mode auto
end

interface Port-channel1
switchport mode trunk
end

And for what it's worth, here's a sample of the neighbor switch configuration on the port-channel (a cisco 4500):

interface TenGigabitEthernet7/1
channel-protocol pagp
channel-group 21 mode desirable
service-policy output uplink-physical-port-qos-out
end

interface TenGigabitEthernet7/4
channel-protocol pagp
channel-group 21 mode desirable
service-policy output uplink-physical-port-qos-out
end

interface Port-channel21
switchport

Here's log output from one of the 3850's experiencing the bouncing. Some 3850's occasionally show the SFP being removed/replaced instantly:

Mar 28 11:33:53.617: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/1/4, changed state to down
Mar 28 11:34:05.359: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/1/4, changed state to up
Mar 28 12:38:46.708: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/1/3, changed state to down
Mar 28 12:38:52.416: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/1/3, changed state to up
Mar 28 23:35:59.869: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/1/4, changed state to down
Mar 28 23:36:11.909: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/1/4, changed state to up

[chrihussey]

Just checking, but is the 4500 end configured as a trunk? Does it also drop at the 4550?

Suggest that you take one switch, remove the port channel configuration and make it a direct link to determine if this is more of a physical issue.

Lastly, is the fiber FDDI grade (OM1/2) or OM3/4? If it is FDDI grade you may need to use mode conditioning patch cords. But as stated the first thing to do is determine if it is a physical issue.

Hope this is of some help.

[chefwearer]

The 4500 ends up negotiating as a trunk:

Cisco4500#sh int po21 trunk

Port Mode Encapsulation Status Native vlan
Po21 auto 802.1q trunking 1

Yes, the 4500 side also drops. The following logs from the 4500 correspond with the 3850 logs I posted before:

Mar 28 23:35:58.874: %EC-5-UNBUNDLE: Interface TenGigabitEthernet7/4 left the port-channel Port-channel21
Mar 28 23:35:58.978: %EC-5-UNBUNDLE: STANDBY:Interface TenGigabitEthernet7/4 left the port-channel Port-channel21
Mar 28 23:36:31.379: %EC-5-BUNDLE: Interface TenGigabitEthernet7/4 joined port-channel Port-channel21
Mar 28 23:36:31.486: %EC-5-BUNDLE: STANDBY:Interface TenGigabitEthernet7/4 joined port-channel Port-channel21

I may consider troubleshooting the links individually, but will probably look to troubleshooting the PO config next, specifically, trying out LACP in place of PAGP, and if that doesn't work, trying no negotiation protocol (channel-group mode on). 

I was told it's OM4 fiber, and we use laser optimized (aqua color) patch cables. 

I appreciate your quick input!