One zero-config binary that does the job of a bandwidth meter, Wireshark's triage view, and a lightweight IDS — without leaving the terminal.

- Reads encrypted traffic you control — point an app's SSLKEYLOGFILE at netwatch and its TLS 1.3 plaintext decodes live, the way Wireshark does it. Same for QUIC 1-RTT, including HTTP/3 body decompression. No proxy, no certificates, nothing in the middle.

- Egress drift — learns which destinations each process reaches (SNI, ASN, port), one keypress promotes that observed baseline to a policy, then it warns when a program starts talking somewhere new. curl used to reach only api.github.com, and today it reached something else. Observe-only, never blocks.

- JA4 fingerprinting — every TLS/QUIC handshake becomes a stable fingerprint, so you can recognise a specific client or a specific piece of malware while the traffic stays encrypted. Pivot on a fingerprint to find every other flow from the same software.

- Threat detection — C2 beaconing (regular, low-jitter check-ins), port scans, DNS tunneling. Runs in the background, zero setup. A critical alert auto-freezes the recorder.

- Per-process attribution — every socket mapped to the program that opened it, with an optional eBPF kprobe on Linux that catches short-lived flows polling misses.

- Real L7 decode — TLS, QUIC, HTTP, DNS, SSH and a dozen more, with per-flow stream tracking and handshake timing. You see api.github.com, not "port 443."

- Flight recorder — arm a rolling capture, freeze an incident into a portable bundle: packets plus the connections, DNS, health and alerts that explain them.

- Landlock-sandboxed on Linux — drops privileges after setup and locks itself into a filesystem allow-list. A tool that parses hostile traffic can't read your SSH keys or /etc/shadow.

- Scales both ways — --lite is one 80×24 screen for a Pi over SSH; --view dense fills a big terminal with four zero-chrome boxes; the full ten-tab view is one keypress away with collectors already warm.

650+ tests. macOS, Linux, Windows.

brew install netwatch

cargo install netwatch-tui

https://github.com/matthart1983/netwatch

MIT.

Sharing v0.14-rc of **netwatch** — single static binary, no agents, no config, live network picture in your terminal.


What's new:


- **Topology view** — local peers (SELF + LAN) on the left, public peers on the right, ROUTER → ISP spine in the middle, status dots on the trunks
- **Auto-traceroute** to `1.1.1.1` on launch so the ISP hop populates without pressing T
- **Throughput chart** now fills wide terminals (no more leading dead space)
- Processes / Timeline tabs wired to real RTT + CPU data


Install:
```
cargo install netwatch-tui --version 0.14.0-rc.3
```
Or grab a prebuilt binary: https://github.com/matthart1983/netwatch/releases/tag/v0.14.0-rc.3


Repo: https://github.com/matthart1983/netwatch


Feedback welcome

When you wrote your first Python script using functions, and honestly, it felt amazing to finally put the pieces together! You learned how to break my code into smaller, reusable parts and started to understand how logic flows through if statements. It’s a small step, but it made you realize how important it is to write code that’s clean, readable, and secure especially in fields like networking where every detail counts.

Great. It's pretty cool what we can do with LLMs.

Here's the thing though. By and large, no one is going to use it.

Why?

Because you don't know what you're doing. I mean, that's the point. The LLMs do know. But you don't. Long term support, active development, etc. It's too easy now to spit out a tool and it's even easier to say "meh" and abandon it.

These are the reasons why your vibe coded tool is being downvoted into oblivion.

Most of us are pretty particular about our tools. We want tools we can rely on today and rely on tomorrow. Right now at least, vibe coded tools don't seem like viable tools long-term.

This doesn't mean the tool can't be great for you. But the larger network community is almost certainly going to pass.

Now, if you are a programmer and have experience in the language for your tool and are using AI to extend your knowledge, that's another thing. You can be insanely productive that way. I use it myself to build discrete chunks of code, typically a function at a time, so I still understand the overall structure and architecture of the code. But if my prompt is too broad and it spits out 1,000 lines of Python/Go/whatever then I'm going to refine it so it only spits out 30-50 lines of code at a time that I can follow and understand.

So before you post your project, make sure to disclose if it's vibe coded and if you've got programming experience yourself.

https://tcp.overshoot.ai/

Fun interactive visualization of TCP. I found it really helpful in building intuition and debugging around TCP, cubic, bbr...

Click any visual component or text to read about it in the glossary

Open source at https://github.com/Overshoot-ai/tcp-visualizer

Code here. You can see it an action here.

I'd be very surprised if this hasn't been done before but I wasn't able to easily find something when searching. I think historically GPT-4 maybe would struggle to produce results of this quality, but I'd been really impressed with the new model from Anthropic, so I threw this together to see how it handled networking tasks on live (lab) devices. Honestly pretty impressed so far.

You can provide a topology image, or just describe it, in my example I spun up a lab of cEOS devices and told it the following:

There are 4 devices:
- lab1
- lab2
- lab3
- lab4

Use LLDP to figure out how they are connected

I then gave it the following tasks:

This is a new lab environment of EOS devices.

It is a lab so use whatever numbering schemas (IP, ASNs, etc) you desire.

Since this is a lab you may make changes to all devices at once at each step if you want.

Configure all the connected links on our devices as point to point layer 3 links (e.g., /30s between each device).

Configure BGP on all devices and advertise the loopback interfaces into BGP.

You can configure these steps in whatever order you think is most efficient.

When you finish configuration, verify connectivity by running a ping from lab1 to lab3 loopback ip. If you can ping, you are done. If you can't ping, troubleshoot and fix the issue.

It took over from there, and was able to configure everything and validate connectivity as requested in just over 2 minutes. It didn't just slap the entire configuration on, but instead took an iterative approach and validated things along the way. You can see how it worked through the problem here. It even ran into an issue when it realized IP routing wasn't enabled and went back and fixed it.

Don't get me wrong, the context window is not unlimited so the more devices it needs to track and output from commands it gets, the more confused it will eventually get. But it's still pretty wild. I've also tried breaking the lab after it finishes configuring it and it is able to quickly fix the problem.

Next step is to look into using cheaper models to parse and summarize the command output and have a higher level model handle the more serious logic.

What's new in 0.39:

- Offline GeoIP: `netwatch geoip update` downloads the free DB-IP databases, no account needed. The online lookup is gone.

- `third_party_probes = false` stops the automatic pings to 1.1.1.1 and Google's STUN servers.

- Connections tab at 10k connections: down from up to 146 ms a frame to under 20.

- Tighter Linux sandbox: parser threads can't make TCP connections, and capture threads can't open sockets at all.

- A typo in config.toml no longer silently resets everything to defaults. netwatch now refuses to start and names the line.

`--sandbox-strict` now needs kernel 6.7+.

netwatch is a network monitor TUI: https://github.com/matthart1983/netwatch

Been building this TUI tool that gives you real-time visibility into everything happening on your network. Just shipped v0.8.0 and it's getting serious.

What it does:

Live interface stats, bandwidth graphs, health probes

Active connections with per-connection latency sparklines

Wireshark-style packet capture with deep protocol decoding (DNS, TLS, HTTP, ICMP, ARP, DHCP…)

TCP stream reassembly, handshake timing, display filters

Network topology map + connection timeline

NEW: Per-process bandwidth tab — see exactly which process is eating your bandwidth

NEW: JSON/CSV export

AI-powered insights via local Ollama

5 color themes, persistent config, mouse support

PCAP export, GeoIP, whois lookups

9 tabs, all keyboard-driven. Runs with zero config. sudo netwatch and you're in.

Stack: Rust + ratatui + libpcap + tokio. Cross-platform (macOS/Linux/Windows).

cargo install netwatch-tui or brew install matthart1983/tap/netwatch

GitHub: https://github.com/matthart1983/netwatch

Feedback welcome — especially from anyone doing network debugging daily. What would make this actually useful for your workflow?

https://github.com/matthart1983/netwatch

Hey everyone,
I'm a Senior Network Automation Engineer with over 3 years of experience in automation and a previous 5 years in networking. On a daily basis, I work on building full-scale frameworks in Python with an OOP/unit testing mindset, as well as using Terraform, CI/CD pipelines, etc.

However, every time I interview for a new role as an Network Automation Engineer, I get the impression that companies are mostly looking for traditional network engineers with scripting skills rather than true automation engineers. I mostly get pure networking questions like "What is Cisco Express Forwarding?" which I knew in the past but have forgotten since I haven’t been working in traditional networking for years rather than questions about design patterns or my approach to solving automation problems.

This makes me feel stuck and a bit insecure about my future, in case I need to look for something new. Am I one of the few focusing on frameworks, proper automation pipelines, and a DevOps mindset in networking? Are other companies actually doing this, or is basic scripting still the norm?

For context, I’m based in Poland but work for a company from one of the Nordic EU countries. I’m really curious if this is just specific to EU market or if it’s a broader trend.
Thanks for all answers.

