Hi Rodney, Thanks for taking a look and researching this one for me.
On 3/08/2007 9:42 PM, Rodney Dunn wrote: > 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'. 370flinders-r200.32-pe01#show ip route summary IP routing table name is Default-IP-Routing-Table(0) Route Source Networks Subnets Overhead Memory (bytes) connected 0 58 4228 8816 static 1 79 5808 14200 eigrp 9176 0 0 0 0 bgp 9176 42568 8972 6430852 7838160 External: 51540 Internal: 0 Local: 0 ospf 9176 24 573 38336 94824 Intra-area: 8 Inter-area: 5 External-1: 583 External-2: 1 NSSA External-1: 0 NSSA External-2: 0 internal 92 107824 Total 42685 9682 6479224 8063824 370flinders-r200.32-pe01# There's a full BGP internet feed coming in but it's filtered to the 42000 routes as seen above (I don't know why, it's an ISP network we have recently taken over management of so there are still some unanswered questions). The 7200 has 1G of DRAM. >> 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? LDP. There are two routers attached to the far end peer which are running TDP still but these are not directly connected to this router I sent the logs from. I am intending to change these over to LDP soon so that the whole network is just using LDP throughout and not a mixture of the two. > What is the peer and code? It is also a 7200 NPE-G1 with 12.3(19). There are three core routers - all the same - linked via ATM in a triangle/meshed MPLS topology. The other two seemed to be OK. > 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. One of the support guys said something about the router dropping it's CEF table. Unfortunately I didn't check that at the time, my concern was more on why so much CPU was being burnt up on that one process. > 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? See above. > Rodney I've also just noticed that the 3550 behind this router and another one connected to that via an ethernet link to that switch also is pretty sick, and both nearly ran out of memory today. Both have logged a lot of messages about "Aug 3 11:51:39: %FIB-2-FIBDOWN: CEF has been disabled due to a low memory condition. It can be re-enabled by configuring "ip cef [distributed]" 'show ip cef' on these switches shows that CEF is now not running. My thinking is that this is a rather big problem in itself (!) and will try get these switches reloaded later tonight. The reason I am bringing this up is that I'm considering if the problem may not have been directly caused by this 7200, but may be caused by some other external factor. The only thing which strikes me as a possibility is that someone or something flooded/redistributed an entire BGP feed into OSPF. Does that sound like a possibility? Still doesn't answer quite why the 7200 was chewing so much cpu though <scratches head>. Reuben _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
