May 2004 - Test - lists.nanog.org

FW: hey had eric sent you
by Riley, Marty 19 Aug '04

19 Aug '04

I'm running short on theories and options, so I thought I would see if any other ISPs have seen this problem on your network(s). If so, what was the cure? mjr -----Original Message----- The Unknown problem. Symptoms: At random times dialup, dedicated, & internal network users are unable to pass TCP traffic to off network sites. ICMP and UDP appears to be uneffected by the outage which lasts anywhere from 2 to 5 minutes. The problem appears to be wide spread with similar reports from WVNET and other ISPS. nTelos is experiencing a similar problem but we have yet to confirm it is the same. Problem has changed in it's action but remained similar enough to consider it the same problem. Effected Platforms: Windows 2000 Pro, XP Home, XP Pro, & 2003 Server. Uneffected Platforms: Unix, MacOS (?) History: During the week of 2/9/04 the call center started recieving reports of users being unable to connect to sites off the CityNet network. Sites hosted on the internal network are uneffected by the outage. Initally it was thought to be a Internet Explorer problem possably caused by the KB832894 / IE SP1 or other updates but after further investigation it was found that Mozilla users were encountering the same problem. After several days of testing it was determined that during the outage any TCP session started on any port would fail. TCP sessions started before the outage continue to work and show no ill effects from the outage. After logging connection attempts at various intervals on many machines there appears to be no sort of pattern in the outages. Most machines encounter the problem, some more than others and a few do not encounter it at all. The duration and frequency of the outage is very fluid. During an outage, we can verify that the packet does seem to leave and reenter the network: Mar 5 22:28:04 pittpa-chaswv-ds3 17083: SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.14.174(3376) -> 216.41.224.3(80), 1 packet Mar 5 22:28:09 pittpa-chaswv-ds3 17084: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.14.174(3376), 1 packet Mar 5 22:28:09 pittpa-chaswv-ds3 17085: SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.14.174(3378) -> 216.41.224.3(80), 1 packet Mar 5 22:28:09 pittpa-chaswv-ds3 17086: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.14.174(3378), 1 packet Mar 5 22:33:24 pittpa-chaswv-ds3 17089: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.14.174(3378), 7 packets Mar 5 22:33:24 pittpa-chaswv-ds3 17090: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.14.174(3376), 17 packets Mar 5 22:33:58 pittpa-chaswv-ds3 17092: SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.14.174(3378) -> 216.41.224.3(80), 7 packets Mar 5 22:33:58 pittpa-chaswv-ds3 17093: SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.14.174(3376) -> 216.41.224.3(80), 18 packets Mar 5 00:58:30 pittpa-clarwv-ds3 16062: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3183) -> 216.41.224.3(80), 1 packet Mar 5 00:58:30 pittpa-clarwv-ds3 16063: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3183), 1 packet Mar 5 01:03:28 pittpa-clarwv-ds3 16067: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3217) -> 216.41.224.3(80), 1 packet Mar 5 01:03:28 pittpa-clarwv-ds3 16068: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3217), 1 packet Mar 5 01:03:34 pittpa-clarwv-ds3 16069: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3228) -> 216.41.224.3(80), 1 packet Mar 5 01:03:34 pittpa-clarwv-ds3 16070: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3228), 1 packet Mar 5 01:03:39 pittpa-clarwv-ds3 16072: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3239) -> 216.41.224.3(80), 1 packet Mar 5 01:03:47 pittpa-clarwv-ds3 16073: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3183) -> 216.41.224.3(80), 74 packets Mar 5 01:04:13 pittpa-clarwv-ds3 16075: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3183), 72 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16078: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3218) -> 216.41.224.3(80), 4 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16079: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3217) -> 216.41.224.3(80), 3 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16080: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3221) -> 216.41.224.3(80), 19 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16081: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3228) -> 216.41.224.3(80), 5 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16082: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3229) -> 216.41.224.3(80), 6 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16083: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3236) -> 216.41.224.3(80), 9 packets Mar 5 01:08:47 pittpa-clarwv-ds3 16084: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3233) -> 216.41.224.3(80), 12 packets Mar 5 01:08:47 pittpa-clarwv-ds3 16085: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3239) -> 216.41.224.3(80), 21 packets Mar 5 01:09:12 pittpa-clarwv-ds3 16087: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3239), 19 packets Mar 5 01:09:12 pittpa-clarwv-ds3 16088: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3228), 4 packets Mar 5 01:09:12 pittpa-clarwv-ds3 16089: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3217), 2 packets Mar 5 01:09:12 pittpa-clarwv-ds3 16091: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3218), 3 packets Mar 5 01:09:13 pittpa-clarwv-ds3 16092: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3221), 17 packets Mar 5 01:09:13 pittpa-clarwv-ds3 16093: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3229), 5 packets Mar 5 01:09:13 pittpa-clarwv-ds3 16094: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3236), 7 packets Mar 5 01:09:13 pittpa-clarwv-ds3 16096: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3233), 9 packets Network analysis showed significant amounts of spoofed multicast traffic and odd arp traffic. 10:17:16.416222 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 278 10:17:16.421886 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 334 10:17:16.423873 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 262 10:17:16.426948 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 254 10:17:16.432095 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 298 10:17:16.435921 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 274 10:17:16.439959 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 328 10:17:16.445317 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 326 10:17:16.449688 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 330 10:17:16.463537 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 322 Steps were taken to elminiate the spoofed traffic on the routers and access servers in the form of ACLs and filter lists. Neither have eliminiated the problem... but to what extent they might have helped has yet to be determined. The problem is still occuring, for some users the duration of the outage seems to have shortened other users notice no difference. It is not yet known if the filtering on the routers and access servers or the conversion to the 10.x.x.x network has made any difference. We should have a better idea in the upcoming days. What Doesn't help: Removing windows updates. Turning off XP firewall. Searching for malware. (SpyBot-SD, Adaware) Virus scanning (Various softwares) Specifying dns servers. Reinstalling windows.

