- Test - lists.nanog.org

Announcing BGPlay - A Tool Hosted By the RIPE NCC that Visualises BGP Updates
by Matthew Williams 12 May '04

12 May '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear All, The Roma Tre University Computer Networks Research Group and the RIPE NCC are pleased to announce BGPlay, a new beta tool that can visualise BGP updates in the Routing Information Service's (RIS) database. Its animated, interactive graphical display makes it easier to interpret how BGP updates affect the routing of a specific prefix than by analysing the updates themselves. For an idea of what BGPlay can do, please visit the BGPlay web page at: http://www.ris.ripe.net/bgplay/ and click on the screenshot for an interactive help page. BGPlay was developed by the Computer Networks Research Group at Roma Tre University, and is hosted by the RIPE NCC, who provide direct access to the RIS database. Links to Respective Groups: * RIPE NCC Routing Information Service: http://www.ripe.net/ris/ * Roma Tre Computer Networks research Group: http://www.dia.uniroma3.it/~compunet/ Please note that BGPlay requires the Java browser plug-in version 1.4 or above (you can download it at http://www.java.com/en/download/ if you don't have it). If you have the Java plug-in installed, click on one of the links below for examples of BGPlay in action: 1. I.Net adds a new upstream: http://www.ris.ripe.net/cgi-bin/bgplay.cgi?prefix=194.185.0.0/16&start =2004-04-08+14:02&end=2004-04-08+14:04 2. Deutsche Telekom starts announcing a new network: http://www.ris.ripe.net/cgi-bin/bgplay.cgi?prefix=84.128.0.0/11&start= 2004-03-16+08:07&end=2004-03-16+08:10 3. A local instance of F root is leaked globally: http://www.ris.ripe.net/cgi-bin/bgplay.cgi?prefix=192.5.5.0/24&start=2 004-03-17+19:30&end=2004-03-18+22:00 4. An anycast prefix with multiple origin ASes: http://www.ris.ripe.net/cgi-bin/bgplay.cgi?prefix=192.88.99.0/24&start =2004-04-01+03:00&end=2004-04-01+20:00 For more information on BGPlay and to run queries of your own, visit the BGPlay web page at http://www.ris.ripe.net/bgplay/ Please send your comments to bgplay(a)dia.uniroma3.it and ris(a)ripe.net. Kind regards, Roma Tre University Computer Networks Research Group & the RIS Team at RIPE NCC --- > Matthew Williams (MW243-RIPE) > Customer Liaison Engineer > RIPE NCC - http://www.ripe.net/np/ -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBQKFudcHkFbJe+GdoEQKw+wCgtKBk1x7u243SphgxdF7ozyhqYRAAoLAw 6F+ERBNpTJyWGH0Voo0qggzF =RzQH -----END PGP SIGNATURE-----

1 0

WAN transfer rates
by Jeff Nelson 11 May '04

11 May '04

Possibly someone in this forum with a better understanding of tcp/ip can articulate this better than I.... I realize that transfer rates across the Internet diminish significantly with latency, but what's the good answer for someone shrunk down to <10Mbps when the smallest pipe between them is 100Mbps and latency is <40ms? Does anyone have reference to any study done in this area? I'm sure window tuning can alter this, but I'm interested in average statistics. Any reference would be appreciated. thanks, jeff

3 2

Re: WAN transfer rates
by Peter Lothberg 11 May '04

11 May '04

TCP is mostly a implemenation/parameter setting problem for resonable speeds, for high_speed, you can not drop packets. Have a look at proj.sunet.se/LSR2. 2 $1500 mail_order PC's, 40 router hops, almost around half of the earth. -Peter

2 1

Re: Spamcop
by Guðbjörn S. Hreinsson 11 May '04

11 May '04

> >. There have been no reminders from > > the mailing list since I signed up which I think is a good policy for a > > mailing list. The mailing list only uses "Precedence: bulk" to mark it as > > a mailing list. > > the list is pretty active, so i would dare say that reminders are > superfluous. an iq test at subscription time would probably work better to > prevent situations like this in the future. Right, the reminder may have no value for the intended recipient which is the one that signed up. However, in the case of an inherited email address this may be valuable. But an IQ test would be nice. What should be the I to test for? Rgds, -GSH

2 1

MightAnyone from swbell on the list? - large name scanning from your DSL
by Nicole 11 May '04

11 May '04

