ICI team sales and services Cisco and Huawei network equipments. Most of our customers are medium and smaller service providers, who usually do not enjoy sufficient services. If you face similar challenges, talk with us and we might help you.
CRS-X line cards (CRS-MSC-X, CRS-MSC400G, CRS-FP-X, CRS-FP400G=, CRS-FP400G, CRS-LSP-X, CRS-LSP400G, CRS-MSC-X-L, CRS-MSC200G=, CRS-FP-X-L, CRS-FP200G, CRS-FP200G-L, and CRS-FP200G=) built with new DRAM memory fail to boot to the XR-Run state in XR releases of 5.3.3, 5.1.4, 5.1.3, 5.3.1, 5.3.2, 5.1.1, 5.1.2, and 5.2.2.
Symptoms: A vulnerability in MPLS LDP packet processing Cisco IOS XR could allow an unauthenticated, remote attacker to cause a reload of the MPLS LDP process on the affected device.
The vulnerability is due to improper processing of crafted MPLS LDP packet. An attacker could exploit this vulnerability by sending crafted MPLS LDP packets to be processed by an affected device. An exploit could allow the attacker to cause a reload of the MPLS LDP process on the affected device.
Conditions: Cisco IOS XR device configured to process MPLS LDP packets.
Workaround: Disable advertising of FECs with prefix length <=24
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 4.3/3.6: http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:N/AC:M/Au:N/C:N/I:N/A:P/E:F/RL:OF/RC:C&version=2.0 CVE ID CVE-2015-4223 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
[UNI-C] NC4K unnum tunnel creation with node inclusion expl path
Status:
Fixed
Severity:
2 Severe
Description:
Symptom: - the user try to create a OCHTrail optical-uni circuit on Unnumbered LM and specify a node inclusion - Explicit path configuration is sent correctly by CTC, but circuit creation fails
Conditions: Setup: - 2xNCSF4K connected to NCS2K network with LMP num/unnum
Stdby LC VM in "Node not Ready" state on A-RP activation during Cal-ISSU
Status:
Fixed
Severity:
2 Severe
Description:
ISSUE seen during cal-ISSU and reproducibility is 1/5
Symptom: this issue is seen when invmgr_init is called simultaneously from both smp_cb and pm_role_notify. due to simultaneous access to inv_conn_handle process crashes.
Conditions: ISSUE seen during cal-ISSU and reproducibility is 1/5
Workaround: setup is recoverable after PC
Further Problem Description: during CAL-ISSU stand by node is stuck in not ready state.it happens because smp_cb and pm_role_notify try to access the same inv_conn_handle simulataneously .As a fix invmgr_init has been removed from smp_cb since it is no longer required there.
Symptom: ARP not getting resolved which leads to traffic not getting forwarded
Conditions: After port shut-no shut as control queue which is having unlimited burst limit is exhausting all the buffers by the punt traffic. This leads to the ARP not getting resolved, which results in FlexLSP tunnel not coming up.
Enhanced fan failure recovery mechanism for Fabric card chassis
Status:
Fixed
Severity:
2 Severe
Description:
Symptom: This enhancement is to improve the fan failure recovery mechanism on fabric card chassis whenever a fan speed read failed due to i2c bus stuck condition. currently when one read of the fan speed failed due to i2c hang, subsequent fan speed read will also failed which will end up in the fan tray failure. To avoid this issue, we need to power cycle the fan tray once the i2c hang is detected. If after power cyle if the i2c hang is still seen, software should skip monitoring the fan
Conditions: whenever a fan speed reading is failed due to i2c hang, software has to follow an algorithm to isolate that failed fan and keep monitoring the other fan.
2016-03-03T05:19:57.373+00:00 tustca4200w-bcr00.tbone.rr.com TUSTCA4200W-BCR00 SC/F0/SC1/CPU0:Mar 3 05:19:57.360 UTC: i2c_server[62]: %PLATFORM-I2C_DRV-3-UNRECOVERABLE_BUS_HANG : Unable to recover the I2C bus 2016-03-03T05:20:02.179+00:00 tustca4200w-bcr00.tbone.rr.com TUSTCA4200W-BCR00 SC/F0/SC1/CPU0:Mar 3 05:20:02.165 UTC: envmon[136]: %PLATFORM-ENVMON-4-ALARM : MAJOR alarm generated by upper fan tray failed 2016-03-03T05:20:04.331+00:00 tustca4200w-bcr00.tbone.rr.com TUSTCA4200W-BCR00 SC/F0/SC1/CPU0:Mar 3 05:20:04.318 UTC: shelfmgrv2[172]: %PLATFORM-SHELFMGRV2-1-ALL_FANTRAYS_OFF : Critical Alarm: Alarm generated because all fans from all fan trays are off or failed. If at least one tray is not recovered within 45 seconds, the chassis will be shutdown 2016-03-03T05:20:49.332+00:00 tustca4200w-bcr00.tbone.rr.com TUSTCA4200W-BCR00 SC/F0/SC1/CPU0:Mar 3 05:20:49.319 UTC: shelfmgrv2[172]: %PLATFORM-SHELFMGRV2-0-CHASSIS_SHUTDOWN : CRITICAL: CHASSIS SHUTDOWN initiated due to no working fan trays in chassis
Workaround: none
Further Problem Description: when a i2c bus is hang while trying to read a particular fan speed, subsequent fan speed read will also fail as the i2c master will be busy. which will result in complete fan tray failure. in order to avoid that software has to isolate the faulty fan and keep monitoring other fans.
i2c is a serial bus that is used in CRS for low level communication such as temperature sensors and fan speed (rpm and control).
[QP4] Traffic switched for some tunnels in run phase of XR-ISSU on Tail
Status:
Fixed
Severity:
2 Severe
Description:
Symptom: Traffic switched for some tunnels at the start of run phase, if during load phase some configuration change was done on the head node.
Conditions: Software configuration/re-signnaling from mpls was done on the head node, when XR-LOAD phase was going on the tail node.
Workaround: NONE
Further Problem Description: During XR load phase change in configuration from MA.chkpt files are copied when load phase starts and are used when run phase starts.
Symptom: An intermittent crash in the telemetry encoder process is observed. The stack trace shows that this happens at schema_class_get_category in the MDA library, due to memory corruption.
Conditions: RootOper.InfraStatistics.InterfaceTable.Interface(*).Latest.GenericCounters is queried for.
Memory leak in mibd_infra on SNMP Polling of RTTMON MIB
Status:
Fixed
Severity:
2 Severe
Description:
Symptom: Increased memory utilization of mibd_infra
Conditions: SNMP Polling of RTTMON Objects
Workaround: None
Recovery: None Required If continuous leak increasing process memory footprint of mibd_infra, then recover using process restart mibd_infra, which will have temporary impact on SNMP polling of Infra objects.
mibd_infra crash on dynamic destroy of mplsvpnMonEntry with creat&wait
Status:
Fixed
Severity:
2 Severe
Description: *
Symptom: mibd_infra crash
Conditions: while doing : 1. This is not consistent nor reproable unless it's a first time SNMP query after turbo boot. 2. SNMP queries which triggers this : a. Create and wait set on rttMplsVpnMonCtrlTable b. Snmpwalk on the same table c. Destroy the table (without going active)
3. Since it's the create and wait operation, dynamic tuples created and held still in memory is getting deleted during the SNMP walk on the same table corrupting the heap. 4. Further, when destroy is attempted on such row, its leading to crash.
Symptom: Can not get source address and target address via SNMP for any probe.
Conditions: The source address and target address are not returned when queried through SNMP. The address translation from sysdb to user readable format is not done internally in the code.
Workaround: User can see the source address and target address using " show ip sla configure probe_id" CLI.
query on rttMonCtrlAdminTable and its members not returning values f
Status:
Fixed
Severity:
2 Severe
Description: *
Symptom:
1. SNMP query operations for the objects like rttMonCtrlAdminRttType, rttMonCtrlAdminVerifyData, rttMonEchoAdminTargetPort, rttMonEchoAdminInterval, rttMonEchoAdminNumPackets, rttMonEchoAdminProtocol with udp jitter probe configured on routerdo not return values as snmp query on rttMonCtrlAdminTable and its member objects not returning any values for them 2. Destination address along with port # can not be set via SNMP for udp jitter operation. The same is applicable to source address and port configuration via SNMP 3. query rttMonReactTriggerAdminStatus rttMonReactTriggerAdminTable not returning any value
Conditions:
snmpwalk, snmpget and snmpset on above mentioned rttmonmib objects
Symptom: This is an umbrella SMU for the following bug fixes:
CSCur31362 Sev2 [aaa-aaacore ] iedge process is crashing due to req_id leak. CSCus57050 Sev2 [aaa ] BNG: iedge needs duplicate detection for COA retransmits CSCur93199 Sev3 [aaa-radius ] asr9k BNG-iosxr 4.3.4-Memory leak at radiusd process
These fixes are highly recommended for BNG deployments on IOS XR release 5.2.4.
IPv6 umbrella for BNG deployments on XR release 5.2.4
Status:
Fixed
Severity:
2 Severe
Description:
Symptom: This is an umbrella SMU for the following bug fixes:
CSCut40941 Sev2 [ipv6-ma ] SSTE:IPv6_ma crash with scale IPoE V6 session CSCut42484 Sev2 [ipv6-nd ] After Rpfo seeing high CPU 25% for ipv6_nd while bringing up v4 sess CSCus33478 Sev3 [ipv6-nd ] Router send bogus ipv6 address in IPV6 NA message to peer side CSCuu74580 Sev2 [ipv6-nd ] Geo 532-9I:seeing dual partial-up on SLAVE with RPFOs
These fixes are highly recommended for BNG deployments on IOS XR release 5.2.4.
Stats Counters Exhausted Msg on metro LC upon remove/add ldp
Status:
Fixed
Severity:
2 Severe
Description:
Symptom:
Stats Counters Exhausted Message appears on Line Cards, resulting in CEF being unresolved for any further IPv4 and IPv6 labelled Prefixes due to failure of allocating Label stats.
Conditions:
Continuous ADD/DELETE of IPv6 Labelled prefixes, where prefixes belong to Global Default Table
Symptom:Install add command will fail stating pie/smu is corrupted or set the clock properly. This is due to the fact that our signing certificate will expire in Oct 2015.
Conditions:System clock crossed Oct17 2015 we will not be able to install add any SMU/Pie
Workaround:No workaround, need to install the Mandatory SMU. If customer is trying to install mandatory SMU before Oct 2015 then you have to use *pre* pie/SMU, if customer crossed OCT 17 2015, then *post* SMU should be used.
More Info:This DDTS is been raised to track the production build for SAM changes POST Oct 17 2015.
Mandatory SMU SAM changeset for certificate expiration.
Status:
Fixed
Severity:
2 Severe
Description:
Moving based on request from TAC engineers.Symptom:When we try to to install add any SMU/Pie post October 2015 all will run in to this error. Since our certificate will expire at oct 2015.
Error: Cannot proceed with the add operation because the code signing Error: certificate has expired. Error: Suggested steps to resolve this: Error: - check the system clock using 'show clock' (correct with 'clock Error: set' if necessary). Error: - check the pie file was built within the last 5 years using Error: '(admin) show install pie-info Error: /tftp://202.153.144.25/auto/tftp-sjc-users3/jamohamm/IMAGES/asr9k- Error: mcast-px.pie-4.3.2'.
Conditions:Install add on any SMU/Pie post Oct 2015.
Workaround:No workaround as of now.
More Info:We will not be able to add any SMU/Pie post Oct 2015.
Multicast Traffic loss During soft RPF0 on SIP-700
Status:
Fixed
Severity:
2 Severe
Description:
Replication of PIM GRE packets is an enhancement to support NSR from 522 which requires PIM topology states being programmed upfront on both Active and Standby RSP.
To create state upfront PIM rely all hellos, Joins, asserts, Data TLVs etc being replicated on both active and standby RSP by LPTS for native and MVPN purposes.
Since PI team changed the behaviour, some changes required in PD as well. So the functionality will broken from 522 and later upgrades.
Symptom: Momentary traffic loss(about 42sec) observed during RSP switch over, When standby become active.
Conditions: In a MVPN setup with 522 release image, when SIP-700 placed as a core facing LC
Workaround: None
Further Problem Description: RCA of the problem was that the core facing Thor LC is not sending the PIM Join,Assert,hello, Data TLVs to standby RSP. When a RSP switchover is done the Data MDTs get deleted and reprogrammed because they are learnt as new routes when the standby becomes active.
R60y-8c:4.7 sec Traffic hits seen on run phase of XR ISSU on middle node
Status:
Fixed
Severity:
2 Severe
Description:
Symptom: After Lc vm switch over during ISSU trigger reconfig is happening for Gearbox leading to traffic glitch. Gearbox reconfig is happening as there is mismatch found in signature of scrath pad register.
Conditions: Glitch issue is observed only during ISSUE trigger from lineup 5.2.47 to r60y
Workaround: Glitch is observed only on port 1 due to the Gearbox reconfiguration. So do configuration only on port 0 of Arwen LC
Further Problem Description: Gearbox reconfiguration on port 1 of Arwen Lc
hfr_fgid_show_items is blocked resulted in inbarhb fgid Dump CLI Failure
Status:
Open
Severity:
2 Severe
Description:
Symptom:When we enter the below command to check the inbarHB fgid association, there is no output returned for 3-4 mins sh controllers fabric fgid information id 47103 brief
Conditions:1. Topaz MSC Physical OIR Scenarios 2. Enter the below command sh controllers fabric fgid information id 47103 brief
Workaround:Power disable the Card using the XR command Topaz MSC Physical OIR Power enable the Card using the XR command
NCS1K: FCS error found in bidirectional traffic over 100GE client ports
Status:
Open
Severity:
2 Severe
Description:
Symptom: FCS error was found in 100G client port in bidirectional traffic in traffic stress test.
Conditions: observed rarely in few attempts in traffic stress test upon reconfiguring all slices with toggling between different FECs(SD7 and SD20) each time . also this is observed only on some specific ports, not all.
SC cards take more than 2 hours to go to XR RUN state
Status:
Terminated
Severity:
2 Severe
Description:
Symptom: After FCC reload (in a x+2 system) CRS-FCC-SC-22GE-B can take more than 2 hours to go to XR RUN state.
Conditions: XR 5.3.3 + hfr-px-5.3.3.CSCuz09063.pie SMU is installed and FCC rack is reloaded due to reboot SMU install or manual reload or any other reason
Workaround: None. SC card completes bootup and recovers after a while
Further Problem Description: Initial DE analysis: As I checked the logs, I can see the delay in response of FGID Server for its registration. The delay is for 2 minutes.
MAPD sent the registration request at: Apr 18 16:22:26.422 odg_local/0/trace 0/RP1 t31202 In connect_cb rc: 'Subsystem(646)' detected the 'unknown' condition 'Code(30)': Unknown error 165 Apr 18 16:22:26.422 odg_local/0/trace 0/RP1 t31202 Registering to FGID server
FGID Server is replying to MAPD for its registration after 2 minutes at: Apr 18 16:24:12.704 odg_local/0/trace 0/RP1 t31202 In fgid_client_register_resp mapd_fgid_resync_fgid_alloc rc: Success Apr 18 16:24:12.704 odg_local/0/trace 0/RP1 t31202 In fgid_client_register_resp mapd_fgid_resync_fapid_bitmap rc : Success Apr 18 16:24:12.704 odg_local/0/error 0/RP1 t31202 In function odg_pd_init_resp_cb succeess status
As there is delay in response of registration from FGID Server, FGID is going 0. This delay needs to be checked by FGID Server team.
Symptom: RF observed on all Client ports in a Back 2 Back NCS1k in a specific P2 NCS1k during 40G Stress test.
Conditions: could Occur once in a 7-8 attempts in 40G Client mode provisioning. This problem occurred only in slice1 of a specific P2(P2_9) during development. It was not observed during Pilot Ncs1k Stress testing.
Workaround: Apply shut/no shut on Trunk/CoherentDSP over which Client payload is carried.
Symptom: When you configure the slice, occasionally you see that Tx down of QSFP in any one of the ports.
Conditions: CDR Serdes of that port is stuck or reset and hence no Rx to QSFP Repetition : 1 out of 20 times and no fixed pattern to encounter this issue
KT CFD: ACL drops agg'ted in 'total input drops' on 'sh inter' for Topaz
Status:
Fixed
Severity:
2 Severe
Description: *
Symptom: ACL drop counts are added to the 'total input/output drops' field in 'show interface ' command output.
The actual ACL drop counts should be looked up using the command: 'show access-lists ipv4 hardware ingress location ' 'show access-lists ipv4 hardware egress location '
Conditions: When packets are dropped at the ingress due to an ACL policy match.
Workaround: None.
Further Problem Description: Based on the ACL policy, the packet drops are expected at the ingress interface. These drops are accounted for, and can be see using the following CLI - 'show access-lists ipv4 hardware ingress location ',
The expected behavior on CRS-X is that the ACL related drop counts should not be included in the 'total drop counts' field in the 'show interface ' command.
Unicast traffic to MH ToR/Leaf dropped when BGP to DC fabric is down
Status:
Open
Severity:
2 Severe
Description:
Symptom: ASR9K VXLAN L2 Gateway PE drops traffic destinated to a multi-homed ToR/Leaf.
Conditions: When a DCI PE is connected to Data Center (DC) fabric via IGP and BGP connection to DC fabric is down, the PE puts MAC routes under EVPN port(MPLS Core facing port) as MACs are learnt from MPLS Core. This DC will send ES and EVI EAD routes as NVE interface isn't down, causing traffic to be received from remote DCI due to MAC Aliasing in remote DCI. Traffic will be dropped in the DCI as destination MACs are also under EVPN port causing traffic black hole.
Workaround: None
Further Problem Description: Traffic black holing persists as long as the error condition lasts: IGP to DC fabric is up and BGP to DC fabric is down.
Symptom: Process l2vpn_mgr exited with signal 11 (SEGV - Segmentation Fault) @l2vpn_fwd_get_l2fib_pw_load_balancing
Conditions: There was a changes made to the l2vpn configuration right prior to the fault here. However, the issue was not reproduced in-house with simply this configuration change. RP/0/RSP0/CPU0:r1.nik.ams# show configuration commit changes 1000000553 Fri Mar 25 16:21:08.596 MET Building configuration... !! IOS XR Configuration 5.1.1 l2vpn no bridge group TMG bridge group TMG no bridge-domain TMG-VLAN21 bridge-domain TMG-VLAN21 no neighbor 10.10.10.3 pw-id 21 neighbor 10.10.10.3 pw-id 21 no backup neighbor 10.10.10.4 pw-id 21 ! no routed interface BVI21 ! ! ! end
NCS1k: XR reload should be blocked during FPD upgrades
Status:
Open
Severity:
2 Severe
Description:
Symptom: Reload from XR will reload XRVM interrupting fpd upgrade. FPD will come back with NEED UPD state. There was no harm seen. But its advisable not to interrupt FPD.
Conditions: reload issued from XRVM, when FPD upgrade is in progress.
Workaround: don't issue reload from XRVM unless FPD upgrade is complete. run 'show hw-module fpd' to see if any FPD in progress. If there is any FPD in progress don't reload VM.
[ISSU] : Hyphy Card got reloaded on Active RP activation during Cal-ISSU
Status:
Terminated
Severity:
2 Severe
Description: *
Symptom: NCS4K-24LR-O-S got reloaded on Active RP activation during Cal-ISSU.
Conditions: During SysAdmin ISSU on Active Route Processor ativation, one NCS4K-24LR-O-S got reloaded which lead to a traffic hit for long time . Issue was observed while testing N+1 -> N -> N-1 ISSU
ESD Process going down after installing Xr_issu SMU
Status:
Fixed
Severity: *
2 Severe
Description:
Symptom: VTY sessions are dropped during the ISSU load phase procedure. Once lost they are no longer accessible.
The RP1 mgmt went down during ISSU load phase (time stamp: Aug 5 15:42:08.968).
RP/0/RP1/CPU0:Aug 5 15:42:08.968 : ifmgr[138]: %PKT_INFRA-LINK-3-UPDOWN : Interface MgmtEth0/RP1/CPU0/0, changed state to Down RP/0/RP1/CPU0:Aug 5 15:42:08.968 : ifmgr[138]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface MgmtEth0/RP1/CPU0/0, changed state to Down
After the sdr reload, I see that mgmt on RP0 also went down (time stamp: Aug 5 15:49:55.925 ). By then the ISSU clean up phase was completed (time stamp: Aug 5 15:48:38 2015)
RP/0/RP0/CPU0:Aug 5 15:49:55.925 : ifmgr[333]: %PKT_INFRA-LINK-3-UPDOWN : Interface MgmtEth0/RP0/CPU0/0, changed state to Down RP/0/RP0/CPU0:Aug 5 15:49:55.925 : ifmgr[333]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface MgmtEth0/RP0/CPU0/0, changed state to Down
ISSU summary confirms these time stamps.
RP/0/RP1/CPU0:R105-PE5#show issu summary Last ISSU operation completed successfully. List of ISSU phases: ------------------------------------------------------------ Phase name : Prep Phase Status : Completed Start time : Wed Aug 5 15:24:23 2015 Complete time : Wed Aug 5 15:27:19 2015 ------------------------------------------------------------ Phase name : Load Phase <<<< Status : Completed <<<<< Start time : Wed Aug 5 15:30:04 2015 <<<<< Complete time : Wed Aug 5 15:46:47 2015 <<<<< ------------------------------------------------------------ Phase name : Run Phase Status : Completed Start time : Wed Aug 5 15:47:28 2015 Complete time : Wed Aug 5 15:47:28 2015 ------------------------------------------------------------ Phase name : Cleanup Phase Status : Completed Start time : Wed Aug 5 15:48:38 2015 Complete time : Wed Aug 5 15:48:38 2015 ============================================================ RP/0/RP1/CPU0:R105-PE5#show interfaces brief | i Mgmt Mg0/RP0/CPU0/0 down down ARPA 1514 0 Mg0/RP1/CPU0/0 down down ARPA 1514 0
Conditions: Performing ISSU for a smu installation. Upgrade is unknown at this point but we can assume it will apply as well
Workaround: you have to retstart esd process on location all from calvados
All SFE link for Hy-phy LC are in operational down state.
Status:
Open
Severity:
2 Severe
Description: *
Symptom: Line card fabric links stay operationally down after Router reload or Line Card reload.
Conditions: Issue may be seen on one or more fabric links. Triggers include: 1. Physical removal/insertion of Line Card. 2. Router reload 3 Soft reload of Line Card.
Workaround: Expected Resolution: This issue is under investigation.
isis lsp md5 authentication fails for lsp with system-id set to 6
Status:
Fixed
Severity:
2 Severe
Description:
Symptom: ========
A CRS-1 or XR12000 router configured for ISIS LSP MD5 authentication may send LSPs to neighbors that fail the MD5 checksum match. The only LSPs that fail are LSPs that the IOS-XR box received from other ISIS peers that have the System-id length field in the LSP header set to 6.
The IOS-XR router is always setting this System-id length to be 0 irrespective of the incoming LSP's header value received before flooding the LSP to it's neighbors.
The result is the MD5 checksum check fails and the LSP that the IOS-XR box flooded is not accepted by the peer device.
When this happens the following errors may be seen on an IOS ISIS neighbor.
This is only happening in ISIS networks with non-Cisco routers that send System-id length field set to 6. All other LSP that have System-id length field set to 0 are unaffected.
Tacacsd regularly crashes with repeated Aux Port no uname login attempts
Status:
Fixed
Severity:
2 Severe
Description:
Symptom: Tacacsd regularly crashes with repeated Aux Port no uname login attempts.
Condition: Observed with aux port tacacs authentication enabled, and aux port connections to terminal servers that may spew login banners or other erroneous output to the aux port.
Workaround: Remove the terminal server aux port connection when not in use, or login to aux port, via the terminal server to stop the condition. Or, don't enable tacacs authentication on aux port.
NCS4K : XR LOAD phase Aborted error with syntax error for protection
Status:
Terminated
Severity:
2 Severe
Description:
Symptom: XR ISSU aborts on ISSU from 5247 to 601 release. With following error:
!!09:02:34 UTC Mon Apr 11 2016 !! SYNTAX/AUTHORIZATION ERRORS: This configuration failed due to !! one or more of the following reasons: !! - the entered commands do not exist, !! - the entered commands have errors in their syntax, !! - the software packages containing the commands are not active, !! - the current user is not a member of a task-group that has !! permissions to use the commands.
Conditions: When ISSU is performed on NCS4K from 5.247 to 6.01, with "protection-type " Configuration applied.
Workaround: Do not apply "protection-type " Configuration in 5.2.47
Further Problem Description: User is not expected to use 1+1, 1+1, 1+1+R protection schemes in 5.2.47. Hence is not expected to perform this configuration
RP stuck in operational lock after CCC-FPGA upgrade
Status:
Terminated
Severity:
2 Severe
Description:
Symptom: RP stuck in operational lock in show platform
Conditions: CCC-FPGA upgrade
Workaround: no WA available as tried to restart the fpd server process but it did not help. RP went for a reload after 1 hour and recovered automatically.
Issue in configuring OTN mode after removing from packet mode on Arwen.
Status:
Fixed
Severity:
2 Severe
Description:
Symptom: Issue in configuring OTN mode after removing from packet mode on Arwen.
Conditions: After moving the interface from packet mode.
Workaround:
Further Problem Description: After removing the packet mode from the interface when I am trying to configure with OTN mode , it's getting error out with following error.
% Failed to commit one or more configuration items during a pseudo-atomic operation. All changes made have been reverted. Please issue 'show configuration failed [inheritance]' from this session to view the errors
RP/0/RP0:vpws_frodo(config-Optics)#show configuration failed inheritance Fri Jul 10 02:26:17.739 UTC !! SEMANTIC ERRORS: This configuration was rejected by !! the system due to semantic errors. The individual !! errors with each failed configuration command can be !! found below.
controller Optics0/6/0/2 port-mode Otn framing opu2 !!% Unable to query IM attr for requested interface: 'portmode' detected the 'warning' condition 'Unable to query IM attr for requested interface' ! End
Here even though we do ?un shut? the controller , it remain in DN state .
RP/0/RP0:vpws_frodo(config)#controller optics 0/6/0/2 RP/0/RP0:vpws_frodo(config-Optics)#no shutdown RP/0/RP0:vpws_frodo(config-Optics)#commit RP/0/RP0:vpws_frodo(config-Optics)#do show controllers optics 0/6/0/2 Fri Jul 10 04:36:14.042 UTC
Controller State: Down
Transport Admin State: In Service
RP/0/RP0:vpws_frodo#show running-config controller optics 0/6/0/2 Fri Jul 10 04:44:15.014 UTC % No such configuration item(s)
RP/0/RP0:vpws_frodo(config-Optics)#do show version Fri Jul 10 02:33:07.972 UTC
Cisco IOS XR Software, Version 6.0.0.06I Copyright (c) 2013-2015 by Cisco Systems, Inc.
Build Information: Built By : abhharih Built On : Wed Jul 8 15:30:17 IST 2015 Build Host : bgl-ads-2296 Workspace : /nobackup/abhharih/xspeed_latest Version : 6.0.0.06I Location : /opt/cisco/XR/packages/
RP/0/RP0:vpws_frodo(config-Optics)#do show hw-module fpd | in 0/6 Fri Jul 10 04:40:24.764 UTC 0/6 NCS4K-2H10T-OP-K 0.2 CCC-FPGA CURRENT 1.10 1.16 0/6 NCS4K-2H10T-OP-K 0.2 CCC-Power-On CURRENT 1.03 1.03 0/6 NCS4K-2H10T-OP-K 0.2 DIGI1 CURRENT 2.03 2.03 0/6 NCS4K-2H10T-OP-K 0.2 DIGI2 CURRENT 2.03 2.03 0/6 NCS4K-2H10T-OP-K 0.2 Ethernet-Switch CURRENT 1.01 1.01 0/6 NCS4K-2H10T-OP-K 0.2 PLX-8649 CURRENT 0.02 0.02 0/6 NCS4K-2H10T-OP-K 0.2 Primary-ZYNQ CURRENT 1.04 1.04
Steps to Repro ***************** Configure ethernet packet mode
% Failed to commit one or more configuration items during a pseudo-atomic operation. All changes made have been reverted. Please issue 'show configuration failed [inheritance]' from this session to view the errors
Tail node tunnel configs not released after deleting circuits from head
Status:
Fixed
Severity:
2 Severe
Description: *
Symptom: Stale tunnels observed at the Tail end after a sequence of Tunnel Create and Delete along with Active RP reloads
Conditions: 1.With RP0 active, create circuits originating from Head to Tail 2. Reload and Stop RP0 at Tail at Boot Manager 3. With RP1 active, Deleted newly created circuits whilst retaining the old ones 4. Recovered RP0 from boot manager. 5. Wait for redundancy establishment 6. Reload RP1 to switch to RP0. 7. Delete all tunnels from Head 8. It is observed that tunnels are still present in the mpls details of tail as tail configs.
Headless SDR post RP-PLX upgrade and active RP reload
Status:
Fixed
Severity:
2 Severe
Description:
Symptom:
One of the node (either RP or LC) XR VM will go down head less .
Conditions: This can happen after card reload of XR Active either by hw mod command or calvados NBN or PLX upgrade. Trigger is reload of card where XR is active.
It can also happen with node reload of xr active. But the chances are less.
Since for this to happen sdr-sm-> sdr-rm or sdr-rm -> sdr-nm connectivity should be interrupted. Workaround:Node goes for reload due to head less and recovers by itself.
Netconf answer truncated in case of a failed controller
Status:
Fixed
Severity:
2 Severe
Description:
Symptom: On execution of controller table get query, netconf response is truncated with this error: 'Subsystem(5473)' detected the 'warning' condition 'Code(15)'
[NCS4K-2H-W] RTRV-OTL show OPR values in wrong way
Status:
Fixed
Severity:
2 Severe
Description:
Symptom: When RTRV-OTL command is executed, OPR values were being displayed improperly, with next lane data merging with the one before. Also rtrv-otl for specific fac was displaying invalid aid response.
Conditions: On scapa node with DWDM LC and traffic up and running, execute RTRV-OTL command to retrieve optics lane data.
Workaround: None
Expected Resolution: Will be given in later release after 5.2.4.
SVG is not getting updated in Network View with Alarm Profile
Symptom: The image Icons present in network view map sometimes go out of synch from Alarm table.
Conditions: Apply alarm profile on a card in the node. Change the severity of the alarm. Sometimes SVG color does not remain in sync with the alarm table.
NCS4K : "Switch Ethernet link fault " stuck alarm on HA triggers
Status:
Fixed
Severity:
2 Severe
Description:
Symptom: Customer might experience GCC traffic disruption on line card reload or shutdown and power up. Through CLI the following alarm log can be seen (example)
0/LC3/LC_SW/8 Minor Ethernet 03/23/1970 21:21:56 Switch Ethernet link fault
Software fails in recovering SGMII bus connection between the DataPath FPGA and the Ethernet switch on the line card; this link carries Ethernet frames and is connecting GCCs to the RP.
Conditions: Problem frequency is very low. It happens only on performing a cold reboot of DWDM line cards or after several chassis power cycles.
[UNI-C] NC4K tunnel creation failure when WL re-tune is required
Status:
Fixed
Severity:
2 Severe
Description:
Symptom: OCHTrail tunnel will not come up and stays down.
Conditions: 1. Wavelength configuration isn't done on optics controller on NCS4k node. 2. To reach neighbouring NCS2k node, NCS4k has routes over multiple IPv4 interfaces.
Workaround: Apply Wavelength configuration on optics port at NCS4k before circuit creation.
Symptom: The color of svg ports are not in sync with the alarms present in alarm table.
Conditions: open Arwen card with 2 or more sessions and performe some operations like raising alarms and clearing alarms and check with all session , the issue will hit.
NCS4K-CTC System install type should display all PKG from XR & Sysadmin
Status:
Fixed
Severity:
2 Severe
Description:
Symptom: Whenever a Sysadmin SMU is added using INSTALL TYPE as SYSTEM, CTC by default tries to Add it using XR , which eventually fails as it can only be done on SYSADMIN.
Conditions: Activating a Sysadmin SMU is failing When the Install type is selected as SYSTEM
calvados inst mgr crash seen during System Upgrade
Status:
Fixed
Severity:
2 Severe
Description:
Symptom: calvados inst mgr crash seen during System Upgrade. CTC gets hanged
Conditions: While SU, during install prepare and activate, inst mgr crash seen on calvados.
Workaround:
Further Problem Description: CTC keeps on triggering show active/committed queries in background when SU is going on. while install agent is working on creating active sw profile. it may happen that at same time show install active xml query from ctc comes to install agent. At this point, the show query will not be able to access the profile info, since the install agent is already accessing that file. so it returns with no output. and on calvados install manager a graceful handling of this NULL output was not taken care of. so the crash is observed.
PRBS PM getting blanked in card veiw after moving to different tabs
Status:
Fixed
Severity:
2 Severe
Description:
PRBS PM getting blanked in card veiw after moving to different tabs
Symptom: On changing tabs from PRBS Stats do different tab and coming back to it , PM values for ODU controllers are getting blank.
Conditions: Create an ODU controller and configure a PRBS from PRBS Config tab with mode as Sink or Source-Sink. go the PRBS Stats pane there should be the PM counters with counter values. Now change the tab and again come on PRBS Stats pane , all data goes blank.
[CTC unnum] discovery of unnum LMP not correct with multiple link
Status:
Fixed
Severity:
2 Severe
Description:
Symptom: When multiple LMP link are present between NC4K and NCS2K nodes, the following issue are observed: - LMP provisioning tab at network view list only one of unum LMP link for each N2K-N4K pair - The number of LMP link is also incorrect at map view (intermittent) - Tooltip (or right click info) on LMP link on map view show correct end point sonly for one LMP link
Conditions: Create multiple unnum LMP link between NCS2K-NCS4K node pair
Workaround: Problem is persistent on CTC restart
Further Problem Description: will be fixed in next release
Symptom: Near end controller's sapi/dapi/OS values in ODU TTI automatically sets for far end controllers also. Error message pop up while setting sapi/dapi value on UNI Controllers.
Conditions: 1) When we set expected TTI on head node NNI controller, Transmitted TTI automatically get set on Tail node, which is wrong behavior. - On both Non-OTN and OTN data paths 2) when sapi/dapi/Operator string is set in ODU-TTI pane, expected on UNI controller, it shows error message and doesn't set Expected TTI. - Only on OTN data paths
Workaround: NONE
Further Problem Description: Reproducibilty: For 1st issue, it is 100% reproducible 2nd issue is intermittent.
421_Scale: sysdb_shared_sc crashed after OIR DSC stdby RP
Status:
Fixed
Severity:
3 Moderate
Description: *
Symptom: after standby RP OIR, sysdb_shared_sc gets asserted. Conditions: This issue should exist on every release after 3.9. Workaround: none. After this assertion, everything should get recovered.
Bundle Infra changes to manage b/w change for load balancing
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: WAN PHY b/w is incorrect and hence applications do not use/report the right b/w
Conditions: Infra support lacking for WAN PHY b/w due to which higher than actual b/w is reported to applications/clients. In certain cases, this results in favouring Cisco gear with WAN PHY over other vendor links.
CRS : Fix for potential infinite loop in bundlemgr_adj code.
Status:
Fixed
Severity: *
3 Moderate
Description:
Symptom: Bundle manager Adjacency process will be spinning in an infinite loop.
Conditions: In function bmp_prog_rx_adj_write() , if call to imc_pic_get_node() fails continuously, it creates an infinite loop.
Workaround: An LC reload will fix this issue.
Further Problem Description: This issue identified while doing a closure code walk through. It is strongly advised to have this fix on production router to avoid any further infinite loops.
Symptom: This DDTS provides the basic infra support to have Ltrace support in the hfr/lc/aib/topaz.
Conditions: There was no support for addition of Ltraces in the packet flow for topaz/aib component. This DDTS intends to provide a infra by which new Ltraces can be added and same can be made use on the device.
Workaround: Leveraged the Ltrace infra and added additional infra support required for this component.
Further Problem Description: The newly added traces will be helpful to enhance the debug options available for the component. Tracepoints can be added with this infra to display the required entity contents.
[ISSU]:OSPF process crash during Cal vados ISSU on tail node
Status:
Open
Severity:
3 Moderate
Description:
Symptom: With the current design, it is possible that due to a possible but rare race condition with lwm event ipc, event-structure may have gone stale resulting in a assert in receiving process. This most likely occurs during ISSU period, when ospf process is coming up on standby RP.
Conditions: This problem is seen very rarely (infact only once) during ISSU. Since ospf does not release its event-structure unless it has to cleanup and restart, in order for this race condition to surface, there is a need to have a condition that requires ospf to exit and restart during ISSU period.
Workaround: None required. Once process is restarted, it automatically recovers.
Conditions: image: Refpoint = calvados/release@main/17 Built By : lucaslee Built On : Sun Mar 27 19:01:14 EDT 2016 Build Host : ott-lb-028 Workspace : /workspace2/lucaslee/xr-dev-0327 Source Base : ios_ena Devline : xr-dev.lu Devline Type : ACME Lineup xr-dev EFR-00000323204 Lineup
Umbrella DDTS for MAC FPGA reset and L2TCAM parity error handling
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: It has 2 bugs in this umbrella
CSCuy44864 Tx and Rx MAC FPGA SBE interrupts are always treated as essential. Ideally the essential bit index will be identified by the software from the predefined EBD file loaded in the FPGA. If the value at the index is 1 then the bit should be essential else it should treat as non essential bit. But due to software bug in the code, Tx and Rx SBE errors are always treated as essential. Also the Tx FPGA EBD file is not correct.
CSCuy49290 This enhancement is to change the below actions
1. For all L2TCAM parity error, reset will happen if 2 error per second or 8 errors per day, earlier it was 5 errors per sec and 20 errors per day. 2. For all L2TCAM parity error, at second hard reset shutdown the card, earlier it is 5 the hard reset reload the card. 3. Changing the HSS PLL LOCK sw action form PON RESET to NONE
Conditions: CSCuy44864 When the SBE interrupt occurred on the Tx or Rx MAC FPGA
CSCuy49290 whenever L2TACM parity error happened, software will add into a count, then will do asic reset for that instance. if the second hard reset happened for the same instance, SW will shutdown the board.
This enhancement will persist even across LC reload by manual or any other failure case
Workaround: NA
Further Problem Description: Please read individual DDTS RNE
Symptom: The mibd_interface process may start leaking memory
Conditions: This problem can be observed when polling the following OIDs: ciscoIetfIpMRouteMIB (1.3.6.1.4.1.9.10.117) or ciscoIetfPimExtMIB(1.3.6.1.4.1.9.10.120).
User = tinhuang Host = sjck-gold-29 Workspace = /san1/nightly/xr-dev_15.12.19C/ncs4k Lineup = xr-dev/all.lu%XR-DEV_NIGHTLY_15_12_19C XR version = 6.0.1.12I
### Broadcom SDK Information
Refpoint = thirdparty/broadcom-pp/fabric/release@thirdparty-ncs/4 Built By : mbaratam Build On : Wed Dec 2 06:31:05 PST 2015 Build Host : sjc-ads-137 Workspace : /nobackup/amimalik/tp-ncs-02-12 BRCM SDK Version : sdk-6.4.7 thirdparty-ncs EFR-00000317749 Project thirdparty EFR-00000314729 Lineup
### Thirdparty Information
Refpoint = thirdparty/opensource/release@tp-main/268 Hostname : sjc-ads-1005 Workspace : /auto/thirdparty-sdk/release/268 Source Base : ios_ena Devline : thirdparty.lu%EFR-00000318604 Devline Ver : EFR-00000318604 Devline Type : ACME Lineup
### Calvados Information for architecture
Refpoint = calvados/release@main/15 Built By : tinhuang Built On : Sat Dec 19 23:53:37 PST 2015 Build Host : sjck-gold-29 Workspace : /san1/nightly/xr-dev_15.12.19C/ncs4k Source Base : ios_ena Devline : xr-dev/all.lu%XR-DEV_NIGHTLY_15_12_19C Devline Type : ACME Lineup xr-dev EFR-00000319361 Lineup
Signal information: Program terminated with signal 11, Segmentation fault.
[arwen] traffic not recovered after CPAK type swap
Status:
Terminated
Severity:
3 Moderate
Description:
traffic not recovered after CPAK type swap
Symptom: traffic fine between 2 cpak sr10 of arwen card, unplug cpak 1 sr10, re plug an LR4 : traffic is not recovered automatically : had to reload the card.
Error with attaching a policy (priority class) to an interface via XML
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: Configuring a service-policy under interface with priority action is getting rejected Conditions:
Priority action configured in a policy-map via XML without using Level tag (i.e as below example request) the default value is considered as zero(which should be 1) due to which when applying the policy-map on to the interface it gets rejected
MinorVersion="0">QOSp1qQOSclass-default
Workaround: A priority action need to be configured with Level info ex request.
CFM interface MEP config incompatible with services with special chars
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom:
On a Cisco IOS-XR router with Ethernet CFM configuration, if a CFM Maintenance Association (service) is configured with (at least one) special character in its name ("\'`\"<>()[]{}/\\&^!?~*%=,.+|"), then that service cannot be used to configure a CFM MEP on a (sub-)interface via the CLI. The configuration will be accepted, but will not be processed correctly: - show run will show a different service name configured with any special characters replaced with percent-encoding - show ethernet cfm configuration-errors will indicate that the service is not configured globally
If the CFM MEP configuration is configured via XML, then the configuration will be processed correctly, but: - show run will fail to display the service name at all, and an IOS message indicating a failure to decode will be emitted
Conditions:
The Symptom is only seen when there is Ethernet CFM configuration, with at least one local MEP configured, and the corresponding service for the MEP has a special character in its name.
Workaround:
The following workarounds may be used: - Rename the CFM service so that it no longer has special characters in its name - If special characters are required as part of the SMAN (which forms part of the MAID in CFM Continuity Check Messages (CCMs)), then rename the service so that it no longer has special characters in its name, and also configure an ID (e.g. service ser_name down-meps id string ser_%_name) - Configure the CFM service via XML, however this will still result in the last symptom described above.
ISSU[DT45->DT47]: ext_alm_mgr crash during Active RP sysadmin upgrade
Status:
Open
Severity:
3 Moderate
Description:
Symptom: sdr_mgr, ext_alm_mgr and sdr_kdump generated. During ISSU as Sysadmin upgrade of active RP0 gets finished, all the traffic is down and both RP reloaded.
NCS1K:Loopback denied even though optics controller is in MA state
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: Loopback configuration is failing on coherent dsp controller
Conditions: Parent optics controller must be in Maintenance state.
Workaround: NONE
Further Problem Description: Expected Resolution: Please check with the support engineer for information on which release(s) this bug is expected to be fixed.
VZ NCS4K:RSVP-TE card attribute fields are not edited asdesired on Apply
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: Changes to the last field modified in CTC tab is not made when Apply button is clicked.
Conditions: If the user inputs a value in one of the fields and immediately selects "Apply", the change to the last field modified is not made. The previous value is kept.
Workaround: NA
Further Problem Description: Reproducibility(%):100%
NCS4K VZ:Explicit path not store correctly through CTC on Node.
Status:
Fixed
Severity:
3 Moderate
Description:
1+1+R:Explicit path not store correctly through CTC on Node.
Symptom: The explicit path configured for respective nodes should be stored on there respective node. Explicit path of respective node should not shown as explicit paths of other node in the network.
Conditions: Strong one explicit path also store the other explicit path on the node automatically which was wrong
Workaround: None
Further Problem Description: Expected Resolution : Shall be available in Next Release
PRBS-PM counters is not getting cleared in case of pattern changed
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: PM counters retain their value after reconfiguring changing configured pattern . PM counters should be reset to default & bucket should be Invalid
Conditions: Check PM counters on Sink port
Workaround: The issue will not be seen if ODU OTN layer is not configured
Further Problem Description: Expected Resolution: This issue will be fixed in future release.
Symptom: Exercise basically used to check whether the respective LSP is ready to take the traffic or not. So this bug is for Signaled failed for this scenario it is failing.
It doesn't impact the customer because it is just a exercise command.
Conditions: While editing a circuit.Apply exercise command at Tail Node in CTC.
Workaround: User can check in Protection pane in edit dialog if signaled failed then user can avoid the exercise command.
Expected Resolution:This bug would be covered in 6.0 release.
Symptom: Subport number is not visible for breakout controllers in CTC
Conditions: Configure a breakout controller on Optics controller.
Workaround: None
Further Problem Description: Expected Resolution: Please check with the support engineer for information on which release(s) this bug is expected to be fixed.
NCS4K:Hold Off timer help text displaying as seconds
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: The Protection profile timer " Hold Off timer "configuration command help text on IOSXR CLI(5.2.41) is displayed as seconds instead of milliseconds.
Conditions: While configuring the Protection profile from IOS XR CLI(5.2.41), the Hold Off timer help text is displayed as seconds.[ <100-10000> seconds].
Symptom: XML query does not contain the info about RP, ECU, craft Same PcbSerialNum is repeating for multiple ports on the card with 10+ pluggables Missing few XML tags in few images like HWID
Conditions: Same PcbSerialNum is repeating for multiple ports on the card with 10+ pluggables
Workaround: XML query will get the info about RP,ECU and craft info
Arwen: Force FPD upg of PLX blocks other FPD upg for a long time
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: If we issue an Calvados fpd upgrade from XR under specific condition,upgrade will complete. But after this, if we try to upgrade any other FPD, we will get UPGRADE_IN_PROGRESS message.
Conditions: Issue is seen if calvados "fpdserv" process is restarted, just before the calvados fpd upgrade is issued from XR.
CTC:EMS/CRAFT IP once given is not getting deleted from CTC
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: CTC : EMS/CRAFT IP once given cannot be deleted from CTC it can only be modified to some other ip address. The only way to remove it is from CLI
Conditions: EMS and Craft IPs are still showing while they should be deleted.
Workaround: NA
Further Problem Description: Reproducibility: 100% Expected Resolution: to be fixed in 6.0 release
NCS4K : Bridge and Roll not working on Protected Circuits
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: Once Roll is created for 1+R circuit, circuit should get converted to 1+1, however circuit is getting converted to 1+1+R.
Conditions: Create 1+R circuit Create Roll using that circuit. through menu option Tools -> Circuits -> Roll Circuit Circuit gets converted to 1+1+R circuit instead of 1+1 circuit
Workaround: N/A
Further Problem Description: Reproducibility: 100%
Expect TTI is not clear properly in Section trace-->OC in CTC.
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: Unable to clear Expected TTI value set under Section trace -> OC
Conditions: This issue may arise when End client is Sonet and TTI is configured .and User is trying to set and clear the expected TTI values .In this case the expected TTI may not get clear.
Workaround: N/A
Further Problem Description: Reproducibility: 100%
NCS4k:WaitTo Restore timer is displayed in Milliseconds in Netconf reply
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: The protection profile timer - wait to restore is displayed in Milliseconds in the Netconf walkdata command .
Conditions: While creating the Protection profile the wait to restore timer is configured in seconds with the range <0-720>. However on commit of the configuration , the wait to restore timer value is converted to Milliseconds and is displayed in Milliseconds in the Netconf o/p.
[CTC] Alarms periodically clear from Network/Shelf/Card graphical view
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: Leaving CTC idle, after few time Network view, Shelkf view and Card view get redraw clearing all the alarm color on graphical view while alarm are actually present on the chassis and in tabular view
Conditions: This scenario may occur on leaving the CTC idle for sometime
Workaround: Click on Synchronize button in alarm pane
Further Problem Description: reproducibility: 100%
Symptom: CTC with multiple nodes discovered , the alarms not getting cleared for the discovered nodes other than CTC launched node even on Auto delete cleared alarms checkbox is enabled.
Conditions: The issue is seen under Alarms pane in network view when multiple nodes are discovered
Workaround: No workaround available
Further Problem Description: Reprooducibility: 100%
RPL inline cmd for nested policies shows wrong o/p
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: show rpl route-policy <> inline is not giving expanded o/p for route-policies referring nested wildcard policies. Conditions: using show rpl route-policy <> inlince command on policies referring nested-wildcard policies. Workaround:
This is a show command to get the expanded form of policies by replacing hierarchical policies with the defninitions. No workaround for nested wildcard policies.
SFE ASIC error injection command to be modified for FE3600
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: SFE ASIC error injection command to be modified for FE3600
Conditions:
Workaround:
Further Problem Description: SFE ASIC error injection command to be modified for FE3600 . Currently it is like below
sysadmin-vm:0_RP0# set controller asic ? Possible completions: fe3200
it should be fe3600.
sysadmin-vm:0_RP0# show version Sun Jan 31 12:15:52.155 UTC
Cisco IOS XR Admin Software, Version 6.0.1.14I Copyright (c) 2013-2016 by Cisco Systems, Inc.
Build Information: Built By : jwu Built On : Fri Jan 15 00:21:22 PST 2016 Build Host : iox-ucs-004 Workspace : /scratch/nightly/xr-dev_16.01.14C/ncs4k Version : 6.0.1.14I Location : /opt/cisco/calvados/packages/
CTC leaves telnet/SSH sessions open on NCS4K device
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: User cannot login to NCS4K device due to maximum Telnet/SSH session opened.
Conditions: Sometime CTC launched on NCS4K devices open several Telnet or SSH sessions reaching maximum allowed. In this case user cannot open further telnet/SSH sessions.
mpls_lsd traceback while linecard reload with SRTE tunnels
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: mpls_lsd traceback while linecard reload with SRTE tunnels
Conditions: When SR and TE feature is enabled and in a transient condition where the prefix does not have a backup path.
Workaround: none required as the situation corrects itself
Further Problem Description: This is a transient error condition due to new SR TE feature introduced in 6.0.0 and also applicable for 6.0.1 for all XR platforms which use SR and TE.
Conditions: This problem may occur if lasting bursts of OSPF LSAs of the same instance are received (the bursts are in a few ms range) AND timers lsa min-arrival 0 is configured under router ospf.
Workaround: As a best practice please avoid to configure a value of 0 for lsa min-arrival time. As save value is 50ms or higher.
Further Problem Description: If the problem is present other side effects like high CPU load, disabling of NSR as well as "Failed to fetch update for gateway cache while calling the RIB instance" messages from BGP may be observed.
RP1 card is showing UNKNOWN state in Show platform after RP0 Hard Reset
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: sh platform in XR node display UNKNOWN card type for standby RP
Conditions: When active RP is rebooted, with standby RP in shutdown state.
Workaround: No workaround. Need to reload the router to correct the sh platform output
Further Problem Description: No functional impact. This UNKNOWN issue doesn't occur when active RP is reloaded normally. It occur only when standby card is in shutdown state.
Conditions: When OSPF is configured with segment-routing and TI-LFA along with UCMP and "mpls traffic-engg multicast-intact" configuration.
If any of the above feature is not enabled, then this issue will not be seen.
Workaround: None - the error is harmless and no functional impact
Further Problem Description: Issue was introduced due to new SR feature change during 6.0.0 and the log is seen as OSPF tries to delete an UCMP path from multicast RIB which was not installed there in the first place. It is applicable for all XR platforms.
This is the normal SDK update procedure for xrv9k. It updates the SDK from REL0031 to latest REL0034.
Symptom: This is the normal SDK update procedure for xrv9k. It updates the SDK from REL0031 to latest REL0034. For details, please see the release note in REL0032/0033/0034
When an Object tracker is configured to track an IPSLA operation, it is seen that sometimes the IPSLA operation times out, causing the OT track to flap
Workaround: Increase the OT delay down timer to 180 seconds
SNMP queries to CISCO-RTTMON-MIB::RttMonJitterStats fail
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: IPSLA UDP jitter CISCO-RTTMON-MIB::RttMonJitterStats* table is not able to be queried via SNMP after 248.57 days of IPSLA instance operation. Conditions: With an IPSLA instance configured and correctly reporting, after 248.57 days in operation SNMP query fails against CISCO-RTTMON-MIB::RttMonJitterStats. SNMPWALK returns missing OID while show ipsla statistics still reports correct information. Workaround: Workaround is to restart both snmpd and ipsla_sa. Example to execute workaround follows:
X86: packet drops seen with IPSLA UDP Jitter probes
Status:
Fixed
Severity:
3 Moderate
Description: *
Symptom: With the UDP jitter operation, the Packet MIA count is seen to be increasing, indicating that the packets are missing in action.
Conditions: When the IPSLA UDP jitter operation is scheduled, the sub-agent miss out on sending some packets from the default count. This is indicated by the increase in the PacketMIA count of the 'show ipsla statistics' command. This behaviour is observed when the responder has the dynamic port configuration.
Workaround: Reduce packet count, or increase packet interval.
XR: rttMonStatsCollectTable returns empty if path-echo is scheduled
Status:
Fixed
Severity:
3 Moderate
Description: *
Symptom: rttMonStatsCollectTable returns empty.
Conditions: icmp path-echo probe is scheduled and happens to be the first (lowest) numbered on the box.
Workaround: Ensure icmp path-echo probe is NOT the first one configured or scheduled on the box, this will ensure other probes are not affected and rttMonStatsCollectTable values can be collected successfully.
Conditions: Without these fixes IPSLA/LMS integration is broken.
Workaround:
Further Problem Description: CSCui63738 XR: rttMonStatsCollectTable returns empty if path-echo is scheduled Sev3 CSCui66730 XR: mibd_infra crash upon removing probe via snmp Sev2 CSCui55032 rttMonCtrlAdminStatus returning 3 when it should return Sev3
XR: rttMonJitterStatsAvgJitter always 0 in rttMonJitterStatsTable
Status:
Fixed
Severity:
3 Moderate
Description: *
Symptom: When doing an SNMP query for rttMonJitterStatsTable, the returned values for rttMonJitterStatsAvgJitter, rttMonJitterStatsAvgJitterSD, and rttMonJitterStatsAvgJitterDS are always zero, even if the show command says otherwise.
Conditions: Always reproducible.
Workaround: Collect the info from the show command "show ipsla statistics"
"SequenceError" is returned due to lower timeout values in IPSLA in X86
Status:
Fixed
Severity:
3 Moderate
Description: *
Symptom:When the timeout of an IPSLA operation is configured below 1000, the operation fails with "Sequence Error" on a show ipsla stats opconfigno. command
Conditions:Configure a udp jitter type operation with timeout 1000 msec, packet count 1000 and packet interval 10 msec and then run a show ipsla stats command
Workaround:Control Packets not coming within the timeout interval to be dropped and not to be signalled as "Sequence Error"
High CPU utilization when IPSLA MPLSLM configured with 100 PE Routers
Status:
Fixed
Severity:
3 Moderate
Description:
Symptoms
When the MPLS LSP stress scenario from Description is configured, the sustained rate of LSP Ping/Trace packets sent will be much higher than expected (>100pps) under normal monitoring conditions, and this will cause the cpu utilization in the RP to be high
Conditions
This high CPU utilization is only observed when the MPLS LSP monitoring configuration is set such that a large number of LSP Ping/Trace request per second is generated.
Workaround
The configuration used for creating the conditions described in this bug is intended for stressing the application and it is very far from what normal monitoring scenarios are. The IPSLA MPLSLM application provides the tools for spreading the monitoring load over time, which leads to a much reduced sustained load.
unable to destroy rttMplsVpnMonCtrlStatus & CtrlAdminStatus via snmp
Status:
Fixed
Severity:
3 Moderate
Description: *
Symptom:
Unable to destroy the ipsla operation via SNMP
Conditions:
When Ipsla operation is scheduled on the UUT
Workaround:
Delete the ipsla operation via CLI " no ipsla"
Further Problem Description:
Setany on both the tables (rttMplsVpnMonCtrlStatus & CtrlAdminStatus ) with the value 6 (destroy) returns commit failed error. qvale:jobs$setany -v2c 12.24.48.130 public rttMonCtrlAdminStatus.2047 -i 6 Error code set in packet - COMMIT_FAILED_ERROR: 1. qvale:jobs$
No operation will start automatically after restarting the master-agent
Status:
Fixed
Severity:
3 Moderate
Description: *
Symptom: When the master-agent (ipsla_ma) restarts while the sub-agent (ipsla_sa) keeps running, the master-agent cleans up all of the operations but never scans the configuration again and all of the configured operations disappear.
Both show ipsla application and show ipsla statistics show nothing about the operations.
Conditions:
The customers see the problem when they enter process restart ipsla_ma or the master-agent crashes/restarts automatically due to any problems
The problem doesn't happen if there is no IPSLA operation configuration.
Workaround:
Do not enter process restart ipsla_ma. If the master-agent (ipsla_ma) was restarted due to any problems or the customers enter process restart ipsla_ma by accident, restarting the sub-agent (ipsla_sa) by process restart ipsla_sa clears up the problem.
Symptom: This is an Umbrella DDTS for IPSLA related fixes. Please check the individual DDTS list for details. CSCuo75699 [4.2.3] x86:IPSLA perm port cfg on responder leads to socket exhaustion CSCti70308 X86: packet drops seen with IPSLA UDP Jitter probes CSCuh29489 Packet Loss on PacketMIA with IPSLA CSCul33732 Packet MIA calculation is wrong CSCul64125 XR: IP-SLA interval timer event isn't triggered
Conditions: IPSLA with UDP Jitter
Workaround: None
Further Problem Description: Address several issues IPSLA issues
IPSLA responder accepts IPSLA control packets without authentication header regardless of IPSLA key-chain config.
Conditions:
This problem possibly occurs when user has the following configs on the router. This means IPSLA responder is running on the router and IPSLA authentication is enabled.
ipsla key-chainkeychain-name ipsla responder
This problem has been there since 3.3.0 (since IPSLA was released for the first time).
Workaround:
There is no workaround.
Further Problem Description:
Even if user configures the following ipsla key-chain config, IPSLA responder still accepts IPSLA control request packets without authentication header.
The expected behavior is IPSLA responder accepts IPSLA control request packets with authentication header but should reject IPSLA control request packets without authentication header when user configures the following config on responder side.
Unable to commit the ipsla cfg with start-time parameter
Status:
Fixed
Severity:
3 Moderate
Description: *
Symptom:
Unable to commit the ipsla cfg with start-time parameter
Conditions:
1) First configure "ipsla schedule operation start-time " and try to commit. This commit would fail obviously. 2) Now try to configure "ipsla schedule operation start-time after " and try to commit. This would also fail all the time
latest RTT is always 0 when operation with destination as Loopback
Status:
Fixed
Severity:
3 Moderate
Description: *
Symptom:When IPSLA UDP Jitter Operation is configured, the latest RTT is shown 0 which is not the proper value
Conditions:On the Customer Setup, a loopback address as destination address in the operation was causing this issue
Workaround:Latest RTT is averaged over number of packets configured in the UDP Jitter Operation, when the packet MIA occurs, the RTT Min value should be the value shown, otherwise it will show 0
Configuration is changed to "no shutdown" unexpectedly after reload.
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: it has seen abnormal behavior(be changed IF configuration from shutdown to no shut) after reload. We also reproduced same issue in their lab. Using versions are 4.2.1 and 4.3.4. This issue has appeared with both of versions.
Conditions: none
Workaround: WA steps. **no interface XX -> IF shutdown(*1)->LC OIR ->reconfiguration on I/F -> Reload
/// (*1)config "shutdown" and then commit. interface TenGigE0/x/x/x shutdown ///
Changes required in TTY as part of consistent multichannelSSH identifica
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: In Multichannel SSH, all multichannel SSH connections close when exit is pressed on any of the channel.
Conditions: As part of fix of another ddts, new identification mechanism is added in SSH to properly & reliably identify single channel & multichannel SSH, it requires some changes in devc-vty also for proper functioning.
Symptom: ISIS fails to accept configuration when the same ISIS process is removed and re-added quickly. The failure reason (from "show configuration failed" output) is the following:
!!% 'CfgMgr' detected the 'fatal' condition 'This configuration has not been verified and can not be accepted by the system.'
Conditions: The problem may happen when the same process is removed and re-added back quickly.
Workaround: Insert a short delay (30 seconds) between removing and re-adding the same ISIS process.
If the problem is hit, repeat the commit, the configuration will be accepted the next time.
sh mpls traffic-eng tunnel command displays incorrect info
Status:
Fixed
Severity:
3 Moderate
Description: *
Symptom:
Persistently 'down' MPLS TE midpoint LSP's. The effected LSP's are not present in RSVP database.
Conditions:
Timing condition exposed by non-XR headend (interop) during scaled/stress triggers (such as shutting midpoint egress interface, and/or tail router reload). As non-XR headend signals many new LSP's specifying mid point DOWN egress link, followed quickly by PATH Change messages, there is possibility some may not be cleaned up properly, leaving them is a 'stale' state.
Workaround:
No known workaround, other than restarting either te_control or rsvp process.
Further Problem Description:
Issue originally exposed with JunOS as head end. During trigger, JunOS would send PATH msg specifying down link which XR will PATH ERROR. But JunOS would also send second PATH msg to change something. If the link was restored between the 2 PATH msg's, the issue could occur.
problems with TI-LFA backup path for adj-SID of link that is not on SPT
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: The backup path for adjacency-SID of a link that is not on the shortest path to the node at the remote end of the link (e.g. has a high metric) is incorrect. - The imposed label on the backup path is ImpNull, while it should be the prefix-SID label of the node at the remote end of the link - The adjacency-SID backup path is also forwarding while the backup is not active, so in normal state the traffic to the adjacency-SID is load-balanced over primary and backup paths
Conditions: The adjacency-SID is of a link that is not on the shortest path to the node at the remote end of the link.
Symptom:With implementation prior to this fix, the thresholds defined for flooding are hard/fixed ones. Any point the bandwidth reserved crosses up/down a defined threshold - ISIS update is triggered. These leads to significant flooding within the ISIS Domain.
The ISIS flooding update happens at the wrong time and too excessively which causes a lot of unnecessary network activity and causes RSVP-TE signaling instability and churn.
The amount of flooding done by current cisco devices in network ~ 25-30 devices is greater than 600 Juniper devices in customer core network.
Conditions:Cisco device doing an role of an LSR or LER. Workaround:There are no workaround. More Info:This fix provides a relative threshold for flooding - which optimizes the amount of flooding within the ISIS domain.
The tag configured with a static route may no long be effective in a very specific scenario. THe static route would exist but as if the tag were not configured.
Conditions:
This can be seen on a router running IOS-XR in the specific following scenario: - two static routes exist for the same prefix towards two egress interfaces. - both interfaces are shut down and the prefix is removed as expected from RIB. - when the first interface is brought up the static is installed without the "tag". - when the second interface is brought up, the tag is correctly associated to the updated entry for the prefix in the RIB.
Symptom: Passive ntp associations are not restricted by default on the Cisco IOS-XR.
Conditions: Exposure is not configuration dependent.
Workaround: Direct control of passive associations is not available. But one can use the ntp authenticate configuration to prevent any unauthenticated sessions, and/or use ACLs to limit the exposure.
Further Problem Description: The IOS-XR by default accepts passive associations, this bug is to update the default to match Cisco IOS and to provide the associated command line configuration.
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:
OCI gets stuck after line loopback is applied and cleared
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: OCI alarm gets stuck on nni controller when line loopback is cleared
Conditions: Create a 1+1/1+0 nni tunnel and configure line loopback on nni controller. Now remove loopback from this controller, OCI gets stuck on this controller and not cleared.
Workaround: None
Further Problem Description: Expected Resolution:Please check with the support engineer for information on which release(s) this bug is expected to be fixed.
Inactive Feature or Service pack shows up in show install active summary
Status:
Open
Severity: *
3 Moderate
Description:
Symptom: Superseded FP/SP may show up in show install active.
Conditions: When not all pies of a given FP are installed on the device.
Workaround: None, cosmetic.
Further Problem Description: ?show install supersede? calculation is done only on FPs that are fully active (meaning all packages of the FP are active). The behavior has been the same for SMU's and SP's as well.
In this case since the FPs are partially active (reason: 9000v-nv optional package is not installed so the corresponding packages of FPs are also not active) Install displays both of them in 'show install active' as well as 'show install inactive'. And supercede calculation is not performed on them.
Enhancement of software scrubbing the pse memory for SBE interrupts-
Status:
Fixed
Severity:
3 Moderate
Description: *
Symptom: In certain conditions the PSE memory gets stuck with single bit errors (SBE) and a message is logged similar to: pse_pogo_driver[244]: %PLATFORM-CIH-5-ASIC_ERROR_SCRUB_THRESH : pse[1]: A sbe error has occurred causing data corrected. 0x12470009 Threshold has been exceeded
Conditions: When SBE interupts cross a threshold they start logging these messages. An SBE is totally benign since it will be corrected by the HW whenever the memory is ready. This error is single bit error and hardware corrects it itself without any user intervention required.
Workaround: SBEs will not cause any Service Impact. If the error message includes elements 0x12470007, 0x12470009 or 0x1247000b then reloading the LC will clear this issue.
Symptom: When a gRPC cli-config request fails to apply configuration, the failed command is not communicated to the user, only the error is communicated. For example, if the gRPC cli-config request included "router bgp 22", and this command failed, the output would be:
enter PID:22892:main.main emsCliConfig: Sending ReqId 22892 emsCliConfig: Received ReqId 22892, Status '{ "cisco-grpc:errors": { "error": [ { "error-type": "application", "error-tag": "operation-failed", "error-severity": "error", "error-message": "The instance name is used already: asn 0.1 inst-name default" }, { "error-type": "application", "error-tag": "backend-status-summary", "error-severity": "warning", "error-message": "QT/SysDB backend failed, non-QT backend passed [read rest of response for details]" } ] } } '
Operation: cli-config Number of iterations: 1 Total bytes transferred: 14 Number of bytes per second: 11 Round trip throughputs Mbps: 0.000095 Ave elapsed time in seconds: 1.177900 Min elapsed time in seconds: 1.177900 Max elapsed time in seconds: 1.177900
--------------- End gRPC Summary ---------------------
exit PID:22892:main.main (2.178239204s)
In the above, the error "The instance name is used already: asn 0.1 inst-name default" is reported but the failed command "router bgp 22" is not reported
Conditions: This bug occurs when a CLI command in the cli-config gRPC request fails
Symptom: stp_io process is blocked and no MSTP packet is sent for approximately 10 seconds after Backup-DSC failover in nV Edge system.
Conditions: This issue can be seen when the following Backup-DSC failover happens.
1) admin reload location 2) Backup-DSC reset or OIR
Workaround: No workaround in case of Backup-DSC reload due to hardware failure Use "hw-module location reload" command instead when you reload Backup-DSC by hand.
Further Problem Description: Please check if stp_io process is blocked on Primary-DSC by the following commands.
- show processes blocked - show processes stp_io - follow job iteration 1 stackonly
Symptom: On an ASR 9000 ethernet line cards, subinterface statistics count packets dropped by queuing as output packets.
Conditions: Output drops may occur due to port oversubscription or MQC shaper applied to the subinterface or port. The count is correctly reflected on the main interface but not the subinterface.
Workaround: Apply a queuing policy to the subinterface and monitor the queue transmit stats.
Further Problem Description: This patch changes the behavior of subinterface stats when an output queuing policy is applied to the subinterface. A queuing policy is a qos policy with any queuing actions, like shaper or bandwidth that cause queues to be explicitly allocated for the subinterface. In this case the subinterface output stats will display the sum of the queue transmit stats in order to provide a more accurate view of the output traffic.
There is no change for cases where queuing policy is applied to the port or the non-qos-policy cases. In these cases, the subinterfaces share queues, so the previous behavior will still apply.
Symptom: This is an umbrella SMU for the following bug fixes:
CSCuu37058 Sev3 [ppp-ma ] New PPPoE sessions not coming up CSCus17352 Sev3 [ppp-ma ] Few PPPoE sessions are disconnected with PPP LCP FSM triggered down
These fixes are highly recommended for BNG deployments on IOS XR release 5.2.4.
BVI Up state should take pseudowires into consideration on MCLAG standby
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: BVI IP protocol state is down on standby MLACP host, eventhough one of the PW is up. According to architecture, BVI state should be up if one of the AC or PW is up.
Conditions: MLACP with BVI and VPLS. Issue is only on standby MLACP host
Workaround: Add a dummy L2 sub-interface to each bridge-domain with BVI.
Symptom: Incorrect LPTS entry for configured BGP peer refuses attempts for TCP connection initiated from remote BGP peer.
Conditions: eBGP peer is configured and following conditions are met: - eBGP neighbor is configured without specifying update-source - directly connected interface towards the peer is down - there is an another entry in routing table over which BGP peer should be reachable
then LPTS entry for this BGP peer is created with local IP address of actual outgoing interface. When the direct link comes up, LPTS entry is not updated and it still uses local IP address of the interface from the moment of BGP peer commit.
Workaround: Specify update source even for eBGP peer reachable over directly connected interface
SMU deactivation results in load path corruption of Trishul
Status:
Open
Severity:
3 Moderate
Description:
Symptom: In some rare scenario one may not be able to execute "install commit" post activation or deactivation of new SMUs due to corruption of packages on certain cards on a CRS system.
The issue is non-impacting & may be recovered from by following the steps mentioned in the workaround.
Conditions:
Workaround: 1) if the issue is hit then execute the following command from admin mode "install verify packages repair"
If the above step fails to resolve the issue, then reload the card on which the error is seen.
autoroute exclude prefix set change leads to large traffic outage
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: Appling a Route-policy with prefix-set under ospf mpls traffic-eng causes large traffic drop as all ospf routes are purged and need to be re-installed.
Conditions: 1. appling a Route-policy with prefix-set under ospf mpls traffic-eng 2. prefix-set is modified for existing Route-policy under ospf mpls traffic-eng
Workaround: Cost Out the router while making these changes to avoid the impact.
Further Problem Description: This is day 1 issue on how this feature works and is applicable for all XR platforms.
Need CLI change to include location option for install verify
Status:
Fixed
Severity:
3 Moderate
Description:
AT&T has requested this feature in form of a 5.3.3 production SMU due to the reasons specified in the symptoms section. In release 5.3.3, install verify can be executed only on a global basis for the entire router.
Symptom: - Current implementation of running install verify for all line cards is very time consuming (about 10 mins for Multi-chassis) - Running the install verify for multiple times (atleast a couple) to check for anomalies before and after ?install repair/boot format? is not practical for our operations as they would run out of scheduled maintenance window - Also running install verify for all line cards creates a huge install log (approx. 800KB as we saw in lab for a MC systems) and this eventually crates other issues like running over the recommended 16 Meg install file size...
Running install verify with option will help AT&T greatly to a avoid the above mentioned issues...
Conditions: Execution of "install verify packages" command has been recommended after every upgrade to releases 5.3.1 and 5.3.3, activation of router reload SMUs and any other situations where a router is reloaded due to Topaz bug CSCux00209.
Workaround: There are no workarounds apart from running install verifiy for the entire 8+1 MC system.
Provide local-label info in ECD notif for IP/MPLS REACHABILITY
Status:
Fixed
Severity:
3 Moderate
Description:
Acc to RFC5884, BFD needs to use MPLS path on return path if an LSP is present. This requires BFD to know if MPLS reachability is there for return path, as well as the local-label associated with prefix.
Symptom:Acc to RFC5884, BFD needs to use MPLS path on return path if an LSP is present. This requires BFD to know if MPLS reachability is there for return path, as well as the local-label associated with prefix.
Conditions:Configure BFD over MPLS LSP Workaround:no workaround
31705 SSL Anonymous Cipher Suites Supported & ciscoSSL support add
Status: *
Other
Severity:
3 Moderate
Description:
Symptom: This is a modification on the product to adopt new secure code best practices to enhance the security posture and resiliency of this product
Conditions: Device configured with default configuration.
Workaround: Not applicable or available.
Further Problem Description: This issue was found during an internal security audit of the product. This issue should not be made public as it is an internal hardening issue to be considered for integration.
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:
yang/netconf attach pbr policy to intf not working
Status:
Other
Severity:
3 Moderate
Description:
Symptom: Hi, Rajesh: I have tried to attach a PBR policy to the interface by specifying two fields values: interface name and pbr-cfg:service-policy-in?the policy name as ?policy_vrf-blue?
It failed due to the following error below. Could you please check if I missed anything or the image has issue (Sangeetha and I couldn't find anything else to config here)
Symptom: MSDP process crash on active RSP due to race condition, when MSDP process was restarted due to SMU installation.
Conditions: IOX upgrade
Workaround: Remove the peer shutdown configuration / remove the down peer
Further Problem Description: This issue is not related to CSCuw12567, This issue can happen when a MSDP peer is shut down and the MSDP process is restarted, it goes into continuous crash. This issue is applicable to all platform and release 5.2.2 or later. Removing the shutdown peer will not cause the problem
NCS1K: Hiber alarms causes errored block in the downstream
Status:
Open
Severity:
3 Moderate
Description: *
Symptoms : After injecting HIBER in Port 3 using testset --> Port 3 receives HIBER, Port 10 receives LF as expected. But the testset receives errored block.
Condition : Only during injection of HiBER this problem is seen
NCS1K : Reprovisioning skipped during Reconfigure of same hwmodule
Status:
Open
Severity:
3 Moderate
Description:
Symptom: slices won't get reprogrammed if the hw-module configuration is removed and re-applied in single commit.
Conditions:
Workaround: Do not remove and re-apply the same hw-module configuration in single commit. Commit the "no hw-module" command first and then re-apply the configuration.
NCS4K:SF/SD on delete/recreate xconnect or shut/unshut ODU with PRBS
Status:
Open
Severity:
3 Moderate
Description:
On deletion /recreation of xconnect with PRBS config BIP errors in the system increases which leads to SF/SD BER.
Symptom: SF/SD alarm raised on delete/recreate xconnect with PRBS config
Conditions: One section of a network is in maintenance state and PRBS is configured. The PRBS configured controllers are deleted and recreated . SF/SD alarm is raised.
Breakout - PTIM alarm not reported in GFP-F and GFP-F-Ext mismatch
Status:
Open
Severity:
3 Moderate
Description:
Symptom: PTIM alarm will not report in case end client's have Different mapping.
Conditions: In case the two end client have different mapping configured like one client is having sonet AMP and other having BMP or one client having Ethernet GFPF and other having GFPF-Ext .In this case this issue will arise.
Wrong Local-Remote failure value of controller in correct Current state.
Status: *
Other
Severity: *
3 Moderate
Description:
Symptom: Local Failure and Remote failure values are not coming correct on edit circuit pane.
Conditions: On edit circuit pane run the APS command to make the Working path as Signal fail, after that Local failure and remote failure values are not coming correct in edit circuit pane.
Workaround: none
Further Problem Description: Reproducibility : 100% Expected Fix : Next release.
Improve usability of "show controllers ..." after the task group change
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: Phy data of "show controllers ..." output does not contain Tx Bias/Tx Power/Rx power
Conditions:
Workaround: "show controllers ... phy" (requires cisco-support task group in 5.3.2 onwards)
Further Problem Description: Phy: Media type: R fiber over 850nm optics Optics: Vendor: CISCO-AVAGO Part number: SFBR-7700SDZ-CS2 Serial number: AGD141134YK Wavelength: 0 nm Digital Optical Monitoring: Transceiver Temp: 40.000 C Transceiver Voltage: 3.268 V
DOM alarms: No alarms
Alarm Alarm Warning Warning Alarm Thresholds High High Low Low ------- ------- ------- ------- Transceiver Temp (C): 75.000 70.000 0.000 -5.000 Transceiver Voltage (V): 3.630 3.465 3.135 2.970 Laser Bias (mA): 10.500 10.500 2.500 2.500 Transmit Power (mW): 1.479 0.741 0.186 0.074 Receive Power (mW): 1.584 0.794 0.102 0.040
Install update with unknow TP smu - operation not aborting
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: Install operation not failing and base pkg of the SMU is activating
Conditions: Install update with Unknow TP smu operation should abort. - currently if the version release or ddts fields are changed with out changing name of the TP SMU, then we are seeing this issue.
Workaround: Use proper TP smu name as per repository content.
Fretta: Bundle vlan range is not progrmmed add / remove member to bundle
Status:
Open
Severity:
3 Moderate
Description:
Symptom: Bundle Subinterface with VLAN-RANGE configuration won't work if there are more than one member on the same NPU or if there is an ADD delete of bundle members
Conditions: Bundle Subinterface with VLAN-RANGE configuration won't work if there are more than one member on the same NPU or if there is an ADD delete of bundle members
Workaround: ensure bundle does not have more than one member on the same NPU and before add delete of member remove the vlan range configuration
NCS1K:SNMP- optics_ea crash observed on continuous polling
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: NCS1K:SNMP- mxp_driver & optics_ea crash observed on continuous polling
Conditions: 1. Did continuously polling of following MIB one by one with many iterations 2. On 74th iteration (~3hrs of polling) observed continuous crash msgs on console. 3. SNMP response timed out
Last Renewal attempt showing "None" status after successful renewal
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: Renewal is done successfully in production mode as it has been seen in the license traces, but it's always showing "None" in last renewal attempt in show license status. Although, after the renewal is done we should expect to see the new timer for last renewal attempt.
Conditions: After renewal has happened, we can check the status of last renewal attempt from sh license status:
RP/0/RP0/CPU0:ios#sh license status Thu Jul 9 18:06:43.001 UTC
Smart Licensing is ENABLED Initial Registration: SUCCEEDED on Thu Jul 09 2015 18:06:09 UTC Last Renewal Attempt: None Registration Expires: Fri Jul 08 2016 18:03:08 UTC
License Authorization: Status: AUTHORIZED on Thu Jul 09 2015 18:06:28 UTC Last Communication Attempt: SUCCEEDED on Thu Jul 09 2015 18:06:28 UTC Next Communication Attempt: Sat Aug 08 2015 18:06:28 UTC Communication Deadline: Wed Oct 07 2015 18:03:28 UTC RP/0/RP0/CPU0:ios#
A9K Flowspec first-fragment causes Flowspec to ignore config changes
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: Configurations: class-map type traffic match-all CORE-FRAG-CM match fragment-type first-fragment end-class-map ! ! policy-map type pbr CORE-FRAG-PM class type traffic CORE-FRAG-CM set dscp af21 ! class type traffic class-default ! end-policy-map ! flowspec address-family ipv4 local-install interface-all service-policy type pbr CORE-FRAG-PM
Error message: RP/0/RSP0/CPU0:Jan 26 18:20:23.756 : flowspec_mgr[1096]: %FLOWSPEC-3-MGR_CLASS_CREATE : Failed to create inline-class for flow Source:10.0.0.0/8,Proto:=17|=70,Frag:=LF with actions DSCP-1157653441875542046 in table default:IPv4, overall:0x4081b400:'PBR' detected the 'warning' condition 'PBR PD': Not supported, 0x493bee30:'PBR' detected the 'warning' condition 'PBR PD': Not supported.
Revert back to original configuration of, ! class-map type traffic match-all CORE-FRAG-CM match fragment-type is-fragment end-class-map ! policy-map type pbr CORE-FRAG-PM class type traffic CORE-FRAG-CM set dscp af23 ! class type traffic class-default ! end-policy-map
Traffic does match the new policy but the dscp value remains AF21 (last-fragment setting)
Conditions:
Workaround: Restart flowspec_mgr process on the FS client.
Issue: Incorrect Interface speed reported for Optics Interface
Status:
Fixed
Severity:
3 Moderate
Description:
Symptom: Incorrect speed is getting displayed in trace file for HyPhy cards for optics interface while for other cards they are displaying correct values
Conditions: Driver is sending some false data to ICPE MA DLL that is furthur getting stored in IM.
vlan cfg change mclag results in L2-L2VPN_ICCP_SM-3-CONFIG_LOCAL_ERROR
Status:
Open
Severity:
4 Minor
Description:
Symptom: changing the vlan configuration for mclag may results in L2-L2VPN_ICCP_SM-3-CONFIG_LOCAL_ERROR and blocks all vlans that are normally active
Conditions: making a vlan change on one POA and not yet on the other
Workaround: configure the vlan change on the second POA to resolve the config conflict
Further Problem Description: the ICCP detects a config inconsistency when say a new vlan is added, this results in a block for all vlans. this ddts to enhance the implementation to say allow for a grace timer or not block all vlans for a particular period of time.
Symptom: After Reload RP , RSVP graceful-restart hello neighbor up timer wrong .
Conditions: Hardware: CRS-X Version:5.3.3 After reload active RP , do show command "show rsvp graceful-restart neighbors detail" , and check neighbor up timer.
Workaround: Clearup RSVP GR hello neighbor . Up neighbor timer get back.
BGP neighbor accepted/PfxRcd couters incorrect after soft reset in
Status:
Fixed
Severity:
4 Minor
Description:
Symptom: PfxRcd counter shows a wrong value of accepted prefixes from a neighbor.
Conditions: Updates coming from the neighbor during 'clear bgp ipv4 unicast * soft in' execution. Soft-reconfiguration inbound is configured and the soft reset is performed without using the route refresh capability.
Workaround: Soft reset the affected neighbor again, when there's no updates coming.
bgp: %ROUTING-BGP-4-DESTROY_CHUNK ios-msg seen when clearing bitfield
Status:
Other
Severity:
4 Minor
Description: *
Symptom:
When a update-group is created or deleted an error message is seen which indicates problem with cleaning up memory.
RP/0/RP0/CPU0:Jul 29 18:26:24.419 : bgp[1045]: %ROUTING-BGP-4-DESTROY_CHUNK : [10] : Chunk pool "AFI:0 vrf:default bitfield-chunk(1)" is no longer in use but cannot be destroyed
Conditions:
For each net in BGP database, BGP maintains a bitfield indicating advertisement/withdraw state for the net for each update-group. The size of this bitfield is dependent on number of update-groups. When number of update-group crosses a certain threshold the BGP bitfield size is increased to accommodate any new update-groups. Similarly when the number decreases BGP bitfield size is reduced so that extra memory can be returned to the system. BGP allocates this new memory from a new memory pool. Memory associated with the old bitfield structure is freed up after the resize operation is complete. This bug prevents BGP from freeing the old memory pool and results in memory leak. This issue is seen very rarely.
Symptom: While creating circuit through fast circuit creation wizard the screens hangs at retrieving data when user selects source and destination node.
Conditions: In fast circuit creation wizard , select source and destination node for circuit creation.
Workaround: None.
Further Problem Description: Reproducibility: 100% Expected Fix: Next release.
Symptom: OSPF generates prefix-sid advertisements that are outside the SRGB range size configured on the router.
There is no functional impact normally since the receiving routers would not use this value since they would not find a label.
Conditions: When prefix-sid index is configured that is greater than the SRGB block size or when the SRGB block size is changed at a subsequent time such that a configured prefix-sid index value becomes greater than the new SRGB block size.
Workaround: Fix the configuration inconsistency - the prefix-sid index must be always within the SRGB value
Further Problem Description: This is just a missing verification for boundary conditions and mainly a misconfiguration. This issue has been there since SR was introduced in 5.2.2 release for OSPF and applicable for all XR platforms.
There is no functional issue and the fix is to actually flag the configuration inconsistency via a syslog and not to advertise inconsistent values in OSPF LSAs.
show bgp ipv6 should print neighbor and AS on single line (usability)
Status:
Open
Severity:
4 Minor
Description: *
Symptom: Not a bug, usability requirement to have the ipv6 neighbor on the same line as the other info in the show bgp commands.
Conditions: ipv6 neighbors
Workaround: live with it :)
Further Problem Description: Proposed solution: Add the keyword "wide" to the show command to print each entry on a single line.
Other suggestions: Append a backslash to incomplete lines to make parsing easier. Use the terminal width as set by the user to determine when to print the full line.
However, important is not to change any existing behavior unless the user specifies it. Thus the "wide" keyword.
After change taskgroup user still in pervious group
Status:
Open
Severity:
5 Cosmetic
Description:
Symptom: This is cosmetic issue, after change taskgroup for each individual user, user still shows under pervious taskgroup , but the new authorization for that user can take affect normally.
RP/0/RP0/CPU0:AP5-PT-PE22#show user all Username: crhe Groups: VZW-ACCESS-UGRP ------------->Exception: After remove authorization group ?VZW-ACCESS-UGRP? from ACS server. Inherit default read-only group normally but cosmetic issue here. Authenticated using method radius User crhe has the following Task ID(s):
snmpset for rttMonCtrlAdminStatus with value 5 is failed
Status:
Fixed
Severity:
6 Enhancement
Description: *
Symptom:
When we do set rttMonCtrlAdminStatus to 5 12000 series router with IOS XR XR does not accept this structure and return "commit failed"
Conditions: Configuring IP SLA over snmp on 12000 series with IOS XR 3.5.2 release.
Workaround: Use "CreateAndGo" with integer 4 which is accepted by 12000 series router. and the provide all parameters separately, i.e by different set statements.
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:
IPSLA recurring schedule:Can not configure past time to start-time 38MH
Status:
Fixed
Severity:
6 Enhancement
Description: *
Symptom: An operation scheduled with time in the past with the recurring option results in the configuration becoming ignored instead of starting the probe the next day at the configured time.
Conditions: Configuring the schedule command for an operation to be of type recurring but with a time in the past.
show ipsla responder statistics reporting wrong number of probes
Status:
Fixed
Severity:
6 Enhancement
Description: *
Symptom: "Show ipsla responder statistics" conflates the IP SLA control packet count with the number of probes received, resulting in an erroneous value:
RP/0/5/CPU0:GSR#show ipsla responder statistics ports Tue Jun 8 03:50:47.120 UTC
Port 5001 Local Address NumberOfProbes 192 RP/0/5/CPU0:GSR#debug ipsla responder probe Tue Jun 8 03:50:59.587 UTC RP/0/5/CPU0:GSR# RP/0/5/CPU0:GSR#RP/0/5/CPU0:Jun 8 03:51:23.737 : ipsla_responder[1190]: udpEcho probe: Receive from ip=, port=5001, delta=0ms
RP/0/5/CPU0:GSR#show ipsla responder statistics ports Tue Jun 8 03:51:26.361 UTC
Port 5001 Local Address NumberOfProbes 194
Conditions: This is an intrinsic problem to the show command.
NCS1k: CDSP upgrade doesnt show the correct upgrade progress
Status:
Open
Severity: *
6 Enhancement
Description:
Symptom: when we do upgrade of Coherent DSP, CFP2, BIos FPDs the progress won't show incremental progress. The percentage of completion will jump from 10% to 100%.
Conditions: 'upgrade hw-module' of CDSP, CFP2 and BIOS
Workaround: no workaround , please wait till the state change from 10% to CURRENT/Reload Required. state.
Install prompts for input with prompt-level none specified
Status:
Open
Severity:
6 Enhancement
Description: *
Symptom: Installmgr prompts for parallel install method with prompt-level none specified. To improve automation around install operations it is necessary that install operations can be able to be performed without prompting the customer for input using "prompt-level none" keywords.
The prompt-level none is not honored with the affected packages using mixed install methods, 'incremental' and 'parallel'. The install should proceed with parallel without prompting the customer to proceed.
install active pies aborted due to Configuration Namespace is locked
Status:
Open
Severity:
6 Enhancement
Description: *
Symptom: Install operation was aborted when loaded the config file during the SMU install. Install should hold the config lock until all pkgs are activated in a multi-seq operation. If it had done that, config session could not have started.
Conditions: The issue can be repro'ed by making a config change during a multi-seq install operation.
Workaround: avoid to do config change before the install operation ended for now.
show tech support for debugging DPA traces , required for Scapa.
Status:
Open
Severity:
6 Enhancement
Description:
Symptom: Following ltrace command are used to capture all DPA activity of Arwen.
dpa_show_ltrace -w or show dpa trace location 0/lc0
But these gives a huge o/p so it would be easy if we make it available in a tech support format which will be easy to use & share with customer. In future also if we add any other command for DPA debugging that also can be included in this tech support format.
Conditions: show tech support for all DPA activity needed on Scapa.
Workaround:
Further Problem Description: Following ltrace command are used to capture all DPA activity of Arwen.
dpa_show_ltrace -w or show dpa trace location 0/lc0
But these gives a huge o/p so it would be easy if we make it available in a tech support format which will be easy to use & share with customer. In future also if we add any other command for DPA debugging that also can be included in this tech support format.
Symptom: If icmp path-echo probe is configured + scheduled and we check the output of : "sh ipsla statistics aggregated", ALL counts are zero. Additionally, the output of "rttMonStatsCollectTable" when polled is empty for this probe type too.
Conditions: If the probe status is Timeout or some other potential error-code apart from OK
IPSLA: Support of low-memory check during run time
Status:
Fixed
Severity:
6 Enhancement
Description: *
Symptom: With the current implementation, we have lower water mark check only implemented in Master-Agent covering for cases like,
1. Check while configuring an operation. 2. Check while configuring schedule of an operation. Maps with 'start-time now'
However, the other variant of scheduling an operation which happens based on the run time scenarios (based on timer events when some future start time is configured) these are not supported in the current ipsla.
This DDTS is enhancement request for supporting the above run time scenario.
没有评论:
发表评论