September 1997 - Test - lists.nanog.org

Re: protecting operational networks
by rja＠corp.home.net 15 Sep '97

15 Sep '97

On Sep 13 16:44, Sean M. Doran wrote: % Then, some protection for routing protocols to make them % both more robust and more secure, and life is a bit nicer. IMHO, any serious network operator using OSPF or BGP should have already deployed the techniques below (as applicable): OSPF with Keyed MD5 Authentication BGP-4 with the Keyed MD5 Authentication extension as a TCP option. WRT ISIS, lack of a CLNP infrastructure limits the ability of outsiders to attack a network. Nonetheless, ISIS should probably also get some kind of cryptographic authentication extension. Ran rja(a)home.net

2 1

NANOG 11 Meeting
by Pam Ciesla 15 Sep '97

15 Sep '97

REMINDER: The block on rooms for the Radisson Resort Scottsdale expires on September 26. For reservations call 602-991-3800 or 800-333-3333, be sure to mention NANOG. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Pam Ciesla 313-936-0172 - phone Merit Network, Inc. 313-647-3185 - fax University of Michigan 4251 Plymouth Road Bldg. I, Suite C Ann Arbor, MI 48105-2785 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

1 0

RE: ATM (was Re: too many routes)
by jan.novak＠aliatel.cz 15 Sep '97

15 Sep '97

Is this course of basic physics or NANOG mailing list ???? >65% the speed of light in a vacuum ? > >> > The equivalent EMR propagation speed in coppr is 0.75c >> >> What is EMR? > >Electo-Magnetic Radiation. Electrons don't count as EMR do they though, >(hell they have a mass!) so data in the form we transmit it down >copper won't move at this speed will it? True, electrons have mass, but we are not 'transmitting' electrons. We are oscilating the electrons in the media. This oscilation creats EM energy which propogates down the media, in the form of photos, and will propogate at some percentage of c depending upon the media.

1 0

Re: ATM (was Re: too many routes)
by Sean M. Doran 15 Sep '97

15 Sep '97

Yes, Paul, I've missed you too. :-) Sean. (why aren't you busy coding? oh wait you work for jUUNiper now, and need to be here defending cell stuff --:) )

2 1

set next-hop based on source/dest port?
by Avi Freedman 15 Sep '97

15 Sep '97

Does anyone know of a router vendor that can reset ip next-hops (not bgp routes, but ip packets) based on source/dest tcp ports? Thanks, Avi

1 1

Re: too many routes
by William Allen Simpson 15 Sep '97

15 Sep '97

> From: Alan Hannan <hannan(a)bythetrees.com> > The scaling issue is synonymous w/ an entirely L3 network. L2 > networks just put it off and make it somewhat less likely. > > See, I get the impression that people on this list can be > categorized as two kinds -- router people and network people. > That may be too strict a delineation. > Sorry, cannot pass this one up: This nonsequitor is a common problem with those folks that like to use "L2" and "L3" labels, rather than the _true_ name of things. Router people and network people are one and the same -- L3 is "network". Link (L2) people are now trying to build networks, and are reinventing the router wheel discovered long ago by earlier network (L3) people. Gosh, it is refreshing to have Sean back! This list is a lot more interesting. Not on topic, but interesting.... WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

Re: ATM (was Re: too many routes)
by Eric Germann 15 Sep '97

15 Sep '97

c is the constant for the speed of light or 299792.5 km/s 186282 statute mi/s At 08:46 AM 9/15/97 -0400, Susan R. Harris wrote: >> Photons propagate at 0.65c in fibre - the exact speed does vary >> depending on whether its single or multimode fibre. > >Hi Geoff - not to reveal my ignorance or anything, but ... is that 65 >degrees celcius? > >> The equivalent EMR propagation speed in coppr is 0.75c > >What is EMR? > > > ============================================================================ ==== Eric Germann Computer and Communications Technologies ekgermann(a)cctec.com Van Wert, OH 45891 Phone: 419 968 2640 http://www.cctec.com Fax: 419 968 2641 Network Design, Connectivity & System Integration Services A Microsoft Solution Provider

1 0

Re: too many routes
by Tony Li 15 Sep '97

15 Sep '97

hannan(a)bythetrees.com (Alan Hannan) writes: > On that tangent, however, flooding is what we're > mostly concerned about, and it's just not that bad. Alan, You are correctly concerned about flooding, however, I suspect that you're underestimating the scalability problems of flooding. Please recall that it's O(n^2) in the number of nodes in your mesh. This is a serious threat to building very large domains. In addition, the full mesh prevents hierarchical abstraction within the domain, defeating the other obvious mechanism for IGP scalability. Tony

1 0

Re: too many routes
by Sean M. Doran 14 Sep '97

14 Sep '97

