Traffic graph anaysis. HELP!
-
That's what I thought, but something is strange here.
I have attached an example of a traffic graph. It shows In-Traffic of approximately 8.7 Mbps on the WAN_IPTV interface. This is multicast traffic from an IPTV provider (one HD channel). The traffic is sent through the IPTV interface (VLAN) to be consumed by my TV-Receiver. The IPTV interface shows Out-Traffic of approximately 17.4 Mbps. This is twice the amount of what would be expected. I learned today that this is due to a known bug (https://redmine.pfsense.org/issues/3314) with VLANs.
What puzzles me however is the In-Traffic on the IPTV interface of approximately 8.6 Mbps. If this would really be "traffic arriving from the LAN clients" that would mean that some device in the IPTV VLAN duplicates all multicast frames and reflects back them to pfSense. This would be very unexpected and unusual.
Or it is related to the duplication of the traffic due to the known bug (see above), however I did not find any hint on this in the descriptions of the bug.
I rather suspect that the way the traffic is counted is somewhat strange in pfSense.
Can anybody explain this in more depth?
-flo-
 -
I have no idea, so I'm just tacking a jab at it.
If IPTV traffic is multi-cast or broadcast, maybe the switch is reflecting the data from the OUT back to the IN and PFSense is just re-routing it back to the out again causing a duplication of data? PFSense is definitely receiving data on the LAN interface equal to the amount it's meant to be sending.
Complete guess with little knowledge.
-
There is no multicast on ethernet. All multicast is actually broadcast in an ethernet.
Any frame sent through a switch port should never leave that port back to the sender. (Unless using special features of a switch like mirroring traffic for analysis purposes of course.) That's just not how ethernet works. Or am I completely mistaken here?
-
There is no multicast on ethernet. All multicast is actually broadcast in an ethernet.
Any frame sent through a switch port should never leave that port back to the sender. (Unless using special features of a switch like mirroring traffic for analysis purposes of course.) That's just not how ethernet works. Or am I completely mistaken here?
Multi-cast is a layer3 thing, so I'm unsure how it is implemented on Ethernet switches. I do want to say you're spot-on for all Layer 2 related things within a single switch.
I guess the next step is to do a wireshark and see what packets are coming in on the LAN interface. Check those source/destination MACs and IPs.
-
That's what I meant: There is no multicast on ethernet (layer 2), multicast is implemented via broadcast. Switches must propagate frames in the broadcast domain. Duplicating a frame back on a port from which it has been received should not happen. Imagine 2 switches with this behavior in a LAN …
So I cannot believe frames are reflected back by the switch. I'm pretty sure that the MediaReceiver is not duplicating back the traffic either.
So - sigh - it seems I should rule this out using Wireshark.
Let's find a free evening .. 8)
-
Multicast is neither broadcast or unicast. Ethernet switches need special support to handle multicast IP frames, i.e IGMP. If the switch does not support IGMP, it has to duplicate the frames across all ports. You might check to see if your switch supports IGMP snooping, otherwise duplicating frames is required.
-
Yes my switches do support IGMP (tested, working) and yes of course frames must be duplicated. But even so a switch must not send back a duplicated frame over the port from which it has been received. Otherwise if there were several switches in a broadcast domain they would be sending every single multicast frame back and forth between them until they hit the frame's TTL limit.
-
In and Out are relative to the interface.
On WAN, In is traffic arriving from the internet (downloads) and Out is traffic sent to the internet (uploads)
On LAN, In is traffic arriving from the LAN clients (mostly destined to the internet = uploads) and Out is traffic to the LAN clients (mostly from the internet = downloads)I am still struggling with this concept, Phil :-[
I would have thought:
LAN-pc -> LAN-interface -> WAN-interface -> internet, and vice versa.
So your LAN in fits in there, but LAN out I would have thought to be going to the WAN-interface (and from there on to the internet).
I am certain you are right and I am wrong, but my brain just refuses to understand that [b]LAN out is out to the LAN. I would have expected WAN out to go to the LAN (the 'vice versa' in the above: the traffic from the internet comes in on the WAN and goes out on the WAN to the LAN).
:o
-
As pfSense is a firewall you could think of it this way…
Draw a box with "Firewall" written in it. Write "Wan" at the top and write "Lan" at the bottom.
Draw an arrow pointing down to Wan, and another arrow pointing to up to Lan.
So the arrow "in" is "ingress". And out is "egress" for each interface.
So it's purpose is to protect on each interface.
-
I am certain you are right and I am wrong, but my brain just refuses to understand that LAN out is out to the LAN. I would have expected WAN out to go to the LAN (the 'vice versa' in the above: the traffic from the internet comes in on the WAN and goes out on the WAN to the LAN).
Maybe another way to think of it? Data arriving from the internet you are happy to call WAN In. Then what label/name will you give packets that are transmitted from the WAN to the internet (acknowledge packets, the Google search string you typed, the email you send, the text that you post here in the forum…). If the stuff coming from the internet is WAN In, then you are kind of forced to call the traffic in the opposite direction "WAN Out".
Once you have that convention, then packets arriving on LAN (=from LAN clients) become LAN In, and packets transmitted to LAN (clients) become LAN Out.
Then you just live with the convention, even if your brain struggles to cope sometimes :)
