If you have spent any time in the networking industry, you know there are two kinds of switching books: the academic ones that explain Spanning Tree as if it were quantum mechanics, and the vendor brochures that explain it as if it were already solved. This book sits in the gap between them.

It exists because thousands of engineers every year sit in front of an EX4300, an EX4400, or a Virtual Chassis and have to do something specific: design VLANs that don't break voice, prevent a contractor from blowing up Spanning Tree with a rogue switch, bring up an aggregation pair without a forwarding loop, and keep the network alive while a Routing Engine reboots. None of that is taught well by reading specs.

The book is also engineered around a specific certification, the Juniper Networks Certified Specialist—Enterprise Routing and Switching (JNCIS-ENT), and around the Junos Enterprise Switching two-day intermediate course (Junos OS Release 21.4R3, EX4300-24T reference platform). Every chapter is mapped to the published course objectives, and Appendix B gives you a one-page traceability matrix from each exam objective back to the exact subtopic that covers it.

What it is not: it is not a replacement for the Juniper Day One series, the Junos OS documentation set, or the official Education Services courseware. Those are excellent. This is the companion volume that sits on your desk while you study them, while you stand up your first lab, and while you sit in the testing centre.

Where I deviate from the official course outline, I do so to make the book read like a book rather than a slide deck. You will not find Day 1 and Day 2 dividers here; you will find chapters with numbered subtopics, just as you would in any classical engineering text. The lab walk-throughs are placed at the end of the chapter that introduces the relevant feature, so you can read, then practise, then move on.

Finally, a word on diagrams. The print and Kindle layout is deliberately black-and-white for body copy — high contrast, no eye-strain — while every figure is rendered in colour. If you are reading on a black-and-white reader, the figures degrade gracefully into clean line art. If you are reading in a browser or on a colour tablet, you will see them in their full palette. Either way, the goal is the same: when you close the book, you know how the EX4300 actually moves a frame.

— Abhijeet Kumar
April 2026

Three Reading Paths

Path 1 — The classroom path. Read straight through, Chapter 1 to Chapter 18. This mirrors the order Juniper teaches the material. Each chapter is self-contained but builds on the previous one. Expected effort: 25–35 hours over two weeks.

Path 2 — The exam-prep path. Read Chapters 1 through 16 in order, skim Chapters 17 and 18 (self-study material on Mist), then jump straight to Appendix E and take the 60-question mock exam. Re-read any chapter where you scored under 80%. Expected effort: 18–25 hours.

Path 3 — The reference path. Use the Table of Contents and Appendix A (CLI quick reference) as the entry points. Each subtopic is independently searchable; configurations are flagged with a code icon and a "Verify" companion block.

Box Conventions

The Lab Kit

You can complete every configuration in this book with one of three setups:

• Physical: Two or more Juniper EX4300-24T or EX4400 switches, an SRX or vMX as an upstream router, a few hosts (laptops or Raspberry Pis), one IP phone for the voice-VLAN labs.
• Virtual: The vJunos-Switch image on KVM, GNS3, or EVE-NG. Same Junos CLI; some hardware-only features (PoE, MACsec on certain ASICs) won't work.
• Cloud: Juniper vLabs (free, time-limited) or a paid AWS/GCP image with vJunos-Switch.

Where a feature only works on physical hardware, the chapter says so explicitly. Where the simulator behaves differently from real silicon (notably storm-control accounting and MACsec hardware offload), the difference is called out in a Production Warning box.

Conventions for Configuration Snippets

• Junos hierarchy is shown using the set command form, because it is the form used on the exam and in JTAC support cases.
• Comments inside snippets begin with ##.
• Variable elements are shown in <angle-brackets>. Replace the brackets and the placeholder.
• Output snippets are abbreviated with ... where lines are omitted; counts and numbers are shown in full.

A Note on Numbers

Every quantitative claim in this book — switching capacity, MAC table size, throughput in Mpps, default timer values, MTU ceilings — is taken from a primary source: the published Juniper TechLibrary documentation, the EX-series datasheets at the time of writing, the relevant IEEE standard, or 3GPP/IETF documents where applicable. Where a number is platform- or release-specific (for example, packet buffer sizes, which vary by ASIC generation and Junos release), the book directs you to the live datasheet rather than quoting a memorised value. If you find a number that disagrees with the current Juniper documentation for your platform and Junos release, trust the documentation. Errata are tracked at cafetele.com; please email [email protected] with a quote from the source so the next edition is sharper.

The Big Picture

The JNCIS-ENT certification (exam code JN0-351 at the time of writing) sits at the second rung of Juniper's Enterprise Routing and Switching certification track, above JNCIA-Junos and below JNCIP-ENT and JNCIE-ENT. Passing it tells employers that you can configure, troubleshoot, and operate enterprise-grade switching and routing on the Junos OS — not just understand it.

Format

What This Book Covers, by Blueprint Domain

The exam blueprint is divided into seven domains. The table below shows where each domain is covered in this book. The full traceability map — objective by objective — is in Appendix B.

Routing topics (OSPF, IS-IS, BGP, policy, multicast) and tunnels are tested on the JNCIS-ENT exam but lie outside the scope of the Junos Enterprise Switching course this book is built around. They are addressed in the companion volume Junos Routing for the Enterprise.

A Realistic Three-Week Study Plan

By the end of this chapter you will know: why the modern LAN is a switched LAN and not a shared one; the layout of an Ethernet frame as the EX4300 sees it; what transparent bridging means and why it does not need any configuration to work; how the MAC address table is built, aged, and used to make forwarding decisions; how to configure and verify Layer 2 interfaces in Junos OS 21.4R3; and how to read the output of show ethernet-switching table the way an exam-taker (and a JTAC engineer) does.

1.1 The Switched LAN Era

The Local Area Network started life as a shared medium. In the early 1980s, the original Ethernet (10BASE5, the “thick yellow cable”) put every station on the same piece of coax. Every transmission was heard by every station, and only one station could transmit at a time without colliding. The protocol that arbitrated this shared cable was called CSMA/CD — Carrier Sense, Multiple Access, with Collision Detection. As a network grew, the available bandwidth divided among all the participants and the collision rate climbed.

The first generation of upgrades replaced the thick yellow cable with a star topology around a central hub. A hub was a multiport repeater: a frame coming in on any port was electrically reproduced on every other port. The shared-medium nature was unchanged — every station still saw every frame, every transmission still risked a collision, and the entire connected hub stack was a single collision domain.

The breakthrough was the bridge — a device that connected two LAN segments and only forwarded a frame from one side to the other if it actually needed to. A bridge implemented the procedure that today we call transparent bridging. Initially used to connect two coax segments, the design was eventually scaled to dozens, then hundreds of ports. We stopped calling these multi-port bridges “bridges” and started calling them switches, but the underlying procedure is exactly the same.

A modern Layer 2 switch puts every port in its own collision domain. Two endpoints connected through a switch never share a wire and never compete for it. This is why every link is full-duplex (no collisions, transmission and reception happen simultaneously) and why CSMA/CD is now a historical curiosity. What remains shared is the broadcast domain: a broadcast or unknown-unicast frame is still flooded to every other port in the same VLAN. That distinction — collision domain per port, broadcast domain per VLAN — is the entire reason VLANs exist (Chapter 3).

1.2 Ethernet Frame Anatomy

The unit a switch forwards is the Ethernet frame. The format you almost always meet today is Ethernet II (also called DIX, after Digital, Intel and Xerox who specified it). Older 802.3 LLC and SNAP-encapsulated frames still exist on niche protocols but are rare on the modern wire.

Figure 1.2 lays out the on-wire bit order. The frame begins with a 7-byte preamble and a 1-byte start-frame delimiter — these are stripped by the receiving NIC and never make it to the switch’s forwarding logic. From there, the fields a switch actually looks at are six bytes of destination MAC, six of source MAC, two bytes of EtherType (or Length, in the rare 802.3 LLC case), 46–1500 bytes of payload, and a 4-byte CRC at the tail.

MAC address structure

A MAC address is 48 bits, conventionally written as six hexadecimal octets separated by colons (e.g. 00:50:56:c0:00:01) or hyphens. The high-order bit of the first octet is the I/G bit: 0 means individual (unicast), 1 means group (multicast). The next bit is the U/L bit: 0 means universally administered (the manufacturer’s OUI assigned by the IEEE), 1 means locally administered. The all-ones address ff:ff:ff:ff:ff:ff is the L2 broadcast.

1.3 Transparent Bridging

The procedure that moves a frame across a switch is the same procedure Radia Perlman’s 1985 specification described, the same procedure 802.1D codified, and the same procedure the EX4300’s Packet Forwarding Engine implements today. There are three rules. They are run in order, on every received frame, with no configuration required.

1. Learn the source. Take the source MAC address from the frame and the port the frame arrived on, and write that pair into the MAC address table. If an entry already exists for that source MAC, refresh its age. If the MAC was previously learned on a different port, update the table to point at the new port (this is a MAC move — we will revisit it in Chapter 12).
2. Look up the destination. Take the destination MAC and search the table.
   • If the destination is a group address (I/G = 1), flood the frame to every port in the VLAN except the one it came in on.
   • If the destination is unicast and we have a table entry, forward the frame out exactly that port (and nowhere else). This is the “unicast forwarding” or “known-unicast” path.
   • If the destination is unicast but the table has no entry, flood the frame to every port in the VLAN except the one it came in on. This is “unknown unicast flooding”.
3. Filter back to the source port. Whatever else happens, never send the frame back out the port it came in on. Without this rule the bridge would create a one-hop loop on every frame.

Three rules — learn, look up, filter the source port — and the entire L2 forwarding plane of an EX4300 falls out of them. There is nothing else to remember about transparent bridging.

The word “transparent” in the name is doing real work. The procedure is invisible to the endpoints: hosts do not know whether they are connected to a hub, a bridge, or a fifty-port switch — the frames they see are the frames they sent, with no encapsulation added or removed. Compare this to a router, which strips the L2 header and writes a new one for the next hop; a router is anything but transparent at L2.

1.4 The MAC Address Table

The table that powers Rule 1 and Rule 2 has many names. In Junos and on the EX4300 it is the Ethernet switching table; in Cisco IOS it is the CAM table; in 802.1Q parlance it is the filtering database or FDB. They are all the same thing: a key/value lookup from (VLAN ID, destination MAC) to egress port.

Each entry has a small set of attributes:

The age column is the one to watch. If an entry sits idle for the full 300 seconds, the EX deletes it and the MAC becomes “unknown” again. The next frame destined to that MAC will trigger a flood — until a return frame from the host re-learns its location. This is why a freshly powered-on host can receive a brief flood spike when its return traffic refreshes its MAC entry across all switches in the path.

1.5 Flooding, Filtering, and Forwarding

Three actions, one decision. Every frame the EX receives goes through the same flow:

This is the model the rest of the book is built on. Spanning Tree (Chapter 5) limits the topology so the flood path cannot loop. VLANs (Chapter 3) carve the broadcast domain. Storm control (Chapter 10) caps how much of the link a flood can occupy. Port security (Chapters 12–13) constrains what the “learn” step is allowed to do. Every one of those features is a refinement of this single decision tree.

1.6 Configuring Layer 2 Interfaces in Junos

An EX4300 interface ships, out of the box, configured for access mode in VLAN default. Plug two laptops in and they will reach each other with no configuration. That is convenient for the first power-on but not what we want once the design is known.

The Junos hierarchy that controls a switching interface lives under [edit interfaces <name> unit 0 family ethernet-switching]. The minimum knobs are port-mode (access or trunk) and vlan members. The full sequence to put port ge-0/0/3 into access mode in VLAN employees, on Junos 21.4R3, looks like this:

root@ex1> configure
## define the VLAN once, then attach interfaces to it
root@ex1# set vlans employees vlan-id 100
root@ex1# set interfaces ge-0/0/3 unit 0 family ethernet-switching interface-mode access
root@ex1# set interfaces ge-0/0/3 unit 0 family ethernet-switching vlan members employees
root@ex1# commit and-quit

For a trunk — a port that carries multiple VLANs to a downstream switch or hypervisor — the syntax differs in two places: interface-mode becomes trunk, and the vlan members takes a list:

root@ex1# set interfaces ge-0/0/47 unit 0 family ethernet-switching interface-mode trunk
root@ex1# set interfaces ge-0/0/47 unit 0 family ethernet-switching vlan members [ employees voice mgmt ]
root@ex1# set interfaces ge-0/0/47 native-vlan-id 99     ## untagged frames belong to VLAN 99
root@ex1# commit

Two things to call out. First, vlan members all is legal and means “every VLAN currently configured on this switch” — it is a convenient default but a security risk on edge trunks because adding a new VLAN later automatically extends to that link. Prefer an explicit list. Second, native-vlan-id is the configuration that controls how the trunk handles untagged frames. We will treat this in depth in Chapter 4.

1.7 Monitoring the Ethernet Switching Table

Once the configuration is committed, three operational commands tell you everything you need.

root@ex1> show ethernet-switching table
root@ex1> show ethernet-switching interface
root@ex1> show vlans

A typical output of show ethernet-switching table on Junos 21.4R3 looks like this:

root@ex1> show ethernet-switching table
MAC database for VLAN employees, MAC age timer 300 s
Routing instance: default-switch
   Vlan                MAC                 MAC      Logical
   name                address             flags    interface
   employees           aa:aa:aa:00:00:01   D        ge-0/0/3.0
   employees           aa:aa:aa:00:00:02   D        ge-0/0/3.0
   employees           bb:bb:bb:11:22:33   D        ae0.0
   employees           00:50:56:c0:01:7e   S        ge-0/0/24.0
   employees           *                   Flood    All-members

Reading the flags column: D = Dynamically learned, S = Statically configured, Flood = the wildcard fallback used when no entry matches. The wildcard row is always last and tells you what the EX will do for an unknown unicast in this VLAN — here, flood to every member port.

Two operational details often asked on the exam:

• Clearing entries: clear ethernet-switching table wipes all dynamic entries (static entries survive). It is harmless but causes a brief flood spike as the table re-learns. Useful when troubleshooting.
• Static entries: set vlans employees mac-table 00:50:56:c0:01:7e interface ge-0/0/24.0 pins a MAC permanently to a port. Static entries do not age and override later dynamic learning attempts.

1.8 Lab 1 — Implementing Layer 2 Switching

Topology

Figure 1.5 shows the lab. One EX4300 switch (or vJunos-Switch instance), four hosts, and a single VLAN tag 99 carried over a trunk to a peer switch (or simulator).

Step-by-step

1. Power on the EX, open a console session, log in as root, and enter configure.
2. Define the three VLANs:

   [edit]
   set vlans employees vlan-id 100
   set vlans guests    vlan-id 200
   set vlans mgmt      vlan-id 99

3. Configure the four access ports (using a wildcard range to save typing):

   set interfaces interface-range ACCESS-100 member-range ge-0/0/1 to ge-0/0/2
   set interfaces interface-range ACCESS-100 unit 0 family ethernet-switching interface-mode access
   set interfaces interface-range ACCESS-100 unit 0 family ethernet-switching vlan members employees
   
   set interfaces interface-range ACCESS-200 member-range ge-0/0/3 to ge-0/0/4
   set interfaces interface-range ACCESS-200 unit 0 family ethernet-switching interface-mode access
   set interfaces interface-range ACCESS-200 unit 0 family ethernet-switching vlan members guests

4. Configure the trunk:

   set interfaces ge-0/0/47 unit 0 family ethernet-switching interface-mode trunk
   set interfaces ge-0/0/47 unit 0 family ethernet-switching vlan members [ employees guests ]
   set interfaces ge-0/0/47 native-vlan-id 99

5. commit and-quit.

Verification

Generate traffic from PC‑A to PC‑C (both in VLAN 100). On the switch, run:

root@EX1> show ethernet-switching table | match employees

You should see two dynamic entries, one per host MAC. Now generate traffic from PC‑A to PC‑B (different VLANs); the frames should be dropped at L2 because there is no L3 gateway between the VLANs in this lab. Check the interface counters with show interfaces ge-0/0/1 extensive and confirm the broadcast count rises while the unicast count for the cross-VLAN flow stays flat.

Common pitfalls

• Forgetting to attach the unit-0 stanza — an interface without family ethernet-switching on unit 0 is administratively up but does no L2 forwarding.
• Mixing port-mode (pre-ELS) and interface-mode (ELS) in the same config — the commit will fail. ELS is exclusive on EX4300 from Junos 14.1X53 onward.
• Putting the trunk in vlan members all on a customer-facing edge port. It works, but every new VLAN you add later silently lands on that customer link.

Chapter 1 looked at one frame at a time. This chapter looks at the box that has to handle several million of them per second. We start by fixing the vocabulary — the words like line-rate, oversubscription, buffering, store-and-forward, cut-through — that show up on the EX4300 datasheet and on the JNCIS-ENT exam. Then we walk through the EX4300 itself: the Packet Forwarding Engine, the Routing Engine, and how the two cooperate. We finish with a practical guide to choosing between EX2300, EX3400, EX4300, EX4400, EX4600 and EX9200 for a given site.

2.1 Switching Terminology and Vocabulary

A surprising number of arguments in network design rooms boil down to people using the same word for different things. This section is the small dictionary you need to read the rest of the book without ambiguity.

2.2 Design Considerations — Latency, Buffering, Oversubscription

The three numbers you should be able to defend for any switch you put in a rack are port-to-port latency, buffer per port, and the oversubscription ratio of the box and of the rack as a whole. They are tied to each other: the deeper the buffer, the more bursty traffic the box can absorb without drops, but the higher the worst-case latency. The lower the oversubscription, the more headroom for bursts but the higher the cost per port.

Latency

For a switched enterprise LAN, port-to-port latency is dominated by serialization delay (the time to clock a frame onto the wire) and by store-and-forward time. On a 1 Gbps link, a 1500-byte frame takes 12 µs to serialise; on 10 Gbps, 1.2 µs. A typical EX4300 in store-and-forward mode adds 1–3 µs of switching latency on top of that. For voice and video, 5–10 ms of one-way path latency is fine; the switch contribution is negligible.

Where it matters is in the data centre — high-frequency trading, low-latency RDMA, GPU-to-GPU traffic. There, the EX4300 is the wrong product (Juniper sells QFX5120/5130 with cut-through forwarding for that role). You will not see those products on the JNCIS-ENT exam, but a senior engineer should know which family solves which problem.

Buffering and microbursts

A “microburst” is a few hundred microseconds of traffic that exceeds egress capacity, even though the long-term average is well within budget. Microbursts are invisible to SNMP polling (5-minute averages flatten them out) but obvious to the application: a TCP retransmit here, a video glitch there.

