If you have virtualized pfsense inside xcp-ng – I take it the process would be different?
As mention over youtube. I have EdgeSwitch Lite 24-port switch. I have setup LAGG with Trunking going to pfsense.
The reason I have did this so I could have more lanes of traffic for all my vlans and also not saturating a single port for a vlan which will have a lot of traffic and the reason of every enthusiast because I can (lols). Here is my config for setting up LAGG.
A. Old interface
Using the legacy UI, went to Switching tab -> Port Channel -> Summary
Selected a port channel port and then click edit
In the Edit Port Channel selected a target physical interfaces and placed it in the Members column and then hit submit
B. New interface
On the new interface select on the right of the target port it should show LAG in gray click it:
When you click it will now show or ask which LAGG number you want to associate the port to:
Willing to try a few things but just wanting to think your opinion of a reasonable starting point –
- Create LAG interface within xcp-ng and then pass this as an interface to pfsense (similar to VLAN workaround)
- Pass two network interfaces directly to pfsense and then create LAG within pfsense??? Would hypervisor need to know about LAG/LACP?
Never did it, try both as I am not sure if it will work at all.
Regarding option 1, this is a popular design when using LACP. Your virtual pfSense will have vNICs and those connect to a vSwitch. That vSwitch will have the physical ports assigned to it and is a similar setup as if you had physical switches. If you went with option 2, the hypervisor shouldn’t need any configuration for LACP.
@LTS_Tom, great video! Anyone looking to set this up could easily do it following your instructions.
There is one thing I would point out on how LACP works when adding or removing ports. Every time there is a topology change LACP runs an algorithm to determine what traffic will flow over what connection. So when you added the connection back, that traffic flow could easily see a delay even if the traffic will continue to flow down the same path prior to adding the connection back. My point is that 100% of traffic will likely see a delay.
The other thing I wanted to point out is that most switches will need their LAG configured as a trunk in order to pass other VLANs across it. I’m surprised the Unifi doesn’t need this, but I don’t own one so I can’t test it.
Again, great video and good job setting expectations on expected throughput!
Yes that’s the case for my Netgear switches, which kinda makes sense when connecting switches.
I thought with unifi by default – all ports were trunk ports — or specifically untagged VLAN 1 and tagged everything else. Perhaps this is the reason unifi doesn’t need this configuation?