I would complete the form here and see about a trial:

https://www.tnsr.com/trials

tnsr could excel in that application.

And I agree. Data in flight is no longer private. Especially through a third party.

dataplane ip heap-size 4G
dataplane ip6 heap-size 2G

should be more than plenty.

@LeeR said in OSPF & OSPFv3 Roadmap:

Is OSPF & OSPFv3 on the roadmap? Any ETA?

The current plan is for both to be in the next release. OSPFv2 for sure. OSPFv3 is still under development.

Would it be safe to configure OSPF on FRR directly until is has been abstracted in the TNSR CLI? Or would the config get overwritten on a reload/reboot?

I wouldn't count on the config files being left alone. In theory since the current release doesn't touch ospfd.conf it may be OK, but if you make any changes in zebra.conf they would definitely be clobbered.

Indeed it was. Thought I could install via the non-trial ISO on top of the trial install. Was expecting it to wipe the partitions and start over but apparently did not. Did the package upgrade to 19.05 and the CLI took the command as expected.

Thank you @jimp . I'll just wait for a reaction :)

Hi @RobertG

Yes, in the current licensing model, you can use TNSR Business (up to 10Gbps of throughput) on a system with faster interface, but will only get 10Gbps of throughput.

In the future, there may be technical limitations in the product that cause TNSR Business to not initialize interfaces that are capable of exceeding 10Gbps throughput, so please be aware... We're interested in customer feedback on the best way to handle this, but have not yet landed on a final model for engineering reasons.

Hi @victorhooi,

I think I just replied to you on Reddit as well.

Advantage to TNSR in 100Mbps scenario.

The first thing that comes to mind is programmability. If you're using this in a home lab, that might not be a big deal, but in a DevOps or distributed environment, TNSR's API will help you automate. As you said, SaltStack, Ansible, and other frameworks are great ways to wrap policy or updates into code.

...no Web GUI at the moment.

That's true, but the reason we started with an API is so TNSR can be easily extended. That could mean a GUI in the future, but for right now we've worked with partners who use TNSR via the API to extend their own products. For example, Fidelis Networks uses TNSR to mirror traffic for inspection in AWS.

Will packages such as nTopNG be available for TNSR?

I don't know if that package specifically will be available, but extensibility was central to the design of TNSR. Here's an example of how TNSR can work with Snort: https://github.com/Netgate/TNSR_IDS

You can probably see how this architecture would be really beneficial once bandwidth exceeds a couple of Gbps. With TNSR+Snort, routing and traffic inspection won't end up competing for CPU resources so you can scale them independently.

If nothing else, grab a TNSR trial and run it your lab environment.