User Guide Functional Overview Requirements Architecture System Installation NetEye Additional Components Installation Setup The neteye Command Director NetEye Self Monitoring Tornado Business Service Monitoring IT Operation Analytics - Telemetry Geo Maps NagVis Audit Log Shutdown Manager Reporting ntopng Visual Monitoring with Alyvix Elastic Stack IT Operations (Command Orchestrator) Asset Management Service Level Management Cyber Threat Intelligence - SATAYO NetEye.Cloud Solution Monitoring Business Service Monitoring Asset Management SOC System Administrator SOC Attacker Centric Cyber Threat Intelligence - SATAYO NetEye Update & Upgrade Backup and Restore How To NetEye Extension Packs Troubleshooting Security Policy Glossary
module icon Requirements
Requirements for a Node Cluster Requirements and Best Practices Kubernetes Networking NetEye Satellite Requirements TCP and UDP Ports Requirements Additional Software Installation
Functional Overview Requirements Architecture System Installation NetEye Additional Components Installation Setup The neteye Command Introduction to NetEye Monitoring Business Service Monitoring IT Operation Analytics Visualization Network Visibility Log Management & Security Orchestrated Datacenter Shutdown Application Performance Monitoring User Experience Service Management Service Level Management & Reporting Requirements for a Node Cluster Requirements and Best Practices Kubernetes Networking NetEye Satellite Requirements TCP and UDP Ports Requirements Additional Software Installation Introduction Single Node Cluster Kubernetes NetEye Master Master-Satellite Architecture Underlying Operating System Acquiring NetEye ISO Image Installing ISO Image Single Nodes and Satellites Cluster Nodes Configuration of Tenants Satellite Nodes Only Nodes behind a Proxy Additional NetEye Components Satellites Nodes only Verify if a module is running correctly Accessing the New Module Cluster Satellite Security Backup and Restore Identity and Access Management External Identity Providers Configure federated LDAP/AD Emergency Reset of Keycloak Configuration Keycloak Hostname Configuration Advanced Configuration Roles Single Page Application in NetEye Module Permissions and Single Sign On Within NetEye Importing User Federation Groups inside another Group Importing OIDC IdP Groups inside another Group Resource Tuning Advanced Topics Basic Concepts & Usage Advanced Topics Monitoring Environment Templates Monitored Objects Import Monitored Objects Data Fields Deployment Icinga 2 Agents Configuration Baskets Dashboard Monitoring Status Integration with Elasticsearch VMD Permissions Notifications Jobs API Configuring Icinga Monitoring Retention Policy NetEye Self Monitoring Concepts Collecting Events Add a Filter Node WHERE Conditions Iterating over Event fields Retrieving Payload of an Event Extract Variables Create a Rule Tornado Actions Test your Configuration Export and Import Configuration Example Under the hood Development Retry Strategy Configuration Thread Pool Configuration API Reference Configure a new Business Process Create your first Business Process Node Importing Processes Operators The ITOA Module Configuring User Permissions Telegraf Metrics in NetEye Telegraf Configuration Telegraf on Monitored Hosts Visualizing Dashboards Customizing Grafana The NetEye Geo Map Visualizer Map Viewer Configuring Geo Maps NagVis Audit Log Overview Shutdown Manager user Shutdown Manager GUI Shutdown Commands Advanced Topics Overview User Role Management Cube Use Cases ntopng and NetEye Integration Permissions Retention Advanced Topics Overview User Roles Install Alyvix Core Install Alyvix Service Nodes RDP Client Building Tools Editor: Interface Overview Editor: Script Building Editor: Managing Scripts Designer: Interface Overview Designer: Interface Options Designer: Component Tree Selector: Interface Overview Test Case Management Dashboard Use Cases Overview Architecture Authorization Kibana Elasticsearch Cluster Elasticsearch Configuration Replicas on a Single Node Elasticsearch Performance tuning Overview Enabling El Proxy Sending custom logs to El Proxy Configuration files Commands Elasticsearch Templates and Retentions El Proxy DLQ Blockchain Verification Handling Blockchain Corruptions El Proxy Metrics El Proxy Security El Proxy REST Endpoints Agents Logstash Rsyslog Elastic APM Elastic RUM Multitenant OpenTelemetry Collector Elastic XDR Overview Authorization in the Command Orchestrator Module Configuring CLI Commands Executing Commands Overview Permissions Installation Plugins Single Tenancy Multitenancy Communication through a Satellite Asset collection methods Display asset information in monitoring host page Overview Customers Availability Event Adjustment Outages Resource Advanced Topics Introduction The Intelligence We Produce Mitre Attack Coverage Getting Started Settings SATAYO Items Intelligence Requirements Managed Service Request Form FAQ Changelog SATAYO Community NetEye.Cloud as a SaaS solution NetEye.Cloud Subscription Base Concepts Authentication Options Authentication via IdP Group Claims for Authorization Management Authentication via Microsoft Entra ID Authorization Navigating the UI Monitoring with NetEye.Cloud Monitored Objects Finding and Filtering Hosts Exporting Monitoring Data Viewing Host and Service Details Organizing with Groups Tactical Overview Problems View Dashboard Typical Daily Interactions Scheduled Downtime Notifications and Alerts VMD Business Service Monitoring Business Process Logic Business Process View Asset Management in NetEye.Cloud Automatic Inventory Collection Software & License Management Contract & Supplier Management Change & Lifecycle Management SOC System Administrator (AdS) Access to NetEye and Elastic Elastic Dashboards Elastic Discover Elastic Alerts Elastic Rules Introduction to SOC Attacker Centric Service Description NetEye SIEM About SATAYO Threat Intelligence and Security Operations How SATAYO works MITRE ATT&CK Coverage Dashboard SATAYO Findings SATAYO REST API SaaS & Managed Mode Before you start Update Procedure Single Node Upgrade from 4.49 to 4.50 Cluster Upgrade from 4.49 to 4.50 Satellite Upgrade from 4.49 to 4.50 DPO machine Upgrade from 4.49 to 4.50 Create a mirror of the RPM repository Sprint Releases Feature Troubleshooting Backup and Restore Tornado Networking Service Management - Incident Response IT Operation Analytics - Telemetry Identity Provider (IdP) Configuration NetEye Cluster on Microsoft Azure NetEye Cluster on AWS Introduction to NEP Getting Started with NEPs Online Resources Obtaining NEP Insights Available Packages Advanced Topics NEP Updates & Upgrades Setup Configure swappiness Restarting Stopped Services Enable stack traces in web UI How to access standard logs Director does not deploy when services assigned to a host have the same name How to enable/disable debug logging Activate Debug Logging for Tornado Modules/Services do not start Sync Rule fails when trying to recreate Icinga object How to disable InfluxDB query logging Managing an Elasticsearch Cluster with a Full Disk Some logs are not indexed in Elasticsearch Elasticsearch is not functioning properly Reporting: Error when opening a report Debugging Logstash file input filter Bugfix Policy Reporting Vulnerabilities Cyber Resilience Act Compliance Glossary

