Help
Logging in to a command line for the first time can be a daunting task. You stare into a black-and-white terminal, and a seemingly infinite combination of commands are staring back—it can be extremely difficult. All users of Junos or Unix start out this way, and soon enough they become nimble on the CLI.
This section is one of two that will show you some of the basic techniques you can use if you’re starting out on the Junos command line with your SRX device.
The first thing you need to do is begin to configure the device. All Junos devices come with some base configurations. In this section, we will ignore the base configurations and instead discuss the important base configuration elements. This should help you to understand how to get the device up and running with base configuration settings.
System Settings
When you configure a Junos device many options are used system-wide. These system-wide options are set in the
system stanza. Several dozen configuration settings are in the system stanza, and here we’ll cover the most important ones that you need to configure for a typical Junos deployment.Note: For further information on these and other configuration options, please review the Junos CLI tech doc references or the free Day One booklets.
Before you can commit a configuration, the root user must have an authentication method configured. When a Junos device ships the root password is empty. The administrator can log in as root (the only default user that’s configured) without a password. Upon the first commit on the device one of the authentication methods must be configured.
[edit system] root@SRX210-A# set root-authentication ? Possible completions: + apply-groups Groups from which to inherit configuration data + apply-groups-except Don't inherit configuration data from these groups encrypted-password Encrypted password string load-key-file File (URL) containing one or more ssh keys plain-text-password Prompt for plain text password (autoencrypted) > ssh-dsa Secure shell (ssh) DSA public key string > ssh-rsa Secure shell (ssh) RSA public key string [edit system] root@SRX210-A# set root-authentication plain-text-password New password: Retype new password: [edit system] root@SRX210-A#
As you can see, you can use four different methods to authenticate the root user. Plain-text password is the most common. This is the normal, hand-typed password and is the example shown in the preceding output. The administrator must hand-type the password and then confirm it. The password is stored in the configuration as an MD5 password with a salt. This means it’s not possible to reverse the password just by seeing it, and because it has a salt, it is extremely hard to determine the password.
The alternate methods for the root password are all about using SSH keys. When you use an SSH key a password is not used to authenticate the user. This is more secure, as the user has ownership of his private key and it is not sent over the network for authentication. In Junos, the user’s public key must be loaded on the system. You can do this in one of three ways: as a DSA key, as an RSA key, or by loading the key from a file.
No matter which way you choose to set up root authentication, it is suggested that you always utilize a nonroot user for administration. Junos is designed to handle multiple user accounts and determining permissions per user based upon groups. The root user has the ultimate permissions into the system, and users logging on as root can choose to do whatever they wish. Individual user accounts enable better tracking of what each user is doing on the device. Junos tracks each user’s commands and configuration commits, and identifies who changed what. So, it is considered a best practice to always use an alternate user account instead of root.
When creating a new user account you need to select a few properties for the new account:
[edit system] root@SRX210-A# set login user ? Possible completions: + apply-groups Groups from which to inherit configuration data + apply-groups-except Don't inherit configuration data from these groups > authentication Authentication method class Login class full-name Full name uid User identifier (uid) (100..64000) [edit system] root@SRX210-A# set login user rcameron class ? Possible completions: <class> Login class operator permissions [ clear network reset trace view ] read-only permissions [ view ] super-user permissions [ all ] unauthorized permissions [ none ] [edit system] root@SRX210-A# set login user rcameron class super-user [edit system] root@SRX210-A# set login user rcameron authentication plain-text-password New password: Retype new password: [edit system] root@SRX210-A#
The minimum items for a user are a username, a class (or group), and an authentication method. The available authentication methods are the same as those covered for the root user. In this example, the common plain-text password was chosen. One item that may not be obvious is class. A class is the same concept as a user group. It provides the user access to issue specific commands and modes. In this example, the super-user class was chosen and this class gives the user access to all possible commands and modes. The various prebuilt classes are a small example of what is possible for classes. It is possible to build custom classes that can restrict a user to run a specific command or view only specific portions of the configuration. You can find further details regarding classes in the Junos documentation suite for your SRX model and platform.
You can remotely access a Junos device in many different ways, all of which are done through the
system services stanza. In this stanza, all of the various services are configured. Depending on the device type, different services may be configured. If only one service needs to be configured, it should be SSH, because SSH is the best way to access the CLI remotely.The service allows for encrypted transport of data, key-based authentication, and even the ability to transfer files. Most Unix-like clients contain a built-in client using the OpenSSH software package. For Windows users, a plethora of SSH clients can be used. Several of them are free, and some are available as commercial packages. Even devices such as the Apple iPhone and iPad have very viable SSH clients.
Enabling SSH is simple, as it requires only a single command and just a few options:
[edit system services] root@SRX210-A# set ssh ? Possible completions: <[Enter]> Execute this command + apply-groups Groups from which to inherit configuration data + apply-groups-except Don't inherit configuration data from these groups connection-limit Maximum number of allowed connections (1..3) + protocol-version Specify ssh protocol versions supported rate-limit Maximum number of connections per minute (1..3) root-login Configure root access via ssh | Pipe through a command [edit system services] root@SRX210-A# set ssh [edit system services] root@SRX210-A#
The single command
set system services ssh enables the SSH service. You also can specify whether the root user can authenticate, whether to rate-limit the number of connections per minute, the maximum number of concurrent connections, and the protocol version. It’s best to disallow SSH authentication for root so that unauthorized attempts to log in as root are not allowed. Also, limiting the rate at connections per minute ensures that someone cannot attempt to use a brute force attack to access the system.A Junos device can use name resolution to convert Domain Name System (DNS) names to IP addresses. This is useful when using ping, SSH, and Telnet commands from the device. Configuring a name server is simple, and it is done under the
system stanza. If a name server is not configured, name resolution will not be possible. Here’s an example:[edit system]
root@SRX210-A# set name-server 208.67.222.222
name-server {
208.67.222.222;
208.67.220.220;
}
--snip—
[edit system]
root@SRX210-A#Each device should have a unique hostname. This is useful for identifying the device on the command line. Providing a unique hostname can also help prevent an accidental configuration change on the wrong device in the network. Configuring the hostname is simple and it takes only one command:
[edit system] root@SRX210-A# set host-name JunosBook [edit system] root@SRX210-A# show host-name JunosBook; --snip-- [edit system] root@SRX210-A#
Interfaces
A networking device without interfaces isn’t much of a networking device. Since a Junos device is always in the network, and most of the time it is in the path of the network, it is critical to understand interface configuration.
Some Junos interface concepts might seem foreign to administrators who are migrating from other operating systems. Remember that the Junos CLI is designed to be extensible and scalable, and once an element is added to the configuration hierarchy after a software release is made, it is not changed. Because of this, creating an interface and modifying its parameters may seem overly complex, but it is done for a good reason: to ensure that 10 years from now the general structure of creating an interface is backward-compatible.
Interfaces come in two types: logical and physical. A physical interface is an actual device that someone can touch and a cable of some sort goes into it. A logical interface is an entity that has a protocol and a network address assigned to it. A physical interface can also be called an IFD and a logical interface is called an IFL, terms sometimes sprinkled around in the documentation or in various Junos material.
An interface is named in a common format and the format is shared regardless of the interface type. The first part of an interface name is the media type. Table 3-3 lists a few of the common media types and their abbreviations.
Table 3-3. Interface media types
| Name | Media type |
fe | Fast Ethernet 10/100 |
ge | Gigabit Ethernet 1000 |
xe | 10 gigabit Ethernet |
t1 | T1 interface |
vlan | Virtual interface that resides in a virtual LAN (VLAN) |
There are many different types of interfaces, and only a handful are represented in Table 3-3. For more information on the various interface types refer to the Junos documentation set.
Interface names also include the location in which they are found in the chassis. This portion of the interface name consists of three numbers: the FPC number, the physical interface card (PIC) number, and the port number.
FPC stands for flexible PIC concentrator, and it is simply a slot in a chassis. The differentiation of FPCs typically determines how the FPC plugs into the backplane of the device. A PIC represents a physical or pluggable (both terms are seen and sometimes used interchangeably) interface card on which interfaces or ports reside. The numbering for an interface is represented in an X/Y/Z pattern, with X being the FPC, Y being the PIC, and Z being the port. An example of a complete interface name is “ge-0/0/0”.
Note: A few interface types do not fit into this format. One of these is fxp0, which is used as a management port. You can configure it with most of the options that an interface can use, such as IP addresses, but this interface cannot route traffic because it is not a transient interface.
Each physical interface has some physical properties that you can configure, such as speed, duplex, and auto-negotiation; these properties vary based on interface type. Because of all the variations that are possible, it’s best to check the latest Junos documentation to get the most up-to-date configuration options. But in most cases, the command-line help, using
?, will give you what you need.When an interface is configured for use on the network it must always be configured with what is known as a unit. A unit is a logical entity that is applied to an interface. A physical interface must have at least one unit, but it can have as many as 16,000, depending on the need. This is a departure from other operating systems.
To communicate with other hosts and pass traffic through the device, protocols must be configured. Junos supports numerous protocols for network communication and several can be configured per unit. The most common protocol that is used is IPv4. This is the current standard on the Internet and in most networks. IPv6 is growing in popularity, and because of this, Junos has support for it as well. When configuring an interface, a protocol is called a family. This is because a protocol is often a family of protocols; an example is IP, as IP uses ICMP, TCP, and UDP for messaging purposes.
Configuring an interface is simple, even though it has several parts to it. Let’s create an interface configured with an IP address on it. Although there are many different protocols and permutations, we will use IPv4, as it is fairly common.
[edit interfaces]
root@SRX210-A# set ge-0/0/0 unit 0 family inet address 1.2.3.4/30
[edit interfaces]
root@SRX210-A# show
ge-0/0/0 {
unit 0 {
family inet {
address 1.2.3.4/30;
}
}
}In this command set the IP address of 1.2.3.4 with a bit mask of 30 bits is used. It is applied to interface ge-0/0/0 and unit 0. Although any unit number can be used, it’s common to use 0 when only one unit is used. When VLANs are implemented, it’s common to have the unit name match the VLAN tag; although this is not required, it helps when other administrators need to look through a configuration.
Instead of having to type out “unit” when running a command, you can use a period (.) instead of the word unit when configuring an interface. It’s a nice shortcut:
[edit interfaces]
root@SRX210-A# set ge-0/0/0.0 family inet address 1.2.3.4/30
[edit interfaces]
root@SRX210-A# show ge-0/0/0
unit 0 {
family inet {
address 1.2.3.4/30;
}
}
[edit interfaces]
root@SRX210-A#Adding a VLAN tag is a simple configuration. To start the configuration the interface needs to have tagging enabled on it, before it can be enabled on the logical interface:
[edit interfaces]
root@SRX210-A# set ge-0/0/0 vlan-tagging
[edit interfaces]
root@SRX210-A# set ge-0/0/0.100 vlan-id 100
[edit interfaces]
root@SRX210-A# set ge-0/0/0.100 family inet address 1.2.3.4/30
[edit interfaces]
root@SRX210-A# show ge-0/0/0
vlan-tagging;
unit 100 {
vlan-id 100;
family inet {
address 1.2.3.4/30;
}
}
[edit interfaces]
root@SRX210-A#Switching (Branch)
On the branch SRX Series, most Ethernet interfaces support the ability to do switching. The switching capabilities in the branch SRX Series are inherited from Juniper Networks’ EX Series Ethernet Switches, so the functionality and configuration are nearly identical.
The most common configuration type is an access port. An access port is a port that does not accept VLAN tagged packets, but rather tags the packets internally to the switch. It will also allow the packet to exit as a tagged packet on a trunk port. (A VLAN must be assigned to an interface even if the traffic will never exit the device as a packet tagged with the VLAN. In cases such as these, the actual VLAN tag used is irrelevant.)
[edit interfaces ge-0/0/2.0]
root@JunosBook# set family ethernet-switching
[edit interfaces ge-0/0/2.0]
root@JunosBook# set family ethernet-switching port-mode access
[edit interfaces ge-0/0/2.0]
root@JunosBook# show
unit 0 {
family ethernet-switching {
port-mode access;
vlan {
members 100;
}
}
}
[edit interfaces ge-0/0/2.0]
root@JunosBook#Here,
ethernet-switching was added as a family (remember that a family represents a protocol suite, and in this case it represents switching). The port was set to access mode, which internally tags the packet after it enters the port. It is tagged with VLAN 100, as that is what is configured under the vlan stanza. An access port can only have a single VLAN configured. When configuring a VLAN it can be specified with the tag number or a configured VLAN name. We will discuss VLAN configuration later in this section.Most of the branch SRX Series devices have several ports that you can configure for switching. In some cases, up to 24 sequential ports can be used for switching. Instead of having to configure all of the ports by hand, it’s possible to use the
interface range command. This configuration allows you to select several ports and then apply the same commands across all of the interfaces:[edit interfaces]
root@JunosBook# show
interface-range interfaces-trust {
member ge-0/0/1;
member fe-0/0/2;
member fe-0/0/3;
member fe-0/0/4;
member fe-0/0/5;
member fe-0/0/7;
unit 0 {
family ethernet-switching {
vlan {
port-mode access;
members 100;
}
}
}
}An interface range must be given a unique name, and then one or more interfaces can be added as members of the range. At this point, any configuration option that can normally be added to an interface can be added here. Because of this, the use of interface ranges is not just limited to switching. For example, unit 0 was created with Ethernet switching and VLAN 100. Upon commit, all interfaces have the same configuration applied to them.
Up to this point, all VLANs have been used with just a number tag. It is also possible to create VLANs and give them a name which allows for easier management and identification in the configuration. You can use the VLAN name instead of the tag name anywhere in the configuration:
[edit vlans]
root@JunosBook# show
vlan-trust {
vlan-id 100;
interface {
fe-0/0/6.0;
}
l3-interface vlan.0;
}
[edit vlans]
root@JunosBook#Each VLAN is given a custom name. This name must be unique and must not overlap with any other existing VLAN name. You also must assign a VLAN ID to the VLAN. You can configure several other options under a VLAN, the most common of which concern the direct configuration of interfaces. Previously, when Ethernet switching was configured on each interface, a VLAN had to be configured. In this configuration example, the VLAN can be configured from one central location directly under the VLAN. Either option is valid; the usage is based on personal preference.
The other common option is the use of a VLAN interface. A VLAN interface allows for the termination of traffic that can then be routed out another interface on the device. The VLAN interface is accessible from any port that is a member of that VLAN. The interface is configured just like any other interface type:
[edit]
root@JunosBook# edit interfaces
[edit interfaces]
root@JunosBook# set vlan.0 family inet address 1.2.3.4/24
[edit interfaces]
root@JunosBook# edit interfaces
[edit interfaces]
root@JunosBook# show vlan
unit 0 {
family inet {
address 1.2.3.4/24;
}
}
[edit interfaces]
root@JunosBook#A trunk port is a port that has two or more VLANs configured on it and traffic entering a trunk port must be tagged with a VLAN tag. A trunk port is typically used when connecting the SRX to another switch:
[edit]
root@JunosBook# edit interfaces
[edit interfaces]
root@JunosBook# set ge-0/0/2.0 family ethernet-switching port-mode trunk
[edit interfaces]
root@JunosBook# set ge-0/0/2.0 family ethernet-switching vlan members 200
[edit interfaces]
root@JunosBook# show ge-0/0/2.0
family ethernet-switching {
port-mode trunk;
vlan {
members [ 100 200 ];
}
}
[edit interfaces]
root@JunosBook#As you can see, the configuration here is very similar to an access port. The differences are minor, as the port mode is configured as a trunk and multiple VLAN members are added to the port. Traffic entering the port must be tagged and must match the VLANs configured on the port.
Zones
A zone is a logical construct that is applied to an interface and is used as a building block for security policies on the SRX Series Services Gateways and the Juniper Networks J Series Services Routers. The concept of the zone originated on the ScreenOS platform from NetScreen Technologies. When creating a security policy, the idea is to allow traffic from a source to go to a destination. The zone adds another dimension to that by allowing for the concept of a source zone and a destination zone. This was very different from all of the existing firewall products of the time. The division of a security policy base into multiple smaller policy sets, or contexts, enhanced performance and simplified management.
Creating a security zone is simple, as the minimum requirement is just a name. In the past on NetScreen products, there was a concept of having prenamed zones called Trust, Untrust, and DMZ. These zone names were always left in place because the original ScreenOS devices actually used these as the interface names. Juniper has moved away from having the default names, and now allows users to name the zones whatever they want. Security zones are located under the
security zones stanza:[edit security zones]
root@SRX210-A# show
security-zone SuperZone {
interfaces {
ge-0/0/0.0;
}
}
[edit security zones]
root@SRX210-A#Security zones offer little to no value without the addition of interfaces. In the example shown here, the ge-0/0/0.0 interface is added to the new zone named
SuperZone. The zone is now ready to be used in security policies.At least one interface must be bound in a zone to be able to use it to create security policies. Multiple interfaces can be added to a zone as well, and this may be helpful depending on the goal of the network design. An interface can only be a member of one zone at a time. Logical interfaces are added to a zone, and so it’s possible to have multiple logical interfaces that are a member of the same physical interface to be members of multiple zones.
Functional zones are a logical entity that is applied to the interface to enable it to have a special function. Interfaces that are a member of a functional zone cannot be used in a security zone. On the SRX, the only functional zone that is used is management. Adding an interface into the management zone allows the interface to be used for out-of-band management, a helpful tool for devices such as the branch SRX Series devices, which do not have a dedicated interface for management.
[edit security zones]
root@JunosBook# set functional-zone management interfaces fe-0/0/6.0
[edit security zones]
root@JunosBook# edit functional-zone management
[edit security zones functional-zone management]
root@JunosBook# show
interfaces {
fe-0/0/6.0;
}
host-inbound-traffic {
system-services {
all;
}
}
[edit security zones functional-zone management]
root@JunosBook#Adding an interface to a functional zone is the same as using a security zone. A new element shown in this configuration is
host inbound traffic. The host inbound traffic stanza can be configured under any zone, and it allows for the acceptance of two different types of traffic to the SRX itself. If the host inbound traffic is not configured, traffic will not be accepted. This is different from creating a security policy, as a security policy is only for transit traffic and not for traffic terminating on the device.root@JunosBook# set host-inbound-traffic system-services ? Possible completions: all All system services any-service Enable services on entire port range dns DNS and DNS-proxy service finger Finger service ftp FTP http Web management service using HTTP https Web management service using HTTP secured by SSL ident-reset Send back TCP RST to IDENT request for port 113 ike Internet Key Exchange lsping Label Switched Path ping service netconf NETCONF service ntp Network Time Protocol service ping Internet Control Message Protocol echo requests reverse-ssh Reverse SSH service reverse-telnet Reverse telnet service rlogin Rlogin service rpm Real-time performance monitoring rsh Rsh service sip Enable Session Initiation Protocol service snmp Simple Network Management Protocol service snmp-trap Simple Network Management Protocol traps ssh SSH service telnet Telnet service tftp TFTP traceroute Traceroute service xnm-clear-text JUNOScript API for unencrypted traffic over TCP xnm-ssl JUNOScript API service over SSL [edit security zones functional-zone management] root@JunosBook# set host-inbound-traffic protocols ? Possible completions: all All protocols bfd Bidirectional Forwarding Detection bgp Border Gateway Protocol dvmrp Distance Vector Multicast Routing Protocol igmp Internet Group Management Protocol ldp Label Distribution Protocol msdp Multicast Source Discovery Protocol ndp Enable Network Discovery Protocol nhrp Next Hop Resolution Protocol ospf Open Shortest Path First ospf3 Open Shortest Path First version 3 pgm Pragmatic General Multicast pim Protocol Independent Multicast rip Routing Information Protocol ripng Routing Information Protocol next generation router-discovery Router Discovery rsvp Resource Reservation Protocol sap Session Announcement Protocol vrrp Virtual Router Redundancy Protocol [edit security zones functional-zone management] root@JunosBook# set host-inbound-traffic protocols
The first type of host inbound traffic is called system services. System services traffic is related to any service that is used for management on the SRX. This includes SSH, Telnet, and DNS. The other type of host inbound traffic is protocols. These are routing protocols or other protocols that are used for communicating with other network devices. Each individual service can be turned on, or all of them can be turned on, using the
all flag.Note: Given that an SRX is most often deployed as a security device, it’s a best practice to reduce the total number of host inbound protocols.
Host inbound traffic can also be enabled on a per-interface basis. This is a good idea when multiple interfaces are in a zone. Also, some protocols such as DHCP can only be enabled on a single interface and not on a per-zone basis. DHCP will not be allowed unless specifically enabled under the interface.
root@host# set interfaces fe-0/0/6.0 host-inbound-traffic system-services dhcp
[edit security zones functional-zone management]
root@JunosBook# show
interfaces {
fe-0/0/6.0 {
host-inbound-traffic {
system-services {
dhcp;
}
}
}
}
host-inbound-traffic {
system-services {
all;
}
}
[edit security zones functional-zone management]
root@JunosBook#
Learn more about this topic from Junos Security.
Junos® Security is the complete and authorized introduction to the new Juniper Networks SRX hardware series. This book not only provides a practical, hands-on field guide to deploying, configuring, and operating SRX, it also serves as a reference to help you prepare for any of the Junos Security Certification examinations offered by Juniper Networks. Network administrators and security professionals will learn how to use SRX Junos services gateways to address an array of enterprise data network requirements -- including IP routing, intrusion detection, attack mitigation, unified threat management, and WAN acceleration.
