- Test - lists.nanog.org

Re: 10/8 announced ?
by Paul Ferguson 11 Jul '96

11 Jul '96

10/8 gets announced at least once a day by someone somewhere. Really. So what else is new? Smart providers explicitly filter RFC-1918 address space. ;-) - paul At 07:31 PM 7/10/96 -0500, Kai wrote: >Hmm, is this just me , or... > >traceroute to 10.1.1.1 (10.1.1.1), 30 hops max, 40 byte packets > 1 bigmac.netaxis.com (198.69.103.23) 214 ms 155 ms 209 ms > 2 aries.netaxis.com (198.69.103.1) 217 ms 155 ms 149 ms > 3 sl-dc-11-S1/2-T1.sprintlink.net (144.228.121.93) 187 ms 171 ms 159 ms > 4 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 307 ms 282 ms 289 ms > 5 sl-pen-1-H2/0-T3.sprintlink.net (144.228.10.34) 167 ms 241 ms 179 ms > 6 icm-pen-2-F1/0.icp.net (144.228.60.101) 167 ms 241 ms 169 ms > 7 icm-pen-1-F0/0.icp.net (192.157.69.30) 1007 ms 171 ms 199 ms > 8 icm-dc-2-H0/0-T3.icp.net (198.67.131.17) 177 ms 184 ms 259 ms > 9 icm-dc-1-F0/0.icp.net (198.67.131.36) 176 ms 183 ms 179 ms >10 icm-ecrc-1-S0-1984k.icp.net (198.67.129.18) 287 ms 284 ms 279 ms >11 ECRC-RBS.ECRC.DE (193.23.5.97) 357 ms 267 ms 279 ms >12 Munich-EBS.EBONE.NET (194.112.80.218) 277 ms * 290 ms >13 ECRC-RBS.ECRC.DE (193.23.5.97) 406 ms 377 ms 379 ms >14 Munich-EBS.EBONE.NET (194.112.80.218) 337 ms 366 ms 319 ms > > >"If we don't have enough IP space, we'll just make more..." > >bye,Kai >ps: someone with access to a serious router show us this route, please... > >

2 1

Re: 10/8 announced ?
by kai＠netcom.com 11 Jul '96

11 Jul '96

Paul Ferguson wrote: > > 10/8 gets announced at least once a day by someone somewhere. Really. > > So what else is new? Smart providers explicitly filter RFC-1918 address > space. ;-) > > - paul Which means that Sean Doran....uhm....err....doesnt. *duck* :) bye,Kai

1 0

10/8 announced ?
by kai＠netcom.com 11 Jul '96

11 Jul '96

Hmm, is this just me , or... traceroute to 10.1.1.1 (10.1.1.1), 30 hops max, 40 byte packets 1 bigmac.netaxis.com (198.69.103.23) 214 ms 155 ms 209 ms 2 aries.netaxis.com (198.69.103.1) 217 ms 155 ms 149 ms 3 sl-dc-11-S1/2-T1.sprintlink.net (144.228.121.93) 187 ms 171 ms 159 ms 4 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 307 ms 282 ms 289 ms 5 sl-pen-1-H2/0-T3.sprintlink.net (144.228.10.34) 167 ms 241 ms 179 ms 6 icm-pen-2-F1/0.icp.net (144.228.60.101) 167 ms 241 ms 169 ms 7 icm-pen-1-F0/0.icp.net (192.157.69.30) 1007 ms 171 ms 199 ms 8 icm-dc-2-H0/0-T3.icp.net (198.67.131.17) 177 ms 184 ms 259 ms 9 icm-dc-1-F0/0.icp.net (198.67.131.36) 176 ms 183 ms 179 ms 10 icm-ecrc-1-S0-1984k.icp.net (198.67.129.18) 287 ms 284 ms 279 ms 11 ECRC-RBS.ECRC.DE (193.23.5.97) 357 ms 267 ms 279 ms 12 Munich-EBS.EBONE.NET (194.112.80.218) 277 ms * 290 ms 13 ECRC-RBS.ECRC.DE (193.23.5.97) 406 ms 377 ms 379 ms 14 Munich-EBS.EBONE.NET (194.112.80.218) 337 ms 366 ms 319 ms "If we don't have enough IP space, we'll just make more..." bye,Kai ps: someone with access to a serious router show us this route, please...

2 1

Re: 10/8 announced ? (fwd)
by Robert Bowman 11 Jul '96

11 Jul '96