Kubernetes Networking

Since NetEye leverages Kubernetes for its container orchestration, it is mandatory to ensure that the networking requirements are met.

For a more detailed discussion of the CIDR roles and how they interact with the current NetEye networking architecture, please refer to the Kubernetes Networking Architecture section.

Summary of the Kubernetes networking

When installing NetEye, define three CIDRs in /etc/neteye-environment.yaml. These are Kubernetes address spaces, not three additional physical networks. In particular, defining a CIDR does not create a VLAN, reserve addresses from DHCP, or require the corresponding number of physical switch ports.

Table 2 Kubernetes address spaces

Setting

Default

Purpose

Visible outside the NetEye cluster

pod_cidr

10.42.0.0/16

Addresses assigned to Pods

No

svc_cidr

10.43.0.0/16

Stable, virtual addresses for Kubernetes Services

No

service_loadbalancer_cidr

10.44.0.0/24

Virtual IPs through which selected workloads are reached

Yes, but only from the trusted network zone

The Pod Network is the address space used by application and platform Pods. A Pod receives one address from the per-node portion of pod_cidr for its lifetime. The Service Network is different: a Service IP is a stable virtual frontend. Cilium redirects traffic sent to the Service IP to one of the current Pod backends, so a Service IP is not an address assigned to a physical network interface.

