Juniper EX Switch Ops: Initial Setup and Key Commands

2026年8月28日 LOG admin

Juniper EX switches behave differently from Cisco gear in several ways that surprise newcomers: there is no "enable" mode, configuration is commit-based, the default root login drops you into the shell rather than the CLI, and Virtual Chassis is a different concept from stacking. This article compiles the practical operations notes from an EX series field wiki — initial setup, everyday interface/VLAN/STP commands, Virtual Chassis essentials, and OSPF/AAA tuning tips — so you can manage EX switches confidently.

If you are arriving from IOS, the important mental shift is small but constant: every change is staged in a candidate configuration, nothing takes effect until you type commit, and a change that breaks your session is one rollback or one timed commit confirmed away from being undone. Once that model clicks, the EX command set reads like any other Junos platform. The notes below follow the order you actually meet the switch in: unboxing, then day-to-day switching, then chassis and routing behaviour.

Basics: Defaults and Initial Setup

Default credentials: username root with no password (drops into the shell, not the CLI).
Default management IP: via DHCPv4.
Serial: RS-232 over RJ45, 115200 baud, 8 data bits, no parity, 1 stop bit, no flow control.
Native VLAN: 0, aka default.

A factory-fresh EX switch boots with an empty configuration and asks the DHCP server on the management VLAN for an address. Because the root account has no password, the very first login is a shell prompt (%) rather than the operational CLI (>) — this is intentional and is the reason so many first-time deployments stall. From the shell you type cli to reach the Junos command interface, then enter configuration mode normally.

First Boot from the Console

Use a USB-to-serial adapter, set your terminal to 115200 8N1 with no flow control, and hit Enter. The sequence that takes a bare switch to a manageable device is short:

login: root
% cli
root> configure
root# set system root-authentication plain-text-password
New password:
Retype new password:
root# set system host-name ex-sw-01
root# set system domain-name lab.example.net
root# set interfaces me0 unit 0 family inet address 192.0.2.10/24
root# set system services ssh
root# set routing-options static route 0.0.0.0/0 next-hop 192.0.2.1
root# commit

The me0 interface is the dedicated out-of-band management port on most EX models; on platforms without one, the management address lives on a unit 0 address of a regular port or on an IRB interface. Setting system root-authentication before committing anything else is not optional — if the switch reboots with no root password while SSH is enabled, you have created a network-accessible unauthenticated box. Junos enforces this in the commit check for many configurations, and it is worth doing deliberately rather than by accident.

Until DNS and routing are in place you can still operate locally; to reach the outside world for software upgrades you will need a default route and a resolver:

root# set system name-server 192.0.2.53
root# set system ntp server 192.0.2.123
root# set system time-zone UTC
root# commit and-quit
root> show system uptime

System Housekeeping

request system storage cleanup          # clean up old files
set system arp aging-timer 300          # 5 min — match MAC timeout, avoid flooding
set system internet-options path-mtu-discovery   # lets BGP use larger packets

On ARP aging: the default 20 minutes on routers can cause flooding when the router tries to forward traffic but the MAC entry has timed out; 5 minutes matches the switch MAC address timeout. The mechanism is worth understanding rather than copying blindly. When a router holds a stale ARP entry, traffic keeps being queued while the next hop is resolved again, and the resulting broadcast burst reaches every host in the VLAN at once. Shortening the aging timer to roughly the same value as the MAC address-table timeout keeps the two caches roughly synchronised, so entries expire together instead of one stalling out behind the other.

path-mtu-discovery matters on any switch that originates BGP sessions. Without it, TCP sessions that cross a lower-MTU transit path can stall during large UPDATE transfers because the sender never learns the path MTU. Enabling it takes one line and removes an entire class of "BGP session flaps under load" tickets.

VLAN and STP Quick Reference

set vlans sales vlan-id 10                      # create VLAN
set interfaces ge-0/0/1 unit 0 family ethernet-switching interface-mode access
set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members sales
show vlans interface <interface>                # verify
show spanning-tree interface                    # STP status

Note: on modern ELS switches (EX2300/EX3400 and all QFX), port-mode was renamed to interface-mode. A trunk port is built the same way but lists several VLAN members and, on ELS platforms, uses a native VLAN statement:

set interfaces ge-0/0/2 unit 0 family ethernet-switching interface-mode trunk
set interfaces ge-0/0/2 unit 0 family ethernet-switching vlan members [ sales voice mgmt ]
set interfaces ge-0/0/2 unit 0 family ethernet-switching native-vlan-id 1
show ethernet-switching interface ge-0/0/2 detail
show ethernet-switching table

Two verification habits save time later. First, show ethernet-switching interface <port> detail tells you the effective mode, the VLAN membership and the tagged/untagged state in one screen, which is faster than reading the configuration back. Second, after adding a VLAN to a trunk, confirm the peer actually learns MACs in that VLAN with show ethernet-switching table rather than assuming the change propagated; mistyped member lists are the classic cause of a "new VLAN that nobody can reach".

ELS vs Non-ELS: The One Difference That Bites

