[c-nsp] IPC-5-WATERMARK messages - FAST.control.RIL?

[Rodney Dunn]

You can open a TAC case and have them attach your case
to;

CSCeh62781
Internally found moderate defect: Resolved (R)
%IPC-5-WATERMARK FAST.control.RIL(2070000.E) seat 2070000

(I'm updating it to be customer viewable now).

It's really just a suboptimal implementation meant to catch
a stuck IPC queue. It doesn't handle burst well. That is
fixed in the above ddts.

The trigger for you is most likely the route churn. 
The recreate in testing here was flapping a thousand VC's
that triggered the extra IPC traffic.

Rodney



On Fri, Jun 03, 2005 at 02:16:32PM +1000, Andrew Fort wrote:
> With ws-sup720 cards (original flavour), we occasionally get syslog 
> about high watermarks on IPC queues across multiple switches within 
> minutes of each other.
> 
> The switches exhibiting this have a full table, and are RRs for about 5 
> other similar boxes, each (which get a filtered table (~12k prefixes), 
> and don't exhibit this message).
> 
> Thus, I'm guessing there's some churn and the IPC messages for DCEF are 
> backing up..
> 
> The slots in question are WS-X6816 w/DFC-3A.
> 
> w/12.2(18)SXD3
> 3960: 000602: May 17 04:55:39.442 AEST: %IPC-5-WATERMARK: 801 messages 
> pending in xmt for the port Slot 8: FAST.control.RIL(2080000.C) seat 2080000
> 
> w/12.2(17)SXA
> 589210: 035375: May 14 04:56:21.304 AEST: %IPC-5-WATERMARK: 801 messages 
> pending in xmt for the port (2080000.C) seat 2080000
> 
> Nice to get a message for the dereference in the newer code, but what is 
> "FAST.control.RIL"?
> 
> It's always '801' messages (is the queue depth for this type of message 
> effectively 800?), and the port is always (2010000.C) or (2080000.C).
> 
> e.g.
> 
> 1481: 000356: Jun 3 12:57:55.214 AEST: %IPC-5-WATERMARK: 801 messages 
> pending in xmt for the port Slot 1: FAST.control.RIL(2010000.C) seat 2010000
> 1145: 000203: Jun 3 12:56:55.989 AEST: %IPC-5-WATERMARK: 801 messages 
> pending in xmt for the port Slot 8: FAST.control.RIL(2080000.C) seat 2080000
> 
> This isn't associated with any network disruption, but is it a sign of 
> future bad ju-ju or some impending resource limit? (considering these 
> are PFC-3A/DFC-3A combos, after all).
> 
> Cheers,
> -Andrew
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/