| |
Bug Id: | CSCtr26695 |
Title: | ASR9k:Line Card Reloads automatically |
|
Description: | Summary
Cisco 9000 Series Aggregation Services Routers (ASR) running Cisco IOS XR Software version 4.1.0 contain a vulnerability that may cause a network processor in a line card to lock up while processing an IP version 4 (IPv4) packet. As a consequence of the network processor lockup, the line card that is processing the offending packet will automatically reload.
Cisco has released a free software maintenance upgrade (SMU) to address this vulnerability.
There are no workarounds for this vulnerability.
This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20110720-asr9k.shtml
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 4.1.0.BASE |
|
Known Fixed Releases: | 4.0.11.1i.BASE, 4.1.1.30i.BASE, 4.1.2.4i.BASE, 4.2.0.14i.BASE |
|
|
| |
| |
Bug Id: | CSCtr70936 |
Title: | BFD label session flap when receive large mount of BFD label packets |
|
Description: | Symptoms:
BFD label session may flab upon receiving large amount of BFD labels at high rate
Conditions:
this happens only if the interface is mpls enabled
Workaround:
if possible disable mpls on the interface
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 3.3/3.1:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:A/AC:L/Au:N/C:N/I:N/A:P/E:F/RL:U/RC:C
No CVE ID has been assigned to 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
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 4.2.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuj81580 |
Title: | ASR9K SIP-700 Malformed packet causes Egress CPP crash and LC restart |
|
Description: | Symptom:Cisco SIP-700 line card crashes on a device configured with MPLS IP.
Conditions:Device configured with mpls ip
ASR9K SIP-700 line cards
Workaround:None.
More Info:A crafted MPLS IP packet may cause the ASR9K SIP-700 line card to crash.
This can be triggered with a crafted MPLS IP packet when the packet requires MPLS fragmentation.
NOTE: It is difficult to inject this crafted packet into the network outside the label switch domain, since routers would/should drop the packet with basic IP Sanity checks that are done with IP CEF code.
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
5.4/4.5:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:H/Au:N/C:N/I:N/A:C/E:F/RL:OF/RC:C
CVE ID CVE-2013-6981 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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 4.3.0.LC, 4.4.0.BASE |
|
Known Fixed Releases: | 4.3.2.SP2, 4.3.2.SP3, 4.3.2.SP5, 4.3.2.SP6, 4.3.2.SP7, 4.3.2.SP8, 4.3.4.9i.BASE, 5.1.1.14i.BASE, 5.1.11.8i.BASE, 5.1.2.5i.BASE |
|
|
| |
| |
Bug Id: | CSCud39254 |
Title: | NP search memory management failure |
|
Description: | Symptom:
The prm_server_ty process is restarted due to a segmentation fault:
Thread:22 received signal:11 - SIGSEGV. Segmentation fault. Sender:kernel pid:1
Signal specific information: Signal code 1 - SEGV_MAPERR. Address not mapped. Accessed BadAddr
0x5b4c7c61 at PC 0x4d77df08.
The prm_server_ty process manages and controls the network processor.
Conditions:
This is a rare occurrence. For this failure to occur, there must first be at least 256 routes
that have the same 24 most significant bits. Then, one of those routes must be added and
deleted at least 4k times.
The problem may occur with any of the routing protocols and with any type of Typhoon based
linecard.
Workaround:
The frequency of this problem can be reduced by minimizing the number of routing topology
changes. The process will be automatically restarted after a failure occurs. If the process is restarted successfully, there will be no functional impact. However, in some cases the process restart will fail due to a secondary problem (CSCuc48596) in which case the linecard will be reloaded.
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 5.4/4.2:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:H/Au:N/C:N/I:N/A:C/E:POC/RL:OF/RC:C
CVE ID CVE-2012-5999 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
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 4.2.0.BASE, 4.2.1.BASE, 4.2.2.BASE, 4.2.3.BASE |
|
Known Fixed Releases: | 4.3.0.39i.BASE |
|
|
| |
| |
Bug Id: | CSCua63591 |
Title: | Routing protocols affected by SPP buffer depletion |
|
Description: | Cisco IOS XR Software contains a vulnerability when handling crafted packets
that may result in a denial of service condition. The vulnerability
only exists on Cisco 9000 Series Aggregation Services Routers (ASR) Route
Switch Processor (RSP-4G and RSP-8G), Route Switch Processor 440
(RSP440), and Cisco Carrier Routing System (CRS) Performance Route Processor
(PRP). The vulnerability is a result of improper handling of crafted
packets and could cause the route processor, which processes the packets, to be
unable to transmit packets to the fabric.
Cisco has released free software updates that address this vulnerability. This
advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-
20120530-iosxr
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 7.8/6.4:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?
dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:OF/RC:C
CVE ID 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
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 3.7.2.BASE, 4.0.0.BASE, 4.0.1.BASE, 4.0.11.BASE, 4.0.3.BASE, 4.1.0.BASE, 4.1.1.BASE, 4.1.2.BASE |
|
Known Fixed Releases: | 4.2.3.99i.BASE, 4.3.2.99i.BASE |
|
|
| |
| |
Bug Id: | CSCuj11397 |
Title: | 511-SIT: self-originated control packets TOS/DSCP not copy to MPLS EXP |
|
Description: | Symptom:
DSCP of self-originated packets are not copied to MPLS EXP.
Conditions:
Seen on ASR9K with Typhoon LC. This is seen in Loop Free Alternative backup path scenarios.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 4.3.4.BASE, 5.1.1.BASE |
|
Known Fixed Releases: | 5.1.1.12i.BASE, 5.1.11.4i.BASE, 5.1.2.2i.BASE, 5.2.0.7i.BASE |
|
|
| |
| |
Bug Id: | CSCty94537 |
Title: | Cisco IOS XR Software Route Processor Denial of Service Vulnerability |
|
Description: | Summary
Cisco IOS XR Software contains a vulnerability when handling crafted packets that may result in a denial of service condition. The vulnerability
only exists on Cisco 9000 Series Aggregation Services Routers (ASR) Route Switch Processor (RSP440) and Cisco Carrier Routing System (CRS)
Performance Route Processor (PRP). The vulnerability is a result of improper handling of crafted packets and could cause the route processor,
which processes the packets, to be unable to transmit packets to the fabric.
Cisco has released free software updates that address this vulnerability. This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120530-iosxr
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 7.8/6.4:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:OF/RC:C
CVE ID CVE-2012-2488 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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 4.2.0.BASE |
|
Known Fixed Releases: | 4.2.1.26i.BASE, 4.2.2.2i.BASE, 4.2.3.9i.BASE, 4.3.0.8i.BASE |
|
|
| |
| |
Bug Id: | CSCuu93156 |
Title: | ipv6 static routes over tunnel-te interfaces not installed |
|
Description: | Symptom:
ASR9k running 5.3.0 code will experience some Ipv6 over Ipv4 packet drop
Conditions:
IPv6 static routes over Ipv4 TE tunnel forwarding chain corruption
Workaround:
no work around
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 5.1.0.BASE |
|
Known Fixed Releases: | 5.3.2.15i.BASE |
|
|
| |
| |
Bug Id: | CSCus85007 |
Title: | ospfv3 neighbor never comes up after FO |
|
Description: | Symptom:
ospfv3 neighbor never comes up after FO
Conditions:
ospfv3 is configured with IPsec authentication
Workaround:
Proactive: disable authentication
Reactive: restart ipsec process
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 4.1.1.BASE, 4.2.1.BASE, 4.2.1.K9SEC, 4.3.0.BASE, 5.3.0.BASE |
|
Known Fixed Releases: | 5.2.5.14i.BASE, 5.3.1.22i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCug19184 |
Title: | ARP entry for 255.255.255.255 should not be allow in ARP table |
|
Description: | Symptoms:
On and ASR9000 if a gratuitous ARP for Sender Protocol Address 255.255.255.255
is received an ARP entry is added for 255.255.255.255. When this happens the
cef entry for 255.255.255.255/32 is removed from the linecard and broadcast
packets like DHCP discover packets received on the linecard get dropped or
routed via default route.
Conditions:
This is seen in all versions.
Workaround:
None
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 3.3/2.7:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:A/AC:L/Au:N/C:N/I:N/A:P/E:F/RL:OF/RC:C
No CVE ID has been assigned to 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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 4.3.0.BASE |
|
Known Fixed Releases: | 4.3.1.30i.FWDG, 4.3.2.14i.FWDG, 5.0.1.8i.FWDG, 5.1.0.8i.FWDG |
|
|
| |
| |
Bug Id: | CSCum14266 |
Title: | IPv4/IPv6 traffic stops when ASR9k processes malformed IPV6 redirects |
|
Description: |
Symptom:
A vulnerability in ICMPv6 processing of Cisco IOS XR could allow an unauthenticated, adjacent attacker to affect IPv4 and IPv6 traffic passing through
an affected device.
The vulnerability is due to a way ICMPv6 Redirect packets are throttled by an affected device. An attacker could exploit this vulnerability by sending
crafted ICMPv6 Redirect packets to an affected device. An exploit could allow the attacker to cause all or most of the IPv4 and IPv6 traffic to fail while
being processed on an affected device.
Conditions:
Device configured to process IPv6 traffic.
Workaround:
While there is no workaround on an affected device itself, the customers are urged to implement any of the First Hop Security measures on adjacent
L2 devices: http://www.cisco.com/c/en/us/td/docs/ios/ipv6/configuration/guide/12_4t/ipv6_12_4t_book/ip6-first_hop_security.html
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are
6.1/5:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:A/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:OF/RC:C
CVE ID CVE-2014-2144 has been assigned to document this issue.
Additional details about the vulnerability described here can be found at:
http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2014-2144
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 4.3.1.K9SEC |
|
Known Fixed Releases: | 5.1.2.20i.BASE, 5.1.3.1i.BASE, 5.2.0.17i.BASE |
|
|
| |
| |
Bug Id: | CSCuv10737 |
Title: | macsec_mka process crash when macsec removed with bulk commit |
|
Description: | Symptom:
macsec_mka process crash
Conditions:
[suchv@bgl-ads-1039 DT24Jun]$ /auto/erbu/herotools/repo/central/releases/ez-sbt/ez-sbt -f /auto/tftp-pw/team/suchv/macsec_logs/first.macsec_mka_265.20150629-140329.node0_0_CPU0.x86.txt -p macsec_mka
VERSION: 0.2.2
What is your specific card/RP type? [Press enter if you don't know]
What is your generic card/RP type (e.g. thor, typhoon, RSP440)? tomahawk
'card_details:'
{
'gen_card_type' => 'tomahawk',
'cpu' => 'x86e',
'platform' => 'viking',
'LC_or_RP' => 'LC',
'spec_card_type' => '',
'os' => 'nto'
}
RUNNING COMMAND:
./util/bin/./sbt -p macsec_mka -f /auto/tftp-pw/team/suchv/macsec_logs/first.macsec_mka_265.20150629-140329.node0_0_CPU0.x86.txt -A x86e
-------------------------------------------------------
Warning: Couldn't find sym file for library libc.dll
Warning: Couldn't find sym file for library libmq.dll
0x422f664: iox_assert
/nobackup/bbayanag/DT24Jun/inc/x86e-nto/global/iosxr-os/os/assert.h:48
0x422f0a0: macsec_ma_process_caps_tx_sa_complete
/nobackup/bbayanag/DT24Jun/crypto/macsec_mka/iox/mka/macsec_ma_imc.c:3359
0x422f543: macsec_ma_im_callback_async_complete
/nobackup/bbayanag/DT24Jun/crypto/macsec_mka/iox/mka/macsec_ma_imc.c:3410
0x97cc70a: imca_op_complete
/nobackup/bbayanag/DT24Jun/ifmgr/clientlib/src/imc_op.c:1958
0x97cc883: imca_op_process_reply_rd
/nobackup/bbayanag/DT24Jun/ifmgr/clientlib/src/imc_op.c:2082
0x97c9f7f: imc_notify_process_rd
/nobackup/bbayanag/DT24Jun/ifmgr/clientlib/src/imc_notify.c:5586
0x97ca0bf: imc_notify_process_rds
/nobackup/bbayanag/DT24Jun/ifmgr/clientlib/src/imc_notify.c:5716
0x82463eb: _event_pulse_handler
/nobackup/bbayanag/DT24Jun/infra/infra/event_manager/src/event_async.c:371
0x8244538: event_dispatch
/nobackup/bbayanag/DT24Jun/infra/infra/event_manager/src/event_manager.c:796
0x4200449: main
/nobackup/bbayanag/DT24Jun/crypto/macsec_mka/iox/mka/mka_main_iox.c:271
Done!
Workaround:
none
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCty37179 |
Title: | ACL: Incorrect handling of remark ACEs in the library |
|
Description: | <B>Symptom:</B>
ACEs that is removed from shared plane is not removed from TCAM, without any error, resulting
in the inconsistency between the shared plane and local plane ACL rules.
<B>Conditions:</B>
When a batch of ACEs of an applied ACL is deleted that contains both the remark ACEs as well as
non-remark ACEs and non-remark ACEs appear before remark ACEs, then those non-remark ACEs which
appear before remark ACEs are not getting deleted.
This issue is applicable to both IPv4 ACL (Release 4.1 onwards) and IPv6 ACL (Release 4.0 onwards)
<B>Workaround:</B>
This issue can be avoided by using any one of the below steps:
-Remark ACEs are not deleted
-Only remark ACEs or non-remark ACEs are deleted at once, but not together
-Remark aces are at the top of the ACL, before any non-remark aces
If this issue is already hit, then work around is to reapply the config or restart the
pfilter_ea process.
<B>Further Problem Description:</B>
When a batch of ACEs of an applied ACL is deleted that contains both the remark ACEs as well as
non-remark ACEs and non-remark ACEs appear before remark ACEs, then those non-remark ACEs which
appear before remark ACEs are not getting deleted.
For example:
<CmdBold>
ipv4 access-list acl1
10 permit tcp any any
20 deny icmp any any
30 remark test acl1
40 permit udp any any
</CmdBold>
Applied to an interface:
<CmdBold>
ipv4 access-group acl1 ingress
</CmdBold>
Now, if we remove the ACEs in following manner, then we will hit this issue.
<CmdBold>
ipv4 access-list acl1
no 20
no 30
no 40
</CmdBold>
In the above example config, all 3 ACEs gets removed from shared plane config, but only ACE #
20 does not get removed from the local plane config.
PSIRT Evaluation:
The Cisco PSIRT has evaluated this issue and does not meet the criteria for PSIRT ownership or involvement. This issue will be addressed via
normal resolution channels.
If you believe that there is new information that would cause a change in the severity of this issue, please contact psirt@cisco.com for another
evaluation.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 4.0.3.BASE, 4.1.1.BASE |
|
Known Fixed Releases: | 4.2.1.25i.FWDG, 4.2.3.7i.FWDG, 4.3.0.8i.FWDG |
|
|
| |
| |
Bug Id: | CSCty14830 |
Title: | VRRP MAC DB memory not being freed/released when sat ether is deleted |
|
Description: | Symptoms:
Memory leak in VRRP
Conditions:
Workaround:
Additional Information:
The memory leak has been fixed before the code was shipped
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 4.2.1.BASE |
|
Known Fixed Releases: | 4.2.1.21i.BASE, 4.2.3.3i.BASE, 4.3.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCsu25985 |
Title: | PRP: SPP Buffer corruption |
|
Description: | Symptoms:
PRP: SPP Buffer corruption
Conditions:
Default configuration.
If there is spp-context-depletion, SPP buffer corruption can occur.
Workaround:
None.
More Info:
PSIRT Evaluation:
The Cisco PSIRT has evaluated this issue and does not meet the criteria for PSIRT ownership or involvement. This issue will be addressed via normal
resolution channels.
If you believe that there is new information that would cause a change in the severity of this issue, please contact psirt@cisco.com for another evaluation.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 3.7.1.BASE |
|
Known Fixed Releases: | 3.7.2.10i.OSMBI, 3.9.0.13i.OSMBI, 3.9.0.4i.OSMBI, 4.1.0.2i.BASE |
|
|
| |
| |
Bug Id: | CSCuu41290 |
Title: | [ci-532] Complete traffic loss with PARSE_DROP_EGR_MPLS_LABEL_INVALID |
|
Description: | Symptom:
Traffic to IPv4 prefixes learnt over OSPFv2 or ISIS reachable via outgoing TE tunnel is dropped on Tomahawk Line card.
Conditions:
1.Software releases: 5.3.2
2. IPv4 prefixes learnt by OSPFv2 or ISIS protocol reachable via outgoing TE tunnel.
Workaround:
Use "clear ipv4 route unicast 1.2.3.4/32" where 1.2.3.4 is prefix and 32 will be corresponding length of prefix.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | 5.3.2.10i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCuf98728 |
Title: | ARP is not triggered for Nexthop which is on the BVI subnet |
|
Description: | <B>Symptom:</B>
Traffic forwarding for a Static route over Bridged Virtual Interface (BVI) fails.
The Nexthop associated with the Static route is not reachable.
ACL based forwarding does not work when the Next hop is on the BVI subnet.
<B>Conditions:</B>
The next hop for the Static route is on the BVI subnet.
The ASR9K is running IOS-XR releases 4.2.0, 4.2.1, 4.2.3, 4.3.0
If the router is ASR-9010, Bay 0 does not have any EPs.
If the ASR9K router is of other form factor, it has a Line card with PID of the form A9K-MOD*
(in any Slot on the chassis) and it's Bay 0 does not have an EP.
<B>Workaround:</B>
Trigger Gratuitous ARP from the Next-hop.
OR
Remove the Static route or ACL based forwarding command under consideration; Ping the next hop
and re-add the Static route.
For EP based systems (ASR-9001 or A9K-MOD* Line card), if possible, place an EP in Bay 0.
Further Problem Description:
PSIRT Evaluation:
The Cisco PSIRT has evaluated this issue and does not meet the criteria for PSIRT ownership or involvement. This issue will be addressed via
normal resolution channels.
If you believe that there is new information that would cause a change in the severity of this issue, please contact psirt@cisco.com for another
evaluation.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 02-JUL-2015 |
|
Known Affected Releases: | 4.2.3.FWDG, 5.1.1.BASE |
|
Known Fixed Releases: | 4.3.1.28i.BASE, 4.3.2.11i.BASE, 5.1.0.9i.BASE |
|
|
| |
| |
Bug Id: | CSCuu69916 |
Title: | ASR9K fib_mgr in Mutex with ipv4_mfwd_partner |
|
Description: | Symptom:
Unexpected forwarding (or complete loss) of ipv4 or multicast traffic due to the fib_mgr process being in a Mutex condition with ipv4_mfwd_partner on the affected line card.
RP/0/RSP0/CPU0:Router#show process blocked location 0/3/cpu0 | include Mutex
Jid Pid Tid Name State TimeInState Blocked-on
180 462959 5 fib_mgr Mutex 44:46:16:0943 462957-01 #1 ipv4_mfwd_partner
Conditions:
First seen on a ASR9K running 5.1.3 under the following conditions:
1) MVPN MLDP configuration is active
2) Node is a bud or tail node for the VRF with MLDP core
3) This linecard is the master linecard for MFIB which will cause both L3 FIB and MFIB to try to access the Master NP entry associated with the same MLDP VRF
4) The potential event that occurred at that time could be one of:
4)a. L3 FIB is adding/removing an MPLS Outleg for the MLDP Core label (i.e., P2MP replication)
4)b. MFIB is adding/removing an outgoing interface (local receiver) for the mcast route in the same VRF
Workaround:
Restart the component that is experiencing the issue.
Either
process restart fib_mgr location 0/3/cpu0
or
process restart ipv4_mfwd_partner location 0/3/cpu0
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 02-JUL-2015 |
|
Known Affected Releases: | 5.1.3.BASE, 6.0.0.BASE |
|
Known Fixed Releases: | 5.3.2.12i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCut84003 |
Title: | SVS FB 513: Netconf interface fails to start |
|
Description: | Symptom:
Polling of netconf query fails
Conditions:
Prior to netconf query failing, netconf process memory should have hit close to RLIMIT. Once this condition is hit, current mechanism assumes that memory level is continue to be at critical level and hence doesnot allow further query processing
Workaround:
Workaround: Process restart netconf_agent_tty
Further Problem Description:
Following logs are seen when netconf query failed:
=========================================
Apr 3 15:07:31.673 netconf/client/err 0/RP0/CPU0 t1 [760086963] Session init error [tp 9]: 'XML Service Library' detected the 'fatal' condition 'The router is low on memory. Please retry the request after memory consumption has gone down.'
Apr 3 15:07:31.673 netconf/client/err 0/RP0/CPU0 t1 [760086963] Failed to send message or reply error [tp 3]: 'XML Service Library' detected the 'fatal' condition 'The router is low on memory. Please retry the request after memory consumption has gone down.'
Apr 3 15:07:31.668 netconf/client/err 0/RP0/CPU0 808# t1 [760086957] Session init error [tp 9]: 'XML Service Library' detected the 'fatal' condition 'The router is low on memory. Please retry the request after memory consumption has gone down.'
Apr 3 15:07:31.668 netconf/client/err 0/RP0/CPU0 512# t1 [760086957] Failed to send message or reply error [tp 3]: 'XML Service Library' detected the 'fatal' condition 'The router is low on memory. Please retry the request after memory consumption has gone down.'
Apr 3 15:07:31.661 netconf/client/err 0/RP0/CPU0 630# t1 [760086962] Session init error [tp 9]: 'XML Service Library' detected the 'fatal' condition 'The router is low on memory. Please retry the request after memory consumption has gone down.'
Apr 3 15:07:31.661 netconf/client/err 0/RP0/CPU0 t1 [760086962] Failed to send message or reply error [tp 3]: 'XML Service Library' detected the 'fatal' condition 'The router is low on memory. Please retry the request after memory consumption has gone down.'
Apr 3 15:07:31.659 netconf/client/err 0/RP0/CPU0 862# t1 [760086954] Session init error [tp 9]: 'XML Service Library' detected the 'fatal' condition 'The router is low on memory. Please retry the request after memory consumption has gone down.'
Apr 3 15:07:31.659 netconf/client/err 0/RP0/CPU0 804# t1 [760086954] Failed to send message or reply error [tp 3]: 'XML Service Library' detected the 'fatal' condition 'The router is low on memory. Please retry the request after memory consumption has gone down.'
Apr 3 15:07:30.992 netconf/client/err 0/RP0/CPU0 t1 [760045999] Session init error [tp 9]: 'XML Service Library' detected the 'fatal' condition 'The router is low on memory. Please retry the request after memory consumption has gone down.'
Apr 3 15:07:30.992 netconf/client/err 0/RP0/CPU0 t1 [760045999] Failed to send message or reply error [tp 3]: 'XML Service Library' detected the 'fatal' condition 'The router is low on memory. Please retry the request after memory consumption has gone down.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 02-JUL-2015 |
|
Known Affected Releases: | 5.1.3.MGBL, 5.3.1.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo74055 |
Title: | OIR of 9001 MPA triggers partial NP lockup |
|
Description: | Symptom:
Packets can't be transmitted out of the interface.
Physical interface queues on egress are not draining, i.e. the "Qdepth" counter in the output of the "show qoshal default-queue subslot port location " command is constantly incrementing.
Examples in 'Further Problem Description'
Conditions:
Running software release 4.3.1 or above on the ASR9001 or ASR9001-S.
The MOD80 and MOD160 are NOT affected.
OIR of an MPA
Workaround:
none
Recovery is to reload the LC or entire router.
Reloading the sub-slot will result in the MPA going into a DISABLED state.
Further Problem Description:
Examples:
The following outputs are using port 1/0/1/0 (rack 1, LC 0, subslot 1, port 0)
RP/0/RSP0/CPU0:A9K#show qoshal default-queue subslot 1 port 0 location 1/0/cpu0
Egress: QID 0x20020 Entity: 1/0/2/4/4/0 Priority: Priority 1 Qdepth: 404 <<<-------------
StatIDs: commit/fast_commit/drop: 0x6900a0/0x61b/0x6900a1
Statistics(Pkts/Bytes):
Tx_To_TM 0/0 Fast TX: 669/28116
Total Xmt 669/28116 Dropped 0/0
Egress: QID 0x20022 Entity: 1/0/2/4/4/2 Priority: Priority Normal Qdepth: 982089 <<<-------------
StatIDs: commit/fast_commit/drop: 0x6900aa/0x61d/0x6900ab
Statistics(Pkts/Bytes):
Tx_To_TM 0/0 Fast TX: 241035322/175468774298
Total Xmt 241035322/175468774298 Dropped 0/0
Another indication is that all egress packets are dropped by the TM. Run a ping and confirm that the "drop paks" counter in the "show controllers np tm counters location " command is incrementing at the same or higher rate than ping drops:
RP/0/RSP0/CPU0:A9K#show controllers np tm counters np1 location 1/0/CPU0
==== TM Counters (NP 1 TM 0) ====
TM Counters:
xmt paks: 1804, xmt bytes: 432445
drop paks: 10, drop_bytes: 1140
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 02-JUL-2015 |
|
Known Affected Releases: | 4.3.4.LC |
|
Known Fixed Releases: | 5.1.3.9i.BASE, 5.2.0.27i.BASE |
|
|
| |
| |
Bug Id: | CSCut27671 |
Title: | FIB_MGR Crash when executing "show cef resource hardware ingress detail" |
|
Description: | Symptom:
fib_mgr crashes when "show cef resource hardware [ingress | egress] location " CLI is executed
Conditions:
The CLI is executed on the ASR9K Ethernet line cards.
IOS-XR 5.3.0 is used.
Workaround:
There is no workaround to prevent fib_mgr from crashing when the CLI is executed.
This CLI does not provide any useful information on ASR9K.
Use "show cef platform resource location " instead.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 02-JUL-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: | 5.3.1.24i.BASE, 5.3.1.24i.FWDG, 5.3.2.3i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCut30119 |
Title: | ASR9000 randomly sends incorrect server-id to clients |
|
Description: | Symptom:> it does looks like we're assigning an incorrect Giaddr to the client based on the following:
> it happens randomly to random clients
RP/0/RSP0/CPU0:1ASR9k#sho dhcp ipv4 proxy binding mac-address 3872.c034.08c6
Fri Feb 20 09:02:19.663 CST
MAC Address: 3872.c034.08c6
VRF: default
Server VRF: default
IP Address: 64.254.187.15
Giaddr from client: 0.0.0.0
Giaddr to server: 216.114.248.1 >>>> Incorrect Giaddr sent to client
Server IP Address: 216.114.192.215
Server IP Address to client: 216.114.224.1
ReceivedCircuit ID: NC05_N110_04 eth 0/13:101
InsertedCircuit ID: NC05_N110_04 eth 0/13:101
ReceivedRemote ID: 13/NC05_N110_04/BT/0010017908DVSL2
InsertedRemote ID: 13/NC05_N110_04/BT/0010017908DVSL2
ReceivedVSISO: -
InsertedVSISO: -
Auth. on received relay info:FALSE
ParamRequestOption: -
SavedOptions: -
Profile: dhcp
State: BOUND
Lease: 12756 secs (03:32:36)
Lease remaining: 9764 secs (02:42:44)
Client ID: 0x38-0x72-0xC0-0x34-0x08-0xC6
Access Interface: Bundle-Ether1.105
Access VRF: default
VLAN Id: 105
Subscriber Label: 0x0
Event History:
Session Start: Jan 29 03:35:40.259
PACKET_DISCOVER : 0.001s
DPM_SUCCESS : 0.001s
PACKET_OFFER : 0.001s
PACKET_REQUEST : 0.037s
PACKET_ACK : 0.038s
LEASE_DPM_SUCCESS : 0.038s
ROUTE_SUCCESS : 0.038s
OTHER : 19.412s
RP/0/RSP0/CPU0:1ASR9k#sho route 64.254.187.15
Fri Feb 20 09:02:29.430 CST
Routing entry for 64.254.187.15/32
Known via "subscriber", distance 1, metric 0 (connected)
Installed Feb 20 08:12:27.350 for 00:50:02
Routing Descriptor Blocks
directly connected, via Bundle-Ether1.105
Route metric is 0
No advertising protos.
interface Bundle-Ether1.105
description 1ASR9k to LC VLAN 105
ipv4 point-to-point
ipv4 unnumbered Loopback0
arp learning disable
encapsulation dot1q 105
ipv4 access-group 180 ingress
ipv4 access-group 181 egress
interface Loopback0
description 1ASR9k Min Pool 1
ipv4 address 216.114.248.1 255.255.252.0
ipv4 address 64.254.184.1 255.255.252.0 secondary >>>> assigned Giaddr for the yiaddr
ipv4 address 64.254.188.1 255.255.252.0 secondary
ipv4 address 68.232.232.1 255.255.248.0 secondary
ipv4 address 68.232.254.1 255.255.255.128 secondary
ipv4 address 69.24.160.1 255.255.224.0 secondary
ipv4 address 172.28.240.1 255.255.252.0 secondary
ipv4 address 216.114.224.1 255.255.248.0 secondary
ipv4 address 216.114.240.1 255.255.248.0 secondary
Conditions:Random
Workaround:Manual clear of proxy binding / manual client reboot
More Info:N/A
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 02-JUL-2015 |
|
Known Affected Releases: | 5.1.3.BASE |
|
Known Fixed Releases: | 5.3.2.7i.FWDG, 6.0.0.5i.FWDG |
|
|
| |
| |
Bug Id: | CSCul84303 |
Title: | Huge Counters on Bundle-ether Sub interface |
|
Description: | Symptom:
Huge counters on Bundle-ether interface.
Conditions:
After doing shut/no-shut or clear counters on bundle-ether interface huge input counters are noticed.
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUL-2015 |
|
Known Affected Releases: | 4.3.2.BASE, 5.1.11.MGBL |
|
Known Fixed Releases: | 5.1.2.9i.BASE, 5.2.0.8i.BASE |
|
|
| |
| |
Bug Id: | CSCuu05769 |
Title: | Wrong flow addition in Standby after rekey on Active SecGW. |
|
Description: | Symptom:
Downlink traffic fails on new Active SecGW after ipsec rekey initiated from peer followed by ICSR switchover on ipv4 S2S tunnels with tsr ranging 0.0.0.0 to 255.255.255.255.
Conditions:
1) Connected Apps is disabled.
2) Enable ipsec rekey at peer.
3) Create an ipv4 S2S tunnel with tsr ranging 0.0.0.0 to 255.255.255.255.
4) Verify that the tunnel is synched to standby.
5) Wait for the Rekey from Peer, after rekey does the switchover.
6) After rekey, wrong s2s flow gets added in Standby due to which traffic fails on new Active SecGW after switchover.
Workaround:
No workarounds found.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUL-2015 |
|
Known Affected Releases: | 18.0.0.59590 |
|
Known Fixed Releases: | 18.2.0, 18.2.0.60389, 18.2.0.60395, 18.2.M0.59947, 18.2.v0, 19.0.M0.60017, 19.1.A0.60021, 20.0.M0.60163 |
|
|
| |
| |
Bug Id: | CSCus64739 |
Title: | auto backups with srlg penalties periodically reoptimize |
|
Description: | Symptom:
auto-tunnel backup with SRLG weighted configured on a DUT with 52.21 image, we observed that it causes a periodically reoptimization
Conditions:
use the following configuration in mpls traffic-eng area. on top of it, we have 4K head end and 64K mid point through this DUT.
mpls traffic-eng
apply-group srlg_test SRLG-COST
interface TenGigE0/0/0/35
!
interface TenGigE0/1/0/23
!
interface Bundle-Ether6064
auto-tunnel backup
exclude srlg weighted
attribute-set bypass
!
!
interface Bundle-Ether6164
attribute-names red
auto-tunnel backup
exclude srlg weighted
attribute-set bypass
!
!
interface Bundle-Ether6264
auto-tunnel backup
exclude srlg weighted
attribute-set bypass
!
!
interface Bundle-Ether6364
auto-tunnel backup
exclude srlg weighted
attribute-set bypass
!
!
mib midstats disable
srlg
admin-weight 30000
value 1
admin-weight 1111111111
!
value 2
admin-weight 2222222222
!
value 3
admin-weight 3333333333
!
value 4
admin-weight 444444444
!
value 5
admin-weight 555555555
!
value 6
admin-weight 666666666
!
value 7
admin-weight 777777777
!
value 8
admin-weight 80000
static ipv4 address 13.60.64.2 next-hop ipv4 address 13.60.64.3
static ipv4 address 13.61.64.2 next-hop ipv4 address 13.61.64.3
static ipv4 address 13.62.64.2 next-hop ipv4 address 13.62.64.3
static ipv4 address 13.63.64.2 next-hop ipv4 address 13.62.64.3
!
value 9
admin-weight 40000
!
value 10
admin-weight 81010
static ipv4 address 13.63.64.2 next-hop ipv4 address 13.63.64.3
!
!
logging events preemption
auto-tunnel backup
timers removal unused 0
tunnel-id min 65000 max 65535
affinity ignore
!
reoptimize 90
fast-reroute timers promotion 900
affinity-map red bit-position 0
affinity-map EDGE bit-position 27
affinity-map METRO bit-position 29
affinity-map ACCESS bit-position 28
affinity-map orange bit-position 11
affinity-map PEERING bit-position 23
affinity-map CONTINENTAL bit-position 30
affinity-map TRANSOCEANIC bit-position 31
affinity-map PEERING-FILTERED bit-position 22
signalling advertise explicit-null
attribute-set auto-backup bypass
logging events lsp-status reoptimize
logging events lsp-status state
record-route
affinity ignore
!
auto-bw collect frequency 1
reoptimize timers delay cleanup 60
reoptimize timers delay installation 20
reoptimize timers delay after-affinity-failure 10
link-management timers periodic-flooding 180
link-management timers preemption-delay bundle-capacity 5
Workaround:
N/A
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUL-2015 |
|
Known Affected Releases: | 5.2.2.BASE |
|
Known Fixed Releases: | 5.2.21.MPLS, 5.2.4.4i.MPLS, 5.3.1.19i.MPLS, 6.0.0.5i.MPLS |
|
|
| |
| |
Bug Id: | CSCuq14174 |
Title: | MTU not correct on satellite side of ICL |
|
Description: | Symptom:
After setting up a satellite on 5.1.2, frames over 1514 bytes (XR MTU calculation) are not being passed to the satellite host ports when MTU is set higher than that.
Conditions:
Running satellite on 5.1.2 with MTU higher than 1514.
Workaround:
Unconfigure the MTU on the host port and reconfigure it
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 5.1(2) |
|
Known Fixed Releases: | 15.1(3)SVG03, 15.1(3)SVG03a |
|
|
| |
| |
Bug Id: | CSCut57864 |
Title: | QoS MIB skips processing remaining items in batch after encount error |
|
Description: | The SNMP index of the egress policies we have configured is missing on several Bundle-Ether Interfaces.For BE11 and BE12, there is no information about outbound qos queue bit/s. For BE16, it works fine.The SNMP index of the egress policies we have configured is missing on several Bundle-Ether Interfaces.For BE11 and BE12, there is no information about outbound qos queue bit/s. For BE16, it works fine.For BE11(ifindex 1206), we can see that we only have ingress policy index.RP/0/RP0/CPU0:bx03.iad23#show snmp interface bundle-ether 11 ifindex Mon Mar 16 14:22:06.426 PDTifName : Bundle-Ether11 ifIndex : 1206ifName : Bundle-Ether12 ifIndex : 1207ifName : Bundle-Ether16 ifIndex : 1331qideng@nbh1-new:~$ snmpwalk -c public -v 2c bx03.iad23.net 1.3.6.1.4.1.9.9.166.1.2.1.1iso.3.6.1.4.1.9.9.166.1.2.1.1.1.1197.1 = Gauge32: 1446755488iso.3.6.1.4.1.9.9.166.1.2.1.1.1.1206.1 = Gauge32: 2078029712>>>>>>>>>>BE11iso.3.6.1.4.1.9.9.166.1.2.1.1.1.1207.1 = Gauge32: 188101793>>>BE12iso.3.6.1.4.1.9.9.166.1.2.1.1.1.1331.1 = Gauge32: 677941965>>BE16 ingressiso.3.6.1.4.1.9.9.166.1.2.1.1.1.1331.2 = Gauge32: 1827653290>>BE16 egressSince Bundle-ethe 11, bundle-eth 12 on lc 0/4/cpu0 , so workaround can try restart this process only on lc 0/4/cpu0 #process restart mibd_interface location 0/4/cpu0after workaround:=======The proposed workaround appears to have worked, I see both MIBs for the interfaces in question. nwinemiller@nbh1-new:~$ snmpwalk -c public -v 2c bx03.iad23.net 1.3.6.1.4.1.9.9.166.1.2.1.1iso.3.6.1.4.1.9.9.166.1.2.1.1.1.1206.1 = Gauge32: 2078029712---BE11-ingressiso.3.6.1.4.1.9.9.166.1.2.1.1.1.1206.2 = Gauge32: 1266264741---BE11--egressiso.3.6.1.4.1.9.9.166.1.2.1.1.1.1207.1 = Gauge32: 188101793---BE12-ingressiso.3.6.1.4.1.9.9.166.1.2.1.1.1.1207.2 = Gauge32: 544924422---BE12-egressiso.3.6.1.4.1.9.9.166.1.2.1.1.1.1331.1 = Gauge32: 677941965---BE16 ingressiso.3.6.1.4.1.9.9.166.1.2.1.1.1.1331.2 = Gauge32: 1827653290--BE16 egress
Symptom:
Missing Qos MIB entries. The configuration (show running-config ) and QoS MIB Polled result are not in sync.
Conditions:
Workaround:
=======The proposed workaround appears to have worked, I see both MIBs for the interfaces in question. nwinemiller@nbh1-new:~$ snmpwalk -c public -v 2c bx03.iad23.net 1.3.6.1.4.1.9.9.166.1.2.1.1iso.3.6.1.4.1.9.9.166.1.2.1.1.1.1206.1 = Gauge32: 2078029712---BE11-ingressiso.3.6.1.4.1.9.9.166.1.2.1.1.1.1206.2 = Gauge32: 1266264741---BE11--egressiso.3.6.1.4.1.9.9.166.1.2.1.1.1.1207.1 = Gauge32: 188101793---BE12-ingressiso.3.6.1.4.1.9.9.166.1.2.1.1.1.1207.2 = Gauge32: 544924422---BE12-egressiso.3.6.1.4.1.9.9.166.1.2.1.1.1.1331.1 = Gauge32: 677941965---BE16 ingressiso.3.6.1.4.1.9.9.166.1.2.1.1.1.1331.2 = Gauge32: 1827653290--BE16 egress
Symptom:Missing Qos MIB entries. The configuration (show running-config ) and QoS MIB Polled result are not in sync.
Conditions:
Workaround:Restart mibd_interface process on the RP. On restart the entire config will be replayed.
#process restart mibd_interface
after workaround:
=======
The proposed workaround appears to have worked, I see both MIBs for the
interfaces in question. nwinemiller@nbh1-new:~$ snmpwalk -c public -v 2c bx03.iad23.net
1.3.6.1.4.1.9.9.166.1.2.1.1iso.3.6.1.4.1.9.9.166.1.2.1.1.1.1206.1 = Gauge32: 2078029712---BE11-ingress
iso.3.6.1.4.1.9.9.166.1.2.1.1.1.1206.2 = Gauge32: 1266264741---BE11--egressiso.3.6.1.4.1.9.9.166.1.2.1.1.1.1207.1 = Gauge32: 188101793---BE12-ingress
iso.3.6.1.4.1.9.9.166.1.2.1.1.1.1207.2 = Gauge32: 544924422---BE12-egress
iso.3.6.1.4.1.9.9.166.1.2.1.1.1.1331.1 = Gauge32: 677941965---BE16 ingress
iso.3.6.1.4.1.9.9.166.1.2.1.1.1.1331.2 = Gauge32: 1827653290--BE16 egress
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 5.1.11.MGBL |
|
Known Fixed Releases: | 5.3.1.28i.FWDG, 5.3.2.6i.FWDG, 6.0.0.5i.FWDG |
|
|
| |
| |
Bug Id: | CSCuv03148 |
Title: | rsp kernel dump due to tcp |
|
Description: | Symptom:
rsp reset due tcp process triggered kernel dump
Conditions:
asr9k router running 532 interim image
Workaround:
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo62207 |
Title: | ASR9000v2: Bundle Ether is not coming up on Satellite access ports |
|
Description: | Symptom:
Bundle ether interfaces on front ports are not coming up.
Conditions:
Create a bundle on host and make access ports of satellite part of it and also create a bundle on the remote router
to which the satellite is connected to. The bundle status on both remote router and on host will be down.
Workaround:
No Workarounds.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 5.2(2) |
|
Known Fixed Releases: | 15.1(3)SVH |
|
|
| |
| |
Bug Id: | CSCus77442 |
Title: | After Router Reload - SAT in Connecting, CPU - 100% @ SDAC Sat Control |
|
Description: | Symptom:
After Router Reload - SAT in Connecting, CPU - 100% @ SDAC Sat Control
Conditions:
Router Reload
Workaround:
Satellite Reload
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 5.3.1.BASE, 5.3.2.BASE |
|
Known Fixed Releases: | 5.3.1.20i.FWDG, 6.0.0.5i.FWDG |
|
|
| |
| |
Bug Id: | CSCud13292 |
Title: | SAT:In 9000v no major alarm raised when there is Serial number mismatch |
|
Description: | Symptom:
Satellite raises no alarms on authentication fail.
Conditions:
Description:
=========
On 9000nv satellite, I am not seeing any alarm [major/critical/minor] turned on when there is a Serial number mismatch". This feature tested on 9000nv when it acts as a satellite mode which is connected to asr9k router.
Detailed procedure:
============
While bringing up the satellite we can configure the "9000 serial number" under the config "nv satellite" on the host. if there is a serial number is mismatch then Satellite State will be in "State: Authentication failed" and the connection will not be established. During this authentication failed we except the major alarm should be signaled on satellite side. But currently we are not seeing any alarm turned on at satellite side.
Common Test bed:
IXIA--[Host ASR9k RO chassis]------(ICL)-------[9000 Satellite] ----IXIA
For Configuration at host:
----------------------------------
RP/0/RSP0/CPU0:mt_vkg3#show running-config nv satellite 100
nv
satellite 100
type asr9000v
serial-number SER-10556333
description sat100
ipv4 address 10.10.10.10
!
!
RP/0/RSP0/CPU0:mt_vkg3#show nv satellite status
Satellite 100
-------------
State: Authentication failed
Type: asr9000v
Description: sat100
MAC address: 4055.3956.3930
IPv4 address: 10.10.10.10
Configured Serial Number: SER-10556333
Received Serial Number: CAT1529B2VM
Configured satellite fabric links:
TenGigE0/1/0/1
--------------
State: Satellite Ready
Port range: GigabitEthernet0/0/0-20
TenGigE0/1/0/18
---------------
State: Satellite Ready
Port range: GigabitEthernet0/0/21-43
Workaround:
user can identify this by executing command
RP/0/RSP0/CPU0:umangasr9k#show nv satellite status satellite .
If state is Authentication failed and serial numbers are different then
he need to reconfigure satellite with proper serial no.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 4.3 |
|
Known Fixed Releases: | 15.1(3)SVD, 15.1(3)SVE |
|
|
| |
| |
Bug Id: | CSCuh56864 |
Title: | asr9000v won't negotiate speed and duplex using copper SFP |
|
Description: | Symptom: autonego won't negotiate speed/duplex on asr9000v satellite
Conditions:no further condition
peer with or without speed and/or duplex preference
peer RJ45 and/or SFP connector
Workaround: hardcode speed and duplex, some peer devices can work in a-nego mode ONLY, no WA for them
DDTS used to commit this Issue on 9k host lineup are:
431: CSCui77863
http://cdets.cisco.com/apps/dumpcr?content=summary&format=html&identifier=CSCui77863
432 :CSCud69751
http://cdets.cisco.com/apps/dumpcr?content=summary&format=html&identifier=CSCud69751
510 : CSCue46285
http://cdets.cisco.com/apps/dumpcr?content=summary&format=html&identifier=CSCue46285
511 : CSCuf73352
http://cdets.cisco.com/apps/dumpcr?content=summary&format=html&identifier=CSCuf73352
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 4.3(1) |
|
Known Fixed Releases: | 15.1(3)SVD02, 15.1(3)SVE, 15.1(3)SVF, 15.1(3)SVF02, 15.1(3)SVF02a |
|
|
| |
| |
Bug Id: | CSCui33744 |
Title: | port states inconsistent between asr9K/host and asr9000v/satellite |
|
Description: | Symptom: port state and/or duplex param inconstent between peer/satellite/host after satellite reboot OR flapping many ports on peer at the same time
Conditions: scaled setup, more then 20 access port used on 9000v, issue seen w/ copper SPFs, however might not be copper specific
Workaround: flap the affected ports manually on host
DDTS used to commit this Issue on 9k host lineup are:
431: CSCui77863
http://cdets.cisco.com/apps/dumpcr?content=summary&format=html&identifier=CSCui77863
432 :CSCud69751
http://cdets.cisco.com/apps/dumpcr?content=summary&format=html&identifier=CSCud69751
510 : CSCue46285
http://cdets.cisco.com/apps/dumpcr?content=summary&format=html&identifier=CSCue46285
511 : CSCuf73352
http://cdets.cisco.com/apps/dumpcr?content=summary&format=html&identifier=CSCuf73352
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 4.2(1), 4.3(1) |
|
Known Fixed Releases: | 15.1(3)SVD02, 15.1(3)SVE, 15.1(3)SVF, 15.1(3)SVF02, 15.1(3)SVF02a |
|
|
| |
| |
Bug Id: | CSCur26531 |
Title: | 530-8i : Satellite has stuck in CONNECTING state during topo change |
|
Description: | Symptom:
Satellite stuck in connecting state
Conditions:
Topology change from L2fab to Simple Ring
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 5.3(0) |
|
Known Fixed Releases: | 15.1(3)SVH04 |
|
|
| |
| |
Bug Id: | CSCut76480 |
Title: | Router reload due to sysdb_shared_nc crash |
|
Description: | Router reload due to sysdb_shared_nc crash
Symptom:
sysdb_shared_nc crash
Conditions:
Occurred in customer network due to ipv6 sysdb data continue increasing indefinitely caused by CSCum93144
Workaround:
use image with the CSCum93144 fix or install CSCum93144 SMU fix
Further Problem Description:
Router reload due to sysdb_shared_nc crash
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 5.1.3.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus62315 |
Title: | ARP/PING packets dropped on port 27 |
|
Description: | Symptom:
Ping and ARP are not working for port 27 on a 9000v
Conditions:
9000v satellite
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 5.1(3) |
|
Known Fixed Releases: | 15.1(3)SVG03a, 15.1(3)SVH04 |
|
|
| |
| |
Bug Id: | CSCuj98150 |
Title: | 9000v:The displayed power levels on satellite have mW unit only,need dBm |
|
Description: | Symptom:
1. ASR9000v doesn't display the optical power levels in dBm. Currently the units are in mW
2. The output should also display min and max thresholds (Alarm and Warning)
Conditions:
This is enhancement request
Workaround:
N/A
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 4.3(1) |
|
Known Fixed Releases: | 15.1(3)SVG01b, 15.1(3)SVG01c, 15.1(3)SVG02 |
|
|
| |
| |
Bug Id: | CSCug90322 |
Title: | ASR9K nV Satellite Auto-QoS P2 Policer Change |
|
Description: | Symptom:
Unable to change the P2 policer configured by auto-QoS that is applied to ASR9K Satellite ICL links.
Conditions:
4.3.1 or previous code
nV Satellite configured
High volume of P2 traffic
Workaround:
None. In order to change the P2 policer and allow greater than 1Gbps of traffic in this queue the associated SMU will need to be installed. The SMU changes the policed rate to 2.5Gbps.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 04.03.00.BASE |
|
Known Fixed Releases: | 15.1(3)SVD01, 15.1(3)SVE, 15.1(3)SVF, 15.1(3)SVF02, 15.1(3)SVF02a |
|
|
| |
| |
Bug Id: | CSCut99536 |
Title: | IPv6 NS packets dropped on ingress of BE |
|
Description: | Symptom:
IPv6 NS packets sent by clients are dropped
Conditions:
Clients are connected behind a bundle-ethernet
Workaround:
Configure a static IPv6 neighborship for the router on the affected client
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 4.3.4.ROUT |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut74251 |
Title: | OSPFv3 neighbors go down after ipsec authentication and never come up |
|
Description: | Symptom:Some OSPFv3 neighbors go down after enabling ipsec authentication and never come up.
Conditions:There are more than 290 OSPFv3 neighbors configured with ipsec authentication on a Trident-based line card.
Workaround:There is no workaround.
More Info:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 4.2.3.BASE, 4.3.4.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCul13386 |
Title: | Half of the satellite ports are not coming up |
|
Description: | Symptom:
Half of the ports of a 9000v satellite stay down
Conditions:
Ports 0->7 are fine, 8->15 are not, etc...
Workaround:
None
Further Problem Description:
The issue is now resolved and it is working for all the supported pluggables for ASR9000v.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 4.3(1) |
|
Known Fixed Releases: | 15.1(3)SVG02, 15.1(3)SVH |
|
|
| |
| |
Bug Id: | CSCuu84008 |
Title: | ASR9000v seeing multiple parity errors on L3_ENTRY_ONLY entry |
|
Description: | Symptom:
1) ASR 9000v running Version 15.1(3)SVB1 and host ASR9k running version 4.2.3 is seeing the below parity errors
*Jun 5 01:02:16.096: %BCMSDK-3-BCM_ERR_MSG_ALERT: BCM SDK error messages logged
*Jun 5 01:02:46.184: %BCMSDK-3-BCM_ERR_MSG_LOG: BCM ERR: [unit 0 L3_ENTRY_ONLY entry 6463 parity error
] -Process= "bcmDPC", ipl= 0, pid= 49
-Traceback= D24A44z B599D8z F0EBA8z E2C3D8z E2CDFCz E2CECCz D2679Cz D288F4z 40D048z 4071E0z
or
*May 6 07:03:22.320: %BCMSDK-3-BCM_ERR_MSG_ALERT: BCM SDK error messages logged
*May 6 18:03:10.789: %BCMSDK-3-BCM_ERR_MSG_LOG: BCM ERR: [unit 0 ING_IPFIX_SESSION_TABLE entry 1899 parity error
] -Process= "bcmDPC", ipl= 0, pid= 49
or
*Feb 10 16:11:55.476: %BCMSDK-3-BCM_ERR_MSG_ALERT: BCM SDK error messages logged
*Feb 10 16:12:37.476: %BCMSDK-3-BCM_ERR_MSG_LOG: BCM ERR: [unit 0 L2X entry 31410 parity error
] -Process= "bcmDPC", ipl= 0, pid= 49
2) These parity errors in some scenarios when customer has configured for q-in-q tunneling sees frame loss.
3) There is no issue when the regular traffic is being passed through the ASR9000v
Conditions:
The only conditions are when the customer is configured for q-in-q tunnel.
Workaround:
In some cases as this is Hardware parity error a reload of the satellite can fix the issue but the parity errors can come again.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 4.2(3) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCup67926 |
Title: | Satellite does not detect ICL link down on Tx cable removal |
|
Description: | Symptom:
Expected Behavior: When the Tx cable is plugged out from ICL port of satellite, the respective port on host stops receiving laser which in turn will go down and notifies satellite port on Remote fault. As satellite receives a Remote fault it should make the ICL port (from which tx is plugged out) down and at the same time as the ICL is down on host, satellites goes down.
But contrary to above mentioned the satellite port is up when we plug out tx cable.
Conditions:
We see this issue if we unplug tx cable from satellite ICL port when connected to host.
9k---------------------satellite
ICL interface
Workaround:
No Work around.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 5.2(2) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCul23049 |
Title: | Fan failure and DC power alarms not raised on ASR 9000v |
|
Description: | Symptom:
Scenario: We simulated a single fan failure on 9000v fan tray, but we did not receive any traps or syslog on the host shelf.
Customer's ask:
1. To get a syslog and a trap even with a single fan failure.
2. Host shows fan1,2,3,4 speed as 960rpm even though only a single fan failed.
Conditions:
Fail a single fan on the 9000v shelf's fan tray by disconnecting the pin.
Workaround:
"show satellite environment" on satellite shelf shows if one of the fan fails
Further Problem Description:
If one of the fan fails, on ASR9K see the fan tray failure alarm syslog.
If any power feed fail, on ASR9k see the corresponding PSU alarm syslog.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 4.3(1), 5.1(1) |
|
Known Fixed Releases: | 15.1(3)SVF01, 15.1(3)SVF02, 15.1(3)SVF02a, 15.1(3)SVF04c, 15.1(3)SVG, 15.1(3)SVG01a, 15.1(3)SVG01c |
|
|
| |
| |
Bug Id: | CSCuv11605 |
Title: | TCAM entries not getting populated properly. |
|
Description: | Symptom:
TCAM entries are not being programmed.
Conditions:
Even though the mpls labels are not programmed I can still get the traffic to flow in IPv4 To IPv6 direction (probably the they are not being classified based on label see attached logs for more detail) but it doesn't work in the IPv6 to IPv4 direction.
Kindly find the attached log for the same.
Workaround:
N/A
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | 5.3.2.3i.BASE |
|
|
| |
| |
Bug Id: | CSCuq16037 |
Title: | High CPU on SAT - leading to SAT in Connecting state. |
|
Description: | Symptom:
High CPU on SAT - leading to SAT in Connecting state.
Conditions:
Router Relaod
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 5.2.2.BASE |
|
Known Fixed Releases: | 5.2.2.23i.FWDG, 5.2.3.8i.FWDG, 5.3.0.8i.FWDG |
|
|
| |
| |
Bug Id: | CSCud99815 |
Title: | Satellite unit 9000v crashed and recovered |
|
Description: | Symptom:
The satellite unit crashes
Conditions:
When running the following commands in the console:
dir /rec xmodem
dir /rec ymodem
Workaround:
None
The fix would be removing that syntax since it is not used.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 06-JUL-2015 |
|
Known Affected Releases: | 4.2(1), 5.1(1) |
|
Known Fixed Releases: | 15.1(3)SVD, 15.1(3)SVE |
|
|
| |
| |
Bug Id: | CSCun15934 |
Title: | Disable Label allocation for learned routes towards BVIs on Trident |
|
Description: | Symptom:
LDP is allocating local label for routes with BVI next hop interfaces
Conditions:
ASR9K PD doesn't support BVI interfaces and as a result traffic is dropped when MPLS label is removed and forwarded as IP on BVI interface
This is not a concern for Typhoon based cards. Those cards can handle the labeled traffic through the BVI. Only Trident cards will drop this traffic.
Workaround:
Add LDP local label ACL filter to prevent LDP from allocating local labels for routes with BVI next hop interfaces. Or use Typhoon based linecards in place of the Tridents.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 4.3.4.MPLS |
|
Known Fixed Releases: | 4.3.4.SP1, 4.3.4.SP4, 4.3.4.SP5, 4.3.4.SP6, 4.3.4.SP7, 4.3.4.SP8, 5.1.2.17i.MPLS, 5.1.2.22i.MPLS, 5.1.3.1i.MPLS, 5.2.0.15i.MPLS |
|
|
| |
| |
Bug Id: | CSCuo17901 |
Title: | Out of order mcast packets introduced by ASR9K MLDP+bundle |
|
Description: | Symptom:
Out-of-order multicast packets in the same multicast stream when using MLDP.
Conditions:
Following conditions are required:
- the traffic must be sent over an MLDP core
- the role of the router must be a bud or mid
- there must be an egress bundle
- two or more bundle members must reside on the same NP
- the LC must be a Typhoon
Workaround:
Possible workarounds:
- Move the egress bundle members to different NPs.
- Remove the egress bundle (use ECMP links)
- Use P2MP or Rosen MVPN instead of MLDP
- Use Trident instead of Typhoon
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 4.3.4.MCAST |
|
Known Fixed Releases: | 4.3.4.SP3, 4.3.4.SP4, 4.3.4.SP5, 4.3.4.SP6, 4.3.4.SP7, 4.3.4.SP8, 5.1.2.23i.BASE, 5.1.3.5i.BASE |
|
|
| |
| |
Bug Id: | CSCuo70584 |
Title: | Devc-vty process crashes when multiple SSH connections |
|
Description: | Symptom:
Devc-vty process crash terminating all SSH connections. Process will recover, and SSH is available again.
Conditions:
Router running 5.1.1 and 5.1.2 using SSH.
Workaround:
none
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 5.1.1.BASE, 5.1.2.BASE, 5.1.2.MGBL, 5.1.2.TOOLS, 5.2.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCun75418 |
Title: | DWDM Umbrella SMU for 4.3.4 |
|
Description: | Symptom:This DDTS is and umbrella SMU for the following bugs CSCun26272, CSCul66327, CSCun27023 and CSCud93983
Conditions:normal
Workaround:none
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 4.3.4.BASE |
|
Known Fixed Releases: | 4.3.4.SP4, 4.3.4.SP5, 4.3.4.SP6, 4.3.4.SP7, 4.3.4.SP8, 5.2.0.99i.BASE |
|
|
| |
| |
Bug Id: | CSCup45536 |
Title: | CEF not updated for recur lev 2 prefix when adding static route to NULL |
|
Description: | Symptom:
When the next hop for a BGP prefix originates from BGP and a static route is added to replace the route, CEF may keep the stale entry from BGP
Example:
4.14.14.0/24, version 689, internal 0x14000001 0x0 (ptr 0x71e8a318) [1], 0x0 (0x0), 0x0 (0x0)
Updated Jun 19 07:14:43.006
Prefix Len 24, traffic index 0, precedence n/a, priority 4
gateway array (0x71450e58) reference count 2, flags 0x8020, source rib (6), 0 backups
[1 type 3 flags 0x80151 (0x71545df4) ext 0x0 (0x0)]
LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0]
Level 1 - Load distribution: 0
[0] via 129.250.0.254, recursive
via 129.250.0.254, 2 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0x71e8a240 0x0]
next hop 129.250.0.254 via 129.250.0.254/32
Load distribution: _ (refcount 1)
Hash OK Interface Address
- Y TenGigE0/1/0/13 remote
RP/0/RSP0/CPU0:ASR9010-C#sh ip rou 129.250.0.254
Thu Jun 19 07:19:40.184 UTC
Routing entry for 129.250.0.254/32
Known via "static", distance 1, metric 0 (connected)
Installed Jun 19 07:16:57.862 for 00:02:42
Routing Descriptor Blocks
directly connected, via Null0
Route metric is 0
No advertising protos.
Conditions:
Workaround:
clear route ipv4 unicast
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 5.1.3.ROUT, 5.2.0.ROUT |
|
Known Fixed Releases: | 4.3.4.SP4, 4.3.4.SP5, 4.3.4.SP6, 4.3.4.SP7, 4.3.4.SP8, 5.1.3.14i.FWDG, 5.2.2.17i.FWDG, 5.2.3.6i.FWDG, 5.3.0.1i.FWDG |
|
|
| |
| |
Bug Id: | CSCuq07432 |
Title: | Ingress SPAN and ABF pointing to egress BVI can cause NP lockup |
|
Description: | Symptom:
Possible to see NP lockup reported and causing NP fast reset on Typhoon based linecards.
Example:
LC/0/3/CPU0:Jun 18 00:15:50.257 GMT: pfm_node_lc[287]: %PLATFORM-NP-2-NP_DIAG : Set|prm_server_ty[176210]|Network Processor Unit(0x1008002)| NP diagnostics warning on NP2.
LC/0/3/CPU0:Jun 18 00:16:06.910 GMT: prm_server_ty[297]: %PLATFORM-NP-4-FAULT : Fast Reset NP2 - successful auto-recovery of NP
LC/0/3/CPU0:Jun 18 00:16:06.910 GMT: pfm_node_lc[287]: %PLATFORM-NP-2-NP_DIAG : Clear|prm_server_ty[176210]|Network Processor Unit(0x1008002)| NP diagnostics warning on NP2.
Conditions:
This has been seen with SPAN on ingress direction with ABF configured where the nexthop interface is a BVI. Sending packets at or near the MTU of the BVI can cause the lockup.
In the NPdatalog written you will see RSV_PUNT_IP_MTU_EXCEEDED.
Workaround:
Increase the BVI MTU so that it's larger than ingress interfaces. Or remove SPAN
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 4.3.4.BASE, 4.3.4.LC |
|
Known Fixed Releases: | 4.3.4.SP4, 4.3.4.SP5, 4.3.4.SP6, 4.3.4.SP7, 4.3.4.SP8, 5.1.3.18i.BASE, 5.1.4.1i.BASE, 5.2.2.21i.BASE, 5.2.3.8i.BASE, 5.3.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCui67212 |
Title: | ASR9K does not generate ICMPv6 packet too big messages |
|
Description: | Symptom:
ASR9K not generate "ICMPv6 packet too big messages" when packets arrive for a destination reachable through a subscriber pppoe interface (provided that packet size > pppoe interface ipv6 mtu = 1492)
Conditions:
This behavior is specific to PPP subscriber interfaces.
Workaround:
Try to use static interface
Example:
interface Bundle-Ether12000.321
ipv6 address
encapsulation dot1q 321
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 4.3.1.BASE |
|
Known Fixed Releases: | 4.3.2.SP5, 4.3.2.SP6, 4.3.2.SP7, 4.3.2.SP8, 4.3.4.SP3, 4.3.4.SP4, 4.3.4.SP5, 4.3.4.SP6, 4.3.4.SP7, 4.3.4.SP8 |
|
|
| |
| |
Bug Id: | CSCus59296 |
Title: | Trident Line Card High CPU due to two processes prm_server_tr and horse |
|
Description: | Symptom:
CPU utilization for one minute: 47%; five minutes: 47%; fifteen minutes: 47%
PID 1Min 5Min 15Min Process
49195 23% 23% 23% horse
155719 3% 3% 3% fialc
155731 21% 21% 21% prm_server_tr
Conditions:
show controllers np interrupts all all location 0/3/CPU0 (snipped)
Sat Jan 3 16:39:03.858 GMT
Node: 0/3/CPU0:
----------------------------------------------------------------
Ch Interrupt Name Id Cnt Brst
-- -------------------------------------------------- ---- ------- ------
1 XAUI_B_MAC 29 -1510663930 0
Workaround:
Configure the interface in "loopback internal". This will prevent the interrupt from flapping.
Also inserting optics in unused ports will prevent the problem.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 4.3.4.BASE, 4.3.4.LC |
|
Known Fixed Releases: | 4.3.4.SP7, 4.3.4.SP8, 5.2.4.4i.BASE, 5.3.1.17i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCuq13793 |
Title: | show inventory, show diag does not present output |
|
Description: | Symptom:
Concern:
show inventory, show diag does not present output
No response from 'invmgr' as per below messages
Evidence:
RP/0/RSP0/CPU0:nr11.b001049-0.iah01#show inventory
Thu Jun 12 22:20:29.480 UTC
RP/0/RSP0/CPU0:Jun 12 22:22:09.631 : sysdb_shared_nc[414]: %SYSDB-SYSDB-6-TIMEOUT_EDM : EDM request for 'oper/inventory/gl/rack/0/entity/' from 'show_inventory' (jid 65776, node 0/RSP0/CPU0). No response from 'lrd' (jid 316, node 0/RSP0/CPU0) within the timeout period (100 seconds)
RP/0/RSP0/CPU0:Jun 12 22:22:09.632 : [417]: %SYSDB-SYSDB-6-TIMEOUT_EDM : EDM request for 'admin/oper/inventory/rack/0/entity/' from 'lrd' (jid 316, node 0/RSP0/CPU0). No response from 'invmgr' (jid 257, node 0/RSP0/CPU0) within the timeout period (100 seconds)
RP/0/RSP0/CPU0:nr11.b001049-0.iah01#show processes block location all
Thu Jun 12 22:04:53.331 UTC
node: node0_RSP0_CPU0
------------------------------------------------------------------
65870 407023950 1 show_inventory Reply 0:00:42:0938 192605 sysdb_mc
Conditions:
unknown
Workaround:
restart invmgr process
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 4.3.2.BASE |
|
Known Fixed Releases: | 4.3.4.SP7, 4.3.4.SP8, 5.2.4.10i.BASE, 5.2.5.4i.BASE, 5.3.1.17i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCui15435 |
Title: | Recovery mechanism needed for FPGA soft errors on Trident Linecards |
|
Description: | Symptom:When the FPGA memory is corrupted by a soft error it will cause inconsistent behavior or deviation from the intended functionality. In these cases the FPGA will remain in the failed state unless a reload of the configuration memory (image) is done or the line card is reloaded. This option needs to be implemented to recover from such scenarios, which can occur in the field without requiring a customer initiated reload of the affected linecard.
Soft errors are nonpermanent errors that cause the state machine to be out of sync. These are seen as Cyclic Redundancy Check (CRC), Frame Check Sequence (FCS), or errored packets on the fabric side of the NP or on the ingress side of the FIA. This issue is currently under investigation with Cisco bug ID CSCui15435.
Conditions:Here are some examples of how this issue can be seen:
RP/0/RSP0/CPU0:asr9k-1#show controllers fabric fia drops ingress location 0/3/CPU0
********** FIA-0 **********
Category: in_drop-0
DDR Rx FIFO-0 0
DDR Rx FIFO-1 32609856 <=== Errors
RP/0/RSP0/CPU0:asr9k-1#show controllers fabric fia errors ingress location 0/3/CPU0
********** FIA-0 **********
Category: in_error-0
DDR Rx CRC-0 0
DDR Rx CRC-1 32616455 <=== Errors
RP/0/RSP1/CPU0:asr9k-1#show controllers fabric fia bridge stats location 0/0/CPU0
Ingress Drop Stats (MC & UC combined)
**************************************
PriorityPacket Error Threshold
Direction Drops Drops
--------------------------------------------------
LP NP-3 to Fabric 0 0
HP NP-3 to Fabric 1750 0
RP/0/RSP1/CPU0:asr9k-1#show controllers fabric fia bridge stats location 0/6/CPU0
********** FIA-0 **********
Category: bridge_in-0
UcH Fr Np-0 16867506
UcH Fr Np-1 115685
UcH Fr Np-2 104891
UcH Fr Np-3 105103
UcL Fr Np-0 1482833391
UcL Fr Np-1 31852547525
UcL Fr Np-2 3038838776
UcL Fr Np-3 30863851758
McH Fr Np-0 194999
McH Fr Np-1 793098
McH Fr Np-2 345046
McH Fr Np-3 453957
McL Fr Np-0 27567869
McL Fr Np-1 12613863
McL Fr Np-2 663139
McL Fr Np-3 21276923
Hp ErrFrNp-0 0
Hp ErrFrNp-1 0
Hp ErrFrNp-2 0
Hp ErrFrNp-3 0
Lp ErrFrNp-0 0
Lp ErrFrNp-1 0
Lp ErrFrNp-2 0
Lp ErrFrNp-3 0
Hp ThrFrNp-0 0
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 4.3.3.BASE |
|
Known Fixed Releases: | 4.3.2.SP5, 4.3.2.SP6, 4.3.2.SP7, 4.3.2.SP8, 4.3.4.SP3, 4.3.4.SP4, 4.3.4.SP5, 4.3.4.SP6, 4.3.4.SP7, 4.3.4.SP8 |
|
|
| |
| |
Bug Id: | CSCuo91149 |
Title: | MPLS packet via BVI interface may cause NP reset on Enhanced Ethernet LC |
|
Description: | Symptoms:
A vulnerability in the parsing of crafted MPLS packets in Cisco IOS XR Software for ASR 9000 Series Aggregation Services Routers could allow an
unauthenticated, adjacent attacker to cause a lockup and eventual reload of a Network Processor (NP) chip and a line card processing traffic.
The vulnerability is due to insufficient logic in parsing MPLS packets. An attacker could exploit this vulnerability by sending a stream of crafted MPLS
packets to be routed by a BVI interface on the affected device. An exploit could allow the attacker to cause a lockup and eventual reload of an NP chip
and a line card, leading to a denial of service (DoS) condition.
Conditions:
Only Typhoon-based line cards on Cisco ASR 9000 Series Aggregation Services Routers are affected by this vulnerability.
L3 output interface is a bridged virtual interface (BVI)
L2 output interface (access circuit of the bridge domain) is on a Typhoon line card.
In the MPLS VPN scenario: routers are not exposed if the MPLS label allocation is per VRF. Per-VRF allocation is the only supported model with BVI,
i.e. MPLS VPN customers are exposed only if they run an unsupported configuration. Restriction is documented on CCO.
In the MPLS VPN scenario: routers are exposed if labels are allocated for prefixes learned via BVI. MPLS LDP does not need to be enabled on BVI.
Workaround:
In MPLS VPN: configure the per-VRF label allocation.
In MPLS without VPN: disable label allocation for prefixes learned via BVI. This should not cause an issue because MPLS without VPN is not a
common deployment scenario.
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
5.7/4.7:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:A/AC:M/Au:N/C:N/I:N/A:C/E:F/RL:OF/RC:C
CVE ID CVE-2014-3321 has been assigned to document this issue.
Additional details about the vulnerability described here can be found at:
http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2014-3321
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 4.3.4.MPLS |
|
Known Fixed Releases: | 4.3.2.SP4, 4.3.2.SP5, 4.3.2.SP6, 4.3.2.SP7, 4.3.2.SP8, 4.3.4.SP3, 4.3.4.SP4, 4.3.4.SP5, 4.3.4.SP6, 4.3.4.SP7 |
|
|
| |
| |
Bug Id: | CSCur80525 |
Title: | DHCPD crashed because of memory corruption |
|
Description: | Symptom:
DHCPD crashed because of memory corruption
Conditions:
1. The client identifier option in packet from client carries client id of length greater than 200 and
2. "show dhcp ipv4 proxy binding" or "show tech dhcp ipv4 proxy" commands are used
Workaround:
Avoid using "show dhcp ipv4 proxy binding" or "show tech dhcp ipv4 proxy" commands
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 4.3.4.BASE |
|
Known Fixed Releases: | 4.3.4.SP6, 4.3.4.SP7, 4.3.4.SP8, 5.1.3.SP4, 5.2.3.99i.BASE, 5.2.4.11i.FWDG, 5.2.5.8i.FWDG, 5.3.1.10i.FWDG, 6.0.0.5i.FWDG |
|
|
| |
| |
Bug Id: | CSCur32156 |
Title: | IPv6 ACL modification is not taking effect in HW PI-PD out of sync |
|
Description: |
Symptom:ACL may not function as expected due to mis-programming of ACL in LC.
Conditions:in-line modification of the IPv6 scale ACL (with object-groups) may fail to get programmed correctly in hardware.
Workaround:Remove the ACL from all the interfaces and reapply it.
"show access-lists ipv6 usage pfilter location " shows list of interfaces where ACL is applied.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 4.3.4.BASE |
|
Known Fixed Releases: | 4.3.4.SP5, 4.3.4.SP6, 4.3.4.SP7, 4.3.4.SP8, 5.2.4.8i.FWDG, 5.2.5.4i.FWDG, 5.3.0.14i.FWDG |
|
|
| |
| |
Bug Id: | CSCur28806 |
Title: | ACL slow-path matching failed for host member in IPv4 obj-group |
|
Description: | Symptoms:
An issue in the Object-ACL matching process Cisco Aggregation Services Router 9000 (ASR9K) could allow an unauthenticated, remote attacker to
bypass protection offerred by a configured ACL on an affected device.
The issue is due to ASR9K incorrectly handling host access control entries by incorrectly matching ''any'' address instead of the specified
''host'' address. An attacker could exploit this vulnerability to bypass the access control list leading to traffic loss or unwanted permits.
Conditions:
ASR9K running affected software.
Workaround:
Manually replace ''host '' with ''ip/32''
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 5/4.1:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:P/I:N/A:N/E:F/RL:OF/RC:C
CVE ID CVE-2015-0694 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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 5.3.0.BASE |
|
Known Fixed Releases: | 4.3.4.SP5, 4.3.4.SP6, 4.3.4.SP7, 4.3.4.SP8, 5.2.3.13i.BASE, 5.2.4.1i.BASE, 5.3.0.14i.BASE |
|
|
| |
| |
Bug Id: | CSCul66510 |
Title: | Trident LC reset upon fatal Error OC_DF_INT_PROT_ERR_1 |
|
Description: | Symptom:
LC Reset caused by FIA Fatal error:
LC/0/3/CPU0:Nov 13 03:46:38.860 utc: pfm_node_lc[284]: %FABRIC-FIA-0-ASIC_FATAL_FAULT Set|fialc[159814]|Fabric Interface(0x1014000)|Fabric interface asic ASIC1 encountered fatal fault 0x1b - OC_DF_INT_PROT_ERR_0
Conditions:
Frequent flow-control from FIA to Bridge with Bursty traffic.
This is extremely rare scenario and following conditions should occur simultaneously.
a). Extremely bursty traffic from NP to bridge which can result in frequent assertion of flow-control from FIA to bridge.
b). Flow-control from egress LC to ingress LC which will also cause flow-control towards bridge
c). High priority traffic from ingress NP to bridge-fia
Workaround:
none
Further Problem Description:
The cause is not necessarily classified into a ?known? entity . We believe there are a number of factors that can come into play here, to expose such an issue. The network topology, traffic load/profile, which can lead to ingress traffic bursts toward fabric. Or it could also occur when the fabric is heavily congested.
The rule would be that if your customer has not experienced this issue, then their network topology and traffic profiles are likely well balanced. In this case I'd recommend that you stay your current course and not worry about this issue.
This SMU is listed as optional, as we do not expect ALL customers would experience this issue.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 4.2.3.BASE |
|
Known Fixed Releases: | 4.3.2.SP2, 4.3.2.SP3, 4.3.2.SP5, 4.3.2.SP6, 4.3.2.SP7, 4.3.2.SP8, 4.3.4.SP3, 4.3.4.SP4, 4.3.4.SP5, 4.3.4.SP6 |
|
|
| |
| |
Bug Id: | CSCun09478 |
Title: | ASR9K: sometimes egress extended uidb lookup fails |
|
Description: | Symptom:
Egress filtering doesn't work for few frames in the egress stream.
Conditions:
Egress traffic on L2 VPWS.
Workaround:
None.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 4.3.4.BASE |
|
Known Fixed Releases: | 4.3.4.SP3, 4.3.4.SP4, 4.3.4.SP5, 4.3.4.SP6, 4.3.4.SP7, 4.3.4.SP8, 5.1.2.20i.BASE, 5.1.3.1i.BASE, 5.2.0.22i.BASE |
|
|
| |
| |
Bug Id: | CSCuh48634 |
Title: | LPTS entry incorrectly programmed causing protocols not to receive data |
|
Description: | Symptom:
Protocols which have optimized entry in the LPTS might not receive the traffic.
Examples of protocols are PIM, IGMP, OSPF.
Conditions:
This is a timing issue and might happen after the changes on the device.
Workaround:
Restart the protocol impacted.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 4.3.4.BASE, 5.1.0.BASE |
|
Known Fixed Releases: | 4.3.4.SP5, 4.3.4.SP6, 4.3.4.SP7, 4.3.4.SP8, 5.1.0.15i.BASE |
|
|
| |
| |
Bug Id: | CSCus94707 |
Title: | XBAR_TIMEOUT_ERROR when LC is inserted with mcast on 9922 |
|
Description: | Symptom:
Linecard insertion may result in XBAR_TIMEOUT_ERROR on a different linecard
Conditions:
The DDTS is specific for ASR9922 running multicast traffic running any release beyond 4.2.1.
The trigger is an LC insertion with it also being a multicast receiver.
The LC insertion causes multicast traffic drop for existing receivers for 10 seconds.
Workaround:
None
Further Problem Description:
Sample PFM log raised by fabric/spine driver:
===========================
RP/0/RP0/CPU0:Feb 12 04:52:23.580 KST: pfm_node_rp[356]: %PLATFORM-CROSSBAR-1-XBAR_TIMEOUT_ERROR_LNK0 : Set|fab_xbar_sp0[208977]|Crossbar Switch(0x101702c)|XBAR_1_Slot_16
RP/0/RP0/CPU0:Feb 12 04:52:23.581 KST: pfm_node_rp[356]: %PLATFORM-CROSSBAR-1-XBAR_TIMEOUT_ERROR_LNK0 : Set|fab_xbar_sp0[208977]|Crossbar Switch(0x1017012)|XBAR_0_Slot_16
Sample PFM log raised by "Ingress" LC fabric driver:
===============================
LC/0/14/CPU0:Feb 12 04:52:26.674 KST: pfm_node_lc[287]: %PLATFORM-CROSSBAR-1-XBAR_TIMEOUT_ERROR_LNK0 : Set|fab_xbar[168016]|Crossbar Switch(0x1017002)|FIA_1
LC/0/14/CPU0:Feb 12 04:52:26.674 KST: pfm_node_lc[287]: %PLATFORM-CROSSBAR-1-XBAR_TIMEOUT_ERROR_LNK1 : Set|fab_xbar[168016]|Crossbar Switch(0x1017001)|FIA_1
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 4.3.4.BASE |
|
Known Fixed Releases: | 4.3.4.SP7, 4.3.4.SP8, 5.3.1.22i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCur16251 |
Title: | Umbrella SMU for PRM issues |
|
Description: | Symptom:
Umbrella SMU for PRM issues that can lead to TCAM issues or traffic issues.
Includes CSCup73846 and CSCuq90878.
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 4.3.4.LC |
|
Known Fixed Releases: | 4.3.4.SP5, 4.3.4.SP6, 4.3.4.SP7, 4.3.4.SP8, 5.2.3.99i.BASE |
|
|
| |
| |
Bug Id: | CSCuo22306 |
Title: | Umbrella DDTS for NP lockup fixes |
|
Description: | Symptom:
This is an umbrella DDTS for delivering following fixes through a single production SMU:
CSCun71928 NP lockup causes ASR9000 Ethernet Line Card restart
CSCun98617 Drop IPv6 packets with inconsistent payload length
CSCun92333 PRM SMU activation on ASR9000 Ethernet Line Cards causing reload
CSCuo00061 NP lockup on ASR9000 Ethernet Line Card
CSCun71685 False NP parity errors reported on ASR9000 Ethernet Line Cards
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 4.3.4.LC, 5.1.1.LC |
|
Known Fixed Releases: | 4.3.4.SP4, 4.3.4.SP5, 4.3.4.SP6, 4.3.4.SP7, 4.3.4.SP8, 5.1.1.SP2, 5.1.1.SP3, 5.1.1.SP4, 5.1.1.SP5, 5.1.1.SP6 |
|
|
| |
| |
Bug Id: | CSCum70202 |
Title: | Linecard should be rebooted after non-recoverable NP errors |
|
Description: | After hitting a double ECC error :%PLATFORM-NP-2-HW_DOUBLE_ECC_ERROR : linecard is not reloading as it should.
Symptom:
The linecard is not automatically reloaded after certain types of non-recoverable NP errors.
Here is an example of a double ECC error:
%PLATFORM-NP-2-HW_DOUBLE_ECC_ERROR : Set|prm_server_tr[151636]|Network Processor Init(0x1008001)|NP DOUBLE ECC ERROR, NP=1, memId=17, subMemId=0x1
Conditions:
Workaround:
Reload the linecard. If a similar non-recoverable error is reported again on that linecard, RMA the linecard.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 4.3.2.BASE, 4.3.4.BASE, 5.1.0.BASE, 5.1.1.BASE |
|
Known Fixed Releases: | 4.3.2.SP2, 4.3.2.SP3, 4.3.2.SP5, 4.3.2.SP6, 4.3.2.SP7, 4.3.2.SP8, 4.3.4.SP1, 4.3.4.SP4, 4.3.4.SP5, 4.3.4.SP6 |
|
|
| |
| |
Bug Id: | CSCur14058 |
Title: | DHCP Relay ARP issue after received OFFER from multiple servers |
|
Description: | Symptom:
ASR9K (4.3.4, 4.1.1, 4.1.2 ) is configured with "broadcast policy check flag" under dhcp relay profile.
More then one DHCP server is configured in the profile.
Under unknown circumstances (more likely high rate of DHCP DISCOVER messages) we could observe "stale ARP" 0000.0000.0000 entry in the arp table after receiving OFFER from DHCP server, while dhcp component gives out "ARP installed successfully" message.
Conditions:
Workaround:
restart DHCP service
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 4.3.4.BASE |
|
Known Fixed Releases: | 4.3.4.SP6, 4.3.4.SP7, 4.3.4.SP8, 5.2.3.99i.BASE, 5.2.4.11i.FWDG, 5.2.5.8i.FWDG, 5.3.0.14i.FWDG |
|
|
| |
| |
Bug Id: | CSCup67367 |
Title: | ipv4_io process crash due to mem-leak in ip_best_local_src_addr function |
|
Description: | Symptom:
Tail drop on XIPC in regular intervals followed by ipv4_io process crash
Conditions:
This is seen on ASR9K running 4.3.4 & 5.2.2
Workaround:
NONE
Further Problem Description:
A slow memory leak to the process causes the ipv4_io to restart after the process hits the max memory.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 5.2.2.BASE |
|
Known Fixed Releases: | 4.3.4.SP6, 4.3.4.SP7, 4.3.4.SP8, 5.2.2.17i.FWDG, 5.2.3.6i.FWDG, 5.3.0.1i.FWDG |
|
|
| |
| |
Bug Id: | CSCui83818 |
Title: | ISIS 64 bytes PSNP packets are counted as "Input drop other" |
|
Description: | Symptom:
ISIS 64 bytes PSNP packets are counted as "Input drop other", though they are not really dropped.
Conditions:
ISIS router with links configured as point-to-point.
Workaround:
This problem is merely cosmetic, the PSNP's are still processed just reported incorrect due to an accumulation discrepancy in the sw.
As this problem is seen on p2p links, you can also move to non p2p links for the ISIS adj to bypass this issue.
Further Problem Description:
Partial sequence number PDU (PSNP) is used to acknowledge receipt of an LSP on point-to-point links.
When a router receives a new LSP, it floods this LSP to its neighbors, except the neighbor that sent the new LSP. On point-to-point links, the neighbors acknowledge the new LSP with a PSNP, which holds the LSP ID, sequence number, checksum, and remaining lifetime. When the acknowledgment PSNP is received from a neighbor, the originating router stops sending the new LSP to that particular neighbor although it may continue to send the new LSP to other neighbors that have not yet acknowledged it.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 4.3.2.BASE, 5.1.0.BASE |
|
Known Fixed Releases: | 5.1.0.23i.BASE |
|
|
| |
| |
Bug Id: | CSCui28202 |
Title: | pvrst don't converge after sh/noshut of bundle w/trident typhoon members |
|
Description: | Symptom:
L2 protocol frames are dropped if STP state is blocked if injected from a bundle interface on RSP3.
Conditions:
Bundle interface on RSP3.
Workaround:
None.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 5.1.0.BASE |
|
Known Fixed Releases: | 4.3.4.SP3, 4.3.4.SP4, 4.3.4.SP5, 4.3.4.SP6, 4.3.4.SP7, 4.3.4.SP8, 5.1.0.18i.BASE |
|
|
| |
| |
Bug Id: | CSCur88023 |
Title: | TXFP - Adaptive FEC control algorithm not working |
|
Description: | Symptom:
MOD cards have a high preFEC error rate and the FEC control threshold is reporting the default 50%.
Conditions:
Workaround:
Assuming Line card# 1, we need to restart the VIC process.
Bay# 0
process restart vic_0 location 0/1/cpu0
Bay# 1
process restart vic_1 location 0/1/cpu0
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 4.3.4.BASE, 5.3.0.BASE |
|
Known Fixed Releases: | 4.3.4.SP6, 4.3.4.SP7, 4.3.4.SP8, 5.2.3.99i.BASE, 5.2.4.11i.BASE, 5.2.5.8i.BASE, 5.3.0.18i.BASE |
|
|
| |
| |
Bug Id: | CSCuq98778 |
Title: | ASR9001 Bay 0 disabled after SMU install |
|
Description: | Symptom:
In 9001 or Typhoon based Line card, MPA in bay# 0 may go to power down state
when CSCup14308 SMU is activated with 4.3.4 image.
No other release is affected.
Conditions:
CSCup14308 SMU is activated with 4.3.4 image.
Workaround:
Please try the following work-around and it may fix the issue. Also, pls don't install CSCup14308 SMU if
DWDM-SFP10G-C Optics is not used. If the issue is not fixed with work-around, CSCuq98778 SMU is needed.
conf t
hw-module subslot 0/0/0 shutdown unpowered
commit
no hw-module subslot 0/0/0 shutdown unpowered
commit
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 4.3.4.ADMIN, 4.3.4.BASE |
|
Known Fixed Releases: | 4.3.4.SP5, 4.3.4.SP6, 4.3.4.SP7, 4.3.4.SP8, 5.2.3.99i.BASE |
|
|
| |
| |
Bug Id: | CSCum05521 |
Title: | Netio Deadlock due to Wdsysmon |
|
Description: | Symptom:
Netio gets into a deadlock condition as indicated by wdsysmon.
Conditions:
Netio indicates that it is in a deadlock and crashes.
Crashinfo and deadlock files will be generated.
Workaround:
No Workaround available
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 4.3.4.LC, 5.1.1.BASE |
|
Known Fixed Releases: | 4.3.4.SP7, 4.3.4.SP8, 5.1.3.1i.BASE, 5.2.0.16i.BASE |
|
|
| |
| |
Bug Id: | CSCuv04581 |
Title: | macsec_ea crash with 336 SA scale |
|
Description: | Symptom:
macsec_ea crash with 336 SA scale
Conditions:
macsec_ea crash after scaling to 336 SAs and doing a ping all interfaces.
All 336 sessions came up , but few were not pingable . And then macsec_ea crashed.
Workaround:
Nil
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu88326 |
Title: | ASR9k becomes unreachable via SSH/Telnet/Console |
|
Description: | Symptom:
ASR9k running 5.1.3 suddenly becomes unreachable via console or SSH
Conditions:
5.1.2 or 5.1.3 software
Use of static routes with IPSLA tracking
Workaround:
Perform a switchover to recover access
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 5.1.3.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuc53683 |
Title: | Intermittent prmserver, fialc crash on A9K-24X10GE-TR due to pcie access |
|
Description: | Symptom:
multiple process crashes on prmserverty, fab_xbar, fialc which resulted in reloading the 24*10GE linecard
Conditions:
Normal operation or linecard bootup
Workaround:
none
Further Problem Description:
none
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 07-JUL-2015 |
|
Known Affected Releases: | 4.2.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu82001 |
Title: | FLEXR: xr vm on RSP is not spawned after fpd upgr reload - sdr_mgr recvr |
|
Description: | Symptom:
xr vm on RSP is not spawned after fpd upgrade reload - sdr_mgr should have recovered from this error.
Conditions:
Executed "upgrade hw-module loc 0/RSP1 fpd IPU\ FPGA force" and "hw loc 0/RSP1 reload"
commands to do fpd upgrade on RSP.
Workaround:
Unknown
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 08-JUL-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCum46326 |
Title: | ASR9k IPv6 CEF broken for bundle subintf if local & remote |
|
Description: | Symptom:
Routing to a previously attached network via a IGP (OSPF is known to be broken), will fail due to CEF thinking the route is still attached:
Both of these subnets are directly connected to ASR9006-E, after interface bundle-E21.21 is shutdown, ASR9006-E should learn this route from a neighbor
Bundle-E20.20 -- FC00:0:0:20::/64
Bundle-E21.21 -- FC00:0:0:21::/64
RP/0/RSP0/CPU0:ASR9006-E#show route ipv6
[output omitted]
C fc00:0:0:20::/64 is directly connected,
01:06:47, Bundle-Ether20.20
L fc00:0:0:20::1/128 is directly connected,
01:06:47, Bundle-Ether20.20
C fc00:0:0:21::/64 is directly connected,
01:13:15, Bundle-Ether21.21
L fc00:0:0:21::1/128 is directly connected,
01:13:15, Bundle-Ether21.21
This is what the routing table looks like after Bundle-e21.21 is shutdown:
RP/0/RSP0/CPU0:ASR9006-E#show route ipv6
[output omitted]
C fc00:0:0:20::/64 is directly connected,
01:12:33, Bundle-Ether20.20
L fc00:0:0:20::1/128 is directly connected,
01:12:33, Bundle-Ether20.20
O fc00:0:0:21::/64 is directly connected,
00:03:47, Bundle-Ether20.20
The route is now learned from the neighbor over a different bundle; however, we cannot route to this subnet, as CEF reports the subnet is 'attached' and 'glean'.
RP/0/RSP0/CPU0:ASR9006-E#show cef ipv6 fc00:0:0:21::
fc00:0:0:21::/64, version 223, attached, glean adjacency, internal 0x4000081 (ptr 0x71cb9954) [1], 0x0 (0x7151bac0), 0x0 (0x0)
Updated Jan 8 18:04:11.523
Prefix Len 64, traffic index 0, precedence n/a, priority 2
via Bundle-Ether20.20, 4 dependencies, weight 0, class 0 [flags 0x8]
path-idx 0 [0x71036500 0x0]
glean adjacency
Conditions:
* IPv6
* Route was previously Connected and Local
Workaround:
Shut and no-shut the connected network.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 08-JUL-2015 |
|
Known Affected Releases: | 4.3.1.BASE, 5.1.0.BASE |
|
Known Fixed Releases: | 5.1.2.13i.ROUT, 5.2.0.14i.ROUT |
|
|
| |
| |
Bug Id: | CSCuu81162 |
Title: | intf not created and entired config was removed after RSP VM change |
|
Description: | Symptom:
intf not created and entired config was removed after RSP VM change
Conditions:
the trigger was RSP VM change on Calvados. Hit this issue twice after 5 tries
Workaround:
No
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 08-JUL-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCui98242 |
Title: | bgp crash on CLI "show bgp neighbor <> advertised-routes". |
|
Description: | Symptom:
BGP process restarts when the command "show bgp neighbor <> advertised-routes" is issued for an EBGP peer.
Conditions:
- "show bgp neighbor <> advertised-routes" command is issued for an EBGP peer.
- The last 'n' paths of the table have CONFED segments in the ASPATH
- The last 'n' paths of the table were advertised to the EBGP peer before, but is no longer allowed to be advertised, but the withdraws have not yet been sent.
- 'n' is large enough (typically around 1000)
Workaround:
Temporary workaround is not to use "show bgp neighbor <> advertised-routes" command for EBGP peer, especially right after changing the outbound policy for that peer.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 08-JUL-2015 |
|
Known Affected Releases: | 4.2.3.ROUT |
|
Known Fixed Releases: | 4.3.3.5i.ROUT, 4.3.31.1i.ROUT, 4.3.4.8i.ROUT, 5.1.1.9i.ROUT, 5.1.11.4i.ROUT, 5.1.2.1i.ROUT, 5.2.0.2i.ROUT |
|
|
| |
| |
Bug Id: | CSCut28851 |
Title: | netio crash on ISMs - ISMs stuck in IN-RESET |
|
Description: | Symptom:
netio might crash on ISM and the ISM might reload and get stuck in IN-RESET state
Conditions:
upgrade of XR image on an ISM router
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 09-JUL-2015 |
|
Known Affected Releases: | 5.2.4.BASE |
|
Known Fixed Releases: | 5.2.4.10i.BASE, 5.2.5.4i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCun48901 |
Title: | 2x100GE egress bundle not loadbalancing correctly on asr9k/typhoon |
|
Description: | Symptom:
When four 100GE interfaces from A9K-2x100GE-TR linecards are in a bundle, traffic output (egress) from this bundle is limited to ~56Gbps per bundle member. In reverse direction (bundle ingress, non-bunlde egress), the traffic rate does not have this limit.
Conditions:
Four 100GE interfaces from A9K-2x100GE linecard in a bundle interface, traffic ingress to non-bunlde interfaces and egress out of the 400Gbps bundle.
Workaround:
use odd number of bundle members.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 09-JUL-2015 |
|
Known Affected Releases: | 4.3.4.FWDG, 5.3.2.BASE |
|
Known Fixed Releases: | 4.3.2.SP8, 5.1.2.20i.BASE, 5.1.3.1i.BASE, 5.2.4.7i.BASE, 5.2.5.4i.BASE, 5.3.1.15i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCuu84164 |
Title: | SSTE: Observing mpls_ldp process crash with typhoon lc oir |
|
Description: |
Symptom:LDP crashed after IM server went down. IM server could go down due to IF mgr crash/restart.
Conditions:Issue impact XR 5.3.1 and 5.3.0 releases and only occurs if ipv6 interfaces are configured.
Workaround:None
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 09-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | 5.3.2.13i.MPLS |
|
|
| |
| |
Bug Id: | CSCuu74580 |
Title: | Geo 532-9I:seeing dual partial-up on SLAVE with RPFOs |
|
Description: | IPoE sessions are clearing after an RSP failover and all sessions must be re-established. This is due to missing data within the checkpoint database.
Symptom:RSP failover may trigger this issue.
Conditions:Workaround:None
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 09-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | 5.2.5.2i.FWDG, 5.3.2.14i.FWDG |
|
|
| |
| |
Bug Id: | CSCuu76322 |
Title: | %ROUTING-LDP-3-NSR_SYNC_PEER_OP_FAILED : Peer 0:0; operation='Peer |
|
Description: |
Symptom:LDP peer info fails to be synced to standby LDP process. The following log will come up repeatedly.
mpls_ldp[1053]: %ROUTING-LDP-3-NSR_SYNC_PEER_OP_FAILED : Peer 202.202.22.2:0; operation='Peer'; Failed to sync Peer, Peer already exists
Conditions:LDP NSR sync of peer fails after disabling and re-enabling of AFI. Impacts XR 5.3.0 and 5.3.1 releases.
Workaround:Restart standby LDP process
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 09-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | 5.3.2.13i.MPLS |
|
|
| |
| |
Bug Id: | CSCut87732 |
Title: | BGP process crash on SW ver 5.1.3 |
|
Description: | Symptom:
%ROUTING-BGP-5-LOWMEM_SHUTDOWN : BGP is shutting down due to Critical low memory condition - use 'process restart bgp location ' to restart
Conditions:
BGP memory consumption reaching maximum and is shutting down.
This is a combination of memory fragmenation and leaks.
Appears to be seen specifically with frequent RPL reconfigurations and large RPL sizes
Workaround:
No specific exists
Further Problem Description:
RPL has compiled instances in BGP, identified leaks in RPL and other memory optimizations that are provided in an RPL umbrella smu.
Sysdb memory handling for BGP contributes to this for which a specific sysdb smu is provided also.
Other improvements such as memory arena size changes seem to contribute to reducing the fragmentation.
This ddts is junked per BGP because the issue is caused by external to BGP factors which are addressed in those areas specifically primarily.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 09-JUL-2015 |
|
Known Affected Releases: | 5.1.3.ROUT |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCun75289 |
Title: | RP2 EDVT@NT -intermittently 40Gig ports down/flapping with RP2 failover |
|
Description: | Symptom:
Intermittently Havok 40Gig interfaces are down on RP2 failover.
Conditions:
RP2 Failover, Glitch in Clock
Workaround:
EP reload
Further Problem Description:
When there is a clock failure
1)on NE,interface went down on NE due to tx_aligned error on PHY(NE).
2)on NE,PQ60 injected local fault on NP(NE)by powering down the lane.
This was done intentionally to bringup both the ends at the same time.
3)on NE,NP transmitted RFI to FE.
4)FE went down due to RFI.
5)Since RFI is considered as fault for bringing down the link on PHY (LASI),
on FE as well,PHY injected local fault to NP(FE) and transmitted RFI to other end.
after this step,both ends have RFI,HW_LINK,LASI on both ends.
6)When glitch is cleared,tx_aligned error is gone but RFI stayed on both ends,as RFI is still in LASI list
PHY would not power on the LANE at all.
Fix description:
=================
Don't consider RFI in the LASI alarm list .
Currently there are several faults considered for declaring LASI (PCS LOCK error,PCS block errors,tx_aligned)
and Silab recalibration is done when these faults gets cleared.
Silab recalibration would not be required for just RFI fault alone.
After fix:
Since RFI is not considered for LASI declartion,here would be sequence
When there is a clock failure
1)on NE,interface went down on NE due to tx_aligned error on PHY(NE).
2)on NE,PQ60 injected local fault on NP(NE)by powering down the lane.
This was done intentionally to bringup both the ends at the same time.
3)on NE,NP transmitted RFI to FE.
4)FE went down due to RFI.
after this step,NE woudl have RFI,HW_LINK,LASI and FE would have RFI.
4)(a)if we consider glitch on this port as well,then both ends would have RFI,HW_LINK,LASI.
6)When glitch is cleared,tx_aligned error would be gone.
means LASI is cleared.since RFI is not considered in LASI list,phy would power on the lane
and local would get cleared on NE.
7)NE NP would stop transmitting RFI after local fault is cleared.
8)FE would get RFI cleared and the ports would be up.
sjc-lds-906:/tftpboot/smunagap >
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 09-JUL-2015 |
|
Known Affected Releases: | 5.2.0.BASE |
|
Known Fixed Releases: | 5.2.0.20i.BASE |
|
|
| |
| |
Bug Id: | CSCut42484 |
Title: | After Rpfo seeing high CPU 25% for ipv6_nd while bringing up v4 sess |
|
Description: | BNG IPoEv4 sessions sessions not being established after RSP failover. Symptom:RSP Failover, after which high CPU at around 25% is seen for ipv6_nd when trying to re-establish the BNG v4 session.
Conditions:RSP failover may trigger this condition.
Workaround:None.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 09-JUL-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: | 5.2.5.14i.FWDG, 5.3.1.28i.FWDG, 5.3.2.6i.FWDG, 6.0.0.5i.FWDG |
|
|
| |
| |
Bug Id: | CSCun76643 |
Title: | mac entries on juggernaut LC aged out before age timer expires |
|
Description: | Symptom:
MAC addresses learned on 2x100GE line card were aged out prematurely. In stead of the 300 seconds of the default timeout value, the MAC entries on these 100GE ports are being removed within 60 seconds, causing the known unicast traffic to flood the bridge domain.
Conditions:
MAC addresses were learned on 2x100GE line cards.
Workaround:
Use other type of typhoon line cards.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 10-JUL-2015 |
|
Known Affected Releases: | 4.3.4.BASE, 5.1.1.BASE, 5.1.11.BASE, 5.1.2.BASE, 5.2.0.BASE, 5.3.0.BASE |
|
Known Fixed Releases: | 4.3.4.SP7, 4.3.4.SP8, 5.1.2.20i.BASE, 5.1.3.1i.BASE, 5.2.0.18i.BASE |
|
|
| |
| |
Bug Id: | CSCum81741 |
Title: | Failed to activate 12th VM on Forge, crash in host os |
|
Description: | Symptom:
Not able to activate 12th VM due to crash in host os on Forge
Conditions:
Activate 11 VMs and then try to activate the 12th VM on Forge
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 10-JUL-2015 |
|
Known Affected Releases: | 5.2.0.BASE |
|
Known Fixed Releases: | 6.0.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCur31362 |
Title: | iedge process is crashing due to req_id leak. |
|
Description: | Symptom:
iedge process is crashing due to req_id leak.
Conditions:
This has been see in 5.1.3.
Issue is reproduced locally with broadcast accounting, and not seen with out the same.
Workaround:
wokraround:
disable broadcast accounting.
configuration with broadcast flag:
aaa accounting service default group QPS-Acct group CAR
aaa accounting subscriber default group QPS-Acct group CAR
after disabling broadcast accounting configuration will be:
aaa accounting service default group QPS-Acct group CAR
aaa accounting subscriber default group QPS-Acct group CAR
Further Problem Description:
CU can see on a daily basis 2-3 crashes of iedge process due to req_id leak.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 10-JUL-2015 |
|
Known Affected Releases: | 5.1.3.BASE |
|
Known Fixed Releases: | 5.1.3.SP2, 5.1.3.SP3, 5.1.3.SP4, 5.2.3.99i.BASE, 5.3.0.15i.BASE |
|
|
| |
| |
Bug Id: | CSCuv19972 |
Title: | Pseudowire Headend <fib_mgr> Tracebacks |
|
Description: | Symptom:
Traceback messages from the FIB manager are printed indicating that FIB got an error back from the platform while trying to program in.
The tracebacks are generated post commitment of the L2VPN PWHE configuration. The issue is observed after the 8th PWHE Interface is introduced on the DUT (each PWHE interface has two associated sub-interface). The VC comes up but traffic flow in the transmit direction fails.
Each PWHE Service Consist of:
1 pw-ether main interface
1 pw-ether interface L3 sub-interface/L2VPN PW <- Tracebacks are produced
1 pw-ether interface L2 sub-interface for VPLS service
Conditions:
5.1.3/RSP440/MOD-80SE/10Gig MPA
Workaround:
none
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 10-JUL-2015 |
|
Known Affected Releases: | 5.1.3.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus26923 |
Title: | traffic from SIP700 to 9000v is dropped when a link to 9000v flaps |
|
Description: | Symptom:
Traffic is not forwarded from core facing SIP card if HSRP flaps from Active to Standby and back to Active.
Conditions:
All below conditions must be met to hit the problem
Core facing card is SIP700
HSRP is configured on the ASR9k with the SIP
9000v satellite connected to the ASR9k
Bundle-ethernet is used to connect 9000v to ASR9k
Workaround:
shut/no shut bundle-member links towards the satellite. The shutting can be done on any of the Ten Gig interfaces bundled to the satellite.
or configure
bundle load-balancing localize threshold links
or
move from bundle to physical interfaces configuration between the 9000v and asr9k
or
Remove the link from l2vpn config and readd it again
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 10-JUL-2015 |
|
Known Affected Releases: | 5.1.3.ROUT |
|
Known Fixed Releases: | 4.3.4.SP7, 4.3.4.SP8, 5.1.3.SP3, 5.1.3.SP4, 5.2.4.5i.BASE, 5.3.0.BASE |
|
|
| |
| |
Bug Id: | CSCuq89377 |
Title: | Envmo in iron man crash when configuring satellite interface |
|
Description: | Symptom:envmon_lc crash loop which causes LC reload loop. The 5.1.3 SMU for this DDTS also include fix for CSCur13869.
Conditions:different, known are:
-satellite interface config
OR
-tengig interface Tx pwr change
Workaround:no workaround
More Info:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 12-JUL-2015 |
|
Known Affected Releases: | 5.3.0.BASE |
|
Known Fixed Releases: | 5.2.2.SP1, 5.2.3.99i.BASE, 5.2.4.4i.BASE, 5.3.0.8i.BASE |
|
|
| |
| |
Bug Id: | CSCuh77742 |
Title: | ASR9001 kernel crash |
|
Description: | Symptom:
On ASR9001 kernel might crash with following info in the crash file: 'Exception at 0x4bf33104 signal 11 c=1 f=11'
Conditions:
This problem will only apply to platforms using the powerPC booke based processors with the p4080, p4040, p2020 CPU, like in ASR9001 router.
It does not apply to MPC 8641D, MIPS and X86e processors, like in the other ASR9k platforms.
Crash might happen during normal operation, no specific trigger is needed.
Note: Though this is mentioned as applicable to RSP2 only, this bug has integrated fix for CSCui69927 apart from other fixes, hence it fully supersedes that on 4.2.1-px.
Workaround:
None.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 12-JUL-2015 |
|
Known Affected Releases: | 4.2.1.BASE, 4.2.3.FWDG, 4.3.1.BASE, 4.3.2.BASE |
|
Known Fixed Releases: | 4.3.2.27i.BASE, 4.3.2.99i.BASE, 5.0.1.99i.BASE, 5.1.0.15i.BASE |
|
|
| |
| |
Bug Id: | CSCuv08171 |
Title: | FLEXR: LC stuck in SW_INACTIVE after insertion - X12 image |
|
Description: | Symptom:
A9K-8X100GE-L-SE linecard stuck in OPERATIONAL / SW_INACTIVE state after insertion.
Conditions:
Swapped a prototype A9K-8X100GE-L-SE linecard on a 9904 chassis with a production A9K-8X100GE-L-SE linecard from a 9010 chassis . Both linecards are loaded with same 6.0.0.x12 image and both are in OPERATIONAL / OPERATIONAL state before swapping.
Workaround:
Unknown.
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus12754 |
Title: | DUI - Temperature Threshold too low reporting massive CR alarms on 9000v |
|
Description: | Symptom:
Chassis temperature appears to be higher than it actually is. Fan runs at high RPM because of this. Also, high temperature threshold alarms are raised though actual chassis temperature is within limits.
Conditions:
No specific conditions. Happens during normal operation. Temperature alarms are raised even at nominal ambient temperature.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 4.3(4), 5.1(1), 5.1(2), 5.3(0) |
|
Known Fixed Releases: | 15.1(3)SVH04 |
|
|
| |
| |
Bug Id: | CSCuu53372 |
Title: | Umbrella SMU for CSCug92264 and CSCut69575 |
|
Description: | Symptom:
Umbrella SMU for CSCug92264 and CSCut69575
Conditions:
pbr_ea process crash on session churn with PBR redirect policy applied on sessions
Workaround:
no workaround availabe
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 4.3.2.BASE |
|
Known Fixed Releases: | 4.3.4.SP8 |
|
|
| |
| |
Bug Id: | CSCup10546 |
Title: | ASR9001 4.3.1 to 5.1.2 Failed Upgrade: Reaching max respawn |
|
Description: | Symptom:
ASR9001 Migration from 4.3.1 to 5.1.2 may not be successfull. A crash file will be generation with a message simaler to this:
0x6560d55ea] Record Reboot History, reboot cause = 0x2c000007, descr = Cause: INIT: respawn 'instsetup' disabled, exit_code 256, INIT_MAX_SPAWN reached Process: init Traceback: 4b0bf35c 4[0x656eb2db8] Record crashinfo
Conditions:
ASR9001 4.3.1/PIE/SMU's -> 5.1.2 PIE's no SMU's
Workaround:
Will provide a 431 SMU which is recommended for single-RP ASR9001 systems as there looks like a disk latency causing a stat failure.
After activating this SMU 512 packages shall be added and activated.
If this SMU is not present on the system then, Turboboot to recover.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 5.1.2.BASE |
|
Known Fixed Releases: | 4.3.4.SP8, 5.1.2.SP3, 5.1.2.SP4, 5.1.3.21i.BASE, 5.1.4.5i.BASE, 5.2.2.23i.BASE, 5.2.3.8i.BASE, 5.3.0.8i.BASE |
|
|
| |
| |
Bug Id: | CSCut60174 |
Title: | Service Update is not updated to LC subscribers |
|
Description: | Symptom:
CoA Service update does not reflects on LC subscribers
Conditions:
Service update via CoA is updating RP service profile however which is not populated to LC and it would affect LC subscriber sessions. Restarting of subdb_svr on LC would help to recover this problem.
Workaround:
Restart of subdb_svr on LC
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | 5.3.2.8i.FWDG, 6.0.0.5i.FWDG |
|
|
| |
| |
Bug Id: | CSCut68088 |
Title: | vic receiving all 0's mac-addr from can bus-server after router reload |
|
Description: | Symptom:
10GE interfaces not initialized after router reload.
Conditions:
After router reload TenGE interfaces were not initialized on an 24x10GE LC. This is due to the failure to assign mac-address to the interfaces.
Workaround:
LC/Router reload
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 5.2.4.BASE |
|
Known Fixed Releases: | 5.2.4.14i.BASE, 5.2.5.8i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCur00674 |
Title: | BNG: Service Accounting Radius Message reports high counter value |
|
Description: | Symptom:
The Cisco ASR9k series routers may report high accounting information for the subscriber.
Example:
Acct-Input-Octets [42] 6 1354107856
RP/0/RSP0/CPU0:Sep 24 22:28:50.831 : radiusd[1108]: RADIUS: Acct-Input-Giga-Words[52] 6 1354107868
RP/0/RSP0/CPU0:Sep 24 22:28:50.831 : radiusd[1108]: RADIUS: Acct-Input-Packets [47] 6 1354107880
RP/0/RSP0/CPU0:Sep 24 22:28:50.831 : radiusd[1108]: RADIUS: Acct-Output-Octets [43] 6 1363273508
RP/0/RSP0/CPU0:Sep 24 22:28:50.831 : radiusd[1108]: RADIUS: Acct-Output-Giga-Words[53] 6 1354107904
RP/0/RSP0/CPU0:Sep 24 22:28:50.831 : radiusd[1108]: RADIUS: Nas-Identifier [32] 16 ACDC-ASR9000-1
Conditions:
This behaviour was encountered with IOS-XR 5.1.3 when the subscriber is moved from one service to another.
Workaround:
None known.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 5.1.3.BASE |
|
Known Fixed Releases: | 4.3.4.SP8, 5.2.3.12i.BASE, 5.2.4.1i.BASE, 5.3.0.12i.BASE |
|
|
| |
| |
Bug Id: | CSCuv25610 |
Title: | service-node configs not programmed on NP1 |
|
Description: | Symptom:
service-node configs might not get programmed on NP1 of 9001
Conditions:
service-node configurations on 9001
Workaround:
none
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu29883 |
Title: | Zero Counters in BNG RADIUS Accounting |
|
Description: | Symptom:
Problem with BNG RADIUS Accounting. The record shows Zero counters for traffic.
Acct-Input-Octets = 0
Acct-Input-Packets = 0
Acct-Output-Octets = 0
Acct-Output-Packets = 0
Conditions:
While using COA to throttle/un-throttle the traffic rate using service-policies configured on the router. We keep changing the service-policies from one to another using COA
Workaround:
Reset modem
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 5.1.3.LC |
|
Known Fixed Releases: | 5.3.2.11i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCup22228 |
Title: | ASR 9001 kernel crash on 4.3.2 |
|
Description: | Symptom:
ASR 9001 kernel crash on 4.3.2
Conditions:
Normal working conditions
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 4.2.3.BASE, 4.3.2.BASE |
|
Known Fixed Releases: | 4.3.4.SP8, 5.1.3.14i.BASE, 5.2.2.15i.BASE, 5.2.3.1i.BASE, 5.3.0.1i.BASE |
|
|
| |
| |
Bug Id: | CSCuu13626 |
Title: | ASR9K / XR5.1.3 - ICMP fragmentation required generated in wrong VRF |
|
Description: |
Symptom:
ICMP unreachable responses generated by the router do not reach back to the sender of the traffic in some cases.
They may take the wrong vrf when injected from the router.
Conditions:
The destination for the traffic is not directly connected, but is reachable through an IGP next hop.
Workaround:
No workaround as such.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 5.1.3.BASE |
|
Known Fixed Releases: | 5.3.2.10i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCuv23858 |
Title: | vic_1 process dumpe core on Typhoon LC. |
|
Description: | Symptom:
The symptom of the issue is process vic_1 dumping core on the MOB-80 Line card while node reload.
Conditions:
The issue is observed when i reloaded the node.
Workaround:
None
Further Problem Description:
None
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 13-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu65150 |
Title: | Tmhwk : cable pull-out and reconnect causes unrecoverable traffic loss |
|
Description: | Symptom:
All packets received are stuck in the NP receive patch, specifically in the interface's ingress FIFO queue. No drop counters are incremented.
Conditions:
This problem can only occur if a packet with a size that exactly matches the configured interface MTU is received at the same time that the fiber connection is disconnected and then reconnected.
This problem is specific to 40g and 100g interfaces on Tomahawk linecards. If the failure occurs on a 100g interface, it will only impact traffic on that specific interface. If the failure occurs on a 40g (breakout) interface, it will impact both 40g interfaces sharing the same CPAK breakout cable.
Workaround:
Admin shut an interface before disconnecting the fiber.
Further Problem Description:
Recovery:
LC reload
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv18644 |
Title: | FLEXR: install activate failed - Failed to prepare logical volume for VM |
|
Description: | Symptom:
install activate operation failed due to "Failed to prepare logical volume for new VM".
Conditions:
Add X12 / EFR-00000306594 full image using "install add" command. Then execute
"install activate" command to activate the X12 image.
Workaround:
Unknown.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv20982 |
Title: | sits process crash seen on Satellite Setup |
|
Description: | Symptom:
sits process crash seen on Satellite Setup
Conditions:
Triggers : Add/ Remove Bundle ICL, RPFO , Crash is even seen silently without any triggers . Looks like a case of memory leak too.
Workaround:
None
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv07237 |
Title: | bfd_agent Crash seen with the 4.3.1 release |
|
Description: | Symptom:
bfd_agent crash is seen
Conditions:
activation/deactivation of smu - CSCul42259 with some scripts shutting/no shutting of interface
Workaround:
No known workaround
Further Problem Description:
The problem could be due to some unusual memory utilization in some corner cases
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 4.3.1.BASE, 4.3.1.K9SEC, 4.3.1.MCAST, 4.3.1.MGBL, 4.3.1.MPLS |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv23137 |
Title: | FLEXR: prm_main hogs 100% LC CPU after loading image on router |
|
Description: | Symptom:
prm_main hogs 100% LC CPU
Conditions:
Load 6.0.0.x12 / EFR-00000306594 image on a 9904 router with 2 RSPs and 1 A9K-8X100GE-L-SE linecard using reimage_chassis command.
Workaround:
Unknown.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCud73764 |
Title: | ASR9000 SIP-700 Multiple processes blocked on cpp_driver0 process |
|
Description: | Symptom:
Multiple processes blocked on the cpp_driverX process.
Conditions:
This may happen on a ASR9000 with a SIP-7000 linecard.
Workaround:
Reload the linecard:
hw-module location a/b/CPU0 reload
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 4.2.0.BASE, 4.2.1.LC |
|
Known Fixed Releases: | 4.3.1.16i.BASE, 5.1.0.2i.BASE |
|
|
| |
| |
Bug Id: | CSCus39199 |
Title: | TSH: DDR CRC error recovery |
|
Description: | Symptom:
The ingress traffic coming into the card would have around one and half seconds loss once the error recovery is triggered because of detection of ASIC DDR crc error.
PFM on CRC error would be raised.
The interfaces associated with the problem slice would be shut down if the error recovery has been run more than 5 times in a day.
Conditions:
ASIC is having DDR crc problem.
Workaround:
None.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 14-JUL-2015 |
|
Known Affected Releases: | 5.3.0.BASE |
|
Known Fixed Releases: | 5.3.1.18i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCut50729 |
Title: | BGP process stuck on CondVar |
|
Description: | Symptom:
The following type of errors may be displayed on an ASR9000:
%SYSDB-SYSDB-6-TIMEOUT_EDM : EDM request for 'oper/ip-bgp/gl/instance/default/act/shared/vrf/default/nbr/' from 'bgp_show' (jid 65880, node 0/RSP0/CPU0). No response from 'bgp' (jid 1049, node 0/RSP0/CPU0) within the timeout period (100 seconds)
causing BGP commands to not return any output
Conditions:
None
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 15-JUL-2015 |
|
Known Affected Releases: | 4.3.4.BASE |
|
Known Fixed Releases: | 5.3.2.5i.ROUT, 6.0.0.5i.ROUT |
|
|
| |
| |
Bug Id: | CSCut88999 |
Title: | FRR is failing to converge within 0.05s after shutting down remote int |
|
Description: | Symptom:
Traffic convergence will take more than the epxected 0.05 seconds.
Conditions:
After configuring per link LFA and shutting down the remote LS
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 15-JUL-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: | 5.3.2.15i.BASE |
|
|
| |
| |
Bug Id: | CSCuu86434 |
Title: | Memory threshold crossed: ipv4_rib hit 9G on standby RSP after LC OIR |
|
Description: | Symptom:
ipv4_rib hit 9G on standby RSP after LC OIR. Then Memory threshold crossed.
Conditions:
LC OIR with 10M ipv4 routes. 80% reproducible
Workaround:
proc restart ipv4_rib
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 15-JUL-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu81866 |
Title: | SysDB Umbrella SMU - Scale RPL |
|
Description: | Symptom:
sysdb_mc process will crash and might result in system getting hang for few minutes, but it will self recover and the system will become stable after few minutes
Conditions:
This crash is seen when we try to load a big ACL config(~ 300K lines)
Workaround:
This crash is not seen for smaller config (~150K lines)
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 15-JUL-2015 |
|
Known Affected Releases: | 5.1.3.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu21495 |
Title: | repeated fib_mgr crash on A9K-MOD80-SE |
|
Description: | Symptom:
fib_mgr process crash on line card
Conditions:
Exact trigger is not known at this stage
Workaround:
none
Further Problem Description:
none
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 15-JUL-2015 |
|
Known Affected Releases: | 5.1.3.MPLS |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur16326 |
Title: | Managment Int VRF config, domain_services request for core dump |
|
Description: | Symptom:
core dump of domain_services, aka DNS server
Conditions:
configuring VRF under management interfaces.
Workaround:
none
Further Problem Description:
This issue is not dependent on having vrf config under mgmt interface.
Can occur without this configured. Can occur with no user intervention.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 15-JUL-2015 |
|
Known Affected Releases: | 5.3.0.BASE |
|
Known Fixed Releases: | 5.2.4.4i.BASE, 5.2.4.4i.FWDG, 5.3.1.17i.BASE, 6.0.0.5i.BASE, 6.0.0.5i.FWDG |
|
|
| |
| |
Bug Id: | CSCur91208 |
Title: | [CI-530] #29 BFD flaps during RSP FO results in traffic drop |
|
Description: | Symptom:
IPv4 BFD single-hop session flaps during RSP fail-over. Flap is seen once, out of approximately 30 RSP fail-over attempts.
Conditions:
Seen on ASR9K, when peer is Traffic generator.
Workaround:
None.
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 15-JUL-2015 |
|
Known Affected Releases: | 5.3.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo31977 |
Title: | CPP Driver LOCKDOWN & LC reload with control word deletion on remote PE |
|
Description: |
Symptom:SIP-700 CPP lockdown and continuous LC reload
Conditions:With MPLS Netflow applied on tail end PE core link, when Control word configuration is removed from tail and head end PE.
Workaround:LC reload stps after enable control word or remove the netflow configuration from the tail end PE.
More Info:Problem seen only with ethernet attachment circuit and onky with Netflow enabled
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 15-JUL-2015 |
|
Known Affected Releases: | 5.2.2.FWDG |
|
Known Fixed Releases: | 5.1.3.16i.BASE, 5.1.3.18i.BASE, 5.2.2.11i.BASE, 5.3.0.1i.BASE |
|
|
| |
| |
Bug Id: | CSCur97784 |
Title: | RSP3 switchover causes 100Gige octane interface to flap |
|
Description: | Symptom:
Interface flaps/Packet Drops on FortyGig / Hundred Gig interface on ASR 9000 when RSP failover is performed with frequency synchronization configured. No flaps/drops seen without frequency synchronization configuration.
Conditions:
Frequency synchronization is configured and system clock is recovered from a linecard interface. The syncE input to the ASR9K could be any interface (i.e even GigE/TenGigE). Flaps/drops are observed on FortyGigE/HundredGigE interfaces on the system.
Workaround:
None ( except removing frequency synchronization configuration globally).
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 15-JUL-2015 |
|
Known Affected Releases: | 5.3.0.BASE |
|
Known Fixed Releases: | 5.3.0.19i.BASE |
|
|
| |
| |
Bug Id: | CSCuu35990 |
Title: | IPoE Subscribers are not abel to get IP addreses |
|
Description: | Symptom:
IPOE subscribers are not getting IP addresses.
dhcpd/proxy_errors 1/RSP0/CPU0 t7 TP3647: FSM call returned error for chaddr_string: xxxx.xxxx.xxxx, msg_type:5, mode: 4, event: 2
dhcpd/proxy_errors 1/RSP0/CPU0 t7 TP1665: Proxy process client request packet failed for chaddr xxxx.xxxx.xxxx
dhcpd/proxy_internals 1/RSP0/CPU0 t7 TP1955: FSM called for chaddr xxxx.xxxx.xxxx with event DPM_DISCONNECT state ACK_DPM_WAIT <===
dhcpd/proxy_internals 1/RSP0/CPU0 t7 TP1915: NAK client request called for chaddr???
dhcpd/proxy_internals 1/RSP0/CPU0 t7 TP1918: Process server reply called for chaddr xxxx.xxxx.xxxx
dhcpd/proxy_internals 1/RSP0/CPU0 t7 TP1917: Process client request called for chaddr xxxx.xxxx.xxxx
dhcpd/proxy_internals 1/RSP0/CPU0 t7 TP2805: Client delete called for chaddr xxxx.xxxx.xxxx due to reason Session disconnect from Iedge
dhcpd/proxy_internals 1/RSP0/CPU0 t7 TP1955: FSM called for chaddr xxxx.xxxx.xxxx with event PACKET_DROP state ACK_DPM_WAIT <====
dhcpd/proxy_internals 1/RSP0/CPU0 t7 TP2607: DPM disconnect requesting state successfully sent NAK for chaddr xxxx.xxxx.xxxx <==== NAK is send to the DHCP client.
show dhcp ipv4 proxy statistics raw all | begin PROXY ERROR
....
request_inject_fail : 1912 <====
show dhcp ipv4 proxy statistics raw all | begin PROXY ERROR
....
request_inject_fail : 2789 <====
Conditions:
N/A
Workaround:
Reload the box.
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 15-JUL-2015 |
|
Known Affected Releases: | 5.2.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCun78145 |
Title: | mlpp member links are not added proper for 35 ML Bundles |
|
Description: | Symptom:
mlpp member links are not properly added
Conditions:
adding mlpp member links 1 to 9 to each bundle
Workaround:
NONE
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 4.3.3.BASE, 5.2.0.BASE |
|
Known Fixed Releases: | 5.1.2.SP3, 5.1.2.SP4, 5.1.3.8i.FWDG, 5.2.0.25i.FWDG |
|
|
| |
| |
Bug Id: | CSCul66806 |
Title: | NP4c fast reset ; TM lockup, search lockup , RFD problems |
|
Description: | Symptom:
NP packet buffer leak happens when there is a large burst of MACs learning along with high rate traffic. Customer traffic drop can happen due to buffer leakage. As the leakage getting worse, packet forwarding on the NP can be so slow that internal heartbeat message cannot be handled in a given period of time. Thus NP is declared in lockup state.
Conditions:
High of egress learning along with high rate of NP processing occurring,
related to high rate of ingress/egress traffic into the NP.
Workaround:
None.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 4.2.1.BASE |
|
Known Fixed Releases: | 4.3.2.SP5, 4.3.2.SP6, 4.3.2.SP7, 4.3.2.SP8, 4.3.4.SP4, 4.3.4.SP5, 4.3.4.SP6, 4.3.4.SP7, 4.3.4.SP8, 5.1.1.18i.BASE |
|
|
| |
| |
Bug Id: | CSCut57910 |
Title: | MLACP standby bundle ipv4 cap in IM chain stuck in up status. |
|
Description: | Symptom:
for standby status bundle interface in MLACP setup, the ipv4 cap may stuck in up status, which cause this standby interface shown in routing table.
Conditions:
it was found after ifmgr process restart.
Workaround:
shut/no-shut this standby bundle interface.
Further Problem Description:
n/a
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 4.3.4.BASE |
|
Known Fixed Releases: | 4.3.4.SP8, 5.3.2.4i.FWDG, 6.0.0.5i.FWDG |
|
|
| |
| |
Bug Id: | CSCur25073 |
Title: | asr9k-530-bnb3 #29 After RSP FO-Clr conf inconsis fails with CfgMgr lock |
|
Description: | Symptom:
Deadlock of Cfgmgr lock.
After RPFO, "show configuration lock" shows config lock that will not be cleared indefinitely
Conditions:
RPFO.
Workaround:
Reload the Standby Card
Further Problem Description:
Please check CA-TAC-Notes attachment for more details
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 5.3.0.BASE |
|
Known Fixed Releases: | 5.2.3.12i.BASE, 5.2.4.1i.BASE, 5.2.4.6i.BASE, 5.3.0.14i.BASE |
|
|
| |
| |
Bug Id: | CSCuu28673 |
Title: | 5.3.1.29I: Too many PWGROUP updates being sent by l2vpn to SIP700 |
|
Description: | Symptom:
Too many PWGROUP updateds are sent by l2vpn PI to SIP700 LC.
Conditions:
With l2vpn scale (bridge domain & xconnect scale) of 32k xconnects. Issue can be seen when flapping core interfaces on remote PE.
Workaround:
No known workaround.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 5.3.1.BASE, 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv16443 |
Title: | Delayed recovery time for the secondary chassis after reboot |
|
Description: | Symptom:
++ Problem Details
Customer setup
Software = 4.3.2
HW = ASR9010 / RSP440
I notice that the primary RSP in the standby rack in the cluster has encountered some MBI hello problems:
show reboot history location 1/RSP0/CPU0
54 Wed Apr 8 05:50:55 2015 0x04000018 Cause: MBI-HELLO HEADLESS RSP HB Timed
out
Process: mbi-hello
Traceback: 8213d7a 8214101 82140
db 42026d9 822605f 82242b2
The standby RSP in the standby rack has lots of watch dog timeouts:
show reboot history location 1/RSP1/CPU0
47 Wed Apr 8 05:29:50 2015 0x2c000010 Cause: Missed deadline, client: dsc, t
imeout: 15
Process: wd-critical-mon
Traceback: 8213d7a 8214101 82140
db 42006fd 4201567 4201d75
Conditions:
The standby RSP in the standby rack rebooted due to the interchassis link issue
Workaround:
NA
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 4.3.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv25605 |
Title: | APM issue : LC relaod results in rxBadFcsFrames for forty gig ports |
|
Description: | Symptom:
APM issue : LC relaod results in rxBadFcsFrames for forty gig ports
Conditions:
LC reload recreated the issue and I am seeing more number of packets in rx as well all are accounted as rxBadFcsFrames in MAC block in PHY.
Workaround:
Nil
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu65277 |
Title: | Loss of management access to an ASR9000 |
|
Description: | Symptom:
At some point, all management connectivity to an ASR9000 is lost (console and aux on primary RSP, telnet, SSH) while the control plane protocols and forwarding is still working.
Conditions:
Workaround:
Active RSP OIR
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 16-JUL-2015 |
|
Known Affected Releases: | 4.3.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv25907 |
Title: | FLEXR: ports on LC go dwon after shelfmgr/env proxy restart testing |
|
Description: | Symptom:
Ports on linecard go down.
Conditions:
Do proc restart for shelf_mgr and envmon_proxy for multiple times.
Workaround:
Unknown.
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu79611 |
Title: | ASR9001 Repeated secondary process crashes with heap corruption |
|
Description: | Symptom:
Secondary processes, possibly for a feature not even configured, will crash though the core file will exhibit stack or heap corruption and erroneous memory addresses
Conditions:
ASR9001 under normal operation
Workaround:
none, processes recover on their own
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 4.3.4.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur44662 |
Title: | Modify the approach of calling nsr_initiate_fo from the signal handler |
|
Description: | Symptom:
BGP signal handler calling nsr_initiate_fo - analysis of the core file from CSCur11134 describes how this led to the eventual deadlock between threads 8 and 26.
Conditions:
Avoid having to call nsr_initiate_fo from a signal handler
Workaround:
None
Further Problem Description:
From: Stephen Cobb (sfc)
Sent: Thursday, October 16, 2014 11:23 PM
To: Ashish Rastogi (ashisras); Tamas Mondal (tmondal); Sunder Gabbita -X (sungabbi - GLOW NETWORKS INC at Cisco); Srinivas Reddy Patlolla Reddy -X (patreddy - INFOSYS LIMITED at Cisco); Vishal Gupta (vishagu2); Gerald Quinn -X (gerquinn - COMPUCOM SYSTEMS INC at Cisco)
Cc: Arunkumar Prabhakaran (arunprab); xr-ind-os-dev(mailer list); Santosh Sharma (santsha2); q-bgp-dev(mailer list); Shankar Satyanarayanan (ssatyana); Aravind Srinivasan (aravinds)
Subject: Re: BGP coredump on ASR9k running 5.1.2 - [CC265] - CSCur11134
There are 3 separate issues identified, so to effectively track them, there should be 3 ddts'.
1) The as-yet not investigated initial cause of the crash - this appears to have been triggered by a SEGV in free(), by thread 8, I think at frame 26. I have guessed that this would be due to heap corruption.
2) BGP signal handler calling nsr_initiate_fo - my analysis of the core file below describes how this led to the eventual deadlock between threads 8 and 26.
3) reload signal handler calling ctime - this is a clear bug in that handler that should be fixed.
Thanks//Steve
From: "Ashish Rastogi (ashisras)"
Date: Wednesday, October 15, 2014 1:10 PM
To: "Tamas Mondal (tmondal)" , sfc , "Sunder Gabbita -X (sungabbi - GLOW NETWORKS INC at Cisco)" , "Srinivas Reddy Patlolla Reddy -X (patreddy - INFOSYS LIMITED at Cisco)" , "Vishal Gupta (vishagu2)" , "Gerald Quinn -X (gerquinn - COMPUCOM SYSTEMS INC at Cisco)"
Cc: "Arunkumar Prabhakaran (arunprab)" , "xr-ind-os-dev(mailer list)" , "Santosh Sharma (santsha2)" , "q-bgp-dev(mailer list)" , "Shankar Satyanarayanan (ssatyana)"
Subject: Re: BGP coredump on ASR9k running 5.1.2 - [CC265] - CSCur11134
Team,
Can you please suggest the next steps, who should own this DDTS CSCur11134.
???
Regards,
Ashish Rastogi
CCIE # 43795
NCE, AS GSP Amer AT&T
ashisras@cisco.com
Mobile: +1 972 989 0421
Desk: +1 732 635 3733
From: "Tamas Mondal (tmondal)"
Date: Tuesday, October 14, 2014 at 7:39 PM
To: "Stephen Cobb (sfc)" , "Sunder Gabbita -X (sungabbi - GLOW NETWORKS INC at Cisco)" , "Srinivas Reddy Patlolla Reddy -X (patreddy - INFOSYS LIMITED at Cisco)" , "Vishal Gupta (vishagu2)" , "Gerald Quinn -X (gerquinn - COMPUCOM SYSTEMS INC at Cisco)"
Cc: Ashish Rastogi , "Arunkumar Prabhakaran (arunprab)" , "xr-ind-os-dev(mailer list)" , "Santosh Sharma (santsha2)" , "q-bgp-dev(mailer list)"
Subject: RE: BGP coredump on ASR9k running 5.1.2 - [CC265] - CSCur11134
Steve,
We get it. What all
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 5.1.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu58858 |
Title: | fpd upgrade fails and node runs golden version |
|
Description: | Symptom:
fpd upgrade fails
Conditions:
asr9k router running 532 interim imgae
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | 5.3.2.11i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCuv17266 |
Title: | [600]-Licmgr process continuously crashes & restarts on RP0 Node |
|
Description: | Symptom:
Licmgr process continuously crashing & restarts on RP0 Node
Conditions:
In 600.5I Image, could see Licmgr process continuously crashing & restarts on RP0 Node after load the image.
Workaround:
NA
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuh23970 |
Title: | Interface <Deleted> for show ethernet cfm ccm VPLS/VPLS-PW VFI int |
|
Description: | Symptom:
Interface show as for show ethernet cfm ccm-learning-database output.
Conditions:
Release: 4.3.1 and higher (4.3.x), 5.1.0
Configure VPLS/VPWS PW for ethernet cfm feature
Workaround:
No workaround available.
Upgrade to 5.1.1 or higher release.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 5.1.0.BASE |
|
Known Fixed Releases: | 5.1.1.1i.BASE, 5.2.0.1i.BASE |
|
|
| |
| |
Bug Id: | CSCuv17023 |
Title: | Upgrade to 6.0 fails as sysmgr dumps Kernel core due to syncctrl process |
|
Description: | Symptom:
Upgrade to 6.0 from 532 fails consistently due to syncctrl process.
Conditions:
This is sbeing observed with upgrade process.
Workaround:
None
Further Problem Description:
stopper.
|
|
Status: | Open |
|
Severity: | 1 Catastrophic |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCul38379 |
Title: | After k9sec pie act/deact tacacs does not use "update-source" |
|
Description: | Symptom:
tacacsd generates packets with source address as the physical interface address rather than the interface specified with "tacacs source-interface [int id] ".
TACACS authentication is unsuccessful when "Client Verification" is enabled on TACACS server.
This is seen after k9sec (crypto pie) activation or deactivation
Conditions:
This behavior is seen with router reloads and after upgrades in the client network.
This is reproducible with the below in the lab environment.
#install deactivate disk0:asr9k-k9sec-px-4.3.2
#install activate disk0:asr9k-k9sec-px-4.3.2
Workaround:
process restart tacacsd
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 4.3.2.BASE |
|
Known Fixed Releases: | 5.1.3.11i.BASE, 5.2.0.25i.BASE |
|
|
| |
| |
Bug Id: | CSCui25519 |
Title: | ASR9K 4.2.1 RIB incorrect routes selection when multiple instances exist |
|
Description: | Symptom:When multiple clients/protocols add the same route, RIB is expected to select the route with the lowest path metric if the admin distances are equal. The implementation of metric selection does not always work on x86 intel (little endian) cpu architectures.
An example scenario would be multiple ISIS instances adding the same route.
Conditions:When the migration involves x86 based RP (A9K-RSP440).
Workaround:To be discussed.
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 4.2.1.BASE, 4.2.1.ROUT |
|
Known Fixed Releases: | 4.3.2.28i.BASE, 5.0.0.35i.BASE, 5.1.0.BASE, 5.1.1.15i.BASE |
|
|
| |
| |
Bug Id: | CSCul42259 |
Title: | XR520:BFD packets getting dropped at NPU in Asr9k for FLEX LSP/MPLS-TP |
|
Description: | Symptom:
BFD session for LSP on tp-tunnel flap continuously
RP/0/RSP0/CPU0:May 1 23:59:30.553 GMT: ifmgr[247]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface tunnel-tp25, changed state to Up
\
LC/0/4/CPU0:May 1 23:59:31.852 GMT: bfd_agent[123]: %L2-BFD-6-SESSION_STATE_DOWN : BFD session for LSP with in-label 40 on interface tunnel-tp25 has gone down. Reason: Nbor signalled down
\
RP/0/RSP0/CPU0:May 1 23:59:31.853 GMT: ifmgr[247]: %PKT_INFRA-LINK-3-UPDOWN : Interface tunnel-tp25, changed state to Down
\
RP/0/RSP0/CPU0:May 1 23:59:31.853 GMT: ifmgr[247]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface tunnel-tp25, changed state to Down }
Conditions:
issues to provision new PW circuits and pinging them.
mpls forwarding with bytes switched set to 0
mpls static labels not seen on the LCs but it is on the RSP.
CEF entries not seen on the LCs but it is on the RSP.
all the LC's show the CEF resources are in Yello state.
Workaround:
reload all LC in the node
remove flapping tp-tunnels
Further Problem Description:
tp-tunnel flapping lead to CEF resource running low and into Yellow state. this prevents any "add" to the node and only "delete"
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 5.2.0.MPLS |
|
Known Fixed Releases: | 5.1.1.16i.BASE, 5.1.2.9i.BASE, 5.2.0.10i.BASE |
|
|
| |
| |
Bug Id: | CSCuv02529 |
Title: | fib_mgr crash and router reboot once PPPoE session cleared on CE |
|
Description: | Symptom:
fib_mgr crash and router reboot
Conditions:
BNG, "clear pppoe all" on the CE
Workaround:
N/A
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 5.1.2.BASE, 5.2.2.BASE, 5.2.4.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv36905 |
Title: | ROUTING-FIB-2-OOR : FIB run out of DATA_TYPE_TABLE_SET resource memory |
|
Description: | Symptom:
OOR FIB run out of DATA_TYPE_TABLE_SET resource memory
Conditions:
LC reloads
Workaround:
none
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCup90910 |
Title: | PRM server crash after hundreds of executions of the show drops command |
|
Description: | Symptom:
The process prm_server_tr or prm_server_ty unexpectedly restarts on
a line card after an excessive number of executions of the command
'show drops location <>' specifying the location of that line card.
Conditions:
The 'show drops location <>' command is executed more than 400
times for a given location.
Workaround:
The process recovers after the unexpected restart. The issue can be
avoided by limiting the execution of the 'show drops location <>' command.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUL-2015 |
|
Known Affected Releases: | 5.1.1.BASE |
|
Known Fixed Releases: | 5.1.3.18i.BASE, 5.2.2.20i.BASE, 5.2.3.8i.BASE, 5.3.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCuv38577 |
Title: | Continuous process crash of bundlemgr_local |
|
Description: | Symptom:
Continuous process crash of bundlemgr_local
Conditions:
RPFO
Workaround:
Router Reload
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 18-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv32201 |
Title: | ASR 9K configuration loss after reload |
|
Description: | Symptom:
partial configuration loss
Conditions:
n/a
Workaround:
none.
Further Problem Description:
Following statements were missing from the 9010-2 after it came back INS.
ipv6 access-list IPV6-SSM-LTE
10 permit ipv6 any ff38::f030:0/116
route-policy MLDP-INBAND
set core-tree mldp-inband
end-policy
!
vrf LTE
address-family ipv6
rpf topology route-policy MLDP-INBAND
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 20-JUL-2015 |
|
Known Affected Releases: | 5.1.3.ROUT |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus79246 |
Title: | NP-DIAG ICFD failure due to NP's search engine lockups |
|
Description: | Symptom:
NP resets with datalog suggesting search lockup.
Conditions:
Exact condition unknown.
Workaround:
None.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-JUL-2015 |
|
Known Affected Releases: | 4.3.4.LC |
|
Known Fixed Releases: | 4.3.4.SP7, 4.3.4.SP8, 5.2.4.8i.BASE, 5.2.5.4i.BASE, 5.3.1.20i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCuv19375 |
Title: | Traffic loss when doing RPFO |
|
Description: | Symptom:
Traffic carried in a TE tunnel may experience packet loss
Conditions:
This problem is observed when doing an Route Processor Failover
Workaround:
None
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 20-JUL-2015 |
|
Known Affected Releases: | 5.1.3.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu81906 |
Title: | WANPHY BER SD/SF is not working - Build 532 10i |
|
Description: | Symptom:
Discrepency in the behaviour of WANPHY SD/SF - Build 532 10i
Conditions:
configured wanphy sd-ber to 8 and wanphy sf-ber to 4 on a Tomakawk Octane LC[with SR10 optics]. I have BIP B2 error from JDSU with a rate 1e-9. In ideal situation none of the alarms should appear as this is a out of boundary condition but I am observing both sf_ber and sd_ber errors on router.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | 5.3.2.17i.BASE |
|
|
| |
| |
Bug Id: | CSCuv37122 |
Title: | BGP process crash at atomic_sub_value |
|
Description: | Symptom:
The bgp process may crash
Conditions:
This problem may occur on performing configuration changes such as vrf deletion or creation
Workaround:
None
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 20-JUL-2015 |
|
Known Affected Releases: | 5.1.3.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut98928 |
Title: | Tomawhawk: traffic drop seen at 100% line rate for certain packet sizes |
|
Description: | Symptom:
Early fast discard packet drops experienced in the ICU (portion that ?pre-parses? incoming packets and schedules them for service through the pipeline) during high packet per second load near maximum forwarding performance.
Conditions:
In typhoon Early Fast Discard was implemented as part of the pipeline processing, hence running as part of the microcode. One of the enhancements of the Tomahawk forwarding architecture is a ?pre-parse? stage that implements the the Early Fast Discard functionality outside of the hardware forwarding pipeline stages.
A software fix is to be provided to optimize the ICU packet handling in these circumstances whereby EFD is required.
Monitoring of the condition is not easy when the drops are occurring that identify the packet loss.
A separate new show command is to be developed along with the fix for this problem so that it is easier to monitor from an operational perspective.
Workaround:
No realistic workaround exists.
Further Problem Description:
The buffers used in the ICU component are 'particalized'.
It is analogus to ATM cells, a certain payload may require an extra cell, but only a small portion of that cell is actually used.
this creates extra overhead (unused space) and in this case it takes a particle/buffer spot away that could be used for another packet.
This is experienced in a lower performance, or higher drop count because lesser buffers are available at that high pps rate with that
particular packet size.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 20-JUL-2015 |
|
Known Affected Releases: | 5.3.1.BASE, 5.3.2.BASE |
|
Known Fixed Releases: | 5.3.2.15i.BASE, 6.0.0.6i.BASE |
|
|
| |
| |
Bug Id: | CSCue19326 |
Title: | PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED seen on Trident/RSP2 |
|
Description: | Symptom:
Diags error seen on Trident NP line cards:
PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED
This issue is not seen on Typhoon NP line cards.
Conditions:
There are 2 cases that can cause this type of failure:
1) VPLS flood reflection filtering on the egress NP with bidirectional traffic.
2) IPV6 header errors on the ingress NP due to length check violation.
Workaround:
None.
Further Problem Description:
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 3.3/2.6:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:A/AC:L/Au:N/C:N/I:N/A:P/E:POC/RL:OF/RC:C
No CVE ID has been assigned to 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
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 20-JUL-2015 |
|
Known Affected Releases: | 4.2.3.BASE, 4.3.0.BASE |
|
Known Fixed Releases: | 4.3.1.27i.BASE, 4.3.2.11i.BASE, 5.1.0.3i.BASE |
|
|
| |
| |
Bug Id: | CSCuu72532 |
Title: | standby RP cannot be ready due to bgp BGP NSR sessions not synchronized |
|
Description: | Symptom:
standby RP cannot be ready. It stuck at "bgp BGP NSR sessions not synchronized : inst_name=default, inst_id=0"
Conditions:
It can be hit by router reload and RP FO
Workaround:
No
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCud54598 |
Title: | Problem relate to "show interface location 0/x/cpu0" display: Port5 |
|
Description: | Problem:
'packets input' count in 'sh interface Giga <>' is 0 for port# 5.
Other 1GE ports are not affected.
The issue is seen in A9K-40GE and A9K-2T20GE Line cards.
Symptom:
'packets input' count in 'sh interface Giga <>' is 0 for port# 5.
Workaround:
There is no impact on functionality or traffic. But billing applications might
suffer from the fact that there is no accurate traffic info.
There is no workaround.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 4.3.0.BASE |
|
Known Fixed Releases: | 4.3.1.21i.BASE, 4.3.2.5i.BASE, 5.1.0.3i.BASE |
|
|
| |
| |
Bug Id: | CSCuv40170 |
Title: | [533]-Ipv4 BFD Sessions are not coming Up on Satellite Sub-Intf with Vrf |
|
Description: | Symptom:
Ipv4 BFD Sessions are not coming Up on Satellite Sub-Intf with Vrf
Conditions:
Could see Ipv4 BFD Sessions are not coming Up on Satellite Sub-Intf with Vrf. Issue is not able to reproduce manually, But it seems to be reproducible with sequential triggers with BFD which almost takes 2 hours. And the workaround seems to be a reload after which the BFD came up fine.
Workaround:
After LC(Bfd multipath LC) Reload BFD Sessions came up fine.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE, 5.3.3.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuh39942 |
Title: | RSP3 confreg ignore break does not work |
|
Description: | Symptom:
A Kernel crash is observed when the console receives a Break signal.
Conditions:
In RSP3, even when ignore break is set (bit 0x100 is set), a kernel core is generated when a Break signal is received.
Workaround:
N/A
More Info:
N/A
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 4.2.1.BASE, 4.2.3.BASE |
|
Known Fixed Releases: | 5.1.2.99i.BASE |
|
|
| |
| |
Bug Id: | CSCut21331 |
Title: | Umbrella SMU for 5.1.3 NP4c PRM and NP driver fixes |
|
Description: | Symptom:
This is umbrella SMU for number of NP issues seen in the field
Conditions:
Single bit ECC errors
Workaround:
No workaround
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 5.1.3.BASE |
|
Known Fixed Releases: | 5.1.3.SP4 |
|
|
| |
| |
Bug Id: | CSCun16919 |
Title: | SSTE: Observing locald blocked on radiusd when testing radius client |
|
Description: |
Symptom:Users will not be able to log into the router if the router is stuck with locald blocked on radiusd/tacacs.
- Locald in blocked state.
- radius/tacacs will not be in locked state.
(if any of radius/tacacs is also in blocked state its is issue with radius/tacacsd)
Conditions:external AAA authentication/authorization/accounting is configured on box using radius/tacacs.
Workaround:
- Restart of locald.
- or restart radiusd/tacacsd (on which locald is blocked to release lwm connection)
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 5.2.0.BASE |
|
Known Fixed Releases: | 5.2.0.15i.BASE |
|
|
| |
| |
Bug Id: | CSCuv29022 |
Title: | ti-lfa is not working when backup is bundle. |
|
Description: | Symptom:
Ti-LFA will not provide a backup path for certain prefixes when using SR with either OSPF or ISIS
Conditions:
When the candidate backup path is a bundle and the backup is via a PQ joint or disjoint node which requires pushing of one or two extra labels.
Workaround:
none
Further Problem Description:
This is because of platform limitation on supporting and API which gives the number of labels that can be pushed for a given interface - this does not support virtual interfaces like bundles.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 5.2.2.ROUT |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus44737 |
Title: | MAC address deleted erroneously by remote NP during aging scan |
|
Description: | Symptom:
When MAC is learned on physical interface based bridge ports (L2 main/sub interfaces), it is seen that the learned MAC addresses are deleted before reaching full MAC age. The MAC being deleted is completely random. This results in random traffic flooding in bridge domain.
Conditions:
1. The problem is specific to Typhoon family of line cards. And
2. The MAC address must be learned on physical interface based bridge ports (L2 main/sub interfaces).
Workaround:
Use bundle L2 interface to replace physical interface.
Further Problem Description:
The problem is less likely to be observed when there are only a few hundreds of MAC learned on ASR9k. The flooding starts to appear when MAC scale goes beyond 50K.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 21-JUL-2015 |
|
Known Affected Releases: | 5.1.3.BASE, 5.2.0.BASE, 5.2.2.BASE |
|
Known Fixed Releases: | 5.1.3.SP3, 5.1.3.SP4, 5.2.4.1i.BASE |
|
|
| |
| |
Bug Id: | CSCur83427 |
Title: | BGP flapping after change route-policy to send FULL routes |
|
Description: | Symptom:
BGP sessions are getting flapped when peer is sending the notification that illegal network data is received
RP/0/RSP0/CPU0:Nov 20 22:45:01.060 : bgp[1041]: %ROUTING-BGP-5-ADJCHANGE : neighbor 10.154.98.253 Down - BGP Notification sent, illegal network (VRF: BPH71TT301) (AS: 65060)
Conditions:
When NSR is enabled and data received by the TCP is large
Workaround:
Disabling the NSR. Please note that disabling the NSR will cause the BGP sessions will flap when RPFO triggered.
Recovery:
None
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 5.2.3.ROUT, 5.3.0.BASE |
|
Known Fixed Releases: | 5.1.3.SP4, 5.2.4.7i.BASE, 5.2.5.4i.BASE, 5.3.1.20i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCug53320 |
Title: | MGID missprogramming after l2fib_mgr process crash |
|
Description: | Symptom:
MAC learning and IGMP snooping stop working after l2fib_mgr crash.
Conditions:
On Trident LC and Typhoon LC,
1. l2fib_mgr process is restarted due to fib_mgr crash, or
2. l2fib_mgr process crashed.
Workaround:
None
More Info:
Recovery: 1. Restart l2fib_mgr on the LC using "process restart l2fib_mgr location ", or 2. LC r eset.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 4.2.1.BASE, 4.2.2.BASE, 4.3.0.BASE, 4.3.1.BASE, 5.1.0.BASE |
|
Known Fixed Releases: | 4.3.2.16i.BASE, 5.1.0.9i.BASE |
|
|
| |
| |
Bug Id: | CSCuu70514 |
Title: | NRLDI Slow Leak Due to P2MP Route Churn |
|
Description: | Symptom:
Following syslog is seen:
ROUTING-FIB-2-OOR : CEF has run out of DATA_TYPE_TABLE_SET resource memory. No more route updates will be handled by CEF. Please delete routes, and then clear CEF on this node to resume normal operation.
NRLDI PRM credits show next to null free credits
RP/0/RSP0/CPU0:ASR9K#show cef platform oor location 1/0/CPU0
The "PD USAGE" column should not be relied upon
for accurate tracking of the PD resources.
This is due to Asynchronous nature of CEF programming
between PD and PRM.
OBJECT PD USAGE(MAX) PRM USAGE(MAX) PRM CREDITS
RPF_STRICT(0) 0(262144) 0(262144) 262144
IPv4_LEAF_P(1) 675(4194304) 676(4194304) 4193628
IPv6_LEAF_P(2) 29(2097152) 338(2097152) 2096814
LEAF(3) 1280(4194304) 1280(4194304) 4193024
TX_ADJ(4) 654(524288) 654(524288) 523634
NR_LDI(5) 2097151(2097152) 2097151(2097152) 1
TE_NH_ADJ(6) 8(65536) 6(65536) 65530
RX_ADJ(7) 33(131072) 31(131072) 131041
R_LDI(8) 670(131072) 670(131072) 130402
L2VPN_LDI(9) 3(32768) 3(32768) 32765
EXT_LSPA(10) 0(524288) 630(524288) 523658
IPv6_LL_LEAF_P(11) 0(262144) 0(262144) 262144
Conditions:
mLDP/mVPN
Any LC
Low route scale
Churn in P2MP routing table
Workaround:
Reload the LC
Further Problem Description:
No impact should be noticed unless p2mp routes are churning rapidly. Normal mLDP/mVPN should not have any impact for years.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 5.1.3.ROUT |
|
Known Fixed Releases: | 5.3.2.13i.BASE |
|
|
| |
| |
Bug Id: | CSCuv29422 |
Title: | ASR 5.2.4 HSRP standby sending wrong packet |
|
Description: | Symptom:
The message on active HSRP can be seen received from standby running 5.2.4
hsrp[1085]: %IP-STANDBY-4-WARN_TRAFFIC_SLAVE : HSRP control packet received from on MGO slave group: TenGigE0_0_2_0.201 group 201
Actually the hsrp standby slave group would send continuous refresh with the source hsrp vmac, causing continuous mac move in L2 switch network, breaking connectivity for hosts.
Conditions:
Router running 5.2.4 configured with HSRP slave group:
router hsrp
interface TenGigE0/0/2/0.2
hsrp bfd minimum-interval 100
hsrp bfd multiplier 8
hsrp delay minimum 5 reload 90
address-family ipv4
hsrp 2 version 2
name HSRP-Te0-2-1
preempt
priority 80
address 1.1.1.1
track TenGigE0/0/2/0.101 25
bfd fast-detect
!
!
!
interface TenGigE0/0/2/0.200
address-family ipv4
hsrp 200 slave
follow HSRP-Te0-2-1
address 2.2.2.2
Workaround:
none
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 5.2.4.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur07854 |
Title: | VPLS/VPWS/PWHE L2 traffic stops after PW neighbor reachability changes |
|
Description: | Symptom:
L2 traffic over VPLS, VPWS and PWHE may get dropped when using ASR9K for L2 forwarding.
A critical SMU for CSCur07854 is available and mandatory for anyone running L2VPN on ASR 9000 routers running IOS-XR release 5.1.3.
Conditions:
The issue is seen on ASR 9000 chassis (all flavors) with IOS-XR version 5.1.3
The line card through which the pseudo-wire (PW) neighbor is reachable is OIRed or the PW neighbor reachability metric changes.
The issue "may" also be observed when the chassis is initially upgraded to 5.1.3.
Workaround:
Possible methods for temporarily clearing the issue.
1.Unconfigure and Configure the MPLS LDP session on the interfaces through which the pseudo-wire (PW) neighbor is reachable.
2.Flap the interface through which the PW neighbor is reachable.
3.Add a static route to the PW neighbor pointing to the Nexthop using the Interface in the static route.
If the Neighbor is reachable via ECMP paths, add each Nexthop/Interface in the Static route.
Do this for each PW is affected.
Further Problem Description:
Use the following set of commands:
1.show cef
This command will give the list of interfaces through which the PW neighbor is reachable.
If the PW Neighbor is reachable recursively, the non-recursive neighbor reachability interface is to be noted.
2.show cef external location | begin "
Look for the "Added to pend list" timestamp.
The timestamp in #1 and #2 should match.
In case of VPLS:
3.show l2vpn forwarding bridge-domain hardware ingress detail location | inc Primary
show im database ifhandle | grep ifh
The output from #1 and #3 should match; else we expect to see the problem.
In case of VPWS:
4.show l2vpn forwarding neighbor pw-id hardware ingress detail location | incl Primary
show im database ifhandle | grep ifh
The output from #1 and #4 should match; else we expect to see the problem.
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 5.1.3.BASE, 5.3.0.BASE, 5.3.0.LC |
|
Known Fixed Releases: | 5.1.3.SP1, 5.1.3.SP2, 5.1.3.SP3, 5.1.3.SP4, 5.2.2.29i.FWDG, 5.2.3.12i.FWDG, 5.2.4.1i.FWDG, 5.3.0.10i.BASE, 5.3.0.10i.FWDG |
|
|
| |
| |
Bug Id: | CSCuu75739 |
Title: | UDP DHCP(dport 67,68) over PW dropped by ASR9K whenDHCP snoop disabled |
|
Description: | Symptom:
UDP DHCP packet dropped by ASR9K after crossing PW even when DHCP snoop was disabled(default).
Conditions:
L2 VPN(PW) should be configured between DHCP server and client.
And, L3 router located between DHCP client and ASR9K works as relay agent.
Refer to the topology.
Workaround:
enable DHCP snoop and trust PW interface on only ASR9K located in DHCP server side.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 22-JUL-2015 |
|
Known Affected Releases: | 4.3.1.LC, 4.3.4.LC |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut59790 |
Title: | [5.3.1-23I] iedged crashed upon receiving access-reject |
|
Description: | Symptom:
Iedge process on LC
Conditions:
"debug subscriber manager all" enabled and when access reject is received for service logon request.
Workaround:
Disable "debug subscriber manager all"
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: | 5.2.5.19i.BASE, 5.2.5.5i.BASE, 5.3.2.9i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCuv06893 |
Title: | [532]-Error while retrieving show Intf after GSP restart on RP1 |
|
Description: | Symptom:
Error while retrieving show Intf after GSP restart on RP1
Conditions:
In 532.13I Image, could see error seeing while retrieving "sh interfaces gig120/0/0/0" after restart GSP process on RP1 node. Issue is not see while doing on RP0 node.
Workaround:
NA
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE, 5.3.3.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur88273 |
Title: | LPTS entry for TCP port 646 is any any |
|
Description: | Symptoms:
A vulnerability in LPTS network stack of Cisco IOS XR for Cisco ASR9k could allow an unauthenticated, remote attacker to cause a limited denial of service (DoS)
condition on an affected platform.
The vulnerability is due to improper handling of flow base entries by LPTS that can cause some TCP and UDP ports to be erroneously opened for network access.
An attacker could exploit this vulnerability by sending continuous connection attempts to those open ports and cause exhaustion of services. An exploit could allow
the attacker to cause a limited denial of service (DoS) condition on an affected platform
Conditions:
List of open ports depends upon clients (of LPTS) which uses those port. Some example of such clients are LDP, SNMP, SSH and Telnet.
Even if the client (of LPTS) doesn't want to keep the port open anymore, LPTS will create an entry (called base flow entry) that will allow open ports on both TCP and
UDP sockets depending upon which transport is being used by client.
It is further possible for the attacker to open a connection to those open ports. The potential effect is to exhaust the available resources by connecting continuously
and taking into account there are only 5 VTY sessions available by default a router can quickly refuse new telnet/ssh sessions.
Workaround:
Possible workarounds include configuring IPv4 and IPv6 access lists that forbid connection attempts to those open ports on an affected platform.
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 5/4.1:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:N/I:N/A:P/E:F/RL:OF/RC:C
CVE ID CVE-2015-4285 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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 5.1.2.ROUT, 5.1.3.K9SEC, 5.1.3.MPLS, 5.2.1.CE, 5.2.2.BASE |
|
Known Fixed Releases: | 5.2.4.7i.BASE, 5.2.5.4i.BASE, 5.3.1.17i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCuv35166 |
Title: | ASR9K/BNG/5.3.1 iedge process block because of xml queries |
|
Description: | Symptom:
IPoE subscribers are not able to connect with BNG.
Conditions:
Initiate 25-30 XML sessions with BNG to get the subscriber information and state.
Workaround:
Disable the XML agent on ASR9K.
-- Example --
RP/0/RSP0/CPU0:acdc-asr9000-4(config)#no xml agent
RP/0/RSP0/CPU0:acdc-asr9000-4(config)#commit
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 5.1.3.BASE, 5.2.2.BASE, 5.3.1.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur33931 |
Title: | Missing ECD marking flag for the rec-leaf in the recursive PW fwd chain |
|
Description: | Symptom:Multicast traffic not passing through bridge-domain but unicast works fine after a BGP PIC cutover. Or shut one of the ECMP path.
Conditions:Traffic can be drop. From log analysis, it shows that the interface information does not get updated in the L3 to L2 notification data.
Workaround:Clearing routes restore the impacted traffic. It has been verified in the customer routers. ( in addition need to also use the fix in PI bug CSCur14272 for complete fix)
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 4.2.3.ROUT |
|
Known Fixed Releases: | 4.3.4.SP5, 4.3.4.SP6, 4.3.4.SP7, 4.3.4.SP8, 5.3.0.12i.FWDG |
|
|
| |
| |
Bug Id: | CSCuu00818 |
Title: | sysdb_shared_sc crash |
|
Description: | Symptom:
sysdb_shared_sc crash
Conditions:
after upgrade 5.1.3
Workaround:
n/a
Further Problem Description:
This issue happens multiple times. The trigger could be the way router's config is updated. They do commit replace everytime update the config.
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 5.1.3.BASE, 5.3.2.BASE |
|
Known Fixed Releases: | 5.3.2.12i.BASE |
|
|
| |
| |
Bug Id: | CSCuv34167 |
Title: | Wanphy SF-BER triggering on invalid range with link flapping on octane |
|
Description: | Symptom:
Wanphy SF-BER triggering on invalid range with link flapping on octane - 532 15.07.12C Nightly
Conditions:
Set the SF-BER as E-4 and SD-BER as E-8 on router port and start inserting B2 BIP errors from jdsu with a rate 1E-5.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur18489 |
Title: | ipv4_rib process crash on stby RSP |
|
Description: | Symptom:
Standby ipv4_rib/ipv6_rib process may crash during RIB updates.
Conditions:
- process only crashes on standby RSP
- most often the crash is seen during big updates which are present during configuration commits, link flaps etc.
Workaround:
There is no workaround.
Further Problem Description:
Standby RIB process would restart automatically and resync with active RSP.
Since crash is only seen on standby RSP there should be no traffic impact from this event.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 5.2.1.BASE, 5.3.0.BASE, 5.3.1.BASE |
|
Known Fixed Releases: | 5.2.4.6i.BASE, 5.3.1.17i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCur45126 |
Title: | Correctable ECC errs in NP instruction mem IDs 42,44,47,52 not repaired |
|
Description: | Symptom:
A single-bit ECC error in NP instruction memory was not repaired properly and thus continues to be detected and reported repeatedly. Here is an example:
LC/0/7/CPU0:Dec 1 01:54:23.793 MYT: prm_server_ty[303]: %PLATFORM-NP-3-ECC : prm_ser_check: Single-bit ECC error detected: NP 3, block 0x17 (MDF), offset 14, memid 47, name INSTRUCTION_MEM14, addr 0x0000003e, bit 16, ext info 0x00000007 0xffffffff 0xffffffff 0xffffffff, action 0 (Fix)
LC/0/7/CPU0:Dec 1 05:00:39.830 MYT: prm_server_ty[303]: %PLATFORM-NP-3-ECC : prm_ser_check: Single-bit ECC error detected: NP 3, block 0x17 (MDF), offset 10, memid 47, name INSTRUCTION_MEM10, addr 0x0000003e, bit 16, ext info 0x00000007 0xffffffff 0xffffffff 0xffffffff, action 0 (Fix)
LC/0/7/CPU0:Dec 1 07:45:28.777 MYT: prm_server_ty[303]: %PLATFORM-NP-3-ECC : prm_ser_check: Single-bit ECC error detected: NP 3, block 0x17 (MDF), offset 8, memid 47, name INSTRUCTION_MEM8, addr 0x0000003e, bit 16, ext info 0x00000007 0xffffffff 0xffffffff 0xffffffff, action 0 (Fix)
LC/0/7/CPU0:Dec 1 12:19:51.357 MYT: prm_server_ty[303]: %PLATFORM-NP-3-ECC : prm_ser_check: Single-bit ECC error detected: NP 3, block 0x17 (MDF), offset 10, memid 47, name INSTRUCTION_MEM10, addr 0x0000003e, bit 16, ext info 0x00000007 0xffffffff 0xffffffff 0xffffffff, action 0 (Fix)
There are no functional side effects, but the error will continue to be detected and reported over and over.
Conditions:
This problem is specific to Typhoon linecards and to the following NP blocks and memid's:
block 0x14 (RSV), memid 42
block 0x15 (RSV), memid 44
block 0x17 (MDF), memid 47
block 0x18 (MDF), memid 52
Any repeating error which has a different block or memid than the ones listed above is not covered by this fix.
Note that this fix only addresses the issue where the underlying bit error is not repaired properly. There is no specific trigger for the underlying error as it is a rare and random hardware occurrence.
Workaround:
Because there are no functional side effects, the repeating error in the logs can be safely ignored. If the logging is a concern, the linecard may be reloaded. If the same errors recur after reloading the linecard, RMA the linecard.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 4.3.2.BASE |
|
Known Fixed Releases: | 5.2.4.4i.BASE, 5.3.1.19i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCuv45725 |
Title: | Place holder for production SMU for CSCus50857 in smu_r51x_5_1_3.lu |
|
Description: | Symptom:
This ddts is raised to handle Production SMU for CSCus50857 (A9K-2x100GE link stay down due to PCS Lane Mapping invalid)
When linkdown occurs due to invalid "PCS Lane Mapping", sometimes link does not go up.
Conditions:
The issue is seen when port receives two wave length signals of upto 50 msec during optical layer switchover from active to backup path.
IOS XR 5.1.2, 5.2.2
Workaround:
triggers the path failover again
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 23-JUL-2015 |
|
Known Affected Releases: | 5.1.3.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus50857 |
Title: | A9K-2x100GE link stay down due to PCS Lane Mapping invalid |
|
Description: | Symptom:
When linkdown occurs due to invalid "PCS Lane Mapping", sometimes link does not go up.
Conditions:
The issue is seen when port receives two wave length signals of upto 50 msec during optical layer switchover from active to backup path.
IOS XR 5.1.2, 5.2.2
Workaround:
triggers the path failover again
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 4.3.4.LC, 5.1.2.LC, 5.2.2.LC |
|
Known Fixed Releases: | 5.2.4.11i.BASE, 5.2.5.8i.BASE, 5.3.1.24i.BASE, 5.3.2.3i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCuv42964 |
Title: | lda_server and vic crashes on fpgalib_hal_update_reg32 |
|
Description: | Symptom:
ASR9K line card experiences repeated crashes of the lda_server and vic processes. This makes the card unusable & results in loss of traffic on the LC.
Conditions:
5.3.1 software
Seen with an A9K-40GE-TR
Occurred during maintenance activity, which included reinstalling cables and sfps.
Workaround:
Reload the impacted line card.
Further Problem Description:
From the show logging output, see these messages repeatedly for both processes. Using lda_server as the example:
LC/0/3/CPU0:Jul 4 18:47:42.390 BST: dumper[56]: %OS-DUMPER-4-BUS_ADRERR : Signal code 2 - BUSADRERR. Trying to access non-existent physical address 4a4d2178 at PC 4a4d2178
LC/0/3/CPU0:Jul 4 18:47:42.390 BST: dumper[56]: %OS-DUMPER-4-CRASH_INFO : Crashed pid = 45088 (pkg/bin/lda_server)
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv15845 |
Title: | BGP prefix not being advertised after adding it to the RPL |
|
Description: | Symptom:
When adding a new prefix into the RPL, this prefix is not advertised to the neighbor until you remove and re-add the RPL in neighbor configuration. Even doing a "clear bgp soft out" this is not working, the prefix is not being advertised. For example, after adding prefix 2.2.2.0/19
RP/0/RSP0/CPU0:Jun 17 15:44:54.214 : bgp[1054]: [default-upd] destination: 2.2.2.0/19 >>>>>>> prefix being tested
RP/0/RSP0/CPU0:Jun 17 15:44:54.214 : bgp[1054]: [default-upd] local-preference: <>
RP/0/RSP0/CPU0:Jun 17 15:44:54.215 : bgp[1054]: [default-upd] Condition: destination in (1.1.1.0/16 eq 16 ...) >>>>>> not testing the new prefix
RP/0/RSP0/CPU0:Jun 17 15:44:54.215 : bgp[1054]: [default-upd] Condition evaluated to FALSE
RP/0/RSP0/CPU0:Jun 17 15:44:54.215 : bgp[1054]: [default-upd] End policy: result=DROP >>>>>>> prefix dropped
Conditions:
IOS XR running 5.1.3. The issue is not seen when you set a community to the RPL prefixes, but if you don't have any set in the RPL, the issue is seen.
RP/0/RSP0/CPU0:RR#sh run route-policy TESTE >>>>>>> route-policy to be used in debug
Wed Jun 17 15:43:05.373 BRT
route-policy TESTE
if destination in (2.2.2.0/19) then
pass
endif
end-policy
Workaround:
Remove and re-add the RPL in neighbor config:
Further Problem Description:
N/A
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 5.1.3.ROUT |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur48521 |
Title: | Device driver for device 'GAMBIT 1G EP FPGA' detected sequence error |
|
Description: | Symptom:
Customer see the following errors, and the interface goes down.
LC/0/0/CPU0:Oct 16 11:10:11.544 : pfm_node_lc[288]: %PLATFORM-FCA-2-SEQ_ERROR : Set|lda_server[40990]|EP Controller(0x1046040)|Device driver for device 'GAMBIT 1G EP FPGA' detected sequence error on 'GAMBIT I2C SILAB Bus'. Error status 0xfeedface. Error address 0xfeedface. Error data 0xfeedface.
LC/0/0/CPU0:Oct 16 11:10:11.581 : lda_server[65]: %L2-SPA-3-POWER_FAILURE : SPA_OK and PWR_OK signal is deasserted on subslot 1
LC/0/0/CPU0:Oct 16 11:10:11.581 : pfm_node_lc[288]: %PLATFORM-FCA-2-SEQ_ERROR : Clear|lda_server[40990]|EP Controller(0x1046040)|Device driver for device 'GAMBIT 1G EP FPGA' detected sequence error on 'GAMBIT I2C SILAB Bus'. Error status 0xfeedface. Error address 0xfeedface. Error data 0xfeedface.
RP/0/RSP0/CPU0:Oct 16 11:10:13.138 : shelfmgr[396]: %PLATFORM-SHELFMGR-6-NODE_STATE_CHANGE : 0/0/1 A9K-MPA-20X1GE state:IN-RESET
LC/0/0/CPU0:Oct 16 11:10:13.200 : lda_server[65]: %L2-SPA-5-OIR_ERROR : SPA (1): A SPA hardware or software error occurred, please contact technical support
RP/0/RSP0/CPU0:Oct 16 11:10:13.203 : invmgr[256]: %PLATFORM-INV-6-NODE_STATE_CHANGE : Node: 0/0/1, state: FAILED
RP/0/RSP0/CPU0:Oct 16 11:10:14.205 : invmgr[256]: %PLATFORM-INV-6-NODE_STATE_CHANGE : Node: 0/0/1, state: UNPOWERED
RP/0/RSP0/CPU0:Oct 16 11:10:17.260 : invmgr[256]: %PLATFORM-INV-6-NODE_STATE_CHANGE : Node: 0/0/1, state: DISABLED
RP/0/RSP0/CPU0:Oct 16 11:11:18.414 : tclsh[65756]: %HA_EM-2-LOG: sl_mpareset.tcl: !!! EEM MPA RESET STARTED - Waiting 20 seconds!!!
RP/0/RSP0/CPU0:Oct 16 11:11:38.416 : tclsh[65756]: %HA_EM-2-LOG: sl_mpareset.tcl: !!! EEM MPA RESET WAIT PERIOD COMPLETE !!!
Conditions:
ASR9001 running 4.3.2.
Workaround:
Reload MPA.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 4.3.2.BASE |
|
Known Fixed Releases: | 5.2.4.6i.BASE, 5.3.0.15i.BASE |
|
|
| |
| |
Bug Id: | CSCuo68417 |
Title: | Invalid IPv4/IPv6 packet punted for netflow processing causes NP lockup |
|
Description: | Disable Netflow.
The following logs may be present on a device:
LC/0/4/CPU0:May 1 02:42:04.501 CET: prm_server_ty[300]: %PLATFORM-NP-4-FAULT : Fast Reset NP1 - successful auto-recovery of NP
LC/0/4/CPU0:May 1 02:42:04.501 CET: pfm_node_lc[290]: %PLATFORM-NP-2-NP_DIAG : Clear|prm_server_ty[168018]|Network Processor Unit(0x1008001)| NP
diagnostics warning on NP1.
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 6.1/5:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:A/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:OF/RC:C
CVE ID CVE-2014-3322 has been assigned to document this issue.
Additional details about the vulnerability described here can be found at:
http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2014-3322
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
Symptom:
A vulnerability in the Netflow processing in Cisco IOS XR Software for ASR 9000 Series Aggregation Services Routers could allow an
unauthenticated, adjacent attacker to cause a lockup and eventual reload of a Network Processor (NP) chip and a line card processing traffic.
The vulnerability is due to improper Netflow sampling of malformed IPv4/IPv6 packets. An attacker could exploit this vulnerability by sending a
stream of malformed IPv4/IPv6 packets to be processed through an affected device. An exploit could allow the attacker to cause a lockup and
eventual reload of an NP chip and a line card, leading to a denial of service (DoS) condition.
Conditions:
Only Typhoon-based line cards on Cisco ASR 9000 Series Aggregation Services Routers are affected by this vulnerability.
Netflow sampling has be configured for this vulnerability to be exploited.
Workaround:
Disable Netflow.
The following logs may be present on a device:
LC/0/4/CPU0:May 1 02:42:04.501 CET: prm_server_ty[300]: %PLATFORM-NP-4-FAULT : Fast Reset NP1 - successful auto-recovery of NP
LC/0/4/CPU0:May 1 02:42:04.501 CET: pfm_node_lc[290]: %PLATFORM-NP-2-NP_DIAG : Clear|prm_server_ty[168018]|Network Processor Unit(0x1008001)| NP
diagnostics warning on NP1.
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 6.1/5:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:A/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:OF/RC:C
CVE ID CVE-2014-3322 has been assigned to document this issue.
Additional details about the vulnerability described here can be found at:
http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2014-3322
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
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 4.3.1.BASE, 4.3.4.BASE, 5.1.0.BASE |
|
Known Fixed Releases: | 4.3.4.SP3, 4.3.4.SP4, 4.3.4.SP5, 4.3.4.SP6, 4.3.4.SP7, 4.3.4.SP8, 5.1.3.13i.BASE, 5.2.0.29i.BASE |
|
|
| |
| |
Bug Id: | CSCut40941 |
Title: | SSTE:IPv6_ma crash with scale IPoE V6 session |
|
Description: | Symptom:
IPv6_ma process crash
Conditions:
when invoke IPoE dhcp v6 sessions
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: | 5.3.1.30i.FWDG, 5.3.2.6i.FWDG, 6.0.0.5i.FWDG |
|
|
| |
| |
Bug Id: | CSCun97435 |
Title: | ASR9k - 100GE LC - punt policer not correctly programmed in NPs |
|
Description: | Symptom:
NP is not rate limiting correctly the punt packets for netflow when configured in a 100GE interface in a ASR9k
Conditions:
flow monitor configured in a 100GE interface of an ASR9k
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 4.2.3.LC, 4.3.4.LC |
|
Known Fixed Releases: | 5.1.3.8i.BASE, 5.2.0.24i.BASE |
|
|
| |
| |
Bug Id: | CSCum91344 |
Title: | ASR9K: BVI routes packet with unicast address and mcast dst mac |
|
Description: | Symptom:
Multiple copies of a packet with a unicast ip address and mcast destination mac address will be sent out each attachment circuit of a bridge domain
Conditions:
configure a bridge domain with a bvi interface and inject a packet with a unicast destination ip address and a multicast destination mac address
Workaround:
L2 ACL in limited use cases
Further Problem Description:
N/A
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 4.3.1.BASE, 4.3.1.FWDG, 4.3.3.CE |
|
Known Fixed Releases: | 5.1.2.15i.BASE, 5.2.0.19i.BASE |
|
|
| |
| |
Bug Id: | CSCum60762 |
Title: | ISM is dropping traffic due to Label Leaf Index Out of Bound |
|
Description: | Symptom:
The ISM will drop all traffic with a MPLS Label above 144999
Conditions:
ASR9K running 4.3.2 with a ISM
Workaround:
mpls label range 16000 144999
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 4.3.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCum21075 |
Title: | large negative number in OAM L2VPN SLA data |
|
Description: | Symptom:
Customer has configured Ethernet CFM between two ASR9k routers with bgp signalled PW between them. Customer noticed that when the ac on either side is shutdown or physical link goes down a very high negative value is shown
Conditions:
HW: ASR9K
SW: 4.2.3
Topology
========
AC_MEP -> ASR-------PW ---[cloud]----PW-----ASR<- MEP_AC
Workaround:
NA
Further Problem Description:
Customer symptom
==================
data (problem) when the edge (AC) interface goes down
Source: Interface TenGigE0/0/0/3.51, Domain ESLA-SUR-bluecran_
Destination: Target MEP-ID 2
================================================================================
Profile 'COS1', packet type 'cfm-delay-measurement'
Scheduled to run every 1min first at 00:00:00 UTC for 1min
Round Trip Delay
~~~~~~~~~~~~~~~~
5 probes per bucket
Bucket started at 07:50:00 EST Fri 06 December 2013 lasting 5min
Pkts sent: 300; Lost: 0 (0.0%); Corrupt: 0 (0.0%);
Misordered: 0 (0.0%); Duplicates: 0 (0.0%)
Min: 0.07ms; Max: 0.07ms; Mean: 0.07ms; StdDev: 0.00ms
Bucket started at 07:55:00 EST Fri 06 December 2013 lasting 5min
Pkts sent: 300; Lost: 0 (0.0%); Corrupt: 0 (0.0%);
Misordered: 0 (0.0%); Duplicates: 0 (0.0%)
Min: 0.07ms; Max: 0.07ms; Mean: 0.07ms; StdDev: 0.00ms
Bucket started at 08:00:00 EST Fri 06 December 2013 lasting 5min
Pkts sent: 300; Lost: 0 (0.0%); Corrupt: 0 (0.0%);
Misordered: 0 (0.0%); Duplicates: 0 (0.0%)
Min: -1439187.42ms; Max: 993544.17ms; Mean: -130130.45ms; StdDev: 1134941.15ms <<<<<<<<<<
Bucket started at 08:05:00 EST Fri 06 December 2013 lasting 5min
Pkts sent: 300; Lost: 0 (0.0%); Corrupt: 0 (0.0%);
Misordered: 0 (0.0%); Duplicates: 0 (0.0%)
Min: -1439187.05ms; Max: 993539.28ms; Mean: -68050.40ms; StdDev: 609120.81ms <<<<<<<<
Bucket started at 08:10:00 EST Fri 06 December 2013 lasting 5min
Pkts sent: 300; Lost: 0 (0.0%); Corrupt: 0 (0.0%);
Misordered: 0 (0.0%); Duplicates: 0 (0.0%)
Min: 0.07ms; Max: 0.07ms; Mean: 0.07ms; StdDev: 0.00ms
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 4.2.3.BASE |
|
Known Fixed Releases: | 5.1.2.12i.BASE, 5.2.0.11i.BASE |
|
|
| |
| |
Bug Id: | CSCul40435 |
Title: | Sometimes can't apply Q-limit and service policy to ATM PVC under 4.3.2 |
|
Description: | Symptom:
Sometimes can't apply Q-limit and service policy to PVC under 4.3.2
Conditions:
When configuration is done.
Workaround:
Reload the ATM SPA to recover.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 4.3.2.BASE |
|
Known Fixed Releases: | 4.3.4.12i.BASE, 5.1.1.17i.BASE, 5.1.11.13i.BASE, 5.1.2.9i.BASE, 5.2.0.10i.BASE |
|
|
| |
| |
Bug Id: | CSCul78173 |
Title: | Trident: Online Diags Failure does not trigger NP fast reset |
|
Description: | To make an effort to recover the data path when NP failure detected.
Symptom:
Automatic NP fast reset not triggered when NP failure detected by online diagnostic.
Conditions:
NP lockup on Trident line cards
Workaround:
None
Further Problem Description:
A change of severity for the alarm of online diagnostic NP loopback failure caused the Fault Manager to refuse to act upon this alarm. This fix is to restore the old severity so the Fault Manager will take the recovery action for this alarm.
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 4.3.2.BASE |
|
Known Fixed Releases: | 4.3.4.14i.BASE, 5.1.1.17i.BASE, 5.1.11.13i.BASE, 5.1.2.9i.BASE, 5.2.0.10i.BASE |
|
|
| |
| |
Bug Id: | CSCuo76609 |
Title: | Single ring dual home satellite send to BFD two BFD packets |
|
Description: | Symptom:
In a Single ring dual home satellite topology running BGP with BFD everything works fine until the ICL link to one of the satellites failed triggering a switch over to the other host. When the ICL is brought back up, the satellite move to the original host, BFD start flapping on the remote CPE. The problem is that the active host, and the back up host are sending bfd packet to the CPE.
Conditions:
Two ASR9000 running 5.1.1 supporting a Single Ring Dual Home Satellite topology, and running BGP and BFD.
Workaround:
1- Run Dual BGP/BFD session from the CPE to each host.
2-Egress ACL on access interface of both the hosts works to deny BFD with TTL less than 255
!
ipv4 access-list 10
10 deny udp any eq 49152 any eq 3784 ttl lt 255
20 permit ipv4 any any
!
int gigabitEthernet 200/0/0/0.2001
interface GigabitEthernet200/0/0/0.2001
vrf vrf1
ipv4 address 1.1.1.1 255.255.255.0
encapsulation dot1q 2001
ipv4 access-group 10 egress
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 5.1.1.BASE, 5.3.0.BASE |
|
Known Fixed Releases: | 5.1.3.13i.BASE, 5.2.2.15i.BASE, 5.2.3.1i.BASE, 5.3.0.1i.BASE |
|
|
| |
| |
Bug Id: | CSCum57888 |
Title: | MAC security logging doesn't work on Trident LC |
|
Description: | Symptom:
1. When MAC address moves from one bridge port to another, only one NP on all Trident line cards will successfully update the MAC entry. The rest NPs on Trident line cards will not have the MAC entry updated to the 2nd bridge port.
2. After MAC flush operation, if the flushed MAC is received on a different bridge port than previously learned, only one NP on all Trident line cards can successfully learn the MAC on new port. The rest NPs on Trident line cards will not learn the MAC.
3. In both case 1 and 2, MAC table on Trident line cards are out of sync among NPs. It takes about half MAC age (2.5 minutes by default) for the MAC table to be synchronized among NPs when traffic from the source MAC is continuously received on ASR9k switch.
Although MAC table is out of sync, traffic forwarding impact is no expected. If there is traffic sent to the MAC destination which is missing on some NPs, the MAC out of sync problem is corrected immediately.
4. If MAC security feature is configured in the bridge domain or on bridge ports and the MAC security action is "none" with logging enabled, logging function will not work when MAC move occurs among bridge ports on GigE and TenGigE main/sub interfaces.
Conditions:
Impacted LC and interface types:
GigE and TenGigE main/sub L2 interface on Trident line cards are impacted by the defect. If MAC moves among PW bridge ports, Ether bundle based bridge ports, BVI based bridge ports, or any other types of internal/virtual bridge ports, the defect has no impact.
Workaround:
None
Further Problem Description:
Impacted releases:
4.2.3, 4.3.0 to 4.3.4, 5.1.0 to 5.1.1.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 4.2.3.BASE, 4.3.0.BASE, 4.3.1.BASE, 4.3.4.BASE, 5.1.0.BASE |
|
Known Fixed Releases: | 5.1.1.21i.BASE, 5.1.11.18i.BASE, 5.1.2.14i.BASE, 5.2.0.11i.BASE |
|
|
| |
| |
Bug Id: | CSCun77266 |
Title: | Zero input counters on PW-IW interfaces |
|
Description: | Symptom:
Input counters on pseudowire headend interworking (PW-IW) interfaces are always zero.
Conditions:
ASR9000 running IOS-XR 5.1.1.
Pseudowire headend interface VC Type 11 (ATM Ethernet interworking).
Workaround:
COunters can be viewed using the "show int pw-iw accounting" command
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 5.1.1.MPLS |
|
Known Fixed Releases: | 5.1.3.11i.BASE, 5.2.0.27i.BASE |
|
|
| |
| |
Bug Id: | CSCuo57935 |
Title: | BFD remain in init state after MPA OIR |
|
Description: | Symptom:
Physical OIR MPA on MOD80 or MOD160 or sub-slot of ASR9001, the bfd session stuck in INIT state.
The original defect is DDTS CSC un 46767 which was integrated in 5.1.2 interim release but later get backed out from CCO image due to ISSU CSC uo 53935.
Conditions:
OIR MPA on MOD80 or MOD160 or sub-slot of ASR9001
Workaround:
Process restart bfd_agent loc <> should clear the problem
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 4.3.4.LC, 5.1.2.BASE |
|
Known Fixed Releases: | 5.1.11.BASE, 5.1.2.SP1, 5.1.2.SP2, 5.1.2.SP3, 5.1.2.SP4, 5.1.3.6i.BASE, 5.2.0.24i.BASE |
|
|
| |
| |
Bug Id: | CSCuo16205 |
Title: | PTA TCP adjust-mss doesnt work over nv-satellite and PWHE |
|
Description: | Symptom:
subscriber pta tcp mss-adjust won't adjust tcp mss according to the mss value requested by configuration
instead, the default/minimum mss of 1280B will be set in case of nv satellite.
In case of PWHE the egress traffic doesnt flow ( irrespective of protocol type)
Conditions:
subscriber session via nv-satellite or PWHE with PTA MSS Adjust config
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 4.3.4.BASE, 5.2.0.BASE |
|
Known Fixed Releases: | 5.1.3.19i.BASE, 5.1.4.1i.BASE, 5.2.0.23i.BASE |
|
|
| |
| |
Bug Id: | CSCum20984 |
Title: | Linecard should be rebooted after non-recoverable NP error |
|
Description: | Symptom:
Symptom:
The linecard is not automatically reloaded after certain types of non-recoverable NP errors.
Conditions:
LC/0/0/CPU0:May 2 14:08:40.268 : prm_server_ty[298]: %PLATFORM-NP-3-ECC : prm_ser_check: Single-bit ECC error detected: NP 1, block 0x1d (SMI), offset 0, memid 557, name INT0_MEM, addr 0x00000bae, bit 2147483648, ext info 0xffffffff 0xffffffff 0xffffffff 0xffffffff, action 2 (Reset)
LC/0/0/CPU0:May 2 14:08:40.274 : pfm_node_lc[288]: %PLATFORM-NP-2-NON_RECOVERABLE_SOFT_ERROR : Set|prm_server_ty[139343]|Network Processor Unit(0x1008001)| A non-recoverable soft error has been detected on NP1. The linecard will be rebooted.
Workaround:
Reload the linecard. If a similar non-recoverable error is reported again on that linecard, RMA the linecard.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 5.1.1.BASE |
|
Known Fixed Releases: | 5.1.1.20i.BASE, 5.1.11.16i.BASE, 5.1.2.12i.BASE, 5.2.0.14i.BASE |
|
|
| |
| |
Bug Id: | CSCul65585 |
Title: | ether like MIB consistently takes more than 500ms in 4.3.2 image |
|
Description: | Symptom:
SNMP is very slow when polling IOS-XR device
Conditions:
running IOS-XR
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 4.3.2.BASE |
|
Known Fixed Releases: | 5.1.3.23i.BASE, 5.1.3.BASE, 5.1.4.5i.BASE, 5.2.2.14i.BASE, 5.3.0.1i.BASE |
|
|
| |
| |
Bug Id: | CSCun53056 |
Title: | Traffic flooding from PE in VPLS network |
|
Description: | Symptom:
Traffic flooding from specific PE (detected garbage traffic) in VPLS network.
Conditions:
none
Workaround:
linecard reload
Further Problem Description:
The issue is rare and no specific steps to repro it.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 4.3.0.BASE |
|
Known Fixed Releases: | 5.1.3.7i.BASE, 5.2.0.18i.BASE |
|
|
| |
| |
Bug Id: | CSCum08957 |
Title: | Core Typhoon LC drops FAT-PW traffic with dst mac starting with 4 or 6 |
|
Description: | Symptom:
Traffic going over a FAT-PW is dropped.
Can be seen in the NP counters as drops in PARSE_DROP_ING_MPLS_LABEL_INVALID and RSV_DROP_ING_MPLS_PLU.
Conditions:
ASR9000 L2VPN PE running 4.3.x is a disposition PE of a FAT-PW (so with pw-class configured with flow-label).
The core LC receiving the MPLS frame must be a Typhoon (Enhanced Ethernet) linecard.
The destination MAC address following the FAT-PW VC label and the MPLS flow label must start with 4 or 6.
Workaround:
Configure a control-word under the pw-class:
l2vpn
pw-class
encapsulation mpls
control-word
load-balancing
flow-label both
!
!
!
bridge group
bridge-domain
vfi
neighbor pw-id
pw-class
!
!
!
!
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 4.3.2.LC |
|
Known Fixed Releases: | 5.1.2.12i.BASE, 5.2.0.13i.BASE |
|
|
| |
| |
Bug Id: | CSCuo35565 |
Title: | Satellite Access Ports on Bundle ICL Counted Against Bundle Credit |
|
Description: | Symptom:
Resource Exhaustion of bundles interfaces can result in VPLS traffic not flowing through some ports.
Conditions:
1) Total number of bundle + sat-ether interfaces mapped via bundle icl is greater than 254 in release 4.3.0
or
2) Total number of bundle + sat-ether interfaces mapped via bundle icl is greater than 510 from release 4.3.1 onwards
You can "show interface summary" to verify.
Workaround:
1) Use Static Pinning
or
2) Reduce the number of satellite Ethernet ports mapped via bundle ICL by not mapping the unused ports. In this example we would only credit 11 access ports as bundles. If we use the range of 0-43 then 44 ports would be counted as bundles. Whether the ports are used or not is irrelevant.
interface Bundle-Ether100
nv
satellite-fabric-link satellite 100
remote-ports GigabitEthernet 0/0/0-10
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 4.3.4.BASE, 5.1.0.BASE |
|
Known Fixed Releases: | 5.1.3.10i.BASE, 5.2.2.17i.BASE, 5.2.3.6i.BASE, 5.3.0.1i.BASE |
|
|
| |
| |
Bug Id: | CSCul03431 |
Title: | ipv6 traffic is dropped on the mpls te mid point |
|
Description: | Symptom:
ipv6 traffic is dropped on the mpls te mid point
Conditions:
when the ASR9k is the mid point and doing the pop operation
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 5.1.0.MPLS, 5.1.1.MPLS, 5.1.11.BASE |
|
Known Fixed Releases: | 5.1.0.SP1, 5.1.1.14i.BASE, 5.1.11.8i.BASE, 5.1.2.5i.BASE, 5.2.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCuj99895 |
Title: | resource not available condition lack of stats counters |
|
Description: | Symptom:
ASR 9000
User is unable to create new subinterface due to following reason :
!!% 'prm_server' detected the 'resource not available' condition 'lack of stats counters'.
Conditions:
Constant churn of update in labelled routes.
Workaround:
Stop the churn of labelled routes change.
Linecard reload is the only way to recover.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 4.2.1.BASE, 4.2.3.BASE |
|
Known Fixed Releases: | 4.3.4.11i.BASE, 5.1.1.15i.BASE, 5.1.2.7i.BASE, 5.2.0.10i.BASE |
|
|
| |
| |
Bug Id: | CSCun46767 |
Title: | BFD remain in init state after Mod80 OIR |
|
Description: | Symptom:
BFD not restarting after an OIR of the MPA ont he MOD80 or MOD160 card
Conditions:
BFD on a modular typhoon card
Workaround:
process restart the BFD process may help here
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 5.1.1.BASE |
|
Known Fixed Releases: | 5.1.2.23i.BASE, 5.1.3.5i.BASE |
|
|
| |
| |
Bug Id: | CSCun19780 |
Title: | fpd upgrade fails on A9K-2x100GE and A9K-1x100GE |
|
Description: | Symptom:
FPGA upgrade fails due to a wrongly read current FPGA number. Sample error message:
fpd_fpga_agent[193]: %PLATFORM-FPD-3-ERR : fpd-err: Cannot downgrade fpga2 for this card on location 0/1/CPU0 from 512.256 to 1.08. Minimum required firmware version of fpga2 for this card is 1.08.
Conditions:
Observed on A9K-2x100GE and A9K-1x100GE cards of the ASR 9000 series routers.
Workaround:
There are no known workarounds.
Further Problem Description:
FGA version can't be read only during the FPGA upgrade attempt. The sh hw-module fpd ... command correctly reads the current FPGA version:
RP/0/RSP0/CPU0:9K1(admin)#sh hw-module fpd location all
HW Current SW Upg/
Location Card Type Version Type Subtype Inst Version Dng?
============ ======================== ======= ==== ======= ==== =========== ====
0/1/CPU0 A9K-2x100GE-TR 1.0 lc cbc 0 21.111 No
lc cpld1 0 1.03 No
lc fpga2 0 1.02 Yes
lc fpga3 0 1.01 Yes
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 5.1.1.BASE |
|
Known Fixed Releases: | 5.1.1.SP2, 5.1.1.SP3, 5.1.1.SP4, 5.1.1.SP5, 5.1.1.SP6, 5.1.2.18i.BASE, 5.1.3.1i.BASE, 5.2.0.16i.BASE |
|
|
| |
| |
Bug Id: | CSCul31382 |
Title: | Optimize the default queue-limit for ATM SPAs of ASR9K Thor |
|
Description: | Symptom:
Queue limit default configuration is suboptimal.
Conditions:
Standard MQC configuration
Workaround:
Configure the queue limit manually with the "queue-limit X" command under the class in the pmap.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 4.3.2.BASE |
|
Known Fixed Releases: | 4.3.4.12i.BASE, 5.1.1.17i.BASE, 5.1.11.13i.BASE, 5.1.2.9i.BASE, 5.2.0.10i.BASE |
|
|
| |
| |
Bug Id: | CSCuj95362 |
Title: | A9K-SIP-700 QoS incorrectly marked UDP multicast traffic as BFD packets |
|
Description: | Symptom:
ASR9K multicast traffics (UDP traffic) on multilink interface ( for example multilink 0/1/0/0/26) could be incorrectly matched to the service policy-map outputs (for example BFD class)on the multilink interface. Depending the class map configurations, it could be dropped due to the class map QoS confiugratoins.
Conditions:
A9K-SIP-700 with QoS class UDP configurations.
Workaround:
Disable the QoS class map with UDP traffics.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 4.2.1.LC |
|
Known Fixed Releases: | 4.3.4.12i.BASE, 5.1.1.15i.BASE, 5.1.2.7i.BASE, 5.2.0.10i.BASE |
|
|
| |
| |
Bug Id: | CSCul77325 |
Title: | Traffics drop through TE when use PBTS |
|
Description: | Symptom:
VRF traffics couldn't through uplink bundle port.
Conditions:
when config PBTS, uplink port is bundle and run MPLS TE
reset uplink port link or reload lc.
Workaround:
check detail tunnel by "show cef exact-route x.x.x.x x.x.x.x", then shut/no shut the tunnel port, then recovery to normal.
Or reload LC.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 4.3.1.BASE |
|
Known Fixed Releases: | 4.3.4.15i.BASE, 5.1.1.18i.FWDG, 5.1.1.21i.FWDG, 5.1.11.13i.FWDG, 5.1.11.18i.FWDG, 5.1.2.14i.FWDG, 5.1.2.9i.FWDG, 5.2.0.10i.FWDG |
|
|
| |
| |
Bug Id: | CSCua47910 |
Title: | Injected packets on bundle might fail when not all members are up |
|
Description: | Symptom:
Traffic forwarding over a bundle member might stop under very specific conditions
Conditions:
the following conditions must be met:
bundle with multiple members on different linecards
member shut on particular linecard
which one that is can't be determined.
arp timer of affected linecard shorter (due to jitter) then linecard that can properly inject packets
Workaround:
shorter arp timeout to minimize jitter
remove bundle member completely from configuration (no bundle id xx)
static arp entry in configuration
Root cause:
when one member is shut the lag table changes. packets are injected using a "shadow" table. when one member is shut, there is a inconsistency in mapping between the ucode view of the bundle members and the shadow table.
when a particular linecard that is affected by this member shut (generally the ones in higher slot ID's then the member that is shut) has an arp time out that wants to refresh before LC's in a lower slotID having members, the arp resolution fails and this LC will remove the adj from the forwarding, only when a linecard that can refresh arp updates all other linecards the forwarding is restored.
the issue is that the locally generated packet is not injected the packet with the right member selector, making the ucode drop the packet with a lag not local reason.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 4.1.2.BASE |
|
Known Fixed Releases: | 4.2.3, 4.2.3.18i.BASE, 4.2.4, 4.3.0.20i.BASE |
|
|
| |
| |
Bug Id: | CSCuo13873 |
Title: | Packets to aggregate label dropped on RSV_DROP_IPV4_RXADJ_DROP |
|
Description: | Symptom:
MPLS VPN traffic to aggregate label (vrf loopback or connected CE networks)
is either dropped on NP counter RSV_DROP_IPV4_RXADJ_DROP
or is showing high round-trip delay (> 1 sec).
Conditions:
ASR9K MPLS VPN PE running 5.1.1.
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 5.1.1.MPLS |
|
Known Fixed Releases: | 5.1.2.SP1, 5.1.2.SP2, 5.1.2.SP3, 5.1.2.SP4, 5.1.3.8i.BASE, 5.1.3.8i.FWDG, 5.2.0.26i.BASE, 5.2.0.26i.FWDG |
|
|
| |
| |
Bug Id: | CSCuv23702 |
Title: | Resource exhaustion for Rx SA on non-KS with multi rem/add macsec on KS |
|
Description: | Symptom:
Resource exhaustion for Rx SA on non-KS with multi rem/add macsec on KS
Conditions:
Do rem/add of macsec on interface multiple times on KS which will result in resource exhaustion on Rx
Workaround:
Nil
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 6.0.0.K9SEC |
|
Known Fixed Releases: | 6.0.0.9i.BASE |
|
|
| |
| |
Bug Id: | CSCuv24123 |
Title: | [600] Template ipoe LC/RP subscriber sessions failed to come up |
|
Description: | Symptom:
IPOE LC/RP subscriber sessions failed to come up
Conditions:
with template ipoe configs
Workaround:
NA
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | 6.0.0.9i.FWDG |
|
|
| |
| |
Bug Id: | CSCuo73341 |
Title: | EXP is not set correctly when ABF configured |
|
Description: | Symptom:
EXP is not set correctly when ABF configured
sh policy-map output shows everything match exp0 even though we set different exp value at ingress.
Conditions:
Only when ABF configured
for example: 10 permit ipv4 any any nexthop1 vrf tms-l3vrf
Workaround:
set EXP at egress interface
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 5.1.1.BASE |
|
Known Fixed Releases: | 5.1.1.SP3, 5.1.1.SP4, 5.1.1.SP5, 5.1.1.SP6, 5.1.2.SP2, 5.1.2.SP3, 5.1.2.SP4, 5.1.3.13i.BASE, 5.2.0.27i.BASE |
|
|
| |
| |
Bug Id: | CSCuj29095 |
Title: | 511-UI: Kernel crash on image upgrade Ironman Clus |
|
Description: | Symptom:
RP failover with kernel core dump with dllmgr as the active process (can check the active process from the crash info file)
Conditions:
On PPC based ASR9k platforms, when the dll text segment size gets full, dllmgr triggers the kernel core dump.
Workaround:
No workaround is available
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 24-JUL-2015 |
|
Known Affected Releases: | 5.1.0.BASE, 5.1.1.BASE |
|
Known Fixed Releases: | 5.1.1.12i.BASE, 5.1.11.4i.BASE, 5.1.2.2i.BASE, 5.2.0.7i.BASE |
|
|
| |
| |
Bug Id: | CSCuo77702 |
Title: | " Install Add tar " failing on ASR9K when upgrading from 4.3.1 to 4.3.4 |
|
Description: | Symptom:
" Install Add tar " failing on ASR9K when upgrading from 4.3.1 to 4.3.4 .
Conditions:
upgrade from 4.3.1 to 4.3.4 using a TAR file
Workaround:
remove /tmp/spawn_lock file on active RP and repeat command or redundany switchover and repeat command.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUL-2015 |
|
Known Affected Releases: | 4.3.1.BASE |
|
Known Fixed Releases: | 5.2.1.27i.BASE, 5.2.2.16i.BASE, 5.2.3.1i.BASE, 5.3.0.1i.BASE |
|
|
| |
| |
Bug Id: | CSCuq22574 |
Title: | %DIAG-DIAG-3-GOLDXR_FAIL msg indicating node role in unknown state |
|
Description: | Symptom:
DIAG-DIAG-3-GOLDXR_FAIL msg indicating node role in unknown state message starts showing up on console. Message shows up every second and is repetitive.
Conditions:
Executed an ssh script that collected few commands in a loop and ran this for about an hour. After leaving the system in that state , i have noticed that GOLDXR FAIL messages start showing up on the console and node state is declared unknown. The sysmgr on that node is not running at that time. This leads to flooding on the console and does not recover from it. This may not be the trigger or cause of this issue but have noticed this after this incident couple of times.
Workaround:
reloading the node is seen to recover from it, but not other workarounds exist as of now.
Further Problem Description:
This issue needs to be looked into further.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUL-2015 |
|
Known Affected Releases: | 5.1.3.BASE |
|
Known Fixed Releases: | 5.1.3.21i.BASE, 5.1.4.5i.BASE, 5.2.2.24i.BASE, 5.2.3.8i.BASE, 5.3.0.10i.BASE |
|
|
| |
| |
Bug Id: | CSCuo85256 |
Title: | new MPA-8X10GE installed in existing MOD160 is not coming up dynamically |
|
Description: | Symptom:
A9K-MPA-8X10GE cannot boot up due to continuous MPA initialization failure when inserting to A9K-MOD160 line card.
Conditions:
When inserting A9K-MPA-8X10GE into an empty subslot of a running A9K-MOD160 line card.
Workaround:
Reload A9K-MOD160 line card hosting A9K-MPA-8X10GE.
Further Problem Description:
Remember to collect the following logs to make sure if hitting this issue or not.
show controllers np drvlog location
show tech-support ethernet interfaces
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUL-2015 |
|
Known Affected Releases: | 4.3.2.BASE, 5.2.2.BASE |
|
Known Fixed Releases: | 4.3.2.SP5, 4.3.2.SP6, 4.3.2.SP7, 4.3.2.SP8, 5.1.3.SP2, 5.1.3.SP3, 5.1.3.SP4, 5.2.2.18i.BASE, 5.2.3.6i.BASE, 5.3.0.1i.BASE |
|
|
| |
| |
Bug Id: | CSCug23739 |
Title: | g_spa process crashed twice on SPA-1XCHOC48_DS3 |
|
Description: | It was previously not reproducible.
Symptom:g_spa_ process sometimes restarts after a crash.
Conditions:Wrong config commit as below:
controller SONET0/0/0/0
description PROV IWEC 999999 ATI
sts 1
width 3
mode pos scramble
clock source internal
interface POS0/0/0/0
description PROV SVT Testing
ipv4 address 192.168.23.69 255.255.255.252
no shutdown
commit
Workaround:Problem is recoverable by itself, the same config commit should not be tried again.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUL-2015 |
|
Known Affected Releases: | 4.3.0.BASE |
|
Known Fixed Releases: | 5.3.1.26i.BASE, 5.3.2.3i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCud37541 |
Title: | asr9k lost lpts config after router reload |
|
Description: | Symptom:
After router reload, the following commands are not able to apply to running
lpts pifib hardware tcam limit ipv4 14000 location 0/2/CPU0
lpts pifib hardware tcam limit ipv6 1400 location 0/2/CPU0
Conditions:
This issue is purely time dependant . When this faliure happens system's node
changes to default values.
Workaround:
None
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUL-2015 |
|
Known Affected Releases: | 4.2.1.BASE |
|
Known Fixed Releases: | 4.3.1.15i.BASE, 4.3.1.15i.FWDG, 5.1.0.2i.BASE, 5.1.0.2i.FWDG |
|
|
| |
| |
Bug Id: | CSCum51429 |
Title: | SW fix for power supply fan failure false alarm |
|
Description: | Symptom:
Syslog indicating power-supply failure due to either input-oring or FAN failure. These are false alarms. Following are the syslogs get generated when false alarm is hit.
ssue 1: Input Oring of A or B failure
pwr_mgmt[356]: %PLATFORM-PWR_MGMT-2-MODULE_FAILURE : Power-module 0/PM3/SP failure condition raised : Module input Or-ing A failure observed invmgr[257]: %PLATFORM-INV-6-NODE_STATE_CHANGE : Node: 0/PM3/SP, state: FAILED
OR
pwr_mgmt[356]: %PLATFORM-PWR_MGMT-2-MODULE_FAILURE : Power-module 0/PM3/SP failure condition raised : Module input Or-ing B failure observed invmgr[257]: %PLATFORM-INV-6-NODE_STATE_CHANGE : Node: 0/PM3/SP, state: FAILED
For FAN failure:
======================
pwr_mgmt[356]: %PLATFORM-PWR_MGMT-2-MODULE_FAILURE : Power-module 0/PM3/SP failure condition raised : Module fan failure observed invmgr[257]: %PLATFORM-INV-6-NODE_STATE_CHANGE : Node: 0/PM3/SP, state: FAILED
Conditions:
no specific trigger. Issue is due to reading incorrect values.
Workaround:
No workaround.
FAN related false alarm gets cleared within 30 seconds automatically.
Input Oring of A/B false alarm requires reseat of the power-supply. But this is very rarely seen.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 25-JUL-2015 |
|
Known Affected Releases: | 4.2.3.BASE, 5.1.1.BASE |
|
Known Fixed Releases: | 4.3.2.SP2, 4.3.2.SP3, 4.3.2.SP5, 4.3.2.SP6, 4.3.2.SP7, 4.3.2.SP8, 4.3.4.SP1, 4.3.4.SP4, 4.3.4.SP5, 4.3.4.SP6 |
|
|
| |
| |
Bug Id: | CSCuv20072 |
Title: | Software upgrade causes reboot loop |
|
Description: | Symptom:
The following log was seen.
Jun 15 06:30:37.362: Install Setup: This node was booted with an incorrect MBI v
ersion (/bootflash/disk0/asr9k-os-mbi-4.3.4.CSCum70202-1.0.0/0x100000/mbiasr9k-r
p.vm) and will now reset to boot with the correct MBI (/bootflash/disk0/asr9k-os
-mbi-4.3.4.CSCup10546-1.0.0/0x100000/mbiasr9k-rp.vm)
Spawning instdir_show_ltrace -r failed. : No such file or directory
Spawning instdir_show_ltrace -Z -r failed. : No such file or directory
Spawning inst_rds_show_ltrace -r failed. : No such file or directory
[0x11c6f703d] Record Reboot History, reboot cause = 0x4000048, descr = Cause: dS
C booted with incorrect MBI Process: in
stsetup Traceback:
4ba5d248 4ba5drebooting
Jun 15 07:11:13.225: Install Setup: Booting with software activated by previous
install operation
Jun 15 07:12:07.884: Install Setup: Failed to update the package file system: (2
) No such file or directory
Jun 15 07:12:07.884: Install Setup: Install Setup (pid 356384) has failed to pre
pare this node successfully and will now exit: (2) No such file or directory
Jun 15 07:12:41.113: Install Setup: Booting with software activated by previous
install operation
Jun 15 07:13:35.780: Install Setup: Failed to update the package file system: (2
) No such file or directory
Jun 15 07:13:35.780: Install Setup: Install Setup (pid 602144) has failed to pre
pare this node successfully and will now exit: (2) No such file or directory
Failed to rename debug file, 18, src: /nvram:/sysmgr.log.timeout.Z, target: /nvr
am:/prev.sysmgr.log.timeout.Z
Jun 15 07:14:04.382 : SYSMGR_LITE: Saving init logs in /nvram:/sysmgr.log.timeou
t.Z ...
Jun 15 07:14:08.924: Install Setup: Booting with software activated by previous
install operation
This (D)RP Node is not ready or active for login /configuration
Jun 15 07:15:03.534: Install Setup: Failed to update the package file system: (2
) No such file or directory
Jun 15 07:15:03.535: Install Setup: Install Setup (pid 847904) has failed to pre
pare this node successfully and will now exit: (2) No such file or directory
Active processes:
proc/boot/procnto-booke-smp-instr Thread ID 0 on cpu 0
Active processes:
asr9k-os-4.3.4.CSCup10546-1.0.0/0x100000/bin/init Thread ID 1 on cpu 1
Active processes:
pkg/bin/devb-umass Thread ID 7 on cpu 2
Active processes:
pkg/bin/pkgfs Thread ID 2 on cpu 3
[0x550cba66f] Record Reboot History, reboot cause = 0x2c000007, descr = Cause: I
NIT: respawn 'instsetup' disabled, exit_code 256, INIT_MAX_SPAWN reached Process
: init Traceba
ck: 4b8c0248 4[0x551a98a0b] Record crashinfo
[0x551c8d123] Record Syslog
Starting Initialization of FMAN0
Starting Initialization of FMAN1
MAC link is up.
Mgt LAN 0 interface is selected
MLAN init done: ready to connect to the network
2015-06-15 07:16:34.933
NOTE: This is NOT a Kernel Crash. This crash was triggered
by the process 'init', by calling reboot API.
Crash Reason: Cause: INIT: respawn 'instsetup' disabled, exit_code 256, INIT_MAX
_SPAWN reached Process: init
Traceback: 4b8c0248 4b8c06b8 4b8c0a1c 40008968 4b812400 0 (Cause
Code: 0x2c000007)
Exception at 0x4b8c0764 signal 5 c=1 f=3
Active process(s):
proc/boot/procnto-booke-smp-instr Thread ID 0 on cpu 0
asr9k-os-4.3.4.CSCup10546-1.0.0/0x100000/bin/init Thread ID 1 on cpu 1
pkg/bin/devb-umass Thread ID 7 on cpu 2
pkg/bin/pk
|
|
Status: | Terminated |
|
Severity: | 1 Catastrophic |
Last Modified: | 25-JUL-2015 |
|
Known Affected Releases: | 4.3.4.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv47966 |
Title: | macsec session in pending state with line traffic after process restart |
|
Description: | Symptom:
macsec session in pending state/secured state with peer count 0
Conditions:
macsec session in secured state without traffic and with traffic in secured but peer count 0 as no MKA packets are reaching the router
Workaround:
stop the traffic
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 25-JUL-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv28884 |
Title: | FLEXR: xr vm on LC is reset and xr vm intf configs lost during RPFO |
|
Description: | Symptom:
xr vm on LC is reset and xr vm intf configs lost during RPFO.
Conditions:
Triggered RPFO using "sdr default-sdr location 0/RSP1/VM1 reload" command on a 9904 router.
Workaround:
Unknown.
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 26-JUL-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus81167 |
Title: | Active RSP is unable to synch 4.3.1 inactive packages to standby RSP |
|
Description: | Symptom:Feb 04 20:54:55.773: Install Setup: Syncing package 'disk0/asr9k-fwding-4.3.1':
Feb 04 20:54:57.938: Install Setup: Failed: Unable to sync all of the contents of '/disk0/asr9k-fwding-4.3.1'
Feb 04 20:54:57.939: Install Setup: Failed to sync some packages or meta-data
Feb 04 20:54:57.939: Install Setup: Install Setup (pid 884778) has failed to prepare this node successfully and will now exit: (2949233664) 'Subsystem(8083)' detected the 'fatal' condition 'Code(30)'
Conditions:install upgrade
Workaround:
remove inactive packages present on the system of other versions than one being activated
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-JUL-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: | 5.3.1.23i.BASE, 5.3.2.3i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCur62957 |
Title: | Cisco IOS XR Software BVI Routed Packet Denial of Service Vulnerability |
|
Description: | Symptom:
A vulnerability in the packet-processing code of Cisco IOS XR Software for Cisco ASR 9000 Series Aggregation Services Routers (ASR) could allow an unauthenticated, remote attacker to cause a lockup and eventual reload of a network processor chip and the line card that is processing traffic. Only Typhoon-based line cards on Cisco ASR 9000 Series Aggregation Services Routers are affected by this vulnerability.
The vulnerability is due to improper processing of packets that are routed via the bridge-group virtual interface (BVI) when any of the following features are configured: Unicast Reverse Path Forwarding (uRPF), policy-based routing (PBR), quality of service (QoS), or access control lists (ACLs). An attacker could exploit this vulnerability by sending IPv4 packets through an affected device that is configured to route them via the BVI interface. A successful exploit could allow the attacker to cause a lockup and eventual reload of a network processor chip and the line card that is processing traffic, leading to a denial of service (DoS) condition.
Cisco has released free software updates that address this vulnerability. There are no workarounds to address this vulnerability.
This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20150415-iosxr
Conditions:
Please see the published Cisco Security Advisory.
Workaround:
Please see the published Cisco Security Advisory.
Further Problem Description:
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 7.1/5.9:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:M/Au:N/C:N/I:N/A:C/E:F/RL:OF/RC:C
CVE ID CVE-2015-0695 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
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-JUL-2015 |
|
Known Affected Releases: | 4.3.1.BASE, 4.3.2.BASE, 4.3.4.BASE, 5.1.2.BASE, 5.1.3.BASE, 5.2.2.BASE, 5.3.2.BASE |
|
Known Fixed Releases: | 4.3.2.SP8, 4.3.4.SP7, 4.3.4.SP8, 5.1.3.SP4, 5.2.4.7i.BASE, 5.2.5.4i.BASE, 5.3.1.15i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCuv15738 |
Title: | netconf start: cannot load Cisco-IOS-XR-aaa-lib-cfg |
|
Description: | verified, the bug is not present when provided smu is installed
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 27-JUL-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv19328 |
Title: | Umbrella DDTS for iedged bugs on XR 5.2.2 |
|
Description: | Symptom:
umbrella production SMU request: Including
CSCur76645, CSCut59790, CSCur01848, CSCur13588, CSCur67363, CSCuv06754
Conditions:
IPoE/PPPoE session are connected state, iedged crash, iedged memleak due to AAA attributes
Workaround:
process restart iedged local all
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-JUL-2015 |
|
Known Affected Releases: | 5.2.2.ADMIN |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu68447 |
Title: | Umbrella SMU for 5.3.1 NP4c PRM and NP ECC fixes |
|
Description: | Symptom:
1. Tomahawk LC reset
Conditions:
Correctable ECC errors
Workaround:
No workaround
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-JUL-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur13869 |
Title: | ONS-SC+-10GEP30.3 optics causing LC crash on IM |
|
Description: | Symptom:
Continuous back to back envmon_lc process crash seen on the ASR9001.
Conditions:
On ASR9001 with SFP/XFP inserted in ports, if envmon alarms (Tx power, Rx power, Voltage) are generated on these SFP/XFP, then this issue of linecard crash will be seen.
This can occur on any ASR9k box with any type of port. The issue is present since 4.2.3 release. Please note that the alarms are not the actual reason for the LC crash, but the traces corresponding to these alarms.
Workaround:
Only workaround would be to shutdown the four fixed ports on IM; which would render them unusable !!
Install SMU for CSCuq89377
It may be necessary to disable the linecard to install the patch:
!
! Enter Admin-config to disable LC 0/0/CPU0
!
admin
config
hw-module power disable location 0/0/CPU0
commit
Further Problem Description:
Ironman fixed ports were not registered to PFM.In cases where the registration is not done, we would run into some of the error cases in envmon_lc process. There was a defect in those error LTRACES which was triggering the crash.
This DDTS is smu'd under CSCuq89377/AA09350 in 5.1.3.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 27-JUL-2015 |
|
Known Affected Releases: | 5.3.0.BASE |
|
Known Fixed Releases: | 5.1.3.SP3, 5.1.3.SP4, 5.2.2.SP1, 5.2.4.4i.BASE, 5.3.0.15i.BASE |
|
|
| |
| |
Bug Id: | CSCuj10837 |
Title: | PUNT_FABRIC_DATA_PATH diag test fails due to fabric link retrain (TX) |
|
Description: | PUNT_FABRIC_DATA_PATH_FAILED error is reported by the RSP for all NPs on a line card:
RP/0/RSP0/CPU0:Sep 3 13:49:36.595 UTC:
pfm_node_rp[358]:%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[241782]|System
Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP) failed: (0/7/CPU0,1)
(0/7/CPU0, 2) (0/7/CPU0, 3) (0/7/CPU0, 4) (0/7/CPU0, 5) (0/7/CPU0, 6) (0/7/CPU0, 7)
Symptom:
PUNT_FABRIC_DATA_PATH_FAILED error is reported by the RSP for all NPs on a line card:
RP/0/RSP0/CPU0:Sep 3 13:49:36.595 UTC:
pfm_node_rp[358]:%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[241782]|System
Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP) failed: (0/7/CPU0,1)
(0/7/CPU0, 2) (0/7/CPU0, 3) (0/7/CPU0, 4) (0/7/CPU0, 5) (0/7/CPU0, 6) (0/7/CPU0, 7)
Conditions:
Observed on ASR9000 routers a few minutes after re-trainig of fabric links. To check whether re-training has happened, run the following command:
show controller fabric ltrace crossbar location 0/rsp1/cpu0 | include rcvd link_retrain
Sep 3 13:47:06.975 crossbar 0/RSP1/CPU0 t1 detail xbar_fmlc_handle_link_retrain: rcvd
link_retrain for (5,1,0),(9,1,0),1.
Alternative possible output:
show controller fabric ltrace crossbar location 0/rsp0/cpu0 | include rcvd link_retrain
Sep 3 13:47:07.027 crossbar 0/7/CPU0 t1 detail xbar_fmlc_handle_link_retrain: rcvd
link_retrain for (9,1,0),(5,1,0),1.
Workaround:
no workaround. SMU's for most of the images are released.
Further Problem Description:
If this issue is observed on an ASR9000, there is no need for a hardware replacement (i.e no need for RMA). Software fix will be provided through this bug id.
The term TX direction refers to the direction from the standpoint of the RSPs crossbar fabric interface towards a fabric crossbar interface on a Typhoon based linecard.
The CSCuj10837 bug is characterized by the Typhoon LC detecting a problem on the RX link from the RSP and initiating a link retrain. Either side (LC or RSP) can initiate the retrain event.
In the case of CSCuj10837 the LC initiates the retrain and can be detected by the init xbar_trigger_link_retrain: message in the traces on the linecard.
For Example:
RP/0/RSP0/CPU0:ios#show controllers fabric ltrace crossbar location 0/0/cpu0 | in link_retrain
Oct 1 08:22:58.967 crossbar 0/0/CPU0 t1 init xbar_trigger_link_retrain: destslot:0 fmlgrp:3 rc:0
When the linecard initiates the retrain the RSP reports a rcvd link_retrain in the trace output.
RP/0/RSP0/CPU0:ios#show controllers fabric ltrace crossbar location 0/rsp0/cpu0 | in link_retrain
Oct 1 08:22:58.999 crossbar 0/RSP1/CPU0 t1 detail xbar_fmlc_handle_link_retrain: rcvd link_retrain for (1,1,0),(2,1,0),1.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 4.2.3.BASE |
|
Known Fixed Releases: | 4.3.2.SP1, 4.3.2.SP2, 4.3.2.SP3, 4.3.2.SP5, 4.3.2.SP6, 4.3.2.SP7, 4.3.2.SP8, 4.3.4.3i.BASE, 5.1.1.8i.BASE, 5.1.11.4i.BASE |
|
|
| |
| |
Bug Id: | CSCuv42985 |
Title: | BGP crash on active RSP in 5.3.1 |
|
Description: | Symptom:
BGP crash in active RSP
Conditions:
n/a
Workaround:
n/a
Further Problem Description:
n/a
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 5.3.1.ROUT |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu45917 |
Title: | Bundle goes down when macsec is applied on member interfaces |
|
Description: | Symptom:
Bundle goes down
Conditions:
when macsec is applied on member interfaces
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | 6.0.0.6i.BASE |
|
|
| |
| |
Bug Id: | CSCus80011 |
Title: | PLATFORM-ENVMON-3-FANTRAY_ALARM : Fan tray alarm on slot 0/FT0/SP |
|
Description: | Symptom:
The following error may be reported in the syslog:
RP/0/RP0/CPU0:Jan 27 10:59:11.480 : envmon[205]: %PLATFORM-ENVMON-3-FANTRAY_ALARM : Fan tray alarm on slot 0/FT0/SP
RP/0/RP0/CPU0:Jan 27 11:00:29.572 : envmon[205]: %PLATFORM-ENVMON-3-FANTRAY_ALARM_CLEAR : Fan tray alarm cleared on slot 0/FT0/SP
Conditions:
This error will shows up while using ASR-9922-FAN-V2. It is only expected to occur very rarely.
Workaround:
No workaround at this time. This issue does not affect the functionality.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 5.3.0.LC |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus65715 |
Title: | BGP to assign unique nexthop for backup path to avoid RIB crash |
|
Description: | Symptom:
Continuous ipv4-rib process crash followed by RSP reload.
Conditions:
In BGP: If nexthop of backup-path is same as nexthop of one of multipaths, rib crash is seen.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 4.3.4.BASE |
|
Known Fixed Releases: | 4.3.4.SP7, 4.3.4.SP8, 5.2.4.6i.ROUT, 5.3.1.24i.ROUT, 5.3.2.3i.ROUT, 6.0.0.5i.ROUT |
|
|
| |
| |
Bug Id: | CSCus85411 |
Title: | More correctable Typhoon instruction memory ECC errors not repaired |
|
Description: | Symptom:
A single-bit ECC error in NP instruction memory was not repaired properly and thus continues to be detected and reported repeatedly. Here is an example:
prm_server_ty[298]: %PLATFORM-NP-3-ECC : prm_ser_check: Single-bit ECC error detected: NP 7, block 0x18 (MDF), offset 1, memid 51, name INSTRUCTION_MEM1, addr 0x0000004d, bit 35, ext info 0x00000001 0xffffffff 0xffffffff 0xffffffff, action 0 (Fix)
There are no functional side effects, but the error will continue to be detected and reported over and over.
Conditions:
This problem is specific to Typhoon linecards. There is no specific trigger for the underlying error as it is a rare and random hardware occurrence.
Workaround:
Because there are no functional side effects, the repeating error in the logs can be safely ignored. If the logging is a concern, the linecard may be reloaded. If the same errors recur after reloading the linecard, RMA the linecard.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 4.2.1.BASE, 4.3.1.BASE, 5.1.0.BASE, 5.2.0.BASE, 5.3.0.BASE |
|
Known Fixed Releases: | 5.2.4.7i.BASE, 5.2.5.4i.BASE, 5.3.1.21i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCuu48034 |
Title: | Should support - Combo of vlan interfaces with macsec and without macsec |
|
Description: | Symptom:
Should support - Combo of vlan interfaces with macsec and without macsec
Conditions:
Should support - Combo of vlan interfaces with macsec and without macsec
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | 6.0.0.6i.BASE |
|
|
| |
| |
Bug Id: | CSCuv34939 |
Title: | macsec_ea process block on lda_server on process restart |
|
Description: | Symptom:
macsec sessions in pending state
Conditions:
macsecea process is blocked on lda_server after the process restart.
Workaround:
RP/0/RSP0/CPU0:macsec-CE2#show processes blocked location 0/0/cpU0
Jid Pid Tid Name State TimeInState Blocked-on
53 32792 1 ksh Reply 0:10:22:0528 16392 devc-ser8250.th
52 73754 2 attachd Reply 50:15:37:0343 57379 eth_server
52 73754 3 attachd Reply 50:15:37:0347 16396 mqueue
85 73756 6 qnet Reply 0:00:00:0000 57379 eth_server
85 73756 7 qnet Reply 0:00:00:0000 57379 eth_server
64 57377 1 lda_server Reply 0:00:00:0070 16392 devc-ser8250.th
51 73766 2 attach_server Reply 50:15:37:0530 16396 mqueue
378 159828 5 online_diag_lc Send 0:21:47:0473 57377 lda_server
166 159831 3 envmon_lc Send 0:22:02:0070 57377 lda_server
166 159831 6 envmon_lc Send 0:22:02:0824 57377 lda_server
242 180336 1 ipv4_ma Reply 0:22:08:0274 180285 ifmgr
242 180336 5 ipv4_ma Mutex 0:00:39:0879 180336-01 #1
117 217221 1 arp Reply 0:00:00:0000 1 kernel
364 237707 1 vic_0_0 Mutex 0:22:03:0773 237707-13 #1
364 237707 10 vic_0_0 Mutex 0:21:56:0070 237707-13 #1
364 237707 13 vic_0_0 Send 0:22:03:0892 57377 lda_server
364 237707 14 vic_0_0 Mutex 0:22:03:0800 237707-13 #1
365 225423 1 vic_0_1 Send 0:22:04:0334 57377 lda_server
365 225423 10 vic_0_1 Mutex 0:21:55:0796 225423-01 #1
365 225423 13 vic_0_1 Mutex 0:22:04:0031 225423-01 #1
365 225423 14 vic_0_1 Mutex 0:22:03:0728 225423-01 #1
366 225424 1 vic_0_2 Send 0:22:04:0007 57377 lda_server
366 225424 10 vic_0_2 Mutex 0:21:55:0759 225424-01 #1
366 225424 13 vic_0_2 Mutex 0:22:03:0838 225424-01 #1
366 225424 14 vic_0_2 Mutex 0:22:03:0704 225424-01 #1
367 225425 1 vic_0_3 Send 0:22:04:0297 57377 lda_server
367 225425 10 vic_0_3 Mutex 0:21:55:0592 225425-01 #1
367 225425 13 vic_0_3 Mutex 0:22:04:0114 225425-01 #1
367 225425 14 vic_0_3 Mutex 0:22:03:0793 225425-01 #1
265 290969 1 macsec_ea Reply 0:22:04:0695 57377 lda_server
381 229547 1 vlan_ma Reply 0:22:09:0097 180285 ifmgr
RP/0/RSP0/CPU0:macsec-CE2#show macsec mka summary
NODE: node0_0_CPU0
============================================================
Interface Status Cipher-Suite KeyChain
============================================================
Te0/0/0/2/7.1 Pending GCM-AES-XPN-256 kc1
Te0/0/0/2/7.5 Init NONE kc1
Fo0/0/0/3/0.1 Init NONE script_key_chain1
Fo0/0/0/3/1.4 Pending GCM-AES-XPN-256 kc3
Fo0/0/0/3/1.8 Pending GCM-AES-XPN-256 kc3
Hu0/0/0/1.3 Init NONE kc3
Hu0/0/0/1.7 Init NONE kc3
Fo0/0/0/3/1.12 Pending GCM-AES-XPN-256 kc3
Hu0/0/0/1.11 Init NONE kc3
Hu0/0/0/1.15 Init NONE kc3
Hu0/0/0/1.19 Init NONE kc3
Te0/0/0/0/2 Pending GCM-AES-XPN-256 kc1
Te0/0/0/0/6 Pending GCM-AES-XPN-256 kc1
Te0/0/0/2/7.2 Pending GCM-AES-XPN-256 kc1
Fo0/0/0/3/0.2 Pending GCM-AES-128 script_key_chain1
Fo0/0/0/3/1.1 Pending GCM-AES-XPN-256 kc3
Fo0/0/0/3/1.5 Pending GCM-AES-XPN-256 kc3
Fo0/0/0
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | 6.0.0.9i.BASE |
|
|
| |
| |
Bug Id: | CSCue24148 |
Title: | ASR9K: P40x0 Revision C Silicon Support |
|
Description: | Symptoms
Newer P4040 (Typhoon) LC's do not boot IOS-XR.
# ! MAJOR ??? Error [platforms/viking/drivers/dpaa/qnx/src/platform_p4080_! MAJOR ??? Error [platforms/viking/drivers/dpaa/qnx/src/platform_p4080_ds.c:117 PLATFORM_GetChipRevInfo]: Invalid ID; Unknown chip ID
FM HW Major rev not supported = 0
FMAN0 can not be reset or Microcode can not be loaded
fman_init() failed ds.c:117 PLATFORM_GetChipRevInfo]: Invalid ID; Unknown c! MAJOR ??? Error [platforms/viking/drivers/dpaa/qnx/src/platform_p4080_ds.c:117 PLATFORM_GetChipRevInfo]: Invalid ID; Unknown chip ID
FM HW Major rev not supported = 0
FMAN0 can not be reset or Microcode can not be loaded
fman_init() failed hip ID
FM HW Major rev not supported = 0
FMAN0 c! MAJOR ??? Error [platforms/viking/drivers/dpaa/qnx/src/platform_p4080_ds.c:117 PLATFORM_GetChipRevInfo]: Invalid ID; Unknown chip ID
Conditions
New P4040 Processor Silicon from vendor.
New silicon is expected to be released sometime during or after CY 2014 Q1.
Workaround
None.
Symptom:
Conditions:
Workaround:
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 4.3.0.BASE |
|
Known Fixed Releases: | 4.3.1, 4.3.1.31i.BASE, 4.3.2, 4.3.2.11i.BASE, 4.3.2.16i.BASE, 4.3.3, 4.3.31, 4.3.4, 5.1.0, 5.1.0.2i.BASE |
|
|
| |
| |
Bug Id: | CSCuv51691 |
Title: | Interrupt based PN rollover not working for macsec on Tomahawk OTN cards |
|
Description: | Symptom:
Interrupt based PN rollover not working for macsec on Tomahawk Octane OTN cards
Conditions:
Once PN number reaches the maximum value, it should rollover back and SA re-key should happen. This is not happening as interrupt is not generated properly when PN rollover happens
PN - Packet number
SA - Security Association
Workaround:
Nil
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus18572 |
Title: | IRL does not work after all control ports are down |
|
Description: | Symptom:
Split node condition not detected and rack does not reboot when all control links go down in a nv Edge cluster.
Conditions:
IOS XR 5.2.0.
When all control links of an NV Edge Cluster go down, the rack hosting the backup-DSC should be taken down and reboot. This split node detection feature is not working in 5.2.0 release.
Workaround:
no workaround
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 5.2.2.BASE |
|
Known Fixed Releases: | 5.2.4.6i.BASE, 5.3.1.20i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCuv37862 |
Title: | PIM sending MDT Default joins and processing them in global table |
|
Description: | Symptom:
PIM neighbors seen on core uplink on global table flapping all the time
Conditions:
5.1.2 + mVPN + commit that failed with new mdt default config for a vrf
Workaround:
clear pim topology should clear the situation
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 5.1.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCud73451 |
Title: | Single bit ECC errors in NP instruction memory not repaired correctly |
|
Description: | Symptom:
A single bit ECC error in NP instruction memory may not be repaired properly.
Conditions:
Single bit ECC errors are reported rarely. To determine whether an error has been detected, the 'show controller np soft-errors' CLI command may be used or the PRM NP error log may be checked using the 'show prm server trace error' command.
Workaround:
To ensure the error is fixed properly, the linecard should be reset after a single bit ECC error is reported in NP instruction memory.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 4.3.0.BASE |
|
Known Fixed Releases: | 4.3.1, 4.3.1.19i.BASE, 4.3.2, 4.3.2.3i.BASE, 4.3.3, 4.3.31, 4.3.4, 5.1.0, 5.1.0.3i.BASE, 5.1.1 |
|
|
| |
| |
Bug Id: | CSCuv29355 |
Title: | EPFT config stuck after interface-based-flow config |
|
Description: | Symptom:
EPFT configs getting stuck
Conditions:
interface based along with
Workaround:
router reload
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv43674 |
Title: | new cli is not getting commited in the new image |
|
Description: | Symptom:
cli not getting commited
Conditions:
commiting together
Workaround:
single commit
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur14272 |
Title: | FIB backwalk not working for recursive pseudowires |
|
Description: | Symptom:
Multicast traffic not passing through bridge-domain but unicast works fine after a BGP PIC cutover.
Conditions:
Traffic drop.
From log analysis,it shows that the interface information does not get updated in the L3 to L2 notification data.
Workaround:
Clearing routes restore the impacted traffic. It has been verified in the customer routers.
Further Problem Description:
( in addition need to also use the fix in PD bug CSCur33931 for complete fix)
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 4.2.0.MCAST |
|
Known Fixed Releases: | 5.2.3.12i.FWDG, 5.2.4.1i.FWDG, 5.3.0.12i.FWDG |
|
|
| |
| |
Bug Id: | CSCuu84081 |
Title: | SSTE:VM is exhausted or totally fragmented after longevity IPv6 session |
|
Description: | Symptom:
VM is exhausted or totally fragmented
Conditions:
longevity scale IPv6 sessions cycle
Workaround:
restart process
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 28-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu81295 |
Title: | NP does not recover from fast reset if stat op occurs, hangs on F_SR |
|
Description: | Symptom:
LC reboot due NP lockup
Conditions:
subinterfaces are protocol down and traffic is running
Workaround:
avoid subinterface state protocol down
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv06754 |
Title: | PPPoE users can't dial in due to id leak in iedged |
|
Description: | Symptom:IPoE sessions are connected state.
Conditions:default policy action id is leaked in following two cases.
1. access-reject after receiving disconnect.
2. Final subscriber kill.
Workaround:process restart iedged location all
More Info:For the first one :
access-reject is considered as failure and that result is stored in policy_context. When disconnect is triggered before the authentication response is received, disconnect is started before authentication completes. In this case, auth_result and eval of policy_context of authentication action was not cleaned up and it is carried forward to the next action "disconnect". In the failure path of session disconnect, policy_map_alloc_handle is leaked.
For the second one :
In the final subscriber kill, the call to PRE from PPSM is missing in the disconnect complete call flow.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 5.2.2.ADMIN |
|
Known Fixed Releases: | 5.2.5.19i.BASE, 5.2.5.5i.BASE, 5.3.2.17i.BASE, 5.3.3.3i.BASE |
|
|
| |
| |
Bug Id: | CSCuv51381 |
Title: | ROUTING-BGP-3-NPL_TIMEOUT : NPL timeout - BGP will reinitialize NSR |
|
Description: | Symptom:
AR9k running 5.3.1 throwing up the below messages:
RP/0/RSP0/CPU0:Jul 16 18:51:19.169 : bgp[1055]: %ROUTING-BGP-3-NPL_TIMEOUT : NPL timeout - BGP will reinitialize NSR
It is affecting redundancy as below.
RP/0/RSP0/CPU0:pe1.nyc1#Show redundancy
Fri Jul 17 14:49:25.126 EDT
Redundancy information for node 0/RSP0/CPU0:
==========================================
Node 0/RSP0/CPU0 is in ACTIVE role
Node Redundancy Partner (0/RSP1/CPU0) is in STANDBY role
Standby node in 0/RSP1/CPU0 is ready
Standby node in 0/RSP1/CPU0 is NSR-ready
Node 0/RSP0/CPU0 is in process group PRIMARY role
Process Redundancy Partner (0/RSP1/CPU0) is in BACKUP role
Backup node in 0/RSP1/CPU0 is ready
Backup node in 0/RSP1/CPU0 is not NSR-ready
Group Primary Backup Status
--------- --------- --------- ---------
dsc 0/RSP0/CPU0 0/RSP1/CPU0 Ready
dlrsc 0/RSP0/CPU0 0/RSP1/CPU0 Ready
central-services 0/RSP0/CPU0 0/RSP1/CPU0 Ready
v4-routing 0/RSP0/CPU0 0/RSP1/CPU0 Ready
v4-routing 0/RSP0/CPU0 0/RSP1/CPU0 Not NSR-Ready
netmgmt 0/RSP0/CPU0 0/RSP1/CPU0 Ready
mcast-routing 0/RSP0/CPU0 0/RSP1/CPU0 Ready
v6-routing 0/RSP0/CPU0 0/RSP1/CPU0 Ready
Process Group Details
---------------------
Current primary rmf state: Ready
All backup not-ready bits clear - backup should be ready
Current primary rmf state for NSR: Not Ready
Reason for backup not NSR-ready
1055 0/RSP0/CPU0 bgp v4-routing BGP NSR sessions not synchronized : inst_name=default, inst_id=0
Not ready set Thu Jul 16 18:42:15 2015: 20 hours, 7 minutes ago
Conditions:
Workaround:
none
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 5.3.1.ROUT |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv23230 |
Title: | BFD on interface stuck is DAMP State |
|
Description: | Symptom:
BFD on interface stuck is DAMP State
Conditions:
BFD fails to come UP
Workaround:
Not Known
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv06101 |
Title: | Traffic loss seen with Multi-path for prefix with more than 4 paths |
|
Description: | Symptom:
Traffic loss seen with Multi-path for prefix with more than 4 paths
Conditions:
1.5.3.0
2. Tomahawk
3. BGP Multipath feature with more than 4 iBGP paths, where each BGP nexthop was reachable only through tunnels with no LDP configured.
Workaround:
No loss seen when path is less than 4
Further Problem Description:
Traffic loss seen with Multi-path for prefix with more than 4 paths
IXIA---LER---LSR---LSER--IXIA
IBGP neighbors across IXIA-LER - 200 Neighbors
prefix is advertised through 10 different neighbors with multi-path enabled.
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 5.3.0.FWDG |
|
Known Fixed Releases: | 5.3.2.16i.BASE, 5.3.3.3i.BASE |
|
|
| |
| |
Bug Id: | CSCuv28489 |
Title: | VPLS: Multicast wrong replication with flood mode resilience-optimized |
|
Description: | Symptom:
multicast stream doubles on ASR9K(PE) via VPLS(resilence-optimized mode). the reciver detectes the total of stream is twice than expected.
Conditions:
Asr9k sends multicast steram twice after reloading asr9k(PE side).
one for primary TE, second for Backup TE.
Workaround:
reload asr9k also recovery way and trigger
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 4.3.2.BASE |
|
Known Fixed Releases: | 5.3.2.18i.BASE, 5.3.3.3i.BASE |
|
|
| |
| |
Bug Id: | CSCuu49049 |
Title: | DMA errors and packet loss leading to satellite reset |
|
Description: | Symptom:
Satellite randomly loses SDAC discovery session, and resets as designed due to session timeout.
Conditions:
No specific condition. Happens randomly.
Workaround:
None
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 5.1(3) |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv09734 |
Title: | Previously known optics show up as unknown in "show inventory" |
|
Description: | Symptom:
"show inventory" doesn't show PID and S/N info,and
description says "Uknown pluggable optics" for some of the optics for A9K-36x10GE-SE.
Eg:
RP/0/RSP0/CPU0:ariad-EC12#show inventory | include Unknown
Mon Jun 29 17:53:48.793 CEST
NAME: "module mau TenGigE0/2/CPU0/1", DESCR: "Unknown pluggable optics"
Conditions:
Issue would be seen in following scenario's
LC(A9K-36x10GE-SE) oir (or)
Router reload
Workaround:
Do opitcs OIR,which would help in getting the correct PID/SN info in show inventory.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: | 5.3.2.18i.BASE, 5.3.3.3i.BASE |
|
|
| |
| |
Bug Id: | CSCus82385 |
Title: | #21 MPLS-LDP Config commit failed |
|
Description: | Symptom:
configuration of mpls ldp would fail. Show placement program all would show that particular process in REMOTE_SPAWN_REQUESTED state on the standby.
Conditions:
We have seen this issue only during bring up in sanity TB. the issue is seen very rarely 1 in 10 times.
Workaround:
Restarting placed process on standby should recover the issue. Then WE should be able to do the configuration of mpls ldp process
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: | 5.2.5.19i.BASE, 5.2.5.5i.BASE, 5.3.2.18i.BASE, 5.3.3.3i.BASE |
|
|
| |
| |
Bug Id: | CSCuv17312 |
Title: | [600]-L2fib_mgr process continuously restarts on Typhoon LC |
|
Description: | Symptom:
L2fib_mgr process continuously restarts on Typhoon LC
Conditions:
In 600.5I Image, could see L2fib_mgr process continuously restarts on Typhoon LC after loaded image.
Workaround:
NA
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE, 6.0.0.BASE |
|
Known Fixed Releases: | 5.3.2.17i.BASE, 5.3.3.3i.BASE |
|
|
| |
| |
Bug Id: | CSCup95716 |
Title: | Chkpt traceback when restarting rib: Leading to traffic drop - NHID mod |
|
Description: | Symptom:
Traceback observed on process restart ipv4_rib and ipv6_rib on asr9k running XR5.2.2 15I image:
RP/0/RSP0/CPU0:Jul 16 16:22:23.044 : ipv6_rib[1157]: %HA-CHKPT_BASIC-7-WARNING : Warning: chk_validate_create called with NULL table id: : 0 : pkg/bin/ipv6_rib : (PID=995669) : -Traceback= 4a2dc140 4a6ed4f8 4a6fb1ec 400727c8 400742ec 40074a58 4003abec 40021bd4 400263b0 400163f0 40017074 4a2fd5d0 4a2fe110 4a2f92a0 4a2f937c 4a373844
This can cause traffic loss due to NHID misprogramming issues.
Conditions:
Process restart on ipv4_rib and ipv6_rib is the trigger for this issue.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 5.2.2.BASE, 5.2.4.BASE |
|
Known Fixed Releases: | 5.2.5.14i.BASE, 5.3.2.18i.BASE, 5.3.3.3i.BASE |
|
|
| |
| |
Bug Id: | CSCuu57171 |
Title: | TenGig intf with SyncE on Typhoon LC remain in 'Unqualified' state |
|
Description: | Symptom:
The SyncE input source stays in Unqualified state when zllc process on the line card is restarted and the transport mode of the SyncE interface is changed from the current mode to another (eg. LAN to OTN, WAN to LAN etc).
Conditions:
ASR 9000 router with syncE configured on an ethernet interface which supports multiple transport modes and the transport mode is modified after the zllc process in the line card crashes or restarted.
Workaround:
A reload of the line card would resolve this issue.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 4.3.2.BASE, 5.3.2.BASE |
|
Known Fixed Releases: | 5.3.2.15i.BASE, 5.3.3.3i.BASE |
|
|
| |
| |
Bug Id: | CSCuu79104 |
Title: | With 42 SA scale and macsec_ea restart, mka sessions flaps continuosly |
|
Description: | Symptom:
With 42 SA scale and macsec_ea restart, mka sessions flaps continuosly
Conditions:
Once we do the process restart for macsec_ea, rekey happening continuously which making huge programming over phy by lda_server. This is the reason why it is showed that macsec_ea is blocked over lda_server for time being.
With traces, it is confirmed that MKA packet are receiving in time from peer, but macsec_mka could not process as it is waiting for macsec_ea to finish the pd programming.
Workaround:
Nil
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 6.0.0.BASE, 6.0.0.CE |
|
Known Fixed Releases: | 6.0.0.6i.BASE |
|
|
| |
| |
Bug Id: | CSCuu97592 |
Title: | local ping failed - FIA has spaui line down after RP VM change |
|
Description: | Symptom:
ping local failed
Conditions:
Changed XR VM from 12 to 16 on calvados. 50% reproducible
Workaround:
no
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCui12600 |
Title: | ASR9K: ACL misprogrammed for VRF after update in place |
|
Description: | Symptom:After making an in place change to an ACL the existing ACE statements no longer work and traffic is impacted
Conditions:ACL on multilink interfaces performing ABF and VRF leaking, make a change to the ACL in place
The fix is applicable to SIP-700 linecard.
Workaround:Create a new ACL with the same ACE statements and apply to the interfaces
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 4.2.1.BASE, 4.2.3.BASE |
|
Known Fixed Releases: | 4.3.2.28i.BASE, 5.1.0.18i.BASE |
|
|
| |
| |
Bug Id: | CSCuu70915 |
Title: | LER: ipv4 pkts drop on remote PE with RSV_DROP_MPLS_LEAF_NO_MATCH on FRR |
|
Description: | Symptom:
ipv4 pkts drop on remote PE node on node FRR
Conditions:
Happens only if there are BGP recursive routes (global BGP only) going over an IGP route which has 64 ECMP tunnels, where all the 64 tunnels are going out of the same bundle interface. Node FRR was triggered by shutting down the bundle interface from the remote side. The issue is scale related and is likely to be seen with 64 tunnels going out of the same bundle interface.
Workaround:
Reducing the number of tunnels going out of the same bundle interface may help.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | 5.3.2.15i.BASE, 5.3.3.3i.BASE |
|
|
| |
| |
Bug Id: | CSCuq37265 |
Title: | Parity error correction failure in TM memory on Typhoon linecards |
|
Description: | Symptom:
Parity error correction failed on NP TM (A9K-2x100GE-TR). This issue is not specific to the 100G linecard.
=syslog=
LC/0/1/CPU0:Aug 11 08:50:43.878 JST: prm_server_ty[297]: %PLATFORM-NP-3-ECC : prm_ser_check: Unable to repair Parity error on NP 0, block 0x24 (TM_QC), offset 50, memid 118, name QD_CCH_SHP_PROF_INDX_L, addr 0x000000da, bit 2147483648, ext info 0xffffffff 0xffffffff 0xffffffff 0xffffffff, action 0 (Fix)
LC/0/1/CPU0:Aug 11 08:50:43.883 JST: pfm_node_lc[287]: %PLATFORM-NP-2-NON_RECOVERABLE_SOFT_ERROR : Set|prm_server_ty[168019]|Network Processor Unit(0x1008000)| A non-recoverable soft error has been detected on NP0. The linecard will be rebooted.
Conditions:
This repair failure can occur whenever an ECC or parity is detected in block 0x24 (TM_QC) with an offset of 46 or 50. Note that the bug is in the repair of the faulty memory location. This fix does not address the underlying ECC/parity which is most likely a rare hardware occurrence.
Workaround:
None required. The linecard will automatically be rebooted since the correction failed.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 4.3.2.BASE |
|
Known Fixed Releases: | 5.2.2.25i.BASE, 5.2.3.12i.BASE, 5.2.4.1i.BASE, 5.3.0.10i.BASE |
|
|
| |
| |
Bug Id: | CSCuv21818 |
Title: | [600] CoA request fails with PPPoE sessions |
|
Description: | Symptom:
No response for the CoA request sent
Conditions:
With PPPoE Sessions
Workaround:
NA
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 6.0.0.ADMIN, 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv44058 |
Title: | CMPv2 initialization response message parsing failure |
|
Description: | Symptom:
parsing failure of the CMP Ir message received
Conditions:
the error is seen while parsing the HTTP header (field-name)
Workaround:
no workarounds
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 18.3.M0 |
|
Known Fixed Releases: | 18.2.T0.60746, 18.3.M0.60730, 18.4.A0.60735, 19.0.M0.60728, 19.0.v0.60722, 19.1.A0.60725, 19.2.A0.60748, 20.0.M0.60745 |
|
|
| |
| |
Bug Id: | CSCuv27439 |
Title: | Cluster - unequal load balancing in IRLs |
|
Description: | Symptom:
In some scenarios the IRLs in a cluster will not balance the traffic evenly between the members.
Conditions:
We have seen the issue when the number of IRLs is greater than or equal to 8 links.
Workaround:
The command "cef load-balancing algorithm adjust" does not influence IRLs balancing algorithm. The only workaround is to reduce traffic using the IRLs by activating locality in bundles or locality for ECMP enabled in version 5.2.2 and later versions.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 5.1.3.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv45919 |
Title: | pfilter_ea process crash after applyin capture keyword to ACL |
|
Description: | Symptom:
crash observed after applying capture key word in ipv6 access list.
Conditions:
1. Create 2 classic ACLs with the same acl-name, one v4 and another is v6.
2. Attach them to interface/s.
3. Edit the latter acl which was attached.
Workaround:
Do not have the same name for both v4 & v6 acl.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv16107 |
Title: | LISP traffic dropped 10 seconds @PUNT_NO_MATCH after RPFO |
|
Description: | Symptom:
LISP traffic may drop briefly after RP failover on an LISP iTR device.
Conditions:
No specific condition for problem to occur.
Workaround:
No workaround is available.
Further Problem Description:
The problem is caused by timing of RIB and LISP processes becoming active after RP switchover. To be specific, RIB becomes active and declare route convergence, which causes stale routes to be removed, before LISP process becomes active and register with RIB.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 5.3.2.ROUT |
|
Known Fixed Releases: | 5.3.2.18i.FWDG, 5.3.3.3i.FWDG |
|
|
| |
| |
Bug Id: | CSCuu89781 |
Title: | v6 Netflow: NP lock up on Tomahawk with resolve lockup in SNF code |
|
Description: | Symptom:
NP lockup with ipv6 netflow.
Conditions:
V6 netflow
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | 5.3.2.18i.BASE, 5.3.3.3i.BASE, 6.0.0.9i.BASE |
|
|
| |
| |
Bug Id: | CSCuv14560 |
Title: | I/f shut down due to DIAG test failure, continued to be down after FO |
|
Description: | Symptom:
Interfaces stay down after the switchover
Conditions:
All below conditions should match in same sequence.
1. Configure "admin fabric data-path toggle" to shutdown the ports when diagnostic test fails and to bring up the ports once test failure cleared.
2. Interfaces shutdown due to diagnostic test fail
3. Before test failure clears, switchover is performed (manually or automatically)
4. Interfaces continue to stay down
Workaround:
unshut the interfaces manually after switchover or reset the cards.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 4.3.4.BASE |
|
Known Fixed Releases: | 5.3.2.17i.BASE, 5.3.3.3i.BASE |
|
|
| |
| |
Bug Id: | CSCum26074 |
Title: | for RPs, voltage, power & on-board temp sensors values are not available |
|
Description: | Symptom:
On IOS-XR These messages appear in the logs:
RP/0/RSP0/CPU0:Feb 16 03:47:45.287 : envmon[207]: %PLATFORM-ENVMON-2-FANTRAY_COMM_FAIL : Fan tray communication failure on slot 0/FT0/SP
RP/0/RSP0/CPU0:Feb 16 03:47:46.305 : envmon[207]: %PLATFORM-ENVMON-2-ENV_CONDITION : Outstanding environmental condition exists in the chassis
RP/0/RSP0/CPU0:Feb 16 03:47:57.287 : envmon[207]: %PLATFORM-ENVMON-2-FANTRAY_COMM_FAIL : Fan tray communication failure on slot 0/FT1/SP
RP/0/RSP0/CPU0:asr9k# show environment leds detail
Mon Feb 17 17:59:03.475 UTC
R/S/I Modules LED Status Alarm Reason
0/RSP0/*
host Critical-Alarm On FT comm. failure; < -------
host Major-Alarm Off ----
host Minor-Alarm Off ----
host ACO Off ----
host Fail Off ----
0/RSP1/*
host Critical-Alarm Off ----
host Major-Alarm Off ----
host Minor-Alarm Off ----
host ACO Off ----
host Fail Off ----
Conditions:
Running 4.3.x on any ASR9K router
Presence of any of these cards in the chassis could trigger this issue.
A9K-8T-B
A9K-8T-E
A9K-8T-L
A9K-16T/8-B
A9K-16T/8-E
A9K-16T/8-L
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 4.3.4.ADMIN, 4.3.4.BASE, 5.2.0.BASE |
|
Known Fixed Releases: | 4.3.4.SP1, 4.3.4.SP4, 4.3.4.SP5, 4.3.4.SP6, 4.3.4.SP7, 4.3.4.SP8, 5.1.1.20i.BASE, 5.1.11.16i.BASE, 5.1.2.12i.BASE, 5.2.0.11i.BASE |
|
|
| |
| |
Bug Id: | CSCuu13459 |
Title: | NSR not reaching ready state bcoz IPC transport went down on stndby |
|
Description: |
Symptom:LDP NSR not ready due to standby LDP not connected to active
Conditions:IPC transport went down and the LDP recovery mechanism failed.
Releases impacted:
5.2.4, 5.3.0 and 5.3.1
Workaround:process restart mpls_ldp on standby node.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | 5.3.2.8i.MPLS, 6.0.0.5i.MPLS |
|
|
| |
| |
Bug Id: | CSCuv03006 |
Title: | FRR is failing to converge within 0.05s after shutting down remote int |
|
Description: | Symptom:
Traffic convergence will take more than the epxected 0.05 seconds.
Conditions:
After configuring per link LFA and shutting down the remote LS
Workaround:
None
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu68949 |
Title: | rpl configs could not be removed with commit replace |
|
Description: | Symptom:
rpl entries could not be removed with commit replace
Conditions:
asr9k router running 532 interim image
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | 5.3.2.18i.ROUT, 5.3.3.3i.ROUT |
|
|
| |
| |
Bug Id: | CSCuq27759 |
Title: | PTP with ARB mode - Slave port stays unqualified after RSP switchover |
|
Description: | Symptom:
After performing several RSP switchovers, it can be observed that PTP slave port stays unqualified.
This behavior can be seen independently of the timescale that is being used (PTP or ARB).
Conditions:
This behavior can be seen after a router reload or RSP switchover
Workaround:
There is no workaround
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 5.2.0.BASE |
|
Known Fixed Releases: | 5.3.2.18i.BASE, 5.3.3.3i.BASE |
|
|
| |
| |
Bug Id: | CSCut14345 |
Title: | prm_server_ty process restarted due to high CPU usage |
|
Description: | Symptom:
The prm_server_ty process may be restarted due to a signal 30 or due to being declared a CPU hog. Here are examples:
wdsysmon[387]: Process prm_server_ty pid 176209 prio 12 using 26 percent is the top user of CPU
wdsysmon[387]: Process prm_server_ty pid 176209 tid 26 prio 12 using 26 percent is a CPU Hog and terminated
dumper[56]: %OS-DUMPER-7-DUMP_REQUEST : Dump request for process pkg/bin/prm_server_ty
Crashed pid:172114 (pkg/bin/prm_server_ty) Time:Tue Apr 21 12:50:30 2015
Thread:28 received signal:30 - SIGXCPU. Exceeded CPU limit. Sender:pkg/bin/wdsysmon pid:131122
The prm process should restart successfully, but there may be secondary issues such as interfaces not getting created.
Conditions:
This is a rare condition and is normally only seen immediately after the linecard boots up.
Workaround:
If the problem is seen and there are secondary issues such as interfaces not being created, reload the linecard.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: | 5.3.2.16i.BASE, 5.3.3.3i.BASE |
|
|
| |
| |
Bug Id: | CSCuv27777 |
Title: | IOS-XR v4-routing stuck in Not NSR-Ready because of BGP after RPFO |
|
Description: | Symptom:
After redundancy failover (RPFO) NSR may stuck in the Not NSR-Ready status for couple of hours because of the BGP Process.
Current primary rmf state for NSR: Not Ready
Reason for backup not NSR-ready
1055 0/RP1/CPU0 bgp v4-routing BGP NSR sessions not synchronized : inst_name=default, inst_id=0
After that time, NSR will auto-recover with the following log messages:
bgp[1055]: %ROUTING-BGP-6-NSR_RESTART : NSR has been restarted - TCP init-sync failed for a batch of sessions
bpm[1070]: %ROUTING-BGP-5-ASYNC_IPC_STATUS : bpm-default:(S)inst-id 0, Connection Closed
bpm[1070]: %ROUTING-BGP-5-ASYNC_IPC_STATUS : bpm-default:(S)inst-id 0, Connection Open
bgp[1055]: %ROUTING-BGP-5-ASYNC_IPC_STATUS : default, process instance 1:(S)inst-id 0, Connection Establised
bgp[1055]: %ROUTING-BGP-5-ASYNC_IPC_STATUS : default:(S)inst-id 0, Initial Config Done
bgp[1055]: %ROUTING-BGP-5-NSR_STATE_CHANGE : Changed state to NSR-Ready
Conditions:
IOS-XR 5.3.1
Redundancy failover
Workaround:
None. NSR will auto-recover.
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 5.3.1.ROUT |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu67727 |
Title: | Some PPPoE fragmented packets are dropped at bundle access interface |
|
Description: | Symptom:
Fragmented packet towards PPPoE subscribers are dropped at bundle access interface.
Conditions:
Packet needs fragment towards PPPoE subscribers.
IPoE or non-BNG flows are not impacted.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 5.3.0.BASE |
|
Known Fixed Releases: | 5.3.2.14i.BASE |
|
|
| |
| |
Bug Id: | CSCuu27992 |
Title: | LER: around 100 to 250 ms traffic loss with ipv6 pkts on TE FRR |
|
Description: | Symptom:
Seeing traffic loss of around 150 to 250 ms with link FRR on bundle.
Conditions:
Link FRR over bundles.
Workaround:
NOne
Further Problem Description:
None
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | 5.3.2.18i.BASE, 5.3.3.3i.BASE |
|
|
| |
| |
Bug Id: | CSCuu96153 |
Title: | FD leaks on bfd_agent process when executing 'show bfd summary' CLI |
|
Description: | Symptom:
On executing "show bfd summary" the open file descriptor counter increments.
bfd_agent process is crashed by WD after the FD exceeds the critical threshold value.
RP/0/RSP0/CPU0:s4bs-e-401#show processes files 125 location all
Thu Jun 18 22:58:32.517 EST
node: node0_0_CPU0
------------------------------------------------------------------
JID Open-Files Open-Channels NAME
125 121 51 bfd_agent
node: node0_1_CPU0
------------------------------------------------------------------
JID Open-Files Open-Channels NAME
125 121 51 bfd_agent
node: node0_4_CPU0
------------------------------------------------------------------
JID Open-Files Open-Channels NAME
125 124 51 bfd_agent
node: node0_5_CPU0
------------------------------------------------------------------
JID Open-Files Open-Channels NAME
125 124 51 bfd_agent
node: node0_RSP0_CPU0
------------------------------------------------------------------
Invalid Job id or Job not running
node: node0_RSP1_CPU0
------------------------------------------------------------------
Invalid Job id or Job not running
RP/0/RSP0/CPU0:s4bs-e-401#show bfd summary
Thu Jun 18 23:13:01.733 EST
Node All PPS usage MP PPS usage Session number
% Used Max % Used Max Total MP Max
---------- --------------- --------------- ------------------
0/0/CPU0 0 0 28000 0 0 9600 0 0 8000
0/1/CPU0 0 0 28000 0 0 9600 0 0 8000
0/4/CPU0 0 233 28000 0 0 9600 2 0 8000
0/5/CPU0 0 233 28000 0 0 9600 2 0 8000
RP/0/RSP0/CPU0:s4bs-e-401#show processes files 125 location all
Thu Jun 18 23:13:08.292 EST
node: node0_0_CPU0
------------------------------------------------------------------
JID Open-Files Open-Channels NAME
125 122 51 bfd_agent
node: node0_1_CPU0
------------------------------------------------------------------
JID Open-Files Open-Channels NAME
125 122 51 bfd_agent
node: node0_4_CPU0
------------------------------------------------------------------
JID Open-Files Open-Channels NAME
125 125 51 bfd_agent
node: node0_5_CPU0
------------------------------------------------------------------
JID Open-Files Open-Channels NAME
125 125 51 bfd_agent
node: node0_RSP0_CPU0
------------------------------------------------------------------
Invalid Job id or Job not running
node: node0_RSP1_CPU0
------------------------------------------------------------------
Invalid Job id or Job not running
RP/0/RSP0/CPU0:s4bs-e-401#
Conditions:
Execution of "show bfd summary" CLI
Workaround:
No Workaround
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 5.1.3.BASE |
|
Known Fixed Releases: | 5.3.2.16i.BASE, 5.3.3.3i.BASE |
|
|
| |
| |
Bug Id: | CSCuv29691 |
Title: | Satellite BoB: LC reload leads to "Replication failed for member" |
|
Description: | Symptom:
Bundle Interfaces Fails to come UP
Conditions:
Router / LC Reload
Workaround:
Not known
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv06078 |
Title: | Neflow v9 records report Junk value for egress interface |
|
Description: | Symptom:
With Ingress netflow, egress interfaces not populated consistently with LER flows i.e. BGP routes going over only tunnel paths with no LDP configured.
Conditions:
1. Tomahawk Linecard
2. 5.3.0
4. LER flows i.e. BGP routes going over only tunnel paths with no LDP configured.
Workaround:
No workaround exist.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 5.3.0.BASE |
|
Known Fixed Releases: | 5.3.2.17i.BASE, 5.3.3.3i.BASE, 6.0.0.9i.BASE |
|
|
| |
| |
Bug Id: | CSCuv52132 |
Title: | snmp may report wrong used/free address counter after modify daps config |
|
Description: | Symptom:
after remove some address range command from one pool to another one.
snmp report wrong used/free address counter.
RP/1/RSP1/CPU0:BNG2#show pool ipv4
Mon Jul 20 15:58:05.436 HKT
Allocation Summary
---------------------------------------------------
Used: 10941
Excl: 0
Free: 3023
Total: 13964
Utilization: 78%
Pool Name Pool ID VRF Used Excl Free Total
----------- --------- --------- ------ ------ ------ -------
Tier2 2 default 350 0 282 632
pppoe-pool 3 default 10591 0 2741 13332 < --- here
Tonys-MacBook-Air:~ tony18mo$ snmpwalk -v 2c -c xxxx 202.175.100.16 1.3.6.1.4.1.9.9.748.1.2.2.1.10
SNMPv2-SMI::enterprises.9.9.748.1.2.2.1.10.0 = Gauge32: 0
SNMPv2-SMI::enterprises.9.9.748.1.2.2.1.10.1 = Gauge32: 1
SNMPv2-SMI::enterprises.9.9.748.1.2.2.1.10.2 = Gauge32: 350
SNMPv2-SMI::enterprises.9.9.748.1.2.2.1.10.3 = Gauge32: 14255 < --- here
Tonys-MacBook-Air:~ tony18mo$ snmpwalk -v 2c -c xxxxx 202.175.100.16 1.3.6.1.4.1.9.9.748.1.2.2.1.11
SNMPv2-SMI::enterprises.9.9.748.1.2.2.1.11.0 = Gauge32: 254
SNMPv2-SMI::enterprises.9.9.748.1.2.2.1.11.1 = Gauge32: 65533
SNMPv2-SMI::enterprises.9.9.748.1.2.2.1.11.2 = Gauge32: 282
SNMPv2-SMI::enterprises.9.9.748.1.2.2.1.11.3 = Gauge32: 4294966370 < -- here
Conditions:
Workaround:
restart daps process on active engine
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 29-JUL-2015 |
|
Known Affected Releases: | 5.2.4.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv16794 |
Title: | LACP Packet Loss on RPFO makes Access Bundle over Bundle ICL FLAP |
|
Description: | Symptom:
LACP Packet Loss on RPFO makes Access Bundle over Bundle ICL FLAP
Conditions:
When LACP is running over satellite interface which hosts on bundle ICL(bundles-of-si), the sat flap issue is seen upon RPFO. So far the issue is hit on PSI scale config, and test was passing with less scale during bundles-of-si DT. But it could also happen with less scale as long as BML gets respawned late, SPIO init takes time(part of BML init) and IM owned resource notification comes late(As long as the combination of time they are taking is more than 3s(LACP fast mode)/90s(LACP slow mode)).
Workaround:
Not known
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv25714 |
Title: | [SecGW] Segmentation fault during ikesa rekeying |
|
Description: | Symptom:
Segmentation fault at ipsecmgr (ikev2_e_init_ikesa_rekey_migrate)
Conditions:
Segmentation fault at ipsecmgr during ikesa rekey processing of site to site tunnel.
Workaround:
No workaround
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 18.2.M0.60312 |
|
Known Fixed Releases: | 18.2.T0.60617, 18.3.M0.60616, 19.0.M0.60623, 19.0.v0.60625, 19.1.A0.60626, 19.2.A0.60676, 20.0.M0.60661 |
|
|
| |
| |
Bug Id: | CSCuv19410 |
Title: | sysdb_item_get failed issuing show logging |
|
Description: | Symptom:
sysdb_item_get failed while getting the stats errno : 1082230272 'sysdb' detected the 'warning' condition
'A SysDB client tried to access a nonexistent item or list an empty directory'
Conditions:
ASR9k under 4.2.1
issuing show logging
Workaround:
unknown yet
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 4.2.1.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCul39674 |
Title: | Fabric link retrain between typhoon and RSP440 (RX) |
|
Description: | Symptom:
If following syslog is seen then customer might be hitting this issue. Below syslog is very high-level. To confirm whether asr9k is hitting this issue, please check the steps mentioned in "Conditions" section.
In 4.2.x
==========
RP/0/RSP0/CPU0:Nov 21 15:00:17.099 UTC: pfm_node_rp[358]: %PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[233591]|System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP) failed: (0/1/CPU0, 0) (0/1/CPU0, 1) (0/1/CPU0, 2) (0/1/CPU0, 3) (0/1/CPU0, 4) (0/1/CPU0, 5) (0/1/CPU0, 6)
4.3.2 and greater:
==========================
FABMGR[222]: %PLATFORM-FABMGR-5-FABRIC_TRANSIENT_FAULT : Fabric backplane crossbar link underwent link retraining to recover from a transient error: Physical slot 1
Conditions:
Issue is due to fabric retrain in LC ==> RSP direction (RX to RSP).
Collect ltraces from RSP's and LC to confirm whether there was fabric-retrain. All 3 lines of output should match.
Example log:
RP/0/RSP0/CPU0:asr9k#show controllers fabric ltrace crossbar location 0/RSP0/CPU0 | in retrain [or 0/RSP1/CPU0]
Nov 21 14:57:17.494 crossbar 0/RSP0/CPU0 t1 init xbar_trigger_link_retrain: destslot:4 fmlgrp:3 rc:0
Nov 21 14:57:17.494 crossbar 0/RSP0/CPU0 t1 detail xbar_pfm_alarm_callback: xbar_trigger_link_retrain(): (4,1,0) initiated
Nov 21 14:57:17.499 crossbar 0/RSP0/CPU0 t1 detail xbar_fmlc_handle_link_retrain: rcvd link_retrain for (4,1,0),(1,1,0),0 <=== Indicates RSP is receiving fabric retrain from LC in slot 1. See below for slot mapping info
RP/0/RSP0/CPU0:asr9k#
slot matching: [In the above output slot 1 is logical. Below data shows how to match logical-to-physical slot mapping
==============
Chassis Type : 9010
Physical-Slot Logical-slot
==========================
0 0
1 1
2 2
3 3
4 RSP
5 RSP
6 4
7 5
8 6
9 7
Workaround:
No workaround.
This is not a hardware issue. No need for RMA.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 4.2.3.BASE |
|
Known Fixed Releases: | 4.3.2.SP2, 4.3.2.SP3, 4.3.2.SP5, 4.3.2.SP6, 4.3.2.SP7, 4.3.2.SP8, 4.3.4.SP1, 4.3.4.SP4, 4.3.4.SP5, 4.3.4.SP6 |
|
|
| |
| |
Bug Id: | CSCuv54413 |
Title: | bundlemgr_distrib crash after MTU change |
|
Description: | Symptom:
bundlemgr_distrib process crashed
crash occurred after MTU was changed on the BE
RP/0/RSP1/CPU0:BNL01#sh configuration commit changes 1000000587
Mon Jul 6 09:36:17.873 EDT
Building configuration...
!! IOS XR Configuration 4.3.4
interface Bundle-Ether100
mtu 9216
!
Perviously it was set to 9212
RP/0/RSP0/CPU0:Jul 1 16:59:57.617 : dumper[60]: %OS-DUMPER-7-DUMP_REQUEST : Dump request for process pkg/bin/bundlemgr_distrib
RP/0/RSP0/CPU0:Jul 1 16:59:57.618 : dumper[60]: %OS-DUMPER-7-DUMP_ATTRIBUTE : Dump request with attribute 7 for process pkg/bin/bundlemgr_distrib
RP/0/RSP0/CPU0:Jul 1 16:59:57.618 : dumper[60]: %OS-DUMPER-4-SIGSEGV : Thread 1 received SIGSEGV - Segmentation Fault
RP/0/RSP0/CPU0:Jul 1 16:59:57.618 : dumper[60]: %OS-DUMPER-4-SIGSEGV_INFO : Accessed BadAddr 0x68 at PC 0x420c7be. Signal code 1 - SEGV_MAPPER. Address not mapped.
RP/0/RSP0/CPU0:Jul 1 16:59:57.619 : dumper[60]: %OS-DUMPER-4-CRASH_INFO : Crashed pid = 577826 (pkg/bin/bundlemgr_distrib)
Conditions:
MTU change under the Bundle-ether caused the crash
Workaround:
crash never recovered and was in continuous loop, had to switchover RSP for the bundle-ether to function again
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 4.3.4.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCup02697 |
Title: | snmpd crash @ ipv4_acl_objgrp_unregister |
|
Description: | Symptom:
snmpd process unexpectedly restarts with the below condition. This happens in active/standby
Conditions:
This was mainly observed in commit replace
Workaround:
remove snmpd with acl configuration to avoid this. This WA is not customer friendly WA.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 5.1.3.BASE, 5.2.0.BASE |
|
Known Fixed Releases: | 5.1.3.15i.FWDG, 5.3.1.3i.FWDG, 6.0.0.5i.FWDG |
|
|
| |
| |
Bug Id: | CSCuv56065 |
Title: | LER PBTS: seeing nr ldi buddy reserve: failed on PBTS to LER transistion |
|
Description: | Symptom:
Traffic loss and continuous tracebacks from PBTS to LER transistion.
Conditions:
PBTS LER
Workaround:
NOne
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo29028 |
Title: | ASR9K/4.3.4 Route not deleted after dhcpv4 proxy bind deletion |
|
Description: | Symptom:
ASR9K is not removing the routes from the routing table, when the DHCP binding is removed. The following error message will be seen. Due to this, there will be random delay for some clients in getting IP address.
ipv4_rib[1135]: %ROUTING-RIB-3-ECMP_ERR_ADD : Path add exceed max number of paths supported by protocol. Table 0xe0000015, prefix 91.105.33.81/32, protocol subscriber, intf 0x800df60, tunnelid 0, nexthop_table 0xe0000015, nexthop 0.0.0.0
Conditions:
ASR9K configured as DHCP proxy
Workaround:
Remove the route from the routing table manually or using EEM scripts
Further Problem Description:
During some binding removal the routes are not removed from RIB. When this IP is assigned to new clients, ASR9k proxy will fail to add the route to RIB, so IP assigning to client will fail. Due to this, there will be random delay for some clients in getting IP address.
As part of fix we make sure we always clear existing RIB route paths before we add new one. The fix can be incorporated as a process restart SMU for 4.3.4 and reload SMU for 5.1.3 [as there is existing DHCP reload SMU on 5.1.3]
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 4.3.4.BASE |
|
Known Fixed Releases: | 5.3.2.18i.FWDG, 5.3.3.3i.FWDG |
|
|
| |
| |
Bug Id: | CSCut16081 |
Title: | [pipd-54] xmen_cluster IRL links fails to come up |
|
Description: | Symptom:
IRL links fails to come up with following errors, and the error continue.
cluster_dlm_lc[146]: %PLATFORM-UDLD-4-DISABLE_PORT : UDLD protocol detected Uni-directional link on [0x4000140][2050][0], Port Disabled
cluster_dlm_lc[146]: %PLATFORM-NVEDGE_DATA-3-ERROR_DISABLE : Interface 0x4000140 has been uni directional for 10 seconds, this might be a transient condition if a card bootup / oir etc.. is happening and will get corrected automatically without any action. If its a real error, then the IRL will not be available fo forwarding inter-rack data and will be missing in the output of show nv edge data forwarding cli
Conditions:
Up on image loading of LC that hosting the IRL - memboot / Turboboot, rack reload, system reload, IRL links are down.
This is timing issue, and rare occurrence.
Workaround:
Need LC reload.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: | 5.3.1.24i.BASE, 5.3.2.3i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
Bug Id: | CSCuv01325 |
Title: | auto backup path computation does not use SRLG diverse path |
|
Description: | Symptom:
auto backup path computation does not use SRLG diverse path
Conditions:
In an MPLE TE environment with primary and backup paths utilizing SRLG diverse path. Issue exists in 513 and was introduced via CSCui63737. Issue does not impact 531
Workaround:
There is no workaround
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 5.1.3.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv56118 |
Title: | PTP_MA process crashing repeatedly and filling up hard disk space |
|
Description: | Symptom:
Continous loop of PTP_MA process crashing.
Conditions:
Normal condition.
Workaround:
None
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 4.3.4.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv49846 |
Title: | [ci-msl-bnb-dev2] qos_ma_ea process crash on ironman LC |
|
Description: | Symptom:
qos_ma_ea process crashing on IRONMAN LC
Conditions:
after removing QOS policer from interface
config
Wed Jul 22 03:24:01.738 UTC
interface GigabitEthernet0/0/0/11.100
no service-policy input iVista-POLICER
commit
Wed Jul 22 03:24:02.946 UTC
end
policy-map iVista-POLICER
class class-default
police rate 25 mbps
conform-action transmit
exceed-action drop
exit
exit
end-policy-map
commit
Workaround:
None
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 1 Catastrophic |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv02783 |
Title: | BGP route-policy drops all prefixes after RPFO |
|
Description: | Symptom:
BGP route-policy drops all the prefixes
Conditions:
This problem occurs after an RP/RSP switchover
Workaround:
re-commit the route-policy for the affected neighbors
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 4.3.2.ROUT |
|
Known Fixed Releases: | 5.3.3.3i.ROUT |
|
|
| |
| |
Bug Id: | CSCuv00365 |
Title: | ipv4_io, ipv6_ea processes blocked on fib_mgr with IGP scale on TE tun |
|
Description: | Symptom:
see processes ipv4_io and ipv6_ea blocked on fib_mgr
Conditions:
ipv4 and ipv6 IGP scale with TE tunnels.
Workaround:
none
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuq09884 |
Title: | RSP4/RSP3 STDBY side RSP0 fails to come up, reboot, then comes up |
|
Description: | Symptom:
The standby side (RSP0) fails to come up, reboot, then comes up.
Conditions:
This issue is seen only when Tomahawk board is present in the chassis. Tomahawk board targeted for 5.3.0 release. So the fix is not needed for 52x releases.
Workaround:
Remove Tomahawk board. Or wait for Standby side to fail for first time. It will boot perfectly in second time.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 5.3.0.BASE |
|
Known Fixed Releases: | 5.3.0.3i.BASE |
|
|
| |
| |
Bug Id: | CSCuj61661 |
Title: | Possible snmpd memory leak |
|
Description: |
Symptom:When we see Dispatch error in show snmp trace request,
Conditions:snmp_msg was not free when dispatch request failed or duplicate request cleanup the request if packet morethan 10sec in processing queue .
Because of SLOW OIDs some of the requests takes more than 10 sec to get the response. Where duplicate feature is enabled and dropped those requests
Workaround:snmpd itself restarted then recover few sec and working snmp functionality.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 4.2.3.BASE, 4.3.2.BASE, 5.0.1.BASE |
|
Known Fixed Releases: | 4.3.3.BASE, 4.3.31.7i.BASE, 4.3.4.7i.BASE |
|
|
| |
| |
Bug Id: | CSCuv51629 |
Title: | ipv6_rib dumps core silently on the node on stdby RP |
|
Description: | Symptom:
The symptom of the issue is ipv6_rib dumping core on t stanby RP.
Conditions:
This issue is seen silently without any trigger.
Workaround:
None
Further Problem Description:
None
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu90886 |
Title: | Accounting rate counters are not correct for Bundle-ether on Tomahawk |
|
Description: | Symptom:
We have a mixed bundle 701 on uplink, it is of 180GIG bandwidth and has nine member links ( one hundred GIG and 8 10GIG) in Tomahawk line card. I am sending continuously around 180GE of traffic on this uplink. The policy map counters are correct , but "show interface accounting rate counters" are not correct, it reached to 180GIG and then decrease to 90GIG.
Can some body look on this ...
RP/0/RSP0/CPU0:PHLASR2#sho policy-map interface bundle-ether 701 out | in Trans
Fri Jun 12 13:17:57.334 EDT
Transmitted : 8327236/16679965504 1772380
Transmitted : 2979784/5272674336 100578
Transmitted : 2494478937/4988939917136 162135232
Transmitted : 164112374/328209215968 7865480
RED Transmitted (packets/bytes) : N/A
RED Transmitted (packets/bytes) : N/A
Transmitted : 286128236/279213670309 6315346
RED Transmitted (packets/bytes) : N/A
RED Transmitted (packets/bytes) : N/A
RED Transmitted (packets/bytes) : N/A
RP/0/RSP0/CPU0:PHLASR2#
RP/0/RSP0/CPU0:PHLASR2#
RP/0/RSP0/CPU0:PHLASR2#
RP/0/RSP0/CPU0:PHLASR2#
RP/0/RSP0/CPU0:PHLASR2#sho int bundle-ether 701 accounting rates
Fri Jun 12 13:19:10.094 EDT
Bundle-Ether701
Ingress Egress
Protocol Bits/sec Pkts/sec Bits/sec Pkts/sec
IPV4_UNICAST 415000 1084 308000 838
IPV4_MULTICAST 7000 1 5000 1
MPLS 158577000 112183 198681772000 14284611
ARP 0 0 0 0
Conditions:
all the time
Workaround:
show interface <> are better or show policy-map interface
Further Problem Description:
The show interface accounting rate counters, is showing that the traffic is rate is decreasing and then increasing, even though the traffic generator is showing constant traffic rate. This is not just on the egress bundle, but also on the ingress regular interface. Also the traffic rate is constant with the show interface counters and show policy-map counters.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv51709 |
Title: | [nVSSU] vpath does not work on Tomahawk |
|
Description: | Symptom:
CLI-Based PBR might not work on Tomahawk
Conditions:
Apply CLI-Based PBR on Tomahawk
Workaround:
none
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuv57209 |
Title: | ASR9k ARP Crash Taildrop on XIPC queue 2 owned by arp |
|
Description: | Symptom:
ARP Crash in BNG environment.
Conditions:
arp crash
These precede the crash:
RP/0/RSP0/CPU0:Jul 4 03:28:35 CETDST: udp[449]: %PKT_INFRA-PQMON-6-QUEUE_DROP : Taildrop on XIPC queue 2 owned by dhcpd (jid=1082)
LC/0/1/CPU0:Jul 4 03:44:46 CETDST: netio[285]: %PKT_INFRA-PQMON-6-QUEUE_DROP : Taildrop on XIPC queue 2 owned by arp (jid=120)
LC/0/1/CPU0:Jul 4 05:35:50 CETDST: netio[285]: %PKT_INFRA-PQMON-6-QUEUE_DROP : Taildrop on XIPC queue 2 owned by arp (jid=120)
Workaround:
none
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 30-JUL-2015 |
|
Known Affected Releases: | 5.1.3.BASE |
|
Known Fixed Releases: | |
|
|
| |
2013 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论