Scenario Prerequisites

To successfully commence the configuration tasks required to complete this scenario, the following lists the prerequisite configuration tasks required on each device in the scenario topology:

Hostname each device should be configured with an appropriate hostname as per Figure 5-12.
Telnet/Enable password each device should be configured with an appropriate telnet and enable password.

This scenario assumes the configuration tasks listed above have already been implemented and hence does not include the configuration of these tasks.

Configuration Tasks

The configuration tasks for this scenario are essentially the same as for Scenario 5-1 because the basic goal of the scenario is the same (i.e., to enable routing for the network). The following lists the required configuration tasks:

Configuring Layer 2 parameters
Configuring inter-VLAN routing
Verifying connectivity

Configuring Layer 2 Parameters

Just as configuring an inter-VLAN routing architecture that uses a router-on-a-stick, for an integrated Layer 3 switching inter-VLAN routing architecture, you must configure Layer 2 parameters first. The only difference with the router-on-a-stick architecture is that the Layer 2 configuration is on a separate Layer 2 switch With the integrated Layer 3 switching architecture, you often find that you configure Layer 2 and Layer 3 attributes on the same switch device using the same management interface. The following lists the configuration tasks required to configure Layer 2 parameters for this scenario:

Configuring Layer 2 parameters on Switch-A
Configuring Layer 2 parameters on Switch-B

Configuring Layer 2 Parameters on Switch-A

When configuring VLANs on a L3 switch, you are controlling the way in which the switching engine of the L3 switch operates. When configuring VLANs on an integrated L3 switch such as the Catalyst 3550 (i.e., Switch-A in this scenario), you must create VLANs as you would on a Layer 2 switch. However, the way you configure VLAN port membership on the switch depends on whether or not the interface is configured as a Layer 3 (routed) interface or a Layer 2 interface. Understand that physical routed interfaces are not configured to belong to a specific VLAN because a routed interface connects directly to the routing engine (see Figure 5-15) and has no connection whatsoever to the switching engine, where VLANs are supported. The concept of a physical routed interface on an L3 switch is identical in concept to Ethernet interface on a normal Cisco routerCisco routers do not support the concept of VLANs and do not require an interface to be configured to a specific VLAN.

NOTE

As you saw in Scenario 5-1, some Cisco routers do support the concept of VLANs in relation to an Ethernet port being configured as an ISL or 802.1Q trunk. On integrated Cisco IOS L3 switches, such as the Catalyst 3550, you cannot configure a routed interface as a routed trunk interface. To support routing sent via a trunk, you must configure a Layer 2 trunk and then create SVI interfaces for each VLAN on the trunk that requires routing.

With relation to Layer 2 ports on an L3 switch, VLAN membership is configured as per a normal Layer 2 switch. The routing engine of the L3 switch can process traffic sent and received on Layer 2 ports via an SVI interface created for the VLAN the Layer 2 ports are configured to belong to.

Now that you understand the VLAN configuration considerations for both Layer 2 and Layer 3 interfaces on Switch-A, it is time to implement the required VLAN configuration. On Switch-A, the following VLAN configuration is required:

VTP must be configured so that VLANs can be created. In this scenario, both switches are configured to operate in VTP transparent mode, meaning VLANs must be manually created on each switch separately.
VLAN 2 must be created. VLAN 3 does not need to be configured on Switch-A because no devices in VLAN 3 are attached to Switch-A.
Interface fa0/2 must be configured as an 802.1Q trunk. To avoid VTP domain mismatches, the trunk should be configured with a DTP mode of on.

NOTE

For this scenario, interface fa0/2 doesn't actually need to be configured as a trunk because only traffic from VLAN 2 is being transported across it. In the real world, however, when connecting two switches, it is likely that the traffic from multiple VLANs will need to be transported across the interswitch link, requiring a trunk interface to be configured.

Example 5-15 shows the VLAN and trunking (i.e., Layer 2) configuration required on Switch-A.

Example 5-15. Configuring VLANs and Trunking on Switch-A

 Switch-A# configure terminal Switch-A(config)# vtp mode transparent Setting device to VTP TRANSPARENT mode. Switch-A(config)# vlan 2 Switch-A(config-vlan)# name VLAN02 Switch-A(config-vlan)# exit Switch-A(config)# interface FastEthernet 0/2 Switch-A(config-if)# switchport trunk encapsulation dot1q Switch-A(config-if)# switchport mode trunk

Notice in Example 5-15 that no configuration is performed on interface fa0/1. This is because interface fa0/1 is a routed interface and, therefore, does not require any Layer 2 configuration.

Configuring Layer 2 Parameters on Switch-B

Switch-B is a Catalyst 4006 switch with a L3 router module installed and is different from Switch-A in that the switching engine (Supervisor 2 engine) and the routing engine (L3 router module) have separate management interfaces. This means that the VLAN and other Layer 2 configuration required on Switch-B must be performed on the CatOS-based Supervisor engine. On Switch-B, the following VLAN and Layer 2 configuration is required:

VTP transparent mode must be configured.
VLAN 2 and VLAN 3 must be created. VLAN 2 is required for the trunk to Switch-A and for the connection to the L3 Router module, while VLAN 3 is required for the connection to Host-B and for the connection to the L3 Router module.
Port 2/3 must be configured as an 802.1Q trunk, with VLANs. To avoid VTP domain mismatches, the trunk should be configured with a Dynamic Trunking Protocol (DTP) mode of on.

Example 5-16 shows the VLAN and Layer 2 configuration required on Switch-B.

Example 5-16. Configuring VLANs on Switch-B

 Switch-B> (enable) set vtp mode transparent VTP domain  modified Switch-B> (enable) set vlan 2 name VLAN02 VTP advertisements transmitting temporarily stopped, and will resume after the command finishes. Vlan 2 configuration successful Switch-B> (enable) set vlan 3 name VLAN03 VTP advertisements transmitting temporarily stopped, and will resume after the command finishes. Vlan 3 configuration successful Switch-B> (enable) set vlan 3 name VLAN03 VTP advertisements transmitting temporarily stopped, and will resume after the command finishes. Vlan 3 configuration successful Switch-B> (enable) set trunk 2/3 on dot1q Port(s)  2/3 trunk mode set to on. Port(s)  2/3 trunk type set to dot1q.

After the configuration of Example 5-16 is complete, assuming Switch-A and Switch-B are connected, a trunk should form between Switch-A and Switch-B. Example 5-17 demonstrates verifying a trunk has formed by using the show trunk command on Switch-B.

Example 5-17. Verifying the Trunk Between Switch-A and Switch-B

 Switch-A> (enable) show trunk 2/3 Port      Mode         Encapsulation  Status        Native VLAN --------  -----------  -------------  ------------  -----------  2/3      on           dot1q          trunking      1

In Example 5-17, you can see by the shaded portion of the output that the trunk has successfully formed.

TIP

You can use the show cdp neighbors command on both switches to verify that each switch has Layer 2 connectivity with the other.

Configuring Inter-VLAN Routing

At this stage you have connected all devices as indicated in Figure 5-12 and enabled Layer 2 connectivity between Switch-A and Switch-B. In this section you enable the Layer 3 switching components of each switch, which ultimately allows Host-A to communicate with Host-B. On Switch-A, the inter-VLAN required routing configuration is performed using the same Cisco IOS management interface used to configure Layer 2 parameters earlier. On Switch-B, the inter-VLAN routing configuration required must be configured separately on the L3 router module, which has a separate Cisco IOS-based management interface from the CatOS management interface on Switch-B. The L3 router module on Switch-B is called Switch-B-L3, and in this section you learn how to configure the L3 router module.

The following lists the configuration tasks required to enable inter-VLAN routing for this scenario:

Configuring Switch-A for inter-VLAN routing
Configuring Switch-B for inter-VLAN routing

Configuring Switch-A for Inter-VLAN Routing

To enable L3 switching on Switch-A, you need to configure the interface connected to Host-A (fa0/1) as a routed interface and also need to create an SVI interface attached to VLAN 2 to enable inter-VLAN routing to the VLAN 2 interface on the L3 router module within Switch-B. You must also configure the appropriate routing for the remote 192.168.3.0/24 subnet attached to Switch-B to ensure Switch-A forwards packets to Host-B to the correct next hop. In this scenario, instead of configuring static routing, as was configured in Scenario 5-1, a dynamic routing protocol is configured.

To configure an interface as a routed interface, you must use the no switchport interface configuration command on the interface you want to convert. After you have completed this configuration, the interface becomes a Layer 3 interface and can be configured with Layer 3 parameters, such as IP addressing information. Example 5-18 shows the configuration required on Switch-A to configure interface fa0/1 as a routed interface.

Example 5-18. Configuring a Routed Physical Interface on Switch-A

 Switch-A# configure terminal Switch-A(config)# interface FastEthernet 0/1 Switch-A(config-if)# no switchport Switch-A(config-if)# ip address 192.168.1.1 255.255.255.0

In Example 5-18, the no switchport command is used to configure the interface as a routed (Layer 3) interface rather than a switched (Layer 2) interface. Any routed interface on a Cisco IOS router or L3 switch is placed into a shutdown state by default, so you must explicitly enable the interface by using the no shutdown command.

NOTE

By default, all interfaces on the Catalyst 3550 and other Cisco IOS-based Layer 3 switches are Layer 2 interfaces and must be configured explicitly as routed interfaces. This does not apply to the Catalyst 6000/6500 operating in native IOS mode, where all interfaces are routed interfaces by default.

Finally, you assign an IP address to the interface, which you must do for any routed interface on a traditional Cisco IOS router.

NOTE

By default, any IP address associated with a routed interface on a L3 switch can be used for management access via Telnet. This means you do not have to create an SVI interface for switch management.

After configuring the routed interface on Switch-A, you next need to create SVI interfaces for each VLAN the L3 switch must route for. An SVI is created by using the interface vlan global configuration command:

 Switch(config)# interface vlan vlan-id

In this scenario, Switch-A needs to route only for VLAN 2. Because interface fa0/2 is configured as a trunk, it cannot be configured as a routed interface (routed trunk interfaces are not supported) and instead must be configured as a Layer 2 trunk interface. To enable the routing engine of Switch-A to communicate with VLAN 2 on the switching engine, an SVI must be created for VLAN 2 as shown in Example 5-19.

Example 5-19. Creating an SVI on Switch-A

 Switch-A# configure terminal Switch-A(config)# interface vlan 2 Switch-A(config-if)# ip address 192.168.2.1 255.255.255.0

As you can see from Example 5-19, the procedure for creating an SVI on a L3 switch is identical to that for a traditional L2 switch. The only difference is that the SVI is used only for management connectivity on a L2 switch while the SVI is used for both routing and management connectivity on a L3 switch.

Now that the appropriate Layer 3 interfaces have been configured on Switch-A, you can configure IP routing. In this scenario, Switch-A is directly connected to the 192.168.1.0/24 and 192.168.2.0/24 subnets. However, it is not directly connected to the 192.168.3.0/24 subnet and, therefore, requires routing information for this subnet to be configured. Because EIGRP must be configured for this scenario, instead of configuring a static route on Switch-A, you must configure EIGRP so that Switch-A can learn about the 192.168.3.0/24 route dynamically and also advertise the 192.168.1.0/24 subnet. Example 5-20 shows the configuration required on Switch-A to perform these tasks.

Example 5-20. Configuring IP Routing on Switch-A

 Switch-A# configure terminal Switch-A(config)# ip routing Switch-A(config)# router eigrp 1 Switch-A(config-router)# network 192.168.1.0 Switch-A(config-router)# network 192.168.2.0

