- Test - lists.nanog.org

AT&T ATM Outage This Week
by Spencer.Wood＠dot.state.oh.us 23 Feb '01

23 Feb '01

The following is from our ISP describing the AT&T ATM Outage: ATM Network - AT&T had an ATM network-wide outage on Tuesday affecting some of our DS1 and DS3 ATM connections. The outage began at Tuesday at 1:30 p.m. affecting 17 switches. Switches were restored by 4:30 p.m. but outages continued into the evening due to switch restarts. AT&T attributed the outage to a cable cut resulting in excessive number of control messages from one of AT&T's network switches. The switches were unable handle the message volume and failed. AT&T turned down some of the links between switches to isolate the problem. Problems continued in Columbus on Wednesday due to an unknown issue with the Lucent switch. PVCs were up but are operating slowly. Another failure in Columbus on Friday morning affecting four of our DS3's was isolated to a link between Columbus and Cleveland. Service was restored by late morning. We are expecting a written summary of these issues from AT&T. **************************************************** Spencer Wood, Network Administrator Ohio Department Of Transportation 1320 Arthur E. Adams Drive Columbus, Ohio 43221 E-Mail: Spencer.Wood(a)dot.state.oh.us Phone: 614.644.5422/Fax: 815.361.0714 ****************************************************

1 0

Re: Beer and Gear surprise
by owen＠dixon.delong.sj.ca.us 23 Feb '01

23 Feb '01

And how exactly would you translate that membership into a voting eligibility? Anyone on the internet who wants to claim they provide network services can vote? I'm OK with that definition, but it will be hard to implement in terms of actually conducting voting in some rational manner. Owen > I disagree. The charter defines membership: > > "The group will have membership that broadly includes network providers. > These may include private, public, federal, commercial or other networks > that consider themselves providers of Internet services. However the > representatives attending this group should be prepared to engage in > technical discussions. Membership should not be limited to North American > participants though the general focus of the discussion should be from the > NA networking point of view." > > --- > Opinions in this email are the personal opinions of the author and are not > associated with author's employer. This email account is a not the regular > email account of the author and is being used for the protection of the > employer. > > ----Original Message Follows---- > From: owen(a)dixon.delong.sj.ca.us (Owen DeLong) > To: nanog(a)merit.edu, kawaii_iinazuke(a)hotmail.com > Subject: Re: Beer and Gear surprise > Date: Wed, 21 Feb 2001 23:40:45 -0800 > > <fact> > There is no NANOG membership. There is the NANOG community. There are no > firm criteria for citizenship in said community, so it would be difficult > to define a voting process in terms of who does or does not get to vote. > </fact> > > Owen > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com > > >

4 3

Re: Beer and Gear surprise
by Ukyo Kuonji 23 Feb '01

23 Feb '01

Why would someone need to buy Merit? Nanog doesn't belong to Merit, does it? Funny, I though it was the North American Network Operators' Group. Doesn't that imply that it collectively belongs to those of use that consider ourselves operators? I don't think people are getting it. It's not about the vendorwear that was eliminated. My point is that someone made a decision about the meeting without even informing the people that were going to attend the meeting beforehand. There was no discussion about it beforehand, no information afterwards, and no mention of it when we signed up for the meeting. The only notification that I saw was a addendum to the charter dated November 2000 which was as long as the original charter. My question, I guess, is this: 1) What does Merit do for Nanog? Looks to me like they help organize the meetings (Which are funded entirely by registration fees and vendor donations, and are supposed to be organized by the hosting organization), host the web site (which has little content on it) and host the mailing list. Am I missing anything else? 2) What gives Merit the right to make decisions about the group without consulting the membership? (Hint: It's not in the charter, or anywhere else I could find) 3) If Merit is not listening to it's membership, and is only providing the web page and mailing list, is there a reason why they are still hosting NANOG? (Hint: It's not in the charter.) I would propose one of the following: 1) The NANOG Charter needs to be revised into a more inclusive charter which includes the resolution of conflicts within the membership, review of the officials actions by the membership and removal of officials by the membership in the event that the actions are in conflict with the membership or charter. There should also be included, in the charter, how to revise and amend the charter. In this option, Merit would still be the ruling body. 2) Remove Merit from the ruling body. There is no reason, today, that the web site and mailing list could not be hosted by someone else. I do not believe that Merit is doing a bad job, but there isn't that much work involved in providing this service. The charter states that meetings are to be organized by the hosting company. I don't see a reason why this could not continue. The charter will still need to be resizes, however to include the items from option 1 3) Continue to live under the rule of a ruling body that does not consult of inform it's membership or decisions that affect the membership and meetings. Merit is under no obligation, at this point, to continue to offer services to NANOG, and the membership has no recourse of action under the current charter. I don't want to play politics, but I think something needs to be done. UK --- Opinions in this email are the personal opinions of the author and are not associated with author's employer. This email account is a not the regular email account of the author and is being used for the protection of the employer. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com