The Service Load Balancer Network is used only for Services that intentionally accept traffic from outside the Kubernetes cluster, such as a Gateway API listener. In a cluster deployment, Cilium assigns a virtual IP from this range and announces it on the selected trusted Layer-2 network. It is the only one of the three ranges that nodes will reach for communication with Kubernetes workloads. All traffic coming from clients are still being proxied through the existing infrastructure (e.g. httpd, nginx, etc.) and then forwarded to the Load Balancer virtual IPs.

Note

No switch, VLAN, DHCP, or router configuration is required for the Pod or Service CIDR. They are logical cluster address spaces managed on the nodes. The existing external-network configuration therefore remains unchanged for Pod and Service traffic. It is not necessary to create a separate VLAN for the Pod or Service CIDR because those ranges are not routed outside the cluster.

Choosing the CIDRs

Users can choose any private CIDR (RFC 1918) for the three required ranges. It is recommended to choose ranges that do not overlap with any other network intended to be reachable from the NetEye installation. This is because routing table entries for the Pod and Service CIDRs are automatically added to the nodes, so any traffic sent to those ranges will be routed to the Kubernetes workloads.

Note

If future connectivity requires to route traffic between the NetEye installation and a client which happens to be in the same Pod or Service CIDR, you could exploit Satellites to monitor those hosts in the overlapping range.

For particular usecases, where no CIDRs are available, it is possible to use some of the IPv4 reserved ranges which are explicitly prohibited for routing on the public Internet, such as the one specified in the RFC 6598 (Carrier-Grade NAT, defined to be 100.64.0.0/10). However, this is not recommended and should be avoided if possible as these ranges are not intended for general use and may cause issues with certain applications and services, or could be requalified for public use in the future.

CIDR reuse and overlap with other kubernetes clusters

Pod and Service ranges can be reused by separate Kubernetes clusters as VXLAN encapsulation ensures that the traffic is isolated. However, the Service Load Balancer range must be unique and do not overlap a network reachable from either cluster. This is common for isolated sites because these three ranges do not need to be globally routable.

Sizing the CIDRs

Kubernetes network CIDRs cannot be enlarged after installation. Increasing an undersized range requires recreating the Kubernetes cluster and migrating its workloads and configuration. This is a disruptive, time-consuming operation; choose the CIDRs carefully before installation. If you are unsure about the size of the CIDRs or your environment is expected to grow, and your IPAM situation allows it, choose a larger range than you think you will need.

Choosing the Pod CIDR

Choose the Pod CIDR primarily according to the maximum number of Kubernetes nodes the cluster may contain, including spare capacity for future expansion. Kubernetes allocates a separate \24 portion of the Pod CIDR to each node, so adding nodes consumes additional address space even when the current number of Pods is low.

Choose a range with sufficient growth headroom. If the Pod CIDR is exhausted, a new node cannot obtain a Pod address range and cannot provide Kubernetes workloads.

The following table shows the maximum number of nodes that can be supported by different Pod CIDR sizes:

Table 3 Maximum number of nodes for different Pod CIDR sizes

Pod CIDR size

Maximum number of nodes

/16

256

/17

128

/18

64

/19

32

/20

16

/21

8

/22

4

For example, a 3-node cluster, expecting to grow to 5 nodes in the future, should choose a Pod CIDR of at least /21.

For single node installations, a /24 Pod CIDR is sufficient, even though it is still recommended to use a higher range to allow for future expansion.

Choosing the Service CIDR

About the Service CIDR, choose a range that can accommodate at least 256 Services for smaller installations, and at least 1024 Services for larger installations. Each Service consumes one address from the Service CIDR, so the number of Services is limited only by the size of the Service CIDR.

The following table shows the maximum number of Services that can be supported by different Service CIDR sizes:

Table 4 Maximum number of Services for different Service CIDR sizes

Service CIDR size

Maximum number of Services

/19

8192

/20

4096

/21

2048

/22

1024

/23

512

/24

256

Choosing the Service Load Balancer CIDR

This network is the least demanding in terms of address space. It is used only for Services that intentionally accept traffic from outside the Kubernetes cluster, such as a Gateway API listener. A /24 network is sufficient for most if not all installations, as it can accommodate between 128 different NetEye nodes and 128 different Load Balancer Services. Furthermore, changing the Service Load Balancer CIDR after installation is possible, although not implemented by any NetEye command, requiring manual intervention and careful planning.

Blog Online Demo Training
Contact Us
© 2026, Würth IT Italy s.r.l.
VAT ID 01054690217
Privacy Cookies