Tip

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

orphan:

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 7.4. 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:: Login for the tnsr user is disabled until its password is reset by an administrator.
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 sudo. For example, the command sudo passwd tnsr will prompt to set and confirm a new password for the tnsr user. The same action may also be performed for the root account (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¶

By default, there is no TNSR configuration present. As such, there are no pre-configured access permissions for users to restrict access to TNSR. Thus, any operating system user on the TNSR host will be able to reach the TNSR CLI and make changes.

To restrict which accounts have access to TNSR, see NETCONF Access Control Model (NACM).

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¶

By default, there is no TNSR configuration present. As such, there are no default access lists (ACLs) and 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)
BGP (TCP/179)
ISAKMP (UDP/500)
NTP (UDP/123, TCP/123)
DNS (UDP/53, TCP/53)
SNMP (UDP/161)
DHCP Server (UDP/67)
UDP Traceroute (UDP ports 33434-33524 with TTL=1)

Future versions of TNSR will include the ability to manage the host OS Netfilter rules.