- Test - lists.nanog.org

Barrages of Packet Errors
by webmagician＠altern.org 09 Jul '04

09 Jul '04

Hopefully this is not an off-topic posting. I've scanned a variety of groups looking to see if anyone else has encountered a similar problem, to no avail, and I simply thought this might be the most appropriate place to post an inquiry. I'm not a service provider, simply a small business operator with a few servers, providing business clients with mostly standard web and email type services. A couple of nights ago my systems started experiencing a sharp increase in DNS traffic generating a new flavor of error messages. I'd like to know if anyone else out there noticed similar DNS errors in the past couple of days. The barrage first hit at roughly 9:15pm (Mountain Std Time) on June 28th and lasted only a few minutes. It repeated again at 9:25pm, and then again at roughly 9:38pm, and a 4th round at 10:06pm. I fired up ethereal shortly after the 4th battery in the hopes of capturing additional data, but there was no further activity, and I shut ethereal down the next morning (June 29th). However, later in the morning of the 29th the problem resurfaced, first at roughly 10am, then at 11:00am, 11:30am, and a final blast at 11:45am. Unfortunately I wasn't around during those barrages, so again I missed the opportunity to collect additional information - I only noticed it had happened while reviewing the server logs later that afternoon. The errors haven't re-occurred since. The error messages are all the same (other than the inbound IP address causing the errors). The error message is as follows: "DNS Server encountered bad packet from 192.5.6.30. Packet processing leads beyond packet length." After extracting and sorting the error messages from the server log, I noticed the errors were associated with about 3 dozen IP addresses. The list of IP's associated with the packets that were generating the errors is as follows: 128.63.2.53 = h.root-servers.net 128.9.0.107 = ns1.isi.edu 152.163.159.234 = dns-01.icq.net 192.112.36.4 = g.root-servers.net 192.12.94.32 = aloe.arin.net 192.203.230.10 = e.root-servers.net 192.228.79.201 = b.root-servers.net 192.26.92.30 = c.gtld-servers.net 192.33.14.30 = b.gtld-servers.net 192.33.4.12 = c.root-servers.net 192.35.51.32 = dill.arin.net 192.36.148.17 = i.root-servers.net 192.42.93.30 = g.gtld-servers.net 192.5.5.241 = f.root-servers.net 192.5.6.30 = a.gtld-servers.net 192.5.6.32 = a3.nstld.com 192.54.112.30 = h.gtld-servers.net 192.58.128.30 = j.root-servers.net 193.0.14.129 = k.root-servers.net 193.205.245.8 = dns2.nic.it 198.32.64.12 = l.root-servers.net 198.41.0.4 = a.root-servers.net 198.96.180.33 = ns1.bmo.com 198.96.183.6 = ns2.bmo.com 199.191.128.105 = cbru.br.ns.els-gms.att.net 199.191.145.136 = macu.ma.mt.np.els-gms.att.net 202.12.27.33 = m.root-servers.net 204.152.185.196 = west-pub.mail-abuse.org 205.188.157.232 = dns-02.ns.aol.com 205.188.157.234 = dns-02.icq.net 209.182.216.75 = ns1.gnac.net 209.237.237.10 = dns1-public.alexa.com 209.47.26.190 = ns.uunet.ca 216.239.34.10 = ns2.google.com 216.239.38.10 = ns4.google.com 35.9.116.13 = serv1.cl.msu.edu 64.4.240.70 = ns1.nix.paypal.com 64.4.240.71 = ns2.nix.paypal.com 64.4.244.70 = ns1.sc5.paypal.com 64.4.244.71 = ns2.sc5.paypal.com I never assume anything happens "by chance" when it comes to anomalies in any of my systems log files, particularly when it's something brand new (I've never encountered this particular error in the past 7 years or so, so it set bells ringing to examine the problem more closely) (and there was nothing different or non-normal in the way of user activity or other processing, etc. at any time prior to or during these 'events'). My initial guess is it's someone trying out some new attack vector attempting to exploit yet another buffer overflow problem in windoze, but the strange thing is that the IP's are all (with the exception of a couple) associated with top-level domain servers (or am I mistaken in that assessment?). I'm not a network specialist by any stretch of the imagination, my skill-sets are in other areas, so I'm afraid I haven't much else to add in the way of information about this problem. I'm just looking to bring it to the attention of those who do have the knowledge/experience in this area in case it's a problem of some significance where forewarning may prove useful to others. Thank you. Brian Pederson Chief Technology Officer TeamWorx Productions Ltd.

