Secure Shell (SSH) provides a secure and reliable mean of connecting to remote devices. It’s an encrypted network protocol that allows users to safely access equipment via command line interface sessions. SSH makes use of TCP port 22 which’s assigned to secure logins, file transfer and port forwarding.

SSH uses public key for authenticating the remote device and encrypt all data between that device and the workstation which makes it the best choice for public networks, unlike (telnet) which transmits data in plain text which subjects it to security threats, this makes (telnet) recommended for private networks only to keep the data uncompromised.

Verifying SSH Support On A Cisco Router

The first step involves examining whether your Cisco router’s IOS supports SSH or not. Most modern Cisco routers support SSH, so this shouldn’t be a problem.

Products with (K9) in the image name e.g c2900-universalk9-mz.SPA.154-3.M2.bin, support strong encryption with 3DES/AES while (K8) IOS bundles support weak encryption with the outdated DES.

To check, simply enter privilege mode and use the show ip ssh command:

R1# show ip ssh
SSH Disabled - version 1.99
%Please create RSA keys to enable SSH (and of atleast 768 bits for SSH v2).
Authentication timeout: 120 secs; Authentication retries: 3
Minimum expected Diffie Hellman key size : 1024 bits
IOS Keys in SECSH format(ssh-rsa, base64 encoded): NONE

In the above output, the system is showing SSH support, but it’s currently disabled as no RSA key has been generated.  It is also worth noting that a key of at least 768 bits must be generated to enable SSHv2.

Securing Router Access

It’s always a good idea to first restrict access to the Cisco router before enabling SSH. This is very important especially when the device has an interface facing public networks e.g Internet, Public Hotspot.

We first create user credentials for the device and then enable Athentication, Authorization & Accounting Services (AAA).  Finally, ensure a secret password is set to protect access to privilege mode, along with the service password-encryption command to ensure all clear-text passwords are encrypted:

Next, it is highly recommended to restrict remote access via the SSH protocol only. This will ensure that insecure services such as Telnet cannot be used to access the router. Telnet sends all information unencrypted, including username/password, and is therefore considered a security risk.

We’ll use the transport input ssh command under the VTY section to restrict remote access using SSH only. Note that we can also use Access-lists to restrict SSH connections to our router:

Note: the password command used under line vty 0 4 section is completely optional and not used in our case because of the login authentication default command which forces the router to use the AAA mechanism for all user authentication.

Generating The Router’s RSA Key – Digital Certificate

Digital keys serve the purpose to help further secure communications between devices. Our next step involves generating an RSA key pair that will be used by SSH to help encrypt the communication channel.

Before generating our RSA key, it is necessary to define our router’s domain using the ip domain-name command, followed by the crypto key generate command:

R1 (config)#  ip domain-name firewall.cx
R1(config)# crypto key generate rsa
The name for the keys will be: R1.firewall.cx
Choose the size of the key modulus in the range of 360 to 4096 for your General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes. How many bits in the modulus [512]: 4096
% Generating 4096 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 183 seconds)

When generating our key pairs, the router notifies us with the name used for the keys, which consists of the router’s hostname (R1) + Configured Domain Name (firewall.cx).  Finally, we can select the amount of bits used for the modulus (key).

Since we selected to generate a key using 4096 bits, the router took a bit over 3 minutes to generate the key! Note that router used in our example was a Cisco 877.

With SSH enabled we are able to ssh into our router and manage it securely from any location around the globe.

To view any active SSH session, simply use the show ssh command:

R1# show ssh
Connection   Version    Mode   Encryption      Hmac       State             Username
0             2.0        IN    aes256-cbc      hmac-sha1  Session started   admin
0             2.0        OUT   aes256-cbc      hmac-sha1  Session started   admin
%No SSHv1 server connections running.
R1#

This article explained the importance of enabling and using SSH to remotely manage and configure your Cisco router. We saw how to create users for remote management, enable AAA, encrypt clear-text passwords, enable SSHv2, generate RSA keys and verify SSH sessions to our router.

Finally, we've also included a number of useful Embedded Packet Capture troubleshooting commands to monitor the status of the capture points and memory buffer.

Let’s take a look at some of the basic features offered by Embedded Packet Capture:

• Capture IPv4 and IPv6 packets in the Cisco Express Forwarding path
• Ability to specify various capture buffer parameters
• Export packet captures in PCAP format, enabling analysis with external tools such as Wireshark.
• Display content of the capture buffer
• Granularity of captured packets via Standard or Extended Access Control Lists (ACLs)

Figure 1. Understanding Basic Embedded Packet Capture Terminology

Before we dive into the configuration of Cisco EPC, let’s explain the two terms used during the EPC configuration:  Capture Buffer & Capture Point.  We’ll use figure 1 to help illustrate the terms.

Capture Buffer

Capture buffer is an area in memory for holding packet data.  There are two types of Capture Buffers: Linear and Circular.

Linear Capture Buffer: When the capture buffer is full, it stops capturing data.
Circular Capture Buffer: When the capture buffer is full, it continues capturing data by overwriting older data.

Capture Point

Capture point is a traffic transit point where a packet is captured. Capture points need to define the following:

• IPv4 or IPv6
• CEF (Cisco Express Forwarding or Process-Switched
• Interface e.g Fast Ethernet0, Dialer0 etc.
• Direction of traffic to the interface: in (ingress), out (engress) or both

Configuring Cisco Embedded Packet Capture

Figure 2. Capturing packets betwen host 192.168.3.2 and Firewall.cx

Note: None of the below configuration commands, except the optional access lists (filters), will be stored in the router's running-configuration or startup-configuration. 'Monitor' commands are only stored in the router's RAM and are lost after a router reboot.

STEP 1 -   Define A Capture Buffer

The capture buffer will store the packets to be captured. Our capture buffer will be named firewallcx_cap and will have size of 1024KB (1 Mb), which is the default size and will be set to linear type buffer:

STEP 2 – Define The Traffic To Be Captured (optional)

We can optionally configure to capture specific traffic. In our case, we need to capture traffic between hosts 192.168.3.2 and 208.86.155.203 (Firewall.cx).  This is accomplished with the use of access control lists. We can make use of standard or extended access lists depending on the granularity required. If no access list is configured, all traffic will be captured.

Note: Our access list includes traffic originating from both hosts because we want to capture bidirectional traffic.  If we included only one ACL statement, then only one-way traffic would be captured.

Our filter is now in place and we are ready for the next step.

STEP 3 – Define Capture Point & Parameters

Here we define which interface will be the capture point. In our case, this is Fast Ethernet0 and we’ll capture both ingress and egress packets. During this configuration phase, we need to provide a name for the capture point, we selected CPpoint-FE0 to make it easy to distinguish.

Note: It is highly advisable to ensure ip cef is enabled to ensure minimum impact on the router’s CPU. If ip cef is not enabled, a message like the one below will appear, in which case you need to enable ip cef and re-enter the command.

STEP 4 – Associate the Capture Point with the Capture Buffer

Here we associate the configured capture point with the capture buffer:

At this point, we are ready to start capturing packets!

STEP 5 – Start, Stop Capturing Packets

It’s now time to start capturing those packets using the monitor capture point start command:

At this point, the router is capturing all traffic between our two hosts.

To stop the capturing process, use the monitor capture point stop command:

Useful Verification Commands

1. To monitor the status of our buffer, we can use the show monitor capture buffer command:

2. To view Capture Point details, use the show monitor capture point all command:

3. To see all information about the captured packets, use the show monitor capture buffer command:

4. To examine the buffer’s contents, use the show monitor capture buffer dump command:

Export Captured Data

In most cases, the data captured will need to be exported to a network analyzer for additional analysis within a user friendly interface.  

Note: Captured buffer can be exported to a number of locations including: flash: (on router), ftp, tftp, http, https, scp (secure copy) and more.

Export the captured buffer using the monitor capture buffer export command. Keep in mind that we must stop the capturing process before exporting the data, and also have our tftp server ready to accept the captured data:

At this point, the capture.pcap file should be located on our workstation.

We are now ready to import the data into our network analyzer for further analysis:

Figure 3. Importing packets into a Network Analyzer

Once the import process is complete, our captured packets are displayed and we can analyse them in a more user-friendly environment:

Figure 4. Packets displayed inside the network analyzer

This article introduced the Cisco Embedded Packet Capture feature offered on all Cisco router IOS platforms from version 12.4.20T and above. We explained terms used by the Embedded Packet Capture feature (Capture Buffer, Capture Point) and showed how to configured Embedded Packet Capture using 5 simple steps, but also how to export captured data from the Cisco router so that it can be imported into a network analyzer.

If a corrupted IOS image is not identified before the reload/reboot of the device, it’s most likely the device will not boot again unless a special recovery procedure is followed. A corrupt IOS image translates to network downtime, service disruption and possibly financial loss for the company.

Therefore verifying an IOS image that has been uploaded to a Cisco device is a very important step, regardless how experienced one might be.  Unfortunately most network engineers skip or are totally unaware of the image verification process and the trouble it can help them avoid.

Here are a few reasons why Cisco IOS image verification should become a mandatory step during any upgrade:

• It helps ensure the IOS image is not corrupt
• It avoids unnecessary surprises after a router/switch reload - especially when it’s at a remote location!
• It verifies the integrity of the software
• Reduces the risk of malicious code being installed on the Cisco IOS device
• TFTP, the method often used to upload files, cannot guarantee error-free transfers
• Helps maintain your professional image and reliability :)

Using The SHA2/MD5 File Verification Feature

The MD5 File Validation feature was added in Cisco IOS Software Releases 12.2(4)T and 12.0(22)S onwards. This feature allows the administrator to calculate the MD5 hash of a Cisco IOS software image previously loaded on a device's flash.

Newer IOS images and ISR routers now make use of the SHA2 algorithm, rather than the older MD5, however we can optionally verify the image using MD5.

Cisco publishes the MD5 hash value (Checksum) for every software image in their download area. This enables the network engineer to easily check and compare the calculated MD5 hash value against Cisco’s site and identify any signs of tampering.

Below is a Cisco 2921 router that has just had an IOS image uploaded (c2900-universalk9-mz.SPA.152-4.M6a.bin):

Before changing the device’s configuration to load the newly uploaded IOS image, we need to verify its integrity first by using the verify command:

When issuing the verify command, the router will compute and automatically verify the image using the SHA2 algorithm and then compare it against the embedded SHA2 hash.  This verification ensures that the file is not corrupt and has not been tampered with.

To verify the image using MD5, we can use the verify /md5 command as shown below:

Verifying The MD5 HASH With Cisco's Site

As noted in our previously, an additional security check is available for those seeking to fully satisfy their security concerns. Cisco makes the MD5 hash available for every image in their download section, allowing the network engineer to compare the embedded and calculated MD5 hash with Cisco.
 
Using our image c2900-universalk9-mz.SPA.152-4.M6a.bin as an example, we went to Cisco’s download section and located the file. By simply placing our mouse cursor above the filename, a popup window appeared showing the file details where the MD5 Checksum can also be found:

Our calculated MD5 checksum was also cec1428c33bce462346d77445d5a468d, which means we have a Cisco original image that has not been altered or tampered in any way.

This article explained the importance of verifying a Cisco IOS image and the problems this simple step can help avoid. We also explained how to verify the image using the SHA2 or MD5 algorithm and compare it against Cisco’s website.

Another common problem CCP users are faced with is the Java “Memory Heap Size Less than 256MB” error. This error is usually presented to the user when trying to access the Intrusion Prevention System (IPS) configuration section in the CCP configuration menu as shown below:

 To overcome this error, Firewall.cx has outlined an easy-to-follow procedure which can be executed even by inexperienced users.

Requirements To Fix Java Memory Heap Size Error

Dealing with the Java memory heap size error is fairly simple, as long as the correct Java version is installed on the system where CCP is run from. 

It should be noted that even if other versions of Java are installed on our system, the error will continue, until the correct version of Java is installed. 

For this reason, it is imperative Java version 1.6 Update 17 is installed.  Users are not required to uninstall existing versions of Java. Installing the provided Java version and following our procedure, will get the job done.

To help make life easier for its readers, Firewall.cx has made the Cisco Configuration Professional program and Java version 1.6 Update 17 available as a free download in our Cisco Tools & Applications download section.  It is advisable to download and install this Java version before proceeding with the next steps.

How To Fix Java Memory Heap Size Error

Assuming Java 1.6 Update 17 is installed on the workstation, go to the Windows Control Panel and launch the Java (32 bit) Control Panel:

Next, select the Java tab as shown in the screenshot below, and click on the View button to reveal the Java Runtime Environment Settings:

In case more than one Java version is installed, it should appear in this window. As seen in our screenshot, we have version 1.7 Update 25 and version 1.6 Update 17 installed. In the Runtime Parameters for the 1.6 platform, enter the value –Xmx256m or –Xmx512m to increase the memory heap size to 256MB or 512MB, and then click on the Enabled checkbox, as shown below:

Finally click on OK to close the window and save the new settings.

While not necessary, it’s a good idea to restart the workstation and then launch Cisco Configuration Professional.

Visiting now the Intrusion Prevention configuration screen within CCP, should provide proper access to the IPS Configuration Wizard:

Cisco’s CCP is available as a free download from Firewall.cx’s Cisco Tools & Applications download section.

Note: Users experiencing the Java Memory Heap Size Less Than 256MB Error can also read our article on how How To Fix Cisco Configuration Professional (CCP) 'Java Memory Heap Size Less Than 256MB Error' & Java Runtime Environment Settings.

CCP is a versatile and easy-to-use tool. It not only provides the ability to configure your Cisco router but also allows you to monitor its interfaces, CPU memory etc. and manage almost every service available on the router itself.

As with most Cisco configuration tools, CCP requires Internet Explorer to work correctly, ironically this is also where the problem with CCP begins.

When installing the Cisco Configuration Professional application on a system running Internet Explorer 10, users frequently get the CCP application displayed only in about one third of the browser’s window, as shown below:

Obviously, working in such a crammed environment is impossible but, thankfully, overcoming this display issue is fairly simple.

How To Get Cisco Configuration Professional Displayed Correctly

The problem with CCP lies inside Internet Explorer’s compatibility settings. To fix this issue, from Internet Explorer’s menu, select Tools> Compatibility View Settings as shown below:

Next, in the new window, type IP address 127.0.0.1 in the Add this Website field and click on the Add button to insert it to the Compatibility View list:

After clicking on the Add button, the IP address should appear in the Compatibiity View area:

When done, click on the Close button to complete the process.

Now we can launch CCP and it will be displayed correctly within our Internet Explorer web browser:

It is recommended that users with little or no experience on Cisco router VPN client configuration read our Cisco Router VPN Client Configuration article before proceeding.

Restricting access to your IPSec VPN clients (or Groups) is possible with the use of standard or extended access lists, which are applied to the crypto isakmp client configuration group section.

The problem many administrators and Cisco engineers are faced with is even though usage of extended ACLs, defining layer-4 services such as TCP or UDP, is allowed, the router will only apply up to layer-3 access list information. Layer-4 information in the defined access lists is completely ignored.

Layer-4 VPN Access Lists Ignored? What Does this Mean?

To put it simply, if there is a need to restrict Cisco IPSec VPN clients to layer 4 services e.g. http access (TCP port 80) or MSSQL access (TCP port 1433) to an internal server (e.g 192.168.0.6), you’d be surprised to know that even though the vpn group access lists can be defind to restrict access to these services, vpn clients will have full access to host 192.168.0.6 when connecting to the VPN!

The Cisco IOS Router will completely ignore any layer 4 information (TCP – UDP) available in the extended access lists applied to the VPN group.

Let’s take for example the following configuration, designed to restrict our CCLIENT-VPN VPN group to host 192.168.0.6 and TCP ports 80 & 1433:

When a VPN client belonging to the CCLIENT-VPN group connects, he is expected to have access to host 192.168.0.6 and the defined (by the ACLs) services - TCP ports 80 & 1433 - right?  Wrong!

Access lists under the crypto isakmp client configuration group are not filtering access lists. Their purpose is not to control Layer-4 services, but identify the network routes the remote VPN user(s) will have access to. This is also called Split-Tunneling.

It is for this reason the IOS router will allow full access to our host 192.168.0.6.  TCP/UDP services, located on Layer-4 of the OSI model, are completely ignored when defined in VPN group access lists.

As a result, this design or limitation (if you like) is a big problem for many network administrators and engineers as it does not provide the flexibility and granularity required in today’s complex and demanding VPN networks.

The Solution To Making Extended ACLs Work For Cisco IOS VPN Clients – Restricting VPN Clients To Layer 4 Services

Despite the setback, it is possible to control access to layer 4 TCP/UDP services for your VPN groups. The solution involves creating different Virtual-Template interfaces to which the ISAKMP profiles, and therefore VPN groups, are bound. We then create a new set of access lists and apply them to the Virtual-Template in the inbound direction as shown below:

Notice how we still use a set of access-lists (110) for our new group web-sql-group, restricting access to host 192.168.0.6.  These will ensure the VPN group will be able to access the particular host.

Next, we create a new set of access-lists (121) which are placed under the new Virtual-Template3 in the inbound direction.  These are the extended access-lists that do the job.

Keep in mind that these access-lists must always be placed in the inbound direction of the Virtual-Template3 interface, to ensure they work correctly and block other types of VPN user traffic from reaching our network or hosts.

Finally, it is equally important to pay attention to the crypto isakmp profile vpn-ike-profile-2 command, which essentially maps the VPN group with our new Virtual-Template3 interface. If there is a need to create additional vpn groups with restricted access, all that is required is to configure new crypto isakmp profiles and Virtual-Templates along with the necessary access lists as shown by this example.

IPSec VPN tunnels can also be configured using GRE (Generic Routing Encapsulation) Tunnels with IPsec encryption. GRE tunnels greatly simply the configuration and administration of VPN tunnels and are covered in our Configuring Point-to-Point GRE VPN Tunnels article.  Lastly, DMVPNs – a new VPN trend that provide outstanding flexibility and almost no administration overhead can also be examined by reading our Understanding Cisco Dynamic Multipoint VPN (DMVPN),  Dynamic Multipoint VPN (DMVPN) Deployment Models & Architectures and Configuring Cisco Dynamic Multipoint VPN (DMVPN) - Hub, Spokes , mGRE Protection and Routing - DMVPN Configuration articles.

ISAKMP (Internet Security Association and Key Management Protocol) and IPSec are essential to building and encrypting the VPN tunnel. ISAKMP, also called IKE (Internet Key Exchange), is the negotiation protocol that allows two hosts to agree on how to build an IPsec security association. ISAKMP negotiation consists of two phases: Phase 1 and Phase 2.  

Phase 1 creates the first tunnel, which protects later ISAKMP negotiation messages. Phase 2 creates the tunnel that protects data.  IPSec then comes into play to encrypt the data using encryption algorithms and provides authentication, encryption and anti-replay services.

IPSec VPN Requirements

To help make this an easy-to-follow exercise, we have split it into two required steps to get the Site-to-Site IPSec Dynamic IP Endpoint VPN Tunnel to work.

These steps are:

(1)  Configure ISAKMP (ISAKMP Phase 1)

(2)  Configure IPSec  (ISAKMP Phase 2, ACLs, Crypto MAP)

Our example setup consists of the headquarter router R1 which is assigned a static public IP address, and two remote routers, R2 & R3. Both remote routers (R2 & R3) connect to the Internet and have a dynamic public IP address assigned by the ISP, as shown in the diagram below:

Our Headquarters is assigned an internal network of 10.10.10.0/24, while Remote Site 1 has been assigned network 20.20.20.0/24.  and Remote Site 2 network 30.30.30.0/24. The goal is to securely connect both remote sites with our headquarters and allow full communication, without any restrictions.

Configure ISAKMP (IKE) - (ISAKMP Phase 1)

IKE exists only to establish SAs (Security Association) for IPsec. Before it can do this, IKE must negotiate an SA (an ISAKMP SA) relationship with the peer.

To begin, we’ll start working on the Headquarter router (R1).

First step is to configure an ISAKMP Phase 1 policy:

The above commands define the following (in listed order):

We should note that ISAKMP Phase 1 policy is defined globally. This means that if we have five different remote sites and configured five different ISAKMP Phase 1 policies (one for each remote router), when our router tries to negotiate a VPN tunnel with each site it will send all five policies and use the first match that is accepted by both ends. Since we only have one ISAKMP policy, this will be used for all remote VPN routers.

Next we are going to define a pre-shared key for authentication with our peers (R2 & R3 routers) by using the following command:

The peers pre-shared key is set to firewallcx and note that we are defining a remote public IP address of 0.0.0.0 0.0.0.0. This tells our headquarter router that the remote routers have dynamic public IP addresses and ensures it will try to negotiate and establish a VPN tunnel with any router that requests it.

Configure IPSec

To configure IPSec we need to setup the following in order:

Creating Extended ACL

Next step is to create an access-list and define the traffic we would like the router to pass through each  VPN tunnel. In this example, for the first VPN tunnel it would be traffic from headquarters (10.10.10.0/24) to remote site 1 (20.20.20.0/24)  and for the second VPN tunnel it will be from our headquarters (10.10.10.0/24) to remote site 2 (30.30.30.0/24).  Access-lists that define VPN traffic are sometimes called crypto access-list or interesting traffic access-list.

Because we are dealing with two separate VPN tunnels, we’ll need to create one set of access-lists for each:

Create IPSec Transform (ISAKMP Phase 2 policy)

Now we need to create the transform set used to protect our data. We’ve named our transform set TS:

The above command defines the following:  

Create Dynamic Crypto Maps

The Crypto Map is the last step of our setup and connects the previously defined ISAKMP and IPSec configuration together. We will need one dynamic crypto map for each remote endpoint, which means a total of two crypto maps for our setup.

First we create a crypto map named VPN which will be applied to the public interface of our headquarter router, and connect it with the dynamic crypto maps we named as hq-vpn.

The ipsec-isakmp tag tells the router that this crypto map is an IPsec crypto map. Now we create our two dynamic crypto maps using the following configuration commands:

Notice how we create one dynamic map for each remote network. The configuration is similar for each dynamic crypto map, with only the instance number (10 , 11) and match address (VPN1-TRAFFIC , VPN2-TRAFFIC) changing.

Adding additional remote sites in the future is as easy as simply adding more dynamic crypto maps, incrementing the index number and specifying the match address extended access-lists for each remote network.

Apply Crypto Map To The Public Interface

The final step is to apply our crypto map to the public interface of the headquarter router, which is FastEthernet0/1. In many cases, this might be a serial or ATM (ADSL - Dialer) interface:

Note that you can assign only one crypto map to an interface.

As soon as we apply crypto map on the interface, we receive a message from the router that confirms isakmp is on: “ISAKMP is ON”.

At this point, we have completed the IPSec VPN configuration on our headquarter router and we can move to the remote endpoint routers.

Configuring Remote Endpoint Routers (Dynamic Public IP Addresses)

Our remote routers connect to the Internet and are assigned a dynamic IP address which changes periodically by the ISP.  In most part, the configuration is similar to that of the headquarter router, but with a few minor changes.

In the configuration below, IP address 74.200.90.5 represents the public IP address of our headquarter router.

Remote Site 1 Router

Network Address Translation (NAT) & IPSec VPN Tunnels

Network Address Translation (NAT) is most likely to be configured to provide Internet access to internal hosts. When configuring a Site-to-Site VPN tunnel, it is imperative to instruct the router not to perform NAT (deny NAT) on packets destined to the remote VPN networks.

This is easily done by inserting a deny statement at the beginning of the NAT access lists as shown below:

For the headquarter router, deny NAT for packets destined to the remote VPN networks, but allow NAT for all other networks (Internet):

For Remote Site 1 Router, deny NAT for packets destined to the headquarter network:

For Remote Site 2 Router, deny NAT for packets destined to the headquarter network:

Bringing Up & Verifying The VPN Tunnel

At this point, we’ve completed our configuration and the VPN Tunnel is ready to be brought up.  To initiate the VPN Tunnel, we need to force one packet to traverse the VPN and this can be achieved by pinging from one router to another.  There is however one caveat that was mentioned in the beginning of this article: 

The reason for this is simple and logical. Only the remote site routers are aware of the headquarter’s public IP address (74.200.90.5) because it is static, and therefore only the remote router can initiate the VPN tunnel.

From Remote Site 1, let’s ping the headquarter router:

R2# ping 10.10.10.1 source fastethernet0/1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
Packet sent with a source address of 73.54.120.100
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 42/46/5

