If you have virtualized pfsense inside xcp-ng – I take it the process would be different?
Hi, Tom.
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:
1 Like
Thanks @reymond070605 and I will double check, but I thin the model I have does not have those menus. And @kevdog I have never tried it in virtual pfsense.
@LTS_Tom
Willing to try a few things but just wanting to think your opinion of a reasonable starting point –
Option #1
- Create LAG interface within xcp-ng and then pass this as an interface to pfsense (similar to VLAN workaround)
Option #2
- 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?
1 Like