Episode 02. Core Features
Hello. Welcome to the “Core Features” video in Netgate’s short-form video series about TNSR. In this video, we’ll cover the foundational software features of TNSR. Of course, the feature set is evolving rapidly, but having this ground level understanding will help viewers understand the scope of what TNSR is targeting - and in fairness, some of the things it is not slated to address.
First and foremost, TNSR is a high-performance software router ideally deployed at the WAN edge - either on premises or in the cloud. Now, most of our viewers are well familiar with router fundamentals, so we want to focus on the areas that usually come up in customer discussions.
The first questions are usually around supported routing protocols and IP address mapping. TNSR supports static routing, eBGP/iBPG, OSPF - version 2 and 3, ECMP, BFD with dynamic routing, RIPv1 and RIPv2.TNSR covers requisite IP address mapping capabilities including IPv4/IPv6 dual stack, Static ARP, and VRF-lite.
These days one can’t really have a discussion about IP address mapping without considering the underlying infrastructure - and here we are not talking about bandwidth. For networks expected to handle very large numbers of devices - think service provider, IoT or autonomous vehicles - IPv4 address space exhaustion is a big problem. But simply adding IPv6 is not the end game. Network engineers must also consider both route table size and convergence time. Fortunately, TNSR scales well beyond expensive TCAM-based hardware solutions for handling large route tables while delivering fast route convergence time.
Next, edge routing deployment topologies vary widely, so buyers will expect flexible VPN, interface, and tunneling capabilities. For VPNs, TNSR supports route-based IPsec - which is more flexible, more powerful and generally recommended over policy-based IPsec. Additionally, TNSR excels at high-performance IPsec with a broad set of standards-based transforms, as well as MD5 and SHA hash functions. For interfaces, TNSR supports VLAN encapsulation including 802.1q, QinQ, VXLAN, and Bridging. Finally, TNSR supports a number of port grouping and tunneling protocols - including LAG, GRE, and SPAN/ERSPAN
Let’s expand a bit. Routing is all about forwarding traffic under a set of specified conditions. There is another key responsibility of a WAN edge or border router - and that is to operate as an effective firewall - which has as its goal to deny specific traffic forwarding based on some set of policies. Firewalls obviously can be applied at any layer of the OSI stack. While TNSR is not a fully-fledged next generation firewall - as the industry likes to call them - it does provide the traffic controls necessary of any WAN edge router - including Layer 2, 3 and 4 ACLs, port forwards, and a suite of network address translation, aka NAT, capabilities. And TNSR goes well beyond basic NAT, and into the territory of large-scale NAT processing needs of both large enterprises and service providers.
Hopefully you can see TNSR has a strong WAN edge routing feature set. But what about the “-ilities”? It has to have high availability and modern manageability to be considered enterprise- or service-provider class.
On this front, we are usually asked about high availability. TNSR supports version 3 of the virtual router redundancy protocol, or VRRP. VRRP is designed to eliminate the single point of failure inherent in a static, default-routed environment - by using an election protocol that dynamically assigns responsibility for a virtual router to one of a pool of VRRP routers. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing, or router discovery protocols, on every end-host. TNSR also supports tracked interfaces, which allows the priority of a virtual router to be changed based on the state of another interface on the router.
With respect to manageability, most enterprises and xSPs today are moving away from strict human management of networks and more towards automated network management - and even more sophisticated “intent-based” networking. They are doing this to more dynamically align network needs with fast changing business demands, as well as to reduce the cost of labor-intensive, more error-prone human intervention. TNSR has both a RESTCONF API - for straightforward integration into either proprietary or open-source IT automation - and a command line interface for traditional install, configuration, and monitoring needs.
This is hardly a complete coverage of TNSR features. For that, it’s best to check tnsr.com - or speak to a sales representative. But hopefully it provides a good overview of where TNSR functionality is centered.
If you want to stay up-to-date on the latest TNSR content releases and news subscribe below.