[c-nsp] SUP720 TFIB scan not completing

[Rodney Dunn]

On Wed, Jan 25, 2006 at 01:57:36AM +0100, Christian Bering wrote:
> Rodney (and Ian),
> 
> Thanks for your replies.
> 
> >You can try a 'sh ip cef events' and see if you see a /32 adjacency
> >entry constantly changing. That will cause us to run the TFIB scanner
> >which piggybacks on the CEF scanner.
> 
> I do see a few showing up repeatedly:
> 
> CEF table events (storage for 10000 events, 15578 events recorded)
> +00:00:00.000: [Internet] zyx.168.184.0/24      NBD modified
> [OK]
> +00:00:00.200:           xyz.17.206.3/32'00    ADJ (Vl488) update
> [OK]
> +00:00:00.448:           1xx.136.88.28/32'00   ADJ (Vl412) update
> [OK]
> +00:00:00.448:           1xx.136.88.28/32'00   ADJ (Vl412) incompl.
> [OK]
> +00:00:00.448:           1xx.136.88.28/32'00   ADJ (Vl412) update
> [OK]
> +00:00:00.448:           1xx.136.88.28/32'00   ADJ (Vl412) incompl.
> [OK]
> +00:00:00.448:           1xx.136.88.28/32'00   ADJ (Vl412) update
> [OK]
> +00:00:00.448:           1xx.136.88.28/32'00   ADJ (Vl412) incompl.
> [OK]
> +00:00:00.816: [Default] 127.0.0.51/32'00      Quash overriding adjfib
> [OK]
> +00:00:00.816:           1xx.136.88.28/32'00   ADJ (Vl412) incompl.
> [OK]
> +00:00:01.028:           192.168.1.19/32'00    ADJ (Vl20) update
> [OK]
> +00:00:01.456:           1xx.136.88.28/32'00   ADJ (Vl412) update
> [OK]
> +00:00:01.456:           1xx.136.88.28/32'00   ADJ (Vl412) incompl.
> [OK]
> +00:00:01.456:           1xx.136.88.28/32'00   ADJ (Vl412) update
> [OK]
> +00:00:01.456:           1xx.136.88.28/32'00   ADJ (Vl412) incompl.
> [OK]
> +00:00:01.456:           1xx.136.88.28/32'00   ADJ (Vl412) update
> [OK]
> +00:00:01.456:           1xx.136.88.28/32'00   ADJ (Vl412) incompl.
> [OK]
> +00:00:02.068:           192.168.1.19/32'00    ADJ (Vl20) update
> [OK]
> +00:00:02.068:           192.168.1.19/32'00    ADJ (Vl20) update
> [OK]
> +00:00:02.376:           xy.218.190.25/32'00   ADJ (Vl321) update
> [OK]
> +00:00:02.480:           1xx.136.88.28/32'00   ADJ (Vl412) update
> [OK]
> +00:00:02.480:           1xx.136.88.28/32'00   ADJ (Vl412) incompl.
> [OK]
> +00:00:02.480:           1xx.136.88.28/32'00   ADJ (Vl412) update
> [OK]
> +00:00:02.480:           1xx.136.88.28/32'00   ADJ (Vl412) incompl.
> [OK]
> +00:00:02.480:           1xx.136.88.28/32'00   ADJ (Vl412) update
> [OK]
> +00:00:02.480:           1xx.136.88.28/32'00   ADJ (Vl412) incompl.
> [OK]
> [snip]
> +00:00:00.420:           1xx.136.95.4/32'00    ADJ (Vl306) update
> [OK]
> +00:00:00.420:           1xx.136.95.4/32'00    ADJ (Vl306) update
> [OK]
> +00:00:00.420:           1xx.136.95.4/32'00    ADJ (Vl306) update
> [OK]
> +00:00:00.420:           1xx.136.95.4/32'00    ADJ (Vl306) update
> [OK]
> +00:00:00.420:           192.168.1.19/32'00    ADJ (Vl20) update
> [OK]
> +00:00:00.420:           10.6.10.121/32'00     ADJ (Vl417) update
> [OK]
> +00:00:00.780:           10.6.10.102/32'00     ADJ (Vl417) update
> [OK]
> +00:00:00.988:           10.6.10.108/32'00     ADJ (Vl417) update
> [OK]
> +00:00:01.200:           172.17.1.20/32'00     ADJ (Vl410) update
> [OK]
> +00:00:01.416:           1xx.136.90.2/32'00    ADJ (Vl308) update
> [OK]
> +00:00:01.416:           192.168.1.19/32'00    ADJ (Vl20) update
> [OK]
> +00:00:01.416:           192.168.1.19/32'00    ADJ (Vl20) update
> [OK]
> +00:00:01.416:           1xx.136.95.4/32'00    ADJ (Vl306) update
> [OK]
> +00:00:01.416:           1xx.136.95.4/32'00    ADJ (Vl306) update
> [OK]
> +00:00:01.420:           1xx.136.95.4/32'00    ADJ (Vl306) update
> [OK]
> +00:00:01.420:           1xx.136.95.4/32'00    ADJ (Vl306) update
> [OK]
> 
> Especially 1xx.136.88.28/32 in Vl412 and 1xx.136.95.4/32 in Vl306 have
> many occurances of the above kind.

It's only relevant if those VLANS have MPLS enabled on them. Otherwise
it's not the bug below.

> 
> >We improved this with:
> 
> >CSCsb16512
> >Externally found moderate defect: Resolved (R)
> >High CPU in CEF Process and CEF scanner due to prefix reresolve
> 
> As I read it, it shouldn't be an issue in SXE? 

It is. It only got fixed/changed in 12.2(18)SXF2.

> 
> >You can correlate 'sh ip cef events' to a debug mpls lfib cef
> >and try to figure out if a mac is constantly changing on one of the
> >mpls enabled interfaces.
> 
> Tried that, but neither show much about MAC addresses. Can the Traceback
> output can be interpreted in some way as a MAC address?
> 
> Jan 25 01:48:45.099 MET: %TFIB-7-SCANSABORTED: TFIB scan not completing.
> MAC string updated.
> -Traceback= 41EB455C 41EB48DC 405233CC 405240F0 40699230 406998BC
> 4069A4E0 4008AB54

Not really. And from what I remember the debug mpls lfib cef didn't show
the mac either it just showed that the tfib scanner was running due to a
mac change. Then you go back to the cef event log to try and figure out
which mac is changing.

> 
> Thanks,
> Christian