The Importance of Keeping an Audit History

The Importance of Keeping an Audit History

What is occurring on the cutting edge of network device configuration management?

“Is the configuration data that we have on hand up to date?” Not only is it common to hear these kinds of common questions, there are more and more demands to know the “who, what, when, where, and why” of configuration changes.

These concerns are not as common in a network managed by a single team, but it is becoming a trend in environments managed by multiple teams or vendors. It is seen especially often in the financial industry.

In a network where there are several vendors for each system, segment or branch, the primary vendor or the system manager within the company should manage the whole network. It can very hard for the controllers to monitor every single action of each vendor.
As they cannot thoroughly understand all the details the situation, it results creates a great deal of risk. For example, if a configuration on a network device is changed before someone was aware of it, or if there is a mismatch between device configurations, a network failure can result.

For those cases, if they have a system where they can centralize and manage all the interactions that each vendor did using TeraTerm against the device, it can make the controller’s job easier. There are some advantages using this thorough audit trail management:

 1. When a failure occurs, you can immediately find when it happened and whose operation was the cause of the problem.
 2. Since you can precisely trace the audit trail, you can clearly see who is responsible.
 3. By reviewing the audit trail, you can find weak points in the daily management tasks.
 4. It becomes easy to exchange opinions between different vendors using the same audit trails.

I can’t promise that you will get these advantages in all situations. However, nowadays, as normal performance of the network infrastructure is an essential condition, I think you can see the importance of using an audit trail system.

Kou Sasaoka

Posted in Network Devices | Tagged , , , , , , | Leave a comment

NCCM Tools and System Integrators

NCCM Tools and System Integrators

It’s already the middle of March. Companies that settle their accounts this month might know what their balances are going to be.  Let me tell you a little bit about our company.
LogicVein closes our books in March, too. Fortunately, this term, our company is expecting to do pretty well.  Our NCCM (Network Change and Configuration Management) tool Net LineDancer is making a huge contribution toward this achievement. 

As our products are network monitoring and management tools, we have received inquiries from many system integrators and we have delivered.  As a system integrator’s business is to design and build networks, it is quite natural that they ask about our products when they consider the effort of monitoring and management.

However, I have recently been seeing cases which are unlikely to happen with monitoring tools, like system integrators themselves are the end user of NCCM tools.

Usually, when a system integrator has made an inquiry, it was the end user who paid for the tool. The system integrator has just had to deliver to them. (There are also some system integrators who configure and build our products.)  Starting last year, there are cases where system integrators make a budget themselves, pay for NCCM tools out of their own pocket (or make the budget in an invisible way to the end user), and manage the client’s network which they build.  It sounds natural, when system integrators target a client who wants to outsource not only the design and architecture but also the operation and maintenance of the network.

Of course, I don’t have any idea about the personnel expenses of system integrators.
I just imagine that some of them choose to introduce NCCM tools, as they can provide stable and reasonable operation and maintenance services, comparing the costs of putting in their resources against utilizing the NCCM tool.

We have been having a good relationship with many sorts of end users thanks to system integrators.  And now, especially with respect to NCCM tools, I feel system integrators can also be our end users.

Kou Sasaoka

Posted in Network Devices | Tagged , , , , , , | Leave a comment

Software Defined Networking, commonly called SDN.

Software Defined Networking, commonly called SDN.

Since the end of 2013, I felt more than ever before that there are needs for SDN in the market. This word makes you think of virtualization of networks or OpenFlow. In my opinion, I define it literally as “manage a network using software” or “devices for a network management by software”.  This terminology is now in vogue for those who are in the networking industry. However, it hasn’t been put into extensive practice yet, with the exception of certain companies like Google.  Let’s take a look at the current state of SDN.

There are some up front issues with the adoption of SDN.  People often mention that SDN is a bit of an over-the-top solution. We can expect that network device costs become lower by introducing OpenFlow. On the other hand, an OpenFlow controller costs at least $1,000 now. (It can be more than 100 million units, depending on a scale, which can be a considerable cost.)

It seems nice when we only look at the pros like its convenience and efficiency. However, as we do not know exactly how its performance will be, many of us ask the question, “Can we get good results on such a large investment?” and then hesitate.

In these circumstances, some people guess they can get similar advantages of SDN, not by using SDN OpenFlow controller but by taking advantage of configuration management tools for network devices and monitoring systems.  For example, if any alerts occur on the network monitoring system, the network management tool issues a command to the network devices to verify the collection of configuration information and connection status.

Customers consult us more than ever about the current operational load of network management. They think they don’t have to fully automate it, but at least they want to automate the preliminary investigation and identification of the extent of ramification.

Someday, SDN will come into worldwide use and we will be able to get controllers at reasonable prices. However, when I think of the very first day when SDN appears, I guess there still are opportunities for a while for network device management tools. What do you think?

Kou Sasaoka

Posted in Network Devices | Tagged , , , , , | Leave a comment

