Seems like this OT thread becomes OT another time :-) The initial question was not whats the best way to measure line usage but if incomming spam can create so much traffic that it comes to a noticeable reduction.
In my opinion spam alone shouldn't create such a big reduction, because one single mail with a larger attachment is creating the same or also much more traffic. To understand if this connection is "overloaded" good old ping and traceroute should be enough. To find an answer what's causing most traffic Glenn can temporaly disable/block certain traffic by stopping the smtp-service or closing http, ftp or all other ports on the firewall. Another way is to connect a separate computer near to the router (using a hub and not a switch) install a packet sniffing software and watch whats going on the internal port of the router. Maybe one nice guy from the 70/80 users has installed P2P software or has running a backdoor infected computer (worm's can come in also trough kazaa, irc and similar client applications) Markus > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rod Dorman > Sent: Thursday, December 02, 2004 9:51 PM > To: [EMAIL PROTECTED] > Subject: Re: [IMail Forum] Somewhat OT, Spam and Bandwidth > > On Thursday, December 2, 2004, 14:04:38, Len Conrad wrote: > >>Umm... perhaps I'm missing something but I don't > see how one > >>can determine "exactly how the WAN link is performing" from > >>pinging and tracerouteing. > > > > easy. Congestion, steady state or transient, is shown by the > > millisecond delay from mtr along the route to each hop. > > But the only item of interest for "how the WAN link is > performing" is the hop from your router to your ISPs. > Ping/traceroute can only measure one protocol at a time. Its > also subject to any rate limiting and other QoS limitations > in effect at your or your ISPs router. > > > Sure, but not everybody who runs Imail has admin access to > the local > > router or Cisco command skills. > > True but everybody should be able to look at an MRTG graph > and see the pretty coloured lines go up and down. > > > I'd be very surprised if the conclusions about the health > of a route > > from mtr stats and cisco stats would be totally different. I would > > expect them to be identical, with mtr being much more > accessible than cisco commands. > > But it doesn't give many hints as to why the WAN link is > performing badly. If I see a high transmit or receive load > that gives me different information than seeing a high number > of CRC errors or overruns. > > > mtr shows packet counts and losses per node, ping > round-trip-time as > > min/avg/max per node. A quick and dirty and easy go/nogo tool. > > I'm not knocking it from that point of view, I'm all for > quick, dirty and easy :-) > > I was just objecting to your "exactly how the WAN link is > performing" > phrase. > > Having MRTG in place also gives history so when someone says > "I came in on Saturday and response time was terrible" you > can see if there was a utilization spike at some point. > > Glancing at the graphs can also give an indication of > increasing bandwidth needs so you've got time to start > budgeting for an upgrade. > > -- > [EMAIL PROTECTED] "The avalanche has already started, it is too > Rod Dorman late for the pebbles to vote." ? > Ambassador Kosh > > > To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html > List Archive: > http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ > Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/ > > To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
