DEV Community

Cover image for Stop Copy-Pasting Router Configs: I Built a Browser-Based Network Config Generator
Dinuka Wijesinghe
Dinuka Wijesinghe

Posted on

Stop Copy-Pasting Router Configs: I Built a Browser-Based Network Config Generator

#networkautomation #networking #devops #javascript

Have you ever had to configure 50 routers using almost the same template, but with different IP addresses, interfaces, VLANs, VRFs, or BGP neighbors?

The first few devices are easy.

Then you reach device number 27.

You copy the previous configuration, change an IP address, change an interface, change a VLAN, change a hostname... and eventually you're wondering:

"Did I actually change everything I was supposed to change?"

This is one of those problems that looks simple until you have to do it at scale.

A wrong IP address, duplicated VLAN, incorrect interface, missing configuration line, or accidental copy/paste can turn a simple provisioning task into a troubleshooting session during a maintenance window.

I've dealt with enough repetitive network configuration work to eventually build something for it.

So I built a free, browser-based Network Config Generator that takes CSV/Excel data and a configuration template and generates ready-to-review CLI configurations in bulk.

Try the tool:

https://dinukawijesinghe.com/tools/config-generator.html

The Problem: Manual Network Configuration Doesn't Scale

Manual configuration isn't necessarily bad.

If you're configuring one router, typing the configuration directly into the CLI is often the fastest approach.

The problem starts when the configuration is mostly identical across dozens or hundreds of devices.

Imagine provisioning multiple PE routers with something like:

hostname PE-001
Enter fullscreen mode Exit fullscreen mode 
interface TenGigE0/0/0/1
 description CUSTOMER-A
 ip address 10.10.1.1 255.255.255.252
 vrf CUSTOMER-A
 no shutdown
Enter fullscreen mode Exit fullscreen mode

Then:

hostname PE-002
Enter fullscreen mode Exit fullscreen mode 
interface TenGigE0/0/0/1
 description CUSTOMER-B
 ip address 10.10.2.1 255.255.255.252
 vrf CUSTOMER-B
 no shutdown
Enter fullscreen mode Exit fullscreen mode

Then another device, and another.

The configuration logic hasn't changed. Only the data has changed.

That's where manual editing becomes risky.

Common problems include:

  • Copy/paste mistakes
  • Wrong IP addresses
  • Duplicate IP addresses
  • Incorrect VLAN IDs
  • Wrong interface names
  • Duplicate hostnames
  • Incorrect VRF names
  • Missing configuration lines
  • Leftover values from the previous device
  • Human fatigue
  • Configuration drift
  • Repetitive provisioning work
  • Change-window pressure

The actual engineering work isn't necessarily writing the configuration.

It's making sure the right values are inserted into the right places.

That's what led me to build this tool.

The Idea Behind the Tool

The concept is simple:

Separate the configuration logic from the device-specific data.

Instead of manually editing this configuration for every device:

interface TenGigE0/0/0/1
 description CUSTOMER-A
 ip address 10.10.1.1 255.255.255.252
 vrf CUSTOMER-A
Enter fullscreen mode Exit fullscreen mode

create one reusable template:

interface {{INTERFACE}}
 description {{DESCRIPTION}}
 ip address {{IP}} {{MASK}}
 vrf {{VRF}}
Enter fullscreen mode Exit fullscreen mode

Then put the changing values into a spreadsheet.

For example:

HOSTNAME INTERFACE DESCRIPTION IP MASK VRF
PE-001 Te0/0/0/1 CUSTOMER-A 10.10.1.1 255.255.255.252 CUSTOMER-A
PE-002 Te0/0/0/1 CUSTOMER-B 10.10.2.1 255.255.255.252 CUSTOMER-B
PE-003 Te0/0/0/1 CUSTOMER-C 10.10.3.1 255.255.255.252 CUSTOMER-C

The generator combines the template with each row and produces the corresponding configuration.

The spreadsheet provides the data.

The template provides the configuration structure.

How the Network Config Generator Works

The workflow is:

CSV / Excel
     |
     v
Data Parser
     |
     v
Validation Engine
     |
     v
Template Engine
     |
     v
Configuration Generator
     |
     +--------+---------+---------+
     |        |         |         |
     v        v         v         v
    TXT     Excel      ZIP    Clipboard
Enter fullscreen mode Exit fullscreen mode

The tool doesn't need to understand whether a particular command belongs to Cisco, Juniper, Arista, or Nokia.

It works with the configuration as text.

That makes the approach flexible across different network platforms.

Template-Based Configuration

The main concept is the {{VARIABLE}} placeholder.

For example:

interface {{INTERFACE}}
 description {{DESCRIPTION}}
 ip address {{IP}} {{MASK}}
 vrf {{VRF}}
 no shutdown
Enter fullscreen mode Exit fullscreen mode

The variable names correspond to spreadsheet column names.

So {{INTERFACE}} expects an INTERFACE column.

Likewise, {{DESCRIPTION}} expects a DESCRIPTION column.

And {{IP}} expects an IP column.

There is no fixed spreadsheet schema.

You define the variables based on what you're configuring.

For example, a BGP template could use:

router bgp {{ASN}}
 neighbor {{PEER_IP}} remote-as {{PEER_AS}}
 neighbor {{PEER_IP}} description {{PEER_DESCRIPTION}}
Enter fullscreen mode Exit fullscreen mode

while an interface template could use:

interface {{INTERFACE}}
 description {{DESCRIPTION}}
 ip address {{IP}} {{MASK}}
Enter fullscreen mode Exit fullscreen mode

The same generator can handle both.

CSV/Excel as the Source of Truth

Network engineers already use spreadsheets heavily during migrations, provisioning, implementation planning, and network expansion.

A typical dataset might look like:

HOSTNAME,INTERFACE,DESCRIPTION,VRF,IP,MASK
PE-001,Te0/0/0/1,CUSTOMER-A,CUST-A,10.10.1.1,255.255.255.252
PE-002,Te0/0/0/2,CUSTOMER-B,CUST-B,10.10.2.1,255.255.255.252
PE-003,Te0/0/0/3,CUSTOMER-C,CUST-C,10.10.3.1,255.255.255.252
Enter fullscreen mode Exit fullscreen mode

The important relationship is:

Spreadsheet column
       |
       v
  {{VARIABLE}}
       |
       v
Configuration template
Enter fullscreen mode Exit fullscreen mode

This makes the template easy to understand and reuse.

Validation Before Generation

Generating hundreds of configurations quickly isn't useful if the input data contains mistakes.

Before generating configurations, the tool checks the relationship between the template and the spreadsheet.

For example, if the template contains:

{{INTERFACE}}
{{IP}}
{{VRF}}
{{PEER_IP}}
Enter fullscreen mode Exit fullscreen mode

but the spreadsheet doesn't contain a PEER_IP column, that's something worth catching before generating the configuration.

The validation process helps identify:

  • Matched variables
  • Missing variables
  • Unused spreadsheet columns
  • Duplicate rows
  • Repeated values
  • Duplicate hostnames
  • Repeated IP addresses
  • Repeated VLAN values
  • Repeated interface values

For example:

HOSTNAME     IP
PE-001       10.10.1.1
PE-002       10.10.2.1
PE-003       10.10.2.1
Enter fullscreen mode Exit fullscreen mode

The repeated IP address is something you can investigate before the generated configuration reaches a production device.

This isn't a replacement for proper network validation. It is an additional check designed to catch common data-entry and copy/paste mistakes.

Generate Configurations at Scale

Once the template and data pass validation, there are two main generation modes.

Generate All

Generate configuration for every row in the dataset.

100 spreadsheet rows
        |
        v
100 generated configurations
Enter fullscreen mode Exit fullscreen mode

Generate Selected

Sometimes you don't want to generate everything.

You may only be working on:

PE-017
PE-018
PE-021
PE-025
Enter fullscreen mode Exit fullscreen mode

The tool allows specific rows to be selected and generated.

This can be useful during staged migrations or maintenance windows where only a subset of devices is being changed.

A Practical Example

Let's say we're provisioning interfaces.

Template 

interface {{INTERFACE}}
 description {{DESCRIPTION}}
 vrf {{VRF}}
 ip address {{IP}} {{MASK}}
 no shutdown
Enter fullscreen mode Exit fullscreen mode

Input Data 

HOSTNAME,INTERFACE,DESCRIPTION,VRF,IP,MASK
PE-001,Te0/0/0/1,CUSTOMER-A,CUST-A,10.10.1.1,255.255.255.252
PE-002,Te0/0/0/2,CUSTOMER-B,CUST-B,10.10.2.1,255.255.255.252
PE-003,Te0/0/0/3,CUSTOMER-C,CUST-C,10.10.3.1,255.255.255.252
Enter fullscreen mode Exit fullscreen mode

Generated Configuration

For PE-001:

interface Te0/0/0/1
 description CUSTOMER-A
 vrf CUST-A
 ip address 10.10.1.1 255.255.255.252
 no shutdown
Enter fullscreen mode Exit fullscreen mode

For PE-002:

interface Te0/0/0/2
 description CUSTOMER-B
 vrf CUST-B
 ip address 10.10.2.1 255.255.255.252
 no shutdown
