- Test - lists.nanog.org

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

Re: Network MOO?
by Bill Woodcock 26 Aug '97

26 Aug '97

There are terms of use for the IPNmoo, basically that your marketing folks won't run around badmouthing other people when you find out about other people's outages through it. So you need to get an account to log in. Mail kc(a)nlanr.net or labovit(a)merit.edu to find out more about it. It's very useful, but like the infamous outage-discussion mailing lists, two is not better. :-) -Bill Woodcock

2 1

Netrail woes (was Re: Atlanta-NAP down (fwd))
by Sean M. Doran 26 Aug '97

26 Aug '97

I just read this after clearing out old NANOG mail... Jon Lewis <jlewis(a)inorganic5.fdt.net> writes: > The Atlanta NAP (www.atlanta-nap.net run by Nathan Stratton) is down, > probably for good. We're a customer (luckily a multihomed one!), and > the word is WORLDCOM pulled all their circuits due to debts. So all the > netrail.net mailing lists and stuff will be down too. 8 mae-east2-nap.Washington.mci.net (204.70.1.222) 107.596 ms 195.051 ms 90.187 ms 9 mae-east.netrail.net (192.41.177.228) 97.759 ms 128.468 ms 108.682 ms 10 mae-east.netrail.net (192.41.177.228) 121.353 ms !H 92.724 ms !H 92.384 ms !H 23 144.228.10.42 (144.228.10.42) 178.501 ms 181.052 ms * 24 mae-east.netrail.net (192.41.177.228) 204.067 ms 206.366 ms * 25 mae-east.netrail.net (192.41.177.228) 208.59 ms !H 197.928 ms !H 207.262 ms !H You know, although I do feel bad for Netrail and its customers, I did read this with a keen appreciation for the irony, given Mr Stratton's public comments about how badly BBN's power system was misdesigned for allowing them to take multi-hour outages, particularly in light of the fact that the outage in question was beyond BBN's immediate ability to fix, and not BBN's fault. It didn't have the personal tastiness of Mr Bass's unfortunate encounter with bad weather a year or so ago, but frankly, I can't help but engage in schadenfreude anyway. I also wonder how the millions of GRFs and the billions of other high-tech expensive pieces of equipment in Netrail's large network Mr Stratton often commented upon are coping right now. One final extract, from <Pine.BSF.3.95q.970716143738.3017A-100000(a)netrail.net> posted to NANOG during the recent backhoe season: "Ya, we are going to kill worldcom for this [outage caused by a fibre-cut]". No tickee, no complainee? The moral of this story: bad things happen to everyone. But when it happens to braggarts who seem to specialize in doing things better than people who are trying their best, it's terribly, terribly cool. --:) Take note, please, Mr Fleming (inventor and super genius). Sean.

13 14

Re: ICMP Attacks???????
by Paul G. Donner 26 Aug '97

26 Aug '97

At 03:26 PM 8/21/97 -0500, Jon Green wrote: >On Thu, 21 Aug 1997 13:18:34 -0700, fair(a)clock.org writes: >> >>There is another mitigation: everyone here should commit to filtering >>customer packets at the customer premesis router (or at the dial in for >>PPP/SLIP) such that it is not possible for a customer to send a packet into >>the network that has an IP source address on it that is not assigned to >>that customer. That is, no more lying about source addresses. > >Every time I show a customer of mine how to configure a router, I >try to educate them on this. We need some kind of massive marketing >effort to get this out to people though. People would do it, but nobody >knows about it. Why not include it as part of "their" contractual obligations by placing it in the text of the contract as well as by including an instructional whitepaper. You can't really enforce it but at least you get the coverage you want. Besides, if the customer is as clueless as most (and I say that in a benign way) they may not know that you can't or wouldn't really enforce it. > >Maybe we should get CyberPromo to spam all the technical contacts >in Internic's database to tell them how to do filtering. :) > >-Jon > > ----------------------------------------------------------------- > * Jon Green * "Life's a dance * > * jcgreen(a)netINS.net * you learn as you go" * > * Finger for Geek Code/PGP * * > * #include "std_disclaimer.h" * http://www.netins.net/showcase/jcgreen * > ------------------------------------------------------------------------- > >

1 0