3 2

Re: "it appears a beaver picked it up and chewed it in half"
by Robert Bonomi 09 Jul '04

09 Jul '04

> From owner-nanog(a)merit.edu Thu Jul 8 23:42:27 2004 > From: "Scot Bryhan" <dsbryhan(a)chartermi.net> > To: <nanog(a)merit.edu> > Subject: "it appears a beaver picked it up and chewed it in half" > Date: Fri, 9 Jul 2004 00:38:50 -0400 > > > > Scot, > > > > Here's what we received from the Assocaited Press. > > > > > > -- > > Kendall P. Stanley > > Managing editor > > Petoskey News-Review > > (231) 439-9349 > > (231) 881-4349 (cell) > > > > > > By JOHN FLESHER > > Associated Press Writer > > TRAVERSE CITY, Mich. _ Northeastern Michigan had a problem to chew > on: > > Long-distance phone service was interrupted for more than six hours after > a > > beaver apparently gnawed through a fiber optic cable. > > > > "In my 33 years with the company I've never heard of this happening," said > > John VanWyck, spokesman for Verizon Communications. "I've heard of > squirrels > > chewing aerial cable, but not this." John apparently leads a rather sheltered life. <grin> Northwestern University, in Evanston, IL, has a substantial squirrel population on/near the campus. One which apparently does _not_ 'learn from experience', I might add. All the campus utilities are underground, including the (dual, redundant, diversely routed) main feeds from the local electric utility. At about 2 year intervals, the livestock manages to find a way into one or the other of the electric feed tunnels. 'whatever it is' that the cable manufacturers use to insulate high-voltage high-ampacity wiring with, the local squirrel population finds it to be irresistable. "Pretty soon there was a 'squirrel boom'", and all the 'non-critical' stuff on half the campus goes dark. Note: the 'squirrel boom' is rather impressive -- sounds like the big brother of an M-80 firecracker/simulated morter round. The fault does tend to be self-clearing -- the only physical evidence of the perpetrator is a grease stain for several feet surrounding. plus a distinctive stink. > From owner-nanog(a)merit.edu Thu Jul 8 23:17:23 2004 > From: "John Ferriby" <john(a)ferriby.com> > To: <nanog(a)merit.edu> > Subject: RE: concern over public peering points [WAS: Peering point speed publicly available?] > Date: Fri, 9 Jul 2004 00:14:39 -0400 > > > On Wednesday 07 July 2004 02:43 am, Valdis.Kletnieks(a)vt.edu wrote: > > Which almost begs the question - what's the oddest "WTF??" anybody's > > willing to admit finding under a raised floor, or up in a ceiling or cable > > chase or similar location? (Feel free to change names to protect the > guilty > > if need be....:) > > Raccoons. Came in late one night and heard noises that I didn't > really expect. Turns out the facility had diverse entrances and > multiple conduits - and one of them had been exposed outside due > to some erosion and had been damaged. We found little surprises > for quite awhile after that. > > Undergarments and shoes. His and hers, but no other clothing. Not 'raised-floor', but qualifies for retelling due to the manner in which the situation was dealt with -- When: 50+ years ago. Locale: An urban newspaper, the office of the (personally quite conservative, but not moralizing) editor-in-chief. Found: A brassiere, under the cushions of the couch in his office. Result: Memo to _all_ staff, announcing the 'find', and requesting that the 'rightful owner thereof' please reclaim their property. Follow-up memo, a couple of days later, when there had been no results from the first one -- again requesting the owner to claim their property, and an announcement that if _not_ claimed, the boss was considering 'holding fittings', to ensure that the lost property WOULD be returned to its rightful owner. [And that is where the story ends -- except to note that "fittings" were _not_ held; there was never any identifiable 'fallout' from the event, in any way.)

1 0

RE: 802.17 RPR and L2 Ethernet interoperablity (Ethernet over RPR)
by Vinay Bannai 09 Jul '04

09 Jul '04

>Hi, > >This is probably a fairly simply question, I'm probably just not quite >groking the layers involved here. > >If I had the following setup: > >Endstation A -- Switch A === RPR Ring === Switch B -- Endstation B > >could there be a VLAN setup such that Endstations A and B are both in it, >and can communicate as if they are on the same LAN segment? (And I mean >natively. ie. not using an MPLS VPN). ie. Will the switches involved >tranlate the different framing formats in use? Is this vendor dependent? > >Sam According to the IEEE 802.17 PAR five criteria, RPR is supposed to satisfy the bridging requirements. In other words, a RPR node on a RPR ring connected to a ethernet switch as shown in your diagram should work transparently. There should be no reason to require MPLS VPNs to make this happen. Having said that your mileage varies depending on the vendor. Most RPR systems are targeted towards the metro space and the core and tend not to use transparent bridging. MAC-in-MAC is one of the mechanisms being used to "bridge" the network between 802.17 and 802.3 networks. Vinay Bannai Luminous Networks

