First off, most of the credit for the following code goes to a contributor on Codeproject, which is where the source came from to build the telnet component of this program. We will code the remainder of the program that utilizes the telnet code obtained from codeproject.

The code contained in this article can be compiled using the Microsoft 2.0 framework that is most likely already installed on your computer.  We will compile this with the command line compiler that comes with the .Net runtime. By using this method, it not only provides a very simple process to compile the program, it also prevents having to download Microsoft Visual Studio Express. I would suggest, however, that if you plan to extend this program – you can benefit greatly from having a full blown IDE to write the code in.

First, let’s look at the telnet component, which is the majority of the program.  This portion of the code is compiled as a library (.dll) under the name scottp.Net.Comm.dll and will be a dependency for the ConfigSafe project. This code could have just as easily been put in the executable, which would have kept the program to a single file. However, in bigger programs, this type of code would go into a library anyway – so there is no time like the present to begin following standard practices.

The telnet method accepts three arguments as input, which is the IP address, port number, and a timeout value in seconds:

        public Telnet(string Address, int Port, int CommandTimeout)
        {
            address = Address;
            port = Port;
            timeout = CommandTimeout;
        }

Once connected, the following method is used to search through the incoming data stream for the string defined as the argument in the WaitFor method:

        public int WaitFor(string DataToWaitFor)
        {
            // Get the starting time
            long lngStart = DateTime.Now.AddSeconds(this.timeout).Ticks;
            long lngCurTime = 0;

            while (strWorkingData.ToLower().IndexOf(DataToWaitFor.ToLower()) == -1)
            {
                // Timeout logic
                lngCurTime = DateTime.Now.Ticks;
                if (lngCurTime > lngStart)
                {
                    throw new Exception("Timed Out waiting for : " + DataToWaitFor);
                }
                Thread.Sleep(1);
            }
            strWorkingData = "";
            return 0;
        }

One of the methods available (and the one we will use) to send data back to the Telnet service:

        public void SendMessage(string Message)
        {
            DoSend(Message + "\r");
        }
        private void DoSend(string strText)
        {
            try
            {
                Byte[] smk = new Byte[strText.Length];
                for (int i = 0; i < strText.Length; i++)
                {
                    Byte ss = Convert.ToByte(strText[i]);
                    smk[i] = ss;
                }

                s.Send(smk, 0, smk.Length, SocketFlags.None);
            }
            catch (Exception ers)
            {
                Console.Error.WriteLine(ers.ToString());
                //MessageBox.Show("ERROR IN RESPOND OPTIONS");
            }
        }

To compile the dll, we follow this simple process: First, you will need to locate where the .net runtime is installed on your computer. One of the easier ways to do this is to perform a search for csc.exe on your machine. Most likely, the path will be the same as it is on my computer: \Windows\Microsoft.NET\Framework\v2.0.50727. In order to compile, this needs to be added to your %PATH. This can be done at the command line or by modifying the Advanced System Properties -> Environment Variables. When using the latter method, all future cmd windows will use the updated path - if you have a cmd window already open and then modify the path in the system properties, it will not have the updated %PATH statement. So, just be sure you are working in a cmd window that is opened after adding to the path in the system properties.

At the command window, change to the directory where the source files are located and compile:

csc /t:library /out:scottp.Net.Comm.dll telnet.cs

We have told the compiler (csc.exe) to compile a library and name it scottp.Net.Comm.dll using the source code contained in telnet.cs

Next, we will write the remainder of code that makes up the overall program. The executable will be much smaller in terms of lines of code than the library we just looked at. In this example, the program would be considered unusable in a production environment, because we have hard coded an IP address, username, and password for the router we want to download the configuration from. To have a usable program, these three values could be taken in at the command line as arguments when running the program. However, since this is just for demonstration purposes, the program will be kept simple. In future articles, we will expand the functionality of the program.

Below is the entire source of the ConfigSafe.exe program:

using System;
using System.Collections.Generic;
using System.Text;
using scottp.Net.Comm;

namespace ConfigBackup
{
    class Program
    {
        static void Main(string[] args)
        {
            CiscoNoEnable cNE = new CiscoNoEnable();
            cNE.sHostName = "10.1.100.1";
            cNE.sUsername = "admin";
            cNE.sPassword = "cisco";
            cNE.getConfig();
        }
    }
        public class CiscoNoEnable
        {

        public string sHostName;
        public string sUsername;
        public string sPassword;

        private void Initialize_Components()
        {
            sHostName = "";
            sUsername = "";
            sPassword = "";
        }

        public CiscoNoEnable()
        {
            Initialize_Components();
        }
        public void getConfig()
        {

            this.sHostName = this.sHostName.Trim();
            this.sUsername = this.sUsername.Trim();
            this.sPassword = this.sPassword.Trim();

            Telnet mST = new Telnet(this.sHostName, 23, 8);

            if (mST.Connect() == false)
            {
                Console.WriteLine("");
                Console.WriteLine("Error: ");
                Console.WriteLine("Timeout connecting to: " + this.sHostName);
                Console.WriteLine("");
            }
            else
            {
                try
                {
                    mST.WaitFor("Username:");
                }
                catch (Exception exc)
                {
                    Console.WriteLine(exc.Message);
                }
                mST.SendMessage(this.sUsername);
                mST.WaitFor("Password:");
                mST.SendMessage(this.sPassword);
                mST.WaitFor("#");
                mST.SendMessage("term len 0");
                mST.WaitFor("#");
                mST.SendMessage("show run");
                mST.WaitFor("#");
                mST.SendMessage("exit");
                Console.Write(mST.FindStringBetween("bytes\r\n", "\r\n\r\n",
                "Error: Configuration not obtained"));
            }
        }
    }
}

Let's pick a couple of the important areas to understand and talk about a little further. First the include statement we need for the library:

using scottp.Net.Comm;

This tells the compiler that we are accessing methods in the previously created library.

Next, here is the code that makes up the Main code block:

        static void Main(string[] args)
        {
            CiscoNoEnable cNE = new CiscoNoEnable();
            cNE.sHostName = "10.1.100.1";
            cNE.sUsername = "admin";
            cNE.sPassword = "cisco";
            cNE.getConfig();
        }

So, we created a new CiscoNoEnable object called cNE and then set three properties that is required before executing the getConfig method. If we take a closer look at the getConfig method:

