- NANOG - lists.nanog.org

Preventative maitenance for diag modems
by Elliott, Andrew 10 Apr '02

10 Apr '02

Hello, I am trying to find a tool to monitor the availability of our diag modems. There have been instances where we were in need of gaining console via the diag number, only to find that it is RNA/oper rec/etc... Can anyone point me toward a tool for this? I heard a rumor on #nanog that Verio has a very nice tool for this. Thanks for your assistance! -andrew

1 0

long distance gigabit ethernet
by Greg Pendergrass 10 Apr '02

10 Apr '02

I'm looking at long-haul gigabit ethernet as a possible solution versus traditional SONET and I'm a little bit wary as promises made on web pages and white papers aren't *always* completely accurate. I'd appreciate it if you all would share your experiences with it. By long-haul I mean in the hundreds or thousands of miles. I need to know: a. Does it work properly? b. Who offers it in the continental US? Please contact me off-list. Any information is greatly appreciated. Thanks in advance, Greg Pendergrass

12 14

Latest CERT/CC attack trends
by Sean Donelan 10 Apr '02

10 Apr '02

CERT/CC has published a paper on the latest trends in malicious attacks (not accidents, operator error, etc) on the Internet. http://www.cert.org/archive/pdf/attack_trends.pdf CERT/CC identifies four increasing trends affecting the network infrastructure: 1. Distributed Denial of Service - From an infrastructure point of view this is a resource exhaustion issue (bandwidth, arp tables, cpu, etc) 2. Worms - Really a vector rather than a different attack, how the attack payload is delivered 3. Attacks on the Domain Name System - Registry security, cache issues at all levels, out of date server software 4. Attacks against or using routers - Transitive trust issues, control/data seperation, poorly secured routers used as attack platforms

1 0

Re: [Q] BGP filtering policies
by smd＠clock.org 10 Apr '02

10 Apr '02

