Scenario practice questions

While examining an RSTP topology, you notice that a designated port has suddenly stopped receiving BPDUs from its upstream neighbor, causing the port to transition into a discarding state to prevent potential loops. Which feature is actively providing this protection?

Trap 1: Root protection

Root protection only discards superior BPDUs arriving on a port configured as designated, defending the root bridge position; it does not react to a designated port losing its upstream BPDUs. It would be correct on a port that must never accept a new root claim.

Trap 2: BPDU guard

BPDU guard err-disables access ports that receive any BPDU, typically at the network edge with PortFast; it does not discard a designated port when upstream BPDUs cease. It would be correct on end-user access ports where BPDUs should never appear.

Trap 3: TC protection

TC protection merely rate-limits topology-change BPDU processing to prevent CAM table flushing storms; it takes no action when BPDUs stop arriving. It would be the right feature when excessive TC notifications are destabilising forwarding tables.

A
Loop protection
Loop protection detects a designated port that stops receiving BPDUs from its upstream neighbour. It then moves that port into a discarding state, preventing a unidirectional link failure from creating a bridging loop, which matches the described RSTP behaviour.
B
Root protection
Why it fails: Root protection only discards superior BPDUs arriving on a port configured as designated, defending the root bridge position; it does not react to a designated port losing its upstream BPDUs. It would be correct on a port that must never accept a new root claim.
C
BPDU guard
Why it fails: BPDU guard err-disables access ports that receive any BPDU, typically at the network edge with PortFast; it does not discard a designated port when upstream BPDUs cease. It would be correct on end-user access ports where BPDUs should never appear.
D
TC protection
Why it fails: TC protection merely rate-limits topology-change BPDU processing to prevent CAM table flushing storms; it takes no action when BPDUs stop arriving. It would be the right feature when excessive TC notifications are destabilising forwarding tables.

Review the full routing breakdown →

Question 2easymultiple choice

What is the primary function of a Junos routing instance of type 'forwarding'?

Trap 1: To terminate BGP sessions from multiple external peers

A forwarding routing instance isolates a set of interfaces and populates its own routing table, but it does not run BGP or terminate external peer sessions. It is tempting because BGP peering is configured under routing instances, yet that is the virtual-router or VRF instance type, not forwarding.

Trap 2: To run multiple independent OSPF instances

A forwarding instance holds only interfaces and a forwarding table, with no routing protocol daemons, so it cannot run OSPF at all. It tempts because separating protocols is a real use of routing instances, but that requires type virtual-router, not forwarding.

Trap 3: To provide transparent bridging across WAN circuits

Forwarding instances perform stateless packet forwarding between interfaces, typically for filter-based tunnelling or VRF-lite, not Layer 2 bridging. Transparent bridging across WAN circuits requires a bridge domain or VPLS instance, where MAC learning and flooding occur.

A
To terminate BGP sessions from multiple external peers
Why it fails: A forwarding routing instance isolates a set of interfaces and populates its own routing table, but it does not run BGP or terminate external peer sessions. It is tempting because BGP peering is configured under routing instances, yet that is the virtual-router or VRF instance type, not forwarding.
B
To run multiple independent OSPF instances
Why it fails: A forwarding instance holds only interfaces and a forwarding table, with no routing protocol daemons, so it cannot run OSPF at all. It tempts because separating protocols is a real use of routing instances, but that requires type virtual-router, not forwarding.
C
To provide transparent bridging across WAN circuits
Why it fails: Forwarding instances perform stateless packet forwarding between interfaces, typically for filter-based tunnelling or VRF-lite, not Layer 2 bridging. Transparent bridging across WAN circuits requires a bridge domain or VPLS instance, where MAC learning and flooding occur.
D
To support filter-based forwarding without running routing protocols
A forwarding routing instance holds only forwarding tables, with no routing protocol process, and is used with firewall filters to direct traffic into specific next-hop or VRF paths. This satisfies filter-based forwarding without protocol adjacencies.

Question 3hardmultiple choice