public void getConfig()
        {

            this.sHostName = this.sHostName.Trim();
            this.sUsername = this.sUsername.Trim();
            this.sPassword = this.sPassword.Trim();

            Telnet mST = new Telnet(this.sHostName, 23, 8);

            if (mST.Connect() == false)
            {
                Console.WriteLine("");
                Console.WriteLine("Error: ");
                Console.WriteLine("Timeout connecting to: " + this.sHostName);
                Console.WriteLine("");
            }
            else
            {
                try
                {
                    mST.WaitFor("Username:");
                }
                catch (Exception exc)
                {
                    Console.WriteLine(exc.Message);
                }
                mST.SendMessage(this.sUsername);
                mST.WaitFor("Password:");
                mST.SendMessage(this.sPassword);
                mST.WaitFor("#");
                mST.SendMessage("term len 0");
                mST.WaitFor("#");
                mST.SendMessage("show run");
                mST.WaitFor("#");
                mST.SendMessage("exit");
                Console.Write(mST.FindStringBetween("bytes\r\n", "\r\n\r\n",
                "Error: Configuration not obtained"));
            }
        }

We notice it uses the Telnet method in our library using the hostname set in the CiscoNoEnable property and has port 23 and a value of 8 seconds hard coded into the program. If the Telnet object is able to connect, we use a try/catch block and wait for the telnet server to return the text 'Username'. If/When we see this text, the value set in the UserName property is sent to the telnet server. The telnet server is expected to return a 'Password:' prompt, in which the value of the password property is sent back to the telnet server.

After logging in, we expect a #, which tells us we are in enable mode and then issue the 'term len 0 command', followed by a show run command, and then terminate the connection. We then find all the text between the word 'bytes' (which will be contained in the first line of the response) and the end of the file and writes that text to the console. If we can't find that text, then the telnet server didn't send us the response expected, so an error message is written to the console instead.

To compile the executable, issue the command:

csc /t:exe /out:ConfigSafe.exe /r:scottp.Net.Comm.dll ConfigSafe.cs

This tells the compiler to compile into an executable file with the name ConfigSafe.exe and that the scottp.Net.Comm.dll library is a requirement in order to compile and last, the code to compile is contained in ConfigSafe.cs

By default, a successful run will output the configuration to the console, which is not that useful - so we will pipe the output to a file.

Now we will take a look at the output by opening config.txt in notepad:

The configuration in the text file also serves as the test configuration used for the IOS device in this example. As you can see, the authorization command was used to give the admin user privileged access, which puts us directly into enable mode. We could have just as easily looked for a greater than sign '>' and issued an 'enable' command, in order to enter into enable mode.

I hope you have found this useful and stay tuned for future articles building on this foundation to make a program that can be used in your daily work.

ConfigSafe Source files

The routing protocol distributes topology information through the network so that the route of a Label Switched Path (LSP) can be calculated. An interior gateway protocol, such as OSPF or IS-IS, is normally used, as MPLS networks typically cover a single administrative domain. Let’s configure OSPF on the P/Core devices so that we can ping every interface on all four routers.

hostname r1
!
interface Loopback1
 ip address 10.254.1.1 255.255.255.255
!
interface FastEthernet1/0
 description r2 f1/0
 ip address 10.1.1.1 255.255.255.252
!
interface FastEthernet1/1
 description r3 f1/1
 ip address 10.1.1.5 255.255.255.252
!
router ospf 1
 log-adjacency-changes
 network 10.1.1.0 0.0.0.3 area 0
 network 10.1.1.4 0.0.0.3 area 0
 network 10.254.1.1 0.0.0.0 area 0

hostname r2
!
interface Loopback1
 ip address 10.254.1.2 255.255.255.255
!
interface FastEthernet1/0
 description r1 f1/0
 ip address 10.1.1.2 255.255.255.252
!
interface FastEthernet1/1
 description r4 f1/1
 ip address 10.1.1.13 255.255.255.252
!
router ospf 1
 log-adjacency-changes
 network 10.1.1.0 0.0.0.3 area 0
 network 10.1.1.12 0.0.0.3 area 0
 network 10.254.1.2 0.0.0.0 area 0

hostname r3
!
interface Loopback1
 ip address 10.254.1.3 255.255.255.255
!
interface FastEthernet1/0
 description r4 f1/0
 ip address 10.1.1.9 255.255.255.252
!
interface FastEthernet1/1
 description r1 f1/1
 ip address 10.1.1.6 255.255.255.252
!
router ospf 1
 log-adjacency-changes
 network 10.1.1.4 0.0.0.3 area 0
 network 10.1.1.8 0.0.0.3 area 0
 network 10.254.1.3 0.0.0.0 area 0

hostname r4
!
interface Loopback1
 ip address 10.254.1.4 255.255.255.255
!
interface FastEthernet1/0
 description r3 f1/0
 ip address 10.1.1.10 255.255.255.252
!
interface FastEthernet1/1
 description r2 f1/1
 ip address 10.1.1.14 255.255.255.252
!
router ospf 1
 log-adjacency-changes
 network 10.1.1.8 0.0.0.3 area 0
 network 10.1.1.12 0.0.0.3 area 0
 network 10.254.1.4 0.0.0.0 area 0

A quick way to determine if all your interfaces are in OSPF and each assigned area is to issue the following command:

r1#show ip ospf interface brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Lo1          1     0               10.254.1.1/32      1     LOOP  0/0
Fa1/1        1     0               10.1.1.5/30        1     BDR   1/1
Fa1/0        1     0               10.1.1.1/30        1     BDR   1/1
r1#

Here is the output of the same command ran on the other three routers, just so you can double check your work and make sure we are in sync:

r2#show ip ospf interface brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Lo1          1     0               10.254.1.2/32      1     LOOP  0/0
Fa1/1        1     0               10.1.1.13/30       1     BDR   1/1
Fa1/0        1     0               10.1.1.2/30        1     DR    1/1
r2#
r3#show ip ospf interface brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Lo1          1     0               10.254.1.3/32      1     LOOP  0/0
Fa1/0        1     0               10.1.1.9/30        1     BDR   1/1
Fa1/1        1     0               10.1.1.6/30        1     DR    1/1
r3#
r4#show ip ospf interface brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Lo1          1     0               10.254.1.4/32      1     LOOP  0/0
Fa1/1        1     0               10.1.1.14/30       1     DR    1/1
Fa1/0        1     0               10.1.1.10/30       1     DR    1/1
r4#

