[c-nsp] 7304-NSE100, 12.2(28), duplicated BGP paths
Bruce Pinsky
bep at whack.org
Mon Aug 21 18:58:46 EDT 2006
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jakob Borg wrote:
> Hi all,
>
> We have an issue I wonder if any of you recognize. It's hitting us on
> peering routers (7304) running 12.2(27)SBC3 through 12.2(28)SB1 at least and
> has to do with BGP paths.
>
> These routers receive one or more full feeds and a number of peering feeds.
> The problem is that BGP memory usage is continously increasing, until a
> reload is necessary once every one or two months. The memory seems to be
> allocated in the form of BGP paths that shouldn't be duplicated; a quick
> "show ip bgp paths" and scroll down shows:
>
> mlmo-krvg-pr0#sh ip bgp paths
> Address Hash Refcount Metric Path
> ...
> 0x567708E8 1 1 0 16150 12989 19151 23342 30686 2013 i
> 0x560A0B28 1 1 0 16150 12989 19151 23342 30686 2013 i
> 0x560A15D0 1 1 0 16150 12989 19151 23342 30686 2013 i
> 0x560A4D84 1 1 0 16150 12989 19151 23342 30686 2013 i
> 0x560A0C9C 1 1 0 16150 12989 19151 23342 30686 2013 i
> 0x560A3A24 1 1 0 16150 12989 19151 23342 30686 2013 i
> ...
>
> which to my mind should be just one line with a refcount of 6. All external
> connections are configured to set MED and local preference, to avoid any
> possible reason there would be multiple similar paths. A summary shows the
> path count slowly increasing, from somewhere around 200K to start with to
> over 750K now:
>
> mlmo-krvg-pr0#sh ip bgp sum
> BGP router identifier 172.16.16.31, local AS number 15782
> BGP table version is 16071189, main routing table version 16071189
> 194477 network entries using 21975901 bytes of memory
> 572830 path entries using 29787160 bytes of memory
> --> 753729/35019 BGP path/bestpath attribute entries using 81402732 bytes of
> memory
> 20 BGP rrinfo entries using 480 bytes of memory
> 438821 BGP AS-PATH entries using 15757724 bytes of memory
> 6965 BGP community entries using 394456 bytes of memory
> 0 BGP route-map cache entries using 0 bytes of memory
> 0 BGP filter-list cache entries using 0 bytes of memory
> BGP using 149318453 total bytes of memory
> BGP activity 590692/396214 prefixes, 8390049/7817218 paths, scan interval
> 60 secs
>
> Any ideas why this is happening?
In a quick look, I didn't see any bugs that seem to fit the bill. What is
interesting to me is the hash on those paths. In a quick test, whenever a
path was referenced by a real prefix, the hash was > 1 like this:
R2#sh ip bgp paths
Address Hash Refcount Metric Path
0xB648F738 0 5 0 i
0xB648F6BC 1 6 0 i
0xB648F640 1536 9 0 1 i
Network Next Hop Metric LocPrf Weight Path
* 10.1.0.0/16 210.150.248.137 0 0 1 i
*> 210.150.248.68 0 0 1 i
* 10.2.0.0/16 210.150.248.137 0 0 1 i
*> 210.150.248.68 0 0 1 i
* 10.3.0.0/16 210.150.248.137 0 0 1 i
*> 210.150.248.68 0 0 1 i
*> 172.16.0.0 0.0.0.0 0 32768 i
*> 172.17.0.0 0.0.0.0 0 32768 i
*> 172.18.0.0 0.0.0.0 0 32768 i
When I tweaked the metric for one of the paths, I got this:
R2#sh ip bgp paths
Address Hash Refcount Metric Path
0xB648F738 0 5 0 i
0xB648F6BC 1 6 0 i
0xB648F548 1212 3 700 1 i
0xB648F640 1536 7 0 1 i
Network Next Hop Metric LocPrf Weight Path
* 10.1.0.0/16 210.150.248.137 700 0 1 i
*> 210.150.248.68 0 0 1 i
* 10.2.0.0/16 210.150.248.137 700 0 1 i
*> 210.150.248.68 0 0 1 i
* 10.3.0.0/16 210.150.248.137 700 0 1 i
*> 210.150.248.68 0 0 1 i
*> 172.16.0.0 0.0.0.0 0 32768 i
*> 172.17.0.0 0.0.0.0 0 32768 i
*> 172.18.0.0 0.0.0.0 0 32768 i
and when I tweaked it for both, I got this:
R2#sh ip bgp paths
Address Hash Refcount Metric Path
0xB648F738 0 5 0 i
0xB648F6BC 1 6 0 i
0xB648F548 1212 9 700 1 i
0xB648F640 1536 1 0 1 i
Network Next Hop Metric LocPrf Weight Path
* 10.1.0.0/16 210.150.248.137 700 0 1 i
*> 210.150.248.68 700 0 1 i
* 10.2.0.0/16 210.150.248.137 700 0 1 i
*> 210.150.248.68 700 0 1 i
* 10.3.0.0/16 210.150.248.137 700 0 1 i
*> 210.150.248.68 700 0 1 i
*> 172.16.0.0 0.0.0.0 0 32768 i
*> 172.17.0.0 0.0.0.0 0 32768 i
*> 172.18.0.0 0.0.0.0 0 32768 i
Note that the non-tweaked path still has a ref count of 1 even though there
are no prefixes that are directly using it.
Similar results when I tweak local pref:
R2#sh ip bgp paths
Address Hash Refcount Metric Path
0xB648F738 0 5 0 i
0xB648F6BC 1 6 0 i
0xB648F548 1536 6 0 1 i
0xB648F640 1536 4 0 1 i
Network Next Hop Metric LocPrf Weight Path
* 10.1.0.0/16 210.150.248.137 0 0 1 i
*> 210.150.248.68 0 500 0 1 i
* 10.2.0.0/16 210.150.248.137 0 0 1 i
*> 210.150.248.68 0 500 0 1 i
* 10.3.0.0/16 210.150.248.137 0 0 1 i
*> 210.150.248.68 0 500 0 1 i
*> 172.16.0.0 0.0.0.0 0 32768 i
*> 172.17.0.0 0.0.0.0 0 32768 i
*> 172.18.0.0 0.0.0.0 0 32768 i
R2#sh ip bgp paths
Address Hash Refcount Metric Path
0xB648F738 0 5 0 i
0xB648F6BC 1 6 0 i
0xB648F548 1536 9 0 1 i
0xB648F640 1536 1 0 1 i
Network Next Hop Metric LocPrf Weight Path
* 10.1.0.0/16 210.150.248.137 0 500 0 1 i
*> 210.150.248.68 0 500 0 1 i
* 10.2.0.0/16 210.150.248.137 0 500 0 1 i
*> 210.150.248.68 0 500 0 1 i
* 10.3.0.0/16 210.150.248.137 0 500 0 1 i
*> 210.150.248.68 0 500 0 1 i
*> 172.16.0.0 0.0.0.0 0 32768 i
*> 172.17.0.0 0.0.0.0 0 32768 i
*> 172.18.0.0 0.0.0.0 0 32768 i
So, I'm curious what your path table looks like immediately after restart.
It could be something related to failure to dereference the non-modified
path when the metric and local pref are set. If that happened at every
withdraw/update, I could see how that could consume all the memory.
Just speculation on my part and I would suggest opening a case to track
this down further.
- --
=========
bep
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFE6jqmE1XcgMgrtyYRAg/xAKDmVbcAXUD7XbPjKHYRbg3wxjnPYACfSw3n
3aVwrgtnYv2SSzbHW/3SQTI=
=ZqnB
-----END PGP SIGNATURE-----
More information about the cisco-nsp
mailing list