JN0-281 Exam Dumps : Data Center Associate (JNCIA-DC)

EBGP is the BGP session type formed between different autonomous systems. In Juniper data center IP fabrics, EBGP is frequently used for the underlay because it can provide all required reachability without an additional interior gateway protocol. The fabric can advertise loopbacks and point-to-point link subnets directly in BGP, then use ECMP to install multiple equal-cost next hops. This is why EBGP sessions do not require an IGP as a fundamental dependency. Some designs still add an IGP for other reasons, but EBGP itself can carry the underlay routes needed for full fabric connectivity.

EBGP sessions are also typically established between directly connected peers. In a standard leaf-spine underlay, each leaf peers with each spine over the routed physical links between them, using the interface IP addresses on those point-to-point subnets. This matches EBGP default behavior, including a one-hop TTL expectation and straightforward operational troubleshooting.

Loopback peering is not required for EBGP. It is possible, but it usually needs additional configuration such as multihop and a routing method to ensure reachability to the remote loopback before the BGP session can form. EBGP also supports sessions with non-directly connected peers when multihop is configured, so it is incorrect to claim EBGP does not support that capability.

Nonstop bridging is a high availability capability focused on maintaining Layer 2 switching continuity during a Routing Engine switchover on platforms that support redundant control planes. The intent is to keep Layer 2 forwarding operational and minimize disruption to bridged traffic when the system transitions from a primary to a backup Routing Engine. Achieving this requires Graceful Routing Engine switchover, because GRES is the mechanism that enables a control plane switchover while keeping forwarding and interface state stable. With GRES in place, the forwarding plane can continue switching frames while the backup Routing Engine assumes control, reducing or eliminating traffic loss for Layer 2 domains.

Nonstop bridging is not the feature that preserves Layer 3 protocol sessions and routing information end-to-end. That function is associated with nonstop routing capabilities, which focus on maintaining routing protocol state across Routing Engine events. Therefore, stating that nonstop bridging preserves Layer 3 information and protocol sessions is incorrect. Likewise, nonstop active routing is not a requirement for nonstop bridging; it is a separate feature aimed at routing stability. The flow-control setting under gigether-options is unrelated to Routing Engine redundancy and does not determine whether nonstop bridging operates.

In data center access and aggregation environments where VLANs must remain stable for servers and appliances, nonstop bridging paired with GRES helps protect Layer 2 service continuity during control plane events.

In BGP (Border Gateway Protocol), when evaluating multiple routes to the same destination, the first attribute that is considered is the local preference value. The local preference is a BGP attribute used to influence outbound routing decisions within an Autonomous System (AS).

Step-by-Step Breakdown:

Local Preference:The local preference attribute is used to determine which path is preferred for traffic leaving the AS. The higher the local preference value, the more preferred the route.

BGP Path Selection:The BGP path selection process evaluates the following attributes in this order:

Local Preference (higher is preferred)

AS Path (shorter is preferred)

Origin (IGP > EGP > incomplete)

MED (Multi-Exit Discriminator) (lower is preferred)

Juniper Reference:

BGP Path Selection: In Junos, the local preference attribute is the first to be evaluated when determining the best path for outbound traffic.