[c-nsp] SUP720's memory, looking at options..

[Howard Leadmon]

 FYI, the version I am currently running is 12.2(33)SXJ1, and though I know
it's not the newest thing going, it for sure has served us well with an
uptime of 4 years, 51 weeks, 4 days, 19 minutes as of this message.    I
have little doubt that a reboot may free up some memory, if nothing else
some more contiguous chunks, but from all I have read here recently, with
taking full routes this is a short term stop gap measure at best.

 So what I am trying to figure out, is what is a good path forward that will
last more than a couple months at best.   As mentioned below,  I have looked
at just using the RSP720-3CXL as it will take a lot more RAM reduce running
on the edge of a memory allocation failure (plus the faster CPU is good for
BGP).  I have looked at using something like the ASR1004/6 as with a full
load of RAM it says it will easily do 4 million routes.  Finally I know
someone that has a GSR12404 that suggested I use it, and though I know it's
not new platform, I can't for the life of me figure out what routing limits
it has.   I for sure need 1G and 10G interfaces (not a lot), also need 32bit
ASN support as we already use it at the IX

 The reboot of the current switch would be easy, but if I need to take the
time to haul around big switches/routers, and changing the network around, I
figure it just makes good sense to learn what I can to make an informed
choice as much as possible.


 Happy 4th to any that celebrate it..


---
Howard Leadmon - howard at leadmon.net
PBW Communications, LLC
http://www.pbwcomm.com

> -----Original Message-----
> From: Jon Lewis [mailto:jlewis at lewis.org]
> Sent: Monday, July 4, 2016 9:34 AM
> To: Howard Leadmon <howard at leadmon.net>
> Cc: 'cisco-nsp' <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] SUP720's memory, looking at options..
> 
> On Mon, 4 Jul 2016, Howard Leadmon wrote:
> 
> >  I knew with the 720-3BXL's I was running, that eventually the TCAM
> > would become an issue, but it seemed like I still had a little bit of
breathing
> > room left.   Then I saw the chatter here about the RAM on the RP
> exhausting
> > before the TCAM, so went peeking at the switch after reading an earlier
> > thread.     Sure enough, though TCAM was starting to get full, to my
> > surprise when I looked at memory, it was at 92%, so even closer than
> > the TCAM by far to exhaustion.
> >
> > I know I can't just up the RAM on the board, so that now leads me to
> > wonder what are reasonable options to resolve this before it becomes a
> very real
> > and big problem.   First let me say, compared to many here we are small
> > guys, we have a limited budget, and our 6509 has served us well for a
great
> > many years, I think it's about to pass the 5yr uptime mark.   We have
2-3
> > full feeds as uptime is important, and we also peer at the Equinix IX,
> > so have a bunch of additional peering sessions.
> 
> Some of the software versions for the 6500 have had BGP related memory
> leaks, and if you've got an uptime of 5yrs, that means you're not exactly
> running recent code, and have had a lot of time for memory to get
> misplaced.  I no longer have access to a 6500 with full feeds, so I don't
know if
> 3 full feeds + an IX should be running you out of memory.  An
> upgrade/reboot might be worth a try though.  I'd stay in whatever major
> version you're in though...not try jumping to a much later version that
might
> be even more memory hungry.
> 
> ----------------------------------------------------------------------
>   Jon Lewis, MCP :)           |  I route
>                               |  therefore you are _________
> http://www.lewis.org/~jlewis/pgp for PGP public key_________