BGP Advanced practice questions

An administrator configures a BGP routing policy to match routes with community members using regex matching in Junos. Which statement accurately describes how Junos represents standard BGP communities in policy matching?

Trap 1: Community matching in Junos requires explicit activation under the…

Community matching is an inherent feature of policy-options and requires no special forwarding-options configuration.

Trap 2: Communities must be converted to extended communities before any…

Standard communities can be matched directly using regular expressions against community strings.

Trap 3: Communities are matched exclusively using hexadecimal bitmasks in…

Junos uses decimal or community names, not raw hexadecimal bitmasks for community matching.

A
Communities are defined within policy-options using community members specified in AS:number format and matched via community-list.
Standard BGP communities are configured under policy-options as community members in AS:number format, then referenced by a community-list in a policy term. This matches the stem's regex-matching scenario, since the community-list is the object evaluated against received route communities.
B
Community matching in Junos requires explicit activation under the forwarding-options hierarchy.
Why it fails: Community matching is an inherent feature of policy-options and requires no special forwarding-options configuration.
C
Communities must be converted to extended communities before any regular expression can be applied.
Why it fails: Standard communities can be matched directly using regular expressions against community strings.
D
Communities are matched exclusively using hexadecimal bitmasks in policy match conditions.
Why it fails: Junos uses decimal or community names, not raw hexadecimal bitmasks for community matching.

Question 2easymultiple choice

Which command should an engineer use on a Junos device to verify whether a BGP next hop is successfully resolved via the routing table?

Trap 1: show bgp neighbor detail

While neighbor detail shows some session info, it does not provide a comprehensive list of next-hop resolution statuses.

Trap 2: show route forwarding-table destination

This command shows forwarding table entries rather than BGP protocol next-hop reachability details.

Trap 3: show bgp summary

show bgp summary provides session states and prefix counts, not next-hop resolution status.

A
show route protocol bgp next-hop
This command is specifically designed to inspect BGP next-hop resolution state in Junos.
B
show bgp neighbor detail
Why it fails: While neighbor detail shows some session info, it does not provide a comprehensive list of next-hop resolution statuses.
C
show route forwarding-table destination
Why it fails: This command shows forwarding table entries rather than BGP protocol next-hop reachability details.
D
show bgp summary
Why it fails: show bgp summary provides session states and prefix counts, not next-hop resolution status.

Question 3easymultiple choice

An administrator is reviewing the BGP route selection process on a Junos device and notices that two paths have identical weights, local preferences, AS path lengths, origins, and MEDs. Which tie-breaking criterion does Junos evaluate next in the BGP route selection algorithm?

Trap 1: Preference for the lowest IGP metric to the BGP next hop

IGP metric is evaluated after the router ID comparison in Junos BGP route selection.

Trap 2: Preference for the oldest route

Route age is not part of the standard Junos BGP deterministic best-path selection algorithm.

Trap 3: Preference for the lowest router ID

Router ID is evaluated later in the BGP selection process after IBGP vs EBGP comparison.

A
Preference for internal (IBGP) paths over external (EBGP) paths
Junos prefers IBGP paths over EBGP paths during the standard BGP route selection tie-breaking steps when earlier attributes are equal.
B
Preference for the lowest IGP metric to the BGP next hop
Why it fails: IGP metric is evaluated after the router ID comparison in Junos BGP route selection.
C
Preference for the oldest route
Why it fails: Route age is not part of the standard Junos BGP deterministic best-path selection algorithm.
D
Preference for the lowest router ID
Why it fails: Router ID is evaluated later in the BGP selection process after IBGP vs EBGP comparison.

Question 4mediummultiple choice

An enterprise network uses BGP communities to tag routes at regional branch offices. Headquarters needs to strip these specific communities from routes before advertising them to external transit providers. Which Junos routing policy action accomplishes this?

Trap 1: community set target_community

Setting a community overwrites or assigns communities rather than deleting them.

Trap 2: as-path-remove target_community

AS path manipulation commands do not affect BGP community attributes.

Trap 3: metric set 0

Setting the metric (MED) modifies the MED attribute, not communities.

A
community delete target_community
The 'community delete' action removes the matched community string from the route.
B
community set target_community
Why it fails: Setting a community overwrites or assigns communities rather than deleting them.
C
as-path-remove target_community
Why it fails: AS path manipulation commands do not affect BGP community attributes.
D
metric set 0
Why it fails: Setting the metric (MED) modifies the MED attribute, not communities.