9 8

RE: History of private peering and exchanges?
by Howard C. Berkowitz 23 Feb '01

23 Feb '01

> > At some point, there started to be a business case for large >> providers to interconnect with bilateral private links as well as at >> exchanges. When did such links first get used for commercial >> traffic? In the beginning, were they short-haul connections between >> cages in exchanges, or WAN links between major provider hubs? I'm >> referring here only to interprovider links, not to transit customers. Mark Borchers added, > >Well, if this is to be a comprehensive list, private interconnects >predated the commercial Internet. At OARnet in Ohio, we set up >peering with CICNet in a facility near the Ohio Supercomputer Center >in order to avoid long round trips. Clearly, there's a need to broaden my scope! I do want differentiate between good solid technical examples, such as yours for OARnet-CICNet, between examples where the suits had an economic motivation. The latter, I would assume, came later. While I recognize I won't be able to publish the details of many NDA-covered commercial private peerings, it is my hope to identify when this practice began. A side motivation for this particular point is to identify when commercial NDA considerations might have restricted the potential ability of routing registries to give reasonably accurate representations of topology and policy. Yeah, yeah...if everyone DID put all their policies in an RR. Yet Another Issue.

2 1

BGP filters for rfc 1918 and other nasties
by Lee Watterworth 23 Feb '01

23 Feb '01