Once all the interfaces are configured correctly in OSPF, the routing tables will have the reach-ability to all interfaces on all routers. At this stage, let’s verify what the routing tables should look like on all four routers.

r1#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, + - replicated route

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 10 subnets, 2 masks
C        10.1.1.0/30 is directly connected, FastEthernet1/0
L        10.1.1.1/32 is directly connected, FastEthernet1/0
C        10.1.1.4/30 is directly connected, FastEthernet1/1
L        10.1.1.5/32 is directly connected, FastEthernet1/1
O        10.1.1.8/30 [110/2] via 10.1.1.6, 00:48:55, FastEthernet1/1
O        10.1.1.12/30 [110/2] via 10.1.1.2, 00:49:05, FastEthernet1/0
C        10.254.1.1/32 is directly connected, Loopback1
O        10.254.1.2/32 [110/2] via 10.1.1.2, 00:49:05, FastEthernet1/0
O        10.254.1.3/32 [110/2] via 10.1.1.6, 00:48:55, FastEthernet1/1
O        10.254.1.4/32 [110/3] via 10.1.1.6, 00:48:55, FastEthernet1/1
                       [110/3] via 10.1.1.2, 00:49:05, FastEthernet1/0
r1#

r2#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, + - replicated route

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 10 subnets, 2 masks
C        10.1.1.0/30 is directly connected, FastEthernet1/0
L        10.1.1.2/32 is directly connected, FastEthernet1/0
O        10.1.1.4/30 [110/2] via 10.1.1.1, 00:49:28, FastEthernet1/0
O        10.1.1.8/30 [110/2] via 10.1.1.14, 00:49:38, FastEthernet1/1
C        10.1.1.12/30 is directly connected, FastEthernet1/1
L        10.1.1.13/32 is directly connected, FastEthernet1/1
O        10.254.1.1/32 [110/2] via 10.1.1.1, 00:49:38, FastEthernet1/0
C        10.254.1.2/32 is directly connected, Loopback1
O        10.254.1.3/32 [110/3] via 10.1.1.14, 00:49:28, FastEthernet1/1
                       [110/3] via 10.1.1.1, 00:49:28, FastEthernet1/0
O        10.254.1.4/32 [110/2] via 10.1.1.14, 00:49:38, FastEthernet1/1
r2#

r3#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, + - replicated route

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 10 subnets, 2 masks
O        10.1.1.0/30 [110/2] via 10.1.1.5, 00:49:53, FastEthernet1/1
C        10.1.1.4/30 is directly connected, FastEthernet1/1
L        10.1.1.6/32 is directly connected, FastEthernet1/1
C        10.1.1.8/30 is directly connected, FastEthernet1/0
L        10.1.1.9/32 is directly connected, FastEthernet1/0
O        10.1.1.12/30 [110/2] via 10.1.1.10, 00:49:53, FastEthernet1/0
O        10.254.1.1/32 [110/2] via 10.1.1.5, 00:49:53, FastEthernet1/1
O        10.254.1.2/32 [110/3] via 10.1.1.10, 00:49:53, FastEthernet1/0
                       [110/3] via 10.1.1.5, 00:49:53, FastEthernet1/1
C        10.254.1.3/32 is directly connected, Loopback1
O        10.254.1.4/32 [110/2] via 10.1.1.10, 00:49:53, FastEthernet1/0
r3#

r4#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, + - replicated route

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 10 subnets, 2 masks
O        10.1.1.0/30 [110/2] via 10.1.1.13, 00:50:29, FastEthernet1/1
O        10.1.1.4/30 [110/2] via 10.1.1.9, 00:50:19, FastEthernet1/0
C        10.1.1.8/30 is directly connected, FastEthernet1/0
L        10.1.1.10/32 is directly connected, FastEthernet1/0
C        10.1.1.12/30 is directly connected, FastEthernet1/1
L        10.1.1.14/32 is directly connected, FastEthernet1/1
O        10.254.1.1/32 [110/3] via 10.1.1.13, 00:50:19, FastEthernet1/1
                       [110/3] via 10.1.1.9, 00:50:19, FastEthernet1/0
O        10.254.1.2/32 [110/2] via 10.1.1.13, 00:50:29, FastEthernet1/1
O        10.254.1.3/32 [110/2] via 10.1.1.9, 00:50:19, FastEthernet1/0
C        10.254.1.4/32 is directly connected, Loopback1
r4#

At this point, pinging any interface from any router should be successful. The next step is to configure MPLS on the physical interfaces of each device. There are a couple of things that are needed in order to do this. First, ip cef needs to be running; which is a global configuration command. Second, mpls ip needs to be configured on each physical interface. Here is what the configuration will look like:

!
hostname r1
!
ip cef
!
interface FastEthernet1/0
 description r2 f1/0
 ip address 10.1.1.1 255.255.255.252
 mpls ip
!
interface FastEthernet1/1
 description r3 f1/1
 ip address 10.1.1.5 255.255.255.252
 mpls ip

!
hostname r2
!
ip cef
!
interface FastEthernet1/0
 description r1 f1/0
 ip address 10.1.1.2 255.255.255.252
 mpls ip
!
interface FastEthernet1/1
 description r4 f1/1
 ip address 10.1.1.13 255.255.255.252
 mpls ip

!
hostname r3
!
ip cef
!
interface FastEthernet1/0
 description r4 f1/0
 ip address 10.1.1.9 255.255.255.252
 mpls ip
!
interface FastEthernet1/1
 description r1 f1/1
 ip address 10.1.1.6 255.255.255.252
 mpls ip

!
hostname r4
!
ip cef
!
interface FastEthernet1/0
 description r3 f1/0
 ip address 10.1.1.10 255.255.255.252
 mpls ip
!
interface FastEthernet1/1
 description r2 f1/1
 ip address 10.1.1.14 255.255.255.252
 mpls ip

Once you start getting mpls configured on each device, console messages will appear alerting that LDP neighbors have been established.

r1#
*Jun  7 10:05:02.335: %LDP-5-NBRCHG: LDP Neighbor 10.254.1.2:0 (2) is UP
*Jun  7 10:03:17.791: %LDP-5-NBRCHG: LDP Neighbor 10.254.1.3:0 (1) is UP

