Device can't communicate

[mdieken011]

I have a stack of 4 WS-C3850-12X48U and I have a port channel going back to my core switch.  On occasion a single device will not be able to communicate outside of this switch.  I have 9 other wiring closets with these identical switches.  I do not have the issue in any other wiring closet.  The configuration for the ports is below.  I am running 03.07.03E code.

interface Port-channel101
 switchport trunk allowed vlan 2,11,12,14,17-19,401,405,700,900
 switchport mode trunk
end

interface TenGigabitEthernet1/1/4
 switchport trunk allowed vlan 2,11,12,14,17-19,401,405,700,900
 switchport mode trunk
 auto qos trust dscp
 channel-group 101 mode active
 service-policy input AutoQos-4.0-Trust-Dscp-Input-Policy
 service-policy output AutoQos-4.0-Output-Policy
end

interface TenGigabitEthernet4/1/4
 switchport trunk allowed vlan 2,11,12,14,17-19,401,405,700,900
 switchport mode trunk
 auto qos trust dscp
 channel-group 101 mode active
 service-policy input AutoQos-4.0-Trust-Dscp-Input-Policy
 service-policy output AutoQos-4.0-Output-Policy
end

[Julio E. Moisa]

Hi,

Try to configure the following under the interface PO 101

interface Port-channel101

auto qos trust dscp
service-policy input AutoQos-4.0-Trust-Dscp-Input-Policy
 service-policy output AutoQos-4.0-Output-Policy

[mdieken011]

auto qos is not an option in the port channel config

Switch#config t
Enter configuration commands, one per line.  End with CNTL/Z.
Switch(config)#int po101
Switch(config-if)#auto ?
  security-port  Configure AutoSecurity

Switch(config-if)#auto

[Georg Pauwen]

Hello, 

is that single device always in a specific VLAN ? Is that just a 'normal' client device, such as a Windows PC ? Getting its IP address via DHCP ?

It is always a good idea to check the VTP status of all switches, and to make sure the (core switch in your case, most likely) is the root for all VLANs...

[mdieken011]

This is happening with about 4 windows PC's and either changing the MAC address of the device or moving ports in the stack typically fixes this.  This is why I suspect the port channel is causing this.  I have 9 other closets identically configured and they are NOT having any issues.

[Georg Pauwen]

Hello,

changing the MAC address or moving ports fixes it...do you have sticky MAC configured ?

Can you post the config of a 'problem' port ?

[mdieken011]

It's pretty simple config really.

interface GigabitEthernet1/0/30
 switchport access vlan 11
 switchport mode access
 switchport voice vlan 14
 trust device cisco-phone
 auto qos voip cisco-phone
 spanning-tree portfast
 service-policy input AutoQos-4.0-CiscoPhone-Input-Policy
 service-policy output AutoQos-4.0-Output-Policy
end

The devices that this happens to can communicate with other devices on the same VLAN when it happens.  They can't get to the core L3 switch when this occurs.

[Georg Pauwen]

Hello,

the port configuration looks normal. Are these devices getting their addresses through DHCP ? If so, does the problem persist when you assign a static IP address ?

Which image are you running (e.g. Lanbase) ?

[mdieken011]

Yes, they get the address from DHCP.  The devices have a valid IP address and are able to ping other devices on the same switch stack.  When they try to go across the port channel that is what is broken.

[Georg Pauwen]

Hello,

I don't think the port channel (or the configuration of the port channel) is the problem. It sounds more like a random problem with random devices. 

Switch uptime can sometimes be a problem, have you tried rebooting the 'problem' switch(es) ?

Also, the physical ports are grouped (usually 1-4, 5-8, and so on, are physically connected to the same ASIC), can you detect a pattern there ?

Something might show up in the output of 'show interfaces x', can you post the output of one of the ports that is having problems ?

Regarding the configuration of the access ports, you might want to try and configure 'flowcontrol receive on'...

[mdieken011]

Georg, the switch stack has been up for about 1 year now.  I have not tried to reboot it since it is in production and I haven't wanted to cause an outage.  The port channel is using ports from different switches for redundancy.  Therefore it is not using the same ASIC's.  A "show interface x" does not show anything that stands out.  I will look into flow control on those ports.

[paul driver]

Hello

This is happening with about 4 windows PC's and either changing the MAC address of the device or moving ports in the stack typically fixes this.  This is why I suspect the port channel is causing this.  I have 9 other closets identically configured and they are NOT having any issues.

Apologies for so many questions:
Are these always the same ports you have issues with or various?
My first thought would be to check the qos mappings if these clients are voip phones with users attached to the phone, but you say you move them to different ports withing the same stack and they begin to work.

Does the etherchannel or access ports show any errors?
Does the switch stack show any inconsistencies  ( ring speed, full-partial config etc..)
Do you have vtp pruning enabled,aswell as your manual pruning?
Is this switch stack a host stack? ( ip routing disabled)

If the etherchannel is problematic then i would expect more than 4 hosts having issues, Anyhow have you tried re-creating the L2 PC from scratch?

1) default the physical interfaces and shut them down
2) apply the physical interfaces configuration, in this case auto-quos, service-policy, and lastly channel-group
3) let the logical PC get created and then apply the trunk config on it ( including switchport trunk allowed vlan)
4) enabled physical interfaces

sh mls qos maps cos-dscp
sh mls qos maps dscp-cos
sh mls qos interface x/x
sh etherchannel port-channel
sh etherchannel summary | be 101
sh etherchannel load-balance
sh int trunk
sh interfaces port-channel 101 pruning
sh vtp status
sh switch
sh switch stack-ring speed

res
Paul