Config Router

You are here: Home / CCNA / Initial Switch Configurations

Initial Switch Configurations

by

Initial Switch Configurations

Objective:

  • Perform and verify initial switch configuration tasks including remote access management

Catalyst switches, for the most part, are designed so that the default state of the switch allows for basic Layer 2 functionality without requiring any configuration from the administrator. For example, the physical interfaces on the switch are already enabled, which means that you can plug a cable in the switch and the interface operates without requiring you to perform a no shutdown on that interface. Does that mean you don’t have to learn about Catalyst switch commands? No such luck.

NOTE
Switch Ethernet interfaces are commonly referred to as ports.

The majority of the administrative configurations such as configuring hostnames, login banners, passwords, and Telnet/SSH access are identical to the configurations of the router IOS, as described in Chapter 7, “Foundation Cisco IOS Operations.” These next sections look at a few commands and configurations that are specific to Catalyst switches.

Assigning a Management IP Address to a Switch

Cisco Layer 2 switches forward frames solely based on MAC addresses. On the other hand, Layer 3 switches and routers use IP addresses in their data forwarding decisions. So why assign an IP address to a Layer 2 switch?

Chapter 8, “Foundation Cisco Configurations,” mentions that to remotely manage a device via SSH, Telnet, or HTTP, you need to have IP connectivity to the switch. Likewise, if you were to manage the switch using SNMP, you would also have to program your management server to use its IP address to gather statistics from the switch. All these management functions assume that an IP address is assigned to the device, which in the Catalyst switch’s case does not have an IP address in its default configuration.

Unlike Cisco routers, Layer 2 switches do not assign IP addresses on all the physical interfaces. In fact, the interface to which you assign an IP address on a Layer 2 Catalyst switch is actually a virtual interface called VLAN 1 (Chapter 15, “Virtual LANs,” discusses the significance of VLAN 1). To assign an IP address to the entire switch, you use exactly the same syntax as a router’s physical interface to configure the VLAN 1 interface:

Switch(config)#interface VLAN1
Switch(config-if)#ip address 172.16.1.100 255.255.0.0
Switch(config-if)#no shutdown
01:35:19: %LINK-3-UPDOWN: Interface Vlan1, changed state to up

Defining a Default Gateway

If you were to Telnet into the switch from the terminal on the far network, the Telnet traffic would traverse through the local router, across the WAN link, through the remote router, and finally to the switch. To return the Telnet traffic back to the terminal, the switch would have to send it to a routing device, because the terminal is on another network. To instruct the switch to send any traffic destined for another network to that router, you have to define a default gateway (also known as a gateway of last resort) as shown in Figure 13.10.

The command to configure a default gateway is ip default-gateway, followed by the IP address of the router that is on the switch’s segment in Global Configuration. Using the example in Figure 13.10, the configuration would look like the following: Switch(config)#ip default-gateway 172.16.1.1

EXAM ALERT
The ip default-gateway switch command is used when a switch needs to send or return traffic to a remote network segment. The IP address specified after the ip default-gateway command is the router on the local segment that will route the traffic to the remote network.

IP Assignment Using DHCP

Similar to router interfaces, the IP assigned to the VLAN 1 interface and the default gateway can be dynamically assigned using a DHCP server. The configuration is also similar to DHCP-assigned router interfaces except that the configuration is applied to the logical VLAN 1 interface as opposed to a physical port on the switch:

Switch#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)#interface vlan 1
Switch(config-if)#ip address dhcp
Switch(config-if)#no shutdown
00:58:49: %LINK-3-UPDOWN: Interface Vlan1, changed state to up
Interface Vlan1 assigned DHCP address 172.16.1.100, mask 255.255.0.0

After the ip address dhcp command is applied, the switch sends a DHCPDISCOVER broadcast out on all switch ports assigned to VLAN1 (by default, all switch ports are assigned to VLAN1). If a configured DHCP server exists on those segments, it replies with the IP address for the VLAN 1 interface and default gateway for the switch. As such, there is no required configuration of an IP address or default gateway in the switch configuration. It must be said, however, that despite the fact that this does simplify some of the administration configuration or reconfiguration tasks that are necessary to manage a switch, it is not practical because you need to readily know the IP address of the switch to effectively manage it.

