PDF JN0-106 Study Guide

In Junos OS, a routing policy is a powerful tool used to manage the flow of routing information between the Routing Information Base (RIB) and routing protocols. Unlike forwarding decisions, which are handled by the Packet Forwarding Engine, routing policies function within the control plane on the Routing Engine. Their primary purpose is to define specific criteria for importing routes into the routing table from neighbors or exporting routes from the routing table to neighbors.

Routing policies consist of terms containing from (match) and then (action) statements. They allow administrators to filter prefixes (e.g., denying specific BGP routes), modify route attributes (e.g., changing OSPF metrics or BGP communities), and manipulate path selection behavior. For example, an export policy might be used to ensure that only specific internal subnets are advertised to an ISP via BGP, preventing the accidental leakage of private infrastructure addresses. By default, Junos applies " default policies " for each protocol (such as OSPF accepting all OSPF routes), but custom policies allow for granular control over how the device interacts with the rest of the network. This ensures that the routing table contains only the desired paths for optimal traffic engineering.

In Junos OS, route preference (often referred to as administrative distance in other operating systems) is the mechanism used to select the " best " path when the routing table receives multiple advertisements for the exact same destination prefix from different routing sources. The core rule for preference is that lower values indicate a more preferred or " higher priority " route . For example, a direct route has a default preference of 0, a static route is 5, and OSPF internal routes are 10. If a router learns about the same network from both OSPF and a static entry, it will select the static route because 5 is lower than 10.

Crucially, route preference is only evaluated after the longest prefix match (LPM) has been determined. LPM is the absolute first step in packet forwarding; the router will always choose the most specific route available (e.g., a /28 over a /24). Only if there are multiple entries for that same /28 does the router look at preference to break the tie. It is a common misconception that a lower preference value can override a more specific prefix; in reality, a /32 route with a preference of 170 (BGP) will always win over a /24 route with a preference of 5 (Static). Understanding this hierarchy is vital for network architects when designing redundant paths and predictable failover behaviors.

Junos OS is distinguished from legacy network operating systems by its modern, modular architecture . Unlike a monolithic system where a single failure can crash the entire kernel, Junos runs various software functions—such as the routing protocol process (rpd), the interface process (dcd), and the management daemon (mgd)—as independent processes in their own protected memory spaces. This modularity ensures high availability; if one daemon encounters an error, it can be restarted without impacting the overall system stability or traffic forwarding.

Furthermore, Junos OS is a leader in automation features . It was built with a programmable foundation, utilizing an XML-based configuration database and supporting NETCONF for standardized remote management. This allows network architects to utilize modern DevOps tools like Ansible, Python (PyEZ), and SaltStack to automate complex configuration tasks, perform bulk upgrades, and enforce state compliance. By treating the network as code, Junos enables high-velocity operations that reduce human error. While Junos originally powered routers, it now runs across a vast portfolio including EX/QFX switches and SRX firewalls, proving its versatility far beyond just routing platforms.

Physical layer connectivity for Junos devices involves a variety of media types, with fiber-optic cabling being the standard for high-speed, long-distance, or high-density uplink requirements. Two of the most prevalent connector types used in these environments are the LC (Lucent Connector) and the SC (Subscriber Connector) .

The LC connector is a small-form-factor (SFF) connector that uses a 1.25 mm ferrule. Due to its compact size and " push-and-latch " mechanism, it is the primary connector type found on SFP, SFP+, and XFP transceivers used in Juniper EX, MX, and QFX series hardware. Its high-density design allows for more ports in a limited space on a line card or chassis. The SC connector , often referred to as a " square connector, " utilizes a larger 2.5 mm ferrule and a " push-pull " snapping mechanism. While it was highly common in older legacy hardware and fiber patch panels, it has largely been superseded by the LC in modern data center and enterprise switching environments.

In contrast, the RJ-45 is a standard copper Ethernet connector (typically used with Category 5e/6 cables), and the BNC (Bayonet Neill–Concelman) is a miniature quick connect/disconnect RF connector used for coaxial cable. As a Senior Architect, distinguishing between these physical interfaces is critical when specifying the correct Small Form-factor Pluggable (SFP) modules and patch cables required to bring a Junos interface into an operational up/up state.