- Test - lists.nanog.org

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

re: POWER: San Mateo/San Francisco power outage report
by CONWAY＠pjm.com 09 Dec '98

09 Dec '98

This didn't make it to the list the first time. Doh! > -----Original Message----- > From: jzeeff(a)verio.net [SMTP:jzeeff@verio.net] > Sent: Wednesday, December 09, 1998 9:04 AM > To: SEAN(a)SDG.DRA.COM > Cc: nanog(a)merit.edu > Subject: Re: POWER: San Mateo/San Francisco power outage report > > > > breakers on the substation. It also caused a cascade effect, tripping > > the Hunters Point and Potrero power plants. > > > grid primary power sources. Aside from the human error, the system worked > > "as designed to protect the rest of the grid." > > I suggest that causing a cascade effect and increasing the area of an > outage isn't a good way to design a system. > > > If you're interested in finding our more about how the power grid is operated, > my company has a lot of operational info documented on the web. It's scope > is the operation of the interconnected grid in the mid-Atlantic region of the > US (PA-NJ-DE-MD-DC-VA). The concepts and procedures documented there are > probably very similar to the ones used on the west coast (YMMV, I'm a > networking tech not a power systems engineer). > > All of our Operations Manuals are available at: http://pubs.pjm.com > > Of specific interest might be: Emergency Operations > http://pubs.pjm.com:80/dynaweb/PJMpubs/m13/@Generic__BookView and > Transmission Operations > http://pubs.pjm.com:80/dynaweb/PJMpubs/m03/@Generic__BookView > > > Chuck Conway > Network Management > PJM Interconnection, LLC > conway(a)pjm.com

1 0

Ascend Router Question Re: IP Classless
by Andrea Di Lecce 09 Dec '98

09 Dec '98

All, Apologies for the seemingly rudimentary question. A select number of customers on Rogers cannot access a certain site, and I have reason to believe that it is due to the lack of an IP Classless statement in a downstream router. The Ascend router that the problem is originating from is owned by another network and is not under my influence. My question is, do the Ascend routers support IP Classless ? If so, what is the command to enable it on the p75 and p50 devices ? Please respond in private :) Thanks, Andrea. ************************************************** Andrea Di Lecce (416) 935-6485 Rogers@Home Network Operations 1 Mount Pleasant Road, Toronto, M4Y 2Y5 **************************************************

1 0

Re: Lawsuit threat against RBL users
by Andrew Staples 09 Dec '98

09 Dec '98

Dean wrote: >But claiming that you can "do anything you please with your equipment" is >complete BS. There isn't anything more I can say. I really hope you mean that. Of course, cant' != won't Andrew

3 2