Well as the subject says.. 4 various mail servers (4 very different companies) are being heavily name guessing scanned via various machines on the xxxxxxx.dsl.rcsntx.swbell.net network. Been going on for a few days now. All from within this block and loads of it. Reported it but no response. Nicole -- |\ __ /| (`\ | o_o |__ ) ) // \\ - nmh(a)daemontech.com - Powered by FreeBSD - ------------------------------------------------------ "The term "daemons" is a Judeo-Christian pejorative. Such processes will now be known as "spiritual guides" -Politicaly Correct UNIX Page http://www.nonsenseband.com *** Spam Sucks and I get tons of it. So I have some tight spam filters. If any email to me bounces, please use your secret decoder ring and send to blabgoo at yahoo dot. com :)

1 0

Re: Spamcop
by Gregory Hicks 11 May '04

11 May '04

> Date: Tue, 11 May 2004 11:51:10 -0700 > From: Vicky Rode <vickyr(a)socal.rr.com> > To: nanog(a)merit.edu, nanog(a)nanog.org, nanog-support(a)nanog.org > Cc: rrsecurity(a)socal.rr.com, vickyr(a)socal.rr.com > Subject: Spamcop > > > Hi there, > > Just wondering why was my e-mail thread (Hierarchical Credit-based > Queuing (HCQ): QoS) dated 5/9/2004 9:36 PM reported as a spam? Just > trying to understand so that I don't repeat it. Below is a cut and paste > of the reported incident. Vicky: I'm guessing here, but it was probably because the *.rr.com addresses originate a LOT of spam and someone has a procmail filter that automatically refers any mail from that domain to spamcop... Or it could be that someone didn't like what you wrote and reported it ... Dunno. Remember, I said that I'm **guessing**. Regards, Gregory Hicks > > > Please advice. > > > regards, > /vicky > > > ---- cut here ------ > > Return-Path: <988145978(a)bounces.spamcop.net> > Received: from vamx01.mgw.rr.com ([24.28.193.148]) by > acme-reston.va.rr.com > (Post.Office MTA v3.5.3 release 223 > ID# 0-59787U250000L250000S0V35) with SMTP id com > for <abuse(a)rr.com>; Mon, 10 May 2004 10:42:14 -0400 > Received: from vmx2.spamcop.net (vmx2.spamcop.net [206.14.107.117]) > by vamx01.mgw.rr.com (8.12.10/8.12.8) with ESMTP id > i4AEkwhn017175 > for <abuse(a)rr.com>; Mon, 10 May 2004 10:47:01 -0400 (EDT) > Received: from sc-app3.verio.ironport.com (HELO spamcop.net) > (192.168.11.203) > by vmx2.spamcop.net with SMTP; 10 May 2004 07:47:00 -0700 > Received: from [68.13.211.63] by spamcop.net > with HTTP; Mon, 10 May 2004 14:47:01 GMT > From: 988145978(a)reports.spamcop.net > To: abuse(a)rr.com > Subject: [SpamCop (24.30.181.126) id:988145978]Hierarchical Credit-based > Queuing (HCQ): QoS > Precedence: list > Message-ID: <rid_988145978(a)msgid.spamcop.net> > Date: Sun, 9 May 2004 21:36:30 -0700 (PDT) > X-SpamCop-sourceip: 24.30.181.126 > X-Mailer: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR > 1.0.3705) > via http://www.spamcop.net/ v1.3.4 > X-Virus-Scanned: Symantec AntiVirus Scan Engine > > [ SpamCop V1.3.4 ] > This message is brief for your comfort. Please use links below for > details. > > Email from 24.30.181.126 / Sun, 9 May 2004 21:36:30 -0700 (PDT) > http://www.spamcop.net/w3m?i=z988145978zab5cec781dcfa15ae459c11bd03b7bef > z > > [ Offending message ] > Return-path: <owner-x> > Envelope-to: x > Delivery-date: Mon, 10 May 2004 00:39:15 -0400 > Received: from [198.108.1.26] (helo=trapdoor.merit.edu) > by wilma.widomaker.com with esmtp (Exim 3.36 #1) > id 1BN2ZP-000Jo6-00 > for x; Mon, 10 May 2004 00:39:15 -0400 > Received: by trapdoor.merit.edu (Postfix) > id B68EC91206; Mon, 10 May 2004 00:36:37 -0400 (EDT) > Delivered-To: x > Received: by trapdoor.merit.edu (Postfix, from userid 56) > id 8645591243; Mon, 10 May 2004 00:36:37 -0400 (EDT) > Delivered-To: x > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) > by trapdoor.merit.edu (Postfix) with ESMTP id 50AFD91206 > for <x>; Mon, 10 May 2004 00:36:34 -0400 (EDT) > Received: by segue.merit.edu (Postfix) > id 3B3955914F; Mon, 10 May 2004 00:36:34 -0400 (EDT) > Delivered-To: x > Received: from ms-smtp-02-eri0.socal.rr.com > (ms-smtp-02-qfe0.socal.rr.com [66.75.162.134]) > by segue.merit.edu (Postfix) with ESMTP id EAB7358E5D > for <x>; Mon, 10 May 2004 00:36:33 -0400 (EDT) > Received: from [192.168.2.2] (cpe-24-30-181-126.socal.rr.com > [24.30.181.126]) > by ms-smtp-02-eri0.socal.rr.com (8.12.10/8.12.7) with ESMTP id > i4A4aUce025659 > for <x>; Sun, 9 May 2004 21:36:30 -0700 (PDT) > Message-ID: <409F________0602(a)socal.rr.com> > Date: Sun, 09 May 2004 21:36:41 -0700 > From: Vicky Rode <vickyr(a)socal.rr.com> > Reply-To: vickyr(a)socal.rr.com > User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) > X-Accept-Language: en-us, en > MIME-Version: 1.0 > To: x > Subject: Hierarchical Credit-based Queuing (HCQ): QoS > X-Enigmail-Version: 0.83.6.0 > X-Enigmail-Supports: pgp-inline, pgp-mime > Content-Type: text/plain; charset=us-ascii; format=flowed > Content-Transfer-Encoding: 7bit > X-Virus-Scanned: Symantec AntiVirus Scan Engine > Sender: owner-x > Precedence: bulk > Errors-To: owner-nanog-outgoing(a)merit.edu > X-Loop: nanog > > > > Hi there, > > > Just wondering if anyone out there has either implemented or looked into > > this queuing method for quality of service implementation. > This solution is offered (hardware solution) and patented by > foursticks.com. According to foursticks, "HCQ achieves the efficiency > and flexibility of first generation queuing systems, without the > disadvantages." > > It compares HCQ (interesting reading) w/ Class-Based Queuing (CBQ), > Random Early Discard (RED) and Weighted Random Early Discard > (WRED),Weighted Fair Queuing (WFQ),Priority Queuing (PQ) & Low Latency > Queuing (LLQ). > > > Also can anyone recommend a qos forum which I can ping as well. > > > Any insight will be appreciated. > > > regards, > /vicky > > ------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3400 San Jose, CA 95134 | Internet: ghicks(a)cadence.com I am perfectly capable of learning from my mistakes. I will surely learn a great deal today. "A democracy is a sheep and two wolves deciding on what to have for lunch. Freedom is a well armed sheep contesting the results of the decision." - Benjamin Franklin "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton

5 4

Re: Spamcop
by Eric Brunner-Williams 11 May '04

11 May '04

I got one of those during the Spring last year, when I was writing about the state of the net in Iraq. Someone used SpamCop to get my ISP's abuse desk interested in me. Not much to be said about that.

1 0

Re: WAN transfer rates
by Vincent J. Bono 11 May '04

11 May '04

A nifty graph that I have found to be fairly accurate is at a little way down the page. http://www.atlantateleport.com/Services/TCP_IP_Via_Satellite/tcp_ip_via_sat… And an intensive whitepaper at: http://public.lanl.gov/radiant/pubs/drs/hpdc2002.pdf Hope this helps. -v > ----- Original Message ----- > From: "Jeff Nelson" <jnelson(a)rackspace.com> > To: <nanog(a)nanog.org> > Sent: Tuesday, May 11, 2004 4:24 AM > Subject: WAN transfer rates > > > > > > Possibly someone in this forum with a better understanding of tcp/ip can > > articulate this better than I.... > > > > I realize that transfer rates across the Internet diminish significantly > > with latency, but what's the good answer for someone shrunk down to > > <10Mbps when the smallest pipe between them is 100Mbps and latency is > > <40ms? > > > > Does anyone have reference to any study done in this area? I'm sure > > window tuning can alter this, but I'm interested in average statistics. > > > > Any reference would be appreciated. > > > > thanks, > > jeff > > > > > > >

1 0

Re: IPv6/IPv6 threat Comparison Paper available for review
by Iljitsch van Beijnum 11 May '04

11 May '04

On 11-mei-04, at 11:19, itojun(a)iijlab.net wrote: >> - Smurf >> I don't think you mention that in IPv6, there are no mechanisms that >> allow an incoming unicast packet to be turned into a broadcast or >> multicast packet, and as such, smurf-like attacks are impossible. > There are cases where malicious IPv6 packet leads to IPv4 smurf > attack (due to wacky IPv4 mapped address and API). > i think it worthwhile to look at threats due to IPv4/v6 interaction. You can obviously craft an IPv6 packet that will be delivered to an IPv4 subnet broadcast address through 6to4 or some such, but unless the hosts that receive the subsequent broadcast (that shouldn't be generated unless v4 isn't properly administered in the first place so it's still not an IPv6 issue) reply with something, nothing is going to happen. > draft-itojun-ipv6-transition-abuse-xx.txt > draft-cmetz-v6ops-v4mapped-api-harmful-xx.txt > draft-itojun-v6ops-v4mapped-harmful-xx.txt Yeah, yeah, everything is harmful. I don't think having IPv4-specific and IPv6-specific code in applications is the answer, though.

1 0

Re: WAN transfer rates
by sthaug＠nethelp.no 11 May '04

11 May '04

> I realize that transfer rates across the Internet diminish significantly > with latency, but what's the good answer for someone shrunk down to > <10Mbps when the smallest pipe between them is 100Mbps and latency is > <40ms? Without window scaling (RFC 1323) your max transfer rate at 40ms RTT is 65535*8/0.040 = 13.1 Mbps. So slightly less than 10 Mbps isn't too unexpected. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0