In Example 5-20, notice that you must explicitly enable IP routing on Switch-A, because by default a Catalyst 3550 series L3 switch is configured as a Layer 2 switch and L3 switching is not enabled. EIGRP is then configured, placing interfaces in the 192.168.1.0/24 and 192.168.2.0/24 networks in the EIGRP routing domain.

Configuring Switch-B for Inter-VLAN Routing

To enable L3 switching on Switch-B, you must configure the router module installed in slot 2 of Switch-B. This router module is essentially a separate router that has its own Cisco IOS management interface and is configured independently of the main Switch-B chassis. To understand how to configure L3 switching using the Catalyst 4000 router module, you must view the router module as a separate router that is attached to the switch internally. This means that you need to provide an initial configuration (e.g., host name, passwords, and so on) for the router module before configuring inter-VLAN routing.

Before configuring inter-VLAN routing on Switch-B, it is a good idea to test connectivity over the trunk between Switch-A and Switch-B. This test can be achieved by configuring the sc0 management interface of Switch-B in VLAN 2 with an appropriate IP address and then attempting to ping the VLAN 2 SVI interface created in Example 5-21. Example 5-21 shows the configuration required on Switch-B.

Example 5-21. Configuring the sc0 Management Interface on Switch-B

 Switch-B> (enable) set interface sc0 2 192.168.2.100 255.255.255.0 Interface sc0 vlan set, IP address and netmask set. Switch-B> (enable) set ip route default 192.168.2.1 Route added. Switch-B> (enable) ping 192.168.2.1 !!!!! ----192.168.2.1 PING Statistics---- 5 packets transmitted, 5 packets received, 0% packet loss round-trip (ms)  min/avg/max = 7/11/25 Switch-A> (enable) show arp ARP Aging time = 1200 sec + - Permanent Arp Entries * - Static Arp Entries 192.168.2.1                               at 00-09-b7-aa-9c-80 port  2/3 on VLAN 2

In Example 5-21, notice that the sc0 interface is configured, a default gateway is configured, connectivity to Switch-A is tested, and then the local ARP cache is viewed on Switch-B. When the ping command is executed, an ICMP echo request packet is generated from the sc0 interface (192.168.2.100) on Switch-B. The show arp command displays the local ARP cache, which contains IP addresstoMAC address mappings for devices on the VLAN the management interface is connected to. When the ICMP echo request packet is generated, assuming Switch-B does not know the MAC address of the SVI interface on Switch-A, Switch-B sends an ARP broadcast to determine the MAC address associated with the destination IP address (192.168.2.1). This broadcast is sent on VLAN 2 and is thus tagged and sent down the 802.1Q trunk to Switch-A. Because the broadcast is tagged with a VLAN ID of 2, the ARP broadcast is forwarded to the SVI interface in VLAN 2, which is configured with an IP address of 192.168.2.1. Switch-A sends an ARP reply back to Switch-B containing the virtual MAC address of the VLAN 2 SVI interface, enabling Switch-B to forward the ICMP echo packet to the VLAN 2 SVI interface on Switch-A. The ARP entry is indicated by the shaded output of the show arp command in Example 5-18.

So now that Layer 2 connectivity between Switch-A and Switch-B has been verified, it is time to begin configuring inter-VLAN routing. Before configuring inter-VLAN routing on the router module, you need to configure the gigabit connections to the router module on the backplane of Switch-B that the Supervisor engine manages. These connections are identified by the Supervisor engine as ports x/1 and x/2, where x is the slot in which the router module is installed, and must be configured in one of three ways:

Physical interfaces only Each gigabit connection to the L3 router module is configured as a separate access port. In this situation, you need only assign each gigabit port to the appropriate VLAN.
Physical trunks Each gigabit connection to the L3 router module is configured as a separate trunk port, allowing the L3 router module access to multiple VLANs. In this situation, you must configure trunking appropriately for each port and optionally define the allowed VLANs on each trunk.
EtherChannel bundle Both gigabit connections are configured as a single EtherChannel bundle, creating a single virtual Layer 2 connection between the Supervisor engine and the L3 router module. The physical ports bundle can be configured as access ports, meaning the EtherChannel bundle belongs only to a single VLAN, or as trunk ports, meaning the EtherChannel bundle is connected to multiple VLANs. In either case, each physical port must be configured identically to ensure the EtherChannel bundle forms.

In this scenario, you configure these connections as an EtherChannel 802.1Q trunk (see Figure 5-15). Example 5-22 demonstrates configuring the Supervisor engine on Switch-B to support the L3 router module.

Example 5-22. Configuring Gigabit Ports on Switch-B to Router Module as an EtherChannel Trunk

 Switch-B> (enable) set trunk 2/1 nonegotiate dot1q Port(s) 2/1 trunk mode set to nonegotiate. Port(s) 2/1 trunk type set to dot1q. Switch-B> (enable) set trunk 2/2 nonegotiate dot1q Port(s) 2/2 trunk mode set to nonegotiate. Port(s) 2/2 trunk type set to dot1q. Switch-B> (enable) set port channel 2/1-2 on Port(s) 2/1-2 are assigned to admin group 112. Port(s) 2/1-2 channel mode set to on.

In Example 5-22, you must configure a trunking mode of nonegotiate because Cisco IOS routers (including the L3 router module) do not use or understand Dynamic Trunking Protocol (DTP). Similarly, you must also configure a PAgP mode of on for the EtherChannel bundle, as Cisco IOS routers do not use or understand Port Aggregation Protocol (PAgP).

At this point, you are ready to begin configuring the Catalyst 4000 L3 router module. Because the L3 router module has its own management interface and cannot be configured from the CatOS interface of Switch-B, you must establish a new management connection to the router module. Catalyst 4000, 5000, and 6000 switches use the session command in conjunction with the slot number of the router module to access an internal console port attached to any module that has a separate management interface. Example 5-23 shows how to establish a connection to the router module.

NOTE

Most modules accessible via the session command also have a console port that allows management access.

Example 5-23. Establishing a Management Connection to the Router Module in Switch-B

 Switch-B> (enable) session 2 Trying IntlgLineCard-2... Connected to IntlgLineCard-2. Escape character is '^]'.

In Example 5-23, you use the session 2 command, where the number 2 specifies the slot in which the router module is installed. The switch then attempts to establish an internal console connection to the management interface (CLI) of the module. Once established, you are presented with a command-line interface within the router module operating system (Cisco IOS), which is totally separate from the CatOS CLI of Switch-A. To return back to the CatOS CLI of Switch-A, you simply use the exit command in the router module IOS to logout of the session.

At this point, you have now successfully established a connection to the router module. The router module is a totally separate device from the Catalyst 4000 switch, with its own processor, memory, flash, and operating system. Use the show version command as shown in Example 5-24 to get a feel for the hardware and software installed in the router module.

Example 5-24. Checking the Router Module

 Router> show version Cisco Internetwork Operating System Software IOS (tm) L3 Switch/Router Software (CAT4232-IN-M), Version 12.0(10)W5(18f)      RELEASE SOFTWARE Copyright  1986-2000 by cisco Systems, Inc. Compiled Mon 04-Dec-00 22:07 by integ Image text-base: 0x60010928, data-base: 0x605F6000 ROM: System Bootstrap, Version 12.0(7)W5(15b) RELEASE SOFTWARE Router uptime is 19 hours, 54 minutes System restarted by power-on Running default software cisco Cat4232L3 (R5000) processor with 57344K/8192K bytes of memory. R5000 processor, Implementation 35, Revision 2.1 Last reset from power-on 1 FastEthernet/IEEE 802.3 interface(s) 4 Gigabit Ethernet/IEEE 802.3z interface(s) 123K bytes of non-volatile configuration memory. 16384K bytes of Flash internal SIMM (Sector size 256K). Configuration register is 0x2

Looking at the output of Example 5-24, you can pick out various pieces of information about the L3 router module, including the fact that the router module is Cisco IOS-based, includes a R5000 processor, 64 MB of memory, and 16 MB of flash memory.

The router module now needs to be configured as a new Cisco IOS router attached to Switch-B via the internal gigabit ports. This requires the router module to be configured with the following parameters:

Host identification information The router module routing engine is called Switch-B-L3.
Interface configuration The gigabit interfaces connected to the Supervisor engine must be configured as an EtherChannel bundle, with trunking configured over the bundle.
Routing configuration The router module must be configured to participate in the EIGRP routing domain so that Switch-B-L3 can exchange routes with the routing component of Switch-A.

Example 5-25 shows the configuration required to configure the host identification and interface configuration requirements just described.

Example 5-25. Configuring the Router Module

 Router> enable Router# configure terminal Router(config)# hostname Switch-B-L3 Switch-B-L3(config)# interface GigabitEthernet 3 Switch-B-L3(config-if)# no shutdown % Shutdown not allowed on this interface. Switch-B-L3(config-if)# channel-group 1 Switch-B-L3(config-if)# exit Creating a port-channel interface Port-channel1 Switch-B-L3(config)# interface GigabitEthernet 4 Switch-B-L3(config-if)# channel-group 1 Switch-B-L3(config-if)# end Switch-B-L3# show interfaces port-channel 1 Port-channel1 is up, line protocol is up   Hardware is GEChannel, address is 0004.4d19.e209 (bia 0000.0000.0000)   MTU 1500 bytes, BW 2000000 Kbit, DLY 10 usec, rely 255/255, load 1/255   Encapsulation ARPA, loopback not set, keepalive set (10 sec)   Half-duplex, Unknown Speed, Media type unknown, Force link-up   ARP type: ARPA, ARP Timeout 04:00:00     No. of active members in this channel: 2         Member 0 : GigabitEthernet3         Member 1 : GigabitEthernet4 ... (Output truncated) ...

In Example 5-25, interfaces GigabitEthernet 3 and GigabitEthernet 4 are added to a channel group, which creates a port-channel interface that represents the logical Layer 2 interface created by the EtherChannel bundle, as indicated by the shaded line directly below the first channel-group command that is executed. Notice the shaded lines in Example 5-25, which indicate that the internal gigabit interfaces connected to the switch backplane can never be shut down. In Example 5-25, also notice that no IP addressing is configured on the EtherChannel (port-channel) interface because it is operating as an 802.1Q trunk and requires subinterfaces to be created for each VLAN that you want to attach to and route for. Finally, the show interfaces port-channel 1 command is used to verify that the EtherChannel bundle has come up, which should happen immediately. As indicated by the shaded output, this interface is up at Layer 1 and Layer 2 and includes the GigabitEthernet 3 and GigabitEthernet 4 interfaces as active members.

TIP

It is important to note that when you configure the internal gigabit interfaces on the Layer 3 router module in an EtherChannel bundle, you cannot apply security access control lists (ACLs) to the port-channel interface that is used to represent the bundle. If you want to apply security ACLs for the purpose of filtering traffic sent or received by the Layer 3 router module on the internal gigabit interfaces, you must configure each port as a separate Layer 2 port.

All that now remains in terms of configuration on Switch-B-L3 is the creation of subinterfaces for each VLAN Switch-B-L3 must route for and the configuration of inter-VLAN routing. Example 5-26 shows the configuration required on Switch-B-L3 to create subinterfaces and verify connectivity from these subinterfaces to devices attached locally.

Example 5-26. Configuring IP and Inter-VLAN Routing on Switch-B-L3

 Switch-B-L3# configure terminal Switch-B-L3(config)# interface port-channel 1.2 Switch-B-L3(config-if)# encapsulation dot1q 2 Switch-B-L3(config-if)# ip address 192.168.2.2 255.255.255.0 Switch-B-L3(config-if)# exit Switch-B-L3(config)# interface port-channel 1.3 Switch-B-L3(config-if)# encapsulation dot1q 3 Switch-B-L3(config-if)# ip address 192.168.3.1 255.255.255.0 Switch-B-L3(config-if)# end Switch-B-L3# ping 192.168.2.100 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.2.100, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms Switch-B-L3# ping 192.168.2.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