The first ping received a timeout, but the rest received a reply, as expected. The time required to bring up the VPN Tunnel is sometimes slightly more than 2 seconds, causing the first ping to timeout.

To verify the VPN Tunnel, use the show crypto session command:

From Remote Site 2, let’s ping the headquarter router:

Again, the first ping received a timeout, but the rest received a reply, as expected. The time required to bring up the VPN Tunnel is sometimes slightly more than 2 seconds, causing the first ping to timeout.

To verify the VPN Tunnel, use the show crypto session command:

Issuing the show crypto session command at the headquarter router will reveal all remote routers public IP addresses. This is usually a good shortcut when trying to figure out the public IP address of your remote routers.

The question that arises here is what will happen when all the IGP loopbacks are advertised as a single network in order to save the number of routes advertised?  Will this drop the traffic as per Penultimate Hop Popping (PHP) logic or will traffic forwarding still work as it is supposed to?

This article focuses on the impact of route summarization summary on loopback addresses in an MPLS environment and examines available work-arounds to overcome problems caused by the route summarization.

Readers seeking more information on MPLS IP VPN Networks, and how they work, can refer to our article: Understanding MPLS IP VPNs, Security Attacks and VPN Encryption. The article covers basic MPLS concepts and explains how MPLS IP VPNs work.

Understanding MPLS Labels: PUSH / POP / SWAP / PHP

When talking about MPLS environments we often come across terms such as PUSH, POP & SWAP & PHP. Below we explain what these terms mean and their functions:

Following is a brief explanation of the popular MPLS terms PUSH, POP & SWAP, PHP:

1. PUSH: Adding a label to incoming packet. Also known as label imposition.
2. SWAP: Swap the incoming label with another outgoing label
3. POP: Remove the label from outgoing packet. Also known as label disposition.
4. PHP: Stands for Penultimate Hop Popping. It refers to the process whereby the outermost label of an MPLS tagged packet is removed by a Label Switch Router (LSR) before the packet is passed to an adjacent Label Edge Router (LER).

Requirements For Our Test Environment

Prior to reading this document you should be familiar with mpls vpn environment. This article assumes the reader has experience in MPLS environments and routing protocols. It is recommended that you understand functions such as Penultimate Hop Popping (PHP) and Double Penultimate Hop Popping Lookup.

Understand the Current Topology - Example

As shown in the figure below, the service provider network is based upon a tier-three architecture. It has three types of layers:  Core, Distribution and Access.

Core Layer is usually referred to as Tier 1, Distribution Layer as Tier 2 and Access Layer as Tier 3. Core Layer is used to connect the different areas with each other and is largely responsible for the forwarding of traffic only. At the Distribution Layer, areas are segregated and used for the area summarization. Customers are terminated at the Access Layer i.e. Tier-3.  

• Tier one consists of core which will be participating only in Area 0
• Tier two is directly connected with area 0 and local area
• Tier three is connected to Tier two and does not directly connect with Tier one. Tier three participates only in the local area & customers connect at this layer.

The same model is used for all the locations. Every Tier 2 has an allocated pool of /16 subnet. If you're wondering why /16, it is because it allows the summary to be performed for Area 1 to Area 0. By performing the summary, only a single route will come in Area 0 and no more flaps will participate in spf (shortest-path-first) calculations.

In figure 1, PUNE (router name) is a Tier two POP and aggregates all links from which arrives Tier 3 or from local PUNE. A schematic ip pool of 10.1.0.0/16 is allocated to router PUNE provisioning team and further this pool is divided into 255 multiple networks of /24 as shown below:

• 10.1.1.0/24
• 10.1.2.0/24
• 10.1.3.0/24

Every /24 is allocated to each POP.  10.1.255.0/24 is reserved for loopback addresses & 10.1.253.0/24,10.1.252.0/24 & 10.1.252.0/24 is reserved for WAN addresses.

Requirements of POP

With every /24 pool given to every PoP (Point of Presence) (where all the devices are physically installed), a /32 IP address is given from the 10.1.255.0/24 pool. When the routes are advertised in MP-BGP, labels are only required for the loopbacks of the PoP routers and not for the entire subnet. The reason is that when the forwarding occurs only the next hop is checked, which is nothing but the loopback address of the PoP router. It means LDP is performing on loopback addresses.

Note: That’s why labels are always required for loopback addresses and not for entire routes like Wan and Lan Addresses.

Performing Route Summarization

Pune router is configured as the ABR (Area Border Router, in which one interface is connected with Area 0 and another interface is connected with Area 1). To reduce the number of routes from the backbone area in Area 0, Pune Router (ABR) has to perform a summarization of Area 0 networks advertised into Area 1.

Before this summarization takes place everything works fine, however, after the Pune Router advertised its summary route towards Area 1 (Not Area 0), connectivity was lost.

Customers start complaining that their VPN network is not working. They are not able to access their VPN’s across the country.

No changes have been made in the network except the summarization. The entire network is reachable except the customer’s VPN network. Does it mean that summarization made the customer’s network go down? How could it be possible?

Understanding Why Connectivity Was Lost

Let us examine why customer VPN networks went down as soon as the ABR router performed its route summarization of Area 0 and advertised it into Area 1

Penultimate Hop Popping will occur only for directly connected & summarized routes. It means every router is giving an implicit null to the adjacent router for its loopback address. In figure 1 router T-PE2 is giving implicit null to router T-PE1 for its loopback 10.1.255.2. It means when a packet destined for router 10.1.255.2 as soon as it arrives at router T-PE1, the upper label (which is an IGP label) is removed by T-PE1.

Now a packet that has a single label called VPN label is forwarded toward T-PE2. Once the packet is received by T-PE2, it will perform the lookup for that VPN label, remove the VPN label and forward it out one of the connected interfaces as a pure IP packet.

Now let's explain what happened in case of summarization at the ABR router.

On the ABR router, summarization is performed for the 10.1.0.0/16 pool, which also includes the loopback addresses. As soon as the summary is announced by ABR, an implicit null was announced to the directly connected peers in Area 0.

Traffic originating from Core-3 and Core-4 with a destination to T-PE2 must pass through the router Pune. But due to summarization, Pune router is announcing 10.1.0.0/16 with implicit null to all its peers connected in Area 0.

At this point the VPN packets, destined for Area 1, originating from Core 3 and Core 4, received by router Pune, have only a single label which is VPN label (Pune router is receiving VPN packets with single label due to PHP).  As soon as the VPN packets destined for T-PE2 arrive at Pune ABR with single VPN label, they are dropped because that VPN label is not available in Pune ABR. The behavior of router Pune remains the same for the entire traffic forwarding and finally traffic gets blackholed at router Pune.

Workarounds

Workaround No.1 - Perform the summary which excludes your loopback addresses

e.g 10.16.0.0/16 is the major pool which has 256 subnets starting from 10.16.0.0/24 10.16.1.0/24, 10.16.2.0/24, 10.16.3.0/24 up to 10.16.255.0/255.

Out of the 256 subnets, we can reserve for loopback addresses a few of the subnets starting from Network IDs 10.16.0.0/24, 10.16.1.0/24, 10.16.2.0/24, 10.16.3.0/24,10.16.4.0/24, 10.16.5.0/24, 10.16.6.0/24, and 10.16.7.0/24, and rest of the /24 pools for Network ID 10.16.8.0/24 onwards can be used for the backbone addresses. In this case, it is not necessary to perform  summarization of the loopbacks pools, while we are able to summarize the rest of the pools.

Workaround No.2 - Make use of a different pool of ip addresses that will never participate in summarization.

Our second workaround involves reserving Network 10.18.0.0/16 for the loopback addresses and assigning Network IDs 10.17.0.0/16 and 10.16.0.0/16 to the backbone addresses. In this case we can perform the summarization on 10.16.0.0/16 and 10.17.0.0/16 pools, excluding Network ID 10.18.0.0/16.

About The Author

Shivlu is a Cisco engineer with extensive experience in planning, designing, managing and maintaining large MPLS VPN service networks. Shivlu also has expertise in leading, envisioning and delivering technology based growth initiatives.

Shivlu currently works at Cisco Systems, he is responsible for designing end to end telecom solutions. He has a Masters Degree in Computer Application.

Readers can contact Shivlu via his blog, located at the following URL: http://www.mplsvpn.info

Web SSL VPN delivers the following three modes of SSL VPN access:

• Clientless - Clientless mode provides secure access to private web resources and will provide access to web content. This mode is useful for accessing most content that you would expect to access in a web browser such as Internet access, web-based intranet, webmail etc.

• Thin Client (port-forwarding Java applet) - Thin client mode extends the capability of the cryptographic functions of the web browser to enable remote access to TCP-based applications such as Post Office Protocol version 3 (POP3), Simple Mail Transfer Protocol (SMTP), Internet Message Access protocol (IMAP), Telnet and Secure Shell (SSH).

• Tunnel Mode (AnyConnect Secure Mobility Client) - Full tunnel client mode offers extensive application support through its dynamically downloaded Cisco AnyConnect VPN Client (next-generation SSL VPN Client) for SSL VPN. Full tunnel client mode delivers a lightweight, centrally configured and easy-to-support SSL VPN tunneling client that provides network layer access to virtually any application.

The advantage of SSL VPN comes from its accessibility from almost any Internet-connected system without needing to install additional desktop software.

Introducing Cisco SSL AnyConnect VPN - WebVPN

Cisco SSL AnyConnect VPN is a real trend these days – it allows remote users to access enterprise networks from anywhere on the Internet through an SSL VPN gateway using a web browser. During the establishment of the SSL VPN with the gateway, the client downloads and installs the AnyConnect VPN client from VPN gateway. This feature allows easy access to services within the company’s network and simplifies the VPN configuration on the SSL VPN gateway, reducing dramatically the administrative overhead for system administrators.

The Cisco secure WebVPN router login screen

The Cisco SSL AnyConnect VPN client was introduced in Cisco IOS 12.4(15)T and has been in development since then. Today, Cisco SSL AnyConnect VPN client supports all Windows platforms, Linux Redhat, Fedora, CentOS, iPhones, iPads and Android mobile phones.

Regardless of the client (PC, smartphone etc), the router configuration remains the same, while the appropriate VPN client software is downloaded by the client connecting to the VPN gateway (router).

Smartphones such as iPhones (iPAD included) and Android can download the Cisco VPN AnyConnect Secure Mobility Client directly from iTunes (Apple) or the Google Play store respectively (android phones).  To download it, connect to your store and search for ‘Cisco AnyConnect’.

To download VPN AnyConnect Secure Mobility Client packages files for Windows, MacOS X and Linux platforms, free, simply visit our Cisco Download section. The latest version of the client was made available at the time of writing this article.

Once our client is downloaded and installed on our Windows 7 workstation it will be ready to initiate the VPN connection to our VPN Gateway:

Steps To Configure & Enable SSL AnyConnect VPN Secure Mobility Client

•  Upload AnyConnect Secure Mobility Client to our Cisco Router
• Generate RSA Keys
• Declare the Trustpoint & Create Self-Signed Certificate
• Configure WebVPN Pool IP addresses assigned to the VPN Users
• Enable and Configure AAA Authentication for SSL VPN & Create User Accounts
• Enable WebVPN License
• Configure and enable WebVPN Gateway
• Configure and enable SSL VPN Context
• Configure default group policy, authentication list and final parameters for WebVPN

Uploading AnyConnect Secure Mobility Client Package To Our Cisco Router

The first step is to upload the Cisco AnyConnect client to the router’s flash memory.  Depending on the type of clients you might need to upload more than one VPN AnyConnect client package.  For our article, we will be using the latest VPN AnyConnect client for Windows, which at the time of writing was version 3.1.00495 (anyconnect-win-3.1.00495-k9.pkg). Cisco AnyConnect VPN client is available for download in our Cisco Download Section.

Generate RSA Keys

The next step is to generate our RSA 1024bit keys. The crypto key generate rsa command depends on the hostname and ip domain-name commands. This crypto command generates a Rivest, Shamir, Adleman (RSA) key pair, which includes one public RSA key and one private RSA key, with a key modulus size of 1024 (usually):

Declare The Trustpoint & Create Self-Signed Certificate

Once complete, we need to declare the trustpoint that the router should use by using the command crypto pki trustpoint command in global configuration mode. When declaring a trustpoint, we can specify certain characteristics in its subcommands as shown in our configuration:

Configure WebVPN Pool IP Addresses

WebVPN users will need to be assigned a LAN IP address so they can communicate with our network. The following command specifies the pool of ip addresses that will be assigned to our users. This can be either part of our LAN network or a completely different network. Since we have plenty of spare IP addresses, we’ll be using a small portion of them:

Note we have named this pool webvpn-pool.

Enable & Configure AAA Authentication for SSL VPN - Create User VPN Accounts

AAA stands for Authentication, Authorization and Accounting. We need to enable AAA in order to use it for our user authentication. 

It could be that AAA is already enabled on the router, in which case we only need to define an authentication list (we named it ‘sslvpn’) to use the router’s local user database for user authentication. 

Enable WebVPN License

When the WebVPN service is enabled for the first time on an ISR Generation 2 Cisco router (1900, 2900 & 3900 series), with the 15.x version IOS software or newer, the router will prompt us to accept the End-User License Agreement (EULA) before enabling and activating the service.

It is imperative to accept the EULA in order to proceed:

After accepting the EULA, we can verify the WebSSL VPN service is activated by issuing the show license all command. Usually StoreIndex 4 contains the WebSSL VPN reference:

Notice the License Type mention: EvalRightToUse.  This means that this is an evaluation license, a license to evaluate. At the end of the 8 ½ week evaluation period, the ISRG2 Cisco router license will not terminate the Web SSL_VPN license, and it will continue to work.

Configure & Enable WebVPN Gateway

After taking care of the licensing it’s time to begin working on the WebVPN Virtual Gateway configuration. The WebVPN Virtual Gateway enables the interface or IP address and port number to which the WebVPN service will ‘listen’ for incoming connections and also determines the encryption that will be used. 

Note: If the interface the WebVPN will be running on has a dynamic IP address, for example Dialer0 (ATM ADSL Interface), the ip address 74.200.90.5 port 443  command can be replaced with ip interface Dialer0 port 443, where ‘Dialer0’ is the dynamic interface.

Configure & Enable SSL VPN Context

The SSL VPN context is used to configure a number of parameters for our Web VPN server, these include:

• Gateway and domain associated
• AAA user authentication method
• Group policy associated
• The remote user portal (web page)
• Limit number of WebVPN SSL user sessions

Most of these parameters are configured in our group policy. This group policy is then set as the default-group policy for our Web SSL VPN.

Let’s explain what all the above commands do:

The webvpn context command is used to create a context named which we have named Cisco-WebVPN. The title command sets the text that will be displayed at the web browser’s Page Title and at the top of the login screen.

The acl “ssl-acl” command configures the access lists for this context. It basically governs what the web vpn users will have access to.  We’ve provided our webVPN users full access to the 192.168.9.0 network.

Our webvpn users' IP addresses have already been defined in the webvpn-pool (192.168.9.80 to 192.168.0.85). Instead of typing each IP address within that range into our ACL list we simply configure the router to allow the 192.168.9.0 network as a source and destination in our VPN tunnel. This ensures any IP in the 192.168.9.0 range assigned to our vpn clients will have access to our LAN (192.168.9.0)

The login-message command defines the text that will be shown in the login section of the webvpn webpage. These messages are also visible in our WebVPN login screen at the beginning of our article.

Since our webvpn pool is part of the same network we just set the 192.168.9.0 network as the source and destination IP address.

Next, we define a group policy. The group policy configures a number of important parameters. We named our group policy webvpnpolicy.

The functions svc-enabled & svc-required commands ensure tunnel-mode is enabled and required. The combination of these two commands will force the VPN user’s PC to start downloading the AnyConnect software client as soon as he authenticates successfully. This is called tunnel-mode operation.

Alternatively, without the svc-required command, a webpage will be presented from which the user can directly launch any configured web service in our webvpn portal or selectively initiate tunnel-mode and start downloading the AnyConnect software client. 

Note: The acronym SVC stands for SSL VPN Client

The screenshot below shows the AnyConnect Secure Mobility Client installation process. Keep in mind that these screenshots apply after the complete configuration of our router's SSL WebVPN service:

During the installation, the user will receive a number of prompts & security warnings about the publisher and website’s certificate verification. Administrators and engineers should instruct their VPN users to accept/allow the installation of the certificates and software client when prompted.

Shortly after the acceptance of certificates and confirming to the web browser to allow the installation of the client, the AnyConnect Secure Mobility Client Downloader will begin:

The filter tunnel ssl-acl command instructs the webvpn gateway to use ssl-acl access list to define the access vpn users will have.

The svc address-pool command defines the pool that will be used to assign IP addresses to our vpn users.

The svc rekey method new-tunnel specifies that the SVC establishes a new tunnel during SVC rekey.

The svc split command enables split tunneling, instructing which network traffic will be sent through the vpn tunnel. If this command is not included, vpn users will not be allowed to access the Internet while connected to the vpn.

Configure Default Group Policy, Authentication List & Final Parameters

Now we will configure the policy we just created as the default policy, set the aaa authentication list (sslvpn) to be used for user authentication and maximum users for the service. Lastly, we enable our webvpn context:

The ssl authenticate verify all command enables SSL configurations for backend server connections. While we are not using any such backend services, it’s a good option to always have enabled.

Supporting Multiple Group Policies on AnyConnect

Administrators and engineers who have worked with the classic Cisco IPSec VPN client will wonder how they can support multiple groups with different access rights using AnyConnect.  The fact is that AnyConnect does support multiple groups, however it requires a radius server at the backend.

AnyConnect on a Cisco router without a radius server will only allow support for one group policy. 

Complete WebVPN SSL AnyConnect Configuration

Finally, below is the complete Web VPN SSL AnyConnect configuration of our router:

This concludes our Cisco SSL VPN AnyConnect configuration for Cisco IOS Routers.

It is highly advisable for those who haven’t read our Introduction to DMVPN to do so as it contains basic concepts and theory that are important to the configuration process.

Configuring DMVPN is simple, if you’ve worked with GRE tunnels before.  If the GRE Tunnel concept is new to you, we would recommend reading through our Point-to-Point GRE IPSec Tunnel Configuration article before proceeding with DMVPN configuration.

DMVPN as a design concept is essentially the configuration combination of protected GRE Tunnel and Next Hop Routing Protocol (NHRP).

DMVPN Operation - How DMVPN Operates

Before diving into the configuration of our routers, we’ll briefly explain how the DMVPN is expected to work. This will help in understanding how DMVPN operates in a network:

• Each spoke has a permanent IPSec tunnel to the hub but not to the other spokes within the network.
• Each spoke registers as a client of the NHRP server. The Hub router undertakes the role of the NHRP server.
• When a spoke needs to send a packet to a destination (private) subnet on another spoke, it queries the NHRP server for the real (outside) address of the destination (target) spoke.
• After the originating spoke learns the peer address of the target spoke, it can initiate a dynamic IPSec tunnel to the target spoke.
• The spoke-to-spoke tunnel is built over the multipoint GRE (mGRE) interface.
• The spoke-to-spoke links are established on demand whenever there is traffic between the spokes. Thereafter, packets are able to bypass the hub and use the spoke-to-spoke tunnel.
• All data traversing the GRE tunnel is encrypted using IPSecurity (optional)

Our DMVPN Network

The diagram below depicts our DMVPN example network. Our goal is to connect the two remote networks (Remote 1 & 2) with the company headquarters. The headquarters router R1 is the central Hub router that will hold the NHRP database containing all spoke routers, their public IP addresses and LAN networks. 

Four Steps To Fully Configure Cisco DMVPN

To help simplify the configuration of DMVPN we’ve split the process into 4 easy-to-follow steps. Each step is required to be completed before moving to the next one. These steps are:

• Configure the DMVPN Hub
• Configure the DMVPN Spoke(s)
• Protect the mGRE tunnels with IPSecurity (optional)
• Configure Routing Between DMVPN mGRE Tunnels (static routing or routing protocol)

Configuring The DMVPN Hub – R1 Router

Configuring the Hub router (R1) is simple.  After configuring the router’s LAN and WAN interfaces we create our mGRE tunnel interface. Let's start with the router’s Ethernet interfaces:

Next, we configure the Tunnel0 interface. Notice this is an almost typical tunnel interface configuration with some minor but important changes that have been highlighted:

Engineers familiar with GRE Tunnels will immediately notice the absence of the tunnel destination command. It has been replaced with the tunnel mode gre multipointcommand, which designates this tunnel as a multipoint GRE tunnel.

The ip nhrp map multicast dynamic command enables the forwarding of multicast traffic across the tunnel to dynamic spokes. This is usually required by routing protocols such as OSPF and EIGRP.  In most cases, DMVPN is accompanied by a routing protocol to send and receive dynamic updates about the private networks.

The ip nhrp network-id 1 command is used to identify this DMVPN cloud. All routers participating in this DMVPN cloud must have the same network-id configured in order for tunnels to form between them.

The ip nhrp authentication command is used to allow the authenticated updates and queries to the NHRP Database, ensuring unwanted queries are not provided with any information about the DMVPN network.

Configuring The DMVPN Spokes – R2 & R3 Routers

Spoke router configuration is similar to that of the hub.  First configure the LAN and WAN interfaces:

Next, it’s time to build that mGRE tunnel:

After a couple of seconds, we receive confirmation that our tunnel interface is up:

The ip nhrp nhs 172.16.0.1 command tells our spoke router who the Next Hop Server (NHS) is, while the ip nhrp map 172.16.0.1 1.1.1.10 command maps the NHS address (172.16.0.1) to the Hub’s (R1) public IP address (1.1.1.10).

The ip nhrp map multicast 1.1.1.10 ensures multicast traffic is sent only from spokes to the hub and not from spoke to spoke. All multicast traffic should be received by the hub, processed and then updates are sent out to the spokes.

Lastly, notice that tunnel source FastEthernet0/1 command. All spokes with dynamic WAN IP address must be configured to bind the physical WAN interface as the tunnel source. This way,  when the spoke’s WAN IP changes, it will be able to update the NHS server with its new WAN IP address.

Note: In R2’s configuration, we’ve configured a static IP address on its WAN interface FastEthernet0/1, but for the sake of this example, let us assume it was dynamically provided by the ISP.

R3’s configuration follows, similar to that of the R2 spoke router:

Next, our tunnel configuration:

Note: In R3’s configuration, we’ve configured a static IP address on its WAN interface FastEthernet0/1, but for the sake of this example, let us assume it was dynamically provided by the ISP.

This completes the DMVPN configuration on our central hub and two spoke routers.  It is now time to verify the DMVPNs are working correctly.

Verifying DMVPN Functionality At The R1 HUB Router

After completing our routers configuration, it’s time to verify everything is working as planned.

First we turn to our main hub, R1, and check the DMVPN by using the show dmvpn command:

The output of our command provides us with some valuable information.  To start with, the router provides an explanation for each column presented (right under the show command) but we are still going to cover them so that we are not left with any unanswered questions.

The first column #Ent shows the number of entries that exist in the NHRP Database for the same spoke. Usually, we wouldn’t expect to see more than one for each spoke.

The second column Peer NBMA Addr presents the spoke’s public IP address, while the third column, Peer Tunnel Add, shows each spoke’s local Tunnel’s IP address. 

Next, the State column shows the current state the tunnel is in. In our case, both tunnels are UP. Right next to the State is the UpDN Tm, which is the Up or Down Time of the current State.  This is a very important bit of information as you can clearly see out how long your tunnel has been in its current state.

For our example, both spokes have been up for almost 5 minutes.

Lastly, the Attrib column shows the type of tunnels established by the spokes. D stands for Dynamic, S for Static and I for Incomplete. Usually dynamic spokes will create D type tunnels. Tunnels established from the spokes to the Hub router are expected to be S type, since the Hub remains static.

Verifying DMVPN Functionality At The R2 & R3 Spoke Router

Turning to R2 router, our first spoke, we can repeat the same show dmvpn command and obtain a list of dmvpns currently created:

As expected, R2’s output shows one entry only. When traffic needs to be directed to R3, a second GRE tunnel will come up. We’ll try this soon. For now let’s check our third remote site, R3 spoke router

Using the same show dmvpn command we obtain the following similar output:

Protecting - Encrypting DMVPN mGRE Tunnels With IPSec

Since we have our GRE tunnels up and running, we need to encrypt them using IPSec to ensure data confidentiality.  Protecting GRE Tunnels is covered in great depth in our Protected GRE over IPSec article, so we are going to simply display the commands here without repeating the topic.

