Allot Comunications - ACPP_Advanced NX Architecture.pdf

ACPP Technical Training

Advanced Architecture1-1


In this module we will examine the architecture of the NetXplorer system and its different component parts. An understanding of this architecture is a crucial pre-requisite for successful troubleshooting.

By the end of this module you will understand the following:y y g

• How data flows through the system when the user configures devices, creates or edits catalogs and provisions policies

• How traffic statistics data is collected and how reports are generated

• How alarms are defined and stored and how are they triggered

• What are the protocols used for communication between the different NetXplorer components



The NetXplorer architecture is comprised of three layers:

• The DPI & QoS layer – consisting of NetEnforcers and optional Data Collectors. This layer controls and monitors the traffic.

• The Server layer – consisting of a single NetXplorer server This isThe Server layer consisting of a single NetXplorer server. This is used as a single point of management and a central point of storage for traffic statistics.

• The User Interface layer – consisting of the GUI client that can be installed remotely from the server. The user interface is used for viewing statistics, setting provisioning rules and changing configuration settingsconfiguration settings

In this module we will see how different NetXplorer functionality is implemented at each layer and how data flows between the layers.



The NetXplorer GUI client runs on windows machines, and uses Java version 1.6.x, based on “project swing” Java components

The NetXplorer Server runs on a Widows or Linux server and is based on Java 1.6.0, a J2EE application server and a Sybase database pp y



In this section, we will examine the data flow through the NetXplorer when creating or editing catalogs, provisioning policies or configuring NetEnforcers.



Catalog entries are used as building blocks for traffic control policies.

Once defined, Service, Time, ToS, QoS, VLAN, DoS, Quota and Service Plan catalogs will always be global.

This means that they can be used by all of the NetEnforcers in theThis means that they can be used by all of the NetEnforcers in the Network tree.

Host Catalogs are by default defined as global, but you can also limit them to a particular NetEnforcer in the Network.

Sometimes you know that particular hosts will be handled only by one y p y yNetEnforcer.

In these cases it is possible and recommended to limit the host catalog definition of these hosts to the specific NetEnforcer.



1. New catalogs can be created, or changes made to existing catalogs, using the NetXplorer GUI or by using the Server CLI (outlined in Module 7: Server CLI)

2. The catalog changes are written into the NetXplorer database

3. Now lets look at what happens when you are editing or adding a GLOBAL catalog. The update process in this case is A-SYNCHRONOUS. What does this mean?

• If the catalog is successfully written into the NetXplorer database, a counter is updated on the NetXplorer server and a message will be sent back to the GUI showing that the catalog has been saved.

Th N tX l ill th d th t l h t N tE f• The NetXplorer will then send the catalog changes to every NetEnforcerin the Network.

• If a catalog is successfully saved on a NetEnforcer, the NetEnforcercounter is updated and an SNMP trap is sent to the NetXplorer. This event is not recorded in the GUI however.

• In a situation where there is a temporary lack of connectivity between the server and one of the NetEnforcers for example the catalog changethe server and one of the NetEnforcers for example, the catalog change will still be saved on the NetXplorer and the other NetEnforcers. Once connectivity is restored, the NetXplorer will push the policy change to the remaining NetEnforcer.

• Note that you can check whether the global catalog has been updated on a specific NetEnforcer by using the go list host_entry CLI command.



As opposed to catalogs which are shared by many NetEnforcers and are therefore maintained on the server, Policies are NetEnforcer specific. Each NetEnforcer therefore maintains its own policy.



What happens when changes are made to the NetEnforcer’s policy table? As with the process for making changes to local catalogs, the update process here is synchronous, and the user will receive an immediate notification as to whether the change was successful.

1. When a user requests to make changes to the policy, the policy is first loaded from the NetXplorer to the GUI

2. Changes are first sent to the server which performs some initial checks to make sure that the policy request is logical.

3. If these tests are passed, the NetXplorer sends the policy updates to the NetEnforcer using XML formatto the NetEnforcer using XML format.

4. The NetEnforcer validates the commands and performs the changes. In some circumstances, the user’s request may not be allowed. This could be for a number of reasons:

• Different NetEnforcers allow different policy changes.

• Different keys limit the type of policy changesy yp p y g

• Model limitations in terms of pipes and VCs

5. The NetEnforcer sends a pass/fail trap to Server. The trap will be logged in the event log.

6. The server then commits the Policy changes – a counter is updated on the Server and a message is sent to the GUI.



Each NetEnforcer maintains its own configuration information. The configuration settings dataflow is similar to that of the policy definition. The NetXplorer server serves mainly as a mediator between the GUI and the NetEnforcer.



