Chapter 10. Configuring Ethernet Switching
This chapter covers the following exam topics:
2.2. Describe classic Ethernet fundamentals
2.2.a. Forward
2.2.b. Filter
2.2.c. Flood
2.2.d. MAC address table
2.3. Describe switching concepts and perform basic configuration
Cisco Nexus switches are designed to have robust Layer 2 Ethernet switching features in addition to feature-rich Layer 3 routing functionality. This product family is known as a multilayer type of switch because it has the hardware and software capable of using both forwarding methods exclusively (Layer 2 only switch or Layer 3 only router) or it can act as a Layer 3 router and a Layer 2 switch at the same time.
This chapter explains a large variety of Layer 2 switching features, broken into two parts. The first half of the chapter explains many switch administrative features that happen to work the same way on all models of Nexus switches; this chapter keeps these common features together so that you can easily refer to them later when working with the different models within the Nexus product family. The second half of the chapter shows how to configure some switch-specific features on the Cisco Nexus platforms series of switches, many of which impact how a switch forwards frames.
“Do I Know This Already?” Quiz
Use the “Do I Know This Already?” quiz to help decide whether you might want to skim this chapter, or a major section, moving more quickly to the “Exam Preparation Tasks” section near the end of the chapter. Table 10-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. For thorough explanations, see Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes.”
1. Which command enables you to configure a user named Fred to have read-only access to the Nexus switch CLI?
a. username Fred read-only
b. username Fred password Cisco123 role network-admin
c. username Fred password Cisco123 role network-operator
d. user Fred password Cisco123 role read-only
2. An engineer had formerly configured a Cisco Nexus switch to allow Telnet access so that the switch expected a password of mypassword from the Telnet user admin with the role of network-admin. The engineer then changed the configuration to support Secure Shell. Which of the following commands could have been part of the new configuration? (Choose two answers.)
a. A username name password password vty mode subcommand.
b. A username name password password global configuration command.
c. A login local vty mode subcommand.
d. None of these answers is correct.
3. The following command was copied and pasted into configuration mode when a user was telnetted into a Cisco switch:
banner motd #this is the login banner #
Which of the following is true about what occurs the next time a user logs in from the console?
a. No banner text is displayed.
b. The banner text “this is” is displayed.
c. The banner text “this is the login banner” is displayed.
d. The banner text “Login banner configured, no text defined” is displayed.
4. Which of the following describes what VRF context the management interface (mgmt0) is in on a Nexus switch by default?
a. In the Management Virtual Routing and Forwarding (VRF) instance.
b. In the Default Virtual Routing and Forwarding (VRF) instance.
c. Not in a Virtual Routing and Forwarding (VRF) instance.
d. None of the answers is correct.
5. In which of the following modes of the CLI could you configure the speed setting for interface Ethernet 1/5?
a. User mode
b. Enable mode
c. Global configuration mode
d. VLAN mode
e. Interface configuration mode
Foundation Topics
Configuration of Features in Common on All Nexus Switches
This is the first of the two major sections of this chapter. It examines the configuration of several features, all done the exact same way on all Nexus switches. In particular, this section examines how to secure access to the command-line interface (CLI) and also covers various settings for the console. Note that although this section refers to only switches, and not routers, the commands apply to both.
Securing the Switch CLI
The first step in securing a switch is to secure access to the CLI. Securing the CLI includes protecting access to the Cisco Nexus switch’s network-admin role, because from the network-admin role, an attacker could reload the switch or change the configuration.
For example, consider a user who accesses a switch from the console. The default console configuration settings allow a console user to access the Nexus switch with a default username of admin in the network-admin role, with no password required. These defaults make some sense, because when you use the console, you are typically sitting near or next to the switch. If you can touch the switch, even if the console has all the available password protections, you can still perform the switch password recovery/reset procedure in 5 minutes and get into the switch. So, by default, console access is open; however, most network engineers add login security to the switch for all access methods by providing a strong password for the admin account. A strong password is one that is not easy to decipher.
Note
To see the password recovery/reset procedures, go to Cisco.com and search for the phrase “password recovery procedure for Cisco NX-OS.”
This section examines many of the configuration details related to accessing EXEC mode on a Cisco Nexus switch. Management interface IP configuration was covered in Chapter 5, “Installing and Operating Nexus Switches,” in the section “Management Interface.”
In particular, this section covers the following topics:
Secure Shell (SSH)
Basics of secure access with authentication servers
Securing Access with Local Usernames and Passwords
Cisco Nexus switches support other login authentication methods that use a username and password so that each user has unique login details that do not have to be shared. One method configures the username/password pairs locally on the switch, and the other relies on an external server called an authentication, authorization, and accounting (AAA) server. (The server could be the same server used for logins for other servers in the network.) This book covers the configuration using locally configured usernames/passwords.
In addition to the username and password, each user can be assigned to a role, as discussed in Chapter 5. Based on the username and password provided and the role assigned by the administrator, the user is given access to the entire switch configuration and verification commands or just a subset.
When a Telnet or SSH user connects to the switch configured as shown in Figure 10-1, the user is prompted first for a username and then for a password. The username/password pair must be from the list of local usernames; otherwise, the login is rejected.
Note
The default admin username cannot be deleted or modified and always belongs to the network-admin role.
Securing Access with External Authentication Servers
Using a local list of usernames and passwords on a switch or router works well in small networks. However, using locally configured username/password pairs means that every switch and router needs the configuration for all users who might need to log in to the devices. Then, when any changes need to happen, like an occasional change to the passwords, the configuration of all devices must be changed.
Cisco switches and routers support an alternative way to keep track of valid usernames and passwords by using an external AAA server. When using a AAA server for authentication, the switch (or router) simply sends a message to the AAA server asking whether the username and password are allowed, and the AAA server replies. Figure 10-2 shows an example, with the user first supplying his username and password, the switch asking the AAA server whether they are valid, and the server replying to the switch stating that the username/password pair is valid.
While the figure shows the general idea, note that the information flows with a couple of different protocols. On the left, the connection between the user and the switch or router uses Telnet or SSH. On the right, the switch and AAA server typically use either the RADIUS or TACACS+ protocol, both of which encrypt the passwords as they traverse the network.
Configuring Secure Shell
The switch already runs an SSH server by default, accepting incoming SSH connections from SSH clients. In addition, the switch is already configured with a cryptography key, used to encrypt the data. Because the Nexus switch is already configured for SSH, recommended practice dictates that you provide a strong password to the default admin user and create any additional usernames and roles that are needed to access the Cisco Nexus switch. The following list details the steps for a Cisco Nexus switch to change any of the default SSH configurations using local usernames.
Step 1. Configure the switch with local usernames, passwords, and roles on the AAA server.
Step 2. Disable the SSH feature:
(config)# no feature ssh
Step 3. Configure the switch to generate a matched public and private key pair to use for encryption, using one command in config mode:
ssh key (dsa | rsa (bits) (force)
Step 4. Enable the SSH feature:
(config)# feature ssh
Seeing the configuration happen in configuration mode, step by step, can be particularly helpful with SSH. Note in particular that the ssh key command actually prompts the user for more information and generates some messages while the key is being generated. Example 10-1 shows the commands being configured, with the encryption key as the final step.
Example 10-1 SSH Configuration Process
Switch# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
! Step 1's username command happens next
Switch(config)# username admin passwordCisc0123 role Network-admin
Switch(config)# username chad passwordCisc0123 role Network-operator
!
! Step 2's feature commands happen next
Switch(config)# no feature ssh
XML interface to system may become unavailable since ssh is disabled
!
! Step 3's key command happens next
Switch(config)# ssh key rsa ?
<CR>
<1024-2048> Enter number of bits (in multiples of 8)
Switch(config)# ssh key rsa 2048
generating rsa key(2048 bits).....
....
generated rsa key
!
! Step 4's feature command happens next
Switch(config)# feature ssh
Switch(config)# exit
Two key commands give some information about the status of SSH on the switch. First, the show ssh server command lists status information about the SSH server itself. The show ssh command then lists information about each SSH client currently connected into the switch. Example 10-2 shows samples of each, with user Wendell currently connected to the switch.
Example 10-2 Displaying SSH Status
Switch# show ssh server
ssh version 2 is enabled
Switch# show ssh key
**************************************
rsa Keys generated:Thu Jan 30 00:08:15 2014
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDICL7II0e18J4pEbgJZ2LnXrKG7xakmhKnIlwf5SRM
lYc3++H5ysdD7dVY2oYYV7lpEjmeAn1lATcn/pvRX+DmqJhl+u9ExQPx9IFVx5fKDQh8MTEKKxIGaISC
ihRYDQFGKGYS3vB1y6uWagXre177XBQKEL9yZ5KXgnYHk9z2OVhE7xa/6mZBUXqb40Id0rheU4GAib5R
TW8S+SFbM59UUXea/09Z4a8v6nSvz7pbSuWzbTfKHieqF5HQSGNb40NJcZUD38jhNq8HnEY1/Y1QhT1i
DoPHnqrkh6h0Dyit8DEWY5Y0aDLA/dTOKP9wQ0/7Uy7DPRNP9nYPdtZB4sEL
bitcount:2048
fingerprint:
ad:0d:54:95:ea:5e:f8:94:ae:28:3e:4d:37:a8:c7:47
Note that this example is using SSH Version 2 rather than Version 1; it is the only version of SSH that NX-OS supports. SSH v2 improves the underlying security algorithms over SSH v1 and adds some other small advantages, such as banner support.
Banners
Cisco Nexus switches can display a banner to notify users they are attempting to log in to a device. This banner appears prior to the user authentication process and serves as a warning to deter unauthorized users from attempting to log in. A banner is simply some text that appears on the screen for the user. You can configure a Cisco Nexus switch to display a banner for use with all login methods (vty, console), before login.
The banner motd global configuration command can be used to configure a banner to be displayed before login for all login types. NX-OS only provides one banner type called Message of the Day (MOTD). IOS has three different types for different login types: console, SSH, and Telnet. The first nonblank character after the banner type is called a beginning delimiter character. The banner text can span several lines, with the CLI user pressing Enter at the end of each line. The CLI knows that the banner has been configured as soon as the user enters the same delimiter character again.
Example 10-3 shows the configuration process for banner MOTD on a Cisco Nexus switch. The banner in Example 10-3 uses a Z as the delimiter character to start and end the message. It is important to know that any character can be used with the exception of the quote (“) or percentage (%) character. Also, the last banner command shows multiple lines of banner text.
Example 10-3 Banner MOTD Configuration
7K-B# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
7K-B(config)# banner motd Z
Enter TEXT message. End with the character 'Z'.
> Authorized Access Only!
> Z
! Below, the user of this Nexus switch exits the Telnet connection, and logs back in,
! seeing the MOTD banner, then the password prompt,
7K-B# exit
Connection closed by foreign host.
telnet 1.1.1.1
Authorized Access Only!
login: admin
Password:
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2013, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained in this software are
owned by other third parties and used and distributed under
license. Certain components of this software are licensed under
the GNU General Public License (GPL) version 2.0 or the GNU
Lesser General Public License (LGPL) Version 2.1. A copy of each
such license is available at
http://www.opensource.org/licenses/gpl-2.0.php and
http://www.opensource.org/licenses/lgpl-2.1.php
7K-B#
History Buffer Commands
When you enter commands from the CLI, the last several commands are saved in the history buffer. As mentioned in Chapter 5, you can use the up-arrow key, or press Ctrl+P, to move back in the history buffer stack to retrieve a command you entered a few commands ago. This feature makes it very easy and fast to use a set of commands repeatedly. Table 10-2 lists some of the key commands related to the history buffer.
The logging synchronous and exec-timeout Commands
This next short section looks at a couple of ways to make using the console a little more user friendly, by asking the switch to not interrupt with log messages and by controlling how long you can be connected to the console before getting forced out.
The console automatically receives copies of all unsolicited syslog messages on a switch. The idea is that if the switch needs to tell the network administrator some important and possibly urgent information, the administrator might be at the console and might notice the message.
The display of these messages at the console can be disabled and enabled with the no logging console and logging console global commands, respectively. For example, when working from the console, if you want to temporarily not be bothered by log messages, you can disable the display of these messages with the no logging console global configuration command, and then when finished, you can enable them again.
Another way to improve the user experience is to control timeouts from the console. By default, the Cisco Nexus switch’s timeout setting is 0, which means it never times out. The exec-timeout minutes seconds line subcommand lets you set the length of that inactivity timer.
Example 10-4 shows the syntax for these two commands, both on the console line. Note that both can be applied to the vty lines as well, for the same reasons.
Example 10-4 Defining Console Inactivity Timeouts and When to Display Log Messages
line console
exec-timeout 5
Nexus Switch Configuration and Operation
Cisco switches work very well when received from the factory, without any configuration added. Cisco Nexus Platforms leave the factory with default settings, with all interfaces enabled (a default configuration of no shutdown) and with auto-negotiation enabled for ports that can use it (a default configuration of duplex auto and speed auto). All interfaces default to be part of VLAN 1 (switchport access vlan 1). All you have to do with a new Cisco switch is make all the physical connections—Ethernet cables and power cord—and the switch starts working.
In most enterprise networks, you will want the switch to operate with some different settings as compared with the factory defaults. The second half of this chapter discusses some of those settings, with Chapter 7, “VLAN Trunking and Configuration,” discussing more. (Also note that the details in this section differ from the configuration on a router.) In particular, this section covers the following topics:
Switched virtual interface (SVI)
Interface configuration (including speed and duplex)
Securing unused switch interfaces
Predicting the contents of the MAC address table
Switched Virtual Interface Concept Inside a Switch
A typical Layer 2 Cisco Nexus Platforms switch can use only one Layer 3 VLAN interface (SVI) without a Layer 3 module or license, but the network engineer can choose which VLAN interface to enable this on (typically VLAN 1). All interfaces on a Cisco Nexus switch belong to a Virtual Routing and Forwarding (VRF) instance called Default, except for the management interface, which belongs to the Management VRF. Within the “default” VRF, the network engineer can configure a single Layer 3 interface called a switched virtual interface (SVI). Example 10-5 shows the configuration of an SVI on VLAN 1.
Note
Some Cisco switches, called Layer 2 switches, forward Ethernet frames, as discussed in depth in Chapter 3, “Fundamentals of Ethernet LANs.” Other Cisco switches, called multilayer switches or Layer 3 switches, can also route IP packets using the Layer 3 logic normally used by routers. Layer 3 switches configure IP addresses on more than one VLAN interface at a time. This chapter assumes all switches are Layer 2 switches. Chapter 6, “VLAN and Trunking Concepts,” further defines the differences between these types of Nexus switches.
Configuring IPv4 on a Cisco Nexus Switch
A switch configures its IPv4 address and mask on this special NIC-like VLAN interface. The following steps list the commands used to configure IPv4 on a switch, assuming that the IP address is configured to be in VLAN 1, with Example 10-5, which follows, showing a configuration example.
Step 1. Enable the SVI feature on the switch using the feature interface-vlan command.
Step 2. Enter VLAN 1 configuration mode using the interface vlan 1 global configuration command.
Step 3. Assign an IP address and mask using the ip address ip-address mask interface subcommand.
Step 4. If not already enabled, enable the VLAN 1 interface using the no shutdown interface subcommand.
Step 5. (Optional) Add the ip name-server ip-address1 ip-address2... global command to configure the switch to use DNS to resolve names into their matching IP address.
Example 10-5 Switch Static IP Address Configuration
Switch# configure terminal
Switch(config)# feature interface-vlan
Switch(config)# interface vlan 1
Switch(config-if)# ip address 192.168.1.200 255.255.255.0
or...
Switch(config-if)# ip address 192.168.1.200/24
Switch(config-if)# no shutdown
00:25:07: %LINK-3-UPDOWN: Interface Vlan1, changed state to up
00:25:08: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed
state to up
Switch(config-if)# exit
As a side note, this example shows a particularly important and common command: the [no] shutdown command. To administratively enable an interface on a switch, use the no shutdown interface subcommand; to disable an interface, use the shutdown interface subcommand. The messages shown in Example 10-5, immediately following the no shutdown command, are syslog messages generated by the switch stating that the switch did indeed enable the interface.
Verifying IPv4 on a Switch
The switch IPv4 configuration can be checked in several places. First, you can always look at the current configuration using the show running-config command. Second, you can look at the IP address and mask information using the show interface vlan x command, which shows detailed status information about the VLAN interface in VLAN x. Example 10-6 shows sample output from these commands to match the configuration in Example 10-5.
Example 10-6 Verifying DHCP-Learned Information on a Switch
Switch# show interface vlan 1
Vlan1 is up, line protocol is up
Hardware is EtherSVI, address is 0026.980b.55c1
Internet Address is 192.168.1.200/24
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
! lines omitted for brevity
The output of the show interfaces vlan 1 command lists two very important details related to switch IP addressing. First, this show command lists the interface status of the VLAN 1 interface—in this case, up and up. If the VLAN 1 interface is not up, the switch cannot use its IP address to send and receive traffic. Notably, if you forget to issue the no shutdown command, the VLAN 1 interface remains in its default shutdown state and is listed as administratively down in the show command output.
Second, note that the output lists the interface’s IP address on the third line. If you statically configure the IP address, as in Example 10-5, the IP address will always be listed.
Configuring Switch Interfaces
NX-OS uses the term interface to refer to physical ports used to forward data to and from other devices. Each interface can be configured with several settings, each of which might differ from interface to interface.
NX-OS uses interface subcommands to configure these settings. For example, interfaces can be configured to use the duplex and speed interface subcommands to configure those settings statically, or an interface can use auto-negotiation (the default). Example 10-7 shows how to configure duplex and speed, as well as the description command, which is simply a text description that can be configured by the administrator.
Example 10-7 Interface Configuration Basics
Switch# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)# interface Ethernet 1/2
Switch(config-if)# duplex full
Switch(config-if)# speed 10000
Switch(config-if)# description Server1 connects here
Switch(config-if)# exit
Switch(config)# interface Ethernet 1/11 - 20
Switch(config-if-range)# description end-users connect_here
Switch(config-if-range)# duplex full
Switch(config-if-range)# speed 10000
Switch(config-if-range)# ^Z
Switch#
Switch# show interface status
Port Name Status Vlan Duplex Speed Type
------------------------------------------------------------------------------------
Eth1/1 -- connected f-path full 10G SFP-H10GB-C
Eth1/2 Server1 connects here connected 1 full 10G 10Gbase-SR
Eth1/3 -- sfpAbsent 1 full 10G --
Eth1/4 -- sfpAbsent 1 full 10G --
Eth1/5 -- sfpAbsent 1 full 10G --
Eth1/6 -- sfpAbsent 1 full 10G --
Eth1/7 -- sfpAbsent 1 full 10G --
Eth1/8 -- sfpAbsent 1 full 10G --
Eth1/9 -- sfpAbsent trunk full 10G --
Eth1/10 -- sfpAbsent 1 full 10G --
Eth1/11 servers-connect-here sfpAbsent 1 full 10G --
Eth1/12 servers-connect-here sfpAbsent 1 full 10G --
Eth1/13 servers-connect-here sfpAbsent 1 full 10G --
Eth1/14 servers-connect-here sfpAbsent 1 full 10G --
Eth1/15 servers-connect-here vpcPeerLn t full 10G SFP-H10GB-C
Eth1/16 servers-connect-here vpcPeerLn full 10G SFP-H10GB-C
Eth1/17 servers-connect-here connected full 10G SFP-H10GB-C
Eth1/18 servers-connect-here connected full 10G SFP-H10GB-C
Eth1/19 servers-connect-here sfpAbsent 1 full 10G --
Eth1/20 servers-connect-here sfpAbsent 1 full 10G --
! lines omitted for brevity
You can see some of the details of interface configuration with both the show running-config command (not shown in the example) and the handy show interfaces status command. This command lists a single line for each interface, the first part of the interface description, and the speed and duplex settings. Some of the early entries in the output purposefully show some differences, as follows:
Ethernet 1/2 (Eth1/2): This output lists the configured speed of 100 and duplex full; however, it lists a status of connected. The connected status means that the physical link is currently working, which means it has been enabled with a cable connection and the no shutdown command.
Also, note that for the sake of efficiency, you can configure a command on a range of interfaces at the same time using the interface command. In the example, the interface Ethernet 1/11 - 20 command tells NX-OS that the next subcommand(s) applies to interfaces Eth1/11 through Eth1/20. You can also use a range of interfaces that are not contiguous, such as interface Ethernet 1/11, 2/20, 2/22.
Note
Configuring both the speed and duplex on a Cisco switch interface disables auto-negotiation.
Securing Unused Switch Interfaces
The default settings on Cisco switches work great if you want to buy a switch, unbox it, plug it in, and have it immediately work without any other effort. Those same defaults have an unfortunate side effect of worse security. With an all-default configuration, unused interfaces might be used by an attacker to gain access to the LAN. So, Cisco makes some general recommendations to override the default interface settings to make the unused ports more secure, as follows:
Administratively disable the interface using the shutdown interface subcommand.
Prevent VLAN trunking by making the port a nontrunking interface using the switchport mode access interface subcommand.
Assign the port to an unused VLAN using the switchport access vlan number interface subcommand.
Set the native VLAN to not be VLAN 1, but to instead be an unused VLAN, using the switchport trunk native vlan vlan-id interface subcommand. (The native VLAN is discussed in Chapter 6.)
Frankly, if you just shut down the interface, the security exposure goes away, but the other tasks prevent any immediate problems if someone else comes around and enables the interface by configuring a no shutdown command.
Predicting the Contents of the MAC Address Table
As explained in Chapter 3, switches learn MAC addresses and then use the entries in the MAC address table to make a forwarding/filtering decision for each frame. To know exactly how a particular switch will forward an Ethernet frame, you need to examine the MAC address table on a Cisco Nexus switch. To derive how this is done, we will use Figure 10-3 and manually build what we believe to be a MAC address table for each switch. It is important to understand how the switch will utilize the MAC address table to forward flows. Your task is to take out a piece of paper and try to build what you believe to be the MAC address table on each Nexus switch.
Now that we have built our MAC address tables manually, you need to validate whether you got it right. The best way to validate what your MAC address tables contain is to use the command show mac-address table. Figure 10-4 shows the MAC address table for each switch. Let’s break this down to understand how it was built and how the switch will use it to forward on a Layer 2 network between the servers in the figure.
The MAC table entries you predict in this case define where you think frames will flow. Even though the sample network in Figure 10-3 shows only one physical path through the Ethernet LAN, the exercise should be worthwhile because it forces you to correlate what you would expect to see in the MAC address table with how the switches forward frames. Figure 10-4 shows the resulting MAC table entries for servers. Let’s work through some scenarios where we want to understand how the switch will forward frames between S1 and S2 as well as S1 and S3.
Scenario 1: Communication Between S1 and S2
When S1 sends a frame destined to the MAC address of S2, the frame will be received in on interface Ethernet 1/1 on Switch 1. The list that follows outlines the steps that the switch will take to get the frame to its destination of S2 on the same network (VLAN 10):
Step 1. Switch 1 will do a lookup for the destination MAC address of 0200.2222.2222 in its MAC address table.
Step 2. Switch 1 sees that the destination address of S2 is learned through its Ethernet 1/2 interface.
Step 3. Switch 1 forwards the frame sourced from S1 to the destination of S2 out of the interface of Ethernet 1/2, which is where the MAC address of S2 has been learned.
Step 4. S2 receives the frame from S1.
In this scenario, one lookup is done on the Switch 1 MAC address table and is sent to the output interface where the destination MAC address was learned.
Scenario 2: Communication from S1 to S3
The list that follows outlines the detailed steps that happen across the communication path between S1 and S3 on VLAN 10 when S1 sends a frame into interface Ethernet 1/1:
Step 1. Switch 1 will do a lookup for the destination MAC address of 0200.5555.5555 of S3 in its MAC address table.
Step 2. Switch 1 sees that the destination address of S3 is learned through its Ethernet 1/3 interface.
Step 3. Switch 1 forwards the frame sourced from S1 to the destination of S3 out of the interface of Ethernet 1/3, which is where Switch 1 has learned the MAC address of S3.
Step 4. Switch 2 receives the frame from Switch 1 on its Ethernet 1/4 interface with a source address of S1’s MAC address and a destination address of S3’s MAC address.
Step 5. Switch 2 will do a lookup for the destination MAC address of 0200.5555.5555 of S3 in its MAC address table and see that it has learned this MAC address on interface Ethernet 1/5.
Step 6. Switch 2 will forward the frame sourced from S1 to S3 out of interface Ethernet 1/5 to reach S3.
Step 7. S3 will receive the frame from S1.
As you can see in the table outputs created by learning the MAC addresses of the servers across the data center LAN in Figure 10-3, switches will always make their forwarding decision based on the destination address. Switches will learn the address of the host or servers (in our case, across their interswitch links) and label this interface between the switches and the path to get to the remote MAC addresses.
Exam Preparation Tasks
Review All Key Topics
Review the most important topics from this chapter, noted with the Key Topic icon in the outer margin of the page. Table 10-3 lists references for these key topics and the page number on which each is found.
Note
There is no need to memorize any configuration step list referenced as a key topic; these lists are just study aids.
Table 10-3 Key Topics for Chapter 10
Definitions of Key Terms
After your first reading of the chapter, try to define these key terms, but do not be concerned about getting them all correct at that time. Chapter 24, “Final Review,” directs you in how to use these terms for late-stage preparation for the exam.
Telnet
SSH
local username
VLAN interface
Command References
Tables 10-4 through 10-7 list the configuration commands used in this chapter, by general topic. Table 10-8, at the very end of the chapter, lists the EXEC commands from this chapter.
Table 10-8 Chapter 10 EXEC Command Reference