Boštjan Šuštar, an internetworking expert at NIL Data Communications, in his fifth article about IPsec implementations in Cisco IOS, explains GET VPNs and their predecessor, the Tunnel Endpoint Discovery (TED). Boštjan first provides an overview of the requirements, advantages and disadvantages of TED and then focuses on GET VPNs. He describes the control plane (full-mesh topology for user data) and the data plane (hub-and-spoke topology for IKE control sessions) of the solution. Special attention is given to high availability, performance and scalability as the key server can easily become the central point of failure. Design recommendations and configuration examples are provided as well.

View article

More NIL IP Corner articles

Boštjan Šuštar, the Internetworking Expert at NIL Data Communications, in his fourth article about IPsec implementation in Cisco IOS, explains the Dynamic Multipoint VPNs (DMVPN). To some degree, DMVPNs mimic the older technologies, providing for the use of proven design choices (e.g., routing), but there are important differences to consider. Although the DMVPN is a combination of three technologies (IPsec, multipoint GRE tunnels and Next-Hop Resolution Protocol [NHRP]), it is implemented in a way that includes more intelligent interaction between these technologies, providing better resilience, performance and stability. Boštjan addresses the simple implementation as well as all enhanced options of DMVPN in his article.

View article

More NIL IP Corner articles

Obviously, we’ve reported the problem to Cisco TAC, which managed to reproduce it, and then passed the ball to development (there is no workaround). In the meantime, NIL’s customer would like to migrate the production network to the new (just purchased, faster, more expensive) devices, but is not willing to take the risks. Would you risk the network outage that could be caused by an unexpected router crash or power failure, if you already know that the router won’t work until someone fixes the configuration and reloads it?

After waiting for a few days with no visible results, NIL decided to develop a workaround based on EEM and Tcl. We’ve implemented an EEM Tcl policy that detects changes in startup configuration and removes the offending lines. Another EEM policy is triggered after the reload; it adds the missing configuration commands, resulting in a perfectly working network. With a reliable and tested workaround in place, we can continue the network deployment while waiting for Cisco to fix the bug.

If you’re faced with a similar problem and need NIL’s help in developing/deploying embedded solutions, get in touch with our Professional Services team.

Note: in the meantime, Cisco has provided an interim image with the fix (works flawlessly) and  we’ve discovered that the bug affect only dynamic crypto-maps, giving the customer and our engineers at least three viable options: upgrade to the interim image, change dynamic crypto-maps into static ones or use the EEM-based solution.

Recently a customer reported high packet delays between his central site and one of his remote sites. These two sites were connected over the Internet by secure IPSec tunnel, while some local traffic was destined directly to the Internet. Examination revealed high packet delays during certain times of day for traffic transmitted over the IPSec tunnel, whereas traffic transmitted directly to the Internet (i.e., ICMP, TCP, UDP) – and not secured by the IPSec tunnel – was not subject to high packet delays at any period of the day.

At first I thought that something might be wrong with the customer’s networking equipment, or that the customer was generating a high amount of traffic at certain times of the day. But a few weeks previously we had placed the customer’s network into the NIL Monitor system, which could provide long-term network statistics (e.g., interface and other resource utilization, packet delay, and so on). Looking at the statistics, I was astonished by the following graph, which revealed daily changing of packet delays over the previous month. After checking RAM usage and interface utilization, I determined that the problem was not in the customer’s network, but rather in the service provider’s network.

Because only encapsulated traffic encountered high packet delays, it was obvious that the encapsulated traffic (protocol ESP) was subject to quality of service issues in the provider’s network. After I informed the customer, he asked the service provider to fix the problem. At first, the provider insisted that nothing on his end would contribute to high packet delay. But after reviewing the previous graph, which revealed the periodic nature of the traffic delay, the service provider immediately solved the problem. The following graph speaks for itself.

Sometimes we need to take a few steps back when we can’t see the forest for the trees. I found NIL Monitor to be a powerful tool that helps me to see the whole problem from a distance, contributing to faster and more efficient problem-solving and finally to a higher level of customer satisfaction.

Boštjan Šuštar, the Internetworking Expert at NIL Data Communications, in his third article about IPsec implementation in Cisco IOS, explains two implementation options of VTI – static and dynamic VTIs. While the first option is similar to point-to-point GREs, the dynamic option is an example of a typical remote-access implementation tool. In large site-to-site deployments the dynamic VTIs simplify management and ensure that the tunnels are always up, thus making this a site-to-site and not really a remote-access VPN.

View article

More NIL IP Corner articles

This is the second in a series of articles describing various methods of implementing IPsec in Cisco IOS.

View article

More NIL IP Corner articles