| |
Bug Id: | CSCut26365 |
Title: | Packet drop on 3850 by an unrelated ACL entry |
|
Description: | Symptom:
TCP ack packet is discarded by unrelated ACE on 3850.
Conditions:
"establish" option is used.
Workaround:
The problem happened with tcp flags which have multiple bit set. If customer cofig as separate bit, then there is no issue.
The ace: deny tcp any any eq ftp established
Configured as two aces (because the tcp flag establish means "ack or rst"
deny tcp any any eq ftp ack
deny tcp any any eq ftp rst
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 3.7(0)E |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCue60618 |
Title: | Katana: ability to shut NMSP (default) service on TCP port 16113 |
|
Description: | Symptom: Katana: ability to shut NMSP (default) service on TCP port 16113.
Conditions: This symptom is observed in the default configuration.
Workaround: There is no workaround.
More Info: After this fix, the NMSP feature needs to be explicitly enabled using CLI nmsp enable. This change satisfies the security baseline requirement that no TCP ports should be open as a default option. The NMSP port 16113 can now be disabled with CLI no nmsp enable which was not an option before this fix.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | n/a |
|
Known Fixed Releases: | 10.1(0.22), 10.1(100.0), 10.2(1.1), 10.2(1.25), 15.0(1)EZ, 15.0(10.1)PKD, 15.0(11.11)EMW, 3.3(0)SE |
|
|
| |
| |
Bug Id: | CSCuu98366 |
Title: | The 3rd party vendor IP Camera is not getting power from Catalyst 3850 |
|
Description: | Symptom:
- The IP Camera is not working at all
- We are constantly receiving following errors:
000423: *Apr 24 23:18:59.456 UTC: %ILPOWER-3-CONTROLLER_PORT_ERR:
Controller port error, Interface Gi2/0/1: Power Controller reports power
Imax error detected
Conditions:
- The IP Camera is working fine under Catalyst 3560
Workaround:
None
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 02-JUL-2015 |
|
Known Affected Releases: | 3.6(2)E |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCup76790 |
Title: | FNF flow doesn't age out after 50 days |
|
Description: | Symptom:
FNF flow not aging out after 50 days
Conditions:
FNF configured and used for about 50days
Workaround:
(1)Write a script to periodically force switch to export flows on the stack for each asic and each switch using the following command:
clear flow monitor xxx cache force-export
(2)Reload
Further Problem Description:
none
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 15.0(2)EX1 |
|
Known Fixed Releases: | 15.0(1)EZ4, 15.0(14.57)EZD, 15.0(14.8)EZD, 15.2(2)E1, 15.2(2b)E, 15.2(3)E, 15.2(3)SE, 3.3(4)SE, 3.6(1)E, 3.7(0)E |
|
|
| |
| |
Bug Id: | CSCuu87436 |
Title: | 3850 / 3.7.1E / "switchport block multicast" blocks multicast ip traffic |
|
Description: | Symptom:
+ Multicast ip traffic blocked
+ Eg: MDNS traffic
Conditions:
+ Requires the command "switchport block multicast" configured on the egress interfaces.
Workaround:
+ Remove "switchport block multicast"
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 08-JUL-2015 |
|
Known Affected Releases: | 3.6(0)E |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCua72199 |
Title: | NG3K-7.65: IPv6 (internal)RAs forwarded as mcast RAs to Wireless clients |
|
Description: | Symptoms: Unsolicited RAs from the switch is forwarded as mcast RAs over the
air to the wireless clients. It should be a unicast packet. CAPWAP packet
header from the switch is populated with L2 MGID and not IPv6 RA MGID (L3)
and forwarded as multicast over air.
Conditions: This symptom is seen with Standalone Newton 48 with a couple of
APs and a couple of wireless clients with IPv6 enabled. IPv6 unicast routing
is enabled on the switch.
Workaround: There is no workaround.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 10-JUL-2015 |
|
Known Affected Releases: | 15.0(7.65)EMP |
|
Known Fixed Releases: | 15.0(1.0)UCT, 15.0(10.16)EMW, 15.0(2)EJ, 15.0(2)EJ1, 15.0(2)EX, 15.0(2)EX1, 15.0(2)EX3, 15.0(2)EX4, 15.0(2)EX5, 15.0(2)EZ |
|
|
| |
| |
Bug Id: | CSCus99367 |
Title: | 3850 re-writes mobility capwap data packets with TTL 9 |
|
Description: | Symptom:
3850 re-writes mobility capwap data packets with TTL 9
Conditions:
3850 re-writes mobility capwap data packets with TTL 9. As a result any capwap data packets(DHCP/ARP etc) sent via mobility tunnel will have a TTL set to 9 which means these packets will not be able to make more than 9 hops.
In an environment where 3850 wlan is anchored to another WLC/Switch >9 hops away, clients will not be able to get DHCP IP.
Hardware affected: 3850/3650
Software versions impacted: 3.3.x, 3.6.0, 3.6.1, 3.6.2, 3.7.0, 3.7.1
5760 is not impacted by this issue
Workaround:
Shorten the path between the foreign and anchor or upgrade to fixed image.
Further Problem Description:
None.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 10-JUL-2015 |
|
Known Affected Releases: | 15.2(3)E |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCul19814 |
Title: | SCHED-3-tHRASHING at fnf-rpc_context_wait_for_completion |
|
Description: | Symptom: After collecting "raw netflow" data, the active switch crashes. The show flow monitor v4 cache command causes the reboot of the switch with the following message:
%SCHED-3-TRASHING: Process thrashing on watched message event.
Conditions: This symptom occurs due to the show flow monitor command.
Workaround: There is no workaround.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 12-JUL-2015 |
|
Known Affected Releases: | 15.0(1)EZ |
|
Known Fixed Releases: | 15.0(1)EZ2, 15.0(10.37)PKD, 15.0(10.37)PKP, 15.0(12.72)EZD, 15.0(14.1)TSR, 15.0(14.49)EZD, 15.0(2.29)ZSR, 15.2(1.1)PSR, 15.2(1.24)PSR, 15.2(2)E |
|
|
| |
| |
Bug Id: | CSCum41076 |
Title: | Wireless IPSG is broken for NG3K |
|
Description: | Symptom:
IP Source Gurad for wireless IPv4 traffic does not take effect. The feature is enabled on a wlan. It is supposed to drop traffic from a wireless client in the wlan if the source IP is not the one allocated to the client.
But, this does not happen and such traffic is forwarded normally.
Conditions:
This is issue is seen whenever IPSG is enabled for a wlan (under all conditions).
Workaround:
There is no reasonable workaround for this issue.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 12-JUL-2015 |
|
Known Affected Releases: | 15.0(11.30)EMP |
|
Known Fixed Releases: | 15.0(1)EZ2, 15.0(10.37)PKD, 15.0(10.37)PKP, 15.0(12.91)EZD, 15.0(14.1)TSR, 15.0(14.49)EZD, 15.0(2.29)ZSR, 15.2(2)E, 15.2(2.2.70)ST, 15.2(2b)E |
|
|
| |
| |
Bug Id: | CSCus13484 |
Title: | Clients stuck in IDLE |
|
Description: | Symptom:
Clients stuck in IDLE state
Conditions:
Open WLAN, 5760 running 03.06.00SE
Workaround:
Force deauthenticate clients:
wireless client mac-address H.H.H deauthenticate forced
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 10.2(102.0) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCua55911 |
Title: | active reloaded with IOSD-EXT-SIGNAL: Segmentation fault(11) |
|
Description: | Symptom:
active reloaded with IOSD-EXT-SIGNAL: Segmentation fault(11)
Conditions:
* did "no issu set rollback-timer 7200" and did wr mem and the active crashed with the error segmentation fault
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 15.1(2)SG1.7, 15.4(1.1) |
|
Known Fixed Releases: | 15.0(1.5)UCT, 15.0(10.16)EMW, 15.0(8.24)EMD, 15.0(9.0)PKD, 15.1(1.40)SID, 15.1(2)SG, 15.1(2)SG1, 15.1(2)SG2, 15.1(2)SG3, 15.1(2)SG4 |
|
|
| |
| |
Bug Id: | CSCum70737 |
Title: | 3850 :: ACL definitions not consistent between stack master and members |
|
Description: | Symptom:
- Policy-map not programmed as indicated by output of "sh plat qos policy hw_state target tenGigabitEthernet X/Y/Z"
- As soon as the policy is re-writted using "match dscp" statements in the class-map instead of "match access-gorup" - the policy is programed correctly,
- Switch on which the policy is to be applied is not aware of nearly any ACL configured
- Output of "sh plat acl info switch X" shows different results for both switch members - at least one of the switches
Conditions:
- Stack of 2x 3850 running 03.03.01SE
- The switch has ACL applied on the management interface !!!
Workaround:
Remove the ACL from the Management interface.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 15.0(1.1)EX |
|
Known Fixed Releases: | 15.0(1)EZ3, 15.0(13.23)EZD, 15.0(14.1)TSR, 15.0(14.49)EZD, 15.0(2.29)ZSR, 15.2(1.30)PSR, 15.2(2)E, 15.2(2b)E, 15.2(4.0)ST, 15.2(5.0)ST |
|
|
| |
| |
Bug Id: | CSCut05943 |
Title: | 3850 incorrect vlan tag once using private vlans |
|
Description: | Symptom:
SW1 Gi1/0/1----TRUNK----Gi1/0/1 SW2 Gi1/0/2----TRUNK----Gi1/0/1 SW3
Gi1/0/48
|
|
Host (ISOLATED VLAN Y)
Each switch has SVI X (PRIMARY vlan). ISOLATED VLAN Y is mapped to PRIMARY VLAN X. We can ping from Host to SVI X of SW1 and SW2 but not SW3.
Conditions:
- 3850/3650 switches running cat3k_caa-universalk9ldpe.SPA.03.07.00.E.152-3.E.bin
- all switches configured with private vlans
- host configured in ISOLATED vlan and trying to communicate with host in PRIMARY vlan, while traffic has to pass between trunks on a device in the middle
Workaround:
- no workaround to have the setup working as expected and not loosing functionality
- we can use COMMUNITY instead of ISOLATED, however then we do not achieve the goal of having isolated hosts
- we can change interfaces from TRUNKs to PRIVATE-VLAN PROMISCOUS but then we can have only one PRIMARY vlan
- we can remove private vlan configuration from SW2, but then we are not able to use private vlan feature on SW2...
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 3.7(0)E |
|
Known Fixed Releases: | 15.2(3)E1, 3.7(1)E |
|
|
| |
| |
Bug Id: | CSCun81556 |
Title: | IPDT: Standby failed to boot up after SSO due to Bulk-sync failure |
|
Description: | Symptom:
- cannot configure "channel-group" on the channel member port
- If stack condition,
after SSO, Standby switch will fail to boot up as a result of bulk sync failure.
Conditions:
- "ip device tracking maximum" is present on an etherchannel member port
- seen with Cat3750, Cat3850 and stack ondition
Workaround:
Remove the config "ip device tracking maximum" from the chanel member ports
before configure channel-group, also before bringing up the switch in order to complete SSO.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 15.2(2)E |
|
Known Fixed Releases: | 15.2(1.41)PSR, 15.2(2)E, 15.2(2.2.32)EA, 15.2(2b)E, 15.2(4.0)ST, 15.2(5.0)ST, 3.6(0)E |
|
|
| |
| |
Bug Id: | CSCup86496 |
Title: | unicast ARP replies not destined to 3850 are forwarded to ARP module |
|
Description: |
Cu migrated 3750 switches to 3850 switches. and they use NAC for security.
The problem occurred with 3850 due to abnormal ARP table update.
Symptom:In 3850, we see that even the unicast ARP replies which are not destined to this box being forwarded to ARP module which will then learn and update the Src MAC for Src IP address which is creating an issue
Conditions:when the 3850 gets ARP replies which are not destined to this box
Workaround:None.
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 15-JUL-2015 |
|
Known Affected Releases: | 15.4(2.12)CG26 |
|
Known Fixed Releases: | 15.0(1)EZ5, 15.0(14.57)EZD, 15.0(2.29)ZSR, 15.2(2)E1, 15.2(3)E, 15.2(4.0)ST, 15.2(5.0)ST, 3.3(5)SE, 3.6(1)E, 3.7(0)E |
|
|
| |
| |
Bug Id: | CSCuj54565 |
Title: | Stack power configuration lost upon reload |
|
Description: | 3750X/3850 switch stack members fall out of the stack-power and change their names to [previous name +#] or the name of the stack-power plus a number.
Sometimes after reloading 3750X/3850 stack SW1's power stack ports remain in shut down state.
Symptom:3750X switch stack members fall out of the stack-power and change their names to [previous name +#] or the name of the stack-power plus a number.
Sometimes after reloading 3750X/3850 stack SW1's power stack ports remain in shut down state.
Conditions:Happens upon reloading a 3750X/3850 switch stack consisting of 5x 3750X/3850 switch members.
Workaround:Running standalone/no standalone resolves issue (fix must be applied post every stack reload).
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 15.2(1)E, 15.2(3.6)T |
|
Known Fixed Releases: | 15.2(1.1)PSR, 15.2(2)E, 15.2(2b)E, 15.2(4.0)ST, 3.6(0)E |
|
|
| |
| |
Bug Id: | CSCuo91792 |
Title: | IPDT:Wired stale entries learned via ARP not clearing out |
|
Description: | Symptom:
Any wireless user who gets an ip address and is shown to have picked the ip address in DHCP server some times shows its state as "IPLEARN".
Conditions:
For the ip address which the Wireless client has picked up and as confirmed in the DHCP server , Issue the following commands and check if that is assigned to any other mac-address inside the IPDT table:
#show ip device tracking ip 10.137.32.52
-----------------------------------------------------------------------------------------------
IP Address MAC Address Vlan Interface Probe-Timeout State Source
-----------------------------------------------------------------------------------------------
10.137.32.52 406c.8f55.f772 300 GigabitEthernet1/0/31 30 INACTIVE ARP
Workaround:
Enable DHCP Snooping on the Client Vlans.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 15.0(1)EX3 |
|
Known Fixed Releases: | 15.0(1)EZ4, 15.0(1.3)TTT, 15.0(1.77)ZSR, 15.0(13.78)EZD, 15.0(14.1)TSR, 15.0(14.57)EZD, 15.0(2.29)ZSR, 15.2(2)E, 15.2(2.3)PSR, 15.2(2.39)PSR |
|
|
| |
| |
Bug Id: | CSCul37521 |
Title: | duplex configuration is lost upon a reload when using the GLC-GE-100FX. |
|
Description: | Symptom:
When GLC-GE-100FX plugged in and reload the switch, Interface configuration shows as "Half" Duplex.
Conditions:
Insert GLC-GE-100FX SFP plugged in and reload the switch
Workaround:
Either GLC-GE-100FX SFP Remove and Insert again or Interface "shutdown" and "no shutdown" to update right configuration.
Further Problem Description:
At reload time, Link Interrupts missed. Right configuration is not update. This issue will fix as seperate CDETS.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 15.2(3.3)S |
|
Known Fixed Releases: | 15.0(1)EZ2, 15.0(10.37)PKD, 15.0(10.37)PKP, 15.0(12.70)EZD, 15.0(14.1)TSR, 15.0(14.49)EZD, 15.0(2.29)ZSR, 15.2(1.1)PSR, 15.2(2)E, 15.2(2b)E |
|
|
| |
| |
Bug Id: | CSCul79858 |
Title: | SNMP polling 3-4 days causes a switch crash |
|
Description: | Symptom:
When switch running 3.3.0/1 is being SNMP polled periodically, the memory leak might be observed. Once ran out of memory switch may crash
Conditions:
periodic SNMP polling. specific MIB OIDs which cause leakage are being investigated.
Workaround:
avoid periodic SNMP polling of the switch
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 15.0(1)EZ |
|
Known Fixed Releases: | 15.0(1)EZ2, 15.0(10.37)PKD, 15.0(10.37)PKP, 15.0(12.69)EZD, 15.0(14.1)TSR, 15.0(14.49)EZD, 15.0(2.29)ZSR, 15.2(1.1)PSR, 15.2(4.0)ST, 3.3(2)SE |
|
|
| |
| |
Bug Id: | CSCul84467 |
Title: | C3850:Stack:Port-Channel:Active Mem Switch Power Shut cause Traffic Loss |
|
Description: | Symptom:Port-Channel:Active Mem Switch Power Shut cause Traffic Loss
Conditions:With "port-channel 128" interface only this issue is observed.
Workaround:re-configure the port-channel 128 to port-channel <1-127>
Eg: port-channel 127
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 15.1(1.23), 3.3(1)SE |
|
Known Fixed Releases: | 15.0(1)EZ2, 15.0(10.37)PKD, 15.0(10.37)PKP, 15.0(12.66)EZD, 15.0(14.1)TSR, 15.0(14.49)EZD, 15.0(2.29)ZSR, 15.2(1.1)PSR, 15.2(2)E, 15.2(2b)E |
|
|
| |
| |
Bug Id: | CSCul66968 |
Title: | Crash after bringing up a port-channel configured with mode on |
|
Description: | Symptom:
A crash is observed after configuring a channel-group and bring the port-channel up.
Conditions:
The channel-group is configured using "mode on" For example:
channel-group 1 mode on
During the configurations, we several errors:
Oct 2 15:05:21.628 EDT: %SNMP-3-DVR_DUP_REGN_ERR: Attempt for dupe regn with SNMP IM by driver having ifIndex 194 and ifDescr Port-channel7
Oct 2 15:05:21.645 EDT: %COMMON_FIB-4-FIBHWIDBMISMATCH: Mis-match between hwidb Port-channel7 (ifindex 189) and fibhwidb Port-channel7 (ifindex 189)
Oct 2 15:05:21.657 EDT: %COMMON_FIB-4-FIBMISSINGHWIDB: No fibhwidb while initializing fibidb for Port-channel7 (if_number 190)
The crash could potential be caused after trying to configure "mode on" after the port-channel was already configured for PAGP. This is still being investigated.
Workaround:
None Known
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 15.0(1)EX2 |
|
Known Fixed Releases: | 15.0(1)EZ2, 15.0(10.37)PKD, 15.0(10.37)PKP, 15.0(12.72)EZD, 15.0(14.1)TSR, 15.0(14.49)EZD, 15.0(2.29)ZSR, 15.2(1.1)PSR, 15.2(2)E, 15.2(2b)E |
|
|
| |
| |
Bug Id: | CSCum43727 |
Title: | DHCP snooping database not being created |
|
Description: | Symptom:
DHCP snooping database is not being created on a 3650/3850 running IOS XEversion 3.3.1. DHCP snooping bindings are created fine but they are being lost upon switch reload as there is no database. This is causing traffic black holing until dhcp is renewed on all clients after switch is reloaded.
Conditions:
So far this has been seen on catalyst 3850/3650 switch with unsynchronized NTP.
Workaround:
Configure NTP master on the switch seeing this problem OR make sure NTP on the switch is in sync with some other NTP master.
Further Problem Description:
After this bug fix DHCP snooping will not depend on NTP state on the switch.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 15.0(1)EZ |
|
Known Fixed Releases: | 15.0(1)EZ2, 15.0(10.37)PKD, 15.0(10.37)PKP, 15.0(12.89)EZD, 15.0(14.1)TSR, 15.0(14.49)EZD, 15.0(2.29)ZSR, 15.2(2)E, 15.2(2b)E, 15.2(4.0)ST |
|
|
| |
| |
Bug Id: | CSCuo84770 |
Title: | 3850/3.3.2SE/Not forwarding double dot1Q tagged packets |
|
Description: | Symptom:
3850 not forwarding double dot1Q tagged ARP broadcast packets
Conditions:
A packet with two (or more) dot1Q tags ingressing into the switch
Workaround:
Disable IP device tracking.
In interface mode, configure "ip device tracking maximum 0" cli.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 15.0(1)EZ2 |
|
Known Fixed Releases: | 15.0(1)EZ4, 15.0(1.77)ZSR, 15.0(14.1)TSR, 15.0(14.12)EZD, 15.0(14.57)EZD, 15.0(2.29)ZSR, 15.2(2)E1, 15.2(2.23)PSR, 15.2(2.39)PSR, 15.2(2b)E |
|
|
| |
| |
Bug Id: | CSCuv32436 |
Title: | ping failure when stack standby boots up |
|
Description: | Symptom:
ping failure when stack standby boots up
Conditions:
the issue is specific to WS-C3850-**S (SFP supported), but not seen on WS-C3850-**L.
Workaround:
none
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 15.2(3)E |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo14901 |
Title: | Crash/High CPU when enabling nbar for Flexible Netflow |
|
Description: | Symptom:
3850 switch crashes and/or experiences high cpu when adding nbar feature to FNF.
Conditions:
Device must have flexible netflow and nbar application configured.
Workaround:
This is not a supported case. We should never have this configuration.
Further Problem Description:
Need to reject the configuration on wired interface.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | n/a |
|
Known Fixed Releases: | 15.0(1)EZ4, 15.0(1.77)ZSR, 15.0(13.70)EZD, 15.0(14.1)TSR, 15.0(14.57)EZD, 15.0(2.29)ZSR, 15.2(2)E1, 15.2(3)E, 15.2(4.0)ST, 3.3(4)SE |
|
|
| |
| |
Bug Id: | CSCun78227 |
Title: | Incorrect temperature thresholds reported via SNMP |
|
Description: | Symptom:
entSensorThresholdValue reports impossible temperature thresholds on 3850
Conditions:
This is known to affect 3850 running 3.2.3SE and 3.3.2SE code, but may affect other versions
Workaround:
Use CLI to check temperature thresholds
i.e.
show environment temperature status
OR, use ciscoEnvMonTemperatureStatusDescr
This will state the temperature threshold in terms of GREEN, YELLOW or RED
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 15.0(1)EZ2 |
|
Known Fixed Releases: | 15.0(1)EZ4, 15.0(1.6)TTT, 15.0(13.80)EZD, 15.0(14.57)EZD, 15.2(2)E, 3.3(4)SE, 3.6(0)E |
|
|
| |
| |
Bug Id: | CSCud68775 |
Title: | Hot Swap of dissimilar FRU uplink module or SFP does not work on WS-3850 |
|
Description: | Symptom:
Hot Swap FRU uplink module or SFP does not work on WS-3850.
Conditions:
What does not work:
In a standalone WS-3850 or a stack of WS-3850 switches
1. Inserting a FRU for first time when switch is already in READY state.
2. With a FRU already present in the switch, removing/re-inserting FRU of different kind.
3. On a FRU that supports 10G interfaces, when
1G SFP is replaced by 10SFP+ or
10G SFP+ is replaced by 1G SFP
What works:
4. Remove/Re-insert FRU of same type.
5. Remove/Re-insert SFP with another SFP.
6. Remove/Re-insert SFP+ with another SFP+.
Workaround:
1. For Case 1, 2, reload the corresponding switch where the FRU uplink was inserted or swapped.
2. For Case 3, if ports go to err-disable state and the following error messages are seen
*Nov 28 20:46:20.742: %PM-4-ERR_DISABLE: Recovery command: "clear errdisable interface recover-uplink" error detected on Te2/1/3, putting Te2/1/3 in err-disable state
DO NOT execute shutdown/ no shutdown on this port. Please execute command "clear errdisable interface recover-uplink" to recover the link.
If accidentally shut/no shut has been executed for err-disable state, please reload the switch.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 0.0, 15.0(9.13)EMP, 15.0(9.46)EXP |
|
Known Fixed Releases: | 15.0(1)EX2, 15.0(1)EZ, 15.0(10.16)EMW, 15.0(9.17)RDD, 15.0(9.18)RDD, 3.3(0)SE |
|
|
| |
| |
Bug Id: | CSCur26195 |
Title: | Cannot clear authorization session on IOS-XE switch stack |
|
Description: | Symptom:
Dot1x configured on a 3850 switch stack running 03.06.00E authenticating against the ISE. After the device is disconnected from the switchport, we see that the authentication session is still stuck. Doing an clear authentication session on the interface does not help and no device can authenticate against the interface.
DEN3850S-2B#sh auth sessions int gi2/0/32 detail
Interface: GigabitEthernet2/0/32
IIF-ID: 0x102CB4000000F4B
MAC Address: b8ca.3ad8.5d39
IPv6 Address: Unknown
IPv4 Address: 192.168.2.27 (old IP address from previous swtichport access VLAN)
User-Name: CA-50-0853.corp.collectamerica.com
Status: Unauthorized
Domain: DATA
Oper host mode: multi-auth
Oper control dir: both
Session timeout: N/A
Common Session ID: AC17049400001ED3F99F40BC
Acct Session ID: Unknown
Handle: 0x63000D1C
Current Policy: POLICY_Gi2/0/32
Blocked On: User Profile Application - apply user profile (1)
Server Policies:
ACS ACL: xACSACLx-IP-PERMIT_ALL_TRAFFIC-51ef7db1
Method status list:
Method State
dot1x Authc Success
Dot1x configuration has been removed from the port but we still see this stuck session.
Conditions:
48 port 3850 switch stack running 03.06.00E configured for dot1x.This has also been seeing on a 4500 stack running the same version.
Workaround:
NA
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 3.6(0) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo14511 |
Title: | fed and stack-mgr causing High CPU on 3850 |
|
Description: | Symptom:
'stack-mgr' process shows high (>75%) CPU utilization. No packet forwarding impact observed in the switch
Conditions:
Observed conditions that were true for this to occur are:
Frequent mac flapping
Aggressive mac-aging timer configuration - less than or equal to 15 seconds
Topology Change Notification due to frequent Spanning-Tree changes or spanning-tree misconfiguration in the network
Workaround:
Eliminate or fix the configuration errors/events triggering the conditions mentioned above.
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 15.0(1)EZ |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCup49704 |
Title: | 3850 FED Crash - Waiting for SPI channels FED_SPI_FLCD,FED_SPI_FAST ... |
|
Description: | Symptom:
When abruptly reloading (eg: manual power cycle) or adding/removing a switch member from a 3850 stack, other switches in the stack may begin crashing on the FED (forwarding engine driver) due to a timeout on the SPI, which is the internal message-passing system that lets services communicate with one another.
The following logs may be seen for the stack members that enter a crash loop:
FED-3-INIT_FAILED MEMBER: X fed: Module SPI Channel failed initialization Waiting for SPI channels FED_SPI_FLCD,FED_SPI_FAST_CONV,
IOSXE-3-PLATFORM MEMBER: X process sysmgr: Service [fed] pid:[XXXX] terminated abnormally [6].
The bug is for 3850 and 3650 as its a timing issue and not related to any particular HW.
Conditions:
A stack member must be either be reloaded abruptly (eg: manual power cycle) or added/removed from the stack.
Workaround:
Reload the entire stack to resolve a sync issue.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 15.0(1)EZ, 15.2(2)E |
|
Known Fixed Releases: | 15.2(2)E1, 15.2(3)E, 3.6(1)E, 3.7(0)E |
|
|
| |
| |
Bug Id: | CSCuu31131 |
Title: | Memory leak under *MallocLite* / tdl code for ipv4 and l3m |
|
Description: | Symptom:
Memory leak is seen in *MallocLite* process. if MallocLite is disabled, we see the increase in memory under the TDL code for l3m and ipv4. Further investigation is going on to identify the source code involved in triggering the leak.
Conditions:
Not known
Workaround:
Not known
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 3.6(2)E |
|
Known Fixed Releases: | 15.2(4.0.8)E, 15.2(5.0)ST |
|
|
| |
| |
Bug Id: | CSCtz13264 |
Title: | 3850: Remove CLIs used to configure GRE tunnel - may cause crash |
|
Description: | Symptom:Crash is observed when GRE tunnels are configured on CAT 3850/3650
Conditions:Configuring of GRE Tunnels on CAT 3850/3560
Workaround:GRE Tunnels are not supported on 3650/3850. This is filed to remove the commands from the parser. In 3.3.4 and higher you will see the following when attempting to configure a tunnel interface.
Switch(config)#int tunnel 0
% Tunnel interfaces are not user configurable.
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 15.0(6.82)EMD, 3.2(0)SE |
|
Known Fixed Releases: | 15.0(1)EZ4, 15.0(1.77)ZSR, 15.0(13.65)EZD, 15.0(14.1)TSR, 15.0(14.57)EZD, 15.0(2.29)ZSR, 15.2(1.1)PSR, 15.2(4.0)ST, 3.3(4)SE, 3.3(5)SE |
|
|
| |
| |
Bug Id: | CSCut22611 |
Title: | 3850 - 1 GiG 1000BaseLX negotiates to "HALF DUPLEX" after reload |
|
Description: | Symptom:
1 Gig port (1000BaseLX) sometime starts operating at HALF DUPLEX mode after a reload.
Shut/no shut or plugging/unplugging the SFP does not fix the issue. Only way to fix it, is remove the SFP, hardcode the duplex to full and insert SFP back.
Conditions:
WS-C3850-24U running 3.3.5
Both ports need to be connected to C3850-NM-4-1G.
GBIC used- GLC-LH-SMD for 1000BaseLX
Workaround:
Not Available yet.
UDLD should be kicked in to stop any possible layer 2 loop due to this unidirectional situation but this is anyway not a valid workaround to stop the SFP port operating at HALF DUPLEX.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 15.0(1)EZ5 |
|
Known Fixed Releases: | 15.2(3)E1, 3.7(1)E |
|
|
| |
| |
Bug Id: | CSCur76872 |
Title: | Stack manager goes down when the system runs out of SDP buffer. |
|
Description: | Symptom:
The SDP (stack discovery protocol) buffer pool gets filled completely and hence the stack manager process goes down. This may manifest itself as any of a number of symptoms, many of which would appear at first glance to be due to stack cable instability (e.g. switches dropping from the stack and rejoining, stack merges, keepalive timeouts, etc).
The fingerprint of this issue is one of more sets of messages similar to the following in the "Trace buffer: stack-mgr-events" in any system-report or switch-report files which are generated during an event:
[01/26/15 23:50:49.498 UTC 283424 5943] No buffers available in chunk ssm 0x55c40ae0, buf (nil)Try increasing the chunk size
[01/26/15 23:50:49.498 UTC 283425 5943] smn-error: ran out of buffers
Conditions:
The issue is seen after SSO In mixed stack and the issue also gets triggered randomly whenever there is a PDS buffer overflow (a high rate of L2 & L3 protocol packets) in any stack.
Issue has been seen:
- After an SSO in a mixed stack
- When any SDP buffer overflow occurs in any stack, which can be triggered by a high rate of L2 / L3 protocol packets.
Workaround:
There is currently no workaround available for this issue.
Further Problem Description:
This defect is fixed in the 3.6.2a.E and 3.7.1.E releases.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 15.2(3.0.81)E1 |
|
Known Fixed Releases: | 15.2(2)E2, 15.2(3)E1, 3.6(2)E, 3.7(1)E |
|
|
| |
| |
Bug Id: | CSCut50625 |
Title: | switch crash with dot1x traceback |
|
Description: | Symptom:
first seen on 3560/3850
switch crashes with dot1x traceback ( please contact TAC to analyse crashinfo file )
Conditions:
aaa configuration
Workaround:
unknown
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 15.2(2.0.0), 15.2(2.1) |
|
Known Fixed Releases: | 15.2(4.0.26)E, 15.2(5.0)ST |
|
|
| |
| |
Bug Id: | CSCuu70556 |
Title: | stack manager crash @ dplr_pd_update_ring_status_chg |
|
Description: | Symptom:
3850 switch running 3.7.1.E might experience a stack manager crash.
Conditions:
unknown yet
Workaround:
unknown yet
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 15.2(3.7.1E) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus96681 |
Title: | IOS-XE 3.7.1 Crash When Configuring "mac addr static X.X.X vlan x drop" |
|
Description: | Symptom:
A 3850 switch running IOS-XE 3.7.1 may experience a crash in the FED process when configuring a static MAC address with the "vlan [id] drop" option. Example:
SWITCH(config)#mac address-table static XXXX.XXXX.XXXX vlan x drop
Message from sysmgr: Reason Code:[2] Reset Reason:Service [fed] pid:[XXXX] terminated abnormally [11].
Conditions:
User is configuring a static MAC address with the "vlan [id] drop" option.
Workaround:
None known.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 25-JUL-2015 |
|
Known Affected Releases: | 15.2(3.1.27)E1, 15.2(3.7.1E) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu35972 |
Title: | MCAST streams stop with more then one outgoing interfaces in the RIL |
|
Description: | Symptom:
With more then one outgoing interfaces, multicast streams do not getting forwarded to any OIL interfaces. The switch forwards multicast stream just fine as long as there is only a single interface in the OIL list.
Conditions:
The issue is seen if there are 2 or more outgoing interfaces.
Workaround:
Not known
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUL-2015 |
|
Known Affected Releases: | 3.6(2)E, n/a |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo14829 |
Title: | 3850/03.03.02SE/Stuck Routing Control Q due to IPV6 MLD |
|
Description: | Symptom:BGL.D.09-3800-1#sh platform punt client
tag buffer jumbo fallback packets received failures
-----SNIP-------------
65544 0/ 96/1600 0/4 0/0 0 0 0 0 0
65545 0/ 96/1600 0/8 0/32 0 0 0 0 0
s65546 511/ 512/1600 0/32 0/512 27369 35180 2507410 0 1
65547 0/ 96/1600 0/8 0/32 0 0 0 0 0
65548 0/ 512/1600 0/32 0/256 1182 1182 70920 0 0
BGL.D.09-3800-1#show platform punt statistics port-asic 0 cpuq -1 direction rm punt statistics port-asic 0 cpuq -1 direction rx
----SNIP-----
RX (ASIC2CPU) Stats (asic 0 qn 4 lqn 4):
RXQ 4: CPU_Q_ROUTING_CONTROL
----------------------------------------
Packets received from ASIC : 27883
Send to IOSd total attempts : 27883
Send to IOSd failed count : 1
RX suspend count : 1
RX unsuspend count : 0
RX unsuspend send count : 0
------SNIP------------
Conditions:IOS-XE 3.2.xSE, 3.3.0SE, 3.3.1SE, 3.3.2SE
Caused by IPV6 MLD group specific query packets
Workaround:+ Reload of the switch brings it out of the condition
More Info:Fixed in 3.3.3SE or higher. Upgrade IOS-XE.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-JUL-2015 |
|
Known Affected Releases: | 15.0(1)EZ2 |
|
Known Fixed Releases: | 15.0(1)EZ3, 15.0(13.44)EZD, 15.0(14.1)TSR, 15.0(14.49)EZD, 15.0(2.29)ZSR, 15.2(1.41)PSR, 15.2(2)E, 15.2(2.2.32)EA, 15.2(2b)E, 15.2(4.0)ST |
|
|
| |
| |
Bug Id: | CSCuu97048 |
Title: | Traffic is dropped due to static mac entry on foreign interface |
|
Description: | Symptom:
Traffic sourced from particular MAC address is getting dropped when this MAC address is statically added for another physical interface in the same broadcast domain.
Conditions:
There is static MAC address entry which is pointing for particular interface. Traffic sourced from this MAC address is silently dropped on other interfaces.
Workaround:
Remove static MAC address entry
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 15.2(3)E |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut44425 |
Title: | SFP remove and crash when "show platform port-asic 0 read counters" |
|
Description: | Symptom:
SFP remove and crash occur when run "show platform port-asic 0 read counters" command
Conditions:
when "show platform port-asic 0 read counters" command is run
Workaround:
We can use the following command as workaround now.
Switch#show platform fwd-asic counters tla ?
AQM Active Queue Management
ASE Acl Search Engine
EGR Egress Global Resolution
EPF Egress Scheduler Module
EQC Egress Scheduler Module
ESM Egress Queue Controller
FPE Flexible Parser
FPS Flexible Pipe Stage
FSE Fib Search Engine
IGR Ingress Global Resolution
IPF Ingress Port FIFO
IQS Ingress Queues and Scheduler
NFL Netflow
NIF Network Interface
PBC Packet Buffer Complex
PIM Protocol Independent Multicast
PLC Policer
RMU Recirculation Multiplexer Unit
RRE Reassembly Engine
RWE Rewrite Engine
SEC Security Engine
SIF Stack Interface
SQS Stack Queues And Scheduler
SUP Supervisor Interface
Switch#show platform fwd-asic counters tla NIF detail asic 0 sw 4
Starting with asic 0
NifRxByteDestinationGroupStats on Asic 0
[0]
rxUnicastBytes1 0x00000000
rxUnicastBytes0 0x00000184
rxMulticastBytes1 0x00000000
rxMulticastBytes0 0x00000000
rxBroadcastBytes1 0x00000000
rxBroadcastBytes0 0x00000000
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 15.5(2)T |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCty49656 |
Title: | Crash @ ip_route_delete_common when "no ip routing" is issued on console |
|
Description: | Symptom:
A crash is observed when executing the
"no ip routing" command.
Conditions:
This symptom is observed under the following conditions:
1) Configure OSPF.
2) Enable multicast.
3) Create several (>6000) routes in the network to be learned by OSPF.
4) Wait for OSPF to learn all the (>6000) routes from the network.
Finally, executing the "no ip routing"command may crash the
box.
Workaround:
There is no workaround.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 15.0(6.48)EMD |
|
Known Fixed Releases: | 15.0(6.99)EMD, 15.0(7.1)EMW, 15.0(9.0)PKD, 15.1(1)SY, 15.1(1)SY1, 15.1(1)SY2, 15.1(1)SY3, 15.1(1.23)SID, 15.1(2)SG, 15.1(2)SG1 |
|
|
| |
| |
Bug Id: | CSCuj51372 |
Title: | MacLearning not occuring for a group of 24 ports on 3850 |
|
Description: | Symptom:
In some rare circumstances, it has been seen Mac Learning is not occurring for either ports 1-24 or ports 25-48 on one member switch of a stacked 3850.
Traffic will flow through the ports. L2 traffic flooding will work.
Conditions:
Issue is seen with IOS-XE 3.2.2, 3.2.3 and 3.3.0
shut/no shut of the affected ports will not enable learning.
Workaround:
Reload the affected switch.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | n/a |
|
Known Fixed Releases: | 15.0(1)EZ1, 15.0(12.41)EZD, 15.0(14.49)EZD, 15.2(2)E, 3.3(1)SE, 3.6(0)E |
|
|
| |
| |
Bug Id: | CSCuu41817 |
Title: | 3850 cts assigning multicast traffic to sgt default (65535) |
|
Description: | Symptom:
Enforcement being applied to multicast traffic
Conditions:
Multicast traffic with igmp join
Workaround:
none
Further Problem Description:
NA
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 3.7(0) |
|
Known Fixed Releases: | 15.2(1.8)SY, 15.2(4.0)ST, 15.2(4.0.15)E, 15.2(5.0)ST, 15.6(0.7)S |
|
|
| |
| |
Bug Id: | CSCuu74507 |
Title: | WS-C3850-24T-- packet drop |
|
Description: | Symptom:
Some of the packets which from server to wireless client are dropped by 3850
Topology:
3750 (or other Layer 3 device)
||port-channel
wireless client(vlan20)---AP---C3850(vlan5)----------Server(FTP)
|
Wired client(vlan20)
Conditions:
-The gateway of client (vlan 20) is set on cat3750
-The gateway of server (vlan5) is set on cat3850
-Wireless client download file from ftp server.
Workaround:
None
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | n/a |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv14903 |
Title: | multigig switch dropping pass through packets received on the uplink |
|
Description: | Symptom:
This issue can be seen in WS-C3850-12XS and WS-C3850-12X48U when used with IOS version (3.7.1) release. Traffic Drop might be seen for some traffic if the incoming port and outgoing port are in 2 different ASIC cores in hardware.
Conditions:
If traffic comes into the system through up-link ports and going out on a down-link which is in another ASIC core e.g. port 41, 42 in WS-C3850-12X48U then the traffic drop might be seen, if the traffic has .1Q packet having CoS values that instruct a priority treatment. The COS values 2-7 might map to a internal queue which is not enabled. The "show platform port-asic ifm mappings local-port" CLI can be used to find the ASIC core for a local port number. The ASIC number in the output can be used to find where the port belongs. If the incoming port is in asic 0 then the out going port should not be in ASIC 1 and vice versa. If the incoming port is in ASIC 2 the outgoing port should not be in ASIC 3 and vice versa.
Workaround:
If the incoming and outgoing impacted port moved to same ASIC core or across switches in the same stack.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 15.2(3)E |
|
Known Fixed Releases: | |
|
|
| |
2013 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论