December 2002 - Test - lists.nanog.org

paix
by Scott Granados 05 Dec '02

05 Dec '02

Anybody else seeing a loss of paix? My peering dropped. as well as everyone else in sf. While writing this my phone rang and it was paix. Seems mfn did an unreported bit of maintenance. Anyone else on the peering by paix switch at e-xchange at least will have lost service but it should be restored.

2 1

More studies: Estimates were wrong
by Sean Donelan 05 Dec '02

05 Dec '02

David Wessel's column in the Wall Street Journal covers the debate over how much electricity does the Internet use. (paid subscription) http://online.wsj.com/article/0,,SB1039040314228813793,00.html?mod=technolo… Mark Mills wrote a paper how the US was running short on power, and the Internet was consuming 13% of it. Jonathan Koomey writes research papers that the number is about 3%. To quote the column: "It's an instructive case study in how a simple assertion of questionable accuracy can be repeated so often that it is accepted as fact by people in the press, in government and on Wall Street who ought to be more discerning."

1 0

mrtg graph
by Sameer R. Manek 05 Dec '02

05 Dec '02

Could someone please send me an mrtg graph of any router that handles sufficient traffic, and goes back at least a year? I need it for a school project. Thanks ------------------------------------------------------------------------- Sameer R. Manek Email: manek(a)ghur.net "What one has not experienced, one will never understand in print." --Isadora Duncan -------------------------------------------------------------------------

2 1

Packets on the floor..
by Robert Mathews 04 Dec '02

04 Dec '02

Has anyone seen problems w/ AS 7170 over the last three days? A trace from two different locales just now (as it has over the past two days at least) indicate that packets are getting dropped on the floor at seattlebr-aip.att-disc.net (135.206.243.11) on its way to the Pacific.. All info appreciated.. All the best.. Robert.

1 0

New ASN allocation from IANA to RIPE
by Rob Thomas 04 Dec '02

04 Dec '02

Hi, NANOGers. As of 03 December 2002 IANA has allocated a block of formerly unallocated ASNs to RIPE. I have adjusted my monitoring accordingly, and you should review any ASN filtering or logging you have in place. The ASN ranges involved are: Was: 28672 - 32767 IANA Now: 28672 - 29695 RIPE 29696 - 32767 IANA My ASN monitoring can be found at the URLs below. http://www.cymru.com/BGP/asnbogusrep.html http://www.cymru.com/BGP/asnreport.html http://www.cymru.com/BGP/ Comments and feedback are welcome and encouraged. Be the first (heck, even second) in your ASN to join the CREDITS section! :) Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);

1 0

Re: Operational Issues with 69.0.0.0/8...
by Martin J. Levy 04 Dec '02

04 Dec '02

Todd, If this helps. Do something like the following... telnet route-views.oregon-ix.net > /tmp/file term len 0 sh ip bgp 69.0.0.0 255.0.0.0 l quit cut -c62-2000 < /tmp/file | awk '{print $1}' | sort -n | uniq -c | more ...your commands will vary. You will see plenty of routes within 69/8. A closer look with show that around 121 routes are seen in the 69/8 range via most of the feeds into Oregon. There is one big exception... 69.4.64.0/20 ... it shows up via AS-2548 (Digex) and the other feeds, but it's the only route within 69/8 that shows up via AS-2548. This is valuable information. It does not mean there is filtering within AS-2548, but I would recommend you contact them to further this investigation. BTW: This is exactly what Oregon is great for! It shows up issues like this with ease. Thanks! Martin --------------------------- At 01:47 PM 12/2/2002 -0500, Todd A. Blank wrote: >Thanks for the reply, James. > >I wish I could tell you the answer. We see traffic passing through some >of the routers (transit), but on each network, or their downstreams >there seem to be different devices filtering. Sometimes it is a border >or peering router. In other cases, it has been access devices, such as >firewalls. > >One we resolved this morning (with some help from the good folks at >ARIN) was a downstream provider from one of these transit providers that >was filtering in their devices as well. > >I am just trying to raise general awareness that the 69.0.0.0/8 block is >assigned and out there in use, and to get people to re-examine their >filters, access lists, etc. > >You help and response is appreciated. > >Sincerely, > >Todd A. Blank >614.207.5853 > >-----Original Message----- >From: Feger, James [mailto:jfeger@feger.net] >Sent: Monday, December 02, 2002 1:35 PM >To: Todd A. Blank >Subject: Re: Operational Issues with 69.0.0.0/8... > >When you say 'Networks involved' do you mean those providers are >blocking >the traffic, or you see these networks in the transit? > >Thanks, >James > > >On Mon, 2 Dec 2002, Todd A. Blank wrote: > >> >> To all concerned: >> >> We have been assigned a CIDR of 69.1.192.0/19. >> >> We have had numerous problems getting traffic through to various >destinations. >> >> We are finding that many routers are still filtering 69.0.0.0/8. >> >> This block used to be restricted, but was assigned by IANA to ARIN in >August of 2002. >> >> If anyone is still filtering this block in their routers, please >remove the filters! >> >> Here are some of the destinations that are not reachable if your >source is anywhere in the 69.0.0.0/8 CIDR: >> >> www.cplink2.com >> www.ocas.com >> www.indofilms.com >> www.lavalife.com >> >> >> Some of the Networks involved are Cable and Wireless, Allegiance >Internet and AT&T. >> >> Thank you, >> >> Todd A. Blank >> IPOutlet LLC >> 614.207.5853 >>

2 1

FYI: ANSI Standard Proposal: A Baseline of Security Requirements for the Management Plane
by Barry Raveendran Greene 04 Dec '02

04 Dec '02

Note: The "baseline" draft is at: ftp://ftp.t1.org/pub/ballots/current/lb1117.pdf ------------------------------------------------------------- November 18, 2002 TO: Members of Accredited Standards Committee T1 - Telecommunications Members of Technical Subcommittee T1M1 SUBJECT: T1 Letter Ballot T1 LB 1117 Dear Members: Enclosed for your action, please find the following T1 Letter Ballot voting form: - T1 LB 1117, Draft Proposed American National Standard - Operations, Administration, Maintenance, and Provisioning Security Requirements for the Public Telecommunications Network: A Baseline of Security Requirements for the Management Plane ** NOTE: The Letter Ballot notifications for LB 1112 thru LB 1120 are being sent separately and comprise this mailing. Please note that the closing date of this T1 Letter Ballot is January 06, 2003 *** You should send your response and must send any corresponding comments on this letter ballot to t1ballot(a)atis.org. If you have any questions, please contact Steve Barclay at sbarclay(a)atis.org. *** Your earliest response to this letter ballot is appreciated. ADDITIONAL INFORMATION: THE DOCUMENT ASSOCIATED WITH THIS LETTER BALLOT IS NOW AVAILABLE FROM THE T1 HOMEPAGE in the "Current" Letter Ballots directory. To obtain a copy of lb1117.pdf go to: WWW: http://www.t1.org/html/ballots.htm (Current Letter Ballots) FTP: ftp://ftp.t1.org/pub/ballots/current/lb1117.pdf ----------------------------------------------------------------- ACCREDITED STANDARDS COMMITTEE T1-TELECOMMUNICATIONS LETTER BALLOT **-- ACTION REQUESTED --** REPLY TO: ATIS Letter Ballot Number: LB 1117 T1 Secretariat Document Number: T1M1.5/2002-125R2 1200 G St., NW, Suite 500 Date: 11/18/03 Washington, DC 20005 Ballot Period: 6 Weeks FAX: 202.347.7125 Ballot Closes: 01/06/03 EM: t1ballot(a)atis.org Authorized By: T1M1 Distributed By: T1 Secretariat Subject: Draft Proposed American National Standard - Operations, Administration, Maintenance, and Provisioning Security Requirements for the Public Telecommunications Network: A Baseline of Security Requirements for the Management Plane Statement: The T1M1 members at its November 2002 plenary approved this dpANS for letter ballot. Please note: Due to an interest category imbalance at the time of this letter ballot, weighted voting of a .53 value applies to the manufacturing interest group. Additionally, due to the upcoming holiday season and its impact on work schedules, this letter ballot period has been extended at the request of the T1M1 Chairman. Question: Do you approve this draft proposed American National Standard for submittal to ANSI for approval as an American National Standard? Ballot: YES ____ NO ____ (Comments Required) Ballot: YES ____ (w/ comments) ABSTAIN ____ (w/ reasons) ABSTAIN ____ (IF VOTING "NO, WILL VOTE CHANGE TO "YES" IF THE ATTACHED CHANGES ARE MADE?) YES ____ NO ____ Signature ___________________________ Principal___ Alternate___ Organization ____________________________________ DATE_________ Telephone #: __________________________ See ANSI's PATENT POLICY (under the Committee T1 Letter Ballots section)