The EX4300 has a modest shared packet buffer per PFE, dynamically allocated across queues; the precise size is published in the model’s datasheet. That is sufficient for normal enterprise access traffic with QoS-marked voice and video. For a top-of-rack role with heavy storage or east-west traffic, you would step up to an EX4600 or move to a QFX5120, where the deeper buffers matter more — again, sizing should come from the live datasheet rather than memory.

Oversubscription, sized end-to-end

Three rules of thumb worth memorising:

• Access → Distribution: 4 : 1 or better. Above 8 : 1 you start seeing TCP throughput degradation under load.
• Distribution → Core: 2 : 1 or better. The core should never be the bottleneck.
• Worst-case under failure: 8 : 1 or better. Loss of one of two uplinks must not push you into double-digit ratios.

2.3 The Junos Enterprise Switch Portfolio

The EX family at the time of writing spans the small office to the large campus core. The matrix below is the one to internalise — for the JNCIS-ENT exam, you do not need port counts memorised, but you must know the role each model fills.

2.4 EX4300 Architecture Deep-Dive

An EX4300 is, internally, two halves that talk to each other over an internal bus: the Routing Engine (RE) — a CPU that runs Junos OS and handles management, configuration, and routing protocols — and the Packet Forwarding Engine (PFE) — an ASIC plus its surrounding microcode that does the per-frame work in hardware.

What runs where

Knowing which work happens on the RE and which on the PFE is the difference between an engineer who can troubleshoot a busy switch and one who is guessing. The general rule: per-frame work is done in the PFE; per-flow or per-protocol work is done on the RE.

The internal bus and the kernel

The RE talks to the PFE via the Junos kernel (kernel on FreeBSD) using a process called ksyncd. When you commit a configuration, the new MAC table policy, ACL, or VLAN definition is compiled by mgd, handed to the kernel, and the kernel pushes it to the PFE’s ASIC. This whole pipeline takes a few hundred milliseconds for a small commit and a few seconds for a large one. The exam will not ask you about ksyncd by name, but understanding that this push is asynchronous explains why commit complete sometimes returns before the new configuration is fully visible in show route.

2.5 Choosing the Right Platform

The matrix below is a working starting point for a campus or branch design. It is not a substitute for sizing the actual traffic, but it covers most enterprise scenarios.

Reading a datasheet

When you open the Juniper EX4300 datasheet, six numbers should jump out:

1. Switching capacity in Gbps full-duplex (e.g. 128 Gbps for the 24-port model). Compare against ports × speed.
2. Throughput in Mfps. Should equal capacity / (84 × 8) for non-blocking.
3. Buffer per PFE. Read it from the datasheet for the model and serial-class you are deploying — numbers vary by ASIC generation and should not be quoted from memory.
4. MAC table size. The Juniper EX4300 datasheet quotes 64,000 entries. Always confirm the exact figure for the platform and Junos release you target. This is the upper bound on hosts the box can serve as L2.
5. FIB size (IPv4 / IPv6 routes). Matters if the box is a distribution layer carrying the campus IGP.
6. Power draw at idle, at typical, at PoE-loaded. Drives rack-power planning.

A VLAN is a single idea applied with discipline: break one physical L2 network into many independent broadcast domains, by writing a 12-bit number into the frame. Everything else — access ports, trunks, the native VLAN, the question of whether to use VLAN 1 — flows from that idea. By the end of this chapter you will know the wire format, the EX4300 implementation, the Junos configuration, and the half-dozen ways VLANs cause outages in production.

3.1 Why VLANs?

Imagine a switch with 48 ports, no VLANs, and 1 000 hosts spread across forty similar switches. Every broadcast from any host reaches every other host, every ARP request floods to the whole estate, and every misbehaving NIC can take the network down. There are three things you cannot do without VLANs:

• Limit the broadcast blast radius. Without VLANs, a faulty NIC sending one million broadcasts per second saturates the entire LAN. With VLANs, that flood is contained to one VLAN.
• Separate trust boundaries. Production servers, guest Wi-Fi, IP phones, building HVAC, and CCTV all share copper but should not share an L2 segment. A VLAN gives each its own private broadcast domain on the same physical infrastructure.
• Move users without re-cabling. A laptop that moves from the second floor to the third stays in the same VLAN, gets the same IP, and reaches the same printer — even though it is now plugged into a different switch.

The mechanism behind all three is identical: every frame carries a 12-bit VLAN tag, and the switch refuses to forward a frame from one VLAN to another at L2. To cross VLANs you must go up to L3, through a router or a Layer-3-capable switch (Chapter 4 covers that path).

3.2 802.1Q Tagging Explained

The mechanism is a 4-byte header inserted between the Source MAC and the EtherType of the original frame. The IEEE published it as 802.1Q in 1998, and the on-wire format has not changed since.

The frame goes through life in two states

A frame inside an EX4300 lives in one of two states at any moment: tagged (4-byte 802.1Q header present, VID set) or untagged (no tag at all). The state changes at the boundary between the host and the access port, and between two trunked switches:

• Host → access port: the host typically sends an untagged frame. The access port adds the tag with the configured VLAN’s VID and forwards internally. Internal forwarding decisions are made on the tagged form.
• Access port → host: the EX strips the tag before transmission. The host sees a plain Ethernet frame, exactly as if VLANs did not exist.
• Trunk → trunk: the tag is preserved. Both ends know the VID.
• Trunk → access (different switch): the receiving access port verifies the VID matches and strips the tag.

The host never sees a tag in the standard case. The exception is when the host’s NIC is itself configured for VLAN tagging (typical for hypervisor uplinks or for an IP phone with a daisy-chained PC); in that case the access port becomes a trunk, and we configure it as such.

3.3 Access Ports vs. Trunk Ports

An EX4300 interface can play exactly one of three L2 roles at a time:

Access mode under the hood

When you configure interface-mode access; vlan members employees, the EX does four things on every received frame:

1. If the frame arrives tagged, drop it. (An access port refuses tagged frames by default. Some platforms let you opt in; on the EX4300 the safe default is to drop.)
2. If the frame arrives untagged, internally tag it with VLAN 100 (the VID associated with the employees VLAN).
3. Make the forwarding decision in the tagged form (Chapter 1, three rules).
4. Strip the tag on egress to any other access port in VLAN 100.

Trunk mode under the hood

When you configure interface-mode trunk; vlan members [ employees voice mgmt ]:

1. If the frame arrives tagged with a VID in the member list, accept it and forward.
2. If the frame arrives tagged with a VID not in the member list, drop it. (This is how a trunk enforces VLAN membership.)
3. If the frame arrives untagged and a native-vlan-id is configured, place it in that VLAN. Otherwise drop it.
4. Egress: tagged frames go out tagged, except frames in the native VLAN, which leave untagged.

3.4 Configuring VLANs in Junos

VLANs are declared once at [edit vlans] and then attached to interfaces by name. Best practice is to give every VLAN a memorable name and reserve numeric VIDs for the actual traffic plan (voice low, data middle, mgmt high).

[edit]
set vlans employees vlan-id 100 description "Corporate users"
set vlans voice     vlan-id 200 description "IP phones"
set vlans guests    vlan-id 300 description "Visitor Wi-Fi"
set vlans mgmt      vlan-id 99  description "OOB / native"

## attach an access port
set interfaces ge-0/0/3 unit 0 family ethernet-switching interface-mode access
set interfaces ge-0/0/3 unit 0 family ethernet-switching vlan members employees

## attach a trunk
set interfaces ge-0/0/47 unit 0 family ethernet-switching interface-mode trunk
set interfaces ge-0/0/47 unit 0 family ethernet-switching vlan members [ employees voice guests ]
set interfaces ge-0/0/47 native-vlan-id 99
commit and-quit

VLAN ranges and bulk operations

For a real campus you rarely declare four VLANs. The two patterns that scale are VLAN ranges and interface-ranges:

## a contiguous span of VLANs (e.g. one VLAN per floor, IDs 100..120)
set vlans floors vlan-id-list 100-120

## one config block applied to many interfaces
set interfaces interface-range ACCESS-EMP member-range ge-0/0/0 to ge-0/0/23
set interfaces interface-range ACCESS-EMP unit 0 family ethernet-switching interface-mode access
set interfaces interface-range ACCESS-EMP unit 0 family ethernet-switching vlan members employees

## explicit member list (non-contiguous)
set interfaces interface-range UPLINKS member ge-0/0/47
set interfaces interface-range UPLINKS member xe-0/2/0
set interfaces interface-range UPLINKS unit 0 family ethernet-switching interface-mode trunk
set interfaces interface-range UPLINKS unit 0 family ethernet-switching vlan members all

3.5 Monitoring VLAN State

Three operational commands answer almost every VLAN question on Junos:

root@ex1> show vlans
root@ex1> show vlans extensive
root@ex1> show ethernet-switching interface
root@ex1> show interfaces ge-0/0/47 detail | match vlan

show vlans in summary form is the “is this VLAN there and what ports are in it” question:

root@ex1> show vlans
Routing instance        VLAN name      Tag      Interfaces
default-switch          employees      100
                                                ge-0/0/0.0*, ge-0/0/3.0*, ge-0/0/47.0*
default-switch          voice          200
                                                ge-0/0/47.0*
default-switch          guests         300
                                                ge-0/0/24.0*, ge-0/0/47.0*
default-switch          mgmt           99
                                                ge-0/0/47.0*

The asterisk after each interface name means the link is currently up. A VLAN listed with no asterisks against any interface is configured but has no operational members — usually a sign that the upstream cabling has not been done yet, or that the trunk to the upstream switch is down.

For a deeper look, show vlans extensive prints the per-interface tagging state, the dynamic MAC count per VLAN, the STP state per port (Chapters 5–7), and the configured ageing time. It is the right command to paste into a JTAC ticket.

show ethernet-switching interface approaches the same data from the other direction — one row per port, summarising the port’s mode, its VLAN list, its STP state, and any port-security state:

root@ex1> show ethernet-switching interface
Interface  State  VLAN members            Tagging   Blocking
ge-0/0/0   up     employees(100)          untagged  unblocked
ge-0/0/3   up     employees(100)          untagged  unblocked
ge-0/0/24  up     guests(300)             untagged  unblocked
ge-0/0/47  up     employees(100), voice(200),
                  guests(300)             tagged    unblocked
                  mgmt(99)                untagged  unblocked  <-- native

Two things to notice. The trunk shows three tagged VLANs and one untagged (the native, VLAN 99). And every port’s blocking state is unblocked, which is what you want when STP is healthy — we will revisit that column in Chapter 6.

3.6 Common VLAN Pitfalls

The same five problems account for nearly every VLAN incident an enterprise will see. They are worth memorising both for the exam and for the on-call shift.

Pitfall 1 — Forgetting unit 0

An EX interface configured without unit 0 family ethernet-switching is administratively up but has no L2 personality. The frame arrives, the PFE has nowhere to put it in the MAC table, the frame is dropped, and there is no obvious error. Always commit a complete unit 0 block.

Pitfall 2 — VLAN configured on the switch but not on the trunk

You can declare vlans engineering vlan-id 400 all you like; if the trunk to the upstream switch does not list engineering in its vlan members, frames in VLAN 400 will not cross. show vlans on each switch will show engineering with no operational interface other than the local access port, and end-users will report “no DHCP” or “no gateway”.

Pitfall 3 — Native-VLAN mismatch

If switch A’s trunk uses native-vlan-id 99 and switch B’s trunk uses native-vlan-id 1, frames sent untagged from A end up in switch B’s VLAN 1 (a different broadcast domain). This is “VLAN hopping” the easy way. The fix: native VLANs must match end-to-end, or be configured as tagged on both sides (so untagged frames are dropped).

Pitfall 4 — VLAN 1 leakage

By convention, switches default to VLAN 1 for control-plane frames they generate (LLDP, LACP, STP). Many vendors also default the native VLAN to 1. The combination means that a misconfigured trunk to a third-party switch can put production data into VLAN 1 unexpectedly. The defensive move is to never put real users in VLAN 1 and to set native-vlan-id to a dedicated, unused VID like 999 or 4090.

Pitfall 5 — Reserved IDs (0, 4095) and the 4094 ceiling

A 12-bit VID has 4096 possible values, but VLAN 0 means “priority-tagged, no VLAN” and VLAN 4095 is reserved by the IEEE. The usable range is 1–4094. Beyond that you need to plan for Q-in-Q (double-tagging), VXLAN, or EVPN, none of which are on the JNCIS-ENT switching exam but all of which are valid follow-on topics.

Pitfall 6 — Forgetting the L3 gateway

VLANs work; users in VLAN 100 cannot reach users in VLAN 200; and the help-desk ticket reads “the network is broken.” Inter-VLAN traffic needs an L3 device. On Junos, the standard pattern is an IRB interface on the EX itself — we configure that in the next chapter.

Chapter 3 left us with three different VLANs and no way for users in one to talk to users in another. This chapter closes those gaps. We start with the voice VLAN: how an IP phone with a PC daisy-chained behind it gets its own auto-provisioned VLAN through LLDP-MED. Next we revisit the native VLAN — what it really is, and the two safe ways to handle untagged frames on a trunk. Finally we configure inter-VLAN routing on the EX4300 itself using an Integrated Routing and Bridging (IRB) interface, the standard pattern for letting a Layer 2 switch act as a Layer 3 default gateway. Lab 2 puts all three pieces together.

4.1 Voice VLAN Concepts

A modern IP phone has two Ethernet ports: an uplink that goes back to the access switch, and a passthrough that carries the user’s PC. Both phone and PC live on the same physical wire to the switch, and the design problem is to keep their traffic separated — voice in its own VLAN with its own QoS markings, data on the regular employee VLAN.

The mechanism is straightforward. The phone tags its own RTP and SIP traffic with the voice VLAN’s VID; it passes through the PC’s traffic untagged. The access port on the EX therefore needs to do two jobs at once on the same physical interface:

• Accept tagged frames on one VLAN (the voice VLAN), as a trunk would.
• Accept untagged frames on a different VLAN (the data VLAN), as an access port would.

This is what Junos calls a VoIP-enabled access port. Configuration lives at the [edit switch-options voip] hierarchy: you keep the interface itself in plain access mode for the data VLAN, then attach a voip profile to it that names the voice VLAN. The phone learns the VID either by static configuration (rare) or by listening to LLDP-MED on power-up (the standard method).

4.2 LLDP-MED for Auto-Provisioning Phones

LLDP (Link Layer Discovery Protocol, IEEE 802.1AB) is a vendor-neutral discovery protocol; LLDP-MED is the Media Endpoint Discovery extension defined by ANSI/TIA-1057. The MED extension lets the switch tell endpoints (typically phones, but also wireless APs and other appliances) about the network they have just plugged into — including the voice VLAN to use, the QoS markings expected, and a location string for emergency services.

On EX4300, the factory-default configuration enables LLDP and LLDP-MED on every interface, so a brand-new switch shipped from Juniper will already advertise LLDP-MED frames the moment a phone boots. You configure LLDP-MED at the [edit protocols lldp-med] hierarchy and turn it on per interface:

## EX4300 ships with LLDP and LLDP-MED enabled on all interfaces.
## You only need this if the factory-default has been overridden.
[edit]
set protocols lldp interface all
set protocols lldp-med interface ge-0/0/2

The LLDP-MED handshake is short. The switch periodically sends LLDP frames; once it sees an MED-capable peer (the phone), it adds the MED-specific TLVs — including a Network Policy TLV that carries the voice VLAN ID, priority, and DSCP. The phone reads the TLV, applies the tag, and starts using the voice VLAN.

For Junos OS to attach the right policy to the LLDP-MED Network Policy TLV, you configure VoIP at the [edit switch-options voip] hierarchy, naming the voice VLAN and (optionally) the QoS forwarding class:

## 1) Define the data VLAN and the voice VLAN
[edit]
set vlans data-vlan  vlan-id 77
set vlans voice-vlan vlan-id 99

## 2) Put the access port in the data VLAN as normal
set interfaces ge-0/0/2 unit 0 family ethernet-switching interface-mode access
set interfaces ge-0/0/2 unit 0 family ethernet-switching vlan members data-vlan

## 3) Attach the voice VLAN to the same interface via switch-options voip
set switch-options voip interface ge-0/0/2.0 vlan voice-vlan
set switch-options voip interface ge-0/0/2.0 forwarding-class assured-forwarding

## 4) Make sure LLDP-MED is enabled on the interface (default on EX4300)
set protocols lldp-med interface ge-0/0/2
commit

Verifying LLDP-MED operation

root@ex1> show lldp neighbors
root@ex1> show lldp neighbors detail
root@ex1> show lldp local-information
root@ex1> show ethernet-switching interface ge-0/0/2 detail

The show lldp neighbors detail output is the most useful for VoIP debugging: it lists each peer’s chassis ID, port description, and (for MED peers) the Network Policy TLV with the voice VLAN ID it received. If the phone is showing “no service” on its display, this command tells you whether the phone has even seen the LLDP-MED frame from the EX.

4.3 Native VLAN Behaviour

The native VLAN is the answer to a single question: what does a trunk port do with an untagged frame?

On an access port the answer is obvious — the port has exactly one VLAN, untagged frames are tagged internally with that VLAN’s VID, and tagged frames are dropped. On a trunk port, where multiple VLANs are expected, an untagged frame has no VID to associate with. There are two safe answers:

1. Drop it. Configure the trunk so that every frame must arrive tagged. Untagged frames are discarded. This is the most secure choice and is the right default for trunks between two switches that you control on both ends.
2. Place it in a designated VLAN. Configure native-vlan-id on the trunk; untagged ingress frames are tagged with that VID internally, and frames egressing in that VLAN leave the trunk untagged. The native VLAN is typically used for legacy management traffic, for hubs that cannot tag, or for the voice/data overlay on a phone-to-switch link.

The Junos configuration for both cases:

## Option 1: trunk where untagged frames are placed in VLAN 99
[edit]
set interfaces ge-0/0/47 unit 0 family ethernet-switching interface-mode trunk
set interfaces ge-0/0/47 unit 0 family ethernet-switching vlan members [ data-vlan voice-vlan mgmt ]
set interfaces ge-0/0/47 native-vlan-id 99     ## untagged ingress -> VLAN 99

## Option 2: trunk where untagged frames are simply dropped
## (do not set native-vlan-id; configure both ends to always tag)
set interfaces ge-0/0/48 unit 0 family ethernet-switching interface-mode trunk
set interfaces ge-0/0/48 unit 0 family ethernet-switching vlan members [ data-vlan voice-vlan mgmt ]
## (no native-vlan-id statement -> untagged frames are dropped)
commit

4.4 Inter-VLAN Routing with IRB