Question 5easymultiple choice

An administrator wants to disable the default behavior where BGP advertises all active routing table paths to peers. Which configuration statement restricts BGP to only advertise the active best path?

Trap 1: Enable route dampening on all EBGP peers.

Route dampening handles unstable flapping routes.

Trap 2: Set the BGP advertisement-interval to zero.

Advertisement-interval controls the minimum time between sending BGP updates.

Trap 3: Disable routing-options bgp multipath globally.

Multipath is disabled by default.

A
Enable route dampening on all EBGP peers.
Why it fails: Route dampening handles unstable flapping routes.
B
Configure an export policy that filters out non-active paths.
BGP default behavior is to advertise only active paths, but export policies explicitly control what is sent.
C
Set the BGP advertisement-interval to zero.
Why it fails: Advertisement-interval controls the minimum time between sending BGP updates.
D
Disable routing-options bgp multipath globally.
Why it fails: Multipath is disabled by default.

Question 6hardmultiple choice

A network engineer is configuring a Junos routing device to use BGP Prefix-Independent Convergence (PIC) edge for faster failover. What is the fundamental mechanism that enables BGP PIC to achieve sub-second convergence upon primary path failure?

Trap 1: It bypasses the routing table entirely and queries the BGP route…

Querying a reflector during failure would introduce unacceptable latency.

Trap 2: It forces the IGP to recalculate shortest paths immediately using…

PIC specifically targets BGP convergence independence from the IGP scale.

Trap 3: It increases the BGP keepalive and hold timers to prevent session…

Timers affect session state, not fast convergence of forwarding paths.

A
It bypasses the routing table entirely and queries the BGP route reflector directly upon failure.
Why it fails: Querying a reflector during failure would introduce unacceptable latency.
B
It pre-installs a backup loop-free alternate (LFA) next hop in the forwarding plane for rapid hardware switching.
BGP PIC pre-computes and installs a backup loop-free alternate next hop in the forwarding plane alongside the primary. On primary path failure, hardware switches to that pre-installed next hop without waiting for control-plane reconvergence, delivering sub-second failover.
C
It forces the IGP to recalculate shortest paths immediately using fast-reroute without BGP participation.
Why it fails: PIC specifically targets BGP convergence independence from the IGP scale.
D
It increases the BGP keepalive and hold timers to prevent session tearing during link flaps.
Why it fails: Timers affect session state, not fast convergence of forwarding paths.

Question 7hardmultiple choice

A BGP routing policy on a Junos router uses an 'as-path' regular expression '^[0-9]+$' in a match condition. Which routes will this regular expression match?

Trap 1: Routes that contain internal confederation segments.

Confederation segments appear in AS paths enclosed in parentheses, which the [0-9]+ token cannot match. The expression would be correct for identifying confederation routes if it included the confederation-specific pattern, for example matching parenthesised AS numbers.

Trap 2: Routes whose AS path starts with local AS 65000 and has multiple…

The expression anchors both ends and matches a single numeric AS number, so it cannot match a path beginning with 65000 followed by further hops. It would be correct if the policy needed to match routes originated by the local autonomous system only.

Trap 3: Any route originating from any AS path of any length.

The anchors and single [0-9]+ token restrict the match to an AS path containing exactly one AS number, so paths of any length are excluded. It would be correct if the expression were written without anchors, such as .*[0-9]+.*, to match numbers anywhere.

A
Routes that contain internal confederation segments.
Why it fails: Confederation segments appear in AS paths enclosed in parentheses, which the [0-9]+ token cannot match. The expression would be correct for identifying confederation routes if it included the confederation-specific pattern, for example matching parenthesised AS numbers.
B
Routes whose AS path contains exactly one AS number ( originated from a directly connected neighboring AS ).
The regex anchors both ends, so it matches an AS path containing exactly one AS number and nothing else. Routes learned from a directly connected neighbouring AS carry a single-element path, satisfying that constraint. Paths with two or more AS numbers, or empty paths, fail the match.
C
Routes whose AS path starts with local AS 65000 and has multiple hops.
Why it fails: The expression anchors both ends and matches a single numeric AS number, so it cannot match a path beginning with 65000 followed by further hops. It would be correct if the policy needed to match routes originated by the local autonomous system only.
D
Any route originating from any AS path of any length.
Why it fails: The anchors and single [0-9]+ token restrict the match to an AS path containing exactly one AS number, so paths of any length are excluded. It would be correct if the expression were written without anchors, such as .*[0-9]+.*, to match numbers anywhere.

