First, a few details regarding the example scenario:

A previous upgrade to an IP enabled KVM switch was causing issues with it’s normal operation. There were issues with local use using a directly attached keyboard/monitor/mouse and also when using the viewer plugin remotely. After my co-workers had complained enough, I decided it was time to downgrade the software to the previously running code, which did not have all the issues that was currently happening. Using the management software for the KVM, I downgraded 7 of 8 devices successfully. One device failed during the procedure and subsequently stopped responding on the network.

After giving sufficient time for possible self-recovery with no results, I decided it was time to investigate further. Upon inspecting the device visually, it was determined that the equipment was in recovery mode (The power light was blinking steady with no other lights on the device). This determination was made by going to the hardware manufacturers website and downloading the manual for my particular model, then looking up the device states in the troubleshooting section of the documentation.

The first thing attempted was an obvious one: Try and power cycle the hardware. After turning off and back on, the same result happened – a steadily flashing power light.

The documentation stated that when the device was in recovery mode, it would automatically attempt to download the system image via tftp from the management server. After inspecting the machine running the KVM management software, I was able to determine there was no traffic between it and the failed device. There are several ways to troubleshoot this, my particular method was to run a packet sniffer (Wireshark) from the management server to see if any requests were coming from the KVM’s IP address. If installing Wireshark (or similar program) is not an option on the machine, a portable version is available from the website that can be run out of a directory that either resides on a hard or flash drive.

At this point, a support call would have been the next course of action. However, a current maintenance contract did not exist on this equipment, so tech support was not an option. Truthfully, even if it was an option, I most likely wouldn’t be using it. I would rather be hung upside down (by my toenails), 30 feet in the air, with a pack of flesh eating Hyenas waiting underneath, for me to plummet to my death so they could consume me. Not that there is anything wrong with calling tech support, never mind – I digress…

The device is now officially ‘bricked’ (hence the title of this article). The urban dictionary defines the term as follows:

Bricked refers to ANY hardware that is unable to start up due to bad software; Usually because of a bad software flash, a modification done improperly, loss of necessary files, etc.

Thankfully, the majority of the time a device can be recovered after being in this state.

The next step in my process was to determine if a console was available. After looking at the documentation once again, I found that a serial port was available on this device for management purposes. After recording the applicable serial port settings and grabbing a null modem (serial) cable, it was off to the data center where the device was located.

My thought was to connect the serial cable between a laptop and the KVM device to see if I could get any output using a terminal program. Putty is my terminal program of choice, which has support for serial connections. I configured Putty to connect to COM1 at 9600 baud with 8 bits, No parity, and 1 stop bit (better known as eight, ‘n’, and one). The hope here was maybe the device used a bootloader which is a small piece of software that loads initially (like a BIOS) and in turn loads the full software image for the device. Many times when a bootloader can’t load the main software image, there is a very basic command line structure available to perform recovery functions such as transferring an image, re-issuing boot commands, etc.

After starting Putty and pressing the Enter key several times (which usually prompts the connected device to respond), there was no response. I’m still not sure what was going on with why the console wasn’t working, because I moved on from that very quickly. (My assumption here was the command line via serial port was only available after the firmware was correctly loaded and running on the device)

As I previously mentioned, by reading the documentation, I knew the device was supposed to request a boot image via TFTP. So, I took my laptop and connected it to an isolated switch along with the KVM device’s network interface. After starting Wireshark on the laptop and starting a capture, the KVM was powered on.

AH, progress!

The above image displays a WireShark window running on my laptop.  When this photo was taken, there was a display filter set – so that only traffic from the KVM src mac-address was shown.  (A mac filter was used, since that was the only known information).  The mac-address is always shown, usually via a sticker on the device.  Notice it has an IP of 10.0.0.2, which obviously is hard coded in the firmware – since I didn’t have a DHCP server running on the laptop. The next thing you see is the appliance making a request via TFTP to 10.0.0.3 (again another hard coded entry in the firmware) and is requesting a file with the name DSRxx20.fl.

With this information, the laptop’s network interface can now be set statically to 10.0.0.3. The next thing I needed was a TFTP server loaded on my laptop. This is an easy task, with several available freely on the Internet, download your favorite (my recommendation is tftpd32) TFTP server and run it.