In Example 5-26, create a subinterface for each VLAN that you want the routing module to attach to. Referring to Figure 5-15, the routing module must route for VLAN 2 and VLAN 3; hence, two subinterfaces are created for each of these VLANs. The configuration here is identical to what was configured on the trunk from Router-B to Switch-A in Scenario 5-1 (see Example 5-4). The only difference here is that you are configuring an EtherChannel trunk rather than a physical trunk interface. After the configuration of each subinterface, connectivity to devices in VLAN 2 is tested. Notice that connectivity to the management interface (192.168.2.100) on the Supervisor engine of Switch-B is verified, as well as connectivity across the trunk to the VLAN 2 interface (192.168.2.1) on Switch-A.

Finally, inter-VLAN routing must be configured on Switch-B-L3, with the interfaces attached to VLAN 2 and VLAN 3 configured as part of the EIGRP routing domain. Example 5-27 shows the configuration required on Switch-B-L3.

Example 5-27. Configuring Inter-VLAN Routing on Switch-B-L3

 Switch-B-L3# configure terminal Switch-B-L3(config)# router eigrp 1 Switch-B-L3(config-router)# network 192.168.2.0 Switch-B-L3(config-router)# network 192.168.3.0

In Example 5-27, it is very important that you configure EIGRP for the same autonomous system number as configured on Switch-A, using the router eigrp 1 command. This ensures that both routers are participating in the same routing domain and can exchange routes. Switch-B-L3 is then configured so that interfaces attached to the 192.168.2.0/24 and 192.168.3.0/24 networks belong to the routing domain.

After a few seconds, an EIGRP adjacency forms between Switch-A and Switch-B-L3 and routes exchange. On either device, you should be able to see any subnets not locally attached in the routing table, since they have been learned via EIGRP. Example 5-28 demonstrates the use of the show ip route command on Switch-B-L3.

Example 5-28. Verifying IP Routing on Switch-B-L3

 Switch-B-L3# show ip route Codes: C - connected, S - static, I - IGRP, 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, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default        U - per-user static route, o - ODR Gateway of last resort is not set D    192.168.1.0/24 [90/0] via 192.168.2.1 C    192.168.2.0/24 is directly connected, Port-channel1.2 C    192.168.3.0/24 is directly connected, Port-channel1.3

As you can see from the shaded output of Example 5-28, a route for the 192.168.1.0/24 network exists, which is reachable via 192.168.2.1. This route has been learned via EIGRP, as indicated by the code D to the left of the route entry.

Verifying Connectivity

You have now configured the scenario topology for full inter-VLAN routing between Host-A and Host-B. At this stage you should be able to ping any IP interface in the network from any location.

On Switch-A, you should be able to successfully ping the VLAN 3 interface on Switch-B-L3 (192.168.3.1), as shown in Example 5-29.

Example 5-29. Testing ping Connectivity from Switch-A to Switch-B-L3

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

Example 5-29 confirms that Switch-A has the appropriate routing information for the 192.168.3.0/24 network.

On Switch-B, you should be able to successfully ping interface fa0/1 on Switch-B-L3 (192.168.1.1) as shown in Example 5-30.

Example 5-30. Testing ping Connectivity from Switch-B-L3 to Switch-A

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

Example 5-30 confirms that Switch-B-L3 has the appropriate routing information for the 192.168.1.0/24 network.

Finally, assuming Host-A and Host-B are connected to the network and configured appropriately, you should be able to successfully ping between these hosts. Example 5-31 shows an example of Host-A successfully pinging Host-B.

Example 5-31. Testing ping Connectivity from Host-A to Host-B

 C:\WINXP\SYSTEM32> ping 192.168.3.100 Pinging 192.168.3.100 with 32 bytes of data: Reply from 192.168.3.100: bytes=32 time=1ms TTL=255 Reply from 192.168.3.100: bytes=32 time=1ms TTL=255 Reply from 192.168.3.100: bytes=32 time=1ms TTL=255 Reply from 192.168.3.100: bytes=32 time=1ms TTL=255 Ping statistics for 192.168.3.100:     Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds:     Minimum = 1ms, Maximum = 1ms, Average = 1ms

Scenario 5-3: Implementing a Redundant Multilayer Topology

In the previous two scenarios, you learned about inter-VLAN routing architectures, which enable routing between VLANs in a LAN topology. In this scenario, it is time to demonstrate more of the big picture. Instead of focusing on a simple LAN topology, in this scenario, you learn how to configure a reasonably complex network using a multilayer design. Possessing a knowledge of inter-VLAN routing is a fundamental requirement for implementing a multilayer design. You learn how to apply the techniques learned in the first two scenarios to enable a multilayer topology that is scalable, available, and performs well.

Figure 5-16 shows the topology used for this scenario.

Figure 5-16. Scenario 5-3 Topology

The following describes the function of each component of the scenario topology shown in Figure 5-16:

Switch-E is a Catalyst 3550-24 switch that provides Layer 2 access for each of the hosts. Switch-E is considered an access layer switch, providing connectivity for hosts in two separate VLANs (VLAN 100 and VLAN 200).
Switch-A and Switch-B are Catalyst 3550-24 Layer 3 switches that provide connectivity between VLAN 100 and VLAN 200, as well as the rest of the network. Switch-A and Switch-B are considered distribution layer switches.
Switch-C and Switch-D are Catalyst 3550-24 L3 switches that represent the core of the network and are responsible for routing packets originated in VLAN 100 and VLAN 200 to other destinations in the network and vice versa.
Host-A and Host-B are workstations attached to VLAN 100 and VLAN 200 respectively.

At the edge of the network, where Switch-A and Switch-B provide routing for the access layer, HSRP is configured to provide default gateway redundancy for all end devices in VLAN 100 and VLAN 200. Within the core and distribution layers, OSPF is configured as the dynamic routing protocol, which is the standards-based, link-state routing protocol of choice for many networks today.

Understanding the Scenario Layer 3 Topology

The physical topology shown in Figure 5-16 does not represent the logical topology of the lab well. Figure 5-17 illustrates the logical topology of the lab from an IP perspective.

Figure 5-17. Scenario 5-3 IP Topology

In Figure 5-17, the network topology essentially consists of a single Layer 2 domain, which includes Switch-E and its connected hosts. Switch-A and Switch-B also connect to the Layer 2 domain but also include routing components that terminate the Layer 2 domain, routing traffic sent to and from the devices in the Layer 2 domain. The most important concept of Figure 5-17 is that the topology includes hierarchy. Hierarchy is achieved by splitting the network into layers as follows:

Access layer Provides LAN connectivity to the network for end devices. In a multilayer topology, access layer switches are typically Layer 2 switches. In Figure 5-17, Switch-E is an access layer switch.
Distribution layer In a multilayer LAN topology, the distribution layer forms the boundary between the Layer 2 domain that includes the access layer and the remaining Layer 2 or Layer 3 topology of the core. Layer 3 switches are implemented at this layer and are normally configured as the default gateway for devices in the access layer. In Figure 5-17, Switch-A and Switch-B are distribution layer devices.
Core layer The core layer can be based on either a high-speed Layer 2 backbone or a high-speed Layer 3 backbone. With modern core switches now supporting Layer 3 switching with no performance penalties, many organizations implement a Layer 3 backbone for the core, with all connections between core switches being routed connections rather than Layer 2 connections. In Figure 5-17, Switch-C and Switch-D are core devices.

NOTE

The hierarchical nature of a multilayer design makes the network more scalable, available, and increases network performance.

To successfully commence the configuration tasks required to complete this scenario, the following lists the prerequisite configuration tasks required on each switch in the scenario topology:

Hostname each switch should be configured with an appropriate hostname as per Figure 5-16.
Telnet/Enable password each switch should be configured with an appropriate telnet and enable password.

This scenario assumes the configuration tasks listed above have already been implemented and hence does not include the configuration of these tasks.

Table 5-1 describes the prerequisite configurations required on each host in the scenario topology. Any configurations not listed can be assumed as being the default configuration.

Table 5-1. Scenario 5-3 Requirements
Device	Required Configuration
	Parameter	Value
Host-A	Operating System	Windows 2000 Professional or Windows XP
	IP Address	192.168.1.100/24
	Default Gateway	192.168.1.10
Host-B	Operating System	Windows 2000 Professional or Windows XP
	IP Address	192.168.2.100/24
	Default Gateway	192.168.2.10

Configuration Tasks

Configuring a multilayer LAN topology requires configuration of both Layer 2 and Layer 3 parameters on each of the various switching and routing devices in the network. To complete this scenario you need to perform the following tasks:

Configuring Layer 2 parameters
Configuring Layer 3 parameters
Verifying connectivity

Configuring Layer 2 Parameters

In this scenario, the network can be viewed as two separate parts:

Layer 2 domain This encompasses Switch-E and the layer interfaces on Switch-A and Switch-B. Within this domain, all devices within the same VLAN can communicate directly at Layer 2.
Layer 3 domain This encompasses the entire network; however, it can be broken into separate IP subnets, which allows hierarchy to be introduced into the network. IP subnets exist for each VLAN in the Layer 2 domain, while IP subnets also exist for each routed link to the core of the network.

When working with Catalyst switches that integrate both Layer 2 and Layer 3 functionality, it is important to be able to recognize the separate Layer 2 and Layer 3 components of the network and then configure each component separately, starting with the Layer 2 component. Once the Layer 2 component is configured and verified, a stable foundation is in place to overlay the Layer 3 component of the network in a trouble-free manner. In this section, you configure the Layer 2 component of the scenario topology. The following lists the configuration tasks required to complete this configuration:

Configuring the distribution layer switches
Configuring the access layer switches

Configuring the Distribution Layer Switches

In this scenario, Switch-A and Switch-B are distribution layer switches (providing both Layer 2 and Layer 3 services) enabling communications between devices attached to the access layer and the rest of the network (reachable via the core). From a Layer 2 perspective, Switch-A and Switch-B form essentially the core of the Layer 2 domain that includes Switch-A, Switch-B, and Switch-E and, hence, must be configured appropriately for this role from a Layer 2 perspective. In a real-world network, there could be tens of access switches in the access layer, all connected to Switch-A and Switch-B. Switch-A and Switch-B are the center of the Layer 2 domain, qualifying their designation as the core of the Layer 2 domain.

Based upon the role of Switch-A and Switch-B in the Layer 2 domain, the following describes the various Layer 2 configuration parameters that must be implemented and how they should be configured on Switch-A and Switch-B:

VLAN Trunking Protocol VTP enables a central VLAN database to be configured that is shared between Switch-A, Switch-B, and all other access layer switches. In an environment where there are many access layer switches and VLANs, using VTP eases the administrative overhead of managing VLANs. Switch-A and Switch-B should be configured as VTP servers, providing VTP server redundancy, while any access layer switches should be configured as VTP clients.
VLANs After configuring VTP, you can then create VLANs that are distributed to other switches in the VTP domain. In this scenario, VLAN 100 and VLAN 200 must be created.
Trunks Trunk connections are required between the distribution layer switches and access layer switches to allow traffic from multiple VLANs to be transported over the same physical connection. A trunk is also required between Switch-A and Switch-B to enable redundancy in the network should any access layer switch uplink fail. In this scenario, the VLANs enabled on each trunk can be restricted to VLAN 1 (native VLAN), VLAN 100, and VLAN 200.
Spanning tree Spanning tree must be configured so that Switch-A is the root bridge and Switch-B is the secondary root bridge, or vice versa. This ensures that the Layer 2 topology formed between Switch-A, Switch-B, and access layer switches is optimal and loop free. In this scenario, to enable load sharing on the uplinks between the access layer and distribution layer, Switch-A should be configured as the root bridge for VLAN 100, while Switch-B should be configured as the root bridge for VLAN 200.

