nanog mailing list archives
Re: BGP peering strategies for smaller routers
From: Łukasz Bromirski <lukasz () bromirski net>
Date: Tue, 3 May 2016 23:13:11 +0200
On 03 May 2016, at 22:31, William Herrin <bill () herrin us> wrote: On Tue, May 3, 2016 at 3:50 PM, Gustav Ulander <gustav.ulander () telecomputing se> wrote:Yes I can confirm that we also had the issue with the asr1001s. For us the router was fine until we upgraded it. When we rebooted it after the upgrade it ran out of memory when populating 2 full feeds. When we contacted TAC they confirmed that indeed it was a memory problem and that we would need to add more memory to the box.Hi Gustav, IMO, you should not accept that answer from the TAC. An IOS release that crashes with two 600k BGP feeds in 4 gigs of RAM is badly defective.
Not necessarily. In essence, your physical memory gets halved in two after router boots up, then it may be further halved if you’re using features like SSO. So, with 4GB RAM config and with SSO running, you may be left with around 600-650MB free after boot and with IOS-XE loaded, and then all the features kick in. Including your BGP feeds that need around 300MB of memory just to store the tables, then there’s CEF RAM representation, and so on. Here’s a good WP w/r to memory usage & architecture on ASR 1k: http://www.cisco.com/c/en/us/support/docs/routers/asr-1000-series-aggregation-services-routers/116777-technote-product-00.html It actually contains the same recommendation given by TAC - with recent/current code if you want to run full tables with BGP, get 8GB of RAM on ASR 1k. In the 3.10-3.12S era I believe it was still possible to fit (without the SSO) full tables in RAM and be fine. As Nick just responded, it’s faster to source the RAM or modify the config to cut down on number of BGP prefixes rather than ping back and forth here discussing all the possibilities. -- Łukasz Bromirski CCIE R&S/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A
Current thread:
- Re: BGP peering strategies for smaller routers, (continued)
- Re: BGP peering strategies for smaller routers Richard Hicks (May 02)
- Re: BGP peering strategies for smaller routers Mark Tinka (May 02)
- Re: BGP peering strategies for smaller routers William Herrin (May 03)
- RE: BGP peering strategies for smaller routers Eric Sabotta (May 03)
- Re: BGP peering strategies for smaller routers Mike (May 02)
- Re: BGP peering strategies for smaller routers Blake Hudson (May 03)
- Re: BGP peering strategies for smaller routers William Herrin (May 03)
- SV: BGP peering strategies for smaller routers Gustav Ulander (May 03)
- Re: BGP peering strategies for smaller routers William Herrin (May 03)
- Re: BGP peering strategies for smaller routers Nick Hilliard (May 03)
- Re: BGP peering strategies for smaller routers Łukasz Bromirski (May 03)
- Re: BGP peering strategies for smaller routers William Herrin (May 03)
- Re: BGP peering strategies for smaller routers Nick Hilliard (May 03)
- Re: BGP peering strategies for smaller routers William Herrin (May 03)
- RE: BGP peering strategies for smaller routers Chuck Church (May 04)
- Re: BGP peering strategies for smaller routers Blake Hudson (May 04)
- Re: BGP peering strategies for smaller routers Mike (May 02)
- Re: BGP peering strategies for smaller routers Richard Hicks (May 02)
- Re: BGP peering strategies for smaller routers Blake Hudson (May 03)
- Re: BGP peering strategies for smaller routers Carlos Alcantar (May 03)
- Re: BGP peering strategies for smaller routers Blake Hudson (May 03)
- Re: BGP peering strategies for smaller routers Łukasz Bromirski (May 03)
- SV: BGP peering strategies for smaller routers Gustav Ulander (May 03)