- NANOG - lists.nanog.org

Operational issue: MAE-WEST
by dlr＠daver.bungi.com 03 Dec '98

03 Dec '98

Looks like AC power was lost at the MFS-side mae-west, around 00:30. No generator, yet. Dave Rand

1 0

Re: identify hostname
by Brandon Ross 03 Dec '98

03 Dec '98

On Mon, 30 Nov 1998, Dan Hollis wrote: > On Mon, 30 Nov 1998, Brandon Ross wrote: > > 1Cust76.tnt1.sfo2.da. > > Id say that looks like uunet. Again. Sigh. > > UUnet uses ascend TNT's which they claim you cant filter > directed-broadcast on. Ive ranted at them since October 20 to get this > serious security hole closed. I've been yelling at them about that as well as not being able or willing to reverse trace spoof attacks. This attack, however, would not have been stopped by such filters, this is just the address that someone used to break into a server with. Thanks for your help. Brandon Ross Network Engineering 404-815-0770 800-719-4664 Director, Network Engineering, MindSpring Ent., Inc. info(a)mindspring.com ICQ: 2269442 Stop Smurf attacks! Configure your router interfaces to block directed broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details.

5 4

@Home NOC?
by Adam Rothschild 03 Dec '98

03 Dec '98

I'd really hate to use NANOG as a phonebook...but... Anyone out there have some accurate contact info for the @Home NOC? The number listed at http://puck.nether.net/netops/nocs.html is not valid... TIA

1 0

Perf. Analysis on Carrier-grade networks
by Lawrence A. Deleski 03 Dec '98

03 Dec '98

I have a customer with a requirement to do performance analysis, capacity planning, network optimization, and network documentation on carrier-grade networks. Very few of the tools I'm used to working with (NetMaker, Comnet, etc.) can do this kind of analysis on hybrid voice/data networks. Does anyone have any experience with any software packages that could address one or more of the above requirements? The networks we need to model consist of a mixture of TDM, FastPacket, and IP traffic running over an eclectic mix of topologies, including T1, E1, FR, ATM (DS3), and OC-3 SONET. It would be helpful if the software could perform failure analysis scenarios on selected components of the network. Thanks in advance for your help. Larry Deleski Cisco Systems ldeleski(a)cisco.com lad(a)inficad.com

1 0

older route update archives?
by Vadim Antonov 03 Dec '98

03 Dec '98

Hi -- does anyone have some trace files with route announcements and withdrawals available? Older (pre flap damping) traces would be the best. Thanks! --vadim

1 0

RE: Effects of traffic shaping ICMP (&c.)
by Martin, Christian 02 Dec '98

02 Dec '98

You could implement priority queueing to this end, but the effects could be disastrous on buffers. At this time, the best way to defend against smurf and UDP floods is via access-lists with fast-packet drop. Chris > -----Original Message----- > From: mark(a)vielle.datasys.net [mailto:mark@vielle.datasys.net] > Sent: Wednesday, December 02, 1998 3:57 PM > To: nanog(a)merit.edu > Subject: Effects of traffic shaping ICMP (&c.) > > > Howdy, > > When our network is being smurfed, we can call our ISPs and have them > setup an access list to block ICMP. That fixes the problem, but it > creates another (obvious) problem. > > Could traffic shaping, or similar QoS configurations, be used to solve > such issues in a more general way? For example, if my source of packet > flooding is ICMP, then I'd like to be able to dedicate as > much as 1/10th > (e.g.) of the bandwidth of each link to ICMP. That's plenty > of ICMP, but > it's not so much that an attack using ICMP would be effective. > > My question, stated briefly, is this: can you solve generic > homogenous-packet-flood problems with QoS and/or traffic > shaping (if the > two can be truly distinguished), in general? If so, are > current routers > capable of doing it? What would be the effect of doing so on dialup > links and backbones? > > --- > Mark R. Lindsey, mark(a)datasys.net > Internet Engineering, DSS Online LLC > Voice: 912.241.0607x200, Fax: 912.241.0190 (US) >

1 0

Winter NANOG meeting
by Susan R. Harris 02 Dec '98

02 Dec '98

Hello everyone - registration is now open for the next NANOG meeting, to be held January 31- February 2 in Denver: http://www.nanog.org/mtg-9901/ Hope you can join us! Just a reminder that slides and RealMedia recordings from the Atlanta NANOG are available here: http://www.nanog.org/mtg-9811/agen1198.html We are still looking for a sponsor for the upcoming spring NANOG (NANOG 16). If you're interested in hosting the meeting, please send e-mail to nanog-support(a)nanog.org. Also, we welcome equipment and break sponsors for the Denver NANOG. If you are interesting in loaning equipment (hubs, caches, wireless), or sponsoring a break, please send e-mail to nanog-support(a)nanog.org. --Susan R. Harris

1 0

Response to those wanting our cflow tools
by John M. Brown 02 Dec '98

02 Dec '98

I have received many responses from people that would like access to the tools we have developed for cflow stuff. Please give us a couple of days to get them packaged into something usefull to the rest of the world. I'll post a URL that will have the info, source, etc. jmbrown(a)ihighway.net

1 0

Re: identify hostname
by Dean Anderson 02 Dec '98

02 Dec '98

True enough. But it would cut out most of the the problems with really small customers (such as the /30's which were mentioned ;-) Sure there are some cases that are hard or impossible to account for, but it would be helpful for ISP's to take a stance that "here's your address space. Unless you tell us otherwise, we assume its not subnetted, and we will block your broadcast addresse. If you subnet or otherwise change your broadcast address, you will need to notify us" I guess what I'm saying is that for many, the default is to do nothing. The default should be different where possible. --Dean >That works fine as long as you either manage your customers' equipment or >your customers don't subnet blocks you give them. However, in real-world >experience, neither of those apply, especially to a larger ISP/NSP (UUNet >was mentioned in this thread at the beginning). > >It certainly doesn't hurt to put in access-list's where you can, to reduce >the problem, but that is not a scalable solution. It is an incredible >management nightmare, especially if you're having to keep track of >autonomous customer routing changes. Not to mention that it adds to the >burden of tracking down problems (imagine a DHCP server which assignes >what used to be a broadcast address, but is no longer because the subnets >were combined, and everytime a machine gets that address, it can't get >outside the network because the administrator hasn't updated the >5,000-line access-list). > >Pete. > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

2 1

Windows TweakDUN issue..
by bcurnow 02 Dec '98

02 Dec '98

In regards to the topic, is there a _technical_ discussion, perhaps written by someone here, on what is broken in Win9x that makes these kinds of software useful? I find it disturbing to read that MS makes 576 the default in 98, while still seeming to produce an ack for every packet on TCP. I think being able to single handedly reduce the number of packets sent by 25% should have been a high priority for them. Instead they choose to triple it. Or am I in need of a higher RFC exposure? ----------------- Brian Curnow ----------------

1 0