[c-nsp] MPLS "Tag Control" process - what does this do?
Reuben Farrelly
reuben-cisco-nsp at reub.net
Fri Aug 3 06:37:31 EDT 2007
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
More information about the cisco-nsp
mailing list