| |
|
Alert Type: | Updated * |
Bug Id: | CSCur07854 | Title: | VPLS/VPWS/PWHE L2 traffic stops after PW neighbor reachability changes |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
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.
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 5.1.3.BASE, 5.3.0.BASE, 5.3.0.LC |
|
Known Fixed Releases: * | 4.2.0, 4.2.1, 4.2.2, 4.2.3, 4.2.4, 5.0.0, 5.0.1, 5.0.90, 5.1.3.SP1, 5.1.3.SP2 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo17901 | Title: | Out of order mcast packets introduced by ASR9K MLDP+bundle |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
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:
|
|
Last Modified: | 14-SEP-2015 |
|
Known Affected Releases: | 4.3.4.MCAST |
|
Known Fixed Releases: * | 4.1.1, 4.1.2, 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 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu00818 | Title: | sysdb_shared_sc crash |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
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.
|
|
Last Modified: | 28-SEP-2015 |
|
Known Affected Releases: | 5.1.3.BASE, 5.3.2.BASE |
|
Known Fixed Releases: * | 5.3.2, 5.3.2.12i.BASE, 6.0.0.10i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv77083 | Title: | [ci-msl] Continuous icpe_satmgr on active RSP duirng image boot |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
icpe_satmgr process crashing on active rsp/rp
Conditions:
During image boot
Workaround:
None
Further Problem Description:
None
|
|
Last Modified: | 28-SEP-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: * | 4.2.1, 4.2.2, 4.2.3, 4.2.4, 4.3.0, 4.3.1, 4.3.2, 4.3.3, 4.3.31, 4.3.4 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv90250 | Title: | IPv6 Traffic on SAT Access dropped on Ingress with 8X100GE as ICL Link |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
IPv6 Traffic on SAT Access dropped on Ingress with A9K-8X100GE as ICL Link
Conditions:
Ipv6 Traffic + A9K-8X100GE as ICL Link
Workaround:
Not known
Further Problem Description:
|
|
Last Modified: | 05-SEP-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: * | 5.3.2.BASE, 5.3.3.8i.BASE, 6.0.0.13i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup45536 | Title: | CEF not updated for recur lev 2 prefix when adding static route to NULL |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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:
|
|
Last Modified: | 09-SEP-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, 5.2.2.17i.FWDG, 5.2.21, 5.2.3.6i.FWDG |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuh55354 | Title: | 4.3.1.CCO: ASR9K POS int with HDLC encap flap when oversubscribe |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
CHDLC interface flaps with oversubscribed traffic.
Conditions:
Issue happens only with over-subscribed traffic on CHDLC interface.
Workaround:
Lower the traffic rate to not oversubscribe the link.
Further Problem Description:
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 4.3.1.BASE, 4.3.2.BASE, 5.1.1.BASE |
|
Known Fixed Releases: * | 4.3.2, 4.3.2.25i.FWDG, 4.3.3, 4.3.31, 4.3.4, 5.0.1.99i.BASE, 5.1.0, 5.1.0.16i.FWDG, 5.1.1, 5.1.11 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue29270 | Title: | pbr_ea crash when apply class-map to policy-map |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
HTTP redirection after two policy-map type pbr service activation/deactivation
Conditions:
When web-login is successful, normal http redirection service is deactivated on subscriber session and http redirection service (only to particular websites) is pushed from policy-server or CLI activated., Which triggers the issue and which results in non-working of later activated http redirection service.
Workaround:
None
More Info:
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 4.3.1.ADMIN, 4.3.1.BASE, 4.3.1.FWDG, 4.3.1.MGBL, 4.3.1.ROUT, 4.3.1.TOOLS, 5.1.1.BASE |
|
Known Fixed Releases: * | 4.3.2.29i.FWDG, 5.1.0, 5.1.0.16i.FWDG, 5.1.1, 5.1.11, 5.1.12, 5.1.2, 5.1.3, 5.1.4, 5.2.0 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun90576 | Title: | 520: memory leaks in exec process with SNMP polling |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
memory leaks in exec process
Conditions:
memory leak is seen for any command applied in exec mode
Workaround:
Not available
Further Problem Description:
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 5.1.1.BASE, 5.2.0.BASE |
|
Known Fixed Releases: * | 5.1.1.SP3, 5.1.1.SP4, 5.1.1.SP5, 5.1.1.SP6, 5.1.11.BASE, 5.1.12, 5.1.12.1i.BASE, 5.1.2, 5.1.2.23i.BASE, 5.1.3 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtz87422 | Title: | 422-SIT: Sub-interface doesn't count multicast traffic packets |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Ingress multicast and MVPN traffic rate and packet counts are not displayed under sub-interface
Conditions:
Enable multicast traffic to ingress over a sub-interface
Workaround:
None, though the statistics on the parent interface are displayed
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 4.2.1.BASE, 4.2.2.BASE |
|
Known Fixed Releases: * | 4.2.2, 4.2.2.12i.BASE, 4.2.3, 4.2.3.20i.BASE, 4.2.4, 4.3.0, 4.3.0.20i.BASE, 4.3.1, 4.3.2, 4.3.3 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur28123 | Title: | te_control crash while traffic is running |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
te_control crash seen
Conditions:
running traffic over mpls-te and snap background polling
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 5.2.2.BASE, 5.3.0.MPLS |
|
Known Fixed Releases: * | 3.9.0, 3.9.1, 3.9.2, 3.9.3, 4.0.0, 4.0.1, 4.0.2, 4.0.3, 4.0.4, 4.1.0 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq81002 | Title: | ICCP-SM State remains unsynchronous after interface/vlan change |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:ICCP-SM remains in unsynchronised state between two peers
Conditions:An interface/vlan configuration change will trigger the issue, more particularly removing and re-adding an interface under
l2vpn
redundancy
iccp group
(no) interface
Workaround:Process restart l2vpn_mgr on both ICCP-SM peer nodes.
More Info:
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 4.3.4.BASE, 5.1.1.BASE, 5.1.2.BASE |
|
Known Fixed Releases: * | 5.1.3.SP2, 5.1.3.SP3, 5.1.3.SP4, 5.2.3.99i.BASE, 5.2.4.5i.FWDG, 5.3.0, 5.3.0.11i.FWDG, 5.3.1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCty37179 | Title: | ACL: Incorrect handling of remark ACEs in the library |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 4.0.3.BASE, 4.1.1.BASE |
|
Known Fixed Releases: * | 4.2.1.25i.FWDG, 4.2.3, 4.2.3.7i.FWDG, 4.2.4, 4.3.0, 4.3.0.8i.FWDG, 4.3.1, 4.3.2, 4.3.3, 4.3.31 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue90697 | Title: | NTPd process does not receive Backup Process role notification |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:Certain processes do not receive role change notifications on a failover. Currently we know of atleast TCP and ntpd being affected by this after a failover.
Conditions:Happens on a ASR9010 cluster based setup or on the role of the node changing from non DSC to a backup DSC.
Workaround:Restart of the affected process on standby RP should recover the issue.
More Info:
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 4.2.3.BASE, 4.2.31.TOOLS, 5.1.0.BASE |
|
Known Fixed Releases: * | 4.3.1, 4.3.1.26i.BASE, 4.3.2, 4.3.2.11i.BASE, 4.3.3, 4.3.31, 4.3.4, 5.1.0, 5.1.0.3i.BASE, 5.1.1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCub18286 | Title: | EIGRP not advertising prefix to downstream neighbors in some cases |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
EIGRP not advertising prefix to downstream neighbors in some cases
Conditions:
In a router if for a prefix there are both internal and external path (via redistribution) and if the internal path is seen as "backup in RIB" and is seen before the external path in "show eigrp topology "
Workaround:
If acceptable make the internal path "not in RIB" by changing the metrics of the external path. Configure "default-metric" or "route-policy" for redistribution such that EIGRP does not install the internal path in RIB.
In the below example, if is greater than , then EIGRP will not install the internal path in RIB.
RP/0/0/CPU0:ios#show eigrp topology 100.100.100.100/32
Mon Jul 23 13:21:23.964 IST
IPv4-EIGRP AS(1): Topology entry for 100.100.100.100/32
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 28160
Routing Descriptor Blocks:
10.10.4.3, from Redistributed, Send flag is 0x0
Composite metric is (/), Route is External
Vector metric:
Minimum bandwidth is Kbit
Total delay is microseconds
Reliability is 100/255
Load is 100/255
Minimum MTU is 100
Hop count is 0
External data:
Originating router is 10.10.0.2 (this system)
AS number of route is 1
External protocol is BGP, external metric is 10
Administrator tag is 100 (0x00000064)
10.10.0.1 (GigabitEthernet0/0/0/0), from 10.10.0.1, Send flag is 0x0
Composite metric is (/), Route is Internal, not in RIB
Vector metric:
Minimum bandwidth is Kbit
Total delay is microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 3.9.0.ROUT, 4.0.1.ROUT, 4.2.0.ROUT, 4.3.0.ROUT |
|
Known Fixed Releases: * | 4.2.3, 4.2.3.24i.ROUT, 4.2.4, 4.3.0, 4.3.0.22i.ROUT, 4.3.1, 4.3.2, 4.3.3, 4.3.31, 4.3.4 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup78472 | Title: | XML PrefixSetTable overrun causes RP to reload. |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Special crafted XML query to set Prefix Tables in BGP causes parser_server to crash. Additional queries cause the RP to reload.
Conditions:
* MGBL Pie is loaded
* XML is Enabled
Configure RPL policies/sets with some lines with more than 1024 characters using xml.
Workaround:
Disable XML
No xml agent tty
Further Problem Description:
The issue happens on configuring RPL with more than 1024 characters in a line using XML.
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 4.3.1.MGBL, 5.1.1.MGBL, 5.1.2.MGBL |
|
Known Fixed Releases: * | 5.1.3.SP2, 5.1.3.SP3, 5.1.3.SP4, 5.2.2, 5.2.2.23i.ROUT, 5.2.21, 5.2.3.8i.ROUT, 5.3.0, 5.3.0.8i.ROUT, 5.3.1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus85007 | Title: | ospfv3 neighbor never comes up after FO |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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:
|
|
Last Modified: | 09-SEP-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, 5.3.1.22i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue21593 | Title: | Umbrella EIGRP SMU |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Umbrella SMU for ASR9K EIGRP fixes
Conditions:
This umbrella SMU contains fixes for the following 3 DDTS's
CSCty72853
CSCtz82543
CSCua92536
Workaround:
Please see the individual Cisco bug IDs for further details.
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 4.2.0.ROUT, 4.2.3.BASE |
|
Known Fixed Releases: * | 4.3.2.99i.BASE, 5.0.1.99i.BASE, 5.1.0, 5.1.1, 5.1.11, 5.1.12, 5.1.2, 5.1.3, 5.1.4, 5.2.0 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCty99591 | Title: | aipc_proxy keeps crashing on BNG pie activation/deactivation |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
AIPC Proxy process ( process name : aipc_proxy ) crashes continuously.
Conditions:
On BNG pie activation-deactivation one might see this issue.
Workaround:
There is no workaround. The only way to recover is to reload the node where the aipc_proxy process is crashing.
Further Problem Description:
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 4.2.1.BASE, 4.3.0.BASE |
|
Known Fixed Releases: * | 4.2.3, 4.2.3.27i.BASE, 4.2.4, 4.3.0, 4.3.0.12i.BASE, 4.3.1, 4.3.2, 4.3.3, 4.3.31, 4.3.4 |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw17288 | Title: | 5.3.2 mb-ipsec umbrella |
|
Status: | Other |
|
Severity: | 2 Severe |
Description: | Symptom:
This is an umbrella CDETS record for:
CSCuv44586: MB IPSec: 2048-bit RSA key size for rekey messages is not working
CSCuv01068: MB-IPSEC:Interop with 6500 - Authentication errors at ASR9k DPVM
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 10-SEP-2015 |
|
Known Affected Releases: | 5.3.2.K9SEC |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut12758 | Title: | SSTE: Observing prm_server_ty process crash after MPA oir |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
wdsysmon detects and reports a deadlock within the prm_server_ty process and
as a result it restarts the prm_server_ty process. An example of the deadlock report
that appears in the syslog is:
LC/0/2/CPU0:Mar 24 14:53:45 EST: wdsysmon[391]: DEADLOCK
LC/0/2/CPU0:Mar 24 14:53:45 EST: wdsysmon[391]: =============================
LC/0/2/CPU0:Mar 24 14:53:45 EST: wdsysmon[391]: node pid tid name STATE node pid tid name
LC/0/2/CPU0:Mar 24 14:53:45 EST: wdsysmon[391]: deadlock 1 num_entries 2-----------
LC/0/2/CPU0:Mar 24 14:53:45 EST: wdsysmon[391]: node0_2_CPU0 172114 1 prm_server_ty MUTEXnode0_2_CPU0 172114 23 prm_server_ty
LC/0/2/CPU0:Mar 24 14:53:45 EST: wdsysmon[391]: node0_2_CPU0 172114 23 prm_server_ty MUTEXnode0_2_CPU0 172114 1 prm_server_ty
LC/0/2/CPU0:Mar 24 14:53:45 EST: wdsysmon[391]: ============================
The process id (pid) and thread id (tid) values may vary.
Conditions:
A Modular Port Adapter (MPA) in a modular linecard on the ASR9000 has been
reloaded with either a physical online insertion and removal (OIR) or with by
way of the "hw-module subslot reload" command.
Workaround:
There is no workaround. The process recovers after it is restarted by wdsysmon.
Further Problem Description:
There is no traffic impact resulting from the deadlock or process restart. There
may be a temporary delay in handling network topology updates until after
the process restart is completed.
|
|
Last Modified: | 10-SEP-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: | 5.3.2.12i.BASE, 6.0.0.10i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq20496 | Title: | ipv6 linklocal ping and gobal ping not working on bvi interface |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
BVI v6 sessions fail on ASR9K chassis with EP based Modular LCs and ASR9001 board.
Conditions:
The issue is observed on a ASR9K chassis that hosts only MOD LCs (EP based LC) or on a ASR9001 board.
The IOS-XR version is 5.1.0, 5.1.1, 5.1.2, 5.1.3, 5.2.0.
Workaround:
Attempt restarting the "ipv6_nd" process on the RP.
If this does not work, try reloading the MOD LC on the ASR9K chassis or reload the LC on the ASR9001.
Further Problem Description:
|
|
Last Modified: | 10-SEP-2015 |
|
Known Affected Releases: | 5.1.0.BASE, 5.1.1.BASE, 5.1.2.BASE, 5.1.3.BASE, 5.2.0.BASE, 5.2.2.ADMIN |
|
Known Fixed Releases: * | 5.1.3.SP2, 5.1.3.SP3, 5.1.3.SP4, 5.2.2, 5.2.2.24i.BASE, 5.2.21, 5.2.3.8i.BASE, 5.3.0, 5.3.0.10i.BASE, 5.3.1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv94339 | Title: | eXR: "show led" is broken in 6.0.0.12AG image |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
"show led" is broken.
Conditions:
Execute "show led" command.
Workaround:
Unknown.
Further Problem Description:
|
|
Last Modified: | 12-SEP-2015 |
|
Known Affected Releases: | 6.1.0.BASE |
|
Known Fixed Releases: * | 6.0.0.14i.BASE |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCul49426 | Title: | 511-SIT: Large TM_LOOP counters for BFD session with HW offlload |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: | Symptom:After enabling BFD HW offload, the following NP counters can be seen to increment in "show controller np" output:
49 PARSE_TM_LOOP_RECEIVE_CNT 641644 159931
316 RSV_DROP_EGR_HWOFF_NO_MATCH 641540 159905
Conditions:ASR9K software supporting OAM or BFD hw offload feature.
Workaround:None. However this is normal behavior and no loop and no drop does occur. The incrementing of these counters just reflects the usage of the hardware offload path for BFD and OAM packets.
More Info:
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: | 5.1.1.BASE, 5.4.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuh95898 | Title: | [PPPoE DS] dhcp release and restarting doesnt sent ipv6 addr to client |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
First DHCPv6-PD request is fulfilled.
if the prefix is released any additional DHCPv6-PD request would fail until the session is active
Conditions:
DHCPv6-PD
Workaround:
No Workaround
Further Problem Description:
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: | 5.1.1.BASE |
|
Known Fixed Releases: | 5.1.1, 5.1.1.6i.FWDG, 5.1.11, 5.1.11.4i.FWDG, 5.1.12, 5.1.2, 5.1.3, 5.1.4, 5.2.0, 5.2.0.2i.FWDG |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv84562 | Title: | On Router Reload - many process crashed , following IFMGR crash. |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
On Router Reload - many process crashed , following IFMGR crash.
Conditions:
Router Reload
Workaround:
Not Required , ALL PROCESS recovered after the crash
Further Problem Description:
|
|
Last Modified: | 12-SEP-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: * | 5.3.3.9i.FWDG, 6.0.0.14i.FWDG |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv56865 | Title: | Native EVPN routes still advertised with "advertise l2vpn evpn disable" |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
BGP Native L2VPN EVPN routes are still being advertised even configure "advertise l2vpn evpn disable"
Conditions:
5.3.2
Workaround:
un-configure and reconfigure the neighbor
Further Problem Description:
|
|
Last Modified: | 12-SEP-2015 |
|
Known Affected Releases: | 5.3.2.ROUT |
|
Known Fixed Releases: * | 6.0.0.14i.ROUT |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw15728 | Title: | PBB-EVPN: RR doesn't reflect Type-4 route to other PE with RT_Constraint |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
PBB-EVPN: RR doesn't reflect "Type-4 Ethernet Segment route" to other PEs with RT_Constraint
Conditions:
5.3.2
Workaround:
remove BGP RT_Constraint config from RR
Further Problem Description:
|
|
Last Modified: | 13-SEP-2015 |
|
Known Affected Releases: | 5.3.2.ROUT |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun81835 | Title: | sysdb_mc Memory Leak in 5.1.0 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Memory Leak observed on sysdb_mc_420 & sysdb_svr_local_425
Conditions:
Issue observed on all the router upgraded to 5.1.0 code
Workaround:
Restarted the sysdb_mc_420 & sysdb_svr_local_425 processes.
Further Problem Description:
|
|
Last Modified: | 16-SEP-2015 |
|
Known Affected Releases: | 5.1.0.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.11.BASE, 5.1.12, 5.1.12.2i.BASE, 5.1.3, 5.1.3.8i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut27671 | Title: | FIB_MGR Crash when executing "show cef resource hardware ingress detail" |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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:
|
|
Last Modified: | 16-SEP-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: * | 5.3.1, 5.3.1.24i.BASE, 5.3.1.24i.FWDG, 5.3.2.3i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv25714 | Title: | [SecGW] Segmentation fault during ikesa rekeying |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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:
|
|
Last Modified: | 16-SEP-2015 |
|
Known Affected Releases: | 18.2.M0.60312 |
|
Known Fixed Releases: * | 18.2.T0.60617, 18.3.0, 18.3.0.60819, 18.3.M0.60616, 18.3.a0, 18.3.v0, 18.3.v0.61344, 19.0.M0.60623, 19.0.v0.60625, 19.1.A0.60626 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv44058 | Title: | CMPv2 initialization response message parsing failure |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
CMPv2 Initialization response message received from the CA-Server fails with parsing failure error logs as mentioned below.
"Certificate Name: cert001, Received HTTP message does not haave valid content length."
Conditions:
The error is seen for the CMPv2 Initialization response message received from the CA-Server.
Workaround:
No Workarounds identified.
Further Problem Description:
|
|
Last Modified: | 16-SEP-2015 |
|
Known Affected Releases: | 18.3.M0 |
|
Known Fixed Releases: * | 18.2.T0.60746, 18.3.0, 18.3.0.60819, 18.3.M0.60730, 18.3.a0, 18.3.v0, 18.3.v0.61344, 18.4.A0.60735, 19.0.M0.60728, 19.0.v0.60722 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw01277 | Title: | A9K-8X100-SE unable to receive traffic with Cisco 15454 after port flap |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Bringing up new links or after a fiber cut. The links get into a unidirectional traffic forwarding condition.ASR9K is able to transmit traffic. But receive packets will be dropped.
Conditions:
Version 5.3.1
This is an interoperability issue between ASR 9000 (A9K-8X100-SE/TR or A9K-4X100-SE/TR) and M6 / NCS2K-100G-CK linecard.
This issue is not applicable to PIDs A9K-8X100-L-SE/TR, A9K-2X100G-SE/TR and A9K-1X100-SE/TR.
The issue happens only when link flaps or comes up in DWDM core network or trunk port.
A9K-8X100GE-TR (or A9K-8X100GE-TR) <-> CPAK-100G-SR10 (on ASR card) <-> CPAK-100G-SR10 (on optical card) <->
NCS2K-200G-CK-LIC (DWDM w/ 20% SD FEC) <-> 600 to 1000 km optical fiber with MSTP amps, ROADMs, etc. <->
NCS2K-200G-CK-LIC (DWDM w/ 20% SD FEC) <-> CPAK-100G-SR10 (on optical card) <->
CPAK-100G-SR10 (on ASR card) <-> A9K-8X100GE-TR (or A9K-8X100GE-TR)
Workaround:
There is no workaround to prevent this issue. One and only known recovery mechanism is to reload the LC
Further Problem Description:
|
|
Last Modified: | 18-SEP-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: * | 5.3.3.10i.BASE, 6.0.0.15i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv65231 | Title: | line card fails to boot up due to mqueue leak |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
ASR9k running 5.1.3 + SP2 fails to boot up line card
if we attach to the console of the line card,we see this
Performing tftpdnld
tsec_init_hw: configuring TSEC (port 1) for: 1GB, Full Duplex
tsec_init_interface: hardware initialization completed
tftp_service_timeout: CONNECT RETRY! retry=18.
tftp_service_timeout: CONNECT RETRY! retry=17.
tftp_service_timeout: CONNECT RETRY! retry=16.
tftp_service_timeout: CONNECT RETRY! retry=15.
Conditions:
incorrect upgrade procedure followed,information to be edited once final trigger is found
Workaround:
-process restart mqueue
-process restart mqueue location
Further Problem Description:
|
|
Last Modified: | 18-SEP-2015 |
|
Known Affected Releases: | 5.1.3.BASE |
|
Known Fixed Releases: * | 5.3.3.9i.BASE, 6.0.0.15i.BASE |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw29848 | Title: | [533]-Traffic loss after restarting ospf process with mpls gre configs |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
Traffic gets dropped with Gre Over MPLS Configs
Conditions:
After restarting process ospf
Workaround:
NA
Further Problem Description:
NA
|
|
Last Modified: | 18-SEP-2015 |
|
Known Affected Releases: | 5.3.3.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus09289 | Title: | [531]-Mcast traffic dropped after LC reloaded and NULL BVI uidb. |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Multicast Traffic will be getting dropped over BVI and PW-HE interfaces
Conditions:
Multicast is enabled in the global table or a VRF, with forwarding over Virtual interfaces, such as BVI and PW-HE interfaces. After an LC Reload, traffic forwarding stop over such interfaces.
Workaround:
None
Further Problem Description:
This issue is present only in XR 5.2.2 and 5.3.0 releases. Other releases do not have this issue. There is a related issue, CSCuw01943 that may be the better match for 5.1.3.
|
|
Last Modified: | 20-SEP-2015 |
|
Known Affected Releases: | 5.2.2.MCAST, 5.3.1.BASE, 5.4.0.BASE |
|
Known Fixed Releases: | 3.8.3, 3.8.4, 3.9.0, 3.9.1, 3.9.2, 3.9.3, 4.0.0, 4.0.1, 4.0.2, 4.0.3 |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw10162 | Title: | TM performance issue with multiple ingress priority. |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:packet drop when we have priority level 1 with police rate percent 100 and class default with default priority level.
Conditions:when you have 2 classes with different priority level
Workaround:If we remove the priority level 1 then there is no traffic drop.. have all class with same prioriity..
More Info:none
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv02783 | Title: | BGP route-policy drops all prefixes after RPFO |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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:
|
|
Last Modified: | 25-SEP-2015 |
|
Known Affected Releases: | 4.3.2.ROUT |
|
Known Fixed Releases: * | 5.3.2, 5.3.2.19i.BASE, 5.3.2.19i.FWDG, 5.3.2.19i.ROUT, 5.3.3.3i.ROUT, 5.3.3.5i.BASE, 5.3.3.5i.FWDG, 5.3.3.5i.ROUT, 6.0.0.12i.BASE, 6.0.0.12i.FWDG |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw40980 | Title: | [600]-Empty redundancy Info seen in "Show Redundancy" cli after FO & FB |
|
Status: | Other |
|
Severity: | 2 Severe |
Description: | Symptom:
Empty redundancy Info seen in ??show redundancy?? cli after FO & FB
Conditions:
In 600.14I Image, Empty redundancy Info seen in ??show redundancy?? cli after FO & FB.
Workaround:
NA
Further Problem Description:
|
|
Last Modified: | 25-SEP-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq90194 | Title: | [530] IPv6 remote Fragmented Ping failed on typhoon LC |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
IPV6 remote fragmented ping fails
Conditions:
Typhoon LC
Workaround:
NA
Further Problem Description:
|
|
Last Modified: | 28-SEP-2015 |
|
Known Affected Releases: | 5.3.0.BASE |
|
Known Fixed Releases: * | 5.2.4.5i.BASE, 5.3.0, 5.3.0.9i.BASE, 5.3.1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut60174 | Title: | Service Update is not updated to LC subscribers |
|
Status: | Fixed |
|
Severity: | 2 Severe |
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:
|
|
Last Modified: | 28-SEP-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: * | 5.3.2, 5.3.2.8i.FWDG, 6.0.0.5i.FWDG |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut84353 | Title: | Session bringup fails with pqos service after RPFO |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Subscriber session bringup fails
Conditions:
After RPFO
Workaround:
None
Further Problem Description:
Doing RPFO with pqos service enabled subscribers causes session setup failure of new subscriber session which uses same pqos service.
|
|
Last Modified: | 28-SEP-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: * | 5.3.2, 5.3.2.8i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup73975 | Title: | 100Gig LC policer rate not updated with deleting ingress netflow |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
This is applicable to card A9K-2x100GE-TR on A9K-2x100GE-SE if the other fix CSCun97435 and CSCuo95719 are installed.
If ingress and egress both netflow is enabled on 100Gig interface and if we remove the ingress netflow , the policer rate for egress netflow will be not set properly and so PUNT_NETFLOW np counter will not be same as expected policer rate.
Conditions:
Workaround:
To apply the egress netflow only first remove the ingress and egress both netflow from interface and freshly configure the egress netflow only and policer rate will programmed correctly.
Further Problem Description:
|
|
Last Modified: | 28-SEP-2015 |
|
Known Affected Releases: | 5.1.2.BASE |
|
Known Fixed Releases: * | 5.1.2.SP2, 5.1.2.SP3, 5.1.2.SP4, 5.1.3, 5.1.3.15i.BASE, 5.1.4, 5.2.2, 5.2.2.18i.BASE, 5.2.21, 5.2.3.6i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus81652 | Title: | Few VRFs have traffic loss with 2K VRF scale from PE to BL. |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Possible L3 traffic drop under scale conditions on ASR9K when the routes are learnt over IGP and EGP paths with same metric.
Conditions:
ASR9K running IOS-XR 5.3.0
The route is learnt over EGP and IGP and has same cost.
The test case is not very clear for the issue to be seen.
It is based on a code inspection.
Workaround:
There is no workaround.
Further Problem Description:
|
|
Last Modified: | 28-SEP-2015 |
|
Known Affected Releases: | 5.3.0.FWDG, 5.3.1.FWDG, 5.3.2.FWDG |
|
Known Fixed Releases: * | 5.3.2.3i.BASE, 5.3.2.6i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv80901 | Title: | IPv6 ND Issue leads to Control - Data Plane Issues |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
IPv6 ND Issue leads to Control - Data Plane Issues
Conditions:
RPFO , SAT Reload , LC Reload
Workaround:
Not Known
Further Problem Description:
|
|
Last Modified: | 28-SEP-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: * | 5.3.2, 5.3.2.FWDG, 5.3.3.8i.FWDG |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv15845 | Title: | BGP prefix not being advertised after adding it to the RPL |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: * | Symptom:
Prefix is not advertised to the BGP neighbour. Running "clear bgp soft out" doesn't clear the condition.
Conditions:
Observed after adding a new prefix into the route-policy.
Workaround:
Apply any of the three workarounds:
1. Remove and re-add the RPL in neighbor config
2. process restart policy_repository
3. Add a dummy pass statement (after an existing pass statement) in the route policy.
Example of the 3rd workaround option:
Old config:
=========
route-policy test1
if destination in PREFIX_FILTER_IN then
if community is-empty then
apply test4
endif
endif
end-policy
New config:
==========
route-policy test1
if destination in PREFIX_FILTER_IN then
if community is-empty then
apply test4
pass
endif
endif
end-policy
Further Problem Description:
|
|
Last Modified: | 29-SEP-2015 |
|
Known Affected Releases: | 5.1.3.ROUT |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv78912 | Title: | 10G: With DFE-ON need to turn on & off attenuator based on optic type |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
At very low temperature, 10G port might be receiving lot of crc error packets due to smaller eye pattern.
Conditions:
At very low temperature only. This issue is not seen at nominal temperature
Workaround:
Flap the interface.
Further Problem Description:
|
|
Last Modified: | 29-SEP-2015 |
|
Known Affected Releases: * | 5.3.2.BASE, 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv40899 | Title: | NP4/Np5: incorrect KPU generation for misc_flags for IPv6 Fmt4 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
when Qos policies are based on ipv6 access list filtering on
// IPv6 Authentication Header present */
// IPv6 Routing Header present */
// IPv6 Destination Options Header present */
the match won't occur when traffic is IPV6.
Conditions:
Qos policy based on ipv6 access list filtering on IPv6 optional header presence
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 01-SEP-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | 5.3.3.5i.BASE, 6.0.0.11i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv54038 | Title: | [513] Some sessions are stuck in disconnecting even after CSCul82895 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
sessions are stuck with "SvcAcct-Final>StatsD" in Pending Callbacks (sh subs sess all det inter)
Conditions:
generally seen with high churn of sessions with large number of services enabled with interim accountin
Workaround:
not available
Further Problem Description:
|
|
Last Modified: | 01-SEP-2015 |
|
Known Affected Releases: | 5.3.2.ROUT |
|
Known Fixed Releases: * | 5.3.2.20i.BASE, 6.0.0.12i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv45439 | Title: | devb-umass process crash after upgrade from 5.3.2.16I to 5.3.2.17I |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
A devb-umass process crash is observed on a ASR9006 router with Typhoon LC.
Conditions:
This issue occurs when upgrading the ASR9006 router from 5.3.2.16I to 5.3.2.17I build. The same issue is also observed when upgrading to 5.3.2.18I.
Workaround:
No workaround is needed. The process will restart and recover from condition.
Upgrade of the router is the only trigger when this crash is observed. The process recovers properly without any major impact on functionality/traffic on the router.
Further Problem Description:
|
|
Last Modified: | 02-SEP-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: * | 5.3.3.7i.BASE, 6.0.0.13i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv97385 | Title: | Unresolved prefix in VRF EINT when using VSM |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
CEF "Updates failed" counter can increase because of an unresolved prefix in VSM cards. This issue does not have impact in production traffic.
Conditions:
VSM cards are installed in the ASR9K.
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 02-SEP-2015 |
|
Known Affected Releases: | 5.2.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCul96823 | Title: | max limit of used file descriptors in eem code |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Crash of eem_server process.after crossing max limit of used file descriptors:
wdsysmon[447]: %HA-HA_WD-3-FD_CRIT_LIM : Process eem_server, pid 623472864 is using 950 file descriptors out of a max of 1000. Critical limit (95%) crossed.
dumper[60]: %OS-DUMPER-4-CORE_INFO : Core for pid = 623472864 (pkg/bin/eem_server) requested by pkg/bin/ksh@node0_RSP0_CPU0
Conditions:
None specified.
Workaround:
None specified.
Further Problem Description:
|
|
Last Modified: | 03-SEP-2015 |
|
Known Affected Releases: | 5.1.1.BASE |
|
Known Fixed Releases: * | 5.2.0, 5.2.0.9i.BASE, 5.2.1, 5.2.2, 5.2.21, 5.3.0, 5.3.1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup35015 | Title: | CDI: Process restart does not clean server data base |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
MPA may not reach OK state, after OIR insertion.
Conditions:
This defect will only be the root cause of MPA failure to reach OK state, in rare and very specific cases:
This defect will only cause an impact when ASR9K MPA has been removed and re-inserted a large number of times, or when certain processes on MPA jacket line cards have been restarted a large number of times.
Example processes: vic_0, vic_1, prm_server_ty
Workaround:
The code causing the issue, can be reset by restarting the lda_server process:
process restart lda_server location
is the Rack/Slot/Instance location of the failing node.
Further Problem Description:
|
|
Last Modified: | 07-SEP-2015 |
|
Known Affected Releases: | 5.3.0.BASE |
|
Known Fixed Releases: * | 5.3.0, 5.3.0.6i.BASE, 5.3.1 |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw15836 | Title: | Interface statistic counts twice PBTS PBR matching traffic |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Interface counts twice PBTS PBR traffic
Conditions:
policy based traffic selection configuration
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 08-SEP-2015 |
|
Known Affected Releases: | 5.1.3.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv99392 | Title: | VXLAN multicast traffic intermittent loss at disposition PE |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
The VXLAN multicast traffic is seen having a small random drop every 3 minutes on disposition PE.
Conditions:
There are contiguous VXLAN underlay multicast traffic sent using (S,G).
Workaround:
None
Further Problem Description:
Root Cause:
VXLAN multi cast traffic is forwarded using PIM-SM BiDIR. ASR9k dynamical creates (S,G) for traffic sent on (*,G). On the multicast traffic receiving PE, data traffic sent on (S,G) is periodically sampled the punt to control plane. The sampling period is 3 minutes. Due to a ucode breakage in VXLAN area, the sampled packet copies are no longer processed as VXLAN disposition traffic. Hence the traffic loss.
Impact:
The impact of the multicast traffic intermittent loss is limited due to the nature of VXLAN overlay traffic mapped to multicast traffic in underlay. When TCP/UDP session starts, the MAC address in overlay is not learned, there will be transient ARP or unknown unicast traffic flooding. Those overlay traffic is mapped to multicast underlay traffic. Intermittent traffic loss at 3 minutes apart does not cause harm in this case due to ARP and TCP/UDP session startup can tolerate traffic loss. The continuous multicast traffic in VXLAN underlay is usually mapped to overlay control plane traffic such as routing protocols and L2 protocols. The control plane protocol traffic can tolerate occasional traffic loss at 3 minutes apart. Hence the problem should not impact VXLAN service in production network.
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 5.3.1.BASE, 5.3.2.BASE |
|
Known Fixed Releases: * | 5.3.3.9i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum55318 | Title: | IPv4 ACL filters MPLS labeled packets |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
IPV4 ACL applied on the core facing interface is blocking MPLS based packets to be routed towards Loopback and CE destination addresses that end up being punted to the software path.
Conditions:
ACL applied on Core facing interface
Workaround:
Do not use the ACL
Further Problem Description:
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 4.2.3.BASE, 4.3.2.BASE, 5.1.1.BASE |
|
Known Fixed Releases: * | 5.1.2, 5.1.2.18i.FWDG, 5.1.3, 5.1.3.1i.FWDG, 5.1.4, 5.2.0, 5.2.0.13i.FWDG, 5.2.1, 5.2.2, 5.2.21 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq78421 | Title: | ospfv3 never comes up after nV Edge FO |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
ospfv3 never comes up after nV Edge FO
Conditions:
ospfv3 is configured with IPsec authentication in nV Edge configuration.-!
Workaround:
Restarting ipsec_pp process as follows after nV Edge FO.
------------------------
process restart ipsec_pp
------------------------
Further Problem Description:
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 4.3.4.BASE, 5.2.2.BASE |
|
Known Fixed Releases: * | 5.2.4.11i.BASE, 5.2.5.8i.BASE, 5.3.0, 5.3.0.14i.BASE, 5.3.1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui19172 | Title: | ICMP packets dropped when there is a parallel ping to an unreachable IP |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Occasional host unreachables when pinging fully reachable (eg. connected) IP address.
Conditions:
When parallel ping is happening to an unreachable ip address.
Parallel ping might be generated either manually or by an application like IPSLA.
Workaround:
Check whether parallel ping is happening to unreachable ip address.
If that is case wait until the ping to unreachable ip address is completed, then start ping to reachable connected IP address.
Further Problem Description:
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 4.3.1.ADMIN, 4.3.1.K9SEC, 4.3.1.LC, 4.3.1.MGBL |
|
Known Fixed Releases: * | 4.3.31, 4.3.31.11i.BASE, 5.0.1, 5.0.1.12i.ADMIN, 5.0.1.12i.BASE, 5.1.1, 5.1.1.9i.BASE, 5.1.11, 5.1.11.4i.BASE, 5.1.12 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq59017 | Title: | OSPF microloop avoidance may cause stale routes to remain in RIB |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
OSPF fails to remove primary and backup paths from RIB after prefix becomes unreachable.
Conditions:
- microloop avoidance must be enabled under OSPF
- prefix reachability is lost completely
Workaround:
Remove 'microloop avoidance protected' config under router ospf
Further Problem Description:
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 4.3.2.BASE, 5.1.2.BASE |
|
Known Fixed Releases: * | 5.2.2, 5.2.2.24i.ROUT, 5.2.21, 5.2.3.8i.ROUT, 5.3.0, 5.3.0.10i.ROUT, 5.3.1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus85604 | Title: | after reload with BE shut,link member in down/down instead of err-disabl |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
After a reload, link member of a bundle interface might come up as down/down instead of err-disabled although Bundle-Ethernet interface is configured in admin shut
Conditions:
happens rarely and randomly due to timing condition
Workaround:
shut/no shut on link member to restore proper state
Further Problem Description:
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 5.1.3.BASE, 5.3.2.BASE |
|
Known Fixed Releases: * | 5.2.5.7i.FWDG, 5.3.1, 5.3.1.22i.FWDG, 6.0.0.5i.FWDG |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuf60173 | Title: | IPSLA counters are incorrect: PacketLossSD, PacketLossDS, PacketMIA etc |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
show ipsla statistics displays incorrect values for aggregate counters.
PacketLossSD
PacketLossDS
PacketMIA
PacketOutOfSequence
PacketLateArrival
Conditions:
After configuring IPSLA.
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 4.2.1.BASE, 4.2.3.BASE |
|
Known Fixed Releases: * | 4.3.4, 4.3.4.3i.MGBL, 5.0.1.99i.BASE, 5.1.0, 5.1.0.4i.MGBL, 5.1.1, 5.1.11, 5.1.12, 5.1.2, 5.1.3 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum50805 | Title: | show bundle status reported false error on ICCP group and mLACP |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
show bundle status command reports false ERROR and MISCONFIG on configuration and operational status result regarding ICCP group and mLACP.
Conditions:
When using ICCP group number which is equal to or larger than 10.
Workaround:
No workaround, but this is a false error and can be ignored.
Further Problem Description:
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 4.3.4.FWDG, 5.1.2.BASE |
|
Known Fixed Releases: * | 5.1.2, 5.1.2.17i.FWDG, 5.1.3, 5.1.3.1i.FWDG, 5.1.4, 5.2.0, 5.2.0.25i.FWDG, 5.2.1, 5.2.2, 5.2.21 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus81856 | Title: | Memory getting fragmented when scripts are continuously running |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Increased memory allocation on standby RP/RSP for sysdb_shared_nc and sysdb_shared_sc processes when comparing to active RP/RSP
Conditions:
IOS-XR 5.1.3 + fix for DDTS CSCur61441 (which consists the fix for CSCur52834) and scripts that connect to active RP via SSH to periodically collect any data from the router. The more scripts and the shorter interval, the memory allocated to the impacted processes on standby RP grows faster.
Workaround:
- Restart sysdb_shared_nc or sysdb_shared_nc process on standby RP
or
- Reload standby RP
Further Problem Description:
The specific functional area that is impacted by the bug is caching mechanism in sysdb process at standby RP. Customer visible symptom is increased memory allocation for sysdb_shared_nc process at standby RP which points to memory leak. However from system technical perspective, there is no memory leak per se but freed memory is unusable because it is getting fragmented to a size which is not big enough to reuse. So we can treat it as memory fragmentation but only within a memory area allocated to particular (sysdb_shared_nc and sysdb_shared_sc) processes. Rest of memory is not affected.
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 5.1.3.BASE, 5.3.1.BASE |
|
Known Fixed Releases: * | 5.1.3.SP3, 5.1.3.SP4, 5.2.4.11i.BASE, 5.2.5.8i.BASE, 5.3.1, 5.3.1.23i.BASE, 5.3.2.3i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum50097 | Title: | nas-port-id formatting inconsistency |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
username session attribute can not be used for nas-port-id format
Conditions:
BNG using "aaa attribute format" to control nas-port-id
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 4.3.1.BASE, 4.3.4.BASE |
|
Known Fixed Releases: * | 5.1.3, 5.1.4, 5.2.0, 5.2.0.15i.BASE, 5.2.1, 5.2.2, 5.2.21 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuh99010 | Title: | Mac addresses not shown on show l2vpn forwarding bridge-domain mac-addr |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Mac addresses are not shown when executing "show l2vpn forwarding bridge-domain <> mac-address location <>" though they do appear of the detail version of the command is used: "show l2vpn forwarding bridge-domain <> mac-address detail location <>"
Conditions:
Running IOS XR 4.3.1
Workaround:
Use the detail version of the command:
show l2vpn forwarding bridge-domain <> mac-address detail location <>
More Info:
Cosmetic issue.
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 4.2.3.BASE, 4.3.1.BASE, 5.1.0.BASE, 5.1.0.ROUT |
|
Known Fixed Releases: * | 4.3.4.7i.FWDG, 5.1.0.19i.FWDG, 5.1.0.20i.FWDG, 5.1.1, 5.1.11, 5.1.12, 5.1.2, 5.1.3, 5.1.4, 5.2.0 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuh94517 | Title: | pbr lstrace crash |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
pbr_ma (standby ) crashed, when pbr_ma failed to get interface name from IM
Conditions:
we have pbr policy configurated under bundle-interface/Giag interface
Workaround:
Expected Resolution: Please check with the support engineer for information on which release(s) this bug is expected to be fixed.
Note there is no workaround for this issue. With PBR configured this process continually crashes.
Reproducibility (%):100
Further Problem Description:
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 4.3.1.BASE, 5.1.0.BASE |
|
Known Fixed Releases: * | 4.3.2, 4.3.2.27i.FWDG, 4.3.3, 4.3.31, 4.3.4, 5.1.0, 5.1.0.16i.FWDG, 5.1.1, 5.1.11, 5.1.12 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum32307 | Title: | BNG-Auto-service activation does not work if service not defined locally |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When auto-service name received in Access-Accept (in subscriber's profile), service is not activated/applied to the session if it needs to be downloaded from the Radius server.
Conditions:
ASR9k with BNG software (versions 4.3.x and 5.1), terminating subscriber sessions in case when services are not defined locally but on the Radius server.
Workaround:
Configure service locally.
Further Problem Description:
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 4.3.1.BASE, 4.3.2.BASE, 5.1.0.BASE |
|
Known Fixed Releases: * | 5.1.3, 5.1.4, 5.2.0, 5.2.0.11i.BASE, 5.2.0.11i.FWDG, 5.2.1, 5.2.2, 5.2.21, 5.3.0, 5.3.1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCua70838 | Title: | Takes long time to close LDP connection after 'clear mpls ldp neighbor' |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
It takes long time to close LDP connection after executing 'clear mpls ldp
neighbor'
Conditions:
'nsr process-failures switchover' and
'mpls ldp nsr' configured
Workaround:
Disable 'nsr process-failures switchover' or 'mpls ldp nsr'.
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 4.1.2.BASE, 4.2.1.BASE, 4.2.3.BASE |
|
Known Fixed Releases: * | 5.1.1, 5.1.11, 5.1.12, 5.1.2, 5.1.3, 5.1.4 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCty12635 | Title: | SNMPV3,EngineTime is being reset after RSP failover |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
If the NMS uses snmp V3 , it is rejecting the snmp v3 packets upong failover of ASR9K
Conditions:
If snmp V3 is configure and if the traps are enabled, if a failover happens anytime, the Engine time in the V3 is off from acceptable window.
Workaround:
They can use snmp v2. In the case of NMS tool using snmp V3, it was reported the tool recovered itself after several minutes.
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 4.1.1.BASE, 5.1.1.BASE |
|
Known Fixed Releases: * | 4.2.3.29i.BASE, 4.2.4.1i.BASE, 4.3.0, 4.3.0.30i.BASE, 4.3.1, 4.3.2, 4.3.3, 4.3.31, 4.3.4, 4.3.91 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuh57524 | Title: | ASR9k with A9K-8T-L running 4.3.0: Flow Duration issue |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Netflow records are not exported as frequently as chosen by the active timer, resulting in longer flow durations (end-flow-time minus start-flow-time) than expected.
Conditions:
This happens when the active timeout period is configured to a small value (e.g. 30 or 60 seconds), and so flows are exported due to the active timer (rather than the inactive timer).
Workaround:
Do not set the active timer to a low value, but let the flows be exported mainly due to the inactive timer.
More Info:
The issue will occur because flows are only compared against the active timer every 16 seconds, so this effects the time until export, and also limits the rate of export for active flows to 2000 per 16 seconds for each monitor. Note that export due to the inactive timer works as expected, and a rate of 2000 flows per second for each monitor.
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 4.3.0.BASE, 4.3.2.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, 4.3.4.15i.FWDG, 5.1.1.6i.FWDG, 5.1.11.4i.FWDG |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo35646 | Title: | redundant CLI for configuration of autoroute announce metric |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Two different CLIs for configuring the same item. Two different SysDB paths, but they execute the same code. This can cause problems if both "autoroute metric" and "autoroute announce metric" are configured. The actual value set in the configuration will depend on the order of execution.
Conditions:
Only if "autoroute metric" and "autoroute announce metric" are both configured.
Workaround:
Only use one of "autoroute metric" or "autoroute announce metric".
Further Problem Description:
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 5.1.1.MPLS, 5.2.0.MPLS |
|
Known Fixed Releases: * | 5.2.2, 5.2.2.24i.MPLS, 5.2.21, 5.2.3.8i.MPLS, 5.3.0, 5.3.0.10i.MPLS, 5.3.1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun05670 | Title: | 5.1.0 asr9k mibd_interface leak and crash |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
The process mibd_interface leaks memory and is crashed by the system manager when it exceeded approx. 800Mb.
Process is reloaded successfully and forwarding is not effected.
Conditions:
SysDB returns an error while the HSRP MIB is generating an information cache in response to an SNMP request.
Workaround:
SNMP views can be used to exclude the HSRP OIDs from SNMP responses being generated by the router.
Excluding the HSRP OIDs will significantly reduce the rate of memory leaking from the mibd_interface process and will help protect the process from crashing due to this defect.
Further Problem Description:
Issue does not effect forwarding.
Issue is the result of an underlying problem with SysDB which is returning an error when indexing interfaces.
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 4.3.1.BASE, 4.3.4.BASE, 5.1.0.MGBL |
|
Known Fixed Releases: * | 5.1.3, 5.1.3.9i.FWDG, 5.1.4, 5.2.0, 5.2.0.22i.FWDG, 5.2.1, 5.2.2, 5.2.21, 5.3.0, 5.3.1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuh98484 | Title: | Tacacsd "Failed to get request for key" error causes high CPU |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
High CPU on ASR9000 due to the locald and tacacsd processes
Conditions:
This high CPU is observed when the following are displayed in the logs:
%SECURITY-TACACSD-7-GENERIC_ERROR : Failed to get request for: key session /:last message repeated times errors
Workaround:
Restarting the tacacsd process fixes the problem
Further Problem Description:
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 4.2.1.BASE, 4.3.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.31.1i.BASE, 4.3.4, 4.3.4.6i.BASE, 5.1.1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup34055 | Title: | PPPoE sessions are cleared with access interface flap |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
PPPoE sessions teardown on access interface flap on BNG cluster
Conditions:
There are times when the access interface will go down on the BNG cluster (or flap), but the DSLAM/OLT or CPE will not detect it even. So it is very bad in such cases that we clear the subscriber sessions by "trying to send out PADT" from our BNG.
Workaround:
None
Further Problem Description:
The deployment is with BNG cluster with pppoe session over the bundle interface with active/standby member links from the milt-chassis LACP transport layer.
The symptom is very clear, when the link FO, sometimes , the previous active link get down and after a while the previous standby link get up, there is a gap between this two event , so from BNG's PoV, it thinks that the bundle is down and the session is cleared.
We tried to shutdown the whole bundle link and observed that the reason of session disconnection are the same to the link FO.
Both cases are as following ( result of show subs manage disconnect uni)
PPPoE access-interface
no longer ready for
sessions, DC: 0 AC: 52
TC: 6
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 5.1.2.BASE, 5.2.0.BASE |
|
Known Fixed Releases: * | 5.2.2, 5.2.2.17i.BASE, 5.2.2.17i.FWDG, 5.2.21, 5.2.3.6i.BASE, 5.2.3.6i.FWDG, 5.3.0.1i.BASE, 5.3.0.1i.FWDG |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq88828 | Title: | clear logging onboard corrupted-file automatically |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
A ASR 9000 reports %OS-OBFLMGR-7-RECORD_TYPE_UNKNOWN unknown record type errors continuously.
In addition, with obfl file corruption the obflmgr manager process may crash due to CSCui12736.
Evaluate the reasons for obfl file corruption and eliminate. In cases it occurs have system clear the obfl corrupted files automatically without user intervention and alarm.
Conditions:
Workaround:
Use admin clear logging onboard corrupted-files with the location option to clear the corrupted files.
The system will generate new obfl files and there is no impact.
Further Problem Description:
|
|
Last Modified: | 09-SEP-2015 |
|
Known Affected Releases: | 4.3.4.BASE, 5.1.1.BASE, 5.1.3.BASE |
|
Known Fixed Releases: * | 5.3.1, 5.3.1.12i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv80537 | Title: | SSTE: pim process crash after config load |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
pim process crash after config load
Conditions:
Issue seen after loading the AST scale config
Workaround:
NA
Further Problem Description:
NA
|
|
Last Modified: | 10-SEP-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: * | 5.3.2.22i.MCAST |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur77545 | Title: | ICMP (ping) not working with CGN map-t |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
ICMP (Ping) not getting translated by CGN MAP-T service when service apps are configured in VRF.
Conditions:
RP/0/RSP0/CPU0:MBR-1#admin show install active summary
Tue Nov 18 17:29:11.698 EST
Default Profile:
SDRs:
Owner
Active Packages:
disk0:asr9k-services-infra-5.2.2
disk0:asr9k-doc-px-5.2.2
disk0:asr9k-fpd-px-5.2.2
disk0:asr9k-k9sec-px-5.2.2
disk0:asr9k-mcast-px-5.2.2
disk0:asr9k-mgbl-px-5.2.2
disk0:asr9k-mini-px-5.2.2
disk0:asr9k-mpls-px-5.2.2
disk0:asr9k-services-px-5.2.2
disk0:asr9k-px-5.2.2.CSCur50673-0.0.3.i
RP/0/RSP0/CPU0:MBR-1#
RP/0/RSP0/CPU0:MBR-1#
RP/0/RSP0/CPU0:MBR-1#
RP/0/RSP0/CPU0:MBR-1#show virtual-service list
Tue Nov 18 17:30:55.163 EST
Virtual Service List:
Service Name Status Package Name Node Name
______________________________________________________________________________
CGN Activated vsmcgv6_ivybridge.ova.vr 0/1/CPU0
RP/0/RSP0/CPU0:MBR-1#
Workaround:
None.
Further Problem Description:
This feature(MAP-T with VRF) came in 5.2.2 with special SMU. It will be available in base image in 5.3.0/5.3.1.
|
|
Last Modified: | 10-SEP-2015 |
|
Known Affected Releases: | 5.2.2.BASE, 5.3.2.BASE |
|
Known Fixed Releases: * | 5.3.0.19i.BASE, 5.3.1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv80890 | Title: | Umbrella DDTS for a separate LPTS entry for DHCP |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
When DHCP snooping is disabled, DHCP broadcast pkts reach LC with PUNT_ADJ as static punt reason. This condition lead to following results:-
1) LC High CPU , or
2) DHCP pkt drops. or
3) Both the above mentioned results.
Conditions:
Scaled environment with high DHCP broadcast request/reply pkts .
Workaround:
LPTS punt police location x/x/x exception adjacency rate <> can be used to increase the police rate(PUNT_ADJ) but is not recommended. Because
since it is a common punt police and used by other CPU bound packets. Increase in this policer may lead unknown results for other components.
Further Problem Description:
When DHCP snooping is disabled, DHCP broadcast pkts reach LC with PUNT_ADJ as static punt reason. This condition lead to following results:-
1) LC High CPU , or
2) DHCP pkt drops. or
3) Both the above mentioned results.
LPTS punt police location x/x/x exception adjacency rate <> can be used to increase the police rate(PUNT_ADJ) but is not recommended. Because
since it is a common punt police and used by other CPU bound packets. Increase in this policer may lead unknown results for other components.
Fix of the issue is to have a dedicated policer for DHCP broadcast request and DHCP reply pkts with CLI to configure the same.
Fix is made available through DDTS CSCun12061 and CSCun91046.
SMU For 4.3.4 is available via AA10272
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
|
|
Last Modified: | 10-SEP-2015 |
|
Known Affected Releases: | 4.3.4.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus08820 | Title: | PLATFORM-CANB_SERVER-3-MESSAGE_FAILED with ASR-9001-FAN-V2 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
ASR9001 reports the following message:
RP/0/RSP0/CPU0:Nov 25 02:55:43.292 : canb-server[153]: %PLATFORM-CANB_SERVER-3-MESSAGE_FAILED : Unexpected CBC message received from slot 0/FT0/SP [ver 24.115] for msg type 3, id 159, len 4
Conditions:
Seen with the ASR-9001-FAN-V2.
Workaround:
Configure log suppression for message.
Example:
logging suppress rule CANB_FAN_MESSAGES
alarm PLATFORM CANB_SERVER MESSAGE_FAILED
!
logging suppress apply rule CANB_FAN_MESSAGES
all-of-router
!
Further Problem Description:
Despite message, fan tray is operating properly. Can verify with the following commands.
admin show environment fans or
admin show environment all
|
|
Last Modified: | 10-SEP-2015 |
|
Known Affected Releases: | 5.1.2.BASE, 5.1.3.BASE, 5.2.2.BASE |
|
Known Fixed Releases: * | 5.2.4.5i.BASE, 5.3.1, 5.3.1.12i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv83731 | Title: | Process radiusd crashed |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Suddenly radiusd crash. Probably due to show command from Cisco Prime Network.
1488645 -rw- 9228 Sat May 2 11:10:35 2015 first.radiusd_1124.by.radiusd.20150502-111014.node0_RSP0_CPU0.x86.txt
1488644 -rw- 181365 Sat May 2 11:10:36 2015 first.radiusd_1124.by.radiusd.20150502-111014.node0_RSP0_CPU0.x86.cpu_info.Z
1488643 -rw- 8436 Sat May 2 15:52:13 2015 first.radiusd_323.by.radiusd.20150502-153524.node0_1_CPU0.ppc.txt
1488604 -rw- 239071 Sat May 2 15:52:14 2015 first.radiusd_323.by.radiusd.20150502-153524.node0_1_CPU0.ppc.cpu_info.Z
1488606 -rw- 8436 Sat May 2 15:52:37 2015 first.radiusd_323.by.radiusd.20150502-153549.node0_2_CPU0.ppc.txt
1488607 -rw- 8436 Sat May 2 15:52:39 2015 first.radiusd_323.by.radiusd.20150502-153614.node0_3_CPU0.ppc.txt
1488608 -rw- 8436 Sat May 2 15:52:39 2015 first.radiusd_323.by.radiusd.20150502-153638.node0_5_CPU0.ppc.txt
1488640 -rw- 174655 Sat May 2 15:52:38 2015 first.radiusd_323.by.radiusd.20150502-153549.node0_2_CPU0.ppc.cpu_info.Z
1488646 -rw- 159318 Sat May 2 15:52:40 2015 first.radiusd_323.by.radiusd.20150502-153614.node0_3_CPU0.ppc.cpu_info.Z
1488647 -rw- 168143 Sat May 2 15:52:41 2015 first.radiusd_323.by.radiusd.20150502-153638.node0_5_CPU0.ppc.cpu_info.Z
1488648 -rw- 8344 Wed May 13 13:52:45 2015 first.radiusd_298.by.radiusd.20150513-135216.node0_4_CPU0.ppc.txt
1488649 -rw- 103155 Wed May 13 13:52:46 2015 first.radiusd_298.by.radiusd.20150513-135216.node0_4_CPU0.ppc.cpu_info.Z
Conditions:
Probably during aggressive show commands which was run by remote script.
Workaround:
No workaround
Further Problem Description:
|
|
Last Modified: | 12-SEP-2015 |
|
Known Affected Releases: | 5.1.3.BASE, 5.3.1.BASE |
|
Known Fixed Releases: * | 6.0.0.14i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue55886 | Title: | when SMU CSCud54093 is on ASR9001, ether_ctrl_msg_server/client restarts |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
ether_ctrl_msg_server/ether_ctrl_msg_client repeatedly restart.
Conditions:
ASR9001 (only)
Running 4.2.3, with SMU asr9k-p-4.2.3.CSCud54093 (must have this smu)
Workaround:
remove SMU asr9k-p-4.2.3.CSCud54093, as it is not needed for ASR9001
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: | 4.2.3.BASE |
|
Known Fixed Releases: * | 4.3.0, 4.3.1, 4.3.2, 4.3.2.99i.BASE, 4.3.3, 4.3.31, 4.3.4, 4.3.91, 5.1.0, 5.1.1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus62379 | Title: | "dot3HCStatsFCSErrors" cannot polling input CRC counter from 10GE |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
"dot3HCStatsFCSErrors" cannot polling input error CRC count for TenGigaEthernet interface in ASR9K from TenGiga interface as below.
RP/0/RSP0/CPU0:ASR9904-A#sh controllers tenGigE 0/1/1/7 stats | in error
Fri Jan 16 03:23:17.965 UTC
Input error giant = 0
Input error runt = 0
Input error jabbers = 0
Input error fragments = 1
Input error CRC = 1 <---!!!
Input error collisions = 0
Input error symbol = 255
Input error other = 1
Output error other = 0
OID: (dot3HCStatsFCSErrors) .1.3.6.1.2.1.10.7.11.1.2 ---> incorrect!!
===================================================================
CHANGDKI-M-Q06Y:~ changdki$ snmpwalk -v 2c -c public 172.18.87.112 .1.3.6.1.2.1.10.7.11.1.2.124
SNMPv2-SMI::transmission.7.11.1.2.124 = Counter64: 0
I can see this issue on 4.2.1 / 4.2.3 / 4.3.2 / 5.1.3 which I have tested in ASR9K platform.
Conditions:
This issue is shown on 10GE interface with following hardware.
A9K-2T20GE-E
A9K-MOD160-SE (A9K-MPA-2X10GE / A9K-MPA-20X1GE)
EtherLike-MIB stats
Workaround:
use OID: ifInErrors
Further Problem Description:
refer to ..
CSCte46224:
delta needed for EtherLike-MIB stats
Externally found moderate (Sev3) bug: V-Verified
|
|
Last Modified: | 11-SEP-2015 |
|
Known Affected Releases: | 4.2.0.BASE, 4.3.0.BASE, 5.1.0.BASE |
|
Known Fixed Releases: * | 5.2.4.6i.BASE, 5.3.1, 5.3.1.19i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv86795 | Title: | ipsub does not provide next hop info for v6 framed routes [533 DT] |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
show ipsubscriber interface dynamic-routes location will not show next hop route for framed subscribers
Conditions:
Seen for v6 framed routes.
Workaround:
none
Further Problem Description:
Bring up ds ipoe LC session with v4 & v6 framed routes from radius .
Observing the framed routes are installed .
Here ipsub does not provide the next hop info ,whereus the rib routes provides next hop LL address.
|
|
Last Modified: | 12-SEP-2015 |
|
Known Affected Releases: | 5.3.3.BASE |
|
Known Fixed Releases: * | 6.0.0.14i.FWDG |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv78509 | Title: | ASR9k QoS Order of Class-map in Policy-Map |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When L-ingress is in the last entry of the policy-map, there is no QoS data
policy-map IngressMefPolicy-6314-bad (L-ingress Q has no data)
class H-ingress-6314 (5M)
class M-ingress-6314 (10M)
class L-ingress-6314 (nothing) <== Problem. Should be 20M
Conditions:
L-ingress Q has no data when the class-map is in this order:
class H-ingress-6314 (5M)
class M-ingress-6314 (10M)
class L-ingress-6314 (nothing) <== Problem. Should be 20M
Workaround:
Removing ipv4 and ipv6 from class-map. Do the same for H-ingress, M-ingress, and L-ingress class-maps.
For example: Was:
class-map match-any L-ingress-6314
match dscp ipv4 default 1 2 3 4 5 6 7
match dscp ipv4 cs1 9 af11 11 af12 13 af13 15
match dscp ipv6 default 1 2 3 4 5 6 7
match dscp ipv6 cs1 9 af11 11 af12 13 af13 15
end-class-map
!
Change to :
class-map match-any L-ingress-6314
match dscp default 1 2 3 4 5 6 7
match dscp cs1 9 af11 11 af12 13 af13 15
end-class-map
!
Further Problem Description:
|
|
Last Modified: | 12-SEP-2015 |
|
Known Affected Releases: | 5.1.3.BASE |
|
Known Fixed Releases: * | 6.0.0.14i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv44586 | Title: | MB IPSec: 2048-bit RSA key size for rekey messages is not working |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When Key Server is configured with RSA signature key having a key length of 2048 bits, ASR9K GM fails to process it when it is recd during GDOI registration.
Conditions:
When KS is having the following config:
KS(config)#crypto key generate rsa general-keys label rsa-2048-key modulus 2048 exportable
rekey authentication mypubkey rsa rsa-2048-key
Workaround:
Use 1024 bit key instead of 2048.
Further Problem Description:
|
|
Last Modified: | 18-SEP-2015 |
|
Known Affected Releases: | 5.3.2.K9SEC |
|
Known Fixed Releases: * | 5.3.3.6i.BASE, 6.0.0.15i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw15926 | Title: | Drops on Bundle subinterface are counted as parent interface drops |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Drops on Bundle-Ether subinterface are counted on parent Bundle interface:
IOS-XR 531 outputs:
########### 2000 PING PACKETS SENT THAT SHOULD GENERATE URPF COUNTS ###########
RP/0/RP0/CPU0:RSN-SAR01#sh int bundle-ether 101 | i input drop
Fri Sep 4 16:53:41.521 BST
4762 packets input, 2772304 bytes, 2000 total input drops <<<<<<<<
RP/0/RP0/CPU0:RSN-SAR01#sh int bundle-ether 101.1115 | i input drop
Fri Sep 4 16:29:25.766 BST
4278 packets input, 791930 bytes, 2000 total input drops
RP/0/RP0/CPU0:RSN-SAR01#sh cef interface bundle-ether 101 rpf-statistics location 0/1/CPU0 <<< Not accounted in per interface RPF stats for main int
Fri Sep 4 16:54:43.368 BST
Zero Counters Found for node(0/1/CPU0).
RP/0/RP0/CPU0:RSN-SAR01#sh cef interface bundle-ether 101.1115 rpf-statistics location 0/1/CPU0
Fri Sep 4 16:30:15.392 BST
Unicast RPF drops 2000
Conditions:
This is only seen for Bundle-Ether subinterfaces. Drops on TenGig subinterfaces are not counted on parent TenGig interface.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 18-SEP-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: * | 5.3.3.10i.BASE, 6.0.0.15i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv88552 | Title: | vic - OS-DATACORRUPTION-1-DATAINCONSISTENCY : copy error |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
You may see below traceback while configuring a OTN/FEC on an wanphy interface for the first time.
Conditions:
WANPHY configuration for first time.
Workaround:
Once configured and "copy error" with traceback generated, can configure successfully on subsequent config attempts.
Further Problem Description:
Reproducibility (%): we do every time on fresh wanphy controller never configured before.
|
|
Last Modified: | 18-SEP-2015 |
|
Known Affected Releases: | 5.1.3.BASE |
|
Known Fixed Releases: * | 6.0.0.15i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv94847 | Title: | Output interface is showing as zero at ingress direction |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Output interface showing zero in netflow records with ingress mpls netflow configuration.
Conditions:
Ingress mpls traffic with null label.
Workaround:
Further Problem Description:
|
|
Last Modified: | 18-SEP-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: * | 6.0.0.15i.BASE |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw38029 | Title: | On Typhoon show controller np reg all cmd fills NPdriver log with errors |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
The NPDriver log which is displayed with the command:
show controller np drvlog location
contains many errors such as:
Sep 23 11:37:12.261 ERROR! 0x8000120B NPprmReg_Read: register 27 is not supported for NP-4 Phase 2.
in file 'drivers/chips/np/npchip-4c/src/host/driver/src/prm/chn/NPprmReg.c' line 409
Sep 23 11:37:12.282 ERROR! 0x8000120B NPapiPrm_ReadReg: Failed to read register Id: 27, channel Id 0. in file 'drivers/chips/np/npchip-4c/src/host/driver/src/api/NPapiPrm.c' line 150
Conditions:
The ASR 9000 has a Typhoon based linecard and the user has executed the
command:
show controller register all location
Workaround:
There is no workaround. The errors are harmless.
Further Problem Description:
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut69575 | Title: | ASR9k BNG: pbr_ea crash |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:pbr_ea process crashes
Conditions:ASR9k running as BNG, with PBR enabled on subscriber interfaces.
Workaround:none
More Info:
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 4.3.2.BASE, 5.1.3.BASE |
|
Known Fixed Releases: * | 5.3.2, 5.3.2.7i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw14076 | Title: | Satellite Umbrella SMU for 4.3.4 |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Umbrella SMU for 4.3.4 for satellite fixes
Conditions:
Umbrella SMU for 4.3.4 for satellite fixes
Workaround:
Umbrella SMU for 4.3.4 for satellite fixes
Further Problem Description:
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 4.3(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw08098 | Title: | eXR: golden fpd version is not displayed after primary fpd is corrupted. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Golden fpd version is not displayed after primary fpd is corrupted.
Conditions:
Interrupting CHA fpd upgrade to corrupt the primary fpd version on RSP.
Workaround:
Can see correct booted golder version from Rommon banner and only CLI will not show correct info.
Further Problem Description:
It will boot with Golden CHA and only version info wont show correctly and Rommon banner will show correct version.
|
|
Last Modified: | 24-SEP-2015 |
|
Known Affected Releases: | 6.1.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv79281 | Title: | SecGW coverity issues |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Internal co verity bugs, not to be exposed to customer.
Conditions:
NULL
Workaround:
NULL
Further Problem Description:
|
|
Last Modified: | 26-SEP-2015 |
|
Known Affected Releases: | 18.2.v1 |
|
Known Fixed Releases: * | 19.2.A0.61196, 19.2.M0.61470, 19.3.A0.61484 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv06372 | Title: | 1.3.6.1.2.1.31.1.2.1.3 oid is populated with incorrect value |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:1.Some interfaces returned as bundle members even though they do not belong to particular bundle.
2 (notInService) returned even though interfaces are valid bundle members. Prior to restarting snmp and mibd_interface, valid members returned 1 (active).
Conditions:When polling for ifStackStatus for specific bundle, interfaces not being bundle members returned along with legitimate bundle members.
Workaround:reload the router will solve the problem 1 and restarted 'mibd_interface' processes fixed problem 2.
More Info:
|
|
Last Modified: | 28-SEP-2015 |
|
Known Affected Releases: | 5.1.11.LC |
|
Known Fixed Releases: * | 5.3.2, 5.3.2.18i.BASE, 5.3.3.3i.BASE, 6.0.0.11i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv27556 | Title: | Use new malloc_opts MALLOC_SHRINK_OPTION provided by CSCuv27376 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Changed API (no function impact
Symptom:
A new libc malloc option was added by CSCuv27376 to allow sysdb to maintain the 256 KB arena
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 28-SEP-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: * | 5.3.2, 5.3.2.19i.BASE, 5.3.3.5i.BASE, 6.0.0.8i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw35524 | Title: | ASR 9001 ipv4_rib crash @ rib_route_copy_to_client_route |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
ipv4_rib process crash on ASR9001
Conditions:
The problem was reported on ASR9001 running 5.2.2
Workaround:
NA
Further Problem Description:
|
|
Last Modified: | 28-SEP-2015 |
|
Known Affected Releases: | 5.2.2.ROUT |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv27376 | Title: | Add a malloc_opts API to control malloc arena truncation behavior |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
This ddts is to introduce malloc_opt MALLOC_SHRINK_OPTION to control this behavior - thus, applications not using the MALLOC_SHRINK_OPTION will see the previous behavior of shrinking to a minimal size, applications using MALLOC_SHRINK_OPTION will see the new behavior of only shrinking to the size set by MALLOC_ARENA_SIZE
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 28-SEP-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: * | 5.3.2, 5.3.2.19i.BASE, 5.3.3.5i.BASE, 6.0.0.8i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu64661 | Title: | I/F doesn't become UP after no-shut, in not receiving RFI |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Interface remains down after a series of interface shut/no shut on both ends of a link.
Conditions:
1. far end 3 vendor doesnt send RFI when receiving LOS;
2. shutdown far end interface and ASR9k port; no shut far end first, then no shut asr9k; asr9k interface remains down.
Workaround:
shut down and then no shut on the far end.
Further Problem Description:
|
|
Last Modified: | 28-SEP-2015 |
|
Known Affected Releases: | 5.3.1.LC |
|
Known Fixed Releases: * | 5.3.2, 5.3.2.13i.BASE, 6.0.0.10i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw27586 | Title: | MIBD process crash leads to MQ list exhaustion and ping failure |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Ping failure:
RP/0/RSP0/CPU0:KS288-AR-ASR-1#ping 122.146.199.20
Thu Aug 13 11:30:13.201 CST
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 122.146.199.20, timeout is 2 seconds:socket_nb_init failed, 'infra/aipc' detected the 'fatal' condition 'Generic/unknown error from OS/system'
RP/0/RSP0/CPU0:KS288-AR-ASR-1#ping 122.146.199.20
Thu Aug 13 11:30:13.643 CST
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 122.146.199.20, timeout is 2 seconds:socket_nb_init failed, 'infra/aipc' detected the 'fatal' condition 'Generic/unknown error from OS/system'
RP/0/RSP0/CPU0:KS288-AR-ASR-1#
Conditions:
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 28-SEP-2015 |
|
Known Affected Releases: | 5.2.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCul56087 | Title: | emweb crash at ewsNetHTTPReceive |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptoms:
The Cisco Aggregate Services Router 9000 Series (ASR) which includes a version of EmWeb that is affected by the vulnerabilities identified by
the following Common Vulnerability and Exposures (CVE) IDs:
CVE-2015-6301
This bug was opened to address the potential impact on this product.
Symptoms:
Cisco includes a version of
Conditions:
Device with default configuration.
Workaround:
Not currently available.
Further Problem Description:
Additional details about the vulnerabilities listed above can be found at http://cve.mitre.org/cve/cve.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 5/4.1:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:N/AC:L/Au:N/C:N/I:N/A:P/E:F/RL:OF/RC:C&version=2.0
CVE ID CVE-2015-6301 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
|
|
Last Modified: | 28-SEP-2015 |
|
Known Affected Releases: | 5.1.1.BASE |
|
Known Fixed Releases: | 5.1.1, 5.1.1.20i.MGBL, 5.1.11, 5.1.11.16i.MGBL, 5.1.12, 5.1.2, 5.1.2.12i.MGBL, 5.1.3, 5.1.4, 5.2.0 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu87189 | Title: | RSP4:Voltage alarm seen from sensor PMOD10_0_9V_VSENSE |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Voltage alarm seen from sensor PMOD10_0_9V_VSENSE.
The alarm syslog will come as well as it will show up in sh led detail.
Conditions:
The problem can occur at any time in RP2 boards.
Once the voltage value goes beyond the voltage threshold values; alarms can come.
Workaround:
These alarms can be ignored as the threshold value which are set in the sw are not the exact expected values.
The alarms can be false one as well.
If the alarm comes , we can check with the actual threshold values which are as follows and then decide if the alarms are real or false ones.
VKG_VOLT_PMOD9_0_9_V_VSENSE 783 - 971 mV (range of acceptable voltage values)
VKG_VOLT_PMOD10_0_9_V_VSENSE 783 - 971 mV (range of acceptable voltage values)
VKG_VOLT_PMOD12_0_9_V_A_VSENSE 783 - 971 mV (range of acceptable voltage values)
VKG_VOLT_PMOD11_0_9_V_A_VSENSE 783 - 971 mV (range of acceptable voltage values)
Further Problem Description:
|
|
Last Modified: | 28-SEP-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: * | 5.3.2, 5.3.2.16i.BASE, 5.3.3.3i.BASE, 6.0.0.10i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu01343 | Title: | 5.3.1.27I : Observing "PuntFabricDataPath failed..." after router reload |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
online_diag fabric punt data test failure would be seen to a particular slice of 8x100 LC
Conditions:
After LC reload.
Workaround:
Do another LC reload.
Further Problem Description:
The cause of the problem is because the FIA ASIC is unable to receive any msg from Arbitratrion ASIC after reload
To make sure that the online diag failure falls into the description of this ddts, please "attach "0/x/CPU0", "fialc -i", "raw_rd 0x26f 2". If the counts are 0, it's the same problem.
|
|
Last Modified: | 28-SEP-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: * | 5.3.2, 5.3.2.7i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv97476 | Title: | cpwVcMIB.2.1 is not generated whenever VPLS PW is down |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
cpwVcMIB.2.1 is not generated whenever VPLS PW is down
Conditions:
VPLS PW is down
Workaround:
n/a
Further Problem Description:
would only happen for static PWs.
|
|
Last Modified: | 28-SEP-2015 |
|
Known Affected Releases: | 5.3.1.MPLS |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu95294 | Title: | OSPFv2 receives and ICMP packet in responce to DBD. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
OSPFv2 prints the messages like BAD length, invalid version
Conditions:
in response to some of the OSPF packets it might be possible that ospf receives the ICMP packet for example destination unreachable. in that case ospf should simply discard the packet rather than processing it.
Workaround:
this does not happen in normal condition. operator should check why ICMP packets are coming to OSPF. this is due to some network issue.
Further Problem Description:
I have attached the WireShark recording of the IXIA interface, in presence of the issue. Typically, the issue is created by simply reloading the Line card hosting the Satellite unit. After a line card OIR, the IXIA exchange was recorded in the attached file.
|
|
Last Modified: | 29-SEP-2015 |
|
Known Affected Releases: | 4.1.1.ROUT, 4.1.2.ROUT, 4.3.0.BASE, 4.3.1.ROUT, 5.2.0.BASE, 5.3.2.BASE |
|
Known Fixed Releases: * | 5.3.2, 5.3.2.18i.ROUT, 5.3.3.3i.ROUT, 6.0.0.12i.ROUT |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw24236 | Title: | Source MAC not the VMAC of the Bundle interface for ASR9k |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
After ifmgr process restart, bundle members operational mac address is programmed with physical interface (BIA) instead of bundle (virtual) mac address.
Before ifmgr process restart, bundle members have correct bundle mac address as operational mac address
Conditions:
Bundle interface configured on IOS-XR
Only specific to 4.3.x release.
After 5.1.0 release, this issue is not seen.
Workaround:
Do "process restart vic location 0/#/CPU0" where # is LC slot number
Further Problem Description:
|
|
Last Modified: | 29-SEP-2015 |
|
Known Affected Releases: | 4.3.4.FWDG |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw43908 | Title: | ASR9k Memory leak at mibd_interface process while polling MSDP data. |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
in the
#show snmp trace packet we can see:
'snmp-lib-ipc' detected the 'resource not available' condition 'Not enough memory'
#show memory heap dllname 330
Mon Aug 31 16:05:06.273 EurAsd
Malloc summary for pid 1239306486 process mibd_interface:
Heapsize 32821248: allocd 30533104, free 255892, overhead 2032252, high watermark 32821248
Calls: mallocs 5084817; reallocs 129217; frees 4805517; [core-allocs 2093; core-frees 180]
core-allocs immediately grows.
#debug snmp mib msdpmib - looping last 3 messages:
RP/0/RSP0/CPU0:Sep 10 13:14:51.882 EurAsd: mibd_interface[330]: bind succeeded
RP/0/RSP0/CPU0:Sep 10 13:14:51.883 EurAsd: mibd_interface[330]: Initializing trap code
RP/0/RSP0/CPU0:Sep 10 13:14:51.885 EurAsd: mibd_interface[330]: Peer nfy : vrf default, peer 1.1.1.1, trap 0, event 0x2, val 2
RP/0/RSP0/CPU0:Sep 10 13:14:51.885 EurAsd: mibd_interface[330]: Peer nfy : vrf default, peer 2.2.2.2, trap 0, event 0x2, val 1
RP/0/RSP0/CPU0:Sep 10 13:14:51.885 EurAsd: mibd_interface[330]: search_context_info NULL
RP/0/RSP0/CPU0:Sep 10 13:14:51.885 EurAsd: mibd_interface[330]: peer: PAddr:2.2.2.2, Nom:0x1, Stype:0xa0
RP/0/RSP0/CPU0:Sep 10 13:14:51.885 EurAsd: mibd_interface[330]: peer: create RBTree
RP/0/RSP0/CPU0:Sep 10 13:14:51.886 EurAsd: mibd_interface[330]: peer: datalist returned 2 entries
RP/0/RSP0/CPU0:Sep 10 13:14:51.886 EurAsd: mibd_interface[330]: peer: decode peer 2.2.2.2
RP/0/RSP0/CPU0:Sep 10 13:14:51.886 EurAsd: mibd_interface[330]: peer: decode peer 1.1.1.1
RP/0/RSP0/CPU0:Sep 10 13:14:51.886 EurAsd: mibd_interface[330]: peer: datalist returned 2 entries
RP/0/RSP0/CPU0:Sep 10 13:14:51.886 EurAsd: mibd_interface[330]: peer: decode peer 2.2.2.2
RP/0/RSP0/CPU0:Sep 10 13:14:51.886 EurAsd: mibd_interface[330]: peer: decode peer 1.1.1.1
Conditions:
Multiple MSDP peers configured and polled via SNMP
The order of the MSDP peers is not incremental.
Even if in the right order in the configuration it might vary in that output:
router msdp
peer 1.1.1.1
!
peer 2.2.2.2
!
!
#show msdp peer
Mon Sep 28 16:33:01.263 CEST
MSDP Peer 2.2.2.2 (?), AS 1111
MSDP Peer 1.1.1.1 (?), AS 1111
Resterting of mibd_interface and snmpd will temporary solve the issue.
Workaround:
Reconfigure MSDP peers - put it in incremental order.
Further Problem Description:
the problem is in sysdb, the peers needs to be configured in the right order
|
|
Last Modified: | 01-OCT-2015 |
|
Known Affected Releases: | 4.3.4.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw46089 | Title: | SSTE: te_control traceback seen after process restart te_control |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
te_control traceback message from ASR router after process restart te_control process
Conditions:
After process restart
Workaround:
NA
Further Problem Description:
NA
|
|
Last Modified: | 01-OCT-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut17712 | Title: | Failure in policy_plane_pqos_ut.py |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
Removing PQoS class is failing
Conditions:
After it is added via access accept
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 14-SEP-2015 |
|
Known Affected Releases: * | 5.3.1.BASE, 5.3.2.ROUT |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw27816 | Title: | No cipher on a policy takes default cipher as GCM-AES-128 instead of XPN |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
On a macsec policy do a 'no cipher'.With this default cipher is reflected as 'GCM-AES-128' instead of XPN-256.
Conditions:
On a macsec policy do a 'no cipher'.With this default cipher is reflected as 'GCM-AES-128' instead of XPN-256.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 16-SEP-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv94776 | Title: | 100GE : netflow on bundle subinterface - np policer rate value wrong |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
RP/0/RSP0/CPU0:PE2(config-if)#show running-config interface hundredGigE 0/1/0/0*
Tue Aug 25 10:27:39.610 UTC
interface HundredGigE0/1/0/0
bundle id 500 mode active
!
RP/0/RSP0/CPU0:PE2(config-if)#show running-config interface hundredGigE 0/1/0/1
Tue Aug 25 10:27:42.995 UTC
interface HundredGigE0/1/0/1
bundle id 500 mode active
!
RP/0/RSP0/CPU0:PE2(config)#interface bundle-ether 500
RP/0/RSP0/CPU0:PE2(config-if)#flow ipv4 monitor fmm-ipv4 sampler fsm ingress
RP/0/RSP0/CPU0:PE2(config-if)#flow ipv4 monitor fmm-ipv4 sampler fsm egress
RP/0/RSP0/CPU0:PE2(config-if)#commi
Tue Aug 25 10:28:11.616 UTC
RP/0/RSP0/CPU0:PE2(config)#interface bundle-ether 500.1
RP/0/RSP0/CPU0:PE2(config-subif)#flow ipv4 monitor fmm-ipv4 sampler fsm egress
RP/0/RSP0/CPU0:PE2(config-subif)#flow ipv4 monitor fmm-ipv4 sampler fsm ingress
RP/0/RSP0/CPU0:PE2(config-subif)#commi
Tue Aug 25 10:29:44.912 UTC
RP/0/RSP0/CPU0:PE2(config)#interface bundle-ether 500
RP/0/RSP0/CPU0:PE2(config-if)#no flow ipv4 monitor fmm-ipv4 sampler fsm ingress
RP/0/RSP0/CPU0:PE2(config-if)#
RP/0/RSP0/CPU0:PE2(config-if)#commi
Tue Aug 25 10:31:01.887 UTC
RP/0/RSP0/CPU0:PE2(config)#interface hundredGigE 0/1/0/0
RP/0/RSP0/CPU0:PE2(config-if)#no bundle id
RP/0/RSP0/CPU0:PE2(config-if)#commi
Tue Aug 25 10:32:00.334 UTC
RP/0/RSP0/CPU0:PE2#show flow platform nfea policer np all location 0/1/CPU0
Tue Aug 25 10:39:28.159 UTC
NP 0 :
#ing_lnks #egr_lnks cur_rate policer_id root_hdl node_hdl chkpt_id
=================================================================
0 2 66666 14876948 0xe91560 0x114 12088
NP 1 :
#ing_lnks #egr_lnks cur_rate policer_id root_hdl node_hdl chkpt_id
=================================================================
1 0 66666 14876948 0xe91560 0x114 12120
NP 2 :
#ing_lnks #egr_lnks cur_rate policer_id root_hdl node_hdl chkpt_id
=================================================================
0 0 0 14876948 0xe91560 0x114 0
NP 3 :
#ing_lnks #egr_lnks cur_rate policer_id root_hdl node_hdl chkpt_id
=================================================================
1 0 66666 14876948 0xe91560 0x114 12248
NP 4 :
#ing_lnks #egr_lnks cur_rate policer_id root_hdl node_hdl chkpt_id
=================================================================
0 0 0 0 0x0 0x0 0
NP 5 :
#ing_lnks #egr_lnks cur_rate policer_id root_hdl node_hdl chkpt_id
=================================================================
0 0 0 0 0x0 0x0 0
NP 6 :
#ing_lnks #egr_lnks cur_rate policer_id root_hdl node_hdl chkpt_id
=================================================================
0 0 0 0 0x0 0x0 0
NP 7 :
#ing_lnks #egr_lnks cur_rate policer_id root_hdl node_hdl chkpt_id
=================================================================
0 0 0 0 0x0 0x0 0
After Fix :
RP/0/RSP0/CPU0:PE2#show flow platform nfea policer np all location 0/1/CPU0
Tue Aug 25 15:55:01.912 UTC
NP 0 :
#ing_lnks #egr_lnks cur_rate policer_id root_hdl node_hdl chkpt_id
=================================================================
0 2 100000 14876948 0xe91560 0x114 12216
NP 1 :
#ing_lnks #egr_lnks cur_rate policer_id root_hdl node_h
|
|
Last Modified: | 18-SEP-2015 |
|
Known Affected Releases: | 5.3.3.BASE |
|
Known Fixed Releases: * | 6.0.0.15i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw26109 | Title: | commit fails if macsec policy overwritten on 10-gig interface |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: * | Symptom:
commit fail
Conditions:
commit failed when a macsec config is overwritten on 10-gig interface .
Workaround:
no macsec/macsec
Further Problem Description:
|
|
Last Modified: | 18-SEP-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw26123 | Title: | commit fails when a macsec policy name is created with > 16 characters |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: * | Symptom:
commit failure if the macsec policy name with >16 characters
Conditions:
RP/0/RSP0/CPU0:macsec-CE1(config)#macsec-policy mk_non_xpn_2tag_temp
RP/0/RSP0/CPU0:macsec-CE1(config-macsec-policy)#cipher-suite GCM-AES-128
RP/0/RSP0/CPU0:macsec-CE1(config-macsec-policy)#con CONF-OFFSET-30
RP/0/RSP0/CPU0:macsec-CE1(config-macsec-policy)#key-server-priority 1
RP/0/RSP0/CPU0:macsec-CE1(config-macsec-policy)#security-policy must-secure
RP/0/RSP0/CPU0:macsec-CE1(config-macsec-policy)#vlan-tags-in-clear 2
RP/0/RSP0/CPU0:macsec-CE1(config-macsec-policy)#window-size 1011
RP/0/RSP0/CPU0:macsec-CE1(config-macsec-policy)#commit
% Failed to commit one or more configuration items. Please issue 'show configuration failed [inheritance]' from this session to view the errors
RP/0/RSP0/CPU0:macsec-CE1(config-macsec-policy)#show config failed errors
!! APPLY ERRORS: This configuration was accepted by the system,
!! but errors occurred when the system attempted to make the
!! configuration operational. The individual errors for each
!! failed configuration command can be found below. These errors
!! will cause an inconsistency between the system's running
!! configuration and its operational state, which may be addressed
!! by using the 'no' form of the command to remove it from the
!! running configuration.
macsec-policy mk_non_xpn_2tag_temp
!!% 'Subsystem(8191)' detected the 'unknown' condition 'Code(63)': Unknown Error(511)
!
end
RP/0/RSP0/CPU0:macsec-CE1(config-macsec-policy)#clear
RP/0/RSP0/CPU0:macsec-CE1(config)
|
没有评论:
发表评论