I have been doing some looking around for a decent access-list or prefix-list to start my inbound BGP filters. I have found quite a few flawed examples, but none that look solid.. What do you use for ingress filters? Found an interesting link in an ancient (12/97) Nanog post. Those who have coffee and BGP for breakfast should take a peek. http://www.employees.org/~tbates/cidr-report.html http://www.lucentnps.com/knowledge/whitepapers/bgp_main_isp.asp missing 172.16/12 ??? access-list 100 deny ip 127.0.0.0 0.255.255.255 255.0.0.0 0.255.255.255 access-list 100 deny ip 10.0.0.0 0.255.255.255 255.0.0.0 0.255.255.255 access-list 100 deny ip 192.168.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 100 deny ip 192.0.2.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 100 deny ip 128.0.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 100 deny ip 191.255.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 100 deny ip 192.0.0.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 100 deny ip 223.255.255.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 100 deny ip 224.0.0.0 31.255.255.255 224.0.0.0 31.255.255.255 access-list 100 deny ip any 255.255.255.128 0.0.0.127 access-list 100 deny ip 0.0.0.0 0.255.255.255 0.0.0.0 255.255.255.255 access-list 100 permit any any http://www.cymru.com/~robt/Docs/Articles/secure-bgp-template.html ip prefix-list bogons description Bogon networks we won't accept. ip prefix-list bogons seq 5 deny 0.0.0.0/8 le 32 ip prefix-list bogons seq 10 deny 1.0.0.0/8 le 32 ip prefix-list bogons seq 15 deny 2.0.0.0/8 le 32 ip prefix-list bogons seq 20 deny 10.0.0.0/8 le 32 ip prefix-list bogons seq 25 deny 23.0.0.0/8 le 32 ip prefix-list bogons seq 30 deny 31.0.0.0/8 le 32 ip prefix-list bogons seq 35 deny 67.0.0.0/8 le 32 ip prefix-list bogons seq 40 deny 68.0.0.0/6 le 32 ip prefix-list bogons seq 45 deny 72.0.0.0/6 le 32 ip prefix-list bogons seq 50 deny 76.0.0.0/6 le 32 ip prefix-list bogons seq 55 deny 80.0.0.0/6 le 32 ip prefix-list bogons seq 60 deny 84.0.0.0/6 le 32 ip prefix-list bogons seq 65 deny 88.0.0.0/6 le 32 ip prefix-list bogons seq 70 deny 92.0.0.0/6 le 32 ip prefix-list bogons seq 75 deny 96.0.0.0/6 le 32 ip prefix-list bogons seq 80 deny 100.0.0.0/6 le 32 ip prefix-list bogons seq 85 deny 104.0.0.0/6 le 32 ip prefix-list bogons seq 90 deny 108.0.0.0/6 le 32 ip prefix-list bogons seq 95 deny 112.0.0.0/6 le 32 ip prefix-list bogons seq 100 deny 116.0.0.0/6 le 32 ip prefix-list bogons seq 105 deny 120.0.0.0/6 le 32 ip prefix-list bogons seq 110 deny 124.0.0.0/7 le 32 ip prefix-list bogons seq 115 deny 126.0.0.0/8 le 32 ip prefix-list bogons seq 120 deny 127.0.0.0/8 le 32 ip prefix-list bogons seq 125 deny 169.254.0.0/16 le 32 ip prefix-list bogons seq 130 deny 172.16.0.0/12 le 32 ip prefix-list bogons seq 135 deny 192.0.2.0/24 le 32 ip prefix-list bogons seq 140 deny 192.168.0.0/16 le 32 ip prefix-list bogons seq 145 deny 198.18.0.0/16 le 32 ip prefix-list bogons seq 150 deny 201.0.0.0/8 le 32 ip prefix-list bogons seq 155 deny 223.255.255.0/24 le 32 ip prefix-list bogons seq 160 deny 224.0.0.0/3 le 32 ! Allow all prefixes up to /27. Your mileage may vary, ! so adjust this to fit your specific requirements. ip prefix-list bogons seq 170 permit 0.0.0.0/0 le 27 -----Original Message----- From: Chris Davis [mailto:chris.davis@computerjobs.com] Sent: February 22, 2001 3:39 PM To: 'nanog(a)merit.edu' Subject: rfc 1918? Hello, Does anyone know why I get inbound packets from 10.x.x.x coming from my ISP, UUNet? They're just headed for a webserver, so it's not likely that they're up to no good. This seems to violate rfc 1918. Am I crazy? Feb 22 15:29:48 computerjobs-gw 353094: Feb 22 20:30:10.439 UTC: %SEC-6-IPACCESSLOGP: list 135 denied tcp 10.10.5.18(62438) -> 63.67.217.184(80), 1 packet Feb 22 15:30:02 computerjobs-gw 353095: Feb 22 20:30:24.024 UTC: %SEC-6-IPACCESSLOGP: list 135 denied tcp 10.10.5.18(62440) -> 63.67.217.184(80), 1 packet Feb 22 15:30:06 computerjobs-gw 353096: Feb 22 20:30:28.168 UTC: %SEC-6-IPACCESSLOGP: list 135 denied tcp 10.10.5.18(62455) -> 63.67.217.184(80), 1 packet

1 0

RE: rfc 1918 (why filtering is a good idea for non-transit organi zations)
by Mathew Butler 23 Feb '01

23 Feb '01

