ECS-Aggregation MC-LAG and CARP Multicast

Networking & Firewalls
1

We recently bought a pair of UniFi ECS-Aggregation switches to use as core switches with MC-LAG, now that 3.0.8 firmware (hopefully) addresses many of the stability issues of previous versions. We also use a pair of 1537 pfSense+ gateways set up in HA.

We have been testing the ECS-Aggregation switches at the edge of our network, but haven’t yet moved them to replace our core switches. We’re looking to MC-LAG each pfSense+ box to the new switches, but are concerned about how CARP will be handled by the switches. The current firmware does not pass multicast traffic across the peer link, which is what CARP/VRRP rely on by default. Would this cause issues with missed CARP heartbeats?

Does anyone else successfully use pfSense CARP with ECS-Aggregation switches or other vendor switches with MC-LAG?

Also, we’re using pfSense+, so would switching to unicast CARP help? Netgate’s CARP documentation warns:

However, use of unicast mode on traditional infrastructure where multicast is more suitable should be avoided. In unicast mode switches may flood packets for unicast CARP VIPs to all ports, leading to significant security and performance concerns.

Could someone please explain the practical security concerns caused by switching to unicast CARP?

And while we’re at it, there are some serious limitations with UniFi’s ECS-Aggregation switches that I don’t remember Tom’s video addressing:

  1. You can currently only define 26 MC-LAG target groups. If you’re like us and looking to set up MC-LAG groups of one port on each switch, you’ll only be able to use 26 ports. UniFi claims this may be addressed in a future fw release, and I can’t blame them for focusing on stability. UniFi only recently added this limitation as an asterisk next to MC-LAG on their store page. You’ll notice it missing in Tom’s video when he shows the store page.
  2. If you’ve set up MC-LAG, you’ll be unable to use normal port aggregation on any of the remaining ports. The option for normal aggregation is grayed out in port config. So you’ll now probably be left with 26 ports on each switch that can’t even be used for normal aggregation. This was a surprise and there is no mention of this limitation on the store page.

Thanks for any advice and sorry for the wall of text!

1 Like
2

I have not tested these with pfsense but that limitation leads me to believe it will not work with an HA setup.

3

I don’t understand why it matters. If both PF and ECS are HA, then each PF is connected to each ECS with MC-LAG. Won’t the PF heartbeats be seen already by both switches through their respective MC-LAG port connections without having to traverse the ECS peer link when using multicast? Granted, this stuff is over my head…. am I missing something?

And if one did use unicast, instead, why would that cause a performance problem? Isn’t that just a tiny bit of occasional data? Even if those went to all ports, how is that significant (or worse than using multicast) for modern/fast switches?