- Test - lists.nanog.org

Re: ICMP rate limiting on EGRESS (Warning, operational contentinside)
by Paul Ferguson 18 Jan '00

18 Jan '00

At 11:26 AM 01/18/2000 +1030, Glen Turner wrote: > > This is the principle reason to encourage everyone to implement > > RFC2267-style filtering. :-/ > >It would be nice if this shipped "on" by default in a particular >major vendor's products. This would at least take care of the >clueless majority, and would force all ISPs to address the issue. > >It is only the router vendors and routing code authors that can >*force* source address checking throughout the Internet. Most >users will simply install it during a normal software update. Well, we don't _force_ anyone to use amything, but we do have a little knob called "Unicast RPF". I'll leave it to the rest of the of the readership to discuss it's merits (or perhaps move the dicussion to the cisco-nsp list instead). Cheers, - paul

1 0

Need @home and Mae-West Help
by Derrick Bennett 18 Jan '00

18 Jan '00

First my appologies to the list. I hate to reach people this way but the truth is it works very well. I need someone from @home or @work's NOC or management staff to contact me off list ASAP. My attempts to escalate an issue via tickets has failed and most of my contacts voicemail boxes are full. There is a peering point congestion problem at Mae-West that is killing bandwidth during peak times and we have not been able to get any resolution to the issue. Thank you. Sincerely, Derrick Bennett

2 1

Re: Fw: Administrivia: ORBS
by Brian Dickson 18 Jan '00

18 Jan '00

> > These days I've been unable to find any justifiable need for an > > unprotected relay of any sort whatsoever. > > We do domain hosting and mail redirection (among other things), but we > don't do dialup. [...] When they want to send mail out, > they have to do it through their IAP's mail server. As much as it's a small hassle, any user stuck behind a horrible IAP, what about setting the SMTP to the *recipient's* MX host. Since this would be local delivery, would it not be accepted, regardless of source? (The hassle is, of course, changing SMTP for each receipient domain...) > POP before SMTP is a crufty hack, IMNSHO, and SMTP auth isn't > implemented to enough of an extent that I'd be comfortable running it. It is crufty, and also crafty. A horrible, but most importantly, effective, kludge. Nearly everyone I've talked to eventually came up with this. It's not the only solution, however, to your particular requirement. Assuming your SMTP gateway is suitably configurable (eg some variant of sendmail or some equally extensible package), you could easily enough set up special rules, on a relay-only box: Call the box "relay.yourdomain.com". Users who use it, configure their outgoing id as "user.name.with.dots.cryptpw(a)hosted-domain.com". Your ruleset for relay, is to strip the ".cryptpw", do RADIUS-auth on the result with the encrypted password. Iff it passes, relay the mail. (You want it to be used only for this purpose, and only with this mechanism, for greatest likelyhood of avoiding screw-ups.) A simple web interface, with password protection, can give out the cryptpw value, or any other "cookie"-type equivalent. Since your box, relay.yourdomain.com is the SMTP, and rewrites the headers, the "cryptpw" value isn't stored anywhere, and except for routers and any sniffers on broadcast domains (Ethernet or FDDI hubs), nothing will see the packets with this magic value - which is user-specific, to boot. > Anyone who says there's absolutely no reason to run an open relay is > talking absolute codswallop - as with every situation like this it > requires a reasoned political decision at the site in question. Open, in this case, is absolute, but there is no absolute closed, only various shades of grey. Any political decision, if made by a reasoning entity, has some chance of being trumped by an adequate technical solution. The only question is what the technical solution costs. I've given it for free; if you use it, please attribute it to me. :-) > We don't use ORBS, either - Alex Rudnev has it spot on, to my mind. MAPS has both the RBL and RSS - both reasonable alternatives to ORBS. Highly recommended. -- Brian Dickson, Email: briand(a)teleglobe.net Director, Backbone Engineering Tel : +1 703 755 2056 Teleglobe Communications Corp., Fax : +1 703 755 2648 Rm 3214, 11480 Commerce Park Drive, Cell : +1 703 851 9053 Reston, Virginia, USA, 20191 http://www.teleglobe.com

2 1

None
by Brad S. Dreisbach 17 Jan '00

17 Jan '00

If anyone on this list works for @home could you please contact me off list. thanks, -brad

1 0

CEF Load balancing...
by Alex Rubenstein 17 Jan '00

17 Jan '00

Question (kinda operational).. I've been looking/asking around, but have yet been able to get the same answer twice to the following question: How many links can you have in parallel when using CEF load-sharing per-packet? Another words, we currently have a site that has four DS1s load balanced, in parallel (terminating in the same router on each end). Can you add a [5th|6th|7th|8th] ? Before you answer "BUY A DS3!", this is located in a rural area that a) really doesn't (easily) even have DS3 capabilites, and b) isn't cost effective to have a DS3 as it is about 15 times the cost of a DS1. Thanks for any insight!

11 14

