- Test - lists.nanog.org

SoCal & Bay Area Troubles
by Karyn Ulriksen 06 Sep '00

06 Sep '00

Looks like GLBX may still be awash from a earlier fiber cut in the Bay Area. Netcom looks like it's having trouble in the LA area. Does anybody have any more information on what's going on down here? --------------------------------------------------------------------- Best regards, Karyn Ulriksen Director of Network Operations PublicHost, A SiteStream Company 22 Mauchly, Suite 200 Irvine, California 92618 USA Phone: (949) 743-2000 email: kulriksen(a)publichost.com URL: http://www.publichost.com ===========================================

1 0

RE: Problems on the net this afternoon?
by Karyn Ulriksen 06 Sep '00

06 Sep '00

The NOC has to be listed somewhere... > -----Original Message----- > From: Michael Medwid [mailto:Michael.Medwid@ariba.com] > Sent: Wednesday, September 06, 2000 10:48 AM > To: NANOG > Subject: RE: Problems on the net this afternoon? > > > > Call the "Internet HelpDesk". :-) > > -----Original Message----- > From: James Smith [mailto:jsmith@dxstorm.com] > Sent: Wednesday, September 06, 2000 10:29 AM > To: NANOG > Subject: Problems on the net this afternoon? > > > > Has anyone been experiencing intermittant problems getting to certain > sites this afternoon? > > > -- > James Smith, CCNA > Chief Network/System Administrator > DXSTORM.COM > > http://www.dxstorm.com/ > > DXSTORM Inc. > 2395 Speakman Drive, Suite 2200 > Mississauga, ON, L5K 1B3 CANADA > Tel: 905-822-1957 (email preferred) > Fax: 905-822-0680 > 1-877-DXSTORM (1-877-397-8676) > > "Don't be irreplaceable - if you can't be replaced, you can't be > promoted." > --Dilbert > > "The more junk you put up with, the more junk you are going to get." > --Dilbert > > > > >

1 0

RE: Problems on the net this afternoon?
by Michael Medwid 06 Sep '00

06 Sep '00

Call the "Internet HelpDesk". :-) -----Original Message----- From: James Smith [mailto:jsmith@dxstorm.com] Sent: Wednesday, September 06, 2000 10:29 AM To: NANOG Subject: Problems on the net this afternoon? Has anyone been experiencing intermittant problems getting to certain sites this afternoon? -- James Smith, CCNA Chief Network/System Administrator DXSTORM.COM http://www.dxstorm.com/ DXSTORM Inc. 2395 Speakman Drive, Suite 2200 Mississauga, ON, L5K 1B3 CANADA Tel: 905-822-1957 (email preferred) Fax: 905-822-0680 1-877-DXSTORM (1-877-397-8676) "Don't be irreplaceable - if you can't be replaced, you can't be promoted." --Dilbert "The more junk you put up with, the more junk you are going to get." --Dilbert

1 0

RE: ARIN Policy on IP-based Web Hosting
by Roeland M.J. Meyer 06 Sep '00

06 Sep '00

> From: Steve Sobol [mailto:sjsobol@NorthShoreTechnologies.net] > Sent: Friday, September 01, 2000 4:43 PM > It seems to me that there's been a lot of discussion about > IPv6, to the > point that the authors of some operating systems[0] have claimed to > actually > have working code that implements it. However, I haven't seen > much talk > about actually deploying it[1]. > > [0] OK, one. I recall seeing somewhere that Linux's TCP/IP > code supports it. it does, in the more recent kernels. It even has the v6-v4 tunnel code. > [1] Truthfully, I don't spend my time with my nose buried in technical > journals, and I don't keep up as much with the infrastructure side of > things as I'd like to (and probably should), but I would > think that this would be big news if it had actually happened. You might want to know that Mickeysoft also has an IPv6 stack for Windoze. The real issue is getting all those routers and switches deployed. We can then turn up the clients and servers as needed.

5 4

Ameritech Service Quality Report
by Sean Donelan 06 Sep '00

06 Sep '00

The Michigan Public Service Commission has launched an investigation into Ameritech's service quality. According to Ameritech, in August the estimated average repair time will be 115 hours (almost 5 days). Significantly up over previous years' average repair times of about a day (25-28 hours). http://www.cis.state.mi.us/mpsc/comm/ameritech.htm What I find interesting isn't Ameritech's long repair times, but how do providers promise 4 hour repair times when the dominant local loop provider takes over a day to fix something on a good day.

