| |
|
Alert Type: | Updated * |
Bug Id: | CSCuc67573 | Title: | Rosen GRE-MVPN bud: MGID isn't programmed on OLE LC XBAR/FIA |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptoms
The feature is for MPVN with Rosen GRE. Data MDT is configured at Decap PE. Source (Encap) PE has minimum two paths reachable to Decap PE. According to an IGP protocol, one path is selected as the primary path, the other is for backup path. The Data MDT path chooses primary path to forward the customer traffic (vrf mcast traffic) to Decap PE. If the network primary path is down and up within 3 minutes, the customer traffic will be continuously dropped at the Decap PE after the primary path resumes back.
Issue can happen in 4.2.1, 4.2.2 and 4.2.3 releases.
Symptom:
Will not see any multicast groups for a VRF
Conditions:
Trigger Conditions
1. The feature is for MPVN with Rosen GRE
2. In Decap PE, data MDT (multicast distribution tree) is configured under ?multicast routing? for a specific VRF.
3. Minimum one Data MDT has been created in the Decap PE.
4. One Data MDT path flap within 3 minutes can cause customer traffic loss carried by other data MDTs within the same VRF at the Decap PE.
5) MDT default can trigger this anomaly also. Will not occur as often.
Workaround:
Workaround
1) If MDT DATA is configured, Do not configure Data MDT at the Decap PE. Use default MDT configuration.
If this does not work, please try the same workarounds as if MDT default is only configured.
2) If MDT default is only configured, please try below
a) Remove all VRF configurations for the VRF in question along with the interfaces for the VRF out of the Multicast configuration and add them back.
If this does not work, please try option b
b) Reset the line card that is not programmed correctly.
Further Problem Description:
This issue can occur with MDT default only and with MDT data configured.
If MDT default is only configured, issue will not occur as frequent
as with MDT DATA configured. This is more a corner case if MDT default is only configured.
|
|
Last Modified: | 25-NOV-2015 |
|
Known Affected Releases: | 4.2.0.1i.MCAST, 4.2.1.MCAST |
|
Known Fixed Releases: * | 4.3.0.32i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw59619 | Title: | syslog was not displayed when Cluster EOBC/IRL UDLD detected err-disable |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
In Nv Edge on ASR9k when IRL/EOBC intermediate links are failed (Ports were actually Up/Up) , the UDLD detection goes to Unknown but this issue is not reported as a syslog.
Conditions:
Failure in the intermediate network connecting the EOBC or IRL links in an NV Edge system.
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 19-NOV-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: * | 5.3.3.19i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw49153 | Title: | Tomahawk MH Improve error correction in receive dir for x120 phy stuck |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Bringing up new links or after a fiber cut. The links get into a unidirectional traffic forwarding condition.ASR9K is able to transmit traffic. But receive packets will be dropped.
Conditions:
This is an interoperability issue between ASR 9000 (A9K-8X100-SE/TR or A9K-4X100-SE/TR) and M6 / NCS2K-100G-CK linecard.
This issue is not applicable to PIDs A9K-8X100-L-SE/TR, A9K-2X100G-SE/TR and A9K-1X100-SE/TR.
The issue happens only when link flaps or comes up in DWDM core network or trunk port.
A9K-8X100GE-TR (or A9K-8X100GE-TR) <-> CPAK-100G-SR10 (on ASR card) <-> CPAK-100G-SR10 (on optical card) <->
NCS2K-200G-CK-LIC (DWDM w/ 20% SD FEC) <-> 600 to 1000 km optical fiber with MSTP amps, ROADMs, etc. <->
NCS2K-200G-CK-LIC (DWDM w/ 20% SD FEC) <-> CPAK-100G-SR10 (on optical card) <->
CPAK-100G-SR10 (on ASR card) <-> A9K-8X100GE-TR (or A9K-8X100GE-TR)
Workaround:
There is no workaround to prevent this issue. One and only known recovery mechanism is to reload the LC
Further Problem Description:
|
|
Last Modified: | 22-NOV-2015 |
|
Known Affected Releases: | 5.3.1.LC |
|
Known Fixed Releases: | 5.3.3.14i.BASE, 6.0.0.19i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw01277 | Title: | A9K-8X100-SE unable to receive traffic with Cisco 15454 after port flap |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Bringing up new links or after a fiber cut. The links get into a unidirectional traffic forwarding condition.ASR9K is able to transmit traffic. But receive packets will be dropped.
Conditions:
Version 5.3.1
This is an interoperability issue between ASR 9000 (A9K-8X100-SE/TR or A9K-4X100-SE/TR) and M6 / NCS2K-100G-CK linecard.
This issue is not applicable to PIDs A9K-8X100-L-SE/TR, A9K-2X100G-SE/TR and A9K-1X100-SE/TR.
The issue happens only when link flaps or comes up in DWDM core network or trunk port.
A9K-8X100GE-TR (or A9K-8X100GE-TR) <-> CPAK-100G-SR10 (on ASR card) <-> CPAK-100G-SR10 (on optical card) <->
NCS2K-200G-CK-LIC (DWDM w/ 20% SD FEC) <-> 600 to 1000 km optical fiber with MSTP amps, ROADMs, etc. <->
NCS2K-200G-CK-LIC (DWDM w/ 20% SD FEC) <-> CPAK-100G-SR10 (on optical card) <->
CPAK-100G-SR10 (on ASR card) <-> A9K-8X100GE-TR (or A9K-8X100GE-TR)
Workaround:
There is no workaround to prevent this issue. One and only known recovery mechanism is to reload the LC
Further Problem Description:
|
|
Last Modified: | 22-NOV-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: | 5.3.3.10i.BASE, 6.0.0.15i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw43558 | Title: | [6.0.0] - interface is not getting detected while configuring on T1 spa |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Interface is not getting detected interface Serial0/1/0/0:0
Conditions:
While trying to configure the interface on the t1 spa
Workaround:
NA
Further Problem Description:
NA
|
|
Last Modified: | 07-NOV-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: * | none |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu86434 | Title: | Memory threshold crossed: ipv4_rib hit 9G on standby RSP after LC OIR |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
ipv4_rib hit 9G on standby RSP after LC OIR. Then Memory threshold crossed.
Conditions:
LC OIR with 10M ipv4 routes. 80% reproducible
Workaround:
proc restart ipv4_rib
Further Problem Description:
|
|
Last Modified: | 25-NOV-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: * | 4.1.0, 4.1.1, 4.1.2, 6.1.0.1i.BASE |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux16938 | Title: | Update handling for FLOW_WSTAT Typhoon NP parity errors |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A typhoon linecard may be reloaded due to the following error:
prm_ser_check: Parity error detected: SN FOC1722N4NH, NP 1, Rev 2, block 0x28 (TM_SC_L234), offset 51, memid 276, name FLOW_WSTAT, addr 0x0000008e, bit 2147483648, ext info 0xffffffff 0xffffffff 0xffffffff 0xffffffff, single count 0, double count 0, flags 0x0, action 2 (Reset)
Conditions:
This is caused by a soft error so there is no specific trigger. It can occur on any Typhoon linecard or asr9001 chassis.
It is a very rare problem as it only occurs when a soft error is detected in the FLOW_WSTAT memory within the TM_SC_L234 block.
Workaround:
There is no workaround.
Further Problem Description:
|
|
Last Modified: | 20-NOV-2015 |
|
Known Affected Releases: | 4.2.0.BASE, 4.3.0.BASE, 5.1.0.BASE, 5.2.0.BASE, 5.3.0.BASE |
|
Known Fixed Releases: | 5.3.3.19i.BASE |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux00886 | Title: | NP Lockup on Typhoon LC with egress ipv4 Netflow + BFD enabled |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
The NPs on Typhoon Linecards go into fast reset due to lockup condition when we have Netflow enabled along with BFD on the core facing interfaces of these linecards. After 3 attempts of fast reset of NP, the linecard is rebooted and traffic is completely lost.
Conditions:
The problem occurs on ASR9K routers having Typhoon LC on which egress netflow + bfd is configured on core facing interfaces
Workaround:
Disable egress netflow on the core facing interfaces of the Typhoon LC and the NP lockup is not observed and traffic flows are not affected.
Further Problem Description:
|
|
Last Modified: | 20-NOV-2015 |
|
Known Affected Releases: | 5.3.3.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur21570 | Title: | Prevent SPP from crashing due to Invalid buffer count |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
The SPP process may crash repeatedly with invalid buffer count.
Invalid buffer count PPORT = 9, LPORT = 4, PCOUNT = 87
RP/0/RSP0/CPU0:Oct 2 21:47:07.492 : dumper[60]: %OS-DUMPER-4-SIGSEGV : Thread 1 received SIGSEGV - Segmentation Fault
RP/0/RSP0/CPU0:Oct 2 21:47:07.492 : dumper[60]: %OS-DUMPER-4-SIGSEGV_INFO : Accessed BadAddr 0x280 at PC 0x280. Signal code 1 - SEGV_MAPPER. Address not mapped.
Since SPP is a mandatory process then a kernel crash will be seen after the SPP process cannot be restarted.
Conditions:
This has been seen on a ASR 9001 running 5.1.2 or 5.1.3
Workaround:
none
Further Problem Description:
This DDTS is to provide a preventative fix to prevent SPP from crashing when packets with invalid buffer count are encountered. The fix should throw away the packet, generate a syslog and save the contents of the packet for analysis.
|
|
Last Modified: | 04-NOV-2015 |
|
Known Affected Releases: | 5.1.2.BASE, 5.1.3.BASE |
|
Known Fixed Releases: * | 5.1.2.SP4, 5.1.3.SP3, 5.1.3.SP4, 5.2.2.SP1, 5.2.3.99i.BASE, 5.2.4.2i.BASE, 5.3.0, 5.3.0.12i.BASE, 5.3.1 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux24607 | Title: | 533-19I fib_mgr crash on Tomahawk@fib_hal_nrlwldi_has_ip_leaf_dependents |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
fib_mgr crashes when multiple triggers like Linecard OIR, reload Linecard and removing and adding BGP peering loopback interfaces are exercised.
Conditions:
1. Tomahawk Linecard
2. BGP prefix over TE tunnels
3. Multiple triggers like Linecard OIR, Reload of Linecard and adding and removing BGP peering loopback interfaces are exercised.
Workaround:
Avoid multiple triggers at the same time.
Further Problem Description:
|
|
Last Modified: | 26-NOV-2015 |
|
Known Affected Releases: | 5.3.3.BASE |
|
Known Fixed Releases: * | 5.3.3.20i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu37646 | Title: | Mcast IPv6 route not installed on one of the two LCs |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Mcast IPv6/v4 ingress/egress traffic drop on interface.
Conditions:
Its being observed for ipv4/ipv6 mast traffic when some interface address configs triggers are done.
Workaround:
ipv4_mfwd_partner/ipv6_mfwd_partner restart should recover the issue
Further Problem Description:
|
|
Last Modified: | 01-DEC-2015 |
|
Known Affected Releases: | 5.1.3.MCAST, 5.2.2.MCAST, 5.3.2.MCAST |
|
Known Fixed Releases: * | 4.2.0, 4.2.1, 4.2.2, 4.2.3, 4.2.4, 4.3.0, 4.3.1, 4.3.2, 4.3.3, 4.3.31 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw42286 | Title: | p2mp-impnull: Unable to bringup p2mp tunnel on Tomahawk with ip options |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Path message dropped on Tomahawk with router alert option
Conditions:
path message with router alert option on Tomahawk
Workaround:
Not seen typhoon card.
Further Problem Description:
None
|
|
Last Modified: | 26-NOV-2015 |
|
Known Affected Releases: | 6.1.0.BASE |
|
Known Fixed Releases: * | 5.3.3.20i.BASE, 6.0.0.18i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur33931 | Title: | Missing ECD marking flag for the rec-leaf in the recursive PW fwd chain |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:Multicast traffic not passing through bridge-domain but unicast works fine after a BGP PIC cutover. Or shut one of the ECMP path.
Conditions:Traffic can be drop. From log analysis, it shows that the interface information does not get updated in the L3 to L2 notification data.
Workaround:Clearing routes restore the impacted traffic. It has been verified in the customer routers. ( in addition need to also use the fix in PI bug CSCur14272 for complete fix)
More Info:
|
|
Last Modified: | 07-NOV-2015 |
|
Known Affected Releases: | 4.2.3.ROUT |
|
Known Fixed Releases: * | none |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj19861 | Title: | ARP packet injects into NP on 100 gig cards over bundle (sub)interfaces |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
NP-reset on Juggernaut LC. Temporary traffic loss and protocol flap.
Conditions:
ARP traffic running over bundle-subinterfaces with members on Juggernaut LC.
The problem should rarely occur.
Workaround
No workaround possible, given the above conditions.
Workaround:
Further Problem Description:
|
|
Last Modified: | 09-NOV-2015 |
|
Known Affected Releases: | 4.3.1.LC |
|
Known Fixed Releases: * | none |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj10837 | Title: | PUNT_FABRIC_DATA_PATH diag test fails due to fabric link retrain (TX) |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | PUNT_FABRIC_DATA_PATH_FAILED error is reported by the RSP for all NPs on a line card:
RP/0/RSP0/CPU0:Sep 3 13:49:36.595 UTC:
pfm_node_rp[358]:%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[241782]|System
Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP) failed: (0/7/CPU0,1)
(0/7/CPU0, 2) (0/7/CPU0, 3) (0/7/CPU0, 4) (0/7/CPU0, 5) (0/7/CPU0, 6) (0/7/CPU0, 7)
Symptom:
PUNT_FABRIC_DATA_PATH_FAILED error is reported by the RSP for all NPs on a line card:
RP/0/RSP0/CPU0:Sep 3 13:49:36.595 UTC:
pfm_node_rp[358]:%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[241782]|System
Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP) failed: (0/7/CPU0,1)
(0/7/CPU0, 2) (0/7/CPU0, 3) (0/7/CPU0, 4) (0/7/CPU0, 5) (0/7/CPU0, 6) (0/7/CPU0, 7)
Conditions:
Observed on ASR9000 routers a few minutes after re-trainig of fabric links. To check whether re-training has happened, run the following command:
show controller fabric ltrace crossbar location 0/rsp1/cpu0 | include rcvd link_retrain
Sep 3 13:47:06.975 crossbar 0/RSP1/CPU0 t1 detail xbar_fmlc_handle_link_retrain: rcvd
link_retrain for (5,1,0),(9,1,0),1.
Alternative possible output:
show controller fabric ltrace crossbar location 0/rsp0/cpu0 | include rcvd link_retrain
Sep 3 13:47:07.027 crossbar 0/7/CPU0 t1 detail xbar_fmlc_handle_link_retrain: rcvd
link_retrain for (9,1,0),(5,1,0),1.
Workaround:
no workaround. SMU's for most of the images are released.
Further Problem Description:
If this issue is observed on an ASR9000, there is no need for a hardware replacement (i.e no need for RMA). Software fix will be provided through this bug id.
The term TX direction refers to the direction from the standpoint of the RSPs crossbar fabric interface towards a fabric crossbar interface on a Typhoon based linecard.
The CSCuj10837 bug is characterized by the Typhoon LC detecting a problem on the RX link from the RSP and initiating a link retrain. Either side (LC or RSP) can initiate the retrain event.
In the case of CSCuj10837 the LC initiates the retrain and can be detected by the init xbar_trigger_link_retrain: message in the traces on the linecard.
For Example:
RP/0/RSP0/CPU0:ios#show controllers fabric ltrace crossbar location 0/0/cpu0 | in link_retrain
Oct 1 08:22:58.967 crossbar 0/0/CPU0 t1 init xbar_trigger_link_retrain: destslot:0 fmlgrp:3 rc:0
When the linecard initiates the retrain the RSP reports a rcvd link_retrain in the trace output.
RP/0/RSP0/CPU0:ios#show controllers fabric ltrace crossbar location 0/rsp0/cpu0 | in link_retrain
Oct 1 08:22:58.999 crossbar 0/RSP1/CPU0 t1 detail xbar_fmlc_handle_link_retrain: rcvd link_retrain for (1,1,0),(2,1,0),1.
|
|
Last Modified: | 10-NOV-2015 |
|
Known Affected Releases: | 4.2.3.BASE |
|
Known Fixed Releases: * | none |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu16370 | Title: | 531 QOS: NP5 TM lockup with VPLS higher rate flooding traffic |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
The NP may halt due to a high rate of vpls flooding on tomahawk cards.
Conditions:
At a higher rate of traffic (above 40gig with 64 byte frames), lockup
was hit after several seconds of running traffic (in some cases after a minute).
Workaround:
Further Problem Description:
|
|
Last Modified: | 02-NOV-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: * | 5.3.1, 5.3.1.BASE, 5.3.2, 5.3.2.9i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw67876 | Title: | Convert handling for some NP soft errs from full reset to NP fast reset |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Typhoon or Tomahawk linecards may be rebooted for certain types of NP soft errors. With this change, the error handling for some errors has been converted so that a full linecard reload is no longer required. See the Conditions section for the specific errors for which handling as been updated.
Conditions:
The NP soft error handling has been changed from a full reset (linecard reload) to an NP fast reset (no linecard reload required) for the following specific errors:
Typhoon:
block = TM_DMA, memory name = OD_FD_LINK0
For example, this Typhoon error will now be handled with an NP fast reset instead of a linecard reload:
prm_ser_check: Double-bit ECC error detected: NP 2, block 0x21 (TM_DMA), offset 18, memid 541, name OD_FD_LINK2, addr 0x00625026, bit 25, ext info 0x00000002 0x00000006 0x00000006 0x000e2502, action 2 (Reset)
Tomahawk:
block = TMOD, memory name = FRG_DRAM_LINK_P2
block = TM_SC_L234, memory name = CLASS_CFG_NIBBLE
block = TM_SC_L234, memory name = CLASS_RANGE_W0_MODE0
Examples of the Tomahawk NP soft errors that will now be handled with an NP fast reset instead of a linecard reload:
prm_ser_check: Double-bit ECC error detected in external memory: SN FOC1924N8MF, NP 0, uiPhase 3, uiRev 8, block 0x41 (TMOD0), offset 91, memid 2099, name FRG_DRAM_LINK_P2, addr 0x00000de8, bit 4294967295, bEndToEnd 0, uiHWMemId 218, device ID 0, bank 0, row 6, column 61, ext info 0x019a0082 0x00000000 0xffffffff 0xffffffff, action 2 (Reset)
prm_ser_check: Parity error detected in internal memory: SN FOC1910N0QS, NP 1, uiPhase 3, uiRev 8, block 0x56 (TM_SC_L234_2), offset 19, memid 1265, name CLASS_CFG_NIBBLE_1, addr 0x00000173, bit 2147483648, bEndToEnd 0, uiHWMemId 14, ext info 0xffffffff 0xffffffff 0xffffffff 0xffffffff, action 2 (Reset)
prm_ser_check: Parity error detected in internal memory: SN FOC1903NESS, NP 2, uiPhase 3, uiRev 8, block 0x54 (TM_SC_L234_0), offset 13, memid 1078, name CLASS_RANGE_W0_MODE_0, addr 0x000003d1, bit 2147483648, bEndToEnd 0, uiHWMemId 12, ext info 0xffffffff 0xffffffff 0xffffffff 0xffffffff, action 2 (Reset)
Workaround:
There is no workaround. Prior to these changes, the linecards were automatically reloaded when these types of errors occurred.
Further Problem Description:
Releases for which handling of these errors was a full linecard reload:
4.2.x
4.3.x
5.1.x
5.2.x
5.3.0 and 5.3.1
|
|
Last Modified: | 11-NOV-2015 |
|
Known Affected Releases: | 5.3.3.BASE, 6.0.0.BASE |
|
Known Fixed Releases: * | 5.3.3.15i.BASE, 6.0.0.20i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw31466 | Title: | ASR9k : mibd_interface process crash seen on 5.3.2 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
mibd_interface process experiences software reset and recovers
Conditions:
continous snmpwalk against ASR 9000 triggers software reset of mibd_interface process.
Workaround:
NA
Further Problem Description:
Issue is observed during continous snmpwalk operation against ASR 9000 router. software reset in other snmp operations against asr 9000 cann't be ruled-out.
Impact is very minimal. Since process recovers itself, further snmp operations are not affected.
|
|
Last Modified: | 01-DEC-2015 |
|
Known Affected Releases: | 4.1.0.MCAST, 5.3.2.BASE |
|
Known Fixed Releases: * | 5.2.5.35i.MCAST, 5.3.3.16i.MCAST, 6.0.0.17i.MCAST |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux00275 | Title: | Slow FRR-Ready on transit node |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: * | Symptom:
Mid point tunnels slowly changing to FRR-Ready state
Conditions:
Apply config on routers then commit replace or node FRR trigger.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 11-NOV-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun72106 | Title: * | [User-Experience] seruser config for drop templates on ifDrops |
|
Status: | Open |
|
Severity: * | 2 Severe |
Description: | Symptom:
Ability to customize which counters are reported on the interface drop counter.
Conditions:
show interface reports drops which is an aggregate of ANY drop.
this counter is also reported on the IF-MIB ifDROP count.
requesting the ability to control which counters would be added, included/excluded from this drop count list.
Workaround:
monitor counters of each individual feature and subtract them in the backend.
not easy, hence the request for this usability enhancement.
Further Problem Description:
|
|
Last Modified: | 11-NOV-2015 |
|
Known Affected Releases: | 4.3.4.BASE, 4.3.4.LC, 5.1.3.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo71501 | Title: | SSTE:OSPFv3 crash when sending malformed Grace LSA |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
OSPFv3 process on Cisco IOS XR may reload when processing a crafted OSPFv3 packet.
Conditions:
An adjacent OSPF connectivity and established OSPF neighborship is needed.
Workaround:
None
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are
3.3/2.7:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:A/AC:L/Au:N/C:N/I:N/A:P/E:F/RL:OF/RC:C&version=2.0
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
Further Problem Description:
This is a day 1 implementation issue affecting all prior IOS-XR releases on all platforms.
|
|
Last Modified: | 04-NOV-2015 |
|
Known Affected Releases: | 5.2.0.BASE |
|
Known Fixed Releases: | 5.1.3.9i.ROUT, 5.2.0.25i.ROUT |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw73376 | Title: | Volume based lifetime announced but not supported |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
The IPsec tunnel negotiation fails and the tunnel interface stays in down/down state.
Conditions:
A Site-to-Site IPSec tunnel is established between Cisco ASR9000 Series router with Virtualized Services Module [A9K-VSM-500] and peers not supporting volume based lifetime proposals.
Cisco ASR9000 Series router is acting as IPSec responder. The current role can be verified with the following show command
show crypto isakmp internal interface tunnel-ip counter
Cisco ASR9000 Series router is configured as responder-only
crypto ipsec profile PROFILE_NAME
responder-only
Workaround:
none
Further Problem Description:
The volume based lifetime is only rejected when the IPSec peer is the Initiator of the SA negotiations and the Cisco ASR9000 Series router responds to the SA proposal.
Note: The Cisco ASR9000 Series router with Virtualized Services Module does not enforce the volume based SA lifetime in its data plane. Therefore, the behavior is changed to announce N/A as the volume based SA lifetime value.
|
|
Last Modified: | 12-NOV-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | 5.3.3.18i.BASE |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw61569 | Title: | Traffic loss during TEK change in G-VPN |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
When lifetime of old TEK expires and gets removed, traffic drop is seen on the decrypting GM.
Conditions:
The problem is seen on ASR9K platform running 5.3.2 release when GETVPN is configured. The traffic drop is seen when lifetime for old TEK SA has expired.
For e.g. if Key Server has configured SA lifetime of 7200 sec, the traffic drop will be seen on decrypting ASR9K GM after expiry of 7200 sec.
Workaround:
None.
Further Problem Description:
The decrypting ASR9K GM uses specific match rules in PBR inbound policy attached to protected interface to decide whether to decrypt incoming traffic, drop it or forward it in clear. The drop rule is used to drop incoming traffic which should have been encrypted by the encrypting GM but came in clear. When old TEK SA expires, the decrypt rule is removed first followed by drop rule. Since the delete operation is not atomic, some packets match the drop rule and get dropped.
|
|
Last Modified: | 12-NOV-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | 5.3.3.18i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw76173 | Title: | Qos Offload Policy on SAT Access Bundle fails to get ACTIVE |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Qos Offload Policy on SAT Access Bundle fails to get ACTIVE
Conditions:
ICL Triggers : Change of ICL Type - Bundle to Physical
Router Reload.
Workaround:
Remove / Add the Bundle Access Interface
Further Problem Description:
|
|
Last Modified: | 26-NOV-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: * | 5.3.3.20i.FWDG, 6.0.0.25i.FWDG |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw26074 | Title: | 532 CCO : pifibm_server_lc Crash on changing OSPF network type |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
The problem is seen with OSPF protocol with security ttl and network point to point configured on the system.
router ospf <>
nsr
log adjacency changes detail
router-id <>
bfd minimum-interval <>
bfd fast-detect
bfd multiplier <>
authentication message-digest keychain OSPF
network point-to-point
mpls ldp sync
security ttl hops 1
mpls ldp auto-config
Conditions:
pfiibm_server_lc crash is seen when network point to point configuration is removed from the OSPF protocol configuration.
Workaround:
There is no workaround as such. pifibm_server_lc process will recover itself after the crash.
Further Problem Description:
|
|
Last Modified: | 26-NOV-2015 |
|
Known Affected Releases: | 5.3.2.BASE, 5.3.3.BASE |
|
Known Fixed Releases: * | 5.3.3.20i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux13132 | Title: | Incomplete graceful reboot error and FRR trigger delay |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
A 2-4 second delay occurs between the point when a fatal linecard error is detected on an asr9k linecard and when the linecard is actually reloaded. This error is also reported:
LC/0/0/CPU0:Nov 12 05:17:07.980 EST: pfm_node_lc[294]: reboot_internal: Incomplete graceful reboot cleanup (Connection timed out)
This can lead to a 2-4 second delay in FRR, but there are no other side effects.
Conditions:
This problem occurs any time the software makes a decision to intentionally reload the linecard.
Workaround:
There is no workaround.
Further Problem Description:
Here is an example of the full sequence, note that it's taking around 4 seconds from the point at which the fatal error is detected until the linecard actually enters BRINGDOWN state:
LC/0/0/CPU0:Nov 12 05:17:05.913 EST: prm_server_ty[305]: %PLATFORM-NP-3-ECC : prm_ser_check: Parity error detected: SN FOC155081EP, NP 0, Rev 2, block 0xb (SRCH), offset 87, memid 557, name INT0_FIFO, addr 0x0000000e, bit 2147483648, ext info 0xffffffff 0xffffffff 0xffffffff 0xffffffff, single count 0, double count 0, flags 0x0, action 2 (Reset)
LC/0/0/CPU0:Nov 12 05:17:05.918 EST: pfm_node_lc[294]: %PLATFORM-NP-0-NON_RECOVERABLE_SOFT_ERROR : Set|prm_server_ty[176209]|0x1008000| A non-recoverable soft error has been detected on NP0. The linecard will be rebooted.
LC/0/0/CPU0:Nov 12 05:17:05.921 EST: pfm_node_lc[294]: %PLATFORM-PFM-0-CARD_RESET_REQ : pfm_dev_sm_perform_recovery_action, Card reset requested by: Process ID: 176209 (prm_server_ty), Fault Sev: 0, Target node: 0/0/CPU0, CompId: 0x1f, Device Handle: 0x1008000, CondID: 1034, Fault Reason: A non-recoverable soft error has been detected on NP0. The linecard will be rebooted.
LC/0/0/CPU0:Nov 12 05:17:05.921 EST: syslog_dev[89]: pfm_node_lc[294] PID-176200: Request Graceful Reboot via Sysmgr: Reason: pfm_dev_sm_perform_recovery_action, Card reset requested by: Process ID: 176209 (prm_server_ty), Fault Sev: 0, Target node: 0/0/CPU0, CompId: 0x1f, Device Handle: 0x1008000, CondID: 1034, Fault Reason: A non-recoverable soft error has been detected on NP0. The linecard will be rebooted.
LC/0/0/CPU0:Nov 12 05:17:05.921 EST: syslog_dev[89]: pfm_node_lc[294] PID-176200:
LC/0/0/CPU0:Nov 12 05:17:06.021 EST: syslog_dev[89]: pfm_node_lc[294] PID-250028: Thu Nov 12 05:17:06 EST 2015
LC/0/0/CPU0:Nov 12 05:17:07.980 EST: pfm_node_lc[294]: reboot_internal: Incomplete graceful reboot cleanup (Connection timed out)
LC/0/0/CPU0:Nov 12 05:17:07.980 EST: pfm_node_lc[294]: Thu Nov 12 05:17:05 2015:sync start
LC/0/0/CPU0:Nov 12 05:17:07.980 EST: pfm_node_lc[294]: Thu Nov 12 05:17:05 2015:sync end
LC/0/0/CPU0:Nov 12 05:17:07.981 EST: pfm_node_lc[294]: Thu Nov 12 05:17:05 2015:platform_reboot_op start
RP/0/RSP0/CPU0:Nov 12 05:17:10.036 EST: shelfmgr[391]: %PLATFORM-SHELFMGR-6-NODE_KERNEL_DUMP_EVENT : Node 0/0/CPU0 indicates it is doing a kernel dump.
RP/0/RSP0/CPU0:Nov 12 05:17:10.037 EST: shelfmgr[391]: %PLATFORM-SHELFMGR-6-NODE_STATE_CHANGE : 0/0/CPU0 A9K-36x10GE-TR state:IOS XR FAILURE
RP/0/RSP0/CPU0:Nov 12 05:17:10.047 EST: shelfmgr[391]: %PLATFORM-SHELFMGR-6-NODE_STATE_CHANGE : 0/0/CPU0 A9K-36x10GE-TR state:BRINGDOWN
|
|
Last Modified: | 14-NOV-2015 |
|
Known Affected Releases: | 5.3.3.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv29422 | Title: | ASR 5.2.4 HSRP standby sending wrong packet |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
The message on active HSRP can be seen received from standby running 5.2.4
hsrp[1085]: %IP-STANDBY-4-WARN_TRAFFIC_SLAVE : HSRP control packet received from on MGO slave group: TenGigE0_0_2_0.201 group 201
Actually the hsrp standby slave group would send continuous refresh with the source hsrp vmac, causing continuous mac move in L2 switch network, breaking connectivity for hosts.
Conditions:
Router running 5.2.4 configured with HSRP slave group:
router hsrp
interface TenGigE0/0/2/0.2
hsrp bfd minimum-interval 100
hsrp bfd multiplier 8
hsrp delay minimum 5 reload 90
address-family ipv4
hsrp 2 version 2
name HSRP-Te0-2-1
preempt
priority 80
address 1.1.1.1
track TenGigE0/0/2/0.101 25
bfd fast-detect
!
!
!
interface TenGigE0/0/2/0.200
address-family ipv4
hsrp 200 slave
follow HSRP-Te0-2-1
address 2.2.2.2
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 04-NOV-2015 |
|
Known Affected Releases: | 5.2.4.BASE |
|
Known Fixed Releases: * | 5.3.3.9i.FWDG, 6.0.0.11i.FWDG |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu84248 | Title: | Umbrella SMU 5.3.0 for Fabric fixes |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
This is a Combo SMU for FIA issues seen in Tomahawk LCs
Conditions:
The SMU addresses few driver issues related to FIA init as well as enhancement to recover from an error with debug logging.
Workaround:
No workaround
Further Problem Description:
|
|
Last Modified: | 02-NOV-2015 |
|
Known Affected Releases: | 5.3.0.BASE |
|
Known Fixed Releases: * | 5.3.2 |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw30290 | Title: | Delay the backup path installation for bundle Convergence issue |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | We have mixed family of line cards. The Tomahawk LCs are faster than the
Typhoon LCs. This is causing the programming (convergence) on the Typhoon LC
to take longer compared to the Tomahawk LC
??? So in the interim we have state where Ingress Tomahawk LC is programmed to
switch from Bundle 1 to Bundle 2. The packet goes to the Typhoon LC which is part
of Bundle 2 but since this card is not yet programmed it black holes the traffic.
??? NHID feature is present on the platform to address such cases where we have
speed mismatched cards. If we have LFA enabled NHID is not supported currently.
??? LSNT team has verified with LFA configuration (NHID enabled) removed we are not
seeing such high traffic loss.
??? Code changes for LFA to utilize NHID would need additional packet buffer header
memory.
??? Typhoon does not have the additional space to support this.
??? Tomahawk would need microcode work in forwarding.
Symptom:
Packet loss of 10-15 sec on some streams during traffic move from Tomahawk
Only Mixed Bundle (B1) to Typhoon/Tomahawk Mixed Bundle (B2), without LFA
FRR being triggered.
Conditions:
Convergence event without LFA trigger
??? Bundle 1 is not going down due to triggers (listed below).
??? Ingress LC is Tomahawk LC/Typhoon (Mod-80) and egress is Typhoon LC
(24x10GE LC)
Following are the triggers:
??? OSPF link manual costing out of Bundle 1.
??? Shutting of some member links of the bundle 1 which trigger OSPF cost
threshold (BW <40GE).
??? LDP failure on Bundle 2. (Seen when traffic re-convergence to Bundle-2)
Workaround:
none
Further Problem Description:
We have mixed family of line cards. The Tomahawk LCs are faster than the
Typhoon LCs. This is causing the programming (convergence) on the Typhoon LC
to take longer compared to the Tomahawk LC
??? So in the interim we have state where Ingress Tomahawk LC is programmed to
switch from Bundle 1 to Bundle 2. The packet goes to the Typhoon LC which is part
of Bundle 2 but since this card is not yet programmed it black holes the traffic.
??? NHID feature is present on the platform to address such cases where we have
speed mismatched cards. If we have LFA enabled NHID is not supported currently.
??? LSNT team has verified with LFA configuration (NHID enabled) removed we are not
seeing such high traffic loss.
??? Code changes for LFA to utilize NHID would need additional packet buffer header
memory.
??? Typhoon does not have the additional space to support this.
??? Tomahawk would need microcode work in forwarding.
|
|
Last Modified: | 07-NOV-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | none |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux27591 | Title: | Token $(line) substitution does not work for ssh telnet |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
When using banner motd or 'banner exec' command with $(line) substitution around various network devices it was found it works on Cisco 7600 but does not work on ASR9000 in 4.2.3
Conditions:
banner motd or 'banner exec' command with $(line) substitution
Workaround:
if using 4.2.3 upgrade to 5.1.3 for telnet.
For ssh there is no workaround.
Further Problem Description:
|
|
Last Modified: | 24-NOV-2015 |
|
Known Affected Releases: | 5.1.3.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw39596 | Title: | Wrong IP address in traceroute response in VRF for BNG subscriber |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
When doing a traceroute in a VRF, the last hop PE may respond with the ICMP ttl exceeded using its MPLS core facing interface instead of an IP address in the VRF.
Conditions:
This is observed when doing a traceroute to a BNG subscriber in a VRF and with 'icmp ipv4 source vrf' configured on the router.
Workaround:
None
Further Problem Description:
it is specific for subscriber interface
it will impact like source address chosen action, like ping, traceroute.
|
|
Last Modified: | 21-NOV-2015 |
|
Known Affected Releases: | 5.1.3.BASE, 5.3.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux21528 | Title: | eXR: RSP Alpha stuck in INIT and Fail LED has color mismatch - fpd upgrd |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
RSP Alpha LED stuck in INIT and Fail LED has color mismatch after fdp upgrade.
Conditions:
During the CBC fpd upgrade, 0/PT0-PM3 is pulled out.
Workaround:
Unknown.
Further Problem Description:
|
|
Last Modified: | 19-NOV-2015 |
|
Known Affected Releases: | 6.1.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw02269 | Title: | NetFlow ASN is wrong on Tomahawk |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
netflow ASN attribute is wrong. It occurs in Tomahawk only. (It does not occur in Typhoon)
Conditions:
Tomahawk LC and configure "bgp attribute-download".
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 18-NOV-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: | 5.3.3.13i.BASE, 6.0.0.15i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus08820 | Title: | PLATFORM-CANB_SERVER-3-MESSAGE_FAILED with ASR-9001-FAN-V2 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
ASR9001 reports the following message:
RP/0/RSP0/CPU0:Nov 25 02:55:43.292 : canb-server[153]: %PLATFORM-CANB_SERVER-3-MESSAGE_FAILED : Unexpected CBC message received from slot 0/FT0/SP [ver 24.115] for msg type 3, id 159, len 4
Conditions:
Seen with the ASR-9001-FAN-V2.
Workaround:
Configure log suppression for message.
Example:
logging suppress rule CANB_FAN_MESSAGES
alarm PLATFORM CANB_SERVER MESSAGE_FAILED
!
logging suppress apply rule CANB_FAN_MESSAGES
all-of-router
!
Further Problem Description:
Despite message, fan tray is operating properly. Can verify with the following commands.
admin show environment fans or
admin show environment all
|
|
Last Modified: | 17-NOV-2015 |
|
Known Affected Releases: | 5.1.2.BASE, 5.1.3.BASE, 5.2.2.BASE |
|
Known Fixed Releases: * | 5.2.4.5i.BASE, 5.3.1, 5.3.1.12i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw94753 | Title: | BGP triggers import reset when L2VPN Mgr replays VPLS bridge import RT |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
BGP VPLS/VPWS import reset is triggerred when L2VPN Mgr. is restarted or on RP switchover.
Unless router has high VPLS/VPWS bridge-domain configuration this does not have impact. However during high VPLS/VPWS bridge-domain scale this can result in momentary higher CPU utilization.
Conditions:
Requires VPLS/VPWS configuration. and L2VPN Mgr. process is restarted or RP switchover is initiated.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 12-NOV-2015 |
|
Known Affected Releases: | 5.3.3.ROUT |
|
Known Fixed Releases: | none |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuv04103 | Title: | invmgr crash on RSP failover @inv_node_state_change_hndl |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
After RSP FO - upgrade to 5.3.2.14 - invmgr crash was observed
Conditions:
IOS-XR running 5.3.2
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 11-NOV-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | 5.3.2, 5.3.2.18i.BASE, 5.3.3.3i.BASE, 6.0.0.12i.BASE |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw91058 | Title: | LBK: 10GE DWDM Optics PM monitoring should only display LBC, OPT & OPR |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Current 10GE DWDM provisioning allows user to configure dwdm optics performance monitoring on CD, DGD, SOPMD, OSNR, PCR and PN.
However, 10GE SFP & XFP DWDM Optics are not able to measure these parameters: CD, DGD, SOPMD, OSNR, PCR and PN.
Hence, user should not be allowed to provisioni any these optics parameters for monitoring.
Also, the output of 'show controller dwdm (10GE port) pm (current|history) (15-min|24-hour) optics' displays these output parameters as 'zero' which is misleading to user. They should not print these parameters at all. The output 10GE DWDM optics PM monitoring should only display LBC, OPT and OPR.
RP/0/RP0/CPU0:megatron#show controllers dwdm 0/7/0/5 pm current 15-min optics
Optics in the current interval [15:30:00 - 15:40:16 Wed Oct 21 2015]
Optics current bucket type : Valid
MIN AVG MAX Threshold TCA Threshold TCA
(min) (enable) (max) (enable)
LBC[mA ] : 36 36 36 50 YES 500 YES
OPT[dBm] : -0.20 -0.20 -0.20 -13.01 YES -3.01 YES
OPR[dBm] : 2.42 2.43 2.44 -13.01 YES -3.01 YES
CD[ps/nm] : 0 0 0 0 YES 0 YES
DGD[ps ] : 0.00 0.00 0.00 0.50 YES 5.00 YES
SOPMD[ps^2]: 0.00 0.00 0.00 0.50 YES 5.00 YES
OSNR[dB] : 0.00 0.00 0.00 0.50 YES 5.00 YES
PDL[dB] : 0.00 0.00 0.00 0.00 NO 0.00 NO
PCR[rad/s] : 0.00 0.00 0.00 0.50 YES 5.00 YES
PN[dB] : 0.000 0.000 0.000 0.050 YES 0.500 YES
Last clearing of "show controllers DWDM" counters never
SW image used : asr9k-mini-px-5.3.3.14I, asr9k-optic-px-5.3.3.14I
Please see attached Email_Threads discussion.
Conditions:
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 10-NOV-2015 |
|
Known Affected Releases: | 5.3.3.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw14605 | Title: | [600] crypto sessions failed to come up |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Crypto sessions failed to come up
Conditions:
With dual RSP.
Workaround:
(1) reboot standby card and (2) restart mbxr_init process
Further Problem Description:
|
|
Last Modified: | 07-NOV-2015 |
|
Known Affected Releases: | 5.3.3.BASE, 6.0.0.BASE |
|
Known Fixed Releases: * | none |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut14500 | Title: | SSTE: SNMP mplsL3VpnVrfRteInetCidrIfIndex Error: OID not increasing |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Error: OID not increasing: when polling mplsL3VpnVrfRteInetCidrIfIndex
Conditions:
Workaround:
N/A
Further Problem Description:
|
|
Last Modified: | 04-NOV-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: * | 5.3.2.17i.BASE, 5.3.3.3i.BASE, 6.0.0.10i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut30719 | Title: | DHCPv6 Relay drops relay-reply packets in 6VPE topology |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
In DHCPv6 Relay mode, with a remote DHCP server and the DHCPv6 RELAY-REPLY packets from server gets dropped.
Error Trace:
RP/0/RSP0/CPU0:Feb 16 09:27:00.305 : dhcpv6d[1086]: DHCPV6 ERROR: TP2792: dhcpv6d_parse_and_validate_msg: Failed fill message info. rc: 'ipv6-new-dhcpv6d' detected the 'warning' condition 'Error: General failure'
RP/0/RSP0/CPU0:Feb 16 09:27:00.305 : dhcpv6d[1086]: DHCPV6 ERROR: TP3417: Failed parse and validate, rc='ipv6-new-dhcpv6d' detected the 'warning' condition 'Error: General failure'
Conditions:
1. DHCPv6 Relay mode
2. Remote server, not directly connected.
3. The RELAY-REPLY packets hits the RP node [on tunnel interface] with client interface being on LC
4. Saw only in 6VPE topology till now.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 02-NOV-2015 |
|
Known Affected Releases: | 5.2.2.BASE |
|
Known Fixed Releases: * | 5.2.4.15i.FWDG, 5.2.5.8i.FWDG, 5.3.1, 5.3.1.25i.FWDG, 5.3.2.3i.FWDG, 6.0.0.5i.FWDG |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw43908 | Title: | ASR9k Memory leak at mibd_interface process while polling MSDP data. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
in the
#show snmp trace packet we can see:
'snmp-lib-ipc' detected the 'resource not available' condition 'Not enough memory'
#show memory heap dllname 330
Mon Aug 31 16:05:06.273 EurAsd
Malloc summary for pid 1239306486 process mibd_interface:
Heapsize 32821248: allocd 30533104, free 255892, overhead 2032252, high watermark 32821248
Calls: mallocs 5084817; reallocs 129217; frees 4805517; [core-allocs 2093; core-frees 180]
core-allocs immediately grows.
#debug snmp mib msdpmib - looping last 3 messages:
RP/0/RSP0/CPU0:Sep 10 13:14:51.882 EurAsd: mibd_interface[330]: bind succeeded
RP/0/RSP0/CPU0:Sep 10 13:14:51.883 EurAsd: mibd_interface[330]: Initializing trap code
RP/0/RSP0/CPU0:Sep 10 13:14:51.885 EurAsd: mibd_interface[330]: Peer nfy : vrf default, peer 1.1.1.1, trap 0, event 0x2, val 2
RP/0/RSP0/CPU0:Sep 10 13:14:51.885 EurAsd: mibd_interface[330]: Peer nfy : vrf default, peer 2.2.2.2, trap 0, event 0x2, val 1
RP/0/RSP0/CPU0:Sep 10 13:14:51.885 EurAsd: mibd_interface[330]: search_context_info NULL
RP/0/RSP0/CPU0:Sep 10 13:14:51.885 EurAsd: mibd_interface[330]: peer: PAddr:2.2.2.2, Nom:0x1, Stype:0xa0
RP/0/RSP0/CPU0:Sep 10 13:14:51.885 EurAsd: mibd_interface[330]: peer: create RBTree
RP/0/RSP0/CPU0:Sep 10 13:14:51.886 EurAsd: mibd_interface[330]: peer: datalist returned 2 entries
RP/0/RSP0/CPU0:Sep 10 13:14:51.886 EurAsd: mibd_interface[330]: peer: decode peer 2.2.2.2
RP/0/RSP0/CPU0:Sep 10 13:14:51.886 EurAsd: mibd_interface[330]: peer: decode peer 1.1.1.1
RP/0/RSP0/CPU0:Sep 10 13:14:51.886 EurAsd: mibd_interface[330]: peer: datalist returned 2 entries
RP/0/RSP0/CPU0:Sep 10 13:14:51.886 EurAsd: mibd_interface[330]: peer: decode peer 2.2.2.2
RP/0/RSP0/CPU0:Sep 10 13:14:51.886 EurAsd: mibd_interface[330]: peer: decode peer 1.1.1.1
Conditions:
Multiple MSDP peers configured and polled via SNMP
The order of the MSDP peers is not incremental.
Even if in the right order in the configuration it might vary in that output:
router msdp
peer 1.1.1.1
!
peer 2.2.2.2
!
!
#show msdp peer
Mon Sep 28 16:33:01.263 CEST
MSDP Peer 2.2.2.2 (?), AS 1111
MSDP Peer 1.1.1.1 (?), AS 1111
Resterting of mibd_interface and snmpd will temporary solve the issue.
Workaround:
Reconfigure MSDP peers - put it in incremental order.
Further Problem Description:
the problem is in sysdb, the peers needs to be configured in the right order
|
|
Last Modified: | 01-DEC-2015 |
|
Known Affected Releases: | 4.1.0.MCAST, 4.3.4.BASE |
|
Known Fixed Releases: * | 5.2.5.35i.MCAST, 5.3.3.16i.MCAST, 6.0.0.18i.MCAST, 6.1.0.2i.MCAST |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw49531 | Title: | ipv4 mroute when polled does not return output |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
ASR9k running 5.2.0 and 5.1.2 do not return any info for ipv4 mroute when polled with MIB 1.3.6.1.4.1.9.10.117.1.1.3.1.8 (only ipv6 infos are returned).
Conditions:
This issue should happen only on the PIM RP routers
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 01-DEC-2015 |
|
Known Affected Releases: | 4.1.0.MCAST, 5.1.3.MCAST |
|
Known Fixed Releases: * | 5.2.5.35i.MCAST, 5.3.3.16i.MCAST, 6.0.0.21i.MCAST, 6.1.0.3i.MCAST |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw12734 | Title: | segmcast: MPLS LDP crash seen on ABR router |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
MLDP process can crash.
Conditions:
When doing a no multicast routing/rollback, the MLDP Process can crash. This can happen also if MLDP process is restarted on both Active and Standby RPs simultaneously.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 01-DEC-2015 |
|
Known Affected Releases: | 5.2.2.MCAST, 6.0.0.MCAST |
|
Known Fixed Releases: * | 5.2.5.35i.MCAST, 5.3.3.16i.MCAST, 6.0.0.15i.MCAST |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu42399 | Title: | % Ambiguous command: clear counter tengigE / hundredGigE / TenGigECtrlr |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Not able to clear counter on Tengig/ hundredGigE/ TenGigECtrlr interfaces in XR-5.2.4
Conditions:
clear counter tengigE0/3/1/0
% Ambiguous command: "clear counter tengigE0/3/1/0"
Workaround:
Use the short CLI:
Example:
RP/0/RP0/CPU0:cr02.chicago.il.ibone#clear counters Hu0/6/0/3
Tue Jun 30 21:25:51.928 UTC
Clear "show interface" counters on this interface [confirm]
RP/0/RP0/CPU0:cr02.chicago.il.ibone#
Further Problem Description:
|
|
Last Modified: | 01-DEC-2015 |
|
Known Affected Releases: | 5.2.4.BASE, 6.0.0.FWDG |
|
Known Fixed Releases: * | 5.2.5.35i.FWDG, 6.0.1.5i.BASE, 6.0.1.5i.FWDG, 6.1.0.7i.FWDG |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuv27376 | Title: | Add a malloc_opts API to control malloc arena truncation behavior |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:This ddts is to introduce malloc_opt MALLOC_SHRINK_OPTION to control this behavior - thus, applications not using the MALLOC_SHRINK_OPTION will see the previous behavior of shrinking to a minimal size, applications using MALLOC_SHRINK_OPTION will see the new behavior of only shrinking to the size set by MALLOC_ARENA_SIZE
Conditions:Workaround:
|
|
Last Modified: | 28-NOV-2015 |
|
Known Affected Releases: | 6.0.0.BASE |
|
Known Fixed Releases: | 5.3.2, 5.3.2.19i.BASE, 5.3.3.5i.BASE, 6.0.0.8i.BASE |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux21873 | Title: | Mobile route is getting diappeared on ipv4_rib restart |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Mobile routes not seen in ipv4 rib
Conditions:
process restart ipv4_rib
Workaround:
none
More Info:
|
|
Last Modified: | 26-NOV-2015 |
|
Known Affected Releases: | 5.3.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux08306 | Title: | ASR9K sends packet having wrong destIP through Mgmt Ether |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
SNMP Server receives duplicated SNMP trap
Conditions:
Sending SNMP Trap through Mgmt Ether and 2 SNMP trap hosts are configured.
For example, 192.168.1.1 is received 1 more trap and 192.168.1.2 is not received 1 trap at the issue with the following configuration.
snmp-server host 192.168.1.1 traps version 2c public
snmp-server host 192.168.1.2 traps version 2c public
Workaround:
No workaround.
Further Problem Description:
BTW, this issue is seen when cdp is configured under Mgmt Ether.
So you might recover the issue if you delete cdp configuration under Mgmt Ether.
|
|
Last Modified: | 26-NOV-2015 |
|
Known Affected Releases: | 4.3.2.BASE |
|
Known Fixed Releases: * | 5.3.3.20i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuh02686 | Title: | ssm_process goes from avilable to un avilable for lrd process |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Customer see the following error during a reboot:
RP/1/RSP0/CPU0:Mar 3 23:11:37.601 : ssm_process[401]: %OS-SSM-6-NODAL_SERVICE_STATE_CHANGE : Nodal service state changes from AVAILABLE to UNAVAILABLE
LC/1/0/CPU0:Mar 3 23:14:16.265 : ssm_process[335]: %OS-SSM-6-NODAL_SERVICE_STATE_CHANGE : Nodal service state changes from AVAILABLE to UNAVAILABLE
Conditions:
Router reload running 5.1.X
Workaround:
none
Further Problem Description:
This error message is cosmetic.
|
|
Last Modified: | 26-NOV-2015 |
|
Known Affected Releases: | 4.3.2.BASE, 5.1.1.BASE |
|
Known Fixed Releases: * | 5.1.3, 5.1.3.14i.BASE, 5.1.4, 5.2.1, 5.2.1.24i.BASE, 5.2.2, 5.2.2.10i.BASE, 5.2.21, 5.3.0, 5.3.0.1i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu95301 | Title: | Umbrella DDTS to address FIB issues causing outage/corruption |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
FIB performance issue resulting in outage
Conditions:
Two underlying issues:
CSCus81652 Few VRFs have traffic loss with 2K VRF scale from PE to BL.
CSCuu93156 ipv6 static routes over tunnel-te interfaces not installed none
And:
CSCuv06101 Traffic loss seen with Multi-path for prefix with more than 4 paths
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 02-NOV-2015 |
|
Known Affected Releases: | 5.1.0.BASE |
|
Known Fixed Releases: * | 5.3.2 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw67179 | Title: | ip ttl propagation disable does not work on ISM service module |
|
Status: | Open |
|
Severity: * | 6 Enhancement |
Description: | Symptom:
CU has topology with centralized CG NAT on ASR9k with ISM.
cpe1---pe1---MPLS_NET_1---ASR9k(ISM/NAT)---MPLS_NET_2---pe2---cpe2
CU decided to hide their network from client eyes and typed command ip ttl propagation disable on all devices in the network.
He is making traceroute from cpe1 to cpe2 and awaiting to see in traceroute the next hops: pe1-ASR9k(ISM)-pe2-cpe2
But actually he can see pe1-ASR9k(ISM)-ALL HOPS IN MPLS_NET_2-pe2-cpe2
It means that ttl after ISM is not installed to mpls label as 255.
Behavior is fluently reproduced in the lab.
Conditions:
Traffic passed through ISM and directed to mpls does not influenced by ip ttl propagation disable command
Workaround:
There are no workaround.
Further Problem Description:
|
|
Last Modified: | 25-NOV-2015 |
|
Known Affected Releases: | 4.3.4.LC |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw14643 | Title: * | PWHE forwarding stops when subint is configured on the Bundle GI member |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Traffic may stop on a PWHE interface
Conditions:
This problem would occur after configuring a sub-interface under the interface used in the generic interface list.
Workaround:
Further Problem Description:
|
|
Last Modified: | 14-NOV-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux21061 | Title: | eXR: Kernel messages during bake phase interferes with install logs |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Kernel messages during bake phase interferes with install logs.
Conditions:
Load image on a router using reimage_chassis.
Workaround:
Unknown.
Further Problem Description:
|
|
Last Modified: | 19-NOV-2015 |
|
Known Affected Releases: | 6.1.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCui41063 | Title: | sh ethernet cfm configuration-errors throws error |
|
Status: | Terminated |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Conditions:
Workaround:
Expected Resolution: Please check with the support engineer for information on which release(s) this bug is expected to be fixed.
Reproducibility (%):
Further Problem Description:
|
|
Last Modified: | 21-NOV-2015 |
|
Known Affected Releases: | 5.1.0.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux15027 | Title: | snmp walk output and CLI output donot match for entSensorMeasuredEntity |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
SNMP walk and the CLI output for the entSensorMeasuredEntity donot match.The no of entries in CLI shows around 90, whereas SNMP has listed few.
Conditions:
snmp walk on the entSensorMeasuredEntity.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 14-NOV-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv10167 | Title: | ASR9K(9000v) LLDP dot1ad nni doesn't work with 3750-ME |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
SR9K(9000v) sends and expects dest MAC address 01-80-C2-00-00-0E regardless dot1d nni is configured or not. This causes interworking issue with Cisco 3750-ME device which sends and expects 01-80-C2-00-00-03 when dot1ad nni is configured. There is no problem when dot1ad nni is not configured, ethertype 0x8100.
Conditions:
3750-ME ethernet dot1ad nni is configured
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 07-NOV-2015 |
|
Known Affected Releases: | 5.1.3.BASE |
|
Known Fixed Releases: * | none |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux23668 | Title: | ASR9k BNG. DHCPv6 VLAN ID lost when using geo red vMAC + ambiguous vlan |
|
Status: | Open |
|
Severity: * | 6 Enhancement |
Description: | Symptom:
VLAN id is changed to 1 for DHCPv6 ADVERTISE packets
Conditions:
when doing IPoE for dual-stack or IPv6 sessions and using geo redundancy vMAC together with ambiguous VLAN on access interface
Workaround:
issue does not occur if vMAC is not used
Further Problem Description:
|
|
Last Modified: | 27-NOV-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: | |
|
|
| |
2015 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论