An administrator implements port security on a switch stack. A user moves their IP phone (which has an integrated PC attached to it) to a port configured with a MAC limit of one. Only the IP phone works, and the PC is blocked. What feature should be configured to allow multiple authenticated MAC addresses behind a single port securely?

Trap 1: Enable DHCP snooping with static ARP inspection override.

DHCP snooping with static ARP inspection override filters rogue DHCP and ARP traffic; it does not authenticate multiple MAC addresses on one port. It is tempting because it is a Layer 2 security feature. The requirement is voice VLAN with a PC behind the phone, which needs the phone's MAC plus the PC's MAC permitted via a MAC limit above one or 802.1X with multiple-host mode.

Trap 2: Increase the mac-limit to 2 and enable dynamic MAC learning…

Raising the limit to two admits a second MAC but grants it no authentication, so any device could occupy that slot; the phone-plus-PC topology needs the phone to authenticate the PC behind it. Dynamic MAC persistence suits retaining learned addresses across link flaps, not securing daisy-chained devices.

Trap 3: Configure storm control with a multi-device profile.

Storm control rate-limits broadcast, multicast and unknown unicast traffic; it does not authenticate or permit additional source MAC addresses. It is tempting because it also concerns port traffic behaviour, but it would be the right choice when a single host floods the segment, not when a phone and PC must both pass port security.

A
Enable DHCP snooping with static ARP inspection override.
Why it fails: DHCP snooping with static ARP inspection override filters rogue DHCP and ARP traffic; it does not authenticate multiple MAC addresses on one port. It is tempting because it is a Layer 2 security feature. The requirement is voice VLAN with a PC behind the phone, which needs the phone's MAC plus the PC's MAC permitted via a MAC limit above one or 802.1X with multiple-host mode.
B
Increase the mac-limit to 2 and enable dynamic MAC learning persistence.
Why it fails: Raising the limit to two admits a second MAC but grants it no authentication, so any device could occupy that slot; the phone-plus-PC topology needs the phone to authenticate the PC behind it. Dynamic MAC persistence suits retaining learned addresses across link flaps, not securing daisy-chained devices.
C
Configure IEEE 802.1X with multiple supplicants or MAC Authentication Bypass (MAB).
IEEE 802.1X with multiple supplicants authenticates several devices independently on one port, while MAB authenticates devices lacking a supplicant via their MAC address. This lets the phone and attached PC both pass port security's single-MAC limit securely.
D
Configure storm control with a multi-device profile.
Why it fails: Storm control rate-limits broadcast, multicast and unknown unicast traffic; it does not authenticate or permit additional source MAC addresses. It is tempting because it also concerns port traffic behaviour, but it would be the right choice when a single host floods the segment, not when a phone and PC must both pass port security.

Question 4easymulti select

Which TWO parameters are mandatory when configuring a basic GRE tunnel interface in Junos? (Choose two)

Trap 1: GRE keepalive interval timer

Junos GRE interfaces do not require a keepalive timer; only source and destination addresses are mandatory. Keepalives are optional and used to detect tunnel failures when the underlying transport cannot signal them. It is tempting because keepalives genuinely help monitor tunnel liveness in production, but they remain an optional enhancement, not a mandatory parameter.

Trap 2: Routing protocol authentication key

GRE tunnel configuration in Junos requires only the tunnel source and destination addresses; authentication keys belong to routing protocols such as OSPF or BGP, not the tunnel interface itself. It is tempting because securing routing adjacencies traversing the tunnel is a real operational concern, but that is configured under the protocol stanza, not the GRE interface.

Trap 3: IPsec security association profile

A basic GRE tunnel carries no encryption; IPsec is applied separately when confidentiality is required, so no security association profile is mandatory. It is tempting because GRE is often paired with IPsec for secure overlays, but that combination is a deliberate design choice, not a requirement of the tunnel interface itself.

