Weekly Network Knowledge Challenge QUIZ from The Network Heroes! (by: The ProfiTAP Team)

For the next 14 weeks the Network Heroes will be asking you the challenge questions.

See if you can answer all 14, correctly!!!

Click here - for the ProfiTAP website Every Monday for the Latest Question! - Click here!

Chris GreerChris heroChris is the Founder and  Chief Network Analyst for Packet Pioneer LLC

Supporting clients in several regions of the USA, Latin America, and the Caribbean, Chris assists IT professionals in resolving the root cause of network and application performance problems.
Chris also develops and delivers Network Analysis and Troubleshooting courses featuring analyzers such as Wireshark. 
Chris is also a founding and still a writer for WWW.LoveMyTool.com

Continue reading "Weekly Network Knowledge Challenge QUIZ from The Network Heroes! (by: The ProfiTAP Team)" »


Solving Network Issues - Machine Learning - The IT Sorcerer’s Apprentice! (by John Kerber)

The IT Sorcerer’s Apprentice!

It_apprentice

Machine learning seemed an odd fit at first. Our company was formed as a simple network discovery tool, as reliable and useful as a carpenter’s hammer. If you don’t know us at Who’s On My WiFi, we started off by offering a platform-agnostic ARP scanning tool to discover connected devices on a network over time.  Our company path changed drastically when we started saving all the information we were scanning.  We made an important discovery: WWW.WhoIsOnMyWiFi.com

Large amounts of network data is useless without some way to make sense of all that information!

For example, the first problem people tried to solve using our software was detecting if an unknown device suddenly joined the network.

We initially required that customers tag devices as KNOWN, and then they could be alerted to any UNKNOWN devices.  But there is a problem with this, especially on larger networks.  Tagging devices is time-consuming and requires constant updating to be useful. Our customers’ IT managers would be tasked with tagging staff and network devices, while reporting on guests that entered their building. It was an up-front workload compounded by the inevitable influx of new devices or [shudders] network equipment overhauls.

The next problem people started solving with our basic network detection was trying to determine the number of people using a public WiFi network over time.  Although this sounds simple, to get accurate usage patterns, again, there is an up front cost of going through and tagging all equipment that could possibly be on a public WiFi network to exclude it.  Otherwise, always on devices like network equipment or printers incorrectly impacted the results.  And what about employees using the public WiFi?  Should they be counted as visitors or not?

To painstakingly go through a large public venue, tag all switches, APs, as well as employee equipment and smartphones was too much maintenance for IT administrators to keep up with.

Enter Machine Learning. 

 

Continue reading "Solving Network Issues - Machine Learning - The IT Sorcerer’s Apprentice! (by John Kerber)" »


4 Ways to Transform Your Packet Capture Workflow (by Zach Chadwick)

When there is a technical problem here at QA Cafe, like you, we go straight to the packets.

 

We’ve been building test solutions for network devices since CDRouter debuted in 2002. Over that time we have learned that the sooner you can put a trace file of a problem in front of someone, the sooner they’ll be able to give you an answer about it.

 

CloudShark Enterprise grew out of our own need to manage and communicate around network capture files. Along the way we’ve learned some best practices for packet capture management. By prioritizing sharing and collaboration, these approaches will transform your workflow to make packet captures work for you.

  Cloudshark-gerald-quote

 

Continue reading "4 Ways to Transform Your Packet Capture Workflow (by Zach Chadwick)" »


LMTV with Christian Ferenz - Why you need a modern Packet Broker – The evolution of Packet Broker features!

LMTV special with Christian Ferenz

Why you need a modern Packet Broker?

Special focus on the evolution of Packet Broker features and how they enhance network performance and security monitoring

 https://youtu.be/go4t1CXJDM0 

In today’s world of large and complex networks, enterprises and carriers often find it challenging, if not overwhelming, to manage their networks, minimise outages, and troubleshoot performance issues. All data centres and enterprises MUST look to secure and manage their growing network traffic demands, improve productivity, and reduce MTTR by having complete network visibility. An estimate from Gartner reveals the hourly cost of downtime for computer networks at $42,000.

Here are some more figures for network downtime.

  • 98% of organisations say a single hour of downtime costs over $100,000
  • 81% of respondents indicated that 60 minutes of downtime costs their business over $300,000
  • 33% of those enterprises reported that one hour of downtime costs their firms $1-5 million

*Source: Information Technology Intelligence Consulting Research

Network outages can result in millions of dollars per hour losses. A lack of visibility can lead to domain-based 'blame games' between different operational departments; Network Engineers pointing the finger at the Security Team while they, in turn, are holding the Developers accountable. When each department is collecting information from their own individual sources that data can be confusing and contradictory because no one has the complete picture. Network outages and network downtime are costly for business because its real value is much more than you see.

A Network Packet Broker (NPB) is necessary to ensure that everyone has complete access to the network and that every monitoring and security tool has all of the data required to properly perform its function. Network Packet Brokers have traditionally been used to aggregate and distribute network traffic to various network appliances; filtering and load-balancing the traffic to optimize it for each tool’s requirements.  Handling network traffic at OSI Layers 2-4 has been instrumental for organizations in avoiding costly downtime and gaining the visibility and insight needed to deal with sluggish application performance, unexpected outages, security issues, and network failures.

As modern networks continue to evolve, with exponentially growing bandwidth speeds and increasingly distributed infrastructure, so too must the Network Packet Broker evolve. An increasing number of monitoring requirements are no longer sufficiently addressed by L2-4 filtering criteria so a more advanced and granular approach must be taken to handle network traffic at the Session layer and above. This is the need that Cubro’s cutting-edge EXA platform and next-generation G5 Packet Brokers were designed to fulfill.

Visibility!! Easy and accurate Focused Visibility… If you cannot see, you will never know, Our Motto!!


Why Bother with Ethernet Cabling. (by Tony Fortunato)

I think there is a balance between doing it yourself and calling the professionals. If it’s a straight forward manageable task and you have the correct tools and knowledge, why not.

For example, I wouldn’t climb an 80 foot tower, pull and terminate 120 pairs of Ethernet cabling or try to terminate fibre connectors.

While working onsite I was asked “Why bother?“ or “We’ll get someone else to do that”. Some people feel that some network tasks are too menial or beneath them. I’ve had some network technicians ask why I would bother doing ‘that kind of work’ when you have had various certifications.

There are many answers; I like the variety, I enjoy keeping my skills sharp, and the job gets done quicker. I find I can add more value to a design or install since I have physically done the work as opposed to just reading the materials. The bonus is that when I watch people do incorrect installations, I have more things to look for when troubleshooting problems.

Here’s a simple example: we had to pull and terminate 3 Ethernet cables as part of an install. The technician said “let’s just call the cabling company to do it”. I asked how long that would take and he responded 2 to 3 days. I reminded him that I was only there for the day and added that it would not take us long to pull three cables 20 feet and terminate them ourselves. The cables were a straight run in the cabling trays above our heads.

Just a quick disclaimer; if you have no experience terminating cables, do not practice or learn on your production environment. Fortunately I have been terminating Ethernet cables for over 20 years, so this is a fairly simple process. I went to my vehicle and got a spool of cable, some RJ 45 connectors as well as my crimper. Fortunately, I had assumed that I might need to do this type of work and had prepared myself with the proper supplies and my vehicle.

Flashback; I will never forget working with network consultants at a new build and I was the only one with tools, a hard hat and my government safety certificates, even though everyone was told this is a construction area. The other consultants  were limited when, and where they could work where I had the run of the place.

Continue reading "Why Bother with Ethernet Cabling. (by Tony Fortunato)" »