There is no doubt that flow technology is revolutionizing network monitoring. In this  NetFlow/J-Flow/IPFIX/sFlow era, there is no need to settle with only knowing utilizations on the network. Besides, little analysis can be done in monitoring bandwidth only anyways.

Scott wrote a blog earlier that made a valid point: “A Network Administrator’s abilities are only as good as his awareness of what happens on his network.” In harmony with that statement, it’s beneficial to have useful tools to be able to collect that traffic information.

Recently, I learned that J-Flow is supported for the Juniper SRX series Gateways. I thought this might be good information for people who want to start monitoring flows on this type of device, especially our NetFlow and sFlow Analyzer users, since it can also process J-Flow packets. Below are some sample commands taken from Juniper’s Knowledge Base which walks you through your J-Flow configuration. Read more »

Daniel Senga
Tech Support
Follow me on Twitter

Today I will discuss the command “ip flow ingress infer-fields”, mostly used in the NetFlow configuration of NetFlow switches. Being the newest member of the Plixer International Tech Support team I am discovering how amazingly large certain networks can get. This is when an outstanding network monitoring and diagnosis capability come in handy. Read more »

Daniel Senga
Tech Support
Follow me on Twitter

How do you know if the NetFlow collector is saving or even getting all of the NetFlow datagrams that are being sent to it or that it is receiving? It is important to know if any flows are missing.

Why do we care?

This is a great question. We care because a loss of flow exports is usually caused by one of three things:

1. The network dropped some packets
2. The router can’t keep up
3. The NetFlow receiver / collector can’t keep up

NetFlow sequence numbers are becoming increasingly important. When building a NetFlow collector it is important that the engine scales while staying accountable. If you look at the NetFlow v9 packet format you will notice something called the package_sequence.

Read more »

If you are running Scrutinizer v7.01, the Cisco ASA interfaces don’t show up in the Status tab yet. It was a philosophical decision. Here’s why:

The ASA running v8.2.1 exports bidirectional NetFlow!  This is unlike anything else we’ve seen.  In nearly all NetFlow exports v5, v9, IPFIX etc. flows are exported in one direction (i.e. A -> B and then a separate flow for B -> A).   This is true for ingress or egress NetFlow. For Example: lets say A -> B creates a flow of 200KB.  Then in return:  B -> A causes a 2nd flow of 40KB. Well, the developers of the ASA decided to be unique and add the two flows together and export A -> B 240KB!!!!  The two added to each other is called a bidirectional flow.

Because of this, when we calculate the percent utilization using NetFlow (i.e. not SNMP) by adding the total flows together we overstate InBound/OutBound utilization in the Status tab. We are talking with Cisco about this unconventional export method. We have no definitive news yet.

NOTE: The ASA also doesn’t support an Active Timeout causing huge spikes in the graphs and thus making network traffic analysis kind of tricky when traffic that occurred over several minutes shows up in a single minute!

If you are seeing some screwy results with ASA and NSEL, the above is why. Anyway, everyone can blame Mike for not sticking the data in the Status tab!

Here is a pic of our  ASA:

Need help configuring NetFlow export from the ASA?  You can also setup NetFlow exports up using Cisco ASDM. Make sure you have watched the Cisco ASA and NetFlow training video.

____________________________________
Jim Dougherty aka "Jimmy D"
International Sales Channel Manager and
Netflow Evangelist for Plixer International!

Follow me on Twitter
http://twitter.com/jimmydnet
____________________________________

I had a customer ask me how HP Procurve’s Class of Service (CoS) for VLANs could be monitored in Scrutinizer with QoS (Quality of Service).

HP Procurves export sFlow (sampled flows). Scrutinizer v6.05 listens to sFlow counters and samples. If specific VLAN tag information is sent out, Scrutinizer ignores it in the current release.

What the sFlow collector (e.g. Scrutinizer), does see is the ToS (Type of Service) byte included in the sFlow packet. The values for this 8-bit field can be defined in Scrutinizer in the QoS Definitions option in Settings. The QoS Definitions feature allows network administrators to customize their QoS settings, with the ability to run reports based on the 8 bit ToS values or 6 bit DSCP values.