7 6

Barracuda Networks Spam Firewall
by Claydon, Tom 28 Jul '04

28 Jul '04

Doing evaluations on anti-spam, anti-virus solutions, and ran across this: http://www.barracudanetworks.com/ Looks like a good box -- even won an Editor's Choice award from Network Computing recently. Does anyone on list have any experience with these boxes? If so, how are they with false positives, quarantine capabilities, etc? Thanks, Tom Claydon Dobson Telephone

27 46

RE: SPAM Directly from AT&T Data Networking
by Callahan, Richard M, GVSOL 05 Jul '04

05 Jul '04

As much as I hate to open this can of worms, I am online, I do work for AT&T and I do have a vested interest in SPAM and other ISP related issues. Some of you may recall I was the naive idiot that allowed AT&T to launch the Do Not Call Registry without first learning the rules, etiquette and proper structure of email. It caused a stir among many of you nanog'ers and a major pain for AT&T in email blocking and other unintended consequences. As the Government pushes through the maze in an effort to make sense of the CANSPAM Act, I continue to stay engaged and am most definitely an anti-spam proponent. When I saw Mr. Lorenz's post I immediately verified it did indeed come from AT&T and called the responsible party. Having spoken directly to her, I would like to point out that she did indeed take the time to research the FCC SPAM laws and has stuck to them. She has provided an opt-out message and assures me she takes it very seriously. If you have responded to her with a request to NOT be contacted again, you have not been. The other side of this coin is her responsibilities are to sell specifically to ISP's, she is young, aggressive and very successful. AT&T's new rate structure has been significantly reduced and this was an expedient way to get the word out. For nearly 80% of those on her mail list, there has been a very positive response and many smiling faces at the money they will be saving. I do not mean this to be a sales pitch, just a different perspective. My apologies to those that are/were offended. I will monitor all input from nanog on this communication chain and forward my (and your) thoughts to Ms. Macker for consideration and appropriate action. Thanks for listening!! Richard Callahan -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Dr. Jeffrey Race Sent: Wednesday, April 14, 2004 2:40 PM To: nanog(a)merit.edu Subject: Re: SPAM Directly from AT&T Data Networking In the last few days I have had two spams with injection point 127.0.0.1. This definitely needs to be addressed by ATT. Anyone online from ATT like to say something? Jeffrey Race On Wed, 14 Apr 2004 14:17:08 -0400 (EDT), William R. Lorenz wrote: > >So, with AT&T being a network provider at all, is it just customary for >them to SPAM like this? This is the second one I've received from them. >

8 8

Re: best effort has economic problems
by Gordon Cook 02 Jun '04

02 Jun '04