The final step is to put the firmware for the device into the TFTP server ‘home’ directory and make sure the filename matches what is being requested (in this case it was DSRxx20.fl). After the file was in place with the TFTP server running, I power cycled the appliance once again:

As you can see from above, the transfer took place, which then the device proceeded to boot up perfectly! SUCCESS! Although this is not a universal step by step instruction on how to save any ‘bricked’ device – it should help outline the steps required to discover what is needed to bring something you are working on back to life.

In this example, we will use a very nice tool called Expect.  Expect has traditionally been run on Unix variants, but has also been ported to Windows.  Activestate, the company known for Perl on the Windows platform, also offers TCL for Windows – which includes Expect.  This particular article will cover the program running on the Linux platform, with the possibility of revisiting at a later date to explore whether we can run the same processes in Windows.

In today’s times, even if your a full blown Windows user, there are very easy ways to add Linux into your engineering toolbox.  This is most commonly done using Virtual technology, which is offered by multiple vendors.  The more common scenarios are to download a free ‘player’, such as the one provided by vmWare. Once you have an installed VM player, you can proceed by building a basic Linux machine from scratch (which will run on top of your Windows platform), or just download a pre-built ‘appliance’ from the vmWare website. You can easily download the latest and greatest versions of Linux, ready to run, by copying an image to your workstation, hit play on the vmPlayer, login and your ready to work!  It really is that easy!

First, let’s start with a simple expect script and then gradually move into something a little more flexible. For an Operating System, I am using Ubuntu 10.10 Server Edition. The Server Edition just installs the minimum requirements to run a linux machine with basic tools. There is no GUI in the installation, so everything is done at a command line. This keeps the footprint small, which is especially good for running inside a virtual machine like I am doing.

