December 1998 - Test - lists.nanog.org

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 08 Dec '98

08 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

Prioritization...
by Rich Sena 08 Dec '98

08 Dec '98

Got a question - been trying to track some loss I've seen in our traffic - and one of the things that came to mind was packet priority and a lower priority being set for UDP at some exchanges - especially congested ones. Anyone here doing such - snd if so does anyone have anysort of data re: how much of that traffic is being dropped... -- I am nothing if not net-Q! - ras(a)poppa.clubrich.tiac.net

2 2

Re: More Sidgemore on per-bit pricing (fwd)
by Paul Vixie 08 Dec '98

08 Dec '98

> > One could use something like MPLS to determine the Ingress and Egress > > points of the network if it had a robust enough MIB. > > Goodbye scalability. > > Please tell me what happens when a link carrying a million MPLS-ed > flows does flap. I can't. But scalability isn't important in the modern era. MPLS and to some extent QOS are all intranet standards, and if they are ever applied to the true universal Internet in an end to end way we'll see a pretty much vertical rise in the complexity of things like BGP and record-route and traceroute. No matter how bad an idea it seems like, the fact remains that to push public data networking to the next level of functionality, vendors and pundits and especially venture capitalists are deliberately waffling on the definition and extent of the word "public." Stateful internets are bad. Stateful intranets aren't so bad. The last voice-over-IP story I heard was just a way to increase cost efficiency in the last mile -- it wasn't an end-to-end thing. The one before that was just to increase cost efficiency in a long distance carrier -- it wasn't an end-to-end thing. Vendors of both equipment and services are thinking of new technology in terms of what it can do for large VPN-consumers or for networks which mostly just move data for their own direct customers. And of course, most of the so-called first tier expects there to just be one network in the endgame, with all others as customers of it. The people who, six years ago, yelled about NAT, and ten years ago, yelled about firewalls, all because "internet" means "network of networks" and anything which couldn't scale to universal end-to-enditude shouldn't be used (and certainly not standardized!) probably had the unspoken worry that we were headed for a "network of VPNs" or a "network of NAT clouds" or a "network of its own customers". I had to think my way through all of this in order to understand the last batch of Internet industry investment analysis briefs I slogged through. Nobody, anywhere, expects to see a million MPLS'd flows going over a single link before 2004, and by that time, the problems will be very different from today's. -- Paul Vixie <paul(a)vix.com>

2 1

Many Thanks!
by Thom Youngblood 08 Dec '98

08 Dec '98

Turns out to be IPinIP packets coming from 10.2.2.21. (Spoofed, of course.) The NOC of the network sending 20mb per second of these is hearing from us now. Thanks for all the help.

1 0