BGP and memory

Alex P. Rudnev alex at virgin.relcom.eu.net
Wed Oct 13 17:40:56 UTC 1999


Sorry, I did not want to blame any developer; I only notified that
even text presentation of this tables get less memory then the structures
in the router. Due to Bill (MS really can't work withouth the heaps of the
memory) memory became the cheap gift this days (talking about the memory
for the BGP tables, not the fast switch buffers memory).

-:) Regards, alex.


On Wed, 13 Oct 1999, Ryan K. Brooks wrote:

> Date: Wed, 13 Oct 1999 12:35:27 -0500
> From: Ryan K. Brooks <ryan at inc.net>
> To: Phillip Vandry <vandry at Mlink.NET>
> Cc: Alex P. Rudnev <alex at virgin.relcom.eu.net>, nanog at merit.edu
> Subject: Re: BGP and memory
> 
> 
> 
> Phillip Vandry wrote:
> 
> > I think you are forgetting that these routes need to be stored in a data
> > structure that allows fast queries as well as fast inserts and deletes.
> > That index takes space, and your "sh ip bgp" doesn't show you that.
> >
> > Yeah, let's store the routing table in a linked list!
> >
> 
> Actually, that isn't that crazy...  There's quite a bit of silicon out there that can
> read link lists very fast (fast enough to paint video frames as an example)...  But I
> suppose we're talking about processor-based (software) routing for the most part..
> 
> Ryan Brooks
> ryan at inc.net
> 
> >
> > -Phil
> >
> > > No, if someone want to implement the core BGP in the 8 MB ram, he can do
> > > it as well (through the cost of his work + cost of debug should be much
> > > greater than the cost of 128RAM memory -:)).
> > >
> > > Aleksei Roudnev, Network Operations Center, Relcom, Moscow
> > > (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 1
> > > 3729 (pager)
> > > (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
> > >
> > >
> 
> 

Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)





More information about the NANOG mailing list