| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq32728 | Title: | 3.6.0 - IP phones reboots continuously |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
IP phones reboots continuously after the upgrade to 3.6.0
Conditions:
LLDP enabled
Workaround:
Disable LLDP
Further Problem Description:
|
|
Last Modified: | 08-AUG-2015 |
|
Known Affected Releases: | 3.6(0) |
|
Known Fixed Releases: * | 15.2(2)E1, 15.2(2)EA1.1, 15.2(2.2.73)ST, 15.2(2.4.5)EA, 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: | CSCur20444 | Title: | I/O memory leak due to DHCPv6 packets. |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
I/O memory leak observed with small or middle buffer pools showing very few buffers in the free list.
Conditions:
The issue is seen when DHCPv6 packets are received on the switch, and the port is configured with 'ipv6 dhcp guard'.
Workaround:
The workaround is to remove the 'ipv6 dhcp guard' configuration from the interface on which DHCPv6 packets are being received.
Further Problem Description:
|
|
Last Modified: | 08-AUG-2015 |
|
Known Affected Releases: | 15.2(2)E |
|
Known Fixed Releases: * | 15.2(2)E2, 15.2(2.1)EB, 15.2(2.2.35)EB, 15.2(2.9.2)EA2, 15.2(3)E1, 15.2(3)E2, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 15.3(3)S5.20 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj94250 | Title: | Traffic drop on receivers in same BD after sending leave from other host |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:Traffic drop on receivers in same BD after sending leave from other host
Conditions:when leave is sent from some host (on compo copper), other receivers in same BD also getting affected.
Workaround:no workaround
|
|
Last Modified: | 03-AUG-2015 |
|
Known Affected Releases: | 15.1(2)SG3, 15.4(2)S |
|
Known Fixed Releases: * | 15.1(1)IC66.54, 15.1(1)ICB29.36, 15.2(1.24)PSR, 15.2(2.2.70)ST, 15.2(4.0)ST, 15.2(5.0)ST, 15.4(1.16)S, 15.4(1.17)PI25a, 15.4(2)S, 15.4(2.1)T |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo88555 | Title: | Sup7-E not forwarding multicast traffic in layer 2 with PIM enabled SVI |
|
Status: | Other |
|
Severity: | 2 Severe |
Description: * | Symptom:
If the 4500/Sup7-E is the Non designated PIM router, it drops multicast packets traversing within the same vlan
Conditions:
4500 has SVI with
1. VRF configuration
2.. PIM SM
3. IP address of the SVI is lower so that it is not the DR on the subnet
4500 runs 3.4.3. Issue is also seen on the 3.5.2
Workaround:
1. Configure 4500 as the PIM DR
2. Downgrade to 03.03.02 fixes the issue
Further Problem Description:
|
|
Last Modified: | 17-AUG-2015 |
|
Known Affected Releases: | 15.1(2)SG3.0.2 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut55114 | Title: | Slow memory leak in IOSd on sup7E |
|
Status: * | Terminated |
|
Severity: | 2 Severe |
Description: | Symptom:
Slow memory leak in IOSd on sup7E
Conditions:
Unknown
Workaround:
None
Further Problem Description:
None
|
|
Last Modified: | 05-AUG-2015 |
|
Known Affected Releases: | n/a |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq54573 | Title: | Service Policy disappears from Running Configuration of the interface |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Service Policy disappears when link flaps or when negotiate for the speed.
Log is seen " Strict priority cannot be guaranteed"
Happens on both the port connected PC / Phone / switch which negotiate the speed lesser than 1Gig
Conditions:
Speed is lesser than 1Gig
and
Bandwidth remaining command used in the class
example:
policy-map Test
class Class1
priority
class Class2
bandwidth remaining percent 40
class Class3
bandwidth remaining percent 40
Workaround:
configure Police under Priority class
or
Configure Speed on the switch port
Further Problem Description:
|
|
Last Modified: | 15-AUG-2015 |
|
Known Affected Releases: | 3.6(0) |
|
Known Fixed Releases: * | 15.2(4.0)ST, 15.2(4.0.64a)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu40317 | Title: | Applying Medianet to interface bypasses SA Miss queue on 4500 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Using Medianet on L2 trunks, we see unknown unicast flooding because MACs are not being learned on interfaces that medianet is configured. When medianet is applied, the SA MISS CPU queue does not increment but medianet CPU queue does.
Conditions:
3.6.0 4500 Sup8 using medianet on the interface, where the medianetMonitor has a match-all criteria specified
Workaround:
For medianet configure a policy with a criteria other than a match-all. Preferably the MediaMonitor policy should match specific flows , that are of interest.
Further Problem Description:
Impacts 4500e and 4500es8 switches
|
|
Last Modified: | 15-AUG-2015 |
|
Known Affected Releases: | 3.6(0) |
|
Known Fixed Releases: * | 15.2(3)E2, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(4.10.62)PI5, 3.7(2)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus46086 | Title: | Dot1x/Mab re-authentication Success with "Status: Unauthorized" |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
The interface is configured for Dot1x/MAC Address Bypass (MAB) authentication. When the interface goes through re-authentication because of a
session timeout it was possible that the Dot1x/MAB re-authentication could be completed with success but the main authentication status would be
unauthorized.
Conditions:
The C4500 interface is configured for Dot1x/MAC Address Bypass (MAB) authentication.
Workaround:
1. Disable /MAC Address Bypass (MAB) re-authentication.
2. Reboot end device so that initial authentication is done properly.
PSIRT Evaluation:
The Cisco PSIRT has evaluated this issue and does not meet the criteria for PSIRT ownership or involvement. This issue will be addressed via normal
resolution channels.
If you believe that there is new information that would cause a change in the severity of this issue, please contact psirt@cisco.com for another
evaluation.
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
|
|
Last Modified: | 08-AUG-2015 |
|
Known Affected Releases: | 3.6(0), 3.7(0) |
|
Known Fixed Releases: * | 15.2(2)E2, 15.2(3)E1, 15.2(4.0.64a)E, 15.2(5.0)ST, 3.6(2)E, 3.7(1)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq39071 | Title: | Mcast packet loss when other receiver leaves group in IGMPv3 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Multicast packet loss when other receiver leaves group using v3 block source
Conditions:
This happens under the following conditions:
1. IGMPv3 should be used and the receivers must use SSM.
2. We need to shut the interface or unplug it.
Workaround:
Disable IGMP snooping.
Further Problem Description:
|
|
Last Modified: | 08-AUG-2015 |
|
Known Affected Releases: | 15.1(2.0) |
|
Known Fixed Releases: * | 15.1(2)SG5, 15.2(2)E1, 15.2(2.23)PSR, 15.2(2.39)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 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun97605 | Title: | 4510 RSP physical removal missing default route for 60 seconds |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Upon physically removing the active SUP from the switch, Multicast and Unicast packet loss for 60 seconds until route convergence takes place.
Conditions:
Default route is learned via SUP uplink interfaces: Te5/1 and Te6/1(ECMP).
ECMP (Equal Cost Multi Path) is affected by physical removal of the active SUP and causing SSO to standby SUP. Only that ECMP path that is taking TenGigabitEthernet ports on the SUPs is affected.
Any ECMP with line card ports is never affected.
Workaround:
None
Further Problem Description:
None
|
|
Last Modified: | 08-AUG-2015 |
|
Known Affected Releases: | 15.4(3) |
|
Known Fixed Releases: * | 15.1(2)SG3.0.214, 15.1(2)SG4, 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: | CSCur98467 | Title: | VSL-MGMT access-list mac address changes after entire VSS reload |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
VSL-MGMT access-list mac address changes every time after both two VSS switches reload or power off/on.
Conditions:
Cat4k VSS
Workaround:
N/A
Further Problem Description:
|
|
Last Modified: | 08-AUG-2015 |
|
Known Affected Releases: | 15.1(2)SGN3.9 |
|
Known Fixed Releases: * | 15.1(2)SG6, 15.2(1)SY1, 15.2(3)E1, 15.2(4.0)ST, 15.2(4.0.64a)E, 15.2(5.0)ST, 3.7(1)E |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuv97331 | Title: | CAT4K-SUP8E-High CPU Usage with "ip device tracking" |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
High CPU usage may be observed when "ip device tracking" command is used on interfaces.
Typically "Core 0" will be affected by this.
Conditions:
Issue has been seen on Cat4k with Supervisor 8E.
Among the high CPU usage processes, we may find "Cat4k Mgmt LoPri" and "K5CpuMan"
Workaround:
Disable "ip device tracking"
Further Problem Description:
|
|
Last Modified: | 28-AUG-2015 |
|
Known Affected Releases: | 15.1(100.1), 15.2(22.22) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuu42267 | Title: | vstack status shows duplicate entries for a single PID |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Switch#sh vsta group custom detail
No custom group configured
ESC-HUB304#sh vsta status
SmartInstall: ENABLED
Status: Device_type Health_status Join-window_status Upgrade_status
Device_type: S - Smart install N - Non smart install P - Pending
Health_status: A - Active I - Inactive
Join-window_Status: a - Allowed h - On-hold d - Denied
Image Upgrade: i - in progress I - done X - failed
Config Upgrade: c - in progress C - done x - failed
Script Upgrade: p - in progress P - done F - failed
Director Database:
DevNo MAC Address Product-ID IP_addr Hostname Status
===== ============== ================= =============== ========== =========
0 7426.aca4.8e40 WS-C4507R+E 10.1.22.1 3560-CG Director
1 04c5.a442.8300 WS-C3560CG-8PC-S 10.1.22.7 3560-CG S A a C <--- duplicate
2 04c5.a442.9b00 WS-C3560CG-8PC-S 10.1.22.5 3560-CGS A a C
3 04c5.a442.8380 WS-C3560CG-8PC-S 10.1.22.7 3560-CG S I a <---- duplicate
Conditions:
4500 running 3.7.2 as the director switch for smart-install
Workaround:
Further Problem Description:
|
|
Last Modified: | 25-AUG-2015 |
|
Known Affected Releases: | 3.6(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuv81357 | Title: | "blocking" status from "show storm-control" lasts after shutdown traffic |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Status of "blocking" from "show storm-control" output lasts even after shut down the traffic
Conditions:
port belongs to standby of VSS
Workaround:
shut/no shut port
Further Problem Description:
|
|
Last Modified: | 19-AUG-2015 |
|
Known Affected Releases: | 15.1(2.0) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur11406 | Title: | dot1q tunneling ethertype 0x88A8 not supported but command is available |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
dot1q tunneling ethertype 0x88A8 feature is not supported on C4900M but command syntax is available under the interface config mode.
WS-C4900M(config-if)#dot1q tunneling ethertype ?
0x88A8 dot1q tunneling etype 0x88A8 <<<<<<<<<<<<<<
0x9100 dot1q tunneling etype 0x9100
0x9200 dot1q tunneling etype 0x9200
Conditions:
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 15-AUG-2015 |
|
Known Affected Releases: | 15.1(2.12) |
|
Known Fixed Releases: * | 15.2(4.0)ST, 15.2(4.0.64a)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtq19252 | Title: | cannot remove "no diagnostic monitor poe health" from cli |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:after configuring "no diagnostic monitor poe health", you cannot
remove it from the cli
Conditions:15.0(2)SG
Solution::
Please use the 'default diagnostic monitor poe health' command to revert poe health monitoring to it's default. The behavior of commands is expected (and intentional). The output of 'diagnostic monitor poe' prints out a message asking the user to use 'default diagnostic monitor poe..' commands to reset the configuration. Software releases 12.2(53)SG6, 15.0(2)SG1 (and subsequent releases) print this message.
|
|
Last Modified: | 15-AUG-2015 |
|
Known Affected Releases: | 15.0(2)SG |
|
Known Fixed Releases: * | 12.2(53)SG6, 15.0(2)SG1, 15.0(2)SG1.2.106, 15.0(2)SG1.2.107, 15.0(2)SG8.0.131, 15.0(2)XO, 15.0(2)XO900.45, 15.0(2)XO900.68, 15.0(2.7)SG, 15.0(5.21)SID |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtj20399 | Title: | C4948:ARP request made in the wrong vlan(shows pv) |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
PVAN is not configured at C4948,But execute "sh ip arp" shows(pv XX).
shows ARP request in the wrong vlan from the "debug arp"information.
Conditions:
A server is connected two C4948 by Bonding.It connects by trunk between two C4948.
C4948 has a default gateway.The C4948 is used as L2 switch.(no ip routing).
Workaround:
Unknown
|
|
Last Modified: | 15-AUG-2015 |
|
Known Affected Releases: | 12.2(53)SG |
|
Known Fixed Releases: * | 12.2(53)SG10, 12.2(53)SG11, 12.2(53)SG5, 12.2(53)SG9, 15.0(0)XJR111.156, 15.0(1)SY, 15.0(1)SY1, 15.0(1)SY2, 15.0(1)SY3, 15.0(1)SY4 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr32522 | Title: | Speed nonegotiate command on SUP-6L-E with a twingig module |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
On the WS-X45-SUP6L-E with the twingig module installed on it, when the "spped nonegotiate" command is configured , the interfcae remains up even if the cable is connected from the interface.
Conditions:
- Sup6L-E
- Twingig module installed in the supervisor
- IOS: 12.2(54)SG or 12.2(54)SG1
- Interface configured with 'speed nonegotiate'
Workaround:
when the cable is removed from the SFP, the interface remains in the 'UP' state , but only when the interface is configured with the 'speed nonegotiate' command. There is no performance issue.
When the 'no speed' command is configured on the same interface and the cable is disconnected, the interface goes down.
|
|
Last Modified: | 15-AUG-2015 |
|
Known Affected Releases: | 12.2(54)SG |
|
Known Fixed Releases: * | 12.2(58)EZ, 12.2(58)SE1, 12.2(58)SE2, 12.2(60)EZ, 12.2(60)EZ1, 12.2(60)EZ2, 12.2(60)EZ3, 12.2(60)EZ4, 12.2(60)EZ5, 15.0(1)EY2 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui99162 | Title: | ARP response for ARP probe flooded through VLAN, ip device tracking |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Catalyst 4500 running cat4500-ipbasek9-mz.150-2.SG7.bin with 802.1x configured and "ip device tracking" enabled floods out the vlan with ARP response to ARP probe
Conditions:
ip device tracking enabled
Workaround:
disable ip device tracking
Further Problem Description:
|
|
Last Modified: | 15-AUG-2015 |
|
Known Affected Releases: | 15.0(2.0.0) |
|
Known Fixed Releases: * | 15.2(2)E2, 15.2(3)E, 15.2(4.0)ST, 15.2(4.0.64a)E, 3.6(2)E, 3.7(0)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu38664 | Title: | Switch 4k shouldn't forward multicast MAC for authentication to radius |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
switch authenticate flow control packets (multicast mac address as a source mac) from a Cisco un-managed switch (Linksys).
switch 4k is forwarding the 802.1 well defined Spanning multicast MAC address to radius server as it's a reserved MAC address switch shouldn't consider this MAC address as a normal MAC address and should never forward to radius server for authentication.
Conditions:
switch authenticate multicast mac address - 01-80-C2-00-00-01 from a Cisco un-managed switch (Linksys)
Workaround:
put a mac address filter on a switch-port and block the mac address.
Further Problem Description:
|
|
Last Modified: | 30-AUG-2015 |
|
Known Affected Releases: | 15.1(1)SG2, 15.1(2)SG |
|
Known Fixed Releases: * | 15.2(4.0.87)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo59641 | Title: | wireshark does not work when file location is usb0: |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
wireshark does not work when file location is usb0:
Conditions:
NA
Workaround:
NA
Further Problem Description:
|
|
Last Modified: | 08-AUG-2015 |
|
Known Affected Releases: | 15.2(1)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: | CSCus47714 | Title: | VSS active and standby MAC address teble can not synchronisation issue. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
This issue occurs in VSS mode switch(WS-C4500X-32SFP+), VSS switchover A(Active) --> B(Standby) , B(Active) --> A(Standby)
Before saving the MAC address table normal save to active switch(VSS-1), But does not synchronisation in the standby switch(VSS-2).
Conditions:
IOS:(03.04.04.SG)
occurs on After VSS switchover A(Active) --> B(Standby) , B(Active) --> A(Standby)
Workaround:
Clear Mac address table or Mac tabel time out. and to learn mac-address table, To solve this problem.
Further Problem Description:
We can using below command with check it:
"show platform hardware mac-address-table address "
|
|
Last Modified: | 08-AUG-2015 |
|
Known Affected Releases: | 15.1(2)SG4 |
|
Known Fixed Releases: * | 15.1(2)SG6, 15.2(1)SY1, 15.2(2)E2, 15.2(3)E1, 15.2(4.0.64a)E, 15.2(5.0)ST, 3.6(2)E, 3.7(1)E |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu14808 | Title: | Upgrade wireshark on cat4500 |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptoms:
Cisco Catalyst 4500 includes a version of Wireshark that is affected by the vulnerabilities identified by the following Common Vulnerability and
Exposures (CVE) IDs:
CVE-2011-0444
This bug was opened to address the potential impact on this product.
Conditions:
Device with default configuration.
Workaround:
Not currently available.
Further Problem Description:
Additional details about the vulnerabilities listed above can be found at http://cve.mitre.org/cve/cve.html
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 10/10:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:N/AC:L/Au:N/C:C/I:C/A:C/E:H/RL:U/RC:C&version=2.0
CVE ID CVE-2011-0444 has been assigned to document this issue.
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
|
|
Last Modified: | 07-AUG-2015 |
|
Known Affected Releases: | 15.2(1)E |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui49469 | Title: | Private Vlan config lost Cat4507-R Sup IV running 12.2(53)SG9 on SSO s/o |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Private Vlan config is lost while doing Sup Switchover. This behaviour is observed first in 12.2(53)SG7 and SG9 as well.
Conditions:
Private Vlan config is lost whenever we do Sup Switchover .
Workaround:
Privatevlan config has to be made once again after the switchover.
Further Problem Description:
|
|
Last Modified: | 15-AUG-2015 |
|
Known Affected Releases: | 12.2(53)SG9 |
|
Known Fixed Releases: * | 12.2(53)SG10, 12.2(53)SG11, 15.0(2)SG8, 15.0(2)SG8.0.116, 15.0(2)SG8.0.117, 15.0(2)SG8.0.118, 15.0(2)SG8.0.130, 15.0(2)SG8.0.131, 15.1(2)SG3.0.128, 15.1(2)SG4 |
|
|
| |
没有评论:
发表评论