Next thing you want to verify is that you have discovered your directly connect neighbors. Each router will have two neighbors, since they have two direct connections to other routers. On any of the routers, we will issue the command: show mpls ldp discovery. This is to verify we are communicating via the LDP protocol to our connected neighbors.

r4(config-router)#do show mpls ldp discovery
 Local LDP Identifier:
    10.254.1.4:0
    Discovery Sources:
    Interfaces:
FastEthernet1/0 (ldp): xmit/recv
    LDP Id: 10.254.1.3:0
FastEthernet1/1 (ldp): xmit/recv
    LDP Id: 10.254.1.2:0
r4(config-router)#end

From the previous example, we examine the output of r4 to determine a few things:

– Our local LDP identifier is 10.254.1.4, this is because we have a loopback configured and LDP will use that first by default as it’s ID.
– We have ldp communications via our local interface FastEthernet1/0 from r3
– We have ldp communications via our local interface FastEthernet1/1 from r2

With everything looking good thus far, I would expect to have formed two neighbor relationships. We can verify our neighbors by issuing the following command: show mpls ldp neighbor

r4#show mpls ldp neighbor
    Peer LDP Ident: 10.254.1.2:0; Local LDP Ident 10.254.1.4:0
        TCP connection: 10.254.1.2.646 - 10.254.1.4.26889
        State: Oper; Msgs sent/rcvd: 11/11; Downstream
        Up time: 00:00:53
        LDP discovery sources:
          FastEthernet1/1, Src IP addr: 10.1.1.13
        Addresses bound to peer LDP Ident:
          10.1.1.2        10.254.1.2      10.1.1.13
    Peer LDP Ident: 10.254.1.3:0; Local LDP Ident 10.254.1.4:0
        TCP connection: 10.254.1.3.646 - 10.254.1.4.17695
        State: Oper; Msgs sent/rcvd: 11/12; Downstream
        Up time: 00:00:53
        LDP discovery sources:
          FastEthernet1/0, Src IP addr: 10.1.1.9
        Addresses bound to peer LDP Ident:
          10.1.1.9        10.254.1.3      10.1.1.6
r4#

Ok, let’s stop for a second – so that I can explain something you might run into when building an MPLS network. Let’s say you expected to see a MPLS neighbor after everything was configured, but when you issued the show mpls ldp neighbor command, the expected neighbor wasn’t there. So, you go back and issue the command: show mpls ldp discovery all to verify local LDP communications and the output looked something like this:

r3#show mpls ldp discovery all
 Local LDP Identifier:
    10.254.1.3:0
    Discovery Sources:
    Interfaces:
FastEthernet1/0 (ldp): xmit/recv
    LDP Id: 10.254.1.4:0; no route
FastEthernet1/1 (ldp): xmit/recv
    LDP Id: 10.254.1.1:0

In this previous example, the neighbor that is not being established is the one directly connected to FastEthernet1/0. As you can see from the output, we are sending and receiving LDP messages; but no neighbor relationship. The LDP Id of the neighbor we want to establish is 10.254.1.4, we can’t establish it because of the following:

FastEthernet1/0 (ldp): xmit/recv
    LDP Id: 10.254.1.4:0; no route

The output shows we have no route to 10.254.1.4. In this case, the reason we don’t have a route to it is because our underlying interior routing protocol was not configured properly. An LDP neighbor can’t be established if it doesn’t have a route to the IP address used for the LDP ID. So, if the LDP ID was the IP address of the locally connected interface – there wouldn’t be a problem, since we would have a route to it. I mention this so that you can watch out for underlying routing issues when trying to establish LDP neighbor relationships.

The last thing we want to do here is a verbose traceroute to actually see the MPLS tags used in the path. For this example, we will issue a traceroute from R4 in our configured network:

r4#traceroute
Protocol [ip]:
Target IP address: 10.254.1.1
Source address: 10.254.1.4
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]: V
Loose, Strict, Record, Timestamp, Verbose[V]:
Type escape sequence to abort.
Tracing the route to 10.254.1.1

  1 10.1.1.9 [MPLS: Label 18 Exp 0] 392 msec
    10.1.1.13 [MPLS: Label 18 Exp 0] 396 msec
    10.1.1.9 [MPLS: Label 18 Exp 0] 508 msec
  2 10.1.1.1 156 msec
    10.1.1.5 232 msec
    10.1.1.1 240 msec
r4#

OK, what did we discover? First let’s look at the traceroute issued, which was to the opposite corner of the network. Just by looking at the drawing, we can tell the traceroute has to go through one of two devices (r2 or r3) in order to get to it’s destination (r1). We are going to issue an extended traceroute to R1′s loopback address using our loopback (of r4) as the source. As you can see from the output of the traceroute, label id 18 was assigned to our traceroute packet before it was switched to the destination.

How are we doing so far? Let’s take a break and pick it up in the third article in this series, where we will add the PE (Provider Edge) devices and begin talking about VRF’s. If you have any questions or comments please leave them in the comment section below and I will answer asap.

I’ll be working with Cisco 7200 routers, since dynamips is being used as the platform.  We could just as easily use some of the other emulated hardware, but out of all the options available in dynamips – a 7200 is probably the closest to what you might see in the core of an MPLS network.  There are three terms that describe the type of MPLS device:

P – which is for Provider equipment
PE – which stands for Provider Edge
CE – which as you have probably already guessed, stands for customer edge.

As far as a provider network that you use for a company WAN solution, your equipment is obviously the CE device and the PE device is what directly connects you into the providers network.  The P devices is what you would consider the providers backbone and would never ‘see’ or interface with that hardware.

In an internally built MPLS network, the premise (or remote office) routers would still be considered the CE equipment and the PE device would typically be in a company data-center serving in a traditional ‘distribution layer’.  The P devices in a corporate built MPLS network would be what connects multiple data-centers together.  For example, if you have two data-centers, then you would have at least one P device at each one that provides the connectivity between those two sites.  The type of hardware used for the P device would be something that supports MPLS label switching.  This could be 7200 routers, 7600 routers, a 6500 Multilayer Switch, or others.  There would be a PE device directly connected to the P devices at each of the two data-centers.  The PE device would be what represents your typical distribution layer, which could be a LAN distribution switch, or a WAN router, or both.  The CE equipment would be say a router at a remote branch office, which resides on the edge of a WAN.  The CE device could also be a firewall back in the data-center.  As you can see, there are many different configurations that one could encounter based on the needs of the company.  I have just tried to list a few of the more common scenarios, but by far is not an exhaustive list.