First stop is our headquarters R1 Hub router:

Notice the command crypto isakmp key firewall.cx address 0.0.0.0 0.0.0.0. The peer address for which the isakmp key is valid is 0.0.0.0 0.0.0.0, which means every possible host on the Internet.  When our remote routers (spokes) have dynamic IP addresses, 0.0.0.0 0.0.0.0 must be used.

The following configuration applies to R2 & R3 spoke routers:

Again we’ve defined 0.0.0.0 0.0.0.0 as the isakmp peer address. While the hub’s public IP address is known we must keep in mind that R2 and R3 can build dynamic VPN tunnel between them. Taking into consideration that their public IP address is dynamic it is imperative to use 0.0.0.0 0.0.0.0 for the remote peer.

Verifying the DMVPN Crypto Tunnels

Once all routers are configured IPSec VPN tunnels are brought up. We can verify this by using the show crypto session command at our R1 hub router:

Routing Between DMVPN mGRE Tunnels

Last step involves enabling routing in our DMVPN network. This is required so that the hub and spoke routers are aware which packets need to be sent via the VPN network.

There are two ways this can be achieved: 1) Static routes  2) Routing protocol.

For the sake of simplicity we are going to focus on static routes.  DMVPN and routing protocol configuration will be covered in another article.

Configuring the necessary static routes is very simple. All that is required is a set of simply static routes on each router (hub and spoke), pointing to the other networks.

On the R1 hub router:

And finally on R3 spoke router:

Our DMVPN Network Is Ready!

At this point, our DMVPN network is ready and fully functional. All networks are connected between each other and dynamic VPN tunnels between spokes can be established.   GRE tunnels are protected properly, providing data confidentiality and ip routing is enabled.

As a final step, we can try sending traffic between the spokes and verify the dynamic tunnel is being established:

From R2 spoke router, we try to ping R3’s LAN IP address:

It is evident that the two spoke routers have established communication.

The DMVPN is up and routing is working perfectly:

This concludes our DMVPN configuration article. 

This article showed how to configure a DMVPN network between Cisco routers. We covered the configuration of a Cisco DMVPN including Hub, Spokes, Static Routing and Protecting the mGRE Tunnel. We also provided some useful show commands to help troubleshoot and debug the DMVPN network. More articles on VPN & DMVPN can be found in our Cisco Routers Section and Cisco Services & Technlogies Section.

Figure 1. The tftp source IP problem with tftp and other services on a Cisco Router

Luckily, there is a way around this problem, and it’s a simple one.

Note: The commands used are identical for all Cisco routers and Catalyst switches.

To ensure your Cisco router or multi-layer switch uses the correct interface during any tftp session, use the ip tftp source-interface command to specify the source-interface that will be used by the device.

The following example instructs our Cisco 3750 Layer 3 switch to use VLAN 5 interface as the source ip interface for all tftp sessions:

As shown below, VLAN 5 has IP address 192.168.131.1 assigned to it, therefore this IP address will be the source interface from now on:

The problem with GRE is that it is an encapsulation protocol, which means that while it does a terrific job providing connectivity between sites, it does a terrible job encrypting the data being transferred between them. GRE is stateless, offering no flow control mechanisms (think of UDP). This is where the IPSec protocol comes into the picture.

IPSec’s objective is to provide security services for IP packets such as encrypting sensitive data, authentication, protection against replay and data confidentiality. IPSec is extensively covered in our IPSec protocol article. 

IPSec can be used in conjunction with GRE to provide top-notch security encryption for our data, thereby providing a complete secure and flexible VPN solution. IPSec can operate in two different modes, Tunnel mode and Transport mode.  Both of these modes are covered extensively in our Understanding VPN IPSec Tunnel Mode and IPSec Transport Mode article. Additionally, Cisco GRE Tunnel configuration is covered in our Configuring Cisco Point-to-Point GRE Tunnels. We highly recommend reading these articles before proceeding as it is a prerequisite for  understanding the information covered here.

As with IPSec, when configuring GRE with IPSec there are two modes in which GRE IPSec can be configured, GRE IPSec Tunnel mode and GRE IPSec Transport mode.

This article examines the difference between GRE IPSec Tunnel and GRE IPSec Transport mode, and explains the packet structure differences along with the advantages and disadvantages of each mode.

GRE IPSec Tunnel Mode

With GRE IPSec tunnel mode, the whole GRE packet (which includes the original IP header packet), is encapsulated, encrypted and protected inside an IPSec packet.  GRE over IPSec Tunnel mode provides additional security because no part of the GRE tunnel is exposed, however, there is a significant overhead added to the packet. This additional overhead decreases the usable free space for our payload (Original IP packet), that means possibly more fragmentation will occur when transmitting data over a GRE IPSec Tunnel VPN.

IPSec Tunnel mode is the default configuration option for both GRE and non-GRE IPSec VPNs. When configuring the IPSec transform set, no other configuration commands are required to enable tunnel mode:

Calculating GRE IPSec Tunnel Mode Overhead

Calculating the overhead will help us understand how much additional space GRE over IPSec in Tunnel mode requires and our effective usable space.

The packet structure below shows an example of a GRE over IPSec in Tunnel mode:

Two important points to keep in mind when calculating the overhead:

• Depending on the encryption algorithm used in the crypto transform set, the Initialization Vector (IV) shown could be 8 or 16 bytes long. For example DES or 3DES introduces an 8-byte IV field, where as AES introduces a 16-byte IV field. In our example, we are using 3DES encryption, therefore producing a 8-byte IV field.

• The ESP Trailer will usually vary in size. Its job is to ensure that the Pad Length, Next Header fields (both 1-byte long and contained within the ESP Trailer) &  ESP Auth.Trailer are aligned on a 4-byte boundary. This means the total number of bytes, when adding the three fields together, must be a multiple of 4.

Following is the calculated overhead:

ESP Overhead:  20 (IP Hdr) + 8 (ESP Hdr) + 8 (IV) + 4 (ESP Trailer) + 12  (ESP Auth) = 52 Bytes

Note: ESP Trailer has been calculated as 4 bytes as per above note.

GRE Overhead: 20 (GRE IP Hdr) + 4 (GRE) = 24 Bytes

Total Overhead: 52 + 24 = 76 Bytes

GRE IPSec Transport  Mode

With GRE IPSec transport mode, the GRE packet is encapsulated and encrypted inside the IPSec packet, however, the GRE IP Header is placed at the front. This effectively exposes the GRE IP Header as it is not encrypted the same way it is in Tunnel mode.

IPSec Transport mode is not used by default configuration and must be configured using the following command under the IPSec transform set:

Finally, if the GRE tunnel endpoints and Crypto tunnel endpoints are different, GRE IPSec transport mode cannot be used.

These limitations seriously restrict the use and implementation of the transport mode in a WAN network environment.

Calculating GRE IPSec Transport  Mode Overhead

Calculating the overhead will help us understand how much space GRE over IPSec in Transport  mode uses and our effective usable space.

The packet structure below shows an example of GRE over IPSec in transport mode:

Again, two important points that must kept in mind when calculating the overhead:

• Depending on the encryption algorithm used in the crypto transform set, the Initialization Vector (IV) shown could be 8 or 16 bytes long. For example DES or 3DES introduces an 8-byte IV field, where as AES introduces a 16-byte IV field. In our example, we are using 3DES encryption, therefore producing a 8-byte IV field.

• The ESP Trailer will usually vary in size. Its job is to ensure that the Pad Length, Next Header fields (both 1-byte long and contained within the ESP Trailer) &  ESP Auth.Trailer are aligned on a 4-byte boundary. This means the total number of bytes, when adding the three fields together, must be a multiple of 4.

Following is the calculated overhead:

ESP Overhead:  20 (IP Hrd) + 8 (ESP Hdr) + 8 (IV) + 4 (ESP Trailer) + 12 (ESP Auth) = 52 Bytes

Note: ESP Trailer has been calculated as 4 bytes as per above note.

GRE Overhead: 4 (GRE)  = 4 Bytes

Total Overhead: 52 + 4 = 56 Bytes

It is evident that GRE IPSec Transport mode saves approximately 20 bytes per packet overhead. This might save a moderate amount of bandwidth on a WAN link, however, there is no significant increase in CPU performance by using this mode.

Summary

When comparing GRE over IPSec tunnel and GRE over IPSec transport mode, there are significant differences that cannot be ignored. 

If the GRE tunnels and crypto endpoints are not the same (IP address wise), transport mode in definitely not an option.

If packets traverse a device (router) where NAT or PAT is used then again, transport mode cannot be used.

On the other hand, tunnel mode seems to pay-off its 20-byte additional overhead by being flexible enough to be used in any type of WAN environment and offering increased protection by encrypting the GRE IP Header inside the ESP packet.

Taking in consideration the small additional CPU load the tunnel mode produces and advantages it offers, we don’t believe it’s a coincidence Cisco has selected this mode in IPSec’s default configuration.

A GRE tunnel is used when packets need to be sent from one network to another over the Internet or an insecure network. With GRE, a virtual tunnel is created between the two endpoints (Cisco routers) and packets are sent through the GRE tunnel.

It is important to note that packets travelling inside a GRE tunnel are not encrypted as GRE does not encrypt the tunnel but encapsulates it with a GRE header. If data protection is required, IPSec must be configured to provide data confidentiality – this is when a GRE tunnel is transformed into a secure VPN GRE tunnel.

The diagram below shows the encapsulation procedure of a simple - unprotected GRE packet as it traversers the router and enters the tunnel interface:

While many might think a GRE IPSec tunnel between two routers is similar to a site to site IPSec VPN (crypto), it is not. A major difference is that GRE tunnels allow multicast packets to traverse the tunnel whereas IPSec VPN does not support multicast packets. In large networks where routing protocols such as OSPF, EIGRP are necessary, GRE tunnels are your best bet. For this reason, plus the fact that GRE tunnels are much easier to configure, engineers prefer to use GRE rather than IPSec VPN.

This article will explain how to create simple (unprotected) and secure (IPSec encrypted) GRE tunnels between endpoints. We explain all the necessary steps to create and verify the GRE tunnel (unprotected and protected) and configure routing between the two networks.

Creating a Cisco GRE Tunnel

GRE tunnel uses a ‘tunnel’ interface – a logical interface configured on the router with an IP address where packets are encapsulated and decapsulated as they enter or exit the GRE tunnel.

First step is to create our tunnel interface on R1:

All Tunnel interfaces of participating routers must always be configured with an IP address that is not used anywhere else in the network. Each Tunnel interface is assigned an IP address within the same network as the other Tunnel interfaces.

In our example, both Tunnel interfaces are part of the 172.16.0.0/24 network.

Since GRE is an encapsulating protocol, we adjust the maximum transfer unit (mtu) to 1400 bytes and maximum segment size (mss) to 1360 bytes. Because most transport MTUs are 1500 bytes and we have an added overhead because of GRE, we must reduce the MTU to account for the extra overhead. A setting of 1400 is a common practice and will ensure unnecessary packet fragmentation is kept to a minimum.

Closing, we define the Tunnel source, which is R1’s public IP address, and destination – R2’s public IP address

As soon as we complete R1’s configuration, the router will confirm the creation of the tunnel and inform about its status:

Since the Tunnel 0 interface is a logical interface it will remain up even if there is no GRE tunnel configured or connected at the other end.

Next, we must create the Tunnel 0 interface on R2:

R2’s Tunnel interface is configured with the appropriate tunnel source and destination IP address. As with R1, R2 router will inform us that the Tunnel0 interface is up:

Routing Networks Through The GRE Tunnel

At this point, both tunnel endpoints are ready and can ‘see’ each other. An icmp echo from one end will confirm this:

Again, this result means that the two tunnel endpoints can see each other. Workstations on either network will still not be able to reach the other side unless a static route is placed on each endpoint:

On R1 we add a static route to the remote network 192.168.2.0/24 via 172.16.0.2 which is the other end of our GRE Tunnel. When R1 receives a packet for 192.168.2.0 network, it now knows the next hop is 172.16.0.2 and therefore will send it through the tunnel.

The same configuration must be repeated for R2:

Now both networks are able to freely communicate with each over the GRE Tunnel.

Securing the GRE Tunnel with IPSec

As mentioned earlier, GRE is an encapsulation protocol and does not perform any encryption. Creating a point-to-point GRE tunnel without any encryption is extremely risky as sensitive data can easily be extracted from the tunnel and viewed by others.

For this purpose, we use IPSec to add an encryption layer and secure the GRE tunnel. This provides us with the necessary military-grade encryption and peace of mind.  Our example below covers GRE IPSec Tunnel mode.

GRE IPSec modes are covered extensively in our GRE and IPSec – GRE Over IPSec - Selecting and Configuring Gre IPSec Tunnel or Transport Mode.

Configuring IPSec Encryption For GRE Tunnel (GRE over IPSec)

IPSec encryption involves two steps for each router. These steps are:

• (1) Configure ISAKMP (ISAKMP Phase 1)
• (2) Configure IPSec (ISAKMP Phase 2)

Configure ISAKMP (IKE) - (ISAKMP Phase 1)

IKE exists only to establish SAs (Security Association) for IPsec. Before it can do this, IKE must negotiate an SA (an ISAKMP SA) relationship with the peer.

To begin, we’ll start working on R1.

First step is to configure an ISAKMP Phase 1 policy:

The above commands define the following (in listed order):

Next we are going to define a pre shared key for authentication with R1's peer, 2.2.2.10:

The peer’s pre shared key is set to firewallcx. This key will be used for allISAKMP negotiations with peer 2.2.2.10 (R2).

Create IPSec Transform (ISAKMP Phase 2 policy)

Now we need to create the transform set used to protect our data. We’ve named this TS:

Finally, we create an IPSec profile to connect the previously defined ISAKMP and IPSec configuration together. We’ve named our IPSec profile protect-gre:

We are ready to apply the IPSec encryption to the Tunnel interface:

Now it's time to apply the same configuration on R2:

Verifying The GRE Over IPSec Tunnel

Finally, our tunnel has been encrypted with IPSec, providing us with the much needed security layer. To test and verify this, all that is required is to ping the other end and force the VPN IPSec tunnel to come up and start encrypting/decrypting our data:

Using the show crypto session command, we can quickly verify the encryption is in place and doing its work:

Summary

In this article we saw how to create simple (unprotected) and secure (IPSec encrypted) GRE tunnels between Cisco routers. We explained all the necessary steps to create and verify the GRE tunnel (unprotected and protected) and configure routing between the two networks.

This article will show how to setup and configure two Cisco routers to create a permanent secure site-to-site VPN tunnel over the Internet, using the IP Security (IPSec) protocol. In this article we assume both Cisco routers have a static public IP address.  Readers interested in configuring support for dynamic public IP address endpoint routers can refer to our Configuring Site to Site IPSec VPN with Dynamic IP Endpoint Cisco Routers article.

IPSec VPN tunnels can also be configured using GRE (Generic Routing Encapsulation) Tunnels with IPsec. GRE tunnels greatly simply the configuration and administration of VPN tunnels and are covered in our Configuring Point-to-Point GRE VPN Tunnels article.  Lastly, DMVPNs – a new VPN trend that provide major flexibility and almost no administration overhead can also be examined by reading our Understanding Cisco Dynamic Multipoint VPN (DMVPN),  Dynamic Multipoint VPN (DMVPN) Deployment Models & Architectures and Configuring Cisco Dynamic Multipoint VPN (DMVPN) - Hub, Spokes , mGRE Protection and Routing - DMVPN Configuration articles.

ISAKMP (Internet Security Association and Key Management Protocol) and IPSec are essential to building and encrypting the VPN tunnel. ISAKMP, also called IKE (Internet Key Exchange), is the negotiation protocol that allows two hosts to agree on how to build an IPsec security association. ISAKMP negotiation consists of two phases: Phase 1 and Phase 2.  

Phase 1 creates the first tunnel, which protects later ISAKMP negotiation messages. Phase 2 creates the tunnel that protects data.  IPSec then comes into play to encrypt the data using encryption algorithms and provides authentication, encryption and anti-replay services.

IPSec VPN Requirements

To help make this an easy-to-follow exercise, we have split it into two steps that are required to get the Site-to-Site IPSec VPN Tunnel to work.

These steps are:

(1)  Configure ISAKMP (ISAKMP Phase 1)

(2)  Configure IPSec  (ISAKMP Phase 2, ACLs, Crypto MAP)

Our example setup is between two branches of a small company, these are Site 1 and Site 2. Both the branch routers connect to the Internet and have a static IP Address assigned by their ISP as shown on the diagram:

Site 1 is configured with an internal network of 10.10.10.0/24, while Site 2 is configured with network 20.20.20.0/24. The goal is to securely connect both LAN networks and allow full communication between them, without any restrictions.

Configure ISAKMP (IKE) - (ISAKMP Phase 1)

IKE exists only to establish SAs (Security Association) for IPsec. Before it can do this, IKE must negotiate an SA (an ISAKMP SA) relationship with the peer.

To begin, we’ll start working on the Site 1 router (R1).

First step is to configure an ISAKMP Phase 1 policy:

The above commands define the following (in listed order):

We should note that ISAKMP Phase 1 policy is defined globally. This means that if we have five different remote sites and configured five different ISAKMP Phase 1 policies (one for each remote router), when our router tries to negotiate a VPN tunnel with each site it will send all five policies and use the first match that is accepted by both ends.

Next we are going to define a pre shared key for authentication with our peer (R2 router) by using the following command:

The peer’s pre shared key is set to firewallcx and its public IP Address is 1.1.1.2. Every time R1 tries to establish a VPN tunnel with R2 (1.1.1.2), this pre shared key will be used.

Configure IPSec - 4 Simple Steps

To configure IPSec we need to setup the following in order:

• Create extended ACL
• Create IPSec Transform
• Create Crypto Map
• Apply crypto map to the public interface
  

Let us examine each of the above steps.

Step 1: Creating Extended ACL

Next step is to create an access-list and define the traffic we would like the router to pass through the VPN tunnel.  In this example, it would be traffic from one network to the other, 10.10.10.0/24 to 20.20.20.0/24.  Access-lists that define VPN traffic are sometimes called crypto access-list or interesting traffic access-list.

Step 2: Create IPSec Transform (ISAKMP Phase 2 policy)

Next step is to create the transform set used to protect our data. We’ve named this TS:

The above command defines the following:  

Step 3: Create Crypto Map

The Crypto map is the last step of our setup and connects the previously defined ISAKMP and IPSec configuration together:

We’ve named our crypto map CMAP. The ipsec-isakmp tag tells the router that this crypto map is an IPsec crypto map. Although there is only one peer declared in this crypto map (1.1.1.2), it is possible to have multiple peers within a given crypto map.

Step 4: Apply Crypto Map To The Public Interface

The final step is to apply the crypto map to the outgoing interface of the router. Here, the outgoing interface is FastEthernet 0/1.

Note that you can assign only one crypto map to an interface.

As soon as we apply crypto map on the interface, we receive a message from the router  that confirms isakmp is on: “ISAKMP is ON”.

At this point, we have completed the IPSec VPN configuration on the Site 1 router.

We now move to the Site 2 router to complete the VPN configuration. The settings for Router 2 are identical, with the only difference being the peer IP Addresses and access lists:

Network Address Translation (NAT) and IPSec VPN Tunnels

Network Address Translation (NAT) is most likely to be configured to provide Internet access to internal hosts. When configuring a Site-to-Site VPN tunnel, it is imperative to instruct the router not to perform NAT (deny NAT) on packets destined to the remote VPN network(s).

This is easily done by inserting a deny statement at the beginning of the NAT access lists as shown below:

For Site 1’s router:

And Site 2’s router:

Establishing and Verifying the IPSec VPN Tunnel

At this point, we’ve completed our configuration and the VPN Tunnel is ready to be brought up.  To initiate the VPN Tunnel, we need to force one packet to traverse the VPN and this can be achieved by pinging from one router to another:

The first icmp echo (ping) received a timeout, but the rest received a reply, as expected. The time required to bring up the VPN Tunnel is sometimes slightly more than 2 seconds, causing the first ping to timeout.

To verify the VPN Tunnel, use the show crypto session command:

Summary

This completes our discussion on how to setup and configure two Cisco routers to create a permanent secure site-to-site VPN tunnel over the Internet, using the IP Security (IPSec) protocol.

Thankfully, since Cisco IOS version 12.3 and later, Cisco provides an easy way for administrators to lock down their Cisco router without entering complex commands and parameters.  This feature was smartly introduced to help remove the complexity of the task and ensure the lock-down is performed according to Cisco’s best security practices.

The Cisco AutoSecure feature is available to all IOS version 12.3 and above and supported on all hardware platforms, including all newer Cisco 870, 880, 1800, 1900, 2800, 2900, 3800 and 3900 series routers.

To maximize flexibility the Cisco AutoSecure command supports two different modes depending on your needs and flexibility required:

AutoSecure Interactive Mode: This mode prompts the user with options to enable/disable services and other security features supported by the IOS version the router is running.

AutoSecure Non-Interactive Mode:  Automatically executes the Cisco AutoSecure command using the recommended Cisco default settings (Cisco’s best security practices).

The Cisco AutoSecure Interactive mode provides greater control over security-related features than the non-interactive mode. However, when an administrator needs to quickly secure a router without much human intervention, the non-interactive mode is appropriate.

We’ll examine the practical difference between the two commands soon. For now, let’s take a look at the functions Cisco AutoSecure performs:

1. Disables the following Global Services:

• Finger
• PAD
• Small Servers
• Bootp
• HTTP service
• Identification Service
• CDP
• NTP
• Source Routing

2. Enables the following Global Services:

• Password-encryption service
• Tuning of scheduler interval/allocation
• TCP synwait-time
• TCP-keepalives-in and tcp-kepalives-out
• SPD configuration
• No ip unreachables for null 0

3. Disables the following services per interface:

• ICMP
• Proxy-Arp
• Directed Broadcast
• Disables MOP service
• Disables icmp unreachables
• Disables icmp mask reply messages.

4. Provides logging for security:

• Enables sequence numbers & timestamp
• Provides a console log
• Sets log buffered size
• Provides an interactive dialogue to configure the logging server ip address.

5. Secures access to the router:

• Checks for a banner and provides facility to add text to automatically configure:
• Login and password
• Transport input & output
• Exec-timeout
• Local AAA
• SSH timeout and ssh authentication-retries to minimum number
• Enable only SSH and SCP for access and file transfer to/from the router
• Disables SNMP If not being used

6. Secures the Forwarding Plane:

• Enables Cisco Express Forwarding (CEF) or distributed CEF on the router, when available
• Anti-spoofing
• Blocks all IANA reserved IP address blocks
• Blocks private address blocks if customer desires
• Installs a default route to NULL 0, if a default route is not being used
• Configures TCP intercept for connection-timeout, if TCP intercept feature is available and the user is interested
• Starts interactive configuration for CBAC on interfaces facing the Internet, when using a Cisco IOS Firewall image
• Enables NetFlow on software forwarding platforms

It is clear that the Cisco AutoSecure does a lot more than execute a couple of commands.

Configuring Cisco AutoSecure Interactive Mode

This happens to be the recommended mode for securing your Cisco router. When using the Cisco AutoSecure Interactive Mode, the router will prompt a number of questions regarding the current topology, how it is connected to the Internet, which interface connects to the Internet and so on.  Providing this information is essential because it will be used by AutoSecure to lock-down the router and disable services as required by Cisco’s best security practices.

Below is the command required to initiate the AutoSecure Interactive mode feature. You can abort the session anytime by pressing Ctrl-C, or press ? to get help:

 Notice the router rejected the initial enable password as it did not conform to the password security requirements

 If at any point you would like to check the configuration changes made by the Cisco AutoSecure feature before saving them, you can use the show auto secure config command:

Configuring Cisco AutoSecure Non-Interactive Mode

The Non-interactive mode of Cisco’s AutoSecure is more of an ‘express’ setup feature, bypassing any user input and quickly securing the router using Cisco’s best security practices.  Think of it as a quick-and-dirty lockdown mode!

Running the Non-Interactive AutoSecure mode is done by entering the auto secure no-interact command as shown below. The router will display some information and continue configuring itself:

R1# auto secure no-interact Below is the expected output once the auto secure non-interactive command is executed:

Exploring Other Cisco AutoSecure Options

For those who like to explore all available options of the Cisco AutoSecure command, use the auto secure command, followed by a question mark ? as shown below:

Trying out different parameters and options will help gain a greater understanding of how AutoSecure works and the options it provides to help best secure your network.

Using the Cisco AutoSecure feature to secure your router(s) is a very simple task and one that should not be neglected, even by experienced network engineers. With the use of such features, one can create a configuration template with all necessary basic security measures taken into account.

Cisco provides a number of features that can help make an engineer’s every-day life more secure and hassle-free. It’s to our advantage to make the best of everything offered!

Policy-Based Routing (PBR) is a very popular feature in Cisco routers, it allows the creation of policies that can selectively alter the path  that packets take within the network. Policy-Based Routing can be used to mark packets so that certain types of traffic are prioritized over the rest, sent to a different destination or exist via a different physical interface on the router.

Classification of interesting traffic is performed using Access-Control Lists (ACLs). These can be standard, extended or named access lists as we know them.

Once the interesting traffic is ‘matched’ with the use of ACLs, the router will perform the configured ‘set’ function which is defined by the Administrator. This ‘set’ function essentially tells the router what to do with the matched traffic and can include sending it to another gateway, dropping it, prioritizing it over other traffic, and much more.

Policy-Based Routing with IP SLA Monitoring for Automatic Fail-over

This article will show how to use Policy-Based Routing to mark a specific type of traffic, for example http, and redirect it to a web proxy (usually Linux Squid) so all network web traffic is automatically filtered through the proxy.

In such setups, network users have no knowledge of the proxy’s existence as they are not required to configure their web browser to use the proxy. All user traffic is forwarded to a single gateway (Cisco ASA Firewall) and from there to router R1. This example is good solution for creating a transparent proxy with automatic failover.

Router R1, with the help of Policy-Based Routing, ‘marks’ all http traffic and then performs the appropriate ‘set’ function, which is to redirect the selected traffic to the Linux proxy with IP address 192.168.150.2.

The Linux proxy accepts the traffic, makes the necessary checks defined by the Administrator and forwards it to the Internet via R2 router.

To complement our solution we’ve added IP SLA tracking so that R1 will continuously monitor the Linux proxy to ensure it has not failed or gone offline.  If for any reason router R1 loses connectivity with the Linux proxy, the IP SLA & Policy-Based Routing mechanism will stop redirecting http traffic to it and forward it directly to the Internet via R2, effectively bypassing the failed proxy.

The next diagram shows how router R1 will respond to a failure of the Linux proxy as described above:

This solution smartly combines Cisco's Policy-Based Routing with IP SLA tracking and provides a number of benefits, some of which are:

• Automatic redirection of selected (http) traffic to the Linux Proxy.
• Transparent web proxy to all network users, with web filtering according to company policy.
• Automatic failover in case proxy fails.  Near-zero downtime.
• Continuous monitoring of proxy after failure – automatic recovery if proxy is back online.

Note: More examples of IP SLA Tracking can be found in our Configuring Static Route Tracking using IP SLA (Basic) article.

How to Configure IP SLA Tracking for a Host

First step is to configure IP SLA tracking for the desired host. This will ensure R1 router will continuously monitor the Linux proxy and stop redirecting http traffic to it in the event it fails:

The above configuration defines and starts an IP SLA probe on router R1.

The ICMP Echo probe sends an ICMP Echo (ping) packet to IP 192.168.150.2 every 4 seconds, as defined by the frequency parameter.

Timeout sets the amount of time (in milliseconds) the Cisco IOS IP SLAs operation waits for a response from its request packet. This has been set to 2000 milliseconds, or 2 seconds which gives the host ample time to respond.

Threshold sets the rising threshold that generates a reaction event and stores history information for the Cisco IOS IP SLAs operation.

After defining the IP SLA operation, our next step is to define an object that tracks the SLA probe. This can be accomplished by using the IOS Track Object as shown below:

The above command will track the state of the IP SLA operation. If there are no ping responses from the monitored IP address (192.168.150.2), the track will go down and it will come back up when the IP SLA operation starts receiving ping responses once again.

To verify the track status, use the “show track” command as shown below:

R1# show track 1
Track 1
  IP SLA 1 reachability
  Reachability is Up
    30 changes, last change 1d08h
  Latest operation return code: OK
  Latest RTT (millisecs) 1
  Tracked by:
    ROUTE-MAP 0

The command output verifies that the tracked object is UP and has a response time of 1ms.  A closer look shows that ,for the duration of the tracking, the state has changed 30 times and the last change was 1 day and 8 hours ago.  This information is extremely important should it be necessary to troubleshoot intermittent problems that might be reported by the users.

How to Configure Policy-Based Routing to Redirect Selected (http) Traffic

Once we have IP SLA up and running the next step is to configure PBR so we can redirect http traffic.

First, we need to use Access-Control Lists to select the traffic we want to redirect. Keep in mind that PBR does not limit the type of ACL that can be used. This means you can use IP named ACLs, standard ACLs, extended ACLs, time-based ACLs and others. In our example we are going to use IP named ACLs:

We've decided to name our IP-named ACL 'http-traffic'. This unique ACL name will be used later in our route-map. By making the appropriate changes in the ACLs we can define different types of traffic that will be redirected. In our example all http traffic from the 192.168.5.0 network that is destined to the Internet (any) is selected.

Now we must create a route-map that will use the above defined ACLs and instruct the router to redirect the traffic to the Linux proxy:

The above command creates a permissive route-map named linux-proxy. The match IP address parameter within the route-map informs the router which set of ACLs defines the traffic we are interested in.  Since we've defined our interesting traffic using IP named ACLs, all we need to do is reference the name of our ACL previously created.

The last command configures the route map to verify the reachability of the tracked object (192.168.150.2). If the tracked object is reachable (IP SLA reports it is reachable), then our policy-based route will redirect the defined traffic to it. If the tracked object is not reachable, (IP SLA reports the host is not reachable - down) then our policy-based route will stop redirecting traffic.

Applying the Policy-Based Route

We are almost done. The very last step is to enable and identify the route-map to be use for policy routing. This is performed by selecting the router interface for which the policy routing will be enabled, and applying the policy-route:

Route-Map & IP SLA Statistics

Keeping a close eye on the router's route-map & IP SLA  performance can be achieved with the use of a few simple commands.  Monitoring your route-map's performance the first couple of days is a very good idea as it will help verify that traffic is still being redirected to the host.

On the other hand, looking at IP SLA statistics will help identify possible failures or changes of state which were not noticed by anyone.

The show route-map command is a favourite as it combines enough information to help verify everything is working as it should:

The numbers shown here verify immediately that our host is reachable (up) and that R1 has redirected more than 510MB of traffic through the Linux proxy!

The show IP SLA statistics command provides in a similar way useful information that helps verify the object tracking is working correctly and the tracked host is up:

The most common setup of this type is one SSID providing access to the local network, while a second SSID provides guests with internet access only. The commands used in this article are applicable on all Cisco 880W series models plus most Cisco routers with integrated access points..

Configuring VLANs on the Cisco 880W (881W, 886W, 887W, 888W) Series Router

First step is to examine the VLANs required. In our example we assume two VLANs - one for the local network and one for guest Internet access. By default VLAN 1 is already created as it is the first VLAN on the router, so we will need to create the second VLAN that will serve the guest wireless network, or second SSID:

Once VLAN2 is created (cover later in this article), we can connect to the integrated access point and begin its configuration. If the integrated access point has no IP address assigned to it yet in order to telnet directly to it, you can connect from within the existing session of your Cisco 880 series router using the service-module wlan-ap 0 session command. 

Cisco Access Point Multiple - Dual SSID Configuration 

Configuring multiple SSIDs on a Cisco access point is a straightforward process, however, it does contain a few details we will analyse as we progress.

We need to now create the two SSIDs by defining their names which will be broadcast so users can find them, the encryption method to be used, wireless secret keys and lastly the VLAN assignment for each SSID:

The above configuration is quite different from setups with one SSID. The reason being the multiple SSID and VLAN configuration required to ensure each SSID is assigned to the correct VLAN. The 'Private' wireless network is assigned to VLAN 1 and the 'Guest' wireless network to VLAN 2.

Notice that when using multiple SSIDs on a Cisco access point it is imperative to use the mbssid guest-mode command otherwise the SSID name of the wireless network will not be broadcast correctly.

The dot11 vlan-name  command ensures the correct mapping of VLANs and their respective VLAN names. In our example, the VLAN names follow the actual VLAN numbers. So, VLAN 1 has been named 'VLAN 1'. This helps easily to keep track of them.

Next, we must ensure the integrated routing and bridging (IRB) feature is enabled to allow the routing of our protocols (IP) between routed interfaces and bridge groups. This command is most likely already present in the configuration, but let's play safe and enter it:

Configuring The Cisco Router Dot11Radio0 Interface

Configuring the Dot11Radio0 interface is our next step. Dot11Radio0 is the actual radio interface of the integrated Cisco access point.  We will need to assign the SSIDs configured previously, to this interface, along with the encryption methods and a few more parameters.

Most commands are self-explanatory. We will however explain the basic and important ones:

The Encryption VLAN commands set the encryption mode for each VLAN and, therefore, each SSID.  

The SSID command assigns the SSIDs to this interface.

The mbssid command ensures both SSIDs are broadcast and are viewable to our wireless clients.

The station-role root is a default command and makes the access point act as a root station, in other words as an autonomous access point.

Note the speed basic command. This is a default command that sets the supported speeds. The first portion, 1.0 to 54.0, refers to the 802.11 b/g protocol, while the m0 to m15 refers to the 802.11n protocol.

Configuring The Dot11Radio0 Sub-Interfaces

At this point we are required to configure sub-interfaces on Dot11Radio0, assigning each sub-interface to a VLAN.

When creating the subinterfaces we always use easy-to-identify methods of mapping. Thus, interface Dot11Radio0.1 means this interface will be mapped to VLAN 1, while interface Dot11Radio0.2 will map to VLAN 2.

The encapsulation dot1Q 1 native command surves two purposes. It maps VLAN 1 to sub-interface Dot11Radio0.1 and tells the access point that this VLAN (1) is the native VLAN. This means that untagged VLAN traffic belongs to VLAN 1.  More information on VLANs is available in our VLAN Section - be sure to visit it.

Similarly, under interface Dot11Radio0.2, the encapsulation dotQ 2 command maps VLAN 2 traffic to this sub-interface.

The bridge-group command assigns each sub-interface to a bridge group. Each sub-interface is assigned to its own bridge-group. The bridge group essentially connects the wireless sub-interfaces with the internal Gigabit Ethernet interface this access point has. This is analysed next.

Configuring Cisco Access Point GigabitEthernet0, Sub-Interfaces & BVI Interface

As mentioned earlier, the integrated access point connects with the Cisco 887W router via an internal GigabitEthernet link. On the access point side this is the GigabitEthernet0 interface.

Following is the configuration required to create the necessary GigabitEthernet sub-interfaces and map the Dot11Radio0.X interfaces previously created with them:

The GigabitEthernet interface and sub-interface configuration follows the same logic as the Dot11Radio0 interface. Notice that each GigabitEthernet sub-interface is mapped to the same VLAN and bridge-group as the Dot11Radio0 sub-interfaces.  

Next, we create the one and only BVI1 interface and assign it an IP Address. This is basically the IP Address of our access point and is reachable from our LAN network, so it's best to assign it an IP Address from your LAN network.

It is important to note that only one bridge-interface (BVI Interface) is configured with an IP Address. The rest of the bridge groups are not required to have a BVI interface as all traffic is trunked through the BVI1 Interface. This is per Cisco design.

Finally, we must enable ip routing for bridge 1:

This completes the setup of our Cisco 887W integrated access point. We can now move to our Cisco  887W router side, complete the configuration and get everything up and running.

Configuring The Cisco Router End - DHCP Services & VLAN Interfaces

The first step is to define the DHCP service and ip address pools for our two VLANs and, therefore, SSIDs.

Detailed instructions on setting up a DHCP Server can be found at our Cisco DHCP Server Configuration article.

To make it easy, we are providing the necessary commands for our example:

Next, we must  ensure the internal Wlan-GigabitEthernet0 interface, connecting the router with the integrated access point, is configured as a trunk port. Essentially, the router's internal Wlan-GigabitEthernet0 connects with integrated access point GigabitEthernet0 we previously configured.

By simply using the switchport mode trunk command, the router will allow all VLAN traffic, configured on both sides, to communicate between the two devices (Router - Access Point):

Lastly, we need to configure our router's VLANs. VLAN 1 is the native VLAN that connects to our local network, while VLAN 2 is used for the wireless Guest Internet access service. Note the ip addresses assigned match the networks configured in our DHCP service.  

To ensure VLAN 2 is created, we suggest you configure one of the router's FastEthernet interfaces so that it is assigned to VLAN 2. This will force the router to create VLAN 2 in its VLAN database: 

Once the switchport access VLAN 2 command is given, the router will automatically create VLAN 2 if it does not exist.  Below is the output to expect when this happens:

You can reassign the interface to VLAN 1 if you wish by using the no switchport access VLAN 2 command.

Remember  that NAT Overload is required to be configured, otherwise no one will have any Internet access.  This is covered extensively in our Cisco Router NAT Overload article.

In order to restrict the Guest VLAN from accessing our internal VLAN (VLAN 1), access lists must be configured and applied in the inbound direction on VLAN2 interface.

Summary

This article provided an in-depth coverage on how to configure a Cisco 880W series router with integrated Access Point to support multiple SSID wireless networks.  The information provided not only covers the basic commands, but also analyses the background theory and logic used for these types of configurations to ensure the reader fully understands why this method is used.

The Point-to-Point Protocol (PPP) is an encapsulation protocol that allows the transporting of network layer traffic over point-to-point links. Examples of point-to-point links are ISDN and Synchronous serial links. PPP is also described in RFC1661.

PPP Multilink is used to  take multiple PPP links and 'bond' them together, making them act as a single PPP link.  Examples of PPP Multilink can be usually found at service providers, who will bond multiple links for a customer in order to provide increased bandwidth.

For example, a company can order two E1 connections from their service provider: each E1 providing a speed of 2.048Mbits/sec. With the use of PPP Multilink we can bond these two links into one and effectively obtain a single link with the speed of 4.096Mbit/sec.

It is important to understand that PPP Multilink requires both ends to be configured the same, which means that both you and your ISP must have PPP Multilink configured otherwise the link will not work.

Configuring PPP Multilink is a pretty straightforward process, however, configuration steps can differ depending on the interfaces and protocols you are dealing with.  

Our example uses two WIC-1T interfaces, installed on our customer's router, which need to be bonded with the service provider's links. Of course, the customer has previously requested the two E1 lines to support PPP Multilink.

Configuring PPP Multilink On A Cisco Router

 First step is to configure the multilink interface on our router. The multilink interface is assigned to a multilink group:

As you can see, the configuration of the Multilink Interface is similar to that of a physical interface. The multilink interface is configured with its IP Address and ip nat outside is enabled, indicating that this virtual interface is the public interface of our router - but of course, you probably figured that out just by looking at its IP address :)

Next, we need to configure each physical serial interface and bind them both to the multilink group 1:

Verifying Our Configuration

Once the above configuration has been applied to the router, we can view the serial ports and check to see they are up and connected to the provider's DCE:

In most real-life scenarios, you are bound to see a few errors on the interfaces as it's unavoidable, however, this number should remain relatively small. The above output is from a working environment and the statistics haven't been reset for over 1.5 months.  The most important areas of the output are highlighted.

If you would like to check the clocking, but also confirm the DTE/DCE ends, simply use the 'show controllers' command. The output data from this command is quite a bit, so we've omitted the rest, keeping just the information we are interested in:

As a last step, we can view the multilink interface to ensure it's up and running as expected. Remember, we are expecting to see an interface with a bandwidth of 4096Kbit/sec:

The output of our command indicates that everything is running fine. Of course, to access the internet, NAT Overload must be configured. More information on Cisco Router NAT Overload can be found on our NAT Overload page.

Summary

In this article we covered the configuration of PPP Multilink on a Cisco router. We covered the necessary commands to ensure the selected serial interfaces are part of the Multilink bundle and verify that the Multilink interface is working correctly.

Multi-Protocol Label Switching (MPLS) networks are the next-generation of networks designed to allow customers create end-to-end circuits  across any type of transport medium using any available WAN technology.  Until recent years, customers with the need to connect remote offices in locations across the country were restricted to the limited WAN options service providers offered, usually Frame Relay or T1/E1 dedicated links. The problem with these WAN technologies is that they are usually very expensive and complex to manage, but also not very flexible, making them a headache for both the end customer and service provider. Worst of all, as the distance between the customer’s end points increased, so did the monthly bill.

How MPLS Networks Work

MPLS works by tagging the traffic entering the MPLS network. An identifier (label) is used to help distinguish the Label Switched Path (LSP) to be used to route the packet to its correct destination. Once the best LSP is identified by the router, the packet is forwarded to the next-hop router. A different label is used for every hop and the label is selected by the router (or switch) that is performing the forwarding operation.

Take for example the below diagram. It shows a simple MPLS network example where the central server is sending packets to two remote hosts.

 

The Ingress router (LSR1) accepts the packets from the server and selects the best LSP based on their destination IP Address. It then selects an initial label (local significance) for each packet and then forwards the packets using MPLS.  When Router2 receives the packets, it uses these labels to identify the LSPs from which it selects the next hops (R3 & R4) and labels (43 & 12).  At the end of the path, the egress routers (R3 & R4) remove the final label and send the packet out to the local network.

One of the great advantages offered by MPLS networks is the built-in Quality of Service mechanisms. MPLS service providers usually offer an end-to-end QoS policy to ensure their customer MPLS networks have guaranteed QoS through the MPLS network backbone. This allows delay-sensitive services such as VoIP to be implemented with guaranteed bandwidth between the endpoints.

There really is no limitation to the type of services that can be run over a MPLS network. The QoS mechanisms and prioritisation services, allow the quick and effective forwarding of traffic between customer endpoints. 

MPLS VPN Basics

MPLS VPNs combine the power of MPLS and the Border Gateway Protocol (BGP) routing protocol. MPLS is used to forward packets over the provider’s network backbone and BGP is used for distributing routes over the backbone.

A MPLS VPN is compromised of the following equipment:

1. Customer Edge (CE) routers. These are placed at the customer site and are usually owned by the customer. Some service providers also supply the CE equipment for a small rental fee.
2. Provider Edge (PE) routers. These are the provider’s edge routers to which the CE routers connect to. The PE routers are always owned by the service provider
3. Provider (P) routers. These routers are commonly referred to as ‘transit routers’ and are located in the service provider’s core network

Routing information is passed from the Customer Edge router to the Provider Edge router using either a routing protocol such as BGP or static routes.  The Provider Edge router keeps a per-site forwarding table also known as ‘VPN Routing and Forwarding tables’ or VRFs. At the Provider Edge router, each VRF serves a particular interface (or set of interfaces) that belongs to each individual VPN. Each Provider Edge router is configured by the service provider with its own VRF that is unique. Routers within the MPLS VPN network do not share VRF information directly.

The above diagram illustrates a typical MPLS VPN network where VRFs are unique for each VPN connected to a particular Provider Edge router

What’s important about MPLS VPN services is that there is no boundary to the type of WAN technology used. This means you can run MPLS over ATM (Also known as MPLS IP VPN over ADSL), leased lines, Satellite links, wireless links and much more. This flexibility makes MPLS networks a preferred method of connecting offices between each other.  The ISP provides the interface to which the local network is connected (usually a router with a LAN interface) and all that’s required is to connect the provided interface to the local network, set the necessary equipment to use the new gateway (MPLS CE router) and everything magically works!

Internet access is also possible through the MPLS IP VPN service where the service provider (ISP)  typically announces the routes of customers that require direct access to the Internet, without affecting the performance of their intrasite VPN links. For example, this means that it’s possible to have a 1024Kbps MPLS link to your ISP which splits to a 512Kbps MPLS IP VPN link to your remote site and a further 512Kbps link to the Internet.  The ISP completely separates these two virtual links, even though they run through the same interface. The link providing Internet access makes use of Network Address Translation (NAT) to translate the private network address space from the customer’s network. In this case, the customer reveals no more information to the Internet than it would with any normal connection  to the Internet.
 

Resistance to Attacks

There is a growing concern as to how secure MPLS IP VPNs really are and how they can be protected from Internet attacks.  Fortunately, the answer is pretty straight forward and doesn’t require a lot of technical analysis to see why.

In pure MPLS IP VPN environments without Internet access, where the network is used to connect different sites, the core network and customer address space is concealed 100%. This means that no information is revealed to third parties or the Internet.  With no information revealed, hackers are unable to obtain access to critical information such as router IP addresses in order to perform Denial of Service (DoS) attacks and bring down the network.

In addition, service providers prevent their routers from being reachable via the Internet by using well-known techniques such as packet filtering, applying access control lists (ACLs) to limit access only to the ports of the routing protocol (e.g BGP) from specific areas within their network.

In an environment where Internet access is provided to the customer via the MPLS link, ISP’s use similar mechanisms to lock down their Customer Edge routers that provide access to the Internet. In addition, the routing protocols used by the ISP have built-in mechanisms that are usually enabled and increase the security level even more.  A few examples are the configuration of the MD5 authentication for routing protocols (BGP, OSPF e.t.c), configuration of maximum number of routes accepted per Virtual Routing and Forwarding instance (VRF) and a few more.

MPLS IP VPN Encryption

While MPLS IP VPN provides a scalable model in which customers can securely connect remote sites between each other, there have been quite a few discussions about the encryption services offered by service providers for these circuits.

The fact is that MPLS IP VPN usually do not offer any encryption services. The MPLS VPN architecture makes it pretty impossible to hack into the MPLS circuits and expose the internal network(s) and routes, unless a major bug or configuration flaw exists somewhere in the provider’s network.

Encryption of the MPLS VPN is performed using IPSec, which essentially is a suite of protocols designed to provide a secure IP based pathway between two or more endpoints. You can read more on IPSecurity on Firewall.cx’s dedicated IPSecurity article.

Below are two examples of IPSec encryption between two sites connected via MPLS VPN:

CE-CE IPSec

In this example, the IPSec is used between the CE’s on each end, therefore the entire path between the CEs is protected. This setup offers the best possible protection against possible hacking attempts. Packets enter the CE router and are immediately encrypted. When packets are decrypted on the other end, they are located directly at the customers LAN network.

CE-CE IPSec offers true protection against the following threats:

• Anti-Replay. Replay of legitimate packets that have been recorded previously
• Change of packets that are in transit between the sites
• Eavesdropping anywhere between the CEs, PE or P routers.

PE-PE IPSec

This method is by far less secure than the previous one examined. IPSec encryption occurs from the PE routers onwards, leaving the rest of the network unencrypted and therefore not providing true VPN security.

PE-PE IPSec offers true protection against the following threats:

• Eavesdropping between the PEs or P routers
• Point-to-point connections are easy to manage but when the scenario gets more complex with multiple endpoints. IPSec tunnels do have a considerable administrative overhead that shouldn’t be taken lightly.   For example, maintaining an IPSec topology between 5 sites requires the configuration of multiple Crypto IPSec tunnels on each router located at every site. Any changes made to one router (e.g internal routes or LAN IP Addressing) requires the reconfiguration of all other routers so that the IPSec tunnels continue working correctly.

ATM (DSL) IP VPN Networks

There is no doubt about the flexibility, security and scalability of MPLS IP VPN networks. Thousands of Enterprise customers are moving from the old and expensive leased-line solutions to the much cheaper MPLS VPN alternative for all the previously mentioned reasons.

While MPLS networks have gained popularity during these last years, ATM IP VPN networks (referred to as ‘DSL IP VPNs’ from now on) are starting to gain considerable attention to the point where they are offered as an alternative to MPLS VPNs!

DSL IP VPNs rely on the customer’s direct Internet connection to create a VPN IPSec tunnel between two endpoints.  A typical scenario is a customer with two sites that require connectivity between each other.  Both sides are equipped with a fast DSL connection using static IP addresses. The configuration is performed on the Customer Edge routers to create an IPSec tunnel between the two sites.

In most cases, the end result is pretty much the same as any MPLS network, but one could argue about the security offered by such a setup, especially when the CE routers are directly connected to the Internet.  Tests performed by large vendors such as Cisco Systems have proven that the security provided in these solutions is directly comparable with that of an MPLS VPN, considering of course proper configuration of the CE routers has been performed.

