| |
|
Alert Type: | Updated * |
Bug Id: | CSCto10165 | Title: | Smart Install Crashes with certain IP Packets |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Summary
A vulnerability exists in the Smart Install feature of Cisco Catalyst Switches running Cisco IOS Software that could allow an unauthenticated,
remote attacker to perform remote code execution on the affected device.
Cisco has released free software updates that address this vulnerability.
There are no workarounds available to mitigate this vulnerability other than disabling the Smart Install feature.
This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20110928-smart-install.shtml.
|
|
Last Modified: | 15-AUG-2015 |
|
Known Affected Releases: | 12.2(55)SE, 12.2(58)SE |
|
Known Fixed Releases: * | 12.2(55)EX3, 12.2(55)SE3, 12.2(55)SE4, 12.2(55)SE5, 12.2(55)SE6, 12.2(55)SE7, 12.2(55)SE8, 12.2(55)SE9, 12.2(58)EY, 12.2(58)EZ |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu47539 | Title: | Stack port becomes root port after reload on 3750X |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Stack port shows up as root port for some or all vlans after a reload.
Reload could be member or whole stack
Logs similar to below are see for the actual root port
Mar 30 04:51:47.128: %DTP-5-TRUNKPORTON: Port Gi4/1/1-Gi4/1/1 has become dot1q trunk (3750-stack-4)
Mar 30 04:51:47.439: %DTP-5-NONTRUNKPORTON: Port Gi4/1/1 has become non-trunk (3750-stack-4)
Mar 30 04:51:50.576: %LINK-3-UPDOWN: Interface GigabitEthernet4/1/1, changed state to up
Conditions:
The uplinks should be fiber connections configured as trunk
"switchport nonegotiate" should be configured on it
Workaround:
remove "switchport nonegotiate
Further Problem Description:
Issue is same as reported in CSCue03558.
But that bug was only fixed for 3750V2
The issue is being seen in 3750X as well
The test was done with 15.0(2)SE7
|
|
Last Modified: | 15-AUG-2015 |
|
Known Affected Releases: | 15.0(2)SE6 |
|
Known Fixed Releases: * | 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(4.10.61)PI5 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtq51049 | Title: | Unable to console from member SW with access-class applied in 12.2(58) |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Unable to console into member switch when an ACL is applied to the VTY lines.
Conditions:
WS-C3750X-48T-S running c3750e-universalk9-mz.122-58.SE.bin
This issue occurs in all versions of 12.2(58) due to changes made in the stacking code.
Workaround:
- Not seen with 12.2(55)SE1
- When applying an acl to the vty lines "line vty 0 4" and "line vty 5 15"; please follow the following procedure.
1. Create the vty acl and permit the 127 network;
2. Append the "vrf-also" keyword to the configured access-class inbound.
Example:
ip access-list standard vty-acl
permit 127.0.0.0 0.0.0.255
line vty 0 4
access-class vty-acl in vrf-also
privilege level 15
length 0
transport input ssh
line vty 5 15
access-class vty-acl in vrf-also
privilege level 15
transport input ssh
|
|
Last Modified: | 10-AUG-2015 |
|
Known Affected Releases: | 12.2(58)SE |
|
Known Fixed Releases: * | 15.0(2)EA, 15.0(2)EB, 15.0(2)EC, 15.0(2)ED, 15.0(2)EH, 15.0(2)EJ, 15.0(2)EJ1, 15.0(2)EK, 15.0(2)EK1, 15.0(2)EX |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum43119 | Title: | switch crash at host_track_lookup_based_on_mac_ip_vlan |
|
Status: | Other |
|
Severity: | 2 Severe |
Description: * | Symptom:
Cisco IOS device crashes at function host_track_lookup_based_on_mac_ip_vlan, when configured with IP device tracking.
Conditions:
Device configured with IP device tracking.
Cisco IOS XE releases 03.02.01.SE, 03.02.02.SE, 03.02.03.SE, 03.03.0XO and 3.5.0E are affected.
Cisco IOS Software releases are affected:
15.0(1)EX1 and later.
15.1(1)XO and later.
15.2(1)E and later.
First Fixed in 15.0(1)EZ
Workaround:
If the features is not being used it is possible to disable IP device tracking.
More-Info:
In certain circumstance the IPDT AVL can become corrupted, resulting in the crash. Packets causing corruption are broadcast domain packets only.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 6.1/5:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:A/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:OF/RC:C&version=2.0
CVE ID CVE-2013-6705 has been assigned to document this issue.
Additional details about the vulnerability described here can be found at:
http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2013-6705
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
Further Problem Description:
|
|
Last Modified: | 18-AUG-2015 |
|
Known Affected Releases: | 15.2(1)E |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup79358 | Title: | C3KX-SM-10G doesn't pass through any packets after reloading switch |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
After reloading switch, port on C3KX-SM-10G doesn't transmit/receive
any packets although the link status is up/up.
Conditions:
- 15.2(1)E, E1, E2, E3, and 15.2(2)E is running
- not always occur after reloading switch
- not depend on SFP type
- not depend on specific configuration
- receive counter of the port never increment
This condition may recover by reloading C3KX-SM-10G.
(but the same behavior may be seen after that)
Workaround:
Enabling macsec on the interfaces
Further Problem Description:
|
|
Last Modified: | 15-AUG-2015 |
|
Known Affected Releases: | 15.2(2)E |
|
Known Fixed Releases: * | 15.0(2)EJ, 15.0(2)EJ1, 15.0(2)SE3, 15.0(2)SE4, 15.0(2)SE5, 15.0(2)SE6, 15.2(1)E, 15.2(2)E1, 15.2(2.54)PSR, 15.2(2b)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup55822 | Title: | Delays in Convergence time during link-flap between VSS and 3750 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:The convergence time ( measured using packet loss duration in IXNetwork) is higher than expected when links on the multi-chassis port-channel between VSS and 3750 access switches flap or failover.
Conditions:This convergence value (packet loss duration) is specifically high when the port-channel member port is coming up ( either using no shut command or during the link insert) on the member switch of 3750 stack
Workaround:The high convergence is taking because the switch is having 95 vlans from 1 to 94, 1699 when ever the link is no shut it programing all the vlans on the port in ascending order of vlan number. Since in this case vlan 1699 is used for sending traffic it takes more time as it vlan 1699 is programmed in the last. The work around is to use lesser numerical vlan number for sending senstive data where less convergence is required ie example. say vlan 14 so that the convergence time will be decreased as vlan 14 is programmed before vlan 1699
More Info:Convergence values during MEC link failover are specified in
http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Campus/Borderless_Campus_Network_1-0/Borderless_Campus_1-0_Design_Guide/BN_Campus_Technologies.html#wp1247223
The value we observe in customer environment and our lab setup is not in accordance to the values specified in the document.
|
|
Last Modified: | 08-AUG-2015 |
|
Known Affected Releases: | 15.1(1)SY2.1 |
|
Known Fixed Releases: * | 15.0(2)EX7, 15.0(2)SE7, 15.1(2)SY4, 15.2(2)E1, 15.2(2.54)PSR, 15.2(2b)E, 15.2(3)E, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq11337 | Title: | Fail to bundle l2protocol ports into channel |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
May fail to bundle l2protocol tunnel ports into channel using mode on. Member port always stays suspended.
If the l2pro port on the master switch joined the channel group first, the port on the member switch stayed in "S" state as incompatible port.
Conditions:
l2pt port configuration under cross stack port-channel
Workaround:
Reload switch stack
or remove commands:
l2protocol-tunnel shutdown-threshold
l2protocol-tunnel drop-threshold
Further Problem Description:
|
|
Last Modified: | 08-AUG-2015 |
|
Known Affected Releases: | 15.0(2)SE6, 15.2(2)E |
|
Known Fixed Releases: * | 15.0(2)SE8, 15.2(2)E1, 15.2(3)E, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 3.6(1)E, 3.7(0)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui41907 | Title: | CTS C3KX-SM to N7K in LACP Link down after ~9 master switchover |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: After a master switchover in a 3750X stack C3KX-SM module port-channels to the neighboring N7K enter into "suspended" state on the N7K side. Interfaces remain suspended even after the original master switch returns to service. The link state is up/down in the 3750X switch. This happens intermittently after a lot of master switch overs.
Conditions: This issue is seen with C3KX-SM module interfaces configured in MACSEC CTS manual mode with SAP GCM Encrypt encapsulation.
Workaround: Shut/No Shut on the affected port.
|
|
Last Modified: | 03-AUG-2015 |
|
Known Affected Releases: | 15.0(2)SE4 |
|
Known Fixed Releases: * | 15.0(2)SE5, 15.0(2)SE6, 15.1(1)SY, 15.2(2)E, 15.2(2.2.70)ST, 15.2(2b)E, 15.2(4.0)ST, 15.2(5.0)ST, 15.4(1.14.11)PIH24, 15.4(1.16)S |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj36089 | Title: | Packet loss during S,G creation |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
In a topology where a 3750X acts as the multicast router and a receiver exists for a multicast group (*,G) prior to the source sending multicast traffic, some of the initial packets sent by the source may be lost. Once the (S,G) is programmed for the traffic sent by the source for the multicast group all subsequent multicast traffic reaches the receiver.
Conditions:
A topology where a 3750X acts as the multicast router and a receiver exists for a multicast group (*,G) prior to the source sending multicast traffic
Workaround:
No Workaround
Further Problem Description:
|
|
Last Modified: | 15-AUG-2015 |
|
Known Affected Releases: | 15.0(2)SE2 |
|
Known Fixed Releases: * | 15.0(2)SE6, 15.2(2)E, 15.2(2b)E, 15.2(4.0)ST, 15.2(4.0.64a)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud51802 | Title: | REP on 3750-X errors: Virtual interface not working on slave |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Ping fail when the REP segment connecting to cat3750x with master switch as one primary edge, slave
switch interface as the other edge.
Conditions:
Affected software release: 15.0(2)SE, 15.0(2)SE1, 15.0(02)SE2.
Workaround:
none
|
|
Last Modified: | 14-AUG-2015 |
|
Known Affected Releases: | 15.2(1.1) |
|
Known Fixed Releases: * | 15.0(2)EJ, 15.0(2)EJ1, 15.0(2)SE3, 15.0(2)SE4, 15.0(2)SE5, 15.0(2)SE6, 15.2(1)E, 15.2(1)E1, 15.2(1)E2, 15.2(1)E3 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv53430 | Title: | inconsistent vlan bpdu received on uplink l3 switch |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
long ping timeout from PC to uplink 3750X vitural ip and saw below error messages
detected on uplink L3 switch when interface gi1/x/x connectiong to HSRP-Active switch
link up back.
-----------------------------------------------------------------
%SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer vlan id xx on GigabitEthernet1/0/20 VLANxx.
%SPANTREE-2-BLOCK_PVID_PEER: Blocking GigabitEthernet1/0/xx on VLANxx. Inconsistent peer vlan.
%SPANTREE-2-BLOCK_PVID_LOCAL: Blocking GigabitEthernet1/0/xx on VLANxx. Inconsistent local vlan.
-----------------------------------------------------------------
WS-C3750X-48P-L(HSRP-A)gi1/0/x------gi1/x/x WS-C3750X-48P-L(Stack)
Gi1/0/x gi1/0/x
| Port-channel |
Gi1/0/x gi1/0/x
WS-C3750X-48P-L(HSRP-S)gi1/0/x------gi2/x/x WS-C3750X-48P-L(Stack)gi1/0/x---PC
----------------------------------------------------------------
Conditions:
gi1/x/x on Stack link down/up by cable OIR or shut/no shut the connecting interface
on uplink side.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 27-AUG-2015 |
|
Known Affected Releases: | 15.0(2)SE6 |
|
Known Fixed Releases: * | 15.2(4.0.86)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud01798 | Title: | "FRU Power Supply is not responding" was seen unexpectedly |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
"FRU Power Supply is not responding" message seen on 3560X/3750X intermittently.
Issue may happen with one or two Power Supply Unit.
Conditions:
3560X/3750X is running IOS 15.0(2)SE.
Workaround:
The power supply is operating normally.
Upgrade to 15.0(2)SE2 or later to resolve this issue.
|
|
Last Modified: | 14-AUG-2015 |
|
Known Affected Releases: | 15.0(2.0.80)SE, 15.0(9.8)EMP |
|
Known Fixed Releases: * | 12.2(55)SE10, 15.0(2)EJ, 15.0(2)EJ1, 15.0(2)EZ, 15.0(2)SE2, 15.0(2)SE3, 15.0(2)SE4, 15.0(2)SE5, 15.0(2)SE6, 15.2(1)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue49529 | Title: | 3750X stack cross channel down/up after master power off/on |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
1.3750X stack running 15.0(2)SE1,connect to 2960 by cross channel.(channel mode on)
The Line Protocol of member I/F and channel will down/up after master switch power off/on,
and channel on 2960 also down/up.This problem does not happen on TeG I/F, channel.
2.even though the channel became down ,sometimes there's no message output on the stack.
We can see the channel down message on the peer 2960.
Conditions:
stack cross channel
Workaround:
No
Further Problem Description:
|
|
Last Modified: | 14-AUG-2015 |
|
Known Affected Releases: | 12.2(58)SE, 15.0(2)SE |
|
Known Fixed Releases: * | 15.0(2)SE5, 15.0(2)SE6, 15.2(1)E, 15.2(1)E1, 15.2(1)E2, 15.2(1)E3, 15.2(1)EX0.87, 15.2(1)EY, 15.2(1.1)EY, 15.2(2)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun51532 | Title: | Sometimes C8945 with port synchronisation lose SW link on PC link |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
The link is up but there is speed mismatch between both ends of the link. This does not allow traffic to flow.
Conditions:
This can be seen when a large no of ports (~20) observe link change event at the same time.
Workaround:
Do a "shut" and "no shut" of the port which is affected.
Further Problem Description:
"shut" and "no shut" will toggle the link and clear the speed mismatch on either side of the link.
|
|
Last Modified: | 08-AUG-2015 |
|
Known Affected Releases: | 15.0(2)SE2 |
|
Known Fixed Releases: * | 15.0(2)EX8, 15.0(2)SE7, 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(4.0.64a)E, 15.2(5.0)ST, 3.6(0)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum86316 | Title: | %ENTROPY-0-ENTROPY_ERROR: Unable to collect sufficient entropy on bootup |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
c2960s OR c3750x will print Below errors some times.
Mar 30 01:30:04.263: %ENTROPY-0-ENTROPY_ERROR: Unable to collect sufficient entropy
Mar 30 01:31:04.275: %ENTROPY-0-ENTROPY_ERROR: Unable to collect sufficient entropy
Mar 30 01:32:04.279: %ENTROPY-0-ENTROPY_ERROR: Unable to collect sufficient entropy
Mar 30 01:33:04.283: %ENTROPY-0-ENTROPY_ERROR: Unable to collect sufficient entropy
Mar 30 01:34:04.278: %ENTROPY-0-ENTROPY_ERROR: Unable to collect sufficient entropy
Mar 30 01:35:04.290: %ENTROPY-0-ENTROPY_ERROR: Unable to collect sufficient entropy
Conditions:
Happens only in the c3750x and c2960s which are using ACT1 base Entropy. Not seen in other models. This does not happen all always and on all the units. Happens only in some units.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 08-AUG-2015 |
|
Known Affected Releases: | 15.4(2.2)T |
|
Known Fixed Releases: * | 15.2(1.30)PSR, 15.2(2)E, 15.2(2.2.32)EA, 15.2(2b)E, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCus32213 | Title: | CTS manual link does not come up |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
cts manual link does not come up between 3750 with 15.2(E) CCO image and any other macsec supported peer switch, unless "dot1x system-auth-control" global cli is configured on the 3750 switch.
Conditions:
CTS manual links on 3750 switch without configuring "dot1x system-auth-control" global configuration.
CTS manal link fails to come up, as the SAP negotiation fails to start due to the missing EAP ACL.
Workaround:
enabled the global "dot1x system-auth-control" CLI on 3750 switches.
Further Problem Description:
|
|
Last Modified: | 28-AUG-2015 |
|
Known Affected Releases: | 15.2(3)E |
|
Known Fixed Releases: | 15.2(3)E1, 15.2(4.0.64a)E, 15.2(5.0)ST, 3.7(1)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum75450 | Title: | CPUHB_RECV_STARVE when acl log configured in stack |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
With following message, switch performance may be slow,
sometimes switch gets hang and not recovered until power cycling.
%SUPQ-4-CPUHB_RECV_STARVE: Still seeing receive queue stuck after throttling
Following messages may also be observed when problem happens.
%PLATFORM_RPC-3-MSG_THROTTLED: RPC Msg Dropped by throttle mechanism
%XDR-6-XDRIPCNOTIFY: Message not sent to slot X because of IPC error timeout. Disabling linecard. (Expected during linecard OIR)
Conditions:
Catalyst 3750X in stack configuration running 12.2(58)SE or later including 15.0SE releases and 15.2E releases.
log keyword is configured in access-list and traffic go through the member switches hit access-list that log keyword is configured.
Workaround:
Configuring longer logging interval may be the workaround for this problem.
For example,
ip access-list logging interval
Risk for this workaround is packet count that hit the access-list might be inaccurate because logging process is involved with every logging interval.
To recover the switch when problem is happening, you need to power cycling the switch.
Further Problem Description:
Note that this problem does not happen in 12.2(55)SE releases.
|
|
Last Modified: | 08-AUG-2015 |
|
Known Affected Releases: | 15.0(2)SE2, 15.2(1)E |
|
Known Fixed Releases: * | 15.0(2)SE7, 15.2(1.30)PSR, 15.2(2)E, 15.2(2b)E, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 3.6(0)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuc95754 | Title: | TestPortAsicCam POST failures |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | PortASIC's TCAM test failure when on-demand diagnostics (through diagnostics start command) was executed.
Symptom:
PortASIC's TCAM test failure when on-demand diagnostics (through diagnostics start command) was executed.
Conditions:
This can happen in any of the versions 12.2(55), 12.2(58) or 15.0(2), with switches 3560-E, 3750-E
3560-X, 3750-X. This problem was initially known to happen in mixed stack of 24 port and 48 port switches in one specific case. In other reproducible cases, it happened randomly in standalone switches with walle uplink modules.
Workaround:
Results of on-demand diagnostics can be ignored if POST succeeds on bootup.
More Info:
|
|
Last Modified: | 14-AUG-2015 |
|
Known Affected Releases: | 15.0(2)SE, 15.0(2.0.0) |
|
Known Fixed Releases: * | 12.2(55)SE8, 12.2(55)SE9, 15.0(2)EJ, 15.0(2)EJ1, 15.0(2)SE3, 15.0(2)SE4, 15.0(2)SE5, 15.0(2)SE6, 15.2(1)E, 15.2(1)E1 |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuu05782 | Title: | Traffic disruption after modification of ACL on SVI with QoS attached |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Traffic outage observed post ACL modification applied to SVI when SVI has been attached with QoS policy. Traffic disruption is seen when ACE is modified or box is reloaded.
Symptom:
Conditions:
Issue happens when ACL and QoS policy-applied to SVI and when ACE is modified. Traffic is disrupted for traffic hitting ACE which has "range" option.
Workaround:
Default the SVI and add the configuration again.
Further Problem Description:
|
|
Last Modified: | 30-AUG-2015 |
|
Known Affected Releases: | 12.2(55)SE9 |
|
Known Fixed Releases: | 15.2(3)E2, 15.2(4.0.64a)E, 15.2(4.10.60)PI5, 15.2(5.0)ST, 3.7(2)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum65542 | Title: | ping lost between 3750X and straight device when PBR next-hop lost |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
ping lost between 3750X and the straight device when PBR next-hop is lost
Conditions:
when PBR is enabled on 3750X and PBR next-hop is lost
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 08-AUG-2015 |
|
Known Affected Releases: | 15.0(2)SE5 |
|
Known Fixed Releases: * | 15.0(2)SE6, 15.2(1.30)PSR, 15.2(2)E, 15.2(2b)E, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 3.6(0)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj68289 | Title: | SGACL counters fail for authentication-server based SGT |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom: Static SGACL permissions are not updated for authentication server assigned SGT.
Conditions: This symptom is seen with an authentication server assigned SGT.
Workaround: Use manual SGT or dynamic SGACL.
|
|
Last Modified: | 12-AUG-2015 |
|
Known Affected Releases: | 15.2(2)E |
|
Known Fixed Releases: * | 15.1(2)IC66.2, 15.2(1)IC273.56, 15.2(1)ICA4.30, 15.2(2)DB101.101, 15.2(2)DB101.112, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 15.4(2.17)S0.6, 15.4(2.6)T |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun01172 | Title: | kSlow CLI response when configuring 3750X stacked switches |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Delayed or slow response while in config mode when config context changes during initial configuration.
Conditions:
Stacked Cat 3K switches, when config context levels change and all neighbor switches are having to be updated. Affected commands which have been observed are vlan and interface range (on first config of device).
Workaround:
The delayed Cli response will not occur when we configuring the vtp domain name.
Further Problem Description:
|
|
Last Modified: | 15-AUG-2015 |
|
Known Affected Releases: | 15.0(2.0.0) |
|
Known Fixed Releases: * | 15.0(2)SE7, 15.2(2)E1, 15.2(2.54)PSR, 15.2(2b)E, 15.2(3)E, 15.2(4.0)ST, 15.2(4.0.64a)E, 3.6(1)E, 3.7(0)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCug90127 | Title: | port-security violation error message appears on the stack switch |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Port goes into err-disabled state because of port-security security violations. This happens due to "Total MAC address" learned is not synced across the stack members.
Conditions:
configure "switchport port-security maximum " on an interface on a stack member and send traffic from the device connected to it. After sometime, device goes into err-disabled state because of the security-violations.
Workaround:
Run "no switchport" command for the interface.
Further Problem Description:
|
|
Last Modified: | 16-AUG-2015 |
|
Known Affected Releases: | 15.0(2)SE |
|
Known Fixed Releases: * | 15.0(2)SE6, 15.0(2a)EX5, 15.2(1.1)PSR, 15.2(2)E, 15.2(4.0)ST, 15.2(4.0.64a)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtj56719 | Title: | Crash on configuring DSCP mutation map on 3750x |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
3750x crashed after configuring dscp-mutation on an interface
Conditions:
Mutation name length > 25
Workaround:
Change the mutation name length <= 25
|
|
Last Modified: | 15-AUG-2015 |
|
Known Affected Releases: | 12.2(55)SE |
|
Known Fixed Releases: * | 12.2(55)SE4, 12.2(55)SE5, 12.2(55)SE6, 12.2(55)SE7, 12.2(55)SE8, 12.2(55)SE9, 12.2(58)EZ, 12.2(58)SE, 12.2(58)SE1, 12.2(58)SE2 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtq00251 | Title: | 3750x: Fan modules unplugged but showed ok in show env all |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Fan modules unplugged but showed ok in show env all
Conditions:
3750x, 3560x, IOS version 58.SE
Workaround:
None
|
|
Last Modified: | 15-AUG-2015 |
|
Known Affected Releases: | 12.2(58)SE |
|
Known Fixed Releases: * | 12.2(55)SE4, 15.0(1)EY2, 15.0(1)SE, 15.0(1)SE2, 15.0(1)SE3, 15.0(2)EA, 15.0(2)EB, 15.0(2)EC, 15.0(2)ED, 15.0(2)EH |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCti50576 | Title: | LED does not light up with traffic running |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
LED turns to black when the cable is pulled out and plugged back in when there is traffic on the port. Sometimes it continues in flashing amber mode.
Conditions:
When there is traffic passing through the port when cable is unplugged and plugged back in.
Workaround:
It will change to the correct color when traffic stops. It works normally after that.
|
|
Last Modified: | 15-AUG-2015 |
|
Known Affected Releases: | 12.2(53)SE2 |
|
Known Fixed Releases: * | 12.2(55)SE3, 12.2(55)SE4, 12.2(55)SE5, 12.2(55)SE6, 12.2(55)SE7, 12.2(55)SE8, 12.2(55)SE9, 12.2(58)EZ, 12.2(58)SE, 12.2(58)SE1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCti27620 | Title: | SNMP trap and snmp walk don't reflect correct status for power supply |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
SNMP traps not sent out when a PS is disconnected from a 3750-X switch.
Conditions:
Workaround:
none
|
|
Last Modified: | 15-AUG-2015 |
|
Known Affected Releases: | 12.2(55)SE |
|
Known Fixed Releases: * | 12.2(55)SE3, 12.2(58)SE, 15.0(4.1)SID, 15.2(4.0)ST, 15.2(4.0.64a)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuf21387 | Title: | WS-C3750X-48T-S || Incorrect Vlaue for "FRULink Container" |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Configure SNMP on the mixture of 3750X and 3750 stack switch
Customer tries to poll the OID: 1.3.6.1.2.1.47.1.1.1.1 which belongs to Object "entPhysicalEntry"The problem occurs for the instance number 3056.
It contains the value 0. This is wrong and produces the problem.
I would expect there a number with 3xxx because the 3750x is the third device in the stack.
The first device in the stack starts with 1xxx, the second with 2xxx and so on.
When you filter for this instance number (3056) you will see, that it is the 'FRULink Container'.
So everything where this container is the parentIndex could not be referenced to the correct device in the stack.
This problem is exactly the same for all stacked 3750X devices. The entPhysicalContainedIn value for the 'FRULink Container' is always 0.
Conditions:
The issue happens only for WS-C3750X-48.
Workaround:
None
More Info:
|
|
Last Modified: | 14-AUG-2015 |
|
Known Affected Releases: | 12.2(55)SE1 |
|
Known Fixed Releases: * | 12.2(33)IRC, 12.2(33)MRA, 12.2(33)SB14, 12.2(33)SB15, 12.2(33)SB16, 12.2(33)SB17, 12.2(33)SB4, 12.2(33)SB6a, 12.2(33)SB6aa, 12.2(33)SB6b |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuf13634 | Title: | C3750X link UP with auto/auto state if configured speed nontgo |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
configured 'speed nonegotiate' on Gi1/1/3
but this port goes up with auto/auto state by "show interface gi 1/1/3 status"
seems same issue as CSCub91647.
Conditions:
- configured 'speed nonegotiate'.
but this problem is not 100% repro.
Workaround:
shut/no shut on Gi1/1/3
Further Problem Description:
|
|
Last Modified: | 14-AUG-2015 |
|
Known Affected Releases: | 12.2(55)SE8, 15.0(2)SE1 |
|
Known Fixed Releases: * | 15.0(2)SE5, 15.0(2)SE6, 15.2(1)E, 15.2(1)E1, 15.2(1)E2, 15.2(1)E3, 15.2(1)EX0.22, 15.2(1)EY, 15.2(1.1)EY, 15.2(1.24)PSR |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuc41395 | Title: | unicast IP routing fails after PBR next-hop is lost by stack master down |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
communication down
Conditions:
PBR is set to Catalyst 3750X stack switch.
When stack master goes down and PBR next-hop is lost, even normal unicast routing fails.
Workaround:
None
|
|
Last Modified: | 14-AUG-2015 |
|
Known Affected Releases: | 15.0(1)SE3, 15.0(2)SE |
|
Known Fixed Releases: * | 15.0(2)EJ, 15.0(2)EJ1, 15.0(2)SE3, 15.0(2)SE4, 15.0(2)SE5, 15.0(2)SE6, 15.2(1)E, 15.2(1)E1, 15.2(1)E2, 15.2(1)E3 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue83689 | Title: | Indus: TB at macsecdev_set_port_option on shutting a authenticated port |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:A Catalyst switch may crash with the below message in the log
%SYS-2-NOBLOCK: may_suspend with blocking disabled. -Process= "hpm main process", ipl= 0, pid= 121
OR
%SYS-2-NOBLOCK: may_suspend with blocking disabled. -Process= "HRPC pm request handler", ipl= 0, pid= 130
Conditions:Seen when a vlan is assigned via ACS and switch is configured for 802.1x authentication.
Workaround:Not known at this time.
|
|
Last Modified: | 14-AUG-2015 |
|
Known Affected Releases: | n/a |
|
Known Fixed Releases: * | 15.0(2)EJ, 15.0(2)EJ1, 15.0(2)SE3, 15.0(2)SE4, 15.2(1)E, 15.2(1)EX0.22, 15.2(1.1)EY, 15.2(1.24)PSR, 15.2(1.25)PSR, 15.2(1.26)PSR |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuc90103 | Title: | Incorrect value of input error count |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom: Incorrect value in input error/FCS error counter
sc-p12379-acsw0801#sh int g2/1/2 | i input errors
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
sc-p12379-acsw0801#sh int g2/1/2 | i input errors
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
sc-p12379-acsw0801#sh int g2/1/2 | i input errors
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
sc-p12379-acsw0801#sh int g2/1/2 | i input errors
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
sc-p12379-acsw0801#sh int g2/1/2 | i input errors
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
sc-p12379-acsw0801#sh int g2/1/2 | i input errors
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
sc-p12379-acsw0801#sh int g2/1/2 | i input errors
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
sc-p12379-acsw0801#sh int g2/1/2 | i input errors
4294963524 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored << Input error counter increases to 4294963524>>
sc-p12379-acsw0801#sh int g2/1/2 | i input errors
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored << Input error counter came to 0>>
sc-p12379-acsw0801#sh int g2/1/2 | i input errors
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
sc-p12379-acsw0801#sh int g2/1/2 | i input errors
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
sc-p12379-acsw0801#sh int g2/1/2 | i input errors
4294963524 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored <<><< Input error counter again increases to 4294963524>>>
Conditions:None
Workaround:
|
|
Last Modified: | 14-AUG-2015 |
|
Known Affected Releases: | 15.0(1.7) |
|
Known Fixed Releases: * | 15.0(2)EJ, 15.0(2)EJ1, 15.0(2)SE3, 15.0(2)SE4, 15.0(2)SE5, 15.0(2)SE6, 15.2(1)E, 15.2(1)E1, 15.2(1)E2, 15.2(1)E3 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj69384 | Title: | IOS Modify default behavior Express Setup to avoid unexpected invocation |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:Express Setup is a feature that allows for quick configuration of basic features on the WS-C3750X and other IOS based switches. Express Setup is invoked through holding the Mode button for 2 seconds on an unconfigured switch or for 10 seconds on a previously configured switch. When this happens the switch configuration is deleted and the switch reboots and can be configured using Express Setup or via the CLI.
Large anti-snag cable boots have the potential of coming into contact with the mode button resulting in the unexpected invocation of Express Setup. This request is for a change in the default behavior of Express Setup to avoid invocation when a switch is in production and invocation is undesirable.
Conditions:The cable boot is making extended contact with the mode button resulting in Express Setup being invoked. When this happens the following messages will be seen on WS-3750X-48 and other IOS based switches:
%SYS-7-NV_BLOCK_INIT: Initialized the geometry of nvram
%SYS-5-RELOAD: Reload requested by Hulc LED Process. Reload Reason: Reason unspecified.
The device will then reset and the configuration will not be present when it comes back up.
Workaround:Disable Express Setup with the following command:
no setup express
Or remove the the cable boot from the cable installed in port 1.
More Info:A similar bug has been filed for IOS-XE based switches:
CSCuj17317 - XE: Modify default behavior of Express Setup to avoid unexpected invocation
|
|
Last Modified: | 08-AUG-2015 |
|
Known Affected Releases: | none |
|
Known Fixed Releases: * | 15.2(3)E2, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(4.10.60)PI5, 15.2(5.0)ST, 3.7(2)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun26893 | Title: | High CPU due to ASP Process Crea, crash on disabling macros |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | High CPU and crash
Symptom:
A stack of four WS-C3750X-48PF-S switches running IOS "c3750e-universalk9-mz.150-2.SE5.bin".
1> Firstly,we are seeing a CPU at 99% majorily due to the process "ASP Process Crea".
b-la1-013-sw-01#sho proc cpu sort
CPU utilization for five seconds: 99%/0%; one minute: 99%; five minutes: 84%
--More-- PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
363 99416 3304 30089 50.39% 43.54% 22.12% 0 ASP Process Crea
180 843481803 98980536 8521 18.55% 18.03% 18.08% 0 Hulc LED Process
ASP process goes high due to macros on multiple inetrfaces.
2>When we try to remove the macros by the command "no macro auto global processing"
The CPU comes back to normal but the master switch crashes.
Conditions:
Macro on multiple interfaces on stack switch WS-C3750X-48PF-S .
Switches running IOS "c3750e-universalk9-mz.150-2.SE5.bin".
Workaround:
Reload the stack and CPU remains low for a while. Removing the macros at this time does not cause the crash.
Further Problem Description:
|
|
Last Modified: | 08-AUG-2015 |
|
Known Affected Releases: | 15.0(2)SE5 |
|
Known Fixed Releases: * | 15.0(2)SE7, 15.2(2)E1, 15.2(3)E, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 3.6(1)E, 3.7(0)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr97529 | Title: | 3750X reload on PS failover even when PSx LED AC/PS turn Green |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
After restoration of power to a power supply slot, the switch reloads or hangs if power is removed from the other power supply slot despite the PS LED green on the first power supply.
Conditions:
Switch with 2 PS installed.
1) Remove power cord from PS1.
2) Plug the power cord back in PS1. Wait for AC and PS LED to turn Green.
3) Within 3-5 seconds of plugging back the power cord for PS1, remove the power cord from PS2.
At this point, switch reloads or hangs, indicating PS1 didn't entirely take over, despite AC/PS LED indicated it to be OK (Green).
Workaround:
Wait 10 seconds after the PS LED is green before removing power from the other power supply slot. Alternately, wait 2 seconds after "%PLATFORM_ENV-1-FRU_PS_SIGNAL_OK: POWER_GOOD signal on power supply <1-2> is restored" is seen.
Further Problem Description:
|
|
Last Modified: | 08-AUG-2015 |
|
Known Affected Releases: | 12.2(58)SE |
|
Known Fixed Releases: * | 15.2(1)SY1, 15.2(3)E1, 15.2(4.0.64a)E, 15.2(5.0)ST, 3.7(1)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo17293 | Title: | MAC sync issue on 3750 stack running SE5 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
mac address table is out of sync.
Conditions:
port-security is configured on all ports and when end host move.
Workaround:
clear mac address table will resolve the issue
Further Problem Description:
Few mac addresses are missing on one or two switches in the stack
|
|
Last Modified: | 08-AUG-2015 |
|
Known Affected Releases: | n/a |
|
Known Fixed Releases: * | 15.0(2)SE7, 15.2(2)E1, 15.2(2.54)PSR, 15.2(2b)E, 15.2(3)E, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 3.6(1)E, 3.7(0)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum89956 | Title: | Stack ping failed on int has static mac bounded after removed cable |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Removed/inserted the cable, or shut/no shut interface, ping failed on interface has static mac bounded.
Conditions:
1. to set static mac-address
2. Stack connection between Master and Member on topology
3. Each each device configured on Stack is bridged by portchannel.
4 Client connected to device is not to be allowed arp resolution.
Workaround:
shut/no shut portchannel
Further Problem Description:
Static mac configured on a cross stack etherchannel is affected.
|
|
Last Modified: | 08-AUG-2015 |
|
Known Affected Releases: | 15.0(2)SE5 |
|
Known Fixed Releases: * | 15.0(2)SE7, 15.2(2)E1, 15.2(2.54)PSR, 15.2(2b)E, 15.2(3)E, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 3.6(1)E, 3.7(0)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum17035 | Title: | link on member switch goes down when master switchover |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
link on member switch goes down when master switchover
Conditions:
This issue happens when "no physleep enable" is configured on interface of member switch
Workaround:
remove "no physleep enable " command
Further Problem Description:
|
|
Last Modified: | 08-AUG-2015 |
|
Known Affected Releases: | 15.0(2)SE5 |
|
Known Fixed Releases: * | 15.0(2)SE6, 15.2(1.30)PSR, 15.2(2)E, 15.2(2b)E, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 3.6(0)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq49531 | Title: | 10G link convergence is better than 1G convergence when is link pulled |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
10G link convergence is better than 1G convergence when is link pulled
Conditions:
10G link convergence is better than 1G convergence during link pull
when a 10G interface is lost in a port channel the flows switch over faster to the back up link when compared to a 1G.
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 08-AUG-2015 |
|
Known Affected Releases: | n/a |
|
Known Fixed Releases: * | 15.0(2)SE7, 15.2(2)E1, 15.2(2.54)PSR, 15.2(2b)E, 15.2(3)E, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 3.6(1)E, 3.7(0)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo97298 | Title: | PS-FAN falls to FAUTY status after upgrading IOS. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
PS-FAN falls to FAUTY status after upgrading your IOS software.
The show env stack command displays the following
SWITCH: 1
FAN 1 is OK
FAN 2 is OK
PS-FAN1 is FAULTY
PS-FAN2 is NOT PRESENT
TEMPERATURE is OK
Temperature Value: 35 Degree Celsius
Temperature State: GREEN
Yellow Threshold : 46 Degree Celsius
Red Threshold : 60 Degree Celsius
POWER is OK
RPS is NOT PRESENT
SWITCH: 2
FAN 1 is OK
FAN 2 is OK
PS-FAN1 is FAULTY
PS-FAN2 is NOT PRESENT
TEMPERATURE is OK
Temperature Value: 34 Degree Celsius
Temperature State: GREEN
Yellow Threshold : 46 Degree Celsius
Red Threshold : 60 Degree Celsius
POWER is OK
RPS is NOT PRESENT
---------------------
Conditions:
3750X
15.0(2)SE6
Workaround:
Downgrade to Cisco IOS Release 15.0(2)SE5.
Further Problem Description:
|
|
Last Modified: | 08-AUG-2015 |
|
Known Affected Releases: | 15.0(2)SE6 |
|
Known Fixed Releases: * | 15.0(2)SE7, 15.2(2)E1, 15.2(2.54)PSR, 15.2(2b)E, 15.2(3)E, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 3.6(1)E, 3.7(0)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCug67745 | Title: | 3750x: sometimes WCCP ISY packets not received by cache engine |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Sometimes WCCP ISY packets not received by the Cache engine in multicast mode
Conditions:
3750x-12S, WCCP in multicast mode
Workaround:
Use unicast mode
Further Problem Description:
|
|
Last Modified: | 08-AUG-2015 |
|
Known Affected Releases: | n/a |
|
Known Fixed Releases: * | 15.0(2)SE5, 15.0(2)SE6, 15.2(1)E, 15.2(1)E1, 15.2(1)E2, 15.2(1)E3, 15.2(1)EY, 15.2(1.1)EY, 15.2(1.30)PSR, 15.2(2)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup86619 | Title: | Port err-disable after link-flap with "speed nonegotiate" option. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Interface step into err-disable due to link flap. Interfaces even not connect any link.
Conditions:
this happens when we configure Speed nonegotiate on a GigabitEthernet Fiber interface.
Workaround:
shut - no shut after connecting the link.
Further Problem Description:
|
|
Last Modified: | 08-AUG-2015 |
|
Known Affected Releases: | 15.0(2)SE |
|
Known Fixed Releases: * | 15.0(2)SE8, 15.2(2)E1, 15.2(3)E, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 3.6(1)E, 3.7(0)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo08166 | Title: | 2x PoE mode does not remain configured on peer switches in a stack |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
If the CLI command 'set power inline port maximum 20000' is applied to PoE ports on subordinate switches within a data stack, the 2x power mode bit on the PoE controller is actually disabled.
Conditions:
This is seen on a data stack of 3750X switches running 15.X code.
After the CLI command 'set power inline port maximum 20000' is entered on a port, if the 2x mode is then unset and set again through the 'set power inline port 2x-mode' CLI, the port will initially power up in 2x mode. However, any power removal condition (plug/unplug, shut/no-shut) will result in clearing the 2x mode bit in the PoE controller.
Workaround:
The ports appear to behave properly when the ?set power inline port maximum 20000? command is not set for a given port.
Further Problem Description:
This command does not impact the master switch in the same manner as subordinate switches.
|
|
Last Modified: | 08-AUG-2015 |
|
Known Affected Releases: | 15.0(2)SE5 |
|
Known Fixed Releases: * | 12.1(22)EA14, 12.2(31)SB16, 12.2(31)SB17, 12.2(31)SGA11, 12.2(33)CX, 12.2(33)MRA, 12.2(33)SB14, 12.2(33)SB15, 12.2(33)SB16, 12.2(33)SB17 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui62464 | Title: | Sync local MAC address in SAP session with ISSU |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
After switchover, CTS triggers the SAP Rekey. The New Master has different MAC address so rekey fails.
Therefore to maintain the SAP Session after switchover. CTS needs to sync the MAC address.
Conditions:
Sync the SAP Session MAC address to the member. To maintain SAP Session after switchover rekey.
Workaround:
Shut / no shut the interface after switchover.
Further Problem Description:
|
|
Last Modified: | 03-AUG-2015 |
|
Known Affected Releases: | 15.0(2.0.44)SE1, 15.0(2.1.1)SE1 |
|
Known Fixed Releases: * | 15.2(1.24)PSR, 15.2(2)E, 15.2(2.2.70)ST, 15.2(2b)E, 15.2(4.0)ST, 15.2(5.0)ST, 15.4(1.14.11)PIH24, 15.4(1.16)S, 15.4(1.17)T, 15.4(2)CG |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue07405 | Title: | 3750X stack member diag TestPortAsicRingLoopback fail randomly |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
1. When manually executing on-demand diagnostic tests for a stack member with "diagnostic start switch X test all", TestPortAsicRingLoopback fails randomly.
2. The POST test at bootup is successful.
3. No operational impact is observed.
4. When executing tests for a stack master it reloads, master changes and no failed tests are present.
5. Another problem seen here - TestPortAsicCam failure, is already fixed by CSCuc95754
Conditions:
1. Manually executing diagnostic tests for a member switch.
2. Reported to be more likely to be seen in a mixed stack (24 ports and 48 ports) and in non-POE (24T, 48T) switches
Workaround:
1. Execute TestPortAsicRingLoop test alone (diagnostic start switch <> test 4). This doesn't fail at all.
2. Execute the tests (diagnostic start switch <> test all) after isolating the switch (DUT) from rest of the stack.
More Info:
|
|
Last Modified: | 14-AUG-2015 |
|
Known Affected Releases: | 15.0(2.0.0) |
|
Known Fixed Releases: * | 12.2(55)SE8, 12.2(55)SE9, 15.0(2)SE5, 15.0(2)SE6, 15.2(1)E, 15.2(1)E1, 15.2(1)E2, 15.2(1)E3, 15.2(1)EX0.87, 15.2(1)EY |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj31600 | Title: * | Call Home causes stack member crash |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
A Cisco 3750x may reload when adding a C3KX-SM-10G
Conditions:
Call-home needs to be enabled
Workaround:
Possibly disable call-home
Further Problem Description:
|
|
Last Modified: | 20-AUG-2015 |
|
Known Affected Releases: | 15.0(2)SE2 |
|
Known Fixed Releases: | 15.0(2)SE8, 15.2(3)E2, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 3.7(2)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCti63427 | Title: | Standalone stack-power mode does not show up in running-config |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | When you configure a 3750X or 3560X switch into standalone stackpower mode it does not show up in the running configuration. This places the stackpower ports in administrative shutdown mode and requires you to go enter no standalone under the stackpower configuration to re-enable them.
|
|
Last Modified: | 14-AUG-2015 |
|
Known Affected Releases: | 12.2(55)SE |
|
Known Fixed Releases: * | 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, 15.0(2)SE1, 15.0(2)SE2 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui21029 | Title: | 3750X Stack no standalone stays in running configureation as standalone |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
When you are configuring a 3750x stack and initially putting it into a stack ring topology by configuring the following.
Switch(config)#stack-power switch 1
Switch(config-switch-stackpower)#sta
Switch(config-switch-stackpower)#no stan
Switch(config-switch-stackpower)#no standalone
You will see that in the running configuration it shows up as standalone mode
stack-power switch 1
switch mode: standalone
stack-power switch 2
switch mode: standalone
Conditions:
3750X stacks with any license level
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 15-AUG-2015 |
|
Known Affected Releases: | 15.0(2)SE2 |
|
Known Fixed Releases: * | 15.0(2)SE7, 15.2(3)E, 15.2(4.0)ST, 15.2(4.0.64a)E, 3.7(0)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj36203 | Title: | 3750X: Log messages to report misconfiguration with Redirect ACL |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Catalyst 3750X CPU utilization may intermittently spikes due to EPM MAIN PROCESS, when the redirect ACL has an Access-list Entry (ACE) with source part not "any".
Under this condition, programming the dACL into the hardware fails and dACL is downloaded again to re-program.
3750X#show process cpu sorted
CPU utilization for five seconds: 97%/2%; one minute: 96%; five minutes: 94%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
311 3168483 177598 17840 27.43% 8.75% 7.95% 0 EPM MAIN PROCESS
Conditions:
Seen in Catalyst 3750X running 15.0(2)SE4 release.
Workaround:
Remove the ACE with wrong configurations.
This bug is an enhancement request to generate a log message (which will be rate-limited) to indicate misconfiguration(s).
Further Problem Description:
|
|
Last Modified: | 03-AUG-2015 |
|
Known Affected Releases: | 15.0(2)SE4 |
|
Known Fixed Releases: * | 15.1(1)ICB40.1, 15.2(1.24)PSR, 15.2(2.2.70)ST, 15.2(4.0)ST, 15.2(5.0)ST, 15.5(0.17)S, 16.1(0.14) |
|
|
| |
:
2013 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论