- NANOG - lists.nanog.org

RE: KVM over IP Suggestions?
by Simon Hamilton-Wilkes 22 Aug '05

22 Aug '05

True, but I've added it to our Cisco ACS server boxes so at least didn't need more hardware. A couple of models (DSR2161 certainly) have alternative firmware available on the Dell site which removes the requirement for the authentication server, but most of the access control goes with it. -----Original Message----- From: Aaron Glenn [mailto:aaron.glenn@gmail.com] Sent: Monday, August 22, 2005 9:42 AM To: Simon Hamilton-Wilkes Cc: nanog(a)nanog.org Subject: Re: KVM over IP Suggestions? On 8/22/05, Simon Hamilton-Wilkes <simon(a)jettis.com> wrote: > > They support P/S2 / USB / Sun and serial - though are a very expensive > way to do serial. And (last time I looked, at least) they required an expensive, proprietary, Windows-only authentication server (DSView) in addition to the client software licenses and hardware costs. aaron.glenn

1 0

Mpower contact
by Jack Bailey 22 Aug '05

22 Aug '05

Anyone have a contact at Mpower who can work on routing issues outside the hours of 9 to 5 Mon - Fri? Thanks.

1 0

Re: New N.Y. Law Targets Hidden Net LD Tolls
by Robert Bonomi 21 Aug '05

21 Aug '05

> From owner-nanog(a)merit.edu Fri Aug 19 14:37:28 2005 > From: Barry Shein <bzs(a)world.std.com> > Date: Fri, 19 Aug 2005 15:31:42 -0400 > To: nanog(a)nanog.org > Subject: Re: New N.Y. Law Targets Hidden Net LD Tolls > > > > Can't one still get minimal phone service which charges a toll on > every phone call? I know this used to cost like $5/mo but I think they > eliminated it in MA a few years ago, or made it hardship-only. Authoritative answer: "Maybe." Depends on the locale, the state regulators, and the phone company. Frequently called "Lifeline" service, when marketed for the elderly, disabled, etc. Also called "measured zero" -- when offered to the general public (for the 'cheap SOB' customer) > > Simple business lines here normally charge for every phone call, 1MB > as they're called, MB = Measured Business tho I guess that's not what > Spitzer was concerned with. > > But that's a big part of the problem, the telcos don't make this > information readily available in a form ISPs can use, and even if they > did it'd depend on the specific service option the customer had. In > our experience customers don't generally know what phone service they > have in any useful way (such as the exact name the telco calls it, > circle dialing, metro calling, etc.) I've had an ILEC refuse to tell me (a CLEC customer) where _their_ "rate center" for my numbers was. That it was 'proprietary' information that they would not release to non-customers. Never mind the fact that the reason I wanted it, was to give it to those of *their* customers who were, incidentally, also my customers. > > And boy howdy we've tried to help, motivated by the occasional livid > customer who got an unexpectedly large bill. We've had a warning just > like the one suggested on our pick a number since before some list > members here were born. It *is* definitely 'good business practice' to supply such advice to "double check" the suggested number. I question the _requirement_ -- and penalties for failure -- to do so. The area transit authority publishes a _single_ 7-digit number that you can call from anywere in the 6 NPA region they service to get travel information. For large portions of the territory dialing that 'same NPA' number results in a pricey INTRA-LATA toll call. For a differently- delimited large area, dialing a different NPA, and then that 7-digits gets you a much _less_expensive_ call to an apparent destination that is (apparently, based on the rates) much 'closer to home'. Why isn't the gov't requiring *them* to run a similar disclaimer -- and with severe penalties for non-compliance -- on all their materials listing that number? > In my not insignificant experience there's some VP inside every RBOC > cackling madly over the revenues generated by this confusion. > > And, no, don't give me the old "don't attribute to malice what can be > adequately explained by stupidity." It is *definitely* not stupidity. In the case mentioned above, the ILEC was handing calls off to the CLEC at points away from where the 'nearest' ILEC-CLEC inter-connect to the CLEC POP was. Calls to lines that were only a few dozens of numbers apart were being routed through _different_ tie-points, with *different* costs to the caller. > Double-digit billion $$ companies don't make universal, big revenue > generating mistakes over a period of probably 50 years with no doubt > millions of complaints (not just ISP dialing) out of "stupidity". > > Such confusion is their stock in trade. > > And I suspect that's, as Paul Harvey used to say, "The rest of the > story". Spitzer's office must have tried to look into why ISPs et al > can't just make a reasonably accurate suggestion to customers looking > for a phone number and, upon querying the telcos, was met with a big: > hahahahahahaha yeah, right! > > It's too obvious to have possibly been missed. > > -- > -Barry Shein > > Software Tool & Die | bzs(a)TheWorld.com | http://www.TheWorld.com > Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD > The World | Public Access Internet | Since 1989 *oo* >

2 1

Rip again!
by Tom Sanders 21 Aug '05

21 Aug '05

Hi, There isnt IMO a way in RIP to identify the source of the RIP packet (the way we have Router ID in OSPF, system ID in ISIS, etc.) Now assume we have 2 vlans defined on an ethernet. Thus we would have two IP interfaces, 1.1.1.1/24 and 2.2.2.2/24 and both using the same physical interface. RIP is running on both these interfaces. My doubt is that how will another router, which is configured in the same way (2 vlans) be able to differentiate between the RIP responses originated by 1.1.1.1 and 2.2.2.2? Thanks, Toms

2 1

RE: Semi-on-topic: Light that travels faster than the speed of light?
by Fergie (Paul Ferguson) 20 Aug '05

20 Aug '05

Well, I would imagine that the faster you can ship the bits, the faster anything can happen -- including BGP convergence and botnet attacks (too!). :-) Yeah, I realize that the possibility to actually "speed up" light via the optical transmission systems may be a long ways off (or simply impossible in practicality!), but I thought this was interesting. - ferg -- "Buhrmaster, Gary" <gtb(a)slac.stanford.edu> wrote: To make this operational, will this speed up BGP convergence? (note that there is a difference between group velocity and phase velocity. The posters of "300,000 Kilometers Per Second. It's Not Just a Good Idea, It's the Law!" are still valid). > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > Behalf Of Fergie (Paul Ferguson) > Sent: Saturday, August 20, 2005 10:40 AM > To: nanog(a)merit.edu > Subject: Semi-on-topic: Light that travels faster than the > speed of light? > > > Man, I knew I should've gotten in on the ground floor in > any effort to speed up light -- someone's going to be > rich beyond their wildest dreams. :-) > > (Thanks to a post over at Slashdot) the Science Blog > reports that: > > [snip] > > A team of researchers from the Ecole Polytechnique Fédérale > de Lausanne (EPFL) has successfully demonstrated, for the > first time, that it is possible to control the speed of light > - both slowing it down and speeding it up - in an optical > fiber, using off-the-shelf instrumentation in normal > environmental conditions. Their results, to be published in > the August 22 issue of Applied Physics Letters, could have > implications that range from optical computing to the > fiber-optic telecommunications industry. > > [snip] > > http://www.scienceblog.com/light.html > > - ferg > > -- > "Fergie", a.k.a. Paul Ferguson > Engineering Architecture for the Internet > fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net > ferg's tech blog: http://fergdawg.blogspot.com/ > >

1 0

RE: Semi-on-topic: Light that travels faster than the speed of light?
by Buhrmaster, Gary 20 Aug '05

20 Aug '05