VLANs at L2 are deliberately isolated — that is the entire point. To let one VLAN talk to another, traffic has to go up to L3 and be routed. The traditional answer was a separate router on a stick: a single physical link between switch and router carrying every VLAN as 802.1Q tags, with the router holding a sub-interface and a default-gateway IP for each one. It worked but added a hop, a cable, and a device.

The modern answer is to give the switch itself a Layer 3 personality. On Junos, this is done with an IRB interface — Integrated Routing and Bridging. An IRB interface is a logical L3 interface that lives inside the switch and is bound to a VLAN; the switch can then route traffic out of that VLAN to any L3 destination just like a router would.

Juniper’s definition is concise: an IRB interface enables the switch to recognise which packets are being sent to local L2 addresses (so they are bridged) and which need to be routed to a remote L3 destination (so they are routed). The switch decides per-packet, in hardware on the EX4300, with no detour to a separate router.

4.5 IRB vs. RVI vs. Sub-Interfaces

If you have come from another vendor, three terms refer to roughly the same idea but differ in detail:

4.6 Configuring and Verifying IRB

The Juniper-documented procedure for configuring an IRB in ELS is exactly four set commands per VLAN:

[edit]
## 1) Define the VLAN
set vlans data-vlan vlan-id 100

## 2) Put one or more access/trunk ports into the VLAN
set interfaces ge-0/0/3 unit 0 family ethernet-switching vlan members data-vlan

## 3) Create the IRB logical interface with an IP address
set interfaces irb unit 10 family inet address 192.168.10.1/24

## 4) Bind the VLAN to the IRB logical unit
set vlans data-vlan l3-interface irb.10
commit

Repeat the IRB-and-binding pair for every VLAN that needs a default gateway. The unit number on the IRB is administrative — many designs use the VLAN ID as the unit number (so VLAN 100 binds to irb.100) for readability, but the only hard rule is uniqueness inside the chassis.

A small but important fact, from the Juniper documentation: you can configure only one IRB logical interface for each VLAN. Two IRB interfaces tied to the same VLAN is rejected at commit. If your design needs two L3 personalities on one VLAN (typical for VRRP or for service redirection), the right pattern is one IRB plus one or more secondary addresses, not two IRBs.

root@ex1> show interfaces irb terse
Interface             Admin Link Proto    Local                 Remote
irb                   up    up
irb.10                up    up   inet     192.168.10.1/24
irb.20                up    up   inet     192.168.20.1/24

root@ex1> show vlans data-vlan extensive | match l3-interface
  L3 Interface: irb.10

root@ex1> show route 192.168.20.0/24
inet.0: routes
192.168.20.0/24    *[Direct/0] 00:01:23
                    >  via irb.20

Three things to look at, in order: the IRB is administratively and operationally up; the VLAN is bound to the right IRB unit; and a connected route appears in inet.0 with irb.N as the next hop. If any of those is wrong, the symptom upstairs will be “ping gateway from a host fails” or “ARP times out”.

Jumbo frames are supported on the IRB up to 9216 bytes, matching the rest of the EX4300 platform. If you need jumbo across the L3 boundary, configure family inet mtu 9216 on the IRB unit; otherwise the IRB inherits the default IPv4 MTU.

4.7 Lab 2 — Implementing Virtual Networks

Topology

One EX4300, one IP phone, one daisy-chained PC, and one host in a separate access port for the data VLAN.

Step-by-step

1. Define the two VLANs:

   set vlans data-vlan  vlan-id 100
   set vlans voice-vlan vlan-id 200

2. Put the access ports into the data VLAN:

   set interfaces interface-range ACCESS-DATA member-range ge-0/0/0 to ge-0/0/23
   set interfaces interface-range ACCESS-DATA unit 0 family ethernet-switching interface-mode access
   set interfaces interface-range ACCESS-DATA unit 0 family ethernet-switching vlan members data-vlan

3. Attach the voice VLAN to the phone’s port via switch-options voip:

   set switch-options voip interface ge-0/0/2.0 vlan voice-vlan
   set switch-options voip interface ge-0/0/2.0 forwarding-class assured-forwarding

4. Ensure LLDP-MED is enabled on that port (factory default on EX4300, but make it explicit):

   set protocols lldp interface all
   set protocols lldp-med interface ge-0/0/2

5. Create the two IRB units and bind them:

   set interfaces irb unit 10 family inet address 192.168.10.1/24
   set interfaces irb unit 20 family inet address 192.168.20.1/24
   set vlans data-vlan  l3-interface irb.10
   set vlans voice-vlan l3-interface irb.20

6. commit and-quit.

Verification

• show vlans — data-vlan and voice-vlan both have at least one member interface marked operationally up.
• show interfaces irb terse — irb.10 and irb.20 are up/up.
• show lldp neighbors detail — the phone appears as a peer; the Network Policy TLV reports VLAN 200 with the DSCP value implied by the assured-forwarding forwarding class.
• show route 192.168.20.0/24 — the connected route lists irb.20 as the egress.
• From the daisy-chained PC: ping 192.168.20.1 succeeds (you are pinging the voice gateway from the data VLAN, through the IRB).
• From the phone’s display, the voice VLAN should now show as “200” or whatever VID you configured.

Common pitfalls

• Phone shows no service. Check show lldp neighbors detail first — if the phone is not visible as a peer, LLDP-MED is not reaching it. Confirm set protocols lldp-med interface ge-0/0/2 is committed and that the phone supports LLDP-MED (most modern Cisco, Polycom, and Yealink phones do).
• Phone lands in the data VLAN by mistake. Confirm that set switch-options voip interface ge-0/0/2.0 vlan voice-vlan is committed, not just the access-mode vlan members data-vlan line.
• IRB stays down. An IRB needs at least one operational member port in the bound VLAN. Plug a host in or bring up a trunk that carries the VLAN.
• Inter-VLAN ping fails but each VLAN works on its own. The IRB IP must match the host’s default gateway exactly; confirm the host has the right gateway via DHCP or static.

Bridges learn from any frame they see. That fact, combined with two parallel links between the same pair of switches, is enough to melt a network in seconds. The fix is a small distributed protocol that elects a root, prunes redundant links into a forwarding-blocked state, and reacts to topology changes in a controlled way. The 1985 version was Spanning Tree Protocol; the 1998 standard was IEEE 802.1D; and the version every modern Junos switch runs by default is Rapid Spanning Tree Protocol, defined originally in IEEE 802.1w and folded into 802.1D-2004. This chapter walks through what RSTP does, why it does it, and the vocabulary you need to read its output.

5.1 Why Spanning Tree Exists

Imagine two switches, A and B, connected by two parallel cables — a perfectly reasonable design for redundancy. A host plugged into A sends a broadcast (an ARP request, say). Switch A floods it on every other port, including both links to B. Switch B receives the broadcast on the first link, floods it on every other port (including the second link back to A); A receives it again, floods it again, and now the loop is closed. The broadcast circulates indefinitely, multiplying because every traversal hits more switches and gets re-flooded.

Three things go wrong, all at once:

• Broadcast multiplication. Every frame is amplified by every traversal. CPU and link utilisation climb to 100% in seconds.
• MAC table thrash. The same source MAC arrives on two different ports as the loop circulates. The switches keep updating their tables to point at whichever port saw the frame last. Forwarding becomes effectively random.
• No TTL at L2. Unlike IP, an Ethernet frame has no time-to-live field. Once a frame is in a loop, nothing inherent to the protocol stops it.

The problem is not the redundant cable; redundancy is what we want. The problem is that a redundant L2 path cannot be allowed to forward simultaneously with the primary. We need a way to keep the second cable plugged in but logically inactive, ready to take over if the primary fails.

Spanning Tree solves this by treating the network as a graph and pruning it down to a tree — a connected, loop-free subgraph that touches every switch. When the primary path of any link fails, the protocol re-runs and the previously blocked port comes alive in seconds.

5.2 STP Operations — BPDUs, Roots, Costs

Spanning Tree builds the tree by exchanging small control frames called Bridge Protocol Data Units (BPDUs). Every bridge sends its current view of the topology out every port on a regular timer; every other bridge listens, compares the incoming BPDU to its own view, and updates if the incoming view is “better”. After a few rounds, the protocol converges on a single tree that every switch agrees on.

The bridge ID

Every switch advertises a 64-bit Bridge ID made of two parts:

• The bridge priority — configurable. On Junos, the default is 32,768; the valid range is 0 through 61,440 in increments of 4,096. (These are not arbitrary; they come from the way the priority field shares its 16 bits with a 12-bit System ID Extension.)
• The bridge’s MAC address — not configurable.

Bridges compare bridge IDs lexicographically, lower wins. The switch with the lowest Bridge ID becomes the root bridge. Because all priorities default to 32,768, the tie-breaker is the MAC address, which means whichever switch happens to have the lowest MAC will become root by default. This is rarely what you want; in any real design you set the priority explicitly so that a chosen device wins root election deterministically.

Path cost

Once the root is elected, every other switch needs to figure out the cheapest path back to it. Each port has a path cost that depends on link speed; the switch sums the cost along each candidate path and chooses the lowest. The IEEE 802.1D-2004 recommended values (the “long” cost form, used by RSTP) are:

The BPDU itself

An RSTP BPDU is a multicast frame with destination MAC 01:80:c2:00:00:00 — the IEEE-reserved bridge group address. The payload carries the sender’s root ID, root path cost, sender bridge ID, sender port ID, port role, and a flags byte that includes the topology-change bit. The exact byte layout is in IEEE 802.1D-2004 §17 — you do not need to memorise it for the JNCIS-ENT exam, but you should be able to recognise a BPDU in a packet capture by the destination MAC.

5.3 Port States and Roles

RSTP has two orthogonal classifications for every switch port: a state (what the port is currently doing with frames) and a role (what the algorithm has assigned it). The state is a small, finite set of three values; the role is a small set of five.

The three RSTP port states

Per the official Juniper documentation:

RSTP collapses the original 802.1D states (disabled, blocking, listening) into the single discarding state. The transition order is always discarding → learning → forwarding, never backwards.

The five RSTP port roles

Putting state and role together

5.4 The Convergence Problem

Original 802.1D STP took a long time to converge after a topology change. The default timers told a port to wait 15 seconds in listening, another 15 in learning, and only then move to forwarding — a 30-second blackhole on every reconfiguration. On a busy link with TCP traffic, that is enough to break user sessions.

The reason was that 802.1D was conservative by design. The protocol could not tell the difference between “link came up because the cable was reconnected” and “link came up because someone plugged a foreign bridge into our network”. The 30-second timer was a safety margin to make sure no transient loop could form during reconfiguration.

RSTP fixes the convergence problem with three changes:

1. Proposal/agreement handshake. Two RSTP-capable bridges connected on a point-to-point link can negotiate the state of the new port directly, without waiting for any timer to expire. The handshake is two BPDUs and takes milliseconds.
2. Edge ports. A port marked as an edge port (because it connects to a host, not another bridge) skips the discarding and learning states entirely and goes straight to forwarding. We will see this configured in Chapter 6 with edge and BPDU protection.
3. Topology-change distribution. Instead of waiting for the next BPDU cycle, an RSTP bridge that detects a change immediately floods a TCN message and forces every other bridge to age out its MAC table.

The combined effect is sub-second convergence in the common case — usually a single-digit number of milliseconds for a point-to-point inter-switch link and effectively instant for an edge port. The 30-second wait is only ever seen on a topology where RSTP has fallen back to legacy 802.1D semantics, typically because a non-RSTP peer is on the link.

5.5 Rapid Spanning Tree Protocol (RSTP)

Per the official Juniper documentation, the default spanning-tree protocol on devices that support ELS is Rapid Spanning Tree Protocol (RSTP). On any current EX-series running a current Junos release, you do not have to enable RSTP; it is already running on every Ethernet switching interface.

RSTP’s timer defaults on Junos are:

All four values are taken verbatim from the Juniper TechLibrary statement reference at the time of writing. The 4,096 granularity on bridge priority is enforced by the IEEE 802.1Q-2014 specification (the priority field is the upper four bits of a 16-bit field, leaving 4 bits for “System ID Extension” that carries the VLAN/MSTI ID); Junos enforces it on commit.

5.6 The RSTP State Machine

The 802.1D-2004 specification describes RSTP as a set of port-level state machines that exchange information through BPDUs. For the JNCIS-ENT exam you do not need the detailed automaton, but you should know the high-level transitions a port goes through after a topology change. Figure 5.2 shows them.

The convergence story end-to-end

Putting the pieces together, here is what happens after a switch-to-switch link comes up between two RSTP bridges:

1. The new port starts in discarding. Both bridges send BPDUs.
2. The first BPDU each side receives carries a proposal. The receiving bridge synchronises — it puts every non-edge designated port on its bridge into discarding.
3. The receiving bridge sends back an agreement BPDU.
4. On agreement, the new port jumps directly from discarding to forwarding, and the synchronised ports also resume forwarding.

The whole exchange is a few milliseconds. RSTP’s reputation for “30 seconds is gone” comes from this handshake. The 30-second number from 802.1D is still in the RSTP timer table (you can see it as forward-delay) but it is only used as a fall-back when the proposal/agreement cannot complete — for example, when the peer is a non-RSTP bridge.

Chapter 5 explained why Spanning Tree exists and what RSTP does. This chapter is the operator’s view: what an EX4300 ships doing, the small set of commands needed to influence the tree, and the four show-commands that answer almost every Spanning Tree question. Every CLI snippet and every output sample in this chapter is taken verbatim from the Juniper TechLibrary documentation; if a number in your lab disagrees, trust the live output and check the Junos release notes.

6.1 Default Spanning Tree Behaviour on EX

An EX-series switch running a Junos release that supports the Enhanced Layer 2 Software (ELS) ships with RSTP already enabled. Per the official Juniper documentation: The default spanning-tree protocol on devices that support ELS is Rapid Spanning Tree Protocol (RSTP). There is nothing to configure on a single switch in the default state — plug it in, and it is already participating in the protocol.

Because every EX out of the box uses the same default bridge priority (32,768) and there is no built-in tie-breaker beyond MAC address, the root election in a multi-switch network is non-deterministic by default: whichever switch happens to have the lowest base MAC becomes the root. That works, but it is not a network you would want to design around. The first thing a real deployment does is set bridge priorities explicitly so the right device wins.

The other defaults you inherit are exactly the ones we listed in Chapter 5:

6.2 Configuring RSTP

RSTP is already running on every interface of a fresh ELS-capable EX, so “configuring RSTP” in production almost always means tuning, not enabling. The minimal commands you need are at [edit protocols rstp]:

[edit]
## RSTP is already on by default. Touch protocols rstp only when you
## want to override priority, mark edge ports, exclude an interface, or
## change a timer (rare).

set protocols rstp bridge-priority 8k                ## 8192 — make this the root
set protocols rstp interface ge-0/0/0 edge            ## host-facing port: skip listening/learning
set protocols rstp interface ge-0/0/47 mode point-to-point
commit

Three things in this block are worth pausing on. The bridge-priority value 8k is the literal Junos shorthand for 8,192 — remember, the priority must be a multiple of 4,096, and Junos accepts both numeric and k-suffixed forms (4k=4096, 8k=8192, 16k=16384, …, 60k=61440). The edge keyword tells RSTP this port faces a host, so a link-up event jumps it straight from discarding to forwarding. The mode point-to-point hint tells RSTP that the link is a switch-to-switch link rather than a shared-medium segment, which lets the proposal/agreement handshake run; this is implicit on any full-duplex Ethernet link, but it is worth setting explicitly when the upstream is unusual.

For a multi-switch network you typically configure two priorities — the primary root and the secondary — and accept the rest of the defaults:

## On Switch-1 (intended primary root):
set protocols rstp bridge-priority 8k

## On Switch-2 (intended secondary root):
set protocols rstp bridge-priority 16k

## On Switch-3 and any access switch:
## leave at default 32k — they will never be root, which is correct

If you ever need to disable RSTP on a particular interface (for example because that interface is a transit to a third-party device that should not see BPDUs), use disable:

set protocols rstp interface ge-0/0/30 disable

6.3 Tuning Bridge Priority and Port Cost

You influence which switch becomes the root by setting bridge priority. You influence which path frames take by setting port cost. The two together let you build a deterministic active topology without changing any timer.

Bridge priority

Lower priority wins. Set the chosen primary root to a low value (commonly 8k=8192), the secondary to a slightly higher value (16k=16384), and leave every leaf switch at the default 32,768. Because priorities must be multiples of 4,096, you have 16 distinct values to play with in the 0–61,440 range; in practice you use four or five of them.

Port cost

Lower cost wins. Junos uses the 802.1D-2004 long-cost values by default (1 Gbps = 20,000, 10 Gbps = 2,000, etc.; full table in Chapter 5). Override per port when you want a specific link to be preferred or avoided:

set protocols rstp interface xe-0/2/0 cost 1000      ## prefer this 10G uplink even more
set protocols rstp interface ge-0/0/47 priority 240  ## de-prefer this gigabit uplink (lower port priority loses)
commit

Port-priority values, like bridge-priority values, follow a granularity rule. Per the IEEE specification the port priority is the upper 4 bits of an 8-bit field, leaving 4 bits for the port number; valid Junos values are multiples of 16 (0, 16, 32, …, 240). The default is 128.

6.4 Verifying RSTP Operations

Junos exposes the Spanning Tree state through a small family of operational commands rooted at show spanning-tree. Four of them answer almost every question.

user@switch> show spanning-tree bridge
user@switch> show spanning-tree bridge detail
user@switch> show spanning-tree interface
user@switch> show spanning-tree statistics

show spanning-tree bridge

The summary view of who you are and who the root is. Sample output, taken verbatim from the Juniper command-summary documentation for the brief form:

user@switch> show spanning-tree bridge brief

STP bridge parameters
Context ID                  : 0
Enabled protocol            : RSTP
  Root ID                   : 32768.00:19:e2:50:95:a0
  Hello time                : 2 seconds
  Maximum age               : 20 seconds
  Forward delay             : 15 seconds
  Message age               : 0
  Number of topology changes: 0
  Local parameters
    Bridge ID               : 32768.00:19:e2:50:95:a0
    Extended system ID      : 0
    Internal instance ID    : 0

Read it top to bottom. Enabled protocol tells you whether the box is running RSTP, MSTP, or VSTP. Root ID in <priority>.<MAC> form is the elected root’s bridge ID. Compare it to Local parameters > Bridge ID: if they are identical, this switch is the root; if not, this switch is a non-root and is forwarding through one of its ports up to the root. Number of topology changes at zero is what you want; a number that climbs over time on a stable network usually means a flapping link is dragging the tree behind it.

show spanning-tree bridge detail

Adds the path-cost method (32 bit on a current EX) and re-exposes the local timer values:

user@switch> show spanning-tree bridge detail

STP bridge parameters
Context ID                  : 0
Enabled protocol            : RSTP
  Root ID                   : 32768.00:19:e2:50:95:a0
  Hello time                : 2 seconds
  Maximum age               : 20 seconds
  Forward delay             : 15 seconds
  Message age               : 0
  Number of topology changes: 0
  Local parameters
    Bridge ID               : 32768.00:19:e2:50:95:a0
    Extended system ID      : 0
    Internal instance ID    : 0
    Hello time              : 2 seconds
    Maximum age             : 20 seconds
    Forward delay           : 15 seconds
    Path cost method        : 32 bit

show spanning-tree interface

The per-port view, with state and role columns. Sample output verbatim from the Juniper documentation:

user@switch> show spanning-tree interface

Interface     Port ID    Designated  Designated         Port    State  Role
                          port ID    bridge ID          Cost
ge-0/0/0.0    128:513    128:513     8192.0019e2500340  1000    FWD    DESG
ge-0/0/2.0    128:515    128:515     8192.0019e2500340  1000    BLK    DIS
ge-0/0/4.0    128:517    128:517     8192.0019e2500340  1000    FWD    DESG
ge-0/0/23.0   128:536    128:536     8192.0019e2500340  1000    FWD    DESG

Two columns to read first: State and Role. FWD is forwarding, BLK is discarding (the “blocking” legacy name), LRN is learning. DESG is designated, ROOT is root, ALT is alternate, BKUP is backup, DIS is disabled. Anything in BLK + ALT is a port the protocol has correctly identified as redundant and is holding in reserve.

The Port ID column shows the IEEE-format port identifier as <priority>:<port-number>. Default port priority is 128, so most ports show 128:NNN. The Designated bridge ID shows which bridge claims to be designated for the segment beyond this port; on every forwarding port that is reaching the root via a different switch, this column will match the root’s Bridge ID.

show spanning-tree statistics

The BPDU counter view. Use this when you suspect a one-way link or a peer that has gone silent:

user@switch> show spanning-tree statistics
## Counters per interface: BPDUs sent / received, RSTP / TCN / config-BPDU breakdown,
## and the time of the last BPDU received. A column with a frozen Rx counter on
## a forwarding interface is a strong signal of unidirectional link or peer silence.

6.5 Troubleshooting Convergence

The four show-commands above are 90% of RSTP operational work. The remaining 10% is troubleshooting when something is wrong. Three patterns cover the common cases.

Pattern 1 — Wrong root

Symptom: show spanning-tree bridge reports a different Root ID than you expected. Cause is almost always that someone added a switch without setting its bridge priority and that switch’s MAC address sorts lower than your intended root’s. Confirm by checking Root ID on every switch and tracing back to the offending unit. Fix is to set bridge-priority on the intended root to 8k (or lower) and verify.

Pattern 2 — Topology change storm

Symptom: show spanning-tree bridge detail reports Number of topology changes climbing into the hundreds or thousands; Time since last topology change stays small and resets repeatedly. Cause is a flapping link, usually a misbehaving cable, NIC, or duplex mismatch. show interfaces extensive on the suspect ports will show carrier transitions or input errors keeping pace with the TCN counter. Fix is to identify the flapping port and disable it (or replace the cable).

Pattern 3 — A port stuck in BLK that should be ROOT

Symptom: an inter-switch link is up at the physical layer but show spanning-tree interface shows it in BLK / ALT when you expect it to be the root port. Possible causes: another path has a lower aggregate cost (override with set protocols rstp interface <name> cost); the peer is sending superior BPDUs because it has a configured priority lower than expected; or there is a cabling mistake and you are blocking the link you actually want forwarding. Always cross-check both ends of the suspect link with show spanning-tree interface before reaching for the configuration.

BPDU traceoptions

For deep debugging, Junos can trace every BPDU sent and received. Configure under [edit protocols rstp traceoptions] with file rstp.log size 1m and the flag values you need. Remember to remove traceoptions when finished — they impose a measurable CPU cost on a busy switch.

RSTP correctly handles every situation it knows about. The trouble is that the network meets situations the protocol’s designers did not plan for: a contractor plugs a five-port switch into a wall jack, a misconfigured neighbour starts advertising itself as the new root, a fibre develops a one-way fault and BPDUs stop arriving in one direction. This chapter introduces the three Junos guards that catch those scenarios — BPDU protection, Root protection, and Loop protection — and shows where each one belongs in a real campus design. Lab 3 closes the chapter by deliberately creating each failure and watching the relevant guard catch it.

7.1 The Threats — Rogue Switches, Unidirectional Links, Loops

Three failure modes are common enough on a real LAN to deserve their own dedicated defence:

• Rogue switch on an edge port. A user or contractor plugs a small switch (or even a wireless router with a switch built in) into an access port that was supposed to host a single PC. The rogue device sends BPDUs, and if its bridge ID happens to be lower than the current root’s, RSTP dutifully re-elects the rogue as the new root. Within seconds, every traffic flow is reconverging through the closet under the user’s desk.
• Hostile or misconfigured peer claiming to be root. Same protocol behaviour, different scenario: the rogue is not on an edge port, but is a peer switch that was reconfigured (or compromised) and started advertising priority 0. If the legitimate root has priority 8,192, the rogue wins.
• Unidirectional link. A fibre-pair fault, a faulty SFP, or a cable damaged on one strand. The link reports up at L1, forwards in one direction, and loses BPDUs in the other. Without help, RSTP on the side that stops hearing BPDUs eventually expires its peer state and unblocks a redundant port — creating a forwarding loop because the peer is still happily forwarding too.

Each threat has its own counter-measure. None of them is enabled by default; you choose where to apply each one based on the role the port plays in the design. The next three sections take them one at a time.

7.2 BPDU Protection

Problem solved: a BPDU arrives on a port that should never see one. Almost always this means a rogue switch, a misconfigured AP, or someone’s home Wi-Fi router has been plugged into an access jack.

Solution: tell the EX that this is an edge port and that any BPDU received on it is a violation. On violation, the port is taken out of service; the rest of the network is unaffected.

Configuration when RSTP / MSTP is running

Per the Juniper TechLibrary, the canonical pattern is to mark the interface as an edge port and enable BPDU protection on edge ports through the bpdu-block-on-edge statement:

[edit]
set protocols rstp interface ge-0/0/0.0 edge
set protocols rstp interface ge-0/0/0.0 bpdu-block-on-edge
commit

You can apply this per interface (as above) or globally to every edge port at [edit protocols rstp bpdu-block-on-edge]. The global form is the right default for an access switch full of host ports.

Configuration when no Spanning Tree is running on the interface

Some access ports are deliberately excluded from RSTP — for example, a transit to a router, or an isolated DMZ access point. You still want to drop unexpected BPDUs there. Junos exposes a separate hierarchy for this case:

[edit]
set ethernet-switching-options bpdu-block interface ge-0/0/5
## or, with the modern alias used in some EX releases:
set protocols layer2-control bpdu-block interface ge-0/0/5
set protocols layer2-control bpdu-block disable-timeout 600   ## auto-clear after 600 s; 0 = manual only
commit

Two enforcement modes

## Before violation: port forwarding normally
user@switch> show spanning-tree interface ge-0/0/0.0

## A violation occurs (rogue device sends a BPDU). Port is now disabled:
user@switch> show ethernet-switching interface ge-0/0/0.0 detail
## Look for: "BPDU error: detected"

## Recover after the rogue is removed:
user@switch> clear error bpdu interface ge-0/0/0.0

7.3 Root Protection

Problem solved: a peer switch on a designated port starts advertising a superior BPDU (one with a lower bridge priority than the current root’s). Without help, RSTP dutifully accepts the new root, the topology reconverges, and traffic flow shifts in unexpected ways.

Solution: tell the EX that this designated port must never become a root port. If a superior BPDU is received, the port is moved to a root-inconsistent state — it blocks, drops the offending BPDU, and refuses to be a candidate for the root port. Once the superior BPDUs stop, the port automatically returns to normal forwarding.

Configuration

The Junos statement is no-root-port, applied per interface under [edit protocols rstp]:

[edit protocols rstp]
user@switch# set interface ge-0/0/7 no-root-port
commit

Behaviour when triggered

Per the Juniper TechLibrary: The root inconsistent state makes the interface block, discarding any received BPDUs, and prevents the interface from becoming a candidate for the root port.

In show spanning-tree interface a root-protected port that has been triggered shows up as:

Interface     Port ID  Designated  Designated         Port    State  Role
                       port ID     bridge ID          Cost
ge-0/0/7.0    128:519  128:519     8192.0019e2500340  20000   BLK    DIS (Root—Incon)

The role column reports DIS with a (Root—Incon) annotation; the state stays BLK as long as the superior BPDUs keep arriving. When they stop — typically because the offending peer was reconfigured or removed — the port returns to its normal designated/forwarding role with no operator action.

Where to apply it

Root protection belongs on every downward-facing interface of a switch you intend to act as the root or as a path-to-root for the topology. Specifically:

• On the core / distribution switches: every link facing the access layer.
• On any link to a third-party network where the peer’s configuration is outside your administrative control.
• Not on links facing the actual root or a designated alternate root — those links must be allowed to elect a root port if the local one fails.

7.4 Loop Protection

Problem solved: a non-designated port (an alternate or backup) stops receiving BPDUs from its upstream designated peer, even though the link looks up at L1 and L2. Without help, RSTP’s normal max-age timer eventually fires and the port concludes the peer is gone — it transitions to designated and starts forwarding. If the underlying problem is a unidirectional fault (BPDUs lost in one direction but data still flowing in the other), the result is a forwarding loop.

Solution: tell the EX that on this port, BPDU silence is suspicious. Instead of transitioning to forwarding, the port moves to a loop-inconsistent state — it does not forward, but it stays up. As soon as a BPDU is received again from the peer, the port returns to its normal blocking state on its own.

Configuration

[edit]
set protocols rstp interface ge-0/0/6 bpdu-timeout-action block
## "block" is the default action; "log" can be used to alert without blocking
commit

Per the Juniper TechLibrary: Include the bpdu-timeout-action statement with either the block or log option for the spanning-tree protocol interface. The block action is the protective one; log is the audit-only mode useful for collecting evidence before turning on enforcement.

Behaviour when triggered

From the same Juniper documentation: It does not transition the interface to a forwarding state, but instead transitions it to a loop-inconsistent state. And on recovery: The interface recovers and transitions back to the spanning-tree blocking state as soon as it receives a BPDU.

Where to apply it

Loop protection belongs on every non-designated port that is the backup path in a redundant topology — specifically:

• The alternate root port (the second uplink to the upstream switch in a 2-uplink design).
• Any backup port on a downstream segment.
• Not on edge ports — edge ports never expect BPDUs at all, so this guard would never fire.
• Not on root ports — loop protection on a root port is technically allowed but adds no value, because losing BPDUs on a root port is supposed to trigger a topology change, not a block.

7.5 Choosing the Right Protection

The three guards solve three different problems. Get them lined up with the right ports and the network is robust against the common failure modes; mix them up and you create new problems.

7.6 Lab 3 — Implementing Spanning Tree

Topology

Three EX4300 switches: D1 and D2 as the redundant distribution pair, A1 as a single access switch dual-homed to both. A traffic generator (or laptop) plays the rogue and the test host roles.

Step-by-step

1. Set deterministic priorities so D1 wins root election:

   ## On D1 (intended primary root):
   set protocols rstp bridge-priority 8k
   
   ## On D2 (intended secondary root):
   set protocols rstp bridge-priority 16k
   
   ## On A1: leave at default 32k

2. Apply BPDU protection to every host-facing edge port on A1. The simplest pattern is to mark the access ports as edges and turn on the global block:

   ## On A1:
   set protocols rstp interface ge-0/0/0 edge
   set protocols rstp interface ge-0/0/0 bpdu-block-on-edge
   ## (repeat for ge-0/0/1..23, or use interface-range, or set globally)

3. Apply Root Protection on D1 and D2 to every link facing A1:

   ## On D1, D2:
   set protocols rstp interface ge-0/0/47 no-root-port

4. Apply Loop Protection on A1’s alternate uplink:

   ## On A1: ge-0/0/46 is the secondary uplink, currently in BLK/ALT state
   set protocols rstp interface ge-0/0/46 bpdu-timeout-action block

5. commit on each switch.

Verification of the steady state

• show spanning-tree bridge brief on every switch — the Root ID reported is D1’s bridge ID on all three.
• show spanning-tree interface on A1 — the primary uplink (ge-0/0/47) is FWD/ROOT; the secondary uplink (ge-0/0/46) is BLK/ALT; every host port is FWD/DESG.

Test 1 — rogue BPDU on an edge port

Plug a small switch (or the lab BPDU generator) into a host port on A1. Within a couple of seconds you should see:

• The interface drops to physical down. show interfaces ge-0/0/0 terse shows it as down.
• show ethernet-switching interface ge-0/0/0.0 detail shows BPDU error: detected.
• The user’s PC behind the rogue is now offline — correct outcome.
• Recovery: remove the rogue, then clear error bpdu interface ge-0/0/0.0. The link comes back up.

Test 2 — rogue with superior priority on a distribution downlink

Configure a fourth switch with bridge-priority 0 (the lowest possible) and connect it to the D1 link facing A1 (ge-0/0/47, where you applied no-root-port). Within a couple of BPDU intervals:

• show spanning-tree interface ge-0/0/47.0 on D1 reports BLK / DIS (Root—Incon).
• show spanning-tree bridge brief still shows D1 as the root — the rogue’s BPDUs were dropped on the protected port, so the rogue never got accepted.
• Recovery: disconnect the rogue. The port returns to FWD / DESG automatically.

Test 3 — one-way fault on the alternate uplink

Simulate a unidirectional link by, for example, applying a firewall filter that drops BPDUs in one direction on ge-0/0/46. Within max-age (20 s default) you should see:

• show spanning-tree interface ge-0/0/46.0 on A1 reports the loop-inconsistent state. The port stays up but does not transition to forwarding.
• No traffic is forwarded over the faulty link — the loop is prevented.
• Recovery: remove the firewall filter. As soon as the next BPDU arrives, show spanning-tree interface reports the port as BLK/ALT again.

Common pitfalls

• Forgetting to mark a port as edge. bpdu-block-on-edge only applies to ports that have edge set. A host-facing port without the edge flag will never trip the BPDU guard.
• Applying no-root-port to the wrong side. Root protection on a switch that could legitimately become root prevents normal failover. Apply it to designated downlinks, not to up-facing ports.
• Loop protection on edge ports. Loop protection looks for BPDU silence on a port that should be hearing them. An edge port intentionally never hears BPDUs, so the guard would fire constantly. Don’t do it.

RSTP runs one spanning tree for the entire bridged network. That keeps the protocol simple, but it also means every VLAN follows the same path, no matter how the physical topology was laid out. If you have two redundant uplinks and ten VLANs, all ten VLANs use the same active link and the alternate sits idle. MSTP — the Multiple Spanning Tree Protocol, originally IEEE 802.1s and folded into 802.1Q — lets you map groups of VLANs to independent spanning-tree instances, so different VLANs can use different physical paths. This chapter explains the model, configures it on EX4300, verifies it, and shows the migration path from RSTP.

8.1 Why MSTP?

Imagine an access switch with two 10 Gbps uplinks — one to distribution A, one to distribution B — and ten user VLANs. Under RSTP, one of those uplinks is the root port (forwarding) and the other is the alternate (blocked). Every VLAN on the access switch goes up the same uplink. The blocked uplink is idle and 10 Gbps of capacity is wasted. If both uplinks were active, half the VLANs could go each way and you would double the available bandwidth.

This is the problem MSTP solves. The protocol partitions VLANs into spanning-tree instances (MSTIs); each instance runs its own RSTP-style election independently; and you can deliberately set bridge priorities so that distribution A is the root for instance 1 (carrying VLANs 100–110) while distribution B is the root for instance 2 (carrying VLANs 200–210). The result: both uplinks forward traffic, every VLAN still has a loop-free topology, and a link or distribution failure causes only the affected instance to reconverge.

The cost of MSTP, compared to RSTP, is configuration complexity — you have to define regions, decide on a VLAN-to-MSTI mapping, and keep that mapping identical on every switch. The benefit, in any campus with more than two or three VLANs and redundant uplinks, is a doubling (or more) of usable upstream bandwidth.

8.2 MST Regions and Instances

MSTP introduces two new concepts that RSTP did not have: the region and the instance.

The region

A region is a set of switches that agree on the same VLAN-to-instance mapping. From outside, the entire region looks like a single bridge to the rest of the network — the spanning tree connecting regions runs at the “outer” layer and treats each region as one logical bridge. From inside, the region runs its own MSTIs.

Per Juniper’s documentation, three configuration values must match exactly on every switch for them to be in the same region:

1. configuration-name — an arbitrary text string, typically the campus or design name.
2. revision-level — an integer, incremented when you change the VLAN mapping.
3. The VLAN-to-MSTI mapping itself — which VLAN belongs to which instance. The protocol hashes this mapping and includes the digest in BPDUs; if any switch has a different mapping, the digest mismatches and the misconfigured switch is treated as if it were in a different region.

The instances

Each region runs:

• One CIST (Common and Internal Spanning Tree). The CIST is the single tree that connects every device in the wider network — it is what the rest of the world sees. CIST is always present and uses MSTI ID 0.
• Zero or more MSTIs (Multiple Spanning Tree Instances), each with a distinct ID in the range 1–4094 (per the Juniper TechLibrary). Each MSTI runs its own RSTP-style election and produces its own active topology. MSTI IDs are local to a region; you may reuse the same ID in a different region without conflict.

Inside a region, MSTI 0 is also called the IST (Internal Spanning Tree). It is the only instance that actually sends and receives BPDUs on the wire; the other MSTIs piggyback their state on those BPDUs as additional records inside the same frame.

8.3 Configuring MSTP on EX

MSTP on Junos lives at [edit protocols mstp]. The full configuration of an access switch in a two-MSTI region looks like this:

[edit]
## 1) Region identity (must match on every switch in the region)
set protocols mstp configuration-name campus-east
set protocols mstp revision-level 5

## 2) Optional: bridge priority for the CIST (instance 0)
set protocols mstp bridge-priority 32k

## 3) Optional: max-hops for the region (consult Junos statement reference for the default)
set protocols mstp max-hops 20

## 4) MSTI 1 carries VLANs 100-110
set protocols mstp msti 1 vlan [ 100 101 102 103 104 105 106 107 108 109 110 ]
set protocols mstp msti 1 bridge-priority 32k

## 5) MSTI 2 carries VLANs 200-210
set protocols mstp msti 2 vlan [ 200 201 202 203 204 205 206 207 208 209 210 ]
set protocols mstp msti 2 bridge-priority 32k

