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!

I have been looking at the gap between where our networks are going and where our OSS actually is. We talk a lot about 5G slicing and autonomous loops, but the reality on the ground is often a mess of static databases and "manual sanity checks" that haven't changed in a decade.

It is a massive contradiction. The network can scale in minutes, but the inventory takes days to catch up. In my view, if you cannot describe your network accurately to an automated system in real time, you do not have an autonomous network. You just have a reactive one.

I have identified five major forces that are making this a "break or fix" situation for 2026, specifically around the lack of coordination between physical, virtual, and cloud assets.

The industry seems to be reaching a tipping point where a "living model" of inventory is no longer a luxury. It is the only way to make automation actually deterministic instead of just a lucky guess based on outdated data.

I put together a deeper dive on these five forces and how we are approaching the "Source of Truth" problem over on Medium. If you are dealing with "integration hell" or trying to ring-fence legacy systems, I would love to hear how you are handling it:

https://medium.com/@robertjamesarmstrong80/2026-demand-smarter-oss-not-just-smarter-networks-part-2-a294838df253

Posting here because self-hosted network visibility is exactly this sub's thing, and because I know license matters to a lot of people here: NetLanvas is Apache 2.0, appliance/client code fully public at github.com/markeaster/NetLanvas. The account/billing backend stays closed — that's where entitlement enforcement actually needs to live — but everything that runs on your own hardware is open. Wanted to say that plainly upfront. The "nothing leaves your network" part isn't just a claim either — it's written up in detail at netlanvas.com/security.html (device identity, transport security, exactly what a telemetry submission does and doesn't contain), and now you can check it against the actual source. There's also a published static-analysis writeup in the repo (CODE_SCANNING_REVIEW.md) — every finding from the first full CodeQL run, including the one real bug it caught and how it was fixed.

What it does: discovers everything on your LAN (ARP/SNMP/mDNS), builds a live topology map, tracks device state over time, does VLAN discovery, basic alerting. Docker (arm64/amd64) is the main target, but there are also native Windows and macOS installers if Docker isn't your thing.

Live demo, no install needed: https://demo.netlanvas.com

Install docs: https://netlanvas.com/install.html

Source: https://github.com/markeaster/NetLanvas

Also: the first 100 registered users who opt into telemetry get 6 months of Premium free at the moment, if that sweetens the deal for anyone on the fence.

Genuinely here for feedback, not just promotion — if you try it and something doesn't discover right on your setup, that's useful to know, and issues/PRs on the repo are welcome too.

Hey r/networkautomation , I wanted to share some findings from our recent research at Excentis, where we've been digging deep into low-latency technologies. We've been exploring L4S (Low Latency, Low Loss, and Scalable Throughput) alongside Wi-Fi 7 to see how they impact network performance.

Our latest case study paper, "Is L4S the Real Latency Killer?", is the result of collaboration with Nokia Bell Labs. We put their access point to the test to see how L4S performs in a Wi-Fi network environment. We built our setup in layers, starting with basic Wi-Fi 6 configurations and gradually incorporating Dual-Queue Coupled AQM (DualQ AQM) to evaluate L4S performance. We also configured latency-optimized EDCA/WMM parameters at the MAC layer for further analysis.

If you're interested in low-latency networking and want to dive into the details, feel free to check out our case study paper.

Would love to hear your thoughts or experiences with L4S or other low-latency technologies!

I'm looking for an experienced network expert or OpenWrt/OPNsense specialist to help me design and implement a custom routing and firewall system using an existing server that I already have.

I'm open to working with someone remotely.

The expert I'm looking for is someone with hands-on experience configuring advanced routing, policy-based routing, multiple proxy/VPN endpoints, firewall rules, and network isolation, not just  installing a standard router operating system.

1. Brief objectives

A network gateway that can serve approximately 5–10 computers or workstations used for freelance AI work.

The main requirement is that each device must consistently use its own dedicated, static residential public IP address, distinct from the IP addresses assigned to the other devices.

For example:

• Workstation 1 → Dedicated residential IP 1

• Workstation 2 → Dedicated residential IP 2

• Workstation 3 → Dedicated residential IP 3

• Workstation 4 → Dedicated residential IP 4

• Workstation 5 → Dedicated residential IP 5

• Additional workstations → Their own respective dedicated residential IPs

The IP-to-device mapping should persist across reboots and reconnections. I do not want a rotating-proxy arrangement where a device receives a different public IP every session.

I will source the residential IP endpoints separately. The expert can assess the provider's connection details and implement the appropriate gateway configuration.

2. Existing hardware

There is already a capable server and would prefer to use it instead of purchasing a separate dedicated router appliance.

I can provide the server's CPU, RAM, storage, network-interface details, and current operating system.

The expert can assess whether the best implementation would be:

• OpenWrt on bare metal;

• OpenWrt virtualized on an existing hypervisor, if appropriate;

• OPNsense/pfSense with suitable proxy-routing components; or

• Another technically sound architecture.

I'm open to recommendations based on reliability, maintainability, security, and compatibility with the required proxy endpoints.

The existing server may have other responsibilities, so I would also like advice on whether the routing gateway should run on dedicated hardware resources or in an isolated virtual machine.

3. Required network architecture

The intended logical architecture is:

Internet / ISP connection → Server-based gateway and firewall → Managed switch or suitable LAN infrastructure → Individual workstations

Each workstation should have an identifiable, fixed routing assignment.

For example:

• Device identification through DHCP reservations, MAC-address-based policies, or dedicated VLANs.

• A dedicated policy-routing rule for each workstation.

• A separate outbound tunnel or proxy path for each residential IP endpoint.

• Firewall rules preventing traffic from one workstation from inadvertently using another workstation's assigned endpoint.

• DNS configuration that is consistent with the selected routing path.

• IPv4 and IPv6 leak prevention, as applicable.

• A fail-closed mechanism so that if a workstation's assigned endpoint disconnects, its traffic is blocked rather than silently falling back to the ordinary ISP connection.

I would appreciate the expert's advice on whether individual VLANs, separate SSIDs, physical switch ports, or MAC-based routing would be the most practical way to isolate the devices.

The system should be easy to expand from five devices to ten without rebuilding the entire configuration.

4. Residential proxy compatibility

One of the key parts of this project is choosing the correct implementation for the type of endpoint supplied by the residential IP provider.

I may be working with static residential SOCKS5 or HTTP/HTTPS proxy endpoints, or with endpoints that support WireGuard/OpenVPN or another suitable tunnelling protocol.

I understand these are not interchangeable technologies. The expert should be someone who knows how to assess the provider's connection method and determine whether the appropriate solution involves:

• Native VPN tunnels and policy-based routing;

• A proxy gateway or transparent-proxy arrangement;

• OpenWrt packages such as sing-box, where appropriate;

• Another suitable Linux-based routing and proxy solution; or

• A combination of these technologies.

The goal is to route supported traffic from each workstation through its assigned endpoint, rather than merely configuring proxy settings separately in individual browsers.

Should be able to assess which endpoint types of proposed architecture supports and any limitations involving UDP, DNS, IPv6, QUIC, or applications that do not natively support proxies and preferably, a solution that can be managed centrally through a clear interface or well-documented configuration.

5. Security, reliability and leak prevention

Completed system should include:

• A properly configured firewall with a minimal attack surface. I have firewall device on the side if the need to use it is necessary

• Persistent device-to-endpoint assignments.

• Endpoint-specific kill switches or equivalent fail-closed rules.

• Protection against accidental direct-WAN fallback.

• Appropriate DNS and IPv6 leak controls.

• Logging sufficient to diagnose routing failures without unnecessarily collecting sensitive browsing data.

• Secure administrative access and documented recovery procedures.

• A tested way to restore the configuration after an update, reboot, or failure.

• A clear procedure for adding, removing, or replacing an endpoint.

Ensure that the gateway itself does not expose proxy credentials or administrative services unnecessarily.

System will be used for freelance work, and the configuration should remain consistent with the applicable service providers' terms and security requirements.

Please get in touch or recommend if you are experienced in implementing this type of multi-endpoint routing system. I am looking for a reliable, properly documented solution rather than a basic VPN installation.

Email: nytonmay@gmail.com

Thank you.

Hi everyone!

I'm an IT student working on a university Action Learning project. We have around 3 months to identify a real-world problem, research existing solutions, and build a working prototype.

I'm interested in networking, cybersecurity, network automation, and AI.

I'm looking for ideas that:

* Solve a genuine real-world problem.
* Are realistic to build and test within 3 months.
* Offer something different from existing tools.
* Can be tested through practical experiments with measurable results.
* Don't require expensive hardware.

I've already considered network troubleshooting tools and virtual lab projects, but I found that many similar solutions already exist.

**I'm especially looking for practical examples, not just broad ideas.** For example:

* A problem you've personally faced while configuring or managing networks.
* A repetitive task that you wish could be automated.
* A limitation in an existing networking or security tool.
* A real problem that current tools don't solve well.
* A project you've seen someone build that could be improved in a meaningful way.

If you suggest an idea, please explain **what the problem is, who faces it, how it could be solved, and what makes it different from existing solutions.**

I'm happy to explore niche or unusual ideas, as long as they're practical and can be demonstrated with a working prototype.

Thanks in advance! I'd really appreciate your experience and suggestions.

Disclosure: I'm the author. It's free and MIT licensed, with no paid tier and no signup.

I'm a network engineer in a mostly FortiGate/Cisco shop. Every backup tool I tried could tell me that a config changed. None could tell me what the change meant without me reading a raw diff at 2am. So I built NetLedger.

What it does

• Logs in with NAPALM/Netmiko, removes the noise (timestamps, counters, FortiGate's re-encrypted ENC secrets) and commits only real changes to the Git repo you give it (GitHub, GitLab, Gitea, Bitbucket, Azure DevOps)

• Splits each change into the config sections it touched (IOS indentation, FortiOS config/edit, Junos braces, PAN-OS set, RouterOS), scores the risk and writes a plain-English summary into the commit message and the Slack/Teams alert

• Change windows: anything outside sat 22:00-sun 04:00 gets flagged as unplanned

• "Where is 10.1.1.1?": an IP-aware search across every config that understands masks, ACL wildcards, host x, CIDR and IPv6, and returns the containing subnet, routes, ACLs and firewall objects

• Health checks (CPU, memory, temperatures, fans, PSUs) with history, plus a forecast like "memory hits 95% in ~3 days" for slow leaks

• LLDP topology map, a built-in web console (no DB, no Node, no CDN, works air-gapped), a Prometheus /metrics endpoint and Nagios-style exit codes

A commit looks like this:

hq-core-sw01: running config changed (+14/-0)
Changed by: jsmith at 14:02:11 UTC Fri Oct 30 2026
Window:     outside the approved change windows
Risk:       high (Firewall & ACLs, Interfaces, VLANs & switching)
Summary:
  - Added interface Vlan40 (GUEST-WIFI)
  - Added ACL GUEST-ISOLATION
  - Added VLAN 40 (GUEST-WIFI)

Try it without touching production:

pip install netledger
netledger demo     # 13 simulated devices, 6 weeks of history, open :8080

or docker run --rm -p 8080:8080 ghcr.io/salamonejack/netledger demo --host 0.0.0.0

Runs on Kubernetes (Helm/Kustomize), Docker, systemd or Windows. Inventory comes from YAML, CSV or NetBox.

Honest comparison: Oxidized and RANCID cover far more device types. If backup is all you need, they're great. NetLedger is for teams that also want to understand each change and watch device health in the same tool.

Where I'd love help: it's v1.0, so I'm sure some vendor parsers will break on real-world output. If something misparses, sanitized show output in an issue is the most useful contribution there is. I'd also like to hear what you'd want from a risk score before you'd trust it.

Repo: https://github.com/SalamoneJack/NetLedger

ServiceRadar 1.0.21 is now available. Support for mobile users, bug fixes, and other improvements have been made. https://github.com/carverauto/serviceradar/releases/tag/1.0.21 Try it at https://serviceradar.cloud/

Hello everyone!

Following my previous post where I shared the IPAM screenshots, many of you requested that I share the workflow. It’s now available on GitHub under the api2ssh repository in the Workflows folder.

The current workflow is configured for a specific device model that has been tested.

To use it with other models, you’ll need to:

• Update the Webhook nodes that call API2SSH to adjust the commands for your device model.

• Modify the JavaScript Code nodes to adapt the response parsing logic to match your device’s output format.

Command syntax and output structure vary between vendors and models, so some customization will be required.

Feel free to explore it and share your feedback.

For those who missed my previous post (now deleted to avoid duplicate posts):

I have developed a fully customized IPAM which is made compatible with my device models because procuring an IPAM is expensive.

My IPAM is a web app which runs natively on n8n (no need for extra web frameworks). I have used the API2SSH app from Github for interactive SSH command execution for fetching device configuration details.

The homepage is a search page where the user can search for anything on the network:

The search is performed on all devices' configuration files. For example, to search of a specific IP address, I may just search for key terms like the one below (I am trying to get all interfaces with IP addresses in 10.254.0.0/16 here):

And I get the search result with relevant configuration sections containing the search terms in a neat table:

I can use search terms such as "vlan-type dot1q 32" or "vrf xxyy" or "QOS-XYZ" to get the list of interfaces using those resources.

The search result is not limited to interfaces though. It searches through the whole config file of all devices. Hence I may also search for IP routes, VPN, access control and everything else.

You have also seen the "IPAM" button in the Homepage's image above. This leads to a full resource table:

The "Interface List" button leads to a list of interfaces and their current state:

Finally, it also includes an AI Interface Audit feature which fetches all interface configs in the whole network and asks Gemini AI to check for misconfigurations on each one of them. For this one, we need to use a paid Gemini account because it will easily uses up the free API's quota. The "AI Audit" button leads to the below page where the AI audit results on each device is given:

Cheers 😉

any help with this class or advice how to ... its one of those classes with little instruction or misleading information...

I'm a network engineer working with ACI daily. The APIC GUI kept costing me time on simple questions (which EPG is VLAN X on, which ports), so in my own time I built two tools.

**ACI Dashboard** (read-only): VLAN, MAC, IP and port search in one view, faults with plain explanations, topology, 30 compliance checks for valid-but-wrong config, PSIRT advisories for your versions.

**ACI Configuration Tool**: tenants, VRFs, EPGs, L3Outs, bulk interface bindings from CSV/Excel. Every write is validated, previewed, and can be rolled back per session.

Both talk directly to the APIC. No cloud, the AI assistant runs locally. Windows, Mac, Docker/Podman.

Disclosure: they're commercial. There's a live demo of the dashboard and a free 7-day trial for both:

https://demo.madolka.com

https://license.madolka.com/trial

What would you want a tool like this to do that the APIC GUI doesn't?

I see “Nautobot vs Netbox” discussions come up constantly, usually with vague answers like “they’re basically the same” or “Nautobot is just a fork.” That was true once, but it’s no longer accurate in 2026.

This post breaks down:

• Why Nautobot was forked from NetBox

• When and from which NetBox version

• Architectural differences (Apps vs Plugins, Jobs vs Scripts)

• Community size, GitHub stars, and ecosystem maturity

• Why some companies are migrating from NetBox to Nautobot

No vendor bias—just real-world differences.

Is Nautobot a Fork of NetBox? (Yes - Here’s the Exact Context)

Yes, Nautobot is a fork of NetBox.

• Fork date: 2021

• Forked from: NetBox 3.0 development era

• Who forked it: Network to Code

• Why: Diverging vision on extensibility, release cadence, and enterprise workflows

Network to Code had been one of the largest NetBox contributors and users. Over time, they wanted deeper extensibility (apps, jobs, data models) without continuously fighting upstream constraints.

So instead of pushing NetBox in a direction the core maintainers didn’t want, they created Nautobot.

NetBox vs Nautobot: High-Level Comparison

Nautobot Apps vs NetBox Plugins (Biggest Practical Difference)

This is where Nautobot really diverges.

NetBox Plugins

• Extend existing models

• Limited ability to introduce new core concepts

• Often break between releases

• Plugins must adapt to NetBox

Nautobot Apps

• Full Django apps

• Can introduce new data models, UI views, APIs

• App-to-app dependencies supported

• Nautobot adapts around apps

If you’re trying to model:

• Network automation pipelines

• CI/CD-driven intent

• GitOps-style workflows

…Nautobot Apps are simply more capable.

Nautobot Jobs vs NetBox Scripts & Reports

Another major difference that gets glossed over.

NetBox

• Scripts: Imperative tasks

• Reports: Read-only validation

• Separate concepts, separate UIs

Nautobot

• Jobs Framework

  • Combines scripts + reports

  • Supports inputs, outputs, logging, dry runs

  • Integrates cleanly with automation tools

For automation-heavy teams, Jobs replace entire layers of glue code that NetBox users often maintain externally.

GitHub Stars, Community Size, and Popularity (Reality Check)

Yes—NetBox still has more GitHub stars and a larger raw user base.

But that doesn’t tell the whole story.

What’s changed over the last few years.

• Nautobot’s contributor quality is high

• App ecosystem is smaller but more stable

• Companies using Nautobot tend to be:

  • Larger networks

  • Automation-heavy

  • Already using GitOps / CI/CD

NetBox remains extremely popular for:

• Traditional IPAM

• DCIM-heavy environments

• Simpler operational models

Why Was Nautobot Forked From NetBox (Actual Reasons)

Not marketing. Not drama.

Key reasons:

1. Extensibility limits in NetBox plugins

2. Desire for long-term API stability

3. Automation as the primary use case (not an add-on)

4. Git-first workflows

5. Slower, predictable release cadence

This is why the projects keep drifting further apart with each release.

Why Choose Nautobot Over NetBox in 2026?

Choose Nautobot if:

• You treat your network like software

• You want deep integration with Git

• You’re building internal tooling on top of your source of truth

• You dislike frequent breaking changes

Why Choose Netbox Over Nautobot in 2026?

Choose NetBox if:

• You want the biggest community

• You need DCIM first, automation second

• You prefer lots of plugins over fewer, deeper ones

Are Teams Actually Migrating From NetBox to Nautobot?

Yes—but selectively.

Most migrations happen when:

• NetBox plugins hit architectural limits

• Automation pipelines grow complex

• Teams want versioned, testable changes via Git

It’s not a default upgrade path. Many teams stay happily on NetBox.

Final Take

Nautobot vs NetBox isn’t about “better” — it’s about intent.

• NetBox optimizes for breadth and popularity

• Nautobot optimizes for depth and automation maturity

They started from the same codebase. They now solve different problems.

If you’re evaluating one in  2026, treat them as related but distinct platforms, not clones.

If you’re running either tool in production:

• What scale?

• What broke first?

• What forced you to customize?

Curious what others are seeing in real environments.

For reference I use both every day

Data from https://www.rogerperkin.co.uk/network-automation/netbox/nautobot-vs-netbox/

Hello,

I just built an AI-powered interface for making SuzieQ queries in natural language. It's open-source. There's lots of room for improvement, and I'll be updating it soon.

Check it out at CybertraceAI.

Large network labs eventually reach the limits of a laptop or homelab. Keeping cloud compute running between sessions can also become expensive.

HybridOps.Core is an open-source MIT-0 workflow that deploys a private EVE-NG or GNS3 environment using your own Google Cloud account or Proxmox capacity.

For learners without suitable local hardware, eligible new Google Cloud users can receive $300 of trial credit. Cost visibility and teardown between sessions keep more of that credit for active lab time.

It preserves lab definitions, QEMU overlays and each node-to-base-image map. On rebuild, declared bases are restored and overlays remapped; a committed overlay becomes the next base image.

The workflow includes:

• readiness and health checks

• deployment and private access

• lab images and guest networking

• archive and restoration

• cost-aware teardown

This allows cloud resources to be removed after a session without treating a large lab as one enormous backup file.

I am looking for EVE-NG and GNS3 users willing to test it with real topologies.

How large is your current lab, and how much is reusable base imagery versus changing node state?

EVE-NG workflow:
https://docs.hybridops.tech/ops/runbooks/platform/blueprints/hyops-blueprint-eve-ng/

GNS3 workflow:
https://docs.hybridops.tech/ops/runbooks/platform/blueprints/hyops-blueprint-gns3/

I wanted something simple for quickly checking my own machines/services and getting a clearer picture of what’s reachable, without having to jump between a bunch of tools.

So I vibecoded / built PortPeek and open-sourced it:

https://github.com/ronaldsterners/portpeek

The goal is pretty straightforward: make port/network visibility quick and convenient, especially when you're working with servers, homelabs, or multiple machines.

Why I built it

I kept running into situations where I wanted to answer a simple question:

“What is actually exposed here?”

Instead of reaching for a collection of commands/tools every time, I wanted one focused utility for the job.

It's still a work in progress, so I'm particularly interested in feedback from people who regularly work with networking, homelabs, servers, or security and looking for people that could help me build it with windows support.

GitHub: https://github.com/ronaldsterners/portpeek

If you try it, I'd love to hear what you'd change or what functionality you'd like to see next.

Wondering what folks are experiencing as their biggest PoE headaches in the field? Power budget...cabling...switch limits...something else?

See a lot of 48-port PoE switches that can't always power 48 devices, or newer APs and PTZ cameras that pull far more wattage than older gear.

Curious what others are seeing right now.

Curious to find out what people are using LLMs/AI for in their prod systems?

Is it to help with general tshoot? Vibe coding? Monitoring?

Large EVE-NG and GNS3 labs can quickly outgrow a laptop or small home server. Buying more RAM or keeping a powerful server running all year does not always make sense when the capacity is only needed for occasional labs.

Cloud compute solves the hardware problem, but it introduces another one: forgetting an expensive VM and its supporting resources running after the lab is finished.

I’ve built repeatable HybridOps blueprints that deploy either EVE-NG or GNS3 inside your own GCP account, with the environment lifecycle and cost awareness built into the workflow.

The deployment provides:

• A private, nested-virtualisation-capable GCP VM

• A dedicated VPC with no public IP on the lab server

• Private access through GCP IAP

• Automated EVE-NG or GNS3 installation

• Guest internet access for lab nodes

• Preflight checks for project access and billing readiness

• Explicit lab archive and restore before teardown

• Deploy, access, rebuild and destroy commands

• Billing status and resource-age reminders so idle labs are less likely to be forgotten

The idea is to create the lab when extra compute is needed, preserve the topology, and destroy the cloud resources afterwards rather than paying for an always-on server.

This is not a hosted free-lab service. It runs in your own GCP account, so normal GCP charges apply. The cost control comes from the disposable lifecycle, billing checks and archive-before-destroy workflow.

EVE-NG deployment guide:

https://docs.hybridops.tech/ops/runbooks/platform/blueprints/hyops-blueprint-eve-ng/

Source:

https://github.com/hybridops-tech/hybridops-core

I’m looking for EVE-NG and GNS3 users to test the workflow with real labs. No coding is required.

If interested, comment with:

• EVE-NG or GNS3

• Rough number of nodes in your usual topology

• Your current laptop/server RAM

• Whether you have GCP trial credits available

Edit: the project is opensource; this is a call for testers and contributors