Connecting and Configuring an EX Series Switch - CLI Procedure

Using the CLI, set the following parameter values in the console server or PC:

• Baud rate—9600
• Flow control—None
• Data—8
• Parity—None
• Stop bits—1
• DCD state—Disregard

1. To connect and configure the switch from the console by using the CLI:

Connect the console port to a laptop or PC by using the RJ-45 to DB-9 serial port adapter. An Ethernet cable that has an RJ-45 connecter at either end and an RJ-45 to DB-9 serial port adapter are supplied with the switch.

2. At the Junos OS shell prompt root%, type ezsetup.
3. Enter the hostname. This is optional.
4. Enter the root password you want to use for the device. Reenter the root password when prompted.
5. Enable services such as SSH and Telnet.

   Note: You will not be able to log in to the switch as the root user through Telnet. Root login is allowed only through SSH.

   • The default option for SSH is yes. Select this to enable SSH.
   • The default option for Telnet is no. Change this to yes to enable Telnet.
6. Use the Management Options page to select the management scenario:

   Note: On EX4500, EX6200, and EX8200 switches, only the out-of-band management option is available.

   • Configure in-band management. In in-band management, you configure a network interface or an uplink module (expansion module) interface as the management interface and connect it to the management device.
     In this scenario, you have the following two options:
     • Use the automatically created VLAN default for management—Select this option to configure all data interfaces as members of the default VLAN. Specify the management IP address and the default gateway.
     • Create a new VLAN for management—Select this option to create a management VLAN. Specify the VLAN name, VLAN ID, management IP address, and default gateway. Select the ports that must be part of this VLAN.
   • Configure out-of-band management—Configure the management port. In out-of-band management, you use a dedicated management channel (MGMT port) to connect to the management device. Specify the IP address and gateway of the management interface. Use this IP address to connect to the switch.
7. Specify the SNMP read community, location, and contact to configure SNMP parameters. These parameters are optional.
8. Specify the system date and time. Select the time zone from the list. These options are optional.
9. The configured parameters are displayed. Enter yes to commit the configuration. The configuration is committed as the active configuration for the switch.
10. (For EX4500 switches only) Enter the operational mode command request chassis pic-mode intraconnect to set the PIC mode to intraconnect.

You can now log in with the CLI or the J-Web interface to continue configuring the switch. If you use the J-Web interface to continue configuring the switch, the Web session is redirected to the new management IP address. If the connection cannot be made, the J-Web interface displays instructions for starting a J-Web session.

Juniper : The death of ScreenOS

The Juniper families of SRX services gateways are the replacement platforms for the SSG platforms, the ISG 1000 and ISG 2000 as well as the NS 5000 Series (NS-5200 and NS-5400). The SRX family include a set of branch platforms (SRX210, SRX240 and SRX650), and the high end platforms (SRX3000 and SRX5000).

The entire line of SRX platforms uses JUNOS, a very powerful networking platform that consolidates switching, routing, security and applications into a single OS. JUNOS is very different than ScreenOS and as such, will place a significant migration burden on Juniper, their customers and their partners.

Key points to consider:

The SRX Is not positioned as a firewall.

•      JUNOS is not a security OS and the SRX positioning reflects this based on the routing and switching emphasis which Juniper uses as a means to compete with Cisco. With the SRX, security is merely a service that is enabled along with switching. Juniper does not try to address the problem of the lack of innovation at the firewall which resulted in the loss of visibility and control over applications, users and content.

They cannot do what we do—even with multiple components.

•      Application visibility and control belongs in the firewall and the port based SRX platforms cannot deliver that functionality.

•      Juniper has taken the Cisco approach to say they can do what we do using multiple devices (SRX with IDP, UAC Controller, a UAC agent on every desktop and multiple management components). Even with this “everything-but- the-kitchen-sink” approach, they cannot address the visibility and control (applications, users and content) problem.

Stuck on old technology.

•      The SRX uses stateful inspection which relies on port and protocol for policy decisions, a technique that is ineffective at controlling applications that use dynamic ports, encryption, or tunnel across often used/allowed ports to bypass firewalls.

•      Full IDP is supported, and can block a very limited set of, mostly bad applications like P2P and IM – currently at 126, an incremental improvement over the 118. The threat focused approach is inadequate in detecting and positively enabling applications. Applications are not threats. They should not be treated as such.

Faster at doing nothing.

•      Their literature claims impressive performance for port-based traffic classification (stateful inspection). But based on packets per second (PPS), a more accurate performance measurement, their performance is not all that great.

A management nightmare.

•      Heavy reliance on CLI for tuning and troubleshooting with no plans to enable management via a GUI.