| UUNet suggested that any problems encountered | as a result of this allocation could probably solved by e-mailing | any NSP whose traffic interchange with us might be negatively | affected (unlikely, to be sure, but still...), and would then | change their filter (I'm unconvinced of this scenario). Try offering some money to such NSPs -- it probably doesn't have to be much, and of course you would be receiving substantial benefit... Sean.

2 1

RE: [Q] BGP filtering policies
by smd＠clock.org 10 Apr '02

10 Apr '02

| With enough badgering most providers will accept a /24 announcement of PA | space. With a token offer to make a payment of, say, 150 dollars, you will save yourself considerable badgering time and effort. Of course, if time isn't money, or you don't believe in negotiations (think ebay...), then badger away. Sean.

1 0

RE: [Q] BGP filtering policies
by Borchers, Mark 10 Apr '02

10 Apr '02

If you'll look at this pointer to one of ARIN's pages, it lists the minimum allocation size for each CIDR block that IANA has given ARIN to manage. From what I've seen, most providers accept at least up to the prefix length that the RIR's are using, if not longer. http://www.arin.net/statistics/index.html#ipv4issued2002 Unfortunately, this doesn't help in your case. My company also has /14's from the traditional class A space. I know of only one case in two years where a customer reported a problem arising from holding a small assignment out of these blocks, which was ultimately corrected by renumbering the customer, a solution which does not scale well. Worst case, however, unless your UUNet connection goes down, you'll still be able to reach most places via your other transit and peering (since /24 is the closest thing to a "universal" allowed prefix length) and will have full reachability via UUNet. IMHO, accepting up to /24 in any of the space listed on the above URL is good service provider practice. > -----Original Message----- > From: Henry Yen [mailto:henry@AegisInfoSys.com] > Sent: Tuesday, April 09, 2002 2:11 PM > To: nanog(a)merit.edu > Subject: [Q] BGP filtering policies > > > > We were recently assigned a /22 from UUNet in conjunction with some > transit we're buying from them. The space is inside their superblock, > 65.242.0.0/14. We are concerned that our route announcement of this > block would be filtered out by some other providers, as it's not > class C/swamp space (or even class B space for that matter). > Verio's current policy, for one, indicates that this would be so. > > This is of particular concern to us as our little network encompasses > several physical partially-meshed locations, with a mix of varying > bandwidths both upstream as well as intra-location. Traffic > Engineering > is what we think is a reasonable (business) approach to address our > flexibility needs, and so we're trying to move to address > space(s) that > would be least likely to be BGP filtered. > > We've asked for a different block from UUNet but the request didn't > meet with success; UUNet suggested that any problems encountered > as a result of this allocation could probably solved by e-mailing > any NSP whose traffic interchange with us might be negatively > affected (unlikely, to be sure, but still...), and would then > change their filter (I'm unconvinced of this scenario). > > I briefly browsed the NANOG archives, and didn't see this > issue discussed > recently. Have the BGP filtering policies for "most" ISP/NSP's been > relaxed to the level of "accept /24's from class A > (ARIN-allocated) space"? > Am I mis-reading Verio's posted policy? Is there anyone from UUNet > who might choose to comment? Is there something else I'm > misunderstanding? > > -- > Henry Yen Aegis > Information Systems, Inc. > Senior Systems Programmer Hicksville, New York >

4 3

Re: packet reordering at exchange points
by Joe St Sauver 09 Apr '02

09 Apr '02

>Date: Tue, 09 Apr 2002 16:03:53 -0400 >From: Richard A Steenbergen <ras(a)e-gerbil.net> >Subject: Re: packet reordering at exchange points > >To transfer 1Gb/s across 100ms I need to be prepared to buffer at least >25MB of data. According to pricewatch, I can pick up a high density 512MB >PC133 DIMM for $70, and use $3.50 of it to catch that TCP stream. Throw in >$36 for a GigE NIC, and we're ready to go for under $40. Yeah I know thats >cheapest garbage you can get, but this is just to prove a point. :) I >might only be able to get 800Mbit across a 32bit/33mhz PCI bus, but >whatever. Of course, in reality, things like choice of NIC can matter tremendously when it comes to going even moderately fast, which is why people continue to pay a premium for high performance NICs such as those by Syskonnect. (When you see vendors touting near-gigabit throughput for inexpensive gig NICs, beware: you're probably looking at benchmarks consisting of multiple streams sent with jumbo frames between two machines connected virtually back to back rather than "real world" performance associated with a single wide area tcp flow across a 1500 byte MTU link). >The problem isn't the lack of hardware, it's a lack of good software (both >on the receiving side and probably more importantly the sending side), a >lot of bad standards coming back to bite us (1500 byte packets is about as >far from efficient as you can get), a lack of people with enough know-how >to actually build a network that can transport it all (heck they can't >even build decent networks to deliver 10Mbit/s, @Home was the closest), >and just a general lack of things for end users to do with that much >bandwidth even if they got it. In the university community, it is routine for students in residence halls to have access to switched 10 (or even switched 100 Mbps) ethernet; of course, at that point, the issue isn't a lack of things for end users to do with that much (potential) bandwidth, it is the *cost* of provisioning wide area commodity bandwidth to support the demand that that speedy local infrastructure can generate that becomes the binding constraint. And speaking of University users, if you look at Internet2's excellent weekly reports (see, for example: http://netflow.internet2.edu/weekly/20020401/#fastest ) you'll see that wide area TCP non-measurement single flows *are* occuring at and above the 100Mbps mark, at least across that (admittedly rather atypical) network infrastructure. [Maybe not as commonly as we'd all like to hope, but they are happening.] Regards, Joe

2 1

Re: Ph.D. student looking for data on network failure causes
by David L. Oppenheimer 09 Apr '02

09 Apr '02

By the way, just a clarification of my original message: the results of this study will (eventually) be published in some academic forum. I'll post to the NANOG mailing list a pointer to any results when they are available, so there's no need to email me separately to indicate your interest in the results. (Interest in providing data, on the other hand, would be most welcome!) Thanks, David > Hello network operators! I'm a Ph.D. student at UC Berkeley working for Dave > Patterson on the ROC project, which is investgiating techniques for > improving the availability and manageability of large-scale Internet > services and systems. I'm currently conducting a study of the root causes > (hardware, softare, human, etc.) and durations of failures in such systems. > To do this, I have been examining the operations trouble ticket databases > from several large-scale Internet services (of the Hotmail, eBay, Yahoo!, > etc. type). > > In doing this research, it has become apparent that for many services > (especially geographically distributed ones, e.g. those that use multiple > colocation facilities), a major cause of problems is failures of various > types in the Internet. Thus I've become interested in finding out the types > and root causes of problems in wide-area networks, e.g. within the kinds of > large-scale ASes that are administered by the folks on this list. I'm not > sure how your services track failures and problems; the problem tracking > databases at the services I've examined have been a great source of data > about problem scale, symptoms, root causes, durations, steps (and missteps!) > taken in diagnosing and fixing problems, etc. > > I'm writing to the list because I'm very interested in working with network > operators to study the causes of failures in large networks. I realize this > type of data is very sensitive to your organizations. I would be happy to > talk offline with anyone who is interested in the possibility of sharing > data, about how I've overcome the multitude of objections that have been > raised by folks I have solicited for data (protecting their customers' > privacy, securing datasets when they are not examined on the premises of the > services, anonymizing and aggregating data in reporting, etc. etc.). I'm > interested in the relative causes of failures, *not* overall availability > numbers. As a result of the precautions we've taken, several household-name > Internet services have allowed me to examine and report on the problems > their servcies have experienced. > > If you're interested in discussing the possibility of sharing access to this > kind of data about your service, please contact me. I'm willing to examine > data on the premises of your service, to anonymize it fully, to submit any > results I want to publish to your organization prior to publication, to sign > any necessary NDAs, etc. In return, I'm happy to share with you any insights > I have about the problems your service experiences, and you'll contribute to > the world's knowledge of why bad things happen to good networks. :-) > > If you're not the right person in your organization to contact with this > request, but you think your organization might be interested in > participating in this study, perhaps you could forward this email to the > appropriate person or let me know who the right person to contact in your > organization would be.

1 0

packet reordering at exchange points
by Paul Vixie 09 Apr '02

09 Apr '02

> packet reordering at MAE East was extremely common a few years ago. Does > anyone have information whether this is still happening? more to the point, does anybody still care about packet reordering at exchange points? we (paix) go through significant effort to prevent it, and interswitch trunking with round robin would be a lot easier. are we chasing an urban legend here, or would reordering still cause pain?

9 14

BGP filtering policies, UU, and you
by David Barak 09 Apr '02

09 Apr '02

Hi Henry et al, There's no real problem with your current space. Assume for the minute that each of your offices has a UU T1. You announce the chunks of your /22 through your various T1s, and that announcement (along with the UU/14) is passed along to UU customers and peers. Verio will ignore the /22, but will direct traffic to UU because they will accept the /14. so no problem there. The only possible issue is this: assume one T1 to UU and one to <non-Verio provider>. UU T1 goes down, therefore /22 withdrawn there, /22 announcement through <provider> becomes only route. Verio ignores this, and directs traffic to UU (via the /14), and UU will then direct traffic to <provider> because UU has very liberal routing policies. So in the worst case, you could get some sub-optimal routing, but nothing particularly bad, and Verio is the only substantive ISP who still uses these filters (AFAIK). The bigger issue in that case would be getting the UU line up faster :) -David Barak "Quis custodes ipsos custodiet?" - Juvenal Henry Yen wrote: We were recently assigned a /22 from UUNet in conjunction with some transit we're buying from them. The space is inside their superblock, 65.242.0.0/14. We are concerned that our route announcement of this block would be filtered out by some other providers, as it's not class C/swamp space (or even class B space for that matter). Verio's current policy, for one, indicates that this would be so. This is of particular concern to us as our little network encompasses several physical partially-meshed locations, with a mix of varying bandwidths both upstream as well as intra-location. Traffic Engineering is what we think is a reasonable (business) approach to address our flexibility needs, and so we're trying to move to address space(s) that would be least likely to be BGP filtered. We've asked for a different block from UUNet but the request didn't meet with success; UUNet suggested that any problems encountered as a result of this allocation could probably solved by e-mailing any NSP whose traffic interchange with us might be negatively affected (unlikely, to be sure, but still...), and would then change their filter (I'm unconvinced of this scenario). I briefly browsed the NANOG archives, and didn't see this issue discussed recently. Have the BGP filtering policies for "most" ISP/NSP's been relaxed to the level of "accept /24's from class A (ARIN-allocated) space"? Am I mis-reading Verio's posted policy? Is there anyone from UUNet who might choose to comment? Is there something else I'm misunderstanding? __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/

2 2