11. 10. 2021 Giovanni Davide Saccá NetEye, Unified Monitoring

Distributed, Multi-Instance nProbe: NetFlow Analysis

A client with a really large number of routers installed at their client asked me one day to analyze each of those network flows. They hoped that an analysis tool would be able to discover and impose a multitenant configuration all on its own, so that access could be granted to final users while guaranteeing isolation from other users.

The network architecture whose flows were to be analyzed expects sending NetFlow from routers which belong to 2 MPLS rings of two different network providers who deliver the connectivity to the end clients.

The client preferred to base the solution on the nProbe/nTop pair, and the NetEye architecture was used both to distribute the NetFlow data sent from about 1800 routers as well as a repository for the data and its analysis.

The scenario described assumes that no physical devices are to be installed at remote locations in order to reduce configuration and maintenance activities there, and so the choice was aimed at the installation “in D.C.” of a multi-instance nProbe configuration, distributed over several NetEye satellites. This guarantees load balancing between satellites (as far as NetFlow collection is concerned) and dedicated nProbe instance to all locations related to a single client.

A naming convention was created to address this, using a 4-digit ID identifying a client to target all related routers installed at that client’s locations.

Once the binomial between router and customer ID was created, we used the same ID to configure in listen to the dedicated nProbe instance on board on the corresponding NetEye satellite. In this way NetFlow from all routers related to the same customer ID, are then presented by nTop, that centralizes the flow data, and offers a WEB GUI for its analysis..

The diagram shows how NetFlows from the client routers are distributed across the two nProbe probes. Thanks to the multi-instance configuration, the probes can segregate data based on the 4 digit client ID.

nProbe’s multi-instance configuration assumes that:

  • A configuration file for every client ID is available to the nProbe daemon
  • nProbe must be enabled as nprobe@clientID
  • Verification or restart of the nProbe instance always happens along with the @clientID

From the point of view of the design and implementation of the network, if you’d like to configure a unique UDP port where all NetFlows send data, then you need to place a DNAT configuration between the MPLS routers, and the NetEye4 satellites, to redirect the NetFlow from the routers towards the dedicated satellite and dedicated UDP port.

For nTopng instead, this configuration will guarantee every “vista cliente” (identified via the client ID) and see to it that the data is segregated. In this screenshot you can see how the administrator can verify each “vista cliente”:

Regarding login, I’d like to show you an example of how the WEB GUI displays data while guaranteeing a multi-tenant configuration. NetEye assumes you will segregate data on the basis of client ID, setting the following configuration and account profile:

In the previous screen shot from the menu Configuration > Authentication > Users we can add each user for each customer.
In the previous screen shot from the menu Configuration > Authentication > Roles we can assign each user the profile and access rights related to Analytics Data.
With this last screen shot from the menu Configuration > Authentication Roles we can assign each user the profile and access rights related to nTop Data.

The system requirements for the three VMs that make up the NetEye architecture are as follows:

  • 4 CPU @ 3.20 GHz
  • 8GB RAM
  • 100GB HD
Giovanni Davide Saccá

Giovanni Davide Saccá

Hi all, my name is Davide and I was born in San Donato Milanese. Since I was a boy I've always been intrigued by PCs, and so I took my first steps with my Commodore VIC-20. Before joining Würth Phoenix as an SI consultant, I worked first as a Network Engineer for several ISPs (Internet Service Providers) in the late 90s, then for the first ASP (Application Service Provider) and next as a head of IT Network and Security. My various ITIL and Vendor certifications have allowed me to be able to cooperate at multiple project levels. I like tennis, music, motorcycles and going on nature walks with my family.

Author

Giovanni Davide Saccá

Hi all, my name is Davide and I was born in San Donato Milanese. Since I was a boy I've always been intrigued by PCs, and so I took my first steps with my Commodore VIC-20. Before joining Würth Phoenix as an SI consultant, I worked first as a Network Engineer for several ISPs (Internet Service Providers) in the late 90s, then for the first ASP (Application Service Provider) and next as a head of IT Network and Security. My various ITIL and Vendor certifications have allowed me to be able to cooperate at multiple project levels. I like tennis, music, motorcycles and going on nature walks with my family.

Leave a Reply

Your email address will not be published.

Archive