- Test - lists.nanog.org

What is APOPS?
by Barry Raveendran Greene 27 Aug '98

27 Aug '98

Hello Everyone, Got several questions about the APOPS list. It's a mailing list similar to NANOG - but focusing on Asia and Pacific. It's sponsored by APNIC (similar to EOF in Europe). To subscribe - apops-request(a)apnic.net It's majordomo, so do the usually. Barry ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Help Map the Internet - RFC 1876 - http://www.caida.org/Tools/iptll.html ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Barry Raveendran Greene | || || | Senior Consultant | || || | Corporate Consulting | |||| |||| | Office of the CTO | ..:||||||:..:||||||:.. | e-mail: bgreene(a)cisco.com | C i s c o S y s t e m s | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PGP Public Key is registered at http://pgp5.ai.mit.edu/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Per-AS average packet sizes.
by Bradley Reynolds 27 Aug '98

27 Aug '98

I was fooling around with low cost (and functional) alternatives to netflow. Using some of the cef per-prefix accounting, I came up with some average packet sizes per-as. I do not know if other pieces of software provide this, but it was interesting to me given the recent debate over traffic/political network engineering. Note: These ASs were chosen because I was looking at aads. Also, some of the average packet sizes (specifically for the universities) are skewed because of small sample size. This data was taken over ~ 3 week period. Report for AS4200 Average Packet Size=207.337627328432 bytes Report for AS6081 Average Packet Size=91.0894051393711 bytes Report for AS4908 Average Packet Size=163.0295230081 bytes Report for AS600 Average Packet Size=185.555733807033 bytes Report for AS3491 Average Packet Size=122.656178436359 bytes Report for AS6172 Average Packet Size=119.599522802812 bytes Report for AS4565 Average Packet Size=101.694844850921 bytes Report for AS3967 Average Packet Size=100.630045695107 bytes Report for AS6502 Average Packet Size=86.1414993563231 bytes Report for AS5696 Average Packet Size=129.799373074708 bytes Report for AS5000 Average Packet Size=815.050455624583 bytes Report for AS3951 Average Packet Size=242.941615947634 bytes Report for AS5646 Average Packet Size=152.496173302478 bytes Report for AS2551 Average Packet Size=230.438698353958 bytes Report for AS4006 Average Packet Size=102.0254851338 bytes Report for AS6402 Average Packet Size=180.478647376678 bytes Report for AS3549 Average Packet Size=78.548229806905 bytes Report for AS10303 Average Packet Size=69.6246769007691 bytes Report for AS6259 Average Packet Size=124.865566859912 bytes Report for AS87 Average Packet Size=295.944768380059 bytes Report for AS3847 Average Packet Size=85.967930320445 bytes Report for AS5762 Average Packet Size=104.255525645514 bytes Report for AS693 Average Packet Size=205.356601218687 bytes Report for AS103 Average Packet Size=451.407999388192 bytes Report for AS160 Average Packet Size=225.945025341309 bytes Report for AS1746 Average Packet Size=354.80284738041 bytes BR

1 0

RE: UUNET Outage in Portland OR
by Kevin Brown 27 Aug '98

27 Aug '98

At 01:47 PM 8/26/98 -0700, Chad Skidmore wrote: >Kind of hard to get accurate and timely information out with that kind of delay! Surely not due to the overwhelming volumes of messages dealing with BBN/Exodus which have suffiently confirmed that many members are email cranks expressing opinions and concepts to which they have little or no facts/involvement. Sure BGP is a relative issue, but the topic of late has dealt with payoffs and billing... not a nanog-ish item. Tis about time for a filter to deal with the BBN/Exodus thread direct to /dev/null.

1 0

Sprint/HiNet
by william＠pacific.net.ph 27 Aug '98

27 Aug '98

Hi all! Whenever we do a traceroute from our Sprint connection to a host in the HiNet network, we get timed out in the Sprint/HiNet link, as follows: Tracing route to w3.hinet.net [168.95.1.82] over a maximum of 30 hops: 1 138 ms 116 ms 113 ms pi-ph-ts01.pacific.net.ph [210.23.234.128] 2 142 ms 111 ms 116 ms pi-ph-gw01.pacific.net.ph [210.23.234.1] 3 332 ms 330 ms 340 ms 204.59.178.25 4 375 ms 324 ms 328 ms 204.59.120.198 5 323 ms 322 ms 339 ms 144.232.1.153 6 380 ms 366 ms 365 ms 144.232.8.70 7 347 ms 373 ms 374 ms 144.232.4.142 8 * * * Request timed out. 9 546 ms 529 ms 523 ms 168.95.253.126 10 540 ms 532 ms 540 ms 168.95.253.189 11 547 ms 556 ms 547 ms w3.hinet.net [168.95.1.82] Trace complete. Line 8 is always like this and a customer of ours is complaining about it. Is this a time out or congestion or something else? William

