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.

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

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.

I have one USB thumb drive that is used strictly for Cisco gear.  First I started with a 256Mb freebie that come from a vendor and inserted it into a 2811 router that was up and running.  The flash was then formatted from the router to insure there would be no issues with the filesystem when using it in future Cisco devices.

Router#format usbflash1:
Format operation may take a while. Continue? [confirm]
Format operation will destroy all data in "usbflash1:".  Continue? [confirm]
Format: Drive communication & 1st Sector Write OK...

Format: All system sectors written. OK...

Format: Total data sectors in formatted partition: 511435
Format: Total data bytes in formatted partition: 261854720
Format: Operation completed successfully.

Format of usbflash1 complete
Router#

Next the thumb drive was inserted into the pc and the IOS image copied to it.  In this scenario, a Catalyst 3560 switch is being upgraded which is connected directly to a 2811 router that will serve as the tftp server.

The router’s FastEthernet0/0 interface is connected to the switch, which is in the same vlan as the management interface (Vlan1) of the switch.

Router#show ip int brief | exc unassigned
Interface               IP-Address      OK? Method  Status     Protocol
FastEthernet0/0         10.1.2.1        YES manual  up         up
Serial0/0/0             192.168.40.214  YES manual  down       down
Loopback1               10.254.1.18     YES manual  up         up
Router#

Connectivity to the access switch is then verified using ping:

Router#ping 10.1.2.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.2.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Router#

The thumb drive is then put back in the router and the contents of the usb drive is verified.

Router#dir usbflash1:
Directory of usbflash1:/

    1  -rw-     8811199  Sep 04 2008 10:18:38 +00:00  c3560-ipbasek9-mz.122-46.SE.bin

261853184 bytes total (252272640 bytes free)
Router#

Next, configure the tftp server on the router:

Router(config)#tftp-server usbflash1:c3560-ipbasek9-mz.122-46.SE.bin

From the switch console, we should now be able to perform an IOS upgrade using the connected router as the tftp source:

Switch#copy tftp://10.1.2.1/c3560-ipbasek9-mz.122-46.SE.bin flash:
Destination filename [c3560-ipbasek9-mz.122-46.SE.bin]?
Accessing tftp://10.1.2.1/c3560-ipbasek9-mz.122-46.SE.bin...
Loading c3560-ipbasek9-mz.122-46.SE.bin from 10.1.2.1 (via Vlan1): !!!!!!!!!!!!!!!<truncated>
[OK - 8811199 bytes]

8811199 bytes copied in 151.591 secs (58125 bytes/sec)
Switch#

Using the router as a tftp server along with the removable storage proves to be a convenient method for upgrading other IOS devices in situations where a spare pc is not readily available. Don’t forget to clean up the router after your finished by removing the tftp-server command.

Etherchannel has not been used nearly as much for such requirements as redundancy, because there is a limitation on all the interfaces that belongs to an etherchannel group, each interface has to be plugged into the same switch. The stackable 3750 switches have allowed a little more redundant ability, in the sense that you can have two switches stacked via the stackwise ports in the back of the switch, which basically extends the backplane. By doing this, you are allowed to have an Etherchannel interface plugged into two different switches (as long as they are stacked). Let’s take a look at an example diagram for clarification:

Let’s take a look at the router configuration to accomplish the task of adding bandwidth.

interface Port-channel1
ip address 192.168.50.1 255.255.255.0
!
interface FastEthernet0/0
duplex full
speed 100
channel-group 1
!
interface FastEthernet0/1
duplex full
speed 100
channel-group 1

Next, the switch configuration:

interface Port-Channel1
switchport
switchport access vlan 10
switchport mode access
!
interface FastEthernet0/1
switchport
switchport access vlan 10
switchport mode access
channel-group 1 mode on
!
interface FastEthernet0/2
switchport
switchport access vlan 10
switchport mode access
channel-group 1 mode on

This example is configured for etherchannel without also being configured as a trunk (which means the aggregated interfaces are in access mode).

Another common configuration that goes along with etherchannel interfaces is Vlan Trunking. The term ‘trunking’ is often misused when referring to etherchannel use. When discussing a trunk, the meaning is an interface that carries multiple vlans across it. The terms trunking and etherchannel do not automatically go with each other.

The following example shows the same Etherchannel configuration as above, only this time the interfaces will also be configured as trunks in order to carry multiple vlans across the link(in this example – vlan 2,3,4,5,6, and 999).

First, the router configuration:

interface Port-channel1
 no ip address
!
interface Port-channel1.2
 encapsulation dot1Q 2
 ip address 192.168.2.1 255.255.255.0