Enter fullscreen mode Exit fullscreen mode

For PE-003:

interface Te0/0/0/3
 description CUSTOMER-C
 vrf CUST-C
 ip address 10.10.3.1 255.255.255.252
 no shutdown
Enter fullscreen mode Exit fullscreen mode

One template.

Three data rows.

Three generated configuration blocks.

The same approach can be used with hundreds or thousands of rows.

Vendor Independence

I deliberately didn't build this around a Cisco-specific configuration parser.

That would make the tool more complicated and less useful for engineers working in multi-vendor environments.

The generator treats the configuration as text.

Cisco IOS-XE 

interface GigabitEthernet{{PORT}}
 description {{DESCRIPTION}}
 ip address {{IP}} {{MASK}}
 no shutdown
Enter fullscreen mode Exit fullscreen mode

Cisco IOS-XR 

interface TenGigE{{INTERFACE}}
 description {{DESCRIPTION}}
 ipv4 address {{IP}} {{MASK}}
 no shutdown
Enter fullscreen mode Exit fullscreen mode

Juniper JunOS 

set interfaces {{INTERFACE}} description "{{DESCRIPTION}}"
set interfaces {{INTERFACE}} unit 0 family inet address {{IP}}/{{PREFIX}}
Enter fullscreen mode Exit fullscreen mode

The generator doesn't need to know what these commands mean.

It simply replaces the variables.

The same approach can be used with:

  • Cisco IOS-XE
  • Cisco IOS-XR
  • Cisco NX-OS
  • Juniper JunOS
  • Arista EOS
  • Nokia SR OS
  • Other text-based CLI systems

This is particularly useful in service-provider environments where engineers may work across different platforms and equipment generations.

Real Network Engineering Use Cases

PE Router Provisioning

Generate repeated interface, VRF, routing, or BGP configuration for multiple PE routers.

Access Switch Configuration

Generate interface configurations across a large number of access switches:

interface GigabitEthernet0/1
 description {{DESCRIPTION}}
 switchport mode access
 switchport access vlan {{VLAN}}
 spanning-tree portfast
Enter fullscreen mode Exit fullscreen mode

VLAN Deployment

Generate repetitive VLAN-related configuration from structured data.

BGP Neighbor Provisioning

For example:

neighbor {{PEER_IP}} remote-as {{REMOTE_AS}}
neighbor {{PEER_IP}} description {{DESCRIPTION}}
Enter fullscreen mode Exit fullscreen mode

VRF Provisioning

Generate repeated VRF and interface configuration across multiple devices.

NNI Configuration

Carrier and ISP environments often involve repetitive NNI configuration where interface IDs, descriptions, VLANs, IP addresses, and peer information vary between locations.

Customer Migration

During migrations, engineers often prepare similar configurations for many services.

Instead of manually editing each block, the common structure can be represented once as a template.

Network Expansion

When adding new sites, routers, interfaces, or services, the same approach can reduce repetitive configuration preparation.

Architecture

The application was intentionally designed to be simple.

There is no backend configuration engine that receives your spreadsheet and generates the configuration remotely.

The processing happens in the browser.

The high-level architecture is:

CSV / Excel
     |
     v
+----------------+
|  Data Parser   |
+----------------+
     |
     v
+----------------+
|   Validation   |
|     Engine     |
+----------------+
     |
     v
+----------------+
|    Template    |
|     Engine     |
+----------------+
     |
     v
+----------------+
|  Configuration |
|    Generator   |
+----------------+
     |
+----+-----+---------+-----------+
|    |     |         |
v    v     v         v
Enter fullscreen mode Exit fullscreen mode

TXT Excel ZIP Clipboard

The application is intentionally lightweight:

  • No installation
  • No Python environment
  • No database
  • No backend required
  • Works directly in a modern browser

Security and Data Privacy

Network configuration data can contain information that engineers may not want to upload to an external service, including:

  • Internal IP addressing
  • Device names
  • Interface details
  • BGP peer information
  • VLAN assignments
  • VRF names
  • Customer-related identifiers

The generator processes the data client-side in the browser rather than requiring the spreadsheet to be uploaded to a configuration-generation server.

This reduces the need to send network data to a backend service.

It is important not to interpret this as a guarantee that the data is automatically secure. Normal browser, endpoint, and organizational security controls still apply.

The main advantage is that the tool does not require a remote backend for the configuration-generation process.

Performance

The tool has been tested with datasets containing more than 10,000 rows.

The goal wasn't to build a benchmark project.

The goal was to make bulk configuration generation practical without requiring a Python environment, database, server, or specialized automation platform.

