Re[2]: [Declude.JunkMail] OT: Switch to control bandwidth
Old thread here, but I'm just catching up. Your budget requirements are going to make a comprehensive solution pretty difficult. Like some other posters mentioned, I think your best bet would be good monitoring. Someone recommend ks-soft (www.ks-soft.com) to us. We've been using for about 9 months now and love it. -David -- Best regards, Davidmailto:[EMAIL PROTECTED] --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] OT: Switch to control bandwidth
Title: Message I just wanted to follow up on this topic. Andrew wins the prize this time for unknowingly pointing out what I consider to have been a gold mine. Packeteer makes very nice devices for bandwidth shaping (the PacketShaper) that allow you to have very granular control of bandwidth down to the IP and Kbps. They even allow you to set guaranteed levels and burst ceilings, and then prioritize groups if you are guaranteeing more than is available or capped overall. They are hugely expensive, with a PacketShaper 2500 and 10 Mbps license running about $13,000...but if you find a used PacketShaper 2000 which handle 10 Mbps, they seem to be going for around $500. Since I'm not protecting users and just a few servers, I don't need the latest greatest features available such as point to point compression and other things, but it's clear that you still get more than what most switches provide in terms of shaping and the interface is sweet (Web based GUI). So I bought a 2000 and will place an inexpensive unmanaged GB switch behind it. Total cost about $700 combined. There are 2 Mbps versions of the PacketShaper 1000 that are more common and sell for even less. The equipment is a little old, but you could always buy 26 of them and still come out ahead of retail and have plenty of redundancy :) There are no licensing issues like with Cisco. Thanks everyone for the help. Matt Colbeck, Andrew wrote: I can add a few bits. Packeteer.com and Net-Reality.com both have swissarmy-like products that will fit the bill, but they don't come at a pricepoint that fits your budget. If their licencing scheme fits, and you can get a bargain on eBay, I'd recommend them. And they do work inline, and "fail open" if the hardware fails or the power to their unit is unplugged. I'm pretty sure that the rate limiting in HTTP for W2K3 does work, but it can't take into account how much of your pipe is empty, it will only work based on your pre-set maximum limit. The queuing problem you saw with IMail is a product of their limited threading. You had ample CPU left, but the thread was full. IMail has an upgrade soon (already? 8.2?) that would help, at least with 2 out of the three issues you cited. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matt Sent: Wednesday, February 16, 2005 12:51 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] OT: Switch to control bandwidth I've got a nice solution for this called IPcheck Server Monitor from Paessler (http://www.paessler.com/products/ipcheck/?link=menu). It is buggy however from the standpoint of the interface, though they have been continually improving and fixing it. It has nice notification features such as dependencies. I monitor from a separate network from the servers themselves, giving a good impression of what my customers experience. I kind of feel tied down to monitoring and then researching, and then resolving issues. For instance, in the last 24 hours I had the following happen: - Customer's mail server IP changed without notifying us, causing lots of spooled messages. - One person sent about 150 MB of E-mail (separate large messages) to a MailPure protected account and that slowed down our responsiveness on all services (HTTP and POP3 also affected. No fix can be applied for this except for limiting as the traffic was legit, just unusually bursty. - Customer's remote Web server misbehaving and delivered 10,000 messages to their own account through our gateway. No immediate issues, but it bears watching for potential escalation that could threaten our performance. I'm spending a lot of time with this stuff on a regular basis and want to be a bit more proactive so that I don't need to feel tied down. Almost all issues can be controlled by rate limiting, though some require extensive granularity to achieve sufficient protection. QOS is also at issue since I stay away from doing inexpensive services, concentrating on value-added, and many of my customers do expect more. Right now I'm fine, but the more I grow, the more often these things will occur and I think it's time to put something else in place that can stop issues from potentially affecting every service/customer. Matt Darin Cox wrote: Best solution is monitoring. Without creating a system of dedicated circuits to each customer you can't guarantee one customer will not adversely affect another. Rate-limiting at the switch (or software "switch") will help, but still means a smaller pipe for everyone else...and doesn't help with multiple customers misbehaving. With appropriate SNMP or RMON monitoring, however, you
Re[2]: [Declude.JunkMail] OT: Switch to control bandwidth
Hi Matt, Read thru their web site - it's not "open source" and he will tell you that. Best thing is to open up a SALES TICKET and ask your questions - he's pretty fast on getting back to you. Also, you can download beta/demo software to try out -- so, you might give that a try. And, he sells a failover nic card too in case the box dies you can still have your data pass through. hth. -jason M> Thanks, this looks like another good candidate. The software license of M> $795 isn't that bad, and you don't need anything special to run it to M> capacity on my network. I would like to see it in action however, and M> figure out if it was easy to use (worth money to me), and also as stable M> as could be. I don't know how I might have a hot spare configuration M> with a setup like this so having something that is virtually bulletproof M> is worth a lot here. M> I'm also guessing that this is an open source app underneath the GUI and M> managed updates. It would be nice to know what that was. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] OT: Switch to control bandwidth
Thanks, this looks like another good candidate. The software license of $795 isn't that bad, and you don't need anything special to run it to capacity on my network. I would like to see it in action however, and figure out if it was easy to use (worth money to me), and also as stable as could be. I don't know how I might have a hot spare configuration with a setup like this so having something that is virtually bulletproof is worth a lot here. I'm also guessing that this is an open source app underneath the GUI and managed updates. It would be nice to know what that was. Matt sbsi lists wrote: Hi Matt, you might look at http://www.etinc.com/index.php?cPath=25 more $$s than your budget UNLESS you go with their software and you handle the OS/Hardware. I don't have experience with this -- yet... but thinking of using one of their appliances or get the software and trying it. -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] OT: Switch to control bandwidth
Darin Cox wrote: For the specific cases you outlined, it sounds like IMGate might help. We don't use it, but from what I've read on the lists, it sounds like it could be configured to protect against these scenarios. We use a single box solution integrating VamSoft's ORF with MS SMTP on the same box as IMail (and also on a backup server that is live with ORF/MS SMTP, cold spare for IMail/Declude). I finally got address validation going the other day, and we are blocking 70% of address attempts (typically 5 bad addresses per dictionary attack E-mail). This only saved an average of about 100Kbps or about 1/6th of average hourly bandwidth at peak times. Spam is typically very small and more of a processing issue than a bandwidth issue. We still have about 40 domains not being fully validated, but the bulk of the issues have been resolved with what we have and the others will come in time. This was only a minor nuisance as this stuff was easy to block with our Declude setup and it is very low in bandwidth unless you get hit by the million address per day guy, but that hasn't happened to us yet. We are protected from that now, and this was designed as protection from just that sort of thing. I'm also looking at tarpitting, dictionary attack protection, and select gateway blacklisting of abusive hosts, but we don't have anything in place for that yet. It's not a fire yet, but I figure that I can save processing power and therefore software and hardware expense by introducing these things before I run out of capacity. Right now we are limited in bandwidth and not burstable, but that will change in 1 1/2 to 2 1/2 months when we migrate our facilities. Then the issue becomes expense, and bandwidth will cost me $200 per Mbps at 95th percentile, so an investment in hardware as opposed to bandwidth seems like a good idea to save money in the long haul. I figure that I can easily save $2,400 a year in bandwidth by doing this, and also protect the CPU utilization and against DOS at the same time. I'm under the impression that you can greatly affect your 95th percentile rate by merely limiting individual IP's, and having 4 MX records and IMail on a separate IP, I think we could manage this fairly effectively without affecting service. Same goes for HTTP and FTP stuff as well. I don't think that anyone would complain about being limited to 512Kbps for a HTTP/FTP connection without being charged for more, and slightly delaying MX's SMTP traffic in this way has almost no affect on QOS for hosted E-mail customers. I know...too much detail :) Matt -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =
RE: [Declude.JunkMail] OT: Switch to control bandwidth
Title: Message I can add a few bits. Packeteer.com and Net-Reality.com both have swissarmy-like products that will fit the bill, but they don't come at a pricepoint that fits your budget. If their licencing scheme fits, and you can get a bargain on eBay, I'd recommend them. And they do work inline, and "fail open" if the hardware fails or the power to their unit is unplugged. I'm pretty sure that the rate limiting in HTTP for W2K3 does work, but it can't take into account how much of your pipe is empty, it will only work based on your pre-set maximum limit. The queuing problem you saw with IMail is a product of their limited threading. You had ample CPU left, but the thread was full. IMail has an upgrade soon (already? 8.2?) that would help, at least with 2 out of the three issues you cited. Andrew 8) -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MattSent: Wednesday, February 16, 2005 12:51 PMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] OT: Switch to control bandwidthI've got a nice solution for this called IPcheck Server Monitor from Paessler (http://www.paessler.com/products/ipcheck/?link=menu). It is buggy however from the standpoint of the interface, though they have been continually improving and fixing it. It has nice notification features such as dependencies. I monitor from a separate network from the servers themselves, giving a good impression of what my customers experience.I kind of feel tied down to monitoring and then researching, and then resolving issues. For instance, in the last 24 hours I had the following happen: - Customer's mail server IP changed without notifying us, causing lots of spooled messages. - One person sent about 150 MB of E-mail (separate large messages) to a MailPure protected account and that slowed down our responsiveness on all services (HTTP and POP3 also affected. No fix can be applied for this except for limiting as the traffic was legit, just unusually bursty. - Customer's remote Web server misbehaving and delivered 10,000 messages to their own account through our gateway. No immediate issues, but it bears watching for potential escalation that could threaten our performance.I'm spending a lot of time with this stuff on a regular basis and want to be a bit more proactive so that I don't need to feel tied down. Almost all issues can be controlled by rate limiting, though some require extensive granularity to achieve sufficient protection. QOS is also at issue since I stay away from doing inexpensive services, concentrating on value-added, and many of my customers do expect more.Right now I'm fine, but the more I grow, the more often these things will occur and I think it's time to put something else in place that can stop issues from potentially affecting every service/customer.MattDarin Cox wrote: Best solution is monitoring. Without creating a system of dedicated circuits to each customer you can't guarantee one customer will not adversely affect another. Rate-limiting at the switch (or software "switch") will help, but still means a smaller pipe for everyone else...and doesn't help with multiple customers misbehaving. With appropriate SNMP or RMON monitoring, however, you can be notified as soon as traffic goes beyond a given threshold and react accordingly. Darin. - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Wednesday, February 16, 2005 3:18 PM Subject: Re: [Declude.JunkMail] OT: Switch to control bandwidth I just wanted to follow up on this thread. First, thanks for all of the suggestions. Here's a summary of what caught my eye. 1) There are some decent choices out there, and seemingly a 3COM SuperStack 3 3226 comes at a nice price point (around $500) and allows limiting per port at 1 Mbps increments and also does 7 custom levels of protocol prioritization. This was suggested to me off-list. It seems like a good thing for colocation since you don't care for more granularity among your customers, they can choose to do with their bandwidth what they wish. I'm not into colocation yet and this probably falls short of my needs otherwise.2) I was also intrigued by the NetEqualizer product, which seems to be a the commercial version of an open source project called Linux Bandwidth Arbitrator (www.bandwidtharbitrator.com). This might very well offer functionality beyond all of the switches, but offers more complication in setup and management unless you go with the f
Re: [Declude.JunkMail] OT: Switch to control bandwidth
I hear ya... hate to be in reactive mode as well. When sharing pipes you only have two choices, clamp bandwidth down for any single customer to the point that one or more customers' abuse won't impact others, or react via monitoring. For the specific cases you outlined, it sounds like IMGate might help. We don't use it, but from what I've read on the lists, it sounds like it could be configured to protect against these scenarios. Darin. - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Wednesday, February 16, 2005 3:51 PM Subject: Re: [Declude.JunkMail] OT: Switch to control bandwidth I've got a nice solution for this called IPcheck Server Monitor from Paessler (http://www.paessler.com/products/ipcheck/?link=menu). It is buggy however from the standpoint of the interface, though they have been continually improving and fixing it. It has nice notification features such as dependencies. I monitor from a separate network from the servers themselves, giving a good impression of what my customers experience.I kind of feel tied down to monitoring and then researching, and then resolving issues. For instance, in the last 24 hours I had the following happen: - Customer's mail server IP changed without notifying us, causing lots of spooled messages. - One person sent about 150 MB of E-mail (separate large messages) to a MailPure protected account and that slowed down our responsiveness on all services (HTTP and POP3 also affected. No fix can be applied for this except for limiting as the traffic was legit, just unusually bursty. - Customer's remote Web server misbehaving and delivered 10,000 messages to their own account through our gateway. No immediate issues, but it bears watching for potential escalation that could threaten our performance.I'm spending a lot of time with this stuff on a regular basis and want to be a bit more proactive so that I don't need to feel tied down. Almost all issues can be controlled by rate limiting, though some require extensive granularity to achieve sufficient protection. QOS is also at issue since I stay away from doing inexpensive services, concentrating on value-added, and many of my customers do expect more.Right now I'm fine, but the more I grow, the more often these things will occur and I think it's time to put something else in place that can stop issues from potentially affecting every service/customer.MattDarin Cox wrote: Best solution is monitoring. Without creating a system of dedicated circuits to each customer you can't guarantee one customer will not adversely affect another. Rate-limiting at the switch (or software "switch") will help, but still means a smaller pipe for everyone else...and doesn't help with multiple customers misbehaving. With appropriate SNMP or RMON monitoring, however, you can be notified as soon as traffic goes beyond a given threshold and react accordingly. Darin. - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Wednesday, February 16, 2005 3:18 PM Subject: Re: [Declude.JunkMail] OT: Switch to control bandwidth I just wanted to follow up on this thread. First, thanks for all of the suggestions. Here's a summary of what caught my eye. 1) There are some decent choices out there, and seemingly a 3COM SuperStack 3 3226 comes at a nice price point (around $500) and allows limiting per port at 1 Mbps increments and also does 7 custom levels of protocol prioritization. This was suggested to me off-list. It seems like a good thing for colocation since you don't care for more granularity among your customers, they can choose to do with their bandwidth what they wish. I'm not into colocation yet and this probably falls short of my needs otherwise.2) I was also intrigued by the NetEqualizer product, which seems to be a the commercial version of an open source project called Linux Bandwidth Arbitrator (www.bandwidtharbitrator.com). This might very well offer functionality beyond all of the switches, but offers more complication in setup and management unless you go with the for-profit version. This is of course not a switch, but that's ok since cheap switches can be placed behind it.3) Cisco is of course a popular choice, but I'm not a fan of their ridiculous licensing schemes for the software and high prices. Used, these things come fairly cheap, but they are the 'Outlook' of routers and switches, and the most likely to be targeted by exploits. For that reason, I am probably going to migrate away from anything Cisco once I outgrow what I already have. I may change my mind however.4) I don't think I need a fi
Re: [Declude.JunkMail] OT: Switch to control bandwidth
The only other thing that I could possibly think of is a lot of what you are talking about could be QoS'ed. Unfortunatly, this would be on a service level requirement. For exmaple not letting SMTP exceed a certain bandwidth when web is at a certain level, but allowing SMTP to burst when web is low. Darrell Darin Cox writes: Best solution is monitoring. Without creating a system of dedicated circuits to each customer you can't guarantee one customer will not adversely affect another. Rate-limiting at the switch (or software "switch") will help, but still means a smaller pipe for everyone else...and doesn't help with multiple customers misbehaving. With appropriate SNMP or RMON monitoring, however, you can be notified as soon as traffic goes beyond a given threshold and react accordingly. Darin. - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Wednesday, February 16, 2005 3:18 PM Subject: Re: [Declude.JunkMail] OT: Switch to control bandwidth I just wanted to follow up on this thread. First, thanks for all of the suggestions. Here's a summary of what caught my eye. 1) There are some decent choices out there, and seemingly a 3COM SuperStack 3 3226 comes at a nice price point (around $500) and allows limiting per port at 1 Mbps increments and also does 7 custom levels of protocol prioritization. This was suggested to me off-list. It seems like a good thing for colocation since you don't care for more granularity among your customers, they can choose to do with their bandwidth what they wish. I'm not into colocation yet and this probably falls short of my needs otherwise. 2) I was also intrigued by the NetEqualizer product, which seems to be a the commercial version of an open source project called Linux Bandwidth Arbitrator (www.bandwidtharbitrator.com). This might very well offer functionality beyond all of the switches, but offers more complication in setup and management unless you go with the for-profit version. This is of course not a switch, but that's ok since cheap switches can be placed behind it. 3) Cisco is of course a popular choice, but I'm not a fan of their ridiculous licensing schemes for the software and high prices. Used, these things come fairly cheap, but they are the 'Outlook' of routers and switches, and the most likely to be targeted by exploits. For that reason, I am probably going to migrate away from anything Cisco once I outgrow what I already have. I may change my mind however. 4) I don't think I need a firewall, or don't want to deal with the expense and limitations of it (concurrent sessions, etc.). I have so few ports open that I'm fine with router level protection and this is exclusively a DMZ with no client computers behind it. Despite what these products offer, I still think that the switches generally come up short of being a perfect solution to my needs (that of a Web hosting/E-mail provider). I essentially have 5 services that I need to support across 3 machines; HTTP, FTP, DNS, SMTP, and POP3. It seems that by just simply bandwidth limiting a port, I won't be able to slow down but a portion of the problematic bandwidth and there can be other issues caused by that (such as limiting all HTTP because of one site that is getting hammered). It would be best to limit HTTP by IP instead of by port. I haven't tested it out yet, but it may be that IIS will actually work when limiting in Windows 2003 unlike 2k, and that may solve my issue on that front at least. FTP may or may not be covered by the same, I'm not sure yet. It seems however that some of the worst issues are coming from fairly unique situations and specific IP addresses. Conditions like E-mail loops can not only bring down a mail server, but also bring down a whole network if all of your bandwidth is used. This of course can also affect POP3 service. If a customer does a mass mailing with huge images sourced from their site, the bandwidth could also bring us down without limits. I even had a customer send 144 messages out the other day with a 2.5 MB attachment, and if you do the math, you will find that this was 400 MB of bandwidth that IMail naturally attempts to deliver ASAP. I've also noted that IMail doesn't do well with response times under heavy bandwidth load even if the CPU is fine while other services on the same box have far less latency. This affects the quality of service to my customers, and I like things to be responsive. So what I am really looking for is some way to protect Web hosting clients from another Web hosting client's issue, protect POP3 service from having the bandwidth bogarted by some SMTP loop, or FTP, or HTTP, etc. Since everyone shares the same MX records, and the same outgoing SMTP and POP3, it's hard to find decent separation unless I get down to the IP level and start limitin
Re: [Declude.JunkMail] OT: Switch to control bandwidth
I've got a nice solution for this called IPcheck Server Monitor from Paessler (http://www.paessler.com/products/ipcheck/?link=menu). It is buggy however from the standpoint of the interface, though they have been continually improving and fixing it. It has nice notification features such as dependencies. I monitor from a separate network from the servers themselves, giving a good impression of what my customers experience. I kind of feel tied down to monitoring and then researching, and then resolving issues. For instance, in the last 24 hours I had the following happen: - Customer's mail server IP changed without notifying us, causing lots of spooled messages. - One person sent about 150 MB of E-mail (separate large messages) to a MailPure protected account and that slowed down our responsiveness on all services (HTTP and POP3 also affected. No fix can be applied for this except for limiting as the traffic was legit, just unusually bursty. - Customer's remote Web server misbehaving and delivered 10,000 messages to their own account through our gateway. No immediate issues, but it bears watching for potential escalation that could threaten our performance. I'm spending a lot of time with this stuff on a regular basis and want to be a bit more proactive so that I don't need to feel tied down. Almost all issues can be controlled by rate limiting, though some require extensive granularity to achieve sufficient protection. QOS is also at issue since I stay away from doing inexpensive services, concentrating on value-added, and many of my customers do expect more. Right now I'm fine, but the more I grow, the more often these things will occur and I think it's time to put something else in place that can stop issues from potentially affecting every service/customer. Matt Darin Cox wrote: Best solution is monitoring. Without creating a system of dedicated circuits to each customer you can't guarantee one customer will not adversely affect another. Rate-limiting at the switch (or software "switch") will help, but still means a smaller pipe for everyone else...and doesn't help with multiple customers misbehaving. With appropriate SNMP or RMON monitoring, however, you can be notified as soon as traffic goes beyond a given threshold and react accordingly. Darin. - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Wednesday, February 16, 2005 3:18 PM Subject: Re: [Declude.JunkMail] OT: Switch to control bandwidth I just wanted to follow up on this thread. First, thanks for all of the suggestions. Here's a summary of what caught my eye. 1) There are some decent choices out there, and seemingly a 3COM SuperStack 3 3226 comes at a nice price point (around $500) and allows limiting per port at 1 Mbps increments and also does 7 custom levels of protocol prioritization. This was suggested to me off-list. It seems like a good thing for colocation since you don't care for more granularity among your customers, they can choose to do with their bandwidth what they wish. I'm not into colocation yet and this probably falls short of my needs otherwise. 2) I was also intrigued by the NetEqualizer product, which seems to be a the commercial version of an open source project called Linux Bandwidth Arbitrator (www.bandwidtharbitrator.com). This might very well offer functionality beyond all of the switches, but offers more complication in setup and management unless you go with the for-profit version. This is of course not a switch, but that's ok since cheap switches can be placed behind it. 3) Cisco is of course a popular choice, but I'm not a fan of their ridiculous licensing schemes for the software and high prices. Used, these things come fairly cheap, but they are the 'Outlook' of routers and switches, and the most likely to be targeted by exploits. For that reason, I am probably going to migrate away from anything Cisco once I outgrow what I already have. I may change my mind however. 4) I don't think I need a firewall, or don't want to deal with the expense and limitations of it (concurrent sessions, etc.). I have so few ports open that I'm fine with router level protection and this is exclusively a DMZ with no client computers behind it. Despite what these products offer, I still think that the switches generally come up short of being a perfect solution to my needs (that of a Web hosting/E-mail provider). I essentially have 5 services that I need to support across 3 machines; HTTP, FTP, DNS, SMTP, and POP3. It seems that by just simply bandwidth limiting a port, I won't be able to slow down but a portion of the problematic bandwidth and there can be other issues caused by that (such as limiting all HTTP because of one site that is getting
Re[2]: [Declude.JunkMail] OT: Switch to control bandwidth
Hi Matt, you might look at http://www.etinc.com/index.php?cPath=25 more $$s than your budget UNLESS you go with their software and you handle the OS/Hardware. I don't have experience with this -- yet... but thinking of using one of their appliances or get the software and trying it. -- Thanks again, -jason [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - > Wednesday, February 16, 2005, 2:18:27 PM, you wrote: M> I just wanted to follow up on this thread. First, thanks for M> all of the suggestions. Here's a summary of what caught my eye. M> 1) There are some decent choices out there, and seemingly a M> 3COM SuperStack 3 3226 comes at a nice price point (around $500) M> and allows limiting per port at 1 Mbps increments and also does 7 M> custom levels of protocol prioritization. This was suggested to me M> off-list. It seems like a good thing for colocation since you M> don't care for more granularity among your customers, they can M> choose to do with their bandwidth what they wish. I'm not into M> colocation yet and this probably falls short of my needs otherwise. M> 2) I was also intrigued by the NetEqualizer product, which M> seems to be a the commercial version of an open source project M> called Linux Bandwidth Arbitrator (www.bandwidtharbitrator.com). M> This might very well offer functionality beyond all of the M> switches, but offers more complication in setup and management M> unless you go with the for-profit version. This is of course not a M> switch, but that's ok since cheap switches can be placed behind it. M> 3) Cisco is of course a popular choice, but I'm not a fan of M> their ridiculous licensing schemes for the software and high M> prices. Used, these things come fairly cheap, but they are the M> 'Outlook' of routers and switches, and the most likely to be M> targeted by exploits. For that reason, I am probably going to M> migrate away from anything Cisco once I outgrow what I already M> have. I may change my mind however. M> 4) I don't think I need a firewall, or don't want to deal with M> the expense and limitations of it (concurrent sessions, etc.). I M> have so few ports open that I'm fine with router level protection M> and this is exclusively a DMZ with no client computers behind it. M> Despite what these products offer, I still think that the M> switches generally come up short of being a perfect solution to my M> needs (that of a Web hosting/E-mail provider). I essentially have M> 5 services that I need to support across 3 machines; HTTP, FTP, M> DNS, SMTP, and POP3. It seems that by just simply bandwidth M> limiting a port, I won't be able to slow down but a portion of the M> problematic bandwidth and there can be other issues caused by that M> (such as limiting all HTTP because of one site that is getting M> hammered). It would be best to limit HTTP by IP instead of by M> port. I haven't tested it out yet, but it may be that IIS will M> actually work when limiting in Windows 2003 unlike 2k, and that may M> solve my issue on that front at least. FTP may or may not be M> covered by the same, I'm not sure yet. M> It seems however that some of the worst issues are coming from M> fairly unique situations and specific IP addresses. Conditions M> like E-mail loops can not only bring down a mail server, but also M> bring down a whole network if all of your bandwidth is used. This M> of course can also affect POP3 service. If a customer does a mass M> mailing with huge images sourced from their site, the bandwidth M> could also bring us down without limits. I even had a customer M> send 144 messages out the other day with a 2.5 MB attachment, and M> if you do the math, you will find that this was 400 MB of bandwidth M> that IMail naturally attempts to deliver ASAP. I've also noted M> that IMail doesn't do well with response times under heavy M> bandwidth load even if the CPU is fine while other services on the M> same box have far less latency. This affects the quality of M> service to my customers, and I like things to be responsive. M> So what I am really looking for is some way to protect Web M> hosting clients from another Web hosting client's issue, protect M> POP3 service from having the bandwidth bogarted by some SMTP loop, M> or FTP, or HTTP, etc. Since everyone shares the same MX records, M> and the same outgoing SMTP and POP3, it's hard to find decent M> separation unless I get down to the IP level and start limiting M> things based on at least the destination IP if not the source IP M> also. To do anything less would seem to be somewhat futile because M> I would continue to have sporadic issues with the most problematic M> things which can be long-lived to the point that they are M> resolved/blocked (DOS or loops for instance). M> I kind of get the feeling that a hardware based solution M> living in a switch or firewall of some sort might not be M> appropriate because it would be too expensive for me to justify. M>
Re: [Declude.JunkMail] OT: Switch to control bandwidth
Best solution is monitoring. Without creating a system of dedicated circuits to each customer you can't guarantee one customer will not adversely affect another. Rate-limiting at the switch (or software "switch") will help, but still means a smaller pipe for everyone else...and doesn't help with multiple customers misbehaving. With appropriate SNMP or RMON monitoring, however, you can be notified as soon as traffic goes beyond a given threshold and react accordingly. Darin. - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Wednesday, February 16, 2005 3:18 PM Subject: Re: [Declude.JunkMail] OT: Switch to control bandwidth I just wanted to follow up on this thread. First, thanks for all of the suggestions. Here's a summary of what caught my eye. 1) There are some decent choices out there, and seemingly a 3COM SuperStack 3 3226 comes at a nice price point (around $500) and allows limiting per port at 1 Mbps increments and also does 7 custom levels of protocol prioritization. This was suggested to me off-list. It seems like a good thing for colocation since you don't care for more granularity among your customers, they can choose to do with their bandwidth what they wish. I'm not into colocation yet and this probably falls short of my needs otherwise.2) I was also intrigued by the NetEqualizer product, which seems to be a the commercial version of an open source project called Linux Bandwidth Arbitrator (www.bandwidtharbitrator.com). This might very well offer functionality beyond all of the switches, but offers more complication in setup and management unless you go with the for-profit version. This is of course not a switch, but that's ok since cheap switches can be placed behind it.3) Cisco is of course a popular choice, but I'm not a fan of their ridiculous licensing schemes for the software and high prices. Used, these things come fairly cheap, but they are the 'Outlook' of routers and switches, and the most likely to be targeted by exploits. For that reason, I am probably going to migrate away from anything Cisco once I outgrow what I already have. I may change my mind however.4) I don't think I need a firewall, or don't want to deal with the expense and limitations of it (concurrent sessions, etc.). I have so few ports open that I'm fine with router level protection and this is exclusively a DMZ with no client computers behind it.Despite what these products offer, I still think that the switches generally come up short of being a perfect solution to my needs (that of a Web hosting/E-mail provider). I essentially have 5 services that I need to support across 3 machines; HTTP, FTP, DNS, SMTP, and POP3. It seems that by just simply bandwidth limiting a port, I won't be able to slow down but a portion of the problematic bandwidth and there can be other issues caused by that (such as limiting all HTTP because of one site that is getting hammered). It would be best to limit HTTP by IP instead of by port. I haven't tested it out yet, but it may be that IIS will actually work when limiting in Windows 2003 unlike 2k, and that may solve my issue on that front at least. FTP may or may not be covered by the same, I'm not sure yet.It seems however that some of the worst issues are coming from fairly unique situations and specific IP addresses. Conditions like E-mail loops can not only bring down a mail server, but also bring down a whole network if all of your bandwidth is used. This of course can also affect POP3 service. If a customer does a mass mailing with huge images sourced from their site, the bandwidth could also bring us down without limits. I even had a customer send 144 messages out the other day with a 2.5 MB attachment, and if you do the math, you will find that this was 400 MB of bandwidth that IMail naturally attempts to deliver ASAP. I've also noted that IMail doesn't do well with response times under heavy bandwidth load even if the CPU is fine while other services on the same box have far less latency. This affects the quality of service to my customers, and I like things to be responsive.So what I am really looking for is some way to protect Web hosting clients from another Web hosting client's issue, protect POP3 service from having the bandwidth bogarted by some SMTP loop, or FTP, or HTTP, etc. Since everyone shares the same MX records, and the same outgoing SMTP and POP3, it's hard to find decent separation unless I get down to the IP level and start limiting things based on at least the destination IP if not the source IP also. To do anything less would seem to be somewhat futile because I would continue to have sporadic issues with the most problematic things which can be long-lived to the point that they are resol
Re: [Declude.JunkMail] OT: Switch to control bandwidth
I just wanted to follow up on this thread. First, thanks for all of the suggestions. Here's a summary of what caught my eye. 1) There are some decent choices out there, and seemingly a 3COM SuperStack 3 3226 comes at a nice price point (around $500) and allows limiting per port at 1 Mbps increments and also does 7 custom levels of protocol prioritization. This was suggested to me off-list. It seems like a good thing for colocation since you don't care for more granularity among your customers, they can choose to do with their bandwidth what they wish. I'm not into colocation yet and this probably falls short of my needs otherwise. 2) I was also intrigued by the NetEqualizer product, which seems to be a the commercial version of an open source project called Linux Bandwidth Arbitrator (www.bandwidtharbitrator.com). This might very well offer functionality beyond all of the switches, but offers more complication in setup and management unless you go with the for-profit version. This is of course not a switch, but that's ok since cheap switches can be placed behind it. 3) Cisco is of course a popular choice, but I'm not a fan of their ridiculous licensing schemes for the software and high prices. Used, these things come fairly cheap, but they are the 'Outlook' of routers and switches, and the most likely to be targeted by exploits. For that reason, I am probably going to migrate away from anything Cisco once I outgrow what I already have. I may change my mind however. 4) I don't think I need a firewall, or don't want to deal with the expense and limitations of it (concurrent sessions, etc.). I have so few ports open that I'm fine with router level protection and this is exclusively a DMZ with no client computers behind it. Despite what these products offer, I still think that the switches generally come up short of being a perfect solution to my needs (that of a Web hosting/E-mail provider). I essentially have 5 services that I need to support across 3 machines; HTTP, FTP, DNS, SMTP, and POP3. It seems that by just simply bandwidth limiting a port, I won't be able to slow down but a portion of the problematic bandwidth and there can be other issues caused by that (such as limiting all HTTP because of one site that is getting hammered). It would be best to limit HTTP by IP instead of by port. I haven't tested it out yet, but it may be that IIS will actually work when limiting in Windows 2003 unlike 2k, and that may solve my issue on that front at least. FTP may or may not be covered by the same, I'm not sure yet. It seems however that some of the worst issues are coming from fairly unique situations and specific IP addresses. Conditions like E-mail loops can not only bring down a mail server, but also bring down a whole network if all of your bandwidth is used. This of course can also affect POP3 service. If a customer does a mass mailing with huge images sourced from their site, the bandwidth could also bring us down without limits. I even had a customer send 144 messages out the other day with a 2.5 MB attachment, and if you do the math, you will find that this was 400 MB of bandwidth that IMail naturally attempts to deliver ASAP. I've also noted that IMail doesn't do well with response times under heavy bandwidth load even if the CPU is fine while other services on the same box have far less latency. This affects the quality of service to my customers, and I like things to be responsive. So what I am really looking for is some way to protect Web hosting clients from another Web hosting client's issue, protect POP3 service from having the bandwidth bogarted by some SMTP loop, or FTP, or HTTP, etc. Since everyone shares the same MX records, and the same outgoing SMTP and POP3, it's hard to find decent separation unless I get down to the IP level and start limiting things based on at least the destination IP if not the source IP also. To do anything less would seem to be somewhat futile because I would continue to have sporadic issues with the most problematic things which can be long-lived to the point that they are resolved/blocked (DOS or loops for instance). I kind of get the feeling that a hardware based solution living in a switch or firewall of some sort might not be appropriate because it would be too expensive for me to justify. It seems that a Linux solution such as Bandwidth Arbitrator/NetEqualizer would need to be added in order to properly achieve the level of granularity that I desire without enormous cost. I have another qualification for this. I wish to spend less that $1,000 and have my network be survivable with a failure of this device. If I was using a switch based solution, I would need two switches for redundancy (though maybe a backup cheap switch). A firewall/router would likely be prohibitively expensive if you went for redundancy. An in-line Linux solution could however be simply bypassed in the event of an outage, though it would need to
RE: [Declude.JunkMail] OT: Switch to control bandwidth
> It > might even be nice to do this on a per-IP basis instead of a > per-port basis, though that's not absolutely necessary. > Since this is a Web hosting segment and our bandwidth is > naturally limited going out, and very little intra-DMZ > traffic exists, something that is 10/100 is all that is necessary. Maybe give a look to a Fortinet 50 or 60-series Firewall. You can manage guaranted & max traffic and also priorize certain protocols. The price shouldn't be higher then a manageable switch with traffic shapping capabilities. If you want to monitor each switch port with SNMP unfortunately the cheap Syslink Switch has no SNMP support. At the moment I look for different solutions. Certain Cisco Catalyst switches looks promising but also the good old HP ProCurve 2512/2524. Markus --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] OT: Switch to control bandwidth
Hi Matt- We do this on our Fortigate antivirus firewall, which allows us bandwidth limits and guarantees, both inbound and outbound, on a service and IP basis. -Dave - Original Message - From: "Matt" <[EMAIL PROTECTED]> To: Sent: Thursday, February 10, 2005 1:30 PM Subject: [Declude.JunkMail] OT: Switch to control bandwidth Ok, I'll break the ice :) I was wondering what people would recommend as far as a managed switch goes that I can use to either limit bandwidth or at least guarantee bandwidth going out to the router. It might even be nice to do this on a per-IP basis instead of a per-port basis, though that's not absolutely necessary. Since this is a Web hosting segment and our bandwidth is naturally limited going out, and very little intra-DMZ traffic exists, something that is 10/100 is all that is necessary. Thanks, Matt -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] OT: Switch to control bandwidth
Hi Matt, There may be other options, but we settled on Cisco 3350 switches for this. Their rate-limiting is much more granular than most others we looked at (most would only limit to 1Mbps per port, not below), however they are both pricey (~$3500) for 48 10/100 Mbps ports and 2 Gbps ports. You can save some money with less port density, though. 3350s can also be stacked and managed as one unit, creating VLANs that span multiple switches, with a slight upgrade to the IOS. Darin. - Original Message - From: "Matt" <[EMAIL PROTECTED]> To: Sent: Thursday, February 10, 2005 1:30 PM Subject: [Declude.JunkMail] OT: Switch to control bandwidth Ok, I'll break the ice :) I was wondering what people would recommend as far as a managed switch goes that I can use to either limit bandwidth or at least guarantee bandwidth going out to the router. It might even be nice to do this on a per-IP basis instead of a per-port basis, though that's not absolutely necessary. Since this is a Web hosting segment and our bandwidth is naturally limited going out, and very little intra-DMZ traffic exists, something that is 10/100 is all that is necessary. Thanks, Matt -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] OT: Switch to control bandwidth
I don't know if this will work the way you want it to, but I saw this company at Networld + Interop last year. It does have manual rate shaping available but it's biggest benefit is that it will automatically rate control connections to ensure no service can run away with too much bandwidth. http://www.netequalizer.com/ _ Scott Fosseen - Systems Engineer -Prairie Lakes AEA http://fosseen.us/scott _ "This 'telephone' has too many shortcomings to be seriously considered as a means of communication. The device is inherently of no value to us." - Western Union internal memo, 1876. _ - Original Message - From: "Matt" <[EMAIL PROTECTED]> To: Sent: Thursday, February 10, 2005 12:30 PM Subject: [Declude.JunkMail] OT: Switch to control bandwidth Ok, I'll break the ice :) I was wondering what people would recommend as far as a managed switch goes that I can use to either limit bandwidth or at least guarantee bandwidth going out to the router. It might even be nice to do this on a per-IP basis instead of a per-port basis, though that's not absolutely necessary. Since this is a Web hosting segment and our bandwidth is naturally limited going out, and very little intra-DMZ traffic exists, something that is 10/100 is all that is necessary. Thanks, Matt -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- [This E-mail scanned for viruses by Declude Virus on the server aea8.k12.ia.us] --- [This E-mail scanned for viruses by Declude Virus on the server aea8.k12.ia.us] --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] OT: Switch to control bandwidth
Matt, This might be a little more than what you need, but we use a product called a NetEnforcer for bandwidth limiting at our shop. There are a lot of other monitoring and accounting features as well. You can find information about them at www.allot.com. This will allow you to rate limit based on IP address, MAC or host name. If you have any questions feel free to contact me off list. Justin Moose Information Technology Manager Sioux Valley Wireless -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: Thursday, February 10, 2005 12:31 PM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] OT: Switch to control bandwidth Ok, I'll break the ice :) I was wondering what people would recommend as far as a managed switch goes that I can use to either limit bandwidth or at least guarantee bandwidth going out to the router. It might even be nice to do this on a per-IP basis instead of a per-port basis, though that's not absolutely necessary. Since this is a Web hosting segment and our bandwidth is naturally limited going out, and very little intra-DMZ traffic exists, something that is 10/100 is all that is necessary. Thanks, Matt -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] OT: Switch to control bandwidth
Matt, I would recommend Cisco for this than again I seem to recommend Cisco for everything. You can get rate limiting in the EMI images of the 2950 series or the SMI images of the 3550 series. What type of other options do you need with this? Straight L2 or L3? Gig uplinks etc? Darrell Matt writes: Ok, I'll break the ice :) I was wondering what people would recommend as far as a managed switch goes that I can use to either limit bandwidth or at least guarantee bandwidth going out to the router. It might even be nice to do this on a per-IP basis instead of a per-port basis, though that's not absolutely necessary. Since this is a Web hosting segment and our bandwidth is naturally limited going out, and very little intra-DMZ traffic exists, something that is 10/100 is all that is necessary. Thanks, Matt -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. Check out http://www.invariantsystems.com for utilities for Declude And Imail. IMail/Declude Overflow Queue Monitoring, MRTG Integration, and Log Parsers. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
[Declude.JunkMail] OT: Switch to control bandwidth
Ok, I'll break the ice :) I was wondering what people would recommend as far as a managed switch goes that I can use to either limit bandwidth or at least guarantee bandwidth going out to the router. It might even be nice to do this on a per-IP basis instead of a per-port basis, though that's not absolutely necessary. Since this is a Web hosting segment and our bandwidth is naturally limited going out, and very little intra-DMZ traffic exists, something that is 10/100 is all that is necessary. Thanks, Matt -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.