Verifying the IP address and default gateway assigned by the DHCP server cannot be achieved by showing the running or startup configuration. Instead, you can use output from the show dhcp lease command to verify the IP address and default gateway:

Switch#show dhcp lease
Temp IP addr: 172.16.1.100 for peer on Interface: Vlan1
Temp sub net mask: 255.255.0.0
DHCP Lease server: 172.16.1.1, state: 3 Bound
DHCP transaction id: 1967
Lease: 16000 secs, Renewal: 3000 secs, Rebind: 16000 secs
Temp default-gateway addr: 172.16.1.1
Next timer fires after: 00:00:32
Retry count: 0 Client-ID: cisco-0019.e86a.6fc0-Vl1
Hostname: Switch

Configuring Multiple Switch Interfaces

By design, switches may have a plethora of interfaces that may require a similar configuration. For instance, if the first 20 ports of your switch need to be set to a speed of 100mbs and full duplex, you would be undertaking quite an administrative task of typing the same commands into each interface configuration for all 20 interfaces. To save time, the Catalyst switch’s IOS
contains a navigation and configuration command shortcut called interface range that enables you to define a range of switch ports and configure them simultaneously. The configuration can be condensed to  something like this:

Switch(config)#interface range FastEthernet 0/1 - 20
Switch(config-if)#speed 100
Switch(config-if)#duplex full

TIP
Note that the syntax of the interface range command requires you to put a space between the start ing and ending interfaces in the range separated by a hyphen.

NOTE
You can manually override the default autonegotiating speed and duplex settings for each interface as demonstrated.

Configuring and Verifying Spanning Tree Protocol

Objective:

  • Verify network status and switch operation using basic utilities (including: ping, traceroute, telnet, SSH, arp, ipconfig), SHOW & DEBUG commands

STP is enabled by default on all Cisco Catalyst switches. In fact, if you are running multiple VLANs (virtual LANs) on your switch (discussed in Chapter 15), Cisco switches run an instance of STP on each VLAN configured. With that being said, no configuration is required unless you want to alter the default parameters of STP or manually define optimal switching paths or designate certain switches as root bridges.

Changing Priority and Port Cost
One of the common configurations you might encounter in your travels is to change the default priority of a switch to ensure that it will win the election for root bridge. To configure this option, you have to define which VLAN’s priority you want to change and give a value in increments of 4096. For instance, if you wanted your switch to be the root bridge for VLAN
1, you would configure the following in global configuration:

Switch(config)#spanning-tree vlan 1 priority 4096
Cisco also created a command that automatically changes the switch’s priority to become the
root bridge for a given VLAN:
Switch(config)#spanning-tree vlan 4 root primary
If you wanted to change the default cost calculations for a specific interface to ensure that a
port becomes a forwarding interface, you could change the spanning tree cost on any interface
by entering interface configuration mode and using the following commands:
Switch(config)#interface FastEthernet 0/1
Switch(config-if)#spanning-tree cost 1

Verifying Spanning Tree Protocol

Objective:

  • Interpret the output of various show and debug commands to verify the operational status of a Cisco switched network

To verify spanning tree operation in your switch, you can issue the show spanning-tree command to see a display of the STP operations for each VLAN. If you want to see specific information regarding a particular VLAN or interface, you can also add additional keywords after the command to see the output for only those items. The following output from show spanningtree displays the STP statistics for VLAN 1:

Switch#show spanning-tree vlan 1
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32769
Address 000d.65d0.4e00
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 000d.65d0.4e00
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 15
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- ---------------------------------
Fa0/1 Desg LIS 19 128.1 P2p
Fa0/23 Desg FWD 19 128.24 P2p
Fa0/24 Back BLK 19 128.23 P2p