4 3

Settlements, etc., etc.
by Derek Elder 27 Aug '98

27 Aug '98

I really wanted to stay out of this one, but something that I remembered from a speech made by an FCC bigwig at ISPCON a couple years ago has pushed me over the edge. His (close enough) statement was "At the FCC, the words "regulation" and "Internet" are not allowed in the same sentence of a document." Their word processors were (supposedly) setup as to not allow it. He stated that the FCC intended to use new IP services (VoIP, etc) to help break up foreign communications monopolies. That is why they were keeping their hands off. So the question that I pose is: Do we actually think that if our greed or inability to find a good peering model, forces us into a "pay for what you use" model, the FCC won't change their minds very quickly and decide that they want their piece of the pie after all? Deciding who is more important - the sender or receiver - is worse than maddening. It's impossible. That's why caller pays in the Telco world and they have alot more infrastructure to track those things than we do. Unfortunatly, I think that this is a train out of control and keeping the regulators out at this point is impossible. Knowing GTE's history (i.e., a company that would never have survived without access charges), who's to say that the BBN movements are not a precisely calculated move to -force- regulators to step in? > Derek Elder > US Web Corporation > Senior Engineer > 212-548-7468 > Pager - 888-232-5028 > delder(a)usweb.com > http://www.usweb.com > A Strategic Partner for the > Information Age. > >

2 1

RE: Urrr... A-root server foul ?
by Dave Van Allen 26 Aug '98

26 Aug '98

! ip subnet-zero ! maybe? Best regards, David Van Allen - FASTNET(tm) / You Tools Corporation dave(a)fast.net (888)321-FAST(3278) http://www.fast.net FASTNET - Business and Personal Internet Solutions > -----Original Message----- > From: Havard.Eidnes(a)runit.sintef.no > [mailto:Havard.Eidnes@runit.sintef.no] > Sent: Wednesday, August 26, 1998 3:49 PM > To: rirving(a)onecall.net > Cc: nanog(a)merit.edu > Subject: Re: Urrr... A-root server foul ? > > > > Is anyone else seeing this? > > Yep, once you point us in that direction. > > > really *cool* udp trick, or is bcast space now DNS capable? > > What am I missing? > > 198.41.0.4 can as far as I can see not be a broadcast address > under any left-contiguous netmask, unless it's the 0'th address > on some subnet and the router sitting on the net has the really- > old-style-and-now-deprecated directed broadcast address > forwarding enabled (not likely). > > A DNS query to 198.41.0.4 does however only elicit a single > response, so I doubt this is much to worry about. (My guess: > they have 4 machines sharing the load via some form of load- > sharing setup.) > > - Håvard >

1 0

Urrr... A-root server foul ?
by Richard Irving 26 Aug '98

26 Aug '98

Is anyone else seeing this ? really *cool* udp trick, or is bcast space now DNS capable ? What am I missing ? Server: ns2.mci.net Address: 204.70.57.242 Non-authoritative answer: Name: A.ROOT-SERVERS.NET Address: 198.41.0.4 And a ping yields ? 64 bytes from 198.41.0.4: icmp_seq=16 ttl=250 time=59 ms 64 bytes from 198.41.0.4: icmp_seq=16 ttl=249 time=76 ms (DUP!) 64 bytes from 198.41.0.4: icmp_seq=16 ttl=250 time=77 ms (DUP!) 64 bytes from 198.41.0.4: icmp_seq=17 ttl=250 time=57 ms 64 bytes from 198.41.0.4: icmp_seq=17 ttl=250 time=64 ms (DUP!) 64 bytes from 198.41.0.4: icmp_seq=17 ttl=249 time=73 ms (DUP!) 64 bytes from 198.41.0.4: icmp_seq=18 ttl=250 time=71 ms 64 bytes from 198.41.0.4: icmp_seq=19 ttl=250 time=53 ms 64 bytes from 198.41.0.4: icmp_seq=19 ttl=249 time=57 ms (DUP!) 64 bytes from 198.41.0.4: icmp_seq=19 ttl=249 time=73 ms (DUP!)

4 3

RE: BBN/GTEI
by Goodwin, Dustin 26 Aug '98

26 Aug '98

