[c-nsp] BGP soft-reconfiguration inbound impact

[Frederic LOUI]

> Frederic LOUI wrote:
>> Hi everyone,
>>
>> I spent some times googling/searching the mailing list but I could 
>> not find any clear answer regarding
>> memory impact related to "soft-reconfiguration inbound" statement. 
>> (If you have any link/pointer, I'm interested !)
>>
>> We're running a bunch of 760X (RSP7203CXL + 8x10G withc DFC3CXL) 
>> having full BGP feed and some of them start to be really overloaded.
>>
>> I've read now and then that it is not recommended to use 
>> "soft-reconfiguration inbound" due to the extra memory used, but :
>>
>> 1) What is the clear impact of this command ? (Is there an algorithm  
>> formula O(n) that would help us to quantity the memory used ?)
>> 2) Is this extra-memory still an issue with modern hardware ?
>
> It depends on how many routes you have I think. If you've got the full 
> feed, then I'd say you're going to pay a heavy price for soft-reconfig.
>
> What does "sh ip bgp summ" say?
BGP router identifier <LOCAL_IDENTIFIER>, local AS number <LOCAL_AS>
BGP table version is 19465839, main routing table version 19465839
314959 network entries using 39054916 bytes of memory
630625 path entries using 32792500 bytes of memory
71249/52253 BGP path/bestpath attribute entries using 5414924 bytes of 
memory
98 BGP rrinfo entries using 2352 bytes of memory
64471 BGP AS-PATH entries using 1647244 bytes of memory
854 BGP community entries using 57562 bytes of memory
27 BGP extended community entries using 2230 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 78971728 total bytes of memory
Dampening enabled. 0 history paths, 0 dampened paths
885 received paths for inbound soft reconfiguration
BGP activity 1266553/943038 prefixes, 6013343/5365600 paths, scan 
interval 60 secs

>
>> 3) What is the common best practice ?
>
> Modern BGP implementations tend to support route refresh, where you 
> request the peer re-send it's RIB. There's no config needed for this - 
> just to a "sh ip bgp nei" and see if refresh is available:
>
> BGP neighbor is X  remote AS 64580, internal link
>  Inherits from template iBGP-world for session parameters
>   BGP version 4, remote router ID X
>   BGP state = Established, up for 4w4d
>   Last read 00:00:43, last write 00:00:31, hold time is 180, keepalive 
> interval is 60 seconds
>   Neighbor capabilities:
>     Route refresh: advertised and received(new)
>
> Of course, refreshing the full feed will take a while! There are I 
> believe optimisations for this - ORF rings a bell - but since I don't 
> deal in full-feeds, it's not something I'm up to speed with.
>
Agree.

>> 4) Are you using "soft-reconfiguration inbound", if yes how ? (i.e: 
>> Only for troubleshooting purpose, "always on" as part of your 
>> configuration template etc.)
>
> We are because it's convenient to be able to do "sh ip bgp nei X 
> received-routes" but we've got a very small routing table:
>
> ac-core#sh ip bgp summary
> BGP router identifier X local AS number 64580
> BGP table version is 8375, main routing table version 8375
> 903 network entries using 105651 bytes of memory
> 1763 path entries using 91676 bytes of memory
> 153/13 BGP path/bestpath attribute entries using 21420 bytes of memory
> 20 BGP rrinfo entries using 480 bytes of memory
> 8 BGP AS-PATH entries using 192 bytes of memory
> 5 BGP community entries using 120 bytes of memory
> 11 BGP extended community entries using 264 bytes of memory
> 0 BGP route-map cache entries using 0 bytes of memory
> 0 BGP filter-list cache entries using 0 bytes of memory
> BGP using 219803 total bytes of memory
>
> Obviously that's not the case for you.
We also feel that this is a comfort for us to use "show ip bgp neighbor 
X received-routes" but this comfort has a cost and I was just wondering 
how much it REALLY is :-)
And if based on users experiences there is something we could miss 
except route-refresh capability that is supported on most BGP 
implementation now and "received-route" command output.


Thanks anyway for your feedback
Have a good week-end

Cheers/Fred