Sie sind auf Seite 1von 27

ACPP Technical Training

1-1

Advanced Architecture

ACPP Technical Training

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. y the end of this module y you will understand the following: g By 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

1-2

Advanced Architecture

ACPP Technical Training

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. 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 settings

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

1-3

Advanced Architecture

ACPP Technical Training

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 pp server and a Sybase y database Java 1.6.0, a J2EE application

1-4

Advanced Architecture

ACPP Technical Training

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

1-5

Advanced Architecture

ACPP Technical Training

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 the Network tree. Host Catalogs are by default defined as global, but you can also limit them to a particular NetEnforcer in the Network. you know that p particular hosts will be handled only y by y one Sometimes y NetEnforcer. In these cases it is possible and recommended to limit the host catalog definition of these hosts to the specific NetEnforcer.

1-6

Advanced Architecture

ACPP Technical Training

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 ASYNCHRONOUS. 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. The Th NetXplorer N tX l will ill then th send d th the catalog t l changes h t to every NetEnforcer N tE f in the Network. If a catalog is successfully saved on a NetEnforcer, the NetEnforcer counter 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 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.

1-7

Advanced Architecture

ACPP Technical Training

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.

1-8

Advanced Architecture

ACPP Technical Training

What happens when changes are made to the NetEnforcers 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 format format. 4. The NetEnforcer validates the commands and performs the changes. In some circumstances, the users request may not be allowed. This could be for a number of reasons: Different NetEnforcers allow different policy changes. Different keys y limit the type yp of p policy y changes 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.

1-9

Advanced Architecture

ACPP Technical Training

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.

1-10

Advanced Architecture

ACPP Technical Training

In this section we will examine the data collection process.

1-11

Advanced Architecture

ACPP Technical Training

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.

1-12

Advanced Architecture

ACPP Technical Training

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 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 p on this data. 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.

1-13

Advanced Architecture

ACPP Technical Training

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. yp Both the 30 second and the 300 second buckets have three types conversation 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.

1-14

Advanced Architecture

ACPP Technical Training

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 g collector. on a distributed short term monitoring 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 bin2ascii ii conversion. i B Buckets k t are written itt i in bi binary f format t on th 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.

gg g the 5 minute samples p into 1hr The short term database then aggregates buckets. 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.

1-15

Advanced Architecture

ACPP Technical Training

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 Server. 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 p processes is over TCP Port 80 or TCP 443.

1-16

Advanced Architecture

ACPP Technical Training

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. server the Logic of the When the request arrives in the NetXplorer server, 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 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 format. format

1-17

Advanced Architecture

ACPP Technical Training

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

1-18

Advanced Architecture

ACPP Technical Training

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 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.

1-19

Advanced Architecture

ACPP Technical Training

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 p Server. NetXplorer 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.

1-20

Advanced Architecture

ACPP Technical Training

The NetEnforcer constantly monitors network traffic and compares its findings to the defined alarms. When an alarm threshold is reached, the NetEnforcer immediately sends p server. A user looking g at the NetXplorer p a notification to the NetXplorer user 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 traps

1-21

Advanced Architecture

ACPP Technical Training

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

1-22

Advanced Architecture

ACPP Technical Training

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 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 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.

1-23

Advanced Architecture

ACPP Technical Training

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 p over UDP p port 162. The menu is available communication of SNMP traps by 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 cases, if the NX server has dual NICS 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.

1-24

Advanced Architecture

ACPP Technical Training

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.

1-25

Advanced Architecture

ACPP Technical Training

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.

1-26

Advanced Architecture

ACPP Technical Training

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 particular importance p when we begin g in this module will be of p troubleshooting the NetXplorer.

1-27

Advanced Architecture