- NANOG - lists.nanog.org

OT: Network Engineer Position in Irvine, California
by Karyn Ulriksen 27 Apr '01

27 Apr '01

Colocation and webfarm looking for Senior Network Engineer. Please contact kulriksen(a)vitalstream.com for information. --------------------------------------------------------------------- Best regards, Karyn Ulriksen Network Operations Manager SiteStream, A VitalStream Company 1 Jenner, Suite 100 Irvine, California 92618 USA Phone: (949) 743-2000 email: kulriksen(a)vitalstream.com URL: http://www.vitalstream.com ===========================================

1 0

RE: jumbo frames
by Roeland Meyer 27 Apr '01

27 Apr '01

> From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Thursday, April 26, 2001 11:47 AM > > April 26, 2001 9:29 AM John Fraizer wrote: > > We only have jumbo frames enabled on router<->router links. > The GigE > > ports facing the aggregation switches runs standard 1500 MTU. > > Hence my original question. Packets across the GE will be > 1500 unless you > are packing them. > > April 25, 2001 8:10 PM John Fraizer wrote: > > Partially because I can. Partially because there seems to be a > > performance increase when you start stuffing the pipe. > > Assuming you are just passing the packets as received from > the aggregation > switch, this would only happen if your router hardware was better at > managing jumbo buffer allocations than 1500B ones. Clearly it > will waste > large chunks of memory, so do you have measurements to show the actual > performance increase? This depends on the type of traffic. We use it to enhance performance of the data tier. We've jiggered the TCP/IP stacks for ~4500 byte packets and have knee-capped the slow-start algorithm (which doesn't make sense in a pure switched environment anyway). What we then wind up with, is a dedicated data LAN between our application servers and the Oracle database servers. It comes out to about an order of magnitude increase in performance and SQL query responsiveness. At first we went to jumbo packets. We saw such a radical improvement that we started investigating and found the slow-start issue. Jumbo packets are one way around the slow-start problem if you can't jigger the stack itself. Most of the queries are reasonably short so we saw some serious improvements by killing the slow-start. If you can modify your IP stack then it still pays to use jumbo packets because you reduce the overhead on the wire. We got sufficient performance improvement that we were able to defer GigE implementation, at some sites. Those sites are using switched FDX 100baseTX.

4 4

Compatible Systems Spare Parts ?
by Smith, Rick 27 Apr '01

27 Apr '01

I'm at the end of my rope in the search for using two Microrouter 1200i's. Wondering if anyone has any spare power bricks for them ? I need ONE :) Specs: Class 2 Transformer Input: 120V 60Hz 50W Output: AC 12V 2.9A Model #: WP573512G No one anywhere has these, and Cisco's response is "Buy Ciscos to replace the 1200's". Sorry for the noise.. Thanks, Rick Smith Director of Technical Services Applied Tactical Systems (A division of Vertex Interactive, Inc.) <http://www.atsworld.com> --- <http://www.vertexinteractive.com> (973) 808 - 1750 x382

2 1

RE: jumbo frames
by Roeland Meyer 27 Apr '01

27 Apr '01

In both cases, it is a bandwidth issue. You either consume the bandwidth in the CPU or consume it on the wire. CPU is cheaper and often under-utilized. Of the two, CPU bandwidth is also cheaper/easier to upgrade. > -----Original Message----- > From: Rowland, Alan D [mailto:alan_r1@corp.earthlink.net] > Sent: Friday, April 27, 2001 8:45 AM > To: 'Kurt Kayser'; Tony Hain > Cc: Roeland Meyer; John Fraizer; Paul Lantinga; nanog(a)merit.edu > Subject: RE: jumbo frames > > > I am not an EE but maybe if you rephrased the question as > > Which is greater, the cpu cycles to assemble/dissemble jumbo > frames or the > additional cycles/bandwidth of more numerous ACK packets? > > Then again, I may be way out of my depth here. > > -Al > > -----Original Message----- > From: Kurt Kayser [mailto:kurt@noris.de] > Sent: Friday, April 27, 2001 8:07 AM > To: Tony Hain > Cc: Roeland Meyer; John Fraizer; Paul Lantinga; nanog(a)merit.edu > Subject: Re: jumbo frames > > > > Hi, > > Isn't it a lot more cpu-intensive to 'collect' some 1500-byte frames > into some larger bucket, reassemble it into a jumbo-frame > when the next > box has to chop it in order to send it out on a Sonet/PPP/etc > interface > which > might have a smaller MTU again? > > Doesn't make too much sense to me. I guess that was Tony's > aim as well.. > > Kurt > > > Roeland you are talking about jumbo frames from the end > system lan, while > > John is talking about only using the jumbo frames between > the routers. My > > point was that in John's environment the packets will all > be 1500 since > the > > packets are restricted to that size just to get to the > router with the GE > > interface. I understand that there are perf gains as long > as the entire > path > > supports the larger packets, but I don't understand the > claim that having > a > > bigger pipe in the middle helps. > > > > Tony > > > -- > noris network AG * tel +49 911 93 52-0 * internet > Kilianstraße 142 * fax +49 911 93 52-100 * solution > 90425 Nürnberg * http://www.noris.net * provider >