To make this operational, will this speed up BGP convergence? (note that there is a difference between group velocity and phase velocity. The posters of "300,000 Kilometers Per Second. It's Not Just a Good Idea, It's the Law!" are still valid). > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > Behalf Of Fergie (Paul Ferguson) > Sent: Saturday, August 20, 2005 10:40 AM > To: nanog(a)merit.edu > Subject: Semi-on-topic: Light that travels faster than the > speed of light? > > > Man, I knew I should've gotten in on the ground floor in > any effort to speed up light -- someone's going to be > rich beyond their wildest dreams. :-) > > (Thanks to a post over at Slashdot) the Science Blog > reports that: > > [snip] > > A team of researchers from the Ecole Polytechnique Fédérale > de Lausanne (EPFL) has successfully demonstrated, for the > first time, that it is possible to control the speed of light > - both slowing it down and speeding it up - in an optical > fiber, using off-the-shelf instrumentation in normal > environmental conditions. Their results, to be published in > the August 22 issue of Applied Physics Letters, could have > implications that range from optical computing to the > fiber-optic telecommunications industry. > > [snip] > > http://www.scienceblog.com/light.html > > - ferg > > -- > "Fergie", a.k.a. Paul Ferguson > Engineering Architecture for the Internet > fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net > ferg's tech blog: http://fergdawg.blogspot.com/ > >

1 0

Announcement Propagation Delay in BGP
by Scott Weeks 20 Aug '05

20 Aug '05

I am going to be announcing two new prefixs into BGP soon and the netgeek in me is very curious as to the length of time it takes to show up in other parts of the world that're logically far from Hawaii. Instead of going to www.traceroute.org and refreshing repeatedly, I thought folks here might've created a tool to do just that. Or, perhaps, someone else has stats on a test they ran in the past. Anyone got any tools or suggestions on how to measure this just for fun and not as a scientific study? I plan to read the beacon paper "sahara.cs.berkeley.edu/papers/MMRB03b.pdf" but I believe this mostly looked at how long-period flaps (2 hours) were still punished. Any other pointers? Thanks, scott

4 3

Re: New N.Y. Law Targets Hidden Net LD Tolls
by Robert Bonomi 20 Aug '05

20 Aug '05

> Cc: <nanog(a)nanog.org> > Subject: Re: New N.Y. Law Targets Hidden Net LD Tolls > Date: Thu, 18 Aug 2005 12:53:43 -0500 > Thus spake "Robert Bonomi" <bonomi(a)mail.r-bonomi.com> > > *NOT* "other people's fraud". Just when you have 'intra-LATA' toll > > charges for some numbers within a single area-code. If the user is > > on one side of the area-code, and the provider's POP is on the far > > side of it, you can have a what appears to be a 'local' number, that > > does incur non-trivial per-minute charges. Without knowing _where_ > > a particular prefix is, you can't tell whether there will be toll charges > > for that call, or not, from any given call origin. > > That's why some states (e.g. Texas) require that all toll calls be dialed as > 1+ _regardless of area code_, and local calls cannot be dialed as 1+. If > you dial a number wrong, you get a message telling you how to do it properly > (and why). In some places that "solution" is _not_practical_. As in where the same three digit sequence is in use as a C.O. 'prefix', *and* as an areacode. (an where, in some 'perverse' situations, the foreign area-code is a 'non-toll' call, yet the bare prefix within the areacode is a toll call. It also becomes 'utterly meaningless', when _all_ calls incur a usage ("message units" or something similar) charge.

8 7

The off-topic thread
by Steve Gibbard 20 Aug '05

20 Aug '05

How to get your customers to use the right dial-up number is presumably on topic for NANOG. I know that when I worked for a dial-up ISP many years ago, it was frequently a big issue for our customers. However, the more general topic of how to dial a phone call in various parts of North America is presumably something that NANOG readers who need to make phone calls in North America can figure out on their own, or for which they will at least be using references other than the NANOG archives. While comprehensive documentation of how to make phone calls from various locations all over the world might actually be quite useful, the NANOG list really isn't the place for it. How dial plans should work really seems like a question for phone network operations list, although people on such a list would probably consider the question long since settled. NANOG is an Internet operations list, where we tend to deal with IP addresses and domain names rather than phone numbers. -Steve One of the list administrators

