Troubleshooting HTTP 503 Issues

 I have mentioned in the past that you should really look ‘under the hood’ as far as application communication goes.

I have seen many web applications that ‘work’ but not ‘work well’. if you dig in, you may find error messages or logs. Errors can caused many different ways;

• Application - Messages are entirely application based and are addressed by the application team or vendor.
• Sending commands with no authentication, wait for the error message, then resend the same command but this time with authentication
• Using small packet or data payload sizes
• Inefficient multi-tiered server architecture
• Login processes that constantly download application files without checking if you have them already 
• References to servers that are de-commissioned or only used for testing/development
• Network – Messages generated by the network devices that can affect application performance and are addressed by the networking team, like ICMP redirects
• MTU issues caused by different network topologies, firewalls, routers or load balancers
• Blocked ICMP error messages that the application needs to make proper adjustments, like MTU and routing

The Meaning of Old

Most of us grasp the meaning of “old” but putting it into words can be challenging. When it comes to people who might be old, there are plenty of euphemisms to choose from. Senior, elderly and senior citizen come to mind, while terms like curmudgeon or geezer are available when appropriate. According to Webster’s, old is something that dates from the distant past, is distinctly different from something similar of an earlier date, has existed for a specified period of time, is advanced in years or shows characteristics of age. Old, it seems, is relative.

Rotary dial telephones are old technology, but at what point will smart phones be consigned to the “old” bin? The same can be said for CRT displays, computer punch cards, vacuum tube radios, phonograph records, Video Cassette Recorders and so on – the replacements for all of these are also living on borrowed time. New will always be fleeting, while old is permanent.

Baselining, No Problem

Not a week goes by without an email from someone asking me to how to create a baseline or worse, requests to review their baseline. I will explain both points before moving on.

Asking how to create a baseline

Spoiler alert, there is no real baseline ‘standard’ or ‘template’ that will meet all your needs. Of course there are typical things that you always document, but after that, it gets very specific. Everyone will use the same software differently.

A great example is Microsoft Outlook, a sales person will use the contacts like a CRM with conversation notes and follow up dates, where an IT person will use the same contacts feature to simply record contact info.

This is precisely why I usually ask the I.T. specialist to spend a little bit of time with the user to determine how they use the software, basic tasks, etc before capturing packets.

Requests to review a baseline

So You Want To Be A ...

 

As the prospect of retirement begins to appear on the outer edges of my radar, I’ve been reflecting on this engineering career that has occupied a large chunk of my adult life. It’s been a rewarding journey and I have no regrets, but what was it that excited me about engineering in the first place?

I don’t believe it was genetics; my Dad was a Professor of Speech and Drama, and my Mom was a schoolteacher who chose to stay at home once I was born. I don’t recall lying in my crib staring at some dangling toy and thinking “I can do better than that.” It’s safe to conclude that I wasn’t born for this profession. If not nature, it must have been nurture.

Finally! It's easy to capture long term.

 "Long term packet capture" and "ease of use" are concepts that rarely go in the same sentence.

Usually, long term packet capture means one of two things. 1) Buy a glitzy, massively expensive, petabyte capture solution that streams a zillion bits per second to disk. 2) Use Wireshark or tshark to do a rolling capture buffer that captures a bunch of files with a dizzying amount of detail.

And then - there was IOTA.

Plug in, power up, press capture. Done.

With the IOTA, long term capture is finally easy - not just to capture, but to analyze as well. Within a few minutes of capturing packets on my home network, I was able to detect and troubleshoot a DNS problem that my wife has been experiencing with Amazon Prime Video for months! (My roku was doing a round robin on DNS and using an internal DNS address that it was not advertising).

Another problem with long term capture is the analysis part.

Oftentimes a long term capture means that we need to comb through a mountain of data, hoping to using the right combo of filters to find the root cause. The analysis part is another area where IOTA helps to make things easy.

The dashboards make packets readable. Protocols, utilization, and conversations are easy to select, sort, filter, and analyze. We can even pull the packets back to Wireshark with a click of a button.

I am really looking forward to using this tool in my analysis work and posting what I learn. For now, the first lesson I would like to share is how simple long-term capture can be. It doesn't have to come from a crazy-expensive platform, nor do we need to do use lossy hardware (laptops and span ports) to bring in the packet truth. This method of analysis is plug and play, getting you the detail you need to fix problems quickly.

Want to know more about Iota 1G and 10G - https://www.profitap.com/iota-1g/