Question 8mediummulti select

Which THREE conditions must be met for a Junos routing device to consider two BGP paths as valid candidates for multipath load balancing when standard multipath is configured? (Choose three)

Trap 1: The router IDs of the advertising peers must be identical.

Multipath requires equal AS path length, matching MED and identical IGP cost to the next hop; router IDs must differ, since identical IDs indicate the same peer and would not yield distinct valid paths. Identical router IDs are tempting as a symmetry condition, but they signal duplicate peers, not parallel paths.

Trap 2: The route advertisement intervals must be synchronized across all…

BGP multipath requires matching path attributes — weight, local preference, AS path, origin, MED and IGP metric — not synchronised advertisement timers. Peers advertise independently, and Junos evaluates each path on arrival. Interval synchronisation is tempting because it sounds like consistency, but it is used for convergence tuning, not candidate validation.

A
The next hops must be resolvable via active routing table entries.
Multipath selection requires each candidate next hop to resolve through an active route in the routing table, ensuring forwarding entries exist for every path. Unresolvable next hops are excluded before load-balancing consideration, so this condition must hold for a path to qualify as a valid multipath candidate.
B
The paths must have identical local preference values.
Identical local preference ensures both paths share the same preference ranking, a prerequisite for multipath eligibility under standard BGP. Junos only considers paths of equal preference for load balancing, so differing local preference values would make one path preferred and exclude the other from the multipath set.
C
The router IDs of the advertising peers must be identical.
Why it fails: Multipath requires equal AS path length, matching MED and identical IGP cost to the next hop; router IDs must differ, since identical IDs indicate the same peer and would not yield distinct valid paths. Identical router IDs are tempting as a symmetry condition, but they signal duplicate peers, not parallel paths.
D
The AS path lengths must be identical.
Identical AS path lengths satisfy the BGP multipath tie-breaking requirement: routes must share the same AS path length before Junos treats them as equal-cost candidates. Without this match, the shorter path wins outright and no load balancing occurs, so this condition directly enables standard multipath selection.
E
The route advertisement intervals must be synchronized across all peers.
Why it fails: BGP multipath requires matching path attributes — weight, local preference, AS path, origin, MED and IGP metric — not synchronised advertisement timers. Peers advertise independently, and Junos evaluates each path on arrival. Interval synchronisation is tempting because it sounds like consistency, but it is used for convergence tuning, not candidate validation.

Question 9hardmulti select

An administrator is troubleshooting BGP route reflector operations in a Junos environment. Which TWO statements regarding route reflection behavior and loop prevention are correct? (Choose two)

Trap 1: Route reflectors change the BGP next hop to their own IP address…

By default, IBGP next hops are preserved unless explicitly changed using 'next-hop-self'.

Trap 2: Route reflectors remove the AS_PATH attribute when reflecting…

AS_PATH is never removed when reflecting IBGP routes.

Trap 3: Route reflectors modify the Local Preference attribute to zero for…

Local Preference is preserved during route reflection.

A
Route reflectors change the BGP next hop to their own IP address when reflecting routes to clients by default.
Why it fails: By default, IBGP next hops are preserved unless explicitly changed using 'next-hop-self'.
B
A route reflector ignores any advertised route that contains its own local Cluster ID in the Cluster List.
Cluster Lists prevent routing loops between clustered route reflectors by rejecting paths containing the local cluster ID.
C
The Originator ID is a 4-byte value created by the route reflector to identify the client that injected the route.
Originator ID is added by the RR to reflect the router ID of the route originator.
D
Route reflectors remove the AS_PATH attribute when reflecting routes to internal non-client peers.
Why it fails: AS_PATH is never removed when reflecting IBGP routes.
E
Route reflectors modify the Local Preference attribute to zero for all reflected routes.
Why it fails: Local Preference is preserved during route reflection.

Question 10easymulti select

Which TWO attributes are considered transitive BGP path attributes? (Choose two)

Trap 1: MED (Multi-Exit Discriminator)

MED is an optional non-transitive attribute by default.

Trap 2: ORIGINATOR_ID

ORIGINATOR_ID is a non-transitive attribute used within route reflection topologies.

Trap 3: LOCAL_PREF

