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 oftnsr-default
.- Appliances Shipped with TNSR Pre-installed:
The
tnsr
user is available with a default password oftnsr-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.
See also
See Virtual Routing and Forwarding for more details.