The advantages offered by DSL IP VPNs is that the costs are extremely low and equal to that of each side’s connection to the Internet.  Companies seeking to cut costs on data telecommunication services are already moving to this new trend which has become extremely popular in Europe and Asia.

Despite the advantages, one must keep in mind the following disadvantages DSL IP VPNs have:

• In order to obtain high VPN speeds between sites, both CE routers must connect to the same ISP so they run on a common backbone.
• CE Routers are directly exposed to the Internet and therefore are vulnerable to DoS attacks
• QoS is not usually guaranteed. Because packets are routed through the ISP backbone using the same path and priority normal Internet users have, there is no QoS guarantee
• Limited scalability. Site to Site DSL IP VPN is great for up to a few sites. Depending on the amount of users  located on each site, more than one DSL connection might be required per site

In our next article we will examine DSL IP VPNs in much greater depth, including DSL IP VPN requirements, their security encryption mechanisms, QoS methods, backup methods, and much more.

This article was written by Chris Partsenidis, for Techtarget.com.

The best and simplest way to achieve WAN redundancy on Cisco devices is to use Reliable Static backup routes with IP SLA tracking.

IP SLAs is a feature included in the Cisco IOS Software that can allow administrators the ability to Analyze IP Service Levels for IP applications and services. IP SLA's uses active traffic-monitoring technology to monitor continuous traffic on the network. This is a reliable method in measuring over head network performance. Cisco Routers provide IP SLA Responders that give accuracy of measured data across a network.

With IP SLAs, routers and switches perform periodic measurements. The number and type of available measurements are vast and in this article we will be covering just the ICMP ECHO feature. IP SLA in itself is a very big topic to cover.

Users interested can head to our Cisco Routers section where they can find a number of articles covering IP SLA configuration on Cisco routers.

Let us take an example of a basic redundant WAN link scenario as shown below:

In the above figure the Cisco device is connected to two WAN links ISP1 and ISP2. The most common setup that we use in day to day life is to have to default routes configured on the Cisco router pointing to the respective next hop IPs as shown below:

If you notice the Administrative Distance for the secondary route pointing to ISP2 is increased to 10 so that it becomes the backup link.

The above configuration with just two floating static routes partially accomplishes our requirement as it will work only in the scenario where the routers interfaces connected to the WAN link are in up/down or down/down status. But in a lot of situations we see that even though the links remain up but we are not able to reach the gateway, this usually happens when the issue is at the ISP side.

In such scenarios, IP SLAs becomes an engineer's best friend. With around six additional IOS commands we can have a more reliable automatic failover environment.

Using IP SLA the Cisco IOS gets the ability to use Internet Control Message Protocol (ICMP) pings to identify when a WAN link goes down at the remote end and hence allows the initiation of a backup connection from an alternative port. The Reliable Static Routing Backup using Object Tracking feature can ensure reliable backup in the case of several catastrophic events, such as Internet circuit failure or peer device failure.

IP SLA is configured to ping a target, such as a publicly routable IP address or a target inside the corporate network or your next-hop IP on the ISP's router. The pings are routed from the primary interface only. Following a sample configuration of IP SLA to generate icmp ping targeted at the ISP1s next-hop IP.

Please note that the Cisco IP SLA commands have changed from IOS to IOS to know the exact command for IOS check the Cisco documentation. The above commands are for IOS 12.4(4)T, 15.(0)1M, and later releases.

The above configuration defines and starts an IP SLA probe.

The ICMP Echo probe sends an ICMP Echo packet to next-hop IP 2.2.2.2 every 3 seconds, as defined by the “frequency” parameter.

Timeout sets the amount of time (in milliseconds) for which the Cisco IOS IP SLAs operation waits for a response from its request packet.

Threshold sets the rising threshold that generates a reaction event and stores history information for the Cisco IOS IP SLAs operation.

After defining the IP SLA operation our next step is to define an object that tracks the SLA probe. This can be accomplished by using the IOS Track Object as shown below:

The above command will track the state of the IP SLA operation. If there are no ping responses from the next-hop IP the track will go down and it will come up when the ip sla operation starts receiving ping response.

To verify the track status use the use the show track command as shown below:

The above output shows that the track status is down. Every IP SLAs operation maintains an operation return-code value. This return code is interpreted by the tracking process. The return code may return OK, OverThreshold, and several other return codes.

Different operations may have different return-code values, so only values common to all operation types are used. The below table shows the track states as per the IP SLA return code.

The Last step in the IP SLA Reliable Static Route configuration is to add the track statement to the default routes pointing to the ISP routers as shown below:

The track number keyword and argument combination specifies that the static route will be installed only if the state of the configured track object is up. Hence if the track status is down the secondary route will be used to forward all the traffic.

If you would like to learn how to configure IP SLA Tracking with Policy-Based Routing to automatically redirect specific type of traffic to other gateways or hosts, visit our Configuring Policy-Based Routing (PBR) with IP SLA Tracking - Auto Redirecting Traffic article.

A DHCP Server is considered necessary in today's networks. Devices usally found providing this service are Windows servers, routers and layer 3 switches.

This article describes how to configure basic DHCP parameters on a Cisco router, enabling it to act as a DHCP server for your network.

Cisco Router DHCP Configuration - Example Scenario

For the sake of this article, suppose we have the network shown in the following diagram, for which we would like to enable the DHCP service on our Cisco router.

The router will act as a DHCP server for the 192.168.1.0/24 network. IP Addresses already assigned to our switch (192.168.1.2) and File Server (192.168.1.5) will be excluded from the DHCP pool, to ensure they are not given out to other hosts and cause an IP address conflict.

First step is to enable the DHCP service on our router, which by default is enabled.

First step is to enable the DHCP service on our router, which by default is enabled:

Next step is to create the DHCP pool that defines the network of IP addresses that will be given out to the clients. Note that 'NET-POOL' is the name of the DHCP IP Pool we are creating:

This tells the router to issue IP addresses for the network 192.168.1.0, which translates to the range 192.168.1.1 - 192.168.1.254. We will have to exclude the IP addresses we want later on.

We now define the DHCP parameters that will be given to each client. These include the default gateway (default-router), dns servers, domain and lease period (days):

 The domain-name and lease parameters are not mandatory. By default, the lease time for an IP address is one day, however we can specify any time range we need. For example, if we need to set the lease time for 4 hours and 30 minutes we would use the following command under our DHCP pool:

R1(dhcp-config)# lease 0 4 30

The above command is interpreted as follows: 0 (Zero) days, 4 hours and 30 minutes.

All we need now is to exclude the IP addresses we don't want our DHCP server giving out. Drop back to 'global configuration mode' and enter the following:

This excludes IP addresses 192.168.1.1 - 192.168.1.5 & 192.168.1.10. As you can see, there's an option to exclude a range of IP addresses or a specific address.

The above configuration is all you need to get the DHCP server running for your network. We'll provide a few more commands you can use to troubleshoot and ensure it's working correctly.

The following command will allow you to check which clients have been served by the DHCP:

Notice that IP addresses 192.168.1.5 & 192.168.1.10 have not been assigned to the clients.

Summary

In this article we've covered how to configure a Cisco router to act as a DHCP server and configure available DHCP options. We also saw how you can obtain general information about the service. There are more options available with the DHCP service, however this basic article should cover most of your network needs.

Future DHCP articles will explore advanced options and debugging for more complex networks containing VLANs and IP Telephony.

If you had a domain name, e.g Firewall.cx, you would then map your static IP address to your domain (via DNS) so when you hit your domain name, you would be directed to your statically assigned IP address and access the resources you need.

While this is the recommended setup for most companies doing serious business, it doesn't really apply to home users or small branch offices because of the increased cost for static IP addresses.

The solution to the above problem is named 'DDNS' - Dynamic DNS Service. DDNS providers allow the registeration and creation of Fully Qualified Domain Names (FQDN) that can be mapped to home or branch office Internet connections without cost . This eliminates the need for a static IP address, since the DDNS provider will automatically update its DNS records with your dynamic IP address every time it changes.

From Cisco IOS version 12.4 onwards, Cisco routers have built-in support for a variety of DDNS providers, making it much easier and a more reliable alternative, as you no longer require a PC in your network that will run the DDNS provider's client program.

This article will show you how you can configure your Cisco router so it can support the DDNS service with No-IP.com and DynDNS.com. Detailed Cisco router CLI commands and debugging information is included to ensure correct configuration and results are obtained.

DDNS Example Scenario

Consider the following network diagram. It shows the simple logic of how DDNS works:

Firstly we need to configure our Cisco router to register and send its periodical updates to the DDNS provider. Once received, the DDNS provider updates the relevant DNS records, in our example, firewallcx.no-ip.info.

When an Internet host queries the DDNS provider for the domain firewallcx.no-ip.info, it will then point the host towards the public IP addresses currently assigned to the router, that is, 195.162.29.1. As the ISP changes the IP address it assigned to the Cisco router, the router in turn will also update its DDNS provider. This way, the domain firewallcx.no-ip.info is always updated no matter how many times its IP address changes.

So, without further delay, here's how you can configure your Cisco router to register with the following DDNS providers:

1) No-ip.com

2) Dyndns.com

Case No.1: Configuring Support For No-ip.com

First step is to enable the DNS service and configure an IP name server (public DNS server) so it can successfully resolve Internet domain names. For our example, we are using Public DNS servers:

 Next, we need to enable the DDNS update service and give it a name (no-ip), and then select the update method to be used, for this example, it's HTTP:

 Now we add the authentication details. The router will use this information to authenticate to the DDNS provider so it can then update the necessary hostname. We should note that each DDNS provider uses its own authentication method & parameters. In No-ip.com's case, it makes use of a login name & password, where the login name is your registered email address.

The command will look something like this:

As noted, the login name is the registered email address. This means that the full syntax above will contain two "@" characters, which can create a problem with the URL sent to the DDNS provider. In addition, the question mark "?" character cannot be inserted straight into the command as the router will consider it as a help request and provide a list of parameters and commands. For this reason, it is required to enter CTRL+V, then insert the "?" character. The same procedure applies for the "@" symbol. Also keep in mind that the command below is entered as one single line:

In the above command, the <h> variable will be substituted with the FQDN that needs to be updated (firewallcx.no-ip.info) which we will configure next, and the <a> variable will be substituted with the IP address of the interface we have enabled for the DDNS updates.

In the next step, we set the update interval, to ensure the FQDN is updated as frequently possible, but without causing problems to the DDNS provider:

The above command sets the update interval to 0 Days, 0 Hours, 5 Minutes and 0 Seconds.

Last step is to set the FQDN we'll be updating and enable the DDNS service on our public interface (usually the Dialer 0 or public FastEthernet interface):

This completes the setup and your router should start sending its updates to the DDNS provider.

If you see that your FQDN hasn't been updated after 5-10 minutes, then you can also use the following debug commands (hit CTRL-Z first) to get an idea of what's happening in the background:

Here are the results of our debug:

Case No.2: Configuring Support for Dyndns.com

Dyndns.com requires a similar configuration as our previous DDNS provider, however, the HTTP authentication string is slightly different, and you'll need to adjust your update interval to once a day rather than every 5 minutes. The interval adjustment is very important as Dyndns.com is unfortunately less forgiving than No-ip.com and will lock your account if multiple updates occur without your IP address having been changed!

The following cli code is the actual configuration required up till the authentication method:

 The HTTP authentication string required for Dyndns.com will look something like this:

In order to insert the "@" and "?" symbol, it is required to enter CTRL+V before each character, as explained previously.

Again, the <h> will be substituted with the FQDN that needs to be updated (firewallcx.dyndns.info) which we will configure next, and the <a> will be substituted with the IP address of the interface we have enabled for the DDNS updates.

Next up, we set the update interval to ensure the FQDN is updated as frequently as possible. DynDNS is a bit sensitive on regular update, so we set it to once a day:

The above command sets the update interval to 1 Day, 0 Hours, 0 Minutes and 0 Seconds.

As a final step, we set the FQDN we'll be updating and enable the DDNS service on our public interface (usually your Dialer 0 or public Ethernet interface):

This completes the setup and your router should start sending its updates to the DDNS provider.

If you see that the your FQDN hasn't been updated after 5-10 minutes, then you can also use the following debug commands (hit CTRL-Z first) to get an idea on what's happening in the background:

Summary

In this article we've covered how to enable and configure Dynamic DNS on a Cisco router to support no-ip.com and dyndns.com. We've seen the process in great depth and analysed all commands required to get the service up and running, but also debug it in case of problems.

Closing, we hope the article comes in handy and answers your questions regarding the configuration of DDNS on Cisco routers.

Accessing a Cisco router requires certain privileges. Depending on the router's configuration, you might be required to firstly log into the router and then enter the popular 'enable' password to elevate your access to privileged mode, from where you can issue configuration commands.

This article will show you how you can gain full administrator access to a Cisco router, bypassing all security passwords. The password recovery process, however, can be rendered useless if the administrator has previously configured the router not to allow this process to take place. In this case, the router will warn the user and, if he proceeds, all configuration will be erased, so there will be nothing to recover!

Example Scenario

Consider we have a Cisco router (2610 for our example - this procedure is the same for all routers) and we are unable to access it due to a lost password. Console and VTY (telnet) sessions ask for a password which we do not have:

Even if we were able to successfully log into the router, but couldn't provide the router with the correct 'enable' password, we would still need to perform a password recovery procedure.

To initiate the password recovery procedure, connect the rollover cable to the console port, then power the router off and back on. As soon as you receive a prompt showing the boot process, hit Ctrl-Break:

 You'll immediately see the 'rommon' prompt, indicating we are in 'rom monitor' mode. This is a mini-IOS that allows you to perform very specific tasks in order to recover your router.

Now, to skip our password-protected configuration, we instruct the router to by-pass the configuration located in NVRAM during bootup, and reset the router:

The router will now reset and start its normal bootup process, however, the current configuration will be ignored. When the bootup is complete, you will be prompted to 'enter the initial configuration dialog', answer 'no':

Next step is to enter 'Privileged Mode' and load the router's configuration from nvram. Then reset the 'enable' or 'secret' password. To be sure, we're showing how to reset both, but we'll only need to use the 'secret' password. In addition, we are going to reset the console port's password:

If you use the 'login local' command you'll need to reset the user account of the password you have lost (in our example, it's 'admin').

Lastly, we need to change the 'configuration register' so the router will load the newly modified configuration next time it reboots, save our settings and reboot the router:

The router will now reload and use the new configuration that contains the newly set passwords.

When the router reboots, log in and check your configuration. If you find any interfaces in the 'shutdown' state, you'll need to use the 'no shutdown' command to bring them back up.

Again, don't forget to save your configuration once all changes are complete!

Summary

We've shown you how to recover lost passwords and gain control of a Cisco router. Of course there are mechanisms, which can be enabled, that will not allow you to perform the password recovery procedure. In this case, any attempt to recover the passwords or configuration will result in the erasure of the device's configuration!

To initiate the connection, we use the Cisco VPN client, available for Windows operating systems (XP, Vista, Windows 7 - 32 & 64bit), Linux, Mac OS X10.4 & 10.5 and Solaris UltraSPARC (32 & 64bit), making it widely available for most users around the globe. Cisco VPN Clients are available for download from our Cisco Downloads section.

The Cisco VPN also introduces the concept of ‘Split Tunneling'. Split tunneling is a feature that allows a remote VPN client access the company's LAN, but at the same time surf the Internet. In this setup, only traffic destined to the company's LAN is sent through the VPN tunnel (encrypted) while all other traffic (Internet) is routed normally as it would if the user was not connected to the company VPN.

Some companies have a strict policy that does not allow the remote VPN client access the Internet while connected to the company network (split tunneling disabled) while others allow restricted access to the Internet via the VPN tunnel (rare)! In this case, all traffic is tunnelled through the VPN and there's usually a web proxy that will provide the remote client restricted Internet access.

From all the above, split tunneling is the most common configuration of Cisco VPN configuration today, however for educational purposes, we will be covering all methods.

Setting up a Cisco router to accept remote Cisco VPN clients is not an extremely difficult task. Following each step shown in this article will guarantee it will work flawlessly.

Below is a typical diagram of a company network providing VPN access to remote users in order to access the company's network resources.

The VPN established is an IPSec secure tunnel and all traffic is encrypted using the configured encryption algorithm:

Engineers and administrators who need to restrict VPN user access to Layer-4 services e.g www, smtp, pop on a specific internal host (e.g web/email server) should read our How to Restrict Cisco IOS Router VPN Client to Layer-4 (TCP, UDP) Services - Applying IP, TCP & UDP Access Lists article.

The Cisco IPSec VPN has two levels of protection as far as credentials concern. The remote client must have valid group authentication credential, followed by valid user credential.

The group credentials are entered once and stored in the VPN connection entry, however the user credentials are not stored and requested every time a connection is established:

We should note that configuring your router to support Point-to-Point Tunnel Protocol VPN (PPTP) is an alternative method and covered on our Cisco PPTP Router Configuration article, however PPTP VPN is an older, less secure and less flexible solution. We highly recommend using Cisco IPSec VPN only.

In order to configure Cisco IPSec VPN client support, the router must be running at least the 'Advanced Security' IOS otherwise most of the commands that follow will not be available at the CLI prompt!

To begin, we need to enable the router's 'aaa model' which stands for 'Authentication, Authorisation and Accounting'. AAA provides a method for identifying users who are logged in to a router and have access to servers or other resources.

AAA also identifies the level of access that has been granted to each user and monitors user activity to produce accounting information.

We enable the 'aaa new-model' service followed by X-Auth for user authentication and then group authentication (network vpn_group_ml_1):

When trying to establish an IPSec tunnel, there are two main phase negotiations where the remote client negotiates the security policies and encryption method with the Cisco VPN router.

Now we create the user accounts that will be provided to our remote users. Each time they try to connect to our VPN, they will be required to enter this information:

We next create an Internet Security Association and Key Management Protocol (ISAKMP) policy for Phase 1 negotiations. In this example, we've create two ISAKMP policies, and configure the encryption (encr), authentication method, hash algorithm and set the Diffie-Hellman group:

We now create a group and configure the DNS server and other parameters as required. These parameters are passed down to the client as soon as it successfully authenticates to the group:

The above configuration is for the 'CCLIENT-VPN' group with a pre-share key (authentication method configured previously) of 'firewall.cx'. Users authenticating to this group will have their DNS set to 10.0.0.10. A maximum of 5 users are allowed to connect simultaneously to this group and will have access to the resources governed by access-list 120.

Lastly, users authenticating to this group will obtain their IP address from the pool named 'VPN-Pool' that provides the range of IP address: 192.168.0.20 up to 192.168.0.25.

Creation of the Phase 2 Policy is next. This is for actual data encryption & IPSec phase 2 authentication:

The transformation named 'encrypto-method-1' is then applied to an IPSec profile named 'VPN-Profile-1':

 Note the encryption and authentication method of our IPSec crypto tunnel as shown by a connected VPN client to the router with the above configuration:

Now its time to start binding all the above together by creating a virtual-template interface that will act as a 'virtual interface' for our incoming VPN clients. Remote VPN clients will obtain an IP address that is part of our internal network (see diagram above - 192.168.0.x/24) so we therefore do not require this virtual interface to have an ip address and configure it as an 'ip unnumbered' interface on our router's LAN interface.

Setting an interface as an ip unnumbered enables IP processing through it without assigning an explicit IP address, however you must bind it to a physical interface that does have an IP address configured, usually your LAN interface:

Above, our virtual template also inherits our configured encryption method via the 'ipsec profile VPN-Profile-1' command which sets the transform method to 'encrypt-method-1' (check previous configuration block) which in turn equals to 'esp-3des esp-sha-hmac'.

Notice how Cisco's CLI configuration follows a logical structure. You configure specific parameters which are then used in other sections of the configuration. If this logic is understood by the engineer, then decoding any given Cisco configuration becomes an easy task.

So far we've enabled the authentication mechanisms (aaa), created an ISAKMP policy, created the VPN group and set its parameters, configured the encryption method (transform-set) and binded it to the virtual template the remote VPN user will connect to.

Second-last step is to create one last ISAKMP profile to connect the VPN group with the virtual template:

Last step is the creation of our access lists that will control the VPN traffic to be tunnelled, effectively controlling what our VPN users are able to access remotely.

Once that's done, we need to add a 'no NAT' statement so that traffic exiting the router and heading toward the VPN user is preserved with its private IP address, otherwise packets sent through the tunnel by the router, will be NAT'ed and therefore rejected by the remote VPN Client.

When NAT is enabled through a VPN tunnel, the remote user sees the tunnelled traffic coming from the router's public IP address, when in fact it should be from the router's private IP address.

We assume the following standard NAT configuration to provide Internet access to the company's LAN network:

Based on the above, we proceed with our configuration. First, we need to restrict access to our remote VPN users, so that they only access our SQL server with IP address 192.168.0.6 (access-list 120), then we deny NAT (access-list 100) to our remote VPN Pool IP range:

R1(config)# access-list 120 remark ==[Cisco VPN Users]==
R1(config)# access-list 120 permit ip host 192.168.0.6 host 192.168.0.20
R1(config)# access-list 120 permit ip host 192.168.0.6 host 192.168.0.21
R1(config)# access-list 120 permit ip host 192.168.0.6 host 192.168.0.22
R1(config)# access-list 120 permit ip host 192.168.0.6 host 192.168.0.23
R1(config)# access-list 120 permit ip host 192.168.0.6 host 192.168.0.24
R1(config)# access-list 120 permit ip host 192.168.0.6 host 192.168.0.25

R1(config)# no access-list 100
R1(config)# access-list 100 remark [Deny NAT for VPN Clients]=-
R1(config)# access-list 100 deny ip 192.168.0.0 0.0.0.255 host 192.168.0.20
R1(config)# access-list 100 deny ip 192.168.0.0 0.0.0.255 host 192.168.0.21
R1(config)# access-list 100 deny ip 192.168.0.0 0.0.0.255 host 192.168.0.22
R1(config)# access-list 100 deny ip 192.168.0.0 0.0.0.255 host 192.168.0.23
R1(config)# access-list 100 deny ip 192.168.0.0 0.0.0.255 host 192.168.0.24
R1(config)# access-list 100 deny ip 192.168.0.0 0.0.0.255 host 192.168.0.25
R1(config)# access-list 100 remark
R1(config)# access-list 100 remark -=[Internet NAT Service]=-
R1(config)# access-list 100 permit ip 192.168.0.0 0.0.0.255 any

Note that for access-list 100, we could either 'deny ip host 192.168.0.6' to our remote clients, or as shown, deny the 192.168.0.0/24 network. What's the difference? Practically none. Denying your whole network the NAT service toward your remote clients, will make it easier for any future additions.

If for example there was a need to deny NAT for another 5 servers so they can reach remote VPN clients, then the access-list 100 would need to be edited to include these new hosts, where as now it's already taken care of. Remember, with access-list 100 we are simply controlling the NAT function , not the access the remote clients have (done with access-list 120 in our example.

At this point, the Cisco VPN configuration is complete and fully functional.

VPN - Split Tunneling

We mentioned in the beginning of this article that we would cover split tunneling and full tunneling methods for our VPN clients. You'll be pleased to know that this functionality is solely determined by the group's access-lists, which our case is access-list 120.

If we wanted to tunnel all traffic from the VPN client to our network, we would use the following access-list 120 configuration:

R1(config)# access-list 120 remark ==[Cisco VPN Users]==
R1(config)# access-list 120 permit ip any host 192.168.0.20
R1(config)# access-list 120 permit ip any host 192.168.0.21
R1(config)# access-list 120 permit ip any host 192.168.0.22
R1(config)# access-list 120 permit ip any host 192.168.0.23
R1(config)# access-list 120 permit ip any host 192.168.0.24
R1(config)# access-list 120 permit ip any host 192.168.0.25

In another example, if we wanted to provide our VPN clients access to networks 10.0.0.0/24, 10.10.10.0/24 & 192.168.0.0/24, here's what the access-list 120 would look like (this scenario requires modification of NAT access-list 100 as well):