This ignores the fact that both companies have paying customers. If I am a BBN access customer and I cannot get to any sites, then what good is BBN to me? As an access provider, I built a access infrastructure and I get payed by my customer for providing it to them (include in this cost is the price to connect to content providers). If I am a Exodus customer and I pay for hosting, Exodus is no good to me if it doesn't have any viewers. Exodus built a hosting infrastructure, its customers pay for the right to use that infrastructure(included in this cost is the price to connect to viewers). So both companies need each other. Both companies get payed for providing a service. Where is the problem? Why should BBN get a cut of what Exodus's cutomers pay? BBN is trying to get payed to provide something it needs to from Exodus. If BBN needs it, why would Exodus pay for it? Isn't BBN trying to get payed twice? > -----Original Message----- > From: Michael Dillon [SMTP:michael@memra.com] > Sent: Friday, August 21, 1998 9:13 AM > To: list(a)inet-access.net > Subject: Re: BBN/GTEI > > On Fri, 21 Aug 1998, Brian Wallingford wrote: > > > If you don't peer with or buy > > transit from GTEI, sit back, shut up, and watch and learn (seriously - > > WATCH and LEARN). > > This is seriously good advice. A lot of people have compared this to the > UUNet peering flap but the two incidents couldn't be more different. In > UUNet's case you had John Sidgemore, an economist, attempting to throw his > weight around and push towards a paid peering scenario with a cartel at > the core, all of this based solely on an economics viewpoint. > > But with BBN, there is a network engineering problem at the core of the > issue, that of assymmetric traffic patterns. And BBN realizes that this > sort of assymmetry will become more and more common in the future and that > the industry needs to find some sort of hybrid peering/settlement > mechanism that will work for both parties in an asymmetric arrangement. > They are looking at things like what kind of methodology can be used to > measure the traffic, what constitutes free balanced peering, how to charge > for regional transit on traffic that exceeds the limits of balanced > peering, and similar difficult issues. > > I believe that the reason we are not hearing many details is that there > are NDAs in place about the specifics of the Exodus, AboveNet and CRL > peering contracts. But sooner or later those companies will come to some > sort of agreement and BBN will explain the rationale behind their > thinking. We may not totally agree with that rationale, but I think we can > all see that establishing peering between two specialty providers has to > be handled a bit differently than between two full-service providers. > > And if BBN's ideas can be refined and accepted by the industry, then we > will be in a better position because there will be an established > methodology and pricing structure for an ISP to transition from full > transit to full peering. I know from my experience with Priori that a lot > of peering negotiations happen like an old-boys club cartel and if you > ain't a member of the club, you can't get in. We need to change this so > that there is an open process by which anyone can transition to being a > peer based on an open and accepted methodology and pricing structure. > > -- > Michael Dillon - Internet & ISP Consulting > Memra Communications Inc. - E-mail: michael(a)memra.com > Check the website for my Internet World articles - http://www.memra.com > >

14 22

RE: UUNET Outage in Portland OR
by Chad Skidmore 26 Aug '98

26 Aug '98

It was up within an hour of going down. UUNET was able to get someone on site to deal with the problem. It looks like it took nearly 24hrs for my post to make it onto the NANOG list. Kind of hard to get accurate and timely information out with that kind of delay! ---------------------------------------------- Chad Skidmore Director of Network Engineering Northwest Nexus, Inc. http://www.nwnexus.com 888-NWNEXUS > -----Original Message----- > From: Steve Weaver [mailto:cyberscape@faulkner.com] > Sent: Wednesday, August 26, 1998 1:24 PM > To: Chad Skidmore > Subject: Re: UUNET Outage in Portland OR > > > Chad, > > Anymore on this outage? > > Thanks. > > At 10:27 AM 8/25/98 -0700, you wrote: > >Currently UUNET is experiencing a network outage in Portland > OR. Master > >ticket #0980776. No ETR at this time. > > > >---------------------------------------------- > >Chad Skidmore > >Director of Network Engineering > >Northwest Nexus, Inc. > >http://www.nwnexus.com > >888-NWNEXUS > > > > > > >

1 0

Re: Urrr... A-root server foul ?
by Havard.Eidnes＠runit.sintef.no 26 Aug '98

26 Aug '98

> Is anyone else seeing this? Yep, once you point us in that direction. > really *cool* udp trick, or is bcast space now DNS capable? > What am I missing? 198.41.0.4 can as far as I can see not be a broadcast address under any left-contiguous netmask, unless it's the 0'th address on some subnet and the router sitting on the net has the really- old-style-and-now-deprecated directed broadcast address forwarding enabled (not likely). A DNS query to 198.41.0.4 does however only elicit a single response, so I doubt this is much to worry about. (My guess: they have 4 machines sharing the load via some form of load- sharing setup.) - Håvard

1 0