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

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

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

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

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

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

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

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

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

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

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

Gateway of last resort is not set

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

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

Gateway of last resort is not set

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

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

Gateway of last resort is not set

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

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

Gateway of last resort is not set

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A little about the lab

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

CompanyX network scenario

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

CompanyX network diagram containing P devices

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

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

Here is the relevant configuration for each router:

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

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

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

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

GNS3 project for basic MPLS build

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Verifying installation compatibility

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

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

Writing installation meta-data.  Please wait ...

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

[DONE]

6500switch#

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

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

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

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

A look at the running configuration shows the following:

6500switch#show run

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

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

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

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

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

The last thing to do is reload the switch:

6500switch#reload
Proceed with reload? [confirm]

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

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

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

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

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

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

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

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

6500switch#show install running

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

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

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

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

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

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

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

6500switch#

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

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

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

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

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

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

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

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

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

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

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

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

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

Command line options for plink.exe

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

Text file to use with plink.exe

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

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

Running plink.exe in batch mode

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

Backup cisco configuration via plink.exe

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

Router backup using plink.exe

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

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 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 gateway 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.

Before you configure STP, select a switch to be the root of the spanning tree. This switch does not need to be the most powerful switch, but choose the most centralized switch on the network. All data flow across the network is from the perspective of this switch. Switches in the distribution layer often serve as the spanning tree root because these switches typically do not connect to end stations. Also, moves and changes within the network are less likely to affect these switches.

Let’s consider the following network diagram:

Vlan3 is defined on the network with SW1configured as the root bridge.

SW1#show spanning-tree root
VLAN3
  Root ID    Priority    8192
             Address     cc00.0cf4.0002
             This bridge is the root
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

The output of the previous show command reflects that it is the root bridge for Vlan3.  The mac-address shown is the address of the switch serving as the root bridge.  Using the mac address shown in the show spanning-tree root output, we can go searching for the root bridge of any vlan.

The priority was configured on SW1 in order for it to assume root bridge status for vlan 3.  The configuration command executed on SW1:

SW1(config)#spanning-tree vlan 3 priority 8192

SW2 is configured to assume the root bridge in the event SW1fails:

SW2(config)#spanning-tree vlan 3 priority 16384

Let’s say on SW3 we configure the following:

SW3(config)#spanning-tree vlan 3 priority 4096

Run the show spanning-tree root command again on SW1:

SW1#show spanning-tree root
VLAN3
  Root ID    Priority    4096
             Address     cc02.0cf4.0002
             Cost        12
             Port        321 (Port-channel1)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

The mac-address cc02.0cf4.0002 belongs to SW3, which has now become the root bridge for vlan3.  How do you prevent this from happening?

Using best practice configuration techniques, make sure SW3 and SW4 does not become the root bridge for any vlan.

SW3(config)#spanning-tree vlan 1-4094 priority 65535
SW4(config)#spanning-tree vlan 1-4094 priority 65535

Configure SW1 and SW2 as the primary and secondary root bridges for vlan 3

SW1(config)#spanning-tree vlan 3 priority 1
SW2(config)#spanning-tree vlan 3 priority 2

Remember to do this configuration for each vlan on the network, because in per vlan spanning-tree, there is a root bridge for each spanning-tree instance.