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

@jimp I did previously try ip link set eno1 down on the host and then restarted tnsr as well as tried rebooting and neither brought the interface back into the dataplane. Luckily it is an interface that I am not currently using.

@network-admin link aggregation always needs to be configured on both sides of a link. Glad you got it sorted out.

@network-admin outer-dot1q and dot1q are synonyms. The fact that show config run cli shows outer-dot1q is not an error.

@network-admin Awesome. Glad to hear that's working. Have a great day.

@helmlein There are currently no hooks to change the syslog destination behavior. Any changes would need to be made to the CentOS host OS.

@derelict
clean install
zero to ping to cli crash
Immagine.jpg

@vesalius Posted a reply to this in another thread. We hope to have a blog out soon addressing this.

@Derelict
done.
this time got an email.
thanks

@MatthaeusHarris

All existing MIBs are net-snmp core. There is no defined MIB for Netgate or VPP specific OIDs.

Were you looking to do something specific that the core MIBs do not provide?

That makes a lot of sense. A system, or person for that matter, waiting to be told to work will never be as responsive as one that is at the ready to pounce.

Thank you Dennis your reply is very helpful.

I do look forward to seeing the new trial model for TNSR I'm very excited about that!

Hi Shem,

Thanks for bringing this to our attention. As we have been discussing over email, we have reproduced the issue and working on it.

Emre