A little about the lab

As I mentioned earlier, we will be using Dynamips to provide the platform on which we will lab this exercise.  More specifically – GNS3, the all encompasing wrapper around dynamips (and now many other programs I might add) will be the tool of choice here.  At the end of this article, you will find an importable project that you can load directly into your own GNS3 installation.  However, to get the very most out of the exercise – I would recommend building the network out manually in GNS3, to get the complete feeling of the build.

CompanyX network scenario

CompanyX has two datacenters, that are connected by high speed point to point connections.  We have two 100Mbit connections between the datacenters, each one provided by a different commercial carrier.  Each datacenter has two ‘core’ devices which will terminate a single 100Mbit connection.  The two core devices in each datacenter will have a local connection to each other, so that full connectivity can be maintained in the event one of the two metro connections are lost.  These ‘core’ devices will serve as the ‘P’ devices, which does nothing but what is called ‘label switching’.  By the time user traffic reaches these devices, they have labels appended to the packet headers and that is what is used to determine where to foward that traffic.  The concept here applies just like when Layer3 switching was introduced – it is much quicker to switch a packet than it is to route it.

CompanyX network diagram containing P devices

The point to point connections are all /30 networks and using the 10.1.1.0 network. All loopback addresses are assigned out of the 10.254.1.0 network as /32 or host addresses.

So, let’s dive in… Below you will find the basic GNS3 project information that is importable – otherwise use the diagram above to build out the network.

Here is the relevant configuration for each router:

hostname r1
!
interface Loopback1
 ip address 10.254.1.1 255.255.255.255
!
interface FastEthernet1/0
 description r2 f1/0
 ip address 10.1.1.1 255.255.255.252
!
interface FastEthernet1/1
 description r3 f1/1
 ip address 10.1.1.5 255.255.255.252

hostname r2
!
interface Loopback1
 ip address 10.254.1.2 255.255.255.255
!
interface FastEthernet1/0
 description r1 f1/0
 ip address 10.1.1.2 255.255.255.252
!
interface FastEthernet1/1
 description r4 f1/1
 ip address 10.1.1.13 255.255.255.252

hostname r3
!
interface Loopback1
 ip address 10.254.1.3 255.255.255.255
!
interface FastEthernet1/0
 description r4 f1/0
 ip address 10.1.1.9 255.255.255.252
!
interface FastEthernet1/1
 description r1 f1/1
 ip address 10.1.1.6 255.255.255.252

hostname r4
!
interface Loopback1
 ip address 10.254.1.4 255.255.255.255
!
interface FastEthernet1/0
 description r3 f1/0
 ip address 10.1.1.10 255.255.255.252
!
interface FastEthernet1/1
 description r2 f1/1
 ip address 10.1.1.14 255.255.255.252

GNS3 project for basic MPLS build

Here is some explanation on how the chart is presented:

The first row in the chart is the decimal representation of each placeholder in an 8 bit (binary) number.  This is pretty self explanatory, nothing so far that you would learn outside of math class.

The second row is the netmask equivalent for each decimal placeholder value. 

Let’s start with a decimal representation of a subnet mask:

x.x.x.x – Where x equals a number between 0 and 255 – well, actually it can’t be any number between 0 and 255 when we are talking about netmasks.  To clarify, in a netmask, the x can only be one of the following numbers: 0, 128, 192, 224, 240, 248, 252, 254, or 255.  Each x represents one octect and we know (version 4) IP addresses and subnet masks each have a total of four octects.

The netmask value is the inverse value of the decimal number.  To come up with this value we take the number 256 (which is how many numbers we can get from a binary 8 bit number) and we subtract the decimal value from it and that gives us the netmask equivalent. 

The same conversion in binary would look like the following:

The inverse value of 00001111 (which is a decimal 16)  would be 11110000 (a simple flip, ones become zeros and zeros become ones), which is a decimal 240.

The remainding lines represent the CIDR notation of a given netmask value.  The CIDR value represents how many binary ones are represented in a given netmask.  Let’s go back to the decimal representation of a netmask:

255.x.x.x – The class A boundary would be between the first and second octect.  There are inherantly 8 binary ones in this 32 bit binary number – before any additional subnetting is applied.
255.255.x.x – The class B boundary would be between the second and third octect.  There are inherantly 16 binary ones in this 32 bit binary number – before any additional subnetting is applied.
255.255.255.x – The class C boundary would be betwen the third and fourth octect.  There are inherantly 24 binary ones in this 32 bit binary number – before any additional subnetting is applied.

The first place to start is with the service commands

service password-encryption

Explanation:

The router administrator will ensure passwords are not viewable when displaying the router configuration. Type 5 encryption must be used for the enable mode password.

no service udp-small-servers
no service tcp-small-servers

Explanation:

All IOS versions above 12.0 has small-servers disabled by default.  However, it is good to make sure these services didn’t get enabled somewhere along the way.  The commands above won’t show up in the configuration, since they are off by default.  Cisco IOS provides these “small services” which include echo, chargen, and discard.  These services are completely unnecessary to run on Cisco devices.

no service pad

Explanation:

Packet Assembler Disassembler (PAD) is an X.25 component that is seldom used.  PAD acts like a multiplexer for the terminals. If enabled, it can render the device open to attacks.

service tcp-keepalives-in

Explanation:

Idle logged-in telnet sessions can be susceptible to unauthorized access and hijacking attacks. By default, routers do not continually test whether a previously connected TCP endpoint is still reachable. If one end of a TCP connection idles out or terminates abnormally, the opposite end of the connection may still believe the session is available. These “orphaned” sessions use up valuable router resources and can also be hijacked by an attacker. To mitigate this risk, routers must be configured to send periodic keep-alive messages to check that the remote end of a session is still connected. If the remote device fails to respond to the keep-alive message, the sending router will clear the connection and free resources allocated to the session.

no service finger

Explanation:

The IOS finger service supports the UNIX finger protocol, which is used for querying a host about the users that are logged on.  This would give potential attackers a head start by providing valid usernames for the device.

no boot network
no service config

