Frequently Asked Questions

Traffic Server and sFlow Probe


How do I filter on IP Multicast traffic?

IP Multicasts addresses fall in the range specified by the following address/mask pair: 224.0.0.0/240.0.0.0

The address/mask pair can be used in traffic queries and as part of a custom top N query in order to display IP multicast data. For example, the traffic query:

tableType=IP
destinationAddress=224.0.0.0/240.0.0.0
resultField=sourceAddress,destinationAddress,frames

would produce a table giving source address, IP multicast group and number of frames.


How do I print the real-time topN chart?

The real-time top N chart is a Java applet. Most browsers do a poor job of printing applets, either loosing part of the chart or getting the scaling wrong. However, Microsoft's latest release of Internet Explorer (IE 5.5) appears to solve the applet printing problem, offering print preview and the ability to accurately print the applet contents.

If you are unable to use IE 5.5 then alternatives are to create a bitmap of the chart (on windows with alt+print screen or on X-windows platforms with xwd (x-windows dump)) and then to print the bitmap.


How do I configure Traffic Server to receive Cisco NetFlow?

Configure the routers with a flow-export active timeout of 5 minutes or less and direct them forward NetFlow data to the Traffic Server using port 9993 (Consult your router documentation for instructions on configuring NetFlow).

You can confirm that NetFlow packets are arriving at the server by running:

% /usr/sbin/tcpdump -n udp port 9993

The source IP address should be the loopback IP address of the router. If the traffic server has received these packets, then the IP address should also be listed in the file /usr/local/inmon/server/config/netflow_agents.

The next test is to make sure that the Traffic Server can make SNMP requests back to the IP address that the router is sending with:

% snmpwalk <router IP> <community string> interfaces

If this does not work, then you may need to change the router configuration to enable read-only SNMP access.

To specify a particular community string and/or sampling-rate for your router, create an [agent] entry in your inmon configuration file like this...

[agent]
address = <router IP>
community = <community string>
samplingRate = <sampling rate>

You may need to create a new [subnet] entry for this [agent] entry to go under.


How do I extract traffic data for use in a billing system?

Traffic Server provides a powerful web-based query mechanism for extracting traffic flow data (see Help:Query). Any HTTP capable tool can be used to make queries and create customized traffic reports suitable charging for network usage.

The bill.pl script provides a useful usage-based billing tool and illustrates how Traffic queries can be scripted in Perl.


How much disk space does Traffic Server require?

The amount of disk space used by Traffic Server is dependent on the number of addresses communicating. However, the numbers below can be used as an estimate.

Traffic Server maintains two types of traffic statistics:

  • minute-by-minute real-time data,
  • hour-by-hour history data

A typical installation will result in:

  • Minute data: 4-5MB/minute for the first hour, 1MB/minute for subsequent hours.
  • Hourly data: 10MB/hour (average for long term storage)

Typically, a 20GB disk is sufficient to hold 1 month's data.

You can configure how much data to keep based on number of minutes or days or disk space in the Traffic Server configuration file:

  • KeepActiveMinutes - number of minutes of minute data
  • KeepHistoryDays - number of days of hourly data
  • KeepFreeMBytes - amount of free disk space to maintain in the disk partition containing the history data

Traffic Server will automatically age out expired data. In addition, if disk space is insufficient to keep the specified amount of data, old data will be deleted to make space for new data.


How much bandwidth does sFlow use?

This example calculation shows that in a typical configuration sFlow traffic is less than 0.1% of the network bandwidth.

You can use this as a basis for calculating network overhead in a specific network configuration.

Assumptions

  • sFlow datagram transport overhead (SDTO) = 66B (sFlow (24) + MAC(14) + IP(20) + UDP(8))
  • Interface counters sample (ICS) = 108B
  • Interface counters sampling rate (ICSR) = 1/30 (ie the counters of each interface in a switch are captured and forwarded every 30s)
  • Flow sample average (FS) = 200B (range = 112 bytes to about 250, depending on whether there are subnets, as-paths etc)
  • Packet sampling rate (PSR) = 1/1000 (ie on average 1 in 1000 packets are sampled)
  • Network traffic rate (NTR) = 4000 pps (10Mb link running at 65% capacity with an average packet size of 200B)

Calculation for a 100-interface switch

Interface counter bits per second (ICBR) = 100*ICS*8*ICSR
ICBR = 100*108*8/30 = 2.88kbps

Flow samples per second (FSR) = NTR*PSR
FSR = 4000/1000 = 4