Notice in this output that you can see the MAC address and the priority of the root bridge and the local switch (which happens to be the root bridge for this VLAN). In addition, you can see the timers using 802.1d for port state transitions, including the max age and forward delay. Finally, this useful show command displays the interfaces that are active and participating in STP and their associated roles and states in the spanning tree network.

Troubleshooting Basic Switch Connectivity

Objectives:

  • Verify network status and switch operation using basic utilities (including: ping, traceroute, telnet, SSH, arp, ipconfig), SHOW & DEBUG commands
  • Identify, prescribe, and resolve common switched network media issues, configuration issues, auto negotiation, and switch hardware failures

As always, when troubleshooting connectivity issues, use a layered approach and eliminate possibilities at each layer to home in on the possible cause of the problem. Over time, you will begin to develop a sixth sense about these problems and decrease the amount of effort it takes to accurately pinpoint a connectivity problem. In the meantime, let’s look at some possible connectivity scenarios and walk through some possible deductions as to what might cause the problem. In instances where you cannot gain console connectivity to the switch, you should ask the following questions:

  1. Is the switch powered on and running? Although this seems like common sense, it is still valid to check to make sure the switch is powered on and successfully completed its bootup process. Catalyst switches all have LEDs (light-emitting diodes) on the switch face to signify that it is operating correctly. The system and status lights for the switch should both be a steady green if the device is powered on and operating normally.
  2. Are your terminal connections correct? Verify that you have configured your terminal application correctly by setting the speed, flow control, and start and stop bits and ensure that you have the console (rollover) cable connected between your PC and the switch.
  3. Did you or someone else change the console password? If you are gaining access to IOS but cannot log in, you may need to perform password recovery on the switch. Consult the switches’ manual or look online at cisco.com for switch-specific steps to recover your password.

In instances where you cannot gain remote connectivity to the switch, you should ask the following questions:

  1. Is the switch powered on and running? If possible, console into the switch or have someone check that the switch is powered on and successfully completed its bootup process.
  2. Do you have IP connectivity to the switch? You can utilize troubleshooting commands from the switch such as ping to test connectivity between the switch and the management computer you are remotely connecting from. If your pings fail, verify that you have configured the default gateway for the switch and continue troubleshooting using the traceroute command to identify where along the forwarding data path the packets are failing.
  3. Did you or someone else change the vty password or SSH login and password? If you are gaining access to IOS but cannot log in, you may need to reconfigure the SSH and Telnet passwords via the console to regain access to these remote management protocols.

In instances where the switch is not forwarding frames, you should ask yourself these questions:

  1. Is the switch powered on and running? This would be fairly evident because all devices connected to the switch would be unable to communicate with each other. If possible, check that the switch is powered on and successfully completed its bootup process.
  2. Does the switch have Layer 1 connectivity to the device(s)? The LEDs above the port may give you a quick indication if there is a problem with that port. To verify your cabling, ensure you are using a straight through Ethernet cable if connecting to a PC, router, or other end device. If connecting to another switch, you should have a cross-over Ethernet cable attached to those interfaces. What’s more, you can also verify that the interfaces are not administratively shut down and are in an up/up state using the show interfaces interface-id command. Keep in mind that if you just connected the end device to the switch, it will take at least 30 seconds to transition to a forwarding state, as dictated by spanning tree protocol.
  3. Does the output of the show interfaces interface-id command show you incorrect speed or duplex? An interface that does not become active or is constantly bouncing up and down may indicate duplex and/or speed mismatches from autonegotiation.
    This will be evident if the show interfaces interface-id output is displaying excessive collisions or the interface is in an up/down state. To remedy this problem, ensure that the switch and the end device are set for autonegotiation. To eliminate all doubt, manually set the speed and duplex parameters on the switch port(s) and the end device.
  4. Does your switched internetwork intermittently stop forwarding frames? Recall that when new switches are added to a switched internetwork, it may take up to 50 seconds to have the switches converge to the new STP topology. If you are not adding switches to the network, verify that there isn’t a faulty switch causing re-elections of the STP topology by using the debug spanning-tree command. This command shows realtime events of the spanning tree process and indicates whether a switch might have an interface that is going up and down causing re-elections in the STP topology.