BGP peering strategies for smaller routers
carlos at race.com
Tue May 3 23:02:05 UTC 2016
I know this thread has been primarily about memory to hold the routing tables, but how well does it do with the BGP convergence time?? which could be the other killer with multiple full route tables.
Race Communications / Race Team Member
1325 Howard Ave. #604, Burlingame, CA. 94010
Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com
From: NANOG <nanog-bounces at nanog.org> on behalf of Blake Hudson <blake at ispn.net>
Sent: Tuesday, May 3, 2016 3:23:42 PM
To: nanog at nanog.org
Subject: Re: BGP peering strategies for smaller routers
Łukasz Bromirski wrote on 5/3/2016 4:13 PM:
>> On 03 May 2016, at 22:31, William Herrin <bill at herrin.us> wrote:
>> On Tue, May 3, 2016 at 3:50 PM, Gustav Ulander
>> <gustav.ulander at 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
> 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:
> 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.
I feel like you're trying to fit some other (possible, but far fetched)
scenario from where we started. Mike, the op, said he has a 1002 which
has an RP1 configured with 4GB of RAM. First, this is not a 1001.
Second, SSO is off by default and is unlikely to be configured on an
ASR1002 (the op certainly never stated he had enabled it). I just
checked a few ASR 1k RP1s I have access to and the 3.10 IOS image has
similar memory usage to the 3.13 (the latest MD release for this
platform). On the RP1 platform, with a default only BGP feed, the
systems have ~ 1.3GB of proc mem available. With a single full IP4 BGP
feed, the free proc mem goes down to ~850MB. With two full feeds, the
proc mem goes down to ~ 800MB. RP memory goes from ~1.8GB used (default
only), ~2.7GB used (1x full), ~2.8GB used (2x full). This still leaves
over 1GB of free RP memory with two full BGP feeds. The amount of FIB is
dependent on the ESP installed by the OP; Mike hasn't yet stated what
ESP he has installed.
So yes, the 1002 can, and will continue to, work with two full BGP feeds
when fitted with an ESP10.
More information about the NANOG