LOCAL_PREF is restricted to the local autonomous system and is non-transitive to EBGP peers.

A
MED (Multi-Exit Discriminator)
Why it fails: MED is an optional non-transitive attribute by default.
B
ORIGINATOR_ID
Why it fails: ORIGINATOR_ID is a non-transitive attribute used within route reflection topologies.
C
LOCAL_PREF
Why it fails: LOCAL_PREF is restricted to the local autonomous system and is non-transitive to EBGP peers.
D
COMMUNITY
COMMUNITY is an optional transitive attribute.
E
AS_PATH
AS_PATH is a well-known mandatory transitive attribute.

Question 11easymulti select

Which TWO well-known BGP communities are recognized universally to control route propagation? (Choose two)

Trap 1: local-only

local-only is not a well-known BGP community; the recognised set is NO_EXPORT, NO_ADVERTISE, LOCAL_AS and INTERNET, each with reserved values. It is tempting because its name suggests confining a route to the local AS, which NO_EXPORT actually achieves, so it would be the right label in a vendor-specific implementation.

Trap 2: transit-only

transit-only is not a universally recognised well-known community; only NO_EXPORT, NO_ADVERTISE, LOCAL_AS and INTERNET carry reserved, globally understood values. It is tempting because it sounds like a propagation-control tag, and a provider-defined community restricting a prefix to transit customers would be the correct mechanism in that network.

Trap 3: no-peer

no-peer is a Cisco-specific community, not one of the four universally recognised well-known communities (NO_EXPORT, NO_ADVERTISE, LOCAL_AS, INTERNET). It is tempting because it genuinely restricts route propagation between peers, and within an all-Cisco autonomous system it would correctly limit advertisement to peer routers.

A
no-export
The `no-export` community (0xFFFFFF01) prevents a route from being advertised beyond the local autonomous system, satisfying the requirement to control propagation at AS boundaries. It is a well-known community recognised by all BGP implementations, unlike extended or link-bandwidth communities, which are not universally honoured.
B
local-only
Why it fails: local-only is not a well-known BGP community; the recognised set is NO_EXPORT, NO_ADVERTISE, LOCAL_AS and INTERNET, each with reserved values. It is tempting because its name suggests confining a route to the local AS, which NO_EXPORT actually achieves, so it would be the right label in a vendor-specific implementation.
C
transit-only
Why it fails: transit-only is not a universally recognised well-known community; only NO_EXPORT, NO_ADVERTISE, LOCAL_AS and INTERNET carry reserved, globally understood values. It is tempting because it sounds like a propagation-control tag, and a provider-defined community restricting a prefix to transit customers would be the correct mechanism in that network.
D
no-peer
Why it fails: no-peer is a Cisco-specific community, not one of the four universally recognised well-known communities (NO_EXPORT, NO_ADVERTISE, LOCAL_AS, INTERNET). It is tempting because it genuinely restricts route propagation between peers, and within an all-Cisco autonomous system it would correctly limit advertisement to peer routers.
E
no-advertise
The no-advertise community prevents a router from advertising the tagged route to any BGP peer, including iBGP and eBGP neighbours. This satisfies the stem's requirement for a universally recognised community controlling route propagation, since the well-known value is honoured across vendor implementations without additional configuration.

Question 12mediummulti select

Which THREE methods can be used on Junos devices to influence inbound BGP traffic selection from external ASNs? (Choose three)

Trap 1: Adjusting the local preference attribute on incoming EBGP updates.

Local preference is an IBGP attribute and is ignored or overwritten on incoming EBGP updates by default.

Trap 2: Changing the local router's weight attribute for incoming EBGP…

Weight is strictly local to the router and has no impact on external peers' decisions.

A
Adjusting the local preference attribute on incoming EBGP updates.
Why it fails: Local preference is an IBGP attribute and is ignored or overwritten on incoming EBGP updates by default.
B
AS path prepending outbound to external peers.
Prepending lengthens the AS path, making the path less desirable to external peers.
C
Utilizing provider-supported BGP communities to influence upstream routing policies.
Many ISPs support specific communities to alter local preference or prepending upstream.
D
Changing the local router's weight attribute for incoming EBGP routes.
Why it fails: Weight is strictly local to the router and has no impact on external peers' decisions.
E
Sending specific MED values to external peers.
MED can influence upstream autonomous systems in choosing an entry point.

Question 13easymulti select

Which TWO statements describe characteristics of BGP route reflectors? (Choose two)

