[c-nsp] MPLS "Tag Control" process - what does this do?

[Reuben Farrelly]

Hi,

We had a rather mysterious and puzzling event occur on one of our 7200s today, 
running 12.3(19) and MPLS on an NPE-G1.

What happened was that a normal IPv4 BGP peer was added to the config for a new 
iBGP session, and at or nearly the same time the router started chewing up 
massive amounts of CPU, things like SNMP stopped working, radius authentication 
started timing out and denying logins, although the router was still alive - and 
(slowly) accepting telnet connections to it but subsequently failing 
authentication on them.

A show proc cpu sorted looked like this (first few lines)

PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
  164     4433204   8742181        507 63.44% 60.27% 40.98%   0 Tag Control
  188     4424124  12026434        367  0.95%  0.80%  0.64%   0 LDP
   52   383431108 451130068        849  0.87%  0.81%  1.59%   0 IP Input
  176     1067504  37471947         28  0.31%  0.18%  0.11%   0 IP-EIGRP: PDM


Quite a few messages like this were logged to the console during the problem 
period and for s short while after it came right:

Aug  3 04:42:37.479: %TIB-3-REMOTETAG: 150.82.0.0/255.255.0.0, peer 
61.84.96.254:0; tag 53643; Failure with LDP Label Release; prefix not in TIB
Aug  3 04:43:08.171: %TIB-3-REMOTETAG: 192.232.71.0/255.255.255.0, peer 
61.84.96.254:0; tag 54898; Failure with LDP Label Release; prefix not in TIB

At about that same time a 3550 switch in another part of the network suffered a 
hardware failure/reload.  So I'm not entirely sure what caused the event - there 
was another 7200 behind the broken switch but it wasn't a major path for any 
sort of traffic pattern to drastically shift.  It may well be unrelated.

Traffic volumes across the 2 ATM PVCs that this router services were 10-15M 
(only a 10M and a 8M PVC into it), so not extraordinarily high and certainly 
could not have gone past 18M even if both PVCs were running full.

After 15 or so mins the router came right and has been OK ever since.

Can anyone tell me what this "Tag Control" process does, and what sort of 
activity might cause it to burn so much CPU for such a length of time?  There 
doesn't seem to be a whole lot about it on CCO and it's a bit worrying when 
things like this happen and there is no real easily documented answer :-)

Thanks,
Reuben