Read more »

If you use both our Scrutinizer NetFlow Analyzer and Denika Performance Trender tools to help meet your network management goals, you can integrate some of the Denika functionality into Scrutinizer.

This integration can include a link directly from the Status page of Scrutinizer to the Denika reports for a device. You can also use Denika reports in Scrutinizer maps.

Read more »

A common problem for network administrators is when end users get in the habit of blaming the network for slowness on their workstations. For this reason it’s important for network administrators to not only prove, but sometimes disprove, issues with the network. Sometimes the issue is a combination of both.

Read more »

Monitoring with CBQoS (Class-Based Quality of Service) in addition to NetFlow and IPSLA on a network can provide additional insight into an organization’s critical applications utilization. As more companies deploy VoIP and video conferencing CBQoS can be utilized to show how these applications are delivered across an infrastructure with defined policies. CBQoS is a Cisco feature set that is part of IOS 12.4(4)T and above, and is available at no additional cost. The QoS statistics provided by CBQoS are made available via SNMP polling and give detailed information about the defined QoS policies applied to interfaces and class-based traffic patterns.

A typical network with no QoS policies defined runs with a best-effort delivery, with all traffic having equal priority and an equal chance of being delivered. When these networks become congested, all traffic also has an equal chance of being dropped. The definition of policies (class-maps defined in policy-maps) allows specific traffic to be prioritized according to its relative importance and uses congestion-avoidance to ensure its delivery. CBQoS can also be used to limit the amount of bandwidth for certain network traffic making network performance more predictable and utilization more efficient.

CBQoS can be used to ensure network applications such as VoIP and video conferencing receive the highest priority. It also provides an in-depth look at the amount of traffic used, both before it is filtered through a policy (pre-policy) and after it has been filtered (post-policy). If any of the traffic was dropped during congestion because of the rules defined in a policy, CBQoS reports the amount of traffic that was dropped.

In the following example, I have configured one of Plixer’s lab routers (sent home with an employee) to prioritize both IAX and SIP traffic for VoIP calls along with a priority for webmail and file transfer. This policy, attached to a WAN interface, will ensure that the employee will be able to effectively work from home. After the policy is in place, I enabled CBQoS to monitor the pre-policy, post-policy, and dropped traffic from my defined class-maps.

In my example, I have classified the VoIP traffic for support protocol of Plixer’s PBX. When an employee is at home, the VoIP traffic will be given 70% (priority) of the interface, only when congested. I have classified PlixerVoIP traffic with an access-list.

lab(config)#ip access-list extended PlixerVoIP
lab(config-ext-nacl)#permit udp any any eq 4569
lab(config-ext-nacl)#permit udp any any eq 5060

This PlixerVoIP class references out access-list, defined above.
lab(config)#class-map match-any PlixerVoIP
lab(config-cmap)#match access-group name PlixerVoIP

The “Web_Email” class includes regular web taffic like HTTP, HTTPS, FTP, SMTP, and POP3. In other words, this includes web browsing, file transfer, and email traffic.

lab(config)#class-map match-any Web_Email
lab(config-cmap)#match protocol http
lab(config-cmap)#match protocol secure-http
lab(config-cmap)#match protocol ftp
lab(config-cmap)#match protocol smtp
lab(config-cmap)#match protocol pop3

The policy-map is used to match the classes, above, with the policy you define for that type of traffic.
In my examples, we are giving PlixerVoIP traffic 70% priority, if that traffic is present. We are also setting the DSCP EF bit to notify routers down the line that this traffic is important PlixerVoIP traffic. We are giving Web_Email web browing traffic 75% of the remaining bandwidth. For all traffic that was not defined (the class-default), it will just be fairly queued.

lab(config)#policy-map TP-Pol-FastEthernet0/1
lab(config-pmap)#class PlixerVoIP
lab(config-pmap-c)#priority percent 70
lab(config-pmap-c)#set dscp ef
lab(config-pmap)#class Web_Email
lab(config-pmap-c)#bandwidth remaining percent 75
lab(config-pmap-c)#exit
lab(config-pmap)#class class-default
lab(config-pmap-c)#fair-queue