A
GRE keepalive interval timer
Why it fails: Junos GRE interfaces do not require a keepalive timer; only source and destination addresses are mandatory. Keepalives are optional and used to detect tunnel failures when the underlying transport cannot signal them. It is tempting because keepalives genuinely help monitor tunnel liveness in production, but they remain an optional enhancement, not a mandatory parameter.
B
Tunnel destination IP address
A GRE tunnel requires the destination address to identify the remote tunnel endpoint, encapsulating the original packet inside a new IP header. Junos mandates both source and destination for the tunnel interface to come up, since the destination defines where encapsulated traffic is sent. Without it, the tunnel interface remains down.
C
Tunnel source IP address
A GRE tunnel requires a source address so Junos knows which local interface's IP to place in the outer header and from which to route encapsulated traffic. Without it, the tunnel interface cannot establish, since the source defines the tunnel endpoint identity and satisfies the mandatory source parameter in the stem.
D
Routing protocol authentication key
Why it fails: GRE tunnel configuration in Junos requires only the tunnel source and destination addresses; authentication keys belong to routing protocols such as OSPF or BGP, not the tunnel interface itself. It is tempting because securing routing adjacencies traversing the tunnel is a real operational concern, but that is configured under the protocol stanza, not the GRE interface.
E
IPsec security association profile
Why it fails: A basic GRE tunnel carries no encryption; IPsec is applied separately when confidentiality is required, so no security association profile is mandatory. It is tempting because GRE is often paired with IPsec for secure overlays, but that combination is a deliberate design choice, not a requirement of the tunnel interface itself.

Review the full OSPF breakdown →

Question 5easymultiple choice

An administrator is configuring Graceful Restart on a pair of Juniper MX series routers running OSPF. What is the primary purpose of Graceful Restart in this scenario?

Trap 1: To instantly drop all adjacencies and force an immediate full SPF…

Graceful Restart exists to avoid dropping adjacencies and triggering full SPF recalculation during a restart; deliberately forcing that is its opposite. It is tempting because rapid reconvergence after failure is a legitimate design goal, but that is achieved through fast hello and BFD tuning, not Graceful Restart.

Trap 2: To automatically upgrade Junos OS images without rebooting the…

Graceful Restart preserves forwarding state and OSPF adjacencies across a control-plane restart; it does not perform in-service software upgrades. It is tempting because non-stop software upgrades are a real Junos capability, but those rely on unified in-service software upgrade, not the OSPF Graceful Restart helper mechanism.

Trap 3: To synchronize firewall filter counters between primary and backup…

Graceful Restart concerns OSPF control-plane restart and forwarding-state preservation, not synchronising firewall filter counters between Routing Engines. It is tempting because Routing Engine redundancy does involve state synchronisation, but counter mirroring is handled by the firewall synchronisation and graceful-switchover features, not OSPF Graceful Restart.

A
To instantly drop all adjacencies and force an immediate full SPF recalculation across the network.
Why it fails: Graceful Restart exists to avoid dropping adjacencies and triggering full SPF recalculation during a restart; deliberately forcing that is its opposite. It is tempting because rapid reconvergence after failure is a legitimate design goal, but that is achieved through fast hello and BFD tuning, not Graceful Restart.
B
To ensure uninterrupted data packet forwarding while the control plane routing protocol restarts.
Graceful Restart preserves forwarding entries in the data plane while the OSPF control plane restarts, so traffic continues flowing. This satisfies the stem's requirement of uninterrupted packet forwarding during the routing protocol restart on the MX routers.
C
To automatically upgrade Junos OS images without rebooting the forwarding plane.
Why it fails: Graceful Restart preserves forwarding state and OSPF adjacencies across a control-plane restart; it does not perform in-service software upgrades. It is tempting because non-stop software upgrades are a real Junos capability, but those rely on unified in-service software upgrade, not the OSPF Graceful Restart helper mechanism.
D
To synchronize firewall filter counters between primary and backup Routing Engines.
Why it fails: Graceful Restart concerns OSPF control-plane restart and forwarding-state preservation, not synchronising firewall filter counters between Routing Engines. It is tempting because Routing Engine redundancy does involve state synchronisation, but counter mirroring is handled by the firewall synchronisation and graceful-switchover features, not OSPF Graceful Restart.

Question 6mediummultiple choice