Re: ICMP rate limiting on EGRESS (Warning, operational content inside)
by Sean Donelan 17 Jan '00

17 Jan '00

On Mon, 17 January 2000, bmanning(a)vacation.karoshi.com wrote: > Source routing and connection based services are creaping into > the Internet, slowly but surely. Both are a far cry from the > destination forwarding and connectionless service that I grew > up with. Yes, but as far as I know, none of the new services rely on the ability to spoof the source address outside of local (perhaps VPN extended) network. Even old services such as roaming and redirector applications have switched to using tunnels instead of spoofed source addresses. Are there any real-world applications which have no alternative but to use spoofed source addresses on the Internet at large? Or is this a case, if we had thought about it, we would have prohibited it at the start; but now its in the wild we don't know how to get it back in the barn.

3 4

ICMP rate limiting on EGRESS (Warning, operational content inside)
by Alex Bligh 17 Jan '00

17 Jan '00

It is reasonably well acknowledge that ratelimiting ICMP on *ingress* to your network can be a good thing to do, if you have available resources to do it. How about players rate-limiting ICMP on *egress* of the network over public exchange points. I have been on the wrong end of several smurfs over 100Mb/s over MAE-East & West, as, I'm sure have others. Whenever anyone is smurfed like this, I presume their port blocks, and anyone sending them data has head of line blocking. Which means, in effect, anyone peering with anyone who is being (sufficiently smurfed) will experience packet loss to *other* peers. By rate-limiting ICMP on output (to perhaps 3 or 4 times its nowmal value which here is 4 times 1% of normal traffic levels), then if one of your peers is being smurfed, you help save HoL blocking occurring. If your peer blocks these on ingress, it won't help - the packets will still get switched. >From what I am (unscientifically) seeing, packet loss over the MAE is spikey and can go through periodicity of badness not dissimilar to the length of such DoS attacks. I am not, of course, suggesting that this will solve all the MAE's problems. If the Gigaswitches could give even an approximation of total traffic that was ICMP, and see if peaks in this correspond to peaks in packet loss between routers on the MAE (not just across the switch fabric), we could even attempt to measure this. Is this a good idea? -- Alex Bligh GX Networks (formerly Xara Networks)

6 5

RE: CEF Load balancing...
by Martin, Christian 17 Jan '00

17 Jan '00

>We have a situation where CEF in a particilar 12.0.x version >broke the BVI >interface in an IRB configuration w/ATM. Then the next version broke >forwarding between an ATM interface and a Ethernet interface in an >interesting way (I haven't tracked down the specifics on the >second case >yet.) I've seen issues where CEF drives the CPU through the roof if it is doing per-packet balancing on interfaces that reside on different VIPs. I've also seen links drop out of a CEF load-balancing group and the Adj Table hashes not purge the down interface, or keep the hash indices the same, with only two interfaces instead of three, thereby doing 67/33 balancing instead of 50/50. The workaround is to diable and reenable CEF. On the positive side, you can easily aggregate 200+Mbps across 6 DS3s with minimal CPU and smooth, per-packet balancing. Process switching on steroids it is... Besides, to uses reverse-path filtering, dCAR, dWRED, etc, you need dCEF. It is stable in 11.1.26CC1 - we use it all over for load-balancing on DS3s... Chris > >All in all, CEF works wonders, if it doesn't break something with its >extra-fancy forwarding. > >- Forrest W. Christian (forrestc(a)imach.com) KD7EHZ >---------------------------------------------------------------------- >iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com >Solutions for your high-tech problems. (406)-442-6648 >---------------------------------------------------------------------- > >

1 0

Mae-West Stats and Nanog Archives
by Derrick Bennett 17 Jan '00

17 Jan '00

I was actually looking for current Mae-West Stats as the page I have ended last year. I thought someone had asked this recently but found that the nanog mailing list search site stopped in october of 99. Does anyone know where newer mae-west stats may be and if the archives for nanog will be updated soon ? Thanks, Derrick Bennett

2 1

Re: Mae-West Stats and Nanog Archives
by Sean Donelan 17 Jan '00

17 Jan '00

On Sun, 16 January 2000, Derrick Bennett wrote: > I was actually looking for current Mae-West Stats as the page I have ended > last year. I thought someone had asked this recently but found that the > nanog mailing list search site stopped in october of 99. Does anyone know > where newer mae-west stats may be and if the archives for nanog will be > updated soon ? I was told (going from memory, so I hope Steve will correct me) there was a SNMP problem collecting stats on mae-west last fall. Since MCI/Worldcom is changing to a new statistics package, instead of fixing the old ones, the new statistics should show up real soon. But I guess like many software projects its been delayed. Because the stats from Ameritech and the MAE's are essentially the only publically available measures of multi-provider Internet traffic, I hope they come back. Sprint & Pacbell/Bellcore used to have some stats, but all the links I had have stopped working. It would be nice to get some aggregate numbers for private interconnects, but I guess it isn't a realistic dream.

2 1