By default, EBGP sessions are built with the expectation that peers are directly connected at Layer 3, and Junos enforces this by sending EBGP packets with a TTL of 1. When loopback addresses are used as the session endpoints instead of the directly connected physical interface addresses, the resulting IP packets must traverse at least one additional router hop between the two loopbacks, and a TTL of 1 will expire in transit before reaching the remote loopback, causing the TCP handshake -- and therefore the BGP session -- to fail even though a valid route to the peer's loopback exists. The multihop statement (configured as an EBGP multihop parameter with an accompanying TTL value, most commonly set to 2 for a single intermediate hop) instructs Junos to increase the TTL used for that peer's BGP packets so they survive the extra hop count between loopbacks. This is a mandatory addition any time an EBGP session is deliberately built against non-directly-connected addresses, whereas IBGP sessions, by contrast, do not have this default restriction because IBGP already assumes peers may be multiple hops apart within the same AS. Multipath affects load-balancing across equal-cost paths, damping suppresses flapping routes, and passive controls whether a router waits for the remote peer to initiate the TCP connection -- none of these resolve the TTL expiration problem inherent to loopback-based EBGP peering.

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 show ethernet-switching table command displays the Layer 2 forwarding database (the bridge or MAC table) that an EX Series switch builds dynamically by inspecting the source MAC address of every frame it receives. Each entry records the learned MAC address, the VLAN it was learned on, the type of entry (dynamic, static, or persistent), and the specific interface through which that address was seen, which is precisely the information needed to confirm whether the switch has learned the host connected to ge-0/0/3. If the host's MAC address is absent from the table, that immediately points to a Layer 1/2 issue -- no frames have been received from the host, a cabling or port problem exists, or the interface is administratively down or blocked by spanning tree -- rather than a Layer 3 routing or VLAN membership problem. show interfaces terse only reports administrative and link state along with any assigned protocol family addresses, offering no MAC-learning visibility. show vlans lists VLAN definitions and their member interfaces but does not display learned host addresses. show interfaces extensive provides detailed physical-layer counters and error statistics, useful for diagnosing frame loss or interface errors, but it does not expose the switching table. For intra-VLAN reachability troubleshooting, verifying MAC learning is always the first and most direct Layer 2 checkpoint.

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.