430 posts categorized "Test & Measurement" Feed

Making SNMP Secure (by Tony Fortunato)

While working with a client on a problem, I suggested we enable SNMP version 2 on some older equipment to get better visibility while we worked on the problem. He immediately said, “No way!! I read that SNMP is insecure and can cause all sorts of issues”.  SNMP version 3 wasn’t supported by all devices and takes a bit longer to setup.  Since this wasn’t meant to be a permanent solution SNMP v2 will do just fine.

I explained that whatever he read is probably true but it depends how you configure it and how your network behaves with it. Enabling SNMP is a temporary recommendation for the duration of our troubleshooting engagement and we can always turn it off when we are done with it.

I started to draw a simple network diagram of his network and identified that his firewalls don’t allow SNMP from the internet so that possible issue is covered.

I then showed him some Cisco configuration commands to prevent SNMP traffic from devices and networks that we can specify.

The Cisco commands look like this;

snmp-server community notpublic RO 99

The above command enables and configures the snmp service with a read only string of notpublic. The 99 refers to an access list where we control what devices have permission to perform SNMP queries.

access-list 99 permit

With this command we define that access-list 99 only allows devices from subnet

You should test by performing an SNMP query with your network management tool to ensure that is has access but you should ensure that unauthorized devices do not have access.

You can get an idea if your access list is working as well with the following Cisco command;

show access-list 99

Standard IP access list 99

    10 permit, wildcard bits (684 matches)

The same points apply to Microsoft (plus WMI) or other devices.  Take the time to determine how you can get more data from your devices while troubleshooting or baselining.


Continue reading other LoveMyTool posts by Tony Fortunato »

Metadata - We all need it now! (by Darragh Delaney)

Metadata – we all need it now!

Not so long ago, flow analysis was one of the tools of choice when it came to troubleshooting security or operational problems on networks. Many vendors developed tools which could take these flow records and store them in a data base, so that you could get real-time and historical reports.

However, metadata analysis is now seen as the must have pieces of technology for keeping modern networks running both securely and efficiently. Metadata analysis systems typically use network traffic or packets as a data source. You can typically source these via SPAN, mirror ports or TAPs. The clever part of metadata analysis involves data reduction. This is where you take raw network traffic and capture interesting pieces of data like IP addresses, website names or filenames. In some instances, you end up with a 4000:1 compression ratio. For example, if I transfer a 4MB file across the network, I may capture 1KB of metadata.

See your network

The screen shot below from our own (NetFort) LANGuardian system is a good example of this data reduction.


Continue reading "Metadata - We all need it now! (by Darragh Delaney)" »

Tip When Using Wireshark's RTT Graph (by Tony Fortunato)

I want to start by saying that I’ve been using and training Wireshark classes from pretty well day one and appreciate all the hard work that goes into an always evolving product.


In my last article I wrote about Wireshark’s Fileset issue and how to work around it. I was surprised when I received several emails asking me if there were other examples of ‘workarounds’. I also want to explain that I do these write ups so users don’t think they are doing anything wrong and give up learning.

As I’ve mentioned in previous articles, this goes back to my point about learning your tools.  That includes the cool and not so cool stuff. 

A great analogy is that I have an old drill that I love and use for everything. Unfortunately the reverse button broke and I have to use a screwdriver to flip the switch, but I don’t care because I know exactly how to use it.

Continue reading "Tip When Using Wireshark's RTT Graph (by Tony Fortunato)" »

Tip When Capturing Remote Traffic (by Tony Fortunato)

The trick to successful protocol analysis is the ability to spot patterns. Unfortunately patterns are usually intertwined between many other packets and untangling them is challenging at best.

This is where filters come into play. Capture or Display filters help you find those patterns.

The skill of protocol analysis is determining what filter to use. I use the word ‘skill’ intentionally since we all have access to the same filters but its how you use those filters what make Wireshark and the analyst effective.

In this video I explain what capture filter to use when you want to capture packets from remote devices. By filtering on your routers mac address, you will see all remote packets.

When using technique, the analyst should be familiar enough with their network architecture and understand how load balancing configurations may change the routers mac address, etc..


Continue reading other LoveMyTool posts by Tony Fortunato »

Understanding Network Visibility Use Cases! (by Keith Bromley)

Understanding Network Visibility Use Cases!


Network visibility is fast becoming a key component of network and security planning. This is because network visibility is more than just network monitoring. It is about understanding the network—how is it actually performing, are there any current problems, where do future pain points lie, and how do I optimize my resources?  IT’s fundamental challenge is to ensure that the infrastructure beneath their applications is reliable, fast, and secure.

As we all know, network blind spots get in the way. Common sources of blind spots include:  Silo IT organizations, SPAN port overloading, rogue IT, SSL encrypted data, data overload of monitoring equipment, and network and equipment complexity. These blind spots directly correlate to network problems and outages, increased network security risk, and potential regulatory compliance issues.

Encrypted data further exacerbates the situation. According to a Bluecoat infographic, half of all network security attacks in 2017 will use encrypted traffic to bypass controls. In addition, internal and external SLA’s and customer quality of experience have become increasingly important for IT. These requirements are forcing IT to gain an even better insight and understanding of the network to maximize performance. What no IT team wants to find out is that all of their assumptions and architecture designs are based on incorrect or missing data. When this happens, it results in higher solution costs, confusion, rework, customer dissatisfaction, performance problems, and unplanned outages.

Continue reading "Understanding Network Visibility Use Cases! (by Keith Bromley)" »

The Benefits of Link Failure Propagation in High Availability Networks (by Joshua Yancey)

The Benefits of Link Failure Propagation in High Availability Networks

Network failures are going to happen. This unfortunate fact is probably why the industry standard for High Availability (HA) Networks is not 100%, but rather the "five nines", or 99.999% availability. To achieve this lofty goal, most HA networks use Link Failure Propagation (LFP) in their network design to ensure that their up-time is as close to continuous as it's possible to get.

Typically, systems that require high availability rely on a primary network to run things normally with a backup network standing by to step in should the primary fail for any reason.

Link Failure Propagation

          Propagating failure might seem like a strange thing to want, but in a network system, when a single link goes down, it could jeopardize all the other connections as well without alerting admin. In LFP, that single failure results in the entire operation being moved to the backup system immediately, resulting in less downtime.

Gigabit copper TAP

Continue reading "The Benefits of Link Failure Propagation in High Availability Networks (by Joshua Yancey)" »