An EX4300 Virtual Chassis experiences a split-brain condition due to a failure of all stacking cables between members 0/1 and members 2/3. How does Junos handle this scenario by default?

Trap 1: All member switches across both partitions automatically shut down…

Only the partition lacking the original master disables its data interfaces; members in the partition retaining the master continue forwarding. Shutting down interfaces across both partitions would black-hole the entire chassis. The both-partitions behaviour is tempting as loop prevention, but that role belongs to STP or MC-LAG, not Virtual Chassis split handling.

Trap 2: The backup routing engine instantly shuts down its control plane…

The backup routing engine does not permanently shut down its control plane daemon; on split-brain each partition elects its own master, and the partition without the original master disables its data interfaces rather than killing routing processes. Permanent daemon shutdown is tempting as a partition-fencing mechanism, but Junos fences by interface state, not daemon termination.

Trap 3: The entire Virtual Chassis reboots simultaneously until stacking…

Junos does not reboot the chassis on split-brain; each partition instead runs its own master, with the partition containing the original master retaining primary status and the other becoming inactive for data forwarding. A simultaneous reboot would be tempting as a fail-safe, but that behaviour belongs to protocols like graceful restart, not Virtual Chassis split detection.

A
Each partition elects its own primary routing engine if dual primary detection is not enabled, leading to potential duplicate IP scenarios.
Without dual primary detection, each Virtual Chassis partition independently elects its own primary Routing Engine, since the split severs the control-plane path used for mastership arbitration. Both partitions then remain active, so identical IP and MAC addresses can appear on the network simultaneously, satisfying the stem's default split-brain behaviour.
B
All member switches across both partitions automatically shut down all data interfaces to prevent loops.
Why it fails: Only the partition lacking the original master disables its data interfaces; members in the partition retaining the master continue forwarding. Shutting down interfaces across both partitions would black-hole the entire chassis. The both-partitions behaviour is tempting as loop prevention, but that role belongs to STP or MC-LAG, not Virtual Chassis split handling.
C
The backup routing engine instantly shuts down its control plane daemon permanently.
Why it fails: The backup routing engine does not permanently shut down its control plane daemon; on split-brain each partition elects its own master, and the partition without the original master disables its data interfaces rather than killing routing processes. Permanent daemon shutdown is tempting as a partition-fencing mechanism, but Junos fences by interface state, not daemon termination.
D
The entire Virtual Chassis reboots simultaneously until stacking cables are re-seated.
Why it fails: Junos does not reboot the chassis on split-brain; each partition instead runs its own master, with the partition containing the original master retaining primary status and the other becoming inactive for data forwarding. A simultaneous reboot would be tempting as a fail-safe, but that behaviour belongs to protocols like graceful restart, not Virtual Chassis split detection.

Review the full OSPF breakdown →

Question 7hardmultiple choice

You are troubleshooting an OSPF network on Junos devices. A router in area 1 is not receiving external routes from an ASBR in area 0. The ABR connecting the areas is correctly configured. You suspect a problem with LSA flooding. Which LSA type is used by the ASBR to advertise external routes, and what is its flooding scope?

Trap 1: Type 3 LSA, flooded between areas but not within an area.

Type 3 LSAs are summary LSAs generated by ABRs to advertise networks from one area to another. They do not carry external route information from ASBRs. External routes are advertised via Type 5 (or Type 7 in NSSA). Type 3 LSAs are used for inter-area routes, not external routes, so they cannot be the missing piece here.

Trap 2: Type 7 LSA, flooded only within an NSSA.

Type 7 LSAs are used within NSSAs to carry external route information. They are flooded only within the NSSA and are translated to Type 5 by the NSSA ABR. Since area 1 is not described as an NSSA, Type 7 LSAs are not relevant. The ASBR in area 0 would generate Type 5 LSAs, not Type 7.

Trap 3: Type 4 LSA, flooded only within the area where the ASBR resides.

