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"
Lead PreSales Support Engineer 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

The Xmas Tree Violation in Flow Analytics is actually looking for a packet known as Christmas Tree Packet. The Christmas Tree Packet is set for any protocol that is being used and it is commonly known as “Kamikaze” packets, lamp test segment or nastygrams.

When a Christmas Tree Packet is sent for scanning purposes the TCP flags are set as FIN, URG and PSH. Some firewall security policies only check packets with the SYN flags set and since SYN flags are not used in a Christmas Tree Packet, the firewall will not detect it and the packet will slide right through without any detection and reach its targeted host.  Christmas Tree packet can be used for Dos attacks as well because the packets require more processing time from router and host than a regular packet.

Xmas Tree Violation in Flow Analytics helps prevent Dos attacks, network scanning and other reconnaissance on your network. When you receive Xmas Tree Violations I would look into it because it likely that some sort of reconnaissance activity is on your network.

Milton

Every morning begins the same way: I come into the office, boot up my laptop, get my coffee and then start on my daily responsibilities.

As I’m sitting at my desk replying to various e-mails and such, Milton decides to talk to himself.

Now when I say that he’s talking to himself, I really mean that he’s talking to everyone in a 10-foot radius, but he’s the only one who understands what he’s talking about.

Here’s a sample of how it goes:

Milton: “There are two girls on the page now…”
Me: “I’m sorry, what?”
Milton: “Who is the new girl on the website?”
Me: “What are you talking about? What girls, what website?”
Milton: “For our blogs…”
Me: “mhrmmmm.” (This is me trying to terminate the conversation)

I’m going to stop there…

That is a common morning conversation scenario with my buddy Milton. If you are confused about this conversation, you are not alone. With Milton starting conversations like we’ve been talking for an hour, he always manages to get a reply out of me, even if it is one of confusion.

I use Milton as an example of how a FIN port scan works.

First think of Milton as a port scan designed for Linux boxes. Milton will first send a conversation to the port using the FIN TCP flag to trick the port into thinking that Milton has been speaking to it all along. After all, the FIN flag is the tag used to FINISH a conversation.

If the port that Milton is talking to is closed, the port replies to Milton with a RST flag. That’s like me saying “mhmmm” just to end the conversation.

However, if the port is open, the conversation packet is quietly discarded, since the conversation is over. But this is exactly what Milton is looking for. If he doesn’t get that RST flag he knows there is a service listening in on that port.

Now that he’s found an open port, he can say what he wants and your server will listen.

Now that you understand how the FIN port scan works; does anyone have an Aspirin?

-Nate