| |
Bug Id: | CSCuu42117 |
Title: | C4503-E sup7 crash on qpair_full after processing dhcpd_ functions |
|
Description: | Symptom:
Switch crashed twice within 4 days and generated the following tracebacks each time:
trace back 0. 0x2413cea8 qpair_full ---> qpair.h:287
trace back 1. 0xNone process_enqueue ---> event_mgmt.c:3138
trace back 2. 0x212df404 process_enqueue_pak ---> network_netinput.c:169
trace back 3. 0x234e9a10 enqueue_ip_socket ---> udp_api_cmn.c:123
trace back 4. 0x22bd4904 dhcpc_for_us ---> dhcpc.c:5596
trace back 5. 0x22bee298 reg_invoke_dhcp_udp_input ---> ip_registry.regh:42750
trace back 6. 0xNone dhcpd_read_packet ---> dhcpd_relay.c:6330
trace back 7. 0x22bee6ec dhcpd_receive_loop ---> dhcpd_relay.c:6678
trace back 8. 0x22beed40 dhcpd_receive_process ---> dhcpd_relay.c:6814
trace back 9. 0x22beebac dhcpd_receive_loop ---> dhcpd_relay.c:6696
trace back 10. 0x00000000 ??
According to the crashinfo file log there was user action taken right before it crashed (confirmed by the customer).
Conditions:
NA
Workaround:
NA
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 03-JUL-2015 |
|
Known Affected Releases: | 15.2(2)E2 |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCua52800 |
Title: | 4500-Sup7E when rebooted causes the int of 2k/3K to errdisabl |
|
Description: | Symptom:
downstream DSBU switches' int goes err-disable if we reload 4500 Sup7E connected to them
Conditions:
cat4500e-universalk9.SPA.03.01.00.SG.150-1.XO.bin ----- No issue
cat4500e-universalk9.SPA.03.01.01.SG.150-1.XO1.bin ----No issue
cat4500e-universalk9.SPA.03.02.01.SG.150-2.SG1.bin ------- No Issue
cat4500e-universalk9.SPA.03.02.02.SG.150-2.SG2.bin ------- 3550 affected but not 2960(tried twice to make sure...)
cat4500e-universalk9.SPA.03.02.03.SG.150-2.SG3.bin -------- Issue exists
cat4500e-universalk9.SPA.03.02.04.SG.150-2.SG4.bin ------ Issue exists
cat4500e-universalk9.SPA.03.03.00.SG.151-1.SG.bin ------ Issue exists
Workaround:
enable err-dsiable recovery time
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 04-JUL-2015 |
|
Known Affected Releases: | 15.2(3.7.1) |
|
Known Fixed Releases: | 15.0(2)SG5.5.38, 15.0(2)SG5.5.39, 15.0(2)SG6, 15.0(2)SG7, 15.0(2)SG8, 15.0(2)SG8.0.131, 15.1(1.25)SID, 15.1(2)SG, 15.1(2)SG1, 15.1(2)SG2 |
|
|
| |
| |
Bug Id: | CSCuq32728 |
Title: | 3.6.0 - IP phones reboots continuously |
|
Description: | Symptom:
IP phones reboots continuously after the upgrade to 3.6.0
Conditions:
LLDP enabled
Workaround:
Disable LLDP
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 05-JUL-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, 3.6(1)E, 3.7(0)E |
|
|
| |
| |
Bug Id: | CSCuu88479 |
Title: | Some ports on WS-X4248-FE-SFP remain down/down |
|
Description: | Symptom:
Sometimes the FastEthernet ports on WS-X4248-FE-SFP stuck in down/down state, although transceiver and fiber are working properly. Bouncing interface with "shutdown/no shutdown" or reconfiguring from default doesn't fix the issue.
Conditions:
Issue is seen on Catalyst 4506-E with Sup8-E. There are WS-X4248-FE-SFP modules populated with only GLC-FE-100BX-D.
Workaround:
Reset particular linecard or reload chassis
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 15.2(2)E2 |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv06235 |
Title: | "no vlan configuration" with "no ip igmp snooping" crash |
|
Description: | Symptom:
crash after issuing "no vlan configuration" crash
first reported on WS-C4500X-32 with 15.1(2)SG2
Conditions:
vlan configuration X
no ip igmp snooping
Workaround:
avoid using this command
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 15.1(2)SG2 |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtx09632 |
Title: | 4500 crash on removing switchport trunk allowed interface config. |
|
Description: | Symptom:
Crash
Conditions:
1. Interface with following configuration:-
interface GigabitEthernet2/1
switchport trunk allowed vlan 100
switchport mode trunk
ip device tracking maximum 10
2. no switchport mode trunk
3. no switchport trunk allowed vlan 100
Workaround:
Not seen all the time. But was able to recreate in lab withing 5 attempts.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 12.2(44)SG1 |
|
Known Fixed Releases: | 12.2(53)SG10, 12.2(53)SG11, 12.2(53)SG7, 12.2(53)SG9, 15.0(2)SG2.2.188, 15.0(2)SG2.2.189, 15.0(2)SG4, 15.0(2)SG6, 15.0(2)SG7, 15.0(2)SG8 |
|
|
| |
| |
Bug Id: | CSCuv14614 |
Title: | WS-X4640-CSFP-E ports (Tx) are disabled |
|
Description: | Symptom:
In Cisco Catalyst 4506-E, 4507R-E, 4507R+E,4510R-E, and 4510R+E chassis with WS-X4640-CSFP-E line cards, random ports are disabled in the transmit direction, when the switch is booted-up. The following message is observed:
Jun 3 14:12:45.607: %SFF8472-5-THRESHOLD_VIOLATION: Gi3/58: Rx power low alarm; Operating value: -40.0 dBm, Threshold value: -23.5 dBm.
+show interface transceiver
Gi3/58 37.4 3.25 -6.3 -40.0
NAME: "GigabitEthernet3/59", DESCR: "1000Base-2BX10-D"
PID: GLC-2BX-D , VID: V01
Conditions:
This problem is seen on Cisco Catalyst 4506-E, 4507R-E, 4507R+E,4510R-E, and 4510R+E chassis when they are fully populated with WS-X4640-CSFP-E line cards, running cat4500e-universalk9.SPA.03.07.01.E.152-3.E1.bin
Workaround:
None
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 15.2(3)E |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCun45846 |
Title: | Mimatch of STP states in hardware and software on 4500-X |
|
Description: | Symptom:
While performing a failovers between active and standby supervisor on a 4500-X VSS, the hardware and Software STP states do not sync
Conditions:
1) 4500-X VSS running cat4500e-universalk9.SPA.03.04.03.SG.151-2.SG3.bin
2) Dual NIC server connected to the 4500.
3) Active Server NIC connects to Active 4500 switch and Standby server NIC connected to standby 4500
4 )Only Active server NIC passes traffic and hence only its MAC is learned on the 4500. Passive Server NIC does not pass traffic
5)Failovers are performed by executing the "redundancy force-switchover" command
6) Port config on the 4500 has portfast configured as follows:
switchport mode access
no snmp trap link-status
spanning-tree portfast
spanning-tree bpduguard enable
Workaround:
1)Shut/no shut of the port with the missing floodset/unsynced STP state fixes the issue
2) Removing "spanning-tree portfast" prevents the problem from happening
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 15.1(2)SG3.0.1 |
|
Known Fixed Releases: | 12.2(33)SXI10, 12.2(33)SXI11, 12.2(33)SXI12, 12.2(33)SXI13, 12.2(33)SXI14, 12.2(33)SXI4, 12.2(33)SXI6, 12.2(33)SXI8a, 12.2(33)SXJ, 12.2(33)SXJ2 |
|
|
| |
| |
Bug Id: | CSCum80951 |
Title: | TCAM does not share when same policy is applied to multiple interfaces |
|
Description: | Symptom:
When you apply the same policy to multiple interfaces, you should use the same label. Incrementing labels when adding them to multiple interfaces quickly exhausts TCAM resources.
The example below is the output of "show platform software acl input paths" where each interface gets a new label.
sh platform software acl input paths:
Path Current Label Next Label
------------------------------------------------------------
(in :0, null) (NQ:16382/PermitAll, Q:16215/Unknown)NotPresent
(in :1, null) (NQ:16382/PermitAll, Q:16365/Unknown)NotPresent
(in :2, null) (NQ:16382/PermitAll, Q:16327/Unknown)NotPresent
(in :3, null) (NQ:16382/PermitAll, Q:16271/Unknown)NotPresent
(in :4, null) (NQ:16382/PermitAll, Q:16336/Unknown)NotPresent
(in :5, null) (NQ:16382/PermitAll, Q:16349/Unknown)NotPresent
Conditions:
This condition was first seen on a cat4K with a sup7-e running 03.03.02.SG. The affected platform has 260 VOIP (phones) attached to WS-X4748-UPOE+E line cards. The problem also occurs in a situation where there are fewer devices and a couple of line cards.
------------------ show platform hardware acl statistics utilization brief ------------------
CAM Utilization Statistics
--------------------------
Used Free Total
--------------------------------
Output Security (160) 6 (0 %) 2042 (100%) 2048
Output Security (320) 12 (0 %) 2036 (100%) 2048
Output Qos (160) 2909 (71 %) 1187 (29 %) 4096 <------------
Output Qos (320) 5116 (83 %) 1028 (17 %) 6144 <------------
Output Unallocated (160) 0 (0 %) 51200 (100%) 51200
#### Log messages seen ###
Dec 5 22:09:19.691: C4K_HWACLMAN-4-ACLHWPROGERR Input VV-7E-Phone-Input-Policy - hardware TCAM limit, qos being disabled on relevant interface.
Dec 5 22:09:19.691: C4K_HWACLMAN-4-ACLHWPROGERRREASON Input(NQ:16382/PermitAll, Q:16199/Unknown) VV-7E-Phone-Input-Policy - insufficient hardware TCAM entries with usable masks.
Dec 5 22:09:20.980: C4K_COMMONHWACLMAN-4-HWPROGSUCCESS Input VV-7E-Phone-Input-Policy - now fully loaded in hardware
Dec 5 22:09:21.116: C4K_COMMONHWACLMAN-4-ALLACLINHW All configured ACLs now fully loaded in hardware - hardware switching / QoS restored.
Workaround:
Remove all service policies and reapply to fix the problem. You can use the range command to remove and reapply all at once.
Example:
1. #int range G2/1-48,G3/1-48
2. #no auto qos trust
3. #auto qos trust
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 15.1(100.1), 15.1(2)SG1.0 |
|
Known Fixed Releases: | 15.1(2)SG5, 15.2(2)E1, 15.2(2.54)PSR, 15.2(2b)E, 15.2(3)E, 15.2(4.0)ST, 15.2(5.0)ST, 3.6(1)E, 3.7(0)E |
|
|
| |
| |
Bug Id: | CSCun97605 |
Title: | 4510 RSP physical removal missing default route for 60 seconds |
|
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-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(5.0)ST, 3.6(0)E |
|
|
| |
| |
Bug Id: | CSCuq39071 |
Title: | Mcast packet loss when other receiver leaves group in IGMPv3 |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-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, 3.6(1)E, 3.7(0)E |
|
|
| |
| |
Bug Id: | CSCur20444 |
Title: | I/O memory leak due to DHCPv6 packets. |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 15-JUL-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(4.0)ST, 15.2(5.0)ST, 15.3(3)S5.20, 15.4(1)S3.2, 15.4(1)S4 |
|
|
| |
| |
Bug Id: | CSCus46086 |
Title: | Dot1x/Mab re-authentication Success with "Status: Unauthorized" |
|
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 15-JUL-2015 |
|
Known Affected Releases: | 3.6(0), 3.7(0) |
|
Known Fixed Releases: | 15.2(2)E2, 15.2(3)E1, 15.2(5.0)ST, 3.6(2)E, 3.7(1)E |
|
|
| |
| |
Bug Id: | CSCui56867 |
Title: | switch isolated on 'no monitor session <id> filter packet-type good rx' |
|
Description: | Symptom:
Removing default config of 'monitor session filter packet-type good rx' from an active SPAN session triggers HSRP and EIGRP flaps making switch unreachable from directly connected peers.
Conditions:
Removing default config of 'monitor session filter packet-type good rx' from an active SPAN session is the trigger for switch isolation.
Workaround:
Restoring the default config of 'monitor session filter packet-type good rx' and bouncing 'err-disabled' ports restores normalcy.
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 15.1(2)SG, 15.1(2)SG1.80 |
|
Known Fixed Releases: | 15.1(1)XO0.18, 15.1(1)XO1, 15.1(1.0.33)XO1, 15.1(2)SG3.0.152, 15.1(2)SG4, 15.2(2)E, 15.2(2b)E, 15.2(4.0)ST |
|
|
| |
| |
Bug Id: | CSCur79622 |
Title: | 4500 Sup8E Supervisor enhanced error logging. |
|
Description: | Symptom:
The dual-sup switch was in SSO. When switchover was initiated using the "redundancy force-switchover" command, the entire chassis rebooted.
Note: This fix does not address the crash, instead it enhances error logging for further investigating this crash.
Conditions:
Switchover
Workaround:
none
Further Problem Description:
The existing logs and crashinfo are not adequate to determine the root cause of the issue. With this fix, additional logging capabiliies have been added. If the issue is observed again, we will have additional logs to further debug the issue and identify the root cause.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 15.1(1.45) |
|
Known Fixed Releases: | 15.2(1)SY1, 15.2(2)E2, 15.2(3)E1, 15.2(4.0)ST, 15.2(5.0)ST, 3.6(2)E, 3.7(1)E |
|
|
| |
| |
Bug Id: | CSCuu40317 |
Title: | Applying Medianet to interface bypasses SA Miss queue on 4500 |
|
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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 3.6(0) |
|
Known Fixed Releases: | 15.2(4.0)ST, 15.2(4.10.62)PI5 |
|
|
| |
| |
Bug Id: | CSCur98467 |
Title: | VSL-MGMT access-list mac address changes after entire VSS reload |
|
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:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-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(5.0)ST, 3.7(1)E |
|
|
| |
| |
Bug Id: | CSCus13479 |
Title: | 4500X VSS: multicast traffic blackholed on orphan L3 egress portchannel |
|
Description: | Symptom:
4500X VSS multicast traffic blackholed on orphan L3 egress portchannel. During problem symptom, traffic hits L2 floodset entry even though L3 entry si present and get dropped.There is a mismatch seen in state of ipv4MulticastEn between active and standby when switch is in this state.
hrn3-4500x-vss-01#sh platfo hardware rxvlan-map-table vl 200 <<< Ingress port
Executing the command on VSS member switch role = VSS Active, id = 1
Vlan 200:
l2LookupId: 200
srcMissIgnored: 0
ipv4UnicastEn: 1
ipv4MulticastEn: 1 <<<<<
ipv6UnicastEn: 0
ipv6MulticastEn: 0
mplsUnicastEn: 0
mplsMulticastEn: 0
privateVlanMode: Normal
ipv4UcastRpfMode: None
ipv6UcastRpfMode: None
routingTableId: 1
rpSet: 0
flcIpLookupKeyType: IpForUcastAndMcast
flcOtherL3LookupKeyTypeIndex: 0
vlanFlcKeyCtrlTableIndex: 0
vlanFlcCtrl: 0
Executing the command on VSS member switch role = VSS Standby, id = 2
Vlan 200:
l2LookupId: 200
srcMissIgnored: 0
ipv4UnicastEn: 1
ipv4MulticastEn: 0 <<<<<
ipv6UnicastEn: 0
ipv6MulticastEn: 0
mplsUnicastEn: 0
mplsMulticastEn: 0
privateVlanMode: Normal
ipv4UcastRpfMode: None
ipv6UcastRpfMode: None
routingTableId: 1
rpSet: 0
flcIpLookupKeyType: IpForUcastAndMcast
flcOtherL3LookupKeyTypeIndex: 0
vlanFlcKeyCtrlTableIndex: 0
vlanFlcCtrl: 0
Conditions:
NA
Workaround:
Unconfigure and reconfigure PIM on the ingress L3 port. For eg:
hrn3-4500x-vss-01#sh int po11 | i rate
Queueing strategy: fifo
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec <<< OIL not sending traffic
hrn3-4500x-vss-01#
hrn3-4500x-vss-01#
hrn3-4500x-vss-01#conf t
Enter configuration commands, one per line. End with CNTL/Z.
hrn3-4500x-vss-01(config)#int vl 200 <<< Ingress L3 port
hrn3-4500x-vss-01(config-if)#no ip pim sparse-mode
hrn3-4500x-vss-01(config-if)# ip pim sparse-mode
hrn3-4500x-vss-01(config-if)
|
没有评论:
发表评论