Monday, November 18, 2024

Measuring DNS Response Time

 Before I start, I want to acknowledge a few things:

-          Yes, there are utilities out there that can do this

-          Yes, you can look at DNS response time in the Statistics->DNS report

-          Yes, you can graph this in Wireshark’s IO graph

 

There a lot of benefits of doing it this way since you can customize your charts, which may not be possible with the other options and you get a better understanding of what you are reporting.


In the video, I start at the command prompt with nslookup, move on Wireshark covering capture filter, adding a column, creating a display filter and then exporting the trace to be used by Excel.


As I mentioned in the video this technique can be used with all sorts of other protocols when troubleshooting or documenting performance.



Friday, November 15, 2024

Enter at Your Own Risk

 

My ISP has been pestering me lately, claiming that my equipment is outdated, and I am not taking full advantage of the higher data rates available on my current Internet plan. I was skeptical, as always, that this was another ploy to sell me less for more – just how bad could my 14-year-old modem/router really be? I finally caved in, and on a recent Friday morning I told my wife that our Internet would be down for about an hour while I set about installing the new WiFi mesh system.


When I called the ISP’s 800 number to register the new equipment, I sent them a screen shot with Model, Serial Number and MAC address for the modem to avoid errors. It took several attempts before they claimed victory. They had found my box, the install would soon be complete, and we would be connected to the world once again. Except that we weren’t.


Assuming that the Internet coax was now live, I turned next to tech support for the new hardware. Those of us who have done these installs understand that each step begins with the warning “this process may take a while.”  After a lengthy online session with hardware tech support, they finally concluded that the problem must be with the ISP. I was about to explain why that could not be true when the “outage” notice arrived on my phone. The estimated time to restore service was 4:20 pm – then 7:20 pm – then 11:20 pm. When I awoke the next morning, there was another message, confirmed by my neighbor, that the Internet service had been restored.


The ISP, which by now had taken a lot of heat for the lengthy outage, dispatched a technician to our home. After another hour or so of plugging, unplugging and sharing dog stories while staring at blinking lights, the technician called tech support, and the two of them finally found the problem – the MAC address (a series of 6 pairs of hex characters separated by colons) was supposed to end in “B” but had somehow been entered as “E”.  The “E” address was the router, which the ISP could identify, but not ping. Of all the things that have to work together for a functioning home Internet, it only took one small “E” to bring down the system.


As dependent as we are on keyboards and screens, it is a small wonder that this type of “typo” hasn’t caused more problems. Typos actually have quite a history of impactful effects.


In the 17th century (long before keyboards, when type was set by hand) about 1,000 copies of the King James Bible were printed with the Seventh Commandment as “Thou Shalt Commit Adultery.” Many readers were pleasantly surprised by the omission of “not,” but King Charles was not amused. He successfully destroyed all but about 20 copies, which are now coveted collectors' items. The long-term impact of what is now known as the “Sinners Bible” is not recorded.


On July 22, 1962, just minutes after the launch of the Mariner 1 spacecraft mission to Venus, the rocket was destroyed because it was deviating from the planned course. Initial reporting blamed a missing “-“ in the software coding, while NASA later said a diacritical for the symbol R in an equation had been omitted. Regardless of the cause, the mistake cost around $180 million in today’s dollars. Science Fiction author Arthur C. Clarke called it “the most expensive hyphen in history.”


Prior to the dedication of the Lincoln Memorial in 1922, a critical typo was discovered in the engraving of Lincoln’s Second Inaugural Address – a sharp observer noted that the phrase “WITH HIGH HOPE FOR THE EUTURE” (sic) made no sense. It was corrected by filling in the bottom of the letter “E” to make an “F.” The mistake is still visible to this day. Google the word “euture” for details.


In 1996, Google co-founders Larry Page and Sergey Brin were pondering a name for their new search engine. Thankfully, they moved on from their first choice (“BackRub”) to Googol (short for the number one followed by 100 zeroes). A colleague checked the availability of that domain name, but mis-typed it as “google.com.” The name of the world’s most popular search engine began with a typo.


The letter “E” is a factor in many typos, which is not surprising given it is the most common letter in the English language. This brings to mind an adage with disputed origins that has often been attributed to aerospace engineer Edward A. Murphy. The phrase arose from an accident involving rocket sled testing around 1949. Murphy’s original comment was “If there are two or more ways to do something and one of those results in a catastrophe, then someone will do it that way.” At a post-incident press conference, John Stapp – head of the test project – summarized his presentation with the succinct and now commonplace “Anything that can go wrong, will go wrong.”


Computers and keyboards are now commonplace. The power of even one typo is worth considering before taking the risk of hitting “Enter”.


 

Author Profile - Paul W. Smith - leader, educator, technologist, writer - has a lifelong interest in the countless ways that technology changes the course of our journey through life.  In addition to being a regular contributor to NetworkDataPedia, he maintains the website Technology for the Journey and occasionally writes for Blogcritics.  Paul has over 50 years of experience in research and advanced development for companies ranging from small startups to industry leaders.  His other passion is teaching - he is a former Adjunct Professor of Mechanical Engineering at the Colorado School of Mines. Paul holds a doctorate in Applied Mechanics from the California Institute of Technology, as well as Bachelor’s and Master’s Degrees in Mechanical Engineering from the University of California, Santa Barbara.

Wednesday, November 13, 2024

Wireshark Packet Capture Limits on Linux Real-Time OS (Carlo Zakarian)


 There are a lot of dedicated hardware-based packet capture devices available that can capture at 1Gb and 10Gb line rate.  These hardware-based devices are designed with real-time Operating Systems, and specialized ASIC NICs with large buffer spaces to write to disk.  This method of acquiring packets guarantees that you will catch all of the bits going across the wire without dropping any of them. These are among the best to use when capturing on a very busy network, however, they come at a higher cost for a good reason.

When looking at the long list of options for capturing packets, most analysts prefer to use a laptop coupled with Wireshark.  The simple fact is that a laptop with Wireshark is convenient, it’s also very portable, cost-effective, and easy enough to use for an analyst.  The problem though is that most laptops and Operating Systems cannot capture at full line rate on a busy network.

However, what if there is a slightly better-performing Operating System out there?  RTOS or better known as Real-Time Operating System in Ubuntu kernel is perfect for those demanding low-latency requirements.  Ubuntu LTS with Real-Time capability can be a possible solution for low-latency captures.  Today, I will evaluate Wireshark on Ubuntu LTS with Real-Time enabled. 

Follow along with me as I use a Netscout Optiview XG traffic generator and blast unicast frames against our laptop with Ubuntu Linux RTOS.  We will test different frame sizes, utilization, data rates, and see how well it will perform under various conditions.  We will also examine at what data rates our Ubuntu Linux RTOS will begin dropping packets and compare those against our Ubuntu Linux running in normal run-time kernel. 



Monday, November 11, 2024

From the net:Understanding the Basics: L2VPN vs L3VPN

 


Understanding the Basics: L2VPN vs L3VPN
It is important to understand the difference between Layer 2 VPN and Layer 3 VPN services when traffic is going through the Service provider's MPLS network.

Saturday, November 9, 2024

from the net: NetAlly’s 3 Speed Tests Explained: Pick the Right Tool for the Job

Introduction

NetAlly offers three distinct network speed test applications as part of the AllyWare™ common technology platform, each designed for a specific use case. Most people will only need one, but understanding the differences will help ensure you’re using the most effective application for the job. Whether you’re verifying a cable, assessing endpoint capacity, or pushing your wired network to the max, the right tool can make all the difference.

NetAlly’s Performance Test Application

click on the image to read the article


 

Popular post