Ok, I am logged into the Linux machine and at a command prompt. In this example, we are going to create a very simple expect script to log into a Cisco router, that is pre-configured to allow a username and password only. After a sucessful login, we will immediately be in priviledged mode. If this is not the way your test device is setup, don’t worry – I will show you how to modify the script, following this example. The script itself contains many comments (lines preceded with the ‘#’ character), which explains what the following line accomplishes.

First, let’s create the script by typing the following command:

root@ubuntu:~/util# vi 1.exp

Once in the vi editor, press ‘i‘ to insert characters and type or paste the following commands: Note: To try this on an actual device, replace the IP address shown below (192.168.1.1) with a valid device address in your network. Also adjust the username and password (admin/cisco) as necessary for your environment.

#!/usr/bin/expect -f
#Tells interpreter where the expect program is located.  This may need adjusting according to
#your specific environment.  Type ' which expect ' (without quotes) at a command prompt
#to find where it is located on your system and adjust the following line accordingly.
#
#
#Use the built in telnet program to connect to an IP and port number
spawn telnet 192.168.1.1 23
#
#The first thing we should see is a User Name prompt
expect "User Name:"
#
#Send a valid username to the device
send "admin\n"
#
#The next thing we should see is a Password prompt
expect "Password:"
#
#Send a vaild password to the device
send "cisco\n"
#
#If the device automatically assigns us to a priviledged level after successful logon,
#then we should be at an enable prompt
expect "#"
#
#Tell the device to turn off paging
send "term length 0\n"
#
#After each command issued at the enable prompt, we expect the enable prompt again to tell us the
#command has executed and is ready for another command
expect "#"
#
#Show us the running configuration on the screen
send "show run\n"
#
#The interact command is part of the expect script, which tells the script to hand off control to the user.
#This will allow you to continue to stay in the device for issuing future commands, instead of just closing
#the session after finishing running all the commands.
interact

Once these commands have been typed, press ESC key to exit out of insert mode. Then press ‘:wq‘ to write to the file 1.exp and exit the vi editor.

If you test device requires an enable password, use this script instead (with the previous mentioned modifications):

#!/usr/bin/expect -f
#Tells interpreter where the expect program is located.  This may need adjusting according to
#your specific environment.  Type ' which expect ' (without quotes) at a command prompt
#to find where it is located on your system and adjust the following line accordingly.
#
#
#Use the built in telnet program to connect to an IP and port number
spawn telnet 192.168.1.1 23
#
#The first thing we should see is a User Name prompt
expect "User Name:"
#
#Send a valid username to the device
send "admin\n"
#
#The next thing we should see is a Password prompt
expect "Password:"
#
#Send a vaild password to the device
send "cisco\n"
#
#If the device requires us to enter an enable password, then we should currently be at a
#non-privileged prompt
expect ">"
#
#Send the command to enter enable mode
send "enable\n"
#
#We should see a prompt asking for the enable password
expect "Password:"
#
#Send the enable password
send "supercisco\n"
#We should be in privileged mode now reflected by a hash prompt
expect "#"
#
#Tell the device to turn off paging
send "term length 0\n"
#
#After each command issued at the enable prompt, we expect the enable prompt again to tell us the
#command has executed and is ready for another command
expect "#"
#
#Show us the running configuration on the screen
send "show run\n"
#
#The interact command is part of the expect script, which tells the script to hand off control to the user.
#This will allow you to continue to stay in the device for issuing future commands, instead of just closing
#the session after finishing running all the commands.
interact

Now, it is time to run our test script:

root@ubuntu:~/util# expect 1.exp

Here is a sample output:

root@ubuntu:~/util# expect 1.exp
spawn telnet 192.168.1.1 23
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.

User Name:admin
Password:*****

Router#term length 0
Router#show run
Building configuration...

Current configuration : 3832 bytes
!
version 12.3
service timestamps debug uptime
service timestamps log uptime
service password-encryption
!
hostname Router
!
boot-start-marker
boot-end-marker
!
!
ip subnet-zero
!
!
ip cef
no ip domain lookup
!
!
!
!
!
!
!
!
!
!
!
!
!
username admin privilege 15 secret ****
!
!
!
!
!
!
!
interface FastEthernet0/0
 ip address 192.168.1.1 255.255.255.0
 duplex auto
 speed auto
!
interface Serial0/0
 no ip address
 shutdown
!
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
!
interface Serial0/1
 no ip address
 shutdown
!
no ip http server
no ip http secure-server
ip classless
!
!
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
!
!
end

Router#

At the end of the script, we are left at the command prompt, so that we may continue interacting with the router.

In the next article, we will take the script to Version 2 (and beyond). Future enhancements include creating a separate file for all the devices and credentials, ability to use telnet or ssh for the connection, copy configurations from different vendors hardware.

The issue I’m speaking about is one regarding Windows Vista/7/2008 Server and the ‘Unidentified network’.  Before we dive into fixing the unidentified network categorization, a little explanation on how the process works:  The Windows Operating System wants to classify each active network interface, in order to determine what category to place the adapter in.  Inside the Control Panel, click on Network and Internet, then click View network status and tasks.  In the default view, this should bring you to the ‘Network and Sharing Center’.  Inside the section ‘View your active networks’, each connected network interface will be displayed.

Each network interface is then categorized as either Public, Private, or Domain.  Once the interface is automatically assigned to one of these categories, certain rules are applied.  The rules are related to the Windows Firewall, Network Discovery, and Network Sharing.

Let’s exclude the Domain category for a moment and talk about Public and Private networks.  Usually when a new network interface is activated (this includes Wireless networks) a window will appear asking you if the network is part of a public or private network.  The Public option is intended to be just that: public areas, which would typically be locations outside of your ‘trust zone’.  With Public networks, you get the most secure settings applied to that interface, which include Firewall, Network Discovery and Sharing settings.  Private networks will get less secure options applied, but usually allow more plug and play functionality like: Windows Firewall being less restrictive, Sharing allowed by default, etc.

Quite honestly, in a company network – most of the time you don’t necessarily want all this automatic stuff to happen.  Us network people like to think we are smart enough to know what is best for our systems and don’t want Windows (or anything else for that matter) to try and figure it out for us.  Nonetheless, most all default software installations and factory hardware configurations are geared toward the automatic, I know what is best for you configuration.

In this specific example, I have a crossover connection between two Windows 2008 servers that will be used with Microsoft Clustering Services.  With this connection, I have the least amount of properties assigned to the interface.  All I need is and IP address and subnet mask.  There won’t be any default gateway, DNS servers, etc – just enough to communicate over a point to point connection with another host.  Another common example of when you would have this same type configuration is when you have a secondary adapter in a machine that is communicating to device on the same subnet and no routing is involved, such as an interface being used for iSCSI storage connection.  Even though this is a common enough configuration in the business world, Windows can’t seem to figure out what to do with it.  So, what happens is the interface becomes part of an ‘Unidentified Network’ and takes on the properties of the Public network settings (strict firewall, no sharing, etc.).

The fix to this is to tell Windows not to try and automatically determine what type of connection it is, but that it is an endpoint device and is not a connection to a true external network.  Consequently, Windows will then ignore the endpoint device when Windows identifies networks. The Network Awareness APIs indicate that the device does not connect the computer to a network. For end users in this situation, the Network and Sharing Center and the network icon in the notification area do not show the NDIS endpoint device as connected. However, the connection is shown in the Network Connections Folder.

So, for every interface that you don’t want showing up as an ‘Unidentified network’ like the example below:

all you have to do is the following:

At a command prompt, run: ipconfig /all

Find the interface that is showing up as Unidentifed, which in this case has been renamed to Crossover:

and make note of the Physical Address (The image above has the mac address erased).

Next, invoke powershell at the command line.  Once that the PS command prompt, issue the command: get-wmiobject win32_networkadapter as shown below:

Once the powershell output is displayed, match up the Physical Address obtained from the previous ipconfig output with the MACAddress field of the Powershell output.  The value that needs to be obtained is the DeviceID.  In our example, the DeviceID is: 10 (shown below)

Now that the proper DeviceID has been obtained, open regedit and browse to the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}