Management Issues with Free Tools and Homegrown Scripts

      Management Issues with Free Tools and Homegrown Scripts
      We covered manual network management with original folders in our last blog article. Now, lets cover the 2nd and 3rd most common systems for network configuration management: open source free tools and homegrown scripts.
      Companies with plenty of technical human resources have a tendency use free or homegrown tools, because the initial cost is free.  In fact, if they build from those tools, they can cover almost everything an enterprise tool can do, such as acquisition of configuration changes from devices.  However, when I ask how the operators felt about managing these initially free tools, their answer is far from positive.
      One of the reasons is that the original creator of the tools creates them for their own personal use.  They create them for themselves, designed for the way they specifically prefer to work.  As a result, other people may not be able to handle them effectively. Even when the author is satisfied with them, that doesn’t guarantee that other users will have the experience.
      When I visited one of our customers, he told me a similar story with an embarrassed smile. He couldn’t mount a protest about their homegrown tool (and has been obligated to manage it), because it was created by one of his superiors.
      Since there are many network devices for each vendor, if they replace with a new one, they have to upgrade their tools. In addition, they have to upgrade the OS every time they find some vulnerability in their managed devices.
      The management tools for network devices tend to require a high frequency of maintenance and huge work. That is a big issue, comparing with the other sorts of tools.
      I often hear that the tools get in the way of the operators work.  The tool itself, which is supposed to help with management, causes a problem. That is a scenario that I bet everyone wants to avoid.
    Kou Sasaoka


Posted in Uncategorized | Tagged , , , , , | Leave a comment

Methods for and Issues With Manual Configuration Management

Methods for and Issues with Manual Configuration Management

In the last blog article, we covered the typical management of network devices.  Now, let’s explore the #1 most commonly used pattern.

I will take one major system integrator as an example of actually managing network devices with this pattern.

      This system integrator has a wide range of customers, both private and public organizations. They installed shared servers for saving configurations and support their customers by sorting folders like the image below:
      Root: Customer Name
      2nd Layer: Item Name
      3rd Layer: Work Execution Date
      4th Layer: Actual History Data
      In the history data for the 4th layer, there is configuration information for before and after the change, latest configurations for devices, trace data, and an estimate for each work.
      Basically, this is simple workflow where they only store document files, such as Text, Excel, and PDF, to the specified folders.
      However, issues lurk in this ordinary, routine work.
      1. Occurring mistakes
      It depends on how many items each person has, but if one person has a lot of items, he has to manage more than several hundred folders, large and small.
      Consequently, there are problems such as: data is saved in wrong folder, latest configurations not being up to date, and unnecessary files are overwritten.
      In addition, this type of mistake is hard to discover immediately at the time the mistake is made. When they refer back to the saved data they will notice the mistake, but in many cases it is too late to fix the problem. This type of mistake can be a nightmare.
      When a device is replaced or restored, they load the data from the latest configuration. If the saved configuration is actually old, the connection will fail.  This case still occurs at the site.
      2. Establishment of business continuity
      There are certain rules for the saving files to server and management policy (i.e. unifying the layer of the management folders, format of saved file names).
      However, they sometimes ignore the policy temporarily because they think they will fix it later and move forward with the operation. In the end, however, they may forget to go back and fix it.
      When someone fills in for a short time, or responsibility is handled off to a successor, it is hard for them to smoothly take over the data.
      If these things pile up, folder management with too much originality becomes an issue.  Bottom line: it’s never okay to have inconsistencies in network management systems. Even when the data is still okay, the credibility and validity of the stored data may start being doubted.
      Kou Sasaoka


Posted in Network Devices | Tagged , , , , , | Leave a comment

Configuration Management of Network Devices

 What is happening with your Network Devices at your operation sites?

LogicVein’s (LVI) premiere software solution, called Net LineDancer, dramatically simplifies the work of management and operation of network devices. Nowadays, it is no exaggeration to say that network devices are infiltrating all enterprise and organizations. And of course, it is not enough to purchase and install these devices. You are also left with the management and operation of these devices after installation. I will be writing weekly about how the administrators in various industries approach these operations, what kind of issues they are facing in daily operations, and what trends can be seen on the front line of operation management.
Network Configuration
      We ran an informal poll, asking customers,“How do you operate the configuration management of your network devices?” Here’s what we found:
      ■1st (about 40% of all answers, especially administrators in manufacturing and logistics answered.)
      ⇒Whenever they change configurations of devices, they drop them in a text file once and store them in the prescribed server.
      ■2nd (about 25% of all answers, especially administrators of MSPs, data centers, and carriers answered.)
      ⇒They installed an enterprise tool or OSS tool and manage the configuration of network devices.
      ■3rd (about 10% of all answers, especially administrators of small enterprises answered.)
      ⇒They created a script which acquires configurations from devices at fixed intervals and manage them.
      There are other answers such as outsourcing operation management to system integrator or doing no management, but most of administrators fell into one of the three most common approaches.
    Next time, I would like to continue the topic about the top 3 answers, more detailed operation methods, and the issues which each approach is currently facing.


Posted in Network Devices | Tagged , , , , , , , | Leave a comment