Trap 1: They rewrite the AS path length attribute for all reflected client…

Route reflectors do not modify AS paths.

Trap 2: They replace the underlying IGP entirely for packet forwarding.

IGP is still required for next-hop resolution.

Trap 3: They operate exclusively at Layer 2 switching boundaries.

BGP operates at Layer 3.

A
They rewrite the AS path length attribute for all reflected client routes.
Why it fails: Route reflectors do not modify AS paths.
B
They replace the underlying IGP entirely for packet forwarding.
Why it fails: IGP is still required for next-hop resolution.
C
They operate exclusively at Layer 2 switching boundaries.
Why it fails: BGP operates at Layer 3.
D
They eliminate the requirement for a full-mesh IBGP topology within an autonomous system.
Route reflectors reduce IBGP sessions from n(n-1)/2 to a hub-and-spoke design.
E
They require all internal non-client routers to maintain a full mesh with each other.
Non-clients must be fully meshed with the route reflector and other non-clients.

Question 14hardmultiple choice

You are troubleshooting a BGP route selection issue on a Junos device. Two otherwise identical paths are received from external peers. According to the standard BGP route selection algorithm implemented by Junos, which tie-breaking attribute is evaluated immediately AFTER comparing the Router ID (RID) of the advertising routers?

Trap 1: AS path length

AS path length is evaluated much earlier in the BGP route selection process, right after local preference.

Trap 2: Multi-Exit Discriminator (MED)

MED is evaluated before the eBGP/iBGP comparison and well before router ID.

Trap 3: Cluster list length

Cluster list length is evaluated during route reflection tie-breaking steps prior to the router ID comparison.

A
AS path length
Why it fails: AS path length is evaluated much earlier in the BGP route selection process, right after local preference.
B
Multi-Exit Discriminator (MED)
Why it fails: MED is evaluated before the eBGP/iBGP comparison and well before router ID.
C
Cluster list length
Why it fails: Cluster list length is evaluated during route reflection tie-breaking steps prior to the router ID comparison.
D
Lowest neighbor IP address
After the Router ID comparison, Junos evaluates the peer's neighbour IP address and prefers the lower value. This is the standard BGP path-selection step following RID, so lowest neighbour IP correctly breaks the tie between the two external paths.

Question 15mediummulti select

Which THREE optional BGP attributes are supported and processed by Junos routing devices? (Choose three)

Trap 1: LOCAL_WEIGHT

Weight is a Cisco-proprietary local attribute, not a standard BGP path attribute.

Trap 2: NEXT_HOP_OVERRIDE

Next-hop override is a configuration feature on interfaces/VPNs, not a BGP path attribute.

A
COMMUNITY
COMMUNITY is a well-known optional transitive BGP attribute that Junos supports and processes, carrying route tagging used for policy matching. It propagates across autonomous systems, unlike non-transitive attributes such as MED, and is manipulated with community lists.
B
LOCAL_WEIGHT
Why it fails: Weight is a Cisco-proprietary local attribute, not a standard BGP path attribute.
C
ATOMIC_AGGREGATE
ATOMIC_AGGREGATE is a well-known discretionary attribute that Junos supports and processes, marking a route as an aggregate whose more-specific components were suppressed. It satisfies the stem's requirement for optional attributes handled by Junos, being recognised in BGP update messages and propagated without alteration.
D
NEXT_HOP_OVERRIDE
Why it fails: Next-hop override is a configuration feature on interfaces/VPNs, not a BGP path attribute.
E
MED (Multi-Exit Discriminator)
MED is a standard optional non-transitive attribute supported by Junos.

Question 16easymultiple choice

An administrator needs to ensure that a Junos routing device performs unequal-cost multi-path (UCMP) load balancing across multiple BGP paths with different local preferences or path attributes. Which BGP feature must be enabled to allow multipath load balancing across paths with different AS path lengths?

Trap 1: set protocols bgp family inet unicast multipath relax

Junos uses 'as-path-ignore' or specific multipath keywords rather than a generic 'relax' keyword.

Trap 2: set routing-options rib inet.0 multipath

This is not a valid syntax for enabling BGP multipath in Junos.

Trap 3: set protocols bgp load-balance per-packet

Per-packet load balancing is a forwarding-plane mechanism and is not a BGP configuration knob for AS path matching.

