1.3. Deployment

1.3. Deployment
	Chapter 1. Introduction

This section discusses the possibilities of deploying nLive in a single location versus deploying nLive enterprise-wide. It also discusses configurations for monitoring selected VLANs or selected switches. Deploying nLive sensors for packet traffic and netflow are discussed as well.

nLive has a distributed architecture that has one or more sensors and a central console. These sensors and console are software components. A sensor has the ability to receive packets from up to three Ethernet interfaces. A sensor also has the capability to receive netflow packets from a large number of routers or switches. Whether these capabilities are enabled or disabled in a sensor depends on your product edition and license. An nLive Console monitors one or more sensors and creates reports from them. It serves as the sole user interface to all the sensors in the installation. A console neither receives netflow nor analyzes packets. All editions of nLive except the Enterprise edition comes with one sensor and one console packaged together. In the Enterprise edition, one has the choice of installing consoles and sensors separately on different hardware or together on the same hardware.

    nLive Core = 1 Console + 1 Sensor packaged together
    nLive Flow = 1 Console + 1 Sensor  packaged together
    nLive Enterprise = 1 Console + 1 or more Sensors

nLive is available as a software-only version or as an appliance on which the software is pre-installed. Please contact the vendor for availability of these options.

1.3.1. nLive Core Deployment

Any edition of nLive Core may be installed in a network as a single hardware appliance or a single software installation on a PC comprising of both Sensor and Console as shown in Figure 1.1, “Deployment of nLive Core”. This is suitable for a minimal installation at one site to monitor a small network or a small section of a large network. Port mirroring is to be enabled on the switch by using commands such as 'SPAN'.

Figure 1.1. Deployment of nLive Core

nLive Core may be installed at the core switch to monitor traffic on certain VLANs by mirroring these VLANs into one or more ports on the core switch. This will capture all traffic in these VLANs that cross the core switch. Typical applications of this kind of deployment include monitoring user area VLANs or server area VLANs. User area VLANs may need monitoring because they are potential sources of network traffic problems such as abuse by users or presence of malware activities. Server area VLANs may need monitoring to keep track of unusual access to sensitive data and applications hosted on servers. An example of this type of deployment is given in Figure 1.2, “Deployment of nLive Core at Core of Network”. Your switch vendor needs to provide the command that will mirror packets from certain VLANs into a core switch. In the case of Cisco equipment, the command is 'RSPAN'.

Figure 1.2. Deployment of nLive Core at Core of Network

1.3.2. nLive Flow Deployment

Any edition of nLive Flow may be installed in a network as a single hardware appliance or a single software installation on a PC comprising of a Sensor and a Console as shown in Figure 1.3, “Deployment of nLive Flow”, Figure 1.4, “Alternate deployment of nLive Flow”, and Figure 1.5, “Yet another deployment topology of nLive Flow”. This is suitable for an installation to monitor netflow exports from one or more routers in a small network. It is not advisable to export netflow across WAN links since it can consume significant bandwidth. Instead, use nLive Enterprise with a sensor for each geographic location or office.

Figure 1.3. Deployment of nLive Flow

Figure 1.4. Alternate deployment of nLive Flow

Figure 1.5. Yet another deployment topology of nLive Flow

1.3.3. nLive Enterprise Deployment

nLive Enterprise supports multiple sensors. It can be installed as a distributed system as shown in Figure 1.6, “Typical deployment of nLive Enterprise”, Figure 1.7, “Alternate deployment of nLive Enterprise” or Figure 1.8, “Yet another deployment of nLive Enterprise” where each sensor monitors certain segments, VLANs or routers in the network. In this figure, we have shown an nLive Console and Sensor installed at headquarters and sensors installed at remote sites. nLive Enterprise can be configured to monitor both netflow and packet analysis on one or more sensors. This allows hybrid installations where netflow and packet traffic from different segments can be monitored simultaneously using nLive Enterprise. Alternately, one can deploy a netflow-only nLive Enterprise setup or packet-traffic-only setup. The configuration in the figure shows monitoring of netflow as well as packet traffic. Netflow from several routers can be received at each sensor. Packet traffic from up to three mirror ports can also be received at each sensor. The system may spread across continents in multiple time zones. The communication among the Sensors and Console is kept to a minimum, so it can be distributed across corporate WAN having limited bandwidth. This is possible due to the fact that nLive maintains its traffic databases in each sensor in a de-centralized fashion, and sends only the relevant data to the Console upon request from the graphical user interface or the report building engine. Sensors do not stream detailed traffic data or netflow to the console.

Figure 1.6. Typical deployment of nLive Enterprise

Figure 1.7. Alternate deployment of nLive Enterprise

Figure 1.8. Yet another deployment of nLive Enterprise

Within a large network, nLive Enterprise sensors may be deployed at the access or distribution levels by mirroring traffic locally on each switch into a local port. This kind of mirroring is also suitable for selective monitoring of the network on specific problem areas such as potential sources of problems (user areas) and potential targets of problems (server and database areas).

Sensors for unconventional network segments

If the network has different segments which may have very different statistical behaviors, such as a testing lab for IP network-based products or a media streaming facility, then it is advised that one uses separate sensors to monitor these segments. This is to ensure that there is minimal 'cross-talk' between the statistical models created of the network traffic behaviors. If the same sensor is used to monitor these and more conventional network segments, then the behavior models created in the sensors may not be as accurate. This may result in reduced sensitivity to problems in the network traffic resulting in higher incidents of false positives and negatives.


1.2. Overview		Chapter 2. Installation