1 0

RE: Operational Issues with 69.0.0.0/8...
by Todd A. Blank 03 Dec '02

03 Dec '02

Some of this is beginning to clear up. The Cable and Wireless stuff seems to be working now. Still, when we source from the 69.0.0.0/8 CIDR, traffic can't go (http) to the following destinations: www.ocas.com www.lavalife.com www.indofilms.com The first two are on AT&T and AT&T Canada. The last one is on allegiance internet. Any insight would be much appreciated. We are sure this is affecting access to other destinations when using 69.0.0.0/8 as a source - we just haven't found them all yet... Thanks, Todd A. Blank 614.207.5853 -----Original Message----- From: Martin J. Levy [mailto:mahtin@mahtin.com] Sent: Monday, December 02, 2002 2:17 PM To: Todd A. Blank; jfeger(a)feger.net Cc: nanog(a)merit.edu Subject: Re: Operational Issues with 69.0.0.0/8... Todd, If this helps. Do something like the following... telnet route-views.oregon-ix.net > /tmp/file term len 0 sh ip bgp 69.0.0.0 255.0.0.0 l quit cut -c62-2000 < /tmp/file | awk '{print $1}' | sort -n | uniq -c | more ...your commands will vary. You will see plenty of routes within 69/8. A closer look with show that around 121 routes are seen in the 69/8 range via most of the feeds into Oregon. There is one big exception... 69.4.64.0/20 ... it shows up via AS-2548 (Digex) and the other feeds, but it's the only route within 69/8 that shows up via AS-2548. This is valuable information. It does not mean there is filtering within AS-2548, but I would recommend you contact them to further this investigation. BTW: This is exactly what Oregon is great for! It shows up issues like this with ease. Thanks! Martin --------------------------- At 01:47 PM 12/2/2002 -0500, Todd A. Blank wrote: >Thanks for the reply, James. > >I wish I could tell you the answer. We see traffic passing through some >of the routers (transit), but on each network, or their downstreams >there seem to be different devices filtering. Sometimes it is a border >or peering router. In other cases, it has been access devices, such as >firewalls. > >One we resolved this morning (with some help from the good folks at >ARIN) was a downstream provider from one of these transit providers that >was filtering in their devices as well. > >I am just trying to raise general awareness that the 69.0.0.0/8 block is >assigned and out there in use, and to get people to re-examine their >filters, access lists, etc. > >You help and response is appreciated. > >Sincerely, > >Todd A. Blank >614.207.5853 > >-----Original Message----- >From: Feger, James [mailto:jfeger@feger.net] >Sent: Monday, December 02, 2002 1:35 PM >To: Todd A. Blank >Subject: Re: Operational Issues with 69.0.0.0/8... > >When you say 'Networks involved' do you mean those providers are >blocking >the traffic, or you see these networks in the transit? > >Thanks, >James > > >On Mon, 2 Dec 2002, Todd A. Blank wrote: > >> >> To all concerned: >> >> We have been assigned a CIDR of 69.1.192.0/19. >> >> We have had numerous problems getting traffic through to various >destinations. >> >> We are finding that many routers are still filtering 69.0.0.0/8. >> >> This block used to be restricted, but was assigned by IANA to ARIN in >August of 2002. >> >> If anyone is still filtering this block in their routers, please >remove the filters! >> >> Here are some of the destinations that are not reachable if your >source is anywhere in the 69.0.0.0/8 CIDR: >> >> www.cplink2.com >> www.ocas.com >> www.indofilms.com >> www.lavalife.com >> >> >> Some of the Networks involved are Cable and Wireless, Allegiance >Internet and AT&T. >> >> Thank you, >> >> Todd A. Blank >> IPOutlet LLC >> 614.207.5853 >>

