- NANOG - lists.nanog.org

Re: mail server probs
by sully＠mail.usinternet.com 12 Feb '98

12 Feb '98

Jay + NANOG I am using Post.office on NT 4.0 SP3, with over 10000 accounts and am running into some trouble. Its running on a dual PPro200 512k cache per chip, 2meg cache on board, 512M RAM, RAID-5 10meg buffer disk totaling 32gig. I've got this problem where the POP3 dies every 10 minutes or so. There is usually 50 SMTP connections, and 10 POP3's when it dies. CPU and Disk I/O are relatively low. The service needs to be stop/started for it to work again (for next 10 mins). I've checked for malicious activities and have pretty much ruled them out (things like socket flooders). Its pretty much got me stumped. Any suggestions? Thanks > > >>Hello... >> >>Do any of you guys/gals happen to use Post.Office as a mail server for NT? >>If so, give me an email I'd like to discuss something with you. > > >I use it on NT 3.51 SP5. I have about 3,000 mail accounts on our server. > >Jay Stewart >Vice President >Olympia Networking Services - "Olympia's Premier ISP" >Phone (360) 753.3636 Fax (360) 357.6160 http://www.olywa.net > > >

1 0

mail server probs
by sully＠mail.usinternet.com 12 Feb '98

12 Feb '98

Hello... Do any of you guys/gals happen to use Post.Office as a mail server for NT? If so, give me an email I'd like to discuss something with you. Thanks. Tim Sullivan Network Administrator Network Enthusiast

1 0

Re: RA/RV Feeds from RBN
by brandon＠rd.bbc.co.uk 11 Feb '98

11 Feb '98

>> Or is it simply time to declare NANOG yet another >> bastion of closed minds, and closed protocols? There's not much rocket science in this, if someone was to get together an open product that did this things may be different. So far most of the systems have been coming out of start ups that end up going for the money. The MBONE tools are OK but from where I sit are useless as the end users don't have MBONE. This is an operational issue and you can programme your Cisco's to do it :) If MBONE is to be a serious contender the ISPs must deliver it, then us content providers that are wasting tons of net bandwith could become nicer netizens and wouldn't use the unicast products that end users are asking for. Of course the ISPs may not take as much money off us as we wouldn't need quite so much bandwidth (perhaps there's a reason there?) > I would be happy if there was actual support for non-Intel/non-MMXprocessors, > aside from Macintosh. I happily run the player and servers on Sparc/Solaris boxes. No Intel, no Microsoft, no problem. It wouldn't hurt to see more platforms though, Real could do with being a bit more open and not trying to do everything themselves, there's plenty that'd help them out (most platforms have some good hacker zealots that'd do a port). > As it is, everything since their version 3 release has been > "Error 88" in our office > since they won't support these so-called 'orphan' CPUs. I think people are getting a bit heavy with the not so bad guys, it could be worse - you could be looking at a Microsoft only system instead. I've found Real to be more receptive to cross platform support, if a little tardy in following it through to delivery. Brandon -- Brandon Butterworth phone: 01737 836592 BBC Research & Development fax: 01737 832336 Kingswood Warren, Tadworth email: brandon(a)rd.bbc.co.uk Surrey, KT20 6NP URL: http://www.bbc.co.uk/

1 0

Re: Media query: ATM
by James Glave 11 Feb '98

11 Feb '98

Jeremy, Not to put too fine a point on it, but the nanog archives weren't really a solution for me because I needed quotes from people on the ATM issue, quotes that I could use in my story. Would you have preferred if I had cribbed someone's old nanog post without their permission, which is what I would have needed to do given the reality of news deadlines? I don't think so. I also was seeking reaction to Mr. Feldman's comment, which the archives would obviously not offer. Unlike many of my colleagues in the computer trade press, I am rabid about sourcing and accuracy. Thankfully, a number of people on the nanog list were very helpful in this regard. Best, James Glave Wired News http://www.wirednews.com At 02:52 PM 2/11/98 -0600, you wrote: > >Not to put too fine a point on it, but this has been discussed in endless >detail on the Nanog archive. I remember a day when reporters did research >but, I guess we are seeing the least common denominator once again. > >In message <3.0.32.19980210131256.009db2b4(a)get.wired.com>, James Glave writes: >>Hi all, >> >>I lurked on this morning's state of the net presentation, and I'd like to >>do a short piece on it for Wired News (http://www.wired.com) The MAE >>"fragility" and transition to ATM seems a contentious issue with many in >>the audience. Is there someone on the list who would like to offer their >>perspective on this, especially Mr. Feldman's observation in the Q&A that >>"the gigaswitch has reached the end of its useful life." >> >>What, briefly, is the controversy around moving to ATM for high-bandwidth >>data needs? If you reply, please do so with the assumption that I may quote >>you for publication. Thanks for your time, >> >>jtg >--- >Jeremy Porter, Freeside Communications, Inc. jerry(a)fc.net >PO BOX 80315 Austin, Tx 78708 | 1-800-968-8750 | 512-458-9810 >http://www.fc.net > James Glave : Senior Technology Writer : Wired News http://www.wirednews.com : 415.276.8430

