Network Traffic Guide

This article explains how Netaphor SiteAudit™ collects data and why network traffic is minimal. Implementer and IT administrators are the audience for this article.

Contents

• SiteAudit's Traffic Impact
• How SiteAudit Discovery Works
• Why Traffic is Minimal
• Collection by Data Type
• Network Traffic Volume
  
• How to Measure Traffic
• Network Traffic Examples

What is SiteAudit's Impact on Network Traffic?

Several factors impact network traffic. How the network is designed, the number of networks, sub-netting and routing all affect network traffic. SiteAudit follows the "good citizen" principle by being unobtrusive and not unduly impacting the resources available to others on the network.

 

During normal operations the traffic impact is minimal, with no measurable impact on the network's bandwidth and quality of service.

During the discovery cycle, network traffic is measured at about three percent to five percent. This is the peak network traffic for SiteAudit. If 'Discover networks automatically' is selected, SiteAudit will use broadcasts to find networks and devices. Broadcast can be disabled, and discovery can be scoped to suite your environment. SiteAudit allows IP network discovery information to be imported for quick and easy setup. (See Knowledge Base article “Importing Data”).

 

How Discovery Works

If desired, SiteAudit can discover all printer assets on the network. 

Here is how the discovery process works:

1. For each network on the included list, determine the addresses in that list.
2. Determine if any of these addresses are excluded (either via another network or via a range)
3. For an included address send an ICMP packet to that address
4. Determine if it supports SNMP, use each of the specified community strings to determine which community string should be used.
5. SiteAudit scans the following ports to find printers and identify open ports that could identify potential security vulnerabilities:
• UDP 161 SNMP: Check for SNMP support. SNMP is used to collect printer data.
• TCP 80 HTTP: Check to see if there is an embedded web server. Port 8080 is tried if no web server is found on port 80. HTTP is used to collect data.
• TCP 9100 and 1650: Print protocol for printers, used to collect data.
• TCP 631 IPP: Print protocol, used to collect data.
• UDP 9300 NPANT: used to collect data from Lexmark devices.
• UDP 47545 CPCA: used to collect data from Canon devices.
• TCP 135 RPC: Used to detect a Windows host for directly connected printers.
• TCP Port Security Scan: scans vulnerable ports (see Discovery Traffic below).
6. If it supports the Standard Printer MIB, then it is a networked printer.
7. If it supports SNMP but not the Standard Printer MIB and it supports Port 9100 (or equivalent), then it is a networked printer.
8. If the device is not a networked printer, determine if it serves Port 135.
9. If it supports Port 135, attempt to connect using WMI and one of the provided credentials.
10. If the credentials worked, determine if there are any local printers or print queues on this host.
11. The discovery process also scales to use multiple threads and connections depending on the host that it is running on and the available resources.

Discovery Scans Timing

How long a discovery scan takes depends on a number of factors. These include:

 

1. The host that SiteAudit is running on and the resources available on that host (i.e., processor, memory, network bandwidth)
2. The number of network addresses to be scanned.
3. Network bandwidth, including the bandwidth of all of the networks that have to be scanned.
4. Density of the networks and ranges that are to be scanned. Sparsely populated networks will take significantly longer to scan. This is because in sparsely populated networks a number of addresses will not respond to ICMP. This in turn will require retries after the timeout period which causes the scan for these networks to last longer.

The discovery scan is scheduled to run in seven-day intervals. For example, if the discovery scan takes two days to complete, the next scan will begin in five days. If a discovery scan takes longer than seven days, the next one begins upon completion of the previous scan.

 

Why Traffic is Minimal

SiteAudit data collection can be characterized as a slow, steady receipt of packets. This results in a smaller percent of the network bandwidth being used.

In contrast, applications like Web JetAdmin send blasts over the network. As a consequence, applications like these require scheduling of data collection, typically during off-peak hours. This is a product design difference that shows up when considering when data is available, and the amount of network traffic generated.

Collection by Data Type

SiteAudit printer data is of two types: volatile and stable data.  The default values are listed below.  

Volatile Data: (Data that can change frequently)

Note that some time intervals have changed in version 6.8.0.0

• Page Counts - collected every 30 minutes.
• Print Jobs - collected every 4 hours.
• Supplies Information - collected every 30 minutes.
• Alerts - checked for changes every 10 minutes.
• Thresholds - checked every 10 minutes.
• Device Status - checked every 10 minutes.
• Move Add Change - checked every 10 minutes.

Stable Data: (Data that does not change frequently)  

• Network and Identification information - Checked every 7 days.
• Configuration Information (input/output options) - Checked every 12 hours.

SiteAudit also stores data about addresses that are discovered by SiteAudit but are not printers.

 

This data includes:

• SNMP information, port information
• For Windows hosts, Make/Model/Last Reboot time and Logged in User, if configured.
• For Windows hosts that are print servers and have queues located on them, SiteAudit will also collect job data, if configured.

Network Traffic Volume

SiteAudit's impact on network traffic depends on the number of devices it is monitoring. The following factors go into calculating the number of packets being sent.

Discovery Traffic

• ICMP: An ICMP packet is sent to each IP address for each network on the list for discovery. If the broadcast address for a network is included, then an ICMP broadcast is sent to that network. The packet is retried three times for devices that do not respond.
• SNMP: An SNMP packet is sent to each IP address for each network on the list for discovery. If the broadcast address for a network is included, an ICMP broadcast is sent to that network. The packet is retried three times for devices that do not respond. The packet is retried for each community string in the list of community strings that are provided. This particular packet type can be reduced by removing community strings that are not required from the list of pre-seeded community strings that have been provided.
• Security Port Scan: Each device that responds to an ICMP packet will also receive port scan packets. The port numbers scanned for each device are 20, 21, 22, 23, 25, 53, 110, 137, 139, 443, 445, 995, 8443. These are TCP ports and are retried a maximum of three times. The security ports scanned can be changed to include/exclude ports or disable the security scan completely.

Monitoring Traffic

• Volatile data: This depends on the type of the device and the number of counters and consumable information available for each device. Advanced devices support about 20 counts. Each count requires one packet. Typical devices support three to four counts. Each packet is 512 bytes. There are no retries. Consumable data is similar to count data. Advanced devices support three to four types of consumables, and each consumable has six pieces of information required for it. Thus, 18-24 packets for advanced devices may be required. Alerts are polled by examining the alert table. If there are no changes in the alert table, alert data is not retrieved. SiteAudit retrieves seven individual pieces of data from the alert table.
• Stable data: Typically, about 100 packets of data per device are retrieved per day.  

Local Printers and Queue Data

All of this data is retrieved using WMI. WMI uses RPC and windows authentication. Five separate queries per host to be polled are issued.

The packets are TCP. The size and number of the packets depends on the network packet size, the type of authentication present and the query being issued.  

SQL Traffic

SQL traffic is used to update the DB when data changes. This is TCP traffic to the server. SQL traffic also exists for queries between SiteAudit viewer applications and the database.  The amount of traffic depends on the number of devices present, the maximum size of the network packet and the type of authentication used. The traffic is only between the hosts running SiteAudit and the SQL server.

Other Traffic

Other traffic may exist if scheduled reports and email notifications are generated. Email traffic is to the SMTP server.

 

How to Measure Network Traffic

Different user environments make it difficult to quantify and forecast network traffic. Among the variables is the network configuration. Different printers also generate different amounts of network traffic. For example, a high-end MFP with many features will generate more messages than a desktop monochrome laser printer.

While SiteAudit has not had a problem relating to generation of excessive network traffic, testing this in the customer environment is important. A simple way to do this is run a network analyzer application in a small test lab to see what traffic is generated.  Netaphor can recommend a free application called Wireshark for testing. It is available at wireshark.com.

 

Network Traffic Examples

Below are examples of the amount of network traffic used by four different fleet sizes: 250, 1,000, 10,000 and 25,000 printers. 

Estimated network traffic for 250 printers

	Type of Packets		Amount		Notes
	×     Discovery packets		40500		Amount of discovery packets/cycle
	×     Monitoring packets		19016		Estimated Monitoring Packets/Hr
	×     Bandwidth		9		Average Bandwidth usage/hr in MB
	×     Bandwidth/Second		0.003		Average Bandwidth usage/ sec in MB
	×     % Usage in GB Network		0.000293		% of bandwidth used in a GB network
	% Usage in 100 MB Network		0.003		% of bandwidth used in a 100 MB network

Estimated network traffic for 1,000 printers:

	Type of Packets		Amount		Notes
	×     Discovery packets		1159200		Amount of discovery packets/cycle
	×     Monitoring packets		75920		Estimated Monitoring Packets/Hr
	×     Bandwidth		37		Average Bandwidth usage/hr in MB
	×     Bandwidth/Second		0.01		Average Bandwidth usage/ sec in MB
	×     % Usage in GB Network		0.000977		% of bandwidth used in a GB network
	×     % Usage in 100 MB Network		0.001		% of bandwidth used in a 100 MB network

Estimated network traffic for 10,000 printers:

	Type of Packets		Amount		Notes
	×     Discovery packets		5025000		Amount of discovery packets/cycle
	×     Monitoring packets		762038		Estimated Monitoring Packets/Hr
	×     Bandwidth		372		Average Bandwidth usage/hr in MB
	×     Bandwidth/Second		0.103		Average Bandwidth usage/ sec in MB
	×     % Usage in GB Network		.010058594		% of bandwidth used in a GB network
	×     % Usage in 100 MB Network		0.103		% of bandwidth used in a 100 MB network

Estimated network traffic for 25,000 printers:

	Type of Packets		Amount		Notes
	×     Discovery packets		5025000		Amount of discovery packets/cycle
	×     Monitoring packets		1901550		Estimated Monitoring Packets/Hr
	×     Bandwidth		928		Average Bandwidth usage/hr in MB
	×     Bandwidth/Second		0.258		Average Bandwidth usage/ sec in MB
	×     % Usage in GB Network		0.025195313		% of bandwidth used in a GB network
	×     % Usage in 100 MB Network		0.258		% of bandwidth used in a 100 MB network

Note: Traffic estimate is based on a typical environment, but results may vary depending on mix of local and networked printers, number of counters, address spacing, number of IP addresses and other factors.