- Test - lists.nanog.org

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

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 Thu Aug 18 11:04:41 2005 > Date: Thu, 18 Aug 2005 07:56:10 -0700 (PDT) > From: David Barak <thegameiam(a)yahoo.com> > Subject: Re: New N.Y. Law Targets Hidden Net LD Tolls > To: Sean Donelan <sean(a)donelan.com>, nanog(a)merit.edu > > > > > --- Sean Donelan <sean(a)donelan.com> wrote: > > I assume the NY AG will also be targeting > > enforcement of Domino's Pizza > > because they have lots of phone numbers and > > consumers may unknowingly dial > > a phone number to order a pizza which may be a toll > > call in their area. > > A typical call to Domino's lasts < 2 minutes, and if > it's not actually a local call, you're almost > certainly not in the delivery area (and would get > redirected to the correct store). Accidentally > dialing a nonlocal Domino's results in a $.10 bill > (and no pizza). > > A typical call to a dial-up ISP is what, a few hours? > Multiple times per month? Accidentally using a > non-local ISP number can result in a bill in the > hundreds of dollars pretty easily (also no pizza). All true, but *WHY* is that 'accidentally dialing a non-local ISP number' the *ISP's* fault??

15 15

Cisco - ZOTOB and WORM_RBOT.CBQ Mitigation Recommendations
by Fergie (Paul Ferguson) 19 Aug '05

19 Aug '05

I have seen this firsthand -- the botnet DoS attacks have begun, and with a furor. I saw an extraordinarily large network brough to it's knees today by an IRCbot.es Dos. I felt like Nero -- fiddling while Rome burned. Cisco - ZOTOB and WORM_RBOT.CBQ Mitigation Recommendations http://www.uniras.gov.uk/niscc/docs/br-20050819-00710.html?lang=en Be afraid. -- 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: Announcement Propagation Delay in BGP
by Scott Weeks 19 Aug '05

19 Aug '05

----- Original Message Follows ----- From: Pete Templin <petelists(a)templin.org> To: surfer(a)mauigateway.com Cc: nanog(a)merit.edu Subject: Re: Announcement Propagation Delay in BGP Date: Fri, 19 Aug 2005 16:33:52 -0500 > Scott Weeks wrote: > > 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. > > Non-scientific test, but I've seen new prefixes appear at > the Oregon-IX route server in <20 seconds (we're only in > Texas), and reach a modestly steady state in <90 seconds. > I've seen adjustments (prepending, etc.) appear in 45+ > seconds, and withdraws in probably the same time. I was hoping to query servers in different parts of the world: China, somewhere in Africa, places in Europe, etc. Does anyone have one already written? Both of these seem to be broken: http://www.ris.ripe.net/bgplay http://bgplay.uoregon.edu/bgplay scott

1 0