•      Palo Alto Networks GUI and centralized management interfaces are identical, simplifying management. A full CLI complements the graphical interfaces and, more importantly, all commands can be accessed from any one of the three interfaces.

•      IDP is not part of the firewall policies, but rather part of the IDP policies, which means that port/protocol still determines what traffic the IDP feature sees giving applications an easy way to bypass the IDP controls.

Understanding Junos OS with Upgraded FreeBSD

Starting with Junos OS Release 15.1, certain hardware platforms run a Junos OS based on an upgraded FreeBSD kernel instead of older versions of FreeBSD. Basing Junos OS on the newer kernel provides Junos OS with sophisticated processing, efficiency, and security features which do not then have to be reproduced in Junos OS.

Junos OS with an upgraded FreeBSD kernel provides a clean-slate implementation of Junos OS on top of a pristine (minimally modified) and current version of the FreeBSD OS.

The platforms currently running Junos OS with upgraded FreeBSD are listed in Table 1.

Table 1: Upgraded FreeBSD Kernel Support by Hardware Platform

Platforms	CPU Type	Release Introduced
MX240, MX480, MX960, MX2010, MX2020	Intel	15.1
EX9200	Intel	15.1
QFX5200	Intel	15.1X53-D30

The major processing changes are as follows:

• Interactions between Junos OS and the upgraded FreeBSD kernel use well-established interfaces because Junos OS is now layered on a minimally modified and current version of FreeBSD.
• Symmetric multiprocessing (SMP) is enabled by default.
• FreeBSD provides a consistent runtime environment for all Junos OS platforms.

There are also major changes in file structures and software packages. These changes are as follows:

• New packages use XML description files instead of scripts.
• Hybrid packages are used to install legacy or replacement build images in the general form junos-upgrade-x.tgz, where x is a variable such as mx-x86-64-15.1-20150114 (the whole package name is junos-upgrade-mx-x86-64-15.1-20150114.tgz).
• Multiple package sets (a collection of installed packages) are stored on the router at the same time. Sets can be either active (the currently used set), pending (the set that should be used at the next reboot), or previous (a formerly active set). Non-recovery snapshots (but not recoverable image snapshots) are available for the package sets to preserve package content lists.

There is now a separate Operations, Administration, and Maintenance (OAM) volume (oam) distinct from the Junos OS volume (junos). This provides support for downgrades from replacement build images (that is, those using the upgraded FreeBSD kernel) to the legacy Junos OS with a different kernel. The OAM volume allows you to recover the Junos OS volume using recovery snapshots.

One major change is the distinction between recovery snapshots and non-recovery snapshots.

The major characteristics of the recovery snapshots are as follows:

• Recovery snapshots are full copies of the packages and configuration taken at the time the snapshot command is issued.
• Recovery snapshots reside on the OAM volume or USB medium.

The major characteristics of the non-recovery snapshots are as follows:

• Non-recovery snapshots are snapshots residing on the Junos OS volume that refer to the current running set of packages and a copy of the configuration at the time the snapshot command is issued.
• Non-recovery snapshots do not need to copy the whole Junos OS installation and so are very fast.
• Non-recovery snapshots can be requested as the boot image for the next reboot.

The upgraded FreeBSD kernel requires changes to several commands and statements and their related parameters. The new and changed actions are summarized in Table 2. For details on the changes, see the topics covering the specific command or statement.

Table 2: New and Changed Commands and Statements for Junos OS with Upgraded FreeBSD

Command or Statement	Release Introduced	Change
request system snapshot delete snapshot	15.1	New action
request system snapshot recovery	15.1	New action
request system snapshot load snapshot	15.1	New action
request system recover volume	15.1	New action: volume is either /junos-volume or /oam-volume
request system snapshot	15.1	Changed action
show system snapshot	15.1	Changed action
request system reboot media	15.1	Changed action with new media options

The new FreeBSD kernel also requires that several commands and statements are now deprecated. In some cases, these commands and statements generate an error, and, in other cases, the result is appropriate for the new kernel. The deprecated commands and statements are summarized in Table 3. For details, see the topics covering the specific command or statement.

Table 3: Deprecated Commands and Statements for Junos OS with Upgraded FreeBSD

Deprecated Command or Configuration Statement	Release Deprecated
Deprecated Command
request system partition abort	15.1
request system partition compact-flash	15.1
request system partition hard-disk	15.1
request system snapshot <config-partition>	15.1
request system snapshot <root-partition>	15.1
request system snapshot <slice>	15.1
request system software delete-backup	15.1
request system software rollback <force>	15.1
show system processes providers	15.1
show system snapshot <slice>	15.1
Deprecated Configuration Statement
set system mirror-flash-on-disk	15.1

