6 posts categorized "Mike Canney" Feed

Give Me Packets!!! Case Study: Slow Oracle DB (by Mike Canney)

There are a number of tools on the market that claim to allow you to analyze Data Bases.  I have many customers that own these tools and sometimes they work great.  Especially if it's what I call a "Low Hanging Fruit" problem, such as a slow SQL call like a SELECT or INSERT etc.  

What happens when it's not so obvious?  This is where deep packet analysis is needed.  In the following case study we will look at a chronic problem that far too many of my customers experience and how to quickly resolve that issue.  This particular problem was lasting for months.  More memory was added, servers upgraded, content switches added/upgraded yet the problem still persisted.  

 Let's take a look:

 

  

Continue reading "Give Me Packets!!! Case Study: Slow Oracle DB (by Mike Canney)" »


The Dark Side of Packet Slicing (by Mike Canney)

SiegerninjaPF

 

Packet or frame slicing our captures can be a great way to hide information in trace files if done correctly.  However, you have to really understand the reason for the captures in the first place.  For example, often times application performance issues leave many clues at layer 4 (specifically TCP).  What happens when you 'hard" slice a trace file and now cannot follow the TCP sequence numbers because the incorrect frame size value is written in the pcap file?

Other times you may need to see the specific application call (SQL/Oracle) to actually fix the problem but you no longer have that data because you've sliced it away.  

Continue reading "The Dark Side of Packet Slicing (by Mike Canney)" »


Give me PACKETS!! Case Study: "The Slow Internet" (by Mike Canney)

Like many Network Engineers, I have also heard all to often that "The Network is Slow".  This is the mantra repeated across the World by end users, server admins and application developers.  

Luckily, we are armed with a tool set to not only exonerate the network (in most cases) but also pinpoint exactly where the problem occurred.  

Being a Packet Fetcher, the first thing I typically turn to in these situations is handy dandy PCAP(s).  In this first case study, we will see how to quickly solve this performance issue given the correct trace files from, more importantly, the correct areas of the network.   See the following diagram of the capture points as well as the video at the end of the post.

Internet_pic

 

 

 

Continue reading "Give me PACKETS!! Case Study: "The Slow Internet" (by Mike Canney)" »


Give me PACKETS!! (by Mike Canney)

Give me Packets!

I have been troubleshooting “network” problems for over two decades.  From mom and pop small businesses to Fortune 10.  Literally thousands of companies.  As far as tools go, I’ve used just about all of them.  From the Network General Sniffer, Novell LanAlyzer, Optimal’s Application Expert/Vantage, Compuware Ecoscope, Cinco NetXray to Wireshark and back.  

You would be hard pressed to find something that is somewhat mainstream that analyzes packets that I haven't used to find and solve network and application issues. Flower issueI’ve have also used the majority of the popular APM/NPM tools on the market for monitoring Network and Application Performance (I won’t list them).  The one thing in common is that they’ve all been useful in their own right.  Understanding at a high level of what traffic is on the network and an inclining of ‘potential’ application performance issues. 

 

Continue reading "Give me PACKETS!! (by Mike Canney)" »


Why Packetheads Need Not Fear Cisco ACI (by Mike Canney)

Why Packetheads Need Not Fear Cisco ACI

There seems to be much mystique and confusion over Cisco’s ACI and how we as network analysts will troubleshoot in this new network environment. It’s an architecture to which few seem to have completed the move, but many are planning to do so in the near future. Now is the time to architect with visibility in mind.

Packethead

With Cisco ACI there has been some misunderstanding based on early claims of ‘not needing packets anymore’ to discussions on ’how the heck are we going to do this?’ Eager to confirm my beliefs about ACI, I attended many sessions at the Cisco Live conference this year. There was a lot of clarification and confirmation of how to best instrument new networks for full visibility. 

The Short Answer:  Not much has changed as far as building a visibility fabric. If you have familiarity with building such a fabric in the VMware Nexus ‘Top of the Rack’ design, you will have no issue capturing in an ACI environment. Wherein the Nexus model, to get east-west traffic, you would simply tap the uplinks between the top of the rack and the aggregation layer, in an ACI environment you tap between the spine and leaf switches to obtain traffic. 

 

Continue reading "Why Packetheads Need Not Fear Cisco ACI (by Mike Canney)" »


The Hidden Value of End User Monitoring (by Mike Canney)

Mike CanneyAuthor Profile: Mike Canney is the President of getpackets.com, specializing in providing application and network performance consulting services. Over the past 22 years Mike has helped 100's of companies identify and resolve their application and network performance issues. Mike has also developed coursework and taught thousands of engineers how to identify, remediate, and prevent network and application issues by analyzing traffic flows at the packet level. 

The Hidden Value of End User Monitoring


End user performance monitoring is currently a very hot topic amongst IT management these days.  Take a quick walk around the vendor pavilion at Interop and you will count at least 5 companies touting that this is what they do and that they do it better than anyone else.

The concept totally makes sense.  As a Network Engineer for that past 22 years, the ability to see what the end users are doing as well as being alerted to “slowdowns” before the phone rings is very cool.  This value alone is worth investing IT budget dollars into but the real value of a solution like this is a “hidden” value.

Most of us engineers have taken calls when things were reported, as “The Network" is slow.   The typical first step is to get your analyzer in place, grab trace files and begin troubleshooting.   The really frustrating thing is when everything looks fine, and the problem just “magically” went away.  I am sure most of you have spent countless hours troubleshooting these types of issues.  I have an old buddy of mine that used to jokingly say, “Well, the Sniffer must have fixed it”.  Why is this the case?  Why do these problems seem to all of the sudden go away once you get your analyzer in place?

 I am going to go out on a limb here and say that most of the time…

THE END USER IS NOT BEING HONEST!!!  Duh!

Ok, well that may be a bit strong but I have seen in countless cases where we are proactively monitoring end user experience that help desk calls go dramatically down when the user knows that you can see what they are doing.

 I had a customer tell me the other day that a user of his was constantly complaining that SAP was slow.

 The user would constantly raise a stink with his management that the “network” was slow and that he couldn't get his work done because of this. 

 The end user knew that SAP was a hot button with management and he could get all kinds of management attention if he just mentioned the word “SAP”. 

 Little did the end user know that their IT staff was now watching every end user transaction on the network!  This time, when he complained that SAP was slow, the network staff pulled up the end user’s transaction report at the time of the supposed “slowdown of SAP” and it showed that the user’s SAP transactions were in the 1-2 second range. 

 On the other hand, his FaceBook and YouTube response times were definitely slow.

 How many hours do you think you have wasted over the years trying to troubleshoot a problem that never existed in the first place?  To the end user, SAP was the same as FaceBook and YouTube.  They were all in the “network”.

Now the fun begins: What do you think happened when their manager saw that SAP was fine but in actuality, what the user was really complaining about was his (non work related) facebook page being slow?

Exactly, no more phone calls complaining that the network was slow from this end user.  Ever!

Good Luck! Have fun Monitoring! Mike.


Continue reading other LoveMyTool posts by Mike Canney »