Example 5-32 shows the configuration required on Switch-A to configure VTP, VLANs, trunks, and spanning tree as just described.

Example 5-32. Configuring Layer 2 Parameters on Switch-A

 Switch-A# configure terminal Switch-A(config)# vtp mode server Device mode already VTP SERVER. Switch-A(config)# vtp domain lanps Changing VTP domain name from NULL to lanps Switch-A(config)# vlan 100 Switch-A(config-vlan)# name VLAN100 Switch-A(config-vlan)# exit Switch-A(config)# vlan 200 Switch-A(config-vlan)# name VLAN200 Switch-A(config-vlan)# exit Switch-A(config)# interface range FastEthernet 0/1  2 Switch-A(config-if-range)# switchport trunk allowed vlan 1,100,200,1002-1005 Switch-A(config-if-range)# exit Switch-A(config)# spanning-tree vlan 1 root primary diameter 4 % This switch is already the root bridge of the VLAN0001 spanning tree  vlan 1 bridge priority set to 24576  vlan 1 bridge max aging time set to 14  vlan 1 bridge hello time unchanged at 2  vlan 1 bridge forward delay set to 10 Switch-A(config)# spanning-tree vlan 100 root primary diameter 4 % This switch is already the root bridge of the VLAN100 spanning tree  vlan 100 bridge priority set to 24576  vlan 100 bridge max aging time set to 14  vlan 100 bridge hello time unchanged at 2  vlan 100 bridge forward delay set to 10 Switch-A(config)# spanning-tree vlan 200 root secondary diameter 4  vlan 200 bridge priority set to 28672  vlan 200 bridge max aging time set to 14  vlan 200 bridge hello time unchanged at 2  vlan 200 bridge forward delay set to 10

In Example 5-32, VTP is first configured, with Switch-A being configured as a VTP server and a VTP domain defined; VLAN 100 and VLAN 200 are then created. Next, the trunk interfaces to Switch-E (fa0/1) and Switch-B (fa0/2) are configured, with the allowed VLAN list on the interfaces effectively restricted to VLAN 1, VLAN 100, and VLAN 200 (VLAN 10021005 are always required on trunk interfaces on the Catalyst 3550 and cannot be removed). Notice that you do not need to configure any other trunking parameters because by default Layer 2 interfaces on the Catalyst 3550 are configured with a DTP mode of desirable, meaning any interswitch connection between Catalyst 3550 switches forms a trunk by default (assuming the VTP domain name is identical on both switches). Finally, spanning tree is configured, with Switch-A configured as the root bridge for VLAN 1 and VLAN 100 and configured as the secondary root bridge for VLAN 200. Notice that the network diameter is configured as 4, while only three switches are present in the Layer 2 domain for this scenario. This is to reflect the network diameter when more than one access layer switch is present in the network.

Now that Switch-A is configured, Switch-B can be configured. When configuring Switch-B, because Switch-A is already present in the network as a VTP server, you should first configure VTP and then verify that VLAN 100 and VLAN 200 have been propagated to the VLAN database on Switch-B via VTP. Example 5-33 shows the process of configuring VTP and then verifying VLANs that have been propagated via VTP on Switch-B.

Example 5-33. Configuring VTP and Verifying VLANs on Switch-B

 Switch-B# configure terminal Switch-B(config)# vtp mode server Device mode already VTP SERVER. Switch-B(config)# vtp domain lanps Changing VTP domain name from NULL to lanps Switch-B(config)# exit Switch-B# show vlan VLAN Name                             Status    Ports ---- -------------------------------- --------- ------------------------------- 1    default                    active    Fa0/1, Fa0/2, Fa0/3, Fa0/4, Fa0/6, Fa0/7,                                              Fa0/8, Fa0/9, Fa0/10, Fa0/11, Fa0/12,                                            Fa0/13, Fa0/14, Fa0/15, Fa0/16, Fa0/17,                                            Fa0/18, Fa0/19, Fa0/20, Fa0/21, Fa0/22,                                                 Fa0/23, Fa0/24, Gi0/1, Gi0/2 100  VLAN0100                         active 200  VLAN0200                         active 1002 fddi-default                     active 1003 token-ring-default               active 1004 fddinet-default                  active 1005 trnet-default                    active VLAN Type  SAID       MTU   Parent RingNo BridgeNo Stp  BrdgMode Trans1 Trans2 ---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------ 1    enet  100001     1500  -      -      -        -    -        0      0 100  enet  100100     1500  -      -      -        -    -        0      0 200  enet  100200     1500  -      -      -        -    -        0      0 1002 fddi  101002     1500  -      -      -        -    -        0      0 1003 tr    101003     1500  -      -      -        -    -        0      0 1004 fdnet 101004     1500  -      -      -        ieee -        0      0 1005 trnet 101005     1500  -      -      -        ibm  -        0      0 Remote SPAN VLANs ------------------------------------------------------------------------------ Primary Secondary Type              Ports ------- --------- ----------------- ------------------------------------------

As you can see in Example 5-33, VLAN 100 and VLAN 200 are present in the VLAN database of Switch-B. Now that the VLAN databases between Switch-A and Switch-B are synchronized, all remaining Layer 2 parameters can be configured on Switch-B. Example 5-34 shows the remaining Layer 2 configuration required on Switch-B.

Example 5-34. Configuring Layer 2 Parameters on Switch-B

 Switch-B# configure terminal Switch-B(config)# interface range FastEthernet 0/1  2 Switch-B(config-if-range)# switchport trunk allowed vlan 1,100,200,1002-1005 Switch-B(config-if-range)# exit Switch-B(config)# spanning-tree vlan 1 root secondary diameter 4  vlan 1 bridge priority set to 28672  vlan 1 bridge max aging time set to 14  vlan 1 bridge hello time unchanged at 2  vlan 1 bridge forward delay set to 10 Switch-B(config)# spanning-tree vlan 100 root secondary diameter 4  vlan 100 bridge priority set to 28672  vlan 100 bridge max aging time set to 14  vlan 100 bridge hello time unchanged at 2  vlan 100 bridge forward delay set to 10 Switch-B(config)# spanning-tree vlan 200 root primary diameter 4  vlan 200 bridge priority set to 24576  vlan 200 bridge max aging time set to 14  vlan 200 bridge hello time unchanged at 2  vlan 200 bridge forward delay set to 10

In Example 5-34, the trunk interfaces to Switch-A and Switch-E are configured to effectively permit traffic only from VLAN 1, VLAN 100, and VLAN 200. Switch-B is then configured as the secondary root bridge for VLAN 1 and VLAN 100 and is configured as the primary root bridge for VLAN 200. It is a good idea to verify the spanning tree configuration, ensuring Switch-A is the root bridge for VLAN 1 and VLAN 100, while Switch-B is the root bridge for VLAN 200. Example 5-35 demonstrates the use of the show spanning-tree summary command on Switch-B.

Example 5-35. Verifying Spanning Tree

 Switch-B# show spanning-tree summary Root bridge for: VLAN0200. Extended system ID is enabled. PortFast BPDU Guard is disabled EtherChannel misconfiguration guard is enabled UplinkFast is disabled BackboneFast is disabled Default pathcost method used is short Name                   Blocking Listening Learning Forwarding STP Active ---------------------- -------- --------- -------- ---------- ---------- VLAN0001                  0        0         0        2          2 VLAN0100                  0        0         0        2          2 VLAN0200                  0        0         0        2          2 ---------------------- -------- --------- -------- ---------- ---------- 3 vlans                   0        0         0        6          6

In Example 5-35, the shaded output indicates that Switch-B is the root bridge for VLAN 200. This implies that Switch-A is the root bridge for VLAN 1 and VLAN 100, although it is a good idea to check this explicitly on Switch-A.

Configuring the Access Layer Switches

Now that the distribution layer is in place from a Layer 2 perspective, the access layer can be configured. In this scenario, Switch-E is an access layer switch, as it provides Layer 2 connectivity for end devices, such as Host-A and Host-B. The following describes the Layer 2 parameters that must be configured on Switch-E:

VLAN Trunking Protocol Switch-E and any other access layer switch must be configured as a VTP client, which enables the VLANs configured on the VTP servers (Switch-A and Switch-B) to be learned automatically.
VLANs Interfaces fa0/3, fa0/4, and fa0/5 must be configured as access ports and placed into the appropriate VLANs. Interfaces fa0/3 and fa0/4 are to be placed into VLAN 100, and interface fa0/5 is to be placed into VLAN 200.
Trunks Interface fa0/1 and interface fa0/2 are trunk connections to each distribution layer switch and the configuration on these trunks should match the configuration on the distribution layer switches. This requires the allowed VLAN list to permit traffic only from VLAN 1, VLAN 100, and VLAN 200.
Spanning tree Spanning tree does not require modification in terms of bridge priority and spanning-tree timers because Switch-A or Switch-B is configured as the root bridge for each VLAN. To improve convergence in the event of an uplink failure, spanning tree UplinkFast should be enabled on Switch-E.

Example 5-36 shows the Layer 2 configuration required on Switch-E.

Example 5-36. Configuring Layer 2 Parameters on Switch-E

 Switch-E# configure terminal Switch-E(config)# vtp mode client Setting device to VTP CLIENT mode. Switch-E(config)# vtp domain lanps Changing VTP domain name from NULL to lanps Switch-E(config)# interface range FastEthernet 0/3  4 Switch-E(config-if-range)# switchport mode access Switch-E(config-if-range)# switchport access vlan 100 Switch-E(config-if-range)# exit Switch-E(config)# interface range FastEthernet 0/5 Switch-E(config-if-range)# switchport mode access Switch-E(config-if-range)# switchport access vlan 200 Switch-E(config-if-range)# exit Switch-E(config)# interface range FastEthernet 0/1  2 Switch-E(config-if-range)# switchport trunk allowed vlan 1,100,200,1002-1005 Switch-E(config-if-range)# exit Switch-E(config)# spanning-tree uplinkfast

Configuring Layer 3 Parameters

Now that the appropriate Layer 2 configuration is in place, Layer 3 parameters such as inter-VLAN routing and HSRP can be configured. When configuring Layer 3 parameters in a topology similar to the one used for this scenario, where there are clear access, distribution, and core layers, configure each of these layers separately, starting from the core and finishing with the access layer. The following lists the configuration tasks required to configure inter-VLAN routing and HSRP for this scenario:

Configuring the core
Configuring the distribution layer
Configuring the access layer

Configuring the Core

The core used for this scenario consists of Switch-C and Switch-D, with both switches providing connectivity to the "core" of the network (10.x.x.x) for the distribution layer switches (Switch-A and Switch-B). The configuration tasks for the core can be split into two:

Configuring routed interfaces
Configuring dynamic routing

Configuring Routed Interfaces

All connections on Switch-C and Switch-D are routed (Layer 3) connections, which means within the core the EtherChannel bundle between Switch-C and Switch-D must be configured as a Layer 3 interface, as opposed to a Layer 2 interface. So far in this book you have not learned how to configure Layer 3 EtherChannel bundles, so it is important to discuss the configuration required. Creating a Layer 3 EtherChannel bundle is almost identical to how you create a Layer 2 EtherChannel bundle. The only difference is that you assign Layer 3 (routed) interfaces to the bundle instead of Layer 2 (switched) interfaces.

NOTE

Note that on the Catalyst 3550, you cannot configure Layer 3 interfaces as trunks, unlike Cisco routers that support trunking. Layer 3 interfaces include SVI interfaces, routed physical interfaces, and Layer 3 EtherChannel bundles. If you need to support traffic from multiple VLANs over a routed connection, you must configure the connection as a Layer 2 trunk and then create an SVI for each VLAN on the trunk.

