May 2001 - Test - lists.nanog.org

Re: Mitch tries to defend his open relay again (was Re: ORBS (Re: Scanning))
by dlr＠bungi.com 31 May '01

31 May '01

[In the message entitled "Re: Mitch tries to defend his open relay again (was Re: ORBS (Re: Scanning))" on May 30, 22:16, Mitch Halmu writes:] > > On Mon, 28 May 2001, John Fraizer wrote: > > > If you want a huge laugh, (and want to give ole Mitch the /. or NANOG > > ... then laugh about this one: > > http://www.dmnews.com/cgi-bin/artprevbot.cgi?article_id=15323 > Without further comment, here's the MAPS press release on the topic. http://www.mail-abuse.org/pressreleases/2001-05-25.html --

1 0

RE: ORBS (Re: Scanning)
by Roeland Meyer 30 May '01

30 May '01

> From: E.B. Dreger [mailto:eddy+public+spam@noc.everquick.net] > Sent: Sunday, May 27, 2001 8:05 AM > ORBS catches far more than MAPS. As Randy stated "so does a hydrogen bomb". The problem is target acquisition and [the lack of] discrimination. The REASON tactical nukes aren't used regularly is the collateral damage issue. > My take is that anybody who has a > problem with the infrequent ORBS probes should have a huge > problem with the daily bombardment of relay attempts. A system that tests positive for ORBS , yet is using MAPS, will not be used as a spam relay. Yet, ORBS will list such a system. > Bottom line: Blocking mail from rogue servers is the best way to stop > spam and to not be a party to somebody else getting > relay-raped. Anyone with clue closed relays how many years ago? It is more accurate to state that most folks have placed guards on their mail systems. > I don't buy the "we need open relay for nationwide users" argument, > either. Build a cheap MX that does nothing but take mail from a given > POP, and send it to the world. Anti-spoofing at the border, > don't accept mail from the outside world, and you're done. You must not have a roaming staff or are willing to keep telcos wealthy.

14 27

experience with BGP on Extreme's Alpine
by Arnold Nipper 30 May '01

30 May '01

I know ExtremeNetwork's high position in L2, but don't have any idea how they perform on L3. Now an Alpine3804 might the right solution for a customer as he needs a loadbalancer, switch and router which also should do BGP. Any experience and hints welcome! Arnold

4 3

Re: jumbo frames
by Richard A. Steenbergen 30 May '01

30 May '01

On Tue, 29 May 2001, Dave Siegel wrote: > I've seen a lot of discussion about why one would want to do Jumbo > frames on your backbone...let's assume for the sake of argument that a > customer requirement is to support 9000 bytes packets across your > backbone, without fragmentation. > > Why not bump MTU up to 9000 on your backbone interfaces (assuming they > support it)? > > What negative affects might this have on your network? > > a) performance delivering average packet sizes > b) QoS > c) buffer/pkt memory utilization > d) other areas Theoretically increasing the MTU anywhere you are not actually generating packets should have no impact except to prevent unnecessary fragmentation. But then again, theoretically IOS shouldn't get buggier with each release. There will obviously be different packet handling techniques for the larger packets, and I'm not aware of any performance or stability testing that has been done for jumbo frames. I'm guessing the people who are actively using them havn't been putting it in line rate mixed small and large packets conditions. Obviously anything extra and uncommon you try to do runs the risk of setting off new bugs (even common stuff sets off new bugs). I can tell you some of the drivers I have seen for PC gige cards (especially linux) badly mangle jumbo frames and may not perform well. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

3 4

Wrap-up of the Yipes! query..
by Los, Ralph 30 May '01

30 May '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 NANOG readers.... OK...this is a wrap-up of the Yipes! query I sent out a little while ago. In listening to all the responses I got back (most of which were, 'me too' queries), I've got the following picture of Yipes!..... 1. Their sales person is quick to introduce himself, but since this post, I've mad a query into company status, funding, and more serious engineering-type queries, with NO ANSWER. 2. They're not funded yet, and selling WAY below cost. Does this mean that a year from now they're going to triple their prices? worse? 3. I've heard 2:1 in horror stories about Yipes! not being able to deliver. Not even T-1's in these cases when a drop-dead delivery date was given. 4. I've heard a few short replies about "we're been using them for x months (2-6) and never had a problem, they deliver what they promise". But what about their support?....no one's seemed to have dealt that way yet. My verdict? I'm going to hold off, going to pursue Cogent (www.cogentco.com) and see if they have a better offering/stability platform. They appear to...give that a look if you have an interest in getting fiber. Good luck, thanks for the replies! Ralph M. Los Asst. Vice-President, Internet Systems and Security EnvestNet Advisory Corp. rlos(a)envestnet.com (312) 827-3945 (direct) (312) 296-9003 (wireless w/voicemail) -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com> iQA/AwUBOxVgMHM6eMaR3AeZEQLVywCePuJj21rYvejIqYDdk9CXLRD85oEAnjnN ZVbFoS0uS4K+39CwciOaBbnK =rLr/ -----END PGP SIGNATURE-----

