Practice Free JN0-281 Exam Online Questions
Question #1
Which statement is correct about building an IP fabric?
- A . Each leaf device should have a direct physical connection to every other leaf device.
- B . Each leaf device must have two or more physical connections to each spine device.
- C . Each leaf device should have a direct physical connection to every spine device.
- D . Each leaf device must have two or more physical connections to each connected server.
Correct Answer: C
C
Explanation:
A modern IP fabric in a leaf spine topology is built to deliver predictable latency, high bandwidth, and horizontal scale. The defining characteristic is that every leaf switch connects upstream to every spine switch. This full mesh between leaf and spine layers creates multiple equal cost paths between any two endpoints connected anywhere in the fabric. With this design, east west traffic between servers attached to different leaves can traverse the fabric using one spine hop, keeping path length consistent and enabling efficient load sharing across links.
Leaf to leaf direct connections are not used in a standard leaf spine IP fabric because they create irregular topologies, complicate troubleshooting, and undermine the uniform multi path behavior that makes fabrics scalable. Similarly, a leaf does not inherently require two or more physical connections to each spine. Many designs start with a single link per leaf spine pair and increase capacity by adding additional parallel links as needed. Redundancy is achieved by having multiple spines and multiple equal cost paths, not by mandating multiple links to every spine from day one.
Server connectivity requirements also vary. Some servers use single uplinks, others use dual homing for redundancy. That decision is independent of the fundamental requirement that each leaf should connect to every spine.
C
Explanation:
A modern IP fabric in a leaf spine topology is built to deliver predictable latency, high bandwidth, and horizontal scale. The defining characteristic is that every leaf switch connects upstream to every spine switch. This full mesh between leaf and spine layers creates multiple equal cost paths between any two endpoints connected anywhere in the fabric. With this design, east west traffic between servers attached to different leaves can traverse the fabric using one spine hop, keeping path length consistent and enabling efficient load sharing across links.
Leaf to leaf direct connections are not used in a standard leaf spine IP fabric because they create irregular topologies, complicate troubleshooting, and undermine the uniform multi path behavior that makes fabrics scalable. Similarly, a leaf does not inherently require two or more physical connections to each spine. Many designs start with a single link per leaf spine pair and increase capacity by adding additional parallel links as needed. Redundancy is achieved by having multiple spines and multiple equal cost paths, not by mandating multiple links to every spine from day one.
Server connectivity requirements also vary. Some servers use single uplinks, others use dual homing for redundancy. That decision is independent of the fundamental requirement that each leaf should connect to every spine.
Question #2
You are troubleshooting BGP routing and want to verify that you are sending a default route to peer address 10.100.25.6.
Which command would satisfy the requirement?
- A . show route protocol bgp 0.0.0.0
- B . show route receive-protocol bgp 10.100.25.6 0.0.0.0
- C . show route protocol static 0.0.0.0
- D . show route advertising-protocol bgp 10.100.25.6 0.0.0.0
Correct Answer: D
D
Explanation:
To confirm that your router is sending a specific route to a particular BGP neighbor, you must inspect the outbound advertisements toward that neighbor. In Junos, the command that shows routes being advertised to a peer is show route advertising-protocol bgp with the neighbor address specified.
Adding 0.0.0.0 to the command filters the output to the default route, making it the most direct way to validate that the default route is actually being exported to peer 10.100.25.6. This is especially important in data center deployments where default route advertisement is often controlled by policy, conditional origination, or specific export terms, and where you want to verify the real operational result rather than just configuration intent.
The receive-protocol variant shows what you are learning from that neighbor, not what you are sending to it. The show route protocol bgp 0.0.0.0 command only confirms that the default route exists in your local routing table as a BGP-learned route, which does not prove it is being exported to the neighbor. The show route protocol static 0.0.0.0 command would confirm the presence of a static default route locally, but again it does not confirm that it is being advertised over BGP. Therefore, the outbound advertisement command is the correct verification method.
D
Explanation:
To confirm that your router is sending a specific route to a particular BGP neighbor, you must inspect the outbound advertisements toward that neighbor. In Junos, the command that shows routes being advertised to a peer is show route advertising-protocol bgp with the neighbor address specified.
Adding 0.0.0.0 to the command filters the output to the default route, making it the most direct way to validate that the default route is actually being exported to peer 10.100.25.6. This is especially important in data center deployments where default route advertisement is often controlled by policy, conditional origination, or specific export terms, and where you want to verify the real operational result rather than just configuration intent.
The receive-protocol variant shows what you are learning from that neighbor, not what you are sending to it. The show route protocol bgp 0.0.0.0 command only confirms that the default route exists in your local routing table as a BGP-learned route, which does not prove it is being exported to the neighbor. The show route protocol static 0.0.0.0 command would confirm the presence of a static default route locally, but again it does not confirm that it is being advertised over BGP. Therefore, the outbound advertisement command is the correct verification method.
Question #3
You are asked to ensure that traffic and routing information is not interrupted if your primary Routing Engine fails or switches to the backup Routing Engine.
In this scenario, which high availability feature will accomplish this behavior?
- A . nonstop active routing NSR
- B . graceful Routing Engine switchover GRES
- C . link aggregation control protocol LACP
- D . bidirectional forwarding detection BFD
Correct Answer: A
A
Explanation:
Nonstop active routing is the Junos high availability feature designed to keep routing protocol operation and routing information continuous across a Routing Engine switchover on platforms with redundant Routing Engines. With NSR enabled, the control-plane routing state is replicated so that protocol sessions and routing information can remain stable when the device transitions from the primary to the backup Routing Engine. The goal is a transparent switchover that minimizes or eliminates routing reconvergence caused by a Routing Engine failure.
This is especially important in data center environments where routing stability underpins EVPN VXLAN control-plane operation, underlay BGP or OSPF adjacencies, and service reachability. By maintaining the routing protocol process state across the switchover, NSR helps prevent neighbor resets and reduces churn in the routing table, which directly protects application traffic paths from
disruption that would otherwise occur during a control-plane restart.
GRES is closely related but has a different focus: it preserves forwarding and certain kernel and interface states so that packet forwarding can continue, but by itself it does not preserve the full routing protocol control plane. That is why NSR is the best match when the requirement explicitly includes routing information continuity in addition to traffic continuity. LACP and BFD are valuable availability tools, but they address link bundling and fast failure detection, not Routing Engine stateful failover.
A
Explanation:
Nonstop active routing is the Junos high availability feature designed to keep routing protocol operation and routing information continuous across a Routing Engine switchover on platforms with redundant Routing Engines. With NSR enabled, the control-plane routing state is replicated so that protocol sessions and routing information can remain stable when the device transitions from the primary to the backup Routing Engine. The goal is a transparent switchover that minimizes or eliminates routing reconvergence caused by a Routing Engine failure.
This is especially important in data center environments where routing stability underpins EVPN VXLAN control-plane operation, underlay BGP or OSPF adjacencies, and service reachability. By maintaining the routing protocol process state across the switchover, NSR helps prevent neighbor resets and reduces churn in the routing table, which directly protects application traffic paths from
disruption that would otherwise occur during a control-plane restart.
GRES is closely related but has a different focus: it preserves forwarding and certain kernel and interface states so that packet forwarding can continue, but by itself it does not preserve the full routing protocol control plane. That is why NSR is the best match when the requirement explicitly includes routing information continuity in addition to traffic continuity. LACP and BFD are valuable availability tools, but they address link bundling and fast failure detection, not Routing Engine stateful failover.
Question #4
When evaluating BGP routes, what will be evaluated first?
- A . The local preference value
- B . The AS path
- C . The MED value
- D . The origin value
Correct Answer: A
A
Explanation:
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.
A
Explanation:
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.
Question #5
What are two characteristics of EBGP? Choose two.
- A . EBGP sessions do not require an IGP.
- B . EBGP sessions require loopback IP address peering.
- C . EBGP does not support sessions with non-directly connected peers.
- D . EBGP sessions are typically established between directly connected peers.
Correct Answer: A, D
A, D
Explanation:
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.
A, D
Explanation:
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.
Question #6
What are two BGP message types? Choose two.
- A . open
- B . hello
- C . update
- D . LSA
Correct Answer: A, C
A, C
Explanation:
BGP uses a small set of well-defined message types to form and maintain peerings and to exchange routing information. The Open message is used during session establishment after the TCP connection is up. It communicates the parameters required to form the BGP session, such as the BGP version, the autonomous system number, the negotiated hold time, the BGP identifier, and optional capabilities. Capabilities are especially important in data center designs because they enable features such as 4 byte ASNs, route refresh, and EVPN signaling when applicable.
The Update message is the core mechanism BGP uses to advertise reachability and to withdraw routes that are no longer valid. In a data center underlay using EBGP, Update messages carry the prefixes that represent loopbacks and point-to-point links, enabling leaf and spine reachability. In an EVPN control plane, Update messages carry EVPN Network Layer Reachability Information to distribute MAC and IP reachability and multihoming information across the fabric.
Hello is not a BGP message type. Hello is commonly associated with protocols like OSPF, IS-IS, and some discovery mechanisms. LSA is not a BGP message type either; Link State Advertisements are
specific to OSPF.
A, C
Explanation:
BGP uses a small set of well-defined message types to form and maintain peerings and to exchange routing information. The Open message is used during session establishment after the TCP connection is up. It communicates the parameters required to form the BGP session, such as the BGP version, the autonomous system number, the negotiated hold time, the BGP identifier, and optional capabilities. Capabilities are especially important in data center designs because they enable features such as 4 byte ASNs, route refresh, and EVPN signaling when applicable.
The Update message is the core mechanism BGP uses to advertise reachability and to withdraw routes that are no longer valid. In a data center underlay using EBGP, Update messages carry the prefixes that represent loopbacks and point-to-point links, enabling leaf and spine reachability. In an EVPN control plane, Update messages carry EVPN Network Layer Reachability Information to distribute MAC and IP reachability and multihoming information across the fabric.
Hello is not a BGP message type. Hello is commonly associated with protocols like OSPF, IS-IS, and some discovery mechanisms. LSA is not a BGP message type either; Link State Advertisements are
specific to OSPF.
Question #6
What are two BGP message types? Choose two.
- A . open
- B . hello
- C . update
- D . LSA
Correct Answer: A, C
A, C
Explanation:
BGP uses a small set of well-defined message types to form and maintain peerings and to exchange routing information. The Open message is used during session establishment after the TCP connection is up. It communicates the parameters required to form the BGP session, such as the BGP version, the autonomous system number, the negotiated hold time, the BGP identifier, and optional capabilities. Capabilities are especially important in data center designs because they enable features such as 4 byte ASNs, route refresh, and EVPN signaling when applicable.
The Update message is the core mechanism BGP uses to advertise reachability and to withdraw routes that are no longer valid. In a data center underlay using EBGP, Update messages carry the prefixes that represent loopbacks and point-to-point links, enabling leaf and spine reachability. In an EVPN control plane, Update messages carry EVPN Network Layer Reachability Information to distribute MAC and IP reachability and multihoming information across the fabric.
Hello is not a BGP message type. Hello is commonly associated with protocols like OSPF, IS-IS, and some discovery mechanisms. LSA is not a BGP message type either; Link State Advertisements are
specific to OSPF.
A, C
Explanation:
BGP uses a small set of well-defined message types to form and maintain peerings and to exchange routing information. The Open message is used during session establishment after the TCP connection is up. It communicates the parameters required to form the BGP session, such as the BGP version, the autonomous system number, the negotiated hold time, the BGP identifier, and optional capabilities. Capabilities are especially important in data center designs because they enable features such as 4 byte ASNs, route refresh, and EVPN signaling when applicable.
The Update message is the core mechanism BGP uses to advertise reachability and to withdraw routes that are no longer valid. In a data center underlay using EBGP, Update messages carry the prefixes that represent loopbacks and point-to-point links, enabling leaf and spine reachability. In an EVPN control plane, Update messages carry EVPN Network Layer Reachability Information to distribute MAC and IP reachability and multihoming information across the fabric.
Hello is not a BGP message type. Hello is commonly associated with protocols like OSPF, IS-IS, and some discovery mechanisms. LSA is not a BGP message type either; Link State Advertisements are
specific to OSPF.
Question #8
Referring to the exhibit, which type of protocol session will be established?
- A . OSPF
- B . IS-IS
- C . EBGP
- D . IBGP
Correct Answer: D
D
Explanation:
The configuration shown is under protocols bgp and defines a BGP group named service-pod with the statement type internal. In Junos, the BGP group type determines whether the sessions formed by neighbors in that group are treated as internal BGP or external BGP. When the group is set to type internal, the router establishes an iBGP session to the configured neighbor address. That means both peers are expected to be in the same autonomous system, and the session is used to exchange routes within that single AS.
The local-address statement sets the source address that the router will use when initiating the TCP connection for BGP. In data center designs, this is commonly a loopback address so the session can be resilient and independent of any single physical interface. The neighbor statement identifies the remote peer address. With type internal, the session is iBGP even if the neighbor is directly connected, because the relationship is defined by AS scope rather than topology.
OSPF and IS-IS are different routing protocols entirely and are not established through BGP configuration. EBGP would require type external and typically involves different AS numbers across the peering. Therefore, the only correct answer is IBGP.
D
Explanation:
The configuration shown is under protocols bgp and defines a BGP group named service-pod with the statement type internal. In Junos, the BGP group type determines whether the sessions formed by neighbors in that group are treated as internal BGP or external BGP. When the group is set to type internal, the router establishes an iBGP session to the configured neighbor address. That means both peers are expected to be in the same autonomous system, and the session is used to exchange routes within that single AS.
The local-address statement sets the source address that the router will use when initiating the TCP connection for BGP. In data center designs, this is commonly a loopback address so the session can be resilient and independent of any single physical interface. The neighbor statement identifies the remote peer address. With type internal, the session is iBGP even if the neighbor is directly connected, because the relationship is defined by AS scope rather than topology.
OSPF and IS-IS are different routing protocols entirely and are not established through BGP configuration. EBGP would require type external and typically involves different AS numbers across the peering. Therefore, the only correct answer is IBGP.
Question #9
You have configured a static route to be used for management traffic. You want to ensure that this route is not propagated to other routers.
In this scenario, which parameter would you add to this route configuration?
- A . reject
- B . preference 255
- C . no-readvertise
- D . discard
Correct Answer: C
C
Explanation:
In Junos, static routes are eligible to be exported into dynamic routing protocols if you configure an export policy that matches them. For management-only routes, especially default routes or specific management subnets used for out-of-band access, you often want to ensure they never leak into the production routing domain. The no-readvertise parameter is designed for this purpose. When you mark a static route as no-readvertise, Junos flags it so other routing protocols do not export or readvertise it, even if an export policy would otherwise match it. This helps keep the management plane isolated from the data plane and prevents accidental propagation of management reachability into the fabric underlay or overlay.
The reject and discard options control how packets are handled if they match the route, not whether the route is eligible to be exported. Preference 255 changes the route’s selection priority relative to other routes, but it does not prevent export. Therefore, no-readvertise is the correct configuration knob when the explicit goal is to prevent propagation of a management static route to other routers.
C
Explanation:
In Junos, static routes are eligible to be exported into dynamic routing protocols if you configure an export policy that matches them. For management-only routes, especially default routes or specific management subnets used for out-of-band access, you often want to ensure they never leak into the production routing domain. The no-readvertise parameter is designed for this purpose. When you mark a static route as no-readvertise, Junos flags it so other routing protocols do not export or readvertise it, even if an export policy would otherwise match it. This helps keep the management plane isolated from the data plane and prevents accidental propagation of management reachability into the fabric underlay or overlay.
The reject and discard options control how packets are handled if they match the route, not whether the route is eligible to be exported. Preference 255 changes the route’s selection priority relative to other routes, but it does not prevent export. Therefore, no-readvertise is the correct configuration knob when the explicit goal is to prevent propagation of a management static route to other routers.
Question #10
Exhibit:
Referring to the exhibit, what is the route preference of the 172.25.11.254 next hop?
- A . 5
- B . 10
- C . 130
- D . 140
Correct Answer: A
A
Explanation:
In the exhibit, we see two next-hop addresses for the default static route (0.0.0.0/0):
The first next hop is 172.25.11.254, with no specified preference.
The second next hop is 172.25.11.200, with a specified preference of 140.
Step-by-Step Breakdown:
Default Static Route Preference:
If no preference is explicitly set for a next hop in Junos, it defaults to 5 for static routes.
Determining Preference:
In this case, the next hop 172.25.11.254 does not have an explicit preference defined, so it will use the default value of 5. The second next hop has a preference of 140, which is higher, meaning it will only be used if the primary next hop is unavailable.
Juniper
Reference: Static Route Preference: In Junos, the default preference for static routes is 5, and this value is applied unless overridden by the preference parameter.
A
Explanation:
In the exhibit, we see two next-hop addresses for the default static route (0.0.0.0/0):
The first next hop is 172.25.11.254, with no specified preference.
The second next hop is 172.25.11.200, with a specified preference of 140.
Step-by-Step Breakdown:
Default Static Route Preference:
If no preference is explicitly set for a next hop in Junos, it defaults to 5 for static routes.
Determining Preference:
In this case, the next hop 172.25.11.254 does not have an explicit preference defined, so it will use the default value of 5. The second next hop has a preference of 140, which is higher, meaning it will only be used if the primary next hop is unavailable.
Juniper
Reference: Static Route Preference: In Junos, the default preference for static routes is 5, and this value is applied unless overridden by the preference parameter.