- Test - lists.nanog.org

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

Re: Fw: Administrivia: ORBS
by Paul Vixie 17 Jan '00

17 Jan '00

> Paul Vixie's Mail Abuse Prevention System ... Ouch! Mail Abuse Prevention System LLC, has a pile of people associated with it, and I can't sit idly by and see it referred to as my possession. MAPS LLC is: Sean Fagan Technologist Nick Nicholas Evangelist Peter Popovich Principal Investigator, RBL Kelly Thompson Associate Director Al Iverson Principal Investigator, RSS Gordon Fecyk Principal Investigator, DUL JD Falk Product Manager While I may have founded it, the *only* work I still do for MAPS LLC is: funding nomination processing arguing on NANOG It's not "mine" and hasn't been "mine" since before it was six weeks old. -- Paul Vixie <vixie(a)mibh.net> >> But what *IS* the internet? > It's the largest equivalence class in the reflexive transitive > symmetric closure of the relationship "can be reached by an IP > packet from". --Seth Breidbart

2 1

Re: Fw: Administrivia: ORBS
by George Herbert 16 Jan '00

16 Jan '00

Danielle writes: >In effect, Above.net is (by filtering the ORBS probes) licensing every >single IP in their /16 to spam via the sordid and detailed means that >ORBS works to prevent. >This is an incorrect assumption? Please educate me as to how this is the >wrong way to view this. There seems to be some sort of implicit assumption in this, and many other postings to NANOG, that if you disagree with ORBS you must be pro-spam, or at least tolerant or neglegent with respect to it. Dave Rand is the CTO of Abovenet. Dave helped found the RBL with Paul Vixie, and has been involved at least on and off with MAPS LLC [I hope this is an accurate one sentence historical summary... someone can correct this if it isn't...]. As far as I can tell, there is no backbone provider which actually responds better to spam problems in its network than Abovenet does. They have one of the best AUPs out there and enforce it very, very well. Various folks who are and/or have been involved with ORBS have had antagonistic relationships with quite a number of other spam fighters over the years. This has led to admitted incidents where non-open-relays were ORBS listed because they were run by people who were disagreeing with ORBS in public. Although any sort of generalization has its flaws, the RBL-centric anti-spam crowd on the spam@zorch list generally believes that ORBS and its approach of netblock scanning and test messages are net abuse, beyond appropriate responses to spam, and that ORBS is run by people who put personal conflicts at the same level as actual spam problems. Part of this obviously is just personality and politics. At the technical and operational level, though, this has significant impacts: a wide number of people who are undoubtedly actively anti-spam believe ORBS scanning constitutes net abuse, and believe that ORBS listing of persons who merely have personal conflicts with ORBS operators is inappropriate for a resource being used by such a large portion of the net. This is more or less the whole reason why RBL/MAPS started the RSS; the RSS is, arguably, what ORBS should have been all along: it doesn't scan for open relays unless a valid report is in hand that the relay is being abused. It uses RBL's professionalism and documented policies so that it has publically known and trusted behaviour rather than arbitrary and personal. For all of those reasons, it is quite possible to be actively and responsibly anti-spam but very much opposed to the methods of ORBS. I personally believe that ORBS has consistently taken actions which are in the long run going to have negative consequences on the efforts to combat spam, such as the personal attack listings and such, and its antagonizing any number of networks by refusing to stop scanning them. I urge anyone who is using ORBS to consider these issues, research the RBL/MAPS approach (http://maps.vix.com/) and reconsider whether ORBS is, in the long run, the approach to spam blocking which is best for you and for your networks. The ORBS approach is not the only viable one, and not the only valid one, and while it does work the negative consequences of its approach should not be ignored. Please note that I am not speaking for MAPS, the RBL, or anyone else in this matter other than myself (I have done some minor stuff for the RBL before but am not actively involved now), though I believe that the consensus opinions from the spam@zorch crowd that I have paraphrased above accurately represent that mailing list / group of people's opinions on the subject. I also would like to note yet again that I am not at this time and have not been for some years a CRL employee, just a shell account end user, and my opinions on this matter should not be associated with CRL in any way. -george william herbert gherbert(a)crl.com

1 0

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

16 Jan '00

Greg Woods wrote: > [ On Friday, January 14, 2000 at 12:24:32 (-0800), J.D. Falk wrote: ] > > Subject: Re: Fw: Administrivia: ORBS > > > > Unfortunately, ORBS does not allow for people who DO know > > about relays, and DO close them, and don't want to be scanned > > anymore. In the ORBS world, that simply isn't an option. > > > > That's where most of the sane anti-ORBS sentiment comes from. > > If your mailers were abused, reported to ORBS and listed, fixed, and > finally cleared from ORBS then please don't prevent ORBS from testing > them again in the future -- that is your guarantee that we won't > individually block your mailers again with our own private lists. I think the issue most people aren't certain of, is when is it reasonable to test a machine, in the manner ORBS does? Let's consider various possibilities, in an order somewhat resembling decreasing reasonable-ness. [My comments on these are bracketed.] 1) If your mailer receives an incoming connection request on port 25, it's pretty reasonable to test the machine from which the request comes. The logic here is pretty solid - before accepting a connection from another mailer, it is reasonable to want to verify that it isn't an open relay being used for spam. For efficiency, perhaps such testing could be limited to incoming requests from machines listed on ORBS or similar sites. If an ORBS-like list, maintained based not on pre-emptive testing, but on at-receive-time non-open-relay verification, this would be pretty benign. The question for this list would be, how can you ensure that any submission from participants is authentic? - have this ORBS-like list *not* trust submissions, per se; - rather, have the machine(s) hosting the list, added as MX entries *for* participants (ie, participants add the MX) - participant machines, upon detecting mail connection requests from a machine, does the following: - check to see if it is listed - if yes, refuse connection - if no, check directly if it is an open relay -if so, refuse the connection Refused connections (listed, or detected open relay) result in the open relay trying MX hosts with larger MX values, until the ORBS-like machine is tried - the ORBS-like machine, would then do its identical check, only because the sending machine was trying to forward mail through it; thus it is no longer pre-emptive. - if already on list, either refuse connection, or test again - if sending machine is determined to be an open relay, add to list [IMHO, this would be both non-pre-emptive, scalable (although with a small ramp-up problem), yet centralized enough to be useful to large and small sites alike. The central machine(s) would clearly need to re-do their testing periodically (not necessarily every time someone from a listed site tries to send mail!), and would need to be capable of handling a huge number of connection requests. I defer to the MTA-gurus as to whether this is do-able in practical terms.] [If anyone is considering implementing this - *please* be sure to put in place checks to avoid mutual- checking run-away recursion!.] 2) Hosts listed in any domain as an MX host. Unfortunately, in neither DNS nor in the IANA assigned ports, is there any distinction between an MDA and an MTA. An MX is a proxy-MDA, which by necessity is an MTA. There is no corresponding "Relay" record for DNS, which *would* be something always valid to test. In the absense of the distinction, the MX meaning could be overloaded (to use the c++ term) to include relay; the question would then become one of whether it is reasonable to test hosts that actively advertise the fact that they are relays. (What would have been really sweet, is if there were separate ports for local deliver (MDA) and transport (MTA). Then, machines with MDA, but no MTA, would never forward mail; they could locally initiate mail, and receive mail for delivery, without being any kind of relay (open or closed). This would reduce the set of hosts needing to be tested, to those with MTA ports accepting connections. It would also mean the default config for any such machine would normally be MDA and no MTA; only MX and Relay machines would have MTA turned on.) [IMHO, there's no clear line on pre-emptive testing; clearly, major mail hubs (closed relays, MX machines, large mailservers with lots of users) have to worry about (a) spam, and (b) scaling issues, and any kind of pre-emptive spam-avoidance is (1) welcome, and (2) maybe necessary.] [If the pre-emptive testing resulted in lists of known-good (machines *known* to be *not-open* for relay), then this would be, in effect, an opt-in/opt-out mechanism; then sites who don't wish to allow testing by a testing-agent, would still need to be verified when mail is received from them; this verification could be cached by mailhubs (and kept for some well-defined interval, such as the refresh period from the SOA for the zone for the sending machine.) Testing of such opt-out sites would then be done only by parties receiving mail from them, not by anyone else. I think that would keep most folks happy.] 3) Hosts listed with A records for any "main" zone, eg "foo.com". If there is no MX record, but there is an A record, which would be used for mail to that zone, it is reasonable to presume that spammers will attempt to use the machine. (Or is it? I'm playing devils advocate, here.) [IMHO, this is reasonable iff (2) is reasonable.] 4) Hosts whose names can be found by zone-tranfer from a "main" zone. If administators for a zone operate a nameserver which does not do ACL-based restrictions on zone-transfers, is it reasonable to presume that any server listening to port 25 is more likely to be an open relay? [IMHO, regardless of SMTP testing, anyone doing this check should notify admins where this is permitted, that they might want to not permit this.] 5) Hosts listening to port 25. [IMHO, Occams razor would have drawn blood already.] -- 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