A
set protocols bgp multipath as-path-ignore
'multipath as-path-ignore' removes AS path length as a multipath eligibility criterion, allowing BGP to install multiple paths with differing AS path lengths into the forwarding table for UCMP. This satisfies the requirement to load-balance across paths whose attributes differ.
B
set protocols bgp family inet unicast multipath relax
Why it fails: Junos uses 'as-path-ignore' or specific multipath keywords rather than a generic 'relax' keyword.
C
set routing-options rib inet.0 multipath
Why it fails: This is not a valid syntax for enabling BGP multipath in Junos.
D
set protocols bgp load-balance per-packet
Why it fails: Per-packet load balancing is a forwarding-plane mechanism and is not a BGP configuration knob for AS path matching.

Question 17hardmultiple choice

An enterprise is designing a BGP confederation to reduce iBGP mesh complexity across multiple data centers. Which statement is correct regarding how confederation members interact with BGP attributes?

Trap 1: Confederations eliminate the need for any internal iBGP peering…

Confederations still require full iBGP peering within each member sub-AS; they only replace the full mesh between sub-ASes with confederation peering. The option confuses the two tiers. Confederations suit scaling across many sub-ASes, but intra-sub-AS peering remains mandatory.

Trap 2: The next-hop IP address is always modified when routes are passed…

Next hop is preserved across sub-AS boundaries inside a confederation, behaving like standard iBGP; it changes only at true external eBGP edges. The option misapplies eBGP next-hop rewriting. Confederations are chosen to shrink mesh size while retaining internal next-hop reachability.

Trap 3: Local Preference is automatically reset to zero whenever a route…

Local Preference is a well-known discretionary attribute carried unchanged across confederation sub-AS boundaries; it is not reset. The reset applies to MED when routes leave the confederation to true external peers. Confederation design preserves internal path preference, which is why the attribute survives sub-AS traversal.

A
Confederations eliminate the need for any internal iBGP peering within the member sub-ASes.
Why it fails: Confederations still require full iBGP peering within each member sub-AS; they only replace the full mesh between sub-ASes with confederation peering. The option confuses the two tiers. Confederations suit scaling across many sub-ASes, but intra-sub-AS peering remains mandatory.
B
The next-hop IP address is always modified when routes are passed between member sub-ASes within the confederation.
Why it fails: Next hop is preserved across sub-AS boundaries inside a confederation, behaving like standard iBGP; it changes only at true external eBGP edges. The option misapplies eBGP next-hop rewriting. Confederations are chosen to shrink mesh size while retaining internal next-hop reachability.
C
Local Preference is automatically reset to zero whenever a route crosses a sub-AS boundary inside a confederation.
Why it fails: Local Preference is a well-known discretionary attribute carried unchanged across confederation sub-AS boundaries; it is not reset. The reset applies to MED when routes leave the confederation to true external peers. Confederation design preserves internal path preference, which is why the attribute survives sub-AS traversal.
D
Sub-AS numbers are preserved in AS_CONFED_SEQUENCE segments inside the confederation but are replaced by the confederation identifier when advertising to external peers.
AS_CONFED_SEQUENCE carries sub-AS numbers only within the confederation, so internal loop detection works across member sub-ASes. When advertising to external peers, the confederation identifier replaces the sub-AS path, presenting one AS externally. This satisfies the stem's requirement for reduced iBGP mesh complexity while preserving external AS-path appearance.

Question 18hardmulti select

A Juniper Networks router is configured with BGP multipath load balancing. An engineer wants to ensure that BGP can install multiple paths to the same destination into the forwarding table. Which two conditions must be met for BGP multipath to be active on a Junos device? (Choose two.)

Trap 1: The multiple paths must be received from the same BGP peer.

BGP multipath requires paths from different peers to provide redundancy and load balancing. If all paths came from the same peer, they would be identical and not provide any benefit. Multipath is designed to use multiple paths learned from different neighbors, so this condition is incorrect.

Trap 2: The multiple paths must have the same next-hop IGP metric.

While the IGP metric to the next hop is used for BGP path selection, it does not need to be identical for BGP multipath. In fact, BGP multipath can load-balance across paths with different IGP metrics if the 'multipath' option is configured and the paths are otherwise equal. The IGP metric is considered in the path selection process, but it is not a strict requirement for multipath.

Trap 3: The multiple paths must have the same CLUSTER_LIST length.