Underneath the above key, there are numbers listed for each interface on the system.  Click on the number that matches the previously obtained DeviceID.

Add the following new DWORD Key:

*NdisDeviceType (be sure to include the * at the begininng)

Then edit the newly created key *NdisDeviceType and set the value to 1

Close regedit and reboot the machine.

After the machine comes back up, the adapter will no longer appear in the Network and Sharing Center. However, if you click the Adapter settings link which lists all the network connections, you will see the interface.  Only this time, there will be no mention of an Identified network!

Let’s get started:

An insurance company in TN named qwikPolicy has decided to open their doors for business and has secured the services to design a network for their business. They have provided a business plan that includes where and how the business will be operated.

Below are key points of information needed for designing the network.

• qwikPolicy will operate in all 95 counties in Tennessee, with a physical office located in each county.
• Three of the county offices will function as a claims center with one in east, middle, and west Tennessee.
• Each county office will average 5 employees, except for the offices that also have a claims center.
• The claims center offices will have an average of 30 employees each and another 10 employees each serving as claims agents, who will all work out of home based offices.
• The company will provide services via the internet for consumers to create quotes, report claims, and to communicate with insurance agents.
• The Engineer is responsible for designing all networking and phone needs.
• Data Center space will be allocated in Nashville and Knoxville
• The I.T. Infrastructure budget has been pre-allocated and is set at $1,000,000.00

The internal services needed for day to day operations are:

• File and Print Services.  Centralized shared directories are needed for different working groups and each person will have a home directory that will provide storage space for automated user profile backups.
• The main suite of insurance applications are web based and will be accessed internally using a browser.
• Email will be provided using a standard email client
• Internet access from each workstation

In the next article we will start laying out the WAN and the two data center areas.

WAN

After reviewing multiple telecom provider offerings, the determination is made to enter into an agreement with bellX. bellX will provide a private MPLS cloud for the wide area network requirements. Ninety two offices will have T1 access into the bellX MPLS cloud with a 512kb port speed. Memphis, which is the only claims combination office without datacenter space, will have a full 1.5mb port speed. The other two combination office/datacenters will have T3 access, with the full 45mb port speed.

With a decision made on how the offices will be connected together, now we can start working on the overall design. Here are a few points that need to be considered during the design phase.

• Redundant internet connections
• Redundant wide area connectivity between the two datacenters
• Centralized phone system, so there is minimal phone infrastructure to manage in each office
• Redundancy in the Phone Switch & Call Center infrastructure
• Redundant internet DMZ for highly available public web sites

