- Test - lists.nanog.org

FCC Ruling, Cost of Internet
by Ivars Upatnieks 10 Nov '98

10 Nov '98

FROM FCC DAILY DIGEST: FCC SAYS GTE'S ADSL INTERNET ACCESS SERVICES IS AN INTERSTATE SERVICE. <snip> The Commission intends to address next week, in a separate order, the broader issue of whether conventional dial-up access to the Internet, made through calls to information service providers, including Internet Service Providers (ISPs), is local or interstate in nature. That decision will address whether incumbent local telephone companies may be required to compensate their competitors for handling calls made by the incumbents' customers to ISPs that are the competitors' customers. Report No: CC-98-41. by MO&O. Action by: the Commission. Adopted: October 30, 1998. (FCC No. 98-292) CCB. ENGLISH TRANSLATION: why is this important? Most ISP's in Michigan purchase dialtone from Competitive Local Exchange Carriers(CLEC) at discounted rates from traditional Ameritech services and thus provide services at lower cost to consumers. If Internet access through CLEC's is deemed to be interstate telecommunications traffic, per minute tariff charges would begin to apply for calls delivered via CLEC's. This could mean a dramatic increase (on the order of 1-2 cents per minute) for Internet access. Additional information on the GTE "test" case can be found at http://www.fcc.gov/Bureaus/Common_Carrier/News_Releases/1998/nrcc8081.html --------- Ivars Upatnieks v (734)998-0090 ICNet, Inc. f (734)998-0816 2901 Hubbard e ivars(a)ic.net Ann Arbor, MI 48105 www.ic.net

7 8

MBONE transmission
by Richard Irving 09 Nov '98

09 Nov '98

So, does netrail have operation QoS ? It is conference quality, at least.... See MBONE sessions Source Response Dest Packet Statistics For Only For Traffic 209.44.92.7 216.37.1.1 All Multicast Traffic From 209.44.92.7 | __/ rtt 83 ms Lost/Sent = Pct Rate To 224.2.156.45 v / hop 83 ms --------------------- -------------------- 209.44.92.2 nanog2.netrail.net | ^ ttl 16 v | hop -113 s 60/467 = 13% 46 pps 31/254 = 12% 25 pps 198.108.2.20 mbone.merit.edu | ^ ttl 64 v | hop 113 s -1/407 = 0% 40 pps -1/223 = 0% 22 pps 204.70.98.29 dec3800-1-fddi-0.NorthRoyalton.cw.net | ^ ttl 65 v | hop 19 ms 0/408 = 0% 40 pps 0/224 = 0% 22 pps 204.70.104.45 dec3800-1-fddi-1.WillowSprings.cw.net | ^ ttl 66 v | hop 104 s 25/408 = 6% 40 pps 13/224 = 6% 22 pps 207.112.240.150 mrouter.chi2.nap.net | ^ ttl 67 v | hop -104 s 0/429 = 0% 42 pps 0/211 = 0% 21 pps 216.37.0.4 207.7.18.3 OCCIndy-0C3-Ether-OCC.onecall.net | \__ ttl 68 v \ hop 0 ms 394 39 pps 211 21 pps 207.7.18.5 216.37.1.1 Receiver Query Source -------------------------------------------------------------- Source Response Dest Packet Statistics For Only For Traffic 209.44.92.2 216.37.1.1 All Multicast Traffic From 209.44.92.2 | __/ rtt 83 ms Lost/Sent = Pct Rate To 224.2.162.63 v / hop 83 ms --------------------- -------------------- 209.44.92.2 nanog2.netrail.net | ^ ttl 16 v | hop -113 s 63/452 = 14% 45 pps 23/182 = 13% 18 pps 198.108.2.20 mbone.merit.edu | ^ ttl 64 v | hop 113 s 0/389 = 0% 38 pps 0/159 = 0% 15 pps 204.70.98.29 dec3800-1-fddi-0.NorthRoyalton.cw.net | ^ ttl 65 v | hop 20 ms 0/389 = 0% 38 pps 0/159 = 0% 15 pps 204.70.104.45 dec3800-1-fddi-1.WillowSprings.cw.net | ^ ttl 66 v | hop 104 s 83/453 = 18% 45 pps 6/159 = 4% 15 pps 207.112.240.150 mrouter.chi2.nap.net | ^ ttl 67 v | hop -104 s 1/457 = 0% 45 pps 0/153 = 0% 15 pps 216.37.0.4 207.7.18.3 OCCIndy-0C3-Ether-OCC.onecall.net | \__ ttl 68 v \ hop 0 ms 379 37 pps 153 15 pps 207.7.18.5 216.37.1.1 Receiver Query Source

