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

[Rodney Dunn]

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