High Availability practice questions

Modify the routing-engine mastership-priority value on the preferred member switch to be higher than the others.

Mastership priority determines primary RE election; the member with the highest configured value wins. Raising the preferred switch's priority above the others ensures it reclaims primary after a reboot, directly preventing the unintended member from taking over again.

show chassis routing-engine

`show chassis routing-engine` reports each Routing Engine's mastership, status and failover state, confirming GRES synchronisation between the primary and backup. It directly satisfies the stem's requirement to verify GRES operation on an MX with dual Routing Engines, unlike interface or protocol commands that reveal nothing about RE redundancy health.

Check physical interface error counters and increase the VRRP advertisement interval if packet drops occur.

Missing advertisements stem from physical-layer drops, so inspecting interface error counters identifies the fault, while raising the advertisement interval reduces sensitivity to intermittent loss. This resolves the transitions without altering master priority, satisfying the stem's constraint.

Virtual Chassis ports (VCPs) must be explicitly configured to match supported transceiver speeds, and mixing unsupported interface types will result in port initialization failure.

Junos requires Virtual Chassis ports to be explicitly configured for the supported transceiver speed on each interface. Mixing unsupported interface types across members causes port initialisation failure, so the configuration must match the hardware capabilities of each port.

show virtual-chassis

`show virtual-chassis` queries the Virtual Chassis control plane directly, returning each member's slot, role (Master, Backup, Linecard), and serial number. It satisfies the stem's requirement to display member status, roles, and serial numbers in one output, unlike interface-level commands that omit chassis membership data.

show chassis hardware

While show chassis hardware displays components, show virtual-chassis specifically lists VC roles and stacking ports.

show vrrp detail

The show vrrp detail command outputs per-group VRRP information, including master router state, virtual IP addresses and advertisement intervals, matching exactly the fields the stem requires for troubleshooting VRRP groups on an EX series switch.

NSR was not enabled under the BGP routing-options protocol hierarchy, causing the protocol daemon state to not synchronize to the backup Routing Engine.

NSR must be enabled under the BGP hierarchy for the routing protocol daemon to synchronise BGP state to the backup Routing Engine. Without it, GRES alone cannot preserve the session, so BGP drops peering after switchover.

show ospf overview

`show ospf overview` displays the OSPF instance parameters, including the Graceful Restart helper capability, which Junos enables by default. It satisfies the stem's requirement to verify helper mode without altering configuration, unlike `show ospf neighbor` or interface-level commands that expose only adjacency or timer state.

The virtual-mac-address option was explicitly disabled, or an incorrect configuration caused the master to use its physical interface MAC address for virtual IP ARP responses.

Disabling the virtual MAC option forces the VRRP master to answer ARP for the virtual IP using its physical interface MAC, breaking the virtual router abstraction. Clients then cache a MAC tied to one router, so traffic drops when mastership moves or that link fails. Re-enabling virtual MAC restores the 00:00:5E:00:01:XX address.

Configure load-balance profiles under [edit forwarding-options hash-key] specifying inet protocols.

Junos performs LAG hashing via load-balance profiles configured under [edit forwarding-options hash-key]. Specifying inet protocols includes Layer 3 IP and Layer 4 port fields in the hash, rather than hashing on Layer 2 MAC addresses alone.

Virtual Chassis split-detection or auxiliary management connection mechanisms that evaluate reachability between partitions to disable the non-primary partition.

Split detection works by monitoring reachability between Virtual Chassis partitions over the auxiliary management connection; when a partition loses contact with the designated primary, it disables its downstream ports. This directly satisfies the stem's requirement to prevent duplicate packet forwarding during a split-brain condition on the EX4300.

GRES must be enabled at the chassis level, and NSR must be explicitly enabled under the BGP protocol hierarchy.

NSR depends on Graceful Routing Engine Switchover to preserve forwarding state during a Routing Engine failover, so GRES must be enabled at the chassis level. Enabling NSR under the BGP hierarchy then lets BGP sessions survive that switchover without tearing down, satisfying the requirement for uninterrupted peering.

show chassis routing-engine

`show chassis routing-engine` reports the Routing Engine's mastership, uptime, memory and CPU utilisation, and GRES readiness state, directly satisfying the stem's requirement to check RE health and graceful switchover status on an MX series router.

show chassis alarms

`show chassis alarms` surfaces hardware and environmental alerts, including Routing Engine failures and GRES switchover conditions, satisfying the requirement to check Routing Engine health. It reports active alarm conditions rather than configuration state, so it directly confirms whether a redundant engine has faulted or a graceful switchover has occurred.

A minimum number of active links can be configured to ensure traffic drops if bandwidth falls below a threshold.

LACP supports a minimum active link threshold; when active members drop below it, the LAG is marked down so traffic fails over rather than being blackholed on degraded bandwidth. This satisfies the stem's requirement to consider bandwidth-threshold behaviour.

All member links must have identical speed, duplex, and LACP active/passive settings.

LACP requires member links to match in speed, duplex and LACP mode (active or passive); mismatches prevent the bundle forming correctly. This satisfies the stem's requirement to consider consistent physical and protocol parameters across all member links.

Aggregated device counts must be defined under the [edit chassis aggregated-devices ethernet] hierarchy.

Configuring aggregated device counts under [edit chassis aggregated-devices ethernet] is mandatory on Junos; without it, the switch cannot create any Link Aggregation Group. This satisfies the platform-level prerequisite that must be set before LACP bundles form, since Junos caps the number of aggregate interfaces the chassis supports.

Pre-provisioning member serial numbers ensures consistent member ID assignments regardless of boot order.

Pre-provisioning maps each serial number to a fixed member ID in the configuration, so a switch retains its assigned ID irrespective of the order in which members boot or join the Virtual Chassis. This satisfies the stem's requirement for consistent member ID assignment, preventing election and port-mapping disruption caused by boot-order variation.

If the primary Routing Engine fails, the backup member assumes the primary role seamlessly if GRES is active.

Graceful Routing Engine Switchover preserves forwarding state during a primary Routing Engine failure, letting the backup member take the primary role without restarting Packet Forwarding Engines or dropping traffic. This satisfies the seamless failover constraint, provided GRES is configured and the backup is ready.

Mastership priority values range from 0 to 255, with the highest value preferred for the primary role.

Mastership priority is a configurable 0–255 value, and the highest number wins the primary role, satisfying the election criterion. This contrasts with the member ID, which only breaks ties after priority. Setting a higher priority on the intended primary switch therefore deterministically controls Virtual Chassis master election.

It helps prevent unnecessary SPF recalculations across the network during transient control plane restarts.

During a neighbour's control-plane restart, helper mode suppresses topology change flooding, so other routers do not run full SPF for a transient event. This directly satisfies the stem's requirement about avoiding unnecessary SPF recalculations network-wide.

Helper mode enables a router to assist a restarting neighbor by maintaining its routing entries during the restart window.

The helper keeps the restarting router's adjacencies and LSAs in its own LSDB for the restart window, preserving routing entries rather than flushing them. This directly satisfies the stem's requirement that the helper maintain routing entries during the restart.

Helper mode is enabled by default for OSPF in Junos OS.

Helper mode is enabled by default on Junos OS OSPF interfaces, satisfying the stem's requirement for a true statement. The router automatically assists a restarting neighbour by suppressing adjacency resets during the graceful restart window, so no explicit helper-mode configuration is needed unless disabled.

Traffic loops may occur if static LAG mode is mismatched with LACP active mode on opposite ends.

A static LAG on one side forwards without LACP negotiation, while the LACP-active peer only aggregates links that complete the handshake. Mismatched modes leave links unaggregated yet forwarding, so the same frames traverse multiple paths and create Layer 2 loops.

The aggregated interface may go operationally down if active member links drop below the configured minimum-links threshold.

LACP tracks operational member links against the configured minimum-links value. When active members fall below that threshold, the aggregated interface is marked down, preventing a degraded LAG from carrying traffic with insufficient bandwidth or redundancy.

Member links may be placed in 'Suspended' or 'Expired' states if LACP protocol handshakes fail.

When LACP protocol data units are not exchanged successfully, member links fail the handshake and enter Suspended or Expired states. Those links stay out of the aggregation, reducing usable bandwidth and potentially dropping the bundle below its minimum-links threshold.

The backup Routing Engine becomes master and maintains the forwarding state of the line cards, provided that graceful switchover is enabled.

When graceful switchover is enabled, the backup Routing Engine takes over and the line cards continue forwarding without reset. This is the purpose of graceful switchover: to provide hitless failover. Without it, the line cards might reset. The scenario asks for immediate takeover without full reboot, which graceful switchover provides.

Enable graceful-switchover under the [edit chassis redundancy] hierarchy.

To enable GRES, you must configure the graceful-switchover statement under [edit chassis redundancy]. This enables the synchronization of kernel and forwarding state between the master and backup Routing Engines. Once enabled, the backup is kept in sync and can take over seamlessly. This is the correct configuration for the scenario.

Configure a backup member by setting the mastership priority appropriately on at least one other member.

The Virtual Chassis elects a master based on mastership priority. To have a backup ready to take over, you must ensure at least one other member has a suitable priority so it can become the backup. Without a designated backup, a master failure could leave the Virtual Chassis without a control plane until a new master is elected, which may cause an outage.

Ensure the backup member is connected and reachable through the Virtual Chassis ports.

For the backup to take over, it must be an active member of the Virtual Chassis with working Virtual Chassis ports. If the backup is isolated or its VCP links are down, it cannot participate in the election or assume the master role. Proper cabling and link health are therefore essential for control-plane redundancy.