1 0

Media query: ATM
by James Glave 11 Feb '98

11 Feb '98

Hi all, I lurked on this morning's state of the net presentation, and I'd like to do a short piece on it for Wired News (http://www.wired.com) The MAE "fragility" and transition to ATM seems a contentious issue with many in the audience. Is there someone on the list who would like to offer their perspective on this, especially Mr. Feldman's observation in the Q&A that "the gigaswitch has reached the end of its useful life." What, briefly, is the controversy around moving to ATM for high-bandwidth data needs? If you reply, please do so with the assumption that I may quote you for publication. Thanks for your time, jtg James Glave : Senior Technology Writer : Wired News http://www.wirednews.com : 415.276.8430

2 1

Re: NANOG in the news
by James Glave 11 Feb '98

11 Feb '98

Or you could read my original, non-reuters, Wired News version... http://www.wired.com/news/news/technology/story/10214.html jtg At 10:58 AM 2/11/98 -0800, J.D. Falk wrote: >http://www.yahoo.com/headlines/980211/wired/stories/crowd_1.html > >-- >J.D. Falk <jdfalk(a)vix.com> >Vixie Enterprises http://www.vix.com/ > James Glave : Senior Technology Writer : Wired News http://www.wirednews.com : 415.276.8430

1 0

NANOG in the news
by J.D. Falk 11 Feb '98

11 Feb '98

http://www.yahoo.com/headlines/980211/wired/stories/crowd_1.html -- J.D. Falk <jdfalk(a)vix.com> Vixie Enterprises http://www.vix.com/

1 0

Registration Fee Refund
by Pam Ciesla 11 Feb '98

11 Feb '98

Please contact me if you registered with payment info but did not attend the NANOG 12 Meeting. Thanks xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Pam Ciesla 734-936-0172 - phone Merit Network, Inc. 734-647-3185 - fax University of Michigan 4251 Plymouth Road Bldg. I, Suite C Ann Arbor, MI 48105-2785 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

1 0

Re: Erroneous BGP advertisement
by David J. Schmidt 11 Feb '98

11 Feb '98

On Wed, 11 Feb 1998, Joe Shaw wrote: > I thought all responsible parties (like Sprint) filtered their customer > routes. I know I can't advertise or leak out anything to MCI or UUNet > that I havn't registered with them. I've heard in the past that Sprints > route acceptance policy was a little on the trusting side, but not > filtering your customers announcements is just silly. They (sprint) > should only allow their customers to advertise their registered IP space > and stop things like this from happening. > > I'm looking at Sprint's BGP policy (http://www.sprint.net/bgppolicy.htm) > and it appears that they are way too trusting. They expect their > customers to do everything right, and for someone with little or no > knowledge of setting up BGP, they could quickly cause havoc for Sprint's > or other carriers' networks. This is especially interesting since they > offer no BGP help what so ever according to this document. Also according > to this document, the customer is responsible for all filtering, which is > an extremely poor practice. I wonder how long it will take for a Sprint > customer to advertise a default route out and I wonder how many sites it > would effectively blackhole. > > Regards, > Joe Shaw - jshaw(a)insync.net > NetAdmin - Insync Internet Services We multihomed with Sprint around the beginning of October. Sprintlink will do either AS or IP based filters to their BGP peers. From their bgpform.txt: --- 8. Do you prefer AS (see 8a) or IP (see 8b) based filters*? [ ] AS filters - answer question 8a [*] IP filters - answer question 8b * All customers are filtered based on either AS path or IP address. AS filters allow customers to announce any blocks they acquire but can lead to problems if the customer configuration announces other provider routes to us (creating transit across the customer) or our own routes back to us (creating a black hole). IP filters allow customers to modify the AS announcements. Both methods have their advantages and we prefer to set up IP filters because it makes the customer configurations simpler and avoids possible transit/black hole problems. --- If the customer has chosen AS based filtering then they can announce any addresses at will, causing this type of problem. Incidently, we chose IP filtering :-). David.Schmidt(a)ior.com Internet Ventures, Inc. (509)622-2878 x238 Spokane, Washington http://www.perki.net/ (509)622-2872 (fax)

1 0

Erroneous BGP advertisement
by Bruce Robertson 11 Feb '98

11 Feb '98

Currently, one half of our /18 is being erroneously advertised by Sprint (207.228.0.0/19). This, naturally, is causing us no end of trouble. Sprint, meanwhile, blames a third party. This has been going on for over 24 hours. First, if you're reading this and you're the culprit, please stop advertising 207.228.0.0/19. Second, I'm soliciting advice from others who have experienced this. How did you get results from the culprits? Can you recommend an attorney who is familiar with the issues, in case we decide to recover our lost revenue stream? Thanks! -- Bruce Robertson, President/CEO Great Basin Internet Services, Inc. +1-702-348-7299 fax: +1-702-348-9412

7 6