For most use cases, generating the text itself is not the difficult part.

Preparing and validating the input data correctly is often more important.

That's why validation and data editing are an important part of the workflow.

Exporting the Result

After generation, configurations can be used in several ways.

Copy to Clipboard

Useful when you're working directly in a terminal, console server, or jump host.

TXT

Generate a text file containing the generated configurations.

Excel

Export the original data together with a generated configuration column.

This can be useful when you want the input data and generated result together for review.

ZIP

Generate individual configuration files for each device.

For example:

configs/
├── PE-001.txt
├── PE-002.txt
├── PE-003.txt
├── PE-004.txt
└── PE-005.txt
Enter fullscreen mode Exit fullscreen mode

The filename can be based on a selected spreadsheet column.

Why I Built This

This project started from a very normal network engineering problem.

I've worked with configuration blocks where most commands are identical, but a handful of values change from device to device.

The process usually becomes:

Copy
Paste
Change IP
Change interface
Change description
Change VLAN
Check
Repeat
Enter fullscreen mode Exit fullscreen mode

Then repeat that process dozens of times.

It's not difficult work.

It's repetitive work.

And repetitive work is exactly where small automation tools can help.

I wanted something lightweight that I could open in a browser, feed with structured data, generate configurations, and move on to the actual engineering work.

The question was simple:

What if I could describe the configuration once and provide the changing values as data?

That's essentially what this tool does.

Limitations

The generator is intentionally simple, and that also defines its limitations.

It generates configuration based on:

  1. Your template
  2. Your input data

It does not understand your actual network topology.

For example, it doesn't know whether:

10.10.10.1/30
Enter fullscreen mode Exit fullscreen mode

is actually the correct address for a particular interface.

It doesn't know whether:

Te0/0/0/7
Enter fullscreen mode Exit fullscreen mode

exists on your router.

It doesn't know whether a BGP neighbor is reachable.

It doesn't understand your network design.

It doesn't replace a proper change-management or network automation platform.

Most importantly:

A successfully generated configuration is not necessarily a correct configuration.

Generated configurations should still be reviewed and, where appropriate, tested before being deployed to production devices.

The tool automates the repetitive part.

The engineer remains responsible for the network decision.

Future Improvements

There are several directions this project could eventually take.

Device Connectivity

Integrate with network devices through an appropriate automation layer instead of only generating configuration files.

Pre-Check / Post-Check Automation

Generate operational checks before and after a change and compare the results.

PRE-CHECK
    |
    v
Configuration Change
    |
    v
POST-CHECK
    |
    v
DIFF
Enter fullscreen mode Exit fullscreen mode

Configuration Diff

Automatically compare pre-change and post-change configuration or command output.

Ansible Integration

Generate structured data or playbook inputs that can be consumed by Ansible-based workflows.

NetBox Integration

Use NetBox as a source of structured device and service data instead of manually maintaining spreadsheets.

Git-Based Configuration Management

Store templates and generated configurations in Git for version control, review, and auditability.

CI/CD Workflows

A future workflow could look like:

Source of Truth
       |
       v
   Validation
       |
       v
     Template
       |
       v
    Generate
       |
       v
Review / Pull Request
       |
       v
     Deploy
       |
       v
   Post-Check
Enter fullscreen mode Exit fullscreen mode

More Advanced Validation

Future versions could perform more meaningful validation for:

  • IP addressing
  • Prefixes
  • VLAN ranges
  • ASN values
  • Interface formats
  • Required fields
  • Vendor-specific syntax

These are future possibilities, not features currently implemented by the tool.

Try the Network Config Generator

If you regularly prepare repetitive router or switch configurations from spreadsheets, give it a try:

https://dinukawijesinghe.com/tools/config-generator.html

The workflow is:

1. Create a template
2. Add {{VARIABLES}}
3. Load CSV / Excel
4. Validate the data
5. Generate configurations
6. Review the output
7. Export
Enter fullscreen mode Exit fullscreen mode

No installation is required.

Conclusion

Network automation doesn't always have to start with a large platform, API, or complex orchestration system.

Sometimes the first useful automation is simply removing repetitive work that engineers are doing manually every day.

A spreadsheet already contains the data.

A configuration template already contains the logic.

The missing piece is often just a reliable way to combine the two.

That's what I built with the Network Config Generator.

It isn't intended to replace Ansible, NetBox, Git-based configuration management, or a full network automation platform.

It's a small tool for a specific problem:

Take structured network data, apply it to a configuration template, validate the inputs, and generate the repetitive CLI work automatically.

If it saves another network engineer from manually editing the same configuration block 50 times during a maintenance window, then it has done its job.

Top comments (0)