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:
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:
The system requirements for the three VMs that make up the NetEye architecture are as follows: