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
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”).
If desired, SiteAudit can discover all printer assets on the network.
Here is how the discovery process works:
- For each network on the included list, determine the addresses in that list
- Determine if any of these addresses are excluded (either via another network or via a range)
- For an included address send an ICMP packet to that address
- Determine if it supports SNMP, use each of the specified community strings to determine which community string should be used
- 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 21 FTP: Port security scan - identify potential security vulnerability
- TCP 23 Telnet: Port security scan - identify potential security vulnerability
- If it supports the Standard Printer MIB, then it is a networked printer
- If it supports SNMP but not the Standard Printer MIB and it supports Port 9100 (or equivalent), then it is a networked printer
- If the device is not a networked printer, determine if it serves Port 135
- If it supports Port 135, attempt to connect using WMI and one of the provided credentials
- If the credentials worked, determine if there are any local printers or print queues on this host
- 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:
- The host that SiteAudit is running on and the resources available on that host (i.e. processor, memory, network bandwidth)
- The number of network addresses to be scanned
- Network bandwidth, including the bandwidth of all of the networks that have to be scanned
- Density of the networks and ranges that are to be scanned. Sparsely populated networkswill 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.
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.
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.
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, with the exception of port 161, which is a UDP port. Each
scan is retried three times.
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.
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.
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.