Example 5-37 and Example 5-38 shows the configuration required on Switch-C and Switch-D to configure the Layer 3 EtherChannel bundle between the switches.

Example 5-37. Configuring a Layer 3 EtherChannel Bundle on Switch-C

 Switch-C# configure terminal Switch-C(config)# interface range fastEthernet 0/1  2 Switch-C(config-if-range)# no switchport Switch-C(config-if-range)# channel-group 1 mode desirable Creating a port-channel interface Port-channel1 Switch-C(config-if-range)# exit Switch-C(config)# interface Port-channel 1 Switch-C(config-if)# ip address 10.1.1.1 255.255.255.0 Switch-C(config-if)# exit

Example 5-38. Configuring a Layer 3 EtherChannel Bundle on Switch-D

 Switch-D# configure terminal Switch-D(config)# interface range fastEthernet 0/1  2 Switch-D(config-if-range)# no switchport Switch-D(config-if-range)# channel-group 1 mode desirable Creating a port-channel interface Port-channel1 Switch-D(config-if-range)# exit Switch-D(config)# interface port-channel 1 Switch-D(config-if)# ip address 10.1.1.2 255.255.255.0 Switch-D(config-if)# exit

In Example 5-37 and Example 5-38, notice that the physical interfaces that comprise each bundle are first configured as routed interfaces using the no switchport command. The interfaces are then configured as an EtherChannel bundle using the channel-group interface configuration command, with a port-channel interface created that represents the bundle as a logical Layer 3 interface.

NOTE

Notice that you can configure PAgP on Layer 3 EtherChannel bundles on the Catalyst 3550. On traditional Cisco routers, PAgP is not supported, meaning you must configure a PAgP mode of on if you are connecting a Layer 3 EtherChannel bundle on the Catalyst 3550 to a Cisco router.

Once the physical interface configuration is complete, all subsequent Layer 3 configuration is performed on the port-channel interfaces created. After the configuration of Example 5-37 and Example 5-38, you should be able to verify IP connectivity between Switch-C and Switch-D, as demonstrated in Example 5-39.

Example 5-39. Verifying IP Connectivity between Switch-C and Switch-D

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

In Example 5-39, the initial timeout is caused by the delays associated with the ARP process determining the MAC address associated with 10.1.1.2.

Now that the IP connectivity in the core has been established, it is time to configure IP connectivity to the distribution layer switches. Example 5-40 and Example 5-41 show the configuration required on Switch-C and Switch-D.

Example 5-40. Configuring Routed Interfaces to Distribution Layer on Switch-C

 Switch-C# configure terminal Switch-C(config)# interface fastEthernet 0/3 Switch-C(config-if)# description CONNECTED TO SWITCH-A Switch-C(config-if)# no switchport Switch-C(config-if)# ip address 192.168.3.1 255.255.255.0 Switch-C(config-if)# exit Switch-C(config)# interface fastEthernet 0/4 Switch-C(config-if)# description CONNECTED TO SWITCH-B Switch-C(config-if)# no switchport Switch-C(config-if)# ip address 192.168.4.1 255.255.255.0 Switch-C(config-if)# exit

Example 5-41. Configuring Routed Interfaces to Distribution Layer on Switch-D

 Switch-D# configure terminal Switch-D(config)# interface fastEthernet 0/3 Switch-D(config-if)# description CONNECTED TO SWITCH-A Switch-D(config-if)# no switchport Switch-D(config-if)# ip address 192.168.5.1 255.255.255.0 Switch-D(config-if)# exit Switch-D(config)# interface fastEthernet 0/4 Switch-D(config-if)# description CONNECTED TO SWITCH-B Switch-D(config-if)# no switchport Switch-D(config-if)# ip address 192.168.6.1 255.255.255.0 Switch-D(config-if)# exit

At this stage, you cannot verify connectivity to Switch-A and Switch-B because these switches have not yet been configured.

Configuring Dynamic Routing

The final configuration task for the core is to configure dynamic routing. For this scenario, OSPF is to be configured, with core network (10.1.1.0/24) configured in Area 0 and the networks connected to the distribution layer switches configured in Area 1. This requires both Switch-C and Switch-D to be configured as area border routers, meaning they are members of more than one area.

NOTE

An in-depth discussion as to OSPF theory and configuration is outside the scope of this book. The configuration of this scenario is included to give you exposure to the dynamic routing capabilities of the Catalyst 3550 switch. For more information on configuring OSPF in a practical lab environment, refer to CCNP Practical Studies: Routing by Henry Benjamin from Cisco Press.

Example 5-42 and Example 5-43 show the OSPF configuration required on Switch-C and Switch-D.

Example 5-42. Configuring OSPF on Switch-C

 Switch-C# configure terminal Switch-C(config)# router ospf 1 Switch-C(config-router)# network 10.1.1.0 0.0.0.255 area 0 Switch-C(config-router)# network 192.168.3.0 0.0.0.255 area 1 Switch-C(config-router)# network 192.168.4.0 0.0.0.255 area 1 Switch-C(config-router)# area 0 range 10.0.0.0 255.0.0.0 Switch-C(config-router)# area 1 range 192.168.0.0 255.255.248.0

Example 5-43. Configuring OSPF on Switch-D

 Switch-D# configure terminal Switch-D(config)# router ospf 1 Switch-D(config-router)# network 10.1.1.0 0.0.0.255 area 0 Switch-D(config-router)# network 192.168.5.0 0.0.0.255 area 1 Switch-D(config-router)# network 192.168.6.0 0.0.0.255 area 1 Switch-D(config-router)# area 0 range 10.0.0.0 255.0.0.0 Switch-D(config-router)# area 1 range 192.168.0.0 255.255.248.0

In Example 5-42 and Example 5-43, an OSPF routing process is first created using the router ospf 1 command, with the number 1 indicating the process ID.

NOTE

You can run multiple instances of OSPF on the same router, with a unique process ID required for each instance. The process ID has only local significance, meaning the router can participate in the same OSPF routing domains as other routers configured with a different process ID.

After the routing process is created, each interface is assigned to the appropriate OSPF area, using the network command. The network command specifies a range of IP addresses using a wildcard mask, which identifies the interfaces to be assigned to the specified area. For example, in Example 5-42, the network 10.1.1.0 0.0.0.255 area 0 command configures any interfaces with an IP address in the address range 10.1.1.0 10.1.1.255 belong to 0. Finally, the area range command is used to generate summary routes for each area, reducing the number of inter-area routes in the OSPF routing domain. The area 0 range 10.0.0.0 255.0.0.0 command configures a summary route of 10.0.0.0/8 that represents any networks in area 0 within the networks summarized by the summary route. The summary route suppresses all other inter-area routes encompassed by it, meaning Switch-C and Switch-D only advertise a route 10.0.0.0/8 from area 0 into area 1 (i.e., to Switch-A and Switch-B), with the 10.1.1.0/24 inter-area route not advertised because it is part of the 10.0.0.0/8 summary route. The area 1 range 192.168.0.0 255.255.248.0 command ensures only a single route (192.168.0.0/21) from area 1 is advertised into area 0, which encompasses all of the /24 subnets within area 1 (192.168.1.0/24 192.168.6.0/24). Figure 5-18 illustrates how summarization of the inter-area routes works.

Figure 5-18. OSPF and Inter-Area Summarization

In Figure 5-18, you can see the inter-area routes advertised by the area border routers Switch-C and Switch-D. Notice that a single summary route is advertised into each area, as described earlier. Without the summary routes being configured, the number of routes advertised into area 0 would be six (192.168.1.0/24 to 192.168.6.0/24).

After completing the OSPF configuration, you should verify OSPF is configured and working correctly. At this stage, because Switch-A and Switch-B are not yet configured for OSPF, no OSPF routes are actually in the routing table of Switch-C or Switch-D. However, you can verify that OSPF neighbor adjacencies have formed correctly using the show ip ospf neighbor command, as demonstrated on Switch-C in Example 5-44.

Example 5-44. Verifying OSPF Neighbors on Switch-C

 Switch-C# show ip ospf neighbor Neighbor ID     Pri   State           Dead Time   Address         Interface 192.168.6.1       1   FULL/DR         00:00:38    10.1.1.2        Port-channel1

In Example 5-44, notice that a single OSPF neighbor is known to Switch-C, via the Port-Channel1 interface (i.e., the 10.1.1.0/24 network). The key parameter to look for when verifying OSPF neighbors is the neighbor state, which is FULL/DR in Example 5-44. FULL means that a full adjacency has been formed with the neighbor, which means both OSPF routers recognize each other as valid neighbors and routes have been exchanged (this is a normal operational OSPF state). DR means that the neighbor is the designated router for the multi-access LAN segment. The DR is responsible for forming adjacencies with all OSPF routers on the same multi-access segment and distributing routes to each, eliminating the requirement for every OSPF router to form an adjacency with every other router.

OSPF also has the concept of a backup designated router (BDR), which in fact in this scenario is Switch-C. The BDR takes over the DR role if the DR fails. For every multi-access LAN segment, a DR and BDR are always elected, with the role chosen based upon the router with the highest router ID. On Switch-C you can see the router ID of Switch-D (the OSPF neighbor) is 192.168.6.1 The router ID is chosen as the highest loopback address on the router or, if no loopbacks are configured, the highest physical interface address. Because no loopbacks are configured on either Switch-C or Switch-D, Switch-C has a router ID of 192.168.4.1, and Switch-D has a router ID of 192.168.6.1. Hence, Switch-D is the DR and Switch-C is the BDR.

Configuring the Distribution Layer

The distribution layer consists of Switch-A and Switch-B, providing default gateway services for access layer devices and providing connectivity to the core. The configuration tasks required on the distribution layer switches are listed below:

Configuring routed interfaces
Configuring dynamic routing
Configuring HSRP

Configuring Routed Interfaces

Switch-A and Switch-B require several routed interfaces to be configured as follows:

Interface fa0/3 and fa0/4 These interfaces must be configured as physical routed interfaces, as they provide routed connections to the core of the network.
Interface VLAN 100 and VLAN 200 These SVI interfaces must be created to allow routing for VLAN 100 and VLAN 200.

Example 5-45 and Example 5-46 show the configuration required on Switch-A and Switch-B to configure routed interfaces.

Example 5-45. Configuring Routed Interfaces on Switch-A

 Switch-A# configure terminal Switch-A(config)# interface FastEthernet 0/3 Switch-A(config-if)# no switchport Switch-A(config-if)# ip address 192.168.3.2 255.255.255.0 Switch-A(config-if)# exit Switch-A(config)# interface FastEthernet 0/4 Switch-A(config-if)# no switchport Switch-A(config-if)# ip address 192.168.5.2 255.255.255.0 Switch-A(config-if)# exit Switch-A(config)# interface vlan 100 Switch-A(config-if)# ip address 192.168.1.1 255.255.255.0 Switch-A(config-if)# exit Switch-A(config)# interface vlan 200 Switch-A(config-if)# ip address 192.168.2.1 255.255.255.0 Switch-A(config-if)# exit

Example 5-46. Configuring Routed Interfaces on Switch-B

 Switch-B# configure terminal Switch-B(config)# interface FastEthernet 0/3 Switch-B(config-if)# no switchport Switch-B(config-if)# ip address 192.168.4.2 255.255.255.0 Switch-B(config-if)# exit Switch-B(config)# interface FastEthernet 0/4 Switch-B(config-if)# no switchport Switch-B(config-if)# ip address 192.168.6.2 255.255.255.0 Switch-B(config-if)# exit Switch-B(config)# interface vlan 100 Switch-B(config-if)# ip address 192.168.1.2 255.255.255.0 Switch-B(config-if)# exit Switch-B(config)# interface vlan 200 Switch-B(config-if)# ip address 192.168.2.2 255.255.255.0 Switch-B(config-if)# exit