Explanation:

The routers can find their startup configuration either in their own NVRAM or load it over the network via TFTP or Remote Copy (rcp).  Obviously, loading in from the network is taking a security risk. If the startup configuration was intercepted by an attacker, it could be used to either gain access to the router.

Next, let’s take a look at the various server services available in IOS.

no ip http-server
no ip ftp-server
no ip tftp-server

Explanation:

The services listed above are extremely insecure and serve very little useful purpose.  An ftp-server or tftp-server might be used in environments where you have one device that has a software image on it that you want to distribute to other reachable devices.  These other devices might not have connectivity to a centralized distribution server that would host images for software upgrades, therefore making it convenient to use a router in order to get the job done.  If these services are used, it should only be in a temporary capacity and need to be disabled before logging out of the device.

no ip bootp server

Explanation:

Bootp is a user datagram protocol (UDP) that can be used by Cisco routers to access copies of Cisco IOS Software on another Cisco router running the Bootp service. In this scenario, one Cisco router acts as a Cisco IOS Software server that can download the software to other Cisco routers acting as Bootp clients. In reality, this service is rarely used and can allow an attacker to download a copy of a routers Cisco IOS Software.

no ip source-route

Explanation:

Source routing is a feature of IP, whereby, individual packets can specify routes. This feature is used in several different network attacks.  The router should always control how traffic is routed as apposed to be told to trust a path that is provided from another source.

The good news is there are resources available to anyone and are provided by Defense Information Systems Agency (DISA) which is a government agency that is part of the Department of Defense (DoD). These guides are separated into two different types: One set is called Security Technical Informational Guides (STIG) and the other is called Security Checklists.  These guides are developed to provide guidance for people who build and manage DoD networks.  They are also used in audits performed within Department of Defense networks.

None of the DoD offered materials has anything to do with HIPPA, PCI, SOX, etc. on the surface, but the thing they do have in common is they are focused on security best practices.  In my experience dealing with HIPPA, PCI, SOX, and DoD networks, using these guides as a reference to secure a network or platform will cover 90+% of anything that would come up in a HIPPA, PCI, or SOX audit.

These guides are available publicly to anyone and are considered unclassified material in their currently offered form.

Use the following link to browse the security checklists, find one that addresses your area of interest and download.  All unpacked files are in .pdf format.

http://iase.disa.mil/stigs/checklist/index.html

This version is actually based on 4.03, but has many added features that doesn’t exist in the 4.0.4 Cisco release. The version given to this particular code distribution is F4.0.3.alpha-9a.

It runs just like the other version, (yes, with all the same qwerks as well) with additional options available to you.

Cisco tacacs+ server for Windows

Have fun, and if you successfully use any of the additional features – be sure to post a comment to let me and others know.

IOS devices functioning as some type of gateway comes to mind as a type of device that won’t route traffic – however network redundancy to the device is still desired.  In this example, a Cisco VG224 is used in a network to provide dial tone to analog devices over an IP network.  The VG224 gateway has multiple interfaces and does have the ability to run a routing protocol for reachability, but would be considered a bloated solution just to provide redundant network connections to the device.

In this example, we will accomplish network link redundancy by using a feature called Integrated routing and bridging or IRB for short.  In an IRB configuration, multiple physical interfaces are assigned to a common bridge group.  The two interfaces then form a bridge what communicates with a bridge virtual interface.  The device IP address then gets assigned to the virtual interface.

As with any bridge, loop detection is necessary to prevent problems in the network.  Spanning tree is configured on the specific bridge which will communicate with the connected access switches.  In this particular scenario, we would never want this bridge to become the root for the connected network.  Therefore it is important to specify a priority, even though it is optional, to influence the root bridge selection process.

To get started, specify a bridge number and spanning tree protocol used. The ieee option is the only real valid choice here, which is the 802.1D standard spanning tree.

GW-VG224-01(config)#bridge 1 protocol ?
  dec          DEC protocol
  ibm          IBM protocol
  ieee         IEEE 802.1 protocol
  vlan-bridge  vlan-bridge protocol

GW-VG224-01(config)#bridge 1 protocol ieee

Every bridge that participates in a spanning-tree domain goes through the root bridge election process. Specify the highest bridge priority for influencing the election process to not select this device as a root bridge:

GW-VG224-01(config)#bridge 1 priority ?
  <0-65535>  Priority (low priority more likely to be root)

GW-VG224-01(config)#bridge 1 priority 65535

This device in this example has two Fast Ethernet interfaces. Assign both of these physical interfaces to the bridge group number previously assigned:

GW-VG224-01(config)#int fa0/0
GW-VG224-01(config-if)#bridge-group 1
GW-VG224-01(config-if)#int fa0/1
GW-VG224-01(config-if)#bridge-group 1

Specify the use of irb:

GW-VG224-01(config)#bridge ?
  <1-255>            Bridge Group number for Bridging.
  crb                Concurrent routing and bridging
  irb                Integrated routing and bridging
  mac-address-table  MAC-address table configuration commands

GW-VG224-01(config)#bridge irb

Enter interface configuration mode for the virtual interface that is created. This interface is where the layer3 configuration goes:

GW-VG224-01(config)#int bvI ?
  <1-255>  BVI interface number

GW-VG224-01(config)#int bvI 1
GW-VG224-01(config-if)#ip address 10.32.16.20 255.255.255.0

Traffic will not be forwarded until the bridge is configured to route the IP traffic through this virtual bridge.

GW-VG224-01(config)#bridge 1 route ?
  ip  IP
GW-VG224-01(config)#bridge 1 route ip

Lastly, take the physical interfaces out of shutdown mode:

GW-VG224-01(config-if)#int fa0/0
GW-VG224-01(config-if)#no shut
GW-VG224-01(config-if)#int fa0/1
GW-VG224-01(config-if)#no shut

A new feature that comes along with the modular image is the inclusion of Cisco Embedded Event Manager (EEM).  This feature allows the EEM process to ‘catch’ a defined event and then spawn an action from that raised event.  For example, the device can generate and send an email when the CPU goes over a certain percentage for a period that is longer than a defined threshold.  The engine behind this functionality is controlled using the Python scripting language.  Using Python to write these embedded event handlers provides some powerful capabilities at your fingertips.

