August 2005 - Test - lists.nanog.org

(non-op) Calling Exchange Point Operators
by Joe Abley 22 Aug '05

22 Aug '05

A couple of people have expressed interest in an exchange-point BOF at NANOG 34 in Los Angeles. The BOF would include a few short presentations on topics of interest to exchange point operators, with time for more general comment and discussion. The kinds of topics that have been suggested to me are exchange point support tools (provisioning automation, monitoring, etc), architecture, vendor selection and policy. This would be a meeting about operating exchange points, rather than a vehicle for trying to attract ISPs to connect to your exchange. If there are exchange point operators here who are planning to go to LA in October, and to whom this sounds vaguely interesting, please drop me a note off-list with your thoughts. Joe (not wearing any particular hat, and speaking for himself)

1 0

Cisco Security Advisories: IDS related
by Fergie (Paul Ferguson) 22 Aug '05

22 Aug '05

This may affect several folks: SSL Certificate Validation Vulnerability in IDS Management Software http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_security_adv… Cisco Intrusion Prevention System Vulnerable to Privilege Escalation http://www.cisco.com/en/US/products/sw/secursw/ps2113/products_security_adv… FYI, - ferg ps. A couple of new bots surfaced over the weekend, too.... :-/ -- "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: 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 21 Aug '05

21 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