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…

The objective is to correlate vlan numbers with any given subnet. Typically, the vlan number matches the third octet of the subnet used inside the vlan. However, this only works out when using full class C subnet allocations. If subnetting is used to further shrink the network allocation size (ex. using a /25,/26,/27,/28 bit mask) – correlating an associated vlan number is a little harder. In order to resolve this, a calculation can be used to assign all vlan numbers.

Using the example above, to assign the associated vlan number, use the following formula:

(256*(Subnet – 1) + thirdOctet)

Where Subnet = the iteration being used

Explanation:

If a class C mask (/24) is used then Subnet is 1

If the mask is greater than 24, then start by calculating how many subnets can be contained inside the class C. Once the network is subnettted, use the subnet number of the network being used.

Exceptions:

If the thirdOctet is zero, then use 255 as the 3rd Octet number

The numbering plan assumes the second octet will always be the same. Since this particular scheme only calculates using the third octet, it would produce duplicate vlan numbers, For Example: 10.1.10.0 & 10.2.10.0 This wouldn’t be a problem if we were using the two subnets on two totally different local area networks (ex: different offices, etc.) because you can reuse vlan numbers that are on separate switch domains.

Example:

10.1.10.0 will be further sub-netted using a /28 mask. For this example, the table shows the number of subnets available. With using the /28 or 255.255.255.240 mask, there are 16 available subnets available.

If we were using the 10.1.10.0 network then Subnet = 1
If we were using the 10.1.10.32 network then Subnet = 3
If we were using the 10.1.10.240 network then Subnet = 16

Final VLAN numbers for the three examples above:

10.1.10.0 = Vlan 10
(256 * (1-1) + 10) = 10

10.1.10.32 = Vlan 522
(256 * (3-1) + 10) = 522

10.1.10.240 = Vlan 3850
(256 * (16-1) + 10) = 3850