Our development team has been working hard and we are pleased to announce the release of Plixer Tools 8.0.0. What’s Plixer Tools you ask? We’ve combined Denika, Logalot, WebNM, and Flowalyzer into a single installer to provide better integration with Scrutinizer.
Paul Dube
OK, let’s say you’ve decided to live a healthier life. You’re exercising regularly, stopped getting drunk every night, and you’re eating healthy. You’ve been eating more salads, almost cut out red meat, and even eating annoyingly healthy desserts, if any. Read more »
“Why don’t I see my VLAN traffic?” was the question one of our customers asked me the other day. Although other Cisco models were exporting flows properly, it seemed that all of his Cisco 7600s were under reporting traffic.
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.
I found something interesting on the Cisco Systems web site. According to Cisco’s forecast, global IP traffic in 2008 stands at more than 10 exabytes per month and will more than quadruple to approach 44 exabytes per month in 2012.
I thought Cisco’s forecast was interesting because I’m not one of those who believes the Internet is going to crash. I do believe that Nathan is right about network forecasting being important.
Anyway, I got to thinking that this topic was worth blogging about again. The Cisco article inspired me to go check out our Internet connection. We added network traffic forecasting to Denika years ago:
Notice you can take you mouse and zoom in on a time frame above to get more details:
Denika can forecast on anything (e.g. database response times, temperature, Cisco CBQoS, etc.). It is not limited to SNMP OIDs.
Michael Patterson
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.
Yet again, it’s raining here in Maine. I think it has been raining for four days straight and now I’m beginning to get a little antsy to see some sunshine.
Usually, I don’t watch the Weather Channel. I just take every day as it comes and adapt to the weather. If I wake up and it’s rainy and cold, I wear something warmer. If it’s bright and sunny, I wear a t-shirt.
I’m simple that way.
But when we have a run in weather like this, I ask myself: “When is this going to end?!?”
That’s when I break out of my normal habit and check the forecast for the next couple days. I must admit, there is a sense of peace knowing that the rain SHOULD end by tomorrow night.
Much like monitoring the weather, you can use SNMP to monitor your daily, weekly or even monthly traffic statistics to help you project what tomorrow may bring.
Notice the Port Utilization graph shown above: Not only does it provide statistics based on current data collected, it also estimates future projections based on your current trend using those strike lines.
With limiting budgets, it’s more difficult to rationalize spending on a new DS3 circuit for the company. However, network performance monitoring applications, such as Denika, make life easy by forecasting network growth, so that you can see a problem before it ever begins.
Think about this: Would you feel better knowing that tomorrow was always going to be a bright and sunny day?
-Nate
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 PoreAs most of you know, IP SLA and Cisco NetFlow are both free features on your Cisco routers. If you are looking to somehow get a higher level status report on both, here is an idea. Why not put both in your maps.
Notice that there are two links between devices that refresh every few minutes. One link represents utilization from NetFlow and the other link represents the MOS (Mean Option Score) on the link which is helpful with VoIP traffic monitoring. The second link can be based on any SNMP value (errors, latency, jitter, etc.) and is done using the Denika plugin.
This feature is 100% web based to configure and view in our Application Performance Dashboard ‘MyView’ and can be a nice addition to your network traffic monitoring needs. Within the maps, you can click on the links to bring up a trend of the interface. This is especially useful when the link changes color based on utilization and you want to drill in for details.
Call us if you need help setting this up.
Michael PattersonIt was a cold day in March, colder than usual for this time of year. The phone rang and it was Jon telling me that his router wasn’t performing well and was having issues. They all have an issue in this city. Some are big and some are small, but they all have issues. As for Jon, his issue was big and that’s why he called me… I’m Jimmy D, the Cisco NetFlow Detective.
His story was the same old song; everyday around a specific time, his network would slow down and the CPU on is his router would peg at 90%. He needed to know why, and fast. His company was getting ready to release a hot new piece of software and they needed the bandwidth to support it.
He had taken the first step; he was already monitoring his bandwidth with Scrutinizer. But Jon needed more. He needed to know what times his CPU utilization was high and what traffic patterns occurred during that time. If this was a perfect world, he would also be alerted when it happened.
“Let’s go get a cup of coffee.” I said.
“Jon, we can trend your CPU utilization via SNMP with Denika. We can also set up alarms and alerts in both Scrutinizer and Denika. We can also capture syslogs from the router with Logalot. All this information can be tied together to give us a better picture and possibly point out a pattern.”
“Awesome, that’s what I was looking for! Can you help me?” he replied.
“Sure Jon, I’m the NetFlow detective, that’s what I do.”
Later that day, we took some time to set up both products. I explained how the process worked and what we were looking for. I let him know that although we can store this data forever, We were specifically interested in the next 24 hours. I was positive that our culprit would strike again.
He let me know that he would call me the next day.
“Jimmy, I just got an alert!” said Jon.
“Lets look at what it said.” I asked.
It was 5:01 p.m. and I wasn’t surprised. Nasty things, like rats and bad packets, show up quickly. After a few minutes of searching, I could see a pattern and it wasn’t pretty.
“I believe that I found your issues Jon.”
I looked at the time of the CPU spikes in Denika’s SNMP reports. We then looked at the Layer 3 traffic reports within Scrutinizer. I compared the timeframes and quickly saw the traffic matched.
“We now know it is a user. So now let’s find out who it is. To do so, we can drill down through the IP addresses in Scrutinizer and find out what IP is causing the traffic. Here you go Jon, are you ready to see who is hogging your bandwidth and causing the high CPU utilization?”
In one click, I quickly resolved the top talkers and saw that it was jenny.abcorp.com.
“Oh no, that’s my girlfriend!” said Jon, “Can we tell who she was talking to?”
We quickly changed to the conversations destination and could see that she was uploading 6 gigs of information to cbacorp.com at 5 p.m. every day. Jon knew the rest of the story because it was a common one. Geek programmer meets cute Russian model who thinks he is Superman, but soon finds out that he had been taken by a pretty face. She was uploading the latest builds of their hot new software to the competitors. She was a spy.
“Thank you Jimmy, you saved our company.” said Jon.
“Don’t sweat it kid. My job is to shed some light in a dark world…”
Most of these names and happenings in this story are true. Some have been changed to protect the innocent.
____________________________________