Tip

This is the documentation for the 19.02 version. Looking for the documentation of the latest version? Have a look here.

orphan:

Zero-to-Ping

This document is a crash course in getting TNSR up and running quickly after installation. The topics included here are covered in more detail throughout the remainder of the documentation.

First Login

When TNSR boots, it will present a login prompt on the console (video and serial). Login at this prompt using the administrator account created during the installation process.

Alternately, if the host OS management interface was configured in the installer, login using an SSH client connecting to that interface.

See also

Changing the Password

The password for administrator accounts was set during the installation process, but the default tnsr account should have its password reset before making other changes.

Once logged in as an administrator, change the password for the default tnsr account using sudo. This tnsr account can then be used to login and load the TNSR CLI automatically:

$ sudo passwd tnsr
Changing password for user tnsr.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
$

Warning

Use a strong password for this account as it will be able to make changes to the TNSR configuration, unless restricted by a custom NACM configuration.

Interface Configuration

There are two types of interfaces on a TNSR system: Host OS interfaces for managing the device and dataplane interfaces which are available for use by TNSR.

Host OS Management Interface

By default the installer will attempt to configure a host OS interface using DHCP. This is by far the easiest method of configuring an interface for management. That said, not every environment will have or want DHCP enabled on a management network. In these cases, the interface must be configured manually in CentOS. A manual, non-DHCP, configuration is also possible in the installer.

At a minimum, the host OS must have an interface address, subnet mask, and a default gateway configured. The default gateway is necessary so that the host OS may retrieve updates as that traffic does not flow through TNSR, but over the management interface. Additionally, other host traffic may flow through the management interface, such as the ping command from within the TNSR CLI.

If an interface was not configured for management in the installer, it will need to be manually changed back to host OS control and then configured for network access.

Consult CentOS 7.4 documentation for the specifics of network configuration for other environments.

Dataplane Interfaces

Interfaces not configured for host OS management control in the installer will be setup in such a way that they are available for use by the dataplane and thus TNSR.

Enter the TNSR CLI (Entering the TNSR CLI) and configure the network interfaces:

tnsr# configure
tnsr(config)# dataplane dpdk dev ?
0000:00:14.0           Ethernet controller: Intel Corporation Ethernet
  Connection I354 (rev 03)
0000:00:14.1           Ethernet controller: Intel Corporation Ethernet
  Connection I354 (rev 03)
0000:00:14.2           Ethernet controller: Intel Corporation Ethernet
  Connection I354 (rev 03)
0000:00:14.3           Ethernet controller: Intel Corporation Ethernet
  Connection I354 (rev 03)
0000:03:00.0           Ethernet controller: Intel Corporation I211 Gigabit
  Network Connection (rev 03)
0000:04:00.0           Ethernet controller: Intel Corporation I211 Gigabit
  Network Connection (rev 03) ( Active Interface enp4s0 )
tnsr(config)# dataplane dpdk dev 0000:00:14.1 network
tnsr(config)# dataplane dpdk dev 0000:00:14.2 network
tnsr(config)# service dataplane restart
tnsr(config)# exit

TNSR Interfaces

Next, the interfaces inside TNSR must be configured with addresses and routing.

WAN Interface

In this example, WAN will be set with a static IP address and configured as the outside NAT interface:

tnsr# configure terminal
tnsr(config)# interface GigabitEthernet0/14/1
tnsr(config-interface)# description Internet
tnsr(config-interface)# ip address 203.0.113.2/24
tnsr(config-interface)# enable
tnsr(config-interface)# ip nat outside
tnsr(config-interface)# exit
tnsr(config)# exit

LAN Interface

Next, configure an address for the internal network and set it as the inside NAT interface:

tnsr(config)# interface GigabitEthernet0/14/2
tnsr(config-interface)# ip address 172.16.1.1/24
tnsr(config-interface)# description Local
tnsr(config-interface)# ip nat inside
tnsr(config-interface)# enable
tnsr(config-interface)# exit

NAT

Configure TNSR to use the WAN interface address for NAT, and enable NAT forwarding:

tnsr(config)# nat pool interface GigabitEthernet0/14/2
tnsr(config)# nat global-options nat44 forwarding true
tnsr(config)#

DHCP Server

Setup a basic DHCP server on the LAN side to hand out addresses, also instruct clients to use TNSR as their gateway and DNS server.

