- Test - lists.nanog.org

ATT problems
by Ian A Finlay 30 May '02

30 May '02

Hi, I can't read a shared imap folder for Nanog right now, so could someone please reply to me off list and let me know if they are seeing problems with ATT's network, especially on the east coast? Thanks, Ian

2 2

Re: IP renumbering timeframe
by k claffy 30 May '02

30 May '02

sorry about long latency but andre did some analysis that's relevant to joe's message during this nanog thread earlier this month. include joe's message for context and andre's response below. (andre's response relates to last paragraph of joe's message) k ================================================== Date: Mon, 6 May 2002 14:14:34 -0400 From: Joe Abley <jabley(a)automagic.org> Subject: Re: IP renumbering timeframe To: David Conrad <david.conrad(a)nominum.com> Cc: grant(a)tnarg.org, nanog <nanog(a)merit.edu> On Mon, May 06, 2002 at 10:41:09AM -0700, David Conrad wrote: > On 5/6/02 10:20 AM, "Grant A. Kirkwood" <grant(a)tnarg.org> wrote: > > I'm sorry, but ARIN's policy practically _encourages_ the "efficient > > wasting" of space to qualify for PI space. This is one of the most > > frustrating things to deal with. > > As someone who used to run a registry, one of the most frustrating things to > deal with was watching ISPs pee in their own pool and then scream at the > registries 'cause the water was yellow. > > Just how big should the DFZ be? > > Given the Internet is not (yet, at least) a fascist state, the registries > rely on ISPs to be aware of the environment in which they are operating. As > it is unlikely any of the registries will be hiring independent auditing > firms to verify true utilization, there is need for a certain level of > trust. If an ISP is too small to justify the allocation of a /20, then they > should obtain address space from an upstream provider so that they do not > add yet another entry to the DFZ. A multi-homed ISP who advertises PA space to multiple transit providers adds state to the DFZ. It is common practice for PA-delegating transit providers to punch a whole in their covering supernet advertisements in order to facilitate this. The PI/PA distinction seems unhelpful in the case of a multi-homed ISP. > The term "tragedy" in "the tragedy of the commons" is not a mistake... It would be interesting to see multi-homed ISPs take the time to classify the parts of the infrastructure which are hard to renumber, versus those that are easy to renumber. It may be quite trivial to renumber large dial/cable/DSL address pools every now and then, as and when transit providers change. It may be a minor nightmare to renumber nameservers that report authoritatively for domains in a large collection of separately-managed TLDs. I wonder whether the average small, multi-homed ISP who currently lusts after PI space would find all their renumbering nightmares reduced to entirely manageable levels by the delegation of (say) 1 x /24 PI netblock to number nameservers and mail exchangers, and n x /whatever netblocks to number everything else. If the justification requirements for PI space were relaxed to accommodate this kind of scenario (or if ISPs were more inclined to use the existing requirements in this way), perhaps fewer multi- omed ISPs would feel obliged to tell lies to RIRs to obtain address delegations they don't really need. But the DFZ still accumulates additional state every time an edge network multi-homes. It would be interesting to compare the growth in the numbers of single-homed vs. multi-homed edge networks. If the edge of the network is becoming predominantly multi-homed, the goals of the RIRs wrt DFZ state containment might usefully be modified to better serve other objectives. Joe ----- End forwarded message ----- From: broido(a)caida.org Joe, We tracked this trend in "Internet expansion, refinement and churn" -- http://www.caida.org/outreach/papers/2002/EGR/ We also just looked at the data available from RouteViews for May 15, 2001. We selected 36 tables (each from a different RouteViews peer) that each had over 109K prefixes. We define prefixes representing DFZ ('default free zone') as those present in 19 or more tables ("semiglobal prefixes"). (See above paper for details on terminology/methodology). Multihoming was on the rise in 1997-1999, but slowed in 2000-2002. As of May 15, 2002, multihomed ASes make up 63% of all ASes. This is an increase of 1.4% since November 2001 (in 6 months). Currently available BGP data sheds doubt on the assumption that multihoming is the dominant contributor to growth of DFZ state. Note that when people refer to the "[problem of] multi-homed ASes" (i.e., ASes with multiple adjacent upstream ASes), they usually mean "nontransit multihomed" since most (over 75%) transit ASes are multihomed, and single homed transit ASes (i.e. ASes with only one upstream AS -- 541 out of 13281 ASes found in these BGP tables) may be an artifact of the undercoverage of BGP AS connectivity data. Multihomed nontransit ASes make up 60% of all non-transit ASes. So, as it stands now, A. The share of DFZ prefixes announced by non-transit multihomed ASes remained at 30% throughout 2000-2002, whereas the share of non-transit multihomed ASes grew 4.7%: May 2000 May 2001 15 May 2002 %ASes: 45.66 48.61 50.36 %prefixes: 29.43 31.30 30.15 This data shows that non-transit multhomed ASes contribute less than their `fair share' of prefixes to the DFZ BGP table. Multihoming would thus seem _not_ to be the primary cause of DFZ BGP table growth. B. As of 15 May 2002, multihomed transit and non-transit ASes originate 77.3% of all prefixes and 75.4% of all more specifics. These ASes announce their `fair' share of more specifics, i.e., proportionate to the total share of their prefixes in the table. The implication is that more specifics and multihoming are independent notions. C. The largest pool of prefixes (47.2%) is announced by transit multihomed ASes (as opposed to transit single-homed, or multi- and single- homed nontransit ASes.) Note that there is an inherent ambiguity in BGP data caused by availability of only a handful of representative tables, which leads us to suspect that there may be more multihomed ASes than this collection of BGP tables suggest. There may also be trends associated with prefixes carried from one group to another, e.g., when an AS becomes transit from non-transit or vice versa. As it stands now, however, we can only say that the largest set of DFZ prefixes, almost 1/2 of total, is announced by transit multihomed ASes (likely on behalf of their customers whose individual degree of multi- or single homing cannot be estimated using BGP tables.) The ultimate conclusion is that available data does not support the statement that multihoming is the dominant source of core BGP table growth. Andre, kc ps: last arin presentation may also be of interest http://www.caida.org/outreach/presentations/arin0402/

