Cisco Notification Alert -ME 3600X Series Switch-01-Jun-2016 16:43 GMT

Feedback Sign Up Unsubscribe         Known Bugs - ME 3600X Series Ethernet Access Switches Alert Type: Updated * Bug Id: CSCuv35094 Title: SAT - L3 IP SLA Traffic Generation is not working Status: Fixed Severity: 2 Severe Description: Symptom: L3 IP SLA Traffic will not egress out of interface. only Tx stats are getting incremented in SLA o/p but actual traffic is not egressing out of the router. Conditions: Seen only on L3 IP SLA targets. Workaround: NONE Further Problem Description: Last Modified: 25-MAY-2016 Known Affected Releases: 15.5(3)S Known Fixed Releases: * 15.5(3)S1.5, 15.5(3)S2, 15.6(1.31)SP Alert Type: Updated * Bug Id: CSCuz64125 Title: AN: ZTB on Whales fails intermittently Status: Fixed Severity: 2 Severe Description: Symptom: AN zero touch bootstrapping in ME3600 platform fails intermittently Conditions: Zero touch bootstrapping of green filed ME3600 Workaround: N/A Further Problem Description: N/A Last Modified: 25-MAY-2016 Known Affected Releases: 15.6(2)SP Known Fixed Releases: * 15.6(1.31)SP, 16.3(0.213) Alert Type: Updated * Bug Id: CSCuy19169 Title: Ping to/through HSRP IP fails after HSRP Switchover Status: Fixed Severity: 2 Severe Description: Symptom: In a HSRP Setup ,traffic from particular hosts getting dropped . Ping from the host to any device through the HSRP routers will fails during the failover . Conditions: Issue seen after a HSRP switchover and when using EVC setup. The packet drops because of some packet loop that is created between the switches running HSRP. Issue is not seen when using normal dot1q tunk interfaces . Same also applied if you use VRRP setup . Workaround: 1- Clearing of the MAC table on the new HSRP active will restores the setup to working conditions . 2- Reducing the CAM table Age-out timers . 3- Using dot1q trunk instead of EVC . Further Problem Description: ME3600 on 15.5(3)S1a is sending packets (having DMAC of hsrp group address ) back to the received port+efp and creating temporary loop and sometimes flaps is seen on downstream switches with this issue . It appears only under below circumstances :- 1. The packet received by Me3600 in above diagram should have DMAC of hsrp group mac addresses (0000.0c07.acXX ) 2. You have EVC configuration instead of dot1q trunk . 2. The SVI on ME3600 should be configured with HSRP . 3. ME3600 should became HSRP active in failover scenario . Under these conditions , me3600 start to send the packets back to received port+efp , and only once the mac entry age out and deleted from the table ,issue is fixed . Issue is seen in all of these release which been tested in the lab : 15.4(3)S2 , 15.4(2)S3 ,15.4(3)S4 and latest one 15.5(3)S1a . Last Modified: 25-MAY-2016 Known Affected Releases: 15.5(1.1) Known Fixed Releases: * 15.5(3)S2.4, 15.6(1.31)SP Alert Type: Updated * Bug Id: CSCuz34638 Title: BFD Control Packets using wrong UDP port in ME-3600X-24CX Status: Fixed Severity: 2 Severe Description: Symptom: ME3600 sends BFD Control packets with UDP src port and dest port set as 3784. The source port MUST be in the range 49152 through 65535 per RFC5881. As a consequence, in our lab, BFD session is not coming up between ME-3600X and ASR-907. This issue was found in interop tests between ME-3600 and ASR-907. ASR-907 only supports BFD Control and it has hardware off-load. This hardware performs UDP source port validation and does not initiate BFD session when neighbor is using source port 3784. Conditions: This condition happens only with BFD Control Packets with Hardware offload. Workaround: Use BFD features that demands BFD packets to be processed in software, for example, BFD authentication. Further Problem Description: Last Modified: 11-MAY-2016 Known Affected Releases: 15.4(3)S4.1 Known Fixed Releases: * 15.4(3)S5.10, 15.5(3)S2.11, 15.6(1.27)SP Alert Type: Updated * Bug Id: CSCux51388 Title: AN: CD punting is getting enabled after save & reload without autonomic Status: Fixed Severity: 2 Severe Description: Symptom: ANrtr1 --- L2 (IOSswitch) L2 --- ANrtr2 When you connect two autonomic routers (ANrtr1, ANrtr2) via an L2 connection that is built via one or more devices providing a switched L2 connection, then AN between the two routers may fail: the autonomic control plane is not built, or if one device (e.g.: ANrtr2) is not yet AN enrolled, it will not enroll into autonomic networking. Conditions: This problem may happen if at least one of the device(s) terminating the L2 connection on ANrtr1 or ANrtr2 is running Cisco IOS 15.5(3)S - 15.6(1)S even though these devices are not configured for AN. save & reload without autonomic config Workaround: The issues exists because of a problem on the L2 IOS device(s) between ANrtr1/ANrtr2. See further problem description below to understand the issue. After you configure "no autonomic" on the L2 device in question, it will correctly forward CD packets between ANrtr1 and ANrtr2. The problem will reoccur after the next reboot though. To make the workaround persistent, configure an EEM script run after bootstrap: event manager applet CSCux51388-fix-cd-forwarding event syslog pattern "SYS-5-RESTART" action 1.0 cli command "enable" action 1.1 cli command "configure terminal" action 1.2 cli command "no autonomic" If you are running an IOS image without -k9 on the L2 device, autonomic can not be configured because it is not enabled in those images, but the problem still exists. There is no workaround for those images. You may want to change to a -k9 image in this case. If the L2 switch is provided by a service provider incapable of enabling the above workaround, there is no full workaround possible on ANrtr1/ANrtr2: It is not possible to zero-touch enroll e.g.: ANrtr2. If both ANrtr1/ANrtr are already configured devices, you can set up the autonomic control plane between them by manually configuring a GRE tunnel between them and enabling "autonomic adjacency-discovery" on both GRE tunnel interfaces. This will not rely/use the CD protocol and therefore not be subject to this problem. Further Problem Description: The cause of the problem is that Cisco IOS switches/routers may not transparently forward AN CD (channel discovery) packets across the L2 connection. This inhibits the automatic AN neighbor discovery between ANrtr1 and ANrtr2. A Cisco IOS device should transparently forward these CD packets as long as AN is not enabled. The problem is that after bootstrap, the default behavior is to not-forward these packets but instead intercept them - and because AN is not enabled, they are then dropped by the device. Last Modified: 20-MAY-2016 Known Affected Releases: 15.6(1.15)S Known Fixed Releases: * 15.5(3)S2.3, 15.6(0.22)S0.15, 15.6(1)T1.1 Alert Type: Updated * Bug Id: CSCuz22404 Title: ME3600x Constant Platform assert failure (del_l2m_phy_met) and traceback Status: Fixed Severity: 3 Moderate Description: Symptom: Traceback (platform assert failure: 0: ../src-nile/src-asic-nile/nile_adjmgr.c: 13987: del_l2m_phy_met) is seen when port-channel member links are flapped Conditions: Issue is seen when IGMP groups should be learned for VLANs of port-channel in IGMP snooping table and member-links are flapping. Workaround: Issue is not seen when port-channel member links are stable Further Problem Description: Last Modified: 25-MAY-2016 Known Affected Releases: 15.4(3)S2.1, 15.4(3)S4.1 Known Fixed Releases: * 15.5(3)S2.9, 15.6(1.31)SP Alert Type: Updated * Bug Id: CSCuu59327 Title: MVPN traffic not forwarded to locally connected receivers. Status: Fixed Severity: 3 Moderate Description: Symptom: MVPN traffic not forwarded to locally connected receivers Control plane entries including PIM,IGMP and Mroute all look good. Hardware programming is missing. Conditions: MVPN setup. Issue is seen in two triggers: 1. Remote PE sending join first before the local receivers. Local receivers do not get traffic. 2. Local PE send join first before Remote PE. Once Remote PE send join then traffic not forwarded to local receivers. Workaround: none Further Problem Description: Last Modified: 25-MAY-2016 Known Affected Releases: 15.5(1)S Known Fixed Releases: * 15.5(3)S2.10, 15.6(1.31)SP Alert Type: Updated * Bug Id: CSCuu62592 Title: MPLS data plane broken on ME3600 Status: Fixed Severity: 3 Moderate Description: Symptom: MPLS data plane is broken. Labeled traffic is dropped. IP traffic works fine Conditions: Link Flap or Reload Workaround: None Further Problem Description: Last Modified: 25-MAY-2016 Known Affected Releases: 15.5(1)S Known Fixed Releases: * 15.5(3)S2.8, 15.6(1.31)SP Alert Type: Updated * Bug Id: CSCuz60216 Title: Traceback when ping to remote SVI in L2VPN Status: Fixed Severity: 3 Moderate Description: Symptom: Traceback Conditions: Ping between PE to PE fails between two ME3600 and hits tracebacks. SR:638366511 Workaround: none Further Problem Description: Last Modified: 18-MAY-2016 Known Affected Releases: 15.4(3), 15.4(3)SS Known Fixed Releases: * 15.6(1.30)SP Alert Type: Updated * Bug Id: CSCuz45578 Title: ME3600 env power state machine broken Status: Fixed Severity: 3 Moderate Description: Symptom: 1.Syslog and snmpwalk are not reported for power supply restored state when less than 1 sec power supply is down. 2.when input power drops, we see the wrong syslog message ?output power faulty? (should be unkown) and snmp return code 2 (warning) instead of 3 (critical). Conditions: na Workaround: Syslog and snmpwalk are reported correctly for power supply restored state when greater than 1 sec power supply is down Further Problem Description: Last Modified: 11-MAY-2016 Known Affected Releases: 15.5(3)S Known Fixed Releases: * 15.4(3)S5.10, 15.6(1.29)SP Alert Type: Updated * Bug Id: CSCuy04249 Title: The 127th OIF Doesn't Work Status: Fixed Severity: 3 Moderate Description: Symptom: The 127th OIF Doesn't Work Conditions: On configuring the 127th OIF, the traffic is not passing on the 127th OIF interface Workaround: N/A Further Problem Description: Last Modified: 05-MAY-2016 Known Affected Releases: 15.3(3)S6 Known Fixed Releases: * 15.5(3)S2.11, 15.6(1.17)SP Alert Type: New Bug Id: CSCuw32890 Title: Interface descriptions disappear from running config after device reload Status: Fixed Severity: 3 Moderate Description: Symptom: After the box reboots for whatever reasons ( device reload or code upgrade ), the interface description would be missing from interface config, but it would be shown in 'show interface desc' command. Conditions: ME-3600X-24FS-M running code 15.5(3)s Workaround: No impact. Need to manually configure the description under Interface Configuration Further Problem Description: Customer noticed that ME3600 devices running version 15.5(3)S loses the interface descriptions in the running config when the device reboots. However when we issue the command "show interface description", the descriptions are displayed. Basically this happened during the reload while upgrading to 15.5(3)s from 15.4(2)S and it was across all the devices in the network. To resolve this, Customer need to manually configure interface description Last Modified: 25-MAY-2016 Known Affected Releases: 15.5(3)S Known Fixed Releases: 15.5(3)S0.14, 15.5(3)S1, 15.5(3)S1a, 15.6(0.21)S Find additional information in Bug Search index.   2015 Cisco and/or its affiliates. All rights reserved. Terms & Conditions | Privacy Statement | Cookie Policy | Trademarks