- Test - lists.nanog.org

Re: More Sidgemore on per-bit pricing
by Dean Anderson 10 Dec '98

10 Dec '98

>Unless I'm misunderstanding you, you've misunderstood me. :-) > >I'm not talking about the card, I'm talking about my proportion of the >amount the guy I'm buying from has to pay for _his_ uplink. > >Bandwidth Costs Money. Oh I see. But you insert 'value added' inbetween, right? Or in the case of Cable modems/home DSL for 50/mo, its probably better described as 'value removed'. If I put 50 DSL T1's against 1 T1 uplink, I can pay a lot for uplink and it still won't make much difference. As long as the DSL lines hit a web cache and a newserver, everything is fine. When they don't, too bad, I guess. Isn't USWest doing all of Phoenix on 4 T1's? Whats that come out to? X,000 to 1? It looks to me like the crucial cost factor is the cost of the home equipment, and whether the customer pays for that or the ISP pays. It's not the last mile, its the last 6 inches. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

POWER: San Mateo/San Francisco power outage report
by Sean Donelan 10 Dec '98

10 Dec '98

Howdy, I'm back from vacation. By popular demand, a summary of the San Francisco/San Mateo power outage on December 8, 1998. At 8:15am workers making changes to 115-kilovolt lines at the San Mateo substation failed to properly ground the system. When they turned on the power, it caused a low frequency condition and tripped protective breakers on the substation. It also caused a cascade effect, tripping the Hunters Point and Potrero power plants. This isolated San Mateo County and northward to parts of San Francisco City from the electrical grid primary power sources. Aside from the human error, the system worked "as designed to protect the rest of the grid." Approximately 375,000 customers were without power, including San Francisco Airport (SFO), the Pacific Stock Exchange, traffic lights, and cable cars. BART (subway) used emergency power to bring trains to the next station, and then shutdown. Since the electrical grid was isolated, PG&E had to "blackstart" the system on a circuit by circuit basis. The SFO airport power was restored at 9:10AM. The San Francisco Office of Emergency Services was activated at 9:22AM according to EDIS. At 1:00PM about 200,000 customers were still without power. PG&E estimated that full restoration would be completed by 2:15PM, but some customers were still without power through the afternoon. No major injuries have been reported directly attributable to the power failure. No major Internet provider reported any network problems directly attributable to the power failure. Since this outage was caused by a PG&E error, customers may make claims for some types of damages. Other damages may be covered by private insurance. http://www.pge.com/resources/claim_form/claim_form.html In other news: On December 7, 1998 PG&E donated $87,000 to San Fransico's Emergency Services Communications Center to install extra back up electrical facilities for the center. The new facility will work with PG&E during major service interruptions to establish restoration priorities. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

10 12

Re: Ignorant mass-media strikes again
by Tony Li 10 Dec '98

10 Dec '98

avg(a)alink.net (Vadim Antonov) writes: > Am i paranoid, or is mass-media hell-bent on propaganda of antisocial > behavior in the Internet? > > Or are they just really clueless? They found out a long time ago that controversy and sensationalism sells papers. This predates the Internet or its founders. Tony

2 1

Re: Ignorant mass-media strikes again
by cache22 09 Dec '98

09 Dec '98

Subject: Ignorant mass-media strikes again Date: Wed, 09 Dec 1998 13:59:37 -0800 From: Vadim Antonov <avg(a)alink.net> To: nanog(a)merit.edu > I bet Ms. Thorton never heard that TCP can preserve idle connections > when dial-up link is down. Yeah, dial-on-demand is such a hard thing > to do! if dial-on-demand means you _demand_ the same ip address... matt sommer

1 0

ARIN co-located nameserver problem
by Dean Anderson 09 Dec '98

09 Dec '98

We are having a problem getting ARIN to do a nameserver change. We are consolidating nameservers for a new customer, and want to make our nameservers authoritative for the in-addr maps. We have a nameserver co-located at Empire Net in Nashua, NH. We do this because we don't want to have nameservice fail if our own internet connection goes down. Needless to say, Empire.net isn't responsible for our address space, nor our domains, nor the management of this machine. The machine at empire.net is currently authoritative for in-addr zones for other address space, and changing nameserver IP addresses previously has not been problematic. ARIN is now enforcing a policy of registering nameservers by IP address instead of by name as Internic and other registeries do (and did prior to ARIN). ARIN says that the IP address of the nameserver 208.223.51.250 does not belong to us (it belongs to Empire.net)--and therefore they can't put through a change to our inverse map for address space that we are coordinator of. We only have one address for one colocated machine. ARIN says it (one IP address) must be SWIP'ed to us before the changes will be allowed. ?!? This hasn't been a problem until now apparently because ARIN never previously enforced this policy. So, does anyone else have a similar situation where nameservers are colocated somewhere else? I'm pretty sure this is the case, so this is a heads up that you will have problems with updating IN-ADDR info. What about this policy of ARIN's--Do people think ARIN should be registering nameservers by name or by IP address? To make this work in general, one would need to SWIP single IP addresses. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

5 4

Re: ARIN co-located nameserver problem
by Dean Anderson 09 Dec '98

09 Dec '98