!
interface Port-channel1.3
 encapsulation dot1Q 3
 ip address 192.168.3.1 255.255.255.0
!
interface Port-channel1.4
 encapsulation dot1Q 4
 ip address 192.168.4.1 255.255.255.0
!
interface Port-channel1.5
 encapsulation dot1Q 5
 ip address 192.168.5.1 255.255.255.0
!
interface Port-channel1.6
 encapsulation dot1Q 6
 ip address 192.168.6.1 255.255.255.0
!
interface Port-channel1.999
 encapsulation dot1Q 999 native
!
interface FastEthernet0/0
duplex full
speed 100
channel-group 1
!
interface FastEthernet0/1
duplex full
speed 100
channel-group 1

Here is the switch configuration:

interface Port-Channel1
switchport
switchport trunk allowed vlan 2,3,4,5,6,999
switchport mode trunk
!
interface FastEthernet0/1
switchport
switchport trunk allowed vlan 2,3,4,5,6,999
switchport mode trunk
channel-group 1 mode on
!
interface FastEthernet0/2
switchport
switchport trunk allowed vlan 2,3,4,5,6,999
switchport mode trunk
channel-group 1 mode on

The answer to that question depends on this secondary question: Will DHCP services be performed on a traditional server running DHCP or does it need to be handled solely by the network?

If the answer to the second question is: There will be a traditional server running DHCP (such as Windows DHCP services or the dhcpd demon on Unix), then the IOS router will be configured as a DHCP relay device.

If the answer to the second question is: DHCP needs to be handled completely by the network , then the IOS router will be configured as a DHCP server.

In either option, both require the following global configuration command (on by default):

Router(config)# service dhcp

Configuring DHCP relay:

The DHCP relay agent is configured on each Layer 3 interface that needs DHCP services.

Router(config)# int FastEthernet 0/0
Router(config-if)# ip address 192.168.1.1 255.255.255.0
Router(config-if)# ip helper-address  x.x.x.x

Where x.x.x.x is the DHCP Server. In this scenario, there isn’t a DHCP server on the 192.168.1.0/24 subnet – so the clients on this network have to get their dynamically assigned IP from a server somewhere else on the network. When the router receives a UDP broadcast (port 67), it examines the gateway IP address field (giaddr) in the DHCP message header. If the value of this field is 0.0.0.0, the DHCP agent replaces the all zero’s entry with the IP address of the interface on which the DHCP message arrived. In this example, the giaddr would be replaced with 192.168.1.1 and then forwarded to the DHCP server IP address that is defined in the helper-address statement on that interface.

When the DHCP server receives the DHCP request, it examines the value in the Gateway IP Address field to determine if the packet was relayed. Once it is determined that the packet was forwarded, it looks at the configured DHCP scopes for the network that would encompass the Gateway IP Address in the packet. If a match is found, an address is proposed out of the pool range for that scope and sent back to the relay agent for forwarding back to the original requesting client.

Configuring DHCP Server Service:

To configure the IOS device to act as a DHCP Server, first start by configuring a pool and assign it a name.

Router(config)# ip dhcp pool SubnetX

Where SubnetX is a meaningful name that describes the network pool. Next assign the network for this pool to handle, which in this example is 192.168.1.0/24.

Router(dhcp-config)#network 192.168.1.0 255.255.255.0

This tells the DHCP service that pool SubnetX is to be used for servicing requests on the 192.168.1.0 network. By default, the DHCP service will attempt to assign any address in the network. If you want to reserve the first twenty addresses, so that the first client will start for .21 – configure the following in global configuration mode:

Router(config)#ip dhcp excluded-address 192.168.1.1 192.168.1.20

Other standard DHCP options to configure:

DNS Servers for the client to use for name resolution:

Router(dhcp-config)#dns-server 10.1.1.100 10.2.1.100

Default Gateway for clients to use on this subnet:

Router(dhcp-config)#default-router 192.168.1.1

Domain Name the client will be assigned:

Router(dhcp-config)#domain-name xpresslearn.com

Here is what the minimal DHCP Server configuration now looks like:

ip dhcp excluded-address 192.168.1.1 192.168.1.20
!
ip dhcp pool SubnetX
network 192.168.1.0 255.255.255.0
dns-server 10.1.1.100 10.2.1.100
domain-name xpresslearn.com
default-router 192.168.1.1

Some additional options available that can be very useful :

Configure lease times

Router(dhcp-config)#lease 5

Wins Server assignment

Router(dhcp-config)#netbios-name-server 10.1.1.100 10.2.1.100

Configure DHCP database location on a physical storage medium, this prevents the router from loosing all of it’s lease data after a reboot. By default, the router maintains the dhcp bindings in NVRAM.