1 0

Details on CareGroup incident
by Stephen Sprunk 03 Dec '02

03 Dec '02

To quote Dr. Halamka: > I hope that my approval enables [Cisco] to share more with the press > so that everyone understands that our issues were purely architectural > and not related to Cisco products or Cisco engineers. So, now that I have it in writing, here's what I'll share: The Topology There are three campuses, each with several phyiscal sites, connected to each other with 8 different FEC and OC3 LANE links -- all L2. Each campus had several core switches depending on the number of buildings, again connected redundantly within the campus with FEC and/or OC3 LANE L2 links, plus dozens of access switches with redundant L2 uplinks to various core switches. Many protocols were in use, including non-routeable protocols like NetBEUI and SNA. How did this mess occur? "The CareGroup network grew organically due to the BIDMC merger, PACS installation, East to West movement of clinical services, Libby sale and changing CareGroup environment." In short, the network was growing very quickly due to business changes and was never redesigned to cope with the much larger scale and new application requirements. This resulted in the previously-mentioned 10+ hop STP, which spanned across multiple sites and multiple adminitrative zones. CareGroup had recently gone through a network audit by a third party which listed most/all of the potential problems in this design and suggested solutions. The outage occurred before CareGroup had an opportunity to act on these recommendations. The Outage The trigger for the outage was the addition of a new high-bandwidth application which somehow interfered with the proper operation of STP. Even after this application was removed, STP could not reconverge due to the default 7-hop limit. During troubleshooting, Cisco inserted L3 hops at logical boundaries, breaking the STP into more manageable chunks. Most of these smaller chunks were still unstable, so Cisco removed all redundant links in each area, verified stability, and then reintroduced redundant links one-by-one to troubleshoot potential problems. As you can imagine, this takes a long time, and was done with Cisco staff on site travelling to each building and wiring closet to make the necessary changes. Going Forward The new design calls for one pair of distribution L3 switches per building, with L3 GE links in a full mesh between all distribution switches in a campus, and between specific switches at each campus. STP will be confined to the access L2 switches. All non-IP traffic will be removed or isolated. In the meantime, CareGroup will be performing small-scare hardware and link upgrades to improve resiliency within each campus, and will install computers with dial-up connections to the datacenter in key locations so that they will have minimal connectivity if another LAN event occurs. Strict change control will be implemented with Cisco approvals. Conclusion As I alluded to before, this is not a story of equipment failure or STP's inherent scaling problems. It's a story of a business which didn't or couldn't adapt the network to the business needs -- even though everyone saw the train coming at them. The lesson here isn't to review your network design, but to review how your business handles growth and/or known problems. S

1 0

Re: Networking in Africa...
by David Charlap 03 Dec '02

03 Dec '02

David Schwartz wrote: > > If you want to do this, your notification has to be explicit. I suggest, > "You have no privacy here. Everything you are doing is being logged." Notice > that when you tell people the truth, it starts looking less like what you > wanted to do in the first place. Well, that makes it sound like you are a pervert that enjoys reading everybody else's e-mail. The language can be a bit better than that. You're right, you should say that all outgoing web forms are intercepted and recorded. But you can add additional statements to the extent that you won't be reading through that information unless it's part of following up on complaints of abuse, or at the request of law enforcement. I'm not trying to establish rules carved in stone, and I'm not trying to play lawyer. I was trying to attempt a possible solution to the problem of these spams coming from anonymous-access terminals in public places via web-based mail systems. Since web-mail doesn't have a fixed protocol to filter/monitor, you have to take a different approach. You can't block all possible vectors, since that would essentially block all traffic. One possibility is monitoring and logging in order to preserving evidence for possible future investigations. Yes it may be seen as invasive, but what other choice is there if your network is routinely being abused by felons? So far, I haven't seen anybody else post even a vague idea of a solution to this problem. Of course, as a network operator, you don't have to care - you can just cut off the service of any cafe owner who can't figure out a solution on his own. -- David

1 0