1 0

Re: New N.Y. Law Targets Hidden Net LD Tolls
by Robert Bonomi 20 Aug '05

20 Aug '05

> From owner-nanog(a)merit.edu Fri Aug 19 14:26:54 2005 > From: "Stephen Sprunk" <stephen(a)sprunk.org> > To: "Robert Bonomi" <bonomi(a)mail.r-bonomi.com> > Cc: "North American Noise and Off-topic Gripes" <nanog(a)merit.edu> > Subject: Re: New N.Y. Law Targets Hidden Net LD Tolls > Date: Fri, 19 Aug 2005 14:20:59 -0500 > > > Thus spake "Robert Bonomi" <bonomi(a)mail.r-bonomi.com> > [ attribution to me missing ] > >> That's why some states (e.g. Texas) require that all toll calls be > >> dialed as 1+ _regardless of area code_, and local calls cannot be > >> dialed as 1+. If you dial a number wrong, you get a message telling > >> you how to do it properly (and why). > > > > In some places that "solution" is _not_practical_. As in where the same > > three digit sequence is in use as a C.O. 'prefix', *and* as an areacode. > > (an where, in some 'perverse' situations, the foreign area-code is a > > 'non-toll' call, yet the bare prefix within the areacode is a toll call. > > We don't have that problem because all nearby area codes are reserved as > prefixes. For instance, if 214 and 817 are nearby, there exist no 214-817 > or 817-214 numbers (or 214-214 or 817-817). Duh? All well and good. *UNTIL* you get assigned an NXX NPA that is _already_ in use as a prefix. 773, 847, and 630 were _all_ in use as prefixes within the 312 area-code (and in the split-off 708 areacode as well) before those sequences were "legal" as an area-code. "Now What?" applies. <wry grin> > > That isn't even necessary, though; if 214-817 existed, there's no way of > confusing it with 817-xxx because all calls are either 10D or 11D. Maybe in *your* territory. :) In 312/708/630/847/773/224, dialing patterns are 7D or 11D ( 847/224 is 11D only) > Such a > tactic is only needed during the transition from 7D to 10D local dialing, > which happened here a decade ago. Lots of places have *NOT* made that transition. It is fairly _expensive_ for the telcos to implement. > For the same reason, we no longer have an excuse for not using 0XX, 1XX, and > X11 as prefixes. "Speak for yourself, John" applies. _Mandatory_ 10D dialing does *not* exist (yet) in *many* areas Mandatory 10D dialing does have non-trivial costs associated with it -- both to the telco, and to the customers thereof. There _is_ a significant performance issue -- and directly related increased costs -- in supporting mixed 7D and 10D dialing. To use 1+ for "toll alerting", in locales where intra-NPA can be toll, and inter-NPA can be local, you have to incur one of those sets of increased expenses. And the 'inconveniences' to the customer. It is a trade-off as to which is 'worse' for the customer. <wry grin> Different utility commissions have decided that issue in different ways. > We're already using [2-7]00 prefixes, but I'm not > surprised we don't yet (AFAICT) have 800 and 900 prefixes. We could > probably drop an entire area code if they started assigning those "reserved" > prefixes. 1-800-800, at least, has been in use for a number of years. and I'm pretty sure I've seen 1-800-900 numbers. > > It also becomes 'utterly meaningless', when _all_ calls incur a usage > > ("message units" or something similar) charge. > > Our PUC would be thrown out on their heads if they suggested that was even > an option; I'd suggest you look a little closer at your own and possibly do > some lobbying. You need a more cosmopolitian view -- This scheme has been in effect for 20 years, locally. *NO* chance of getting it reversed. In other major metro areas something very similar has been in effect for much longer. Most big-city systems have charged on such a basis for a long time now.,

3 3