1.2 Junos CLI, Enterprise Platforms & Interface Families

Junos CLI, Enterprise Platforms & Interface Families

The Junos operating system is built upon a modular architecture that separates control processing from hardware forwarding. Understanding this separation, along with physical interface hierarchy, protocol family capabilities, and configuration transaction controls, is essential for operating Junos enterprise platforms.

1. Junos Architecture: Routing Engine vs Packet Forwarding Engine

At the core of Junos OS lies a clean architectural division between two specialized functional components:

+-----------------------------------------------------------------------------------------+
|                                    ROUTING ENGINE (RE)                                  |
|  - Intel x86 or PowerPC CPU running FreeBSD Kernel                                      |
|  - Routing Protocol Daemon (rpd): OSPF, IS-IS, BGP calculation & master RIB             |
|  - Management Daemon (mgd): CLI parsing, user sessions, commit processing               |
|  - Device Control Daemon (dcd): Interface configuration & state coordination            |
|  - Chassis Daemon (chassisd): Power supplies, fans, temperature monitoring, line cards   |
+-----------------------------------------------------------------------------------------+
                                             |
                                  Internal Dedicated Link
                                (Rate-Limited Control Plane)
                                             |
+-----------------------------------------------------------------------------------------+
|                               PACKET FORWARDING ENGINE (PFE)                             |
|  - Custom ASICs (Trio, Express) or High-Speed Merchant Silicon                          |
|  - Hardware Forwarding Table (FIB): Synchronized from Routing Engine                    |
|  - Wire-Speed Layer 2 Switching: MAC learning, frame flooding, VLAN tagging             |
|  - Layer 3 Longest-Prefix Match (LPM) IP lookups                                        |
|  - Stateless Firewall Filtering, Policers, Class of Service (CoS) Queuing               |
+-----------------------------------------------------------------------------------------+

The Routing Engine (RE)

The Routing Engine is the brain of the device. It executes the FreeBSD-based Junos kernel and hosts all user-space management and protocol daemons:

• rpd (Routing Protocol Daemon): Calculates shortest paths, exchanges protocol messages (OSPF Hellos, BGP OPEN/UPDATE, IS-IS LSPs), and constructs the master routing tables (inet.0 for IPv4, inet6.0 for IPv6).
• mgd (Management Daemon): Manages incoming user sessions (console, SSH, NETCONF), processes candidate configuration edits, and oversees the commit engine.
• dcd (Device Control Daemon): Translates interface configuration hierarchies into low-level driver commands.
• chassisd (Chassis Daemon): Monitors environmental hardware, fan trays, power supplies, transceivers, and line cards.

The Packet Forwarding Engine (PFE)

The Packet Forwarding Engine is the high-performance data plane. It processes transit traffic directly in application-specific integrated circuits (ASICs) or optimized network processors. The PFE receives a compiled copy of the forwarding state—the Forwarding Information Base (FIB)—from the RE. When transit packets traverse the switch, the PFE performs destination address lookups, evaluates firewall filters, decrements TTL, rewrites Layer 2 MAC headers, and handles queue scheduling without taxing the RE CPU.

The RE-to-PFE Interconnect

Communication between the RE and PFE occurs across an internal bus or dedicated Ethernet link. This internal channel carries:

1. Control updates: FIB installation, interface status notifications, and microcode commands.
2. Punt traffic: Packets destined to the device itself (such as SSH management sessions, ICMP echoes to local IPs, OSPF hello packets, and BGP keepalives).
3. Transit generation: Traceroute replies or ICMP time-exceeded messages originating from the PFE.

Because this internal link represents a finite bandwidth resource, Junos incorporates built-in internal rate-limiters and DDoS protection mechanisms to prevent flooded transit packets from overwhelming the RE.

2. Enterprise Hardware Platforms

In enterprise architectures, Junos OS operates across three core hardware families:

3. Interface Naming Hierarchy & Types

Junos identifies physical and logical interfaces using a structured, deterministic naming convention:

type-fpc/pic/port.unit

Physical Interface Component Breakdown

• Type Prefix: Describes the physical media type and bandwidth capability:
  • ge-: Gigabit Ethernet (1 Gbps)
  • xe-: 10-Gigabit Ethernet (10 Gbps)
  • mge-: Multi-Gigabit Ethernet (1/2.5/5/10 Gbps supported on EX4400 multi-gig models)
  • et-: 40-Gigabit, 100-Gigabit, or 400-Gigabit Ethernet
• FPC (Flexible PIC Concentrator): Identifies the hardware slot in a chassis, or the member ID (0 through 9) within an EX Series Virtual Chassis. On standalone fixed-configuration switches, the FPC number is 0. On member 2 of a Virtual Chassis, the port becomes ge-2/0/0.
• PIC (Physical Interface Card): Designates the sub-module or fixed port group. Fixed front-panel base ports reside on PIC 0. Optional uplink module slots typically map to PIC 1 or 2.
• Port: The zero-indexed physical port number on that PIC (e.g., 0 through 47).

