Traffic Graphc statistics are backwards for LAN interface
-
Switching to absolute style does not do it for you?
-
It's correct in general. Download is out on LAN, upload is in. That pulls from the NIC's counters, so it'd only be backwards if the NIC's counters are backwards somehow.
What's your LAN? Just a regular interface, or VLAN, or lagg, or? What type of NIC? I'm not aware of any circumstance where things are backwards, but that might help track down something.
-
I got the same thing when doing a speedtest
88M "in" on the LAN interface
192.168.1.2 88.64M Bits/sec 5.65M Bits/secRRD graphs show LAN correctly
Intel i350-T2
-
Hm, checked several of our installs, all correct. Some lagg, some VLAN on lagg, some VLAN on igb NIC, some just igb NIC with no VLANs. All fine. These are all 2.2.3 but that shouldn't be relevant, that code hasn't changed in quite some time.
Check the output of:
netstat -bi igb0
Replacing igb0 with whatever your LAN NIC is. Pass some traffic, significantly more in one direction than the other, and re-run and compare. Guessing the ibytes/obytes are opposite?
-
@cmb:
Hm, checked several of our installs, all correct. Some lagg, some VLAN on lagg, some VLAN on igb NIC, some just igb NIC with no VLANs. All fine. These are all 2.2.3 but that shouldn't be relevant, that code hasn't changed in quite some time.
Check the output of:
netstat -bi igb0
Replacing igb0 with whatever your LAN NIC is. Pass some traffic, significantly more in one direction than the other, and re-run and compare. Guessing the ibytes/obytes are opposite?
It's just a plain old D-Link NIC assigned to LAN and an Intel assigned to WAN. Data seems correct everywhere else (like RRD), so this is just kind of a minor annoyance:
fxp0 = WAN
rl0 = LANfxp0: <intel 100="" 82801db="" (ich4)="" pro="" ve="" ethernet="">port 0xecc0-0xecff mem 0xfcfff000-0xfcffffff irq 11 at device 8.0 on pci1 miibus0: <mii bus="">on fxp0 rl0: <d-link 10="" dfe-690txd="" 100basetx="">port 0xe000-0xe0ff irq 11 at device 0.0 on cardbus0</d-link></mii></intel>
Before speedtest: Name Mtu Network Address Ipkts Ierrs Idrop Ibytes Opkts Oerrs Obytes Coll fxp0 1500 <link#1> 00:0b:db:9f:f4:25 48892172 0 0 3418772828 19928703 0 3956696969 0 rl0 1500 <link#6> 00:0d:88:1b:74:70 20518700 0 0 3899690950 39572398 0 2600191963 0 After speedtest: Name Mtu Network Address Ipkts Ierrs Idrop Ibytes Opkts Oerrs Obytes Coll fxp0 1500 <link#1> 00:0b:db:9f:f4:25 48909216 0 0 3438870948 19940169 0 3963044215 0 rl0 1500 <link#6> 00:0d:88:1b:74:70 20530578 0 0 3906303805 39588043 0 2620064664 0</link#6></link#1></link#6></link#1>
And a screenshot from Traffic Graph:
On the left hand side of the graph, it's correct. But on the right hand side where the columns live update, it's backwards.
-
Oh, I see what you mean there. Is that the case for the others as well, the actual graph is correct, but the display on the right side with the hosts is backwards?
The RRD data comes from pf's counters rather than netstat (where Status>Traffic Graph pulls), so even if the graph itself were wrong, the RRDs wouldn't likely show the same issue.
-
It has always been like that. The graph is with respect to the pfSense interface - so download traffic goes OUT LAN.
The table of clients is with respect to the client - download traffic is IN to the client.
It needs to be this way, because the clients in the table can also be systems out on the public internet (selecting to show "Remote" or "All"). And in that case it looks sensible that the table shows bandwidth out of some public IP and bandwidth in to some LAN client. -
It has always been like that. The graph is with respect to the pfSense interface - so download traffic goes OUT LAN.
The table of clients is with respect to the client - download traffic is IN to the client.
It needs to be this way, because the clients in the table can also be systems out on the public internet (selecting to show "Remote" or "All"). And in that case it looks sensible that the table shows bandwidth out of some public IP and bandwidth in to some LAN client.I can see what you're trying to say, but it's still the odd duck with respect to reporting direction. Lemme edit your quote and tell me if this makes more sense:
The table of clients is with respect to the pfsense box - download traffic is OUT to the client.
It needs to be this way, because the clients in the table can also be systems out on the public internet (selecting to show "Remote" or "All"). And in that case it looks sensible that the table shows bandwidth IN from some public IP and bandwidth OUT to some LAN client.Bolded is my edits. If this was the case, it would all match neatly with the rest of the graphs and statistics and rules on pfsense. As it stands right now, if you select WAN, it'll show (for example) 55M bit/sec IN (correct) and when you select LAN, it'll also show 55M bit/sec IN (incorrect).
-
@fyy:
Bolded is my edits. If this was the case, it would all match neatly with the rest of the graphs and statistics and rules on pfsense. As it stands right now, if you select WAN, it'll show (for example) 55M bit/sec IN (correct) and when you select LAN, it'll also show 55M bit/sec IN (incorrect).
You're strictly talking about the display on the right side though, correct?
The rate output there with the host IPs is backwards on LAN. The graph itself is correct.
-
@cmb:
@fyy:
Bolded is my edits. If this was the case, it would all match neatly with the rest of the graphs and statistics and rules on pfsense. As it stands right now, if you select WAN, it'll show (for example) 55M bit/sec IN (correct) and when you select LAN, it'll also show 55M bit/sec IN (incorrect).
You're strictly talking about the display on the right side though, correct?
The rate output there with the host IPs is backwards on LAN. The graph itself is correct.
Yes.
-
It has always been like that. The graph is with respect to the pfSense interface - so download traffic goes OUT LAN.
The table of clients is with respect to the client - download traffic is IN to the client.
It needs to be this way, because the clients in the table can also be systems out on the public internet (selecting to show "Remote" or "All"). And in that case it looks sensible that the table shows bandwidth out of some public IP and bandwidth in to some LAN client.The issue is the opposite. It's showing that "downloading" is "in" for the LAN, when relative to PFSense, it should be "out". I'm seeing 85Mb "in" on the WAN, and 85Mb "in" on the LAN. One should be "in" and the other should be "out".
-
In the table Bandwidth In and Bandwidth Out columns is the perspective of the system listed in the Host Name or IP column on the same row.
So 13.48 Mpbs Out on the pfSense LAN (shown in graph) is 12.4 M Bits/sec Bandwidth In on host 192.168.1.103 (shown in the chart).
And 284 Kbps In on the pfSense LAN (shown in the graph) is 165.81 K Bits/sec Bandidth Out on host 192.168.1.103 (shown in the chart).Is that not correct?
I know this confused me the first time I saw it too. But I think it is correct. Just have to understand the perspectives.
-
I was seeing something like this
WAN 85Mb in / 3Mb out
LAN 85Mb in / 3Mb outMade no sense to me.
-
Well, it's not happening right now…. Maybe I was sleep deprived. I'll check for it over this weekend and see if it happens again.
-
Got it. The graph is showing in/out correctly, but the side value is showing in/out relative to the client.
-
Correct. The bandwidth in/out shown in the table is of the interface listed in the same row.
-
If you really what to twist your brain. Figure this one out.

 -
I see where the confusion is coming in. The graph is relative to the interface but the table is relative to the host.
-
I see where the confusion is coming in. The graph is relative to the pfSense interface but the table is relative to the host interface.
Exactly.
-
If you really what to twist your brain. Figure this one out.
The graph has a "better" longer-term view of the total data in/out on the pfSense interface. The table of clients takes a shorter-term snapshot on each update. Thus the table is just a "rough idea" of what is going on. For clients that are doing something consistent across time it gives a good snapshot of the activity, for clients that do bursty things then it is hit and miss.
Also, anyone making further comments about In/Out please always say if you are talking about the graph or the table - it is very difficult to sort out who is commenting about what.