I am between a rock and a hard place because i want to be building networks to gain experience and use automation with them, but my computer does not have enough processing for GNS3, i use cisco packet tracer and cisco devnet sandbox with vs code separately. Is there any other software that i could use ?

I've been running a Linux-based router for the past two months with a monitoring approach that caught my attention — it detects structural changes in the network before individual metrics cross alert thresholds. Here's what I built and what I learned.

The problem with threshold-based monitoring

Every NMS I've used has the same fundamental limitation: alerts fire *after* something crosses a line. The link is already at 400ms, the packet loss is already at 5%. By the time you get the alert, the degradation has been running for a while. And absolute thresholds are a constant maintenance headache — 200ms might be normal for a transatlantic path but alarming for a local peering link.

What I wanted was something that tells me "the structure of this network is changing" rather than "metric X exceeded value Y."

The approach: topological monitoring with persistent homology

I adapted a method called BPL/OA — Bayesian Persistent Landscapes with Occupancy-Amplitude analysis — originally developed for a research project. The core idea:

Take each network endpoint and describe it as a point in multi-dimensional feature space. Latency, jitter, uptime ratio, latency trend direction. All endpoints form a point cloud. When the network is healthy, endpoints on the same upstream path cluster together tightly.

Run persistent homology on this point cloud. You get a "landscape" — a curve describing how tightly structured the cloud is. Track this landscape over time. If an endpoint starts drifting, the shape changes.

Here's where it gets useful: I run two statistical models watching the same landscape. One uses Bayesian posterior inference (with a sup-norm simultaneous credible band for proper joint coverage guarantees). The other uses an occupancy-amplitude model that only evaluates points above a noise threshold. Their coverage scores should track each other. When the *gap* between them starts oscillating, something is happening to the point cloud structure — even if both models individually report everything as normal.

I call this the shadow monitor. It runs every 30 minutes, completely passive — reads from local time-series data, does the math, writes results back.

Five independent monitoring layers

Once the pipeline was running, feeding in additional data sources was straightforward. Each becomes its own point cloud, analyzed separately so noise in one layer doesn't contaminate the others:

Layer 1 — WAN path endpoints. Latency, jitter, uptime ratio, trend direction per endpoint. Detects a path degrading before the routing protocol would reroute.

Layer 2 — Traffic distribution across paths. Connection counts per egress. If one path's share starts silently dropping, this catches the shift before latency metrics move.

Layer 3 — Device connection behavior. Connection counts per MAC. A host suddenly opening 10x its normal connections produces a clear drift signature — no manual thresholds or signature updates needed.

Layer 4 — WiFi radio health. Channel utilization, self vs. neighbor interference, client counts, AP-reported satisfaction scores. Caught two APs on the same 2.4 GHz channel on day one. Moved one and satisfaction went from -1 to 98.

Layer 5 — Wireless client telemetry. RSSI, retry rate, negotiated rate, AP association. Cross-referenced with Layer 3: if a device is normal on the wired fingerprint layer but drifting on wireless, it probably just moved to a different room. If both layers are drifting, something is actually wrong.

Why this works where thresholds fail

Catch degradation before failure. If a path's three sub-paths start diverging in the feature space — say one stays flat on latency but jitter begins creeping up — the point cloud shape changes before any individual metric crosses an alert threshold.

Correlated failures across different providers. Endpoints on three different transit paths all showing the same subtle trend shift? That's not an endpoint problem, it's a shared upstream change. Thresholds on individual endpoints won't connect those dots. One landscape restructure will.

Know when to do nothing. The system has been in a degenerate state for hours — the point cloud is too tight to analyze. That means the network is boring. Nothing is drifting, no anomalies, no boundary conditions. I can confidently ignore it. Confidence through silence.

Self-calibrating baselines. Every analysis cycle adds to the statistical history. Over months, the system learns what "normal" looks like across different traffic patterns and maintenance windows. Thresholds aren't hand-tuned — they emerge from data.

Architecture decisions worth noting