After implementing the configuration of Example 5-45 and Example 5-46, all connectivity between Switch-A, Switch-B, Switch-C, and Switch-D is in place, and you should be able to ping any of these devices from each other. Example 5-47 demonstrates verifying IP connectivity from Switch-A using the ping utility.

Example 5-47. Verifying IP Connectivity from Switch-A

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

In Example 5-47, after an initial timeout due to delays associated with the ARP process, you can see that connectivity to interface VLAN 100 on Switch-B (192.168.1.2), interface fa0/3 on Switch-C (192.168.3.1), and interface fa0/3 on Switch-D (192.168.5.1) is confirmed. IP connectivity to Switch-B verifies the Layer 2 trunk between Switch-A and Switch-B (configured earlier in this scenario) is operational, while IP connectivity to Switch-C and Switch-D verifies the routed interfaces configured in this section are operational.

Configuring Dynamic Routing

As distribution layer switches, Switch-A and Switch-B are to be configured as OSPF routers, with both devices residing in OSPF area 1. OSPF must be configured so that routes for VLAN 100 and VLAN 200 are advertised to the core Layer 3 switches and also to allow Switch-A and Switch-B to learn the 10.0.0.0/8 route being advertised by the core.

Example 5-48 and Example 5-49 show the OSPF configuration required on Switch-A and Switch-B.

Example 5-48. Configuring OSPF on Switch-A

 Switch-A# configure terminal Switch-A(config)# ip routing Switch-A(config)# router ospf 1 Switch-A(config-router)# network 192.168.0.0 0.0.255.255 area 1

Example 5-49. Configuring OSPF on Switch-B

 Switch-B# configure terminal Switch-B(config)# ip routing Switch-B(config)# router ospf 1 Switch-B(config-router)# network 192.168.0.0 0.0.255.255 area 1

As you can in Example 5-48 and Example 5-49, the OSPF configuration required on Switch-A and Switch-B is identical and very simple. After IP routing is enabled using the ip routing command, an OSPF process is created; the network command is used to place all interfaces with an IP address in the address range 192.168.x.x into area 1. Refer back to the Layer 3 topology for this scenario (see Figure 5-17) and notice that all interfaces on Switch-A and Switch-B have IP addressing within the 192.168.x.x range. This means that the network command executed in Example 5-48 and Example 5-49 places all routed interfaces into the OSPF routing domain.

After completing the OSPF configuration of Switch-A and Switch-B, adjacencies should form across each of the routed connections, with link state information being exchanged that allows each OSPF router to install the appropriate routes into the local IP routing table. Example 5-50 shows the use of the show ip ospf neighbor command on Switch-A to initially verify that all expected adjacencies have formed correctly.

Example 5-50. Verifying OSPF Neighbors on Switch-A

 Switch-A# show ip ospf neighbor Neighbor ID     Pri   State           Dead Time   Address         Interface 192.168.4.1       1   FULL/BDR        00:00:36    192.168.3.1     FastEthernet0/3 192.168.6.1       1   FULL/DR         00:00:38    192.168.5.1     FastEthernet0/4 192.168.6.2       1   FULL/DR         00:00:32    192.168.1.2     Vlan100 192.168.6.2       1   FULL/DR         00:00:32    192.168.2.2     Vlan200

In Example 5-50, notice the four OSPF neighbors, when you might be expecting only three OSPF neighbors (Switch-B, Switch-C, and Switch-D). The reason for four neighbors is the fact that two directly connected paths exist between Switch-A and Switch-B, with an adjacency formed for each of these paths. This illustrates the fact that OSPF adjacencies are formed on a per-interface basis rather than a per-router basis. You can see that two adjacencies have been formed with the same router, as indicated by the two entries for the neighbor with a neighbor ID of 192.168.6.2 (the highest IP address on Switch-B). In Example 5-44, the Interface and Address columns allow you to determine over which interface an adjacency has formed and the IP address of the interface on the neighbor attached to the same Layer 2 segment as the local interface.

Referring again to Example 5-50, all of the adjacencies are operating in the FULL state, which means the adjacency is valid and link state information has been exchanged. This means that all the information required for the SPF calculations that generate OSPF routes has been obtained, and the IP routing table should contain OSPF routes. Example 5-51 demonstrates the use of the show ip route command on Switch-A to view the local IP routing table.

Example 5-51. Viewing the IP Routing Table on Switch-A

 Switch-A# show ip route Codes: C - connected, S - static, I - IGRP, 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, E - EGP        i - IS-IS, 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 Gateway of last resort is not set O IA 10.0.0.0/8 [110/2] via 192.168.3.1, 00:00:32, FastEthernet0/3                         via 192.168.5.1, 00:00:34, FastEthernet0/4 C    192.168.1.0/24 is directly connected, Vlan100 C    192.168.2.0/24 is directly connected, Vlan200 C    192.168.3.0/24 is directly connected, FastEthernet0/3 O    192.168.4.0/24 [110/2] via 192.168.1.2, 00:00:40, Vlan100                             via 192.168.2.2, 00:00:40, Vlan200                             via 192.168.3.1, 00:00:32, FastEthernet0/3 C    192.168.5.0/24 is directly connected, FastEthernet0/4 O    192.168.6.0/24 [110/2] via 192.168.1.2, 00:00:40, Vlan100                             via 192.168.2.2, 00:00:40, Vlan200                             via 192.168.5.1, 00:00:34, FastEthernet0/4

In Example 5-51, each of the OSPF routes are shaded. The first route is an OSPF inter-area route, as indicated by the O IA designation at the beginning of the route entry. This route is the 10.0.0.0/8 summary route generated by Switch-C and Switch-D (see Figure 5-18). Notice that Switch-A has installed two next hop routers for this routeone via 192.168.3.1 (Switch-C) and the other via 192.168.5.1 (Switch-D). Because Switch-C and Switch-D advertise the 10.0.0.0/8 route with the same cost, the routes are considered equal-cost routes and, hence, are both installed into the routing table. The remaining OSPF routes are intra-area routes (i.e., routes within the OSPF area the router belongs to), as indicated by the O designation at the beginning of each route entry. These routes represent the subnets that are used to interconnect the distribution layer with the core and are unlikely to be used for normal traffic on the network.

NOTE

By default, Cisco routers and Layer 3 switches install up to four equal-cost routes into the local routing table. This number can be altered by using the maximum-paths command under the routing process that you want to modify.

Given that two next hop routers exist for the 10.0.0.0/8 route, you might wonder how traffic sent to a destination within the 10.0.0.0/8 network is actually routed. When equal-cost routes exist in the routing table, load sharing of traffic occurs on either a per-destination basis or per-packet basis.

When load sharing takes place on a per-destination basis, the next hop router chosen is alternated on a per-destination basis. This means that packets sent to the same destination always are sent over the same path; however, packets sent to multiple destinations are load balanced. For example, if a packet is received with a destination IP address of 10.1.1.1, the route via the next hop router 192.168.3.1 (Switch-C) is chosen. If another packet is received with a destination IP address of 10.1.1.1, that packet is always routed via the same next hop router originally chosen (i.e., Switch-C). If a packet is then received with a destination IP address of 10.1.1.2, assuming that for the last load-sharing decision Switch-C was selected as the next hop, Switch-D is selected as the next hop router. Any subsequent packets received with a destination IP address of 10.1.1.2 are always be routed via Switch-D.

When load sharing takes place on a per-packet basis, each packet is load shared, with the destination IP address of each packet having no bearing on the load-sharing decision. For example, if packets are received with the same destination IP address (e.g., 10.1.1.1), the next hop router chosen for delivery of each packet is alternated packet by packet. Load sharing on a per-packet basis is more accurate in terms of the amount of traffic that is actually sent over each path in the network. With per-destination load sharing, large amounts of traffic sent to the same destination can mean one path is used more than the other path.

Now that you understand about per-destination and per-packet load sharing, you might be wondering which load-sharing mechanism is selected. On the Catalyst 3550 switch, only per-destination load sharing is supported; per-packet load sharing is not supported. This means that you have no choice as to how traffic is load shared and must bear this in mind when considering the performance of redundant paths in the network.

Configuring HSRP

All that now remains in terms of Layer 3 configuration at the distribution layer is the configuration of HSRP. HSRP is required to enable redundancy for each default gateway address configured on hosts in the access layer.

HSRP is configured in terms of HSRP groups, where each HSRP group is configured with a number of parameters that define the behavior of the group. These parameters include the following:

Group ID The group ID identifies a specific HSRP group. HSRP groups are configured on a per-interface basis, and more than one HSRP group can exist on an interface, hence the requirement for a group ID. The group ID can be any value in the range of 0 to 255 (0 is the default group ID).
Virtual IP address (Group address) The virtual IP address is also known as the group address and is the IP address associated with an HSRP group. It is important to understand that routers participating in HSRP are configured with their own separate physical interface IP addresses and can communicate using these IP addresses. In fact, any router control communications, such as dynamic routing protocol packets, are sent using the physical IP address of an interface, rather than the virtual IP address. This extends to Layer 2 communications, where routers listen for frames addressed to both the burned-in address (BIA), as well as the virtual MAC address.
Virtual MAC address All Layer 3 communications over a LAN require Layer 2 communications to be operational. On Ethernet networks, devices must possess a MAC address to communicate. Hence, a virtual MAC address is required for the virtual IP address associated with an HSRP group. By default, the MAC address associated with a virtual IP address is assigned from a special MAC address pool designated by Cisco for HSRP groups. This MAC address pool is 0000.0c07.ac**, where ** represents the HSRP group number (0-255). For example, if the HSRP group number is 1, the virtual MAC address for the group is 0000.0c07.ac01. When a device on the LAN sends an ARP request for the virtual IP address, the virtual MAC address (e.g., 0000.0c07.ac01) is returned in the ARP reply by the active router. The active router then listens for any frames addressed to the virtual MAC address, ensuring it receives any communications associated with the virtual IP address.
NOTE

The virtual MAC address used can be manually configured, and you can also configure the burned-in address (BIA) to be used instead of the HSRP virtual MAC address (0000.0c07.ac**). The BIA is the hardware address that ships with the router. Some older Cisco routers that use Lance Ethernet controllers only support using a single MAC address at one time. These routers include the Cisco 1000, Cisco 2500, Cisco 3000, and Cisco 4500 series routers. When running HSRP, these routers use only the HSRP virtual MAC address if they are active and use the BIA when they are not. Because these routers support only a single MAC address, you cannot configure more than one HSRP group on any single interface.
Timers HSRP uses periodic Hello messages as a mechanism to detect the failure of other routers within an HSRP group. By default, the Hello timer is used to send Hello messages, and the value of this timer is 3 seconds by default. A remote router within an HSRP group is declared down if a Hello message is not received within the Hold down timer, which is 10 seconds by default. These timer values can be modified to reduce the convergence associated with a failure to milliseconds if required.
Priority Priority is used to determine which physical router is the active router for a specific HSRP group. Priority is transmitted in each Hello message sent by an HSRP router. The default priority value is 100, but this is configurable. The router with the highest priority in an HSRP group is selected as the active router, which services any communications associated with the virtual IP address and virtual MAC address of the HSRP group.
Operational state The operational state of a physical router within an HSRP group is non-configurable and is instead determined by the configured priority and current network conditions (e.g., if the active router is operational or if it has failed). An HSRP router can operate in one of four statesActive, Standby, Speaking + Listening, and Listening
Preempt Although the router with the highest priority is supposed to become the active router, whether this happens or not is often determined by the ability of physical routers to preempt the active router role. If a physical router is attached to the network and belongs to an HSRP group that already has an active router, by default, even if the new router has a higher priority, the existing active router actually remains as the active router. To override this behavior, you can configure physical routers to preempt the active role, which means they assume the active role if they detect they have the highest priority for the group, even if another router already exists as the active router.
Interface tracking Provides the ability for a physical router to decrement its priority for an HSRP group, based upon the failure of one or more interfaces. Other HSRP routers within the group detect a lower priority in the periodic Hello messages sent by the active router and can then assume the active role as long as their priority is higher than the decremented priority of the active router. The ability to preempt is important for interface tracking, because other standby routers must be able to assert themselves as the active router as soon as they have the highest priority for a group. Careful planning of group priorities is also required to ensure the decremented priority of the active router is lower than the priority of the appropriate standby router(s).