## 6) Per-interface tuning if needed (priority, cost, edge, p2p mode)
set protocols mstp interface ge-0/0/47 mode p2p
set protocols mstp interface ge-0/0/0  edge
commit

On the two distribution switches you do exactly the same, except you set different priorities so each one wins root election for its instance:

## On Dist-A — primary root for MSTI 1, secondary for MSTI 2
set protocols mstp msti 1 bridge-priority 8k
set protocols mstp msti 2 bridge-priority 16k

## On Dist-B — secondary root for MSTI 1, primary for MSTI 2
set protocols mstp msti 1 bridge-priority 16k
set protocols mstp msti 2 bridge-priority 8k

The result is the topology in Figure 8.1: VLANs 100–110 use the Dist-A path; VLANs 200–210 use the Dist-B path; both uplinks from the access switch forward in steady state.

8.4 Verifying MSTI State

The same Junos show-commands you used for RSTP work for MSTP, with extra detail per instance. The official Juniper sample output for show spanning-tree bridge on a switch running MSTP looks like this (taken verbatim from the Juniper TechLibrary):

user@switch> show spanning-tree bridge

 STP bridge parameters
 Context ID                          : 0
 Enabled protocol                    : MSTP

 STP bridge parameters for CIST
   Root ID                           : 32768.00:11:f2:56:df:40
   Root cost                         : 0
   Root port                         : ge-0/0/1.0
   CIST regional root                : 32768.00:11:f2:56:df:40
   CIST internal root cost           : 20000
   Hello time                        : 2 seconds
   Maximum age                       : 20 seconds
   Forward delay                     : 15 seconds
   Hop count                         : 19
   Message age                       : 0
   Number of topology changes        : 1
   Time since last topology change   : 108 seconds
   Topology change initiator         : ge-0/0/1.0
   Topology change last recvd. from  : 00:11:f2:56:df:4c
   Local parameters
     Bridge ID                       : 32768.00:11:f2:57:1c:00
     Extended system ID              : 0
     Internal instance ID            : 0

 STP bridge parameters for MSTI 10
   MSTI regional root                : 32778.00:11:f2:56:df:40
   Root cost                         : 20000
   Root port                         : ge-0/0/1.0
   Hello time                        : 2 seconds
   Maximum age                       : 20 seconds
   Forward delay                     : 15 seconds
   Hop count                         : 19
   Number of topology changes        : 1
   Time since last topology change   : 108 seconds
   Topology change initiator         : ge-0/0/1.0
   Topology change last recvd. from  : 00:11:f2:56:df:41
   Local parameters
     Bridge ID                       : 32778.00:11:f2:57:1c:00
     Extended system ID              : 0
     Internal instance ID            : 1

Three things to read in this output. First, Enabled protocol is MSTP, confirming the box is running MSTP rather than RSTP or VSTP. Second, the CIST block shows the wider-network root (the “Root ID”) and the regional root (“CIST regional root”); for a single-region campus they match, but in a multi-region design they will be different. Third, each MSTI has its own block with its own root and its own counters — convergence within one MSTI is independent of the others.

The Hop count field is the MSTP equivalent of the IP TTL: BPDUs decrement it as they cross the region, and a switch ignores a BPDU whose hop count has reached zero. The default initial value comes from the max-hops statement on the regional root.

Per-interface MSTI state

Use show spanning-tree interface with the msti qualifier to see each port’s state in a specific instance:

user@switch> show spanning-tree interface
## Default view shows all instances together (CIST + every MSTI)

user@switch> show spanning-tree interface msti 1
## Filter to MSTI 1 only — useful when you have many instances

user@switch> show spanning-tree mstp configuration
## Confirms the region identity (configuration-name, revision-level,
## VLAN-to-MSTI digest). Use this to verify two switches agree they
## are in the same region.

If two switches that should be in the same region show different digests, one of them has a different VLAN-to-MSTI mapping. Find the difference, fix it, increment revision-level on both, recommit.

8.5 Migration from RSTP to MSTP

Migrating an existing campus from RSTP to MSTP is straightforward because MSTP is backwards compatible with RSTP at region boundaries. A switch running MSTP that meets a switch running RSTP simply treats the RSTP switch as belonging to a different region; the CIST handles the inter-region link with RSTP-compatible BPDUs.

The recommended sequence is to migrate one switch at a time, starting at the leaves and working toward the core:

1. Plan the VLAN-to-MSTI mapping. Decide which VLANs go to MSTI 1, which to MSTI 2, and which stay in the CIST. The plan must be the same on every switch in the future region.
2. Decide the region identity. Choose a memorable configuration-name (e.g. campus-east) and start at revision-level 1.
3. Set bridge priorities. Pick a primary and a secondary root for each MSTI — typically the two distribution switches, swapping primary/secondary roles for each instance.
4. Migrate the access switches first. An access switch in the new region whose distribution peers are still RSTP will see them as a different region; the CIST runs RSTP-compatible BPDUs over the inter-region link. Traffic continues to flow.
5. Migrate the distribution pair. When the second distribution switch is converted, the region is complete and MSTI elections take effect. Traffic for VLANs in MSTI 1 starts using the path you designed; traffic for MSTI 2 uses the other path.
6. Verify with show spanning-tree mstp configuration. Every switch in the region must report the same digest.

[edit]
## Remove the old RSTP block
delete protocols rstp

## Apply the new MSTP block (see Section 8.3 for the full template)
set protocols mstp configuration-name campus-east
set protocols mstp revision-level 1
## ... mstp msti / vlan / interface lines from the design ...
commit

You cannot run RSTP and MSTP simultaneously on the same Junos switch — they are mutually exclusive at [edit protocols]. The delete step is therefore mandatory before commit; otherwise the configuration check rejects the change.

Spanning Tree picks one path and blocks the rest. Often you would rather use both. Junos gives you two answers depending on what the other end of the link looks like. Link Aggregation Groups (LAGs), defined in IEEE 802.3ad and managed by LACP, bundle two or more identical links into a single logical interface that forwards on all of them; both ends must support the protocol. Redundant Trunk Groups (RTGs) are a Juniper-specific failover construct: one primary, one secondary, sub-second cut-over, no protocol negotiation required — useful when the upstream is a non-LAG-capable device. This chapter walks through both and finishes with Lab 4 covering each.

9.1 LAG Fundamentals

A LAG combines two or more physical Ethernet links between the same two devices into a single logical link. From every protocol that runs on top — RSTP, MSTP, MAC learning, IRB, OSPF — the LAG looks like one interface with one MAC address, one IP address (if it is L3), and a single Spanning Tree state. Frames are spread across the member links by a hash function so a single TCP flow always uses the same physical wire (avoiding reordering), but two different flows can use different wires (giving you parallelism).

On Junos, a LAG is exposed as an aggregated Ethernet interface, named aeN. The N range is 0 through 4091, but the number you actually use depends on a chassis-level allocation: set chassis aggregated-devices ethernet device-count N tells Junos how many ae bundles to make available for configuration. Allocate exactly the number you need; over-allocating wastes data structures, under-allocating prevents commit.

Three reasons a LAG beats a single link:

• Bandwidth. Two 10 Gbps links bonded into one ae0 give you up to 20 Gbps of aggregate throughput, distributed by the hash.
• Resilience. When one member link fails, the LAG simply rehashes onto the survivors. No Spanning Tree topology change, no MAC table flush, just a momentary blip while the LACP machine notices the loss and updates.
• Operational simplicity. Configuring VLANs, IRB, ACLs, or QoS on ae0 applies to all member links automatically. You change one place.

Static vs. dynamic

You can build a LAG two ways. Static bundling assumes both ends agree by configuration; if a member link silently fails (one direction drops, the other keeps forwarding) the LAG keeps trying to use it. Dynamic bundling uses LACP, the IEEE 802.3ad control protocol, to verify both ends agree on each member and to detect link-layer faults independent of L1 status. Static is simpler; dynamic is correct. Use LACP unless you have a specific reason not to.

9.2 LACP Operations

LACP — Link Aggregation Control Protocol, defined in IEEE 802.3ad — runs as a small state machine on each member link. It exchanges periodic frames called LACPDUs to confirm that both ends agree on which physical port belongs to which logical bundle. If the LACPDU exchange fails (peer goes silent, or one direction is broken), the affected member is removed from the bundle and the LAG continues with the remaining members.

Active vs. passive

Each end of the LAG can run LACP in one of two modes:

• Active — the end actively sends LACPDUs to negotiate the bundle.
• Passive — the end will respond if the peer initiates, but does not initiate by itself.

The combinations:

Periodic transmission interval

LACP can transmit LACPDUs fast (every 1 second) or slow (every 30 seconds). On Junos, periodic fast is the standard production setting because it gives sub-second detection of a failed member. slow is the protocol default and is fine for low-criticality links.

9.3 Configuring LAGs in Junos

The configuration is a four-step pattern:

[edit]

## 1) Allocate the number of ae bundles you need (one in this example)
set chassis aggregated-devices ethernet device-count 1

## 2) Move the member ports into the bundle. Use ether-options on EX (10G/40G)
## or gigether-options on a copper 1G port. Both forms accept "802.3ad ae0".
set interfaces xe-0/2/0 ether-options 802.3ad ae0
set interfaces xe-0/2/1 ether-options 802.3ad ae0

## 3) Turn on LACP on the bundle. "active" means this side initiates.
set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 aggregated-ether-options lacp periodic fast

## 4) Configure the bundle exactly like a normal switching interface.
set interfaces ae0 unit 0 family ethernet-switching interface-mode trunk
set interfaces ae0 unit 0 family ethernet-switching vlan members [ data-vlan voice-vlan mgmt ]
set interfaces ae0 native-vlan-id 99
commit

Every protocol that previously needed two interface-name lines (one for each physical port) now needs one — everything attaches to ae0.

Optional knobs you may meet on the exam

Verification

user@switch> show interfaces ae0 terse
user@switch> show interfaces ae0 detail
user@switch> show lacp interfaces
user@switch> show lacp interfaces ae0 detail
user@switch> show lacp statistics interfaces ae0

show lacp interfaces is the first command to read. The two state columns to check are LACP state – Active or Passive, the role you configured — and protocol state – Distributing/Collecting on a member that is fully partnered. Anything else (Defaulted, Expired) is a fault: most often, the peer is not running LACP, or the cabling crosses two different bundles, or one end is passive while the other is also passive.

9.4 Hash Algorithms and Load Balancing

A LAG is only as effective as the way frames are spread across its members. The choice of hash function determines whether two flows that you expect to balance actually do.

Junos hashes each frame on a tuple of header fields. The exact tuple is platform-dependent and configurable, but on a typical EX4300 the default L2 hash includes:

• Source MAC
• Destination MAC
• VLAN ID

For L3-aware hashing (IPv4 / IPv6 frames), the EX adds:

• Source IP, destination IP
• L4 source and destination port (if it can find them)

The hash output picks one member of the bundle and the frame is sent on that member. Flows that share all hash inputs land on the same member; flows that differ in any one input may land on different members. The standard pathological case is “two heavy hosts talking to one server” — both flows have the same destination MAC, the same destination IP, the same destination port, and only differ in source. If your hash includes source, they will balance. If it does not, they will not.

Configuring the hash

On Junos the hash is controlled at [edit forwarding-options enhanced-hash-key] on EX platforms. The defaults are sensible for the campus; only change them if you have measured an imbalance.

9.5 Redundant Trunk Groups (RTGs)

RTG is a Juniper-only L2 failover construct. Two trunk ports are designated as a group; one is primary, one is secondary. The primary is the active forwarding path; the secondary is held in a blocked state, invisible to Spanning Tree. If the primary goes down, the secondary takes over within roughly a second.

An RTG has three properties that make it different from a LAG:

• No protocol negotiation. The peer is unaware of RTG; it sees two ordinary trunks. This is exactly what you want when the peer is a non-LACP-capable device or a third-party switch you do not control.
• Active/standby, not active/active. Only the primary forwards. There is no bandwidth aggregation — this is purely a failover mechanism.
• RSTP must be disabled on the RTG members. RTG and RSTP are mutually exclusive on the same interface; the protocols would fight over which port to forward.

Configuration

On a Junos ELS-capable EX, RTG lives under [edit switch-options redundant-trunk-group]. The Juniper-documented configuration block is:

[edit]

## 1) Disable Spanning Tree on the two interfaces that will form the RTG.
##    Without this, RSTP and RTG would race; the commit succeeds but the
##    operational state is unpredictable.
set protocols rstp disable

## 2) Define the group, naming the primary and the secondary.
set switch-options redundant-trunk-group group rtg0 interface ge-0/0/9.0 primary
set switch-options redundant-trunk-group group rtg0 interface ge-0/0/10.0

## 3) Optional: how long a re-enabled primary waits before taking over from
##    the active secondary. Default is 1 second; the example sets 60.
set redundant-trunk-group group rtg0 preempt-cutover-timer 60
commit

Per the Juniper TechLibrary: If you do not change the time with the preempt-cutover-timer statement, a re-enabled primary link takes over from the active secondary link after 1 second.

Behaviour

Steady state: the primary (ge-0/0/9.0 in the example) forwards normally; the secondary (ge-0/0/10.0) is administratively up but functionally blocked. Frames that arrive on the secondary are dropped; broadcasts are not forwarded out the secondary.

If the primary fails: Junos detects the link-down event, copies the MAC table entries that pointed at the primary onto the secondary (so existing flows do not need to re-learn), and unblocks the secondary. The whole transition is sub-second on a healthy link-down event.

If the primary comes back: the secondary keeps forwarding for preempt-cutover-timer seconds (default 1, configurable up to 600) before the primary resumes. Setting the timer higher avoids flapping if the primary is unstable; setting it to 0 disables preemption entirely so the secondary stays active until you intervene.

Verification

user@switch> show redundant-trunk-group
## Lists every RTG, its members, the current state of each (Up/Pri or Up/Sec),
## and a flap counter. Reading this is enough to confirm the RTG is healthy.

9.6 LAG vs. RTG — Choosing the Right Tool

The two constructs solve different problems. Pick the wrong one and the symptom is invisible until the link fails.

The decision tree is short:

• If the upstream is a Juniper switch (or any vendor that runs IEEE 802.3ad LACP), use a LAG. You get bandwidth and resilience.
• If the upstream is a non-LACP device (some legacy distribution boxes, certain firewall pairs, occasional third-party appliances), use an RTG. You get failover but not bandwidth aggregation.
• You almost never want both on the same path.

9.7 Lab 4 — Implementing LAGs and RTGs

Topology

Two EX4300 switches, S1 and S2, connected by four physical links. Two of the links (xe-0/2/0 and xe-0/2/1) form the LAG; two others (ge-0/0/9 and ge-0/0/10) form the RTG. A single host on S1, a single server on S2.

Step-by-step — the LAG

1. On both S1 and S2, allocate two ae bundles so we have room for the RTG comparison too:

   set chassis aggregated-devices ethernet device-count 2

2. Move xe-0/2/0 and xe-0/2/1 into ae0:

   set interfaces xe-0/2/0 ether-options 802.3ad ae0
   set interfaces xe-0/2/1 ether-options 802.3ad ae0

3. Turn on LACP active and configure the bundle as a trunk:

   set interfaces ae0 aggregated-ether-options lacp active
   set interfaces ae0 aggregated-ether-options lacp periodic fast
   set interfaces ae0 unit 0 family ethernet-switching interface-mode trunk
   set interfaces ae0 unit 0 family ethernet-switching vlan members all
   commit

4. Verify on each side: show lacp interfaces ae0 detail shows both members in Distributing/Collecting; show interfaces ae0 terse shows ae0 as up/up.
5. Run a parallel iperf with several flows from the host through to the server. Observe two flows on each member by checking show interfaces xe-0/2/0 statistics vs show interfaces xe-0/2/1 statistics — byte counters should grow on both.
6. Pull one of the cables. show lacp interfaces ae0 detail shows the surviving member only; iperf throughput drops by half but does not stop.
7. Plug the cable back in. The recovered member rejoins within seconds.

Step-by-step — the RTG

1. Disable RSTP on S1 (the side hosting the RTG):

   ## On S1:
   set protocols rstp disable

2. Define the RTG, with ge-0/0/9 as primary:

   set switch-options redundant-trunk-group group rtg0 interface ge-0/0/9.0 primary
   set switch-options redundant-trunk-group group rtg0 interface ge-0/0/10.0

3. Optionally raise the preempt timer to avoid flap-on-recovery:

   set redundant-trunk-group group rtg0 preempt-cutover-timer 30
   commit

4. Verify: show redundant-trunk-group shows ge-0/0/9.0 as Up/Pri and ge-0/0/10.0 as Up/Sec.
5. Run a steady ping from the host through this path to the server.
6. Pull the primary cable. The ping pauses for < 1 s, then resumes — on the secondary. show redundant-trunk-group now shows ge-0/0/10.0 as Up/Pri.
7. Reinsert the primary cable. After the preempt-cutover-timer expires, the primary resumes; another < 1 s blip in the ping.

What you should observe

• The LAG provides parallel bandwidth: with two flows, both members are busy.
• The RTG provides failover but only one member ever forwards.
• LAG failover (LACP periodic fast) is faster than RTG failover; RTG is still sub-second.
• Putting the LAG on a switch where the upstream does not run LACP would have failed at step 4 with members stuck in Defaulted — that scenario is exactly when you reach for an RTG.

Common pitfalls

• Both ends configured passive. The LAG never forms; show lacp interfaces shows Expired. At least one side must be active.
• Forgetting device-count. Junos rejects the commit if no ae bundles are allocated.
• Mismatched member speeds. A LAG built with one 10 G member and one 1 G member will form, but performance is undefined and the standard does not endorse the configuration. Keep members at the same speed.
• Leaving RSTP enabled on RTG members. RSTP and RTG conflict; the symptom is unpredictable failover. The Juniper-documented configuration explicitly does set protocols rstp disable.

A network running RSTP and the three Spanning Tree guards from Chapter 7 will withstand the typical loop. But on the day a forwarding loop does form — perhaps because the protection was misconfigured, perhaps because someone unplugged the wrong cable — the resulting flood of broadcasts and unknown-unicast frames can saturate every uplink in the campus in seconds. Storm control is the second-line defence: a per-interface rate limiter that drops or shuts down the port the moment broadcast / multicast / unknown-unicast traffic exceeds a configured threshold. On EX-series switches under ELS, it is enabled by default; this chapter covers what the default does, how to tune it, and how to read its output.

10.1 What is a Broadcast Storm?

A broadcast storm is what happens when a frame that has to be flooded enters a forwarding loop and the network amplifies it. Three classes of frame trigger the “flood” path:

