- NANOG - lists.nanog.org

RE: perf #s for GRF vs 7500 Re: Anyone Deployed Ascend's GRF IP S witch?
by Marten Terpstra 27 Aug '97

27 Aug '97

[sorry - should have replied to Paul directly but hit the 'd' key too soon] >> Bay claims to hold the entire Internet routing table in just 4-6MB RAM >> per BGP peer (I assume this is after convergence). They say that the >> method in which they do this is proprietary. I am just wondering if it >> is possible..... Let's see. Here is a router I used a couple of months ago: ... 38 peers configured. Using 52565 Routes out of a total of 266710. 24135 unique paths maintained. ... And memory usage: Process Memory Use Statistics ----------------------------- Name Slot Used %Used ---------------- ---- -------- ----- ... bgp 9 23251104 48 ... So, 23251104 bytes / 266710 routes would be around 87 bytes per route, multiple that by say 48000 or so for a full table now and that would make it 4.1M per copy. Note though that the 23M used above is not just route memory, it is also for the BGP code itself (most software modules on a Bay are loaded dynamically when needed) and other BGP things like filters and such (although the above router did not have too many). -Marten PS different sets of BGP routes may of course alter these numbers, I just wanted to provide a live sample to answer the question.

1 0

Filters and reality
by Sean Donelan 27 Aug '97

27 Aug '97

I'm wondering just how far someone can get ignoring the prefix-length filtering rules used by Sprint/ANS/etc as long as you use Spring/ANS/etc as your provider. The National Archives of Canada has a traditional class B network 142.42. However, instead of advertising the network as 142.42/16, they've elected to advertise only 142.42.242/24. The /24 prefix-length announcement in traditional class B network space wouldn't pass the access-lists some providers use on their inbound BGP sessions. The same providers don't seem to use the same filters on their outbound announcements, leading to customer (and often network engineer) confusion why things don't work to some places but work ok inside the providers own network. Should we continue to poke holes in our filters to let Sprint's customer's customer routes through, or should we keep trying to explain to the Sprint NOC why their customer's customers could use shorter prefix length announcements? Be liberal in what you send, and conservative in what you accept? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

4 3

RE: perf #s for GRF vs 7500 Re: Anyone Deployed Ascend's GRF IP S witch?
by Paul Peterson 27 Aug '97

27 Aug '97

Has anyone compared the figures or have any feelings regarding the Bay Networks BCN ?? We are considering one over a Cisco 7513/RSP4 or a GRF. Bay claims to hold the entire Internet routing table in just 4-6MB RAM per BGP peer (I assume this is after convergence). They say that the method in which they do this is proprietary. I am just wondering if it is possible..... TIA Paul... > -----Original Message----- > From: Craig A. Huegen [SMTP:c-huegen@quadrunner.com] > Sent: Tuesday, August 26, 1997 9:00 PM > To: joseph j. kim > Cc: Joe Shaw; nanog(a)merit.edu > Subject: Re: perf #s for GRF vs 7500 Re: Anyone Deployed Ascend's > GRF IP Switch? > > On Tue, 26 Aug 1997, joseph j. kim wrote: > > ==>So, who's numbers should we believe or feel are more appropriate to > real > ==>world situations? > ==> > ==>> Comparing GateD to IOS becomes more of a religious preference > than > ==>> anything else. I'm content knowing both, truth be told. > ==>> > ==>> > maybe someone can post some performance numbers. > > Tolly's report didn't use CEF/FIB switching, and used classical > (centralized) switching. Ascend paid Tolly for the test anyway--the > only > *true* test would be one from Data Communications or similar. > > /cah

2 1

Re: Anyone Deployed Ascend's GRF IP Switch?
by joseph j. kim 27 Aug '97

27 Aug '97

On Mon, 25 Aug 1997, Justin W. Newton wrote: > At 08:35 PM 8/25/97 +0000, Nathan Stratton wrote: > > > >On Fri, 22 Aug 1997, Lane Patterson wrote: > > > >> Talk to Nathan Stratton at Netrail. He's our collective test case :-) > >> > >> Aren't you looking at Cisco's BFR too? > > > >We have been trying to get a BFR (now GSR) in, but I think Cisco does not > >want a GSR next to a GRF or something. :-) > > i don't understand all of the mail comparing the two, there is really no comparison. the GSR blows the GRF away. there is an order of magnitude difference in the aggregate b/w supported between the two correct? 4Mb/s vs 40Mb/s. Also, not that I know anything about the GRF but I think Cisco claims that 7500 real-world performance is much better than the GRF400. maybe someone can post some performance numbers. -jjk

5 5

Re: Filters and reality
by Paul G. Donner 27 Aug '97

27 Aug '97

At 08:32 AM 8/27/97 +0900, David R. Conrad wrote: >[Apologies for an (almost technical) post from outside NA to NANOG] > >Hi, > >>Should we continue to poke holes in our filters to let Sprint's customer's >>customer routes through, or should we keep trying to explain to the Sprint >>NOC why their customer's customers could use shorter prefix length >>announcements? > >I suppose it depends on what slope you want the graph at >http://www.iepg.org/ops/bgptable.html to have. Regardless of whether >the filters are a "good idea" or not, they do tend to limit routing >table growth and its implications, if for no other reason than smaller >sites are "encouraged" to go to their providers for address space due >to fear of being filtered. No argument there, but what about more consistency in filtering which *might* lead to more predictability in routing behavior? Given, diversity in address assignment (as well as policy) serves as a cause the variation in filtering policy. - donner > >Regards, >-drc > >