Special Enterprise Interface Types

Beyond physical Ethernet ports, enterprise Junos configurations rely on specialized logical and virtual interfaces:

• ae (Aggregated Ethernet): Represents an IEEE 802.3ad Link Aggregation Group (LAG). Individual physical ports (ge- or xe-) are bound into an ae bundle (e.g., ae0, ae1) to provide link redundancy and aggregated bandwidth.
• irb (Integrated Routing and Bridging): The logical routed interface in Enhanced Layer 2 Software (ELS). It terminates a Layer 2 VLAN and serves as the Layer 3 default gateway for connected hosts (e.g., irb.10 bound to VLAN 10).
• lo0 (Loopback Interface): A virtual interface residing on the Routing Engine. Unit lo0.0 is commonly configured with a host IP address (/32 or /128) to serve as the stable OSPF/BGP router ID, BGP peering endpoint, and target for local control plane firewall filters.
• me0 / fxp0 / em0: Dedicated out-of-band management Ethernet interfaces connected directly to the RE CPU, bypassing the PFE data plane.

4. Protocol Families & Switched vs Routed Port Rules

Logical interfaces (unit <number>) require a protocol family definition to instruct the PFE how to handle frames. The primary protocol families in enterprise routing and switching include:

• family ethernet-switching: Configures Layer 2 bridging, MAC address learning, 802.1Q tagging, and VLAN membership on access and trunk switchports.
• family inet: Enables IPv4 protocol processing and assigns IPv4 addresses for Layer 3 unicast routing.
• family inet6: Enables IPv6 protocol processing, neighbor discovery, and IPv6 unicast routing.
• family iso: Enables Connectionless Network Service (CLNS) protocol processing, required exclusively for IS-IS routing.

The Fundamental Rule: Switched vs Routed Units

A critical rule on Junos EX Series enterprise switches dictates:

An interface logical unit cannot run both family ethernet-switching and family inet (or family inet6) simultaneously.

If a port connects to an end-user workstation, access point, or trunk link to another switch, unit 0 is configured under family ethernet-switching. If that VLAN requires a Layer 3 default gateway, routing is not configured on the physical port; instead, an irb logical interface is created under family inet and bound to the VLAN:

[edit]
user@EX4300# show interfaces ge-0/0/10
unit 0 {
    family ethernet-switching {
        interface-mode access;
        vlan {
            members DATA_VLAN;
        }
    }
}

[edit]
user@EX4300# show interfaces irb
unit 10 {
    family inet {
        address 10.1.10.1/24;
    }
}

[edit]
user@EX4300# show vlans DATA_VLAN
vlan-id 10;
l3-interface irb.10;

Conversely, if an EX switchport connects directly to an upstream enterprise router (such as an MX or SRX), it can be configured as a pure routed point-to-point interface by placing family inet directly on unit 0 without any Layer 2 switching commands:

[edit]
user@EX4300# show interfaces ge-0/0/0
description "Routed Uplink to Campus Core Router";
unit 0 {
    family inet {
        address 192.168.100.2/30;
    }
}

5. Configuration Lifecycle: Candidate Commits & Rollback Control

Junos uses a transactional configuration model rather than an immediate-execution model. When an administrator modifies the configuration, changes reside exclusively in a candidate configuration buffer. The live operational state of the device remains untouched until an explicit commit command is issued.

Essential Commit Operations

• commit check: Evaluates the candidate configuration for syntax errors, missing mandatory parameters, and conflicting statements without activating the configuration or affecting forwarding.
• commit confirmed <minutes>: Essential safeguard for remote administration. Activates the candidate configuration while starting an automatic rollback timer (default 10 minutes if no duration is specified). If the administrator loses connectivity or fails to enter a subsequent confirming commit command before the timer expires, the switch automatically rolls back to the previous configuration and commits it, restoring previous access.
• commit comment "<text>": Attaches an audit string to the commit history, visible via show system commit.
• commit at <time>: Schedules a configuration commit for a future maintenance window.

Rollback Mechanisms

Junos retains the active configuration plus up to 49 previous configurations (rollback 0 through rollback 49):

• rollback 0: Discards all uncommitted changes currently in the candidate configuration buffer, resetting the candidate configuration to match the currently running active configuration.
• rollback 1: Loads the configuration that was active immediately prior to the most recent commit.
• rollback <n>: Replaces the candidate configuration with historical configuration n.
• show | compare: Displays an annotated diff (using + and -) comparing the active running configuration with candidate edits.
• show | compare rollback <n>: Displays a diff comparing the candidate configuration against historical commit n.