I'm pretty sure Reuben that it's controlling the allocation of labels to prefixes. I'd need to dig a bit more on it.
How many routes do you have in the global routing table? 'sh ip route summ'. > 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 Are you running TDP or LDP? What is the peer and code? I looked around a bit to try and understand that messge. Seems it has to do with getting a label for a prefix we don't have. Problem Description: ==================== Problem: LDP does not withdraw label before announcing a new label for the same FEC. Solution: To fix this problem a new config command is introduced: [no] mpls ldp neighbor A.B.C.D implicit-withdraw-label default Behavior: It will follow the LDP standard i.e. LDP will withdraw previously advertised label before advertising a new label for a FEC. When "mpls ldp neighbor A.B.C.D implicit-withdraw-label" is configured LDP will not withdraw the previous label before advertising a new label. default behavior is changed. Now when there is a need to change label for a FEC: 1. LDP will send a Label withdraw and then after receiving Label Release, it will advertise the new binding with a Label Mapping. If after sending Label Withdraw, no Label Release is received from a peer(s) and sufficient time (Currently set to 5 minutes) has passed, then LDP will assume that peer(s) is not capable of sending a label release and it will send Label Mapping to the peer. 2. LDP maintains a list of previous labels for which a Label Release is awaited from any peer. A new Label Mapping for a FEC is not announced to a peer if a Label release for the same FEC is pending from the peer. that was changes that went in under: CSCdv74248 Externally found enhancement defect: Resolved (R) LDP session drop after receiving a new label for the same FEC that you would have in 12.3(19). But what about the peering router? Rodney On Fri, Aug 03, 2007 at 08:37:31PM +1000, Reuben Farrelly wrote: > 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/ _______________________________________________ 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/