- NANOG - lists.nanog.org

RE: Problems on the net this afternoon?
by Hayden, Robin 07 Sep '00

07 Sep '00

>Has anyone been experiencing intermittant problems getting to certain >sites this afternoon? I had a hard time getting to work this morning, train delays, but I hear they're working on one of the lines :) Robin Hayden Cable & Wireless London -----Original Message----- From: James Smith [mailto:jsmith@dxstorm.com] Sent: Wednesday, September 06, 2000 06:29 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

cisco search
by Dave McKay 07 Sep '00

07 Sep '00

I know the AUP on Nanog says no advertising, so I hope I'm not overstepping the boundrys on this post. I am writing in to notify people of a Cisco specific search. The location url is http://cisco.google.com/cisco This search is generally the same as the one on CCO now, (because we do the search) but sometimes gets better results. -- Dave McKay dave(a)sneakerz.org Network Engineer - Google Inc.

1 0

RE: Problems on the net this afternoon?
by Tom Beeson 06 Sep '00

06 Sep '00

UUnet had a hic-up in Phoenix (grrrrrr!!!!) dumped a large part of traffic at the worst time of the morning. (UUnet is one of our primary connections). -- Tom Beeson Oso Grande Technologies At 02:12 PM 09/06/2000 -0400, James Smith wrote: >Sorry about being so vague, but I find it gets people talking about even >little problems that might be occur, which I find helpful. > >I got hold of somebody at UUNet and things seem to be back together now >with our connection. > > >-- >James Smith, CCNA >Chief Network/System Administrator >DXSTORM.COM --**--**--**--**--**--**--**--**--**--**--**-- Tom Beeson Oso Grande Technologies Network Engineer A New Mexico Technet Co. (505) 345-1748 noc(a)nm.net "Sanity checks cashed here" --**--**--**--**--**--**--**--**--**--**--**--

1 0

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