Unable to set Media / Mediaopt for LAGG Members
xwni last edited by
When pfSense (2.2 & 2.2.1-dev) configures a LAGG interface, neither the webui or the underlying mechanism seem to have any facility to apply settings such as media / duplex on the underlying member interface.
I think i have a partial workaround below but am missing some information, such as how to reapply the carp/vips to the interface.
Also, in general I think this should be considered a bug since it is not possile to specify media information for the member interfaces of a lagg. Maybe those settings shoudl go into the webui under the <lagg0>edit page.
Am I missing something? Should I go about implementing my workaround differently?
Could the lack of media options for a lagg interface be considered and as a bug/new feature request?
- My Situation *
In my case, my underlying interfaces are solarflare, sfxge interfaces which I want to have runing at 1000baseSX.
The config option in the webui at <interfaces>-> NAME -> Speed and Duplex -> Advanced , will only show as 'autodetect' if the interface 'NAME' is supplied by a virtual interface such as lagg0.
Unfortunately in my case, autodetect with the sfxge seems to assume a 10GbaseSX link and obviously fails to bring the nic up because I'm using 1GE equipment.
So I need a way to tell pfSense when it is configuring the lagg, to set media as 1000baseSX on the underlying member interfaces.
- partial workaround *
I can force this with shellcmd in the config file, but doing so in this way messes with other settings, removing configuration such as carp and virtual ip's.
<shellcmd>ifconfig lagg0 destroy</shellcmd> <shellcmd>ifconfig sfxge0 media 1000baseSX mediaopt full-duplex</shellcmd> <shellcmd>ifconfig sfxge1 media 1000baseSX mediaopt full-duplex</shellcmd> <shellcmd>ifconfig lagg0 create</shellcmd> <shellcmd>ifconfig lagg0 laggproto lacp laggport sfxge0 laggport sfxge1 up</shellcmd> <shellcmd>ifconfig lagg0 192.168.8.7 netmask 255.255.255.0</shellcmd>
This workaround is incomplete however as I need to add a command replace/regenerate the carp/vip configuration, and anything else i have upset when i did the lagg0 destroy.
doktornotor Banned last edited by
Well, you should never ever need to hardcode any of this for Gbit+ interfaces. Suggestion? Fix your broken HW instead.
xwni last edited by
Yeah, I guess. I understand your approach.
Clearly the hardware should be able to detect, and report that it's only working within a 1G infrastructure.
However in this case I'm stuck with what hardware i've got. I guess if it comes to it, I'll have to change the software.. Either hack a workaround into pfSense or more likely do something manually with a base operating system.
Even if I was flexible on hardware, I might still have good reasons to want to run the interface at a particular speed/duplex, depending on my requirement at the time. Auto detect is not always the right answer.
… So I still think this as should be seen as a fault - If pfSense is prepared to offer speed/media opt on a base network interface, then it should be smart enough to realise.. that when it is dealing with a lagg virtual if, then it should drill down to the underlying media and offer a speed/duplex combination that is common to all interfaces
- I'm thinking for this purpose the cable medium doesn't need to be relevant - for example, baseT, and baseSX ; these could go together as member interfaces, so long as both are set to the same duplex and speed rating.