Ethernet flow control, yes or no? NetGate pfSense seems to default to 'yes'
-
I've heard and read many times that one should in general avoid using ethernet flow control, and indeed all of my managed switches seem to default to 'off; for this. However I notice on my NetGate 6100 all of the interfaces, including the SFP+ ones, default to 'on'.
Anyone have any guidelines/thoughts on this? I don't think it is causing me any problems but I am just curious as to why it defaults to on.
-
Do you really need it? TCP already has flow control. Perhaps if you're sending A LOT of UDP?
The purpose of Ethernet flow control is to reduce lost frames due to congestion. However, IP is designed to allow for lost packets.
-
Flow control can be a debated topic for sure.. I believe it can be helpful or problematic depending on your network and the traffic flow. Do you have devices that are different in speed, like 100 and gig or gig and 10ge?
Normally you prob never notice if on or off, etc. I wouldn't go looking to change the setting on a switch port unless you were running into some issue related to it.
In a perfect world if sender is sending data too fast that would fill up the switch buffer, the switch would send a pause to say hey slow down once my buffer is full I am going to start dropping shit ;)
But with something like voip or something that could cause issue, where you wouldn't want that to happen and would rather use some qos to make sure voip continues on and you drop other traffic, etc.
To make the call on which is best, you would need to know the environment and details of the traffic flow, and even if your running into some issues where turning it off or on at the switch level could help, etc.
-
I have to wonder if there might be an issue with 2 levels of flow control. Seems to me that was an issue when using TCP for VPNs.
-
@JKnott There are multiple scenarios were it could be a bad thing or a good thing. Without full understanding of the type of traffic and amount of flow its hard to say, best to turn it off, or best to turn it on on the switch port.
Depending on the devices nic, you can also turn it off there, etc..
I don't recall ever touching it often to be honest. Not like we had any sort of standard config we would do that said hey turn it off when you setup a new switch.. Or validate its on, etc.
Personally whatever the switch defaults to, I really wouldn't mess with unless was running into some sort of issue where that could be related.
-
So the consensus is that 'it depends' or '2 competing types of flow control (ethernet and TCP) could be bad'.
As I said at the beginning, my managed switch defaults to having it turned off for all ports, while the NetGate 6100 defaults to having it on for all ports. Presumably if you connect a NetGate port that has flow control enabled to a switch port that has it disabled then there is essentially no flow control? or does the switch respect any pause/resume commands from the NetGate but not send any itself? Or...?
Anyway, since these are the default settings for both devices and everything seems to be working I guess I'll just leave well alone :-)
-
@ChrisJenk said in Ethernet flow control, yes or no? NetGate pfSense seems to default to 'yes':
seems to be working I guess I'll just leave well alone :-)
That would be my take on it ;) hehehe
-
Here's a Wikipedia article about it.
As a layer 2 function, pfSense won't pass it, so it will only affect your LAN or the WAN connection, but not indicate congestion from one to the other. I could see, perhaps, there might be a need on the WAN port, when connected to fibre as that can support a LOT pf bandwidth. As for switches, the condition it's supposed to protect against is called "funneling" where multiple ports can overload the switch buffers. I have also read that trying to fix that can introduce worse problems. As I mentioned, networks expect dropped packets and something like this might affect TCP flow control.
BTW, TCP flow control is an interesting topic in itself. The book "Computer Networks", by Andrew Tanenbaum and David Wetherall has a section on it. Many years ago, the Internet crashed because of flow control, before they knew it would be an issue.
-
Yup, usually you won't notice the difference. We have seen some situations where it is required though. Others where the throughput can be significantly increased by disabling it.
It's worth testing disabling it if you are not seeing the expected throughput and have local access to revert that change if required.Steve