BGP peering strategies for smaller routers

Wed May 4 21:29:17 UTC 2016

Chuck Church wrote on 5/4/2016 12:14 PM:
> ----------------------------------------------------------------------------------------------------------------------
> Hi Nick,
>
>> You missed the point. Sloppy memory management is a "canary in a coal mine." It's a user-visible symptom that reflects poor code quality underneath. Programmers who >don't care how much ram they're consuming are the same fools who catch and then ignore exceptions, don't bother evaluating the big-oh running time of their algorithms >(often have no idea what that is) and engage in a variety of other bad practices that you as the customer suffer for but never directly see.
>
> That Cisco URL covering ASR1K memory details did mention that due to 64 bit, everything does use more memory.
> http://www.cisco.com/c/en/us/support/docs/routers/asr-1000-series-aggregation-services-routers/116777-technote-product-00.html
>   My biggest beef is that right off the bat, IOSd process only gets half the physical RAM.   I'm not sure of that reasoning.  Maybe to support ISSU with SW redundancy?  Would be nice to be able to disable or tune that.  I'm not sure what else that memory would be reserved for.  It doesn't seem right that 2 full feeds works fine on an ISR with 768MB RAM, yet doesn't work on a 1K with 4 gigs of RAM.
>
> Chuck
>

Given that the IOSd process runs under 32bit Linux (on the RP1), the 2GB 
allocation is probably a reflection of the max that Cisco could allocate 
to a single process in user space. The other 2GB (in a 4GB system) gets 
used, just not by the IOSd process. On the 8GB and 16GB versions of the 
RP2, I'm not sure why you'd maintain the 50/50 split. Perhaps it's not 
quite as simple as the document lets on.