Router(config)#ip dhcp database flash:router-dhcp write-delay 60 timeout 10

The security used by rsh is considered to be basically non-existent for the following reasons:

• No passwords are used, only usernames
• The username and IP address of a system running the rsh command can easily be duplicated/spoofed in order to gain access to a remote system running the rsh server
• There is no encryption used between the rsh client and server

The following example shows running a couple of remote commands:

The authentication process between the rsh client and server explained:

The rsh server has a local username, remote username, and an allowed IP source address of every connection allowed to it.

• Local username means the name local to the RSH server.It isn’t defined on a Cisco router in the sense of a traditional local username/password entry. It’s basically just a random word that could be considered as a ‘shared secret’ between the server and client. What is defined here has to match was it being used with the –l option in the rsh client.
• The remote username is the name of the logged in user running the rsh client. This username is taken from the currently logged in user that is running the RSH command. If being run as a process, it uses the defined user that is setup to run the command. You can’t manipulate this in the rsh client, it automatically uses the username from the Operating System. In Windows the rsh command just uses the user name with no <domain>\ or <computername>\ prefix.
• The IP source IP address is the address of the machine running the RSH client.

As you can see from the previous explanation, all the information that is really needed to execute commands on a remote rsh server is the local username and which remote usernames and IP’s the server allows. The last two items as previously mentioned, can easily be duplicated from an normally unauthorized computer.

Here is the output from the debug command – debug ip tcp rcmd:

An unsuccessful attempt

%RCMD: [514 <- 10.1.100.20:1023] recv 1022\0
%RCMD: [514 <- 10.1.100.20:1023] recv Administrator\0Administrator\0show run\0
%RCMD: [514 <- 10.1.100.20:1023] recv -- Administrator 10.1.100.20 Administrator not in
trusted hosts database
%RCMD: [514 -> 10.1.100.20:1023] send <BAD,Permission denied.>\n

In the above attempt, there is not a local user called Administrator on the router, thus the request is denied.

A successful attempt

%RCMD: [514 <- 10.1.100.20:1023] recv 1022\0
%RCMD: [514 <- 10.1.100.20:1023] recv Administrator\0Router\0show run\0
%RCMD: [514 -> 10.1.100.20:1023] send <OK>

Steps for configuring a Cisco device to support RSH:

Router(config)#ip rcmd remote-host Router 10.1.100.20 Administrator enable
Router(config)#ip rcmd rsh-enable
Router(config)#no ip rcmd domain-lookup

The previous configuration example allows a host with the IP address of 10.1.100.20 that is logged into the Operating System as the user Administrator to run commands on the device using rsh. Notice the use of the no ip rcmd domain-lookup command. Without this, the router will attempt to do a reverse lookup on the incoming source IP address and will fail if the reverse dns entry does not exist, so in our example scenario, we turn off this behavior. If we had left it on in our test environment the rsh execution would have failed with the following debug output:

%RCMD-4-RCMDDNSFAIL: DNS hostname/ip address mismatch.  10.1.100.20 unknown to DNS

If you need to allow a single user to come from multiple source IP addresses, use an access list in the rcmd configuration as shown in the following example.

Router(config)#access-list 1 remark Source IP addresses allowed to use RCMD
Router(config)#access-list 1 permit 10.1.100.20
Router(config)#access-list 1 permit 192.168.100.20
Router(config)#ip rcmd remote-host Router 1 Administrator enable
Router(config)#ip rcmd rsh-enable

RSH is currently used between Cisco products to serve certain functions. CiscoWorks, which is a Network Management System, uses rsh to run certain processes on Cisco devices that it manages. Also, various Cisco VoIP platforms use rsh to execute commands on routers as needed.

In my opinion, if this type of access could be used in your network, consider only allowing a secured, centrally located computer the ability to execute rsh commands on your network devices. By having a physically and logically secure station that is allowed to run rsh, you stand less of a risk of someone being able to steal it’s identity for replication on an unauthorized computer.

- Message of the day (MOTD)
- Login
- exec
- incoming
- slip-ppp

Let’s take a look at each of these in a little more detail to determine their purposes.

MOTD

This MOD banner is displayed on terminal lines at the time of login. This message will appear before the user/password prompt. To configure a message of the day:

Router(config)#banner motd ^
Enter TEXT message.  End with the character '^'.
This is a wise message of the day

^
Router(config)#

When you telnet to the device, this is what appears:

This is a wise message of the day

User Access Verification

Username:

Login

The login banner is displayed on terminal lines at login. This message will appear after the MOTD (if configured) and before the login prompts. To configure a login banner:

Router(config)#banner login ^
Enter TEXT message.  End with the character '^'.

