Tip

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

Default Behavior¶

After the installation completes and TNSR boots for the first time, TNSR has an empty default configuration. This means that TNSR has no pre-configured interfaces, addresses, routing behavior, and so on.

The host OS defaults are set during installation, and depend on the base OS, CentOS 8. For example, host management interfaces may have been configured by the installer.

Default Accounts and Passwords¶

By default, the TNSR installation includes host OS accounts for root with interactive login disabled, and a tnsr account.

For ISO installations, the best practice is to create at least one additional initial administrator account during the installation process. That user is custom created by the person performing the installation, and thus is not a common default that can be listed here.

Warning

When installing TNSR from an ISO image, the installer allows the root account to be unlocked and assigned a password. The best practice, however, is to leave the root account locked and create at least one additional administrator account using the installer. These additional accounts may use sudo to elevate privileges. Any users added to the wheel group later may also use sudo to execute commands as root.

The default behavior of the tnsr account varies by platform:

ISO/Bare Metal:: The tnsr user is available with a default password of tnsr-default.
Appliances Shipped with TNSR Pre-installed:: The tnsr user is available with a default password of tnsr-default.
AWS:: The tnsr account is present but restricted to key-based authentication via SSH, using a key selected when launching the TNSR instance.
Azure:: The tnsr account is present but restricted to key-based authentication via SSH, using a key selected when launching the TNSR instance.

The password for the tnsr account can be reset by any other account with access to the shell and sudo. For example, the command shell sudo passwd tnsr run at a TNSR prompt will set and confirm a new password for the tnsr user. The same action may also be performed for the root account (shell sudo passwd root). As mentioned in the previous warning, it is best to leave interactive logins for root disabled.

Warning

Change default passwords, even randomized default passwords or passwords pre-configured when launching a cloud-based instance, after the first login. Do not leave default passwords active!

Note

User authentication is performed by the host OS. Though users may be created inside TNSR (User Management), these users are propagated to the host. To control what users may access, see NETCONF Access Control Model (NACM).

Default TNSR Permissions¶

Current versions of TNSR include a default set of NACM rules. These rules allow members of group admin to have unlimited access and sets the default policies to deny. By default this group includes the users tnsr and root.

See NETCONF Access Control Model (NACM) for more information on managing access to TNSR.

Default Allowed Traffic¶

For the default behavior of allowed traffic to and from TNSR, there are two separate areas to consider:

Traffic flowing through TNSR
Traffic for the host OS management interface

TNSR¶

There are no access lists (ACLs) in the default TNSR configuration. Thus, once TNSR is able to route traffic, all packets flow freely. See Access Lists for information on configuring access lists.

Host OS¶

The TNSR installation configures a default set of Netfilter rules for the host OS management interface. The following traffic is allowed to pass into and out of the host operating system interfaces:

ICMP / ICMP6
SSH (TCP/22)
HTTP (TCP/80)
HTTPS (TCP/443)
NTP (UDP/123, TCP/123)
SNMP (UDP/161)
UDP Traceroute (UDP ports 33434-33524 with TTL=1)

To manage host ACLs which can override this behavior, see Host ACLs.

Note

Previous versions of TNSR also included Netfilter rules granting access to services run by the dataplane (dynamic routing, IPsec, DNS, DHCP). These are no longer necessary as current versions of TNSR isolate the dataplane and host OS services using separate network namespaces. Access to dataplane services can be controlled using TNSR ACLs.

Default Namespaces¶

Networking Namespaces enable isolated networking environments for the host OS and TNSR.

Network-related services run in the dataplane namespace, these are available via interfaces and addresses controlled by TNSR:

BGP, OSPF, OSPF6, RIP (frr-dataplane)
IKE/IPsec (strongswan-dataplane)
Unbound DNS Resolver (unbound-dataplane)
IPv4 DHCP Server (kea-dhcp4)

Management-oriented services run in the host namespace by default. As such, these services are only accessible via interfaces controlled by the host itself. These services include:

Secure Shell (sshd)
RESTCONF API (nginx)
SNMP (snmpd)
NTP (ntpd)

Note

When upgrading TNSR from an older version without namespaces, enabled services will also be automatically activated in the dataplane namespace.

CLI commands can also support multiple namespaces, as described in Namespaces in TNSR CLI Commands. The ping and traceroute commands default to the dataplane namespace; The shell command defaults to the namespace from which the TNSR CLI was launched, which is typically the host namespace.

See Networking Namespaces for details on working with TNSR namespaces.

Default Services¶

The SSH server (sshd) in the host namespace is the only service active on TNSR installation by default.

Default Routing and VRF Behavior¶

The default VRF used by TNSR is named default and has a VRF ID of 0. The default VRF is special in that it has separate route table names for IPv4 (ipv4-VRF:0) and IPv6 (ipv6-VRF:0).

The default VRF is assumed when a VRF is not explicitly specified, for example on an interface with no VRF.