Flow sample bits per second (FSBR) = FSR*FS*8
FSBR = 4*200*8 = 6.4kbps

Typically all 4 flow samples and the counter samples will fit in a single datagram

sFlow datagram bits per second = ICBR + FSBR + (SDTO*8) = 2.88 + 6.4 + 0.53 = 9.81kbps

This is approximately 0.1% of a 10Mb link. If the sampling rate is 1/100 the network overhead for the same traffic rate and packet size is 0.7%


How can I add my own web pages to Traffic Server?

Traffic Server web pages all have the web path http://<server>/its/. By default, when you connect to the home page of a Traffic Server, you are redirected to the Traffic Server web pages. This behavior is controlled by the file /etc/inmon/apache/inmon_httpd.conf. If you wish to replace the home page with your own, simply edit the inmon_httpd.conf file and comment out the redirect as follows:

# Redirect / to /its
# Note: Comment out the following lines if you want to maintain your own home
# page for the server.
# RedirectMatch ^/$ /its/
# RedirectMatch ^/index\.htm /its/

You will need to restart Apache in order for the changes to take effect:

/etc/rc.d/init.d/httpd restart

You can now make changes to the web server's home page. To access Traffic Server, you will need to explicitly type in the /its/ path in your URL. It is generally a good idea to create a link from the home page to Traffic Server so that you don't need to remember the path extension. Creating your own Traffic Server home page is a good way to provide contact information, additional information about the network and links to other network management tools. You can also create your own customized reports and navigational screens with links to specific Traffic Server pages, reports and charts.


How do I configure NetFlow on my Cisco router?

The exact commands to configure NetFlow vary between products and IOS releases. The best way to find the appropriate commands for your Cisco product is to search the Cisco web site. As a starting point, here are a few useful links:

You need to configure the router to send NetFlow version 5 to port 9993 on the Traffic Server.

In order to allow Traffic Server to provide long term trending you also need to ensure that you configure your switch or router to provide SNMP ifIndex Persistance.


How do I configure sFlow on my Foundry Networks switch?

The following commands configure a Foundry switch to sample at 1-in-512 and send the sFlow packets to a Traffic Server (192.168.4.5) using UDP port 6343:

config> int e 1/1 to 4/48
interface> sflow forwarding

config> sflow destination 192.168.4.5 6343
config> sflow sample 512
config> sflow polling-interval 30
config> sflow enable

You can also use the command:

sflow source <interface>

to control the source IP address that will be used, and finally:

show sflow

will list the configuration settings.

Additional information can be found on the Foundry Networks web site:

Foundry Enterprise Configuration and Management Guide, Appendix A: Remote Network Monitoring

Note: If you are using a VM-1 module you must select the interfaces and enabled flow-switching...

interface e1/1 to 4/32
ip route-cache flow

How do I programmatically update a Traffic Server's configuration file?

The postConfig.pl Perl script can be used to send a new configuration file to a Traffic Server. This is is equivalent to submitting a new file manually using the "Server > Configure" option.

If you have multiple servers in your organization, this script could easily be adapted to send the unified configuration file to all of them.

The postRules.pl Perl script can be used in a similar way to send out updates to the security rules. This is is equivalent to submitting a new file manually using the "Server > Security" option.


How do I password protect Traffic Server access?

Access control to Traffic Server is provided by the Apache web server. The following steps can be used to create an operator user and password that will be required to access Traffic Server. Administrative changes will still require the administrative password.

First type the command:

htpasswd /etc/inmon/apache/HttpUsers operator

You will be prompted for a password, and the operator user will be created. At any time you can type this command to change the password.

Next, modify the file /etc/inmon/apache/inmon_httpd.conf, changing the entry:

# Make traffic server tools universally accessible

<Location /its/>
Options Indexes Includes FollowSymLinks
order allow,deny
allow from all
AllowOverride None
</Location>

to the following:

# Make traffic server tools accessible to operator and admin users

<Location /its/>
satisfy any
order deny,allow
deny from all
AllowOverride None
AuthUserFile /etc/inmon/apache/HttpUsers
AuthName "Operator"
AuthType Basic
require user operator admin
</Location>

Finally, you must restart Apache in order for the new configuration to take effect. Type:

/etc/rc.d/init.d/httpd restart

How do I programmatically extract data from Traffic Server?

Traffic Server supports programatic access to the real-time and historical traffic data via an http accessible query interface.

Any tool capable of making http requests can be used to programmatically construct queries, encoding the query parameters in a URL, and extract data from Traffic Server.