Actually, if memory serves me correctly (for once), there was a situation several years ago where a transit provider ran out of bandwidth and started shunting traffic through a (better-connected) customer's network. If filtering had been operating properly at that time (if there had been enough CPU muscle in the routers) as specified below, then this could NOT have happened -- the customer's network would have recognized the destination IP as not being within its address range, and filtered it on ingress. (Or, it could have checked the source IP, and if it wasn't in its address range, filtered it on egress. My personal opinion is that both are necessary and desirable, for different reasons.) -Mat Butler -----Original Message----- From: Stephen J. Wilcox [mailto:steve@opaltelecom.co.uk] Sent: Friday, February 23, 2001 2:19 AM To: Mark Radabaugh Cc: North America Network Operators Group Mailing List Subject: RE: rfc 1918? This only can apply to small networks, specifically stub networks, if you're carrying transit or have multiple connections out you'll find filters which only allow your own ips in and out start dropping a whole lot else! But i think you have the right idea, filters should be applied at the provider edge to such stub networks and then no nasty ips will get through to the provider network and hence the internet. Oh, and I dont think I showed my opinion on my last mail, i think use of 1918 on p2p is wrong! But.. as so many large networks do it you cant just filter it out and assume everything will work. Steve On Thu, 22 Feb 2001, Mark Radabaugh wrote: > It is my intention to avoid having 1918 addresses leaving my network. > > At our egress points the filters are fairly short -- they allow only traffic > with our IP source addresses to leave. This was my interpretation of the RFC's. > Some in this discussion seem to be saying that we should also filter for RFC1918 > destinations. Am I reading this correctly? > > I can see that packets destined for RFC1918 addresses will leave our network > (due to default routes) but are promptly dropped at the first BGP speaking > router they encounter. Is it worth the extra router processing time to check > all outgoing packet destinations as well? I can't see where this extra > filtering is worth the trouble. > > Mark Radabaugh > VP, Amplex > (419)833-3635 > mark(a)amplex.net > > > > >

1 0

DS3 Ordering Experiences
by Andy Dills 23 Feb '01

23 Feb '01

This might help some people ordering DS3s from UUnet in the future, so I'll post it here for the archives. We ordered a DS3 to UUnet last July, and after several blown FOC dates, we finally started passing packets last night. (And man, nothing like 2 ms latency and being able to measure downloads in MB/s.) Thank god the circuit is quality, or this would be an entirely different post. UUnet was amazingly slow: 7+ months to terminate a DS3 to Frederick, MD, 50 miles north of their world headquarters. The main reason they were so slow is because of the way they tried to design the circuit. They have various 'legacy' systems (worldcom isn't one big happy family) that they must check with to determine if they have the proper capacity to bring the circuit to your location. Checking with each of these legacy systems takes up to 21 days or even more. And here's the fuckup: They check each one serially, instead of all at the same time. So, with us, they hit worldcom, mci, and mfn (I believe) before they realized they don't have the capacity, and had to contract AT&T. They didn't contract AT&T to backhaul our circuit until DECEMBER. The entire time from July to December, they were checking with their legacy systems to determine if they had capacity. Had we told them to check all three at the same time, we could have saved 2-3 months. So, some things we have learned from this experience, that I would like to pass on to future people: 1) If you are not in a metro area, and are ordering a circuit of any sort with UUnet (or that touches Worldcom in any way), demand up front that they check all of their legacy systems for capacity at the same time. Request to be informed of the completed circuit design within 30 days. 2) Escalate early and often, and be aggressive. Give them a chance to deliver the circuit design, but if the circuit design isn't done in 30 days, escalate every three days until it's done. 3) Every time they miss a FOC date, escalate two levels. Believe me, once you start annoying the VPs, things start to happen _real_ fast. 4) Be an asshole when you order the circuit with regard to the SLA; demand that for every month after 90 days that the circuit is on order (but not installed), you get a free month of service. So, it was the world's biggest pain in the ass to bring up, but now that it's installed, I love it. <does the bandwidth dance> Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access

4 4