Legacy DHCPD (DHCP Daemon) configuration syntax will be hidden starting from 15.1X49-D60

Currently, the SRX platform supports two syntax styles for configuring DHCP Client, Server, and Relay. These two configuration syntax styles correspond to two different DHCP daemons, namely the legacy DHCPD, and JDHCP. Moving forward, all the new features and capabilities will be developed on JDHCP. The deprecation plan for DHCPD will begin with the following changes starting from Junos OS Release 15.1X49-D60:

• The factory default DHCP Server / Client configuration is changed to JDHCP style.
• DHCPD configuration syntax will be hidden, but will continue to function and pass commit check as before.
• When upgrading a device to 15.1X49-D60 and onwards (until deprecation is completed), a warning message is displayed if DHCPD configuration syntax is present.
• A commit error is displayed if both DHCPD and JDHCP is configured simultaneously.
• J-Web is updated to support JDHCP exclusively.

      Note: DHCPD configuration style must be manually converted to JDHCP first via CLI before using DHCP with J-Web.

Solution:
To prepare for the future deprecation of DHCPD, it's recommended that the DHCPD's configuration syntax be converted to JDHCP's syntax style. Most of the configuration statements in DHCPD already have an equivalent in the JDHCP configuration style. For those that do not have an equivalent configuration statement, the commands will be added in future Junos OS releases before DHCPD is fully deprecated.

Note: The system does not allow both daemons to run at the same time. If you are using more than one function of the DHCP daemon (for example, both DHCP Client and DHCP Server), you must migrate both of those functions at the same time.


Legend:
Black: Both DHCPD and JDHCP have the same command (top level hierarchy may be different).
Blue: Different keyword for the same function between DHCPD and JDHCP.
Red: The JDHCP equivalent will be implemented in a future Junos release.

DHCP Client:

DHCPD	JDHCP
Hierarchy Level: [edit interfaces interface-name unit logical-unit-number family inet dhcp]	Hierarchy Level: [edit interfaces interface-name unit logical-unit-number family inet dhcp-client]
client-identifier	client-identifier
ascii ascii	userid ascii ascii
hexadecimal hexadecimal	userid hexadecimal hexadecimal
lease-time	lease-time
retransmission-attempt	retransmission-attempt
retransmission-interval	retransmission-interval
server-address	server-address
update-server	update-server
vendor-id	vendor-id

 DHCPD

	JDHCP
Hierarchy Level: [edit system services dhcp pool subnet-ip-address/mask]	Hierarchy Level: [edit access address-assignment pool pool-name family inet]
subnet-ip-address/mask	network network
address-range	range range-name
high address	high address
low address	low address
static-binding	host hostname
mac-address	hardware-address mac-address
fixed-address ip-address	ip-address ip-address
Hierarchy Level: [edit system services dhcp pool subnet-ip-address/mask]	Hierarchy Level: [edit access address-assignment pool pool-name family inet dhcp-attributes]
boot-file	boot-file
boot-server	boot-server
default-lease-time seconds	maximum-lease-time seconds (merged)
domain-name	domain-name
domain-search dns-search-suffix	option 119 string "dns-search-suffix"
exclude-address ip-address	excluded-address ip-address (available starting from 15.1X49-D60)
maximum-lease-time seconds	maximum-lease-time seconds
name-server	name-server
next-server	next-server
option	option
propagate-ppp-settings	propagate-ppp-settings
propagate-settings	propagate-settings
router	router
server-identifier	server-identifier
sip-server	sip-server
address ip-address	ip-address ip-address
name sip-server-name	name sip-server-name
wins-server	wins-server
Hierarchy Level: [edit system services dhcp]	Hierarchy Level: [edit system processes dhcp-service]
traceoptions	traceoptions
Hierarchy Level: [edit system services dhcp]	Hierarchy Level: [edit access address-assignment pool pool-name family inet]
option option-identifier-code	option option-identifier-code
byte-stream decimal-ascii	hex-string hexadecimal-ascii
(all other option-types are equivalent)	(all other option-types are equivalent)

DHCP Relay:

DHCPD	JDHCP
Hierarchy Level: [edit forwarding-options helpers bootp]	Hierarchy Level: [edit forwarding-options dhcp-relay]
client-response-ttl	(to be implemented in a future Junos release)
description	(to be implemented in a future Junos release)
dhcp-option82	(to be implemented in a future Junos release)
interface interface-name	group group-name interface interface-name
maximum-hop-count	(to be implemented in a future Junos release)
minimum-wait-time	(to be implemented in a future Junos release)
relay-agent-option	(to be implemented in a future Junos release)
server address	server-group server-group-name ip-address