[c-nsp] Route processor memory at 99% on 720-3bxl
Mack McBride
mack.mcbride at viawest.com
Wed Jun 22 13:07:42 EDT 2016
If BGP is holding that much memory I would verify 'soft-reconfiguration inbound' is not configured.
It stores the update messages and is not efficient at deleting them.
Then do a 'clear ip bgp *' to restart the process.
A reboot may be in order.
You may also want to put in Selective Route Download and rely on defaults for routes that are fairly
distant from you network wise. Or just prune your table if that is an option.
We are running the same code and not seeing that kind of memory usage on BGP router or IP RIB Update.
We have two larger iBGP tables for ipv4 and two ipv6 iBGP table of about the same size.
And two downstream customers with full BGP tables.
It is also possible there is some kind of memory leak.
These have previously been associated with 'inactive' bgp sessions.
Even ones that were admin down.
Our utilization of the BGP process:
PID TTY Allocated Freed Holding Getbufs Retbufs Process
641 0 1219766648 1120578988 396258488 0 0 BGP Router
0 0 174776148 11120 159003332 0 0 *Init*
380 0 230882752 145539804 62344120 0 0 IP RIB Update
Mack McBride | Senior Network Architect | ViaWest, Inc.
-----Original Message-----
From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of chiel
Sent: Tuesday, June 21, 2016 4:01 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Route processor memory at 99% on 720-3bxl
Hi,
We got a 6500 with a 720-3bxl running
s72033-advipservicesk9-mz.151-2.SY7.bin.
Devices is has to do some basic routing/switching with full BGP.
- 1x IPv4 full ebgp router with 585172 prefixes and a ibgp with 216827 prefixes.
- 1x IPv6 full ebgp with 28013 prefixes and ibgp with 30104 prefixes.
We have already relocated the CEF so tcam can can hold more ipv4 routes.
But the problem the last couple of weeks has been the RP memory. At this moment its on 99% utilization of the max 1GB that the 720-3bxl can hold! On short term we can downgrade back to 12.* version, or to "ip base" or "ip service" branch, that might give us some room to breath. Or are we missing something that could free up lots of memory on a 720-3bxl? I heard BGP Soft Reset might free up some memory? Is this true and will it be significant?
#show mls cef summary
Total routes: 621171
IPv4 unicast routes: 590424
IPv4 non-vrf routes: 590310
IPv4 vrf routes: 114
IPv4 Multicast routes: 107
MPLS routes: 0
IPv6 unicast routes: 30637
IPv6 non-vrf routes: 30637
IPv6 vrf routes: 0
IPv6 multicast routes: 3
EoM routes: 0
#show mls cef maximum-routes
FIB TCAM maximum routes :
=======================
Current :-
-------
IPv4 + MPLS - 832k (default)
IPv6 - 90k
IP multicast - 1k
#show ip route summary
IP routing table name is default (0x0)
IP routing table maximum-paths is 32
Route Source Networks Subnets Replicates Overhead Memory (bytes)
connected 0 27 0 1720 4860
static 1 6 0 648 1260
ospf 10 4 146 0 9000 27600
Intra-area: 13 Inter-area: 80 External-1: 0 External-2: 57
NSSA External-1: 0 NSSA External-2: 0
bgp 16281 178650 411418 0 35404080 106212240
External: 537410 Internal: 52658 Local: 0
internal 6527 23798440
Total 185182 411597 0 35415448 130044400
#show processes memory sorted
Processor Pool Total: 885604800 Used: 873661740 Free: 11943060
I/O Pool Total: 67108864 Used: 21605592 Free: 45503272
PID TTY Allocated Freed Holding Getbufs Retbufs Process
648 0 509215580 57367348 508116264 0 0 BGP Router
380 0 215107608 40228 215035168 0 0 IP RIB
Update
0 0 168613476 12296 152776588 0 0 *Init*
Chiel
_______________________________________________
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/
This message contains information that may be confidential, privileged or otherwise protected by law from disclosure. It is intended for the exclusive use of the addressee(s). Unless you are the addressee or authorized agent of the addressee, you may not review, copy, distribute or disclose to anyone the message or any information contained within. If you have received this message in error, please contact the sender by electronic reply and immediately delete all copies of the message.
More information about the cisco-nsp
mailing list