This article wasn’t really intended to help you decide on using the IOS modularity option, but to explain the upgrade/conversion process.  The first thing to do is obtain the proper image from CCO.  The modular version has the same feature sets and versions available just like the native IOS versions do.  Just pick the right modular image based on your hardware and services needed just like you would any other time.

Once you have downloaded the image, upload it to storage that is available on the (primary) supervisor.  Before the ‘installation’ of the modular IOS, the supervisor has to boot from it first, like it would any other image.  In fact, the switch can load the modular IOS .bin file and run just like it was the non-modular version.  However, this would defeat the purpose, since patching is not available until the installation has been performed and the system rebooted.

Put a boot statement in the configuration pointing it to the .bin file that was just uploaded to storage and reload the switch.  Once the switch is back up running on the new image here is where it starts to get fun…

Let’s look at the output of the show version command after the switch has booted the new IOS image:

6500switch#sh version
Cisco IOS Software, s72033_rp Software (s72033_rp-ADVIPSERVICESK9_WAN-VM),
Version 12.2(33)SXH3a, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2008 by Cisco Systems, Inc.
Compiled Wed 24-Sep-08 14:37 by prod_rel_team

ROM: System Bootstrap, Version 12.2(17r)SX5, RELEASE SOFTWARE (fc1)

6500switch uptime is 14 hours, 53 minutes
Uptime for this control processor is 14 hours, 52 minutes
Time since 6500switch switched to active is 14 hours, 52 minutes
System returned to ROM by reload at 23:22:24 CDT Tue Oct 14 2008
 (SP by reload)
System image file is "disk0:s72033-advipservicesk9_wan-vz.122-33.SXH3a.bin"

cisco WS-C6506-E (R7000) processor (revision 1.1) with
516096K/8192K bytes of memory.
SR71000 CPU at 600Mhz, Implementation 1284, Rev 1.2, 512KB L2 Cache
Last reset from s/w reset
1 Virtual Ethernet interface
52 Gigabit Ethernet interfaces
1917K bytes of non-volatile configuration memory.

65536K bytes of Flash internal SIMM (Sector size 512K).
Configuration register is 0x2102

Patching is not available since the system is not running from an
installed image. To install please use the "install file" command

Take a look at the last couple of lines of the output. This output is telling you to run the ‘install file’ command in order to install the image. The installation procedure creates a directory structure on the file system specified in the install command. In this example, the image is running from flash installed in slot0:, which is known to the switch as disk0:. We are going to install onto the sup-bootdisk0: flash, which is an compact flash module installed internally with a compact flash adapter that replaces the SP bootflash on the supervisor. Cisco recommends the modular installation use internal storage, because it is too easy to eject the flash from the slots on the front of the supervisor – which would cause the switch to crash.

The command to start the process will be: install file disk0:s72033-advipservicesk9_wan-vz.122-33.SXH3a.bin sup-bootdisk0:/sys . The syntax is basically the source image to use then the destination. Notice the /sys at the end of the destination, which is a required argument and is called the search root. The search root is basically just a top level directory and valid entries are: sys|newsys|oldsys .  Below is a normal output during the installation:

6500switch#install file disk0:s72033-advipservicesk
9_wan-vz.122-33.SXH3a.bin sup-bootdisk:/sys
Source filename [s72033-advipservicesk9_wan-vz.122-33.SXH3a.bin]?
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Verifying checksums of extracted files

Verifying installation compatibility

Finalizing installation ...
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Computing and verifying file checksums
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Writing installation meta-data.  Please wait ...

NOTE: The newly added base image is not yet active.
      To activate the new base image, perform an 'install bind' in
      config mode followed by a 'reload'.

[DONE]

6500switch#

The last thing you see is a note on how to activate the new base image.  The correct command in this example is: 6509switch(config)#install bind sup-bootdisk:/sys .  Notice this command is done from configuration mode.  This command basically just adds a boot statement in the switch configuration pointing to the new modular image.  Here is the output from the install bind command:

6500switch(config)#install bind sup-bootdisk:/sys
WARNING: This system is running in a redundant mode.  However, the specified
search root on the Standby does not contain installed software, or is unavailable.
Unless the proper software is installed on the Standby,
it will not boot from this binding

The message we received above was due to the fact the example system was running dual supervisor modules.  If you have a single supervisor, this message will not display.  In order to get the installation onto the redundant supervisor, the process is a little simpler.  There is a copy command that will copy the existing installation on sup-bootflash0:/sys to the redundant supervisor’s file system.  The following is all that is required to insure the secondary supervisor can boot successfully:

6500switch#install copy sup-bootdisk:/sys slavesup-bootdisk:/sys
Copying installed software at sup-bootdisk:/sys to slavesup-bootdisk:/sys
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[DONE]

A look at the running configuration shows the following:

6500switch#show run

boot-start-marker
boot system flash disk0:s72033-advipservicesk9_wan-vz.122-33.SXH3a.bin
boot system flash sup-bootdisk:
boot system sup-bootdisk:/sys/s72033/base/s72033-advipservicesk9_wan-vm
boot-end-marker

As you can see, the install bind command will not remove any of the previous boot statements.  In all the upgrades I have performed so far, I have went ahead and removed all the old boot statements, just to make sure the supervisor boots correctly.

6500switch#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
6500switch(config)#no boot system flash disk0:s72033-advipservicesk9_wan-vz.122-33.SXH3a.bin
6500switch(config)#no boot system flash sup-bootdisk:
6500switch(config)#end
6500switch#wr
Building configuration...
[OK]
6500switch#sh boot
BOOT variable = sup-bootdisk:/sys/s72033/base/s72033-advipservicesk9_wan-vm,12;
CONFIG_FILE variable =
BOOTLDR variable =
Configuration register is 0x2102

Standby is up
Standby has 524288K/8192K bytes of memory.

Standby BOOT variable = sup-bootdisk:/sys/s72033/base/s72033-advipservicesk9_wan-vm,12;
Standby CONFIG_FILE variable =
Standby BOOTLDR variable =
Standby Configuration register is 0x2102

The last thing to do is reload the switch:

6500switch#reload
Proceed with reload? [confirm]

Once the switch is back up, the output of show version now looks like:

6500switch# sh ver
Cisco IOS Software, s72033_rp Software (s72033_rp-ADVIPSERVICESK9_WAN-VM),
 Version 12.2(33)SXH3a, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2008 by Cisco Systems, Inc.
