- Test - lists.nanog.org

MAE-East
by Brian Merritt 01 Aug '97

01 Aug '97

I'm sure all of you noticed that MAE-East has ate it a few times in the last hour or so. Did any of you have any luck getting an explanation as to what's going on? Connections to the gigaswitches, the shared fddi concentrators, and the ethernet switches all went down... Power? If not, what would cause such a massive disturbance? Besides an airplane crashing into it.... -Brian

3 3

RE: disabling directed broadcasts
by jan.novak＠aliatel.cz 01 Aug '97

01 Aug '97

I also have (past) experience with a network running MS/NetBIOS cruft through routers with forwarding of directed broadcasts DISABLED. It worked fine. If there is some corner case I've missed that requires forwarding of directed broadcast packets, it would be useful for that specific case to be enumerated _in detail, in public_. Ran rja(a)home.net We ran MS Windows over routed network in seven localities without any type of broadcast enabled. All what is needed for user transparent operation is to setup WINS.

1 0

Re: disabling directed broadcasts
by rja＠corp.home.net 31 Jul '97

31 Jul '97

On Jul 30 21:16, Edward Henigin wrote: } Subject: disabling forwarding of directed broadcasts % this does work as you'd expect (it prevents the cisco % from framing an IP broadcast packet into an ethernet broadcast % frame) BUT unfortunately it can break Windows networking, as well % as BOOTP/DHCP, depending on how you're set up. BOOTP/DHCP does NOT need directed broadcast forwarding enabled to work properly. The "helper-address" function and the DHCP RELAY code take care of BOOTP/DHCP traffic. Implementations of BOOTP/DHCP don't require enabling forwarding of directed broadcast packets. I've verified this experimentally in a previous life. I also have (past) experience with a network running MS/NetBIOS cruft through routers with forwarding of directed broadcasts DISABLED. It worked fine. If there is some corner case I've missed that requires forwarding of directed broadcast packets, it would be useful for that specific case to be enumerated _in detail, in public_. Ran rja(a)home.net

2 1

Re: thats stupid
by Paul G. Donner 31 Jul '97

31 Jul '97

Does this, among a million other things I've seen on this list lately, belong on this list? At 05:49 PM 7/29/97 +0000, Pam Evon wrote: >dear nasa.com,my name is glen.i like tecnology type things.i like to >go to nasa.gov to see the new pathfinder pictures.but its a bit >confusing to see the differince between nasa.com and >nasa.gov.kix.country 92.9 told people to go to nasa.gov to see the >pathfinder pictures and not to go to nasa.com because they have >pictures of women having sex and naked women.yours truly glen. > > > > > >ps. e-mail me at pevon(a)cyberstreet.com >thank you > >

1 0

[FYI] Broadcasts at NAPs
by Lyndon Levesley 31 Jul '97

31 Jul '97

