| |
|
Alert Type: | Updated * |
Bug Id: | CSCux88789 | Title: | IOS-XE crash at smi_calc_hop_value_internal |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
4500X VSS crash when trying to access data at freed memory location.
Conditions:
Unknown.
Workaround:
Unknown.
Further Problem Description:
|
|
Last Modified: | 29-JUN-2016 |
|
Known Affected Releases: * | 15.2(3.7.1E), 15.2(3.7.2C) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw90551 | Title: | 4500 No SGT tag on individual port |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
SGT values are being overwritten / not preserved ingress on 4500 port g2/2
even with static trusted configuration.
Conditions:
This is observed on a 4500 with traffic coming ingress into the 4500 on g2/2
with a SGT tag. The SGT tag is being overwritten with the tag statically
configured on the interface even though the static configuration is supposed
to trust the incoming SGT. No other ports exhibit this behavior. This is
consistent across 3 different 4500's with both sup8's and sup7's. The
hardware is the same in all 3 chassis with the affected line card being WS-
X4748-RJ45V+E .
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 09-JUN-2016 |
|
Known Affected Releases: | 3.6(3)E |
|
Known Fixed Releases: * | 15.2(1)E, 15.2(1)E1, 15.2(1)E2, 15.2(1)E3, 15.2(1)EY, 15.2(2)E, 15.2(2)E1, 15.2(2)E2, 15.2(2)E3, 15.2(2)E4 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz70781 | Title: | VSS comes up when use same port channel number on both chassis for VSL |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When a VSS is formed for the first time, VSS is formed without VSL links. When, standby node goes for a reload, VSS enters dual-active scenario.
Conditions:
Problem is seen only on first time VSS formation when customer assigns same Port-channel number to VSLs on both chassis.
Workaround:
Assign a unique port-channel to the VSL on the standby chassis.
Further Problem Description:
|
|
Last Modified: | 30-JUN-2016 |
|
Known Affected Releases: | 15.2(2)E4 |
|
Known Fixed Releases: * | 15.2(5.2.39i)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCva13664 | Title: | DOC: CTS Critical authentication behavior on partial AAA failure |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
The documentation for critical auth explains well how critical auth triggers in the event of AAA server unreachability. However, none of the below documentation links explain a situation where only one device is defined in the AAA server and the other missing (and the missing one could be a supplicant or authenticator).
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_cts/configuration/15-e/sec-usr-cts-15-e-book/cts-critical-auth.html
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_cts/configuration/15-sy/sec-cts-15-sy-book/cts-critical-auth.pdf
In the absence of this documentation, one can presume that a AAA client missing on AAA server should still be good enough for critical auth to be invoked on the CTS link. But thats not the case.
I think that we should at a minimum add these facts into the documentation:
1. Links in authenticator state on deleted switch always succeed on bringing up critical auth. Definition of success means "bring up interface and associated port-channel if any"
2. Links in supplicant state on deleted switch will be the impacting links. Impacting means SAP_NE on one side and DOT1X-->Auth in another side leading to interface flap events.
Conditions:
Partial AAA Network failure
Workaround:
Put back the AAA client on the AAA server
Further Problem Description:
|
|
Last Modified: | 20-JUN-2016 |
|
Known Affected Releases: | 15.2(3)E |
|
Known Fixed Releases: | |
|
|
| |
2015 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论