CSCui67903

CSCui67287

CSCui02391

CSCui91589

CSCuj05333

CSCuj10061

CSCuj21258

 

 

CSCui67903 (sev2): PON exit with PGM_SIZE_EXCEPTION

 

Release-note:

Symptom:

There are two different symptoms with this issue, one that is harmless that just log a WARNING syslog message from ccc_driver component like the following one:

 

0/RP1:Sep 11 02:15:38.125 : ccc_driver[1962]: %DRIVER-CCC-4-PON_EXIT_FAILURE : Power-on interpreter exited while executing RED_VLAN_CONFIG command - pon exit  <-- RED_VLAN_CONFIG cnt=2! exit_code=PGM_SIZE_EXCEPTION

 

And the other case is the one that can leave the card with HW State as "FAILED" in the output of "show platform" command. The output of "show platform detail" will indicate the same exit_code of PGM_SIZE_EXCEPTION. The card will become non-operational when hit with this condition.

 

Conditions:

This is a timing condition when accessing the CCC SPI flash and the problem can be seen during chassis bootup, OIR insertion/removal of a card or execution of "hw-module location  reload" command on multiple cards.

 

Workaround:

Use "hw-module location  reload" command to reload the card affected with this failure to recover.

 

 

 

CSCui67287 (Sev2): Bgp NSR not ready-BGP NSR sessions not synchronized : inst_name=default,

 

Release-note:

Symptom:

show redundacy will show nsr is not ready and nsr not ready syslogs keep popping up , check show bgp convergance , if bgp is NOT converged then wait for it being converged and even after bgp convergence reached , NSR is not ready , then this might be the issue.

 

Conditions:

NSR supporting protocols being configured and due to certain unknwon conditions , NSR is NOT ready but we have seen that if router boots up , then applied the config , then commit replace to wipe out config and then put the config again can result in the issue.

 

This is only seen if done right after first boot.   Once the router is up and running for several days, a commit replace and rollback was not able to hit this issue.

 

Workaround:

none

 

Recovery:

process restart bgp / ldp should recover it

 

 

 

 

CSCui02391 (sev3): CPAK Intermittent PCS Lane Bit Errors during power-cycle

 

Release-note:

Symptom:

A few possible symptoms might be seen:

 

"show controllers  phy" will show large number of BIP errors.

LC Console message " %L2-PLIM_ETHER-2-RX_LF : , Detected Local Fault"

Interfaces remain at DOWN state

 

Conditions:

Intermitent issue which usually seen after linecard reload or CPAK OIR

 

Workaround:

Change the interface configuration by configure the interface to loop internal, then back to no loopback internal

 

 

 

 

CSCui91589 (Sev6): Add new card  hw state "POWERED-OFF" in show platform

 

Release-note:

Symptom:

A system has some nodes powered off due to not enough power budget, while other nodes are powered on, and have been granted power budget.

 

A reload of both a non-powered card as well as a powered card results in the previously unpowered card taking the power budget away from

the node that was previously powered.

 

Nodes in a system which have previously been granted power, are supposed to be immune from losing power during node reload.  In this timing condition, it is possible to lose the budget to another previously unpowered card.

 

Conditions:

A node needs to request power, at the same time a node that already has been granted power is reloaded.  There is a small window where the card which currently has been granted power will lose its budget to the new request.

 

Router is in a state where more nodes that required power supplies are present.  Recommend adding power supplies for all nodes that are plugged in.

 

Workaround:

If an undesired node is powered on, shut down that node using the power shut command.  This will return the power to the overal budget.  Then attempt a reload of the desired node, which should then be granted power.

 

Adding more power to the system, to support all plugged in cards is the recommended way to recover.

 

 

 

CSCuj05333 (sev3): Insertion of optics takes upwards of 80 seconds to populate in inventory

 

Release-note:

Symptom:

Insertion of optic takes upwards of 80 seconds to reflect in inventory.

 

Conditions:

When inserting an optic into CPAK or CXP node.  Issue is not so noticeable with the removal of the optic, but upon insertion only, either fresh insertion or insertion+removal.  This issue is non-traffic impacting.

 

Workaround:

There are no workarounds, and system self-updates after 80 seconds.

 

 

CSCuj10061 (Sev2): ospfv3 Neighbors are not coming up wth ipsec used as auth

 

Release-note:

Symptom:

OSPFv3 Neighbors are not coming up wth IPSec used as authentication

 

Conditions:

Occurs when ipsec is used as authentication, without authentication neighbors are fine

 

Workaround:

There is no workaround if IPSec is Must for your deployment case.

Target for fix is IOS XR 5.0.1

 

Recovery:

Avoid using IPSec with OSPFv3.

 

 

 

CSCuj21258 (sev2): user-initiated dumpcore running can take more than 20 minutes to execute

 

Release-note:

 

Symptom:

User-initiated dumpcore running is taking up to 20 mins to execute

 

Conditions:

Due to the length of time taking to execute dumpcore, customers are not advised to run this command on a production router.  This sort of information should only be collected during maintenance events when the router is costed out from production traffic.

 

Workaround:

Avoid using dumpcore on production router in customer network.   Only to be used as part of maintenance troubleshooting.