• Broadcast. Destination MAC ff:ff:ff:ff:ff:ff. ARP requests, DHCP discovery, NetBIOS announcements.
• Multicast. Destination MAC with the group bit (I/G) set. Routing-protocol hellos, multicast video, IPv6 neighbour discovery, mDNS / LLMNR.
• Unknown unicast. A unicast frame whose destination MAC is not in the EX’s switching table. Behaves identically to broadcast in flooding terms.

In a healthy network the volume of these three classes is small — a few percent of total traffic on most campuses. In a looped network they can each occupy 100% of every link. Because the flood scales geometrically with the number of switches the loop traverses, even a small two-switch loop can saturate a 10 Gbps uplink within seconds.

Storm control caps the rate of these three classes at a per-interface threshold. When the threshold is exceeded, the EX either drops the excess or, optionally, takes the offending interface out of service so the loop cannot continue.

10.2 Storm Control Fundamentals

Per the Juniper documentation, storm control is enabled by default on ELS platforms and the default level is 80 percent of the available bandwidth for ingress traffic. In other words, a fresh EX out of the box already enforces a hard ceiling on the combined broadcast, multicast, and unknown-unicast rate at 80% of port speed. You do not have to do anything to get protection. Tuning is necessary only when you want a tighter limit, a different action, or selective protection for one traffic class but not another.

Two ways to express the threshold:

• bandwidth-level <kbps> — an absolute rate, in kilobits per second. Range 100 through 10,000,000 on most EX platforms. Useful when you want the same limit on different speed ports.
• bandwidth-percentage <%> — a fraction of the port’s bandwidth. Useful when you want, say, 10% on every port regardless of whether it is 1G or 10G.

Two actions when the threshold is crossed:

• Drop (default) — the EX silently discards the excess frames once the rate exceeds the limit. The interface stays up; legitimate unicast forwarding continues.
• Shut down — with action-shutdown, the EX disables the interface entirely. Manual recovery is required (clear the error). This is the right choice when an in-progress loop must be broken hard.

10.3 Configuring Storm Control on Junos

Storm control on ELS Junos is a two-step pattern: define a storm-control profile at [edit forwarding-options storm-control-profiles], then bind it to one or more interfaces under family ethernet-switching.

Minimum useful configuration

From the Juniper TechLibrary example, verbatim:

[edit]

## 1) Define a profile named "sc" that caps the combined storm
##    traffic at 15,000 Kbps (15 Mbps) on whatever interface uses it
set forwarding-options storm-control-profiles sc all bandwidth-level 15000

## 2) Bind the profile to an interface
set interfaces ge-0/0/0 unit 0 family ethernet-switching storm-control sc
commit

The keyword all in the profile name applies the limit to all three traffic classes at once; the keyword bandwidth-level takes a Kbps value. The bind line under family ethernet-switching is what actually enforces the profile on a port; multiple ports can share the same profile by reference.

Percentage form

[edit]
set forwarding-options storm-control-profiles sc-pct all bandwidth-percentage 10
set interfaces interface-range ACCESS-PORTS unit 0 family ethernet-switching storm-control sc-pct
commit

This caps storm traffic at 10% of each member interface’s bandwidth — 100 Mbps on a 1 G port, 1 Gbps on a 10 G port. For a campus with mixed speeds, percentage is usually the cleaner expression.

Selective protection by traffic class

You can disable storm control for any individual traffic class by including the matching no-... sub-statement. The Juniper-supported toggles:

The most common pattern is to leave broadcast and unknown-unicast protected but turn off rate-limiting for registered multicast — because IGMP-aware multicast video has its own join control and a 10% storm limit can starve a video stream:

set forwarding-options storm-control-profiles sc-mcast-friendly all bandwidth-percentage 10
set forwarding-options storm-control-profiles sc-mcast-friendly no-registered-multicast

Action: shutdown

Add action-shutdown to a profile to make the EX disable the interface (rather than just drop the excess frames) when the threshold is crossed:

set forwarding-options storm-control-profiles sc-strict all bandwidth-percentage 5
set forwarding-options storm-control-profiles sc-strict action-shutdown

Recovery is manual. Use clear ethernet-switching recovery-timeout interface <name> (or, on some Junos releases, clear error mac-rewrite interface) to bring the port back. Confirm the offending host or loop has been resolved before clearing — otherwise the port will trip again on the next storm.

10.4 Action Profiles

The combination of bandwidth-level / bandwidth-percentage, no-... selective filters, and action-shutdown gives you a small palette of pre-built profiles that cover almost every campus scenario:

10.5 Monitoring and Logging

Two operational commands answer almost every storm-control question:

user@switch> show ethernet-switching interface ge-0/0/0 detail
## Confirms which storm-control profile is bound and shows interface-level
## counters. The "Storm-control level / action" line reflects the profile.

user@switch> show log messages | match storm-control
## When a port is rate-limited or shut down, the EX writes a syslog entry
## of the form "STORM_CONTROL_DROPS_EXCEEDED" or similar. Grep the log to
## find the offending port and the time of the event.

Recovery from action-shutdown is by manual operator action. The exact recovery command varies by Junos release; check show ethernet-switching interface ge-0/0/0 detail for the recommended clear command in your release notes. After clearing, watch for repeat events — if the port trips again within minutes, the underlying loop or rogue host has not been resolved.

SNMP and structured monitoring

Storm-control events generate SNMP traps that can be picked up by an NMS. The OID for the basic event is in the standard EtherLike-MIB; the Juniper-specific event OIDs are in JUNIPER-COS-MIB. For a managed campus, configuring traps to your NMS is the normal way to learn about storm-control trips without scraping syslog.

Storm control protects the network from a quantity of unwanted frames. A firewall filter protects it from a type of unwanted frame. Junos exposes a single, consistent filter language at every layer — L2, L3, L4 — with the same term / from / then grammar. This chapter covers the L2 form, where filters are bound to family ethernet-switching and decide what frames are accepted, discarded, counted, policed, or marked for QoS, before any other forwarding decision happens. Lab 5 at the end of the chapter combines a storm-control profile from Chapter 10 with an L2 filter to demonstrate the “rate plus class” pattern that makes up most production access-edge configurations.

11.1 Firewall Filters on EX

A Junos firewall filter is an ordered list of terms. Each term has an optional from clause that names the conditions a frame must match, and a mandatory then clause that names the actions to take when the frame matches. Terms are evaluated top-to-bottom; the first matching term wins; if the term’s action is non-terminal (a count, for example, with no explicit accept/discard), evaluation continues to the next term. A frame that reaches the end of the filter without matching a terminal action is implicitly discarded.

The Junos hierarchy is:

firewall {
    family ethernet-switching {
        filter FILTER-NAME {
            term TERM-NAME {
                from { /* match conditions */ }
                then { /* actions */ }
            }
        }
    }
}

Filters under family ethernet-switching are the L2 form. There are also family inet (IPv4), family inet6 (IPv6), family mpls, and family vpls; the grammar is identical, only the supported match conditions and actions differ. The discussion below sticks to family ethernet-switching because that is what the JNCIS-ENT exam tests.

Where filters apply

An L2 filter can be applied at three points:

11.2 Filter Structure — Term, From, Then

The smallest useful filter has one term:

[edit]
set firewall family ethernet-switching filter BLOCK-IPX term drop-ipx
set firewall family ethernet-switching filter BLOCK-IPX term drop-ipx from ether-type 0x8137     ## IPX
set firewall family ethernet-switching filter BLOCK-IPX term drop-ipx then discard

## Implicit second term — accept everything else
set firewall family ethernet-switching filter BLOCK-IPX term default then accept

Adding more conditions

A term’s from clause can have multiple conditions; the term matches only if all of them are true. You can also make a term match more broadly by listing multiple values for one condition (a logical OR within the condition).

set firewall family ethernet-switching filter GUEST-LIMIT term block-corp-targets {
    from {
        ip-source-address      10.20.0.0/16;       ## guest VLAN
        ip-destination-address [ 10.10.0.0/16 10.30.0.0/16 ]; ## any corp subnet
        ip-protocol            tcp;
        destination-port       [ 22 3389 ];        ## SSH or RDP
    }
    then {
        count   guest-blocked-ssh-rdp;
        log;
        discard;
    }
}
set firewall family ethernet-switching filter GUEST-LIMIT term default then accept

This filter says: any frame from the guest VLAN attempting SSH or RDP into a corporate subnet is counted (the counter is named for later inspection), logged, and dropped. Everything else is accepted. The combined count + log + discard in the then block is a common audit pattern — it gives you both the realtime alert (log writes a syslog entry) and the historical statistic (the counter accrues).

11.3 Layer 2 Match Conditions

Per the Juniper TechLibrary, the match conditions available under family ethernet-switching on EX/QFX include the following:

Actions you can take

Per the Juniper TechLibrary, the documented then actions for family ethernet-switching are:

11.4 Applying Filters at L2

A filter is inert until it is applied. Three application points were summarised above; the practical syntax for each is:

## Per-interface, ingress (the most common case)
set interfaces ge-0/0/0 unit 0 family ethernet-switching filter input GUEST-LIMIT

## Per-interface, egress
set interfaces ge-0/0/47 unit 0 family ethernet-switching filter output UPLINK-AUDIT

## Per-VLAN (filter applies to every port in the VLAN)
set vlans guest-vlan forwarding-options filter input GUEST-LIMIT

You can apply different filters to ingress and egress on the same interface; you can apply both an interface filter and a VLAN filter (the interface filter runs first).

Filter ordering and precedence

When the same frame can be matched by multiple filters (an interface ingress filter and a VLAN ingress filter, for example), Junos evaluates them in this order:

1. Per-interface ingress filter
2. Per-VLAN ingress filter (if defined and the frame is in that VLAN)
3. Forwarding decision (MAC table lookup, RSTP, etc.)
4. Per-VLAN egress filter
5. Per-interface egress filter

If an earlier filter discards the frame, no later filter sees it. This pipeline is the same as in family inet filters; if you have used Junos firewall filters at L3, the L2 form behaves identically.

11.5 Counters, Logging, Policers

Counters

A count action increments a named 64-bit counter every time the term matches. The counter persists across commits; clear it explicitly with clear firewall counter NAME. Read counters with:

user@switch> show firewall
## Lists every filter and every counter inside each, with byte and packet totals.

user@switch> show firewall filter GUEST-LIMIT
## The same data, narrowed to one filter.

user@switch> show firewall counter guest-blocked-ssh-rdp
## Just the named counter.

Logging vs syslog

Two action keywords look similar but behave differently:

• log writes a per-frame record into a small in-memory firewall log on the EX itself. Read with show firewall log. The buffer is small (a few thousand entries) and rolls; it is intended for “watch this in real time” usage.
• syslog generates a full syslog message each time the term matches. Heavier; the message goes to whatever syslog destination is configured. Use sparingly — on a term that matches a million frames per second, this will overwhelm the syslog daemon.

Policers

A policer is a rate-limit object defined separately at [edit firewall policer ...], then referenced from a filter term’s then clause. A typical pattern:

## 1) Define the policer (10 Mbps with 1 MB burst, drop excess)
set firewall policer RL-10M if-exceeding bandwidth-limit 10m
set firewall policer RL-10M if-exceeding burst-size-limit 1m
set firewall policer RL-10M then discard

## 2) Reference the policer in a filter term
set firewall family ethernet-switching filter RATE-GUEST term rate-it {
    from ip-source-address 10.20.0.0/16;
    then policer RL-10M;
}
set firewall family ethernet-switching filter RATE-GUEST term default then accept

This caps every frame from the guest VLAN at an aggregate 10 Mbps. Bursts up to 1 MB are absorbed; sustained traffic over the limit is dropped.

11.6 Lab 5 — Implementing Storm Control and Firewall Filters

Topology

One EX4300 access switch, one host (PC A) on ge-0/0/0 in VLAN 100 (the data VLAN), one server (S1) on ge-0/0/47 as the trunk to the rest of the lab.

Step-by-step

1. Define a storm-control profile that caps storm traffic at 5% with shutdown action:

   set forwarding-options storm-control-profiles edge-strict all bandwidth-percentage 5
   set forwarding-options storm-control-profiles edge-strict action-shutdown

2. Define a Layer 2 firewall filter that:
   • blocks any frame with a destination of 10.99.0.0/24 (a sensitive subnet),
   • permits HTTP and HTTPS to anywhere,
   • counts both classes,
   • accepts everything else.

     set firewall family ethernet-switching filter EDGE-IN term block-sensitive {
         from ip-destination-address 10.99.0.0/24;
         then { count edge-blocked-sensitive; log; discard; }
     }
     set firewall family ethernet-switching filter EDGE-IN term permit-web {
         from {
             ip-protocol tcp;
             destination-port [ 80 443 ];
         }
         then { count edge-web-allowed; accept; }
     }
     set firewall family ethernet-switching filter EDGE-IN term default then accept

3. Bind both to the access port:

   set interfaces ge-0/0/0 unit 0 family ethernet-switching storm-control edge-strict
   set interfaces ge-0/0/0 unit 0 family ethernet-switching filter input EDGE-IN

4. commit and-quit.

Verification

• show ethernet-switching interface ge-0/0/0 detail — confirms both the storm-control profile and the input filter are bound.
• From PC A, generate normal HTTP traffic to 10.10.5.5 (any non-sensitive host on port 80). Browsing works. show firewall counter edge-web-allowed shows the bytes accruing.
• From PC A, attempt to ping or SSH to 10.99.0.10. The traffic is silently dropped. show firewall counter edge-blocked-sensitive shows the bytes accruing; show firewall log shows per-frame log entries.
• From PC A, run a small program that floods ff:ff:ff:ff:ff:ff at high rate (e.g. a tight loop sending UDP broadcasts). Within a couple of seconds storm control trips and disables the port; show interfaces ge-0/0/0 terse shows it as down; show log messages | match storm shows the trigger event.
• Recover with the appropriate clear ethernet-switching command for your Junos release.

Common pitfalls

• Forgotten default accept. Without a final term default { then accept; }, every non-matching frame is implicitly dropped. The user’s PC will lose DNS, DHCP, ARP, and everything else.
• Counter never increments. If you applied the filter to the wrong direction (output instead of input), traffic from the host is not seen by the term. Re-bind to filter input.
• Order matters. A broad permit-web term placed before block-sensitive would let HTTPS to 10.99.0.10:443 through. Specific terms must come before broad ones.

Storm control limits volume; firewall filters limit traffic types; this chapter and the next limit identity. We start with three Junos features that constrain who is allowed to plug into a port: MAC limiting (how many MAC addresses can the port learn), MAC move limiting (how often a single MAC is allowed to move between ports), persistent MAC learning (lock learned MACs to the port even across reboots), and MACsec (line-rate encryption of every Ethernet frame defined by IEEE 802.1AE). Every command in this chapter is taken verbatim from the Juniper TechLibrary documentation.

12.1 The Threat Model at the Access Edge

An access port is the most-attacked surface of a campus network. The threats that show up most often:

• Unauthorised devices. A user (or contractor) plugs in a personal laptop, a small switch, or a wireless router. The port’s MAC table grows with addresses you did not authorise.
• MAC flooding. A malicious host sends frames with thousands of forged source MACs, filling the EX’s switching table and pushing legitimate entries out so traffic gets flooded everywhere — the classic CAM-overflow attack.
• MAC spoofing / hijack. An attacker on another port advertises themselves as someone else’s MAC to redirect that user’s traffic.
• Wire-tapping. Anyone on the wire between two switches can passively read every frame — broadcasts, ARP, plaintext credentials — unless the link is encrypted.

This chapter’s three features address them in order: MAC limiting caps how many MACs the port can learn (defeats unauthorised devices and flooding); persistent MAC learning pins learned MACs in place (defeats spoofing and survives reboots); MACsec encrypts every frame at L2 (defeats wire-tapping). Chapter 13 covers the rest of the access-edge defence stack — DHCP snooping, Dynamic ARP Inspection, IP Source Guard.

12.2 MAC Limiting

MAC limiting tells the EX how many distinct MAC addresses a port is allowed to learn. The 49th MAC on a port limited to 48 triggers the configured action.

Configuration

Per the Juniper TechLibrary, the ELS hierarchy for MAC limiting is [edit switch-options interface name interface-mac-limit]. The basic statement takes a numeric limit and an action:

[edit]

## Allow at most 1 MAC on this access port — typical "one PC per cable" policy
set switch-options interface ge-0/0/0 interface-mac-limit 1
set switch-options interface ge-0/0/0 interface-mac-limit packet-action drop

## Allow up to 5 MACs (laptop + phone + behind-the-phone PC + the phone's mDNS,
## with a margin) and shut the port if exceeded
set switch-options interface ge-0/0/2 interface-mac-limit 5
set switch-options interface ge-0/0/2 interface-mac-limit packet-action shutdown
commit

The three documented packet actions

Per the Juniper documentation, the default action is drop. After you change the MAC limit using the interface-mac-limit statement, the system clears the corresponding existing entries in the MAC address forwarding table; legitimate hosts re-learn at the next frame.

Sizing the limit

Three numbers worth keeping in mind for a campus access port:

MAC move limiting

A related but distinct control: a single MAC address legitimately stays on one port. If the same MAC appears repeatedly on different ports, that is either a flapping link or a host being moved — or, in the malicious case, an attacker spoofing a known MAC from a second port. MAC move limiting caps the number of times one MAC can move per second across the switch:

[edit]
set vlans data-vlan switch-options mac-move-limit 5
set vlans data-vlan switch-options mac-move-limit packet-action drop
commit

If a single MAC moves more than five times in one second within VLAN data-vlan, the EX takes the configured action. Default action is the same drop as for MAC limiting; log and shutdown are available too.

12.3 MAC Move Limiting

MAC move limiting (introduced briefly above) deserves a section of its own because it catches a different class of failure than MAC limiting does.

MAC limiting answers “how many distinct addresses on this port?”. MAC move limiting answers “how often is one address bouncing between ports?”. The latter is the diagnostic for two situations:

• An L2 loop has formed. The same source MAC arrives on two different ports as the loop circulates; the EX moves the entry back and forth on every frame. MAC move limiting trips early and identifies the affected VLAN.
• An attacker is spoofing a legitimate MAC from another port. The same MAC alternates between the legitimate port and the attacker’s port. MAC move limiting flags it.

The configuration is a per-VLAN ceiling on the move rate, with the same three packet actions (drop, log, shutdown) as interface-mac-limit:

[edit]
set vlans data-vlan switch-options mac-move-limit 10
set vlans data-vlan switch-options mac-move-limit packet-action log
commit

Start with the log action, watch for false positives over a few weeks (forklifted desktops, hot-swapped servers), then promote to drop or shutdown.

