JN0-352 Exam Questions Tutorials

The BGP finite state machine defined in RFC 4271 progresses through Idle, Connect, Active, OpenSent, OpenConfirm, and finally Established. The Active state is entered either directly after Idle, when the local router begins retrying a TCP connection setup toward the configured peer, or after a previous Connect attempt has failed and the ConnectRetry timer has expired, prompting the router to keep trying to complete the underlying TCP three-way handshake. Seeing a peer parked in Active therefore means the local device has a fully valid neighbor configuration and is persistently attempting to reach the remote address on TCP port 179, but the handshake is not succeeding — common root causes include a firewall or ACL blocking TCP 179 between the two endpoints, an unreachable or incorrect peer IP address, the remote BGP process not running or not listening, or an asymmetric routing path preventing the SYN/ACK from returning. It does not indicate a misconfiguration on the local box in the sense of a missing statement (that would typically leave the session as Idle), nor does it indicate an established, functioning session exchanging UPDATE messages (that state is Established), and it is not a deliberately idle/disabled condition, which Junos reports plainly as Idle. Recognizing Active as 'trying to connect' rather than 'connected' is essential for correct BGP troubleshooting sequencing. Reference topics: Junos Enterprise Routing – BGP Fundamentals, BGP Finite State Machine and Session Verification.

The Junos BGP path selection algorithm proceeds through a strict, ordered sequence of comparison steps, and once next-hop reachability and route preference (administrative distance) have been confirmed as equal, local preference is the very first BGP-specific path attribute evaluated in the decision process. A route carrying a higher local preference value is always chosen over a competing route to the same prefix with a lower local preference, and this comparison takes absolute precedence over every subsequent attribute in the algorithm; if local preference values differ between candidate paths, the selection process concludes at this step without ever needing to examine AS path length, origin type, or MED at all. Only when two or more competing paths share an identical local preference value does the algorithm proceed to its third step, comparing AS path length and preferring the shortest, and only after a further tie does it move on to origin type (preferring IGP-origin over EGP-origin, and EGP-origin over incomplete), followed by MED comparison (preferring the lowest value, and only among routes learned from the same neighboring AS by default). Because local preference is evaluated strictly before all three of the other listed attributes, it is the attribute BGP consults first among the choices given, making it the deciding factor in scenarios such as this exhibit where multiple autonomous systems advertise competing paths toward the same 192.168.1.0/24 prefix. Reference topics: Junos Enterprise Routing – BGP, Understanding BGP Path Selection Order.

Root protection (root guard) must always be applied on the ports of the switches you trust to remain root-bridge-eligible, specifically on the interfaces facing away from the legitimate root and toward parts of the network where an untrusted or rogue device could plausibly appear and begin transmitting superior BPDUs. In this topology, Switch-1 is the intended, permanent root bridge (lowest priority, 4k), and Switch-2 is its aggregation-layer peer; both sit above the access layer, where Switch-3 and Switch-4 connect downstream toward end-user-facing infrastructure and where an accidental or malicious rogue switch is realistically most likely to be introduced. The ge-0/0/6 and ge-0/0/8 interfaces on Switch-1 and Switch-2 are precisely the downlink ports facing that access layer, meaning they are the exact points at which a rogue switch's superior BPDU (one advertising a lower priority than the legitimate root) would first be received if such a device appeared beneath Switch-3 or Switch-4. Applying root protection on those specific interfaces causes Junos to immediately block (move to a root-inconsistent, discarding state) any port that receives a superior BPDU, preventing the rogue device from ever being accepted as root, while normal, non-superior BPDUs continue to be processed without disruption. Applying root guard on Switch-1 and Switch-2's peer link (ge-0/0/12/13) would be inappropriate, since that link legitimately connects two trusted, root-eligible switches. Reference topics: Junos Enterprise Switching – Spanning Tree Protocols, Root Protection Placement Strategy.

The virtual-router routing-instance type in Junos is a general-purpose instance type intended for creating isolated, independent routing and forwarding contexts within a single physical device for applications that have nothing to do with MPLS-based VPN services — common use cases include multi-tenant network segmentation, filter-based forwarding deployments, and simple traffic isolation between departments or customers on a shared switch or router, all of which are non-VPN-related applications by nature. Layer 2 and Layer 3 VPN services, by contrast, rely on a different, dedicated routing-instance type specifically named vrf, which integrates with MPLS/BGP-based VPN signaling, route distinguishers, route targets, and PE-CE routing exchange; virtual-router instances do not participate in that VPN signaling framework at all, which is why the statement associating virtual-router with VPN use is incorrect. Whenever an administrator creates any user-configured routing instance — regardless of its specific type — Junos automatically allocates and generates a brand-new, dedicated routing table for that instance, named according to the pattern instance-name.inet.0 (or the appropriate address-family suffix), which is entirely separate from and independent of the default master inet.0 table used by the global/default routing context. Because each new routing instance receives its own distinct table rather than sharing or defaulting into the master inet.0 table, the statement claiming instances automatically fall back to using inet.0 unless configured otherwise is factually incorrect; instances are isolated by design from the outset. Reference topics: Junos Enterprise Routing – Protocol Independent Routing, Routing Instance Types and Table Allocation.