Type 4 LSAs are generated by ABRs to describe the ASBR to other areas. They are flooded throughout the OSPF domain except stub areas, not just within the ASBR's area. Their purpose is to tell other areas how to reach the ASBR. They do not carry external route information; that is the role of Type 5 LSAs. So this does not explain missing external routes.

A
Type 3 LSA, flooded between areas but not within an area.
Why it fails: Type 3 LSAs are summary LSAs generated by ABRs to advertise networks from one area to another. They do not carry external route information from ASBRs. External routes are advertised via Type 5 (or Type 7 in NSSA). Type 3 LSAs are used for inter-area routes, not external routes, so they cannot be the missing piece here.
B
Type 5 LSA, flooded throughout the entire OSPF domain except stub areas.
Type 5 LSAs are generated by ASBRs to advertise external routes. They are flooded throughout all areas except stub, totally stubby, and NSSA areas. In this scenario, area 1 is a standard area, so Type 5 LSAs should be flooded into it by the ABR. The ABR generates Type 4 LSAs to advertise the ASBR, and Type 5 LSAs are propagated. If not received, check area type or filtering.
C
Type 7 LSA, flooded only within an NSSA.
Why it fails: Type 7 LSAs are used within NSSAs to carry external route information. They are flooded only within the NSSA and are translated to Type 5 by the NSSA ABR. Since area 1 is not described as an NSSA, Type 7 LSAs are not relevant. The ASBR in area 0 would generate Type 5 LSAs, not Type 7.
D
Type 4 LSA, flooded only within the area where the ASBR resides.
Why it fails: Type 4 LSAs are generated by ABRs to describe the ASBR to other areas. They are flooded throughout the OSPF domain except stub areas, not just within the ASBR's area. Their purpose is to tell other areas how to reach the ASBR. They do not carry external route information; that is the role of Type 5 LSAs. So this does not explain missing external routes.

Open the full VLAN trunking answer →

Question 8mediummulti select

You are configuring a Private VLAN (PVLAN) on an EX Series switch to isolate hosts within a DMZ segment while allowing them to reach a shared gateway. Which TWO statements correctly describe the behavior of PVLAN port types in this scenario? (Choose two.)

Trap 1: Isolated ports can communicate with promiscuous ports and with…

While isolated ports can communicate with promiscuous ports, they cannot communicate with other isolated ports. The purpose of an isolated port is to prevent any host-to-host communication within the PVLAN, which is critical for DMZ segmentation. Allowing isolated ports to talk to each other would defeat the security model and is not how PVLANs operate on EX Series switches.

Trap 2: Promiscuous ports can only communicate with isolated ports and not…

Promiscuous ports are not limited to isolated ports; they can communicate with all ports in the PVLAN, including community ports. This universal reachability is what allows a gateway connected to a promiscuous port to serve all hosts, whether they are isolated or in a community. Restricting promiscuous ports to isolated ports only would break community-based designs and is incorrect.

Trap 3: Isolated ports can communicate with each other and with community…

Isolated ports are restricted to communicating only with promiscuous ports. They cannot communicate with other isolated ports or with community ports. This isolation is the primary security benefit of PVLANs, preventing lateral movement between hosts in the same DMZ segment. The statement contradicts the core PVLAN design and is therefore incorrect.

