Sanity check network traffic

[ritsovih]

Just wondering whether the below stats are normal (ballpark range). Our environment is about 120 workstations (50 use WAN connections), we haven't had any large scale deployments (netboot or localboot) in the past 12 days. I'm particularly puzzled by the amount of RX bytes (250 GB), it seems unusually high, but I wanted to ask for some feedback here first before I submit a support ticket.

root@opsi:/home/opsiproducts/# ifconfig
eth0 Link encap:Ethernet HWaddr 52:54:007b:b1
inet addr:192.168.102.55 Bcast:192.168.103.255 Mask:255.255.252.0
inet6 addr: fe80::5054:ff:fede:7bb1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:174354506 errors:0 dropped:542755 overruns:0 frame:0
TX packets:109611784 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:264897166570 (246.7 GiB) TX bytes:408175030452 (380.1 GiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:16598 errors:0 dropped:0 overruns:0 frame:0
TX packets:16598 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2674808 (2.5 MiB) TX bytes:2674808 (2.5 MiB)

root@opsi:/home/opsiproducts/# uptime
15:48:06 up 12 days, 4:29, 3 users, load average: 0.58, 0.61, 0.62

[uncle_scrooge]

Difficult to tell from the distance what should be normal for your specific environment.
If it were me I would give tcpdump a try. Fire it up with tcpdump -s 64 -w dump.pcap. (-s limits the captured packet size. 64 Bytes should be sufficient, as we only need the header information.) And let it run for a couple of hours or a day.
Feed Wireshark with the file and you can check with Statistics\Conversations who's talking with your server. And with what amount of data.

Edith said:
IPTraf might come in handy, too. Will give you kind of a 'live' view of who's talking.

[ritsovih]

I guess I should've phrased it differently. I'm interested in what numbers other people have (i.e. RX/TX numbers, uptime, how many opsi clients "served", how many localboot/netboot performed). Ballpark only of course. Reason I ask is because I never monitored traffic before, yes I know so I'm looking for some comparison material, just to get a rough idea.

I was monitoring traffic on and off with iftop, and the sort of traffic I see was/is normal, as far as I can tell. On the RX side I see stuff going mostly to port 4447, some traffic going to port 1900 (SSDP traffic from Windows clients probably). It's the receiving side that puzzles me, since apparently 20 GB of data is being received per day!! If I'd seen those numbers on the TX side I wouldn't have been surprised as we deploy software and are also just started netboot Win installs to abt. 40 new PCs.

On the TX side I mainly see traffic coming from 4447 if there are no deployments, otherwise also port 445 (cifs) obviously.

[uncle_scrooge]

Sorry, then I can't be of any further help.
We only use OPSI with our servers. And they are obviously not that talkative.
But for the sake of completeness: 150 servers, 750MB RX, 180MB RX, uptime 19 days. No software deployment, no OS installs during that time.

Your number of clients would be interesting.

(And thanks for ballpark. My vocab grows.)

[ritsovih]

We have about active 140 workstations at the moment, of those some 50 are a also WAN clients. I've been busy with uploading capture images and other smaller files (MSI installers ertc.) in the past weeks, nowhere near at a rate of 20 GB per day though. I'll see if I can get bandwidth graphing going in nagios first and start monitoring for a longer time to try and get a clearer picture. Thanks for your input.

[n.wenselowski]

Hi,

We have about active 140 workstations at the moment, of those some 50 are a also WAN clients.

you could check if the high amount of traffic may be triggered through WAN clients that have their connectivity (re-)established very often. This could lead to a lot of requests.
In such a case tweaking the used WQL query is usually the way to go.


Kind regards

Niko