Tip

This is the documentation for the 19.12 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 7.7. 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

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)

  • OSPF (Protocol 89)

  • RIP (UDP/520)

  • 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)

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