R1(config)# access-list 120 remark ==[Cisco VPN Users]==
R1(config)# access-list 120 permit ip 10.0.0.0 0.0.0.255 host 192.168.0.20
R1(config)# access-list 120 permit ip 10.0.0.0 0.0.0.255 host 192.168.0.21
R1(config)# access-list 120 permit ip 10.0.0.0 0.0.0.255 host 192.168.0.22
R1(config)# access-list 120 permit ip 10.0.0.0 0.0.0.255 host 192.168.0.23
R1(config)# access-list 120 permit ip 10.0.0.0 0.0.0.255 host 192.168.0.24
R1(config)# access-list 120 permit ip 10.0.0.0 0.0.0.255 host 192.168.0.25
R1(config)#
R1(config)# access-list 120 permit ip 10.10.10.0 0.0.0.255 host 192.168.0.20
R1(config)# access-list 120 permit ip 10.10.10.0 0.0.0.255 host 192.168.0.21
R1(config)# access-list 120 permit ip 10.10.10.0 0.0.0.255 host 192.168.0.22
R1(config)# access-list 120 permit ip 10.10.10.0 0.0.0.255 host 192.168.0.23
R1(config)# access-list 120 permit ip 10.10.10.0 0.0.0.255 host 192.168.0.24
R1(config)# access-list 120 permit ip 10.10.10.0 0.0.0.255 host 192.168.0.25
R1(config)#
R1(config)#
R1(config)# access-list 120 permit ip 192.168.0.0 0.0.0.255 host 192.168.0.20
R1(config)# access-list 120 permit ip 192.168.0.0 0.0.0.255 host 192.168.0.21
R1(config)# access-list 120 permit ip 192.168.0.0 0.0.0.255 host 192.168.0.22
R1(config)# access-list 120 permit ip 192.168.0.0 0.0.0.255 host 192.168.0.23
R1(config)# access-list 120 permit ip 192.168.0.0 0.0.0.255 host 192.168.0.24
R1(config)# access-list 120 permit ip 192.168.0.0 0.0.0.255 host 192.168.0.25
R1(config)#
R1(config)#
R1(config)# no access-list 100
R1(config)# access-list 100 remark [Deny NAT for VPN Clients]=-
R1(config)# access-list 100 deny ip 10.0.0.0 0.0.0.255 host 192.168.0.20
R1(config)# access-list 100 deny ip 10.0.0.0 0.0.0.255 host 192.168.0.21
R1(config)# access-list 100 deny ip 10.0.0.0 0.0.0.255 host 192.168.0.22
R1(config)# access-list 100 deny ip 10.0.0.0 0.0.0.255 host 192.168.0.23
R1(config)# access-list 100 deny ip 10.0.0.0 0.0.0.255 host 192.168.0.24
R1(config)# access-list 100 deny ip 10.0.0.0 0.0.0.255 host 192.168.0.25
R1(config)#
R1(config)#
R1(config)# access-list 100 deny ip 10.10.10.0 0.0.0.255 host 192.168.0.20
R1(config)# access-list 100 deny ip 10.10.10.0 0.0.0.255 host 192.168.0.21
R1(config)# access-list 100 deny ip 10.10.10.0 0.0.0.255 host 192.168.0.22
R1(config)# access-list 100 deny ip 10.10.10.0 0.0.0.255 host 192.168.0.23
R1(config)# access-list 100 deny ip 10.10.10.0 0.0.0.255 host 192.168.0.24
R1(config)# access-list 100 deny ip 10.10.10.0 0.0.0.255 host 192.168.0.25
R1(config)#
R1(config)#
R1(config)# access-list 100 deny ip 192.168.0.0 0.0.0.255 host 192.168.0.20
R1(config)# access-list 100 deny ip 192.168.0.0 0.0.0.255 host 192.168.0.21
R1(config)# access-list 100 deny ip 192.168.0.0 0.0.0.255 host 192.168.0.22
R1(config)# access-list 100 deny ip 192.168.0.0 0.0.0.255 host 192.168.0.23
R1(config)# access-list 100 deny ip 192.168.0.0 0.0.0.255 host 192.168.0.24
R1(config)# access-list 100 deny ip 192.168.0.0 0.0.0.255 host 192.168.0.25
R1(config)# access-list 100 remark
R1(config)# access-list 100 remark -=[Internet NAT Service]=-
R1(config)# access-list 100 permit ip 10.0.0.0 0.0.0.255 any
R1(config)# access-list 100 permit ip 10.10.10.0 0.0.0.255 any
R1(config)# access-list 100 permit ip 192.168.0.0 0.0.0.255 any

 When the VPN client connects, should we go to the connection's statistics, we would see the 3 networks under the secure routes, indicating all traffic toward these networks is tunnelled through the VPN:

 Cisco VPN Configuration Tips

Engineers and administrators who need to restrict VPN user access to Layer-4 services e.g www, smtp, pop on a specific internal host (e.g web/email server) should read our How to Restrict Cisco IOS Router VPN Client to Layer-4 (TCP, UDP) Services - Applying IP, TCP & UDP Access Lists article.

It is evident from our last example with the tunneling of our 3 networks, that should our VPN IP address pool be larger, for example 50 IP addresses, then we would have to enter 50 IPs x 3 Networks = 150 lines of code just for the access-list 120, plus another 150 lines for access-list 100 (no NAT)! That is quite a task indeed!

To help cut down the configuration to just a couple of lines, this is the alternative code that would be used and have the same effect:

Mark VPN Traffic to be tunnelled:

R1(config)# access-list 120 remark ==[Cisco VPN Users]==
R1(config)# access-list 120 permit ip 10.0.0.0 0.0.0.255 192.168.0.0 0.0.0.255
R1(config)# access-list 120 permit ip 10.10.10.0 0.0.0.255 192.168.0.0 0.0.0.255
R1(config)# access-list 120 permit ip 192.168.0.0 0.0.0.255 192.168.0.0 0.0.0.255

Do not NAT any traffic from our LANs toward VPN clients, but NAT everything else destined to the Internet:

R1(config)# access-list 100 remark [Deny NAT for VPN Clients]=-
R1(config)# access-list 100 deny ip 10.0.0.0 0.0.0.255 192.168.0.0 0.0.0.255
R1(config)# access-list 100 deny ip 10.10.10.0 0.0.0.255 192.168.0.0 0.0.0.255
R1(config)# access-list 100 deny ip 192.168.0.0 0.0.0.255 192.168.0.0 0.0.0.255
R1(config)# access-list 100 remark
R1(config)# access-list 100 remark -=[Internet NAT Service]=-
R1(config)# access-list 100 permit ip 10.0.0.0 0.0.0.255 any
R1(config)# access-list 100 permit ip 10.10.10.0 0.0.0.255 any
R1(config)# access-list 100 permit ip 192.168.0.0 0.0.0.255 any

The access-list 120 instructs the router to tunnel all traffic from the three networks to our VPN clients who's IP address will be in the 192.168.0.0/24 range!

So, if the VPN client received from the VPN Pool, IP address 192.168.0.23 or 192.168.0.49, it really wouldn't matter as the '192.168.0.0 0.0.0.255' statement at the end of each access-list 120 covers both 192.168.0.23 & 192.168.0.49. Even replacing the '192.168.0.0 0.0.0.255' with the 'any' statement would have the same effect.

For 'access-list 100' that controls the NAT service, we cannot use the 'any' statement at the end of the DENY portion of the ACLs, because it would exclude NAT for all networks (public and private) therefore completely disabling NAT and as a result, Internet access.

As a last note, if it was required the VPN clients to be provided with an IP address range different from that of the internal network (e.g 192.168.50.0/24), then the following minor changes to the configuration would have to be made:

R1(config)# access-list 120 remark ==[Cisco VPN Users]==
R1(config)# access-list 120 permit ip 10.0.0.0 0.0.0.255 192.168.50.0 0.0.0.255
R1(config)# access-list 120 permit ip 10.10.10.0 0.0.0.255 192.168.50.0 0.0.0.255
R1(config)# access-list 120 permit ip 192.168.0.0 0.0.0.255 192.168.50.0 0.0.0.255

Do not NAT any traffic from our LANs toward VPN clients, but NAT everything else destined to the Internet:

R1(config)# access-list 100 remark [Deny NAT for VPN Clients]=-
R1(config)# access-list 100 deny ip 10.0.0.0 0.0.0.255 192.168.50.0 0.0.0.255
R1(config)# access-list 100 deny ip 10.10.10.0 0.0.0.255 192.168.50.0 0.0.0.255
R1(config)# access-list 100 deny ip 192.168.0.0 0.0.0.255 192.168.50.0 0.0.0.255
R1(config)# access-list 100 remark
R1(config)# access-list 100 remark -=[Internet NAT Service]=-
R1(config)# access-list 100 permit ip 10.0.0.0 0.0.0.255 any
R1(config)# access-list 100 permit ip 10.10.10.0 0.0.0.255 any
R1(config)# access-list 100 permit ip 192.168.0.0 0.0.0.255 any

Summary

This article explained the fundamentals of Cisco's VPN client and features it offers to allow the remote and secure connection of users to their corporate networks from anywhere in the world.

We examined the necessary steps and commands required on a Cisco router to setup and configure it to accept Cisco VPN client connections. Detailed explanation was provided for every configuration step, along with the necessary diagrams and screenshots.

Split tunneling was explained and covered, showing how to configure the Cisco VPN clients access only to the required internal networks while maintaining access to the Internet.

Lastly, a few tips were presented to help make the Cisco VPN configuration a lot easier for large and more complex networks.

For security reasons, we do not keep any history of decoded passwords.

Ensure you only enter the encrypted password. For example, for the code below, you would paste the yellow highlighted portion. Do not include anything before the encrypted password.

username fcx password 7 0709285E4B1E18091B5C0814

When ready, click on the Submit button. The system will then process and reveal the text-based password. Ensure there are no space characters in front of your encrypted password.

More Information On Cisco Passwords and Which can be Decoded

Back in late 1995, a non-Cisco source had released a program that was able to decrypt user passwords (and other type of passwords) in Cisco configuration files.

This new program was a major headache for Cisco since most users were relying on Cisco's equipment for their repulation of strong encryption and security capabilities. What users were not aware was that there are two different type of encryption mechanisms used by Cisco's IOS, one which was reversable (Type 7 Passwords) and one which is not (Type 5).

Even until today, administrators and users still make use of the weaker Type 7 passwords, mainly because they aren't aware that these passwords can be decrypted.

Knowing what Can and Cannot be Decrypted

It is important to understand that only the following type of passwords are able to be decrypted. Thefollowing examples show which common areas Type 7 passwords are used in Cisco equipment:

User Passwords

Used to create users with different privilege levels on Cisco devices.

 Enable Password

Used to gain elevated access on the Cisco device.

 Access Point SSID Keys

Used to configure the SSID key on a Cisco wireless access point:

If wpa-psk ascii 0 is used then the ascii text that follows is clear text and its not encrypted.

Encryption Methods That Cannot be Decrypted

As opposed to Type 7 Passwords which can easily be decrypted, Secret 5 passwords cannot be decrypted as the password has ben hashed with MD5. This is also the recommened way of creating and storing passwords on your Cisco devices.

Following are a number of examples where Secret 5 passwords can and should be used:

User Passwords

Enable Password

Unfortunately Access Point SSID Keys do not support Type 5 passwords. This means that any passwords configured into the access point should be stored in a safe place.

 We trust the information was valuable and hope users will stop using Type 7 Passwords in mission critical equipment.

By disabling the Password-Recovery service you prevent anyone with physical access to the device (e.g console port) from performing the Password-Recovery process and obtaining access to its configuration.

Disabling the Password-Recovery service requires extreme attention because should you loose your password, there is no turning back. It is highly advisable to always keep a backup of your configurations in a secure area - just in case.

Note: To decrypt/crack Cisco Passwords, visit our Cisco Password Crack page.

You will also notice that the 'no service password-encryption' command will not show up when hitting '?' (for help) as this command is undocumented in the IOS help.

Following are the steps to disable the Password-Recovery service and the message confirmation shown when the device boots up after the Password-Recovery service is disabled:

Summary

This article explains the password-recovery service and how to disable it on a Cisco device.

While some believe the term 'router-on-a-stick' sounds a bit silly, it's a very popular term and commonly used in networks where no layer-3 switch exists. A good example of a router-on-a-stick configuration (which also happens to be the one we are going to cover) would be a Call Manager Express installation where there is the need to split the VoIP network, consisting of your Cisco IP Phone devices, from your data network where all workstations and servers are located.

Router on A Stick Example

Our example is based on a scenario you are most likely to come across when dealing with VoIP networks. Because VoIP implementations require you to separate the data and voice network in order to route packets between them, you need either a layer 3 switch or a router. This configuration ensures availability and stability of the VoIP service, especially during peak traffic hours in your network.

Packets running between VLANs are routed via the CCME router connected to the switch using one physical port configured as a trunk port on both ends (switch and router). If you would like to read more on VLAN routing and VLAN theory, you can visit our popular VLAN Section that covers all related topics and terms found in this article.

This example will show you how to configure a Cisco router and switch in order to create a trunk link between them and have the router route packets between your VLANs.

This diagram shows an illustration of the above configuration:

STEP 1 - Switch Configuration

First step is to create the required two VLANs on our Cisco switch and configure them with an IP address. Since all Cisco swiches contain VLAN1 (Default VLAN), we only need to create VLAN2:

Next, we need to create the trunk port that will connect to the router. For this purpose, we've selected port GigabitEthernet 0/1 (port 1):

To eliminate confusion, these commands are instructing the switch thus:

1) Define the trunk to use the 802.1q protocol

2) Set the specific port to trunk mode

3) Enable the spanning-tree portfast trunk function to ensure the port will forward packets immediately when connected to a device e.g router. Note: The spanning-tree portfast trunk command should never be used on ports that connect to another switch, to ensure network loops are avoided.

The above steps complete the switch-side configuration.

STEP 2 - Router Configuration

We need to follow a similar configuration for our router to enable communication with our switch and allow all VLAN traffic to pass through and route as necessary.

Creating a trunk link on a router port is not very different from the process used above - while we create the trunk port on one physical interface, we are required to create a sub-interface for each VLAN.

Again, this is a fairly simple process and easy to understand once you've done it at least one time.

In order to form a trunk link with our switch it is necessary to create one sub-interface for every VLAN configured on our switch. After creating the sub-interface, we assign an IP address to it and set the encapsulation type to 802.1q along with the VLAN to which the subinterface belongs.

For example, the encapsulation dot1q 2 command defines 802.1q encapsulation and sets the subinterface to VLAN 2. The native parameter we used for subinterface gigabitethernet0/1.1 tells the router that the native vlan is VLAN 1. This is a default parameter on every Cisco switch and therefore must be matched by the router as well.

The ip virtual-reassembly command is usually automatically thrown in by the Cisco IOS (we've included it to show you the command) and is a security measure to avoid buffer overflow and control memory usage during an attack of fragmented packets which can cough up your router's resources. This command is added automatically when you enable the NAT service using the ip nat inside command. More information on NAT configuration can be obtained by our Cisco Router NAT Configuration articles.

Summary

This article explained the use of router-on-a-stick configurations and showed how you can configure an 802.1q trunk link between a Cisco switch and router. Router-on-a-stick configurations are extremely useful in environments where no layer-3 switch exists, providing Inter-VLAN routing services with a single router and one interface - cutting down seriously the costs for internal routing.

It is always preferable to use a router with a Gigabit Ethernet interface to ensure you've got plenty of bandwidth to handle large amounts of data transfers if needed.

The most common application of PPP is your ISP dialup account, whether it be ADSL, ISDN or even the good old analog modems - PPP is found in all of these connectivity methods.

PPP is a non-proprietary protocol, which also explains its wide adoption by vendors around the world.

Example Scenario

In this example, we'll be dealing with the PPP connection to our ISP. We are using a Cisco 2811 ISR router equipped with an HWIC-ADSLI card, which means we are connecting via ADSL and therefore using a virtual Dialer interface configured with our ISP account.

We will examine how to verify the connection to our ISP account and explain the steps that should be followed in case we are unable to connect. There are many reasons why a router might not be able to log in to the ISP account so we will cover the most common problems, which include: Incorrect username, incorrect password, invalid IP address & invalid authentication configuration.

Troubleshooting these possibilities will provide you with enough experience and information to help you deal with other similar problems that can occur during the ppp negotiation process.

Remember, the goal here is to cover these problematic cases, but most importantly - gear you up with enough experience and troubleshooting skills to help you tackle similar situations.

PPP Authentication - Incorrect Username or Password

This is a typical errors. You've mismatched the username and password, therefore unable to connect to the ISP account.

Under normal operation, you wouldn't be able to detect that your router is unable to connect to your ISP account. The results (e.g no Internet connection) will surely start making you wonder and start searching until you find out what's happening.

A quick check on the Dialer0 interface will confirm that there is a problem, as you notice there is no IP address assigned to it:

To check whether there is an issue with the ISP account and get a deeper insight to the source of the problem, issue the following debug command:

This debugging provides quite a bit of information during the authentication process and we've only included a portion of it. We don't want to analyse everything here, because later on we will deal with all this information without choice :)

In our lab, we've deliberately set an incorrect password to force these errors, and unfortunately the ISP response is not being specific on where the problem is. The response 'user unknown' tells us that either our username, firewallcx@myisp.com, or password is incorrect.

At this point, we at least know one of the two is causing the problem.

You can check your username by viewing the dialer configuration and try re-inserting your password, just in case you mistyped it the first time. If this gives the same result, then obviously the account credentials you've got are incorrect.

Thankfully most ISPs have a customer web-portal that allows them to log into their account and change usernames and passwords. If you've got this capability, use it. If not, a quick call to your ISP will prove most useful.

Lastly, if you would like to check you have inserted the correct account password, under your dialer interface, copy the type 7 password value from the dialer configuration:

Next, visit our Cisco Type 7 Password Decrypt / Decoder / Cracker Tool and insert the hashed password so it can reveal it:

Incorrect Configured IP Address on Dialer Interface

In many cases, engineers might select to statically configure the static IP address, purchased from the ISP, directly on the dialer interface. If all settings are correct and the ISP has provided the correct IP address you should expect no surprises.

It happens many times though, that the incorrect IP address has been provided and when the router authenticates to the ISP it is unable to route any packets towards the Internet.

The short and effective way around this problem is to never assign any IP address to the Dialer interface unless it's required. Services such as Crypto VPN tunnels to remote offices, various Internet services served to the Public (mail, web etc.) do not usually require you to configure the statically assigned IP address directly to the Dialer interface.

Allowing the ISP take care of the IP address assignment to your Dialer interface will in many cases help you avoid these problems completely.

For the purpose of our example, assuming we've got an incorrect IP address configured, following is the repeated behaviour we would encounter:

The router will continuously install and remove the default route provided by the ISP. The Virtual-Access interface is then shutdown and brought back up. This behavior will continue non-stop until you either shutdown the Dialer interface or correct the problem.

Changing our tactic, we decide to correct this problem and let the Dialer interface negotiate the IP address from our ISP:

On the next cycle of negotiation, the Dialer interface is assigned its IP address:

Invalid Authentication Configuration

Another common configuration problem is the ppp authentication direction, where your router should only authenticate to your ISP and not expect the ISP to authenticate to it as well.

The typical ppp authentication command under the dialer interface provides a number of supported authentication protocols (pap, chap, ms-chap, ms-chap-v2) but also allows you to control which way the authentication occurs:

Notice the 'callin' option in the above output. This option is almost always used and effectively tells the router not to expect the peer router (ISP) to authenticate back (to local router).

Here is the debugging output when we configure the ppp authentication method without the 'callin' parameter:

So always ensure that you add the 'callin' parameter at the end of the 'ppp authentication' command.

Further analysing the authentication protocol, generally all ISPs support CHAP primarily and PAP as a secondary option. However, due to the large amount of security breaches on accounts, PAP support is being dropped as it sends all account details in clear text, without any type of encryption.

CHAP authentication on the other hand sends a hashed result of the stored password. The router sends its hashed result to the ISP so it may compare it. If the calculated hash is identical to the one received by the ISP router, that means the password stored by each matches the other.

Following is the recommended ppp authentication options for most ISPs:

Of course, if your ISP supports CHAP, you can safely remove all references to the PAP authentication method.

Summary

This article showed you how to configure and troubleshoot your PPP connection on your Cisco router. We covered the most common problems found in PPP connections, how to identify them and successfully resolve them and also provided general information about PPP which can be used to troubleshoot other similar scenarios.

If you have found the article useful, we would really appreciate you sharing it with others by using the provided services on the top left corner of this article. Sharing our articles takes only a minute of your time and helps Firewall.cx reach more people through such services.

This article will show you how to configure your Cisco router to synchronise its software clock from external sources such as NTP servers. We will also show you how to configure your router to act as an NTP server for your internal network devices, ensuring all devices are synchronised.

When it comes to Cisco routers, obtaining the correct time is extremely important because a variety of services depend on it. The logging service shows each log entry with the date and time - very critical if you're trying to track a specific incident or troubleshoot a problem.

Generally, most Cisco routers have two clocks (most people are unaware of this!): a battery-powered hardware clock, referenced as the 'calendar' in the IOS CLI, and a software clock, referenced as the 'clock' in the IOS CLI.

The software clock is the primary source for time data and runs from the moment the system is up and running. The software clock can be updated from a number of sources:

Because the software clock can be configured to be updated from an external source, it is considered more accurate in comparison to the hardware clock. The hardware clock can be configured to be updated from the software clock.

Example Scenario

First example involves setting up the router to request NTP updates and synchronise itself from a public NTP server. This will ensure the router's time is constantly synchronised, however it will not act as an NTP server for internal hosts:

It is also worth noting the column named 'st' which is equal to two (2). This represents the stratum level. The higher the stratum, the closer to the Atomic clock source we are. As a general rule, always try to synchronise with a server that has a low stratum.

The 'show ntp status' command confirms that we are yet to be synchronised with the NTP server as it clearly states that the 'clock is unsynchronised' and also shows us the current system time: 1st of Jan. 1900.

After a couple of minutes, we re-visit the CLI prompt and re-issue the commands with the following results:

Looking at the new output, we can see that our Cisco router is now synchronising with the configured peer (*) - public NTP server. Polling of the public NTP server will occur every 64 seconds, as shown in the command output.

The 'show ntp status' command also confirms the synchronisation, however, notice that the router has set its stratum level to 3. This is expected as the reference is stratum 2. The time is now correctly shown (01:17:15.562 Athens Sun Apr 23 2023).

Synchronising Software Clock and Hardware Clock

Here we'll see how in fact the software and hardware clocks on a Cisco router can have different times and how we can synchronise them between each other.

The following two commands show the difference in time between the two clocks on our Cisco router:

While the difference is minor, we want to keep everything in our network synchronised as precisely as possible.

Keep in mind that 'show clock' refers to the software clock and 'show calendar' refers to the hardware clock of your router.

To synchronise the two clocks all we need to do is issue the following command:

The 'ntp update-calendar' forces the hardware clock to synchronise with the system's software clock. After a couple of minutes, we check to see if the two clocks have synchronised:

We can see now that both clocks are accurately synchronised.

Configuring The System as an Authoritative NTP Server

If you want your system to become an authoritative NTP server from which other internal routers or machines can synchronise, you can achieve this with the following command:

The router now acts as an NTP server and is able to respond to internal clients NTP requests. Executing the 'ntp association' command reveals our router is obtaining its time synchronisation from itself:

Troubleshooting and Monitoring NTP Status

Troubleshooting NTP messages and events is important when you are trying to verify everything is working correctly. You might notice that your Cisco router is not able to create a peer connection with a configured NTP server or your internal LAN clients might not be able to synchronise with your Cisco router; In any case, knowing how to troubleshoot NTPs is something every engineer must be aware of.

Thankfully Cisco provides a number of options that allow you to troubleshoot many aspects of your NTP service.

The most useful debug commands are the 'debug ntp events', 'debug ntp adjust' and 'debug ntp core'. These three commands provide enough debugging to help you troubleshoot problems you might encounter.

Closing, if you would like more information on the ntp associations created by your router you can try the following command:

The 'show ntp associations detail' command will provide much information on the association created with the NTP servers. This is most helpful when you see you are unable to create an association with an NTP server.

Summary

This article provided an insight to NTP configuration on Cisco routers. We analysed why the NTP service is important and how it can be used to keep every node in a network synchronised. We examined different methods of NTP synchronisation and provided a fairly in-depth analysis.

If you have found the article useful, we would really appreciate you sharing it with others by using the provided services on the top left corner of this article. Sharing our articles takes only a minute of your time and helps Firewall.cx reach more people through such services.

This article will take you through the basic steps of configuring a Cisco Router to work with ISDN. Below is a table of ISDN Switch Types. Before you attempt to configure ISDN you need to ensure that you know which type of ISDN switch you are connecting to at the Telco.