Kai wanted this forwarded to the list, although it is exactly what Paul Ferguson has just stated ;) Rob Forwarded message: > From kai(a)netcom.com Wed Jul 10 18:26:17 1996 > Date: Wed, 10 Jul 1996 20:26:16 -0500 > From: kai(a)netcom.com (Kai) > Message-Id: <199607110126.UAA22659(a)netcom19.netcom.com> > To: rob(a)exoserv.exodus.net > Subject: Re: 10/8 announced ? > > NANOG is the list read by the people who are a.) responsible for this > b.) will stop this. > > I would like to see you posting what you said to the list... > > bye,Kai > > > > What's exactly suprising or new about the fact that people are advertising > > reserved IP space? People leak /24s, IXP addresses, and all sorts of things > > out into cyberspace every day. > > > > Rob > > > > > > Hmm, is this just me , or... > > > > > > traceroute to 10.1.1.1 (10.1.1.1), 30 hops max, 40 byte packets > > > 1 bigmac.netaxis.com (198.69.103.23) 214 ms 155 ms 209 ms > > > 2 aries.netaxis.com (198.69.103.1) 217 ms 155 ms 149 ms > > > 3 sl-dc-11-S1/2-T1.sprintlink.net (144.228.121.93) 187 ms 171 ms 159 ms > > > 4 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 307 ms 282 ms 289 ms > > > 5 sl-pen-1-H2/0-T3.sprintlink.net (144.228.10.34) 167 ms 241 ms 179 ms > > > 6 icm-pen-2-F1/0.icp.net (144.228.60.101) 167 ms 241 ms 169 ms > > > 7 icm-pen-1-F0/0.icp.net (192.157.69.30) 1007 ms 171 ms 199 ms > > > 8 icm-dc-2-H0/0-T3.icp.net (198.67.131.17) 177 ms 184 ms 259 ms > > > 9 icm-dc-1-F0/0.icp.net (198.67.131.36) 176 ms 183 ms 179 ms > > > 10 icm-ecrc-1-S0-1984k.icp.net (198.67.129.18) 287 ms 284 ms 279 ms > > > 11 ECRC-RBS.ECRC.DE (193.23.5.97) 357 ms 267 ms 279 ms > > > 12 Munich-EBS.EBONE.NET (194.112.80.218) 277 ms * 290 ms > > > 13 ECRC-RBS.ECRC.DE (193.23.5.97) 406 ms 377 ms 379 ms > > > 14 Munich-EBS.EBONE.NET (194.112.80.218) 337 ms 366 ms 319 ms > > > > > > > > > "If we don't have enough IP space, we'll just make more..." > > > > > > bye,Kai > > > ps: someone with access to a serious router show us this route, please... > > > > > > > >

1 0

L'ironie est le fond du caractere de la Providence
by Sean Doran 11 Jul '96

11 Jul '96

Alternatively: Chang'd loves are but chang'd sorts of meat, And when he hath the kernel eat, Who doth not fling away the shell? Well, Elise is going to yell at me -- perhaps even in person -- for abusing the mailing list, and I deserve it, but I can't help myself. I like irony too much. Maybe the subject line (I figure that she likely will recognize the source) will appease her a bit. (So, Kai, no need to duck :) ) Anyway, the originator of this note should be lauded for very sensibly restricting its audience, and I deserve the blame for posting it here (with permission obtained after much grovelling and pleading on my part), thinking it was too good a line not to share. Sean. - -- > O please, o please, o please can I post this as a note from > an anonymous person? O please o please o please? > > Sean. > - -- > To: smd(a)sprint.net > From: Someone You Wouldn't Expect > > The really odd thing about Metcalfe arguing for more control, more > predictability, inevitable failure of distributed control, etc., is that it > makes me think I've taken a time machine back in time to a slightly > different universe where someone else invented ethernet and Metcalfe is > promoting Token Ring. > > But since I'm not a North American Network Operator I'll keep my mouth shut > in public.

1 0

Re: Ping flooding
by Brett D. Watson 11 Jul '96

11 Jul '96

> From: Jerry Anderson <jerry(a)gi.net> > Subject: Re: Ping flooding > > Return-Path: <nanog-owner(a)merit.edu> > In-Reply-To: <9607092210.AA19147(a)butler.ncube.com> from "Vadim Antonov" at Jul > ***9, 96 03:10:38 pm > X-Mailer: ELM [version 2.4 PL23] > MIME-Version: 1.0 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: 7bit > Sender: owner-nanog(a)merit.edu > Precedence: bulk > > > That's once again a matter of defaults -- routers should _by > > default_ discard all packets from interfaces which they won't > > use for forwarding those packets back. > > Why? then you'll never have an asymetric route. how handy. -brett

1 0

Re: Ping flooding (fwd)
by Daniel W. McRobb 10 Jul '96

10 Jul '96

> On Jul 9, 20:31, "Daniel W. McRobb" <dwm(a)ans.net> wrote: > > When I asked Cisco about this (a while ago), they said flow-switching > > incurred a 20% overhead (which someone there called "minimal", which I > > didn't agree with). > > I guess this has changed; we have a clear performance improvement. > > > 'tis very unwise to run IP accounting on a very busy router. We > > wouldn't dare turn it on for a core router w/ 40,000 routes. Some of > > our customers who have done so on border routers immediately turn arond > > and complain about performance problems. :-( And we're not talking > > Yes, if the box doesn't have the CPU to do it, don't. But I said > 'edge routers'. Core routers are the wrong places to do it anyway, > depending on paradigm; but generally, traffic will be collected from > and broken down into fairly small streams. It's only when it passes > through core routers the proportions are too large; a 'border > router' for a large network/customer is in this context a core router. "fairly small" streams is only true if you don't have bandwidth-heavy customers. We have several customers w/ lots of bandwidth, who use it. > > 'tis also very important to know the route taken for a net when > > analyzing the data. Discrepancies here can be huge and completely > > invalidate any conclusions you might make about how much traffic is > > traversing a given path. > > For this we like combined interface stats; AS-based traffic matrices > are (from our point of view) mostly useful for end-to-end measurements. > > > traversing a given path. This is particularly true for busy end routers > > (like NAP peers) and core routers. > > One wouldn't do it here anyway, as noted. Then you potentially miss huge contributions to your network load (NAP routers <-> T3 customers, for example). > > I also prefer measurements that won't potentially get dropped in > > transit (throwing a big unknown into confidence level of data). Is > > there an efficient means of retrieving flow data from a Cisco and not > > potentially dropping a bunch of it on the floor? > > You may drop something from time to time, but this simply turns the > data collection into sampling. With a sufficient sample size, this > is as good as anything; you still want to correlate your information > with other sources, such as interface stats, and adjust accordingly. > But please, let us not turn this into "my box is better than your > box". I wasn't doing that. I asked an honest question. Dropping data at indeterminate points, unknown to the measurement tool, is not turning collection into sampling (well, at least not useful sampling). If you have no means of determining how many were dropped, and under what conditions, you have essentially useless data. Interface stats won't get you that information. If you drop traffic at times of heavy bursts you lose some of the most interesting data (that which may be causing your network real pain). Is there an efficient means of retrieving flow data from a Cisco and not potentially dropping a bunch of it on the floor? Will there be at some point in the future? We'd use it if it was available. We'd even pay for it, I imagine. :-) Daniel ~~~~~~

3 3

Re: Ping flooding (fwd)
by Sean Doran 10 Jul '96

10 Jul '96

| But please, let us not turn this into "my box is better than your | box". Why not? I'm sure there are people who would LOVE to see people buying up all the NSSes that ANS is throwing away. They're *fabulous*. Sean.

2 1

Re: Ping flooding
by rmg＠ranma.com 10 Jul '96

10 Jul '96

From: Michael Dillon <michael(a)memra.com> > On Tue, 9 Jul 1996, Daniel W. McRobb wrote: > > > There will likely never be a means for a single NSP to track down the > > real source of spoofed packets using IPv4. Service providers won't be > > letting other service providers track spoofed packets through their > > network. > > Why not? Don't telcos do this? Yes, telcos do this, but they (used) to have the same problem we all have in the ISP world, in that your average DMS-100 voice switch is optimized for call processing, not for call-detail searches. Your average call-detail search used to take 1-2 hours for a 5 minute window. (I say "used to" as now the SS7 STP processors now do the call-detail recording, and call lookups are a matter of keystrokes and seconds away.) Router mfgrs are still in the stages of switching packets as fast as they can, not detail management. And of course, nooone of us want to drop our routers down to process switching to track packets. > Or if your answer is that telcos only do it for the police and not for > each other, then my question would be why can't we form an Internet > equivalent, maybe affiliated with something like CERT, that can make these > requests and with whom NSP's would cooperate. Telco call-detail lookups for law enforcement constitute <-.01% of those lookups (I did work at MCI's Western Region Net Mgt canter). All the other lookups are for maint purposes (like finding marginal trunks, tracking call patterns, making sure routing databases are working right, etc). It's obviously going to be different in our case. rob.

2 1

Re: Ping flooding (fwd)
by Sean Doran 10 Jul '96

10 Jul '96

| I have always been under the impression that Cisco flow switching and | high performance were mutually exclusive if there were too many active | flows as is the case for the major US ISPs at least. Not quite. The flow switching path was tuned manually by Darren Kerr, who is an impressive bit-twiddler. He spent some time watching how his path behaved in a huge network (mine) and in a big network (Dorian's) and adjusted it accordingly. The current path appears -- to me, qualitatively -- to consume less CPU per packet per second in 7500s than the other released switching methods. Yes, I was seriously surprised too, however People That Know with three letter logins weren't. There are some memory concerns and some concerns about mixing optimum switching and flow switching in a busy box with recent code, however these are bugs that don't affect normal processing. | Another difference is with the flow switching, you need to catch them | in the act. With the sampling and collection, you can call hours | later (days or weeks actually, years if you count going to tape) and | still determine the candidate entry points for the traffic. I don't | think there is a practical way to get the same sort of historic | archive from the flow switching stats. conf t flow-export <ip-address> ^Z and have a client do whatever you want with the stream of UDP datagrams that will be sent to you. The dkerr stuff is neat. I'm looking forward to the completion of the other work in progress by the folks who've inherited it, since that has considerable neatness potential too. Sean.

2 1