1 0

Sprint routing problems 11/7 & 11/8
by York, Tracy (Atlanta) 09 Nov '98

09 Nov '98

Did anyone hear about or see problems on Sprint Internet this past weekend (11/7 &11/8)? If so, where can I find some detailed info on the problems (cause, solution, etc.)? Thx Tracy York Network Manager AutoConnect L.L.C. 404.843.7428 404.843.5484 fax tracy.york(a)autoconnect.com www.autoconnect.com We are born naked, wet and hungry. Then things get worse.

1 0

RE: ARIN?
by I Am Not An Isp 09 Nov '98

09 Nov '98

At 12:11 AM 11/5/98 -0800, Gary E. Miller wrote: >I think you need to take a serious look at how little of their >address space they have really used. This is not funny when I have >to kill to allocate /30. Some animals are more equal than others >on THIS farm. I know a little bit about @Home, but not as much as the people who work there, so feel free to yell & scream if I mess this up. I do believe you are correct in your implication that @Home does not utilize address space quite as efficiently as most traditional ISPs. However, they are under a greater burden than your traditional ISP. Most of the equipment they were forced to use in the "early days", and possibly a good deal of it today, is not what I would call "optimal". They are forced to allocate /24s to some cable routers no matter how few customers there are on that router. Most do not understand classless IP, or even basic subnetting. Etc., etc. The point is, the people I know at @Home do try very hard to use their IP space within reason. But there are some things they just can not do. There are two sides to every story. (Well, almost every story.... ;) >Gary E. Miller Rellim 2680 Bayshore Pkwy, #202 Mountain View, CA 94043-1009 TTFN, patrick I Am Not An Isp www.ianai.net "Think of it as evolution in action." - Niven & Pournelle

7 11

Strange BGP announcement.
by Neil J. McRae 09 Nov '98

09 Nov '98

Aug 6 13:46:20 BGP RECV 207.45.199.225+179 -> 207.45.199.226+1935 Aug 6 13:46:20 BGP RECV message type 2 (Update) length 71 Aug 6 13:46:20 BGP RECV flags 0x40 code Origin(1): Incomplete Aug 6 13:46:20 BGP RECV flags 0x40 code ASPath(2): 6453 701 65525 ((65523)) 356 1 1691 Aug 6 13:46:20 BGP RECV flags 0x40 code NextHop(3): 207.45.199.225 Aug 6 13:46:20 BGP RECV 204.174.40/24, 204.239.26/24, 204.239.27/24, 204 .239.147/24 Aug 6 13:46:20 Aug 6 13:46:20 bnp_path_attr_eer: peer 207.45.199.225 (External AS 6453) bad up date send NOTIFY flag 0 type 0 err_subcode 11, data 0 Aug 6 13:46:20 NOTIFICATION sent to 207.45.199.225 (External AS 6453): code 3 ( Update Message Error) subcode 11 (AS path attribute problem) data Aug 6 13:46:20 Aug 6 13:46:20 BGP SEND 207.45.199.226+1935 -> 207.45.199.225+179 Aug 6 13:46:20 BGP SEND message type 3 (Notification) length 21 Aug 6 13:46:20 BGP SEND Notification code 3 (Update Message Error) subcode 11 ( AS path attribute problem) Aug 6 13:46:20 Regards, Neil. -- Neil J. McRae. Alive and Kicking. Domino: In the glow of the night neil(a)DOMINO.ORG NetBSD-1.3 released! ftp://ftp.uk.netbsd.org/pub/NetBSD Free the daemon in your <A HREF="http://www.NetBSD.ORG/">computer!</A>