RE: rfc 1918?
by Chris Davis 23 Feb '01

23 Feb '01

My incident started the thread. The packets are not even an irritant; I was just curious as to why the rfc1918 addresses were being logged by my ingress filter. Now I know- General Practice dictates that my filters on my stub network are the appropriate place to filter out the private addresses. I had always believed the private addresses to be "non routable" (ie handled by ISPs) but that seems to be at least partially incorrect. Thanks to everyone who discussed! Hopefully this thread shed some light for some other people regarding the difference between the way things work in theory and in practice. My apologies to Mr Steenbergen who seemed very, very distressed about seeing this topic. -----Original Message----- From: Mark Borchers [mailto:mborchers@splitrock.net] Sent: Friday, February 23, 2001 9:46 AM To: 'nanog(a)merit.edu' Subject: RE: rfc 1918? > This is not an issue of paranoia (except for those who actually use > PRIVATE addresses internally and have properly configured > their gateways > to be paranoid about even seeing such packets, let alone > routing them). Unless I'm mistaken, a prime reason for the evolution of RFC 1918 addresses was that it was once common practice for people to help themselves to PUBLIC address space to use on PRIVATE networks. As the world got more connected, these addresses occasionally got leaked and caused address conflicts. Using RFC 1918 addresses prevents conflicts with public/registered space. Obviously the possibility of leakage still exists, but with RFC 1918 the havoc potential is diminished to a mere irritant level. Which is what the incident that started this thread appeared to be.

1 0

History of private peering and exchanges?
by Howard C. Berkowitz 23 Feb '01

23 Feb '01

Between fading memories and NDA's, it can be hard to track how things happened...but I'm trying to put together some timelines about interprovider peering both through private peering (i.e., at what point it became economic to meet other than through ARPANET/NSFNET) and at exchanges. In the beginning, of course, there was the ARPANET. Then there was the NSFNET. The NAPs were the first recognizable exchange points, with AUPs. NAPs were linked by VBNS. CIX came later, without the AUP restrictions of NSFNET. My impression is that bandwidth into it, at first, was quite limited. At some point, there started to be a business case for large providers to interconnect with bilateral private links as well as at exchanges. When did such links first get used for commercial traffic? In the beginning, were they short-haul connections between cages in exchanges, or WAN links between major provider hubs? I'm referring here only to interprovider links, not to transit customers. Also in the timeline was the advent of true "local" or "metro" exchanges. Going through the archives, the first I see was Tucson. Was that indeed the first cooperative exchange intended to reduce backhaul?

4 4

Re: rfc 1918?
by Richard A. Steenbergen 23 Feb '01

23 Feb '01

On Fri, Feb 23, 2001 at 12:32:11AM +0200, Ariel Biener wrote: > > On Thu, 22 Feb 2001, Greg A. Woods wrote: > > > This gets us back to the discussin we had here about 3-4 months ago > about what should be done in order to create a friendly internet > environment, that is, where every Internet connected entity actually > gives a damn about everyone else. We go through this every couple months, and the same conclusion is reached every time. The psycho paranoid people like Greg Woods and Eric Hall scream that any RFC1918 sourced packet on the internet is a sign of the apocalypse, and you must apply packet filters to stop them from going out and coming in. Most everyone else just doesn't care, and realizes that yes it's a packet you won't be able to reply to but the world will not end if a few of them are floating around on the internet. There is far worse traffic floating about then an RFC1918 packet because of someone's misconfigured NAT, and they will probably proceed to FIX IT when they can't communicate with the rest of the world through it. Yes sometimes there IS communication from sources where we DO NOT want a reply back, like the ICMP messages generated by a router. It might be a better practice to simply put them in a section of allocated but unannounced IP space to avoid the 1918-nazi's, but thats another story. If you have your own 1918 space and you are worried that there might be some mysterious conflict, then by all means filter them from your ingress connection the same way you should filter ALL packets sourced from your ip space. Now can we please let it go? -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

5 4