service dataplane restart restarts the VPP daemon and will definitely affect service.

While that daemon is restarting, no traffic can pass.

Thankfully it usually restarts very quickly so the disruption would be minimal, but still best to do in a brief maintenance window.

@mleighton Thank you, yes I know there is lots of factors, I just wanted to know that IPSEC for a fact is awesome on the TNSR platform.

I am looking forward to get started working with it :) and will update here when we something working with Prisma

Thanks
Felix

when i rebooted tnsr interface looking down on show interface command

@johnpoz Actually quite a few of the proprietary VM's I run in my Lab depend on hairpin NAT to function correctly.
Cisco Expressways - Poly DMA Edge - Audiocodes & Ribbon Session border controllers.
Lack of hairpinning can be worked around but takes more effort :)
Split DNS I agree is easier for domain name look up but some of the advance SIP signaling I use routes back in through the wan IP address.

TNSR is a high-performance software router. If you have a need for 10, 40, 100+ Gbps then TNSR may be the solution for you.

This overview video may help as well. You can see a list of features of TNSR here.

Against other options out there, we feel the price for performance can't be beaten.

@jimp said in Introducing the Netgate 6100 Max with TNSR:

The page is listing the different platforms on which TNSR is available, that sentence doesn't have any bearing on installation media.

There aren't different TNSR software installer images for different bare metal hardware variations like there are for pfSense. Currently the TNSR installation process for hardware only requires a single ISO and that ISO supports everything.

Thanks for clearing this up. :)

@nbhatti As has been said, we don't know. For what you are describing to happen there would need to be practically zero traffic passing, to both BGP peers, at the same time, for long enough to trigger the hold timer expiration. It doesn't sound like that is the case from what you have stated. Some occasional packet loss will not cause two TCP sessions to stop passing traffic at the same time and not recover.

I would packet capture the BGP sessions to the peers (TCP port 179) and try to capture the event. Then load it up into wireshark and see what happened to the session(s).

This would best be done at from place in the topography like a switch mirror port mirroring the traffic of the port connected to the tnsr node.

It is even more odd now. I have it working the only thing I needed to change was the number of CPU assigned. The VM is using 4 threads so I did "dataplane cpu main-core 3" and this prevents the crashing when I reboot after the NAT rule.

I still have this message after a reboot in the log though:
Jun 18 07:11:40 tnsrrouter vpp[1044]: /usr/bin/vpp[1044]: perfmon: skipping source 'intel-uncore' - intel_uncore_init: no uncore units found
Jun 18 07:11:40 tnsrrouter vpp[1044]: /usr/bin/vpp[1044]: perfmon: skipping source 'intel-core' - intel_core_init: not a IA-32 CPU
Jun 18 07:11:40 tnsrrouter /usr/bin/vpp[1044]: perfmon: skipping source 'intel-uncore' - intel_uncore_init: no uncore units found
Jun 18 07:11:40 tnsrrouter /usr/bin/vpp[1044]: perfmon: skipping source 'intel-core' - intel_core_init: not a IA-32 CPU

@sheebz
tnsr is needed for speeds >= 10GBe

@oudenos check private message