The following examples illustrate how to use perl to extract traffic data programatically. (A free perl distribution for the PC can be found at http://www.activestate.com/Products/Download/Get.plex?id=ActivePerl)

  • query.pl - example of extracting data from the historical database.
  • minuteQuery.pl - example of pulling data from the real-time minute database.
  • entity.pl - example using POST for long http queries, and mapping subnets to name entities.

How does the sFlow Probe "Virtual Tap" technology work?

If you have one or more core switches that carry all the traffic to your routers, you can monitor all the traffic that crosses the switch(es) using an sFlow Probe attached to gigabit SPAN port(s) of the core switch(es). Since you are already seeing all the raw packets that go up to the router, there is no need to monitor the router too. With "Virtual Tap" monitoring, the sFlow Probe can extract routing information from the router and use that information to allocate traffic seen passing through the core switch(es) to remote the links (see drawing below).

The sFlow Probe is configured to extract routing information from the site router via expect/snmp/iBGP. The sFlow Probe will then generate three data streams, one for each of the switches that it is monitoring directly, and a fourth "virtual" stream providing information on the links attached to the router. This technique is useful for monitoring links that are not easily or cost effectively monitored directly.


How do I configure a Cisco router to allow iBGP peering with an sFlow probe?

To configure a Cisco router to accept an IBGP peering session from an InMon sFlow probe, issue the following commands on the router:

router bgp <AS>
neighbor <probe_IP> remote-as <private_AS>
neighbor <probe_IP> next-hop-self
neighbor <probe_IP> update-source <interface>

For example if your AS-number is 10846, your sFlow Probe IP address is 10.1.1.100, you have defined the loopback interface to be "loopback 1", and you are not currently using private AS number 65222 for anything else:

router bgp 10846
neighbor 10.1.1.100 remote-as 65222
neighbor 10.1.1.100 next-hop-self
neighbor 10.1.1.100 update-source lookback 1

Note:

  • The first line causes you to enter "router configuration mode".
  • The second line declares 10.1.1.100 as an IBGP neighbour with AS 65222 (anything over 65000 is reserved for private use, and 65222 is the default setting for the sFlow Probe).
  • Setting "next-hop-self" disabled next-hop processing for this neighbour.
  • Setting the update-source to a lookback interface allows the TCP connection to use whatever is the most appropriate interface.

There is a complete guide to these settings at:


Why don't I see any data when I access the Routing-Path Analysis Query?

The Examining routing performance tutorial describes how to use the Path Analysis feature.

Traffic Server maintains routing path performance data by automatically running traceroute to the top "remote" subnets. Traffic Server uses its configuration file and also the traffic data to determine the remote subnets and which are the most active. The subnets specified in the Traffic Server configuration file (using [subnet] blocks) define the "local" subnets.

Traffic Server then uses the subnet information in the sFlow (or NetFlow) data, to identify the top remote subnets which are talking to the local subnets. It then runs periodic traceroute tests to these remote subnets.

There are typically three reasons why you do may not get data for Path Analysis

  1. The traceroute function has not been enabled - check that traceEnabled =YES in the Traffic Server configuration file.
  2. There are no (or very few) subnets defined in the Traffic Server configuration file, or there is no traffic observed between the defined subnets and any other subnets. In this case, Traffic Server is unable to identify the top remote subnets. It is possible to force Traffic Server to traceroute to specific hosts by using "traceTargets" and a comma separated list of hosts and subnet masks in theTraffic Server configuration file, e.g.: traceTargets = 65.69.192.15/19, 65.20.10.87/13
  3. The switch that is being monitored with sFlow is not doing layer 3 switching, and consequently the subnet information is not being exported in the sFlow data. In this case, Traffic Server cannot identify subnet-subnet traffic.

To see whether sFlow is exporting subnet information look at Monitor > Traffic and use Custom to filter on SUBNETS. If there is "no data", subnet information is not being exported.


How do I avoid Traffic Server or Perl script queries timing out?

It is possible to issue a query that will take longer run longer to run than the configured timeouts (particularly if the Traffic Server host is under-powered or heavily loaded). In this case a Traffic Server query may result in "page cannot be displayed error" displayed by the browser after 3 or 4 minutes or a Perl script query may timeout.

To avoid this, limit the number of records retrieved to a "sufficiently large" data set for your purposes by including the 'resultTruncate=(N)' value in your query.

If it is not desirable to limit the number of records, it is possible to configure longer timeouts. However, since there are are two places where timeout settings can be configured:

  1. Perl LWP::UserAgent
  2. Apache web server

These settings should be coordinated, making sure that the Perl script timeout is greater than the Apache timeout so that a meaningful error is returned and the Perl script behaves gracefully.

Perl LWP::UserAgent

In a perl script, the timeout value is set as follows:

# Create a User Agent to make our query
$ua = new LWP::UserAgent;
$ua->agent("Mozilla/0.1 " . $ua->agent);

# Set a query Timeout. Default is three minutes (180 secs)
$ua->timeout(600); # this is ten minutes

For more details see the documentation for LWP::UserAgent.

Apache web server

In the Apache server config on the Traffic Server machine, the timeout value is set in the /etc/httpd/conf/httpd.conf file: #
# Timeout: The number of seconds before receives and sends time out.
#

Timeout 300

For more details see the documentation for Timeout.


Which ports does Traffic Server use when monitoring a network?

Traffic server makes use of a number of ports and services in order to monitor network traffic. Understanding which ports are required is helpful in setting access control/firewall controls.

  1. The server talks SNMP to the network devices, so that means it sends to the UDP destination port 161.
  2. The server sends traps (e.g. to OpenView) on UDP port 162.
  3. The server send email messages by connecting to the mail server on TCP port 25. (the mail server is set by "smtpHost" in the config file.)
  4. The server also occasionally sends ICMP ECHO messages to the devices to test availability, and as part of the autodiscovery.
  5. The server exports a web interface, so TCP port 80 should be visible to clients trying to reach the server (or 443 if you use SSL).
  6. The server will make DNS requests to the nameserver on UDP port 53.
  7. The switch agents stream information back to the server in UDP packets. The HP Extended RMON, NetFlow and sFlow ports that the server listens on are set in the server/inx/bin/program/inxGlobal.ini file: FirstSampleTrapPort = 19981 ; HP XRMON
    SamplePortsToOpen = 11 ; (19981 - 19991)
    FirstNetflowPort = 9985 ; NetFlow in
    NetflowPortsToOpen = 11 ; (9985-9995)
    InMonSamplePort = 6343 ; sFlow samples in
    InMonSamplePortsToOpen = 11 ; (6343 - 6353)
    These are the default settings - they can be changed by overriding these parameters in the [site] section of the inmon config file and then restarting all the data-collection processes (Server > Control).
  8. The server will send packets to UDP destination port 33435, as part of the ""Routing > Path Analysis" data collection. For this tracing function to work, the resulting ICMP destination_ureachable responses from routers across the open internet must also be allowed to get back to the server.
    TraceUDPDestPort = 33435 ; for trace pkts (32768+666+1) - same as traceroute pkt with ttl=1
  9. You will need to be able to log in to the server via ssh (TCP port 22).
  10. We strongly recommend running NTP (Network Time Protocol) on the server. NTP uses port 123.

Security

If you put the server outside the firewall, then you will need to make sure that it is locked down from a security standpoint. Be careful to shut down all non-essential services and ensure that all relevant Linux security patches are installed. In our experience, the Red Hat Network service is good for this.


Why do Traffic Server Monitor > Top N and Segment Counters charts not display when using Mozilla, Firefox, or Netscape?

Traffic Server uses Java applets for the Monitor Top N, Circles, and Segment Counters Charts. For these to display properly when using Mozilla, Firefox, and Netscape, you must ensure that you are using the correct Java plug-in.

For Mozilla 1.4 and later and Mozilla Firefox on Linux a compatible plug-in must be used. JRE 1.4.2 and later contain a compatible plug-in. See http://plugindoc.mozdev.org/faqs/java.html for details on installing and linking to the plug-in

For older versions of Mozilla the plug-in can be downloaded from http://plugins.netscape.com

  1. select "find plugin" on the left.
  2. select platform=Linux and mimeType=application/x-java-applet
  3. this will lead you to a "Java by Sun Microsystems" download page, which you can also access directly: http://cgi.netscape.com/cgi-bin/pi_moreinfo.cgi?PID=10048

How do I correct "Neighbor table overflow" error?

When the Linux arp table overflows there will be a dmsg entry "Neighbor table overflow". The Traffic Server autodiscovery process which involves pinging the address space defined by the subnets in the configuration file, can cause the arp table to overflow. This is most likely to happen when class A or class B subnets are defined. The solution to this problem is to tune proc. Suggestions on how to tune proc are given at: http://www.rstack.net/tuning_proc_for_arp.html