Compiled Wed 24-Sep-08 14:37 by prod_rel_team

ROM: System Bootstrap, Version 12.2(17r)SX5, RELEASE SOFTWARE (fc1)

 6500switch uptime is 8 minutes
Uptime for this control processor is 7 minutes
Time since 6500switch switched to active is 7 minutes
System returned to ROM by reload at 15:07:48 CDT Wed Oct 15 2008 (SP by reload)
System image file is "sup-bootdisk:/sys/s72033/base/s72033-advipservicesk9_wan-vm"

cisco WS-C6506-E (R7000) processor (revision 1.1) with 516096K/8192K bytes of memory.
SR71000 CPU at 600Mhz, Implementation 1284, Rev 1.2, 512KB L2 Cache
Last reset from s/w reset
1 Virtual Ethernet interface
52 Gigabit Ethernet interfaces
1917K bytes of non-volatile configuration memory.

65536K bytes of Flash internal SIMM (Sector size 512K).
Configuration register is 0x2102

System is currently running from installed software
For further information use "show install running"

To look at the actual software versions along with any patch information, issue the show install running command:

6500switch#show install running

B/P C State     Filename
--- - --------  --------

Software running on card installed at location s72033_rp - Slot 6 :
 B    Active    slavesup-bootdisk:/sys/s72033_rp/base/DRACO2_MP

Software running on card installed at location s72033 - Slot 5 :
 B    Active    sup-bootdisk:/sys/s72033/base/s72033-advipservicesk9_wan-vm -
Version 12.2(33)SXH3a

Software running on card installed at location s72033_rp - Slot 5 :
 B    Active    sup-bootdisk:/sys/s72033_rp/base/DRACO2_MP

Software running on card installed at location c2_lc - Slot 1 :
 B    Active    sup-bootdisk:/sys/c2_lc/base/C2LC

Software running on card installed at location s72033 - Slot 6 :
 B    Active    slavesup-bootdisk:/sys/s72033/base/s72033-advipservicesk9_wan-vm -
Version 12.2(33)SXH3a

LEGEND:
-------:
B/P/MP - (B)ase image, (P)atch, or (M)aintenance (P)ack
'C' - (C)ommitted
Pruned - This file has been pruned from the system
Active - This file is active in the system
PendInst - This file is set to be made available to run on the
   system after next activation.
PendRoll - This file is set to be rolled back after next activation.
InstPRel - This file will run on the system after next reload
RollPRel - This file will be removed from the system after next reload
RPRPndIn - This file is both rolled back pending a reload, and pending
   installation.  On reload, this file will not run and will move to
   PendInst state.  If 'install activate' is done before reload, pending
   removal and install cancel each other and file simply remains active
IPRPndRo - This file is both installed pending a reload, and pending rollback.
   If the card reloads, it will be active on the system pending a rollback
   If 'install activate' is done before a reload, the pending install and
   removal with cancel each other and the file will simply be removed
Occluded - This file has been occluded from the system,
   a newer version of itself has superceded it.

6500switch#

All things considered, this is a pretty easy upgrade – just take your time and make sure each step is followed carefully. I would recommend allocating 1.5 hours for the first upgrade performed. Once you’re familiar with the process, it can be done in half that time and even quicker if the image is transferred to a filesystem on the switch prior to performing the upgrade.

Putty has a sister program that is called plink.  Like putty, plink is a standalone executable that is capable of accessing remote devices using telnet or ssh.  Plink is basically used in place of putty when you want the input/output of the program to use STDIN/STDOUT.  So, for example you can open a command prompt, invoke plink and connect to a device.  The interaction with the session will look just as if it would when using the telnet.exe from the XP/Vista command line.  One of the features of plink is that it can share the saved sessions created in Putty.  By default, putty will use the Windows registry to store saved connection information.  However, the configuration can be changed to store the sessions in the local file system.

In this initial example, lets configure a router to accept an incoming ssh connection with a locally defined username/password combination.  The basic IOS configuration to accomplish this task will look like the following:

R1(config)#int fa0/0
R1(config-if)#ip address 10.1.100.1 255.255.255.0

! Define the hostname on the router - required for enabling ssh
Router(config)#hostname R1

! Define the domain name on the router - required for enabling ssh
R1(config)#ip domain-name xpresslearn.com

! Generate encryption keys for use with ssh
R1(config)#crypto key generate rsa general-keys
The name for the keys will be: R1.xpresslearn.com
Choose the size of the key modulus in the range of 360 to 2048 for your
General Purpose Keys. Choosing a key modulus greater than 512 may take
a few minutes.
How many bits in the modulus [512]:
% Generating 512 bit RSA keys, keys will be non-exportable...[OK]

! Use the latest version of ssh
R1(config)#ip ssh version 2

! Locally defined username on the router
R1(config)#username xpresslearn privilege 15 secret pa55w0rd

! Enable aaa
R1(config)#aaa new-model

! Set all logins by default to use the local username entries
R1(config)#aaa authentication login default local

! Use the priviledge level defined in the local username statement
R1(config)#aaa authorization exec default local

Now, from the command line, let’s use the plink.exe program to show the interfaces of the Cisco device. But first, lets take a look at the options available from the plink executable:

Command line options for plink.exe

As you can see, one of the options is a -m to run remote commands from a file.  In order to automatically run commands without interaction, the commands you want to run need to be inserted into a text file.

Text file to use with plink.exe

Now, run the program with the proper command line options.  Which in the following example is:

- Use ssh to connect
- Connect with the username xpresslearn
- The IP address of the device we are connecting is 10.1.100.1
- use the password pa55w0rd
- run the commands contained in the file called plink-commands.txt that resides in the current directory.

Running plink.exe in batch mode

As you can see, the output from the command is displayed as standard program output.  This output can just as easily be piped to a text file.  Next, let’s use this method to back up the configuration of the router.  First, we will put the proper commands in the text file for batch processing.

Backup cisco configuration via plink.exe

Now, run plink.exe with the same command line options and add the pipe to end:

Router backup using plink.exe

So we ran plink with the commands in the text file and piped them to a file called R1.txt.  In the above screen shot, you can see where we view the text file after the program has executed.  The text file contains the complete configuration of the device, which was displayed using the show run command.  FYI: the term length 0 command is used to prevent paging when showing the running configuration.