| |
Bug Id: | CSCuo85722 |
Title: | 3850: L2 traffic dropped on the switch |
|
Description: | Symptom:
L2/L3 traffic is not forwarding by 3850 and clear ip arp fix the issue regardless if it is L2 or L3 traffic.
Conditions:
3.3.0 and 3.3.3 observed to be affected
Workaround:
clear ip arp
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 04-MAY-2015 |
|
Known Affected Releases: | 15.0(1)EY |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCui69119 |
Title: | IPDT: rejected channel conf&Standby failed to boot up |
|
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: | 04-MAY-2015 |
|
Known Affected Releases: | 15.2(1)E |
|
Known Fixed Releases: | 15.0(1)EZ4, 15.0(1.77)ZSR, 15.0(13.83)EZD, 15.0(14.1)TSR, 15.0(14.3)TTT, 15.0(14.57)EZD, 15.0(2.29)ZSR, 15.2(1.30)PSR, 15.2(2)E, 15.2(2.2.32)EA |
|
|
| |
| |
Bug Id: | CSCup53338 |
Title: | 3850 IOSD crash | Signal=SIGSEGV(11) @ pm_port_data_from_swidb |
|
Description: | Symptom:
The standby switch on a 3850 stack may reboot due to an IOSd crash following a stack-merge event.
Conditions:
Not Known
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 05-MAY-2015 |
|
Known Affected Releases: | 12.3PI4, n/a |
|
Known Fixed Releases: | 15.0(1)EZ4, 15.0(1.77)ZSR, 15.0(14.1)TSR, 15.0(14.57)EZD, 15.0(14.9)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: | CSCup09246 |
Title: | Catalyst3850 NetFlow export invalid packet |
|
Description: | Symptom:
Catalyst3850 NetFlow export invalid packet after changing configurations
Conditions:
when exporter is attached to a flow monitor before the flow monitor has a flow record defined
Workaround:
attach flow record to the flow monitor first and then attach flow exporter to the flow monitor.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 05-MAY-2015 |
|
Known Affected Releases: | 15.0(1)EZ3 |
|
Known Fixed Releases: | 15.0(1)EZ4, 15.0(13.81)EZD, 15.0(14.1)TTT, 15.0(14.57)EZD, 3.3(4)SE |
|
|
| |
| |
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: | 05-MAY-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, 3.3(2)SE |
|
|
| |
| |
Bug Id: | CSCuh59075 |
Title: | member switch crashed with tracebacks due to MEMBLK CORRUPTION |
|
Description: | Crash on the system after netflow configuration and unconfiguration.
Symptom:
Crash with MEMBLK corruption is observed.
Conditions:
When "collect interface input" and "collect interface output" fields are configured in a flow record, followed by attaching to flow monitor to interface and then un-configuring these fields and reattaching the same flow monitor to and interface. Crash is observed on execution of "show flow mon cache"
Workaround:
1) Reload the system.
2) Configure flow monitor with correct fields to avoid un-configuration.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 06-MAY-2015 |
|
Known Affected Releases: | 15.0(1)EZ |
|
Known Fixed Releases: | 15.0(1)EZ3, 15.0(13.21)EZD, 15.0(14.49)EZD, 15.2(2)E, 3.3(3)SE, 3.6(0)E |
|
|
| |
| |
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: | 06-MAY-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, 3.3(3)SE |
|
|
| |
| |
Bug Id: | CSCui69999 |
Title: | 3850 crashes when switches in the stack have different images |
|
Description: | Symptom:
Scenario 1:
Existing stack running 3.2.1/3.2.2/3.2.3
Add switch running 3.3.0
Result:
Added switch will display a platform mismatch
Scenario 2:
Existing stack running 3.3.0
Add switch running 3.2.1/3.2.2/3.2.3
Result:
Added switch will be recognized by existing stack and start "Initializing," but will eventually go down due to a FED crash
Conditions:
You'll run into issues if you have an existing stack running image1 and add switches to the stack which are running image2.
Workaround:
Please ensure all your switches have the same image.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 09-MAY-2015 |
|
Known Affected Releases: | 15.0(11.27)EMP |
|
Known Fixed Releases: | 15.0(1)EZ1, 15.0(10.27)PKD, 15.0(10.27)PKP, 15.0(12.29)EZD, 15.0(14.1)TSR, 15.0(14.49)EZD, 15.0(2.29)ZSR, 3.3(1)SE |
|
|
| |
| |
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: | 13-MAY-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: | 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: | 13-MAY-2015 |
|
Known Affected Releases: | 15.0(1)EZ5 |
|
Known Fixed Releases: | 15.2(3)E1, 3.7(1)E |
|
|
| |
| |
Bug Id: | CSCup77986 |
Title: | WS-C3850-48P-S stnadby member of the stack crashes |
|
Description: | Symptom:
standby member of the stack crashes
Conditions:
Stacks was working fine for 3 days with DHCP snooping and ARP inspection on all vlans without the one with printers in it (vlan304).
After both features were enabled on that vlan (304) after the night stack crashed again.
Workaround:
None
Further Problem Description:
None
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 15-MAY-2015 |
|
Known Affected Releases: | 15.0(1)EZ3 |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur58886 |
Title: | 3850 crash in webauth function |
|
Description: | Symptom:
crash on 3850 running 3.6.0E
Conditions:
3850 with 3.6.0E
Workaround:
none
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 15-MAY-2015 |
|
Known Affected Releases: | 15.2(2.0)E |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur09135 |
Title: | Memory Leak in IP Host Track Process |
|
Description: | Symptom:
Customer is monitoring 3850 WLC using Prime Infrastructure PI. Intermittently (after about 3 days), the 3850 will hang. And the PI shows the switch at 98% memory utilization.
Below shows the memory information.
switch#show proc memory detailed process iosd sorted
Processor Pool Total: 671088640 Used: 650355928 Free: 20732712
IOS Proce Pool Total: 16777216 Used: 11150140 Free: 5627076
PID TTY Allocated Freed Holding Getbufs Retbufs Process
211 0 2255279084 1461325716 474985068 0 0 IP Host Track Pr
switch#show proc memory detailed process ios task 211
Process ID: 211
Process Name: IP Host Track Process
Total Memory Held: 475000632 bytes
Processor memory Holding = 474975492 bytes
pc = 0x55EDD274, size = 474518704, count = 28574
pc = 0x560F652C, size = 299080, count = 1728
pc = 0x560F0410, size = 153992, count = 1734
pc = 0x56622240, size = 1544, count = 1
pc = 0x560F06EC, size = 1144, count = 6
pc = 0x58F185EC, size = 796, count = 1
pc = 0x58F090FC, size = 232, count = 1
IOS Process stack memory Holding = 25140 bytes
pc = 0x562BCF38, size = 25140, count = 1
Conditions:
3850 WLC running 03.06.00E
Workaround:
none
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 1 Catastrophic |
Last Modified: | 15-MAY-2015 |
|
Known Affected Releases: | 15.2(2.0.0) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur09076 |
Title: | %SYS-4-CHUNKSIBLINGSEXCEED: No of siblings in chunk gone above threshold |
|
Description: | Symptom:
3850 WLC intermittently will hang and no access allowed. Once the 3850 is reloaded, the issue goes away. The following is seen:
-Traceback= 1#048b6a8b926898a0a997138bbf4f379d :5501E000+258A31C :5501E000+3EF9114 :5501E000+EEC27C :5501E000+EEC898 :5501E000+1103900 :5501E000+1106B24 :5501E000+11070B0 :5501E000+1107688 :5501E000+3EAD28C
Sep 18 11:05:35 EDT: %DOT1X-5-FAIL: Authentication failed for client (f437.b720.88c2) on Interface Ca32 AuditSessionID 0a570a15541af4630003ee1f
Sep 18 11:05:59 EDT: %DOT1X-5-FAIL: Authentication failed for client (54ea.a882.8fc9) on Interface Ca35 AuditSessionID 0a570a15541af47a0003ee23
Sep 18 11:06:13 EDT: %SYS-4-CHUNKSIBLINGSEXCEED: Number of siblings in a chunk has gone above the threshold. Threshold:10000 Sibling-Count:22552 Chunk:0x38157CB0 Name:AIM_ATTACH -Process= "IP Host Track Process", ipl= 0, pid= 213
-Traceback= 1#048b6a8b926898a0a997138bbf4f379d :5501E000+258A31C :5501E000+3EF9114 :5501E000+EEC27C :5501E000+EEC898 :5501E000+1103900 :5501E000+1106870 :5501E000+11070B0 :5501E000+1107688 :5501E000+3EAD28C
Sep 18 11:06:18 EDT: %SYS-4-CHUNKSIBLINGSEXCEED: Number of siblings in a chunk has gone above the threshold. Threshold:10000 Sibling-Count:22902 Chunk:0x38EE9A74 Name:AIM_ATTACH -Process= "cpf_msg_rcvq_process", ipl= 0, pid= 129 (NC5A4-3)
-Traceback= 1#048b6a8b926898a0a997138bbf4f379d :54615000+258A31C :54615000+3EF9114 :54615000+EEC27C :54615000+EEC898 :54615000+10FE660 :54615000+1110F64 :54615000+1112198 :54615000+22A6FBC :54615000+22B3A20 :54615000+22AEA54 :54615000+3EAD28C (NC5A4-3)
Conditions:
3850 WLC running 03.06.00E
Workaround:
none
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 1 Catastrophic |
Last Modified: | 15-MAY-2015 |
|
Known Affected Releases: | 15.2(2.0.0) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur33133 |
Title: | Reboot of Standby Stack Member after configuration change. |
|
Description: | Symptom:
The issue is that after a configuration is changed, the Standby member reloads and displays error messages.
Conditions:
The standby can randomly reload on different occasions, for example when applying policy on interface or modifying VLAN configuration.
Workaround:
There is no workaround.
Further Problem Description:
Software version 3.6.0 or 3.3.1 (in lab I tested 3.3.1SE)
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-MAY-2015 |
|
Known Affected Releases: | 15.0(1)EZ1 |
|
Known Fixed Releases: | 15.2(1)SY1, 15.2(2)E2, 15.2(3)E1, 3.6(2)E, 3.7(1)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: | 18-MAY-2015 |
|
Known Affected Releases: | 10.2(102.0) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuq89605 |
Title: | Switch does not show the configured duplex value |
|
Description: | Symptom:
When a down interface is configured on Catalyst switch 3850 for a fixed speed and duplex value, the "show int status" command shows the correct speed, but it shows duplex as auto.
This behavior is seen only on an unconnected port.
Example:
#######
CAT3850#show run interface gigabitEthernet 1/0/2
Building configuration...
Current configuration : 62 bytes
!
interface GigabitEthernet1/0/2
speed 100
duplex full
end
CAT3850#show interfaces status | include Gi1/0/2
Gi1/0/2 notconnect 1 auto 100 10/100/1000BaseTX
Conditions:
The problem is seen on down interface, but when the link is ?up?, it shows the correct settings.
Workaround:
There is no workaround.
Further Problem Description:
NA
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-MAY-2015 |
|
Known Affected Releases: | 15.2(2)E |
|
Known Fixed Releases: | 15.2(1)SY1, 15.2(2)E2, 15.2(3)E1, 3.6(2)E, 3.7(1)E |
|
|
| |
| |
Bug Id: | CSCuu36538 |
Title: | Port of CSCuq73836 to polaris dev - C3850 sends unexpected GARP |
|
Description: | Symptom:
refer CSCuq73836
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 19-MAY-2015 |
|
Known Affected Releases: | 15.0(1)EZ4 |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut06539 |
Title: | Standby switch in 3850 stack crashes in .1x code |
|
Description: | Symptom:
A 3650 or 3850 switch running 3.6.1E or 3.7.0E and using dot1x authentication could experience a crash during new client registration.
Conditions:
Exact conditions not yet known
Workaround:
No known workaround.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 1 Catastrophic |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 15.2(2.0.0) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus93034 |
Title: | 5760 segmentation fault(11) on Auth-proxy HTTP daemon |
|
Description: | Symptom:
IOS Thread backtrace:
IOSD-EXT-SIGNAL: Segmentation fault(11), Process = Auth-proxy HTTP daemon 0
5760 crashes
Conditions:
Usage of web authentication
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-MAY-2015 |
|
Known Affected Releases: | 10.2(100.0) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 21-MAY-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: | 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: | 22-MAY-2015 |
|
Known Affected Releases: | 15.0(1)EZ |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuf77489 |
Title: | Changing vty password can cause config corruption or crash |
|
Description: | Symptom:
A 3850 switch can crash when there are concurrent sessions and when a user tries to remove an existing password from console or vty. Various inconsistencies can be seen in running configuration that start with line. See "show runn | be line". Inconsistencies, if present can result in a crash later.
Conditions:
This can occur in a stacked setup on a 3850 switch.
Workaround:
Minimize configuration changes to "password" on vty s. Use a standalone switch when making such changes.
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 22-MAY-2015 |
|
Known Affected Releases: | 3.2(1.0) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCug87540 |
Title: | 3850: traffic L3 routed on 1 switch/member fails for newly added devices |
|
Description: | Symptom:The following symptoms can appear on the impacted switch (which can be standalone or a stack member):
- traffic is not routed between devices on different vlans (impacting newly connected devices, or devices that have changed ports)
- new routes do not function
- qos or ACL changes do not take effect
This issue occurs due to a failure to program changes into hardware once the breakage occurs, so existing hardware programming will allow traffic between previously connected devices to continue to flow correctly.
Conditions:Seen on Catalyst 3850 stacks running 3.2.0SE, 3.2.1SE and 3.2.2SE.
Workaround:None. To recover reload the impacted switch. The issue does not show in 3.3.0(SE) due to code restructure.
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 22-MAY-2015 |
|
Known Affected Releases: | 15.0(1)EY |
|
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: | 25-MAY-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: | CSCuq73836 |
Title: | C3850 sends unexpected GARP |
|
Description: | Symptom:C3850 will sent a GARP which it should not
Conditions:a tester is sending a arp with C3850's ip address and its own MAC address
Workaround:Disable IPDT on uplinks towards C3850 using "nmsp attachment suppress" command.
More Info:the issue is not seen when C3750X is used
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-MAY-2015 |
|
Known Affected Releases: | 15.0(1)EZ4 |
|
Known Fixed Releases: | 15.2(2)E1, 15.2(3)E, 3.6(1)E, 3.7(0)E |
|
|
| |
| |
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: | 25-MAY-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: | CSCur47054 |
Title: | Issue with updating Ingress WCCP with Egress label |
|
Description: | Symptom:
Symptom 1) Egress WCCP not working on cat3850. Traffic is not getting redirected. 2) Traffic egressing on routed interfaces that have wccp on the ingress direction are being subjected to egress racls configured on some other routed interfaces.
Conditions:
1) This problem will arise in certain scenario when ingress wccp is configured along with egress wccp on the same interface. The problem will only be seen if ingress wccp is applied after egress wccp which updates the egress label causing the problem. The problem will also be seen if ingress wccp is removed causing the label to be unset on egress wccp. 2) L3 interface A (port or svi) configured with an egress racl. L3 interface B configured with wccp on the ingress direction. Now traffic being routed out of B will be subjected to the egress racl of A. A and B are independent entities with no common config.
Workaround:
1) The workaround is to detach the ingress and egress wccp from the interface and to reapply egress wccp after ingress wccp. In this fashion since ingress is applied before egress, it cannot update egress label. if the problem has happened because of ingress wccp going away, simply detach and attach egress wccp. 2) The workaround is to remove wccp from the routed interface. If wccp cannot be removed, a complex workwround can be to configure/attach acls and wccps in such a manner that there is no overlap between the ingress wccp label and the egress racl label.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 15.0(1)EZ, 3.6(0) |
|
Known Fixed Releases: | 15.2(2)E2, 15.2(3)E1, 3.6(2)E, 3.7(1)E |
|
|
| |
| |
Bug Id: | CSCug52183 |
Title: | 3850 stack master crash |
|
Description: | Symptom:
Cisco 3850 router may reload after days of operation.
Conditions:
This can happen if significant traffic comes to the CPU at the same as when approximately 2^32 or 4
billion packets have traversed the CPU. It may take days or weeks for CPU bound traffic to reach 4
billion depending on control traffic pattern.
The CLI show platform punt stat port-asic 0 cpuq -1 direction rx can be used to check for this condition.
Workaround:
None
Further Problem Description:
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: | 1 Catastrophic |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 3.2(0.900.67) |
|
Known Fixed Releases: | 15.0(1)EX2, 15.0(1)EZ, 15.0(1.50)XRD, 15.0(10.74)EMW, 15.0(9.87)EXD, 3.2(2)SE, 3.3(0)SE |
|
|
| |
| |
Bug Id: | CSCus92830 |
Title: | 5760 memory leak in IOSD |
|
Description: | Symptom:
5760, 3.6.1 is having mem leak in IOSD.
In about 2-3 days the system is out of memory.
Conditions:
Wireless functionality is used with Radius authentication.
Workaround:
Reload WLC.
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 1 Catastrophic |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 10.2(111.0) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCup04121 |
Title: | Redirection loop when WCCP "OUT" enabled on SVI on Cat-3850 |
|
Description: | Symptom:
When wccp redirect out is enabled on the SVI on cat 3850 switch all the ttraffic going this link starts blackholing.
Conditions:
When wccp redirect out is enabled on the SVI on cat 3850 switch all the ttraffic going this link starts blackholing.
Workaround:
1- Apply wccp ingress
2- Apply wccp only on physical interface
3- Create a static arp entry for a random ip address in the same subnet as that of server (ip of svi 703 10.100.255.62 255.255.255.240) with the same mac address that was already learnt from the server.
For example:
Switch???vlan703--------------------------------------Server
3.3.3.3/24 3.3.3.2/24
Switch mac table entry for server
703 0000.42ac.5cdb DYNAMIC
Create a static arp in the switch:
Switch(config)# arp 3.3.3.20 0000.42ac.5cdb arpa
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 15.0(3.3)SID |
|
Known Fixed Releases: | 15.0(1)EZ4, 15.0(13.92)EZD, 15.0(14.15)TTT, 15.0(14.57)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 |
|
|
| |
| |
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: | 26-MAY-2015 |
|
Known Affected Releases: | n/a |
|
Known Fixed Releases: | 10.1(0.22), 10.1(100.0), 10.2(1.25), 15.0(1)EZ, 15.0(10.1)PKD, 15.0(11.11)EMW, 3.3(0)SE |
|
|
| |
| |
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-MAY-2015 |
|
Known Affected Releases: | 3.6(2)E, n/a |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur25796 |
Title: | Phones on protected switch ports unable to communicate with each other. |
|
Description: | Symptom:
Phones on protected switch ports cannot communicate with each other.
Conditions:
With the 'switchport protected' privileged EXEC command, the EAP times out, authentication fails, and 802.1x authentication is stopped.
Workaround:
There is no workaround.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 26-MAY-2015 |
|
Known Affected Releases: | 15.0(1)EZ4, 15.2(2)IE101.140 |
|
Known Fixed Releases: | 15.2(2)E2, 15.2(3)E1, 3.6(2)E, 3.7(1)E |
|
|
| |
| |
Bug Id: | CSCuq20110 |
Title: | Stack Upgrade failed from 3.3.2 to 3.6.0 |
|
Description: | Symptom:
3 members of the stacks were bouncing between removed/initializing.
sch-pharm-2fl1-3850m# sh switch
Switch/Stack Mac Address : 6c99.8963.bc80 - Local Mac Address
Mac persistency wait time: Indefinite
H/W Current
Switch# Role Mac Address Priority Version State
------------------------------------------------------------
1 Member 0000.0000.0000 0 0 Removed
*2 Active 6c99.8963.bc80 10 V03 Ready
3 Member 1c1d.8651.f680 5 0 Initializing
4 Member 0000.0000.0000 0 0 Removed
The following error were seen:
Jul 25 11:26:11.987 EDT: %ISSU-3-PEER_INCOMP_SET: Peer incompatibility set for image (CAT3K_CAA-UNIVERSALK9-M), version (03.06.00E) on peer uid (3)
Jul 25 11:26:11.987 EDT: Config Sync: Bulk-sync failure due to PRC mismatch. Please check the full list of PRC failures via:
show redundancy config-sync failures prc
Jul 25 11:26:11.988 EDT: Config Sync: Starting lines from PRC file:
-table-map gold-dscp2dscp
-table-map gold-dscp2up
-table-map silver-dscp2dscp
-table-map silver-dscp2up
Jul 25 11:26:13.254 EDT: %STACKMGR-1-RELOAD_REQUEST: 2 stack-mgr: Received reload request for switch 3, reason ISSU Incompatibility
Jul 25 11:26:13.253 EDT: %STACKMGR-1-RELOAD: STANDBY:3 stack-mgr: Reloading due to reason ISSU Incompatibility (sch-pharm-2fl1-3850m-3)
Jul 25 11:26:13.805 EDT: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr: Stack port 2 on switch 2 is down
Conditions:
When going to code 3.6.0 from 3.3.2
Workaround:
Customer downgraded to 3.3.2
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 26-MAY-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: | 26-MAY-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: | 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: | 27-MAY-2015 |
|
Known Affected Releases: | 15.5(2)T |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 26-MAY-2015 |
|
Known Affected Releases: | 3.7(0)E |
|
Known Fixed Releases: | 15.2(3)E1, 3.7(1)E |
|
|
| |
| |
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: | 28-MAY-2015 |
|
Known Affected Releases: | 3.6(0) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus13331 |
Title: | iosd crash in_be_http_epm_process_clean_up |
|
Description: | Symptom:
5760 will randomly crash. Was on call with cu when this happended and it was when we were trying to config fqdn acl on the wlc.
Conditions:
trying in config fqdn acl with CWA with ClearPass Radius. Once a client connected to this wlan the wlc crashed. We adjusted the acl's in the redirect acl and tried again but as soon as a client connected the wlc crashed a second time.
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 28-MAY-2015 |
|
Known Affected Releases: | 3.6(0) |
|
Known Fixed Releases: | 15.2(4.10.54)PI5 |
|
|
| |
| |
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: | 29-MAY-2015 |
|
Known Affected Releases: | 15.2(3)E |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu41817 |
Title: | 3850 cts assigning multicast traffic to sgt default (65535) |
|
Description: | Symptom:
3850 cts assigning multicast traffic to sgt default (65535)
As per CSCuu34717 we should assign sgt tag 0 not 65535
Conditions:
Workaround:
none
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-MAY-2015 |
|
Known Affected Releases: | 3.7(0) |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 29-MAY-2015 |
|
Known Affected Releases: | 3.7(0)E |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCui59593 |
Title: | PBR: policy route map not working | WS-C3850-24T - 03.02.01.SE |
|
Description: | Symptom:
PBR functionality does NOT seem to work the way it should in certain conditions as mentioned below, routing does NOT happen the way PBR is configured.
Conditions:
Policy based routing configured on 3850 switch with permit and deny statements in the route-map or in the access-list tied with route-map.
For eg: If your route-maps for PBR are applied in this way:
route-map VLAN2 deny 45 ------<<<< deny
match ip address 1
route-map VLAN2 permit 50 ------<<<< permit
match ip address 2
set ip next-hop 1.o.0.1
or ACL for PBR:
access-list 113 deny ip 1.1.e.0 0.0.0.255 1.2.e.0 0.0.0.255 ------<<<< deny
access-list 113 permit ip 1.1.e.0 0.0.0.255 any ------<<<< permit
Workaround:
Workaround:
Work this problem around by configuring route-map/acl with below technique:
the access-lists 3 permits the subnets that you want to DBR
(destination based routing with normal IP routing) as there is no set clause.
The access-list 4 should PBR the rest of the traffic to defined next-hop.
route-map VLAN3, permit, sequence 45
Match clauses:
ip address (access-lists): 3 -------<<<< normal routing table
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map VLAN3, permit, sequence 50
Match clauses:
ip address (access-lists): 4 -------<<<< PBR
Set clauses:
ip next-hop 1.o.0.1
this problem is fixed in: IOS-XE: 3.3.0SE and later
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-MAY-2015 |
|
Known Affected Releases: | 15.0(1)EX, 15.0(1)EY |
|
Known Fixed Releases: | 15.0(1)EZ, 15.0(12.3)EMW, 3.3(0)SE |
|
|
| |
| |
Bug Id: | CSCur16497 |
Title: | Egress WCCP does not work when configured with Egress SPAN |
|
Description: | Symptom:
On a stack of 3850 switches (WS-C3850-48T-E) running 3.3.4SE, when wccp redirect out is configured on the vlan interface the traffic is not getting redirected
Conditions:
"ip wccp 61 redirect out" or "ip wccp 62 redirect out" configured on the WAN side along with egress wccp span.
Workaround:
remove egress span from the same interface as egress wccp.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-MAY-2015 |
|
Known Affected Releases: | 15.0(1)EZ4 |
|
Known Fixed Releases: | 15.2(3)E1, 3.7(1)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: | 29-MAY-2015 |
|
Known Affected Releases: | 3.6(2)E |
|
Known Fixed Releases: | |
|
|
| |
| |
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: | 29-MAY-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 |
|
|
| |
没有评论:
发表评论