[c-nsp] 12.2(25)S5 shows 190000 BGP prefixes?

[Rodney Dunn]

CSCeh16989
Externally found severe defect: Resolved (R)
BGP number of attributes is constantly increasing, consuming more memory

sounds like a good possiblity.

You could try setting the advertisement interval down to 0 and
see if we can get all the peers to converge fast enough to
clean up all the networks that don't have any available paths.

That's what I can tell from a guick glance at the bug.

Rodney



> Re Bruce,
> 
> On Wed, Aug 31, 2005 at 05:44:05PM -0700, Bruce Pinsky wrote:
> > Andre Beck wrote:
> > > 
> > > I just found that a 72xx running 12.2(25)S5 shows an increased number
> > > of active BGP prefixes. Compared to the other iBGP mesh members, the
> > > number from "sh ip bgp summary" is way too large:
> > > 
> > > ----------------------------------------------------------------------------
> > > BGP router identifier 212.111.224.8, local AS number 15372
> > > BGP table version is 12935683, main routing table version 12935683
> > > 190844 network entries using 21565372 bytes of memory
> > > ^^^^^^^^^^^^^^^^^^^^^^
> > > 302705 path entries using 15740660 bytes of memory
> > > 57469/31045 BGP path/bestpath attribute entries using 6206652 bytes of memory
> > > 51832 BGP AS-PATH entries using 1384316 bytes of memory
> > > 1009 BGP community entries using 39244 bytes of memory
> > > 0 BGP route-map cache entries using 0 bytes of memory
> > > 42054 BGP filter-list cache entries using 504648 bytes of memory
> > > BGP using 45440892 total bytes of memory
> > > BGP activity 190845/0 prefixes, 4608899/4306191 paths, scan interval 60 secs
> > >              ^^^^^^
> > > Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
> > > 212.111.224.2   4 15372   84994 3335308 12935678    0    0 8w3d            2
> > > 212.111.224.7   4 15372 4116825 3335309 12935678    0    0 8w3d       135105
> > > 213.148.131.181 4 20676 6778241  169985 12935683    1    0 8w3d       167596
> > > ----------------------------------------------------------------------------
> > > 
> > > Using "sh ip route summary", the real amount of BGP routes comes out
> > > at a more reasonable count:
> > > 
> > > Route Source    Networks    Subnets     Overhead    Memory (bytes)
> > > bgp 15372       110058      59849       10874048    26063524
> > >   External: 127676 Internal: 42231 Local: 0
> > 
> > Info from "show ip route summary" is displaying the number of BGP routes in
> > the forwarding RIB, i.e. installed in the routing table.  The output of
> > "show ip bgp summary" is showing you the count of the number of network
> > entries across all of your BGP peers in the BGP adacency RIB structures.
> > That would explain the difference between the counts.
> 
> Yep, but up to now, the value in the third line of "sh ip bgp summary" has
> always been a somewhat reliable count of the total number of unique BGP
> prefixes the box is getting from peers. This all of a sudden changed with
> 12.2(25)S it seems.
> 
> > What versions are running on your other BGP routers that you included?  I'd
> > be curious to do a quick test to see if I can duplicate your results.
> 
> The other box with eBGP runs 12.0(21)S and the pure iBGP one is at
> 12.2(18)S (with some digit after the S in both cases, of course). The
> router in question showed a number more similar to the other boxes before
> upgrade to 12.2(25)S, so it's not just a topology glitch. It's also
> interesting that this box didn't come up with this number directly after
> boot. At this time (and the following days), the prefix count seemed well
> in the sane area. That "off by 20000 prefixes" situation developed slowly
> and constantly over a month or so, and it seems it's still growing - I'm
> at 191424 now. Not that it actually matters as long as memory is plenty
> and per-peer prefix limits are not triggered to tear down sessions. But
> it hoses my MRTG graphing...
>  
> > I know there were changes in 12.2(25)S in several areas of code that
> > contribute to the output of "show ip bgp summary".  I suppose there could
> > be a bug that was introduced as a result of some of those changes.
> 
> Either that or the meaning of this value has changed to something I don't
> understand. It doesn't seem to be a combination of individual peer contri-
> butions and certainly isn't path cumulation (the box got some 300k paths).
> So a bug seems likely.
> 
> > I'd probably open a case at this point.
> 
> It's not that mission critical here, just another counter fun issue. But
> if you can replicate it and want to throw it at TAC, all the better ;)
> 
> Thanks,
> Andre.
> -- 
>                   The _S_anta _C_laus _O_peration
>   or "how to turn a complete illusion into a neverending money source"
> 
> -> Andre Beck    +++ ABP-RIPE +++    IBH Prof. Dr. Horn GmbH, Dresden <-
> _______________________________________________
> 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/