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 _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/