CLUSTER_LIST is used for route reflection loop prevention, not for multipath equality. While it is considered in the BGP path selection algorithm, it is not a strict requirement for multipath. In fact, paths with different CLUSTER_LIST lengths can still be considered for multipath if other attributes are equal, depending on the configuration.

A
The multiple paths must be received from the same BGP peer.
Why it fails: BGP multipath requires paths from different peers to provide redundancy and load balancing. If all paths came from the same peer, they would be identical and not provide any benefit. Multipath is designed to use multiple paths learned from different neighbors, so this condition is incorrect.
B
The multiple paths must have the same ORIGIN attribute.
The ORIGIN attribute must be the same for BGP multipath to consider paths as equal. ORIGIN indicates how the route was learned (IGP, EGP, or incomplete). If the ORIGIN attributes differ, the paths are not considered equal, and only the best path is used. Therefore, identical ORIGIN is a required condition for multipath.
C
The multiple paths must have the same AS_PATH length and the same MED value.
For BGP multipath to consider multiple paths as equal, they must have the same AS_PATH length and the same MED value. These are among the BGP path selection criteria that must be identical for paths to be considered equal-cost. If they differ, only the best path is selected, and multipath is not activated for that destination.
D
The multiple paths must have the same next-hop IGP metric.
Why it fails: While the IGP metric to the next hop is used for BGP path selection, it does not need to be identical for BGP multipath. In fact, BGP multipath can load-balance across paths with different IGP metrics if the 'multipath' option is configured and the paths are otherwise equal. The IGP metric is considered in the path selection process, but it is not a strict requirement for multipath.
E
The multiple paths must have the same CLUSTER_LIST length.
Why it fails: CLUSTER_LIST is used for route reflection loop prevention, not for multipath equality. While it is considered in the BGP path selection algorithm, it is not a strict requirement for multipath. In fact, paths with different CLUSTER_LIST lengths can still be considered for multipath if other attributes are equal, depending on the configuration.

Question 19hardmultiple choice

An engineer is configuring a JN0-650 BGP route reflector cluster with two route reflectors (RR1 and RR2) that use the cluster ID 10.10.10.10. A route received from a client is reflected by RR1 to non-clients. RR2 also reflects the same route. The engineer observes that non-client routers are receiving duplicate route updates. What is the primary cause of this behavior?

Trap 1: The cluster ID is configured as a loopback address instead of a…

The cluster ID can be any 32-bit value, typically a loopback IP, and does not need to be a physical interface address. Using a loopback is a common practice and does not cause duplicate updates. The issue lies elsewhere in the route reflection configuration.

Trap 2: The route reflectors are not configured with the same cluster ID.

If the cluster IDs were different, the route reflectors would not recognize each other as part of the same cluster, and loop prevention would fail, potentially causing routing loops. However, the scenario states both use cluster ID 10.10.10.10, so this is not the cause of duplicate updates.

Trap 3: The route reflectors are not configured to use the same cluster ID,…

The scenario explicitly states that both route reflectors use cluster ID 10.10.10.10. Therefore, this option contradicts the given information. Even if they were different, the result would be potential loops, not necessarily duplicate updates to non-clients.

A
The cluster ID is configured as a loopback address instead of a physical interface address.
Why it fails: The cluster ID can be any 32-bit value, typically a loopback IP, and does not need to be a physical interface address. Using a loopback is a common practice and does not cause duplicate updates. The issue lies elsewhere in the route reflection configuration.
B
The route reflectors are not configured with the same cluster ID.
Why it fails: If the cluster IDs were different, the route reflectors would not recognize each other as part of the same cluster, and loop prevention would fail, potentially causing routing loops. However, the scenario states both use cluster ID 10.10.10.10, so this is not the cause of duplicate updates.
C
The route reflectors are not configured to use the same cluster ID, causing them to reflect routes independently.
Why it fails: The scenario explicitly states that both route reflectors use cluster ID 10.10.10.10. Therefore, this option contradicts the given information. Even if they were different, the result would be potential loops, not necessarily duplicate updates to non-clients.
D
The route reflectors are not configured with a unique originator ID, and they are reflecting routes from each other.
In a route reflection cluster, the originator ID is used to prevent loops. If RR1 and RR2 reflect routes to each other (as iBGP peers) and then to non-clients, without proper originator ID handling, non-clients may receive duplicates. By default, Junos sets the originator ID to the router ID of the route reflector that first received the route. If both RRs reflect the same route, non-clients may see two copies unless the originator ID is consistent or additional loop prevention is in place. The correct solution is to ensure that the originator ID is preserved and that route reflectors do not reflect routes back to the originator, but the duplicate issue arises when both RRs reflect the same route to non-clients without suppressing duplicates based on originator ID. In Junos, the originator ID is automatically set and used for loop prevention, but if the route reflectors are not configured to use the same cluster ID, they would not recognize each other as part of the same cluster. However, the scenario states they use the same cluster ID. The actual cause is that the route reflectors are reflecting routes to each other and then to non-clients, and the non-clients are receiving duplicates because the originator ID is not being used to suppress the duplicate. This can happen if the route reflectors are not configured to use the same cluster ID, but they are. Therefore, the issue is that the originator ID is not unique or not being used correctly. In practice, Junos automatically sets the originator ID, so the problem might be that the route reflectors are not configured with the same cluster ID, leading to independent reflection. But the scenario says they are. The correct answer is that the route reflectors are not configured with a unique originator ID, and they are reflecting routes from each other. This is a plausible cause for duplicate updates.