10 14

RE: ARIN
by Jeff Mohler 09 Nov '98

09 Nov '98

[Someone with a clue one said...*grin*] Hrmmmm, you have a major point. Suppose only routers costing 6 figures or more could do CIDR, while routers costing, say, four figures could do RIPv1? Should we give someone a large block to get "up and running" until they could afford the much more expensive routers? (stuff deleted) See, I just don't think "Address Space" should be a barrier to entry. It's not like ARIN *owns* the space, they're just the caretaker for the IPv4 space in America for the "community". As a member of the community, I want them to be fugal to avoid waste. But unusually large (and temporary) allocations to allow a company to enter the market - a company that would otherwise have to perform Herculean tasks, tasks none of the rest of us have ever had to perform, or maybe even tasks impossible with the State of the Art - is not, IMHO, waste. --- What about the case of an NSP looking to obtain a block to begin business with? A case where the parent company (via direct ownership and mergers) holds a couple of /16 allocations across a nationwide LAN infrastructure, and at the same time is not able to deliver to a spinoff arm of the company a 'clean' chunk of space to bring up a very large Internet Backbone. At the same time, the parent company has 0 SWIP documentation of the existing /16s and is still about 18 months away from a total migration to 10.x.x.x space internally. What is ARINs job at this point? To force the spinoff to document the IP allocations within the Sister company before they allow you to do business, or based on the current and future deployment (and CIDR capabilities) allocate sufficient address space to allow the business to launch and grow.

1 0

Re: Strange BGP announcement.
by Dave Curado 09 Nov '98

09 Nov '98

> Since this isn't directly my upstream's problem I've edited them out of the > log (actually, this could have come from more than one of my upstreams) > > Nov 8 17:45:26 BGP RECV x.x.x.x+179 -> x.x.x.x+1161 > Nov 8 17:45:26 BGP RECV message type 2 (Update) length 64 > Nov 8 17:45:26 BGP RECV flags 0x40 code Origin(1): Incomplete > Nov 8 17:45:26 BGP RECV flags 0x40 code ASPath(2): (0x02 0x07 0x0f 0x7f 0x02 0xbd 0x0d 0xa5 0x03 0x30 0x03 0x2f 0x03 0x2e) > Nov 8 17:45:26 BGP RECV flags 0x40 code NextHop(3): x.x.x.x > Nov 8 17:45:26 BGP RECV flags 0xc0 code Aggregator(7): 6218 206.53.128.254 > Nov 8 17:45:26 BGP RECV 206.148.144/22 > Nov 8 17:45:26 > Nov 8 17:45:26 bnp_path_attr_eer: peer x.x.x.x (External AS yyyy) bad update send NOTIFY flag 0 type 0 err_subcode 11, data 0 > Nov 8 17:45:26 NOTIFICATION sent to x.x.x.x (External AS yyyy): code 3 (Update Message Error) subcode 11 (AS path attribute problem) data > Nov 8 17:45:26 > Nov 8 17:45:26 BGP SEND x.x.x.x+1161 -> x.x.x.x+179 > Nov 8 17:45:26 BGP SEND message type 3 (Notification) length 21 > Nov 8 17:45:26 BGP SEND Notification code 3 (Update Message Error) subcode 11 (AS path attribute problem) > Nov 8 17:45:26 > > (We saw the problem start around 1640 GMT tonight) > > Problem at AS6218 perhaps ? (of course if this is the result of some > random corruption that can't be relied on... ) > > Anyone else see anything ? Another note on this, I wasn't able to stop the updates with a filter-list... perhaps because the AS path is problematic. I had to use a distribute list instead, listing each of the networks that 6218 is aggregating for... Not sure if this affects anyone else or not, but: access-list 21 deny 206.53.128.0 0.0.3.255 access-list 21 deny 206.53.128.0 0.0.0.255 access-list 21 deny 206.53.129.0 0.0.0.255 access-list 21 deny 206.53.130.0 0.0.0.255 access-list 21 deny 206.53.131.0 0.0.0.255 access-list 21 deny 206.148.144.0 0.0.3.255 access-list 21 deny 206.190.224.0 0.0.0.255 access-list 21 permit any davec