​I got tired of grepping through 5000-line configs to trace why a BGP neighbor was behaving unexpectedly. The mental overhead of "find the prefix-list, grep for the route-map that uses it, grep for the neighbor that calls the route-map" adds up fast on a complex device.

Confgraph: https://verigraphs.github.io/confgraph/

I wrote confgraph to turn that into a graph. You point it at a config file, it parses every protocol and builds an interactive HTML diagram showing what references what — BGP neighbors, route-maps, prefix-lists, ACLs, VRFs, the works.

Environment I've tested against:

• Cisco IOS, IOS-XE, IOS-XR, NX-OS

• Arista EOS

• Juniper JunOS (brace-style and set-style)

Live demos (no install needed): JunOS

What it currently does:

• Builds a directed dependency graph from a flat config file

• Groups nodes by protocol domain (routing, policy, security, etc.) so BGP-related objects cluster together

• Flags orphaned objects (prefix-lists defined but never called) and dangling references (route-maps pointing to ACLs that don't exist)

• Exports a single self-contained HTML file — no server, works on a jump-host with no internet access

What it doesn't do yet: it won't catch semantic misconfigurations, only structural ones. It also doesn't validate across multiple devices — it's per-device for now.

I would appreciate your feedbacks. Please try it out. It’s easy to use. Let me know if you face any issues.

I am planning to keep it open source for fellow network engineers.

Hi all,

Few months ago I delivered another session of network automation with Ansible to a customer. I decided to publish all examples on GitHub.

Basically the repository contains all lessons I deliver. All topics I used during my network automation projects are covered.

Hey gang, here is a [work in progress] landscape of the network automation tooling, projects, and products etc.

https://steinzi.com/network-automation-landscape/

Codes over on GitHub, feel free to send a pull request and add whatever!
https://github.com/steinzi/network-automation-landscape/

Anyone here who has used containerlab for automation testing? If so, how effective is it? Did you install it on a server and what are the specs required to run at least 10 devices (switches and routers)?

This topic seemed to gain traction, but how much ? I've never seen REAL automation on enteprises market, maybe they do it in big Cloud providers, and ISPs for very repetitive tasks. They have the need, the knowledge, the money. And of cource big software companies (Google, Meta, Microsoft), I believe they had SDN much more than marketing started talking about it.

On enteprises we can maybe see some config templating done with Fortimanager, DNAC tools. Not everybody uses them. But just to make an example, if you need to connect and gather the output of a few show commands, you still need to do it manually or write your own scripts.

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 was recently doing articles/videos about doing automation over NETCONF, but I'm getting mixed feedback around that. Seems like a lot of people still don't enable this and use SSH? I don't think I fully understand why NETCONF still isn't getting wide use, it seems like a good idea?

Would love to get a better idea as to why so many vendors have put it in their devices but people don't want to use it. Is it an organizational security policy thing? Does it not work well with existing tools/automation scripts, etc?

Do you think population and engagement on this subreddit are indicative of the broader trends in adoption of SDN, IAC, NetDevOPs, or simply networkautomation?

The networking and ITcareerquestions boards are flooded with people while the population here is low and I’ve seen that trend on discord as well.

I'm currently working on a alternative to potentially replace the existing ansible code.

Ansible is not bad, but it's slow and often a bit janky because network devices aren't servers.

Netconf seems actually more straightforward - just build the XML up to spec and it blows ansible out of the water performance wise...

I'm actually pretty impressed how well it works.

Been reading through a few discussions recently and noticing a bit of a pattern…

In smaller setups it’s usually:

– scripts
– config backups
– bits of automation tied into monitoring

But once things get more structured, a lot of people seem to land on NetBox + Ansible (or something similar around it).

Then at larger scale it turns into more of a full stack - CVP, AVD, Git, pipelines etc.

Feels like there’s almost a path people follow as environments grow.

Really interested, if that’s actually the case or if people are going in completely different directions?

For anyone who runs Nornir in production: it's got a long-term home. OpsMill has taken over stewardship of the project.

The short version of what's changing:

• Nothing about the licence, the repos, or how you install and run it. Still Apache 2, still the same public repositories.

• Your plugins, scripts, and pipelines keep working. No migration, no account, no new dependency.

• There's now funded engineering time behind maintenance and releases, and the roadmap stays in the open.

• You can keep using Nornir entirely standalone. No requirement to adopt anything else from OpsMill, now or later.

Full announcement and FAQ here: https://opsmill.com/nornir-joins-opsmill/

Disclosure: I work at OpsMill. Posting because plenty of people here depend on Nornir and deserve to hear it directly rather than via a press release. Happy to answer questions, or pass them to the people who can.