5 7

Trust in cyberspace
by Sean Donelan 16 Jan '00

16 Jan '00

I visited the bookstore (you know, those places you bought books before Amazon.com) and picked up a copy of "Trust in cyberspace." Although much of the book is concerned with "security," I was pleased to see some coverage of other problems which reduce people's confidence in network systems. The chapter on the "Public Telephone Network" (PTN) and the Internet trustworthiness has a very good overview of the design decisions, types of failures and attacks. Unlike many cyber-assurance studies which only focus on the "hacker" attack; congestion, link failure (aka Backhoe attack), and operator error are included in this book. Most of us are aware of the security weakness with the current Internet, but this book is one of the first I've seen to list several weaknesses in the Public Telephone Network in on place. One oversight is the book doesn't really explain the definition of "failure" or "outage" varies between the PTN and the Internet. So you can't easily compare reliability measurements between them. The famous 99.999% reliability of the PTN doesn't translate to the Internet because the Internet measurements include things normally excluded by the PTN measurements, e.g. congestion. One important buzzword I would call your attention to is "Minimum Essential Information Infrastructure." This is a creation of a RAND researcher in 1995, and is percolating around the cyber-assurance groups.

1 0

Re: Fw: Administrivia: ORBS [LONG]
by Randy Bush 16 Jan '00

