| |
|
Alert Type: | Updated * |
Bug Id: | CSCut51192 | Title: | LDP does not have a retry mechanism if failure in vbind observed |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
MPLS LDP stop forwarding and the 'Failed lookup' count incrementing in show mpls forwarding summary output.
Conditions:
No NSR configured for LDP and RP FO
Workaround:
None
Further Problem Description:
Problem can be recovered with MPLS LDP process restart
|
|
Last Modified: | 04-NOV-2015 |
|
Known Affected Releases: | 5.1.3.CE |
|
Known Fixed Releases: * | 5.2.5.25i.MPLS, 5.3.1.27i.MPLS, 5.3.1.28i.MPLS, 5.3.2, 5.3.2.6i.MPLS, 6.0.0.5i.MPLS |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut54688 | Title: | mLDP FRR Duplicated packets received when shutdown primary interface |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
During mLDP FRR, duplicate packets are seen for 100 ms after the initial 50ms drop due to link down. The expectation is to see the duplicates for a very short duration, when the MergePoint adds the new (MBB) LSP and removes the old LSP.
Conditions:
mLDP FRR should be enabled, either with P2P-TE-backup tunnels or with LFA backup LSPs
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 01-DEC-2015 |
|
Known Affected Releases: | 5.1.1.MCAST, 5.3.2.BASE |
|
Known Fixed Releases: * | 5.2.5.35i.MPLS, 5.3.2, 5.3.2.7i.MPLS, 6.0.0.5i.MPLS |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu20483 | Title: | Graceful way to handle cases where clients were slow to pick up mq msgs |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
When a particular ENF client MQ is full, enf_broker is permanently blocked in mq_send.
Conditions:
This happens in a scenario where the enf client is slow to pick up the mq messages.
This can eventually lead to the client mq being full. Once the mq is full, any event notification such as process death, start, ready, node down notifications which is typically delivered by enf will cause enf_broker to be blocked forever.
Workaround:
No workaround
Further Problem Description:
|
|
Last Modified: | 07-NOV-2015 |
|
Known Affected Releases: | 5.3.1.BASE, 5.3.2.BASE |
|
Known Fixed Releases: * | none |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux09858 | Title: | v6 NA, NS packets for taiko satellite dropped as PLU LEAF Type No match |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
IPv6 ND is not resolved on vrf interface on remote side of CRS-1,3 LC
Conditions:
Locally generated IPv6 ND (both NA & NS) packets for vrf interafces on CRS-1, 3 LC interfaces get dropped on Egress PSE, resulting in ND not being resolved on peer.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 25-NOV-2015 |
|
Known Affected Releases: | 5.3.3.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv69846 | Title: | Traffic Drops on Bundle interface |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Forwarding chain is not updated after bundle member removal/addition
Conditions:
Bundle member removal/addition
Workaround:
LC reload
Further Problem Description:
|
|
Last Modified: | 07-NOV-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: * | none |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw12567 | Title: | MSDP process keeps crashing because of memory depletion |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:MSDP process crash because of memory depletion. On Standby RP, MSDP process memory is increasing slowly and after certain time, the process crashes and this is happening continuously
Conditions:enable multicast
Workaround:None
More Info:
|
|
Last Modified: | 01-DEC-2015 |
|
Known Affected Releases: | 5.2.2.CE, 5.3.1.CE |
|
Known Fixed Releases: * | 5.2.5.35i.MCAST, 5.3.3.16i.MCAST, 6.0.0.14i.MCAST |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw92664 | Title: | OSPF process crash seen after bundle link shut |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
OSPF process crashes when there is adjacency flaps in some scenarios.
Conditions:
The exact trigger is not known, but OSPF needs to be enabled with Traffic Engineering and also multicast-intact knob enabled. The issue happens when processing of summary or external routes right around the time when a large number of adjacencies flaps.
Workaround:
there is no workaround
Further Problem Description:
This is likely a day 1 issue affecting all XR platforms.
|
|
Last Modified: | 14-NOV-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux06698 | Title: | ATT-CERT: RCC check fails - Remote-Backup-label Mismatch |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: * | Symptom:
RCC Check fails on all nodes, for few routes due to "Remote-Backup-label Mismatch" after clear ospf process.
Conditions:
Clear ospf process
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 26-NOV-2015 |
|
Known Affected Releases: | 5.3.3.ROUT |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw76916 | Title: | Deletion of packet interface happens post to LC reload. |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Ethernet Packet interfaces get deleted upon RP reload
Conditions:
Configure Ethernet Packet interfaces and reload the active RP
Workaround:
NONE
Further Problem Description:
1. Configure 1 L2 xconnect & bring up the traffic
2. Reload active RP VM & after this wait till redundancy to get established again & traffic flow starts .
sysadmin-vm:0_RP0# sdr default-sdr location 0/RP0/VM1 reload
Sat Oct 17 07:59:58.162 UTC
RP/0/RP1:ios#show redundancy summary
Fri Oct 16 09:09:08.262 UTC
Active Node Standby Node
----------- ------------
0/RP1 0/RP0 (Node Ready, NSR:Not Configured)
0/LC0 0/LC1 (Node Ready, NSR:Not Configured)
3. Reload active LC >>>> after this all the created packet interface are deleted resulting into complete traffic drop even though both RP &LC vm redundancy is UP.
RP/0/RP1:ios#show interfaces brief
Fri Oct 16 09:27:12.052 UTC
Intf Intf LineP Encap MTU BW
Name State State Type (byte) (Kbps)
--------------------------------------------------------------------------------
Nu0 up up Null 1500 0
Mg0/RP0/CPU0/0 admin-down admin-down ARPA 1514 10000000
Mg0/RP1/CPU0/0 admin-down admin-down ARPA 1514 1000000
RP/0/RP1:ios#show l2vpn xconnect
Fri Oct 16 09:28:26.161 UTC
Legend: ST = State, UP = Up, DN = Down, AD = Admin Down, UR = Unresolved,
SB = Standby, SR = Standby Ready, (PP) = Partially Programmed
XConnect Segment 1 Segment 2
Group Name ST Description ST Description ST
------------------------ ----------------------------- -----------------------------
1 1 UP Te0/2/0/3 UP Te0/2/0/4 UP
----------------------------------------------------------------------------------------
|
|
Last Modified: | 14-NOV-2015 |
|
Known Affected Releases: | 6.0.0.BASE, 6.1.0.BASE |
|
Known Fixed Releases: * | 6.1.0.7i.BASE, 6.1.0.7i.FWDG |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw53705 | Title: | [NCS4K] A "TX fifo underrun" alarm is standing on one of the 4K nodes. |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
HUB1-4K2 has the following standing alarm since 09/09/15: Object: 0/LC2/LC_SW/25; Slot: NA; Port: 25; Sev: MN; Con: CPSS_PP_PORT_TX_UNDERRRUN_E; Description: TX fifo underrun. The alarm has not impacted traffic or communications to the node, but its impact has not been fully assessed.
Conditions:
it happens after we did upgrade the system using new image
Workaround:
reload the LC which have the alarm error
Further Problem Description:
This error should not happens on switch, it means there's pkt to transfer but check TX engine and found no pkt there. We saw lots of pkt drop on the port which reports the issue.
We need to regard this error as critical alarm and doing switch reset once hit it.
|
|
Last Modified: | 01-DEC-2015 |
|
Known Affected Releases: | 5.2.41.BASE |
|
Known Fixed Releases: * | 5.2.5.35i.BASE |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw52352 | Title: | FM clients need to use unique instance_id when reg same XML with FM |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
Fake Alarms may appear at NMS side
Conditions:
on RPVM, LCVM switchover or RP Reload
Workaround:
None
Further Problem Description:
reproducible 100%
Expected Resolution - Next Release
|
|
Last Modified: | 14-NOV-2015 |
|
Known Affected Releases: | 5.2.41.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux00857 | Title: | RSVP incorrectly triggers graceful restart when process restarted |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
RSVP process restart on the active RP incorrectly triggers Graceful Restart
Conditions:
restart of the RSVP process on the active Route Processor.
Workaround:
None
Further Problem Description:
With the introduction of RSVP NSR in 520 a process restart should not trigger GR procedures. The RSVP control plane should be recovered through NSR procedures. Note that RSVP will still ack as a GR helper,
|
|
Last Modified: | 28-NOV-2015 |
|
Known Affected Releases: | 5.2.4.MPLS |
|
Known Fixed Releases: * | 6.1.0.9i.MPLS |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuv67843 | Title: | Multicast Traffic loss During soft RPF0 on SIP-700 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Replication of PIM GRE packets is an enhancement to support NSR from 522 which requires PIM topology states being programmed upfront on both Active and Standby RSP.
To create state upfront PIM rely all hellos, Joins, asserts, Data TLVs etc being replicated on both active and standby RSP by LPTS for native and MVPN purposes.
Since PI team changed the behaviour, some changes required in PD as well.
So the functionality will broken from 522 and later upgrades.
Symptom:
Momentary traffic loss(about 42sec) observed during RSP switch over, When standby become active.
Conditions:
In a MVPN setup with 522 release image, when SIP-700 placed as a core facing LC
Workaround:
None
Further Problem Description:
RCA of the problem was that the core facing Thor LC is not sending the PIM Join,Assert,hello, Data TLVs to standby RSP.
When a RSP switchover is done the Data MDTs get deleted and reprogrammed because they are learnt as new routes when the standby becomes active.
|
|
Last Modified: | 12-NOV-2015 |
|
Known Affected Releases: | 5.2.4.BASE |
|
Known Fixed Releases: | none |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw28202 | Title: * | HW CEF entry is not updated after changing igp topology |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Symptom 1.
When IGP topology is changed(e.g. ospf cost change), HW CEF for the bgp prefix, which needs two or more recursive lookup like the following, is not updated and old egress path info(tunnel-te A) remains.
- affected BGP prefix : X.X.X.X/28 (nexthop Y.Y.Y.Y)
- other BGP prefix : Y.Y.Y.0/24 (nexthop Z.Z.Z.Z)
- IGP prefix : Z.Z.Z.0/24 (egress IF before IGP change: tunnel-te A, egress IF after IGP change: tunnel-te B, )
Symptom 2.
after sysmptom 1, if down event of tunnel-te A which is old info in the HW CEF entry happens, the adjacency info in the HW CEF entry becomes invalid state and packet drop continues with increase of PAT drop counter. (e.g. TLU entry has invalid TLU_ID, MPLS FIB NH Drop)
Conditions:
When router matches all of the following condition and trigger, the issue happens.
Condition:
A. there is bgp routes which need two or more recursive lookup
B. the nexthop of the routes of condition A is tunnel-te
C. there is IGP route that depth_changed flag in CEF entry is 0. (egress IF of this IGP route is tunnel-te B in the above symptom 1)
Trigger of Symptom 1 : change igp topology (e.g. ospf cost change)
Trigger of Symptom 2 : down/up of tunnel-te A which is old egress IF for the prefix of symptom 1.
Workaround:
Finding IGP CEF entry with depth_changed flag 0 and changing the flag to 1 can prevent this issue.
We can change the flag to 1 by changing the igp route as follows.
e.g. 1 path -> ECMP path -> 1 path
Further Problem Description:
We can check the depth_changed flag by the following cli.
#show cef ipv4 hardware ingress detail location 0/x/CPU0
-- snip ?-
Gateway array (0x5e98d5d0) reference count 3, flags 0x0, source rib (6), 0 backups
[4 type 3 flags 0x10101 (0x5fe69da8) ext 0x0 (0x0)] <<<<< chech flags
#show cef obj-flags loadinfo 0x10101
owner locked, added to pl, depth changed <<<<< if you can see "depth changed", the flag is 1.
|
|
Last Modified: | 07-NOV-2015 |
|
Known Affected Releases: | 5.1.2.BASE |
|
Known Fixed Releases: * | none |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv17805 | Title: | MSDP sessions are kept flapping on CRS router |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
MSDP sessions are kept flapping on the router
Conditions:
Standby RP or RSP has to be present on the router. There is higher probability of hitting this issue when the number of SAs are very high (say, 20000) OR the load on the router control-plane (RP or RSP) is very high.
Workaround:
None
Further Problem Description:
MSDP process restart may recover the router back to normal. Another possible recovery is to shutdown and start the standby MSDP process.
|
|
Last Modified: | 01-DEC-2015 |
|
Known Affected Releases: | 5.2.2.MCAST, 5.3.1.MCAST, 5.3.3.MCAST |
|
Known Fixed Releases: * | 5.2.5.35i.MCAST, 5.3.3.16i.MCAST, 6.0.0.20i.MCAST, 6.1.0.3i.MCAST |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue69413 | Title: | show packet-memory show UDP hold packets and never free |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Cisco IOS XR Software version 4.3.1 contains a vulnerability that could result in complete packet memory exhaustion. Successful exploitation could render critical services on the affected device unable to allocate packets resulting in a denial of service (DoS) condition.
Cisco has released free software updates that address this vulnerability.
Workarounds that mitigate this vulnerability are available.
This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20131002-iosxr
Conditions:
See Affected Products section of the advisory.
Workaround:
See Workarounds section of the advisory.
Further Problem Description:
See PSIRT Security Advisory.
PSIRT Evaluation:
Cisco has released free software updates that address this vulnerability.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 07-NOV-2015 |
|
Known Affected Releases: | 4.3.1.BASE, 4.3.2.BASE |
|
Known Fixed Releases: * | none |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux22878 | Title: | EEM crashed - eem regns missing |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
run show event manager policy registered causes crash
Conditions:
CRS 4.2.4 normal show command caused a crash - this had a different signature that eem regns were gone
Workaround:
restart eem_policy_dir process and reregister all the scritps that were previously registered
Further Problem Description:
|
|
Last Modified: | 20-NOV-2015 |
|
Known Affected Releases: | 4.2.4.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv29693 | Title: | AMBER: cannot set CFP2 optics Tx power to 0 dBm |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
On a Cisco router, Tx power setting of CFP2 optics with EMON tool is not supported
Conditions:
Thee current HW revision of the optical modules on a Cisco router an not adjust the output power. 200G CFP2 optics has fixed output power.
Workaround:
FW 4.1C of CFP2 will be supporting Tx power setting.
Further Problem Description:
|
|
Last Modified: | 19-NOV-2015 |
|
Known Affected Releases: | 5.3.2.BASE |
|
Known Fixed Releases: * | 6.0.1.5i.BASE, 6.0.1.5i.FWDG |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw63692 | Title: | Stale tunnel config present in node after RP reload |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: * | Symptom:
After Active RP reload on Head Node, "show running-config" displays tunnels which were deleted just before Active RP reload
Conditions:
Active RP reload immediately after the tunnel deletion.
Workaround:
Provide atleast few mins before performing Active RP reload after a GMPLS tunnel configuration.
If it still leads to the issue, restart te_control and delete the tunnel
Further Problem Description:
N/A
|
|
Last Modified: | 19-NOV-2015 |
|
Known Affected Releases: | 5.2.41.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj01218 | Title: | Need to change "/service-role/" subtree |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
In CRS or ASR9K routers having CGSE/CGSE+ or ISM modules, these Line cards may show up as "FAILED" (or in a state other than OK or "App Ready") state. This could be noticed in the output of "show platform" command. If this issue is not fixed, all traffic that requires NAT44, NAT64 or DS Lite processing will be dropped.
If you examine the output of "show running-config", it is noticed that the configuration line items "hw-module service cgn location " is missing
Conditions:
1. The CRS or ASR9K router has CGSE/CGSE+ or ISM modules.
2. The Software is upgraded to 4.3.1 or 4.3.2 from a previous version
Workaround:
There is no workaround. To recover, please configure and commit the "hw-module service cgn location " once more after the upgrade. Then reload the module.
Further Problem Description:
|
|
Last Modified: | 16-NOV-2015 |
|
Known Affected Releases: | 4.3.2.BASE |
|
Known Fixed Releases: * | 5.1.1.9i.BASE, 5.1.1.9i.FWDG, 5.1.11.4i.BASE, 5.1.11.4i.FWDG, 5.1.2.1i.BASE, 5.1.2.1i.FWDG, 5.2.0.2i.BASE, 5.2.0.2i.FWDG |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw75752 | Title: | BO - Improper removal alarm is not suppressing SYNCLOSS |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
On breakout ports, imrproper removal alarm is not suppressing the SYNCLOSS alarms.
Conditions:
ON any HA events the issue can be seen for breakout ports
Workaround:
No
Further Problem Description:
|
|
Last Modified: | 14-NOV-2015 |
|
Known Affected Releases: | 5.2.41.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu16784 | Title: | circuit can not be created on dual channelization of same odu2 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
After editing the open end circuit for new controllers, tunnel do not show new controllers on GUI.
Conditions:
In edit pane, if controller are changed to new value ,new controllers are not shown in circuit and old controller state is not free in CLI.
Workaround:
Create another open end circuit with some other new channelized controller.
Further Problem Description:
Expected Resolution: To be fixed in 6.0 release.
Reproducibility: 100%
|
|
Last Modified: | 07-NOV-2015 |
|
Known Affected Releases: | 5.2.4.BASE, 5.2.41.BASE |
|
Known Fixed Releases: * | none |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv53911 | Title: | Fragmented MPLS packets injected with MPLS label 4 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
MPLS packets are forwarded with outer MPLS label 4.
Conditions:
MPLS packets punted to LC CPU for fragmentation. Label operation should be pop.
Workaround:
No known workarounds
Further Problem Description:
Fragmentation in MPLS core should be avoided through network design.
Some bad consequences of fragmentation are:
- Packets may be delivered out of order. If packet 1 is large, it's delayed on the router because of fragmentation (depending on the platform implementation it may be punted to process level or looped through normal forwarding path). If packet 2 of the same flow is received immediately after the packet 1, it will be forwarded before the two fragments 1a and 1b are forwarded.
- Higher performance strain on the router. Regardless of which fragmentation method is implemented, at minimum a loop through the internal forwarding path is required, if not a punt to process level.
- On ASR9000 packets requiring fragmentation are policed on the punt path towards LC CPU.
|
|
Last Modified: | 07-NOV-2015 |
|
Known Affected Releases: | 5.2.2.BASE, 5.2.4.MPLS, 5.4.0.BASE |
|
Known Fixed Releases: * | none |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw55927 | Title: | Shut & Maintenance not working for channelize controller in CTC |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Apply Button is not enabled on edit circuit pane.
Conditions:
On changing the admin state from ODU configuration of the controller on edit circuit pane APPLY button is not enable.
Workaround:
Change the OTN property to CONTROLLER in preference window.
Further Problem Description:
Reproducibility : 100%
Expected fix : Next release.
|
|
Last Modified: | 07-NOV-2015 |
|
Known Affected Releases: | 5.2.41.BASE |
|
Known Fixed Releases: | none |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw55379 | Title: | In 'create SNMP community' window all four basic traps should be checked |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
on selecting the Basic Traps in SNMP all for of the traps are selected by default , in SNMP as the XML query which was being fired was irrelevant
Conditions:
1. Network View -> SNMP ->SNMP -> Trap Destinations
2. Select a Trap Destinations
3. Create a new community
4. Select Ok without selecting all traps
5.all basic traps are applied
Workaround:
NA
Further Problem Description:
reproducibilty 100%
|
|
Last Modified: | 07-NOV-2015 |
|
Known Affected Releases: | 5.2.41.BASE |
|
Known Fixed Releases: | none |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuv58131 | Title: | Bringdown Fabric board on hitting FGID SRAM parity error |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When the 40-G fabric card is recovering from FGID sram parity error, sometimes the fabric barrier errors are reported. It causes some instability in the network and forwarding path.
Conditions:
The FGID sram parity error in 40-G fabric card.
Workaround:
There is no workaround. The fabric barrier errors and network instability due to FGID sram parity error are seen once in a while.
Further Problem Description:
When the ASIC is recovered from FGID sram parity error, sometime the bad fabric hardware disrupts the fabric barrier flow in the system and causes barrier time-outs in other fabric ASIC stages of same fabric plane, and the barrier errors propagate to other planes subsequently.
|
|
Last Modified: | 07-NOV-2015 |
|
Known Affected Releases: | 5.3.3.BASE |
|
Known Fixed Releases: | none |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw24345 | Title: | BVI Up state should take pseudowires into consideration on MCLAG standby |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
BVI IP protocol state is down on standby MLACP host, eventhough one of the PW is up. According to architecture, BVI state should be up if one of the AC or PW is up.
Conditions:
MLACP with BVI and VPLS. Issue is only on standby MLACP host
Workaround:
Add a dummy L2 sub-interface to each bridge-domain with BVI.
Further Problem Description:
|
|
Last Modified: | 07-NOV-2015 |
|
Known Affected Releases: | 5.2.4.BASE |
|
Known Fixed Releases: | none |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw24956 | Title: * | Large backlog size is required for LDP scale test on IoT w/ other vendor |
|
Status: * | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
When 100+ LDP neighbors try to connect one LDP node, TCP SYN might be dropped by socket queue drop.
Conditions:
During scale LDP neighbors topology.
Workaround:
No workaround.
Further Problem Description:
|
|
Last Modified: | 07-NOV-2015 |
|
Known Affected Releases: | 4.2.1.MPLS, 4.3.1.MPLS, 5.3.2.MPLS |
|
Known Fixed Releases: * | none |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut44220 | Title: | (531-SSR3) show logging start CLI not working as expected |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
show logg start not working as expected
Conditions:
System timezone has daylight savings time enabled
Workaround:
None
Further Problem Description:
For non-DST timezones, it works fine
|
|
Last Modified: | 04-NOV-2015 |
|
Known Affected Releases: | 5.3.1.BASE |
|
Known Fixed Releases: * | 5.3.2, 5.3.2.3i.BASE, 6.0.0.5i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv40040 | Title: | Umbrella ddts for ppp-ma bugs on XR 5.2.4 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
This is an umbrella SMU for the following bug fixes:
CSCuu37058 Sev3 [ppp-ma ] New PPPoE sessions not coming up
CSCus17352 Sev3 [ppp-ma ] Few PPPoE sessions are disconnected with PPP LCP FSM triggered down
These fixes are highly recommended for BNG deployments on IOS XR release 5.2.4.
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 04-NOV-2015 |
|
Known Affected Releases: | 5.2.4.BASE |
|
Known Fixed Releases: * | 5.3.2 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu96125 | Title: | ESD Process going down after installing Xr_issu SMU |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
VTY sessions are dropped during the ISSU load phase procedure. Once lost they are no longer accessible.
The RP1 mgmt went down during ISSU load phase (time stamp: Aug 5 15:42:08.968).
RP/0/RP1/CPU0:Aug 5 15:42:08.968 : ifmgr[138]: %PKT_INFRA-LINK-3-UPDOWN : Interface MgmtEth0/RP1/CPU0/0, changed state to Down
RP/0/RP1/CPU0:Aug 5 15:42:08.968 : ifmgr[138]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface MgmtEth0/RP1/CPU0/0, changed state to Down
After the sdr reload, I see that mgmt on RP0 also went down (time stamp: Aug 5 15:49:55.925 ). By then the ISSU clean up phase was completed (time stamp: Aug 5 15:48:38 2015)
RP/0/RP0/CPU0:Aug 5 15:49:55.925 : ifmgr[333]: %PKT_INFRA-LINK-3-UPDOWN : Interface MgmtEth0/RP0/CPU0/0, changed state to Down
RP/0/RP0/CPU0:Aug 5 15:49:55.925 : ifmgr[333]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface MgmtEth0/RP0/CPU0/0, changed state to Down
ISSU summary confirms these time stamps.
RP/0/RP1/CPU0:R105-PE5#show issu summary
Last ISSU operation completed successfully.
List of ISSU phases:
------------------------------------------------------------
Phase name : Prep Phase
Status : Completed
Start time : Wed Aug 5 15:24:23 2015
Complete time : Wed Aug 5 15:27:19 2015
------------------------------------------------------------
Phase name : Load Phase <<<<
Status : Completed <<<<<
Start time : Wed Aug 5 15:30:04 2015 <<<<<
Complete time : Wed Aug 5 15:46:47 2015 <<<<<
------------------------------------------------------------
Phase name : Run Phase
Status : Completed
Start time : Wed Aug 5 15:47:28 2015
Complete time : Wed Aug 5 15:47:28 2015
------------------------------------------------------------
Phase name : Cleanup Phase
Status : Completed
Start time : Wed Aug 5 15:48:38 2015
Complete time : Wed Aug 5 15:48:38 2015
============================================================
RP/0/RP1/CPU0:R105-PE5#show interfaces brief | i Mgmt
Mg0/RP0/CPU0/0 down down ARPA 1514 0
Mg0/RP1/CPU0/0 down down ARPA 1514 0
Conditions:
Performing ISSU for a smu installation. Upgrade is unknown at this point but we can assume it will apply as well
Workaround:
you have to retstart esd process on location all from calvados
!admin
process restart esd location 0/RP0
process restart esd location 0/RP1
process restart esd location 0/0
process restart esd location 0/1
process restart esd location 0/2
process restart esd location 0/3
process restart esd location 0/4
process restart esd location 0/5
process restart esd location 0/6
process restart esd location 0/7
Further Problem Description:
|
|
Last Modified: | 03-NOV-2015 |
|
Known Affected Releases: | 5.2.4.BASE |
|
Known Fixed Releases: * | 5.2.5.29i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw56610 | Title: | sysdb_srv_local crash at chk_shmheap_map_index_addr |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: * | Symptom:
sysdb_srv_local process crash on LC.
Local slot running configuration is lost.
Conditions:
SMU install:
admin install deactivate disk0:hfr-px-5.1.4.CSCut37872-1.0.0
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 14-NOV-2015 |
|
Known Affected Releases: | 5.1.3.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv31661 | Title: | CRS-X LC QoS Ref_rate for priority class is slice bw instead of intf. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
The QoS Config commit will fail with an error described earlier whereby a high queue-limit value if applied to member's of a bundle within the same slice of the CRS-X LC will overflow the 32 bit value since the reference_rate calculated is the slice bw instead of Per Member BW.
Conditions:
100G bundle member's residing on the same slice & high queue-limit configured in a priority class.
Workaround:
Reduce the value of the queue-limit given that the max buffering that can be done @200G is ~30ms
Further Problem Description:
|
|
Last Modified: | 01-DEC-2015 |
|
Known Affected Releases: | 5.1.3.CE |
|
Known Fixed Releases: * | 5.2.5.35i.BASE, 5.3.2, 5.3.2.20i.BASE, 5.3.3.6i.BASE, 6.0.0.12i.BASE |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv35736 | Title: | join-prune-mtu value reset back to default after RP reload |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
After reload configured value for PIM "join-prune-mtu" for some interface is not re-applied and PIM interface get default MTU.
Conditions:
This was observed on asr9000 running 4.3.4 SP6, with PIM configuration and custom MTU setting using "join-prune-mtu" on some of PIM interfaces.
Workaround:
Once RP is reloaded and default MTU is set for PIM interface, to get back the custom MTU value you need to remove " join-prune-mtu" and re-configure it back.
Further Problem Description:
|
|
Last Modified: | 01-DEC-2015 |
|
Known Affected Releases: | 4.3.1.MCAST, 4.3.4.BASE |
|
Known Fixed Releases: * | 5.2.5.35i.MCAST, 5.3.2, 5.3.2.18i.MCAST, 6.0.0.11i.MCAST |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw73130 | Title: | multiple process blocked on mrib afetr LC going down |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
MRIB is in a tight loop, not processing messages or show commands
Conditions:
This can happen if any of the following features are present.
AMT forwarding
PW-HE multicast
MVPN/GTM with Ingress-Replication
In the above cases, we need to have forwarding over Bundle interfaces. If a bundle-member is deleted (say, the LC is OIR'd), then we May run into this blockage.
Workaround:
None
Further Problem Description:
Restarting MRIB/MRIB6 processes should recover the issue.
|
|
Last Modified: | 01-DEC-2015 |
|
Known Affected Releases: | 4.3.1.MCAST, 5.3.3.MCAST |
|
Known Fixed Releases: * | 5.2.5.35i.MCAST, 5.3.3.15i.MCAST, 6.0.0.20i.MCAST, 6.1.0.3i.MCAST |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut81907 | Title: | Autorp RP address for the group 224.0.0.4 is not properly learned |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Deleted RP mappings announced by Auto-RP MA
Conditions:
Unconfig and config of autoharp MA and deleted RP mappings exist during unconfig.
Workaround:
unconfig auto-RP MA when all RP mappings have expired.
Further Problem Description:
|
|
Last Modified: | 01-DEC-2015 |
|
Known Affected Releases: | 5.2.2.MCAST, 5.3.1.MCAST |
|
Known Fixed Releases: * | 5.2.5.35i.MCAST, 5.3.2, 5.3.2.8i.MCAST, 6.0.0.5i.MCAST |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu15259 | Title: | "show mrib mpls forward summary" goes into infinite loop |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
"show mrib mpls forwarding summary" is going into an infinite loop and never returns to the CLI prompt
Conditions:
mLDP, P2MP-TE or IR is configured. LMRIB has more than 256 P2MP Labels (shown in "show mrib mpls forwarding").
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 01-DEC-2015 |
|
Known Affected Releases: | 5.1.3.MCAST, 5.2.0.MCAST, 5.3.2.BASE |
|
Known Fixed Releases: * | 5.2.5.35i.MCAST, 5.3.1.MCAST, 5.3.2.7i.MCAST, 5.3.2.7i.MPLS, 6.0.0.5i.MCAST, 6.0.0.5i.MPLS |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw37957 | Title: | CISCO-IETF-MSDP-MIB returns incorrect values |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
asr9000 does not return correct values for snmpwalk from CISCO-IETF-MSDP-MIB. E.g. MSDP peers' status always returns as 'listen'
Conditions:
seen on 9922 running 5.3.1
Workaround:
none known at this time
Further Problem Description:
|
|
Last Modified: | 01-DEC-2015 |
|
Known Affected Releases: | 5.1.1.MCAST, 5.3.1.MCAST |
|
Known Fixed Releases: * | 5.2.5.35i.MCAST, 5.3.3.16i.MCAST, 6.0.0.17i.MCAST |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv11184 | Title: | PIM S,G join not sent when PIM neighbor IP changes |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
PIM S,G joins may not be sent to the PIM neighbor
Conditions:
The problem may be observed when the PIM neighbor IP address changes
Workaround:
Reducing the PIM hello timers may help reduce the impact of this particular problem
Further Problem Description:
|
|
Last Modified: | 01-DEC-2015 |
|
Known Affected Releases: | 4.3.4.CE |
|
Known Fixed Releases: * | 5.2.5.35i.MCAST, 5.3.2, 5.3.2.18i.MCAST, 5.3.3.3i.MCAST, 6.0.0.11i.MCAST |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw96402 | Title: | 'show l2route evpn mac all' output incorrect in show tech l2rib |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
'show l2route evpn mac all' output incorrect in show tech l2rib
Conditions:
Issue 'show tech l2rib' from the CLI.
Workaround:
In addition to 'sh tech l2rib', issue the command 'show l2route evpn mac all'.
Further Problem Description:
|
|
Last Modified: | 21-NOV-2015 |
|
Known Affected Releases: * | 6.1.1.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux07401 | Title: | srte tunnel primary/standby LSP using same egress |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
srte tunnel explicit path protection primary/standby LSP using same egress
Conditions:
srte tunnel explicit path protection base on node-sid, happens after protection trigger
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 24-NOV-2015 |
|
Known Affected Releases: | 6.1.1.MPLS |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv68895 | Title: | NAT44 traffic drops seen as output drops CGSE+ card 6.0 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Conditions:
Pass traffic to the router at high rate and then reload the router. After the router reload, the CGN traffic flow reduces.
Workaround:
Reload the CGSE+ line card and the traffic flow resumes.
Further Problem Description:
This is intermittent issue, and not seen on all router reloads.
|
|
Last Modified: | 25-NOV-2015 |
|
Known Affected Releases: | 6.0.0.FWDG |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw97470 | Title: | I-PMSI & Leaf AD still sent with color after unconfig "segmented color" |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Segmented MVPN:
I-PMSI & Leaf AD are still sent with color after unconfig "segmented color"
Conditions:
IOS XR 5.3.2
Workaround:
No
Further Problem Description:
|
|
Last Modified: | 26-NOV-2015 |
|
Known Affected Releases: | 5.2.2.MCAST, 6.0.0.BASE |
|
Known Fixed Releases: | 5.3.3.20i.MCAST, 6.1.0.6i.MCAST |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun86803 | Title: | BGP neighbor accepted/PfxRcd couters incorrect after soft reset in |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
PfxRcd counter shows a wrong value of accepted prefixes from a neighbor.
Conditions:
Updates coming from the neighbor during 'clear bgp ipv4 unicast * soft in' execution.
Soft-reconfiguration inbound is configured and the soft reset is performed without using the route refresh capability.
Workaround:
Soft reset the affected neighbor again, when there's no updates coming.
Further Problem Description:
|
|
Last Modified: | 13-NOV-2015 |
|
Known Affected Releases: | 4.1.1.BASE, 5.2.2.ROUT |
|
Known Fixed Releases: * | 6.1.0.7i.ROUT |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtf41781 | Title: | %ROUTING-IPV4_PIM-3-IDB_INIT : Failed to insert IDB in name tree : En6tu |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Observed console message
pim6[372]: %ROUTING-IPV4_PIM-3-IDB_INIT : Failed to insert IDB in name tree : En6tunnel227
Conditions:
This message can be seen when there are multiple RP mappings (across All VRFs). If the RP mappings are flapping or flapped rapidly, this message may occur. In this case, it was seen after removal and re-addition of one vrf from multicast-routing config and then performing an RP FO.
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 01-DEC-2015 |
|
Known Affected Releases: | 3.9.1.ROUT |
|
Known Fixed Releases: * | 5.2.5.35i.MCAST, 6.0.0.11i.MCAST |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq27836 | Title: | default-originate route-policy doesn't work with route-policy out |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
The BGP attributes of a default route received from the DUT may not be according to the default-originate route-policy configured on DUT.
Conditions:
On the DUT, the default-originate route-policy and the outbound route-policy for the same neighbor are configured in the same commit.
Workaround:
Use different commits for outbound route-policy and default-originate route-policy.
Further Problem Description:
|
|
Last Modified: | 03-NOV-2015 |
|
Known Affected Releases: | 4.3.2.BASE, 4.3.4.BASE, 5.2.0.BASE |
|
Known Fixed Releases: * | 5.2.3.13i.ROUT, 5.2.4.1i.ROUT, 5.3.0.7i.ROUT |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui33301 | Title: | show ospf trace cmd gives broken pipe error if quit in the middle |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
Only observed this problem with show ospf trace pipe to "be"; did not see problem with show bgp trace ...
RP/0/RSP1/CPU0:RouterA#sh ospf trace all | be "Jun 20 17"
1113 Jun 20 17:05:57.155 ospf_build_rtr_lsa: area 0.0.0.0 rtrid 1.1.1.1 seq 0x80000120 vrfid 0x60000000
...
1135 Jun 20 18:18:00.350 ospf_log_adj_chg: Flooding stats: LSA-Req sent: 0 pkts 0 LSAs, LSA-Upd Rcv: 0 pkts 0 LSAs
bgerror failed to handle background error.
Original error: error writing "stdout": broken pipe
Error in bgerror: invalid command name "bgerror"
can't wait for variable "done": would wait forever
while executing
"vwait done"
("for" body line 7)
invoked from within
"for {set i 0} {$i < $count} {incr i} {
set pipe($i) [open "|ospf_show $cmd -y $buffer($i)"]
fconfigure $pipe($i) -buffering line
fconfig..."
(file "/pkg/bin/ospf_get_all_traces" line 46
Conditions:
Hitting Cntrl-C when the display of "show ospf trace all" is in progress, triggers error.
This is functionally non-impacting
Workaround:
Non-impacting error.
More Info:
|
|
Last Modified: | 17-NOV-2015 |
|
Known Affected Releases: | 5.1.0.ROUT |
|
Known Fixed Releases: * | 5.1.0.19i.ROUT, 5.1.0.20i.ROUT |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux01279 | Title: | NCS4K VZ :No active indication on NCS4K software dwnld progress in CTC |
|
Status: | Open |
|
Severity: * | 6 Enhancement |
Description: | Symptom:
User tries to install add packages to the node, But no progress bar to indicate the progress.
Conditions:
This is when the install add operation is in progress.
Workaround:
User can check the Install logs on CTC>installation pane to verify the status of the operation.
Further Problem Description:
Expected Fix: In the next release.
Reproducibility: 100%
|
|
Last Modified: | 14-NOV-2015 |
|
Known Affected Releases: | 5.2.41.BASE |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuf91134 | Title: | ipv4_acl_mgr blocked on gsp process when using log keyword |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: |
Symptom:
An ACL is applied onto an interface. Operator attempts to modify
one or more ACEs of said ACL. The commit fails with the error
message that one or more ACL consumers has not responded to
a verification request. Output of "show process blocked" on RP
indicates that "ipv4_acl_mgr" (if it is IPv4 ACL) or "ipv6_acl_daemon"
(if it is IPv6 ACL) is blocked on process "gsp". The configuration
is rejected as a result and the ACE change does not take effect.
Conditions:
The ACL must have one or more ACEs with "log" keyword configured.
For an extended period of time, a flow of traffic is hitting said
ACE(s), causing netio to generate an exceedingly large number of
log requests. Without the "log" keyword or without traffic,
this issue would not occur.
Workaround:
Remove "log" keyword from the ACE(s)
Further Problem Description:
Without "log" keyword, the operator still have the ability
to check hit count of a particular (set of) ACE(s) by
executing "show access-list ipv4/ipv6 hardware ingress/egress location "
|
|
Last Modified: | 05-NOV-2015 |
|
Known Affected Releases: | 4.2.3.BASE, 4.2.31.K9SEC |
|
Known Fixed Releases: * | none |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur08199 | Title: | CGSE/CGSE-PLUS: service attach vulnerability |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
The following Cisco products
CRS-CGSE-PLIM
CRS-CGSE-PLUS
include a version of Bash that may be affected by the vulnerabilities identified by the following Common Vulnerability and Exposures (CVE) IDs:
CVE-2014-6271
CVE-2014-6277
CVE-2014-6278
CVE-2014-7169
CVE-2014-7186
CVE-2014-7187
Cisco has analyzed this vulnerability and concluded that while the previously listed products may run a vulnerable version of Bash, there are no exploitation vectors present - therefore, those products are not impacted.
Conditions:
Not applicable
Workaround:
Not applicable
Further Problem Description:
Additional details about those vulnerabilities can be found at http://cve.mitre.org/cve/cve.html
PSIRT Evaluation:
The Cisco PSIRT has evaluated those issues and they do not meet the criteria for PSIRT ownership or involvement. Those issues will be addressed via normal resolution channels.
If you believe that there is new information that would cause a change in the severity of those issues, 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/web/about/security/psirt/security_vulnerability_policy.html
|
|
Last Modified: | 07-NOV-2015 |
|
Known Affected Releases: | 5.3.0.BASE |
|
Known Fixed Releases: * | none |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw74242 | Title: | BMP: IOS XR queues messages for a down server causing memory to run out |
|
Status: | Open |
|
Severity: * | 6 Enhancement |
Description: | Symptom:
BMP messages are enqueued for BMP server that is technically down.
RP/0/RSP0/CPU0:cirl-sjc16-a9k1#show bgp bmp server 1 | i pending Thu
Jun 11 06:36:58.725 UTC Messages pending: 4385 Messages pending:
7313338 Messages pending: 23078
Conditions:
ASR9K running XR 5.3.1
We only see this with large peering, such as in one case with 330 peers with over 6,500,000 Adj-In-Pre-RIB prefixes.
Workaround:
This workaround is not a fix, it helps to slow/prevent the problem.
bmp server
! Wait at least 2 minutes before reconnecting - this will prevent flapping causing refreshes.
! This is also the window to group refreshes for multiple BMP servers that transition, so
! one refresh covers more than one bmp server.
! I would recommend 5 minutes because of the number of peers the RR has
initial-delay 300
! This delays the refreshes. Recommend setting this to a value that would be high enough to ensure that
! a previous refresh completes before starting another. Based on connect delay being 5 minutes and this
! being 15 minutes, a flap should not trigger a refresh till 20 minutes or later. This is enough time
! to ensure previous refreshes are complete.
initial-refresh delay 900 spread
Further Problem Description:
|
|
Last Modified: | 21-NOV-2015 |
|
Known Affected Releases: | 5.2.3.ROUT |
|
Known Fixed Releases: | |
|
|
| |
2015 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论