tnsr(config)# dhcp4 server
tnsr(config-kea-dhcp4)# description LAN DHCP Server
tnsr(config-kea-dhcp4)# interface listen GigabitEthernet0/14/2
tnsr(config-kea-dhcp4)# subnet 172.16.1.0/24
tnsr(config-kea-subnet4)# pool 172.16.1.100-172.16.1.245
tnsr(config-kea-subnet4-pool)# exit
tnsr(config-kea-subnet4)# interface GigabitEthernet0/14/2
tnsr(config-kea-subnet4)# option domain-name-servers
tnsr(config-kea-subnet4-opt)# data 172.16.1.1
tnsr(config-kea-subnet4-opt)# exit
tnsr(config-kea-subnet4)# option routers
tnsr(config-kea-subnet4-opt)# data 172.16.1.1
tnsr(config-kea-subnet4-opt)# exit
tnsr(config-kea-dhcp4)# exit
tnsr(config)# dhcp4 enable

DNS Server

Configure TNSR to act as a DNS server for local clients, using upstream forwarding DNS servers of 8.8.8.8 and 8.8.4.4:

tnsr# configure
tnsr(config)# unbound server
tnsr(config-unbound)# interface 127.0.0.1
tnsr(config-unbound)# interface 172.16.1.1
tnsr(config-unbound)# access-control 172.16.1.0/24 allow
tnsr(config-unbound)# forward-zone .
tnsr(config-unbound-fwd-zone)# nameserver address 8.8.8.8
tnsr(config-unbound-fwd-zone)# nameserver address 8.8.4.4
tnsr(config-unbound-fwd-zone)# exit
tnsr(config-unbound)# exit
tnsr(config)# unbound enable

See also

Ping

From the Host

The TNSR CLI includes a ping utility which will send an ICMP echo request out.

tnsr# ping 203.0.113.1
PING 203.0.113.1 (203.0.113.1) 56(84) bytes of data.
64 bytes from 203.0.113.1: icmp_seq=1 ttl=64 time=0.680 ms
64 bytes from 203.0.113.1: icmp_seq=2 ttl=64 time=0.176 ms
64 bytes from 203.0.113.1: icmp_seq=3 ttl=64 time=0.505 ms
64 bytes from 203.0.113.1: icmp_seq=4 ttl=64 time=0.453 ms
64 bytes from 203.0.113.1: icmp_seq=5 ttl=64 time=0.420 ms
64 bytes from 203.0.113.1: icmp_seq=6 ttl=64 time=0.144 ms
64 bytes from 203.0.113.1: icmp_seq=7 ttl=64 time=0.428 ms
64 bytes from 203.0.113.1: icmp_seq=8 ttl=64 time=0.494 ms
64 bytes from 203.0.113.1: icmp_seq=9 ttl=64 time=0.163 ms
64 bytes from 203.0.113.1: icmp_seq=10 ttl=64 time=0.346 ms

--- 203.0.113.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9000ms
rtt min/avg/max/mdev = 0.144/0.380/0.680/0.167 ms

tnsr#

By default this will follow the host OS routing table, but by specifying a source address, it will use addresses from TNSR:

tnsr# ping 203.0.113.1 source 203.0.113.2
PING 203.0.113.1 (203.0.113.1) from 203.0.113.2 : 56(84) bytes of data.
64 bytes from 203.0.113.1: icmp_seq=1 ttl=64 time=0.700 ms
64 bytes from 203.0.113.1: icmp_seq=2 ttl=64 time=0.353 ms
64 bytes from 203.0.113.1: icmp_seq=3 ttl=64 time=0.590 ms
64 bytes from 203.0.113.1: icmp_seq=4 ttl=64 time=0.261 ms
64 bytes from 203.0.113.1: icmp_seq=5 ttl=64 time=0.395 ms
64 bytes from 203.0.113.1: icmp_seq=6 ttl=64 time=0.598 ms
64 bytes from 203.0.113.1: icmp_seq=7 ttl=64 time=0.490 ms
64 bytes from 203.0.113.1: icmp_seq=8 ttl=64 time=0.790 ms
64 bytes from 203.0.113.1: icmp_seq=9 ttl=64 time=0.155 ms
64 bytes from 203.0.113.1: icmp_seq=10 ttl=64 time=0.430 ms

--- 203.0.113.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9001ms
rtt min/avg/max/mdev = 0.155/0.476/0.790/0.187 ms

From LAN Client

At this stage a LAN client will be able to connect to the network (port or switch) connected to the LAN interface. It can pull an IP address and other configuration via DHCP, resolve domain names via DNS, and reach hosts beyond TNSR using it as a gateway.

A ping executed on a client will flow through TNSR and replies will return.