[nsp] Max eBGP sessions

[Gert Doering]

Hi,

On Mon, Jun 09, 2003 at 12:02:27PM -0700, Jim Devane wrote:
> Very interesting. Yes, I would likely only be sending out a default
> route and receiving 2-6 routes per peer.

"Thousands of peers" :-)

> I was concerned about the CPU load if a few of the routers rebooted or
> the BGP session was otherwise lost.

I'm not sure whether IOS has a limit on the number of concurrent TCP
sessions, or the IOS BGP implementation has a limit on the number of
peers, but from the CPU and memory point of view, I wouldn't worry -
there's very little work to do in this setup.

> A friend asked about setting up downstream peering to his T1 customers.
> I thought it was a very bad idea. Since some of the clients turn off
> their CPE router at the end of the work day. 

BGP should be able to handle that.  They would need to know that it might
take a few minutes for routing to come up when they turn on their router
(turning off leased line routers is a weird idea...) but otherwise it
should be fine.

> Any advice on what to expect for a CPU load. Do you think a number of
> 150-200 peers ( again with only a handful of routes) would be possible?>

I wouldn't sell that without testing it, but based from our NPE-225
experiences (over 80 peers, some of them sending over 10000 routes, and
everything working just fine) I wouldn't expect major problems here.

One important point is to use peer-groups: this means that the router
doesn't have to walk through all 150 peers for every update to check "do I
need update X to peer Y", but only check the peer-group *once* and then
distribute the update to all of them, or none.

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert.doering at physik.tu-muenchen.de