[ILUG] SSH bandwidth usage.
Kieran.Tully AT acm.org
kieran.tully at gmail.com
Wed Mar 30 17:21:39 IST 2005
On Wed, 30 Mar 2005 16:51:25 +0100, Colm MacCarthaigh <colm at stdlib.net> wrote:
> On Wed, Mar 30, 2005 at 04:43:26PM +0100, Kieran.Tully AT acm.org wrote:
>> A conscientious network user would install a sniffer to measure how
much of the
> > network traffic they were responsible for. Of course you'd need more than one
> > to get a fully representative picture of the network usage.
> sniffers arn't terribly useful for gauging how much traffic you're
> generating. Interface counters are a more reliable, and far easier tool
If it was me I'd look of what proportion of the total traffic I was
rather than local interface totals. Though admittedly your sniffer
would have to be
well-placed to tell you anything useful in a switched network (barring
/ARP poisoning etc.).
> Depending on the quality of the NAT device, the actual recourse the
> resource utilisation can be tiny, but it is there and can add to what
> the network administrators have to manage. To facilitate the SSH
> connections they might have to lengthen the timeout period on that state
> for example - which definitely will increase the ammount of memory they
> need and so on. (Or of course they can just tell you to use keepalives).
Speaking of which, I have a persistent ssh connection setup to a
remote server, which
stays up indefinitely. When I initiate the connection from a different
local server, it times
out. Both servers run Linux and OpenSSH. The same firewall is in the
middle in both
cases, but I don't want to fiddle with it.
Apart from the TCP keepalive settings and the ssh socket and
application level keepalives (various handled in /proc, sshd_config
and ssh_config) is there anything
else I should check for differences?
Not critical, so I haven't had a chance to do a detailed analysis.
But if anyone has any suggestions for the "obvious" thing I've
Kieran Tully, Software Developer and Tenor
Reply to Kieran.Tully AT acm.org
More information about the ILUG