A
Isolated ports can communicate with promiscuous ports and with other isolated ports on the same switch.
Why it fails: While isolated ports can communicate with promiscuous ports, they cannot communicate with other isolated ports. The purpose of an isolated port is to prevent any host-to-host communication within the PVLAN, which is critical for DMZ segmentation. Allowing isolated ports to talk to each other would defeat the security model and is not how PVLANs operate on EX Series switches.
B
Promiscuous ports can only communicate with isolated ports and not with community ports.
Why it fails: Promiscuous ports are not limited to isolated ports; they can communicate with all ports in the PVLAN, including community ports. This universal reachability is what allows a gateway connected to a promiscuous port to serve all hosts, whether they are isolated or in a community. Restricting promiscuous ports to isolated ports only would break community-based designs and is incorrect.
C
Isolated ports can communicate with each other and with community ports within the same PVLAN.
Why it fails: Isolated ports are restricted to communicating only with promiscuous ports. They cannot communicate with other isolated ports or with community ports. This isolation is the primary security benefit of PVLANs, preventing lateral movement between hosts in the same DMZ segment. The statement contradicts the core PVLAN design and is therefore incorrect.
D
Promiscuous ports can communicate with all isolated and community ports, and they typically connect to the gateway or router.
Promiscuous ports are designed to communicate with all ports in the PVLAN, including isolated and community ports. In a DMZ, the router or gateway connects to a promiscuous port so that isolated hosts can reach the gateway while remaining unable to communicate directly with each other. This behavior is fundamental to PVLAN operation and satisfies the requirement of shared gateway access.
E
Community ports can communicate with other ports in the same community and with promiscuous ports, but not with isolated ports.
Community ports form a subgroup that can communicate with each other and with promiscuous ports, but they cannot communicate with isolated ports or with ports in other communities. In a DMZ, this allows a set of servers that need to talk to each other to do so while still being isolated from other hosts and able to reach the gateway through the promiscuous port.

Question 9hardmultiple choice

You are implementing MACsec on an EX Series switch to secure a point-to-point link between two data centers. The link uses a 10 Gigabit Ethernet interface. You want to ensure that only encrypted traffic is accepted and that unencrypted frames are dropped. Which configuration parameter must be set on the interface?

Trap 1: Set the MACsec security mode to 'should-secure'.

'should-secure' mode attempts to secure traffic but allows unencrypted frames to pass if the MACsec session is not established. This does not guarantee that only encrypted traffic is accepted; unencrypted frames could be accepted during session negotiation or if MACsec fails. Therefore, it does not meet the requirement to drop unencrypted frames.

Trap 2: Enable MACsec with the 'no-encrypt' option.

The 'no-encrypt' option disables encryption while still providing integrity checks. This would not encrypt traffic, so unencrypted frames would not be dropped. It is used for scenarios where encryption is not required, but integrity is. This does not satisfy the requirement for encrypted-only traffic.

Trap 3: Configure MACsec with a pre-shared key (PSK) and set the…

Setting the replay-protection window to 0 does not enforce encryption; it only affects replay protection. A PSK is used for authentication, but without the correct security mode, unencrypted frames may still be accepted. This option does not address the requirement to drop unencrypted frames.

A
Set the MACsec security mode to 'should-secure'.
Why it fails: 'should-secure' mode attempts to secure traffic but allows unencrypted frames to pass if the MACsec session is not established. This does not guarantee that only encrypted traffic is accepted; unencrypted frames could be accepted during session negotiation or if MACsec fails. Therefore, it does not meet the requirement to drop unencrypted frames.
B
Set the MACsec security mode to 'must-secure'.
The 'must-secure' mode enforces that all traffic on the interface must be encrypted with MACsec. If an unencrypted frame is received, it is dropped. This ensures that only secured traffic is accepted, meeting the requirement. The other modes, such as 'should-secure' or 'clear', do not enforce encryption and would allow unencrypted frames.
C
Enable MACsec with the 'no-encrypt' option.
Why it fails: The 'no-encrypt' option disables encryption while still providing integrity checks. This would not encrypt traffic, so unencrypted frames would not be dropped. It is used for scenarios where encryption is not required, but integrity is. This does not satisfy the requirement for encrypted-only traffic.
D
Configure MACsec with a pre-shared key (PSK) and set the 'replay-protection' window to 0.
Why it fails: Setting the replay-protection window to 0 does not enforce encryption; it only affects replay protection. A PSK is used for authentication, but without the correct security mode, unencrypted frames may still be accepted. This option does not address the requirement to drop unencrypted frames.

Question 10hardmultiple choice

You are troubleshooting an RSTP network. You notice that a port on an EX Series switch is flapping between Discarding and Forwarding states. You suspect a BPDU inconsistency. Which command would you use to check for BPDU inconsistencies on the switch?

Trap 1: show spanning-tree statistics