The first thing needed is to sketch out a high level design drawing. Visio can be used to quickly sketch out a high level drawing. It can also be used later to expand a high level drawing into a detailed design drawing.  The following is a high level diagram of the datacenter networking:

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

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.

Configure netflow exports on an IOS device to be received by a netflow collector for data analysis.

Solution:

!
! Cisco Express Forwarding has to be enabled on most newer platforms
!
ip cef
!
! Configure where to send the netflow exports
!
ip flow-export destination hostaddress 2055
!
! Configure which interface that will send the netflow data
!
ip flow-export source interface_name
!
! Configure the version of netflow exports to send
!
ip flow-export version 9
!
! Enable netflow on all interfaces of the router
!
interface int_name int_slot/int_number
ip route-cache flow
!
! Keeps the interface names/indexes the same across reboots
! This needs to be done in order for the netflow data to remain
! accurate across device reboots
!
snmp-server ifindex persist

Most backup schedules run jobs during ‘off hours’, when the servers are not as busy. This is good for the network also, since you don’t want to interfere with the traffic generated from doing business during peak usage times. However, there really is never a time the network availability is not important. Nor is there a time when it’s ok for the network to be degraded. So, even during non peak times, we don’t want to interfere with what I’ll call primary traffic. Here are steps to take in order to ensure the different traffic types don’t affect one another.

The goal here is to separate the system backup traffic from everything else. Starting with the host:

Use a dedicated network interface for system backup use. This NIC will be assigned an IP address from a subnet dedicated just for this use. This interface will not have an associated default gateway. Generally speaking, a system should always have only one default gateway, which is associated with the primary interface. In regards to routing system backup traffic (if required), that will be addressed later in this article.

Regarding the network design, ask a couple of questions first before getting started with the design:

1. Do I have dedicated network hardware to run the backup network?
2. Do I have multiple sites that need to talk back to a ‘centralized’ backup device?

Dedicated hardware in most cases would be unlikely. However, if you have a single site that had the cabling available and the budget to buy dedicated switch hardware – this is the way to go. The rest of this article will continue down the path of logical separation, in which vlan(s) will be created to run just the backup traffic.

First create a vlan id that will be assigned to this logical network. Assuming the network has the ability to configure private vlans, use this technology to protect ‘backdoor’ access from one host to another via the system backup interfaces. This article explains how to setup private vlans or even an alternative solution if you have older Cisco switch hardware.

Once you have layer2 isolation using one of the protected port/private vlan methods, the next step is to determine if this traffic will need to be routed. If you have only one building or physical network, chances are no layer3 interface will be needed and it will just remain a flat, non-routed network

If you have mutliple networks seperated by a wan and the ‘master’ backup server is at a central location, then at least some portion of that network will need to be routable. Typically in an enterprise backup environment you have two types of servers that make up the solution. One type is the ‘Master’ server and the others are ‘Media’ servers. The media servers are what is directly attached to the stoarage media and does the backup over the network from each host. The master server talks to the media servers to send them backup schedules, synchronize catalogs, submit jobs, etc. So, the traffic from the Master to Media servers are minimal, with the bulk of the network utilization being between a system being backed up and a local media server.

Most of the time, the systems being backed up will have no reason to talk to any centralized master servers, which means no routing will ever take place between the dual-homed systems being backed up. However, if there is a need like a centralized media server backing up manageable amounts of data over the wan, you want to use static, persistent routes in the hosts being backed up. By doing this, you tell the systems to only use a gateway on the system backup network to talk to a very specific destination.

Regarding the layer3 security needed for the backup network, use extended access-lists on traditional routers or vlan access-lists on layer3 switches that support it. The access-list should be placed on every system backup layer3 interface in your network. The access list will basically only allow the backup networks to talk to each other – denying everything else. This will ensure an unauthorized host on the system backup network can’t reach primary networks used to carry other traffic.

One of the most important things to be on the lookout for is port speed/duplex mismatches. This one area will be the source of your pain the majority of the time when the backup administrators complain about backup throughput.

There are some other tweaks that can be done once your system backup network is up and running. Jumbo Frame support would be one of my first recommendations. You can squeeze another 20% increase in backup and restore speeds on just this modification alone. However, be sure to plan this out carefully if you intend to implement jumbo frames – the network must support this end to end or traffic could wind up being dropped.

