OBSERVE → PLAN → VERIFY → ROLLBACK

Network Change Planner & MOP Generator

Turn current device state into a minimal, risk-scored, reversible and verifiable network change plan.

5 VendorsMinimal DeltaRisk + MOPClosed-loop Verification

Configuration parsing and verification run locally in your browser. V1.1 manages the tested LAG and trunk/VLAN domain only.

1
Capture current statePaste running configuration or load a representative engineering case.
2
Define desired intentSelect the device, aggregate members, VLANs and native/PVID.
3
Review plan and riskInspect minimal delta, risk reasons, rollback and MOP.
4
Verify executionPaste post-check evidence and evaluate PASS / ROLLBACK.
Select a device and build your first change plan.

STEP 1 · OBSERVE

Current state and engineering case

EXAMPLE DATA

The loaded case is training data. Replace the running configuration before using the plan for a real change.

Current running configuration
Input readiness

    STEP 2 · INTENT

    Desired change intent

    Device model
    Aggregate ID
    LAG mode
    Aggregate members
    Member A
    Member B
    Trunk allowed VLANs
    Native / PVID VLAN
    Description
    Nothing is sent to a device.

    STEP 3 · PLAN

    Change summary and explanation

    Next: Build a plan, then review risk, forward config and rollback before following the runbook.
    Risk assessment

    What this plan means

    iBuild a plan to see the operational meaning of the detected drift and risk.

    Semantic diff

    Minimal forward configuration

    Rollback configuration

    EXECUTION

    Execution MOP / runbook

      STEP 4 · VERIFY

      Post-change verification loop

      Paste the real output for each requested command. Missing evidence returns INCONCLUSIVE rather than a false PASS.

      0 checks have evidence.

      DOCUMENT

      Copyable MOP document

      The document is generated from the same plan, risk factors, runbook, forward/rollback configuration and final verification decision.

      Build a change plan to generate the MOP document.

      From configuration generation to a closed-loop change workflow

      1. Parse current state

      The tool extracts managed LAGs, member bindings, trunk VLANs, native/PVID values and VLAN inventory from the running configuration. Unsupported context is kept unmanaged.

      2. Reconcile desired intent

      Select a real baseline device and ports, then declare aggregate ID, LACP/static mode, allowed VLANs and native VLAN. Conflicting member ownership and missing VLANs block execution.

      3. Emit only the minimal delta

      State that is already correct is not reconfigured. Member, VLAN, native VLAN and description differences become deterministic forward actions and inverse rollback actions.

      4. Close the loop with real CLI evidence

      After execution, paste the requested show/display output back into the page. PASS requires positive evidence; incomplete evidence returns INCONCLUSIVE.

      Engineering boundaries and safety principles

      Fail closed

      Member ownership conflicts, missing VLAN inventory, invalid port selection or invalid intent block configuration generation.

      Evidence before PASS

      Post-change PASS requires sufficient CLI evidence. Missing or unsupported evidence is INCONCLUSIVE rather than assumed successful.

      Managed domain only

      V1.1 automatically manages the platformized LAG and trunk/VLAN semantics only; BGP, OSPF, STP, QoS and other domains remain outside this tool.

      Operator control

      Generated MOP and rollback output are engineering aids. Production execution should still follow vendor documentation, change approval, maintenance-window and site rollback procedures.

      Frequently asked questions

      Why does the tool generate a minimal delta instead of a full replacement?

      Production changes should minimize blast radius. The planner parses the managed current state and emits only the actions needed to reach the desired intent, plus the inverse rollback actions.

      Can I paste any running configuration?

      Flagship V1.1 manages the LAG and trunk/VLAN domains already implemented and tested in the V2 shared core. Other lines remain unmanaged context and are not automatically rewritten.

      What can trigger ROLLBACK_REQUIRED?

      An aggregate that stays down, insufficient bundled members, trunk/native VLAN mismatch, unexpected aggregate members or new interface errors can trigger an automatic rollback recommendation.

      Does this tool connect to devices and execute commands?

      No. Flagship V1.1 is a local browser-based planning, generation and verification tool. It does not log into devices, store credentials or automatically push configuration.

      Why are device models and port ranges deliberately limited?

      Automatic interface resolution is enabled only for baseline models in the Device Platform Catalog with explicit naming contracts. Outside verified scope, an engineer should confirm the interface rather than let the system guess.

      References and review

      Engineering content reviewed: 2026-09-05 · Scope: LAG + trunk/VLAN closed-loop change V1.1

      Production execution should still be checked against the applicable vendor guide. Useful starting points include Cisco Catalyst 9200 documentation, Huawei Enterprise Switch documentation and Juniper EX Series documentation.

      ENGINEERING WORKFLOW

      Continue the engineering workflow

      Current workflowNetwork Change Automation Workflow

      Validate policy intent, then turn current device state and desired LAG/VLAN changes into a risk-scored, verifiable and reversible MOP.

      Step 2 of 2
      PreviousMulti-Vendor ACL Generator & ValidatorGenerate, convert and validate IPv4 ACLs for Cisco IOS, Huawei VRP, H3C Comware and Juniper Junos.
      NextWorkflow complete

      Related tools

      Also used inData Center Network Fabric Planning Workflow