JNCIE-SEC key terms

A partitioning feature on Junos security devices that splits one physical chassis into multiple independent routing instances, each with its own policies, zones, and interfaces. Traffic between logical systems is treated like inter-device traffic and requires explicit configuration.

A named collection of interfaces that share a common security policy boundary. Zones are the primary match criterion in policy evaluation, and traffic direction between zones determines which policy sets apply.

A routing instance on a security device that maintains its own routing table and protocol processes. Multiple virtual routers allow overlapping address space and separate routing domains on a single chassis.

A container holding a distinct set of routing tables and interfaces. On SRX devices, virtual routers and virtual switches are types of routing instances used to isolate traffic and support overlapping subnets.

A Layer 2 routing instance on SRX that bridges interfaces within an isolated broadcast domain. It is used for transparent-mode deployments and for separating Layer 2 segments without a separate device.

An SRX operating mode where the device forwards frames at Layer 2 without acting as a routing hop. Security policies still apply, but IP addresses on protected hosts are preserved end to end.

A high-availability pair of SRX devices that share a control link and fabric link to act as one logical device. It provides redundancy through active/passive or active/active failover and state synchronization.

A numbered failover unit within a chassis cluster that owns a set of interfaces and services. Each group has its own priority and failover thresholds, allowing selective failover per redundancy group.

The process by which a chassis cluster copies session state, including NAT translations and ALG state, from the primary node to the secondary. It enables established flows to survive a failover without renegotiation.

The two dedicated connections in a chassis cluster. The control link carries heartbeats and cluster control traffic, while the fabric link carries data-plane traffic and session state synchronization between nodes.

A stateless Junos filter applied to an interface or routing engine that matches packet header fields and takes actions such as accept, discard, or count. It is evaluated before security policy processing.

An ordered rule that matches traffic by zone pair, source and destination address, application, and user, then applies an action such as permit, deny, or reject. Policies are evaluated top-down with first match winning.

The rule that Junos evaluates security policies sequentially from the top of the policy set and stops at the first match. Ordering therefore determines outcomes, and shadowed or unreachable policies must be avoided.

A configuration error where a broader policy higher in the list matches traffic intended for a more specific policy below it. The specific rule never evaluates, producing unexpected permits or denials.

A feature that classifies traffic by inspecting payload signatures rather than relying solely on port and protocol. It enables policies based on actual applications such as social media or peer-to-peer clients.

A rule set layered on top of AppID that controls specific application actions, such as blocking file uploads or IM file transfers. It refines coarse permit decisions into granular application-level control.

A bundle of content security features including antivirus, antispam, Web filtering, and content filtering applied within a security policy. UTM profiles are attached to policy rules to inspect permitted traffic.

Traffic where source and destination interfaces belong to the same security zone. By default it is denied, and permitting it requires explicit intra-zone policy configuration or a host-inbound-traffic setting.

Traffic destined to the device itself, such as management, routing protocols, or ICMP. It must be explicitly allowed per interface or zone, independent of transit security policies.

The initial negotiation that establishes a secure channel between peers, authenticating them and agreeing on encryption and hashing for the management tunnel. It uses main or aggressive mode with pre-shared keys or certificates.

The negotiation that creates the unidirectional security associations protecting actual user data. It defines the proxy IDs, protocols, and encryption parameters used for the data tunnel.

The traffic selector in Phase 2 that specifies which source and destination subnets are protected by a tunnel. Mismatched proxy IDs between peers are a common cause of failed tunnel establishment.

The pair of local and remote prefixes that defines interesting traffic for an IPsec tunnel. Only packets matching the selector are encrypted and sent through the tunnel.

The second version of the Internet Key Exchange protocol, offering simpler negotiation, built-in NAT traversal, and support for MOBIKE. Junos supports IKEv1 and IKEv2, with IKEv2 preferred for new deployments.

NAT Traversal encapsulation that wraps IPsec ESP packets in UDP port 4500 so they can pass through NAT devices that cannot translate ESP. Both peers must support it for the tunnel to work through NAT.

A hub-and-spoke IPsec feature where spoke devices establish tunnels automatically with minimal configuration. The hub uses a group IKE identity and point-to-multipoint setup to accept many spokes.

Translation that rewrites the source address of outbound packets, typically to hide internal addresses behind a public pool. It supports interface, pool-based, and persistent address translation variants.

Translation that rewrites the destination address of inbound packets, used to publish internal servers behind a public address. It is commonly paired with a security policy permitting the translated flow.

A one-to-one mapping between an internal address and an external address that persists regardless of traffic. It allows inbound connections to reach a specific internal host without dynamic allocation.

A configured range of addresses used for source NAT translation. Pools can be configured for round-robin or persistent allocation, and address persistence affects how long a mapping is retained.

A setting that keeps a translated address and port bound to a given host for a defined period, ensuring return traffic maps back correctly. It matters for applications that require stable addressing.

A component that inspects and fixes up application payloads containing embedded IP addresses or ports, such as FTP or SIP. ALGs ensure those protocols work correctly across NAT and firewall boundaries.

The stateful database tracking active flows, including addresses, ports, sequence state, and associated NAT translations. Policy and ALG decisions rely on entries created on the first packet of a flow.

A Python library for automating Junos devices over NETCONF or the CLI. It provides object models for configuration and operational data, making scripted tasks like audits and provisioning straightforward.

An XML-based protocol for configuring and retrieving data from network devices. Junos supports NETCONF over SSH, and it is the transport used by many automation frameworks including PyEZ and Ansible.

A script that runs during the commit process to validate or modify configuration before it is applied. It can reject invalid configurations or automatically add required settings.

A script executed from the CLI that automates operational tasks, such as gathering interface statistics or performing health checks. It can be written in SLAX, XSLT, or Python.

A diagnostic feature that logs detailed packet processing decisions, including policy lookups and NAT results, for traffic matching configured filters. It reveals why a session was permitted or dropped.

A debugging mechanism that copies matching packets to a file for analysis, configured with capture filters and file parameters. It is used to verify whether traffic arrives and how it is altered.