Best wishes in your pursuits of building backup network architecture!

• Get to use the familiar IOS used at work on your home network as well
• These routers are still more powerful than many of the new SOHO routers of today
• Can run modern IOS (12.3) with an easy flash/ram upgrade – allowing you to use many newer features.
• Can be purchased very cheaply – I’ve found them on Ebay for as little as $25.

This article focuses specifically on the Cisco 1605 router, because it has two Ethernet ports. One of the ports will be connected to the cable/dsl modem and the other to an internal switch. The 1605 router uses flash on a PCMCIA card. A 16mb card is all that is needed to hold the image and there is still room for crashdump and configuration file saves. The DRAM can be upgraded by placing a 32Mb chip in the single slot of these routers. I was able to upgrade my 1605 with a SIMM from a 2500 router (same memory).

Here is a show version of the 1605:

(Note: Although 12.3 is available for this device – I am running a 12.2 image to get the feature set needed with the amount of memory I have – only 16mb).

Router#sh ver
Cisco Internetwork Operating System Software
IOS (tm) 1600 Software (C1600-NOSY-M), Version 12.2(46a), RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2007 by cisco Systems, Inc.
Compiled Wed 11-Jul-07 19:12 by pwade
Image text-base: 0x02005000, data-base: 0x0293B3CC

ROM: System Bootstrap, Version 11.1(12)XA, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)
ROM: 1600 Software (C1600-RBOOT-R), Version 11.1(12)XA, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)

Router uptime is 1 day, 6 hours, 26 minutes
System returned to ROM by power-on
System restarted at 13:50:23 CST Sat Nov 17 2007
System image file is "flash:c1600-nosy-mz.122-46a.bin"

cisco 1605 (68360) processor (revision C) with 15470K/914K bytes of memory.
Processor board ID 14431821, with hardware revision 00000000
Bridging software.
X.25 software, Version 3.0.0.
2 Ethernet/IEEE 802.3 interface(s)
System/IO memory with parity enabled 16384K bytes of DRAM on SIMM  (On Board Memory disabled)
System running from RAM
7K bytes of non-volatile configuration memory.
16384K bytes of processor board PCMCIA flash (Read/Write)

Configuration register is 0x2102

The following is a working configuration that can be used in a home network environment:

version 12.2
service timestamps debug datetime localtime
service timestamps log datetime localtime
service password-encryption
!
hostname Router
!
aaa new-model
aaa authentication login default local
enable secret <secretpassword>
!
username admin password <adminpw>
clock timezone CST -6
ip subnet-zero
ip domain-name xpresslearn.int
!
ip dhcp pool home_lan
   network 192.168.200.0 255.255.255.0
   default-router 192.168.200.1
   dns-server <isp-dns-ip-1> isp-dns-ip-2>
!
!
!
!
interface Ethernet0
 description Attached to Cable Modem
 ip address dhcp
 ip nat outside
!
interface Ethernet1
 description Internal Network Default Gateway
 ip address 192.168.200.1 255.255.255.0
 ip nat inside
!
ip nat inside source list 100 interface Ethernet0 overload
ip classless
no ip http server
!
access-list 1 remark Allowed telnet management sources
access-list 1 permit 192.168.200.0 0.0.0.255 log
access-list 1 deny   any log
access-list 100 remark Inside Source addresses for NAT Translation
access-list 100 deny   ip any host 192.168.200.1
access-list 100 permit ip 192.168.200.0 0.0.0.255 any
!
line con 0
line vty 0 4
 access-class 1 in
!
ntp clock-period 17042421
ntp server 198.38.16.2
end

This configuration does the following:

•  Enables AAA and sets the default authentication method to using the local defined username/password
• DHCP Server configured for assigning IP addresses to internal clients that are directly connected to the inside interface of the router
• Set’s the outside interface (connected to a cable modem) to DHCP
• Set’s the internal interface (connected to home switch) to 192.168.200.1
• Configures Port Addresses Translation (PAT) to nat the internal addresses behind the dynamically assigned Public IP assigned to the public interface
• Secures the router, so that only trusted IP source networks can telnet to the device
• Configured an ntp server (pool.ntp.org), so that the correct time can be kept up with on the router for logging purposes, etc…