12.4 Persistent MAC Learning

MAC limiting controls how many MACs the port learns; persistent MAC learning controls which MACs the port retains. With persistent learning enabled, each MAC the port learns is written to the EX’s configuration database and becomes a near-permanent entry — it survives clear ethernet-switching table and, importantly, it survives a reboot. The exact Juniper-documented effect: the interface does not have to relearn the addresses from ingress traffic after a restart.

Persistent learning is most useful as the second half of a pair with MAC limiting:

[edit]
set switch-options interface ge-0/0/0 interface-mac-limit 1
set switch-options interface ge-0/0/0 interface-mac-limit packet-action drop
set switch-options interface ge-0/0/0 persistent-learning
commit

The combined behaviour:

1. The first MAC that arrives on the port is learned and written persistently.
2. Any subsequent different MAC trips the limit and is dropped (because the limit is 1).
3. The original MAC remains the “owner” of the port across reboots, even if the original device is offline at boot time.
4. Moving the device to another port without first clearing the persistent entry locks the new port out: the documentation warns explicitly that if you move a device without clearing its persistent entry from the original port, the new port will not learn the MAC address of the device and the device will not be able to connect.

Clearing persistent entries

user@switch> show ethernet-switching table persistent-learning
## Lists every persistently-learned MAC and the interface it is bound to.

user@switch> clear ethernet-switching table persistent-mac interface ge-0/0/0
## Clears the persistent entry on a specific interface, allowing a new device
## to be learned. Required after legitimate hardware moves.

12.5 MACsec — 802.1AE in Practice

MACsec, defined by IEEE 802.1AE, encrypts every Ethernet frame on a point-to-point link. The encryption is line-rate, hardware-accelerated, and sits at L2 — it protects everything above (IP, TCP, application data) and almost everything below (everything except the bytes the standard explicitly leaves in the clear, like the destination MAC and the SecTAG). MACsec is what you reach for when you cannot trust the cable: a fibre that runs through unsecured space, a copper link to a tenant in a shared building, or a switch-to-switch link that crosses a campus boundary.

How MACsec is configured

A MACsec deployment has three pieces:

1. A connectivity association (CA) — a named profile that holds the security mode and the pre-shared key.
2. The pre-shared key itself, made of a CKN (Connectivity Association Key Name — an identifier) and a CAK (Connectivity Association Key — the actual key material).
3. An interface attachment binding the CA to a specific port.

Per the Juniper documentation: The CKN and CAK must match on both ends of the link to initially enable MACsec. Mismatched CKN or CAK means the MACsec Key Agreement (MKA) handshake fails and the link does not become secured.

Typical configuration on EX (static-CAK mode)

[edit]

## 1) Create the connectivity association
set security macsec connectivity-association ca1
set security macsec connectivity-association ca1 security-mode static-cak

## 2) Configure the pre-shared key. Both CKN and CAK must match on both ends.
set security macsec connectivity-association ca1 pre-shared-key ckn 37c9c2c45ddd012aa5bc8ef284aa23ff6729ee2e4acb66e91fe34ba2cd9fe311
set security macsec connectivity-association ca1 pre-shared-key cak 228ef255aa23ff6729ee664acb66e91f

## 3) Optional knobs
set security macsec connectivity-association ca1 key-server-priority 0
set security macsec connectivity-association ca1 mka-transmit-interval 6000

## 4) Bind to the interface
set security macsec interfaces ge-0/0/1 connectivity-association ca1
commit

The CKN is hex-encoded and identifies the key (it is sent in the clear inside the MKA messages). The CAK is the secret key material proper. Both must be agreed beforehand by the operators of the two ends — Junos has no key-distribution mechanism in static-CAK mode; the keys are typed in by hand.

Two practical points specific to EX4300

• MACsec on EX4300 is supported on uplink modules with the right transceivers, not on the base 1 G access ports. Plan accordingly.
• EX4300 (and EX4600) automatically append SCI tags on outgoing MACsec-secured frames; this option is not configurable on these platforms. (The SCI — Secure Channel Identifier — is an 8-byte field that disambiguates traffic on a multi-channel deployment; on a point-to-point EX link it is harmless either way.)

12.6 Configuring MACsec

The minimum configuration was shown above. A real deployment usually includes a few more options that influence the protocol’s behaviour.

Key server selection

MACsec uses a key-distribution protocol called MKA. Both ends exchange MKA frames; one end is elected the key server and is responsible for generating the per-frame keys (Secure Association Keys, SAKs) used to actually encrypt frames. The election uses the key-server-priority value — lowest wins. Default is 16; for a deterministic election, set it explicitly:

set security macsec connectivity-association ca1 key-server-priority 0   ## this end will be key server
set security macsec connectivity-association ca1 key-server-priority 255 ## this end won't

Replay protection

By default, MACsec checks that incoming frames are not replays of frames already received. The window is configurable:

set security macsec connectivity-association ca1 replay-protect
set security macsec connectivity-association ca1 replay-protect replay-window-size 128

A small replay window is more strict (replays are caught faster) but can cause false drops if the wire is mildly jittery. 128 packets is a safe default.

Cipher suite

MACsec on EX supports GCM-AES-128 (the IEEE-default cipher) and, on newer hardware, GCM-AES-256. The cipher is set per-CA:

set security macsec connectivity-association ca1 cipher-suite gcm-aes-128   ## default
## or, on supported hardware:
set security macsec connectivity-association ca1 cipher-suite gcm-aes-256

Both ends of the link must use the same cipher.

12.7 Verifying MACsec

Three operational commands answer “is this link encrypted, and is the key agreement healthy?”.

user@switch> show security macsec connections
## Lists every CA, the bound interface, and the connection state.
## Look for "Secured" / "Active" — anything else (e.g. "Pending") is a failure.

user@switch> show security macsec connections detail
## Adds the cipher suite, the elected key server, the SAK key number,
## and the time the secure channel was last established.

user@switch> show security macsec statistics interface ge-0/0/1
## Per-interface counters: secured frames in/out, frames decrypted,
## frames discarded by replay protection, frames discarded by integrity
## check. The discard counters should be 0 in steady state.

The most common MACsec failure modes and how the show commands tell you:

Chapter 12 controlled which devices and which links were trusted. This chapter controls which IP and ARP claims those devices are allowed to make. The three features are deeply related: DHCP snooping watches DHCP exchanges and builds a database of legitimate IP/MAC/port bindings; Dynamic ARP Inspection (DAI) uses that database to validate ARP frames; IP Source Guard uses the same database to validate the source IP of every frame. They share the same Junos hierarchy and the same data structure; turning on either DAI or IP Source Guard automatically turns on DHCP snooping on the same VLAN. Lab 6 brings the whole set together.

13.1 DHCP Snooping Concepts

A normal DHCP exchange is four messages: Discover, Offer, Request, Ack. The client broadcasts Discover; the legitimate DHCP server unicasts Offer; the client broadcasts Request; the server unicasts Ack with the lease. Every step is plaintext UDP and there is nothing in the protocol that prevents a second device on the LAN from answering Discover before the real server does. That second device is a rogue DHCP server, and the result — clients with attacker-controlled gateways, DNS, or address ranges — is a man-in-the-middle of the entire VLAN.

DHCP snooping prevents this with a single rule: only trusted ports may originate DHCP server responses. The Juniper documentation puts it as: DHCP snooping enables the switching device to monitor DHCP messages received from untrusted devices connected to the switching device.

Trusted vs. untrusted ports

Per the Juniper TechLibrary: By default, all trunk ports on the switch are trusted and all access ports are untrusted for DHCP snooping. That default is correct for the typical campus — the legitimate DHCP server lives upstream of the access switch and is reached through a trunk; users live behind access ports and must never act as DHCP servers.

The two behaviours, in Junos terms:

The DHCP snooping database

Whenever a legitimate DHCP transaction completes, the EX writes a binding to the snooping database. Per the Juniper documentation, each entry contains current IP-MAC address bindings, as well as lease time, type of binding, names of associated VLANs and interfaces. That database is the data structure DAI and IP Source Guard read from to validate per-frame claims.

13.2 Configuring DHCP Snooping

On a current ELS Junos release, DHCP snooping is enabled per VLAN at the [edit vlans name forwarding-options dhcp-security] hierarchy. The simplest possible enablement is one statement:

[edit]
set vlans data-vlan forwarding-options dhcp-security
commit

From this point, every untrusted port in data-vlan drops DHCPOFFER and DHCPACK frames; every legitimate DHCP transaction is captured into the snooping database and timestamped with the offered lease.

Overriding the default trust

The default (trunks trusted, access untrusted) is correct most of the time but not always. Two scenarios where you need to override:

• An access port that hosts a real DHCP server. A rare scenario, but possible — for example, a small lab DHCP server attached to a regular access port. Mark it trusted so its OFFERs are not dropped.
• A trunk port that should not act as a DHCP relay path. For example, a transit trunk to a partner network where you do not want their DHCP traffic to leak in. Mark it untrusted.

[edit]
set vlans data-vlan forwarding-options dhcp-security group dhcp-server-group overrides trusted
set vlans data-vlan forwarding-options dhcp-security group dhcp-server-group interface ge-0/0/24.0
commit

Marking individual interfaces is done by putting them into a named “group” under the VLAN’s dhcp-security hierarchy and setting the overrides behaviour for the group. The exact statement names vary by Junos release; consult the version-specific documentation (the model in current Junos uses the dhcp-security+group+overrides idiom shown above).

Verification

user@switch> show dhcp-security binding
## Lists every learned IP/MAC/port binding, the VLAN, and the lease time remaining

user@switch> show dhcp-security binding interface ge-0/0/0.0
## Narrowed to one interface

user@switch> show dhcp-security statistics
## How many DHCP messages have been seen / dropped, broken down by reason

An entry that has been in the binding table for longer than the lease has expired is dead-weight; the EX cleans these up automatically as leases time out. A live binding means: this IP has been legitimately leased to this MAC, behind this port, and the lease is still valid.

13.3 The Snoop Database

The DHCP snooping database is the central asset of this whole chapter. Both DAI and IP Source Guard depend on it; an empty database means both protections fail open. Three operational facts to know about it:

Persistence across reboots

By default, the snooping database is in-memory. A reboot wipes it; clients then have to renew DHCP for their bindings to repopulate. Junos supports a persistent snoop file that survives reboots; the relevant statement is set ethernet-switching-options secure-access-port dhcp-snooping-file (in non-ELS releases) or its ELS equivalent — consult the version-specific documentation for the exact path. In a high-availability access switch, configuring the persistent file means DAI and IP Source Guard keep working across a switch restart without users seeing an outage.

Static bindings

For devices that do not use DHCP (servers with static IPs, lab equipment, printers with hard-coded addresses), you can write a static entry into the snooping database. The static binding behaves exactly like a DHCP-learned one for DAI and IP Source Guard purposes — it is a known IP/MAC/port tuple that the switch will validate against.

Static bindings are the bridge between the snoop-based protections of this chapter and the static-MAC table of Chapter 12: a static MAC stops unauthorised devices from sending; a static snoop binding stops unauthorised IP claims.

Lease tracking

Each entry has a remaining-lease counter. Entries are removed automatically when the lease expires; the IP returns to the pool, the MAC is no longer bound, and any frame from that MAC claiming that IP would now fail DAI/IPSG. This is the right behaviour — it stops the “stale binding” class of attack — but it does mean a host that goes silent for longer than its lease will lose its protection until it renews.

13.4 Dynamic ARP Inspection (DAI)

Per the Juniper TechLibrary: Dynamic ARP inspection (DAI) protects switching devices against Address Resolution Protocol (ARP) packet spoofing. DAI inspects ARPs on the LAN and uses the information in the DHCP snooping database on the switch to validate ARP packets and to protect against ARP spoofing.

The threat is ARP cache poisoning: an attacker sends gratuitous ARPs claiming to be the gateway, every host on the VLAN updates its ARP cache to point at the attacker, and the attacker is now in the middle of every conversation. DAI defeats this by checking every ARP on the wire: if the (sender IP, sender MAC, ingress port) tuple does not match a binding in the snooping database, the ARP is dropped.

Configuration

DAI is configured per-VLAN. The Juniper-documented form (and the one tested on the JNCIS-ENT exam) is:

[edit]
set vlans employee-vlan forwarding-options dhcp-security arp-inspection
commit

One statement — that is the entire enablement. From this moment, every ARP frame entering an untrusted port in employee-vlan is validated against the snooping database before it is allowed to forward; mismatches are dropped silently and counted.

Per the Juniper documentation: You configure DAI for each VLAN, not for each interface (port). By default, DAI is disabled for all VLANs. When you enable DAI, the configuration automatically enables DHCP snooping for the same VLAN — you do not need to set dhcp-security separately.

What DAI catches and what it does not

13.5 IP Source Guard

IP Source Guard (IPSG) is the third member of the trio. Where DAI checks the source MAC of an ARP, IPSG checks the source IP of every IP frame. The mechanism is the same: cross-reference the (source IP, source MAC, ingress port) tuple against the DHCP snooping database; drop any frame that does not match.

The threat IPSG defeats is IP spoofing: an attacker on an untrusted port sends frames claiming to be from someone else’s IP, hoping return traffic will be routed back to them or that an upstream firewall will accept the spoofed source as authorised.

Configuration

[edit]
set vlans employee-vlan forwarding-options dhcp-security ip-source-guard
commit

Like DAI, IPSG is per-VLAN; like DAI, enabling it automatically enables DHCP snooping. Once committed, every IP frame entering an untrusted port in employee-vlan is validated against the snooping database; mismatches are dropped.

The full set together

The most common Junos access-edge security profile is to enable all three:

[edit]
set vlans employee-vlan forwarding-options dhcp-security                  ## DHCP snooping
set vlans employee-vlan forwarding-options dhcp-security arp-inspection   ## DAI
set vlans employee-vlan forwarding-options dhcp-security ip-source-guard  ## IPSG
commit

Strictly the first line is redundant — either of the other two implies it — but committing all three explicitly is good documentation.

13.6 Putting It Together — Defending the Access Edge

Across Chapters 7, 10, 11, 12, and 13 we have introduced a stack of port-security features. The standard Junos enterprise access port deployment looks like this:

The features are inexpensive; the cost is in the rollout discipline and in the operational support to keep the snoop database accurate. A campus that turns the whole stack on at once will discover every static-IP printer, every hand-set test workstation, and every ten-year-old appliance that does not speak DHCP — at the same time. Stage the deployment: enable in log action where available; let the binding database populate over a few days; remediate the discoveries; then promote to enforcing mode.

13.7 Lab 6 — Implementing Port Security

Topology

Step-by-step

1. Define the VLAN and put the four ports into it (Chapter 3 patterns):

   set vlans employee-vlan vlan-id 100
   set interfaces interface-range USERS member-range ge-0/0/0 to ge-0/0/1
   set interfaces interface-range USERS unit 0 family ethernet-switching interface-mode access
   set interfaces interface-range USERS unit 0 family ethernet-switching vlan members employee-vlan
   set interfaces ge-0/0/47 unit 0 family ethernet-switching interface-mode access
   set interfaces ge-0/0/47 unit 0 family ethernet-switching vlan members employee-vlan

2. Enable the full snoop stack on the VLAN:

   set vlans employee-vlan forwarding-options dhcp-security
   set vlans employee-vlan forwarding-options dhcp-security arp-inspection
   set vlans employee-vlan forwarding-options dhcp-security ip-source-guard

3. commit and-quit.
4. Power up Client A and Client B. Confirm both get IP addresses by DHCP. Run show dhcp-security binding; you should see two entries, one per client, each with the right MAC, port, and an active lease.

Test 1 — rogue DHCP server

On the attacker port (ge-0/0/47), start a DHCP server (e.g. dnsmasq with a custom config). Boot a fifth client. Without DHCP snooping, the rogue server might race the legitimate one and win; with snooping, the rogue’s OFFER is dropped at the EX:

• The fifth client gets its lease from the legitimate server (or fails to lease, depending on race).
• show dhcp-security statistics shows the dropped server-message counter incrementing.
• The snooping database still contains only legitimate bindings.

Test 2 — ARP cache poisoning

On the attacker port, run a tool such as arpspoof claiming to be the gateway. With DAI enabled:

• The attacker’s gratuitous ARPs are dropped at the EX (no binding matches).
• Client A’s ARP cache continues to point at the real gateway.
• show arp-inspection statistics (or the equivalent for your release) shows the dropped-ARPs counter incrementing.

Test 3 — IP spoofing

On the attacker port, send a frame with source IP equal to Client A’s leased IP (and the attacker’s own source MAC). With IP Source Guard enabled:

• The frame is dropped at the EX — the (src-IP, src-MAC, port) tuple does not match any binding.
• No spoofed traffic reaches the upstream router.
• The IP-source-guard drop counter (visible under show dhcp-security statistics in current Junos releases) shows the event.

Common pitfalls

• Static-IP server traffic dropped after enabling DAI. Add static bindings (set vlans employee-vlan forwarding-options dhcp-security static-ip ... — consult the per-release statement reference for exact syntax) for any device that does not use DHCP.
• Empty snoop database after a reboot. By default the database is in-memory. Enable persistent storage if your campus cannot tolerate a brief outage at boot.
• Slow rollout, fast enforcement. Enabling DAI/IPSG on a VLAN with twenty static-IP devices instantly takes them off the network. Always inventory first; ideally start with audit-only behaviour where the release supports it.

A switch with two Routing Engines (REs) — an EX9200, an EX4400 in some configurations, or an EX4300 / EX4400 Virtual Chassis where two member switches play the master and backup RE roles — can survive an RE failure if it is configured to. The three Junos features that make that survival graceful are Graceful Routing Engine Switchover (GRES), Non-Stop Active Routing (NSR), and Non-Stop Bridging (NSB). This chapter covers each, in the order they must be enabled, and finishes with the verification you do after switchover.

14.1 The Routing Engine Pair

A redundant-RE chassis has two physical RE cards: master (or, in current Junos terminology, primary) and backup. The master runs the configuration, the routing protocol process (rpd), the management daemon (mgd), and writes the FIB to the PFE. The backup runs a quiet copy of Junos with no protocols active and the kernel up only enough to take over if asked.

Without HA features, a master RE failure looks like this: the backup detects the master is gone, takes over as master, and starts cold — protocols re-establish from scratch, the FIB is rebuilt from the RIB, and end-to-end traffic stops for the duration. Recovery is on the order of tens of seconds. With the three HA features enabled, the same failure becomes a sub-second event, invisible to running TCP sessions.

14.2 Graceful Routing Engine Switchover (GRES)

