@derelict Thanks.

@vesalius no they do not. RHEL can always be rebuilt from the source code that rhel MUST provide per the GPL. When centos was borged by RHEL the writing was on the wall for Centos. The other rebuilds will continue because the rhel sources will always be available. https://etc-md.com/2020/12/09/the-end-of-centos-and-my-moving-to-bsd/

@robing They need to be a type of NIC that dpdk supports. It should basically work with vmxnet3. Not sure what the capabilities of vmware player are.

@schnitzel_itdept Can do you do a packet capture on server B to double check all advertisements are received correctly?

@capitanblack

Thanks for your interest.

TNSR provides a RESTCONF API. I'm not aware of anyone that has attempted to integrate or test the API against Openstack/Ansible, but if those tools can make RESTCONFI requests it should be possible for them to configure TNSR.

The TNSR API docs can be found here: https://docs.netgate.com/tnsr/en/latest/api/

Feel free to send more questions or update us on your progress!

Time to put a CAPTCHA on logins? I dislike those things but sometimes you do what you gotta do...

The pricing from here is $500 per year for the Business Pro plan. There is no minimum/maximum speed, it's flat rate. It's not a replacement product for pfSense so your network doesn't need to be 'big enough' to benefit from it, you may use it even for the smallest networks if you wanted.

@prx said in TNSR on AMD EPYC ROME:

16.26.1040

i think it was specific for that firmware revision but for the network card you mentioned :

tested platform
https://doc.dpdk.org/guides-20.02/rel_notes/release_20_02.html#tested-platforms
Mellanox® ConnectX®-5 Ex EN 100G MCX516A-CDAT (2x100G)
Host interface: PCI Express 4.0 x16
Device ID: 15b3:1019
Firmware version: 16.27.1000 and above

also,
That is the kind of speed I have when one of my side it's not set with Mtu 9000, double-check that on all your machine.
I found this tuning useful for Ubuntu https://fasterdata.es.net/host-tuning/linux/

Netgate provided an example on how to integrate Snort to create an IDS back in 2018, which needs an update as TNSR has continued to evolve. From a 2018 blog:

TNSR-IDS is written in the Go programming language, allowing it to be easily compiled for a large number of OS and architectures. Details, source code, and setup instructions (including TNSR, SNORT and ERSPAN) can be found at the TNSR-IDS Project GitHub Repository(https://github.com/Netgate/TNSR_IDS). A README file is included in the repository that provides a lot of detail about the process, as well as a TNSR-Snort setup file that gives detailed installation instructions.

I'd use that as a starting point, but there may well be some architectual or setting changes that need to be tweaked to get the spice flowing.

There was an issue with heap-size that will be corrected in version 20.10.1.

The upcoming 20.10 release has IPFIX NAT logging which will fill that need for most situations.

Using "BIOS" boot mode instead of "UEFI" seemed to solve the issue.
Thanks for the hints.
Stefano

Currently the only supported IPsec method is routed IPsec as described in the docs. Policy-based tunnels are something we are looking to add, but there is no ETA.

At the moment there isn't support for an IPv6 DHCP client on TNSR interfaces.

I had a chance to look at the data from Prometheus on TNSR and the nodes you'll be interested in to track load appear to be:

_sys_vector_rate _sys_vector_rate_per_worker

That's on 20.10 which will be out soon. I didn't have a 20.08 system with Prometheus handy to see if it had the same data.

@Derelict Thanks for reply.

Did you mean NPAR(NIC Partitioning)? Could you indicate the specific name of the feature which enables that one NIC presents to the OS as 4 NICs?

Or could you recommend some NICs from TNSR recommended NICs etc?

@Derelict
Ok, thank you for the feedback.
Will change the NIC's for now.

Yes, we are tracking that. It looks like there is a problem there.

@graphine thanks for reaching out. We don't have near-term plans for TNSR on ARM.

@NetFreak said in no bgp default ipv4-unicast:

4399

Thanks Joey, the original request is still on our backlog, no roadmap ETA at the moment though.

@sadekyo1712 - Thanks, look forward to your updates

use case I'm looking at is using tnsr for a ha perimeter firewall deployment (including destination nat port forwarding and outbound nat masquerading). so keeping the nat state table in sync between router instances definitely a concern. Can you use regular Linux Contrack to keep the tables in sync? on regular centos/ubuntu/etc you can use this: https://conntrack-tools.netfilter.org/manual.html.

@mski your type of vnic driver is just not compatible with it.

Check this out for more info:
https://docs.netgate.com/tnsr/en/latest/vrrp/compatibility.html

Afaik VMware is also capable of the intel e1000 vnic which uses the igb driver.

Joey

Had the same issue some month ago. In some cases it can be usefull to have IP space overlapping on multiple interfaces. For example if you have a routed /24 which is bound to a loopback interfaces to prevent l3 loops while only having a smaller subnet assigned to a different interface.

eg:

185.121.69.0/24 dev lo
185.121.69.0/26 dev eth0.502
...

However, the developer of TNSR are aware of this, I had a evaluation meeting longer ago where I explained this issue to them.

They are geared for two very (very) different markets and there isn't likely to be huge overlap between their intended customer bases.

I'm vastly oversimplifying it but the tl;dr version is that TNSR is focused on high performance routing and VPN transit, for example, where the architecture of pfSense can't keep up. While pfSense has more flexibility with packages and firewall-type features which don't necessarily require >10GBit/s performance.

@kiokoman Thanks for your curiosity :)

You can set asymmetric PSKs in tnsr too.