Thanks! --Dean >Dean...we added this requirement a while ago after Jon Postel/IANA came >to us about the number of unassigned and incorrect IP numbers being used >on in-addr entries. Up to now, it hasn't been an issue but you do have >a valid point so we'll review the policy and adjust it in a way to allow >for exceptions like yours. > >Kim ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Re: ARIN co-located nameserver problem
by Dean Anderson 09 Dec '98

09 Dec '98

At 02:17 PM 12/8/1998 -0800, Michael Dillon wrote: >On Tue, 8 Dec 1998 prue(a)ISI.EDU wrote: > >> >...Presumably in this case, you are responsible for that nameserver >> >and therefore the /32 should be SWIP'd to you. > >> so well, that Paul decides to sell this as a service to many >> small/medium size ISP's, running it on a single server. Now one /32 is >> the name server for multiple networks. So the registration system must >> be able to deal with that. This is not an unreasonable scenario. > >In this case Paul would not SWIP the /32 at all since he maintains the >responsibility for the server. Presumably then he would handle the >registration of the nameserver address with ARIN and the original problem >would not occur since the registration application is coming from the >entity with administrative control over the IP address in question. But if he hasn't been SWIP'd the address for his server, then ARIN won't let him assign his machine as a nameserver for inverse mapping. This might be the case if he just buys a machine and colocates it somewhere else. There is no reason to assume that management of the server also implies management of the address (address space) used by the server. (or vice versa). Whats important is that you manage the machine, and the address space whose in-addr zone you plan to service. Basically, I think one is trying to prevent lame delegations, and manage address space so that one can find out who is authoritative for it. I think there are two pieces of information that are necessary: 1) responsibility for the address space whose in-addr zone is to be serviced. Indicated by the address space coordinator 2) responsibility for the server that is to provide DNS service. Indicated by the name/handle of the server and the host coordinator. ARIN has inserted a third requirement, that I think is probably unnecessary: 3) responsibility for the address space which includes the address of the nameserver. The third requirement only works for those that put nameservers in their own address space, and doesn't seem to add anything to the goals of preventing lame delegations or address space coordination. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

2 1

UUNet goon
by Joe Shaw 09 Dec '98

09 Dec '98

I'm wondering why someone at UUNet decided to start announcing a /24 (209.113.17.0) out of our ARIN assigned /17 (209.113.0.0). >whois 209.113.17.0(a)whois.arin.net [whois.arin.net] Insync Internet Services (NETBLK-INSYNC3) 5555 San Felipe, Suite 700 Houston, TX 77056 US Netname: INSYNC3 Netblock: 209.113.0.0 - 209.113.127.255 Maintainer: SYNC An example from Nitrous (MAE West): BGP routing table entry for 209.113.17.0/24, version 335267 Paths: (6 available, best #1) 701 165.117.52.234 (metric 14) from 165.117.1.145 Origin IGP, metric 4294967294, localpref 100, valid, internal, best Community: 2548:186 2548:666 3706:153 Originator : 165.117.1.145, Cluster list: 165.117.1.145 701 206.181.125.154 (metric 52) from 165.117.1.57 Origin IGP, metric 4294967294, localpref 100, valid, internal Community: 2548:219 2548:666 3706:120 Originator : 165.117.1.57, Cluster list: 165.117.1.57 [SNIP] And here's our /17 from MAE West (5003 is us): BGP routing table entry for 209.113.0.0/17, version 102340 Paths: (14 available, best #13, advertised over IBGP) 3561 3831 5003, (aggregated by 5003 10.10.10.12) 192.157.69.48 (metric 47) from 165.117.1.120 Origin IGP, metric 4294967294, localpref 100, valid, internal, atomic-aggregate Community: 2548:202 2548:666 3706:143 701 5003 5003, (aggregated by 5003 10.10.10.8) 137.39.140.21 (metric 70) from 165.117.1.76 Origin IGP, metric 4294967294, localpref 100, valid, internal, atomic-aggregate Community: 2548:254 2548:666 3706:102 Originator : 165.117.1.76, Cluster list: 165.117.1.76 It appears that one of our previous customers who was assigned that class C by us decided to buy a T1 from UUNet and UUNet let them use our IP space. What kind of checks are usually done when peolpe come to the NSP's with other people's address space? A simple check at ARIN would have shown that the entire /17 is our IP space. What really chaps my ass is we're a UUNet multi-meg customer and so far I'm fighting to have to get them to stop blackholing my IP space. I guess their guaranteed service clause is going to come in handy this month. I smell a free month of service coming. -- Joseph Shaw - jshaw(a)insync.net NetAdmin/Security - Insync Internet Services Free UNIX advocate - "I hack, therefore I am."

2 1

Modest colocation in New York City or Northern NJ
by lp 09 Dec '98

09 Dec '98

I would like to discuss collocation arrangements with anyone who can provide modest (under $1000 monthly) rack space and IP transit. The facility must be in New York City or Northern New Jersey. Ideally, I would like to be able to get DSx lines without the local loop cost from multiple providers. Please reply to me PRIVATELY! PS This is the first and last time I will intentionally violate the NANOG AUP. However, I just had to ask, because NANOG people know everything about the Internet.

1 0

Downtown NYC
by alex＠nac.net 09 Dec '98

09 Dec '98

apprently there was a fire near 60 Hudson St., and some circuits are down from various carriers. Interestingly, we lost our Frontier Long Distance, but our GlobalCenter connectivity is OK. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 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 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

1 0