[KLUG Members] A plea for firewall ideas

[awilliam at whitemice.org]

> > > We are sending ~250k messages an hour during these problems, and I'm not
> > > worried about mail server throughput, only firewall throughput.  The two
> > > mail servers are behind the firewall, not on the firewall.
> > Honestly, it is hard to believe there is a legitimate use for that
> > quantity of messages.  Thats a message for every resident of the state
> > of Michigan in only a few hours;  major universities don't generate that
> Nice.  Think 'Donor', and 'nonprofit organization'. There's quite a few
> nonprofits, and here's quite a few people who donate to, or at least like to
> be affiliated with those orgs.  Sending email to donors, well-wishers, etc, is
> probably a safe way of contacting them, right?  Right.  

Ok

> > > > > > not just normal mail, but large amounts of mail for clients. We have
> > > > > > two servers that will send this mail, and the activity usually peaks
> > > > > > at 8 Mbit for about 4 hours (Connections come in from one f the
> > > > > > internal zones, gets SNATted on the way out, etc).
> > How big is your Internet pipeline?
> Um, plenty.  Burstable to 100 Mbit.

So it is frame relay?  If so that can explain alot, what is your CIR?  
Does your provider send you reports on cloud loss?  What type of router is 
at the frame circuit end-point?  What do you FECN & BECN counters look like? 
Do they surge during this activity?

We have a dozen or some frame circuits, and "burstable" is a theoretical 
statement.  

And at 250,000+/hr TCP connections your not really "bursting". :)  Very 
brief flickers in the amount of bandwidth available from the cloud will 
dramatically increase the effort required to establish a connection.
 
> > > > > I'm not following why email would be different than other internet
> > > > > traffic, and why passing traffic should use so much CPU power.         
> > > In speaking with someone else, it was a matter of "open TCP connections",
> > > not just 'how much traffic I'm sending'.     
> > This is possible with that insane number of connections,  you might just
> > want to try adjusting FIN/ACK timeouts as you probably have lots dead
> > remotes with that number of connections.  There are several TCP
> > connection handling parameters available via sysctl.
> > Some are covered in -
> > ftp://ftp.kalamazoolinux.org/pub/pdf/PerfTune2001.pdf
> I'll take a look at this, thanks.