Everything on a current EX platform uses the Enhanced Layer 2 Software CLI. Older EX2200/EX4200/EX4500 units that were never migrated keep the legacy syntax, where a port is configured with port-mode access, VLAN membership is expressed as a family on the port rather than a named list, and some firewall-filter features behave differently. Before you paste a configuration from a forum post, check which world you are in:

show version | match "Junos:"
show configuration interfaces ge-0/0/1 | display set

If the running config shows family ethernet-switching interface-mode, the platform is ELS. Junos refuses to commit a mix of the two syntaxes on the same platform, which is helpful — the error message is confusing, but it always points at the same root cause.

Virtual Chassis Essentials

Virtual Chassis (VC) connects multiple switches into a ring and manages them as one logical device, simplifying loop prevention (no STP needed inside the VC) and improving fault tolerance. With a preprovisioned config, mastership priority is assigned automatically based on the selected role. Each member shows up as a separate FPC; the master's MST LED is solid green, the backup's blinks green. Alarms for a member appear only on the master and the member itself.

The practical consequence of that "separate FPC" statement is that interface names carry a member index: ge-0/0/1 is member 0, ge-1/0/1 is member 1, and so on. A VC therefore lets you cable servers into two different physical chassis and configure one logical port channel, which is why VC is so often used in closets where a second uplink switch would otherwise be an STP design problem. When you add a member later, preprovision it first so its ports appear in the configuration before the hardware does:

set virtual-chassis preprovisioned
set virtual-chassis member 0 role routing-engine
set virtual-chassis member 0 serial-number ABC123456789
set virtual-chassis member 1 role routing-engine
set virtual-chassis member 1 serial-number DEF987654321
set virtual-chassis member 2 role line-card
set virtual-chassis member 2 serial-number GHI555666777

Verify with show virtual-chassis and show virtual-chassis vc-port. If a member shows NotPrsnt, the serial number in the configuration does not match the hardware; if a link shows as a network port rather than a VC port, the dedicated VCP ports are not cabled or the set virtual-chassis vc-port statement is missing.

For roles, member numbering and the conversion procedure, see our Juniper EX Virtual Chassis configuration guide.

Routing and AAA Tips

OSPF: set router ID, define areas, mark interface lo0.0 passive, and use interface-type p2p on point-to-point links for fast recovery on short breakages.
AAA: no enable mode; use authentication-order [ radius ] and login classes with permissions. Locally defined users are unnecessary when RADIUS/TACACS is configured.
Config archival: use system archival with transfer-on-commit for automatic backups.

A minimal OSPF skeleton on an EX switch looks like this:

set routing-options router-id 192.0.2.10
set protocols ospf area 0.0.0.0 interface ge-0/0/24.0
set protocols ospf area 0.0.0.0 interface ge-0/0/24.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.1 interface irb.20
show ospf neighbor
show ospf interface detail
show route protocol ospf

The p2p interface type is the single highest-value OSPF line on a switch uplink. Without it, the adjacency is treated as a broadcast network, needs a DR/BDR election, and reacts to a link blip by tearing down the neighbour and waiting for the dead interval. With it, the neighbour is a point-to-point relationship that converges in seconds and does not pay for an election it never needed.

On the AAA side, the absence of an enable mode is the thing that surprises IOS engineers most. There is no privileged tier to reach, so authorisation is expressed through login classes instead: a user is assigned a class, and the class carries permission bits such as configure, network, view and shell. Keep at least one local account with a super-user class reachable over the console, and order the authentication methods so RADIUS is tried first and the local account is the fallback:

set system authentication-order [ radius password ]
set system radius-server 192.0.2.50 secret <shared-secret>
set system radius-server 192.0.2.50 timeout 3
set system archival configuration transfer-on-commit
set system archival configuration archive-sites "scp://backup@192.0.2.60:/configs"

Archival is easy to overlook and painful to reconstruct after a failure. With transfer-on-commit every committed configuration is pushed to the archive site, which gives you a version history that survives a device replacement. Pair it with a rescue configuration so that a remote mistake is recoverable from the box itself.

Everyday Operational Commands

show interfaces terse
show interfaces ge-0/0/1 extensive | match error
show configuration | display set
show chassis environment
show system alarms
show log messages | last 50
rollback 0
commit confirmed 5
commit and-quit

Two habits in that list are worth adopting immediately. commit confirmed 5 makes the change temporary: unless you run commit again within five minutes, Junos automatically rolls back to the previous configuration. Use it on every remote change that touches management access or routing. rollback 0 then commit reverts to the previously committed configuration, and show configuration | display set is the fastest way to confirm exactly what a commit will apply.

Common Pitfalls

Logging in as root and stopping at the shell prompt. Type cli.
Forgetting that exit from configuration mode discards uncommitted changes — there is no "write memory" step to fall back on.
Mixing ELS and non-ELS syntax on one platform; the commit fails with an error about the interface family.
Assuming a trunk port exists because the VLAN does. A VLAN with no members on a trunk is invisible to the peer.
Leaving me0 on DHCP after commissioning, so the switch changes management address on the next reboot.
Adding a VC member without preprovisioning it, then wondering why its ports are absent from the configuration.