LAGG and VPNs
-
Unlikely unless you have and bridged NICs in pfSense.
Does the Draytek router use the same 4 links to the switch?
Does the LAGG come up correctly if only those links are connected between pfSense and the switch?
-
The router has 2 links to the switch (LAG) and there are 4 links from this switch to another but that is all working. Yes, the draytek router is using the same links.
Never seen the LAGG come up yet to the pfsense either with just those links or others.
Is it possible to let me know what the pfsense settings should be for a LAGG with VPNs and I can try and make the switch match, although there aren't that many options really on the draytek switch to get wrong to be fair.
-
@stevencavanagh said in LAGG and VPNs:
The switch has 4 connections associated with pfsense:-
The WAN link - igb0.101
The 2 LAG links - igb2 & igb3
Additional link for this laptop - igb1What are the 4 connections then? That looks like 4 NICs in pfSense that are connected to the switch no?
Any VPNs you might have setup wouldn't have any effect here this is a layer 2 or even 1 issue.
I assume you are able to see a link between pfSense and the switch if there isn't a lagg in play?
-
the first connection is from the pfsense to the modem (igb0.101)
the LAGG (2 connections igb2 & igb3) from pfsense to the switch
the last is igb1 which is a connection from the pfsense to the laptopYes, if the LAGG is removed and a single cable put direct to the switch from the pfsense (obviously different port from the LAGG) then I get a connection, although at 100MB not 1GB as it should! No idea why though.
For info - the pfsense box is a DELL PC (i5) with 2 twin port NICs, giving a total of 5 ports if you include the motherboard one.
-
Ah, Ok only two links to the switch. Hard to see how that could be a loop then. The fact it only links at 100M is not a great sign! Is it set to fixed speed in the switch maybe?
-
Nope, changed the patch cable, changed the port and forced it 1GB where it stopped working completely so put back to auto and it auto negotiates at 100M
-
Hmm, with igb NICs too. About the best supported hardware there is...
If you force them to 100M does it link?
-
To clarify, the 2 cables for the LAG show as 1G on the switch, it is the single cable to another port (when the LAG is disconnected) that defaults to 100M but it works.
-
Hmm, earlier you said the port LEDs on the links in the lagg are off when it's connected. I wouldn't expect any link speed to be shown in that situation.
Do you mean those links when not configured as a LAGG link at 1G?
If you only connect one link from the lagg does it still fail?
-
@stephenw10 said in LAGG and VPNs:
Hmm, earlier you said the port LEDs on the links in the lagg are off when it's connected. I wouldn't expect any link speed to be shown in that situation.
Do you mean those links when not configured as a LAGG link at 1G?
If you only connect one link from the lagg does it still fail?
yes, the port LEDs are off when the LAGG cables are connected
Not tried removing the LAGG from the switch to prove it to be the case as I can't afford to cock it up when I go back to the draytek router for work! However, all other ports are at 1G so I suspect they will
yes, 1 link still fails
-
Hmm, OK, if it still fails with only one link to the switch it can't be a loop, it must be a mismatch in the lagg protocol.
Strange though, I wouldn't expect it to show the links down just because LACP is failing. Does pfSense still show the NICs as linked?
-
You can try disabling strict mode:
sysctl net.link.lagg.lacp.default_strict_mode=0You can also try enabling LACP debugging but be warned it creates a LOT of logs!
sysctl net.link.lagg.lacp.debug=1 -
When I plug the LAGG cables in the status\dashboard links go to red after a few secs and then appear to try again after around 30 secs or so
-
@stephenw10 said in LAGG and VPNs:
You can try disabling strict mode:
sysctl net.link.lagg.lacp.default_strict_mode=0You can also try enabling LACP debugging but be warned it creates a LOT of logs!
sysctl net.link.lagg.lacp.debug=1I will give it a go
-
I haven't seen anything that wasn't using active mode LACP for a while but....
-
Hi,
Quick question.........for example
If I have LAN set up as 192.168.0.1 and its DHCP server obviously also set up on 192.168.0 (eg. 192.168.0.50 - 192.168.0.199 with the switch in question having a static ip address of 192.168.0.21 (not in dhcp range) then when I come to allocate a static ip for the LAG I cannot use 192.168.0.1/24, despite all the network IP addresses on the default VLAN being 192.168.0.XXX.
Consequently, do I set up the LAN interface as a different ip address such as 192.168.1.1 and then set up the LAG as 192.168.0.1/24 to match the same range as the 2 managed switches namely 192.168.0.21 / 22 as I assume once the LAG is set up I won't need the LAN interface??
Hope it makes sense!
-
Yes, you can't have two interfaces in the same subnet so if you have lagg0 assigned an interface other than LAN it cannot use the LAN subnet.
So what I would normally do here is reassign LAN from igb1 to lagg0. To do that you need to be connected to the firewall via some other interface though since you would lose connection on igb1.
-
ok, so LAN is currently set to 192.168.2.1 and LAGG 192.168.0.1.
I am currently going through to pfsense via 192.168.2.1
so i have set up another interface 192.168.5.1 on port em0 but this seems to just go via 192.168.0.1 anyway, so if I change LAN to lagg0 I may end up locking myself out if the lagg is not working, if em0 fails but I will give it a go.
Looking at the LAG currently there is no activity on the ports and looking at the switch mimic (on draytek console) it isn't detecting anything plugged into the ports in question but there is!
The lagg was showing up a minute ago but now down in status and nothing changed. The log show the link coming up and then down again!
-
I have now assigned LAN to lagg0 and it has the right ip address of 192.168.0.1 but the link is obviously down due to the LAG not working
-
looking at the log i get:-
Aug 25 21:31:30 check_reload_status 420 Reloading filter
Aug 25 21:31:30 check_reload_status 420 Linkup starting igb2
Aug 25 21:31:30 kernel igb2: link state changed to DOWN
Aug 25 21:31:30 check_reload_status 420 Reloading filter
Aug 25 21:31:30 check_reload_status 420 Linkup starting igb3
Aug 25 21:31:30 kernel igb3: link state changed to DOWNSo it looks as though pfsense is starting the LAGG but it is shutting down straight away, presumably because the interfaces do not match somehow!