1 0

RE: [WAY OT]: concern over public peering points...
by Stewart, William C (Bill), RTSLS 08 Jul '04

08 Jul '04

Steve wrote: > water - 8" of it Scary stuff - was that at Murray Hill? My department at Holmdel inherited a computer lab with various Vaxen, and more obvious problem under the raised floor was too much cable to get all the tiles to stay down. The less obvious problems had to do with unbalanced grounding on the power feeds, but at least it was dry. Edward Lewis wrote: > [Secure building with a Mac FOIRL'd to unsecured building with thinwire; > security officer said it was ok] And it probably was ok, at least if you're allowed to have the Mac with a networking connection to outside at all. The fiber connection means that it's not going to act as an antenna and leak out data that didn't get there from in or very near the Mac. We used printers inside and OCR outside as our data network for nonsensitive data; I tried to buy a paper tape punch and reader but by the late 80s DEC wasn't making those any more :-) Bill Stewart

2 1

Source of dictionary MTA attacks
by Jon R. Kibler 08 Jul '04

08 Jul '04

Greetings, In the past 10 hours, we have had over 5,000 dictionary MTA attacks originate from IPs in the 67.234.73.0/24 netblock, which appear to be uu.net (MCI) dial access IPs in the Dallas-Ft. Worth area. We have notified MCI and blocked this netblock at the border. Something interesting about this attack... the attacking software generates dictionary addresses in groups ranging from 16 to 29 addresses. We have seen an almost identical number of dictionary probes for each count of dictionary addresses (i.e., X occurrences of 16 addresses/connection, X occurrences of 17...). Just a heads up... you may want to look out for these patterns. Jon Kibler -- Jon R. Kibler Chief Technical Officer A.S.E.T., Inc. Charleston, SC USA (843) 849-8214 ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email.

1 1

RE: [WAY OT]: concern over public peering points [WAS: Peering po int speed publicly available?]
by Williams, Jeff 08 Jul '04

08 Jul '04

Not really a "WTF" on my part, but... Many years ago I was hand tracing a cable in a data center due to the usual lack of docs and ensuing spaghetti factory. Said cable went under the three foot raised floor, so I dove in. I'd been going for a while and was getting concerned that I'd accidentally gotten hold of the wrong cable, so I called back to my co-worker to give it a tug. No response. I decided to come up for air and try again. I had crawled under two equipment rows and into the operator area and I can only imagine what that operator thought was happening when I just popped up through the floor next to her. Judging by the yelp and the look I got it was probably not good. Still gives me a chuckle thinking about it. Jeff -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Valdis.Kletnieks(a)vt.edu Sent: Wednesday, July 07, 2004 12:43 AM To: Leo Bicknell Cc: nanog(a)merit.edu Subject: Re: concern over public peering points [WAS: Peering point speed publicly available?] On Tue, 06 Jul 2004 08:46:49 EDT, Leo Bicknell <bicknell(a)ufp.org> said: > Everyone running their cable wherever they want with no controls, and > abandoning it all in place makes a huge mess, and is one way to think > about it. While clearing out the space that eventually ended up being repurposed for a supercomputer, we encountered a small run of Ethernet Classic - the thickwire stuff. We never did figure out how or why it got there (I doubt that anybody stashed it down there just for storage stretched straight out, with 3 vampire taps still attached), as the location in question was still cow pasture when we decided that all new cable would be thinwire (and we certainly had plenty of THAT under the floor, buried under all the cat-5...) And we're a small enough shop with low enough personnel turnover that rounding up *all* the possible co-conspirators and getting somebody to admit "Ahh... now there's a story attached to that wire..." usually doesn't take more than 3 or 4 pitchers of Guinness... ;) Which almost begs the question - what's the oddest "WTF??" anybody's willing to admit finding under a raised floor, or up in a ceiling or cable chase or similar location? (Feel free to change names to protect the guilty if need be....:) ************************************************************** This message, including any attachments, contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, please contact sender immediately by reply e-mail and destroy all copies. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. TIAA-CREF **************************************************************

2 1