5 7

RE: time for a new list?
by John Fraizer 09 Nov '98

09 Nov '98

I don't believe that a ceiling on number of posts is a solution at all. When an issue occurs that requires, or at least RATES discussion, it would stifle effective communication. I disagree with taking all issues offline to private email as well. While I can see where it would dramatically decrease the number of messages on the list of we did so and then submitted one email with "notes" of the discussion, it will also stifle communication. Not everyone is going to pipe when they see the first or even third email on a subject. Suggestions and opinions often require some thought after reading through the thread and though some might think of the thread as idle chatter over some issue they have no interest in, others find it interesting and even educational. >At 11:57 PM 11/2/98 -0700, Forrest W. Christian wrote: > >Assuming we can't agree on what is valid and what is not - then how about a >list where a user can only post 5 messages per month? If you need to post >more than 5 messages a month to NANOG - then there is something wrong. This >would eliminate the "I said, you said" flame wars between antagonists. If >some emergency came along where one had to post more than 5 a month, they >would have to approach merit anf justify why this month is an exception. >The number 5 can be 3 or 7 for that matter. The only question is the list >serving technology (majordomo, listserv, etc.). If it is able to handle >such a function (or easily modified), we might be able to cut down on the >noise a bit. > >-Hank ------- John Fraizer | __ _ The System Administrator | / / (_)__ __ ____ __ | The choice mailto:John.Fraizer@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...

2 1

Has anyone else
by alex＠nac.net 09 Nov '98

09 Nov '98

seen UU Net wierdness? The UU Noc knows nothing: core1.brd>sho ip bgp 137.39.0.0 BGP routing table entry for 137.39.0.0/16, version 4783497 Paths: (3 available, no best path, advertised over EBGP) 6347 3549 (history entry) 209.83.160.97 from 209.83.160.97 (209.83.159.2) Origin IGP, localpref 100, external Community: 8001:666 8001:6347 Dampinfo: penalty 4211, flapped 47 times in 01:55:23 8001 8001 4969 6461 701, (suppressed due to dampening) 207.106.96.5 from 207.106.96.5 Origin IGP, localpref 100, valid, external Community: 0:6861 8001:666 8001:4969 Dampinfo: penalty 5566, flapped 54 times in 01:54:20, reuse in 00:43:20 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Atheism is a non-prophet organization. I route, therefore I am. Alex Rubenstein, alex(a)nac.net, KC2BUO, ISP/C Charter Member Father of the Network and Head Bottle-Washer Net Access Corporation, 9 Mt. Pleasant Tpk., Denville, NJ 07834 Don't choose a spineless ISP; we have more backbone! http://www.nac.net -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

3 2

IRR/RADB updates vs. ANS?
by Daniel Senie 09 Nov '98

09 Nov '98

I'm looking for information on how and/or when ANS takes updated information from the IRR databases (RADB in this case) and applies them internally. I've got a case where a net has just been moved from one ISP to another, and while a new entry was placed in the RADB, there is no connectivity from the net in question to anyplace in ANS. >From various observations, ANS is the only net not accepting routes for this particular net. I've looked at the various looking glass servers, and of the ones I know of, everything looks OK (and indeed connectivity is OK). Are there any looking glass capabilities to see what ANS is routing? One guess is that ANS only takes new data from the RADB on a set schedule and insufficient time has elapsed for that data to reach their internal files. I've got a number of other nets to be moved shortly, so I'd really like to be clear on how this works. It appears that very few nets rely on the data in the RADB, or take updated data from the RADB in near-real-time fashion. Any/all info appreciated. Dan -- ----------------------------------------------------------------- Daniel Senie dts(a)senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com

1 0