For a very basic BRI ISDN configuration on a Cisco Router, you need to perform the following steps (that's providing you are not using DDR - Demand Dial Routing);

• •Configure the Switch Type (Using switch-type)
• Configure the ISDN Dialer Map; this basically maps the IP Address of the end router's IP Address with its telephone number (Using dialer-map)
• Configure your ISDN Interface IP Address (using interface & ip address)
• Configure a routing rule (using ip route)

For Example,

N.B. If using the DMS-100 and National-1 switch types (as well as AT&T 5ESS), you will need to obtain from you telco the Service Profile Identifier (SPIDs) of which you require one per each Bearer Channel. For these switch types, these need to be configured using the isdn spid1 and isdn spid2 commands. The SPIDs are used to authenticate call requests at the telco's switch. The format for using the SPIDs is isdn spid1 spid-number ldn and isdn spid2 spid-number ldn.

Demand Dial Routing

Since ISDN is a circuit switched technology, you usually pay for the amount of time that the line is active. For this reason, you generally do not want to raise the ISDN line for just any type of traffic. In order to accommodate this, you can configure what's called Demand Dial Routing or, DDR for short. The idea behind DDR is that you to specify the ‘interesting traffic' that will be able to raise the ISDN line.

For example, you can set as ‘interesting traffic', all packets destined towards a specific remote network you connect to. If none of the routed traffic that is heading for that network (on the other side of the ISDN line), the line doesn't get raised. This saves on unnecessary costs due to none essential traffic raising the line.

The way you specify ‘interesting traffic' is with the use of Access Control Lists (ACL's). If the traffic destined for the remote network doesn't match this interesting traffic, then the line stays down, otherwise the line is raised and traffic is allowed to travel to the remote network. It's worth mentioning here that although you have defined this “Interesting” traffic, it doesn't mean that other traffic will not be allowed to travel along the ISDN link. If the link is active, any traffic (unless blocked by Access Lists) is allowed to travel the link, therefore keep in mind that the “Interesting” traffic is used only to bring the line up.

You can then create a 2 nd set of ACL's which defining the traffic that can traverse the ISDN line. Also, the DDR works using a counter, like a time-out counter, once the counter reaches a preset configurable threshold, the line will drop again. This threshold is reduced each time “Interesting” traffic is sent over the ISDN Link, therefore it's also only the “Interesting” traffic that is used to maintain the link.

Steps in configuring DDR (assumes part of the basic steps above have already been configured)

• Define Interesting Traffic (Using dialer-list & access-list)
• Assign Interesting Traffic to an Interface (Using dialer-group)
• Define the destination IP address, hostname and telephone number to dial (Using dialer map)
• Define any additional options (Using dialer idle-timeout, dialer fast-idle, dialer load-threshold)

The Additional Options

For Example:

What this example does, is allowing all web traffic (http) from anywhere to anywhere. As you can see, the dialer-list is specifying the 101 access list to dialer-list 1. The dialer-group is then specifying the 1, which links to the dialer-list 1.

Dialer Profiles

On Cisco's website it states that “Dialer Profiles implementation of DRR is based on a separation between the logical and physical interface configurations. Dialer profiles also allow the logical and physical configurations to be bound together dynamically on a per-call basis.”

There are several advantages of Dialer Profiles over Legacy DDR, it is much more scalable then Legacy DDR because Legacy DDR is based on a static binding between the per-destination call and the physical interface configuration. Dialer profiles are point-to-point interfaces which mean we no longer need the layer 3 to layer 2 mapping (layer 2 meaning the telephone number) since the profile can only dial a single location (hence point-to-point).

Since the logical and physical configurations are dynamic, it allows physical interfaces to take on different characteristics based on the logical call requirements that is utilising the physical interface. The final advantage that we will include here is that it enables you to have a backup interface that isn't tying up one of the physical interfaces. Providing a spare interface is available, the backup can be used when it's required.

Dialer Profiles are made up of a Dialer Interface, dialer pool and physical interface. Optionally, you can also have a map class. These are highlighted in the table below

Steps in creating a Dialer Profile (assumes part of the basic steps above have already been configured, such as ISDN type);

• • Define a Dialer Interface
• Configure a Dialer String
• Assign Physical Interface to a Dialer Pool, plus any additional Physical attributes

• Other steps from the previous sections may need to be performed, for example; if you wanted to active the link using interesting traffic, DDR needs to be configured.

For Example:

Define Dialer Interface

Configure Physical Interface:

Configure DDR to specify “Interesting” traffic (http) used to bring the line up:

A Simple Example

The following example includes a variety of different items discussed in this document, in order to help you see how they are applied in a real-case scenario. As always, depending on the security policies and network complexity, the configuration can change quite a bit. For simplicity reasons, we've keep the complexity to a minimum.

Our scenario is based upon two routers who occasionally require to connect their networks via an ISDN dial line, in order to transfer data between them.

Router 1 – Remote Office

Assign the switch type that we are connecting through to on the physical layer, AT&T Basic Rate Switch telco switch:

Router1(config)# isdn switch-type basic-5ess

Router1(config-if)# ip address 10.10.10.1 255.255.255.252

Configure the encapsulation used when we are connecting through this virtual interface:

Router1(config-if)# encapsulation ppp

Set our ppp authentication to use chap, pap. The ‘Callin' parameter ensures our router authenticates the remote router (HQ) on an incoming call. Since we are always the calling party, it does not expect the remote (HQ) router to authenticate, making this authentication process a one-way direction. Remote Office authenticates to the HQ router:

Router1(config-if)#ppp authentication chap pap callin

Set the username & password for chap/pap authentication protocol & number to dial:

Assign this virtual interface to use any physical interface that's assigned to pool number 1:

The following command is used to define the interesting traffic that can be used to raise this virtual interface. The next command is paired with the "dialer-list 1" command later on. Next, disconnect this call after 300 seconds of inactivity:

Make this link ‘ppp multilink' capable, allowing the aggregation of the two available 64K ISDN lines to a total of 128Kbps and when the incoming or outgoing (either) traffic reaches half of the available bandwidth (125), then bring up the 2 nd ISDN channel:

The commands below takes us into the interface sub command of the physical interface bri0/0, ready for configuring the physical characteristics. Configure the encapsulation for this physical interface. Optional command since we've already included it in the Dialer Interface:

Access lists are used to define interesting traffic. This line specifies that tcp port 80 traffic from anywhere to anywhere is interesting. The second command Maps the access-list with the dialer-group. As you can see, number 1 is used in the dialer-list and dialer-group statements:

Next command creates a route to the 192.168.0.0/24 subnet to go through 10.10.10.2 (will use Dialer1 to get there since it's on the 10.10.10.0 subnet):

Router1(config)# ip route 192.168.0.0 255.255.255.0 10.10.10.2

Router 2 – HeadQuaters

The configuration for the HQ node is similar:

Assign the username & password the remote office router will user while authenticating to this route:

HQ(config)# username remote-office password cisco

Summary

Here's the complete configuration without comments:

Router 1 - Remote Office

Router 2 - Headquaters

Configuring Windows XP Client for VPDN

The great thing about VPDN/PPTP is that it is natively supported by most Windows operating systems. This means you're not required to install additional drivers or programs to get it working.

In order to connect to the VPDN, we need to create a VPDN dialup and modify a few parameters. So, without further delay, here are the steps required:

Firstly go to Control Panel --> Network Connections. From there, select Create a new connection:

Next, select the Connect to the network at my workplace to create the VPDN connection:

Next step, select the Virtual Private Network connection:

On the next step, you'll need to provide a description for the new VPDN connection:

Assuming you're directly connected to the Internet via LAN or wireless, you won't need to initiate a dialup:

Next, we insert the router's public IP address to which the VPDN will terminate:

Last step, simply click on finish to save the new connection:

Double-clicking on the connection will open up the connection dialogue, here you'll need to enter the credentials of the username/password you previously created on the router. However you need to be aware that once connected, all traffic, including Internet traffic, will be directed through the VPDN connection. This effectively means that it's most likely you won't be able to browse the Internet because all traffic will be sent to the router on the other end, which will most probably drop the traffic.

In order to overcome this problem, you'll need to 'un-check' a specific option under the VPDN's TCP/IP settings. From the connection dialogue, click on Properties, go to the Networking tab and from there double-click on the TCP/IP protocol. Next, click on the Advanced button on the lower right corner and you'll be presented with the window below:

All you need to do here is 'un-check' the Use default Gateway on remote network and click OK on every window to ensure the setting is saved.

What this option does is ensure that only traffic destined to the remote network (192.168.0.0 /24 in our example) traverses the VPN tunnel. All other traffic will be sent through the workstation's default gateway.

This concludes the setup of a VPDN on a Windows based workstation.

Summary

This article showed how to create a VPDN connection to a PPTP server, including how to configure the VPN tunnel to ensure only necessary traffic passes through it. Its application is similar to all Windows-based operating systems.

If you have found the article useful, we would really appreciate you sharing it with others by using the provided services on the top left corner of this article. Sharing our articles takes only a minute of your time and helps Firewall.cx reach more people through such services.

While PPTP's encryption algorithms do offer a certain level of security and privacy, they aren't the best encryption technologies available today. PPTP does have its weaknesses and therefore is not used for long term transactions. PPTP uses the Password Authentication Protocol and the Challenge Handshake Authentication Protocol encryption algorithms. It can offer encryption options of 40, 56 and 128 bit, depending on your needs.

PPTP is an excellent quick VPN solution for short-term transactions and is natively supported by all current Windows platforms without the need for additional drivers or programs.

Cisco routers can be set up to act as PPTP servers, alternatively known as a Virtual Private Dialup Network (VPDN) servers. PPTP has been supported by Cisco routers since IOS release 12.1(5)T.

We should point out that Windows Servers are also capable of handing PPTP connections by configuring their RAS services, however, we feel that being able to provide this service from a Cisco router makes it more flexible and easier to implement in any environment.

Note: You can read our article on Windows VPDN setup to get all the information on how to set up a remote teleworker to connect to the VPDN configured on your Cisco router.

Example Scenario

In this example, we need to set up our Cisco router so that it accepts VPDN requests, allow our remote clients to connect to the internal network, assign them an internal IP address and provide them access to all network resources:

The remote VPN user will have to create a VPDN dialup from its operating system (we assume Windows XP) in order to initiate the VPN connection and authenticate to the Cisco router.

First step is to enable VPDN and create the VPDN group parameters that will define various aspects of the PPTP connection:

The above configuration enables the router to accept incoming PPTP connections and specifies the virtual interface to which the PPTP tunnel is configured.

Next up, we need to bind the virtual interface to a real interface. This effectively binds the PPTP connections to the real interface. We'll also need to create a pool of IP addresses that will be assigned to the VPDN users. This pool is named 'PPTP-Pool' and we'll later on assign the addresses to be allocated to the VPN users.

The 'ppp encrypt' command specifies the encryption to be used - in our case, that's 128 bit. This can be set to 'auto' for maximum compatibility. The authentication is set to ms-chap and ms-chap v2 so that we can offer the best possible authentication method for this case.

The 'ip unnumbered <interface>' command is worth analysing a bit further.

All VPDN clients will either obtain an IP address that is part of the existing internal network (as in our example), or they will be assigned an IP address that is totally different from the internal network scheme e.g 192.168.5.20 - 192.168.5.25.

If you want to assign them an IP address that's part of the existing internal network (most cases), you need to use the 'ip unnumbered' command to bind the virtual adapter to the real interface connected to the internal network - in our example, this is FastEthernet 0/0.

If on the other hand you wish to provide VPDN clients with a totally different IP address from that of your internal network, then you must configure the Virtual-Template interface with an IP address belonging to that network e.g 192.168.5.1 and configure the VPDN pool with the appropriate range e.g 192.168.5.20 - 192.168.5.25.

Older Cisco router models such as the 836 & 837 series had problems assigning the VPDN clients an IP address that belonged to the existing internal network, so engineers didn't have much choice but to assign a different IP addressing scheme for the VPDN clients.

From the configuration and diagram provided so far, you can see that we'll be assigning the VPDN clients an IP address range that's part of the existing internal network:

Last step is to create the user accounts our VPDN clients will require to authenticate to the router and access internal resources.

This is a fairly simple task as you only need to add a username, followed by the password:

The remote user will need the above username and password to successfully connect to the VPN.

You can read our article on Windows VPDN setup to get all the information on how to set up a remote teleworker to connect to the VPN.

Summary

This article covered the configuration of a PPTP or VPDN server on a Cisco router. We saw all aspects of its configuration, plus alternative configurations that will help you adjust the set up to your needs.

If you have found the article useful, we would really appreciate you sharing it with others by using the provided services on the top left corner of this article. Sharing our articles takes only a minute of your time and helps Firewall.cx reach more people through such services.

Cisco routers are usually equipped with an ISDN BRI (Basic Rate) Interface. This interface is capable of supporting up to two 64Kbps channels, providing a maximum of 128Kbps throughput.

You can learn all about the ISDN protocol and capabilities by reading our popular ISDN WAN Protocol article.

Here will show you how to configure step-by-step your Cisco router to perform basic ISDN dialup to an Internet provider. We will also cover some basic authentication options and ISDN parameters that will help you better control your connection.

Example Scenario

The diagram below is our example network. The router is the local network's gateway and connects to our Internet provider via ISDN, when needed.

One first thing we need to do is configure the ISDN WAN interface with the necessary parameters. While every BRI ISDN interface card on a Cisco router looks the same, the actual ISDN parameters required to configure it (ISDN switch-type) changes depending on the country you live in.

For Europe, Australia, Asia and the UK, the ISDN switch-type is usually set to 'ISDN Basic Net3'. For North America, 'Basic 5ess' or 'Basic-dms100' depending on your telecommunication provider. We will be using the 'Basic Net3' switch type.

For more information, please visit our Basic ISDN configuration article. It contains extensive information on the various switch-types used throughout the world.

Further configuration of the BRI interface involves the encapsulation type, which is set to 'ppp' (Point-to-Point Protocol), common amongst all ISP's.

The dialer pool-member will associate the physical ISDN interface (bri 0) with a dialer interface (dialer 0) configured later on. In this example, any dialer interface assigned to dialer pool member 5 will use this BRI interface when dialing out.

Dialer interfaces carry the same role as a dialup connection in Windows, where you create a new connection, inserting the phone number, username, password and other parameters. This is a virtual interface that will use the BRI interface to complete the dialup and establish our Internet connection.

A number of parameters are necessary to make the connection work, these include IP address, encapsulation type, authentication method (CHAP or PAP), ISP username/password and of course, the number it needs to dial:

Again, the dialer pool 5 command associates this dialer with the physical BRI 0 interface as it too is a member of the same pool. The dialer-group 1 command is used to match 'Interesting Traffic', that is, traffic that would initiate the dialup to the ISP.

The ip nat outside command is part of the NAT configuration for this router. While NAT is covered in a different article, we will simply list the necessary commands to configure NAT so that the internal network has access to the Internet. You can find more information on NAT by reading through our NAT Articles.

We now need to configure the 'ip nat inside' interface, global nat overload command and associated access list. The access list is used to control which internal hosts or network(s) will pass through the nat service so they can access the Internet. Lastly, we insert a default route (0.0.0.0 0.0.0.0) instructing the router to send all traffic destined to other networks, out through the dialer 0 interface:

Here we've enabled the NAT service for the 192.168.0.1/24 network via access list 100. Generally, if you want to restrict the NAT service to a few hosts, you would simply need to modify access-list 100 to include these hosts only.

The above configuration commands are enough to successfully make your router connect to your ISP and provide full Internet access to your internal network.

Let's now take a quick look at a few additional commands you can use to help tweak your connection.

Additional ISDN Tweaks

Because ISDN dialups are usually charged by telecommunication providers based on their time usage, having the connection active without any data passing through, will eventually have you receiving a pretty large phone bill. For this reason, there is a command that can be used to instruct the router to tear-down the dialup if no data triverses the connection for an certain amount of time.

The dialer idle-timeout command does exactly that. If no data passes through the Internet link within the specified time, the dialup connection is teared down. In our example, this timeout is 300 seconds:

Up to this point, the configuration of our 'dialer 0' interface will only use one ISDN B channel. This means you'll have a maximum throughput of 64Kbps. Because ISDN BRI can handle up to 128Kbps, we can force the router to bring up the second 64Kbps channel if the first one reaches its full capacity:

The threshold that triggeres the second channel can be configured for incoming, outgoing or either traffic. In our example, if the incoming or outgoing traffic reaches 64Kbps, the second ISDN channel will autmomatically come up.

Summary

This article covered basic ISDN commands required to initiate a simple ISDN dialup to an ISP. We took a look at some tweaking commands to help make the most out of the ISDN connection and also touched on Network Address Translation.

If you have found the article useful, we would really appreciate you sharing it with others by using the provided services on the top left corner of this article. Sharing our articles takes only a minute of your time and helps Firewall.cx reach more people through such services.

Once the internal host stops sending and receiving packets from the Internet, the router's NAT timeout will clear the Dynamic NAT entry from its NAT table, making the real IP address available to the next internal host.

The following steps explain basic Cisco router Dynamic NAT configuration. If you would like to read more on the NAT theory, be sure to read our popular NAT articles, which explain in great depth the NAT functions and applications in today's networks. Finally, if you're only interested in Dynamic NAT, you can simply follow this link and read up on our theoretical example covered on Firewall.cx.

Example Scenario

The diagram below represents our example network, which consists of a number of internal clients trying to access the Internet via our router. The router is connected to the ISP via its serial interface. The company has been assigned the following Class C subnet: 200.2.2.0/29 (255.255.255.248). This translates to the following usable Public IP addresses: 200.2.2.1 - 200.2.2.6.

As one would expect, we need to sacrifice two IP addresses: one for the router's serial interface and one for the ISP's router. This leaves us with the following pool of usable Public IP addresses: 200.2.2.2 - 200.2.2.5.

The goal here is to configure the router to dynamically allocate the pool of Public IP addresses to our internal network.

Configure Dynamic NAT

Dynamic NAT configuration is a pretty straightforward process and is almost identical to other types of NAT configurations. The first step in any NAT configuration is to define the inside and outside interfaces. It is imperative that we define these interfaces for the Dynamic NAT service to function.

Enable IP routing and set the fast ethernet 0/0 interface as the inside interface:

Next step is to set the serial interface S0/0 as the outside interface:

Next step is to create our pool of Public IP addresses that will be handed out by the router to our internal hosts trying to connect to the Internet. Each time a host sends a packet destined for the Internet, the router will automatically allocate one of the Public IP addresses for the length of that session.

When the session is over, the NAT entry will timeout and the Public IP address is released, making it available once again to the Dynamic NAT pool. Let us define the NAT Pool:

We now need to create an Access Control List (ACL) that will include local (private) hosts or network(s), depending on how large the internal network is.

This ACL will be applied to the NAT pool named 'Public-IPS', effectively controlling the hosts that will be assigned a Public IP address and therefore able to access the Internet.

You can use standard or extended access lists depending on your requirements:

The above command instructs the router to allow the 192.168.0.0/24 network to use the NAT Pool and provide each host with a unique Dynamic Public IP address. Note that Cisco router standard and extended ACLs always use wildcards (0.0.0.255).

Verifying Dynamic NAT Operation

By viewing the Dynamic NAT table you can easily verify that the internal hosts are correctly being assigned a Dynamic IP address from the configured pool:

 As shown, two internal hosts (192.168.0.6 & 192.168.0.8) have each been assigned an external IP address from the pool we previously created.

These translations will eventually timeout if no activity is present from the internal hosts, however, if you need to forcibly clear them this can be easily done by entering the following command:

Assuming no request has been sent right after the command was entered, the NAT translation table should be empty:

Lastly, you can obtain statistics on the Dynamic NAT service. This will help you monitor the usage of your Dynamic NAT pool and available public IP addresses:

Summary

In this article we've covered the configuration of Dynamic NAT on Cisco routers. We also saw how you can control the Dynamic NAT service using ACLs and obtain detailed statistics on the NAT service. The configuration and commands presented here are compatible with all Cisco router models and IOSs.

If you have found the article useful, we would really appreciate you sharing it with others by using the provided services on the top left corner of this article. Sharing our articles takes only a minute of your time and helps Firewall.cx reach more people through such services.

The main purpose of NAT is to hide the IP address (usually private) of a client in order to reserve the public address space. For example a complete network with 100 hosts can have 100 private IP addresses and still be visible to the outside world (internet) as a single IP address. Other benefits of NAT include security and economical usage of the IP address ranges at hand.

The following steps explain basic Cisco router NAT Overload configuration. NAT overload is the most common operation in most businesses around the world, as it enables the whole network to access the Internet using one single real IP address. If you would like to know more about the NAT theory, be sure to read our popular NAT articles, which explain in great depth the NAT functions and applications in today's networks.

Example Scenario

This translates to one usable real IP address - 200.2.2.1 - configured on our router's serial interface. IP address 200.2.2.2 will be used on the other end, that is, the ISP's router. Our ISP has also provided us with the necessary default gateway IP address (configured on our router - not shown) in order to route all traffic to the Internet.

Our goal in this example is to configure NAT Overload (PAT) and provide all internal workstations with Internet access using one public IP address (200.2.2.1).

Configure NAT Overload - PAT (Port Address Translation)

'Overloading' means that the single public IP assigned to your router can be used by multiple internal hosts concurrently. This is done by translating source UDP/TCP ports in the packets and keeping track of them within the translation table kept in the router (R1 in our case). This is a typical NAT configuration for almost all of today's networks.

In addition, NAT Overload (PAT) is covered in great depth on Firewall.cx. Those interested can visit our NAT Overload (PAT) article.

The first step in any NAT configuration is to define the inside and outside interfaces. It is imperative that we define the these interfaces for NAT overload to function.

We now need to create an Access Control List (ACL) that will include local (private) hosts or network(s). This ACL will later on be applied to the NAT service command, effectively controlling the hosts that will be able to access the Internet. You can use standard or extended access lists depending on your requirements:

The above command instructs the router to allow the 192.168.0.0/24 network to reach any destination. Note that Cisco router standard and extended ACLs always use wildcards (0.0.0.255).

All that's left now is to enable NAT overload and bind it to the outside interface previously selected:

R1(config)# ip nat inside source list 100 interface serial 0/0 overload

From this point onward, the router will happily create all the necessary translations to allow the 192.168.0.0/24 network access to the Internet.

Verifying NAT Overload Οperation

Viewing the NAT translation table can sometimes reveal a lot of important information on your network's activity. Here you'll be able to identify traffic that's not supposed to be routed to the Internet or traffic that seems suspicious.

As packets start traversing the router it will gradually build up its NAT/PAT translation table as shown below:

As shown, the first 2 translations directed to 74.200.84.4 & 195.170.0.1 are DNS requests from internal host 192.168.0.6. The third entry seems to be an http request to a web server with IP address 64.233.189.99.

Looking at the fourth and fifth translation entry, you should identify them as pop3 requests to an external server, possibly generated by an email client.

Because these entries are all dynamically created, they are temporary and will be removed from the translation table after some time.

Another point you might want to keep in mind is that when we use programs that create a lot of connections e.g Utorrent, Limewire, etc., you might see sluggish performance from the router as it tries to keep up with all connections. Having thousands of connections running through the router can put some serious stress on the CPU.

In these cases, we might need to clear the IP NAT table completely to free up resources.
This is easily done using the following command:

R1# clear ip nat translation * 

Assuming no request has been sent right after the command was entered, the NAT translation table should be empty:

Lastly, you can obtain statistics on the overload NAT service. This will show you the amount of current translations tracked by our NAT table, plus a lot more:

Article Summary

In this article we've covered configuration of NAT Overload on Cisco routers. We also saw how you can control the NAT Overload service using ACLs and obtain detailed statistics on the NAT service. The configuration and commands presented here is compatible with all Cisco router models and IOS's.

If you have found the article useful, we would really appreciate you sharing it with others by using the provided services on the top left corner of this article. Sharing our articles takes only a minute of your time and helps Firewall.cx reach more people through such services.

In many cases, where a local DNS server is not available, we are forced to either use our ISP's DNS servers or some public DNS server, however, this can sometimes prove troublesome. Today, small low-end routers have the ability to integrate DNS functionality, making life easier, but so do Cisco routers - they simply have to be setup and you're done.

This article will show you how to configure your Cisco router to provide DNS services to your network, and make all clients use it as a DNS server. Our easy to follow step-by-step process ensures you'll understand the process and have it running within minutes.

Example Scenario

Consider the following network diagram. This is our example network, we'd like to enable the DNS Service so our workstations can properly resolve Internet domains but also local network names.

First step is to enable the DNS service and domain lookup on the router:

Next, we need to configure the router with a public name-server, this will force the router to perform recursive DNS lookups, in other words, for every request it receives from our workstations the router will try to find the answer by asking as many DNS servers it needs, and finally return with an answer:

The Cisco IOS will allow you to enter up to 6 different name servers (essentially DNS servers). Usually you would use your ISP's DNS server to ensure you have quick responses, then place a few free public DNS servers such as the ones above. This will ensure that you'll get a DNS response from either your ISP or public DNS servers.

Next step is to configure your DNS server with the host names of your local network, this way when Alan's PC trys to ping or connect to Wayne, the router will successfully resolve its netbios name to the appropriate IP address:

If you now try to ping 'wayne' directly from your router's CLI prompt, you should receive an answer:

At this point, you can configure your workstations to use your router's IP address as the primary DNS server:

Summary

We've covered how a Cisco router can be used as a basic DNS server to enable network clients to perform DNS queries for the local network and Internet.

Future articles in DNS will cover more advanced configurations, including full domain resource records, DNS load balancing and more.

If you have found the article useful, we would really appreciate you sharing it with others by using the provided services on the top left corner of this article. Sharing our articles takes only a minute of your time and helps Firewall.cx reach more people through such services.

There are two different editions of SDM, the full SDM package and the SDM Express package.

The full SDM package contains a number of modules and options for your router's configuration, while the Express package is essentially a cut-down version containing the core modules. You should note that you'll need Java Runtime 1.5 installed on your workstation in order for SDM to function. To obtain the necessary Java Runtime click here.

The full SDM can be found on the CD that came with your router but is also downloadable via Cisco's website. The SDM Express package usually comes preinstalled on your router's flash memory.

If you would like to download the latest available Cisco SDM, you can conveniently find it in our Cisco Tools & Application Download Section or alternatively go to Cisco's website, log in to your CCO account and download from there. If you don't have a CCO account, you can register one for free and proceed to the following location http://www.cisco.com/cgi-bin/tablebuild.pl/sdm as shown below:

Once you log in, you'll be presented with the download table from where you can select the latest version:

Once you select and download the appropriate zip file (SDM-V25.zip in our example) you'll be able to unzip it and start your installation, however, to ensure your installation succeds, you must telnet into your router or use the console port to log in via CLI, create a username & password, and enable HTTP authentication:

Now start your installation. During the installation you'll be prompted to select if you'd like to install Cisco SDM on your computer, router or both. Select your router:

In the next screen, you'll be asked for your router's details (IP Address, username, password) in order to have the SDM software installed on it:

Once you provide all necessary information, you'll get the progress bar indicating the connection towards your router:

Next is the section where you can select a 'Typical' installation or 'Custom'. Select 'Typical' as it will automatically choose the appropriate settings and packages for your router:

As you can see, SDM v2.5 requires approximately 8.9MB of flash space. Hit 'Next' and your installation begins:

This process will take a couple of minutes as all files are transferred to your router's Flash and final configuration changes are made. Once complete, you'll be given the option to start SDM. If you choose to do so, you'll be redirected to your web browser and asked for the appropriate credentials.

You'll have to make sure you've disabled any pop-up blockers otherwise you won't be able to see the necessary windows that will try to 'pop-up'. After a minute or so you should see the first screen of SDM collecting information on your router:

Once this step is over, you'll get your first real-time overview of your router. From here you can configure or monitor any aspect of your Cisco router. The SDM software is constantly being updated with new features, bringing it closer to the flexibility and power of the IOS command line - however, it does still have a long way to go :)

The following screenshot is from the 'Monitor' tab, which can provide a wealth of information regarding the router's status and is extremely useful even for the most experienced:

Summary

We've covered Cisco's popular SDM software and gave the download location and the steps required to successfully install it on your local router. While the SDM software is unable to completely replace the Cisco CLI, you'll surely find it useful. If you happen to run into problems installing the SDM software, you can turn to our site's forums where our community and dedicated Cisco engineers will gladly help you out!

The Privileged Mode (Global Configuration Mode) is used mainly to configure the router, enable interfaces, setup security, define dialup interfaces etc.

We've included a screenshot of the router to give an idea of the commands available in Privileged Mode in comparison to the User Exec Mode. Remember that these commands have sub-commands and can get quite complicated:

As you can see, there is a wider choice of commands in Privileged Mode.

Now, when you want to configure certain services or parts of the router you will need to enter Global Configuration Mode from within Privileged Mode. If you're confused by now with the different modes available try to see it this way:

User Exec Mode (distinguished by the ">" prompt) is your first mode, which is used to get statistics from router, see which version IOS you're running, check memory resources and a few more things.

Privileged Mode (distingushed by the "#" prompt) is the second mode. Here you can enable or disable interfaces on the router, get more detailed information on the router, for example, view the running configuration of the router, copy the configuration, load a new configuration to the router, backup or delete the configuration, backup or delete the IOS and a lot more.

Global Configuration Mode (distingushed by the (config)# prompt) is accessable via Privileged Mode. In this mode you're able to configure each interface individually, setup banners and passwords, enable secrets (encrypted passwords), enable and configure routing protocols and a lot more. We dare say that almost everytime you want to configure or change something on the router, you will need to be in this mode.

Entering Global Configuration

The picture below shows you how to enter Global Configuration Mode:

As you can see, we have telneted into the router and it prompted for a password. We entered the password, which is not shown, at this point we are in User Exec Mode and then entered "enable" in order to get into the Privileged Mode. From here to get into Global Configuration Mode you need to enter the "configure selection" command.

Now you must be wondering what the various parameters shown in the picture are, under the "configure" command. These allow you to select how you will configure the router:

• Configure Memory means you enter Global Configuration Mode and are configuring the router in its NVRAM. This command will force the router to load up the startup-config file stored in the NVRAM and then you can proceed with the configuration. When you're happy with the configuration, save it to NVRAM by entering "copy running-config startup-config".

• Configure Network means you enter Global Configuration Mode and load a startup-config file from a remote router (using tftp) into your local router's memory and configure it. Once you're finished, you need to enter "copy running-config tftp" which will force the router to copy its memory configuration onto a tftp server. The router will prompt you for the IP address of the remote tftp server.

• Configure Overwrite-network means that you overwrite the NVRAM's configuration with a configuration stored on a tftp server. Issuing this command will force the router to prompt for an IP address of the remote tftp server. This command is rarely used.

• Configure Terminal means you enter Global Configuration Mode and work with the configuration which is already loaded into the router's memory (Cisco calls this the running-config). This is the most popular command, as in most cases you need to modify or re-configure the router on the spot and then save your changes.

You will need to save this configuration otherwise everything you configure will be lost upon power failure or reboot of the router!

Below are the commands you need to enter to save the configuration, depending on your network setup:

• Copy running-config startup-config: Copies the configuration which is running in the router's RAM in to the NVRAM and gives it a file name of startup-config (default). If one already exists in the NVRAM, it will be overwritten by the new one.

• Copy running-config tftp: Copies the configuration which is running in the router's RAM in to a tftp server which might be running on your network. You will be asked for the IP address of the tftp server and given the choice to select a filename for the configuration. Some advanced routers can also act as tftp servers.

Generic Configuration

There are a few standard things with which you always need to configure the router . For example, a hostname. This is also used as a login name for the remote router to which your router needs to authenticate. Before we get stuck into the interface configuration we are going to run through a few of these commands. The following examples assume no passwords have been set as yet and that the router has a default hostname of "router":

We connect to the router via the console port using the serial cable and type the following:

This is a standard way of authentication with Cisco routers. Your router's hostname is your login name and your password (in our case "firewallcx") is entered at the same time you define the remote router's hostname.

Next we create a static route so the router will pass all packets originating from our network to the remote router. This is usually the case when you connect to your isp.

With the above command we tell our router to create a default route where any packet -defined by the first 0.0.0.0- no matter what subnetmask -defined by the second 0.0.0.0- is to be sent to ip 139.130.34.43 which would be the router we are connecting to.

In the case where you were not configuring the router to connect to the Internet but to join a small WAN which connects a few offices, then you probably want to use a routing protocol:

Alternatively, you can use IGRP as a routing protocol, in which case you would have to enter the following:

After that, we need to create a dialer list which our WAN interface BRI (ISDN) will use to make a call to our ISP.

We'll give you a quick example to make sure you understand the reason we put this command:

If you launched your web browser, it would send an http request to the server you have set as a homepage e.g www.firewall.cx. This request which your computer is going to send, is encapsulated in an ip packet that will cause your router to initiate a connection, as it is now configured to do so.

The dialup interface for Cisco routers is broken into 2 parts: a Dialer-list and a Dialer-group.

The Dialer-list defines the rules for placing a call. Later on when you configure the WAN interface, you bind that Dialer-list to the interface by using the Dialer-group command (shown later on).

Configuring Interfaces

In our example we said we have a router with one Ethernet and one basic ISDN interface (max of 128Kbit). We are going to go through the process of configuring the interfaces. We will start with the Ethernet Interface.

In order to configure the interface, we need to be in Global Configuration Mode, so we need to type first "enable" in order to get into Privileged Mode and then "configure terminal" to get into the appropriate Global Configuration Mode (as explained above). Now we need to select the interface we want to configure, in this case the first ethernet interface (E0) so we type "interface e0".

This picture shows clearly all the steps:

Any commands entered here will affect the first ethernet interface only. So we start with the IP address. It's important to understand that this IP address would be visible to both networks to which the router is connected. If we were connecting to the Internet then everyone would be able to see this IP. Futhermore, the IP address would also be the default gateway for our firewall or machine which would physically connect directly to the router.

The following commands will configure the ethernet interface's IP address:

or

Now that we have given e0 its IP address, we need to give the ISDN interface its IP as well, so we need to move to the correct interface by typing the following:

Now when it comes to configuring WAN interfaces, you need more than just an IP address (LAN interfaces such as E0 are a lot easier to configure). You need to set the encapsulation type, the authentication protocol the router will use to authenticate to the remote router, the phone number it will need to dial and a few more:

That pretty much does it for our ISDN (WAN) interface. All you need to do now is to SAVE the configuration!

We hope it wasn't too bad for you, since there is a quite a bit of information on this page. We encourage you to read through it again until you understand what is going on, then you will find it a breeze to configure a Cisco router yourself!

Let's see what it looks like to be in User-Exec mode on a Cisco router. Below, we have telneted into our lab router and are in User Exec Mode:

The easiest way to keep track of the mode you're in is by looking at the prompt. The ">" means we are in User Exec Mode. From this mode, we are able to get information like the version of IOS, contents of the Flash memory and a few others.

Now, let's check out the available commands in this mode. This is done by using the "?" command and hitting enter:

Wow, see all those commands available? And just to think that this is considered a small portion of the total commands available when in Privileged Mode! Keep in mind that when you're in the console and configuring your router, you can use some short cuts to save you typing full command lines. Some of these are :

Tab: By typing the first few letters of a command and then hitting the TAB key, it will automatically complete the rest of the command. Where there is more than one command starting with the same characters, when you hit TAB all those commands will be displayed. In the picture above, if i were to type "lo" and hit TAB, we would get a listing of "lock, login and logout" because all 3 commands start with "lo".

?: The question mark symbol "?" forces the router to print a list of all available commands. A lot of the commands have various parameters or interfaces which you can combine. In this case, by typing the main command e.g "show" and then putting the "?" you will get a list of the subcommands. This picture shows this clearly:

Below are a number of shortcut keys used to make the configuration experience as simple as possible. While these shortcuts might not seem very useful, but they are! When it comes to typing long commands for a complex configuration, these shortcuts can save you a lot of time:

CTRL-A: Positions the cursor at the beginning of the line.

CTRL-E: Positions the cursor at the end of the line.

CTRL-D: Deletes a character.

CTRL-W: Deletes a whole word.

CTRL-B: Moves cursor back by one step.

CTRL-F: Moves cursor forward by one step.

One of the most used commands in this mode is the "Show" command. This will allow you to gather a lot of information about the router. Here I have executed the "Show version" command, which displays various information about the router:

The "Show Interface <interface> " command shows us information on a particular interface. This includes the IP address, encapsulation type, speed, status of the physical and logical aspect of the interface and various statistics. When issuing the command, you need to replace the <interface> with the actual interface you want to look at. For example, ethernet 0, which indicates the first ethernet interface :

Some other generic commands you can use are the show "running-config" and show "startup-config". These commands show you the configuration of your router.

The running-config refers to the running configuration, which is basically the configuration of the router loaded into its memory at that time.

Startup-config refers to the configuration file stored in the NVRAM. This, upon bootup of the router, gets loaded into the router's RAM and then becomes the running-config!

So you can see that User Exec Mode is used mostly to view information on the router, rather than configuring anything. Just keep in mind that we are touching the surface here and not getting into any details.

This completes the User Exec Mode section. If you like, you can go back and continue to the Privileged Mode section.

While examples provided in this article are identical to pretty much any IOS version, we are taking version 12.4.x as the basic version. Our examples in the pages that follow (covering Cisco router modes) make use of a Cisco router with an ISDN interface. The ISDN Interface is configured to make a dialup connection to an ISP.

Because this article serves as an introduction, we decided to keep things as simple as possible, while our more advanced articles cover a lot more complex configurations and scenarios that will satisfy all advanced engineers.

Now, when you power up a Cisco router, it will first run a POST test to ensure all hardware is ok, and then look into the Flash to load the IOS. Once the IOS is loaded, it will then check the NVRAM for any configuration file. Since this is a new router, it won't find any, so the router will go into "setup mode".

Setup Mode

The setup mode is a step-by-step process which helps you configure basic aspects of the router. When using this setup mode, you actually have 2 options:

1) Basic Managment Setup, which configures only enough connectivity for managment to the system.

2) Extended Setup, which allows you to configure some global parameters and interfaces.

