Re: [pfSense] Using LAGG interfaces with CARP to allow future router replacements

[Steve Yates]

Thanks for the assist/validation.  It is a bit awkward to set 
up because one can’t put an active NIC into a LAGG so there’s a bit of round 
robin to get igb0 into a LAGG and assigned to WAN again.  But it does work as 
long as one has a spare interface.  I think it’d be difficult if not impossible 
to configure remotely but we can config a replacement router and take it to the 
data center.

Once I did it here and could export the config, it was much 
easier to just edit the to-be-replaced router’s config file and paste in the 
LAGG section and update the interface names, and it gets set up all at once 
upon restore.

--

Steve Yates
ITS, Inc.

From: Adam Thompson [mailto:athom...@athompso.net]
Sent: Wednesday, November 29, 2017 3:03 PM
To: Steve Yates <st...@teamits.com>
Subject: RE: [pfSense] Using LAGG interfaces with CARP to allow future router 
replacements

Yeah, in theory that should work. I've never need to care *that* much about 
downtime, so haven't tested it.
-Adam
On November 29, 2017 1:42:29 PM CST, Steve Yates 
<st...@teamits.com<mailto:st...@teamits.com>> wrote:
OK thanks for the observations.  Fortunately the 4860 has a bunch of ports but 
dedicating one to a management port would seem to require 4 in our case, 
instead of 3.  My thought would be that in the future we could edit a saved 
config file to change interface names and just restore it to the new hardware, 
and have it sync states with the LAGGs.  Hopefully that’s not going to happen 
for many years, but…


--


Steve Yates
ITS, Inc.


From: Adam Thompson [mailto:athom...@athompso.net]
Sent: Tuesday, November 28, 2017 5:29 PM
To: pfSense Support and Discussion Mailing List 
<list@lists.pfsense.org<mailto:list@lists.pfsense.org>>; Steve Yates 
<st...@teamits.com<mailto:st...@teamits.com>>
Subject: Re: [pfSense] Using LAGG interfaces with CARP to allow future router 
replacements


Yes, there's downtime to set up LAGs. So this won't help avoid all downtime.
Since the SG-2440 just went EOL, I would expect the SG-4860 will also go EOL 
soon, perhaps next quarter (Q1’18).
There is a small performance hit. It's not large - certainly not large enough 
that I ever cared to measure it. Unless you are pinning the CPU regularly, I 
expect it would be undetectable.
There is a much bigger hit in complexity, since you still can't set up LAGs 
during initial setup, necessitating a dedicated mgmt interface to avoid certain 
types of "oops, oh shit" problems.
-Adam
On November 28, 2017 5:08:48 PM CST, Steve Yates 
<st...@teamits.com<mailto:st...@teamits.com>> wrote:

 We had two routers set up using CARP and unfortunately had some issues with 
them, and currently have a temporary router in place.  We will be replacing the 
temp router with a SG-4860 1U HA however that unfortunately has different 
interface names, so state sync won't work, and the cutover won't be transparent.

 I understand from 
https://doc.pfsense.org/index.php/Redundant_Firewalls_Upgrade_Guide#pfSense_2.2.x_and_pfsync
 that using LAGGs can work around this.  My question is, is it worth setting up 
LAGGs just to allow for future proofing to have the state sync working on 
disparate devices if we ever replace a router down the road?  Is there any sort 
of performance penalty or significant complexity?

 Note we have five CARP interfaces, IPv4 and IPv6 for WAN and LAN, and a LAN 
IPv4 on a second subnet.  So as a first run-through on LAGGs, it seems like we 
would need at least four LAGGs for the WAN and LAN interfaces (we can ignore 
the secondary LAN for this purpose)?  So we would set up four LAGG interfaces 
using Failover (?) with one interface each, and have WAN and LAN use those?

 Avoiding downtime would be really nice, but I don't think we can get around 
that at this point (for this router replacement) since LAGGs apparently can't 
be set on an interface that is in use already and thus there would be downtime 
to set up LAGGs on our temp router anyway.

--

Steve Yates
ITS, Inc.



pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Using LAGG interfaces with CARP to allow future router replacements

[Adam Thompson]

Yes, there's downtime to set up LAGs.  So this won't help avoid all downtime.
Since the SG-2440 just went EOL, I would expect the SG-4860 will also go EOL 
soon, perhaps next quarter (Q1’18).
There is a small performance hit.  It's not large - certainly not large enough 
that I ever cared to measure it.  Unless you are pinning the CPU regularly, I 
expect it would be undetectable.
There is a much bigger hit in complexity, since you still can't set up LAGs 
during initial setup, necessitating a dedicated mgmt interface to avoid certain 
types of "oops, oh shit" problems.
-Adam

On November 28, 2017 5:08:48 PM CST, Steve Yates  wrote:
>   We had two routers set up using CARP and unfortunately had some issues
>with them, and currently have a temporary router in place.  We will be
>replacing the temp router with a SG-4860 1U HA however that
>unfortunately has different interface names, so state sync won't work,
>and the cutover won't be transparent.
>
>   I understand from
>https://doc.pfsense.org/index.php/Redundant_Firewalls_Upgrade_Guide#pfSense_2.2.x_and_pfsync
>that using LAGGs can work around this.  My question is, is it worth
>setting up LAGGs just to allow for future proofing to have the state
>sync working on disparate devices if we ever replace a router down the
>road?  Is there any sort of performance penalty or significant
>complexity?
>
>   Note we have five CARP interfaces, IPv4 and IPv6 for WAN and LAN, and
>a LAN IPv4 on a second subnet.  So as a first run-through on LAGGs, it
>seems like we would need at least four LAGGs for the WAN and LAN
>interfaces (we can ignore the secondary LAN for this purpose)?  So we
>would set up four LAGG interfaces using Failover (?) with one interface
>each, and have WAN and LAN use those?
>
>   Avoiding downtime would be really nice, but I don't think we can get
>around that at this point (for this router replacement) since LAGGs
>apparently can't be set on an interface that is in use already and thus
>there would be downtime to set up LAGGs on our temp router anyway.
>
>--
>
>Steve Yates
>ITS, Inc.
>
>___
>pfSense mailing list
>https://lists.pfsense.org/mailman/listinfo/list
>Support the project with Gold! https://pfsense.org/gold

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold