JNCIA Implementation Planning 2 — Questions and Answers

Question 1: What is the primary purpose of a network implementation plan for a Junos deployment?

To document the configuration steps, rollback procedures, and testing criteria before making changes to production (Correct answer)
To purchase hardware from Juniper
To document IP addressing only
To configure routing protocols automatically

Correct answer: To document the configuration steps, rollback procedures, and testing criteria before making changes to production

An implementation plan defines the sequence of configuration changes, pre/post-change verification steps, rollback procedures, and success criteria to reduce risk during network changes.

A good Junos implementation plan includes: pre-change baseline (current state of routing, interfaces, error counters), configuration changes with exact CLI commands, verification steps after each change (specific 'show' commands with expected output), rollback procedure using 'rollback 1' and 'commit', and success criteria. The plan should be reviewed by peers before execution. Junos features like 'commit confirmed' and rollback files support safe implementation practices.

Question 2: In Junos, what is the maximum number of rollback configurations stored by default?

50 (Correct answer)
10
100
5

Correct answer: 50

Junos stores up to 50 rollback configuration files (rollback 0 through rollback 49), with rollback 0 being the current active configuration and rollback 1 being the previous.

Junos automatically saves the previous configuration every time a 'commit' is executed. The files are stored as rollback 0 (current), rollback 1 (previous), up to rollback 49. The number can be adjusted with [edit system max-configurations-on-flash N]. To revert: 'rollback N' in configuration mode followed by 'commit'. 'show system rollback compare N' (or 'rollback compare N M') shows differences between rollback versions. This extensive history makes it easy to recover from configuration mistakes.

Question 3: What does 'load override' do in Junos configuration mode?

Replaces the entire candidate configuration with the contents of a specified file (Correct answer)
Merges a file's configuration with the existing candidate configuration
Reverts to the last committed configuration
Loads only the changed portions of a configuration file

Correct answer: Replaces the entire candidate configuration with the contents of a specified file

'load override' completely replaces the candidate configuration with the file's contents, discarding any existing candidate configuration. It is used to deploy a complete configuration from a file.

Junos 'load' commands: 'load override [file]' — replaces entire candidate with file contents; 'load merge [file]' — merges file into existing candidate (additions only); 'load replace [file]' — merges with replace semantics (removes existing hierarchy if file has it); 'load patch [file]' — applies a diff-style patch; 'load set [file]' — processes a file of 'set' commands. 'load override' is typically used during initial provisioning or when deploying a complete configuration from a template.

Question 4: How should VLAN IDs be planned when deploying Juniper EX switches in a multi-switch environment?

Assign unique VLAN IDs consistently across all switches and trunk ports to ensure traffic segmentation and correct tagging (Correct answer)
Assign random VLAN IDs per switch since VLANs are locally significant
Only configure VLANs on the core switch
Use VLAN IDs above 4000 to avoid conflicts

Correct answer: Assign unique VLAN IDs consistently across all switches and trunk ports to ensure traffic segmentation and correct tagging

VLAN IDs must be consistently planned across the network because 802.1Q VLAN tags are significant end-to-end on trunk ports. Inconsistent VLAN IDs cause traffic misclassification.

In 802.1Q networks, VLAN IDs are carried in frame headers on trunk ports. Both ends of a trunk must agree on which VLAN ID maps to which segment. Juniper EX switches support VLANs 1-4094 (0 and 4095 reserved). Planning should include: VLAN ID assignments, VLAN names, which ports are access vs. trunk, native VLAN assignment, and pruning (limiting which VLANs traverse each trunk). In ELS platforms, VLANs are configured under [edit vlans]; in non-ELS under [edit interfaces unit family ethernet-switching].

Question 5: What is the purpose of 'commit check' in Junos?

Validates the candidate configuration for syntax and semantic errors without activating it (Correct answer)
Checks if the configuration can be committed without conflicts
Tests connectivity after a commit
Verifies hardware compatibility

Correct answer: Validates the candidate configuration for syntax and semantic errors without activating it

'commit check' runs Junos's configuration validation engine against the candidate configuration, reporting any errors or warnings, without making any changes to the active configuration.

'commit check' is a dry run of the commit process. It catches: syntax errors, missing required fields, circular dependencies, interface references to non-existent interfaces, and policy/filter errors. It does not activate changes. This is extremely useful during batch configuration or when deploying via automation. Many Junos automation tools (Ansible Junos module, PyEZ) support 'commit check' as a separate step in CI/CD pipelines. 'commit check' does not catch semantic issues that only manifest at runtime (e.g., a correct but wrong IP).

Question 6: During a Junos upgrade, what is the recommended step before upgrading production devices?

Test the new software version in a lab environment that mirrors production and review the Junos release notes for known issues (Correct answer)
Upgrade during peak traffic hours to detect issues quickly
Skip testing to reduce maintenance window duration
Upgrade all devices simultaneously

Correct answer: Test the new software version in a lab environment that mirrors production and review the Junos release notes for known issues

Testing upgrades in a lab environment and reviewing release notes (for known caveats, changed behaviors, and upgrade paths) minimizes the risk of production issues during a Junos software upgrade.

Best practices for Junos upgrades: (1) Review release notes for 'known issues', 'changes in behavior', and required upgrade paths; (2) Test in lab with representative configuration and traffic; (3) Check for ISSU compatibility if using hitless upgrade; (4) Backup current configuration and verify rollback capability; (5) Schedule a maintenance window; (6) Have rollback plan ready; (7) Monitor after upgrade. Some Junos versions require intermediate upgrade steps (e.g., can't jump from 18.x to 22.x directly on some platforms).

JNCIA Implementation Planning 2

What is the primary purpose of a network implementation plan for a Junos deployment?