may I make just a passing observation? From a technology point of view the best effort internet certainly "works." Not surprisingly the comments here are primarily debating the finer points of the technology. The point I am making in my report is NOT that the best effort network has technology problems but rather that it has ECONOMIC PROBLEMS. That it might support 2 or 3 players not 2 or 3 HUNDRED. That until companies begin to go chapter seven and vanish, the best effort net will be a black hole that burns up capital because, for many players, the OPERATIONAL expense is more than they get for bandwidth never mind cap-ex. best effort won't go away. many best effort players will. for the time being, best effort bandwidth prices as an absolute commodity cannot sustain networks over the long haul. A network that can deliver QoS the report hypothesizes may be able to attract enough revenue to become profitable. How to to this my group is still discussing. We don't pretend that QoS is easy or any kind of mature collection of technologies, but increasingly it looks as though the industry, if it is ever going to be self sustaining, really needs to look at QoS services and solutions. >On Sat, 29 May 2004, Edward B. Dreger wrote: > >> Nitpicking: Latency isn't that important with unidirectional >> communication. However, VoIP users seem reasonably happy with >> current latency and jitter -- and the Internet still is _largely_ >> xxTP, anyway... particularly if one ignores peer-to-peer file- >> swapping programs. > >Latency is fine for VOIP as long as you dont interact with the PSTN >network, if you want to interact with PSTN then you need echo >cancellation if you have high latency on the IP part. > >Most VOIP applications can handle 40ms jitter, so that's normally no >problem unless your local access is full. Packet loss is normally no >problem for VOIP if you use a proper (non-telco developed) codec. > >VOIP is actually better off with high packet loss and low jitter than the >other way around (throwing off the old truth that core equipment should >have lots of buffers). > >-- >Mikael Abrahamsson email: swmike(a)swm.pp.se -- ============================================================= The COOK Report on Internet Protocol, 431 Greenway Ave, Ewing, NJ 08618 USA 609 882-2572 (PSTN) 703 738-6031 (Vonage) Subscription info & prices at http://cookreport.com/subscriptions.shtml Report on economic black hole of best effort networks at: http://cookreport.com/13.04.shtml E-mail cook(a)cookreport.com =============================================================

12 15

a small note for the Internet archives
by Peter Lothberg 31 May '04

31 May '04

RP/0/RP0/CPU0:sl-bb-stk#sh int pos 0/1/0/0 POS0/1/0/0 is up, line protocol is up Hardware is Packet over SONET Description: To sl-bbh-sj POS0/2/0/0 OC768 to SL-BB-SJC Internet address is 144.232.8.30/30 MTU 4474 bytes, BW 39813120 Kbit reliability 255/255, txload 11/255, rxload 16/255 Encapsulation HDLC, crc 32, controller loopback not set, keepalive set (10 sec) Last clearing of "show interface" counters 00:54:50 30 second input rate 2556047000 bits/sec, 601233 packets/sec 30 second output rate 1778638000 bits/sec, 511869 packets/sec 1666954975 packets input, 858714019017 bytes, 1 total input drops 0 drops for unrecognized upper-level protocol Received 0 broadcast packets, 0 multicast packets 0 runts, 0 giants, 0 throttles, 0 parity 1 input errors, 1 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 1493380753 packets output, 636636581471 bytes, 0 total output drops Output 0 broadcast packets, 0 multicast packets 0 output errors, 0 underruns, 0 applique, 0 resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions RP/0/RP0/CPU0:sl-bb-stk#sh control sonet 0/1/0/0 Port SONET0/1/0/0: Status: Up Loopback: None SECTION LOF = 0 LOS = 0 BIP(B1) = 1 LINE AIS = 0 RDI = 0 FEBE = 0 BIP(B2) = 1 PATH AIS = 0 RDI = 0 FEBE = 0 BIP(B3) = 1 LOP = 0 NEWPTR = 0 PSE = 0 NSE = 0 Line triggers delayed 20 msDetected Alarms: None Asserted Alarms: None Mask for Detected->Asserted: None Detected Alerts: None Reported Alerts: None Mask for Detected->Reported: None Alarm reporting enabled for: SLOS SLOF SF_BER PLOP Alert reporting enabled for: B1-TCA B2-TCA B3-TCA Framing: SONET SPE Scrambling: Enabled C2 State: Stable C2_rx = 0x16 (22) C2_tx = 0x16 (22) / Scrambling Derived S1S0(tx): 0x0 / Framing Derived PATH TRACE BUFFER : STABLE Remote hostname : sl-bb-sj Remote interface: POS0_2_0_0 Remote IP addr : 144.232.8.29 Remote Rx(K1/K2): 00/00 Remote Tx(K1/K2): 00/00 BER thresholds: SF = 10e-3 SD = 10e-6 TCA thresholds: B1 = 10e-6 B2 = 10e-6 B3 = 10e-6 Optics type: VSR2000-3R2 (2km) Clock source: line (actual) line (configured) Optical Power Monitoring (accuracy: +/- 1dB) Rx power = 1562.3280 mW, 31.9 dBm Tx power = 15.4640 mW, 11.9 dBm Tx laser current bias = 96.2 mA

4 3

Re: [url correction] Cable networks RE: best effort has economic problems, maybe OT
by frank＠dticonsulting.com 31 May '04

31 May '04

