The first place to start is with the service commands

service password-encryption

Explanation:

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

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

Explanation:

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

no service pad

Explanation:

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

service tcp-keepalives-in

Explanation:

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

no service finger

Explanation:

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

no boot network
no service config

Explanation:

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

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

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

Explanation:

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

no ip bootp server

Explanation:

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

no ip source-route

Explanation:

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

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

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

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

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

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

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

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

Cisco tacacs+ server for Windows

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

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

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

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

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

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

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

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

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

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

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

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

Specify the use of irb:

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

GW-VG224-01(config)#bridge irb

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

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

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

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

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

Lastly, take the physical interfaces out of shutdown mode:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Verifying installation compatibility

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

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

Writing installation meta-data.  Please wait ...

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

[DONE]

6500switch#

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

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

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

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

A look at the running configuration shows the following:

6500switch#show run

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

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

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

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

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

The last thing to do is reload the switch:

6500switch#reload
Proceed with reload? [confirm]

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

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

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

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

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

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

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

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

6500switch#show install running

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

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

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

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

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

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

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

6500switch#

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

Anyone who has worked around any network device knows about putty.  It is one of the greatest gifts given to a network/system administrator.  One of the biggest reasons behind the popularity of this program is the cost, which is *free*…  Add tons and tons of functionality on top of that and you have yourself a winner for one of the greatest proggies of all times!  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 convinient 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.

Router Platform(s): 7200, 3600
IOS Version: 12.4(11)T1, 12.4(18)
IOS Feature Set: Service Provider, Enterprise
IOS File Name: c7200-spservicesk9-mz.124-11.T1.bin, c3640-js-mz.124-18.uncompressed.bin
idlepc: 0×61280c1c, 0×60428c4c
IOS Image Uncompressed before use: Yes , Yes
IOS Memory Requirements: 256Mb, 128Mb
Average Dynamips.exe CPU Utilization: 30%

Comments:

The configuration in this article contains two devices, one 7200 serving as the router and one 3600 used as a network switch.  The point of this lab is to demonstrate the use of Etherchannel and also Vlan Trunking in an Etherchannel configuration (2 separate scenarios).  There are two .net configuration files included.  One file contains the 7200 setup with etherchannel and the 3640 acting as the switch has the etherchannel interfaces in access mode (assigned to vlan 10).  The other .net file is basically the same scenario, with Vlan Trunking added.

Other Notes:

You will need to create vlan 10 on the 3640 after it boots.  You can do this by getting to an enable prompt and typing:

vlan database
vlan 10
exit

Failure to do this will prevent you from pinging the layer3 interface configured on the 3640 from the 7200 router.

Link to configuration files:

Dynagen GNS3 configuration files

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 solution in this scenario is to use something called policy based routing:

Policy-based routing provides a tool for forwarding and routing data packets based on policies defined by network administrators. In effect, it is a way to have the policy override routing protocol decisions. Policy-based routing includes a mechanism for selectively applying policies based on access list, packet size or other criteria. The actions taken can include routing  packets on user-defined routes, setting the precedence, type of service bits, etc.

Consider the following diagram:

Host 1 and 2 both have a default gatway of the defaultRouter, which has the address of 192.168.1.1.  The default route/next hop address in defaultRouter for all traffic is 192.168.2.1, which is named LanRouter.  When Host1 pings Host3 the full path looks like:

Host1 –> defaultRouter –> LanRouter –> Host3

Host1#traceroute 192.168.3.100

Type escape sequence to abort.
Tracing the route to 192.168.3.100

  1 192.168.1.1 152 msec 168 msec 144 msec
  2 192.168.2.1 288 msec 256 msec 172 msec
  3 192.168.3.100 264 msec 260 msec 255 msec
Host1#

Let’s say we want Host1 to take an alternate path in the network, but leave Host2 alone and allow it to continue through the original route.  A policy route will be configured on defaultRouter to look for the source address of Host1 and re-route that traffic over altLanRouter.  Any traffic sourced from Host2 will remain going through the original path via LanRouter.