In this section we will examine the data collection process.



To understand the data collection process lets first have a look at the data resolution possibilities available when defining a report.

Long term data can be displayed at a resolution of 1 hour, 1 day or 1 month

Short term data can be displayed at a resolution of 30 seconds, 5 minutes or 1 hour.

As 30 seconds is the smallest resolution to which we can display data, this is also the smallest time span over which we can aggregate data on the NetEnforcer.



The NetEnforcer generates three types of buckets – Rule buckets, Conversation buckets and Service buckets.

Rule buckets (sometimes known as VC buckets) include data that can be used for Statistics, Utilization, Line, Pipe and VC reports. They can also be used for the Pipe popularity and VC popularity reports too The amount ofused for the Pipe popularity and VC popularity reports too. The amount of data in these buckets is limited by policy definitions and can therefore be controlled. Because the amount of data is always limited, there is no chance of it getting ‘out of control’ and reduction is not required. As no reduction is performed on rule buckets, this means that rules data is exact. The user will always obtain exact information from the graphs which are opened based on rules statistics.

Conversation buckets include data that can be used for Protocols, Hosts and Conversation reports. The amount of data in these buckets is not limited by policy definitions. The data here concerns activity on the network, as opposed to classified traffic. These buckets collect data regarding each individual connection on the network. The amount of data here is virtually unlimited and can exceed millions of conversations. For this reason, reduction is performed on this data., p

The third type of buckets are service buckets. These are used for the average protocol popularity graphs, and measure the average number of IPs (or subscribers) generating each type of protocol.

These three buckets are collected every 30 seconds and every 300 seconds.



The statistics manager process on the NetEnforcer aggregates data into buckets every 30 seconds and every 300 seconds (5 minutes). These two processes occur in parallel.

Both the 30 second and the 300 second buckets have three types –ypconversation buckets, rule buckets and service buckets.

The NetEnforcer by default creates 30 buckets into which it aggregates data:

• 15 x 30 sec Buckets (5 x Rule, 5 x Conversation and 5 x Service)

• 15 x 300 sec Buckets (5 x Rule, 5 x Conversation and 5 x Service)

When the 30th bucket is full, the next set of statistics overwrites the first one.



The 5min buckets are imported every 5 minutes and the 30 second buckets every 30 seconds to a short term database.

The short term database can be either on the NetXplorer Server itself, or on a distributed short term monitoring collector. g

The collection is performed by the following processes which are located on the short term collector:

• The Poller process. This is responsible for pulling the data from the NetEnforcers

• The Converter process. This is responsible for performing a bi 2 ii i B k t itt i bi f t thbin2ascii conversion. Buckets are written in binary format on the NetEnforcer. The Converter will convert them to ASCII format to be placed in the database.

• The Loader process. This is responsible for placing the converted records into the short term databases.

The short term database then aggregates the 5 minute samples into 1hr gg g pbuckets.

When real-time monitoring reports are generated, the requested resolution can be either 30 seconds, 5 minutes or 1 hour. As we have seen, these resolutions correspond to the 30 second, 5 minute and 1 hour buckets which are all stored in the short term database.



Once an hour the short term data is imported to the long term database.

The long term database is always located on the NetXplorer Server.

The data is imported by a process called “ltc_poller” that runs on the NetXplorer ServerNetXplorer Server.

A process called “ltc_loader” loads the 1 hr samples into the long term database.

There is no Converter process on the Long Term Collector since the files are already stored in ASCII format.

All data transfer between processes is over TCP Port 80 or TCP 443.p



Lets now see the data flow when a report is requested via the NX GUI

• A user requests a report. The GUI application sends the report parameters to the NetXplorer Server.

• When the request arrives in the NetXplorer server the Logic of theWhen the request arrives in the NetXplorer server, the Logic of the report is analyzed: Is the data Long Term or Short Term? Which database is required? From which NetEnforcers is the data required? The report generation logic functionality is part of the server application and is not a separate process.

• The report request is now passed to a Query Generator which determines the relevant select commands and which databases todetermines the relevant select commands and which databases to query. The Generator will send a query to the specific database requesting the name of the exact table where the information resides.

• Data retrieved from different databases, by the select command, is compiled into a report by the Logic functionality. Once the data is received the “Logic” will assemble the data from the different tables into the requested report formatthe requested report format.



In this section we will examine how alarms are configured and stored, and how they are triggered.



Lets begin with a quick reminder about the NetXplorer alarm definition process. NetXplorer constantly monitors your network and can notify you of any change in normal network behavior, so that you can quickly implement corrective action.

To use alarms, you must go through the following steps:

Firstly, define the alarm itself. Here you set the conditions under which the alarm will be set, as well as its severity.