1 0

Contact for UniNet S.A. de C.V. (NETBLK-UNINET-NETBLK-12)
by Dan Hollis 29 May '02

29 May '02

Does anyone have a real contact for UniNet S.A. de C.V. (NETBLK-UNINET-NETBLK-12) ? The email address registered bounces "mailbox full". -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]

3 3

Draft agenda for Toronto
by Susan Harris 29 May '02

29 May '02

Agenda: NANOG 25 June 9-11, 2002 Richmond Hill, Ontario, Canada SUNDAY TUTORIALS 1:30 - 3:00 p.m. Introduction to RPSL Level: Intermediate Ambrose Magee, Ericsson 1:30 - 3:00 p.m. BGP Techniques for Service Providers Level: Intermediate Philip Smith, Cisco 1:30 - 3:00 p.m. Inter-domain Traffic Engineering: Overview and Case Examples Level: Intermediate Josh Wepman, Ixia; Joe Abley, MFN; Andrew Lange, CW; Matthew Meyer, Global Crossing 3:00 - 3:30 p.m. BREAK 3:30 - 5:00 p.m. Intro to RPSL (cont'd.) 3:30 - 5:00 p.m. BGP Techniques (cont'd.) 3:30 - 5:00 p.m. Inter-domain TE (cont'd.) 5:00 - 7:30 p.m. DINNER BREAK 7:30 - 9:00 p.m. Deploying Tight-SLA Services on an Internet Backbone: ISIS Fast Convergence and Differentiated Services Design Level: Intermediate Clarence Filsfils, Cisco Monday, June 10 General Session --------------- 9:00 a.m. Welcome, Introductions Susan Harris, Merit Robert Watson, GT 9:15 a.m. Panel: Core Network Design and Vendor Prophecies Danny McPherson, TCB, moderator Carey Parker, Chiaro; Riad Hartani, Caspia; Dave Ward, Cisco; Puneet Agarwal, Pluris; Scott Poretsky, Avici; Dave O'Leary, Juniper; Ori Aruj, Charlotte's Web 10:45 a.m. BREAK 11:00 a.m. Why Are we Scared of SPF? IGP Scaling and Stability Dave Katz, Juniper 12:00 p.m. LUNCH 1:30 p.m. Convergence and Restoration Techniques for ISP Interior Routing Curtis Villamizar, Avici 2:30 p.m. Controlling the Impact of BGP Policy Changes on IP Traffic Nick Feamster, MIT Jennifer Rexford & Jay Borkenhagen, AT&T Labs 3:15 p.m. BREAK 3:40 p.m. Redistribution Communities for Interdomain Traffic Engineering Bruno Quoitin & Olivier Bonaventure Univ. of Namur, Belgium 4:10 p.m. Panel: Economic Differences Between Transit and Peering Exchanges Bill Woodcock, Packet Clearing House, moderator Keith Mitchell, XchangePoint Philip Smith, Cisco MONDAY EVENING BOFs ------------------- 7:30 - 9:00 p.m. Peering BOF V Bill Norton, Equinix, moderator 7:30 - 9:00 p.m. BGP Benchmarking BOF Sue Hares, NextHop, moderator 7:00 - 9:30 p.m. What Would You Like to Get Out of NANOG That You're not Getting Now? Susan Harris, Merit, moderator Tuesday, June 11 General Session ---------------- 9:00 a.m. Panel: Smart Routing Technologies 9:00-9:15 a.m. - Overview 9:15-10:15 a.m. - Vendor Presentations 10:15-10:30 a.m. - Q & A Sue Hares, NextHop, moderator Jeremy Johnson, netVmg; Aaron Britt, Opnix; Robert Bays, Proficient; Mike Lloyd, RouteScience; Daniel Golding & Brandon Ross, Sockeye 10:30 a.m. BREAK 10:45 a.m. Smart Routing (cont'd.)1 10:45-11:20 a.m. - BGP Issues 11:20-11:35 a.m. - Q & A 11:35 a.m. 10 Gigabit Ethernet Technology and Market Overview Dave O'Leary, Juniper 12:00 p.m. LUNCH 1:30 p.m. Protecting the BGP Routes to Top Level DNS Servers Lan Wang, UCLA; Xiaoliang Zhao, NCSU; Dan Pei, UC Davis; Randy Bush, AT&T; Daniel Massey & Allison Mankin, USC/ISI; Felix Wu, UC Davis; Lixia Zhang, UCLA 2:15 p.m. BGP Security Update Barry Raveendran Greene, Cisco 3:00 p.m. BREAK 3:15 p.m. Industry/Government Infrastructure Vulnerability Assessment: Background and Recommendations Avi Freedman, Akamai 3:45 p.m. Core Router Testing for High Availability Scott Poretsky, Avici 4:15 p.m. Using the New ARIN WHOIS Server Ginny Listman, ARIN 4:35 p.m. Adjourn Susan Harris, Merit

1 0

proposed government regulation of .za namespace
by Andy Rabagliati 29 May '02

29 May '02

http://www.politechbot.com/p-03548.html http://www.namespace.org.za/ Folks, A choice quote (not mine) from the URLs above :- "I write in my capacity as the person who brought the Internet to South Africa, who got permission for the country to use the ZA namespace in November 1990 and who has been the de jure administrator of the ZA namespace since February 1994." It is off-topic by virtue of the name of this list, but I think of general interest to the lists readers. Cheers, Andy!

7 10

Customer oversubscription levels
by Mathew Lodge 29 May '02

29 May '02

This might be a dumb question, but I can be sure that I'll be told if that's the case, so here goes: What's a good oversubscription ratio for customer traffic to global Internet bandwidth these days? I.e., if you have, say 90megs of bandwidth to other transit providers, how much bandwidth, in aggregate, are you selling to customers -- 90? 450? 900? Do customers care about this? Or do they assume that if they get a T1 to the Internet from you that they have their own T1's worth of non over-subscribed bandwidth to your transit providers? Thanks, Mathew

5 5

ARIN Route Registry Auto-Reply out of Control
by David McGaugh 28 May '02

28 May '02

Anyone on the list with ARIN (hopefully in the capacity to deal with ARIN route registry) who can help out with an out of control auto-reply from rtreg(a)arin.net please contact me off-list. We are getting hammered with auto-replies at a rate of about 40 messages a minute. ------------------------------------------- Dave McGaugh, Internetwork Engineer Electric Lightwave, Inc. E-mail: dmcgaugh(a)eli.net Office: 360.816.3718 | Fax: 360.816.3297 -------------------------------------------

1 0

upcoming NANOG
by Ariel Biener 28 May '02

28 May '02

Hi, Does any of you plan to make it to the upcoming Nanog ? If so, please contact me off list. thanks, --Ariel -- Ariel Biener e-mail: ariel(a)post.tau.ac.il PGP(6.5.8) public key http://www.tau.ac.il/~ariel/pgp.html

1 0

RE: operational: icmp echo out of control?
by Rowland, Alan D 28 May '02

28 May '02

We had one user report our DNS servers were hacking his system. Knew enought to do a whois but didn't have any clue beyond that. :) (lots of port 53 activity in the logs every time he surfed the web...) Best, -Al -----Original Message----- From: Richard A Steenbergen [mailto:ras@e-gerbil.net] Sent: Tuesday, May 28, 2002 1:01 PM To: Mike Tancsa Cc: Jeff Mcadams; nanog(a)merit.edu Subject: Re: operational: icmp echo out of control? On Tue, May 28, 2002 at 03:36:08PM -0400, Mike Tancsa wrote: > > Jeu 09 mai 2002 15:30:22, Port 3, ICMP, Destination Unreachable > Jeu 09 mai 2002 15:30:21, Port 3, ICMP, Destination Unreachable > Jeu 09 mai 2002 15:30:10, Port 3, ICMP, Destination Unreachable > Jeu 09 mai 2002 15:30:09, Port 3, ICMP, Destination Unreachable I don't know whats worse, those crappy personal firewalls that make every packet look like a life or death assault, or the idiots who send abuse email demanding that you do something for them or they will sue and/or hax0r you. I've seen supposed "security professionals" for theoretically clued places like NASA send abuse complaints over traceroutes they've originated, and people complain about "port 80 hacking attempts" then flatly refuse to admit they visited website. At best, it's annoying clutter. Is it any wonder that legitimate emails about ongoing DoS attacks are completely ignored or responded to a week later? At worst, it can get innocent people in trouble and cost them a lot of time, effort, and potentially money. These false abuse reports are FAR too common, and the net equivilent of crying wolf. In my opinion, it is the responsability of these personal firewall makers to at least make an EFFORT to warn their users about this. So far, I havn't seen it. -- 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)

2 1

operational: icmp echo out of control?
by Mark Kent 28 May '02

28 May '02

Hello, I've observed that our border routers are getting pinged a fair bit. I measured on one router and saw: 5 per second, seems consistent throughout the day, roughly 40 different sources every 15 seconds I took a look at the varied sources and discovered that the sites are well connected and those that resolve resolve to akamai names. This isn't more than a nuisance for me, but I run a small net. Should I conclude that an ISP with a population 10 times bigger would have their border routers getting pinged at 10 times the rate I see? If so, should we care, or just ignore it? Thanks, -mark

15 18