First thing to configure is the access list that will be used to match the desired source address.

defaultRouter(config)#ip access-list extended hosts-to-redirect
defaultRouter(config-ext-nacl)#permit ip ?
A.B.C.D  Source address
any      Any source host
host     A single source host

defaultRouter(config-ext-nacl)#permit ip 192.168.1.100 ?
A.B.C.D  Source wildcard bits

defaultRouter(config-ext-nacl)#permit ip 192.168.1.100 0.0.0.0 ?
A.B.C.D  Destination address
any      Any destination host
host     A single destination host

defaultRouter(config-ext-nacl)#permit ip 192.168.1.100 0.0.0.0 any

Next, create the route map and configure what to use for matching traffic, which is the access list that was previously created.  Also, configure what action to take on the traffic that is matched.

defaultRouter(config-route-map)#match ip address ?
  <1-199>      IP access-list number
  <1300-2699>  IP access-list number (expanded range)
  WORD         IP access-list name
  prefix-list  Match entries of prefix-lists

defaultRouter(config-route-map)#match ip address hosts-to-redirect
defaultRouter(config-route-map)#set ?
  as-path           Prepend string for a BGP AS-path attribute
  automatic-tag     Automatically compute TAG value
  clns              OSI summary address
  comm-list         set BGP community list (for deletion)
  community         BGP community attribute
  dampening         Set BGP route flap dampening parameters
  default           Set default information
  extcommunity      BGP extended community attribute
  interface         Output interface
  ip                IP specific information
  ipv6              IPv6 specific information
  level             Where to import route
  local-preference  BGP local preference path attribute
  metric            Metric value for destination routing protocol
  metric-type       Type of metric for destination routing protocol
  mpls-label        Set MPLS label for prefix
  nlri              BGP NLRI type
  origin            BGP origin code
  tag               Tag value for destination routing protocol
  traffic-index     BGP traffic classification number for accounting
  vrf               Define VRF name
  weight            BGP weight for routing table
defaultRouter(config-route-map)#set ip ?
  address     Specify IP address
  default     Set default information
  df          Set DF bit
  next-hop    Next hop address
  precedence  Set precedence field
  qos-group   Set QOS Group ID
  tos         Set type of service field
defaultRouter(config-route-map)#set ip next-hop 192.168.2.2

Once the route map is configured the only thing left is to apply it to the interface where the traffic comes into the router, which is FastEthernet1/0.

defaultRouter(config)#int fa1/0
defaultRouter(config-if)#ip policy ?
  route-map  Policy route map

defaultRouter(config-if)#ip policy route-map ?
  WORD  Route map name

defaultRouter(config-if)#ip policy route-map altRouterRedirect

Now let’s take a look at the path Host1 takes to connect to Host3:

Host1#traceroute 192.168.3.100

Type escape sequence to abort.
Tracing the route to 192.168.3.100

  1 192.168.1.1 112 msec 168 msec 72 msec
  2 192.168.2.2 192 msec 312 msec 336 msec
  3 192.168.3.100 288 msec 288 msec 288 msec
Host1#

Now, verify that host 2 still takes the original path via LanRouter:

Host2#traceroute 192.168.3.100

Type escape sequence to abort.
Tracing the route to 192.168.3.100

  1 192.168.1.1 140 msec 144 msec 144 msec
  2 192.168.2.1 192 msec 212 msec 172 msec
  3 192.168.3.100 432 msec 384 msec 360 msec
Host2#

This configuration has successfully changed the path in the network of Host 1 and left the traffic sourced from Host 2 untouched. Keep in mind that the reply traffic from R3 is going back across defaultRouter in both scenarios, this is because Host3 has a default gateway of 192.168.3.1, which is assigned to defaultRouter. If we wanted the reply traffic from Host 3 destined to host 1 sent via altLanRouter, a policy map would need to be applied to match the destination ip address of Host 1.