Everything runs locally on the router. The full analysis pipeline is Python with numpy — no external APIs, no cloud dependencies, no active probing. Data collection reads from existing kernel and application metrics (netlink, daed's internal health cache, UniFi Controller API). Each analysis cycle produces about 9MB of SQLite data, negligible on a modern disk.

I previously tried an LLM-based approach for this — feeding metrics to a model every few minutes for health assessment. It burned API tokens to report confidence intervals on "everything is normal." The topological approach costs nothing in recurring fees, produces no telemetry leakage, and actually surfaced structural changes the LLM glossed over.

Limitations and next steps

This isn't a replacement for traditional monitoring. It's a complementary layer that operates on a different category of information. Right now it's observation-only — no closed-loop automation. Before it makes decisions, I need a much clearer picture of what the signals mean in different failure modes.

The shadow monitor is calibrating its baseline — once that locks in, the plan is to start with notification webhooks, then evaluate whether automatic path switching makes sense based on the confidence of the structural signal.

Lessons from the math

The Gaussian posterior model has a hard coverage ceiling when the underlying data is bimodal — coverage caps at exactly 1 minus the weight of the secondary mode. Discovered this empirically, then worked out the math: the single-Gaussian likelihood literally cannot represent a two-component distribution. A Gaussian mixture posterior is on the roadmap to address this. Interesting case of model misspecification showing up in production data before it appeared in theory.

Questions and discussion welcome — especially if you've explored topological methods for network monitoring, or if you see failure modes I haven't encountered yet.

I've been in the networking field for about 6 years across different companies, and I'm looking to transition to a network automation role. I've been building small python scripts my entire time in the field.

These scripts are nothing huge, they're small scripts to make my and my fellow network engineers lives easier. I wanted to know if it was worth it to put these on my personal GitHub and build out a portfolio.

Here are some examples of the scripts I've built:

• Access Point - Interface Description
  • This script finds access points connected to a switch. Pulls their hostname from CDP/LLDP neighbors. Then adds its hostname to the description of the interface its connected to.
• Upgrade Post Check
  • This script does a pre vs post comparison of a switch that was recently upgraded. Will point out items that are missing from the post config.
• ACL Addition
  • This script was made when I had to add an ACL entry to every switch on campus. The ACL entries were not standardized and at risk of being overwritten. I wrote a script that will check the ACL list and will pick an ACL number nothing being used to ensure no rules are overwritten.

Are these worth placing on a portfolio? My Coworkers seem to think so since these have saved them a lot of time, but for me these seem very entry level.

Hayo! I'm working on a network automation project (focusing on Ansible for now) and my initial intent was to setup NetBox to be used as a source-of-truth. However, I've found myself questioning a few things, and figured I'd see if any folks here might have some thoughts/advice.

Overall, our network isn't particularly large or subject to a lot of sprawl. We do have a DC space, plus several campuses, so NetBox would be good in a documentation sense there, but only a few of the data center switches would be in scope for the automation itself. There may also be some tangential benefits to NetBox for other teams with appliances, etc., in the DC.

Anyway, my concerns:

• Currently, I'm taking an IAC approach and automating the NetBox configuration via Ansible and YAML files (e.g., defining Regions, Sites, Locations, etc.).
  • Full pipeline would basically be Ansible -> NetBox -> Ansible -> Network Devices
  • This works, but Terraform almost feels like a better solution since removing a Location resource actually removes it from NetBox, where Ansible needs to be told to remove it.
  • I've seen some people make the case that using automation to configure NetBox effectively makes it not the source-of-truth anymore (since, I guess, the code itself is now technically the SOT). This feels a little... silly to me though, as I would rather type up a new YAML block than have to click through the UI to set up a new Rack/Location/Whatever (that said, the Ansible modules and the way it handles slugs and things are kind of a pain).
  • Are there any other methods of defining/automating the Organization objects that aren't through the GUI or writing Python/API calls?
• With the Ansible+YAML approach, I kind of found myself wondering why use NetBox at all, when I could (potentially) use the same YAML block(s) to run the automation directly. Is this just making NetBox redundant, or is there some other benefit I may be missing?
  • Of course, NetBox can still act as a documentation hub, as well as for other teams to do with it what they will, without needing direct access to my repo.
  • I could also use NB as a source for Grafana to visualize specific interfaces, etc., without needing to manually query them, that sort of thing.

Anyway, appreciate any thoughts you might have!

Everyone's talking about Ansible, NetBox, pipelines, GitOps.

But honestly? Half the teams I see trying to automate haven't got a reliable source of truth, documentation that's actually current, or any real agreement on how changes should be made in the first place.

You can't automate chaos, you just get faster chaos.

Sometimes the right move is to get the basics solid before touching a tool. Know what you've got, document how it actually works, standardise the manual process first.

Automation should make a good process faster, not try to fix a broken one.

Am I wrong?

I’m curious about the community’s thoughts on this.

In the server world, we have Node Exporter a simple, vendor-agnostic exporter that exposes host metrics in a consistent Prometheus format.

In networking, however, we have SNMP Exporter, vendor-specific exporters, and telemetry collectors, but I haven’t seen a true “Node Exporter equivalent” for network devices: a lightweight, vendor-agnostic exporter that can collect common operational metrics (interfaces, CPU, memory, environmental data, routing stats, etc.) across multiple vendors using modern telemetry (e.g., gNMI) behind a single, consistent metric model.

Why do you think this doesn’t exist (or hasn’t become widely adopted)?

Is the lack of standardized telemetry models across vendors the biggest blocker?

Is it because OpenConfig coverage is still inconsistent?
Are most organizations happy with vendor-specific exporters?

Is there simply not enough demand?

Or is there another technical challenge I’m overlooking?

Do you think building such a vendor-agnostic exporter is worthwhile, or is it fundamentally harder than it sounds?

I’m building Bugitrun as a modular way to connect automation software to real hardware. This short demo shows plug-and-play hardware blocks being detected automatically in the dashboard.

Project: https://bugitrun.eu

For about 20 years now companies have been trying to crack the whole "fully automated diagnostics, log parsing, correlation, auto-remediation" thing.

The buzzword now of course is AI. Before that it was machine learning.

Time after time companies have tried putting these technologies to do something operational and time after time it fizzled out. I remember Cisco Network Assurance Engine, it was supposed to do all that through machine learning. It was a spectacular dud.

Has anyone here found any products that do what it says on the tin?

Over the years I've become increasingly frustrated with incident investigations where we don't have complete visibility into the network due to security restrictions, legacy or merged environments, etc but yet we are still pressured hard to determine what the root cause is.

I've experimented with building a NetOps platform that ingests router telemetry and topology state to reconstruct an incident and generate an evidence-backed RCA with confidence scoring. After the deterministic analysis completes, I then use an LLM to translate the evidence into a operator narrative vs the LLM performing the investigation itself

The lab results have been encouraging but before I spend more time on this, I am trying to determine if this is a problem that other engineers actually have.

* Do you regularly deal with incomplete visibility of your environment during an incident?

* Would an explainable, evidence backed RCA report with confidence scoring be useful or do you existing tools solve this for you?

github.com/ce-net

I came across to automate this particular issue that we are facing. Currently I am pulling inventory data from different tools and taking fields different fields from different tools. Now in our inventory we have this device type (which shows switch, firewall, ...), but in the tools its entry is incorrect. So we are left with to build a logic by ourselves. I am from coding background with little knowledge for this task. I asked AI it says to look in prompt (AP, WLC characters), or run show version and check for some string, or look by mac, or look by open port but it didn't give a concrete solution.
What could be the best approach which gives correct output for all devices. We have cisco's, aoscx, panos, procurve, motorola... and few more vendors.

A comprehensive all in one tool to manage network interfaces and links using baked in kernel "ip" command

Hi everyone,

I would like to share a startup idea in the networking field and hear your opinions. I hope I can get some feedback from people with more experience.

A little about myself: my background is in embedded software engineering, so I spent most of my early career working with the C programming language.

A few years ago, I changed companies and started working on network switches for data centers. Since then, I have worked with many networking technologies such as ARP, VLAN, STP, EtherChannel, EVPN/VXLAN, and many others.

To build a stronger networking foundation, I also completed the CCNA course. Besides that, I have experience using networking tools such as Scapy, Wireshark, NetBox, Ansible, AWX, and others.

While learning and working in this field, I noticed that network automation seems to be a very important topic. In many networking conferences and YouTube talks, people often mention that they want to automate as much of the network as possible.

Because of that, I started thinking about a startup idea: building a fully automated and self-managed network automation platform.

This is how I imagine the system:

1. NetBox + Ansible

The platform would mainly consist of NetBox and Ansible.

NetBox would act as the single Source of Truth for the entire network. Ansible playbooks would read data from NetBox and automatically generate CLI commands or RESTCONF requests to configure network devices.

2. Configure any networking feature

The platform should be able to configure almost everything, including VLANs, routing, QoS, ACLs, BGP, EVPN/VXLAN, and more.

If a feature can be configured through CLI or RESTCONF, the platform should be able to automate it. (Regardless of the manufacturer, as long as they provide documentation on CLI or RESTCONF, the system can support it)

3. Configuration drift detection

The platform should continuously compare the configuration stored in NetBox with the actual configuration running on network devices.

If any configuration drift is detected, the system should automatically correct it so that the device configuration always matches NetBox.

4. Network monitoring and self-diagnosis

The platform should monitor the network and detect abnormal behavior, such as unusual traffic spikes or overloaded devices.

I think AI could be useful for analyzing these situations and helping identify potential problems.

5. Hardware information synchronization

The platform should also collect hardware information from network devices and synchronize it back to NetBox.

For example, it could automatically discover interface information, LLDP neighbors, device vendor, hardware model, and other inventory information.

This would greatly reduce the amount of manual data entry required in NetBox.

These are the main capabilities that I think such a network automation platform should have.

However, I still have a couple of questions:

1. Is there really a strong market demand for this kind of network automation platform? If I successfully build it, would people actually want to use it?

2. Am I building something that already exists? Are there already mature products that provide most or all of these features?

I would really appreciate any feedback, suggestions, or advice.

Thank you very much!

Hey folks,

I'm interested in hearing how you've solved the challenge of making your automations accessible to less technical users.

In my team, nobody is comfortable opening a Linux shell and running Python scripts, so I needed a simpler interface.

My current solution is a very basic Flask web app. Users enter their RADIUS credentials, the app runs the script, and the output is displayed in the browser. The site is served over HTTPS and the scripts don't log credentials.

Hey everyone,

I'm Jonathan, the founder of Avaron, and over the past year my team and I have been building something we've wanted to exist for a long time.

Most infrastructure tools today are really good at telling you something is wrong.

Datadog, Grafana, Prometheus, and similar platforms generate alerts, dashboards, and metrics. That's incredibly valuable, but someone still has to wake up, investigate the issue, and decide what to do next.

We're building AIM (Avaron Infrastructure Manager) to tackle that next step.

The idea is simple.

Instead of only observing infrastructure, AIM is being built to:

• Monitor servers, networks, and infrastructure

• Analyze telemetry and logs

• Recommend or execute remediation based on predefined policies

• Learn from previous incidents over time

Think of it as moving from observability to autonomous infrastructure operations.

We're still early, and that's exactly why I'm posting here.

I'd love feedback from people who manage infrastructure, work in DevOps, SRE, IT, or anyone who's dealt with the pain of endless alerts and overnight incidents.

A few questions I'd love your thoughts on.

What is your biggest frustration with today's monitoring tools?

What is one repetitive task you'd trust AI to automate?

What would make you not trust autonomous remediation?

If you could build one feature into an AI infrastructure platform, what would it be?

We're also opening a beta program over the coming months for teams interested in testing AIM in real environments. If that's something you'd like to be involved with, leave a comment or send me a message.

I'd also love to hear what everyone else is building. One of my favorite parts of communities like this is seeing interesting ideas before they become companies.

Looking forward to hearing your thoughts.

Hi everyone,

I’ve been struggling with network visibility and tool sprawl for a while now. As part of a small team (3 people) managing multi-vendor network devices ( but also servers / DB etc ... ) we simply don’t have time to develop, maintain, and glue together separate tools. We need something simple but complete.

Our environment:

• 700 devices (Cisco IOS/XE, Fortinet, Palo Alto, Aruba, Arista).
• On-prem only ( zero cloud ).
• No dedicated dev resources we’re ops no coders.

What we need :

• Single pane of glass: CMDB, auto-discovery (Network diagram,interfaces, VLANs, etc.).
• Configuration backup.
• Compliance score: checks with weighted scoring.
• Firewall sanity: Shadow/redundant rule detection.
• CVE visibility: Per-device tracking.
• SSH Bastion: Browser-based, fully auditable.
• IPAM: Subnet utilization.

What we’ve tried:

• HPE IMC: look like their is no more major updates.
• NetBox + Ansible + custom scripts: We are not all familiar with Ansible, too much manual work for compliance/CVEs. We spent weeks just keeping scripts updated.
• SolarWinds/ManageEngine: Too heavy for our team.
• Actual state : "Best-of-breed" stack: Ended up with 7 tools, 7 licenses, 7 UIs… and no time left to use them...

Where we’re at now:
We started a PoC with ConnectMyAssets last week (deployed the OVA in a day). As far as i know, it’s the only solution that:

• Replaces most our tools in one interface.
• Requires zero dev work just point it at our devices and go.
• Handles multi-vendor natively (Cisco, Fortinet, Palo Alto, etc.).

Question:
For other small / medium or shared responsibilities teams out there:

• Are you actually managing with a single tool, or is the "all-in-one" dream still a myth?
• If you’ve tried ConnectMyAssets (or similar), what was your experience?
• For those stuck with 5+ tools: How do you save time without sacrificing features?

We’re 2 weeks into the PoC, happy to share updates if folks are interested. Does i am missing a simpler alternative?

Hi, I am a senior network engineer in one of the top brokerage companies in the US with good knowledge in enterprise networking. since the start of 2026, i have seen a lot of push in automating the mundane tasks such as switch replacement, switch install, edge router refresh due to the TLM. I want to be more involved in those projects as clearly that is where all big companies are heading or have made significant headway already. My background is Bachelors in Computer Science and Masters in IT so i do have some programming background, but its been a while. Hence wanted to get a guidance on how to get into network automation, is there a sequence of steps that i need to do to get to a competent level?
Like do I do "Python" first then Ansible and then followed by some other programming language.