The SR Linux device must have a host name configured. The default host name is srlinux. The host name normally appears on all CLI prompts on the device, although you can override this with the environment prompt CLI command.
The host name should be a unique name on the network, and can be a fully qualified domain name (FQDN), or an unqualified single-label name. If the host name is a single-label name (for example, srlinux), the system may use its domain name, if configured, to infer its own FQDN.
Example:
The following shows the configuration for a host name on the SR Linux device.
The SR Linux device uses its host name, combined with a domain name to form its fully qualified domain name (FQDN). It is expected that the FQDN exists within the DNS server(s) used by SR Linux, though this is not a requirement.
Assuming the SR Linux FQDN is in the DNS server, you can use the FQDN to reach the SR Linux device without knowing its management address. A domain name is not mandatory, but if specified, it is added to the DNS search list by default.
Example:
The following shows the configuration for a domain name on the SR Linux device. In this example, the device FQDN is set to 3-node_srlinux-A.mv.usa.nokia.com.
The SR Linux device uses DNS to resolve host names within the configuration, or for operational commands, such as ping. You can specify up to three DNS servers for the SR Linux device to use, with either IPv4 or IPv6 addressing.
You can also specify a search list of DNS suffixes that the device can use to resolve single-label names; for example, for a search list of nokia1.com and nokia2.com, a ping for host srlinux does a DNS lookup for srlinux.nokia1.com, and if unsuccessful, does a DNS lookup for srlinux.nokia2.com.
The SR Linux device supports configuration of static DNS entries. Static DNS entries allow resolution of host names that may not be in the DNS servers used by the SR Linux device. Using a static DNS entry, you can map multiple addresses (both IPv4 and IPv6) to one host name. The SR Linux linux_mgr application adds the static DNS entries to the /etc/hosts file in the underlying Linux OS.
Example:
In the following example, the SR Linux device is configured to use two DNS servers to resolve host names, a search list of DNS suffixes for resolving single-label names, and IPv4 and IPv6 static DNS entries for a host.
DNS requests are sourced from the mgmt network-instance (see Configuring the management network-instance).
Management of the SR Linux device is primarily done via a management network-instance. The management network-instance isolates management traffic from other network-instances configured on the device.
The out-of-band mgmt0 interface is automatically added to the management network-instance, and management services run within the management network-instance.
Although the management network-instance is primarily intended to handle management traffic, you can configure it in the same way as any other network-instance on the device, including protocols, policies, and filters. The management network instance is part of the default configuration, but may be deleted if necessary.
Addressing within the management network-instance is available via DHCP and static IP addresses. Both IPv4 and IPv6 addresses are supported.
Example:
Access to the SR Linux device is available via a number of APIs and protocols. The SR Linux supports the following ways to access the device:
Regardless of the method of access, all sessions are authenticated (if authentication is enabled), whether the session is entered via the console, SSH, or an API. Access to the device is controlled via the aaa_mgr application. See Securing access.
You can enable an SSH server for one or more network instances on the SR Linux device, so that users can log in to the CLI using an SSH client. The SR Linux device implements SSH via OpenSSH, and configures /etc/ssh/sshd_config in the underlying Linux OS. Only SSHv2 is supported.
Example:
In the following example, an SSH server is enabled in the mgmt and default network-instances, specifying the IP addresses where the device listens for SSH connections:
The SR Linux SSH server supports RSA public-private key-based authentication, where an SSH client provides a signed message that has been encrypted by a private key. If the SSH client’s corresponding public key is configured on the SR Linux, the SSH server can authenticate the client.
When performing authentication for a user, the SR Linux first tries public-key authentication; if this fails, the SR Linux tries password authentication.
To configure SSH key-based authentication, you generate a public-private key pair, then add the public key to the SR Linux.
The following is an example of using the ssh-keygen utility in Linux to generate an RSA key pair with a length of 2,048 bits:
After generating the RSA key pair, you can add the public key to the SR Linux. The location for the public key depends on the type of user for which SSH key-based authentication is being configured:
For example, the following CLI command configures a public key and password for the SR Linux user srlinux:
In the example, the <public-key> has the format ssh-rsa <key> <comment>. If multiple public keys are configured for a user, they are tried in the order they were configured.
You can enable an FTP server for one or more network instances on the SR Linux device, so that users can transfer files to and from the device. The SR Linux uses the vsftpd (very secure FTP daemon) application within the underlying Linux OS. The authenticated user’s home directory returned by the aaa_mgr application is set as the user’s FTP root directory.
Example:
In the following example, the FTP server is enabled in the mgmt and default network-instance, specifying the IP addresses where the device listens for FTP connections:
You can specify banner text that appears when a user connects to the SR Linux device. The following banners can be configured:
The banners appear regardless of the method used to connect to the SR Linux, so they are displayed to users connecting via SSH, console, and so on.
Example:
In the following example, login and motd banners are configured. The login banner text appears at the prompt when a user attempts to log in to the system, and the motd banner text appears after the user has been authenticated.
Network Time Protocol (NTP) is used to synchronize the system clock to a time reference. You can configure NTP settings on the SR Linux device using the CLl, and the SR Linux linux_mgr application provisions the settings in the underlying Linux OS.
NTP does not account for time zones, instead relying on the host to perform such computations. Time zones on the SR Linux device are based on the IANA tz database, which is implemented by the underlying Linux OS. You can specify the time zone of the SR Linux device using the CLI.
Example:
The following configuration enables the system NTP client on the SR Linux device and specifies an NTP server to use for clock synchronization. The NTP client runs in the mgmt network-instance. The system time zone is set to America/Los_Angeles.
The SR Linux device supports SNMPv2. To allow an SNMP client to read information about the system as an aid in monitoring the device, the SR Linux supports the OIDs listed in Supported SNMP OIDs. The MIB file that covers these OIDs is packaged with each release.
Example:
In the following example, an SNMP server is running within the mgmt and default network-instances, and the configuration specifies the IP addresses where the device listens for SNMP client connections:
The SR Linux supports the following OIDs. Details about each OID are listed in the linked sections.
The sysName OID is located within the SNMP MIB-2 subtree, specifically at 1.3.6.1.2.1.1.5. This is generally the device FQDN. The SR Linux device reads the sysName from the configured system host name.
If the host name does not contain a dot (.) character, the configured domain name is also read, and is appended to the host name before being returned to the client.
The sysObjectId is located within the SNMP MIB-2 subtree, specifically at 1.3.6.1.2.1.1.2. This identifies the kind of device being managed. SR Linux uses the subtree at 1.3.6.1.4.1.6527.
The sysContact OID is located within the SNMP MIB-2 subtree, specifically at 1.3.6.1.2.1.1.4. This identifies the contact person for this managed node, together with information on how to contact this person. SR Linux propagates the information configured for /system/information/contact for the sysContact OID.
The sysLocation OID is located within the SNMP MIB-2 subtree, specifically at 1.3.6.1.2.1.1.6. This identifies the physical location of the device. SR Linux propagates the information configured for /system/information/location for the sysLocation OID.
The sysDescr OID is located within the SNMP MIB-2 subtree, specifically at 1.3.6.1.2.1.1.1. This value can include the name and version for the system hardware, software operating system, and networking software. This must contain only printable ASCII characters.
The SR Linux uses a fixed sysDescr field, based on this template:
The ifIndex is located within the SNMP IF-MIB ifEntry subtree, specifically at 1.3.6.1.2.1.2.2.1.1. This is a unique value, greater than zero, for each interface. SR Linux propagates the /interface[]/ifindex leaf into the ifIndex OID. One ifEntry is created for each ifIndex found in the system. If an interface does not have an ifIndex, it is not populated into SNMP. An ifIndex is generated only for physical interfaces (excluding management).
The ifDescr OID is located within the SNMP IF-MIB ifEntry subtree, specifically at 1.3.6.1.2.1.2.2.1.2. This is a string containing information about the interface. This string can include the name of the manufacturer, product name, and version of the interface hardware/software. SR Linux propagates the /interface[]/description leaf into the ifDescr OID. If the description passed from /interface[]/description exceeds 255 characters, it is truncated.
The ifOperStatus OID is located within the SNMP IF-MIB ifEntry subtree, specifically at 1.3.6.1.2.1.2.2.1.8. This indicates the current operational state of the interface. SR Linux propagates the /interface[]/oper-state leaf into the ifOperStatus OID using the mapping shown in Table 3:
ifOperStatus OID value | ID | /interface[]/oper-state enum | /interface[]/oper-state value |
up | 1 | up | 1 |
down | 2 | down | 2 |
testing | 3 | ||
unknown | 4 | ||
dormant | 5 | ||
notPresent | 6 | empty | 3 |
lowerLayerDown | 7 | down | 2 |
The ifAdminStatus is located within the SNMP IF-MIB ifEntry subtree, specifically at 1.3.6.1.2.1.2.2.1.7. This is the desired state of the interface. The testing (3) state indicates that no operational packets can be passed. When a managed system initializes, all interfaces start with ifAdminStatus in the down (2) state. Based on either explicit management action or configuration information retained by the managed system, ifAdminStatus is then changed to either the up (1) or testing (3) states (or remains in the down(2) state).
SR Linux propagates the /interface[]/admin-state leaf into the ifAdminStatus OID using the mapping shown in Table 4:
ifAdminStatus OID value | ID | /interface[]/admin-state enum | /interface[]/admin-state value |
up | 1 | enable | 1 |
down | 2 | disable | 2 |
testing | 3 |
The ifType OID is located within the SNMP IF-MIB ifEntry subtree, specifically at 1.3.6.1.2.1.2.2.1.3. This indicates the type of interface. SR Linux propagates the ifType based on the interface name using the mapping shown in Table 5.
ID | ifType OID value | /interface[name=<>] value | /interface[]/subinterface[]/type value |
6 | ethernetCsmacd | ethernet-* | |
6 | ethernetCsmacd | * | bridged |
24 | softwareLoopback | lo* | |
142 | ipForward | * | routed |
161 | ieee8023adLag | lag* |
The ifMtu is located within the SNMP IF-MIB ifEntry subtree, specifically at 1.3.6.1.2.1.2.2.1.4. This indicates the size of the largest packet that can be sent/received on the interface, specified in octets.
When used with Ethernet/bridged interfaces, this includes Ethernet overhead, but does not include the 4-byte FCS. When used with routed interfaces, this includes the IP header, but excludes any Ethernet encapsulation.
SR Linux propagates the /interface[]/mtu leaf into the ifMtu OID when dealing with physical or top level interfaces. For subinterfaces, the /interface[]/subinterface[]/l2-mtu should be used for type=bridged, and /interface[]/subinterface[]/l3-mtu should be used for type=routed.
The ifSpeed OID is located within the SNMP IF-MIB ifEntry subtree, specifically at 1.3.6.1.2.1.2.2.1.5. This is an estimate of the interface’s current bandwidth in bits per second. For interfaces that do not vary in bandwidth, or for those where no accurate estimation can be made, this object contains the nominal bandwidth.
If the bandwidth of the interface is greater than the maximum value reportable by this object, then this object reports its maximum value (4,294,967,295), and ifHighSpeed is used to report the interface’s speed using the mapping shown in Table 6.
ifSpeed OID value | ifHighSpeed OID value | /interface[]/ethernet/port-speed value |
10000000 | 10 | 10M |
100000000 | 100 | 100M |
1000000000 | 1000 | 1G |
4294967295 | 10000 | 10G |
4294967295 | 25000 | 25G |
4294967295 | 40000 | 40G |
4294967295 | 50000 | 50G |
4294967295 | 100000 | 100G |
4294967295 | 200000 | 200G |
4294967295 | 400000 | 400G |
4294967295 | 800000 | 800G |
4294967295 | 1000000 | 1T |
The ifPhysAddress OID is located within the SNMP IF-MIB ifEntry subtree, specifically at 1.3.6.1.2.1.2.2.1.6.
This is the interface address at its protocol sublayer. For example, for an 802.x interface, this object normally contains a MAC address. The interface’s media-specific MIB defines the bit and byte ordering and the format of the value of this object. For interfaces that do not have such an address (for example, a serial line), this object contains an octet string of zero length.
SR Linux propagates the /interface[]/ethernet/hw-mac-address leaf into the ifPhysAddress OID, with transformations to conform to the SNMPv2 IF-MIB. The transformations are to remove the “:” separators. For example, the MAC address 00:25:ba:51:c7:0a, is transformed into 0025ba51c70a. For subinterfaces, the parent interface MAC is used, and for any interfaces which do not use MAC addresses, the field contains an octet string of zero length.
The ifName OID is located within the SNMP IF-MIB2 ifXEntry subtree, specifically at 1.3.6.1.2.1.31.1.1.1.1.
This is the textual name of the interface. The value of this object is the name of the interface as assigned by the local device, and is suitable for use in commands entered at the device's console. This might be a text name, such as le0 or a simple port number, such as 1, depending on the interface naming syntax of the device. If several entries in the ifTable together represent a single interface as named by the device, then each will have the same value of ifName. Note that for an agent that responds to SNMP queries concerning an interface on some other (proxied) device, then the value of ifName for such an interface is the proxied device’s local name for it.
If there is no local name, or this object is otherwise not applicable, then this object contains a zero-length string.
SR Linux propagates /interface[]/name (for physical or top-level interfaces) leaf or for subinterfaces the /interface[]/subinterface[]/name leaf into the ifName OID.
The ifHCInOctets OID is located within the SNMP IF-MIB2 ifXEntry subtree, specifically at 1.3.6.1.2.1.31.1.1.1.6.
This is the total number of octets received on the interface, including framing characters. This object is a 64-bit version of ifInOctets.
Discontinuities in the value of this counter can occur at reinitialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime.
SR Linux propagates /interface[]/statistics/in-octets (for physical or top-level interfaces) leaf or for subinterfaces the /interface[]/subinterface[]/statistics/in-octets leaf into the ifHCInOctets OID.
The ifHCOutOctets OID is located within the SNMP IF-MIB2 ifXEntry subtree, specifically at 1.3.6.1.2.1.31.1.1.1.10.
This is the total number of octets transmitted out of the interface, including framing characters. This object is a 64-bit version of ifOutOctets.
Discontinuities in the value of this counter can occur at reinitialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime.
SR Linux propagates /interface[]/statistics/out-octets (for physical or top-level interfaces) leaf, or for subinterfaces the /interface[]/subinterface[]/statistics/out-octets leaf, into the ifHCOutOctets OID.
The ifHighSpeed OID is located within the SNMP IF-MIB2 ifXEntry subtree, specifically at 1.3.6.1.2.1.31.1.1.1.15.
An estimate of the interfaces current bandwidth in units of 1,000,000 bits per second. If this object reports a value of `n then the speed of the interface is somewhere in the range of `n-500,000 to `n+499,999. For interfaces that do not vary in bandwidth, or for those where no accurate estimation can be made, this object contains the nominal bandwidth. For a sub-layer that has no concept of bandwidth, this object is zero.
See Table 6 for the use of ifHighSpeed.
The ifPromiscuousMode is located within the SNMP IF-MIB2 ifXEntry subtree, specifically at 1.3.6.1.2.1.31.1.1.1.16.
This object has a value of false (2) if this interface only accepts packets/frames that are addressed to this station. This object has a value of true (1) when the station accepts all packets/frames transmitted on the media. The value true (1) is only legal for certain types of media. If legal, setting this object to a value of true (1) may require the interface to be reset before becoming effective.
The value of ifPromiscuousMode does not affect the reception of broadcast and multicast packets/frames by the interface.
This field is set to false (2) for all interfaces in SR Linux.
The ifConnectorPresent OID is located within the SNMP IF-MIB2 ifXEntry subtree, specifically at 1.3.6.1.2.1.31.1.1.1.17.
This object has the value true (1) if the interface sublayer has a physical connector and the value false (2) otherwise.
This field is set to false (2) for all non-physical interfaces. For physical interfaces with non-removable optics, this is set to true (1), and for physical interfaces with optics present, this is also set to true (1). A physical interface without an optic is set to false (2).
The ifAlias OID is located within the SNMP IF-MIB2 ifXEntry subtree, specifically at 1.3.6.1.2.1.31.1.1.1.18.
This object is an alias name for the interface as specified by a network manager, and provides a non-volatile identifier for the interface.
On the first instantiation of an interface, the value of ifAlias associated with that interface is the zero-length string. When a value is written into an instance of ifAlias through a network management set operation, the agent retains the supplied value in the ifAlias instance associated with the same interface for as long as that interface remains instantiated, including across all re-initializations/reboots of the network management system, including those that result in a change of the interface’s ifIndex value.
An example of the value that a network manager may store in this object for a WAN interface is the circuit number/identifier of the interface.
Some agents may support write access only for interfaces having particular values of ifType. An agent that supports write access to this object is required to keep the value in non-volatile storage, but it may limit the length of new values depending on how much storage is already occupied by the current values for other interfaces.
SR Linux propagates the /interface[]/description (for physical or top-level interfaces) leaf, or for subinterfaces the /interface[]/subinterface[]/description leaf, into the ifAlias OID.