This ICMP discussion reminded me that we've been logging broadcasts for a while at ME to see what percentage of traffic they represented and what it was (the wrong way round to track back thru ICMP DoS attacks). If anyone's interested, the results are : 192.41.177.255 (254376 matches) 255.255.255.255 (1694830 matches) any other dest. (1047899270 matches) which is 0.18% of the total accounted for by broadcasts. Bad, of course, but not as bad as I thought. I guess the bigger the provider the smaller percentage of total (that 1billion is total input on our FDDI since I applied the list, rather than total packets on the LAN) I'm assuming that a billion packets is enough to be a representative sample. A bit of a breakdown from the logs : Split of broadcasts is ICMP 12% UDP 88% (actually, there were 5 packets for protocol 9 (private IGP?) but that's neither here nor there) Port breakdown (based on a smaller sample to save resources) ICMP ---- I won't name names (I'll contact people later on probably) but 99.2% of the ICMP traffic comes from one provider (two routers) and is directed at 255.255.255.255. That should be fairly easy to stop. Is there any good reason for a router to ping the broadcast address of a NAP ? UDP --- PORT: 53 PACKETS: 5 PORT: 67 PACKETS: 5364 PORT: 123 PACKETS: 9950 PORT: 161 PACKETS: 12 PORT: 513 PACKETS: 6635 PORT: 520 PACKETS: 19486 PORT: 5841 PACKETS: 4344 -------------------------------- 45796 53 = DNS (badly configured cisco, but temporary so that's OK) 67 = BOOTPS (!) (probably misconfigured cisco again ;) 123 = NTP (ditto!) 161 = SNMP (?? - god knows why this would happen) 513 = who? 520 = routed ( oh dear) 5841 = ??? (is this CDP?) The upshot would seem to be that even with loads of misconfigured/ clueless stuff going on, random traffic is so insignificant that it wouldn't affect the performance of the NAP infrastructure. Cheers, Lyndon -- Penis Envy is a total Phallusy.

2 2

This list
by Al Smith 31 Jul '97

31 Jul '97

I thought this list was created to be used in mind for reporting problems with the internet as well as failure's and cuts. Not to be a bitch board for people to complain. -Al Smith p.s. This is the only bitch you will see from me.

2 1

nic.ddn.mil
by sk8r steve 31 Jul '97

31 Jul '97

Is it me or is the .mil nic now messed up?

1 0

This list -
by Chris Yarnell 31 Jul '97

31 Jul '97

Hi, Is it me, or has the quality of the posts on this list gone further south than at any other time in recent history? <sigh> ---- Chris Yarnell - cyarnell(a)nasa.gov - 415-604-0726 NASA Network Information Center & GLOBE - NASA Ames Research Center

1 0

Re: [nsp] known networks for broadcast ping attacks
by Joe Provo - Network Architect 31 Jul '97

31 Jul '97

jra(a)scfn.thpl.lib.fl.us wrote: >On Wed, Jul 30, 1997 at 10:15:24PM -0700, Joe Rhett wrote: >> > .255 is _always_ a broadcast address, no? >> >> Uh, no. If the bit mask is smaller than /24, any given .255 address could >> be legitimate. > >RFC 917 and RFC 922 (admittedly old) suggest strongly that this isn't a >good idea; I'm still searching to find the reference I remember that >specifically deprecates it. This isn't a problem, nor is it recent/CIDR-specific. Given a /16 ('class B') that everyone and their brother had not even 5 years ago and a flat network, X.Y.n.255 isn't only a valid address for all values of "n", but is in real live use today. The only reason it wouldn't be "a good idea" is because we network folks have to be able to react and change things as needed, and there's less pain in skipping a few addresses so you stay on the "clean" bit boundaries then painting yourself into a corner WRT possible future subnetting and needing to renumber folks. I would say also because "vendors can be counted on to make nasty assumptions", but I can't think of any off the top of my head that, given the right address/mask pair, would make the wrong assumption (except those known to err in favour of being classful). >I guess it matters, since I'm not aware of routers that allow the >specification of filter rule addresses with /netsizes. I don't follow the significance of your statrement. There's no true difference between specifying masks by noting the bitsize or writing out the actual masks in octets; consider the former "reasonable-to-humans shorthand" and the latter akin to long division. Aside from that, it's an IP world, where specific implementation is meaningless... but off the top of my head, Compatible Systems boxes us /xx notation in their filters. Cheers, -- Joe Provo, Network Architect 800.763.8111 x3006 Network Operations Center Fax 508.229.2375 UltraNet Communications, Inc. <jprovo(a)ultra.net>

1 0

Re: TLD .ES screw up
by Eric Germann 31 Jul '97

31 Jul '97

At 06:01 PM 7/30/97 +0200, Miguel A. Sanz. RedIRIS/CSIC wrote: >So my questions now: > >Does any one know a direct way to reach the InterNIC technical staff to solve >this kind of urgent problems? > Flaming them on NANOG seems to work, but you get singed in the process also. Try markk(a)internic.net. He seemed helpful. From him: "Hostmaster receives at least 20K pieces of mail a day. If you have an operational issue of this nature, feel free to send it to action(a)internic.net. The people who are responsible for monitoring the roots also read that box." Let us know how [un]responsive action(a)internic.net is! >Shouldn't there be a specific set up of procedures, forms and communication >channels between the managers of the root zone and the TLD managers? > Apparently they're still drafting those. >Any help will be appreciated. > >Miguel A. Sanz >ES-NIC > >__________________ __ ______________________ > /_/ >Miguel A. Sanz __ __ Email: miguel.sanz(a)rediris.es >RedIRIS/CSIC /_/ RedIRIS /_/ Tel: + 34 1 5855152 >Serrano 142 __ Fax: + 34 1 5855146 >E-28006 Madrid /_/ >SPAIN Network Manager >____________ Spanish Academic & Research Network ________________________ > > > >--- Forwarded mail from "Miguel A. Sanz. RedIRIS/CSIC" <miguel.sanz(a)rediris.es> > >Date: Wed, 30 Jul 1997 15:05:45 +0200 (MET DST) >From: "Miguel A. Sanz. RedIRIS/CSIC" <miguel.sanz(a)rediris.es> >To: "David H. Holtzman" <dholtz(a)internic.net> >Subject: (Fwd) EMERGENCY TLD .ES >Cc: hostmaster(a)nic.es > > >Please take quick action on this and report back! > >We will wait a couple more hours before escalating this to IANA and >TLD list. > >Regards, > >Miguel A. Sanz >ES-NIC > > >--- Forwarded mail from "Miguel A. Sanz. RedIRIS/CSIC" <miguel.sanz(a)rediris.es> > >Date: Wed, 30 Jul 1997 11:49:59 +0200 (MET DST) >From: "Miguel A. Sanz. RedIRIS/CSIC" <miguel.sanz(a)rediris.es> >To: hostmaster(a)internic.net >Subject: EMERGENCY TLD .ES >Cc: cert(a)rediris.es, Mark Kosters <markk(a)internic.net>, hostmaster(a)nic.es > > > >Dear hostmaster, > >I am the technical contact of the top level domain for Spain (".es"). > >Much to our surprise we discover yesterday that a new unauthorized NS was >popping up in everybody's caches for the ".es" zone. > >At first we thought that a cache infection attack (the kind of Alternic's >against InterNIC) was taking place and spread the word that everybody in >the country upgrade to the recent versions of BIND. > >However, some places running BIND-4.9.6 and 8.1.1 were also infected!!! > >We the went to check InterNIC's database and ... the problem is there!!! > >InterNIC has made a change in the delegation of the ".es" zone without >our request, knowledge or consent. Instead of the authorized nameservers >which are: > > SUN.REDIRIS.ES 130.206.1.2 > CHICO.REDIRIS.ES 130.206.1.3 > PRADES.CESCA.ES 192.94.163.152 > NS.EUNET.ES 193.127.1.11 > SUNIC.SUNET.SE 192.36.125.2 192.36.148.18 > NS.EU.NET 192.16.202.11 > RS0.INTERNIC.NET 198.41.0.5 > NS.UU.NET 137.39.1.3 > MUNNARI.OZ.AU 128.250.1.21 128.250.22.2 > >You have now: > > SUN.REDIRIS.ES 130.206.1.2 > CHICO.REDIRIS.ES 130.206.1.3 > PRADES.CESCA.ES 192.94.163.152 > LINUX2.DYCSA.ES 195.53.97.1 > SUNIC.SUNET.SE 192.36.125.2 192.36.148.18 > NS.EU.NET 192.16.202.11 > RS0.INTERNIC.NET 198.41.0.5 > NS.UU.NET 137.39.1.3 > >For unkown reasons an unauthorized change has been made to the root >zone and the InterNIC database. You have placed a bogus NS >LINUX2.DYCSA.ES instead of the legal one: NS.EUNET.ES !!! > >Please CORRECT this as soon as possible and restart the root server. > >We would also like that you open an investigation about this case >to know if this has been caused by some InterNIC's internal error >or by an intentional ill will request made by someone. > >Please keep as inform about your actions to correct this error and >of the results of your internal investigation. > >Regards, > >Miguel A. Sanz (MAS122) >ES-NIC > >__________________ __ ______________________ > /_/ >Miguel A. Sanz __ __ Email: miguel.sanz(a)rediris.es >RedIRIS/CSIC /_/ RedIRIS /_/ Tel: + 34 1 5855152 >Serrano 142 __ Fax: + 34 1 5855146 >E-28006 Madrid /_/ >SPAIN Network Manager >____________ Spanish Academic & Research Network ________________________ > > > > >---End of forwarded mail from "Miguel A. Sanz. RedIRIS/CSIC" ><miguel.sanz(a)rediris.es> > > >---End of forwarded mail from "Miguel A. Sanz. RedIRIS/CSIC" ><miguel.sanz(a)rediris.es> > > ============================================================================ ==== Eric Germann Computer and Communications Technologies ekgermann(a)cctec.com Van Wert, OH 45891 Phone: 419 968 2640 http://www.cctec.com Fax: 419 968 2641 Network Design, Connectivity & System Integration Services A Microsoft Solution Provider

3 2