GRES is the foundation. Per the Juniper TechLibrary: GRES enables a device with redundant Routing Engines to continue forwarding packets even if one Routing Engine fails, while preserving interface and kernel information so traffic is not interrupted. The mechanism is a continuous synchronisation of kernel state — interface tables, ARP tables, IGMP/MLD state, and so on — from master to backup. When the backup takes over, it inherits a warm kernel and the PFE’s forwarding tables remain valid.

GRES alone does not preserve routing-protocol state. After switchover the new master’s rpd still has to re-establish OSPF/BGP/IS-IS sessions; while it does, the FIB the backup inherited from the master is what keeps traffic flowing. That is enough for most short failures but not for protracted ones.

[edit]
set chassis redundancy graceful-switchover
set system commit synchronize
commit

The commit synchronize statement is mandatory: it ensures the backup RE always has an exact copy of the master’s configuration. Without it, the backup might come up with a stale config and the switchover behaves unpredictably.

14.3 Non-Stop Active Routing (NSR)

NSR is the next step up. Per the Juniper TechLibrary: NSR uses the same infrastructure as GRES to preserve interface and kernel information, but NSR also saves routing protocol information by running the routing protocol process on the backup Routing Engine. With NSR, OSPF, BGP, IS-IS, LDP, and friends keep their adjacency state on the backup RE; on switchover, the new master continues those sessions without re-establishing them. End-to-end neighbour state remains; traffic does not pause.

NSR requires GRES. The Juniper documentation is explicit: Nonstop active routing (NSR) requires you to configure graceful Routing Engine switchover (GRES). And: If you try to commit the nonstop active routing configuration without including the commit synchronize statement, the commit fails.

[edit]
set chassis redundancy graceful-switchover     ## prerequisite
set system commit synchronize                  ## mandatory
set routing-options nonstop-routing
commit

14.4 Non-Stop Bridging (NSB)

NSB is to L2 protocols what NSR is to L3: it preserves the state of L2 control protocols across an RE switchover. The list of NSB-supported protocols includes RSTP, MSTP, VSTP, LACP, LLDP, and others. Per the Juniper documentation: nonstop bridging (NSB) ensures that all NSB-supported Layer 2 protocols operate seamlessly during the Routing Engine switchover.

NSB also requires GRES. The configuration adds one statement at [edit protocols layer2-control]:

[edit]
set chassis redundancy graceful-switchover     ## prerequisite
set system commit synchronize
set protocols layer2-control nonstop-bridging
commit

For a switch acting as a campus distribution layer running RSTP and LACP downward and OSPF upward, the production-ready HA configuration is all three together: GRES + NSR + NSB.

14.5 Verifying HA State

user@switch> show chassis routing-engine
## Reports each RE's slot, status (Master/Backup), uptime, and load.

user@switch> show system switchover
## Confirms GRES is enabled and reports last switchover time / cause.

user@switch> show task replication
## NSR's protocol-state replication status. Look for "Stable Connected".

The single most useful diagnostic is show task replication — if it reports anything other than Stable Connected for the routing protocols you care about, NSR is not actually protecting you and a switchover will degrade to a GRES-only event.

A Virtual Chassis (VC) is a Juniper-specific construct that lets up to ten physical EX switches present themselves to the rest of the network as one logical device. One IP address, one configuration file, one Spanning-Tree instance, one OSPF process — spread across ten boxes connected by Virtual Chassis Ports (VCPs). This chapter covers the model; Chapter 16 takes you through the configuration and the operational lifecycle.

15.1 Why Virtual Chassis?

Three reasons to put two or more EX4300 switches in a Virtual Chassis instead of leaving them as independent boxes:

• Single management point. One Junos configuration file describes the whole stack. Adding a new VLAN, applying a new ACL, upgrading software — one operation, applied to every member.
• No Spanning Tree on the inter-switch links. The VCPs use a proprietary internal protocol; from RSTP’s perspective, the entire VC is a single bridge. A pair of access switches dual-homed to a VC distribution sees the upstream as one bridge and gets to forward on both uplinks via a LAG — no blocked alternate.
• Sub-second hardware redundancy. If the master fails, the backup takes over (combined with GRES + NSR + NSB from Chapter 14) in milliseconds.

15.2 VCP Ports and Topology

Member switches are interconnected by Virtual Chassis Ports (VCPs). Per the Juniper documentation, on an EX4300-48MP the only ports usable as VCPs are the dedicated 40 Gbps QSFP+ ports on the rear panel; on a standard EX4300, uplink ports can be configured as VCPs at either 40 Gbps (QSFP+) or 10 Gbps (SFP+).

The topology is normally a ring: member 0 to member 1 to member 2 ... back to member 0. The ring gives each member two paths to every other member, so a single VCP failure does not split the chassis. For two-member VCs, two parallel VCPs between the two switches achieve the same redundancy.

A Virtual Chassis can have at most 10 members, numbered 0 through 9. The number is a hard limit per the Juniper hardware guide.

15.3 Member Roles — Master, Backup, Linecard

Every member of a VC plays one of three roles:

15.4 Mastership Election

The master and backup are elected from the members using a multi-step algorithm. Per the Juniper documentation, in most cases the switch that has been powered on the longest assumes the master role when all VC members are configured with the same mastership priority. The full tie-break order:

1. Highest user-configured mastership-priority wins. Range 1–255; default 128.
2. Otherwise, the switch that has been up the longest.
3. Otherwise, the lowest member ID.
4. Otherwise, the lowest base MAC address.

For deterministic behaviour, configure mastership-priority explicitly. The standard pattern is the highest possible value (255) on the intended master, the next-highest (254) on the intended backup, and leave members 2–9 at the default 128.

15.5 Pre-Provisioning vs. Auto-Provisioning

Two ways to bring up a Virtual Chassis:

• Auto-provisioning. Connect the VCPs, power up the switches, and the VC forms by itself using the default member IDs and elected roles. Quickest path to a working VC; the master’s config becomes the VC’s config; subsequent reordering of physical units does not change the logical IDs.
• Pre-provisioning. The administrator declares each member by serial number and assigns it a member ID and role before the switches are connected. The result is deterministic: when switch X with a given serial is plugged in, it always becomes member N. Use pre-provisioning for any production VC where post-deployment serial-to-slot mapping matters.

15.6 Failure Modes

Three classes of failure to plan for:

• VCP link failure. The ring topology means a single VCP failure leaves the chassis whole — the affected pair of members reaches each other via the long way around. A second VCP failure on the same ring can split the chassis into two halves.
• Master failure. With GRES + NSR + NSB enabled, the backup takes over in sub-second time. Without HA features, the takeover is cold.
• Split-brain. If the chassis splits into two halves that can each see a majority of the original members, both halves may try to become independent VCs — with the same configuration, the same IPs, and the same MAC addresses. This is the catastrophic failure mode. Junos provides split-detection mechanisms; consult the Juniper TechLibrary for the configuration of split-detection on your platform and Junos release.

Chapter 15 covered the model. This chapter is the practical deployment: cabling, configuration commands, software upgrades using NSSU, and Lab 7. Every CLI snippet is from the Juniper TechLibrary EX4300 Virtual Chassis configuration page.

16.1 Cabling and Topology Choices

For a 2-member EX4300 VC, run two parallel 40 G QSFP+ links between the two switches and configure them as VCPs. For three or more members, use the ring topology: each member connects to its two neighbours, and the last connects back to the first. The ring tolerates one VCP link or transceiver failure with no service impact.

Two further constraints to remember from the Juniper hardware documentation:

• EX4300 and EX4300-MP are non-mixed VCs only — you cannot mix EX4300-MP with EX4300 base in the same VC.
• EX4300-48MP must use the rear-panel dedicated 40 Gbps QSFP+ ports for VCPs; uplink-port-as-VCP is not supported on this model.

16.2 Configuring a 4-Member Virtual Chassis

The pre-provisioned form is the recommended production pattern. Each member is named by serial number and assigned a member ID and a role.

[edit]
set virtual-chassis preprovisioned

## Each member: serial number + member ID + role
set virtual-chassis member 0 serial-number PE3713070123 role routing-engine
set virtual-chassis member 1 serial-number PE3713070124 role routing-engine
set virtual-chassis member 2 serial-number PE3713070125 role line-card
set virtual-chassis member 3 serial-number PE3713070126 role line-card

## Optional but recommended: explicit mastership priority
set virtual-chassis member 0 mastership-priority 255
set virtual-chassis member 1 mastership-priority 254

## Convert uplink ports into VCPs (only required if not using dedicated VCPs)
## On EX4300 with QSFP+ uplinks, use the operational-mode command:
## request virtual-chassis vc-port set pic-slot 1 port 0

commit

The role values are routing-engine for the master/backup pair and line-card for the rest. Members designated as routing-engine are eligible to be elected master or backup; those designated line-card are not.

16.3 Adding and Removing Members

To add a fifth member to an existing 4-member VC:

1. Cable the new switch into the ring (extend the loop to pass through the new unit).
2. Power the switch on. It boots; it sees the existing VC’s VCP traffic; it requests entry.
3. If the VC is pre-provisioned, add a new member 4 stanza naming the new serial number; commit. The new switch is admitted, takes the linecard role, and starts forwarding.
4. If the VC is auto-provisioned, the new switch is admitted automatically using the next available member ID.

To remove a member, first reassign its load (move trunks, drain LAGs); then power it down or unplug its VCPs; the ring auto-heals via the long way around.

16.4 Software Upgrades (NSSU)

Non-Stop Software Upgrade (NSSU) lets you upgrade a Virtual Chassis to a new Junos image without taking the chassis out of service. NSSU upgrades members in a controlled sequence: first all linecards (one at a time), then the backup RE, then a switchover, then the old master.

NSSU prerequisites are GRES and NSB (NSR is also recommended for L3 environments). Per the Juniper documentation, NSB does not have to be enabled to perform an NSSU, but enabling it ensures that all NSB-supported Layer 2 protocols operate seamlessly during the Routing Engine switchover — which is the whole point.

user@switch> request system software nonstop-upgrade /var/tmp/junos-image.tgz

The upgrade runs to completion over several minutes; data-plane forwarding continues throughout.

16.5 Troubleshooting Virtual Chassis

user@switch> show virtual-chassis
## Lists every member, its role, member ID, mastership priority, and status.

user@switch> show virtual-chassis vc-port
## Lists every VCP, peer member, and link status.

user@switch> show virtual-chassis status
## Summary of VC health, including any split-detection state.

The most common symptom of a broken VC is a member showing NotPrsnt in show virtual-chassis. That means the master cannot reach the unit through any VCP path — usually a cable problem on both sides of the ring at once, or a unit that has crashed. Trace each VCP with show virtual-chassis vc-port.

16.6 Lab 7 — Implementing Virtual Chassis Systems

1. Cable two parallel 40 G QSFP+ links between the rear-panel ports of the two EX4300s. Convert them to VCPs with request virtual-chassis vc-port set on each side.
2. On both switches, apply the pre-provisioned configuration (Section 16.2 pattern). Use serial numbers from show chassis hardware on each unit.
3. Add HA layer:

   set chassis redundancy graceful-switchover
   set system commit synchronize
   set routing-options nonstop-routing
   set protocols layer2-control nonstop-bridging

4. Commit. Verify with show virtual-chassis — both members up, one as Master, the other as Backup.
5. Generate continuous traffic between two hosts, each plugged into a different member.
6. Initiate a switchover: request chassis routing-engine master switch. The active master changes; traffic does not pause.
7. Run NSSU: copy the new Junos image to /var/tmp, run request system software nonstop-upgrade. Upgrade runs over ~10 minutes; ping continues throughout.

If at any point ping pauses for more than ~1 second, one of the HA pre-conditions is missing — usually commit synchronize or graceful-switchover. Re-verify before continuing.

Mist Wired Assurance is Juniper’s cloud-managed model for EX and QFX switches. The same Junos OS still runs on the box; what changes is who configures it (the Mist cloud, via templates), where telemetry goes (to the Mist cloud, where it drives the SLE dashboard), and how anomalies are surfaced (through Marvis, Mist’s AI-driven assistant). This chapter introduces the model; Chapter 18 takes you through Day-One adoption.

17.1 Mist Cloud Architecture

Mist is a multi-tenant SaaS platform run by Juniper. Customer organisations are tenants; each tenant has one or more sites; each site has switches, access points, and (optionally) WAN devices adopted into it. Adopted devices send telemetry to Mist over a secure outbound TLS connection; Mist sends configuration back. The connection is initiated outbound from the device, so no inbound firewall holes are required.

The core data flow:

• Switch → Mist: streaming telemetry (interface counters, MAC table, LLDP neighbours, environmentals, syslog) at near-real-time intervals.
• Mist → Switch: configuration changes from templates, software upgrade triggers, on-demand diagnostic commands.

17.2 What "Wired Assurance" Means

Per the Juniper Mist Wired Assurance datasheet, the product provides operational visibility into the wired experience with SLEs for Juniper EX and QFX Switches. Wired Assurance is therefore the bundle of features that turn raw switch telemetry into actionable user-experience metrics: how often clients connect successfully, how often DHCP works, how long authentication takes, where traffic is hitting interface errors, where Spanning Tree is unstable. These are the questions an operations team actually asks; Wired Assurance computes the answers from the telemetry stream.

17.3 Provisioning Options

Two patterns to put a switch under Mist’s control:

• Greenfield (zero-touch). A new switch boots, contacts Juniper’s redirect service, is pointed at the customer’s Mist tenant, and adopts itself with a single activation code. The operator has no console session at any point. The Juniper Mist datasheet describes this as true plug-and-play capabilities, the wired switches can be onboarded by the cloud with a single activation code.
• Brownfield (existing deployment). An EX already in production is adopted by running a one-line CLI command on the switch. Per the Juniper documentation: existing (brownfield) EX deployments can take advantage of Wired Assurance as well, once adopted to the cloud. The switch keeps its current configuration; new configuration changes can then be made through Mist.

17.4 The Telemetry Pipeline

Every adopted switch streams a continuous set of metrics to Mist. The collected categories include:

• Per-interface byte and packet counters, error counters, broadcast/multicast counters.
• MAC table summaries (size, flap rate per interface).
• LLDP neighbour information (who is on each port, with what capabilities).
• Spanning Tree topology and topology-change counts.
• VLAN membership and DHCP snooping bindings.
• Environmental (temperature, fans, PSU).
• Syslog events and configuration changes.

Mist correlates these across the site to compute the SLEs.

17.5 The SLE Framework

SLE stands for Service Level Expectation. Per the Juniper Wired Assurance datasheet, the framework enforces throughput, successful connects, switch health, and switch bandwidth, with pre- and post-connection performance metrics. The SLEs that ship with Wired Assurance:

• Throughput — were applications able to push the data they wanted to?
• Successful connects — what fraction of connection attempts succeeded?
• Switch health — were the switches themselves healthy (CPU, memory, environmentals)?
• Switch bandwidth — were uplinks within their utilisation budgets?

Each SLE is a percentage with a drill-down: when an SLE is below 100%, Mist breaks the deficit down by root cause — bad cable, port negotiation mismatch, congestion, authentication failure, and so on. Marvis (Mist’s AI assistant) overlays anomaly detection: Marvis brings proactive anomaly detection into the SLE dashboard so users know when there are deviations from established baselines.

Day-One Mist deployment is mostly clicks-in-the-cloud, not CLI. This chapter walks through the practical steps and the verification an operator does on the morning after.

18.1 Adopting an EX into Mist

To adopt a brownfield EX into Mist, the operator generates an adoption command from the Mist UI (Organisation → Switches → Adopt Switches), copies it, and pastes it onto the switch CLI. The command sets the Mist Cloud URL on the switch and triggers the outbound TLS connection. After a few seconds the switch appears in the Mist UI with status Connected; the operator assigns it to a site.

For greenfield zero-touch, no CLI is required at all: the switch boots, fetches its activation code from Juniper’s redirect service, and adopts itself.

18.2 Templates and Switch Profiles

Configuration in Mist is hierarchical. A template defines the standard config for a class of switches (for example, “branch access switch” or “campus distribution”). A template is assigned to a site or a site-group, and applies to every adopted switch matching the model. Inside a template you set:

• Default VLAN list and VLAN names.
• Port profiles (access port for users, trunk port for APs, etc.).
• RADIUS / TACACS+ servers for switch admin.
• SNMP, syslog, NTP destinations.
• Auto-upgrade target Junos image.

A switch profile is a per-port assignment within a template — a profile-based way of saying “ports 1–24 are access in the data VLAN with voice tagged on top, ports 47–48 are trunks with all VLANs.” Mist compiles the template + profile assignments into Junos CLI behind the scenes and pushes the result to the switch.

18.3 Configuration Through Mist

Per the Juniper Mist datasheet, consistent configurations can be enabled via global templates through the cloud with the flexibility to configure specific switch and site attributes. The Mist UI exposes the same VLAN, RSTP, MAC-limit, MACsec, DHCP-snooping primitives covered in earlier chapters of this book — the difference is the entry point. A change applied to a template propagates to every assigned switch within seconds; rollback is one click.

For configuration that is not yet exposed through the Mist UI, you can include raw Junos CLI snippets in the “Additional CLI Commands” field of the template; Mist appends them to the generated configuration on commit.

18.4 Wired Assurance SLEs in Action

Once a site has switches adopted and traffic flowing, the SLE dashboard becomes the operations team’s daily view. A typical morning workflow:

1. Open the Mist UI and select the site.
2. The four Wired SLEs (Throughput, Successful Connects, Switch Health, Switch Bandwidth) are shown as percentages, each with a 24-hour trend graph.
3. Click on any SLE under 100% to see the breakdown by root cause — bad cable, port negotiation mismatch, STP loop, authentication failure, etc.
4. Drill in further: which port, which client, which time window. This is the actionable list for the day’s tickets.

18.5 Marvis and Wired Insights

Marvis is Mist’s AI-driven assistant, accessible through a search bar at the top of every Mist UI page. The Wired Assurance datasheet enumerates the issues Marvis Actions surface proactively: missing VLANs, DHCP failure scopes, wired authentication failures, bad cables, port negotiation mismatches, persistently failing clients, detection of L2 loops, misconfigured ports, and traffic loops.

Marvis also accepts natural-language queries (“why can client mac:00:50:56:c0:01:7e not connect?”) and returns a structured answer that draws on the telemetry pipeline. For an operations team, Marvis is the difference between “reading dashboards” and “asking questions.” The two are complementary and both are part of the Wired Assurance subscription.

This concludes the main body of the book. The appendices that follow give you a one-glance Junos CLI reference for switching, a JNCIS-ENT exam-objectives traceability map, lab walk-throughs, a glossary, and a 60-question mock exam. Use them as you study; revisit them during the exam itself if it is open-book in your testing centre’s configuration. Good luck.