[OT] Layer 2 Trace
by Vicky 08 Jul '04

08 Jul '04

Hi there, Just wondering if there's anyone who can recommend a layer 2 trace utility similar to "l2trace" on a cisco switch but one that runs on a linux box? Any help will be appreciated. regards, /vicky

1 0

RE: [WAY OT]: concern over public peering points [WAS: Peering po int speed publicly available?]
by rwcrowe＠comcast.net 08 Jul '04

08 Jul '04

I use to work for a growing .com before it went down. One project was to move the company from 5 or 6 suites in an executive campus to a newly built building about 10 miles down the road. Our IT team oversaw the construction of the datacenter from soup to nuts. We went through the whole drill over test patch panels and drops and made sure everthing worked. The only thing we didnt have to do (until the day we moved the servers over) was to look under the newly constructed raised floor. Well, long story short, we started moving the servers over and pulling up tiles to run the cables for them and behold we found a 12-pack and a half frozen pizza. Apparently the some of the workers had decided during the construction to put some beer and food under the floor to keep it cold and forgot about it. :) -- rwcrowe(a)comcast.net -------------- Original message -------------- > > Not really a "WTF" on my part, but... > > Many years ago I was hand tracing a cable in a data center due to the usual > lack of docs and ensuing spaghetti factory. Said cable went under the three > foot raised floor, so I dove in. I'd been going for a while and was getting > concerned that I'd accidentally gotten hold of the wrong cable, so I called > back to my co-worker to give it a tug. No response. I decided to come up > for air and try again. I had crawled under two equipment rows and into the > operator area and I can only imagine what that operator thought was > happening when I just popped up through the floor next to her. Judging by > the yelp and the look I got it was probably not good. Still gives me a > chuckle thinking about it. > > Jeff > > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of > Valdis.Kletnieks(a)vt.edu > Sent: Wednesday, July 07, 2004 12:43 AM > To: Leo Bicknell > Cc: nanog(a)merit.edu > Subject: Re: concern over public peering points [WAS: Peering point speed > publicly available?] > > > On Tue, 06 Jul 2004 08:46:49 EDT, Leo Bicknell said: > > > Everyone running their cable wherever they want with no controls, and > > abandoning it all in place makes a huge mess, and is one way to think > > about it. > > While clearing out the space that eventually ended up being repurposed for a > supercomputer, we encountered a small run of Ethernet Classic - the > thickwire stuff. We never did figure out how or why it got there (I doubt > that anybody stashed it down there just for storage stretched straight out, > with 3 vampire taps still attached), as the location in question was still > cow pasture when we decided that all new cable would be thinwire (and we > certainly had plenty of THAT under the floor, buried under all the cat-5...) > And we're a small enough shop with low enough personnel turnover that > rounding up *all* the possible co-conspirators and getting somebody to admit > "Ahh... now there's a story attached to that wire..." usually doesn't take > more than 3 or 4 pitchers of Guinness... ;) > > Which almost begs the question - what's the oddest "WTF??" anybody's willing > to admit finding under a raised floor, or up in a ceiling or cable chase or > similar location? (Feel free to change names to protect the guilty if need > be....:) > > > > > ************************************************************** > This message, including any attachments, contains confidential information > intended for a specific individual and purpose, and is protected by law. If you > are not the intended recipient, please contact sender immediately by reply > e-mail and destroy all copies. You are hereby notified that any disclosure, > copying, or distribution of this message, or the taking of any action based on > it, is strictly prohibited. > TIAA-CREF > ************************************************************** >

1 0

Relationship between DNS requests and server's CPU load
by Joe Shen 08 Jul '04

08 Jul '04

Hi, I want to know, is there any research or analysis on relationship between DNS server load ( e.g. CPU load, Memory utilized) and incoming DNS resolution requests ? Besides those research on name system architecture and cache policy, is there any guideline on planing or optimizing domain name service system ? thanks in advance. Joe Cool Things Happen When Mac Users Meet! Join the community in Boston this July: www.macworldexpo.com

1 0

Relationship between DNS requests and server's CPU load
by Joe Shen 08 Jul '04

08 Jul '04

Hi, I want to know, is there any research or analysis on relationship between DNS server load ( e.g. CPU load, Memory utilized) and incoming DNS resolution requests ? Besides those research on name system architecture and cache policy, is there any guideline on planing or optimizing domain name service system ? thanks in advance. Joe ---- Cool Things Happen When Mac Users Meet! Join the community in Boston this July: www.macworldexpo.com

1 0