Correcting a previous url error on my part. Narad's site is at: http://www.naradnetworks.com Sorry 'bout that, folks. Frank On Mon, 31 May 2004 11:30 , <frank(a)dticonsulting.com> sent: > >Agree, this is a great discussion, akin to a recent Cook Report accounting of best >effort considerations. Several startups (now going into year two) have addressed >the cable-HF/C constraints you've mentioned. You may be interested in perusing >these two: > >http://www.narad.com > >Another, Rainmaker Technologies... > >http://www.rainmakertechnologies.com > >.... appears to have fallen on hard times while seeking later round funding. Not >sure of their disposition at this time, but doing googles on their name reveal >some good articles on their approach to using wavelets to improve bit gain over >black coax/fiber systems to homes and businesses. > >Metcalfe has financial backing hooks and input into Narad, and Mark E. Laubach of >COM21 fame (ATM over HF/C) heads up (headed up?) Rainmaker's technical pursuits. > >[[As an aside, I'm finding increased interest in corporate parks (especially those >that are boondocks-bound) where MSO fiber-based offerings are being seriously >considered for WAN access, both of the type discussed above and enterprise- >tailored rings coming off local head-ends.]] > >Frank > > >On Sun, 30 May 2004 08:47 , 'Christopher J. Wolff' chris(a)bblabs.com> sent: > >> >>Folks, >> >>This is a great discussion. I'm interested in understanding these types of >>limitations in the context of HFC cable networks. In my opinion, HDTV >>channel bandwidth (30mhz?) , increased demand for voip, and growing demand >>for IP connectivity is going to stress the cable network model as well, >>forcing cable operators to convert everything to IP before going out across >>the wire. Any input is appreciated. >> >>Regards, >>Christopher >> > > > >

2 1

Re: What HTTP exploit?
by Mike Nice 31 May '04

31 May '04

>It seems to be another stupid Microsoft Exploit that just >causes annoyance for Unix Boxes. >The only side effect is they fill my dmesg logs with >signal 11's from apache crashing. Am I the only one that sees the irony that Apache seg faults from an attack aimed at Msoft?!

6 5

Tracking the bad guys
by Sean Donelan 31 May '04

31 May '04

Microsoft now employs 100 people with a budget of $10 million dollars (Ok, if you do the math, the average salary is a bit low if they also have benefits or any equipment) to track down people attacking Microsoft's Hotmail service, online fruad, identity theft and spyware. The Direct Marketing Association pays 15 detectives $500,000 (even a lower salary) to work with FBI agents (which are paid government salaries). http://www.iht.com/articles/522553.html "Initially you start to work backwards from the e-mail and find that to be a very frustrating route," said Daniel Larkin, chief of the FBI's Internet Crime Complaint Center, the unit that is coordinating Project Slam Spam. "that doesn't lead to a live body. We have collectively realized you have to go the other way and follow the money trail."

5 4

Re: Cable networks RE: best effort has economic problems, maybe OT
by frank＠dticonsulting.com 31 May '04

31 May '04

Agree, this is a great discussion, akin to a recent Cook Report accounting of best effort considerations. Several startups (now going into year two) have addressed the cable-HF/C constraints you've mentioned. You may be interested in perusing these two: http://www.narad.com Another, Rainmaker Technologies... http://www.rainmakertechnologies.com .... appears to have fallen on hard times while seeking later round funding. Not sure of their disposition at this time, but doing googles on their name reveal some good articles on their approach to using wavelets to improve bit gain over black coax/fiber systems to homes and businesses. Metcalfe has financial backing hooks and input into Narad, and Mark E. Laubach of COM21 fame (ATM over HF/C) heads up (headed up?) Rainmaker's technical pursuits. [[As an aside, I'm finding increased interest in corporate parks (especially those that are boondocks-bound) where MSO fiber-based offerings are being seriously considered for WAN access, both of the type discussed above and enterprise- tailored rings coming off local head-ends.]] Frank On Sun, 30 May 2004 08:47 , 'Christopher J. Wolff' <chris(a)bblabs.com> sent: > >Folks, > >This is a great discussion. I'm interested in understanding these types of >limitations in the context of HFC cable networks. In my opinion, HDTV >channel bandwidth (30mhz?) , increased demand for voip, and growing demand >for IP connectivity is going to stress the cable network model as well, >forcing cable operators to convert everything to IP before going out across >the wire. Any input is appreciated. > >Regards, >Christopher >

1 0

What HTTP exploit?
by John Palmer (NANOG Acct) 31 May '04

31 May '04

Can anyone identify this http exploit? Seen in the apache logs: foo.bar.com - - [30/May/2004:02:45:28 -0400] "SEARCH /\x90\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\ x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb 1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\ xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1 etc - and it goes on for about 1200 bytes. Been getting an annoying number of these in my httpd logs today - it botches up my log analyser program.

5 4