This command shows BPDU statistics, such as number of BPDUs sent and received, but it does not indicate inconsistencies. It can help identify if BPDUs are being received, but not whether they are inconsistent. It is useful for traffic analysis but not for detecting configuration mismatches.

Trap 2: show spanning-tree bridge

This command displays bridge-level spanning-tree information, such as bridge ID and timers, but it does not provide per-interface BPDU inconsistency details. It is more for overall bridge status rather than troubleshooting port-specific issues like BPDU inconsistencies.

Trap 3: show spanning-tree interface

This command displays spanning-tree information for interfaces, including role and state, but it does not specifically show BPDU inconsistencies. It can provide general status but not the detailed inconsistency flags needed for troubleshooting. It might show the current state but not the reason for flapping.

A
show spanning-tree interface detail
On Juniper EX Series switches, the 'show spanning-tree interface detail' command provides detailed information for each interface, including any BPDU inconsistencies detected, such as type or version mismatches. This is the correct command to identify why a port might be flapping due to inconsistent BPDUs.
B
show spanning-tree statistics
Why it fails: This command shows BPDU statistics, such as number of BPDUs sent and received, but it does not indicate inconsistencies. It can help identify if BPDUs are being received, but not whether they are inconsistent. It is useful for traffic analysis but not for detecting configuration mismatches.
C
show spanning-tree bridge
Why it fails: This command displays bridge-level spanning-tree information, such as bridge ID and timers, but it does not provide per-interface BPDU inconsistency details. It is more for overall bridge status rather than troubleshooting port-specific issues like BPDU inconsistencies.
D
show spanning-tree interface
Why it fails: This command displays spanning-tree information for interfaces, including role and state, but it does not specifically show BPDU inconsistencies. It can provide general status but not the detailed inconsistency flags needed for troubleshooting. It might show the current state but not the reason for flapping.

Open the full BGP breakdown →

Question 11mediummulti select

You are configuring BGP on a Juniper SRX Series firewall. You want to influence inbound traffic from an eBGP peer for a specific prefix. You have applied an export policy that prepends your AS multiple times. Which two statements are true about AS path prepending in this scenario? (Choose two.)

Trap 1: It is applied using an import policy on the local router.

AS path prepending is typically applied via an export policy that modifies the AS path before advertising to eBGP peers. An import policy affects routes received from peers, not the attributes sent to them, so it cannot prepend AS numbers on outbound updates.

Trap 2: It affects outbound traffic from your local router.

AS path prepending is applied to outbound BGP updates and influences how remote peers select paths toward your network. It does not affect how your local router selects outbound paths; that is determined by inbound BGP attributes and local routing policy.

Trap 3: It requires the 'as-override' statement to function.

The as-override statement is used to replace the peer's AS number with your own in the AS path, typically in MPLS VPN scenarios. It is not required for AS path prepending; prepending simply adds your AS number multiple times using an export policy.

A
It makes the AS path longer, which is less preferred by BGP path selection.
AS path prepending increases the length of the AS path attribute. BGP prefers shorter AS paths, so a longer path is less likely to be selected by remote routers. This is a common technique to influence inbound traffic by making a particular path appear less attractive.
B
It is applied using an import policy on the local router.
Why it fails: AS path prepending is typically applied via an export policy that modifies the AS path before advertising to eBGP peers. An import policy affects routes received from peers, not the attributes sent to them, so it cannot prepend AS numbers on outbound updates.
C
It affects outbound traffic from your local router.
Why it fails: AS path prepending is applied to outbound BGP updates and influences how remote peers select paths toward your network. It does not affect how your local router selects outbound paths; that is determined by inbound BGP attributes and local routing policy.
D
It can be used to influence inbound traffic by making the path less preferred.
By prepending your AS number multiple times, the AS path length increases, making the route less preferred by remote BGP speakers. This is a standard method to influence inbound traffic, often used when you want traffic to prefer another link or provider.
E
It requires the 'as-override' statement to function.
Why it fails: The as-override statement is used to replace the peer's AS number with your own in the AS path, typically in MPLS VPN scenarios. It is not required for AS path prepending; prepending simply adds your AS number multiple times using an export policy.