@johnpoz I know I thought maybe he could be my study buddy for a while but never responded so I gave up .

There are plans for it, but we don't have a timeline to share at the moment. As tends to be the case, it's more involved than one might initially think.

@fractal_boy Sure but thats a bit legacy when it comes to datacenter design to be honest.
Having multiple VRRP groups isn't a modern design. VARP also wont have traffic run over the MLAG link but VRRP will.
Even thinking about multiple VRRP groups in my use case isn't scalable. I have over 100 SVIs in production and development environments. Its starts getting unwieldy

edit:
Looking at your drawing, forget end user or servers downstream. Pretend its a dual homed switch or server that has a LAG up to the MC-LAG. It can send frames to either spine. That alone would warrant VARP.

@binbinyoulee not at this moment, maybe in the future. What are your use cases for arm64?

@fractal_boy very nice. Exactly what I’m looking for

@boblovesbacon created an internal feature request to add this MIB. Ticket number #16743

@michmoor said in VRRP tracking:

How do i submit a feature request to have VRRP track the route instead of an interface?
Its not uncommon to have an uplink L3 nexthop not be directly connected so even if the interface goes down the nexthop is still accessible. Tracking route gives another way to influence VRRP master/router selection.
Juniper and Cisco offer this feature.

A feature request (#12423) has been opened on Netgate's internal tracker for this.

Thank you.

Yes, it is clear that the focus so far has been larger corporate and datacenter use cases. After all, using it on something as "low" as a 1 Gbit/s connection seems like a needlessly complicated setup when kernel based networking such as pfsense has no problem with those speeds on even low end hardware. However, the lack of end user IPv6 features is a bit more surprising since I would assume at least some of those would be useful in at least some corporate settings too.

Based on responses in other threads, they are at least working on PPPoE support. I have seen no statements about the IPv6 features being worked on however, so we'll just have to see. I'm sure it's somewhere on their TODO-list, but I'm not sure how far down.

@wbaja Interesting that RESTCONF crashed, I'll take a look into this. Feel free to send me a DM or email (my username at netgate.com) with more information, and I'll try to get it fixed

@raph Thanks for your feedback.

To clarify some of the questions you've raised here:

I will test this and create a bug report to see what can be done there. I, myself, am not certain what restrictions we can place in the Ubuntu installer regarding valid usernames, but if there is a way to prevent that from happening, we'll see what we can do.

SSH is only listening on the host interface. This interface should be on a trusted private network. Of course it is best practice to change the default password immediately, but there are very few reasons that this interface should be exposed to the internet at any time, let alone on first install and boot up. Of course, it is always an option to use a VM console, VGA, or serial connection to access the system prior to connecting it to the local network in order to change the password.

The Home+Lab evaluation ISO can be downloaded by placing a $0 order in the Netgate shop here: https://shop.netgate.com/products/tnsr-software-subscription

The upgrade documentation accounts for several scenarios that may be applicable to different TNSR users. For example, in-place upgrades of TNSR related packages are not applicable to Home+Lab users because a paid subscription is required, but the base operating system can be upgraded. Alternatively, some users may manage a single TNSR instance via the TNSR CLI, while others appreciate scripts to be executed via the REST API. Given the wide range of TNSR use-cases, various upgrade scenarios must be accounted for. While we always strive to keep the documentation as clear as possible, we appreciate your feedback and will look into whether there are any ways to improve. Please feel free to continue to provide any suggestions/feedback.

Thanks again for your input and for being a TNSR user. We are committed to making the TNSR experience as smooth as possible, and feedback like yours goes a long way towards that goal.

@matlear Hey thanks for your post I am thinking about using TNSR on a 6100 for a small branch office. 👍