Alan Hannan <hannan(a)bythetrees.com> writes: > > AFAICT there is only one orderable, deployable and tested > > IP router which observably terminates multiple 622-Mbit/s bit > > pipes, notably that made by cisco. > > Hmm, well, the lack of knowledge I suppose shouldn't be held > against you. > > http://www.ascend.com/505.html > > lists their support for such interfaces. > > ( nonsequiter comments deleted ) I hope the comments privately prior to your writing any of this that pointed out that nowhere in this URL or in Ascend's other literature is the concept of non-ATM 622 mentioned. Oh wait, that's a non sequitur, because it's the same thing as POS, right, only with extra features. > On their head? I can assure you the IGP is still a manageable > problem in larger ISPs with meshed backbones. In fact, there is > one solution available that is not yet even exercised. It's only manageable because Henk Smit (and before him Dave Katz) has been going to lots of trouble to clean up all the edge cases strangely flat backbones reveal, and because Cisco has no trouble with the idea of adding in richer metrics to iIS-IS. (Well, neither do I, actually :) ) Really rich connectivity means that it is more work to calculate new forwarding tables as point to point connections come and go, and the results are much harder to predict. Of course, if you take your approach and DON'T route dynamically between routers, but rather reroute VCs around link failures, then you might not have these problems except when fun things happen like ATM switches reloading or router-to-switch failures happen. At that point you have the fun of working out appropriate backup paths for the traffic that used to fan out over a large number of VCs. This is non trivial and scales geometrically with the size of the mesh. > > try to avoid thinking too hard about how to build spanning > > trees without building a physical VC topology for > > multicast and can put up with interesting buffering and > > switching effects > > Okay, I'll bite: Which interesting buffering and switching effects? You have to copy datagrams out to each branch of your spanning tree. If you have a largd number VCs out one interface overlaid with a dense spanning tree, you end up with large buffering requirements on that card, or alternatively do funny queue management so that you eat lots of queueing slots if you use an indirection list (i.e., you use pointers pack to the multicast PDU rather than copy the PDU multiple times, however "boxing" datagrams, while it saves memory-to-memory copies can make it difficult to do clever cache prefetching from packet memory, and may not reduce the number of memory reads you have to do, and certainly will increase CPU use). In other words, when using smart line cards like Wellpap or Cisco do, if you are doing lots of multicast with a fairly large distribution, you are better off keeping the spanning tree small. If you have a large number of downstream interfaces on a box, that box works harder. If you have a large number of downstream interfaces on a single card, that card works harder. Harder can be described as larger CPU time and more memory references in some combination, depending on the queueing mechanism and what does the packet copying. Also when you have a large concentration of downward links on a box, that box tends to attract more join and prune messages which also keeps it busier. You could add RSVP issues to that too, if you thought RSVP were somehow relevant to the Universe. > > and, as you say, the dynamics of WHY it > > works vs. why it doesn't work when things break. > > Yes, indeed this is a tradeoff. Obviously you and I have different thoughts about Byzantine failures. I've experienced enough of them driven by multilayer operability issues with a small set of vendors that widening the vendor base substantially (i.e., adding lots of switch vendors and the like, not just adding a second router vendor) or increasing the number of layers which have to interoperate does not appeal much to me. > But, the more I think about the KISS principle, I become convinced > that only our own limitations, ignorance, and hesitancy prevent us > from adding complexity to achieve increased control. Sure. How much do you want to spend on NOC staff is a factor in how much complexity NOC staff can handle, and that is a factor in how quickly Byzantine failures can be dealt with. Personally, Byzantine failures that require waking up senior smart people at multiple vendors' companies are scary and as Byzantine failures happen sometimes in big networks, keeping the number of people potentially needed to effect a fix for something really weird strikes me as a win. In short, defensive engineering. Sure complexity seems attractive, but only until your first major meltdown driven directly by or even only exacerbated by that complexity. > > I hate to say it but I think I have become old and this > > might explain why I like really simple and straightforward > > failure modes. > > See above comments. See bags under eyes and many scars. > Yes, we at 'bythetrees.com' are avid supporters of ATM in today's > technology. Oh sure, you're bythetrees.com NOW. --:) > Why do you always insist on linking one's place of business with > their technological idealogy? Because: a) it makes people angry, and that's really funny b) it reminds people whom they are working for and what trade-offs they make between what they want and what their employers say they want c) a + b sometimes causes people to fix their employers into doing things "correctly", or leads people into realizing their employers are hopeless and that there are other opportunities elsewhere (which sometimes also fixes the employer) the latter part of (c) is particularly edifying if it involves physical violence to doors and so forth. So, needle needle, if you are at variance with UUWHO's technical policies, why are you still there? > Certainly I work at UUNET and my opinion is occasionally > involved in certain decisions. Oh, cool, so I can blame you for brain damage. Several managers will be really happy now that you've volunteered yourself to be picked on in technical lists instead of them. :-) > Hmm, I tend to be atheistic about technology -- what can it do for > me today, and what will it to do tomorrow with a reasonable chance > of success. I think you mean agnostic, not atheistic. I distinctly remember you comparing me to Jesus Christ. > > There may be choice in what you can put at the end of an > > OC12 though, but it's either something smart or something > > you'd find at Hobson's Tavern. > > How do you define smart? When you put your brain into a blender and unpack it into individual cells in hopes you can put it all back together the way it was without having noticed, that's not very smart. Sean. (don't send the next cheesecake as breadcrumbs please :-) )

2 1

Re: LSR and packet filters
by Hank Nussbacher 14 Sep '97

14 Sep '97

At 02:37 AM 9/14/97 -0400, Alex \"Mr. Worf\" Yuriev wrote: >> Quoting Radia Perlman: >> >> "The goal is to design a network that will guarantee that >> a packet transmitted between two nonfaulty end systems A >> and B will have a high probability of being delivered, >> provided that at least one path consists of nonfaulty >> components connects the two end systems. [...] The >> network layer makes no attempt to keep conversations >> private. If privacy is necessary, encryption must be >> done at a higher layer. Also, the network layer need not >> certify data that it delivers. For instance, it is >> possible for some malicious node C to generate data, get >> it delivered to B, and claim that the data was from A. >> It is up to the higher layer in B to differentiate >> between corrupted or counterfeit data and real data, >> using known cryptographic techniques". > >Well, then he is *WRONG*. Authentication and privacy should be a function >of the network layer, not the application layer because it is a lot easier >to attack application layer encryption compared to lower layers. Radia is a she. Anyone who has been in this field for more than 2 years should know that even if you can't guess what tli or pst or Yakov are :-) -Hank

3 2