2 1

CORRECTION: 8th Maryland Workshop on Very High Speed Networks
by Account of Maryland Center for Telecommunications Research 26 Aug '97

26 Aug '97

!!!!!!! NOTE: PLEASE NOTE NEW DATES FOR THIS WORKSHOP !!!!!! *************************************************************** 8th Maryland Workshop on Very High Speed Networks November 12-13, 1997 *************************************************************** Maryland Center for Telecommunications Research Department of Computer Science and Electrical Engineering University of Maryland Baltimore County The Maryland Center for Telecommunications Research (MCTR) at the University of Maryland Baltimore County (UMBC) will hold the 8th Maryland Workshop on Very High Speed Networks (VHSN '97) on November 12-13 1997 at the UMBC campus. The Workshop will be held in the Ballroom of the University Center on the UMBC campus. The goal of the workshop is to provide a forum where researchers and developers can meet to exchange ideas and report on leading- edge developments in the area of high speed networks. Each of the previous workshops attracted approximately 150 researchers representing academia, industry and government. The two day meeting will include invited speakers and contributed presentations. Papers on selected presentations will appear in a special issue of the Journal of High Speed Networks. A registration fee of $325 will include two lunches and conference proceeding. For questions regarding the technical content of the workshop or giving a presentation, please contact the workshop organizer: Dr. Deepinder Sidhu, Tel: (410) 455-3028 or 3063, Fax: (410) 455-3969, Email: mctr(a)cs.umbc.edu. Mail checks (payable to University of Maryland Foundation) and registration form to Dr. D. Sidhu, Maryland Center for Telecommunications Research, University of Maryland Baltimore County, 1000 Hilltop Circle, Baltimore, MD 21250. All funds for this event will be managed by the UM foundation. Please DO NOT include hotel accommodation expenses in your payment for the Workshop Registration. Room payment should be made directly to the hotel you selected for stay. The following hotels are closest to UMBC campus. Some hotels may offer reduced rate. To obtain the reduced rate, you must identify yourself as an attendee of this workshop. BWI Airport is approximately five miles from UMBC Campus. * Sheraton International Hotel - BWI Airport. Closest to airport and UMBC campus. Tel: (410) 859-3300 or (800) 638-5858 * Holiday Inn - BWI Airport. Close to airport and UMBC campus. Tel: (410) 859-8400 or (800) HOLIDAY * Omni Inner Harbor Hotel. Close to Downtown Baltimore/Inner Harbor. About 20 minutes drive to UMBC campus. Tel: (410) 752-1100 or (800) 843-6664 For more information on the workshop and directions to UMBC, check our home page on WWW (http://www.mctr.umbc.edu) --------------------------------------------------------------- VHSN '97 REGISTRATION FORM (November 12-13, 1997) Name: Affiliation: Address: Tel: Fax: Email: Dietary Restrictions: Vegetarian ------ Kosher -------- ---------------------------------------------------------------

1 0

Re: Is this just a rumor?
by sob＠academ.com 26 Aug '97

26 Aug '97

Network Solutions' presentations at NANOG have stated that there is a "limiting" agent in the whois server to prevent wholesale dumping of the database. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

2 1

Re: Is this just a rumor?
by Dan Grillo 26 Aug '97

26 Aug '97

Stan Barber writes: > Network Solutions' presentations at NANOG have stated that there is a > "limiting" agent in the whois server to prevent wholesale dumping of the > database. That's true, but it's not very "limiting". I just wrote something to list all class-Bs and their owners. --Dan -- Dan Grillo dan_grillo(a)280.com 415 575-4020 fax 415 703-7220

1 0

Re: Multiple fiber carriers (was Re: Netrail woes)
by Sean Donelan 26 Aug '97

26 Aug '97

>It's one of the questions we ask prior to purchasing service. Just has >MFS install a new ring and put in physically seperate paths to one of our >facilities for just that reason. We made sure the paths were physically >seperate when they did the install. We waited for them to bring fiber up Never underestimate Mr. Murphy's ingenuity. At DRA's main data center in St. Louis we have three seperate entrance facilities seperated by a mininum of 50 feet from three seperate carriers. While I was away in Munich, an unsupervised MFS tech managed to take down both halves of one of the self-healing SONET rings. Gosh, that didn't work, why don't I do the same thing to the backup ring. Duh! I assume if DRA had a fifty-foot crater in front of the building, I'd likely have other, more pressing problems to worry about. Unfortunately, an unsupervised tech can easily, and silently take out multiple diverse facilities. Imagine what he could have done with malice and planning. We try to keep the techs isolated from other carriers equipment, but techs can be an ingenious bunch when doing dumb things. Backhoes and other physical disruptions usually have a nice random distribution modulo the fact that backhoes are often used in right-of-ways. With the right statistical model, and enough money most folks can come up with a survivable plan for typical physical disruptions. On the other hand, Tech errors are more worrisome, mainly because techs tend to be working near your most vulnerable points, the nodes that handle failover. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

Network MOO?
by Eric Osborne 26 Aug '97

26 Aug '97

I saw a pointer to the IPNmoo off of www.nanog.com, and this got me thinking - how many other people would be interested in a Nanog-flavor MOO? IPNmoo doesn't seem to be running (www.nlanr.net:4766) I've had a bit of experience running a MOO, and it seems like it might be a useful thing to have. I may even be able to provider server space, if there's enough interest. Comments? eric

2 1