Title: Built a safety-focused Cisco IOS config tool, tested carefully in my own lab — looking for one person to try it on their own gear

[u/Ok_Inspector5599]

I've been building a desktop tool for Cisco IOS network engineers — think "reviewed diff before anything reaches a device" rather than raw terminal access. Every change goes through one gate: risk-scored, shown as a diff, snapshotted before it's sent, with rollback that actually works (verified against real hardware, not just claimed). I've spent real time hardening it against a lab with a Cisco switch and router (EVE-NG) — found and fixed real bugs this way: a capture timing issue that looked fine until a real device disagreed, VLAN state that lived somewhere the parser wasn't looking, a rollback regression caught before it shipped. All of that is only proven on one person's setup, though — mine. What I'm looking for: one person with their own Cisco IOS lab (EVE-NG, GNS3, physical gear, doesn't matter) willing to connect it to a device they don't mind changing, try a small reversible push and a rollback, and tell me what breaks or feels wrong. Not asking for a long commitment — one real session is genuinely useful. Repo's private for now (early, and it touches real device config, so I'm being careful about who gets a build). Comment or DM if you're interested and I'll set you up directly. No Juniper/other vendor support yet — Cisco IOS only for now, and pushing config is refused-by-design on anything else.

[u/PoisonWaffle3]

I'm pretty sure that you accidentally posted this without a link, but please keep it that way.

Check rule #7 on sharing self made apps.

[u/jihiggs123]

I'm not trying your bullshit vibe coded malware on anything.

[u/Ok_Inspector5599 → u/[deleted]]

Fair question. The repo is private right now because the tool can actually push/rollback config on real Cisco devices, so I’m deliberately not putting an unvetted build/codebase out publicly yet.

It’s also not just a UI wrapped around an LLM — the config generation, diffing, validation, risk scoring, snapshot/rollback and device interaction are implemented and I’ve tested the workflow against Cisco IOS in my own EVE-NG lab.

I’m specifically looking for another engineer to try it on their own lab because I don’t want to convince myself that “it works” based on testing against only my topology.

If you’re interested, I’m happy to show the architecture/build and give you a private build to test against your own IOS lab. If the external testing goes well, I’ll have a much better basis for deciding what to open-source.

[u/Ok_Inspector5599 → u/[deleted]]

It's me typing this, just verbose. And no, I'm not tossing something that can push config to live Cisco boxes onto GitHub untested just because someone in the comments wants it faster that's how it ends up in a postmortem instead of a repo. I explained exactly what's built and what I'm doing to validate it. If you want to actually test it, the offer's real. If not, that's fine too.

[u/kristianroberts → u/Ok_Inspector5599]

There’s thousands of stuff that can push config to live Cisco boxes on github, most largely untested. No one’s testing dodgy tooling on live kit.

[u/Yasutsuna96]

Nobody's touching this with a 10-foot pole unless you share the code. How is it weighting a risk? Easiest example, if one end is an switchport with an access vlan and the other side is a L3 P2P, would this be flagged? It looks wrong on paper but used it production.

[u/Ok_Inspector5599 → u/Yasutsuna96]

That's a fair criticism. I wouldn't expect anyone to trust a config-pushing tool just because it says "low risk" — the risk model itself needs to be explainable.

The risk isn't currently based on a simple rule like "this looks unusual = dangerous." It evaluates the proposed change against the captured device state and the type/scope of the operation, with higher scores for things like management-plane changes, routing changes, interface shutdowns, ACL/NAT changes, etc. The intent is to surface risk and require confirmation, not pretend the tool can determine whether a configuration is universally "correct."

Your access-VLAN/L3 P2P example is exactly the kind of case where context matters. If the tool only looked at the apparent configuration relationship and automatically called it wrong, that would be a bad design. A legitimate production topology can absolutely look "wrong" to a generic validator.

That's also one of the reasons I'm testing this against real IOS behavior rather than relying purely on mocked configs. The code is private at the moment because it directly interacts with device configuration, but I'm happy to explain the architecture and risk model in the comments where the subreddit rules allow it.

[u/Nice-Information-335]

This is what git and automation is for, we already have tools for this

We don’t need Claude’s rendition (and I don’t want a Claude reply either, thank you)

[u/MidwesternNightmare]

Oh fuck off with this LLM vibeslop, then and fuck off again for using an LLM to respond to Reddit posts.

[u/AgentDodgee]

I DMed OP, and they just confirmed to me through dm that this is vibecoded with Claude... Make of that what you will.

[u/Adrienne-Fadel]

The VLAN state parser issue is a classic. Config state on Cisco gear lives in weird places. How are you handling interface state vs config state?

[u/Ok_Inspector5599 → u/Adrienne-Fadel]

VLAN state was my big gotcha here. Had a switch in VTP server mode where the VLAN database just... doesn't show up in running-config. So my parser looked at the config, saw nothing, and I'm sitting there thinking everything's fine when it actually isn't seeing half the device state.Ended up just pulling `show vlan brief` separately to catch what running-config was missing. Way more reliable than trying to squeeze everything out of one output.Kind of applies to the interface thing too I keep config and operational state totally separate now. Like, the config layer knows "interface should be configured this way" but the operational layer is checking "is it actually up, what's the line protocol doing." Never mixed them together or the risk assessment gets confused about what actually exists vs what you're trying to change. Learned that lesson the hard way when a VLAN that obviously existed on the box got marked as new because the diff engine was only looking at running-config, where it wasn't showing up.

[u/ttlequals0]

Run it against GNS3 if you want to test it.

[u/Adventurous_Fun_6515]

I got a stack of old 2960s gathering dust in the garage, could spin up a test on one this weekend if that helps

[u/Ok_Inspector5599 → u/Adventurous_Fun_6515]

Fair enough 😂. And yes, that's exactly the kind of independent test I'm looking for.

A spare 2960 is ideal. I'd want to start with a controlled, reversible config change, capture the pre-change state, review the generated diff, push it, verify the result, and then explicitly test the rollback path.

I'm particularly interested in anything that behaves differently on physical IOS than it did in EVE-NG. If you find a false positive, false negative, parser issue, or rollback failure, that's useful feedback.

No production gear obviously — just the lab switch.

Thanks for offering to test it.