It should be noted that when you are prompted to enter a value at the console prompt, whatever is between the square brackets [ ] is considered to be a default value. In other words, if you hit enter without entering anything, the value in those brackets will be set for the specific question.

I'll try to keep this as simple and straightforward as possible.

Cisco routers have different configuration modes (depending on the router model), and by this I mean there are different modes in which different aspects of the router can be configured.

These are :

1) User Exec Mode (>)

2) Privileged Mode (#) which has as a subset, the Global Configuration mode -

To be able to get into either User Exec or Privileged mode, you will most likely need a password. This password is set during the initial configuration of the router or later on. Once in Privileged Mode, you can then enter Global Configuration Mode (password not needed to enter this mode) to then futher configure interfaces, routing protocols, access lists and more.

The picture below shows you a quick view of the modes. Notice the red arrow, it's pointing towards the Global Configuration Mode and Privileged mode meaning that some of the specific configuration modes can be entered from Global Configuration Mode and other from Privileged mode:

We've dedicated a separate page for each user mode, to avoid squezing all the information into one long page and make it easier to read.

You may choose one of the following modes:

1) User Exec Mode (>) - Click to select

2) Privileged Mode (#) which has as a subset, the Global Configuration mode - Click to select

All the above equipment runs special software called the Cisco Internetwork Operating System or IOS. This is the kernel of Cisco routers and most switches. Cisco has created what they call Cisco Fusion, which is supposed to make all Cisco devices run the same operating system.

We are going to begin with the basic components which make up a Cisco router (and switches) and I will be explaining what they are used for, so grab that tea or coffee and let's get going !

The basic components of any Cisco router are :

• Interfaces
• The Processor (CPU)
• Internetwork Operating System (IOS)
• RXBoot Image
• RAM
• NVRAM
• ROM
• Flash memory
• Configuration Register

We'll cover each of the above components and explain their purpose, function and importance.

Interfaces

These allow us to use the router ! The interfaces are the various serial ports or ethernet ports which we use to connect the router to our LAN. There are a number of different interfaces but we are going to hit the basic stuff only.

Here are some of the names Cisco has given some of the interfaces: E0 (first Ethernet interface), E1 (second Ethernet interface). S0 (first Serial interface), S1 (second Serial interface), BRI 0 (first B channel for Basic ISDN) and BRI 1 (second B channel for Basic ISDN).

In the picture below you can see the back view of a Cisco router, you can clearly see the various interfaces it has:(we are only looking at ISDN routers)

You can see that it even has phone sockets ! Yes, that's normal since you have to connect a digital phone to an ISDN line and since this is an ISDN router, it has this option with the router. I should, however, explain that you don't normally get routers with ISDN S/T and ISDN U interfaces together. Any ISDN line requires a Network Terminator (NT) installed at the customer's premises and you connect your equipment after this terminator. An ISDN S/T interface doesn't have the NT device built in, so you need an NT device in order to use the router. On the other hand, an ISDN U interface has the NT device built in to the router.

Check the picture below to see how to connect the router using the different ISDN interfaces:

Apart from the ISDN interfaces, we also have an Ethernet interface that connects to a device in your LAN, usually a hub or a computer. If connecting to a Hub uplink port, then you set the small switch to "Hub", but if connecting to a PC, you need to set it to "Node". This switch will simply convert the cable from a straight through (hub) to a x-over (Node):

The Config or Console port is a Female DB9 connector which you connect, using a special cable, to your computers serial port and it allows you to directly configure the router.

The Processor (CPU)

All Cisco routers have a main processor that takes care of the main functions of the router. The CPU generates interrupts (IRQ) in order to communicate with the other electronic components in the router. The Cisco routers utilise Motorola RISC processors. Usually the CPU utilisation on a normal router wouldn't exceed 20%.

The IOS

The IOS is the main operating system on which the router runs. The IOS is loaded upon the router's bootup. It usually is around 2 to 5MB in size, but can be a lot larger depending on the router series. The IOS is currently on version 12, and Cisco periodically releases minor versions every couple of months e.g 12.1 , 12.3 etc. to fix small bugs and also add extra functionality.

The IOS gives the router its various capabilities and can also be updated or downloaded from the router for backup purposes. On the 1600 series and above, you get the IOS on a PCMCIA Flash card. This Flash card then plugs into a slot located at the back of the router and the router loads the IOS "image" (as they call it). Usually this image of the operating system is compressed so the router must decompress the image in its memory in order to use it.

The IOS is one of the most critical parts of the router, without it the router is pretty much useless. Just keep in mind that it is not necessary to have a flash card (as described above with the 1600 series router) in order to load the IOS. You can actually configure most Cisco routers to load the image off a network tftp server or from another router which might hold multiple IOS images for different routers, in which case it will have a large capacity Flash card to store these images.

The RXBoot Image

The RXBoot image (also known as Bootloader) is nothing more than a "cut-down" version of the IOS located in the router's ROM (Read Only Memory). If you had no Flash card to load the IOS from, you can configure the router to load the RXBoot image, which would give you the ability to perform minor maintenance operations and bring various interfaces up or down.

The RAM

The RAM, or Random Access Memory, is where the router loads the IOS and the configuration file. It works exactly the same way as your computer's memory, where the operating system loads along with all the various programs. The amount of RAM your router needs is subject to the size of the IOS image and configuration file you have. To give you an indication of the amounts of RAM we are talking about, in most cases, smaller routers (up to the 1600 series) are happy with 12 to 16 MB while the bigger routers with larger IOS images would need around 32 to 64 MB of memory. Routing tables are also stored in the system's RAM so if you have large and complex routing tables, you will obviously need more RAM !

When I tried to upgrade the RAM on a Cisco 1600 router, I unscrewed the case and opened it and was amazed to find a 72 pin SIMM slot where you needed to attach the extra RAM. For those who don't know what a 72 pin SIMM is, it's basically the type of RAM the older Pentium socket 7 CPUs took, back in '95. This type of memory was replaced by today's standard 168 pin DIMMs or SDRAM.

The NVRAM (Non-Volatile RAM)

The NVRAM is a special memory place where the router holds its configuration. When you configure a router and then save the configuration, it is stored in the NVRAM. This memory is not big at all when compared with the system's RAM. On a Cisco 1600 series, it is only 8 KB while on bigger routers, like the 2600 series, it is 32 KB. Normally, when a router starts up, after it loads the IOS image it will look into the NVRAM and load the configuration file in order to configure the router. The NVRAM is not erased when the router is reloaded or even switched off.

ROM (Read Only Memory)

The ROM is used to start and maintain the router. It contains some code, like the Bootstrap and POST, which helps the router do some basic tests and bootup when it's powered on or reloaded. You cannot alter any of the code in this memory as it has been set from the factory and is Read Only.

Flash Memory

The Flash memory is that card I spoke about in the IOS section. All it is, is an EEPROM (Electrical Eraseable Programmable Read Only Memory) card. It fits into a special slot normally located at the back of the router and contains nothing more than the IOS image(s). You can write to it or delete its contents from the router's console. Usually it comes in sizes of 4MB for the smaller routers (1600 series) and goes up from there depending on the router model.

Configuration Register

Keeping things simple, the Configuration Register determines if the router is going to boot the IOS image from its Flash, tftp server or just load the RXBoot image. This register is a 16 Bit register, in other words has 16 zeros or ones. A sample of it in Hex would be the following: 0x2102 and in binary is: 0010 0001 0000 0010.

Routers Purpose and Function

Routers are very common today in every network area, this is mainly because every network these days connect to some other network, whether it's the Internet or some other remote site. Routers get their name from what they do.... which is route data from one network to another.

For example, if you had a company which had an office in Sydney and another one in Melbourne, then to connect the two you would use a leased line to which you would connect a router at each end. Any traffic which needs to travel from one site to another will be routed via the routers, while all the other unecessary traffic is filtered (blocked), thus saving you valuable bandwidth and money.

There are two type of routers: 1) Hardware routers 2) Software routers.

So what's the difference ?

When people talk about routers, they usually don't use the terms "hardware" or "software" router but we are, for the purpose of distinguishing between the two.

Hardware routers are dedicated hardware that run special software created by their vendors to give them the routing capabilities, plus a whole lot more functions. Hardware routers a most common amongst companies as they are faster and more reliable. In the earlier days, hardware routers would start from a couple of hundred dollars, however their prices today are extremely low for cheaper-brand models.

The picture below shows a new-generation cisco 2900 series router that offers a lot more than simple routing capabilities:

Software routers perform similar tasks as the above hardware routers (route data), but they don't come in small flashy boxes. A software router could be an Windows , Linux or Novell NetWare server. All network servers have built-in routing capabilities.

Most people use them for Internet gateways and firewalls but there is one big difference between the hardware and software routers. You cannot (in most cases) simply replace the hardware router with a software router.Why? Simply because the hardware router has the necessary hardware built-in to allow it to connect to the special WAN link (frame relay, ISDN, ATM etc), where your software router (e.g a NT server) would have a few network cards one of which connects to the LAN and the other goes to the WAN via the hardware router.

We've seen a few cards in the market which allow you to connect an ISDN line directly into them. With these special cards, which retail from $500 to $5000 depending on their capacity, you don't need the hardware router. But as you can understand, it's a much cheaper solution to buy a hardware router. Plus, the hardware routers are far more advanced and faster than the software routers since they don't have to worry about anything else but routing data, and the special electronic components they have in them are developed with this in mind.

The picture below illustrates a router's place in the Local Area Network (LAN):

In the example shown, the workstations see the router as their "gateway". This means that any machine on this LAN that wants to send a packet (data) to the Internet or anywhere outside its Local Area Network (LAN) will send the packet via the gateway. The router (gateway) will know where it needs to send it from there on so it can arrive at its destination.

This explains the reason you need to add an Internet Protocol (IP) number for a gateway, when you have a LAN at home or in the office, in your TCP/IP network properties on your windows workstation.

The above figure shows only one example of how routers connect so the LAN gets Internet access. Let's have a look how 2 offices would use routers to connect them.

The routers in the above picture connect using a particular WAN protocol, e.g ISDN.

In reality, there would be a cable (provided by your service provider) which connects to the "WAN" interface of the router and from there the signal goes straight to your service provider's network and eventually ends up at the other router's WAN interface.

Depending on the type of router you get, it will support one of the most commonly used WAN protocols: ISDN, Frame Relay, ATM, HDLC, PPP. These protocols are discused in the protocols section.

It's important to note down and remember a few of the main features of a router:

• Routers are Layer 3 devices
• Routers will not propagate broadcasts, unless they are programmed to
• Enterprise-class routers have their own operating system
• Routers use special protocols between them to exchange information about each other (not data)

This concludes our brief introduction to routers. Next articles will deal with Cisco routers specifically as they are the most popular and preferred router devices in the world.