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

Dinuka Wijesinghe — Sat, 08 Aug 2026 12:49:57 +0000

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

interface TenGigE0/0/0/1
 description CUSTOMER-A
 ip address 10.10.1.1 255.255.255.252
 vrf CUSTOMER-A
 no shutdown

Then:

hostname PE-002

interface TenGigE0/0/0/1
 description CUSTOMER-B
 ip address 10.10.2.1 255.255.255.252
 vrf CUSTOMER-B
 no shutdown

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

create one reusable template:

interface {{INTERFACE}}
 description {{DESCRIPTION}}
 ip address {{IP}} {{MASK}}
 vrf {{VRF}}

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

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

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}}

while an interface template could use:

interface {{INTERFACE}}
 description {{DESCRIPTION}}
 ip address {{IP}} {{MASK}}

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

The important relationship is:

Spreadsheet column
       |
       v
  {{VARIABLE}}
       |
       v
Configuration template

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}}

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

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

Generate Selected

Sometimes you don't want to generate everything.

You may only be working on:

PE-017
PE-018
PE-021
PE-025

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

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

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

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

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

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

Cisco IOS-XR

interface TenGigE{{INTERFACE}}
 description {{DESCRIPTION}}
 ipv4 address {{IP}} {{MASK}}
 no shutdown

Juniper JunOS

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

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

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}}

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

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

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

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:

Your template
Your input data

It does not understand your actual network topology.

For example, it doesn't know whether:

10.10.10.1/30

is actually the correct address for a particular interface.

It doesn't know whether:

Te0/0/0/7

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

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

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

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.

DEV Community: Dinuka Wijesinghe

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

The Problem: Manual Network Configuration Doesn't Scale

The Idea Behind the Tool

How the Network Config Generator Works

Template-Based Configuration

CSV/Excel as the Source of Truth

Validation Before Generation

Generate Configurations at Scale

Generate All

Generate Selected

A Practical Example

Template

Input Data

Generated Configuration

Vendor Independence

Cisco IOS-XE

Cisco IOS-XR

Juniper JunOS

Real Network Engineering Use Cases

PE Router Provisioning

Access Switch Configuration

VLAN Deployment

BGP Neighbor Provisioning

VRF Provisioning

NNI Configuration

Customer Migration

Network Expansion

Architecture

Security and Data Privacy

Performance

Exporting the Result

Copy to Clipboard

TXT

Excel

ZIP

Why I Built This

Limitations

Future Improvements

Device Connectivity

Pre-Check / Post-Check Automation

Configuration Diff

Ansible Integration

NetBox Integration

Git-Based Configuration Management

CI/CD Workflows

More Advanced Validation

Try the Network Config Generator

Conclusion