June 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

Re: Verisign vs. ICANN
by Paul Vixie 17 Aug '04

17 Aug '04

> Anything I/we can do to help the cause? not at the moment. i'm not a defendant, just a named co-conspirator.

15 23

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

Companies that sell NEBS x86 servers
by james edwards 01 Jul '04

01 Jul '04

I have gotten quotes from alliancesystems & crystalpc for a x86 NEBS DC powered server. Can anyone suggest some other companies that sell x86 NEBS servers ? -- James H. Edwards Routing and Security At the Santa Fe Office: Internet at Cyber Mesa jamesh(a)cybermesa.com noc(a)cybermesa.com (505) 795-7101

2 2

E-Mail Snooping Ruled Permissible
by John Neiberger 01 Jul '04

01 Jul '04

http://wired.com/news/print/0,1294,64043,00.html Yet another reason why we should develop a system where all Internet communications can be easily encrypted, whether it's email, VoIP, or whatever. It's not like it's horribly difficult now in some cases, but it does have its difficulties when it comes to implementation on a large scale. John --

9 8

Appeals court deals setback to spammers
by Henry Linneweh 01 Jul '04

01 Jul '04

One more feather in our cap :) http://seattletimes.nwsource.com/html/businesstechnology/2001968539_spam30.…

3 2

RE: Companies that sell NEBS x86 servers
by Burton, Chris 30 Jun '04

30 Jun '04

Depending on the server size and processing power requirements HP has the "CC" line of servers. They are available for the most part with AC or DC power supplies in x86 configurations. http://www.hp.com/products1/servers/carrier_grade/ Chris Burton Network Engineer Walt Disney Internet Group: Network Services The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact Walt Disney Internet Group at 206-664-4000. -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of james edwards Sent: Wednesday, June 30, 2004 3:43 PM To: nanog(a)merit.edu Subject: Companies that sell NEBS x86 servers I have gotten quotes from alliancesystems & crystalpc for a x86 NEBS DC powered server. Can anyone suggest some other companies that sell x86 NEBS servers ? -- James H. Edwards Routing and Security At the Santa Fe Office: Internet at Cyber Mesa jamesh(a)cybermesa.com noc(a)cybermesa.com (505) 795-7101

1 0

(UPDATE) Can a Customer take their IP's with them? (Court says yes!)
by Alex Rubenstein 30 Jun '04

30 Jun '04

* Alex Yuriev wrote: > Judge grants the TRO. > Defendant waves arms on nanog-l. > > Moral - > > When a legal system is involved, use the legal system, not the > nanog-l. The former provides provides ample of opportunities to > deal with the issues, while the later only provides ample of > opportunities to do hand waving. I would like to make a few comments on this and other posts that have been made in response to my original post last night. First of all, there is no question that there is a contractual dispute between NAC and the Customer. There is a lengthy complaint filed by the Customer against NAC, alleging a variety of things. Next, the more important issue. While there is a dispute between NAC and the Customer, as mentioned above, I am *NOT LOOKING FOR COMMENTS ON THE ACTUAL LAWSUIT* from nanog-l. I am not waving my arms about the lawsuit, as Alex implies above. What I AM looking for is a commentary from the internet community, strictly relating to the fact that a judge has issued a TRO that forces an ISP (NAC) to allow a third-party, who WILL NOT be a Customer of NAC, to be able to use IP Space allocated to NAC. In other words, I am asking people to if they agree with my position, lawsuit or not, that non-portable IP's should not be portable between parties, especially by a state superior court ordered TRO. This issue has been misunderstood, in that there is belief by some that the Customer should be allowed some period of grace for renumbering. I want to remind people that this Customer has had ARIN allocations for over 15 months. Also, recall that Customer has terminated service with us, and we would still allow them to be a Customer of ours if they so choose. This fact is undisputed as evidenced by the filing of certain public documents. With the above being said, I solicit comments on the following certification: Those would like to make a certification on behalf of their business: http://www.nac.net/cert.pdf Those would like to make a certification on behalf of themselves: http://www.nac.net/pcert.pdf Forgetting the facts of the case, for the moment, I think we all agree with the terms of this certification. The above does not ask for anyone to form an opinion about the case. It asks Internet Operators, as a community, if portability of non portable space is bad. If you agree, I ask you to execute this certification as an amicus brief, and fax it to us at 973-590-5080. Thank you for your time on this matter, it is truly appreciated. Please do not take the above that I do not appreciate all the commentary. As I say above, my point is that I am not trying to have a trial in a public forum, but, more importantly, I am verifying that our opinion regarding IP portability is one that the community as a whole shares. -- Alex Rubenstein, AR97, K2AHR, alex(a)nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --

15 18

EFF Publishes Patent Hit List
by Henry Linneweh 30 Jun '04

30 Jun '04

This is a very serious list, because it addresses the basic idea of being able to do business for everyone without being heald hostage by patents who work against the best interests of keeping the interent open.... http://www.wired.com/news/politics/0,1283,64038,00.html?tw=wn_tophead_2

1 0