15 17

Re: ARIN Policy on IP-based Web Hosting
by Ben Ryan 06 Sep '00

06 Sep '00

> -----Original Message----- > From: Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp] > Sent: Thursday, 31 August 2000 11:19 AM > To: nanog(a)merit.edu > Subject: Re: ARIN Policy on IP-based Web Hosting > > > > Bennett; > > > > Same goes for ftp as far as I know. > > > > ftp can't be name-virtual-hosted. It is also such a wretched > > protocol that it urgently needs to be retired in all settings for > > all purposes. > > > The only real excuse I'd argue for keeping IP virtual hosts is > > Excuse? Why? > > I'm afraid some of you, including ARIN, are assuming, that IPv4 > address space will last forever, if ARIN allocate the space > cautiously. > > But, IPv4 address space will be used up, sooner or later certainly > before anonymous ftp become obsoleted and, perhaps, a lot sooner > than most of you expect and > > Note that there is no requirement to preserve IPv4 address > space forever > and the only requirement is to preserve IPv4 address space > until we are > ready for IPv6. > > However, the effort not to allocate enough IPv4 address space to > satisfy ISP requirements make name virtual hosts and NAT popular, > which, then, let people think IPv4 address space last forever, > which motivate ISPs delay the deployment of IPv6. > > So, when we really use up the IPv4 address space, ISPs will not > be ready for IPv6. > > The only reasonable solution for the problem, it seems to me, > is to assign a lot of IPv4 address space to good ISPs (good > means various things including that they are ready for IPv6) and > let all the ISPs realize the space will be used up soon. > I feel compelled to comment on this issue, there seems to be a lot of discussion on IP resourcing. Much of which I propose is obsolete. If you're interested in other views regarding not how we allocate remaining space, but how we DETERMINE how much space is REMAINING in our finite IP real estate, take a quick look. (btw, there is a lot of good sense in Masataka's opinion with regard to IPv6 takeup, but that's not what I am dealing with here so consider that viewpoint to be supplemental...) HOW IS 0.0.0.0-255.255.255.255 DIVIDED UP CURRENTLY? WHAT DO WE HAVE TO PLAY WITH? (RFC1917) (heh these figures are very vague and are not authoritative up to the minute stats, but for current info, ask an expert where to find the info - that's not me, btw :)) 25% of the Class A address space remains unallocated (Class A is 50% of total IPv4 address space) ~25% of Class B remains unallocated (25% of total IPv4 space) ~70% of Class C remains unallocated (class C is ~12% of IPv4 space) ~50% of Class D is 'reserved' for 'future applications', whatever that means (6.25% total IPv4 addresses) RESERVED SPACE: Sort of like half filling the car's fuel tank, *just in case* there's a cheaper fuel servo down the road... We have huge reserves of "reserved" space. It is naive to say they will never be used, but there are bigger issues at stake here than some academic atruistic plans to leave enough empty space to readdress the whole internet if it becomes technically necessary (or whatever other contingencies such a large 'reserved' space could be necessary). Anybody in the numbering authorities actually understand that the addresses are there to be used? While growth is incredibly strong, with a sensible management policy IP utilization can be nicely balanced off against customer need and convenience - everybody's happy, and we don't need to bitch to our software companies that X address-minimsation technique with the mail server/ftp server/web server doesn't work properly, etc etc etc. UNALLOCATED SPACE: Panicking that one has only 1/2 tank left, and hell, they're still 10 minutes away from their destination.. Quick! Turn the engine off down hills, pump the tyres up to reduce rolling resistance, throw a few kids out, etc :) Come on. IPv6 is rolling out quite well AFAIK, and while it will still be some time before it becomes the default addressing scheme for new services, take a look at the unallocated IPv4 space we have to play with in the meantime. That's not to say we should return to the bad old days of throwing a /16 at anything that moved - on the contrary, now that we're all used to it and there aren't any real technical issues remaining unsolved, CIDR/VLSM is an essential part of good IP strategy and is a requirement to maximise addressing efficiency without causing undue pain to engineers/customers. GENERAL COMMENTS: Yes. IPv4 *will* be exhausted, someday. No, IPv6 isn't yet the default addressing method. Yes, growth in IP allocation is still enormous, and shows no sign of slowing. But to those predicting doom and gloom, you're being shortsighted. Think laterally - yes, according to our current IP plan, we will be in trouble soon if orgs like ARIN don't implement draconian addressing guidelines. But step back and look at the big IP picture. Sure, we might be looking shaky with the way we've divided up the whole space 0.0.0.0-255.255.255.255. But by using common sense and remaining compatible with current reservations and planning for "likely" reserved requirements, we can increase the available space by a relatively HUGE amount. While this doesn't mean we can go back to the wasteful ways we were used to, with our current smart addressing guidelines we can maximise () Customer flexibility () Simplicity - virtual means more complex, means more variables = less reliable () Money - it's a lot easier to throw an IP at a site, set up an FTP on that IP and bind the mail server to it than to go thru the virtual rigmarole.. "err, you have to put this special, non-standard username to access this site etc" () Management - managing sites by discrete IP address is a whole lot easier from many points of view () Security - Ever tried to implement IP ACL's via Host Headers? Didn't think so... It's quite possible I have missed a whole lot of the picture here in terms of reservations - I don't claim to be a large-scale network engineer, nor am I always involved with the latest technologies. But from my understanding, much of what is reserved is a "what-if" reservation, and that which remains unallocated is just that - unallocated. Please let me know if I have made any grave technical errors in assumptions, understanding or expression. But if it's the opinion you disagree with, that's what the whole idea was - to challenge conventional wisdom on how we allocate the (finite) space we have. thanks for your time, all in all, just $0.02. regards ben ________.-~-.________ Ben Ryan Network Engineer Kiandra Systems Solutions Pty Ltd Level 9, 455 Bourke Street Melbourne, Vic. 3000 Australia Cellphone - +61-(0)417-502-061 Work - +61-(0)3-9600-1639 Fax - +61-(0)3-9600-1656 email: - ben(a)kiandra.com URL: - www.kiandra.com FOOTNOTE: Refer RFC2036, Observations on Class A Utilisation RFC1917, Appeal to greedy companies hogging unused address space RFC1466, IP Management guidelines (Other RFC's relevant, I'd be preaching to the converted telling nanog what a great resource they are, but if you haven't given them much attention, take a stroll - http://www.rfc-editor.org/ )

2 1

mae-east atm latency
by Leo Bicknell 06 Sep '00

06 Sep '00

A couple of times over the weekend I did some diagnosis of problems across mae-east ATM. Each case consisted of brief periods of high latency (200-400ms) across the fabric. This seemed to affect multiple, but not all providers at the same time. Has anyone else seen this sort of thing lately? I can't see anything wrong with all the tests I've done other then latency. -- Leo Bicknell - bicknell(a)ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request(a)tmbg.org, www.tmbg.org

3 3

PI or PA?
by Ray Davis 05 Sep '00

05 Sep '00

A customer needs a /24 which is to be announced by us and other ASes (including uunet). Should we just give them a /24 out of our space or would it be better to apply for a /24 PI space? Thanks, Ray

2 1

Sidgmore to Join MicroStrategy
by Mohamed Hirse 05 Sep '00

05 Sep '00

FYI, I guess this means UUNET will finally be devoured by WorldCom. Those of you interested, the following link has the full press release by MicroStrategy. http://biz.yahoo.com/rf/000905/n0428432.html Mo

2 1

Re: bring sense to the ietf - volunteer for nomcom
by Randy Bush 05 Sep '00

05 Sep '00

>>> * The IETF makes the standards (for good or ill) and the quality of those >>> standards, and, indeed, the decision about what to standardize has an >>> impact on operations. By attending, you can help avoid disasterous >>> standards and help shape useful ones. >> >> my candidate of the season is rfc 2547,mpls vpns. consider what it will >> do to your bgp table and the load on the PEs when you have say 100k vpns. >> and we have customers who want over 1k vpns each. > > Sorry to get off the subject, but to answer your question wrt > "what it will do to your bgp table and the load on the PEs" > please (re)read section 15 of draft-rosen-rfc2547bis-02.txt. no problem. scalability just might be of interest to providers. i am far from convinced that route reflectors will be sufficient. in a few years, just about every dedicated customer will want multiple vpns, some will want many, and most vpns will cross inter-provider boundaries. the root mis-design here is that it is telco-style, putting the complexity in the core network. this means the core bears the burden of scaling. the internet style, smart edges and simple core, scales sooooo much better. hence my mention of ipsec. but mpls vpns will sure sell hardware. randy

1 0