16 Jan '00

> People who object to their networks being scanned for SMTP vulnerabilities > on occasion (with an interval that ranges from a couple of weeks to a > couple of months) have something to hide. thank you joe mccarthy randy

1 0

Re: Fw: Administrivia: ORBS
by Paul Vixie 15 Jan '00

15 Jan '00

patrick(a)ianai.net (I Am Not An Isp) writes: > What do other open relay lists (e.g. MAPS/RSS) do when they are filtered at > the network level? That's a misleading question. MAPS RSS doesn't probe for relay openness unless spam has been received from the relay in question. OTOH, if there is spam receipt and if the relay doesn't appear to be reachable, a human operator can decide that a firewall might be involved and block the relay in spite of our inability to test it. MAPS RSS never blocks whole address ranges, only /32's. ORBS is apparently blocking whole /16's belonging to Abovenet only because Abovenet refuses to have whole /16's probed for SMTP servers and then having each such server probed for relay openness. (I can't say as I blame them.) -- Paul Vixie <vixie(a)mibh.net> >> But what *IS* the internet? > It's the largest equivalence class in the reflexive transitive > symmetric closure of the relationship "can be reached by an IP > packet from". --Seth Breidbart

5 5

Re: Fw: Administrivia: ORBS
by Paul A Vixie 15 Jan '00

15 Jan '00

> I don't have much of a problem about Abovenet having a policy of not > allowing spam across their network, as you say it is theirs. What is bad, > however, is that Abovenet still advertise the prefix surrending hosts they > block, blackholing these hosts for their BGP mutilhomed customers - this is pretty hard for abovenet to fix, since no router i'm aware of is able to take in a /13 from some customer, blackhole a smattering of /32's inside of it, and only send the remnants of the /13 to its downstreams. what MIBH does, as a transit customer of abovenet among others, is to take an RBL BGP feed just for the purpose of route-mapping all of its contents toward one of our other transit providers. (MIBH is the transit provider for MAPS, among other things, and MAPS has web servers which *must* be able to be reached by people listed on its RBL. is that funny, or what?) i agree that this is painful, and if it were my network i'd find some way to let abovenet's multihomed customers automatically avoid abovenet for things which aren't going to work.

1 0