I could not be happier to report that IS-IS has been available in our last couple of releases. My favorite routing protocol ever!

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

@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.

Posting the solution here for anyone that runs into similar issues... The problem turned out to be hardware-related. The Chelsio SFP+ NIC was identified to be the reason behind the TX drops, and after working with Netgate TAC confirmed the best course of action was to use a different NIC. There are an number of alternatives available out there, however we chose the Intel X710 offering from Netgate to ensure compatibility with the XG1541. Once the cards were swapped out, we ran the same test and confirmed the TX errors were no longer present. As of this writing we also successfully deployed TNSR at our event for the first time using the new NICs, and it performed beautifully. One thing important to note: After getting everything configured we needed to support our event (VRRP, NAT, bonded interfaces, routing, etc.) things generally behaved as expected (i.e. connectivity existed). When observing the arp table on switches that each router connected to however, every couple of seconds the VRRP MAC address flapped between the primary and secondary routers. Per Netgate documentation this was apparently related to the Intel X710 NICs, which we resolved by adding "devargs disable_source_pruning=1" to the configuration that brings physical interfaces into the dataplane from the host OS. (Reference https://docs.netgate.com/tnsr/en/latest/advanced/dataplane-dpdk.html for documentation)