On the WAN interface (your connection to the Internet, in this example it is FastEthernet0/1).
The NBAR protocol-discovery command must be applied for NBAR to recognize traffic.
The service-policy command applies your QoS policy to the Interface.

lab(config)#interface FastEthernet 0/1
lab(config-if)#ip nbar protocol-discovery
lab(config-if)#service-policy output TP-Pol-FastEthernet0/1

Now that our policy has been applied to the interface, let’s enable CBQoS.

lab(config)#enable
lab(config)#configure terminal
lab(config)#snmp-server ifindex persist
lab(config)#snmp mib persist cbqos
lab(config)#end
lab(config)#write mib-data
or
lab(config)#write

To verify our CBQoS commands, we can show them in the running-config:

lab(config)#show running-config | include cbqos
snmp mib persist cbqos
lab(config)#show running-config | include persist
snmp-server ifindex persist
snmp mib persist cbqos

We can monitor the CBQoS statistics with the Denika add-on to Scrutinizer.

As you can see below, there isn’t enough traffic to cause dropped packets, so the pre-policy traffic is the same as the post-policy traffic. The dropped bytes trending graphs indicate that we have not had any problems with our business specific applications.

-Tom Pore
Follow me on Twitter

Oftentimes, when I’m running around the country setting up Flow Analytics, I don’t see Null Scans pop up. However, recently I’ve visited high profile customers that are big targets for malicious behavior. As we configure Cisco NetFlow on their routers and ASA firewalls, I’ve noticed FA alerting on these packets with no flags set.

The Null Scan is a type of TCP scan that hackers — both ethical and malicious — use to identify listening TCP ports. In the right hands, a Null Scan can help identify potential holes for server hardening, but in the wrong hands, it is a reconnaissance tool. It is a pre-attack probe.

A Null Scan is a series of TCP packets that contain a sequence number of 0 and no set flags. In a production environment, there will never be a TCP packet that doesn’t contain a flag. Because the Null Scan does not contain any set flags, it can sometimes penetrate firewalls and edge routers that filter incoming packets with particular flags.

The expected result of a Null Scan on an open port is no response. Since there are no flags set, the target will not know how to handle the request. It will discard the packet and no reply will be sent. If the port is closed, the target will send an RST packet in response.

Information about which ports are open can be useful to hackers, as it will identify active devices and their TCP-based application-layer protocol.

Cisco NetFlow packets contain a summary of the packets flowing through an interface including TCP flags, or in this case, not set. Cisco NetFlow coupled with a behavior analysis tool can help identify when Null Scans are occurring on your network.

-Tom Pore
Follow me on Twitter

If you are not fortunate enough to have equipment that supports Cisco NetFlow technology, but still need to know bandwidth utilization statistics across network links, then there may be no better solution than the combination of SNMP and MRTG.

MRTG (or Multi Router Traffic Grapher) is a free software tool, developed by Tobias Oetiker, that uses SNMP (Simple Network Management Protocol) to poll network devices. MRTG stores the retrieved data to a log file, where it then generates a graphical representation of the stored data.

There are several third party network monitoring tools, like Denika, that use MRTG and SNMP as the means to capture this valuable data. In Denika’s case, the functionality of MRTG is expanded on by incorporating a MySQL database, which provides long term data storage.

If you have ever used MRTG, then you know that it is not easy to configure. MRTG uses a system of templates to send the neccessary object identifiers (OIDs) to the device, which then must have a MIB (or management information base).

Plixer has gone a long way to simplifying this process by making its database of MRTG templates available on the web. In Plixer’s MRTG repository, one can browse a number of different vendors, hardware models and templates. So whether you want to gather port utilization information on your Adtran devices, or frame relay utilization on your Cisco Catalyst 6509, or maybe just CPU utilization on your Foundry BigIron switch, it’s much easier to configure MRTG using Plixer’s MRTG repository.

~ Jon Mills

Jon Mills
Marketing & Public Relations Manager
Follow Me On Twitter