1 0

RE: QOS or more bandwidth
by Irwin Lazar 30 May '01

30 May '01

> > > FWIW, I recently heard someone ask the question - "how do you go to your > investors and tell them you need more money for more bandwidth because you > don't want to efficiently manage your existing capacity?" > > This is the business case for QoS, IMHO. > > Irwin Which costs more, wholesale, raw bitpipes or qualified engineering talent to create/police the policies needed to maintain QoS? --bill That's the $64k question. :-) >From what I've seen, there isn't a simple answer. In places where bandwidth is exorbantantly expensive (such as outside the United States), simply over provisioning isn't an acceptable answer. However, in some places in the U.S. & Europe, over-provisioning may certainly make more sense. In our area, we're also seeing a lot of pushback against the continued tearing up of streets to lay additional fiber, so QoS may become the only option to meet required service levels. Irwin

12 17

Re: QOS or more bandwidth
by rs＠seastrom.com 30 May '01

30 May '01

Irwin Lazar <ILazar(a)tbg.com> writes: > From what I've seen, there isn't a simple answer. In places where bandwidth > is exorbantantly expensive (such as outside the United States), simply over > provisioning isn't an acceptable answer. However, in some places in the > U.S. & Europe, over-provisioning may certainly make more sense. I think we're running into some semantic issues here. What you call "overprovisioning", I call "not underprovisioning" or "accurately predicting growth". There has never been a shortage of people willing to market something-for-nothing schemes to the gullible. Over the years, there have been perpetual motion machines, gizmos that you put in the fuel line to "magnetize" your gasoline and make your Eldorado get 50mpg, and end-to-end QoS schemes. If you were around for Peter Lothberg's presentation at nanog-last, you know what I'm driving at here. > In our area, we're also seeing a lot of pushback against the > continued tearing up of streets to lay additional fiber, If you put a reasonable amount of conduit in the first time (conduit is *cheap*), there is no reason to tear up the streets again to put in more fiber. Most of the street-re-tearing-up that I've seen done has been additional vendors, and no QoS mechanism that I've seen addresses that little problem. If you put in a reasonable amount of glass, and you're running low on strands, metro area sparse-wdm schemes are getting cheaper all the time, and presumably you can support their deployment because you have high demand (else why are you running out of fiber?). Notice that these are *quantity* of service mechanisms... > so QoS may become the only option to meet required service levels. Or you may have to face the fact that it is impossible to provide the desired level of service at a price that people are willing to pay, in your particular locality. For instance, QoS schemes or no, I don't think any of the major (or minor for that matter) players have plans to put a datacenter on Pitcairn Island. ---rob

1 0

Re: port filtering list
by Chris Beggy 30 May '01

30 May '01

From: "Avleen Vig" <avleen(a)ivision.co.uk> > >> Shouldn't this list be by AS? (Although the translation to common >domains >> is helpful, too...) > >It's a good idea... Chris? :) > Thanks for the suggestion and the nudge :-) The column heading is in the table now but without data. My feeling is that AS indexed information is good for transit providers and access provider indexed info is good for service providers and roamers. Thanks for all the entries so far, NANOGsters. Chris

1 0

Knowledgable Excite.com Contact
by Marius Strom 30 May '01

30 May '01

Can anyone provide me off list with a knowledgable Excite.com contact? I can't find anything for them on the NOC List at puck, and one of my netblocks is having reachability problems to mta.excite.com. Thanks, and sorry for the bandwidth waste. -- Marius Strom <marius(a)marius.org> Professional Geek/Unix System Administrator URL: http://www.marius.org/ http://www.marius.org/marius.pgp 0xF5D89089 *updated 2001-02-26* It is a natural law. Physics tells us that for every action, there must be an equal and opposite reaction. They hate us, we hate them, they hate us back and so, here we are, victims of mathematics. -- Londo, "A Voice in the Wilderness I"

1 0

Re: More BW, Less Taxes
by David Lesher 30 May '01

30 May '01

> > but then again, there are probably far fewer errant backhoes in the atlantic. > There are all those NSA subs practicing on our cables...... -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

1 0