Question 20hardmultiple choice

A Juniper Networks router is configured with BGP and you want to influence outbound traffic for a specific prefix by prepending the AS path. You apply an export policy to an EBGP peer that prepends the AS number 65001 three times. However, you notice that the peer is still receiving the prefix with the original AS path length. What is the most likely reason?

Trap 1: The AS path prepend action requires the 'as-path-expand' command…

'as-path-expand' is used to expand an AS path by replacing the last AS number with a specified sequence, often for traffic engineering. However, the standard way to prepend AS numbers is using 'as-path-prepend' in the routing policy. The 'as-path-expand' command is not a direct replacement for prepending; it is a different action. The problem is likely that the policy is not matching the route due to a missing match condition.

Trap 2: The AS path prepend action is only applied to iBGP peers by default.

AS path prepending is commonly used on EBGP sessions to influence inbound traffic from external peers. There is no default restriction that prepending only applies to iBGP peers. In fact, prepending is typically applied on EBGP export policies. The issue in this scenario is more likely related to the policy not being applied due to a missing 'from' clause or incorrect policy order.

Trap 3: The peer is configured with 'remove-private' which strips the…

'remove-private' is used to remove private AS numbers from the AS path when advertising to external peers. It only removes AS numbers in the private range (64512-65534). The AS number 65001 is a private AS number, so if 'remove-private' is configured, it would remove the prepended 65001s. However, the scenario does not mention 'remove-private', and the symptom is that the peer receives the original AS path length, which suggests the prepend did not take effect at all. The more likely cause is a policy mismatch.

A
The AS path prepend action requires the 'as-path-expand' command instead.
Why it fails: 'as-path-expand' is used to expand an AS path by replacing the last AS number with a specified sequence, often for traffic engineering. However, the standard way to prepend AS numbers is using 'as-path-prepend' in the routing policy. The 'as-path-expand' command is not a direct replacement for prepending; it is a different action. The problem is likely that the policy is not matching the route due to a missing match condition.
B
The AS path prepend action is only applied to iBGP peers by default.
Why it fails: AS path prepending is commonly used on EBGP sessions to influence inbound traffic from external peers. There is no default restriction that prepending only applies to iBGP peers. In fact, prepending is typically applied on EBGP export policies. The issue in this scenario is more likely related to the policy not being applied due to a missing 'from' clause or incorrect policy order.
C
The export policy does not include a 'from' clause, so it matches no routes.
In Junos, a routing policy without a 'from' clause matches all routes, but if the policy is intended to match specific prefixes and lacks a 'from' clause, it might inadvertently apply to all routes or none if combined with other terms. However, the most common mistake is that the policy is not applied to the correct protocol or the 'from' clause is missing, causing the policy to not match the intended prefix. In this scenario, the policy likely lacks a 'from' clause to match the specific prefix, so it does not modify the AS path for that prefix.
D
The peer is configured with 'remove-private' which strips the prepended AS numbers.
Why it fails: 'remove-private' is used to remove private AS numbers from the AS path when advertising to external peers. It only removes AS numbers in the private range (64512-65534). The AS number 65001 is a private AS number, so if 'remove-private' is configured, it would remove the prepended 65001s. However, the scenario does not mention 'remove-private', and the symptom is that the peer receives the original AS path length, which suggests the prepend did not take effect at all. The more likely cause is a policy mismatch.