1 0

Re: jumbo frames
by Stephen Sprunk 27 Apr '01

27 Apr '01

From: "Kurt Kayser" <kurt(a)noris.de> > > Isn't it a lot more cpu-intensive to 'collect' some 1500-byte frames > into some larger bucket, reassemble it into a jumbo-frame when the > next box has to chop it in order to send it out on a Sonet/PPP/etc > interface which might have a smaller MTU again? Intermediate routers to not 'collect' small packets into big packets. > Kurt S -- Stephen Sprunk "So long as they don't get violent, I want to CCIE #3723 let everyone say what they wish, for I myself have K5SSS always said exactly what pleased me." --Albert Einstein

1 0

RE: jumbo frames
by Rowland, Alan D 27 Apr '01

27 Apr '01

I am not an EE but maybe if you rephrased the question as Which is greater, the cpu cycles to assemble/dissemble jumbo frames or the additional cycles/bandwidth of more numerous ACK packets? Then again, I may be way out of my depth here. -Al -----Original Message----- From: Kurt Kayser [mailto:kurt@noris.de] Sent: Friday, April 27, 2001 8:07 AM To: Tony Hain Cc: Roeland Meyer; John Fraizer; Paul Lantinga; nanog(a)merit.edu Subject: Re: jumbo frames Hi, Isn't it a lot more cpu-intensive to 'collect' some 1500-byte frames into some larger bucket, reassemble it into a jumbo-frame when the next box has to chop it in order to send it out on a Sonet/PPP/etc interface which might have a smaller MTU again? Doesn't make too much sense to me. I guess that was Tony's aim as well.. Kurt > Roeland you are talking about jumbo frames from the end system lan, while > John is talking about only using the jumbo frames between the routers. My > point was that in John's environment the packets will all be 1500 since the > packets are restricted to that size just to get to the router with the GE > interface. I understand that there are perf gains as long as the entire path > supports the larger packets, but I don't understand the claim that having a > bigger pipe in the middle helps. > > Tony > -- noris network AG * tel +49 911 93 52-0 * internet Kilianstraße 142 * fax +49 911 93 52-100 * solution 90425 Nürnberg * http://www.noris.net * provider

1 0

RE: commonly accepted prefix length filters?
by Segal, Mark 27 Apr '01

27 Apr '01

You saw 110,000 from Teleglobe this morning as well? Mark -- Mark Segal Director, Data and Internet Planning Axxent Corp. Tel: (416)907-2858 > -----Original Message----- > From: Jim Mercer [mailto:jim@reptiles.org] > Sent: Friday, April 27, 2001 10:54 AM > To: nanog(a)merit.edu > Subject: commonly accepted prefix length filters? > > > > > our bgp tables are starting (?) to get out of hand. > > we are thinking maybe we should start nuking some routes in > order to reduce > the size of the tables. > > is there a list of commonly accepted aggregating prefix filters? > > > -- > [ Jim Mercer > jim(a)pneumonoultramicroscopicsilicovolcanoconiosis.ca ] > [ Reptilian Research -- Longer Life through Colder > Blood ] > [ aka jim(a)reptiles.org +1 > 416 410-5633 ] >

1 0

commonly accepted prefix length filters?
by Jim Mercer 27 Apr '01

27 Apr '01

our bgp tables are starting (?) to get out of hand. we are thinking maybe we should start nuking some routes in order to reduce the size of the tables. is there a list of commonly accepted aggregating prefix filters? -- [ Jim Mercer jim(a)pneumonoultramicroscopicsilicovolcanoconiosis.ca ] [ Reptilian Research -- Longer Life through Colder Blood ] [ aka jim(a)reptiles.org +1 416 410-5633 ]

3 2

Re: RIP and RIPv2, "The glue that makes the internet work"
by rs＠seastrom.com 27 Apr '01

27 Apr '01

> On the other hand, reports of large, multinational networks > running static routing in their cores seem to indicate a > desire to have routing in the core more stable than any dynamic > protocol will allow. Or lack of sufficient clue in their IT departments to implement anything but static routing (sadly, very often the case in my experience). Which of course is preferable to the four-router thirty-route OSPF "designs" I have seen that put each router in its own area (!). ---rob

1 0

Re: RIP and RIPv2, "The glue that makes the internet work"
by Sean Donelan 27 Apr '01

27 Apr '01

On Thu, 26 April 2001, bmanning(a)vacation.karoshi.com wrote: > On the other hand, reports of large, multinational networks > running static routing in their cores seem to indicate a > desire to have routing in the core more stable than any dynamic > protocol will allow. You only need a dynamic routing protocol if there are alternate paths in your network. If don't have more than one way to get from point A to point B, static routing may be acceptable.

1 0