For this scenario, referring back to Figure 5-16, end devices are located within VLAN 100 and VLAN 200. Each host is to be configured with the virtual IP address of an HSRP group consisting of each physical distribution layer router (i.e., Switch-A and Switch-B). Separate HSRP groups are required for VLAN 100 and VLAN 200. To implement load sharing, the active routers for each HSRP group should be different. For VLAN 100, Switch-A is configured as the active router, while for VLAN 200, Switch-B is configured as the active router.

The first HSRP group that must be created is for the virtual IP address (VIP) 192.168.1.10 on VLAN 100. For this group, Switch-A is to be configured as the active router, with Switch-B operating as the standby router. Interface tracking should also be configured on Switch-A, so that if connectivity to the core is degraded (a single connection fails) or completely lost (both connections fail), Switch-A lowers its priority for the group so that Switch-B becomes the active router. To ensure that Switch-A and Switch-B assume the active role when appropriate, both devices must be configured to preempt the active role. Example 5-52 and Example 5-53 show the configuration required on Switch-A and Switch-B to configure HSRP for the 192.168.1.10 VIP.

Example 5-52. Configuring HSRP for the 192.168.1.10 VIP on Switch-A

 Switch-A# configure terminal Switch-A(config)# interface vlan 100 Switch-A(config-if)# standby 1 ip 192.168.1.10 Switch-A(config-if)# standby 1 priority 200 preempt Switch-A(config-if)# standby 1 track FastEthernet0/3 50 Switch-A(config-if)# standby 1 track FastEthernet0/4 50

Example 5-53. Configuring HSRP for the 192.168.1.10 VIP on Switch-A

 Switch-B# configure terminal Switch-B(config)# interface vlan 100 Switch-B(config-if)# standby 1 ip 192.168.1.10 Switch-B(config-if)# standby 1 priority 150 preempt

The standby 1 ip 192.168.1.10 command on Switch-A and Switch-B creates an HSRP group with an ID of 1 and a virtual IP address of 192.168.1.10. Switch-A is configured with a priority of 200 for the group, while Switch-B is configured with a priority of 150. This means that Switch-A assumes the active role for the group. Both Switch-A and Switch-B are also configured to preempt the active role.

Notice on Switch-A that the standby track command is configured, which enables interface tracking. Both interfaces that are connected to the core are tracked, and in the event that one of these interfaces fails, the priority of the group is configured to decrement by 50.

NOTE

If both interfaces fail on Switch-A in Example 5-48, the priority is decremented by the sum of the decrement values configured for each tracked interface (i.e., 100).

Because the priority of Switch-B is 175, a single interface failure causes the priority of Switch-A to fall to 150, with Switch-B assuming the active role. It is very important that Switch-B is configured to preempt the active role, which ensures it actively takes over active role as soon as the priority of Switch-A falls below 175.

The second HSRP group that must be created is for the virtual IP address (VIP) 192.168.2.10 on VLAN 200. For this group, Switch-B is to be configured as the active router, with Switch-A operating as the standby router. Interface tracking should be configured on the active router (Switch-B). Example 5-54 and Example 5-55 show the configuration required on Switch-A and Switch-B to configure HSRP for the 192.168.2.10 VIP.

Example 5-54. Configuring HSRP for the 192.168.2.10 VIP on Switch-A

 Switch-A# configure terminal Switch-A(config)# interface vlan 200 Switch-A(config-if)# standby ip 192.168.2.10 Switch-A(config-if)# standby priority 150 preempt

Example 5-55. Configuring HSRP for the 192.168.2.10 VIP on Switch-B

 Switch-B# configure terminal Switch-B(config)# interface vlan 200 Switch-B(config-if)# standby ip 192.168.2.10 Switch-B(config-if)# standby priority 200 preempt Switch-B(config-if)# standby track FastEthernet0/3 50 Switch-B(config-if)# standby track FastEthernet0/4 50

In Example 5-54 and Example 5-55, notice that the group ID is not specified in the standby command, which means a group ID of 0 is assumed.

At this point, Switch-A is configured as the active router for the 192.168.1.10 VIP, while Switch-B is configured as the active router for the 192.168.1.20 VIP and 192.168.2.10 VIP. To verify that Switch-A and Switch-B have actually assumed these roles correctly, you can use the show standby brief command, as demonstrated in Example 5-56 on Switch-A.

Example 5-56. Verifying HSRP

 Switch-A# show standby brief                      P indicates configured to preempt.                      | Interface   Grp Prio P State    Active addr     Standby addr    Group addr Vl100       1   200  P Active   local           192.168.1.2     192.168.1.10 Vl200       0   175  P Standby  192.168.2.2     local           192.168.2.10

In Example 5-56, notice that an entry exists for each group. The State column indicates the current status of the router; you can see that Switch-A is active for the group address 192.168.1.10, but is the standby router for the other group.

Configuring the Access Layer

At this stage, the Layer 3 configuration of the network is almost complete. All that remains is for devices in the access layer to be configured with the appropriate default gateway information to enable traffic generated by these devices to be routed correctly through the network. As indicated by Figure 5-16, the following default gateway addresses should be configured for each host:

Host-A 192.168.1.10
Host-B 192.168.2.10

Assuming the IP address on each host is configured correctly and the default gateway configuration listed previously is in place, you should be able to ping any interface on any device in the network from each host.

Each of the hosts listed previously are not the only access layer devices in this scenario; Switch-E is also an access layer device and should be configured with an IP address and default gateway to allow for remote network management. Example 5-57 shows the configuration required on Switch-E to configure an IP address and default gateway and then verify connectivity to the rest of the network.

Example 5-57. Configuring IP on Switch-E

 Switch-E# configure terminal Switch-E(config)# interface vlan 100 Switch-E(config-if)# ip address 192.168.1.50 255.255.255.0 Switch-E(config-if)# exit Switch-E(config)# ip default-gateway 192.168.1.10 Switch-E(config)# exit Switch-E# ping 192.168.1.10 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.10, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms Switch-E# ping 10.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds: !!!!! Success rate is 80 percent (5/5), round-trip min/avg/max = 4/4/6 ms

Example 5-58 demonstrates verifying connectivity to the second HSRP group on VLAN 100 (192.168.1.20) and each of the VLAN interface IP addresses on Switch-A and Switch-B and then using the show arp command to view the ARP cache on Switch-E, where the MAC addresses associated with the HSRP group on VLAN 100, as well as the interfaces on Switch-A and Switch-B should be present.

Example 5-58. Testing Connectivity and Viewing the ARP Cache on Switch-E

 Switch-E# ping 192.168.1.20 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.20, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms Switch-E# ping 192.168.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms Switch-E# ping 192.168.1.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms Switch-E# show arp Protocol  Address          Age (min)  Hardware Addr   Type   Interface Internet  192.168.1.1             0   0009.b7aa.9b40  ARPA   Vlan100 Internet  192.168.1.2             0   0009.b7aa.9c80  ARPA   Vlan100 Internet  192.168.1.10            0   0000.0c07.ac01  ARPA   Vlan100

In Example 5-58, the shaded lines indicate each of the entries in the ARP cache of Switch-E. Notice that the MAC addresses associated with the VLAN interface IP addresses of Switch-A and Switch-B (192.168.1.1 and 192.168.1.2, respectively) are physical MAC addresses (e.g., 0009.b7aa.9b40), while the MAC address associated with the HSRP group address is based upon the special MAC address family used for HSRP. You can see from the MAC address associated with the HSRP group address 192.168.1.10, that the HSRP group ID is 1, as indicated by the last two hex digits of the MAC address (01).

Verifying Connectivity

All of the required Layer 2 and Layer 3 configuration for the network is now in place. During the configuration tasks in this scenario, much of the network connectivity configured was verified immediately after configuration; hence, network connectivity under normal working operation has been verified. The only remaining verification required is to test how the network reacts during a network failure. In this section, the network path from the access layer to the core of the network is verified during normal operation, and then a network failure is simulated to ensure that the network converges to a working topology in a correct and timely manner.

To verify the path taken for packets sent while the network is in a fully operational state (i.e., all routing devices are operational), you can use the tracert utility on Windows (or traceroute on Cisco IOS). Example 5-59 demonstrates the use of this utility on Host-A in VLAN 100 for determining the path to the 10.1.1.0/24 network in the core.

Example 5-59. Determining the Network Path from Host-A to the Core

 C:\WINXP\SYSTEM32> tracert d 10.1.1.1 Tracing route to 10.1.1.1 over a maximum of 30 hops   1     1 ms     1 ms     1 ms  192.168.1.1   2    20 ms     8 ms     8 ms  10.1.1.1 Trace complete.

In Example 5-59, although the configured default gateway on Host-A is 192.168.1.10, the first response for both traceroutes is from 192.168.1.1 (physical interface on Switch-A), which confirms that Switch-A is indeed the active router for 192.168.1.10.

NOTE

The d option used with the tracert command tells Windows not to attempt to resolve IP addresses to DNS names, which speeds up the traceroute process.

Example 5-60 demonstrates the use of the tracert utility on Host-B in VLAN 200 for determining the path to the 10.1.1.0/24 network in the core.

Example 5-60. Verifying the Network Path from Host-B to the Core

 C:\WINXP\SYSTEM32> tracert d 10.1.1.1 Tracing route to 10.1.1.1 over a maximum of 30 hops   1     1 ms     1 ms     1 ms  192.168.1.2   2   18 ms     12 ms     8 ms  10.1.1.1 Trace complete.

Notice in Example 5-60 that although the configured default gateway on Host-B is 192.168.1.20, the first response in the traceroute is from 192.168.1.2 (physical interface on Switch-B), which confirms that Switch-B is the active router for 192.168.1.20. This means that Switch-A and Switch-B are load sharing because each router is active for one of HSRP groups.

Now that the active routers have been verified on VLAN 100 and VLAN 200, it is time to test how the network responds to failure. When testing HSRP failover, it is useful to generate a constant stream of traffic between devices that are affected by the HSRP failover event, so you can monitor when connectivity is lost and how long it takes for connectivity to be restored. Example 5-61 shows how to generate a continuous ping on Host-A.

Example 5-61. Establishing a Continuous ping Between Host-A and Host-B

 C:\WINXP\SYSTEM32> ping 192.168.2.100 -t Pinging 192.168.2.100 with 32 bytes of data: Reply from 192.168.2.100: bytes=32 time<1ms TTL=255 Reply from 192.168.2.100: bytes=32 time<1ms TTL=255 Reply from 192.168.2.100: bytes=32 time<1ms TTL=255 Reply from 192.168.2.100: bytes=32 time<1ms TTL=255 Reply from 192.168.2.100: bytes=32 time<1ms TTL=255 ... (Output Repeated Continuously) ...

In Example 5-61, ping packets are generated continuously between VLAN 100 and VLAN 200, with replies received continuously while the network is up and running.