Only authorized people may login to this router

^
Router(config)#

Below is what a telnet session looks like when both a MOTD and a login banner is configured:

This is a wise message of the day

Only authorized people may login to this router

User Access Verification

Username:

You might wonder when would you configure both a motd and a login banner. A login banner can be used to display a more ‘permanent’ message, that doesn’t get changed often – such as a disclaimer, security message, etc. The motd may be configured with only a temporary message, such as a message stating when the next maintenance will occur, etc…

EXEC

The exec banner when configured, will display when an EXEC process is initiated. For example, the exec process is started after a successful login via telnet. The message will display after successfully going through the username/password prompts and before the router/switch prompt is displayed. To configure an EXEC banner:

Router(config)#banner exec ^
Enter TEXT message.  End with the character '^'.

Make sure you know what you are doing before changing anything!

^
Router(config)#end
Router#

A telnet session with all three previous examples configured looks like:

This is a wise message of the day

Only authorized people may login to this router

User Access Verification

Username: admin
Password:

Make sure you know what you are doing before changing anything!

Router>

Incoming

You can configure a banner to be displayed on terminals connected to reverse Telnet lines. This banner is useful for providing instructions to users of these types of connections. An incoming banner is configured like:

Router(config)#banner incoming ^
Enter TEXT message.  End with the character '^'.
This is reverse telnet session A
^
Router(config)#

SLIP-PPP

This banner is used to display a message to standard PPP and SLIP dial up software. To configure a slip-ppp message:

Router(config)#banner slip-ppp ^
Enter TEXT message.  End with the character '^'.
Unauthorized access to this system is prohibited
^
Router(config)#

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!

If the mac-address of a the device is known, then skip this first step of determining the mac-address from the IP address.

From the layer 3 device directly connected to the subnet containing the device to be found, ping the IP address of the host. From a cisco device the process will look like the following:

bna-lan-01#ping 10.120.2.100

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.120.2.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

It’s always a good idea to ping the device first. Otherwise, if there has been no recent communication to/from the device trying to be located, it will not appear in the arp table. Therefore, ping the device to ensure the mac address will be in the arp table. To locate the device, issue a show arp command with a pipe that includes the IP address of the host.

bna-lan-01#sh arp | inc 10.120.2.100
Internet  10.120.2.100            0   000d.23e4.1f20  ARPA   Vlan2
bna-lan-01#

The output of the show arp command will include the mac address along with what vlan the device resides in.. Now that the mac address of the host has been obtained, next issue the show mac-address command on the switch at the core of your network: In this example, the layer 3 device and the core switch is the same Cisco 6500 switch, with the name bna-lan-01.

bna-lan-01#sh mac-address-table address 000d.23e4.1f20
Legend: * - primary entry
        age - seconds since last seen
        n/a - not available

  vlan   mac address     type    learn     age              ports
------+----------------+--------+-----+----------+--------------------------
Supervisor:
*  2     000d.23e4.1f20  dynamic  Yes      80               Gi1/8

After issuing the show mac-address command, we see that the mac address was learned via Gigabit 1/8. From here, let’s assume the network is an all Cisco network and CDP is still running on the uplink ports. The next bit of information needed is what is connected on the other end of Gig1/8. Let’s do a show cdp nei to obtain that information:

bna-lan-01#sh cdp nei detail Gi1/8
-------------------------
Device ID: bna-asw-01
Entry address(es):
  IP address: 10.1.0.21
Platform: cisco WS-C3750-48TS,  Capabilities: Router Switch IGMP
Interface: GigabitEthernet1/8,  Port ID (outgoing port): GigabitEthernet1/0/49
Holdtime : 124 sec

Version :
Cisco Internetwork Operating System Software
IOS (tm) C3750 Software (C3750-I9-M), Version 12.1(19)EA1d, RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2004 by cisco Systems, Inc.
Compiled Mon 05-Apr-04 22:40 by antonino

advertisement version: 2
Protocol Hello:  OUI=0x00000C, Protocol ID=0x0112; payload len=27, value=0FF0000
VTP Management Domain: 'BNA-NET'
Native VLAN: 257
Duplex: full

The downstream access switch is a 3750 with a management IP address of 10.1.0.21. The next step is to access this switch and issue the show mac address command on it.

bna-asw-01#sh mac-address-table address 000d.23e4.1f20
          Mac Address Table
-------------------------------------------

Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
 2      000d.23e4.1f20    DYNAMIC     Gi1/0/4

The output shows the host connected to the port Gigabit 1/0/4. If there had been another switch in between bna-asw-01 and the host, we would just do the same thing as previously – which is issue the show cdp neighbor command and find the management IP of the next access switch.