| |
Bug Id: | CSCuu00604 |
Title: | interface back to back ping failed after config/unconfig multiple times |
|
Description: | Symptom:
Looks like only one-side ARP is working. CE1 is not able to resolve 91.1.0.2 at 12:55pm. Can the slow path team have a look?
Lucas
From PE1:
The ARP is good.
RP/0/RP0/CPU0:pe1-uut#show arp vrf vpnv4v6
-------------------------------------------------------------------------------
0/RP0/CPU0
-------------------------------------------------------------------------------
Address Age Hardware Addr State Type Interface
91.1.0.1 01:40:20 90e2.ba8e.c124 Dynamic ARPA TenGigE0/RP0/CPU0/3
91.1.0.2 - 90e2.ba8e.c075 Interface ARPA TenGigE0/RP0/CPU0/3
110.1.0.1 - 90e2.ba84.d55d Interface ARPA TenGigE0/RP0/CPU0/2
Apr 20 12:41:22.940 ipv4_arp/fast 0/RP0/CPU0 t6773 DET: Stored IPv4 address change in incomplete idb. ifh:0x8000514, addr(ip:91.1.0.2) prev_addr(ip:0.0.0.0).
Apr 20 12:41:22.941 ipv4_arp/fast 0/RP0/CPU0 t6773 EVT: interface_entry (91.1.0.2, 90e2.ba8e.c075) created successfully for ifh:0x8000514, if:TenGigE0/RP0/CPU0/3
Apr 20 12:41:22.941 ipv4_arp/fast 0/RP0/CPU0 t6773 EVT: updated aib entry (91.1.0.2, 90e2.ba8e.c075) proto:12 successfully for ifh:0x8000514, if:TenGigE0/RP0/CPU0/3
Apr 20 12:55:12.254 ipv4_arp/fast 0/RP0/CPU0 t6773 EVT: updated aib entry (91.1.0.1, 90e2.ba8e.c124) proto:12 successfully for ifh:0x8000514, if:TenGigE0/RP0/CPU0/3
Apr 20 12:55:12.254 ipv4_arp/pkt 0/RP0/CPU0 t6773 TBL: address resolution completed for 91.1.0.1
From CE1:
The ARP resolution failed for 91.1.0.2
Apr 20 12:55:11.648 ipv4_arp/pkt 0/RP0/CPU0 t6759 TBL: received address resolution request for 91.1.0.2
Apr 20 12:55:11.648 ipv4_arp/pkt 0/RP0/CPU0 t6759 TBL: creating incomplete entry for address: 91.1.0.2
Apr 20 12:55:13.649 ipv4_arp/pkt 0/RP0/CPU0 t6759 TBL: received address resolution request for 91.1.0.2
Apr 20 12:55:15.655 ipv4_arp/pkt 0/RP0/CPU0 t6759 TBL: received address resolution request for 91.1.0.2
Apr 20 12:55:16.298 ipv4_arp/pkt 0/RP0/CPU0 t6759 TBL: address resolution failed for 91.1.0.2
Apr 20 12:55:18.307 ipv4_arp/pkt 0/RP0/CPU0 t6759 TBL: received address resolution request for 91.1.0.2
Apr 20 12:55:20.300 ipv4_arp/pkt 0/RP0/CPU0 t6759 TBL: received address resolution request for 91.1.0.2
Apr 20 12:55:22.954 ipv4_arp/pkt 0/RP0/CPU0 t6759 TBL: address resolution failed for 91.1.0.2
Apr 20 12:55:25.141 ipv4_arp/slow 0/RP0/CPU0 t6759 TBL: entry 91.1.0.2: deleted from table
Conditions:
image:
Refpoint = calvados/release@ci-msl/4
Built By : kentp
Built On : Thu Apr 16 20:25:46 EDT 2015
Build Host : ott-pd-vs-016
Workspace : /workspace/kentp/CD3
Source Base : ios_ena
Devline : bnb-54-flex.lu%EFR-00000301563
Devline Type : ACME Project (Devline uses a project: bnb-54-flex%56)
bnb-54-flex EFR-00000301563 Project
ci-msl EFR-00000301020 Lineup
ci-532 EFR-00000299491 Lineup
ci-531 EFR-00000298991 Lineup
default EFR-00000294653 Lineup
RP/0/RP0/CPU0:ott-ss-dt-08B-uut#
Workaround:
Even with interface shut/noshut the ping cannot recover. have to reset the UVF.
Further Problem Description:
N/A
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 01-JUN-2015 |
|
Known Affected Releases: | 5.4.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCum72711 |
Title: | (520-SSR3) 511.20i to 520.9i upgrad failed due to pkg iincompatibilities |
|
Description: | Symptom:
not able to upgrade from 511 to 520
Conditions:
upgrade
Workaround:
turboboot
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 01-JUN-2015 |
|
Known Affected Releases: | 5.2.0.BASE, 5.2.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus70746 |
Title: | Rack1 Taiko control traffic causing MC psn wrap on topaz cards of rack0 |
|
Description: |
Symptom:Seeing MC PSN wrap on multicast destination nodes of topaz nodes after physical Oir of Control ether cables on Rack1
Conditions:removal of control ethernet cables between racks.
Workaround:
Graceful rack reload.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 01-JUN-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu50752 |
Title: | controller after backup/restore is not visible on CTC - Arwen lineup |
|
Description: | Symptom:
controller after backup/restore is not visible on CTC - Arwen lineup
Conditions:
Take backup and restore from CTC and verify controller on CTC
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUN-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus08348 |
Title: | PBR stops receiving updates after rsi_agent restart |
|
Description: | Symptom:
Flowspec rules not applied to either ipv4 or ipv6 traffic flows following proc restart of flowspec_mgr on Active RP.
Conditions:
Observed during test:
Prior to 'proc restart of flowspec_mgr' on the active RP the following processes were successfully restarted on the RP where the traffic continued to be forwarded as per the drop or police actions configured for the respective matching flows and traffic was not impacted for non-matching flows:
pbr_ma
rsi_master
rsi_agent
Workaround:
TBD
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 01-JUN-2015 |
|
Known Affected Releases: | 5.2.2.BASE |
|
Known Fixed Releases: | 5.3.1.19i.FWDG |
|
|
| |
| |
Bug Id: | CSCuu44818 |
Title: | sub-interface protocol down after RPFO |
|
Description: | Symptom:
all protocols go down
Conditions:
RP fail over
Workaround:
not known
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 02-JUN-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo62468 |
Title: | Topaz/B2B:l2vpn traffic drop for Bundle as AC@ decap PE |
|
Description: | Symptom:
L2VPN traffic drops for bundle interface on MSC-X configured as attachment circuit with mpls core on MSC140/MSC40 LC.
Conditions:
MSC140/MSC40 LC as MPLS core and MSC-X as Attachment circuit(Bundle AC)
Workaround:
None
Further Problem Description:
With Bundle as AC, observed complete traffic drop for l2vpn
Ixia 1 ??? bundle(ac)???(MSC-X ) PE1 (MSC140/MSC40) ??? P ??????PE2 ??? ixia2
Traffic drops from ixia 2 ??? Ixia1 @ MSC140/MSC40 with Invalid XID entry drops @ Ingress PSE.
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 02-JUN-2015 |
|
Known Affected Releases: | 5.1.3.BASE |
|
Known Fixed Releases: | 5.1.3.7i.BASE, 5.1.3.7i.FWDG, 5.3.1.3i.BASE, 5.3.1.3i.FWDG |
|
|
| |
| |
Bug Id: | CSCuu49543 |
Title: | IPV6 BGP NEXT-HOP Inaccessible |
|
Description: | Symptom:
IPV6 BGP next-hop which is directly connected and pingable is being marked as inaccessible and none of the prefixes received from that peer are installed in RIB.
Conditions:
none
Workaround:
none
Further Problem Description:
BGP Prefixes are not installed into RIB
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 02-JUN-2015 |
|
Known Affected Releases: | 3.9.1.16i.ROUT |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuo22047 |
Title: | 5 Fabric card core durmps during OiR testing |
|
Description: | Symptom:
In a CRS-1 Single Chassis System, upon RPFO, multiple crashes of process sfe_drvr were seen followed by kernel dump
Conditions:
Issue seen upon RP Switchover
Workaround:
None
Further Problem Description:
sfe_drvr process is a mandatory process which runs on all fabric cards. Multiple crashes of sfe_drvr can lead to fabric card being reloaded in which the process crashes.
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 02-JUN-2015 |
|
Known Affected Releases: | 5.1.1.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu26014 |
Title: | After power cycle traffic is not up, due to change in snmp ifindex value |
|
Description: | Symptom:
After power cycle traffic is not up due to change in snmp ifindex value.
Conditions:
During power cycle.
Workaround:
re-provision the traffic.
Further Problem Description:
After power cycle of the traffic is down because snmp indexes of uni ports changed in tail of the tunnels.
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 02-JUN-2015 |
|
Known Affected Releases: | 5.2.4.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCto08397 |
Title: | kernel crash @ pathmgr_object while neighbour router reload |
|
Description: | Symptom:
kernel crash @ pathmgr_object while neighbour router reload
Conditions:
XR12K router running 410 interim image
Workaround:
none
Recovery:
none
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.1.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCti88887 |
Title: | metro LCs stucked at MBI-running after upgrade from 3.9.1 to 4.0 61I |
|
Description: | symptom:you may see Metro LC stucked at MBI-running state on platform crs-1 running relaese 4.0 61I image
condition: standby RP became active after upgrade from 3.9.1 to 4.0.61I image
workaorund:process restart sw_dwnld_svr
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCua08643 |
Title: | Stale entries in LC hardware for scaled ACL |
|
Description: | Symptom:
An Access-Control List Entry (ACE) may be present in software, but
it is not present in hardware, or vice versa, following edit of ACEs.
Specifically, when adding an ACE under certain condition, the ACE is
rejected by PD silently (without turning on Pfilter-EA debug), but
at the same time, it is quietly accepted by PI DLL in EA and ACL manager.
The inconsistency could mean traffic loss, e.g. if the new ACE added
is a permit for a smaller network, but it is not added, it could cause ACL
matching to fall to a later ACE, which may deny traffic from a larger
network, which contains the said smaller network. Depending on the
situation, not having an ACE programmed in hardware could lead to
all sorts of problems.
Conditions:
User edits two regular ACEs, changing both from regular to remark;
then user changing the 2nd ACE again into regular. The 2nd change
is not honored.
Example:
10 permit ipv4 any any
20 permit icmp any any
First edit:
10 remark previously permitting all v4
20 remark previously permitting all icmp
2nd edit:
20 permit ipv4 any log
The 2nd edit will not be honored by PD. It is saved in PI (ACL manager/sysdb)
but it is not programmed in PD.
Changing a regular ACE to remark ACE amounts to removal of it in PD,
because remark ACE does nothing in data path.
Changing a remark ACE to regular ACE amounts to add a new ACE.
It is this add that may not be honored.
To verify whether this issue has occurred, perform the necessary
ACE-edit operations, then obtain the count of ACE in software by:
show access-list ipv4 | exclude "!|remark" | util wc -l
For IPv6 ACLs, replace the keyword "ipv4" with "ipv6".
Next, find out the count of ACE in hardware by
show access-list ipv4 hardware ingress detail location | in Sequence | util wc -l
where:
- "ingress" can be replaced with "egress" depending on the direction in which the ACL is applied
- specifies the LC where the ACL is applied.
The two commands would produce two counters of ACE, and they should always match.
Otherwise, this issue could be suspected.
Workaround:
Proc restart the affect pfilter-ea should resolve the problem.
process restart pfilter-ea location
Other Information:
This issue affects IPv4 ACLs on all releases on all platforms except
4.3.0 and beyond. The issue is fixed in 4.3.0 and 4.3.2 but is not fixed in release 4.3.1.
As of Ju 26, 2012, Production SMU to fix the
problem is available for IOS-XR 4.0.3
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.0.3.BASE, 4.3.1.BASE, 5.0.1.BASE |
|
Known Fixed Releases: | 4.2.3.17i.FWDG, 4.3.0.17i.FWDG, 5.0.1.99i.BASE, 5.0.1.FWDG |
|
|
| |
| |
Bug Id: | CSCtr88602 |
Title: | Polling doesnt return any values against stats supported L2 subintf basi |
|
Description: | Symptom:
IfInOctets and IfOutOctets does not return a value.
Conditions:
n/a
Workaround:
n/a
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.1.0.BASE, 4.2.0.BASE |
|
Known Fixed Releases: | 4.1.2.22i.BASE, 4.2.0.16i.BASE |
|
|
| |
| |
Bug Id: | CSCtx25811 |
Title: | NextHop info not getting upgdated when ABF applied |
|
Description: | Symptom:
When a nexthop becomes unreachable it is not switching to the subsequent reachable nexthop in the ABF config. As a result of this traffic gets blackholed as the NH which is programmed in HW is down.
Conditions:
1. A /24 route is deleted
2. FIB first cleaning up /32 leaves learned from ARP
3. This triggers a notification to ECD client, and is before deletion
of the /24 leaf in FIB shm.
4. If ECD client comes back to do the lookup very quickly, it would likely
be looking at /24 leaf which was not yet cleaned up at that time, thus
that leaf bears a UP status.
This issue is applicable to both IPv4 ACL (Release 4.1.2 and 4.2 onwards) and IPv6 ACL (Release 4.0 onwards)
Workaround:
This issue can be avoided by using any one of the below steps:
-restarting pfilter_ea process
-removing and reapplying the ABF config
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.2.1.BASE, 4.2.1.FWDG |
|
Known Fixed Releases: | 4.2.1.21i.FWDG, 4.2.3.3i.FWDG, 4.3.0.5i.FWDG, 5.0.1.99i.BASE |
|
|
| |
| |
Bug Id: | CSCth67103 |
Title: | interfaces are in admin down after reload |
|
Description: |
symptom: Interface was in admin shutdown
trigger: router reload or MSC reload, have noticed very rarely on some error
condition during config load, when cfmgr get some critical error from sysdb
workaround: Bring those down interfaces manualy up by no shut in interface
config mode
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCun21771 |
Title: | IPv4/IPv6 Labeled Unicast don't generate default-originate |
|
Description: | Symptom:
IPv4/IPv6 Labeled Unicast don't generate default-originate
Conditions:
1) default-originate enabled under IPv4/IPv6 Labeled Unicast Address family
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 5.1.2.BASE |
|
Known Fixed Releases: | 5.1.3.15i.ROUT, 5.2.2.15i.ROUT, 5.2.2.24i.ROUT, 5.2.3.1i.ROUT, 5.2.3.8i.ROUT, 5.3.0.1i.ROUT |
|
|
| |
| |
Bug Id: | CSCtz79136 |
Title: | OSPF fails to flush self-generated external LSA |
|
Description: | Symptom:
OSPF may fail to flush self-generated external LSA when the redistributed prefix disappears from the routing table.
This can create a permanent routing loop for the given prefix.
Conditions:
The following conditions needs to be met in order to trigger the problem:
- there needs to be two prefixes redistributed into OSPF with the same network address, but different mask length
- both prefixes must be added and deleted simultaneously in a very quick succession (less then LSA throttle delay, which is 50ms by default)
The prefix with the longer mask length is affected.
Workaround:
There is no workaround, apart from applying filtering to avoid having prefixes with the same network but different mask redistributed into OSPF.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.0.3.BASE, 4.2.1.ROUT |
|
Known Fixed Releases: | 4.2.3.18i.ROUT, 4.3.0.17i.ROUT |
|
|
| |
| |
Bug Id: | CSCtx11638 |
Title: | mibd_entity process crashes when CISCO-FABRIC-MCAST-MIB invoked |
|
Description: | Symptom:
RP switchover took place after multiple crashes of "mibd_entity" process.
Conditions:
mibd_entity process crashes when CISCO-FABRIC-MCAST-MIB is invoked.
Workaround:
SMU with NULL check pointer for which the atoi function was crashing should be installed and tested.
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 3.8.4.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCug62327 |
Title: | OSPF LSA update does not get retransmitted if nsr is enabled |
|
Description: | Symptom:
OSPF router may not have the latest version of an LSA in the database.
This may lead to various failures - routes missing in RIB, routes present in RIB while it should not be there, etc.
Conditions:
The problem only happen when NSR is enabled in OSPF configuration.
Problem happens when an LSA update does not get received properly (due to CRC error, packet drop, min-arrival LSA interval being hit, etc), and has to be retrasmitted.
Routers running 4.3.1 image does not retransmit the LSA update, if it was not acknowledged by the neighbor.
Workaround:
Workaround is to disable NSR in OSPF configuration in all routers running 4.3.1.
Recovery from the failure is either of the following:
- process restart ospf, or process restart , where JID is the Job ID of the affected ospf process
- clear ospf process
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.3.2.BASE, 4.3.2.ROUT, 5.0.1.BASE, 5.1.0.BASE, 5.1.1.BASE |
|
Known Fixed Releases: | 4.3.2.20i.ROUT, 5.0.1.13i.ROUT, 5.0.1.99i.BASE, 5.1.0.11i.ROUT |
|
|
| |
| |
Bug Id: | CSCty29885 |
Title: | IGMP Access group does not filter link local groups. 224.0.0.X |
|
Description: | Symptom:
When configuring an access group to filter specific link local groups the
entries for 224.0.0.X are ignored while filter does work as expected for
any other multicast group.
Conditions:
The problem occurs when a link local group address is used to configure
IGMP interface access group.
Example)
ipv4 access-list mygroup
10 deny ipv4 host 224.0.0.252 any
router igmp
interface GigabitEthernet0/0/0/0
access-group mygroup
Workaround:
None
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.1.1.ADMIN, 4.1.1.BASE, 4.1.1.CE, 4.1.1.FIRWL, 4.1.1.FWDG, 4.1.1.K9SEC, 4.1.1.LC, 4.1.1.MGBL, 4.1.1.MPLS, 4.1.1.ROUT |
|
Known Fixed Releases: | 4.2.1.22i.MCAST, 4.2.3.5i.MCAST, 4.3.0.6i.MCAST |
|
|
| |
| |
Bug Id: | CSCue42151 |
Title: | Kernel crash with PAE enabled by app accessing invalid virtual address |
|
Description: | Symptom:
Kernel crash on LC
Conditions:
-only applicable to x86 processor platform
-The trigger can be *any* user code that is trying to access an address ( virtual ) above 0xff000000.
-Crash of other processes could trigger this bug
-After the CSCue42151 fix, such access will result in a SIGSEGV instead of a kernel crash.
Workaround:
None. LC reloaded and recover itself.
Further Problem Description:
This DDTS was raised when the kernel crash was triggered by snmpd crash. But there could be other processes triggering same issue.
it is a pretty rare occurrence.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.2.1.BASE, 4.2.4.BASE, 5.1.1.LC |
|
Known Fixed Releases: | 5.1.0.12i.BASE |
|
|
| |
| |
Bug Id: | CSCty50157 |
Title: | nfma process taking too long to respond when applying Netflow on intefac |
|
Description: | Symptom:
nfma process taking too long to respond when applying Netflow on interface
Error message:
RP/0/RSP1/CPU0:ASR9K(config)#int ten 0/1/0/0.1
RP/0/RSP1/CPU0:ASR9K(config-subif)#flow ipv4 monitor MM-IPv4 sampler SM ingress
RP/0/RSP1/CPU0:ASR9K(config-subif)#commit
Wed Mar 7 17:53:54.817 EST
% Failed to commit one or more configuration items during a pseudo-atomic operation. All changes made have been reverted. Please issue 'show configuration failed' from this session to view the errors
RP/0/RSP1/CPU0:ASR9K(config-subif)#
RP/0/RSP1/CPU0:ASR9K(config-subif)#show config failed
Wed Mar 7 17:54:41.407 EST
!! SEMANTIC ERRORS: This configuration was rejected by
!! the system due to semantic errors. The individual
!! errors with each failed configuration command can be
!! found below.
Conditions:
This occurred after making numerous configuration changes including removing and adding the following interface commands.
!
interface x/x/x/x
flow ipv4 monitor MM-IPv4 sampler SM ingress
encapsulation dot1q 10
ipv4 access-group IPv4-EGRESS-IN-13-10 ingress
ipv4 access-group IPv4-EGRESS-OUT-13-10 egress
Workaround:
Currently there is no workaround.
Recovery:
Restart the nfsvr process in the affected Line Card.
Issue the command "proc restart nfsvr location .
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.2.0.BASE, 4.2.1.BASE |
|
Known Fixed Releases: | 4.2.1.30i.FWDG, 4.2.2.4i.FWDG, 4.2.3.12i.FWDG, 4.3.0.12i.FWDG |
|
|
| |
| |
Bug Id: | CSCud26461 |
Title: | BGP incomplete scoped sync due to improper handling of the resume logic |
|
Description: | Symptom:
Affected neighbors will not achieve NSR-readiness permanently.
Conditions:
After initial NSR-readiness, session flap or TCP oper down for some session triggers scoped table sync.
During scoped table sync, we hit QAD queue full error and the
table sync walk got suspended. When the resume trigger is received, we do
not do the table sync walk and declare scoped sync done. The problem is
that we do not set send_ctx->af[afi].walk_completed to FALSE when suspending.
Workaround:
None.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.2.3.BASE, 4.3.0.BASE |
|
Known Fixed Releases: | 4.3.0.39i.ROUT, 5.0.1.99i.BASE |
|
|
| |
| |
Bug Id: | CSCuc15603 |
Title: | BGP is unable to malloc a large buffer - OS says resource not available |
|
Description: | Symptom:
BGP memory leak when executing "show bgp advertised" command
The 'show memory heap dllname ' command will show increasing memory usage for "BGP EDM xxx" entries
Conditions:
executing "show bgp advertised" command or any of its variants
The show output must have some entries. The condition will not be hit if there is an empty advertisement table for BGP.
Workaround:
None
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.2.3.BASE, 4.3.0.BASE |
|
Known Fixed Releases: | 4.2.4.6i.ROUT, 4.3.0.35i.ROUT, 4.3.1.5i.ROUT |
|
|
| |
| |
Bug Id: | CSCtz24398 |
Title: | IPoE SINT: ICMP unreachable not sent unless debug enabled |
|
Description: | Symptom:
ICMP unreachable is not sent for a TTL expired or port unreachable condition. Due to this the traceroute is failing.
Conditions:
Found in normal use.
Workaround:
"debug icmp location <>" can temporarily workaround it.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.2.1.BASE, 4.2.3.BASE, 4.3.0.BASE |
|
Known Fixed Releases: | 4.2.2.BASE, 4.2.3.23i.BASE, 4.3.0.20i.BASE, 5.0.1.99i.BASE |
|
|
| |
| |
Bug Id: | CSCuh42639 |
Title: | Can not poll rttMonStatsCollectTable, rttMonStatsCaptureTable on XR |
|
Description: | Multiple tables in RTTMON MIB can not be polled due to path changes in sysdb and some of them are not implemented at all.
Symptom:
If polled for any of the tables listed in description of this bug, user will get no result.
Conditions:
When polled for MIB user can encounter this bug.
Workaround:
NA
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 3.9.0.BASE, 4.2.3.MGBL, 5.1.4.MGBL |
|
Known Fixed Releases: | 4.3.2.24i.MGBL, 5.1.0.16i.MGBL |
|
|
| |
| |
Bug Id: | CSCua77763 |
Title: | Static does not remove the route with bfd even if the interface is DOWN. |
|
Description: |
Symptom:
Erratic Route and CEF entries for an interface which is in protocol down state. Route entries for an
interface which is down.
Conditions:
Configuring same IP address on two interfaces. Configure static routes out through the interfaces.
Workaround:
Issue "clear route" command.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.2.1.BASE, 4.2.1.FWDG |
|
Known Fixed Releases: | 4.2.3.23i.ROUT, 4.3.0.20i.ROUT |
|
|
| |
| |
Bug Id: | CSCuc42621 |
Title: | aipc_proxy process crashed multiple times |
|
Description: | Symptom:
aipc_proxy process keeps crashing on a asr9k running 4.2.3 and can impact behavior of other processes such as NSR etc.
Conditions:
No known trigger know that causes AIPC proxy crash
Workaround:
no workaround.
Clearing aipc proxy process or reload of active RSP would not fix the issue.
Further Problem Description:
Issue fixed in 4.3.0 and later codes.The primary reason for the changes is to avoid deadlock. Initially, aipcproxy was maintaining two tables proxy_conn and connection entry. Both these tables needs to be synchronized. To avoid this issue it was decided to move the proxy conn table into the connection entry table. This also results in reduction in code.
The secondary reason is that after restart of the proxy there can be inconsistency between the two tables and it can eventually result in crash.
The workaround can be reload of the router..
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.2.3.ROUT, 4.3.0.BASE, 4.3.1.BASE |
|
Known Fixed Releases: | 4.3.0.29i.BASE |
|
|
| |
| |
Bug Id: | CSCtr12563 |
Title: | BGP Coredump due to memory corruption |
|
Description: | Symptom:
Coredump occurred.
Conditions:
For one or more peers, the address families enabled do not have additional-path configured.
Workaround:
n/a
Recovery:
Process comes up properly after coredump.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.0.1.ROUT, 4.1.1.ROUT |
|
Known Fixed Releases: | 4.0.11.3i.ROUT, 4.1.2.12i.ROUT, 4.2.0.18i.ROUT |
|
|
| |
| |
Bug Id: | CSCuh02932 |
Title: | BGP Stale routes seen when a peer runs into TCP Oper-Down back-2-back |
|
Description: | Symptom:
- Stale prefix remains in table instead of properly aging out.
- The messages in the InQ for the affected peer are not processed.
- Back-to-back IOS messages (within 5 min) indicating Neighbor aborting NSR can be treated as a potential trigger. Sample IOS message is given below.
RP/0/RP0/CPU0:Sep 10 10:40:13.083 EDT: bgp[1045]: %ROUTING-BGP-3-NBR_NSR_DISABLED : NSR disabled on neighbor 201.11.23.41 due to TCP retransmissions
Conditions:
The occurrence of this defect is rare and the following conditions need to aligned to be able to run into this issue.
- A NSR ready neighbor runs into too many TCP retransmissions due to data-path issue. TCP disables NSR for the neighbor and announces OPER_DOWN condition.
- After a cool-down period (2 min), BGP triggers scoped -sync for that neighbor in an effort to restore the NSR state.
- Scoped-sync is a light-weight mechanism to sync information specific to a single neighbor. It is done in two phases:
(a) TCP Session Synchronization (replication of the TCP session information), (b) BGP Database Sync (replication of the BGP neighbor information)
- BGP on the active RP throttles reading incoming BGP updates during the TCP sync so that both active and standby BGP can synchronize processing updates after the standby BGP session comes up
- In this particular situation, a second TCP OPER_DOWN condition was encountered when the TCP sync was in progress to recover from the first OPER_DOWN condition
- The problem related to stale route results from the fact that BGP fails to reset the neighbors NSR state to OPER-DOWN. As a result, instead of another attempt to start the scoped-sync and restore normal update processing, BGP fails to resume reading from the socket resulting into permanently throttled Rx side.
Workaround:
Recovery can be done by taking the following steps for the affected neighbor:
(i) Configure "shut" for the neighbor. This will bring down the neighbor session.
(ii) Wait for 5 mins to make sure that all paths received from this neighbor are deleted.
(iii) Unconfigure the BGP neighbor
(iv) Wait for 5 mins
(vii) Reconfigure the neighbor.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.2.3.BASE, 4.2.3.ROUT, 4.2.4.BASE, 4.2.4.ROUT |
|
Known Fixed Releases: | 4.3.0.26i.ROUT, 5.0.1.99i.BASE, 5.1.3.99i.BASE |
|
|
| |
| |
Bug Id: | CSCuc46134 |
Title: | Bundle_ether interface QoS total interface bandwidth is incorrect |
|
Description: | Symptom:
bundle-ether interface qos bandwidth was not programmed correctly, for a 40G bundle ( include 4 10GE link in same line card), in the "show qos interface" output, it show only 10G bandwidth, which cause the traffic tail drop in ingress direction. The traffic exceed 10Gbps are dropped.
Conditions:
This problem was found after customer upgrade from 3.9.0 to 4.1.2.
The peak rate police token bucket is 100%, so when trying to add add QoS to second tenge member link, the token bucket depth will be 20G, which is bigger than 16G metro police limit, so fail to programmed QoS to second tenge interface.
On old version, it did not do this rejection on peak rate configuration.
Workaround:
change the police configuration, so that it will not exceed the 16G limit.
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.1.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCua14945 |
Title: | Routes are not filtered properly in redistribution and advertising |
|
Description: | Symptom:
Routes are not filtered properly resulting to routes not learned or
advertised properly to eBGP/iBGP peers.
Conditions:
Seen on all platforms running IOS-XR images including CSCty83336 (eg: 4.2.1) or
on CRS - PRP running images without CSCty83336.
RPL policy is used on the bgp neighbour matching a prefix set with ge or le
keywords.
When a prefix set with mask ranges is used in a policy, the routes
will be shown as not matched even in case of a proper match.
For IPv4 prefixes, problem is seen with zero being used as prefix mask.
As in the following IPv4 example:
route-policy policy_A
if destination in (0.0.0.0/0 ge 32) then
pass
endif
end-policy
For IPv6 prefixes problem is seen if any masks are employed as example of
failing policy:
route-policy policy_B
if destination in (89::/16 le 128) then
pass
endif
end-policy
If this policy is being used, then the routes 89:0:0:X::1 will be dropped even
though they should pass.
Workaround:None.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.2.1.BASE, 4.2.3.BASE |
|
Known Fixed Releases: | 4.2.2.11i.FWDG, 4.2.2.11i.ROUT, 4.2.3.17i.FWDG, 4.2.3.17i.ROUT, 4.2.3.18i.FWDG, 4.2.3.18i.ROUT, 4.2.3.20i.FWDG, 4.2.3.20i.ROUT, 4.3.0.17i.FWDG, 4.3.0.17i.ROUT |
|
|
| |
| |
Bug Id: | CSCtd83440 |
Title: | MC4 instdir process crash on 3.9-renumber upgrade |
|
Description: | Symptom:
unecpected RPFO from 0/RP0 to 0/RP1
Conditions:
system upgrade 3.9 34I to 3.9.0 Renumber
Workaround:
none
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 3.9.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCue18938 |
Title: | G-Ether should always propagate link down events |
|
Description: |
Symptom:
Protected tunnel traffic may get transitioned onto a backup path even through no link flap of the interface associated with the primary path has been reported in the system.
Conditions:
This issue can very rarely be seen if the link flaps down then up for a very short time interval.
Workaround:
Configuring "carrier delay up 250" on the linecard Ethernet interfaces ensures that any link up events are delayed long enough to ensure that the link down flap will always be seen by the system but without affecting the time taken for FRR protection.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 3.7.0.BASE, 4.1.2.FWDG |
|
Known Fixed Releases: | 5.1.3.11i.BASE, 5.1.3.11i.FWDG, 5.2.1.20i.BASE, 5.2.1.20i.FWDG, 5.2.2.8i.BASE, 5.2.2.8i.FWDG, 5.3.0.1i.BASE, 5.3.0.1i.FWDG |
|
|
| |
| |
Bug Id: | CSCud54747 |
Title: | gsp crash with "ERR: buf_ptr magic check failed!" |
|
Description: | Symptom:
The GSP process unexpectedly restarts after an error message on the console containing the text "ERR: buf_ptr magic check failed!".
Conditions:
The problem might be observed:
1. On and after the 4.1.0 release.
2. With moderate route scale.
3. When multiple route updates arrive with a combined size which is exactly right to trigger an internal buffer to overflow.
Since the size of each route update varies (typically according to the nature of changes in the network topology), and several such changes have to combine to produce just the right total size, and they have to arrive consecutively such that they are all allocated to a single given buffer, the expected frequency of this error is low.
Workaround:
WORKAROUND
============
No workaround is possible.
RECOVERY
=========
No recovery action is needed because the error clears itself after GSP restarts. The restart could happen multiple times.
Further Problem Description:
IMPACT
======
1. Instability (due to multiple GSP restarts).
2. Forwarding impact (due to some route updates not being received by FIB because GSP crashes). Once GSP recovers, the route updates should be handled correctly.
This only applies to updates in progress, routes which are already programmed will continue to forward smoothly throughout.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.2.4.BASE, 4.3.0.BASE, 4.3.1.BASE |
|
Known Fixed Releases: | 4.3.1.20i.FWDG, 4.3.2.5i.FWDG, 5.0.0.22i.FWDG |
|
|
| |
| |
Bug Id: | CSCuc83543 |
Title: | Failed to read Address Family data file: Missing END marker |
|
Description: | Symptom: Address family is not configured
Conditions: If ios 3.6.0 is upgraded to ios-xr 4.0.1 by turbobooting then bgp_ipv4_mcast.af and bgp_ipv6_ucast.af are corrupted
Workaround: Turbobooting with latest bgp SMU CSCtx22241 this issue does not showup.
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.0.1.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCty76924 |
Title: | BGP not NSR-Ready due to inconsistent NSR state between A/S-BGP |
|
Description: | Symptom:
NSR may fail to re-synchronise on the standby processor.
RP/0/8/CPU0:HOSTNAME#show red
Redundancy information for node 0/8/CPU0:
==========================================
Node 0/8/CPU0 is in ACTIVE role
Partner node (0/7/CPU0) is in STANDBY role
Standby node in 0/7/CPU0 is ready
Standby node in 0/7/CPU0 is not NSR-ready
Details
--------
Current active redcon state: 4 (I_READY)
All not-ready bits clear - standby should be ready
Current active redcon state for NSR: Not ready
Reason for standby not NSR-ready
1046 0/8/CPU0 bgp BGP NSR sessions not synchronized
Not ready set Sat May 6 6:03:38 2012: 5 weeks, 5 days, 6 hours, 32 minutes ago
Conditions:
Router running IOS-XR and recovering from unusual error situation
such as packet memory shortage or communication errors with standby node.
Recovery:
Restart the bgp process on the standby RP processor.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.1.1.BASE, 4.2.1.BASE |
|
Known Fixed Releases: | 4.2.1.27i.ROUT, 4.2.2.2i.ROUT, 4.2.3.9i.ROUT, 4.3.0.9i.BASE, 4.3.0.9i.ROUT, 5.0.1.99i.BASE |
|
|
| |
| |
Bug Id: | CSCud43677 |
Title: | Clients of ifindex library fail to get ifindex after RP failover |
|
Description: | Symptom:<\B>
On a Cisco router running IOS-XR an error message indicating the inability
to get an interface index may be observed after RP switchover.
Conditions:<\B>
The problem may be triggered if an RP switchover occurred and a new interface is
created afterwards. New interfaces are created at the following cases:
* A new LC is inserted
* A new subinterface is configured
* A new bundle interface is configured
* OIR of an LC
After RP switchover, any newly created interface will have an ifindex value of 0.
The problem will be observed when the ifindex is accessed of such an iterface from
a process depending on the unique ifindex (ospf, isis, ifmib, bundle-mgr, rsvp,mpls etc. ).
Changing the configuration of an existing interface will not trigger the issue.
Workaround :<\B>
After RP switchover before a new interface is created restart the processes ifindex_server and
mibd_interface with the following CLIs:
"process restart ifindex_server" just after fail over
"process restart mibd_interface" (sync ifMIB dbase with ifindex_server).
Recovery:<\B>
When the problem is present apply the procedure as described in the Workaround.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.3.0.BASE, 4.3.1.BASE, 5.1.0.BASE, 5.2.0.BASE, 5.2.0.MPLS, 5.2.0.ROUT |
|
Known Fixed Releases: | 4.3.1.22i.BASE, 4.3.2.7i.BASE, 5.0.1.99i.BASE, 5.1.0.3i.BASE |
|
|
| |
| |
Bug Id: | CSCtz95112 |
Title: | Cluster: Rack Reload + Rack bootup issues |
|
Description: | RNE: Added 08/22/2012 09:56:32 by vineelak
None of the processes will have a backup version running on the backup-DSC.
This issue happens in cluster setup. Issue was observed while the following step was issued:
Pre-condition: Rack0--Rack1 system all up and running.
->Rack0 reloaded, Rack1 has DSC and backup-DSC.Rack0 booted, then backup-DSC migrated to Rack0
none
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.2.1.BASE, 4.3.0.BASE |
|
Known Fixed Releases: | 4.3.0.37i.BASE |
|
|
| |
| |
Bug Id: | CSCsu49640 |
Title: | [371_CRS][REG]:config's failed to commit due to sysmgr semantic error |
|
Description: | Symptom: config's failed to commit due to sysmgr semantic error
Conditions: after doing RP Fo/Fb for 15 times
Workaround: No
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 3.7.1.BASE, 3.8.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuc96174 |
Title: | After OIR LC fails to pass SNMP data on CRS |
|
Description: | On CRS-3 running 4.1.0 after OIR of 2 LC's (FP-140G/14-10GbE) they failed to pass SNMP requests. SNMP requests across other LC's were fine. On these 2 LC's in question there are no LPTS SNMP (port 161) bindings. Prior to the OIR SNMP was functioning normally. No other impact has been observed.
Workaround:
None at this time.
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.1.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCud81608 |
Title: | ITALv2: provide fwd_ref functionality to clients |
|
Description: | Symptom:With IPsec configured, ospfv3 sessions are not coming up after LC OIR.
Conditions:With LC OIR only the ospfv3 sessions configured with ipsec are effected.
Workaround:None. With ipsec configuration only this behavior is observed.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.3.2.BASE, 5.0.0.LC |
|
Known Fixed Releases: | 4.3.1.30i.FWDG, 4.3.2.14i.FWDG, 5.0.0.34i.FWDG, 5.1.0.8i.FWDG |
|
|
| |
| |
Bug Id: | CSCto74902 |
Title: | Error messages flooding on the console after RPFO |
|
Description: | Symptom:
After RPFO, the following error messages flooding on the console. And process eem_ed_syslog and ipsec_mp are not working properly.
RP/0/RP1/CPU0:Apr 15 15:38:25.873 : eem_ed_syslog[188]: %HA-HA_EM-7-FMFD_EVM_CREATE : Could not create event manager: File exist
s : pkg/bin/eem_ed_syslog : (PID=7786806) : -Traceback= 40002fb4 4000686c
RP/0/RP1/CPU0:Apr 15 15:38:26.098 : sysmgr[90]: %OS-SYSMGR-3-ERROR : eem_ed_syslog(1) (jid 188) exited, will be respawned with a
delay (slow-restart)
Conditions:
RPFO
Workaround:
No
Recovery:
No
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.1.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCub45840 |
Title: | mpls_ldp crash on continuous add/remove of mpls ldp config |
|
Description: |
mpls_ldp process may crash under a rare timing condition.
Conditions:
1) We need to receive a ldp hello packet for a different peer than the peer
that just went down.
2) The peer that just went down needs to be a GR peer.
3) The GR liveness timer must expire very quickly after the GR peer went down
and before the new peer comes up. This typically would make this problem very
difficult to hit since the GR liveness timer is usually a large value, ie 120
seconds. In some case the GR liveness can expire almost immediately because
the session had flapped many times and GR wasn't being maintained.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.1.1.BASE, 4.2.0.BASE, 4.2.3.BASE |
|
Known Fixed Releases: | 4.2.3.26i.MPLS, 4.3.0.23i.MPLS |
|
|
| |
| |
Bug Id: | CSCti82475 |
Title: | Continous platform_mgr_common logs seen on 5+1 MC. |
|
Description: | Symptom:
Continous platform_mgr_common syslog messages being seen.
Conditions:
steady state of 401.8I 5+1 MC
Workaround:
none
Recovery:
none
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.0.1.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCub98565 |
Title: | PIE installation failing. "instdir" process crashed. |
|
Description: | Symptom:
Not being able to install the MPLS PIE
"show context" revealed that instdir had crashed
Conditions:
Not being able to install the MPLS PIE
Workaround:
None known.
|
|
Status: | Terminated |
|
Severity: | 1 Catastrophic |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.3.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuc96239 |
Title: | xml dedicated and tty agent crashed on show xml session |
|
Description: | Symptom:
xml_tty_agnet / xml_dedicated_agent process get crashed while executing 'show xml sessions' CLI with corresponding sessions exists.
Conditions:
tty/default XML session present
Workaround:
NIL
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.3.1.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur52834 |
Title: | 8KB arenas created in sysdb_shared_sc causing fragmentation |
|
Description: | Symptom:
8KB arenas created in sysdb_shared_sc causing fragmentation and crash
Conditions:
Some application uses malloc_opt to change to have larger arena size. Arena can be reduced to smaller size which can have impact to fragmentation.
Workaround:
Process restart typically can help reducing fragmentation
Further Problem Description:
This change is to change the size to malloc_opt specified minimum arena size.
The behavior without this ddts change has been in previous releases for many many years without nay issue.
This is unlikely to cause fragmentation issue bad enough to cause harm but rather this ddts is just to address the
proper or expected behavior when using this malloc opt.
This ddts is unlikely to cause any impact to router and I don't think customers need to worry about it.
In other words, SMU for customers is not necessary.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 5.1.3.BASE |
|
Known Fixed Releases: | 5.1.3.SP2, 5.1.3.SP3, 5.1.3.SP4, 5.2.3.99i.BASE, 5.3.0.16i.BASE |
|
|
| |
| |
Bug Id: | CSCtr83738 |
Title: | Need to implement LC CPU Tx stall recovery mechanism |
|
Description: | Symptom:
Need to implement LC CPU Tx Stall recovery mechanism
Conditions:
Currently we do nothing to recover from LC CPU Tx stall. We just wait and hope it recovers by itself.
Workaround:
none
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.0.4.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCud30368 |
Title: | mibd_interface crashing at cdm_evm_thread |
|
Description: | Symptom:
mibd_interface process crashes on the LC.
Conditions:
This crash is observed when an interface with scaled sub-interface config flaps continuously.
Workaround:
None.
Recovery:
The process immediately recovers after the crash.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.2.3.BASE, 4.3.0.BASE |
|
Known Fixed Releases: | 4.3.1.18i.BASE, 4.3.2.3i.BASE, 5.1.0.2i.BASE |
|
|
| |
| |
Bug Id: | CSCua56647 |
Title: | MGMNT: IPC buffers used up on snmp polling timeout, stops pollin |
|
Description: | Symptom
SNMP is not responding or responding very slowly
conditions
with rapid successive polls or walks
recovery
process restart snmpd or pace the snmp requests so the system can keep up with he requests,
increase snmp timeout
detail
snmpd receives the requests and dispatches that to other processes to get the data of the system.
this communication between snmpd and the recipient is done via IPC's.
This is where delay can be generated and snmp requests timing out.
The management station might retry for the same requests basically aggrevating this situation.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.2.1.BASE, 4.2.3.BASE, 4.3.0.BASE |
|
Known Fixed Releases: | 4.2.2.BASE, 4.2.3.21i.BASE, 4.2.3.23i.BASE, 4.3.0.20i.BASE |
|
|
| |
| |
Bug Id: | CSCsx24046 |
Title: | auto-rp mapping agent are not merged in group cache in XR like IOS |
|
Description: | None
In IOS if we have a network with multiple MA's for an Auto-RP we merge the groups from the MA's into
the group cache. In IOS XR this behavior was not applied and it is required that the MA's each
publish the same group mappings. If the mappings are not the same the one with the removed mappings
is removed. The user will see a flap in the PIM group at every interval of the updates from the PIM
mapping.
Workaround: Both MA's must send the exact same PIM group mappings.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 3.6.1.MCAST, 3.9.1.ROUT, 4.0.1.BASE, 4.0.1.ROUT, 4.1.0.MCAST, 4.1.0.ROUT |
|
Known Fixed Releases: | 3.9.3.11i.MCAST, 4.0.1.17i.MCAST, 4.0.1.19i.MCAST, 4.0.1.20i.MCAST, 4.0.2.2i.MCAST, 4.1.0.16i.MCAST |
|
|
| |
| |
Bug Id: | CSCud57200 |
Title: | 431UI:Partial config loss on downgrade from 4.3.1.11I to 4.3.0.35I |
|
Description: | Symptom:
When doing a software downgrade from IOS-XR 4.3.1 (or later) to IOS-XR 4.3.0 (or earlier), all xconnect PW configuration is lost.
Conditions:
This happens when downgrading from IOS-XR 4.3.1 (or a later release) to IOS-XR 4.3.0 (or an earlier release).
Workaround:
Remove the ipv4 keyword from the xconnect PW configuration and reapply the configuration.
Also, before doing a software upgrade, save the configuration so that the configuration can be re-applied if the upgrade has to be stopped.
Further Problem Description:
In IOS-XR 4.3.0 and earlier releases, xconnect PWs are configured as:
neighbor ipv4-addr pw-id id
In IOS-XR 4.3.1, because of the introduction of IPv6 PWs, we added an AF keyword:
neighbor ipv4|ipv6 ipv4-addr pw-id id
However we still support the old form of the CLI (without ipv4 or ipv6 keyword) but it NVGENs to ipv4 (the default AF). So when we downgrade from 4.3.1 to 4.3.0 the 4.3.1 configuration fails because 4.3.0 does NOT support the ipv4 keyword.
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.3.1.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCub13435 |
Title: | BGP Process crash SIGBUS error |
|
Description: | Symptom:
XR12000 running 4.1.2 has a BGP process crash.
Conditions:
XR12000 running 4.1.2, and running BGP.
Workaround:
none
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.1.2.ROUT, 4.3.0.BASE, 4.3.0.CE |
|
Known Fixed Releases: | 4.3.0.30i.ROUT |
|
|
| |
| |
Bug Id: | CSCug87067 |
Title: | %ROUTING-FIB-5-ROUTE_UPDATE_DROP : LABEL-RECYCLING for CSC PE-CE link |
|
Description: | RNE Enclosure
Symptom:
Logs containing the following appear
fib_mgr[209]: %ROUTING-FIB-5-ROUTE_UPDATE_DROP : LABEL-RECYCLING
Forwarding for the old label fails.
Conditions:
If BGP resolves a nexthop using a labeled BGP route and that nexthop is deleted, BGP also deletes the label for that route, but continues to use it.
Workaround:
process restart mpls_lsd
or
process restart bgp
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.1.2.BASE, 4.3.2.BASE |
|
Known Fixed Releases: | 5.2.4.6i.ROUT, 5.3.1.7i.ROUT |
|
|
| |
| |
Bug Id: | CSCug48609 |
Title: | UCMP with BGP extended communities not populating CEF correctly |
|
Description: | Symptom:
After a route update to one of the UCMP paths, cef collapses the paths incorrectly and makes the router behave in an ECMP mode which is undesired
Conditions:
Running UCMP and receiving an update for a path that is part of the UCMP paths.
Workaround:
clear the rib route to recompute cef, reconfigure an RPL policy to have the FIB recompute the paths
or any other operation that will effectively recalculate the fIB for that particular UCMP route(s).
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.2.3.FWDG, 4.3.1.FWDG |
|
Known Fixed Releases: | 5.1.0.17i.BASE, 5.1.0.17i.FWDG |
|
|
| |
| |
Bug Id: | CSCuf20502 |
Title: | eem_metric_dir Crash on Switchover 4.3.23K |
|
Description: | Symptom:
eem_metric_dir Process Crash
Conditions:
Switchover
Workaround:
Since the process has HA, its bound to recover from crash.
Further Problem Description:
Noticed in rare RPFOs with high scale.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.3.1.BASE, 5.1.0.BASE |
|
Known Fixed Releases: | 4.3.1.31i.BASE, 4.3.2.16i.BASE, 5.1.0.8i.BASE |
|
|
| |
| |
Bug Id: | CSCuf30180 |
Title: | mpls_ldp process is continuously down once it is restarted |
|
Description: |
Symptom:mpls_ldp process is unable to restart and re spawning is continuously scheduled
Conditions:restart mpls_ldp process
Workaround:no workaround
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 5.1.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCur91995 |
Title: | continuous devc-vty crash on EEM script runs |
|
Description: | Symptom:
devc-vty process continuous crash.
Conditions:
running EEM script
Workaround:
none
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 5.3.0.BASE, 5.3.1.BASE |
|
Known Fixed Releases: | 5.2.21.1i.BASE, 5.2.4.3i.BASE, 5.3.0.18i.BASE |
|
|
| |
| |
Bug Id: | CSCty83336 |
Title: | 4.1.Route Policy not parsing ipv6 or IPv4 default prefix-list properly |
|
Description: | Symptom:
Default IPv4 or IPv6 prefix in prefix-set is matching against other prefixes of
IPv4 or IPv6
Conditions:
The same RPL prefix-sets works 4.1.1 on RP's, but not on (PRP)Satori or any x86
RP running on px (crs-px, asr9k-px) images.
RootCause
Masking logic in matching algorithm is failing due to endianness.
Workaround:
Removing the default prefix entries from prefix set would resolve the issue,
but there is no workaround if the default route needs to be in the policy.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.0.4.BASE, 4.1.1.BASE |
|
Known Fixed Releases: | 4.2.1.FWDG, 4.2.1.ROUT, 4.2.2.8i.FWDG, 4.2.2.8i.ROUT, 4.2.3.16i.FWDG, 4.2.3.16i.ROUT, 4.2.3.20i.FWDG, 4.2.3.20i.ROUT, 4.3.0.13i.FWDG, 4.3.0.13i.ROUT |
|
|
| |
| |
Bug Id: | CSCtr53990 |
Title: | mibd_interface memory leak in 3.8.1 because of POS MIB |
|
Description: | Symptom:mibd_ineterface memory leak and crash
Conditions:normal polling
The crash is because of atm mibs polling addressed by CSCtq25693 however there
are other MIBs too that are causing the memory leak.
Other MIBs that was suspected was Sonet , POS and snmpDot3MauMgt = 1.3.6.1.2.1.26
This bug takes care of POS
Workaround:Processes restart mibd_inetrace however if the processes is
leaking memory continuously then restarting processes can be a temporary solution.
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 3.8.1.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCue04290 |
Title: | CRS Console & VTY unresponsive |
|
Description: | Symptom:
CRS Console & VTY unresponsive.
Conditions:
The node was not responsive, console and VTY was not working Customer traffic was fine and no traffic loss was reported.
Status:
Insufficient data collected to further investigation.
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 3.9.3.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCts08870 |
Title: | Stndby RP stuck in not ready, cfgmgr-rp error msgs after failed FSU |
|
Description: | Symptom:
Standby RP is stuck in the not ready state and cfmgr-rp error messages are seen following a failed FSU attempt.
Conditions:
Seen after failed FSU attempt and after issuing 'clear configuration inconsistency'
Workaround:
Unknown.
|
|
Status: | Terminated |
|
Severity: | 1 Catastrophic |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.1.1.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCti09589 |
Title: | all bundle interfaces goes down after router reload |
|
Description: | Symptom:
all bundle interfaces goes down after router reload
Conditions:
After router reload
Workaround:
None
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCud83018 |
Title: | [C12K-RPC] Lost all config after loading 510 FCA image on all router |
|
Description: |
Symptom:I lost all configurations after loading FCA image provided by you.
After loading saved config from disk0: ,also all gig interfaces were in shutdown state.
I did not see this behavior before.
Conditions:reload router with a particular image
Workaround:not required
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 5.1.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtx53395 |
Title: | insthelper crash on stdby RP on RP switchover |
|
Description: |
Triage.
Symptom:
Insthelper process crash will be seen on standby.
Conditions:
This bug affects 4.2.1 and 4.3.1
Workaround:
removing inactive package may help
to reduce size of install state file so it will help for this issue but cant completely avoid this
issue
More Info:
Install state files includes Loadpath files, Historylog files, Admin meta-data files, Rollback Label files, etc.
Whenever we do install related operation one or more of these files will be updated, all these
files are created when we do turboboot, these files will keep on growing(updated) on every install
related operation, these files will be replicated
to all DRP nodes(nodes which can become Dsc in case of HA) using RDS(replication data services),
Instdir process on Dsc owns these files and writes to them whenever we do install related operations.
instdir sends either full updates containing all the state files or specific updates for certain
file types.
when insthelper initializes, it requests a full update to be sent out but rest of the time update
will be to specific file. Here after upgrade it has requested full state file update, it is
confirmed as per the corefile, process has reached rlimit when it has request for full update, and
the file data size can be big in this case. In this particular case it is around 54 MB of install
state files data, while trying to allocate 54MB memory buffer for receiving this update it has
crossed the limit.
Every inactive package will have entry in admin_pkgs_mdata, so every inactive packages present on
the box will increase size of this install state file data, for example every inactive package will
be having entry in this admin_pkgs_mdata as
# ls -l /instdb
total 56
drwxr-xr-x 2 0 0 4096 Mar 28 11:05 .
drwxr-xr-x 4 0 0 4096 Mar 28 11:05 ..
-rwxr-xr-t 1 0 0 16996 Mar 28 11:05 component.db
-rwxr-xr-t 1 0 0
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.1.2.BASE, 4.2.1.BASE, 4.2.2.BASE, 4.2.3.BASE, 4.3.0.BASE, 4.3.1.BASE, 4.3.2.BASE |
|
Known Fixed Releases: | 4.3.1.31i.BASE, 4.3.2.16i.BASE, 5.0.1.99i.BASE, 5.1.0.8i.BASE |
|
|
| |
| |
Bug Id: | CSCuc16418 |
Title: | ISSU:L2Mcast Traffic Drop occuring once RUN executed+ping failure,OSPFup |
|
Description: | Symptom:
Partial Traffic Drop
ISSU not running to completion
Conditions:
ISSU RUN mode executed
Workaround:
None known
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.3.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtu37039 |
Title: | Stale entries remain in sadb after a iedge process restart |
|
Description: |
Symptom : show subscriber manager sadb has extra entries for subscribers not
avialble on the system
Trigger : Process restart while session inlight but session create not
complete.
Impact : No Functional impact.
Any work around: No
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.2.0.ROUT |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCtz79455 |
Title: | l2vpn vc trap is not generated whenever VC went up/down |
|
Description: | Symptom:
Executing show l2vpn xc detail results in MIB cpwVcIndex field equal to 0
"MIB cpwVcIndex: 0"
Conditions:
Doing a reload on a router configured for VPWS (Virtual Private Wire Service)
Workaround:
Remove the l2vpn config and then reapply the config. This will populate the MIB database with a valid entity and the traps will be generated again.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 03-JUN-2015 |
|
Known Affected Releases: | 4.2.1.BASE, 4.2.1.MPLS |
|
Known Fixed Releases: | 4.2.3.28i.FWDG, 4.3.0.12i.FWDG, 5.0.1.99i.BASE |
|
|
| |
| |
Bug Id: | CSCut99726 |
Title: | continuous barrier error seen of Topaz S13 after upgrade to 29I |
|
Description: | Symptom:
Some fabric planes stayed in MCAST_DOWN state after image upgrade
Conditions:
As part of image upgrade, the router got reloaded. Once the router is boot-up, one of the LCC racks went for reload more than one time due to a continuous CCSQ ASIC reset in RP. After the 2nd reload, due to barrier errors the fabric bundle links started flapping but came up. However some of the S2 -> S3 stage links stayed down towards one of the CRS-X LCC racks. Hence the fabric planes stayed in MCAST_DOWN state.
It is observed that all the down links belong to a particular S2 ASICs which has all the S2 -> S3 links down to the affected rack S3. This led to the number of UP fabric bundle links being below the threshold, so the fabric bundle could not be declared as UP and hence the plane is MCAST_DOWN. The S13 fabric cards, where the fabric bundle links (S2 -> S3) are down, were continuously reporting the barrier errors.
Workaround:
Shutdown the fabric plane(s) which stayed in MCAST_DOWN state and reload the S2 cards belonging to that plane. Once the S2 cards are boot-up after reload, un-shut the corresponding fabric plane(s).
If more than one plane stayed in MCAST_DOWN state then follow the above step and recover the planes one by one.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 04-JUN-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCug71770 |
Title: | cepki Coredump after OIR active RSP - |
|
Description: | Symptom:
Not happening once initialization is over with cepki.
Conditions:
Crash happens after OIR active RSP.
Workaround:
Wait for some time to get it initialized. No other workaround other than this, if we wait for the init to complete then crash is not seen.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 04-JUN-2015 |
|
Known Affected Releases: | 4.3.1.BASE, 4.3.2.BASE, 4.3.3.BASE |
|
Known Fixed Releases: | 4.3.31.9i.BASE, 5.1.1.20i.BASE, 5.1.11.16i.BASE, 5.1.2.12i.BASE, 5.2.0.14i.BASE |
|
|
| |
| |
Bug Id: | CSCuu63353 |
Title: | Traffic drop with XPN-128 and XPN-256 with newly configured policy |
|
Description: | Symptom:
traffic drop once XPN-128 or XPN-256 is applied
Conditions:
using XPN-128 or XPN-256 macsec encryption
Workaround:
do not use XPN-128 or XPN-256
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 04-JUN-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuj95304 |
Title: | XR:4.3.1: Unable to disable MPLS TTLpropagation |
|
Description: | Symptom:
Disabling the MPLS TTL propagation for locally generated packets via "mpls ip-ttl-propagation disable local" global config on asr9k platform is not working.
Conditions:
This issue will be seen :
1)Only for mpls configuration
2) only for locally generated packets
3) if there is an outgoing label or explicit NULL.
As a result of this bug we see IP-TTL will still be propagated to MPLS-TTL if there is an outgoing label/Explicit Null.
Example: Traceroute, BGP etc
Workaround:
Expected Resolution: Please check with the support engineer for information on which release(s) this bug is expected to be fixed.
Will be fixed in 520 & 512
Reproducibility (%): 100%
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 04-JUN-2015 |
|
Known Affected Releases: | 4.3.1.BASE, 5.1.1.BASE |
|
Known Fixed Releases: | 4.3.4.SP4, 4.3.4.SP5, 4.3.4.SP6, 4.3.4.SP7, 5.1.11.BASE, 5.1.2.12i.BASE, 5.2.0.9i.BASE |
|
|
| |
| |
Bug Id: | CSCuc46165 |
Title: | CRS MSC-140G/14-10GBE going in reset after interface comes up 623173195 |
|
Description: | Symptom:
Customer running 4.2.1 on a CRS with a 14X10GB card goes into reset after an interface come up.
The card stay in-reset until the link is pull out, and the card is reset.
Conditions:
CRS running 4.2.1 with a 14X10GB card when GRE and QoS is enabled.
Workaround:
Disable GRE or QoS.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 04-JUN-2015 |
|
Known Affected Releases: | 4.2.1.BASE, 4.3.1.BASE |
|
Known Fixed Releases: | 4.3.1.17i.FWDG, 4.3.2.3i.FWDG, 5.1.0.2i.FWDG |
|
|
| |
| |
Bug Id: | CSCti93480 |
Title: | Fail to telnet&ssh into UUT with Failed to allocate pty |
|
Description: | Symptoms:
Affected device will not allow new Telnet or SSH Sessions. The devc-vty process shows high cpu usage.
Conditions:
Devices running an affected version of IOS-XR.
Workaround:
The issue can be recoverd from by issuing the process restart devc-vty command from the cli.
Further Problem Description:
The issue stems from a failure to properly release VTY resources when an affected device receives a series of malformed SSH packets. The device
may automatically recover from such an attack in certain situations.
Impact is limited to a failure to open new Telnet and SSH session to the device.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are
5/4.1:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:N/I:N/A:P/E:F/RL:OF/RC:C
CVE ID CVE-2011-0971 has been assigned to document this issue. Additional information on Cisco's security vulnerability policy can be found at the
following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 05-JUN-2015 |
|
Known Affected Releases: | 3.9.2.BASE, 3.9.3.BASE, 4.0.1.BASE |
|
Known Fixed Releases: | 3.9.3.7i.OSMBI, 4.0.1.13i.BASE, 4.1.0.9i.BASE |
|
|
| |
| |
Bug Id: | CSCuu36973 |
Title: | [NCS4k-SIT] traffic lost after power active RP reload |
|
Description: | Symptom:
After RP reload, APS traffic is down
Conditions:
After RP reload
Workaround: None
Reproducibility (%):100%
Further Problem Descri
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 05-JUN-2015 |
|
Known Affected Releases: | 5.2.4.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu10633 |
Title: | Traffic not resumed on Tunnel deletion/recreation after stdby RP plugout |
|
Description: | Symptom:
Traffic not recovered on tunnel deletion/recreation
Conditions:
After standby RP OIR
Workaround:
Insert standby RP and traffic recovered
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 05-JUN-2015 |
|
Known Affected Releases: | 5.2.4.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCup04472 |
Title: | CGSE+ Console is hung and 8 or 16 cores do not respond |
|
Description: | Symptom:
HA failures are detected if HA core-to-core test is enabled.
8 or 16 cores stop responding to show commands and stop processing NAT traffic
CGSE+ console (accessed using the command 'service-attach location will be unresponsive
Conditions:
There is no specific condition. Apparently, it is a CPU level issue and happens when there is an interrupt between the 'branch likely instruction' and a 'delay slot'. Hence there is no apparent condition at the usage level
Workaround:
There are no workarounds. Reload the card to recover
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 08-JUN-2015 |
|
Known Affected Releases: | 4.3.2.BASE, 5.1.3.BASE |
|
Known Fixed Releases: | 5.1.3.11i.BASE, 5.2.2.14i.BASE, 5.3.0.1i.BASE |
|
|
| |
| |
Bug Id: | CSCuu00270 |
Title: | Memory leak in BGP because of policy clientlib for attach point add/del |
|
Description: | Symptom:
policy_repository crash
Conditions:
after upgrade to 5.1.3
Workaround:
n/a
Further Problem Description:
there is no trigger is seen, customer is occasionally update the config by doing commit replace. This happen only on this router, other router in 5.1.3 same SMUs are working fine.
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 08-JUN-2015 |
|
Known Affected Releases: | 5.1.3.BASE |
|
Known Fixed Releases: | 5.3.2.10i.ROUT |
|
|
| |
| |
Bug Id: | CSCue04603 |
Title: | CRS 140G LC reload due to sporadic asic error |
|
Description: | Symptom:
1)LC/0/7/CPU0:Jan 12 12:34:44.131 : pse_pogo_driver[281]: %L2-PSE-6-INFO_MSG : PSE 0 Dumped PPE Exception data to /harddisk:/dumper/pogo_ppe_exception/ingress-pogo-v2-ppe_dump.node0_7_CPU0.first
LC/0/7/CPU0:Jan 12 12:34:44.146 : pse_pogo_driver[281]: %PLATFORM-CIH-5-ASIC_ERROR_ASIC_SCAN : ASIC SCAN is needed due to ASIC error 0x12800005 with instance 0
2)A LC on a Cisco CRS-3 may reload with an error message like the following example:
LC/0/13/CPU0:Jan 13 19:23:16.171 : platform_mgr_common[272]: %PLATFORM-HFR_PM-3-
ERR_FAULT_FROM_DEVICE : Device pla #0 has a fault=CRITICAL. action: Rebooting node
Conditions:
PSE driver is unable to fix the SBE in (CIMEM/GIMEM) and as a result SBE is getting accumulated into MBE on occurrence of another SBE at same memory. Also in the attempt of fixing the SBE, pse driver is corrupting the memory.
Workaround:
Not available.
Recovery:
This issue is due to soft error(very very rare to repro) and line card RMA wont fix the issue.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 08-JUN-2015 |
|
Known Affected Releases: | 4.1.2.BASE, 4.2.4.BASE |
|
Known Fixed Releases: | 4.3.1.24i.BASE, 4.3.1.24i.FWDG, 4.3.1.29i.FWDG, 4.3.2.14i.FWDG, 4.3.2.9i.BASE, 4.3.2.9i.FWDG, 5.1.0.3i.BASE, 5.1.0.3i.FWDG |
|
|
| |
| |
Bug Id: | CSCuu12932 |
Title: | After Reload of card having NNI link odu-group-ma process blocked |
|
Description: | Symptom:
After Reload of card having NNI link odu-group-ma process blocked and traffic is dropped
Conditions:
NNI links and traffic flooding on OTN GMPLS-TE circuits
Workaround:
NONE
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 08-JUN-2015 |
|
Known Affected Releases: | 5.2.4.BASE |
|
Known Fixed Releases: | 5.2.4.BASE |
|
|
| |
| |
Bug Id: | CSCus04459 |
Title: | no flowspec does not remove all v4 rules from linecard |
|
Description: |
Symptom:After unconfiguring flowspec on PE router, the rules are not removed from the h/w.
Conditions:After unconfiguring flowspec on PE router
Workaround:None.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 08-JUN-2015 |
|
Known Affected Releases: | 5.3.0.BASE |
|
Known Fixed Releases: | 5.3.0.21i.FWDG |
|
|
| |
| |
Bug Id: | CSCus38149 |
Title: | MFIB leaking share memeory in mfwd_info window |
|
Description: | Symptom:
MFIB is leaking share memory in mfwd_info window.
RP/0/RSP0/CPU0:router#show mfib counter shmwin loc 0/1/CPU0
Thu Jan 1 12:22:40.273 WET
Shmwin Memory Allocation Info :
[snip]
* Total shmwin sync free : 0
* Total packet mutex locks : 904533
* Num Shared Memory BVIDB : 3299521 <<<<<<<<< leaking here
* Num Shared Memory BVI INTF : 3299520 <<<<<<<<< leaking here
* Num Shared Memory Interface Head : 755
* Pool Size 168 : 1
* Pool Size 480 : 1
RP/0/RSP0/CPU0:router#sh memory 241 location 0/1/cpu0
Thu Jan 1 12:23:04.714 WET
node: node0_1_CPU0
------------------------------------------------------------------
Physical Memory: 8192M total
Application Memory : 8005M (3327M available)
Image: 57M (bootram: 57M)
Reserved: 128M, IOMem: 0, flashfsys: 0
Shared window vkg_pbr_ea: 35K
[snip]
Shared window im_rd: 1M
Shared window mfwd_info: 862M <<<<<<<<<< leaking at mfwd_info window
Shared window inline_svc: 35K
Shared window im_db_private: 1M
Shared window infra_statsd: 3K
[snip]
Conditions:
IGMP snooping is enable, but associated BVI interface is not multicast enable.
Workaround:
clear mfib database location can recover this problem.
Further Problem Description:
n/a
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 09-JUN-2015 |
|
Known Affected Releases: | 4.3.2.MCAST, 5.1.2.MCAST |
|
Known Fixed Releases: | 4.3.2.SP8, 5.2.4.4i.MCAST, 5.3.1.15i.MCAST |
|
|
| |
| |
Bug Id: | CSCuh85502 |
Title: | L2VPN - Control-Word (CW) configuration knob for VPLS VFI with BGP-AD |
|
Description: | Symptom:
No Control-Word setting cli knob is available for VPLS performing BGP-based auto-discovery.
Conditions:
!
bridge-domain CustA-BD
!
mtu 9000
interface GigabitEthernet0/1/1/1.100
!
vfi CustA-VFI
vpn-id 400
autodiscovery bgp
rd 65509:200400
route-target import 65509:200400
route-target export 65509:200400
signaling-protocol ldp
vpls-id 65509:200400
load-balancing flow-label both
!
control-word <-------------------------------missing
!
!
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 09-JUN-2015 |
|
Known Affected Releases: | 4.2.3.MPLS, 4.3.2.MPLS |
|
Known Fixed Releases: | 4.3.2.SP3, 4.3.2.SP5, 4.3.2.SP6, 4.3.2.SP7, 4.3.2.SP8, 5.1.11.5i.FWDG, 5.1.2.4i.FWDG, 5.2.0.16i.FWDG |
|
|
| |
| |
Bug Id: | CSCuu46298 |
Title: | changing cipher-suit on KS results in loss of trafic without recovery |
|
Description: | Symptom:
Ocne system is running with 5 macsec peer then changing the macsec encryption does take effect on the non-KS. BUt observng the complete traffic loss
Conditions:
there must be 5 peers. with 4 p2mp peers problem is not observed
Workaround:
use <5 p2mp peer
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 09-JUN-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu32699 |
Title: | After RPvm Switchover traffic fluctuation observed on multiple tunnels |
|
Description: | Symptom:
After Active RP reload/ RP side switch, Traffic for some odu-group-te tunnels fluctuates.
Conditions:
1. Configure several odu-group-te tunnels with a mix of 1+1 and 1+1+R protection types.
2. Toggle status of GCC communication channel between the node participating the in above circuit.
3. Side switch the active RP.
4. Traffic for some of the tunnels created in Step1 will fluctuate
Workaround:
None
Further Problem Description:
Reproducibility: 10% (Very-Rare)
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 09-JUN-2015 |
|
Known Affected Releases: | 5.2.4.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu40416 |
Title: | ATT-CERT: bfd crash on multiple METRO nodes on MC after router reload |
|
Description: | Symptom:
bfd_agent process cash with core dump crash on multiple METRO nodes on MC after router reload.
After this it restarts and does not crash.
Conditions:
Condition under which it occurred in test set up was with MC metro setup on reload of router.
Workaround:
no workaround as of now, but happens only on router reload.
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 09-JUN-2015 |
|
Known Affected Releases: | 5.3.1.CE, 5.3.2.CE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCum71513 |
Title: | BGP doesn't update LSD when backup path changes |
|
Description: | Symptom:
The backup BGP path in LSD is different from the backup path in BGP.
Conditions:
BGP had already installed a backup path to LSD, and then the backup path changed (i.e., a different path became the backup).
Workaround:
Restart BGP or LSD, or force a bestpath transition for that prefix.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 09-JUN-2015 |
|
Known Affected Releases: | 4.2.3.BASE, 4.2.4.ROUT |
|
Known Fixed Releases: | 4.3.2.SP3, 4.3.2.SP5, 4.3.2.SP6, 4.3.2.SP7, 4.3.2.SP8, 5.1.11.ROUT, 5.1.2.20i.ROUT, 5.1.3.1i.ROUT, 5.2.0.18i.ROUT |
|
|
| |
| |
Bug Id: | CSCuu45970 |
Title: | None of the plane has both Admin and Plane states UP over DT4 (arwen lu) |
|
Description: | Symptom:
In the Cisco NCS4k cli the Fabric card and Line cards are reporting as operation down, but traffic is not affected through them
Conditions:
1.insert RP, LC and FC cards into the Cisco NCS4k
2.Restart the R
Workaround:
None
Further Problem Description:
Reproducibility : 0%
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 09-JUN-2015 |
|
Known Affected Releases: | 5.2.4.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCun90694 |
Title: | Traffic loss when VRRP Master changes on a l2vpn environment. |
|
Description: | Symptom:
After VRRP/HSRP master switches from one router to another, the newly elected master router fails to program VRRP/HSRP MAC address on BVI interfaces. Traffic sent to VRRP/HSRP master router is dropped on BVI interfaces when receiving traffic from L2 bridge.
Conditions:
VRRP/HSRP is configured on BVI interface.
1. VRRP/HSRP failover happens back and forth rapidly within half MAC age (2 to 3 minutes by default). Meanwhile, high speed traffic is sending from VRRP mater to BVI bridge.
2. In some rare case, local router becomes VRRP/HSRP master while the master's MAC address is learned on some NPs, not on the last NP on each NP. When the control plane pushes the master's MAC to NP, the NPs which flag the MAC as dynamically learned will refuse the MAC push from control plane. Those NP will not have VRRP/HSRP MAC correctly programmed.
Workaround:
The following work around will eliminate 90% of the chance of hitting the bug.
Avoid LDP MAC withdraw message when VRRP master switchover occurs.
Avoid rapid VRRP failover back and forth within half MAC age.
Further Problem Description:
The symptom of the bug is: VRRP/HSRP virtual router MAC address on some NPs on the LC while the last NP on the LC does not have the MAC. User can use "shpw controllers np struct l2fIB search key <6-byte-MAC-address> all location <>" to dump MAC address on all NPs. When the problem is hit, the output should show the virtual router MAC address is on last NP, not on all NP.
The problem cannot be hit if there is only one NP on the LC. The more NPs on the LC, the higher chance of this bug hit during rapid VRRP/HSRP failover.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 09-JUN-2015 |
|
Known Affected Releases: | 4.2.3.BASE, 4.3.2.BASE, 5.1.1.BASE |
|
Known Fixed Releases: | 4.3.2.SP8, 5.1.2.20i.BASE, 5.1.3.1i.BASE, 5.2.0.18i.BASE |
|
|
| |
| |
Bug Id: | CSCus85027 |
Title: | fd leak on udp process of RP |
|
Description: | Symptom:
RP/0/RP1/CPU0:2015 Feb 9 16:37:21.853 IST: wdsysmon[437]: %HA-HA_WD-4-FD_MAJ_LIM : Process udp, pid 258601168 is using 14731 file descriptors out of a max of 15800. Major limit (90%) crossed.
RP/0/RP1/CPU0:2015 Feb 9 16:26:51.639 IST: wdsysmon[437]: %HA-HA_WD-3-FD_CRIT_LIM : Process udp, pid 257663184 is using 15633 file descriptors out of a max of 15800. Critical limit (95%) crossed.
Conditions:
Normal operation
Workaround:
None known
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 09-JUN-2015 |
|
Known Affected Releases: | 5.2.4.BASE, 5.3.1.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu21581 |
Title: | XR ISSU from CTC is not going through |
|
Description: | Symptom:
During issu ,before XR issu gets started, calvaods commit was not done.. Also before sending any query to node there was no time gap .Hence sometimes the first operation was not started/completed but second operation was sent on the node due to which ISSU does not gets completed.
Conditions:
Issu wizard is open and XR issu gets started.
Workaround:
Fix for this DDTS has been provided as SMU on DT27 image.
Further Problem Description:
Expected Resolution:-Fix for this DDTS has been provided as SMU on DT27 image.
Reproducible:-30%
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 09-JUN-2015 |
|
Known Affected Releases: | 5.2.4.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut77468 |
Title: | APRIL 2015 NTPd Vulnerabilities |
|
Description: | Symptom:
This product includes a version of ntpd that is affected by the vulnerability identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2015-1798 and CVE-2015-1799
This bug has been opened to address the potential impact on this product.
Conditions:
ntp authenticate
ntp authentication-key 1234 md5 104D000A0618 7
ntp trusted-key 1234
ntp peer 1.2.3.4 key 1234
>
< All versions before first commit are affected >
Workaround:
"Not available."
Further Problem Description:
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are: 4.3/3.2
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:M/Au:N/C:N/I:P/A:N/E:U/RL:OF/RC:C
The Cisco PSIRT has assigned this score based on information obtained from multiple sources. This includes the CVSS score assigned by the third-party vendor when available. The CVSS score assigned may not reflect the actual impact on the Cisco Product.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 09-JUN-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu30226 |
Title: | Calv ISSU should wait till NSR- ready to enable the next button on CTC |
|
Description: | Symptom:
CTC next button is enabled before standby RP vm NSR ready .
Conditions:
During calvados ISSU, standby RP vm NSR is not ready and Next button gets enabled.
Workaround:
Check in CLI for NSR ready
Further Problem Description:
Reproducibility: 100%
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 09-JUN-2015 |
|
Known Affected Releases: | 5.2.4.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu38515 |
Title: | support of .tar SMU |
|
Description: | Symptom:
.tar file cannot be added from CTC.
Conditions:
In CTC, while adding .tar file, it throws error that this file type is not supported.
Workaround:
Add .tar from CLI end.
Further Problem Description:
Reproducibility: 100%
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 09-JUN-2015 |
|
Known Affected Releases: | 5.2.4.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCto56028 |
Title: | ksh on the standby RP leaking 8.553 MB of memory per day |
|
Description: | Symptom
-------------
Memory leak during aux login if kept idle.
Condition
------------
If aux authentication is enabled and if we don't enter the username, it will
keep prompting for username and we can observe the memory leak in ksh/aaa code
Work around
----------------
1. Don't enable aux authentication. Set AUX_AUTHEN_LEVEL=0 at rommon prompt
2. If you want to enable aux authentication, don't keep the aux login idle
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 10-JUN-2015 |
|
Known Affected Releases: | 4.0.2.BASE |
|
Known Fixed Releases: | 4.0.3.2i.BASE, 4.0.3.3i.BASE, 4.0.3.BASE, 4.1.1.20i.BASE, 4.1.1.21i.BASE, 4.2.0.3i.BASE |
|
|
| |
| |
Bug Id: | CSCuu04665 |
Title: | bundle_mgr crash pointing to rdm |
|
Description: |
Symptom:
When a slice PON reset is immediately followed by a hard reset, bundlemgr process crashes.
Conditions:
1. Slice PON reset is triggered.
2. While the data is being replayed after the pon reset, a hard reset is triggered which results in the crash.
Workaround:
If the resets are manually triggered , sufficient time gap between them will avoid the crash.
Further Problem Description:
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 10-JUN-2015 |
|
Known Affected Releases: | 5.2.5.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuq33737 |
Title: | Multicast Auto-RP mappings leak when interface flaps |
|
Description: | Symptoms:
On a MPLS PE, it is possible for
auto-RP announcementts from one VRF to leak into a different VRF
Conditions:
All the following must be met, plus there is a narrow timing window where packets from the two different VRFs are processed one after the other
in the MPLS PE router.
- MPLS PE router.
- Several VRFs, where more than two of them use multicast auto-RP
- Interface flaps
- Auto RP information flap in the VRF that would receive the extraneous auto-RP information.
Workaround:
Add a secondary interface to prevent the (S,224.0.1.40) entry from expiring
in the VRF that could receive the foreign auto RP information.
Further Problem Description:
From the receiving VRF perspective, this could interfere with the auto-RP
information in that VRF, for that, the ''received'' information would need to be
routable in that VRF.
From the sending VRF, this can be seen as a partial information disclosure, but the disclosed information is very limited, it consist of:
- Well known Auto-RP multicast groups.
- Address of the rendevouz point (RP) on the sending VRF.
The two VRFs are not selectable, the conditions for this bug depends on succeessive processing of multicast packets from the two VRFs in the PE
router.
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 2.6/2:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:H/Au:N/C:P/I:N/A:N/E:POC/RL:OF/RC:C
No CVE ID has been assigned to this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 10-JUN-2015 |
|
Known Affected Releases: | 4.1.2.MCAST |
|
Known Fixed Releases: | 5.2.2.26i.MCAST, 5.2.3.12i.MCAST, 5.2.4.1i.MCAST, 5.3.0.10i.MCAST |
|
|
| |
| |
Bug Id: | CSCur04029 |
Title: | Wrong values of SD/SF BER threshold for non-Bonavista/non-Torngate plim |
|
Description: | Symptom:
Not able to configure SD/SF threshold values.
Output of "show controller dwdm r/s/i/p" command shows garbage values for SD/SF threshold default.
RP/0/RP1/CPU0:CRS-BB-05(config-dwdm)#g709 odu threshold sf-ber 5 ?
RP/0/RP1/CPU0:CRS-BB-05(config-dwdm)#g709 odu threshold sf-ber 5
RP/0/RP1/CPU0:CRS-BB-05(config-dwdm)#commit
Thu Sep 4 03:57:40.370 UTC
% Failed to commit one or more configuration items during a pseudo-atomic operation. All changes made have been reverted. Please issue 'show configuration failed [inheritance]' from this session to view the errors
Conditions:
when you set the SF/SD threshold value. commit in failing.
Workaround:
None
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 11-JUN-2015 |
|
Known Affected Releases: | 5.1.4.BASE |
|
Known Fixed Releases: | 5.1.4.9i.FWDG, 5.3.1.10i.FWDG |
|
|
| |
| |
Bug Id: | CSCus49973 |
Title: | All SFE link for Hy-phy LC are in operational down state. |
|
Description: | Symptom:
Line card fabric links might stay operationally down after router reload or LC reload.
Conditions:
You may see on one or more fabric links. Triggers include
1. Physical removal/insertion of line card.
2. Reload the router
3 Soft reload of line card.
Workaround:
Expected Resolution: This issue is under investigation.
Reproducibility (%): 5%
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 11-JUN-2015 |
|
Known Affected Releases: | 5.2.4.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCul58246 |
Title: | Service Pack version handling |
|
Description: | This fix enables detecting SP as a SMU like package. Without it, the SP will have deactivation/version issues.
Symptom:
Service Pack version in "show version" is incorrect. Service Pack deactivation fails.
Conditions:
Service Pack is activated on any image.
Workaround:
No workaround.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 11-JUN-2015 |
|
Known Affected Releases: | 4.3.2.BASE |
|
Known Fixed Releases: | 4.3.2.SP1, 4.3.2.SP2, 4.3.2.SP3, 4.3.2.SP5, 4.3.2.SP6, 4.3.2.SP7, 4.3.2.SP8, 4.3.4.SP1, 4.3.4.SP4, 4.3.4.SP5 |
|
|
| |
| |
Bug Id: | CSCuu09549 |
Title: | vpe crashed when doing configuration on the router |
|
Description: | Symptom:
Hi, Bud:
I saw this crash on both 0422A and 3I image, the decode is below.
For the 3I image below the crash happened at Apr 26 18:48, when the script did the configuration on the router:
-rw-r--r-- 1 root root 35522886 Apr 26 18:48 vpe_6998.by.6.20150426-184632.uvf.5172f.core.gz
http://ott-pixr1.cisco.com/cgi-bin/hfr-mpls/auto-view.php?file=/auto/ott-tst/apache/htdocs/ena-rsvp-regression/regression_archives/www/2015Apr/oliviaj/600037959-10-931482-sunstone_2CEs2PEs_noRR_coreOSPF_edgeSTATICISIS.2015Apr26_18:44:58.ott-ss-dt-01-6pe/TaskLog.config2CEs2PEs1P_LDP__ospf____ebgp-static-isis__.html
Could you please take a look and let me know if a DDTS is need to track this issue.
-----
#0 0x00007fbfa894a389 in raise () from /auto/ng_ott_auto/DEVELOPMENT_USERS/oliviaj/tmp/root/lib64/libc.so.6
#1 0x00007fbfa894b788 in abort () from /auto/ng_ott_auto/DEVELOPMENT_USERS/oliviaj/tmp/root/lib64/libc.so.6
#2 0x000000000040f0ee in os_panic () at /ws/griseb-bxb/vpe_sunstone_dpdk18/closed-repo/build-data/../vpe/vnet/main.c:212
#3 0x00007fbfaa24de3d in vlib_worker_thread_barrier_sync ()
at /ws/griseb-bxb/vpe_sunstone_dpdk18/open-repo/build-data/../vlib/vlib/threads.c:854
#4 0x00007fbf3993e45f in dpa_poll ()
at /workspace/kentp/dt_images/5.4.0.03I/workspace/platforms/common/gdplane/platform/sunstone/dpa/dpa_poll.c:523
#5 0x00007fbf3993e7c0 in dpa_input [dpa_input.244461.457?...] (vm=0x8419c0, node=Unhandled dwarf expression opcode 0xf3
)
at /workspace/kentp/dt_images/5.4.0.03I/workspace/platforms/common/gdplane/platform/sunstone/dpa/dpa-input.c:209
#6 0x00007fbfaa235fa2 in vlib_main () at /ws/griseb-bxb/vpe_sunstone_dpdk18/open-repo/build-data/../vlib/vlib/main.c:905
#7 0x00007fbfaa4660e3 in thread0 () at /ws/griseb-bxb/vpe_sunstone_dpdk18/open-repo/build-data/../vlib/vlib/unix/main.c:384
#8 0x00007fbfa97df640 in clib_calljmp () at /ws/griseb-bxb/vpe_sunstone_dpdk18/open-repo/build-data/../clib/clib/longjmp.S:96
#9 0x00007fff979dbac0 in ?? ()
#10 0x00007fbfaa466888 in vlib_unix_main ()
at /ws/griseb-bxb/vpe_sunstone_dpdk18/open-repo/build-data/../vlib/vlib/unix/main.c:443
#11 0x0000000000000000 in ?? ()
(gdb)
Conditions:
Refpoint = calvados/release@ci-msl/5
Built By : kentp
Built On : Sun Apr 26 08:48:30 EDT 2015
Build Host : ott-pd-vs-016
Workspace : /workspace/kentp/dt_images/5.4.0.03I/workspace
Source Base : ios_ena
Devline : bnb-54-flex.lu
Devline Type : ACME Project (Devline uses a project: bnb-54-flex%105)
bnb-54-flex EFR-00000302823 Project
ci-msl EFR-00000302174 Lineup
ci-532 EFR-00000299491 Lineup
ci-531 EFR-00000298991 Lineup
default EFR-00000294653 Lineup
RP/0/RP0/CPU0:pe1-uut#
Workaround:
N/A
Further Problem Description:
Core file and txt file location:
rw-r--r-- 1 oliviaj eng 10313785344 Apr 27 14:03 vpe_6998.by.6.20150426-184632.uvf.5172f.core
drwxrwxrwx 2 oliviaj eng 4096 Apr 27 14:37 ./
-rwxrwxr-x 1 65534 65534 13920 Apr 27 14:37 vpe_6998.by.6.20150426-184632.uvf.5172f.core.txt*
ott2lab-as3:1071> pwd
/auto/ng_ott_auto/DEVELOPMENT_USERS/oliviaj/core_files
ott2lab-as3:1072>
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 12-JUN-2015 |
|
Known Affected Releases: | 5.4.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu32158 |
Title: | otn_ma took 4 seconds to inform IM about LC OIR event |
|
Description: | Symptom:
Delay of four seconds in switch to restore path after NCS4K-2H-O-K LC OIR.
Conditions:
LC OIR triggers restore on 1+R.
Workaround:
None
Reproducibility (%):- 50
Further Problem Description:
None
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 12-JUN-2015 |
|
Known Affected Releases: | 5.2.4.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCue58130 |
Title: | fib_mgr[163]: %PLATFORM-PLAT_FIB-3-ERROR : 6 0x6029c174 ECLDI_V2: LSPA H |
|
Description: | Symptom:
The following error message might be observed on a Cisco CRS indicating an exhaustion
of TLU resources:
LC/0/3/CPU0:Feb 13 21:15:31.872 : fib_mgr[163]: %PLATFORM-PLAT_FIB-3-ERROR : 6 0x6029e9ec
ECLDI_V2: LSPA HW alloc failed Not enough memory rc: 0xc : pkg/bin/fib_mgr : (PID=114788) : -
Traceback= ad4e3f2 ac5f40e aa0d3c6 aa0d92b aa17125 aa06947 a975091 4281a0a 42d02f1 42d1e64
42d2419 42b7ff2 42b8e07 42b8f6b 8200a8e 8200a36
Conditions:
The issue happens on CRS with an IOS-XR version 4.2.1 or higher.
Also, the CRS must have 6PE/VPE configured.
With MSC-140G/FP-140G linecards, it manifests as ingress TLU exhaustion
on channels 5 and 6 - MPLS.
With legacy MSC linecards, it manifests as ingress TLU exhaustion
on channels 0 - MPLS.
Workaround:
none
Recovery:
Reload the affected LC.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 12-JUN-2015 |
|
Known Affected Releases: | 4.2.3.BASE |
|
Known Fixed Releases: | 4.3.1.24i.FWDG, 4.3.2.9i.FWDG, 5.1.0.3i.FWDG |
|
|
| |
| |
Bug Id: | CSCuu34619 |
Title: | After Mid node power cycle Traffic down on few tunnels. |
|
Description: | Symptom:
On power cycle of MID node, traffic on Tunnels will not recover even after MID node comes up.
Conditions:
1. Tunnels should be created on a topology having at least 3 nodes. Initially Working path should be up and traffic is running.
2. Power cycle any of MID node having OTN links carrying active traffic.
3. On MID node coming up after power cycle, Traffic will not recover even though MID node comes up.
Workaround:
None.
Further Problem Description:
Reproducibility(%):
50%
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 12-JUN-2015 |
|
Known Affected Releases: | 5.2.4.BASE, 5.2.4.MPLS |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuc02092 |
Title: | ONE-P fails to validate IDL length |
|
Description: | $$PRECFS
Symptoms:
The ONE-P process does not effectively validate input which could allow for a denial-of-service condition on the device.
Conditions:
A device configured to make use of the ONE-P functionality.
Workaround:
None.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 7.1/5.9:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:M/Au:N/C:N/I:N/A:C/E:F/RL:OF/RC:C
No CVE ID has been assigned to this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 12-JUN-2015 |
|
Known Affected Releases: | 4.2.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCui76623 |
Title: | Meta-data anomalies detected on install verify packages |
|
Description: | Symptom:After IOS-XR upgrade the error "meta-data anomalies detected" may be displayed when the CLI "install verify packages" is executed.
Conditions:The problem may happen if there are stale entries of dirlist.db in the local_md5_meta file.
Workaround:No workaround is available.
More Info:The problem may occur if the update of the local_md5_meta file is not done properly during package removal. Occasionally improper entries of db files remain as stale in local_md5_meta file. There is no operational impact on the install infrastructure or functionality of the router.
local_md5_meta was introduced in Release 3.7 with issues seen upgrading/downgrading from old releases including 4.2.1.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 12-JUN-2015 |
|
Known Affected Releases: | 4.3.2.BASE |
|
Known Fixed Releases: | 4.3.4.12i.BASE, 5.1.1.8i.BASE, 5.1.11.4i.BASE, 5.1.2.1i.BASE, 5.2.0.2i.BASE |
|
|
| |
| |
Bug Id: | CSCur04769 |
Title: | pkg/bin/sysdb_mc crash on loading ACL scale config |
|
Description: |
Symptom:sysdb_mc process will crash and might result in system getting hang for few minutes, but it will self recover and the system will become stable after few minutes
Conditions:This crash is seen when we try to load a big ACL config(~ 300K lines)
Workaround:This crash is not seen for smaller config (~150K lines)
More Info:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 12-JUN-2015 |
|
Known Affected Releases: | 5.1.4.BASE |
|
Known Fixed Releases: | 5.2.4.8i.BASE, 5.2.5.4i.BASE, 5.3.0.18i.BASE |
|
|
| |
| |
Bug Id: | CSCtt18880 |
Title: | BGP crash during RP switchover |
|
Description: | Symptom:
The BGP process crashed during an RP switchover.
Conditions:
Occurred during RP switchover.
Workaround:
Unknown.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 12-JUN-2015 |
|
Known Affected Releases: | 4.1.2.ROUT |
|
Known Fixed Releases: | 4.1.2.ROUT, 4.2.0.28i.ROUT |
|
|
| |
| |
Bug Id: | CSCuu14640 |
Title: | ESD crash and traffic down after RP OIR |
|
Description: |
Symptom:ESD crash seen after RP OIR for a P2 card.
Conditions:RP OIR of a P2 LC. Issue seen on a single setup only
Workaround:None
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 12-JUN-2015 |
|
Known Affected Releases: | 5.2.4.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut96381 |
Title: | History bucket not working |
|
Description: | Symptom:The history bucket is not working in perf-mgmt. The show command doesnt show any data.
Conditions:In normal case also the history bucket doesnt work. There is no special trigger for this issue.
Workaround:Expected Resolution: Please check with the support engineer for information on which release(s) this bug is expected to be fixed.
Reproducibility (%):100%
There is no workaround for this
More Info:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 12-JUN-2015 |
|
Known Affected Releases: | 5.2.4.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCto11030 |
Title: | Ping process crashed with parallel pings |
|
Description: | Symptom:
Ping process crash
Conditions:
Issue is seen when parallel pings are performed on multiple vty sessions.
Workaround:
None
Recovery:
None
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 12-JUN-2015 |
|
Known Affected Releases: | 4.0.2.ROUT |
|
Known Fixed Releases: | 4.1.1.22i.BASE, 4.1.1.22i.FWDG, 4.2.0.5i.BASE, 4.2.0.5i.FWDG |
|
|
| |
| |
Bug Id: | CSCuu65686 |
Title: | session for sub interfaces stuck in INIT |
|
Description: | Symptom:
session stuck in INIT state while macsec is enaled on two subinterfaces of the physical port
Conditions:
macsec is enabled on the subinterfaces
Workaround:
do not enable multiple encapsulation on subinterfaces or do not enable macsec on multiple encapsulated subinterfaces of same physical port
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 15-JUN-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu33521 |
Title: | BFD sessions flapping when the traffic is oversubscribed |
|
Description: | Symptom:
This is on 6vpe setup (but the issue is not related to 6vpe--use it for repro reference)
TOPO:
ixia--ce1--pe1--p--pe2--ce2--ixia
ce1 and pe1 are sunstone routers with 10G passthrough and 1g (ether1000) in between. pe2/p/ce2 are asr9k routers.
Without traffic running, the bfd sessions between CE1 and PE1 are all up and no flapping (stable.
Then turn on traffic with the 40% of 10G line rate on each side, we can see the bfd sessions are continuously flapping.
Copy Bud's initial analysis here:
After turning on the TM on both back-to-back sunstones, and increasing
the number of dpdk buffers so we don't run out, the sessions are still flapping.
These stats are 60 seconds after they were cleared. Two stats stand out:
- the "no punt buffer" drops.
The dataplane can buffer up to 500 high priorty punts waiting for the DPA
to send them to XR. Seems like the dataplane got a big burst, faster than
the DPA could consume them
- the 10GE rx-miss drops.
This happens when the 10GE NIC receives packets faster than the
dataplane can pull them from the RX ring. The incoming packets here
are 1500B at 328Kpps, which is not a lot. So something is making the
dataplane stop servicing the 10GE (and by inference, all) interfaces
for a short period of time.
I'll keep looking...
bud
P2# sho er
Count Node Reason
24873609 ant-input packets received
24875491 ant-ingress packets received
20564 ant-ingress ant-ingress drop
24852249 ant-egress packets received
20877231 ant-egress Ant-egress Drop
3977696 ant-tx packets received
201 ant-tx no punt buffer drop for high priority
8199 ant-tx punt processing
3969296 ant-tm packets enqueued
2762037 ant-tm packets dequeued
1207312 ant-tm-bg-deq packets dequeued
24852249 tb-output-fab packets received
24873609 ant-plu-ing packets received
1882 dpa-input packets injected
P2# sho dpa stat g
Index Name Count
34 From Fabric inject packets 667
44 NP Port inject packets 1332
48 Preroute PIT packets 65
49 Preroute next-hop packets 146
55 To Fabric inject packets 667
1863 Punt IPv6 BFD 128
1911 Punt adj 6030
1912 Punt adj (policer drop) 4252073
1926 Punt for ICMP 921
1927 Punt for ICMP (policer drop) 99585
P2# sho int
Name Idx State Counter Count
GigabitEthernet0/8/0 7 up rx packets 267609
rx bytes 400235904
tx packets 783145
tx bytes 1171460840
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 15-JUN-2015 |
|
Known Affected Releases: | 5.4.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCut94977 |
Title: | ipv6 SR/LDP with LDP pref: not all labels imposed on TI-LFA backup path |
|
Description: |
Symptom:The label stack for a TI-LFA single-segment (PQ) and double-segment (P and Q) protection is not correctly imposed on the backup path for ipv6 prefixes. TI-LFA protection will not be effective.
Conditions:- ipv6 network with LDP and SR enabled
- LDP configured as preferred for ipv6 (default: no "sr-prefer" keyword after "segment-routing mpls")
- TI-LFA calculates a single-segment (PQ) or double-segment (P and Q) protection for one or more ipv6 destinations
Workaround:remove LDP for ipv6 or configure SR as preferred for ipv6 ("sr-prefer")
More Info:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 15-JUN-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCty84842 |
Title: | With GR enabled, Stale route not cleaned up after bgp neighbor unconfig |
|
Description: | Symptom:
- Stale prefix remain in the BGP table instead of properly aging out
Conditions:
- BGP Graceful-Restart (GR) capability is enabled on the router
- BGP GR capability is exchanged with the peer and the peer session is established
- Un-configure the peer on router
Workaround:
If the issue is not hit, use one of the workarounds below to avoid it.
1) If the BGP GR enabled peer is shutdown prior to un-configuring it, the stale path from that peer will not show up
2) If BGP GR is disabled globally or individually for the peer prior to un-configuring it, the stale path from that peer will not show up. Make sure the peer is not GR enabled before un-configuring. A peer session flap may be required for this.
If the issue is hit, restart bgp process on Active RP to clear the issue.
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 15-JUN-2015 |
|
Known Affected Releases: | 4.2.1.BASE, 4.2.4.ROUT, 4.3.0.BASE |
|
Known Fixed Releases: | 4.3.0.17i.ROUT |
|
|
| |
| |
Bug Id: | CSCuo75699 |
Title: | [4.2.3] x86:IPSLA perm port cfg on responder leads to socket exhaustion |
|
Description: | Symptom:
The following msg is displayed on on the responder side:
RP/0/RP0/CPU0:XRSMU1-CRS1a#sh logging RP/0/RP0/CPU0:May 12 02:03:33.263 : ipsla_responder[1121]: %MGBL-IPSLA-5-INTERNAL : Failed to open a port:1151568896:'Subsystem(2375)' detected the 'warning' condition 'Code(6)'
RP/0/RP0/CPU0:May 12 02:05:23.261 : ipsla_responder[1121]: %MGBL-IPSLA-5-INTERNAL : Failed to open a port:1151568896:'Subsystem(2375)' detected the 'warning' condition 'Code(6)'
RP/0/RP0/CPU0:May 12 02:07:13.261 : ipsla_responder[1121]: %MGBL-IPSLA-5-INTERNAL : Failed to open a port:1151568896:'Subsystem(2375)' detected the 'warning' condition 'Code(6)'
On the sender side, the return code is RespFailure.
Conditions:
1) X86-based sender and
2) "Long duration" is configured (i.e. "packet count" * "packet interval" + timeout > 65,535 ms)
Workaround:
Process restart ipsla_responder
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 15-JUN-2015 |
|
Known Affected Releases: | 4.2.3.MGBL |
|
Known Fixed Releases: | 5.1.3.14i.MGBL, 5.2.2.11i.MGBL, 5.3.0.1i.MGBL |
|
|
| |
| |
Bug Id: | CSCus48746 |
Title: | SCAPA DT9 - no commands at Calvados RP1 after RP0 hw-module reload |
|
Description: | Symptom:
No commands accepted by Calvados console other than "exit"
Conditions:
Issue randomly detected at Calvados console at boot-up (power cycle and/or hw-module reload)
Workaround:
User need to power cycle the node to restore functionality of affected Calvados console
Further Problem Description:
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 15-JUN-2015 |
|
Known Affected Releases: | 5.2.4.ADMIN |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu21295 |
Title: | cef: ECMP load-balancing problem after phy link flap |
|
Description: | Symptom:
cef load balancing issue
When there is a recursive route, which depends on several load balancing interfaces, and there is at least one POS interface for load balancing,
If one link flap, then load balancing groupwill not be recalculated.
Conditions:
Phy link flap
Recursive route
The route is using p2p interface, typically POS.
Workaround:
configure the next hop in the static route
For the static route config, we must specify next hop IP address.
Further Problem Description:
This bug will impact all p2p interfaces (physical and virtual).
In most cases, however, virtual p2p interfaces are not used in a way that this issue can be triggered.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 15-JUN-2015 |
|
Known Affected Releases: | 4.2.4.FWDG |
|
Known Fixed Releases: | 5.3.2.9i.FWDG |
|
|
| |
| |
Bug Id: | CSCun06352 |
Title: | ods_update_entry: lst_delete() error: 'prm_server' detected the 'warning |
|
Description: | Symptom:pifilter timing out on PRM when modifying the ACL, leading to an ACL being configured on the system, but not being committed in the config. Essentially each ACE entry is taking seconds to program, which leads to a timeout. The ACL under the cover gets applied, but it doesn't get committed in the config, the commit fails.
Conditions:Can happen under any normal operation
Workaround:Remove the ACL from all interface and attempt another configuration.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 5.1.2.BASE, 5.2.0.BASE |
|
Known Fixed Releases: | 4.3.4.SP6, 4.3.4.SP7, 5.1.2.20i.BASE, 5.1.3.1i.BASE, 5.2.0.18i.BASE |
|
|
| |
| |
Bug Id: | CSCut47784 |
Title: | [NCS4K-2H-W] RTRV-OTL show OPR values in wrong way |
|
Description: | Symptom:
When RTRV-OTL command is executed, OPR values were being displayed improperly, with next lane data merging with the one before. Also rtrv-otl for specific fac was displaying invalid aid response.
Conditions:
On scapa node with DWDM LC and traffic up and running, execute RTRV-OTL command to retrieve optics lane data.
Workaround:
None
Expected Resolution: Will be given in later release after 5.2.4.
Reproducibility (%): 100%
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 5.2.4.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu04195 |
Title: | [NCS4k-SIT] NNI TCM link down after head node RP switchover |
|
Description: | Symptom:
NNI TCM link is down after head node RP switchover.
Conditions:
On RPFO with ODU-Group controller and GMPLS configurations,link goes down
Workaround:
None
Reproducibility (%): - 100%
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 16-JUN-2015 |
|
Known Affected Releases: | 5.2.4.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCek40854 |
Title: | mpls te tunnels down due to ospf router-id not read |
|
Description: | Symptom: All the mpls tunnels down due to ospf router-id not read
Conditions: The mpls pie has been installed/upgraded after the mpls config in ospf.
Also seen after replacing ISIS with OSPF
Workaround: Re-apply the ospf router-id (We probably have to delete and re-add it).
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 3.3.91.BASE |
|
Known Fixed Releases: | 3.3.0.1i.ROUT |
|
|
| |
| |
Bug Id: | CSCum18842 |
Title: | SAT: obfl_mgr crash during LC xr-vm reload |
|
Description: | Symptom:
Issue observed one time. obfl_mgr crashed due to internal timer timeout. Issue thought to be a kvm_long_exit suspension of sysadmin VM.
Conditions:
Not known - problem is not reproducible.
Workaround:
None.
Further Problem Description:
If encountered, /var/log/messages should be gathered from HOST partition of node reporting crash.
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 5.0.1.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCte72653 |
Title: | Forward asynch pulse to GSP PD lib |
|
Description: | Symptom:
Upon RP FO, multiple processes terminated on the standby RP and the standby RP was continuously reset.
Conditions:
This is observed in a CRS-1 running 3.8.3 interim built.
Workaround:
There is no known workaround.
Recovery:
None.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 3.8.3.18i.BASE, 3.8.3.BASE, 3.9.0.ROUT, 3.9.1.BASE, 4.0.0.BASE |
|
Known Fixed Releases: | 3.8.3, 3.8.3.24i.ADMIN, 3.8.4, 3.9.1, 3.9.1.24i.ADMIN, 3.9.2, 3.9.3, 4.0.0, 4.0.0.10i.BASE, 4.0.1 |
|
|
| |
| |
Bug Id: | CSCua94975 |
Title: | te_control crashed at rib_tlv_strip after config file applied |
|
Description: | Symptom:
Hit this crash after applied the config file by commit replace
Conditions:
load the config file then commit replace
Workaround:
No
|
|
Status: | Terminated |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 4.2.3.BASE, 4.3.1.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCug98053 |
Title: | (510-SSR3)PLATFORM-SHELFMGRV2-6-TIMER_EXPIRED : Failed to get MBI Hellos |
|
Description: | Symptom:
On turbobooting of image, few LCs were not coming up.
Conditions:
On booting of new 510 image
Workaround:
No workaround exists
Reproducibility (%): 75%
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 5.1.0.BASE, 5.1.1.BASE, 5.1.1.ROUT |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCus42773 |
Title: | JANUARY 2015 OpenSSL Vulnerabilities |
|
Description: | Symptom:This product includes a version of SSL that is affected by the vulnerability identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2014-3569 CVE-2014-3570 CVE-2014-3571 CVE-2014-3572 CVE-2014-8275 CVE-2015-0204 CVE-2015-0205 CVE-2015-0206
This bug has been opened to address the potential impact on this product.
Conditions:Cisco IOS XR is only affected by CVE-2015-0204 and CVE-2014-3570.
None of the other CVE-IDs are applicable.
The version of OpenSSL used in Cisco IOS XR will be updated under Cisco bug ID: CSCur26433
Workaround:
None.
More Info:
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score.
The Base and Temporal CVSS scores as of the time of evaluation are: 4.3/3.6
http://tools.cisco.com/security/center/cvssCalculator.x?version=2.0&vector=AV:N/AC:M/Au:N/C:P/I:N/A:N/E:F/RL:OF/RC:C
The Cisco PSIRT has assigned this score based on information obtained from
multiple sources. This includes the CVSS score assigned by the third-party
vendor when available. The CVSS score assigned may not reflect the actual
impact on the Cisco Product.
Additional information on Ciscos security vulnerability policy can be
found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Status: | Other |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 5.3.3.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu45631 |
Title: | Error comes on applying changes after reloading card through CTC. |
|
Description: | Symptom:
After reloading the card from the inventory, apply button remains enable.
Conditions:
After reloading the card from the inventory successfully, user clicks the Apply button again and error-pop up message comes.
Workaround:
Expected resolution: Fix will be available in Release 6.0
Reproducibility : 60%
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 5.2.4.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCul11222 |
Title: | BFD process crash on RSP FO |
|
Description: | Symptom:
bfd processc crash
Conditions:
RSP FO with 1000 Flex LSP tunnels
Workaround:
Not known
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 5.2.0.BASE, 5.2.1.BASE |
|
Known Fixed Releases: | 5.2.0.5i.FWDG |
|
|
| |
| |
Bug Id: | CSCty50129 |
Title: | Improperly bounded memcpy in sftpsvr_mkdir |
|
Description: | Symptoms:
This is a proactive software enhancement to implement secure best practice procedures into the code.
Conditions:
Default configuration.
Workaround:
None
PSIRT Evaluation:
The Cisco PSIRT has evaluated this issue and does not meet the criteria for PSIRT ownership or involvement. This issue will be addressed via
normal resolution channels
If you believe that there is new information that would cause a change in the severity of this issue, please contact psirt@cisco.com for another
evaluation.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 4.2.0.BASE |
|
Known Fixed Releases: | 4.2.1.22i.BASE, 4.2.1.26i.BASE, 4.2.2.2i.BASE, 4.2.3.5i.BASE, 4.2.3.9i.BASE, 4.3.0.6i.BASE |
|
|
| |
| |
Bug Id: | CSCtw64363 |
Title: | RP Consoles Frozen on MC after Reload/Activate |
|
Description: | Symptom:
redfs_svr mutex process gets blocked on RP0 of Rack1
Conditions:
after MultiChassis router reload.
Seen intermittently on one testbed.
Workaround:
n/a
Recovery:
Need to powercycle the MC in case no CLI access to router due to router busy.
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 4.2.0.BASE, 4.2.1.BASE, 4.3.0.BASE |
|
Known Fixed Releases: | 4.2.1.26i.BASE, 4.2.2.2i.BASE, 4.2.3.9i.BASE, 4.3.0.8i.BASE |
|
|
| |
| |
Bug Id: | CSCtk55589 |
Title: | DUI-4.0.1.22i: mpls_ldp[1041]: rm: Error reading directory //dev/shmem/a |
|
Description: | symptom:
The following console message is seen by the user:
rm: Error reading directory //dev/shmem/aipc/.....
conditions:
This message is seen under the following conditions:
(a) Upon restart of the processes that is using the AIPC infrastructure.
(b) Upon SMU installation when the process(es) using the AIPC infrastructure are restarted as a result of the SMU installation.
(c) When a image upgrade in performed on the node.
This error message is seen for some applications upon start up.
work around:
No workaround is available. This is a harmless console message and will not impact the functional operation of the node.
recovery:
No recovery is required in this case as the console message is harmless.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 4.0.1.BASE, 4.1.0.BASE, 4.1.0.ROUT, 4.1.1.BASE |
|
Known Fixed Releases: | 4.0.1.BASE, 4.0.2.8i.BASE, 4.1.0.19i.BASE, 4.1.0.20i.BASE |
|
|
| |
| |
Bug Id: | CSCua05162 |
Title: | sysmgr crashed in ISSU run phase |
|
Description: | Symptom: sysmgr crash due to bad address access in cerrno library
Conditions:sysmgr initialization on v2 during node IMDR
Workaround:Not available
Fix:cerrno library invokes sysmgr_get_respawn_count API to ensure sysmgr is up and running before invoking shm_open API
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 4.2.1.BASE |
|
Known Fixed Releases: | 4.2.3.18i.BASE, 4.3.0.20i.BASE |
|
|
| |
| |
Bug Id: | CSCek48043 |
Title: | nrs crash freeing malloc object that is not allocated |
|
Description: | 1. In rare interactions of resource allocation and timing, NRS and another process may contend for the same memory resource leading to some delays while the operation is retried.
2. Conditions: If a context switch occurs while NRS is freeing its
async_msg_ctx structure and that memory is re-allocated to another process,
when NRS becomes active again it can finish the cleanup and free the object
which it no longer owns.
3. Workaround: None.
4. Further problem description: This is one of two fixes which must both be
included to fully fix the problem. The other part of the fix is in DDTS
CSCsd94943. This DDTS addresses something that was overlooked in the original fix.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 3.3.2.BASE, 3.4.0.BASE |
|
Known Fixed Releases: | 3.3.2.5i.BASE, 3.4.0.6i.BASE |
|
|
| |
| |
Bug Id: | CSCth58327 |
Title: | PLATFORM-SHELFMGR-3-UNKNOWN_BOARD - invalid board type msg after OIR |
|
Description: | B>Symptom:
Card is not booting , it is kept in "IN-RESET" and the similar message is seen in the logs
RP/0/RP1/CPU0:Aug 25 13:07:56.904 : shelfmgr[317]: %PLATFORM-SHELFMGR-3-UNKNOWN_BOARD : Boot request from node 0/9/SP contains invalid board type 0x0, This board is being shutdown
This is happening only with SP board.
Conditions:
System reload or single board reload
Workaround:
none
Recovery:
hw-module reload location <> could be tried first but if this is still giving the same symptom then a physical OIR of the board should recover it.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 3.9.2.BASE, 4.0.0.ADMIN, 4.0.2.BASE, 4.2.1.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCun30812 |
Title: | pim process crash |
|
Description: | Symptom:
PIM or PIM6 crashes
Conditions:
Interface deletions are being processed
Workaround:
None
Further Problem Description:
Not in released code.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 4.3.3.BASE, 5.2.0.BASE |
|
Known Fixed Releases: | 4.3.31.13i.MCAST, 5.2.0.16i.MCAST |
|
|
| |
| |
Bug Id: | CSCth49449 |
Title: | HPI PON RESET - Pogo 1 causes netio/multiple process in mutex |
|
Description: | Symptom : A CRS-1/CRS-3 router running a post 3.9 X image can run into a situation where fib_mgr is permanently stuck on a mutex. The resulting condition is a linecard is not able to download any routes or process any route-updates or interface updates.
Conditions/Triggers: It is necessary for the fib_mgr or netio process to crash holding a particular mutex(TBM mutex in this case). This can happen typically due to an existing bug in the code or a PSE asic reset caused by an asic-error.
Workaround: Reload of linecard where is the problem is seen will recover the issue.
Frequency/Probability: This is a 2nd order problem caused by a 1st order problem which is a fib_mgr crash. The probability of occurence is low since it requires a fib_mgr crash.
Recreate Steps: For MSC140G/FP-140G cards this can be recreated by writing into certain registers using the gaspp command. It is not guaranteed that the error will happen everytime.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 3.9.2.BASE, 4.0.0.BASE, 4.0.1.BASE, 4.0.1.ROUT |
|
Known Fixed Releases: | 3.9.2, 3.9.2.19i.OSMBI, 3.9.3, 4.0.1, 4.0.1.9i.BASE, 4.0.2, 4.0.3, 4.0.4, 4.1.0, 4.1.0.6i.BASE |
|
|
| |
| |
Bug Id: | CSCtj69436 |
Title: | Excess Spurious interrupt msgs on device Fabricq seen on 4.0.1.16S |
|
Description: | Symptom:%PLATFORM-CPUCTRLLIB-4-INT_WARNING : Excess Spurious interrupt on device Fabricq messages seen on console after turbobooting CRS multi-chassis to 4.0.1.16S
Conditions:turboboot CRS multi-chassis to 4.0.1.16S
Workaround:none
Recovery:Self recovers after a few minutes
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 4.0.2.BASE, 4.1.0.BASE |
|
Known Fixed Releases: | 4.0.2, 4.0.2.4i.BASE, 4.0.3, 4.0.4, 4.1.0, 4.1.0.20i.BASE, 4.1.1, 4.1.2, 4.2.0, 4.2.1 |
|
|
| |
| |
Bug Id: | CSCum46695 |
Title: | NG ISSU: cdm_rs crashing at cdmrs_worker_control |
|
Description: |
Symptom:With NG 2-VM ISSU, cdm_rs has been seen to crash on the Secondary-Active VM, during the LOAD phase
Conditions:Issue can be seen with cdm_rs process in NG boxes.
Workaround:None
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 5.1.0.BASE, 5.1.1.BASE, 5.2.0.BASE, 5.2.1.BASE, 5.2.1.CE, 5.2.3.BASE |
|
Known Fixed Releases: | 5.1.2.20i.BASE, 5.1.3.1i.BASE, 5.2.0.13i.BASE |
|
|
| |
| |
Bug Id: | CSCej20780 |
Title: | GSP inconsistent node-id after boot and failover (SRP down) |
|
Description: | CSCej20780 (CRS-1 multichassis) Intermittent bootup problem/console messages
from gsp process => gsp_incorrect_rsi causing the multichassis router to not bootup
correctly.
Impact: Intermittent router bootup failures. some cards wont bootup, gsp process
restarts multiple times.
Cause: Timings of some cards going down during the bootup (possibly due to a
problem with these cards) , is the trigger for this software defect to occur,
this software defect will cause further bootup defects causing more failures.
Workaround: None. Reboot the router.
|
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 3.2.0.BASE, 3.3.0.BASE |
|
Known Fixed Releases: | 3.2.2.0i.BASE, 3.2.2.4i.BASE, 3.3.80.2i.BASE, 3.3.80.3i.BASE |
|
|
| |
| |
Bug Id: | CSCuq55681 |
Title: | 631507989: SFP-GE-T stay down in 6-10GE-WLO-FLEX/SPA-10X1GE-V2 in CRS |
|
Description: | Symptom:
SFP-GE-T transceivers do not come up in 6-10GE-WLO-FLEX/SPA-10X1GE-V2 in CRS.
Conditions:
SFP-GE-T with 6-10GE-WLO-FLEX/SPA-10X1GE-V2
Workaround:
In most times, the interfaces would only come up after reloading the CRS, but other cases even after reloading the router the interfaces do not go up. Besides reloading CRS, reloading the PLIM or OIR SPA with the problem also fix the problem.
Further Problem Description:
Logs: http://www-tac.cisco.com/Teams/ks/c3/getLargeFile.php?srId=631507989&fileName=20140821-165028_SFP%20Problem.log&forceText=1
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 5.1.2.BASE |
|
Known Fixed Releases: | 5.3.0.19i.BASE |
|
|
| |
| |
Bug Id: | CSCuu10254 |
Title: | After RP OIR on tail node 1GE and STM16 traffic down(DT22+SMU) |
|
Description: | After RP OIR on tail node 1GE and STM16 traffic down.
Symptom:
On tail node RPFO/RP OIR Traffic on Protect and Restore LSPs will not be recovered.
Conditions:
1. Setup GMPLS 1+1 or 1+1+R or 1+R tunnels and traffic should be up on Working LSP.
2. Make Working path down so that Traffic switches to Protect/Restore.
3. Tail node RPFO/RPOIR. Traffic on Protect/Restore links will go down.
Workaround:
None.
Further Problem Description:
Reproducibility (%):
100%
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 5.2.4.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu89196 |
Title: | After xr reload the registered license is lost--back to DEMO mode |
|
Description: | Symptom:
RP/0/RP0/CPU0:ott02-sim-09-uut#show licen status
Smart Licensing is ENABLED
Initial Registration: SUCCEEDED on Tue Jun 16 2015 17:12:55 UTC
Last Renewal Attempt: None
Registration Expires: Wed Jun 15 2016 17:09:49 UTC
License Authorization:
Status: AUTHORIZED on Tue Jun 16 2015 17:15:23 UTC
Last Communication Attempt: SUCCEEDED on Tue Jun 16 2015 17:15:23 UTC
Next Communication Attempt: Thu Jul 16 2015 17:15:23 UTC
Communication Deadline: Mon Sep 14 2015 17:12:17 UTC
RP/0/RP0/CPU0:ott02-sim-09-uut#show licen platform sum
Current state: PRODUCTION
Collection: LAST: Tue Jun 16 17:28:31 2015
NEXT: Tue Jun 16 17:30:31 2015
Reporting: LAST: Tue Jun 16 17:28:31 2015
NEXT: Tue Jun 16 17:30:31 2015
Count
Feature/Area Entitlement Last Next
================ =============================================== ==== ====
System Product: Right to Use 1 0
System Foundation: IP/MPLS/L3VPN Premium (per 1 Gbps) 1 0
System Feature: QoS (per 1Gbps) 1 0
RP/0/RP0/CPU0:ott02-sim-09-uut#
RP/0/RP0/CPU0:ott02-sim-09-uut#
RP/0/RP0/CPU0:ott02-sim-09-uut#reload
Standby card not present or not Ready for failover. Proceed? [confirm]
Preparing system for backup. This may take a few minutes especially for large configurations.
Status report: node0_RP0_CPU0: BACKUP INPROGRESS
Status report: node0_RP0_CPU0: BACKUP HAS COMPLETED SUCCESSFULLY
[Done]
Proceed with reload? [confirm]
Reloading node 0/RP0/CPU0
Query the node to be reloaded
Received get inv reply nobjs 1 for 4
NODE_IP of noded to be reloaded 0xc0000004
sending stop hb
Cause: User initiated forced reload
VM IP addr sent for relaod 0xc0000004
After booting:
RP/0/RP0/CPU0:ott02-sim-09-uut#
RP/0/RP0/CPU0:ott02-sim-09-uut#show licen platfor sum
Current state: DEMO
Collection: LAST: (disabled)
NEXT: (disabled)
Reporting: LAST: (disabled)
NEXT: (disabled)
Count
Feature/Area Entitlement Last Next
================ =============================================== ==== ====
RP/0/RP0/CPU0:ott02-sim-09-uut#
RP/0/RP0/CPU0:ott02-sim-09-uut#show licen stat
Smart Licensing is ENABLED
License Authorization:
Status: No Licenses in Use
RP/0/RP0/CPU0:ott02-sim-09-uut#RP/0/RP0/CPU0:Jun 16 17:40:42.560 UTC: bgp[1048]: %ROUTING-BGP-5-ADJCHANGE : neighbor 2002:6d01:1700::1 Up (VRF: default) (AS: 201)
RP/0/RP0/CPU0:ott02-sim-09-uut#
Conditions:
image:
Refpoint = calvados/release@bnb-54-flex/5
Built By : therrien
Built On : Mon Jun 15 17:27:28 EDT 2015
Build Host : ott-pd-vs-010
Workspace : /nobackup/therrien/works
Source Base : ios_ena
Devline : bnb-54-flex
Devline Type : ACME Project
bnb-54-flex EFR-00000306577 Project
ci-msl EFR-00000306252 Lineup
ci-532 EFR-00000305773 Lineup
default EFR-00000304397 Lineup
RP/0/RP0/CPU0:ott02-sim-09-uut#
Workaround:
N/A
Further Problem Description:
N/A
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 5.4.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuq30507 |
Title: | Topaz: Fabric Card: Backing out the asic-scan changes for sapir asic. |
|
Description: | Symptom:
Less free memory availability on Metro Cards . Due to which following operation/functions gets effected
1. Increased periodic alarms from WD (watch dog ) about critical available free memory.
2. Failure in SMU upgrades or ISSU.
3. If very low memory condition persists , WD monitor would kill the high memory consumers , which might have random effects over the router function based on the process killed.
Hence, to mitigate above symptoms and to increase the free available memory the allscan file for sapir asic is removed . which impacts and produces following symtoms
1. No asic scan for sapir asics in case of asic-erros which causes the asic scan of sapir asic
2. No effect of manual asic scan trigger for sapir asic from the CLI.
Conditions:
For example CLI command
admin)#asic-scan sfe instance 0 quick-scan allscan location
Workaround:
NO work Around available . Shall be fixed in upcoming 5.1.4 release.
Further Problem Description:
The Root Cause of the issue is a limitation of packaging demarcation for individual cards . More granularity on the decision/control to add or remove the components on the respective packages based on the card types would resolve the issue.
The resolution shall and asic-scan for sapir shall be restored in the upcoming 5.1.4 release.
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 5.1.3.BASE |
|
Known Fixed Releases: | 5.1.3.20i.BASE, 5.1.4.1i.BASE, 5.3.1.3i.BASE |
|
|
| |
| |
Bug Id: | CSCup91834 |
Title: | In ci-530: ipv6 cross ping on "Bundle-Ether" failed |
|
Description: | Symptom:
Unable to ping between CRS Topaz 4x100ge PLIM and Nexus over bundle-ether.
Conditions:
Enable bundle ipv6 connection between CRS and Nexus using 4x100ge PLIM.
Workaround:
NA
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 5.3.0.BASE |
|
Known Fixed Releases: | 5.1.4.FWDG, 5.3.0.7i.BASE, 5.3.0.7i.FWDG |
|
|
| |
| |
Bug Id: | CSCuu01887 |
Title: | ROUTING-FIB-3-PLATF_UPD_FAIL after restart stats_svr on FP400 |
|
Description: | Symptom:
After restart stats_svr process as workaround for CSCuo56817 FP400 shows below traceback message.
LC/0/3/CPU0:Apr 4 09:39:44.163 jst: fib_mgr[166]: %ROUTING-FIB-3-PLATF_UPD_FAIL : FIB platform update failed: Obj=DATA_TYPE_NHINFO[ptr=607e5058,refc=0,flags=0] Action=CREATE Proto=ipv4. Cerr=No locks available : pkg/bin/fib_mgr : (PID=426082) : -Traceback= c02e41d 4269c4f 42704c6 42749f2 427a4cd 427b622 42bddef 42be2bc 4207fc6 8236db3 8234f44 4200ee3 4210ec5 827a050
Conditions:
restart stats_svr on FP400 many times.
Workaround:
NA
Further Problem Description:
|
|
Status: | Open |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 5.1.2.CE |
|
Known Fixed Releases: | |
|
|
| |
| |
Bug Id: | CSCuu50621 |
Title: | OSPF SR label missing on RIB for remote PE's address |
|
Description: | Symptom:
In some rare cases, especially after reload, OSPF may fail to allocate Segment Routing Label Range.
Conditions:
Router reload
Workaround:
Restart OSPF process
Further Problem Description:
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 17-JUN-2015 |
|
Known Affected Releases: | 5.3.2.CE |
|
Known Fixed Releases: | 5.3.2.12i.ROUT |
|
|
| |
| |
Bug Id: | CSCur25840 |
Title: | Traffic drop on link recovery with PSE drops in the egress direction |
|
Description: | Symptom:
Traffic drop on bundle link restoration from a backup link
Conditions:
unshut of the primary link
Workaround:
None
Further Problem Description:
For ipv4 traffic outage, drops are reported as "MPLS remote next hop" and for ipv6 outage, drops are reported as "IPv6 L3LI drop".
Node 0/4/CPU0 Egress PSE Stats
--------------------------------
Punt Stats Punted Policed & Dropped
---------- ------ -----------------
Diagnostic 180 0
IPv6 L2LI punt 16 0
Drop Stats Dropped
---------- -------
IPv6 L3LI drop 1
MPLS remote next hop 317568
Debug Stats Count
----------- -----
IPv6 link-local packets 29
Pre route IPV6 pkt 19
RP/0/RP1/CPU0:DCMAR2#
|
|
Status: | Fixed |
|
Severity: | 2 Severe |
Last Modified: | 18-JUN-2015 |
|
Known Affected Releases: | 4.3.3.BASE |
|
Known Fixed Releases: | 5.3.2.13i.FWDG |
|
|
| |
| |
Bug Id: | CSCuu31528 |
Title: | BFD v4 session didnot resolve some vlans ARP after shut/noshut main intf |
|
Description: | Symptom:
RP/0/RP0/CPU0:ott02-sim-09-uut#show bfd ipv4
IPV4 Sessions Up: 1000, Down: 0, Unknown/Retry: 0, Total: 1000
RP/0/RP0/CPU0:ott02-sim-09-uut#show bfd ipv4
IPV4 Sessions Up: 1000, Down: 0, Unknown/Retry: 0, Total: 1000
RP/0/RSP0/CPU0:ott02-sim-09-r1#config terminal
RP/0/RP0/CPU0:ott02-sim-09-uut(config)#interface TenGigE0/RP0/CPU0/0
RP/0/RP0/CPU0:ott02-sim-09-uut(config-if)#shutdown
RP/0/RP0/CPU0:ott02-sim-09-uut(config-if)#commit
RP/0/RP0/CPU0:ott02-sim-09-uut(config-if)
|
没有评论:
发表评论