While you are keeping a close eye on the continuous ping established in Example 5-61, Example 5-62 shows what happens to the continuous ping after Switch-A is powered off.

Example 5-62. Continuous ping Between Host-A and Host-B after Switch-A is Powered off

 Reply from 192.168.2.100: bytes=32 time=1ms TTL=255 Reply from 192.168.2.100: bytes=32 time=1ms TTL=255 Reply from 192.168.2.100: bytes=32 time=1ms TTL=255 Request timed out. Request timed out. Reply from 192.168.2.100: bytes=32 time=1ms TTL=255 Reply from 192.168.2.100: bytes=32 time=1ms TTL=255

In Example 5-62, the first shaded line shows what happens immediately after Switch-A is powered off. Because Switch-A is the active router for the default gateway (192.168.1.10) of Host-A, powering the switch off causes a disruption. However, the default HSRP timers are in place for the HSRP group, so Switch-B waits 10 seconds before declaring Switch-A to be down and assuming the active role for the 192.168.1.10 VIP. Because Host-A has a ping timeout of 5 seconds by default (the default on Windows XP), you see two Request timed out messages before connectivity is re-established, and the ping requests are responded to, as indicated by the second shaded line.

You should be able to verify that Switch-B is now the active router for the 192.168.1.10 group. Example 5-63 shows the output of the show standby brief command on Switch-B.

Example 5-63. Verifying HSRP Status on Switch-B

 Switch-B# show standby brief                      P indicates configured to preempt.                      | Interface   Grp Prio P State    Active addr     Standby addr    Group addr Vl100       1   175  P Active   local           unknown         192.168.1.10 Vl200       0   175  P Active   local           unknown         192.168.2.10

Notice that Switch-B has become the active router for the 192.168.1.10 VIP. You can see that currently no HSRP communication with Switch-A exists, as indicated by the text "unknown" in the Standby addr column. This means that Switch-B cannot detect any other HSRP routers.

At this stage, if Switch-A is powered on, after bootup is complete, Switch-A should preempt the active router role for the 192.168.1.10 VIP. On Switch-B, you can monitor these events by using the debug standby events command. Example 5-64 demonstrates the use of this command while Switch-A boots up.

Example 5-64. Monitoring HSRP Events

 Switch-B# debug standby events HSRP Events debugging is on 01:07:39: SB1: Vl100 Active: j/Coup rcvd from higher pri router (200/192.168.1.1) 01:07:39: SB1: Vl100 Active router is 192.168.1.1, was local 01:07:39: SB1: Vl100 Active -> Speak 01:07:39: %STANDBY-6-STATECHANGE: Vlan100 Group 1 state Active -> Speak 01:07:39: SB1: Vl100 Redundancy "hsrp-Vl100-1" state Active -> Speak 01:07:49: SB1: Vl100 Speak: d/Standby timer expired (unknown) 01:07:49: SB1: Vl100 Standby router is local 01:07:49: SB1: Vl100 Speak -> Standby 01:07:49: SB1: Vl100 Redundancy "hsrp-Vl100-1" state Speak -> Standby

In Example 5-64, you can see that after Switch-A has been restored a Coup message is received from Switch-A indicating it has the highest priority for the HSRP group and is assuming the active role. Switch-B changes its state from Active to Speak, and then from Speak to Standby, because Switch-A has assumed the active role.

NOTE

When a router preempts to takeover the active role, you might notice a slight disruption to traffic using the VIP.

Now it is time to test the interface tracking feature. With interface tracking, an interface failure on the active router causes it to decrement its priority for a particular HSRP group, which might cause another router in the group to preempt the active role. Figure 5-19 demonstrates what happens during interface tracking.

Figure 5-19. Interface Tracking

In Figure 5-19 the following events occur:

Step 1.

Switch-A is the active router for the HSRP group. On Switch-C, the interface to Switch-A is shut down, causing the line protocol to go down on the interface. At this point, any traffic sent to Switch-A that is to be routed to Switch-C cannot be sent via Switch-C because the interface to Switch-C is down.

NOTE

In the topology of Figure 5-19, Switch-A actually reroutes traffic to Switch-B because of the dynamic routing protocols configured in the network.

Step 2.

Switch-A decrements its group priority in response to a tracked interface going down. The decremented priority is immediately transmitted in a Hello message to all other HSRP routers.

Step 3.

Switch-B receives the Hello message from Switch-A and detects that it now has a higher priority than Switch-A for the HSRP group. Assuming that Switch-B is configured to preempt, Switch-B assumes the active role. Traffic sent from Host-A is now routed by Switch-B.

Now that you understand how interface tracking works, it is time to see interface tracking in action. Assuming the continuous ping established in Example 5-61 is still running, Example 5-65 shows the process of shutting down interface fa0/3 on Switch-C. This causes the priority for the 192.168.1.10 VIP to be decremented to 150, meaning Switch-B preempts the active router role because it has a higher priority of 175. Example 5-66 shows the resulting effect on the continuous ping running on Host-A.

Example 5-65. Shutting Down a Tracked Interface on Switch-C

 Switch-C# configure terminal Switch-A(config)# interface FastEthernet 0/3 Switch-A(config-if)# shutdown

Example 5-66. Continuous ping Between Host-A and Host-B after the FastEthernet0/3 Interface on Switch-C is Shut Down

 Reply from 192.168.2.100: bytes=32 time<1ms TTL=255 Reply from 192.168.2.100: bytes=32 time<1ms TTL=255 Reply from 192.168.2.100: bytes=32 time<1ms TTL=255 Reply from 192.168.2.100: bytes=32 time=2ms TTL=255 Reply from 192.168.2.100: bytes=32 time<1ms TTL=255 Reply from 192.168.2.100: bytes=32 time<1ms TTL=255

In Example 5-66, notice the response time for the shaded reply. The response time is 2 ms, as opposed to <1 ms response times for all other ping replies. This "glitch" represents the slight delay caused by the active router changing from Switch-A to Switch-B. Clearly, this slight delay has a negligible effect on end-to-end connectivity for the network. The "smooth" failover is due to the fact that Switch-A immediately transmits its decremented priority for the group to Switch-B when interface FastEthernet0/3 on Switch-A is shut down. Switch-B then immediately assumes the active role because it is configured to preempt.

To verify that Switch-A has indeed decremented its priority, Example 5-67 demonstrates the use of the show standby command on Switch-A.

Example 5-67. Checking HSRP Status on Switch-A after Interface Failure

 Switch-A# show standby Vlan100 - Group 1   Local state is Standby, priority 150 (confg 200), may preempt   Hellotime 3 sec, holdtime 10 sec   Next hello sent in 2.343   Virtual IP address is 192.168.1.10 configured   Active router is 192.168.1.2 expires in 00:00:07   Standby router is local   Virtual mac address is 0000.0c07.ac01 Priority tracking 2 interfaces, 1 down:     Interface             Decrement  State     FastEthernet0/3           50      Down     FastEthernet0/4           50      Up ... (Output Truncated) ...

In Example 5-67, notice in the first shaded line that the priority of the HSRP group for 192.168.1.10 is now 150 and that there is also an indication that the configured priority is 200. The current status for the group is also indicated as standby, which means Switch-B is the active router. The second to last shaded line of the output confirms that the current state of the FastEthernet0/3 is down.

Configuration Tasks

Configuring Layer 2 Parameters

Configuring Layer 2 Parameters on Switch-A

Example 5-15. Configuring VLANs and Trunking on Switch-A

Configuring Layer 2 Parameters on Switch-B

Example 5-16. Configuring VLANs on Switch-B

Example 5-17. Verifying the Trunk Between Switch-A and Switch-B

Configuring Inter-VLAN Routing

Configuring Switch-A for Inter-VLAN Routing

Example 5-18. Configuring a Routed Physical Interface on Switch-A

Example 5-19. Creating an SVI on Switch-A

Example 5-20. Configuring IP Routing on Switch-A

Configuring Switch-B for Inter-VLAN Routing

Example 5-21. Configuring the sc0 Management Interface on Switch-B

Example 5-22. Configuring Gigabit Ports on Switch-B to Router Module as an EtherChannel Trunk

Example 5-23. Establishing a Management Connection to the Router Module in Switch-B

Example 5-24. Checking the Router Module

Example 5-25. Configuring the Router Module

Example 5-26. Configuring IP and Inter-VLAN Routing on Switch-B-L3

Example 5-27. Configuring Inter-VLAN Routing on Switch-B-L3

Example 5-28. Verifying IP Routing on Switch-B-L3

Verifying Connectivity

Example 5-29. Testing ping Connectivity from Switch-A to Switch-B-L3

Example 5-30. Testing ping Connectivity from Switch-B-L3 to Switch-A

Example 5-31. Testing ping Connectivity from Host-A to Host-B

Scenario 5-3: Implementing a Redundant Multilayer Topology

Figure 5-16. Scenario 5-3 Topology

Understanding the Scenario Layer 3 Topology

Figure 5-17. Scenario 5-3 IP Topology

Table 5-1. Scenario 5-3 Requirements

Configuration Tasks

Configuring Layer 2 Parameters

Configuring the Distribution Layer Switches

Example 5-32. Configuring Layer 2 Parameters on Switch-A

Example 5-33. Configuring VTP and Verifying VLANs on Switch-B

Example 5-34. Configuring Layer 2 Parameters on Switch-B

Example 5-35. Verifying Spanning Tree

Configuring the Access Layer Switches

Example 5-36. Configuring Layer 2 Parameters on Switch-E

Configuring Layer 3 Parameters

Configuring the Core

Configuring Routed Interfaces

Example 5-37. Configuring a Layer 3 EtherChannel Bundle on Switch-C

Example 5-38. Configuring a Layer 3 EtherChannel Bundle on Switch-D

Example 5-39. Verifying IP Connectivity between Switch-C and Switch-D

Example 5-40. Configuring Routed Interfaces to Distribution Layer on Switch-C

Example 5-41. Configuring Routed Interfaces to Distribution Layer on Switch-D

Configuring Dynamic Routing

Example 5-42. Configuring OSPF on Switch-C

Example 5-43. Configuring OSPF on Switch-D

Figure 5-18. OSPF and Inter-Area Summarization

Example 5-44. Verifying OSPF Neighbors on Switch-C

Configuring the Distribution Layer

Configuring Routed Interfaces

Example 5-45. Configuring Routed Interfaces on Switch-A

Example 5-46. Configuring Routed Interfaces on Switch-B

Example 5-47. Verifying IP Connectivity from Switch-A

Configuring Dynamic Routing

Example 5-48. Configuring OSPF on Switch-A

Example 5-49. Configuring OSPF on Switch-B

Example 5-50. Verifying OSPF Neighbors on Switch-A

Example 5-51. Viewing the IP Routing Table on Switch-A

Configuring HSRP

Example 5-52. Configuring HSRP for the 192.168.1.10 VIP on Switch-A

Example 5-53. Configuring HSRP for the 192.168.1.10 VIP on Switch-A

Example 5-54. Configuring HSRP for the 192.168.2.10 VIP on Switch-A

Example 5-55. Configuring HSRP for the 192.168.2.10 VIP on Switch-B

Example 5-56. Verifying HSRP

Configuring the Access Layer

Example 5-57. Configuring IP on Switch-E

Example 5-58. Testing Connectivity and Viewing the ARP Cache on Switch-E

Verifying Connectivity

Example 5-59. Determining the Network Path from Host-A to the Core

Example 5-60. Verifying the Network Path from Host-B to the Core

Example 5-61. Establishing a Continuous ping Between Host-A and Host-B

Example 5-62. Continuous ping Between Host-A and Host-B after Switch-A is Powered off

Example 5-63. Verifying HSRP Status on Switch-B

Example 5-64. Monitoring HSRP Events

Figure 5-19. Interface Tracking