Secondly, you may wish to define a series of alarm actions. In addition to displaying the alarm in the Alarms log and relevant Events log, you can specify additional action to be taken when an alarm is set This action mayspecify additional action to be taken when an alarm is set. This action may for example be sending an email notification to a user-defined address.

Finally, once alarms and alarm action entries have been defined, they can be associated with a network entity, such as a Pipe or Virtual Channel.

A single alarm entry may be associated with different Pipes or Virtual Channels, and the same or different alarm actions can be assigned to each one.



Where are alarm definitions stored?

The alarm conditions and alarm actions can be assigned to any NetEnforcer. They are therefore stored in a central location - the NetXplorer Server.p

The alarm conditions which are assigned to a specific line, pipe or virtual channel are stored on the relevant NetEnforcer. This way each NetEnforcer only needs to check its data against the alarms which have been associated to it.



The NetEnforcer constantly monitors network traffic and compares its findings to the defined alarms.

When an alarm threshold is reached, the NetEnforcer immediately sends a notification to the NetXplorer server. A user looking at the NetXplorer p g puser interface will see the notification in the alarms or events log. The alarm action, if defined, will also be triggered.

Note: Alarm notification is completely independent of the statistics data collection process.

Alarms are sent from the NetEnforcer as SNMP Traps. Other network monitoring applications that support SNMP can listen for these trapsmonitoring applications that support SNMP can listen for these traps



In the final section of this module, let’s check which are the protocols used for communication between the different components of an Allot solution.



Communication between the NX GUI and the NX Server can take place either over TCP 80 (HTTP), or over TCP 443 (HTTPS).

The NX password cannot be sniffed from outside.

When working with NPP communication between the NPP client and theWhen working with NPP, communication between the NPP client and the server takes place over TCP port 443. If an NPP user tries to browse to http://<NPP server IP>/npp, he will be automatically redirected to https://<NPP server IP>/npp. When the NPP server is installed on a separate machine to the NX server, communication between the two is also over TCP:443.

The transfer of monitoring and reporting data between databases isThe transfer of monitoring and reporting data between databases is performed by XML over HTTP or SSL. Port 80 is used by default. If port 80 is closed between NetXplorer and NetEnforcer, and “Enable SSL Between NetXplorer Server and Device” is checked on the security tab of the NetEnforcer Configuration dialog, then port 443 will be used instead.



Communication between the NetXplorer Server and NetEnforcer for configuration purposes is performed by SNMP over UDP port 161. UDP port 162 is used for sending events from the NetEnforcer to the NetXplorer.

In addition, if statistic MIBs are activated on the NetEnforcer, SNMP traffic statistics may be obtained using an external SNMP management application such as HP Open View. The SNMP application can retrieve this information from the NetEnforcer over UDP port 161.

The SNMP v3 menu gives you further configuration options for the communication of SNMP traps over UDP port 162. The menu is available p pby selecting Network on the network tree and choosing Configuration. Now select the SNMP v3 tab.

The SNMP Device Access parameters include the passphrase for authentication which is a fundamental part of SNMP v3. Leave these fields alone.

In some cases if the NX server has dual NICS you may wish to assignIn some cases, if the NX server has dual NICS, you may wish to assign two separate IP addresses to the same NetXplorer. For example, you can assign a public IP for external access and a private IP for the internal LAN. In such cases you can decide here which IP address to send the SNMP traps to. In this tab, you can also set the SNMP timeout period.



If the windows firewall on the server is enabled, make sure that these ports are open. Ports 50,000, 50,001 and 50,002 are used for internal communication by the NetXplorer with its 3 databases: cfg, stc and ltc respectively.



GUI Browsing to the server is performed by the Java RMI protocol. Java communication between the NX GUI and the NetXplorer requires that TCP ports 1098, 1099 and 4444 are open. In addition, TCP:8093 is used for communicating alarms.

Finally, UDP port 123 must be open to enable NTP clock synchronization.

Note that when working with SMP, you will also need the following ports to be open: UDP 53 (DNS), UDP 1646 or 1813 (Accounting Messages), TCP 5555 (Fast Update Process) and TCP50003 (JDBC query). These are discussed in more detail in Module 12: Troubleshooting SMP.



Here we see a summary of the different communication protocols used.

In this module we have examined the architecture of the NetXplorer system and its different component parts. The foundation you have gained in this module will be of particular importance when we begin p p gtroubleshooting the NetXplorer.


Date post:	01-Jan-2016
Category:	Documents
Upload:	newlevel
View:	90 times
Download:	6 times

Allot Comunications - ACPP_Advanced NX Architecture.pdf

Documents