Administrators are tasked with configuring interfaces on network devices more than any other single thing. This makes sense—interfaces are the main points of connectivity, sending and receiving traffic throughout an organization.
Configuring interfaces can be deceptively easy. Switchports might require a VLAN assignment, and often function with no other configuration at all. Router interfaces can be up and running with only an IP address. That said, network admins should give more attention to configuring interfaces. A lot is happening with those interfaces, and careful networkers will want to retain control of them.
In this article, we’ll take an introductory look at Ethernet switch interface configuration.
Who’s in control?
When you look at the running configuration of a Cisco switchport left at defaults, it appears empty—a blank canvas on which to paint your configuration. This isn’t so. In reality, Cisco hides a large number of default commands so you don’t see them. The interface is very much configured, just not by you.
Let’s take a look at a sample interface configuration displayed by a “show run” versus a “show run all” on a Cisco Catalyst 3560G switch.
SWITCH#show run interface gi0/1 Building configuration... Current configuration : 37 bytes ! interface GigabitEthernet0/1 end SWITCH#show run all | section interface GigabitEthernet0/1 interface GigabitEthernet0/1 switchport switchport access vlan 1 switchport trunk encapsulation negotiate switchport private-vlan trunk encapsulation dot1q switchport private-vlan trunk native vlan tag no switchport nonegotiate no switchport protected no switchport block multicast no switchport block unicast switchport port-security maximum 1 no switchport port-security switchport port-security aging time 0 switchport port-security violation shutdown switchport port-security aging type absolute switchport port-security limit rate invalid-source-mac 10 no switchport port-security mac-address sticky no switchport port-security aging static no ip arp inspection trust ip arp inspection limit rate 15 burst interval 1 ip arp inspection limit rate 15 load-interval 300 snmp trap mac-notification change added snmp trap mac-notification change removed snmp trap link-status cdp tlv location cdp tlv server-location cdp tlv app spanning-tree port-priority 0 spanning-tree cost 0 hold-queue 75 in hold-queue 0 out ip igmp snooping tcn flood no bgp-policy accounting input no bgp-policy accounting output no bgp-policy accounting input source no bgp-policy accounting output source no bgp-policy source ip-prec-map no bgp-policy source ip-qos-map no bgp-policy destination ip-prec-map no bgp-policy destination ip-qos-map passive-interface GigabitEthernet0/1 SWITCH#
Startling, isn’t it? There’s a vast number of default commands hidden from normal view that dictate interface behavior. I’m not suggesting you need to worry about each and every one of these commands, but researching what they all do is an interesting project I recommend for a rainy day. Mostly, I want to raise awareness that there’s a whole lot going on behind the scenes of an interface whether or not you’ve added any switch configuration commands of your own. If you leave the port unconfigured, you’re not in control of that interface.
In my experience, network administrators who wish to remain in control of their network infrastructure gain control of their network interfaces. The idea is that since physical interfaces are how data arrives at and leaves the network, controlling those interfaces goes a long way towards maintaining a stable network topology. Stability is the most desirable characteristic of any network.
A stable network is one that stays up, forwards traffic via consistent paths, and is generally unremarkable. “Unremarkable” doesn’t sound impressive, but the best network is one that’s invisible, doing its job effectively without making its presence felt unduly.
Many of the bad things that can introduce instability to a network happen because of what someone plugs into a switchport interface. Let’s take a look at how to control these interfaces.
Switchport interface configuration guidelines
If you aren’t using an interface, shut it down. Think of your configuring interfaces as closing the doors to a house. To discourage intruders from entering your home, you lock the door. Shutting down an interface is like locking the door.
In a practical sense, shutting down interfaces can be inconvenient. Server admins want to plug into any port in the data center and get a link light. Users want to plug into any random jack and have it light up. Depending on your organization, you might find that convenience is more important than any other consideration. Fair enough. But consider that the easiest way for an intruder to gain access to your network is by walking into the building, jacking in, getting an IP address, and seeing what they can do. A secure building is less prone to this problem, but are there areas guests have access to an Ethernet jack?
Also consider that in a data center, new hosts getting racked up are almost always going to require a unique interface configuration. The server folks might want the network interface to light up when they plug it in, but that should only happen if they’ve coordinated with network engineering to configure the switchport first.
SWITCH#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SWITCH(config)#interface Gi0/1
SWITCH(config-if)#shutdown
SWITCH(config-if)#exi
SWITCH(config)#exi
SWITCH#show run interf gi0/1
Building configuration...
Current configuration : 47 bytes
!
interface GigabitEthernet0/1
shutdown
end
SWITCH# Understand speed and duplex. Some experienced network administrators remember the day when Fast Ethernet auto-negotiation chronically failed, resulting in a duplex mismatch on either side of the link that negatively affected performance.
In the age of Gigabit Ethernet, the best practice is to leave speed and duplex settings to automatic. In the Gigabit Ethernet world, the interface will almost always end up with the optimal setting when left alone. I recommend manually setting speed and duplex only for links where a duplex mismatch has been observed. This is very rare in modern networks, but can still crop up once in a while. Auto-negotiation is the default interface setting for Cisco switches. If necessary, speed and duplex can be manually set with the “speed” and “duplex” commands in interface mode.
Add a description. I can’t tell you how many interfaces I’ve run into that have no description, which is really a shame. Networking vendors make it very easy to assign a plain-English description to an interface. This is helpful in troubleshooting, useful for self-documentation, and is leveraged by network management systems in reports and graphs.
Always fill in a port description. A standard port description (a format that’s the same for every interface) is outstanding, but any description is better than no description at all. On Cisco gear, you can use the “description” command to label an interface however you like.
SWITCH#show run interf gi0/1
Building configuration...
Current configuration : 169 bytes
!
interface GigabitEthernet0/1
description UPLINK TO MAIL SERVER 1
end
SWITCH# Set trunking and VLAN characteristics. By default, a Cisco switchport will attempt to come up as an 802.1q trunk (i.e., tagged for VLANs) that allows all VLANs, failing back to forwarding traffic untagged in VLAN1. Intruders with access to your network can take advantage of this default behavior by bringing up a trunk and seeing what VLANs are available. This is due to the behavior of Cisco’s Dynamic Trunking Protocol (DTP), which sends frames from the interface to anyone on the other side of the link, hoping to bring up a trunk. While this is convenient for bringing up 802.1q trunk interfaces between switches automatically, my preference is to manually configure whether or not the port will be an 802.1q trunk, what VLANs will be allowed if the interface is a trunk, and which specific VLAN the interface will be a member of if it’s not.
Let’s look at couple of examples. The first shows an interface configured as a trunk, allowing traffic tagged with VLAN numbers 10, 20, and 30. The second configures an access port resident in VLAN 10. I’ve commented on the commands inline.
Example 1: 802.1q port
SWITCH#show run interf gi0/1 Building configuration... Current configuration : 165 bytes ! interface GigabitEthernet0/1 switchport trunk encapsulation dot1q ! Set the encapsulation type to standard "dot1q" ! instead of older Cisco "ISL", required on some ! switches before you can configure the ! interface to be a trunk. switchport trunk allowed vlan 10,20,30 ! Only allow frames tagged with VLANs 10, 20, or ! 30. Frames tagged with other VLAN numbers will ! be discarded. switchport mode trunk ! Manually set the interface to be a trunk. ! In Cisco-speak, trunk interfaces carry traffic ! from many different VLANs, identified with a ! unique number. By setting the mode to "trunk" ! manually, the interface is prevented from ! being anything else. switchport nonegotiate ! Turn off Cisco DTP. You can't do this until ! the switchport mode is set first. end SWITCH#
Example 2: Access port
SWITCH#show run interf gi0/1 Building configuration... Current configuration : 113 bytes ! interface GigabitEthernet0/1 switchport access vlan 10 ! Assign all traffic arriving on the port to ! VLAN 10. switchport mode access ! Manually set the interface to be an access ! port, which in Cisco-speak implies that the ! port is untagged. switchport nonegotiate ! Turn off Cisco DTP. You can't do this until ! the switchport mode is set first. end SWITCH#
Consider spanning tree. The loop-prevention tool spanning tree is sometimes ignored by IT teams, when it should be a carefully managed and guarded protocol. A carefully managed spanning tree configuration will improve network stability enormously, whereas instability can result from a spanning tree left to configure itself. We’re not going to dig deeply into spanning tree here, but when it comes to interface configurations, there are a couple of spanning tree points worth mentioning.
First, you can reduce the amount of time it takes for a switchport to start forwarding traffic by putting the port into spanning tree portfast mode. Portfast should only be used on host-facing ports (which is to say, interfaces that connect a workstation or server). Portfast should not be used on interfaces that connect to other switches.
The point of spanning tree portfast is to tell the switch, “Hey, this port is only used to talk to hosts, and not other switches. So you don’t have to worry about listening for spanning tree information and detecting loops on that port. It’s okay to go ahead and start forwarding traffic immediately.” This connects the host to the network several seconds faster, which doesn’t sound like much but can be critical for many applications.
Second, you can help enforce the spanning tree topology by putting guards in place. There are several guards available that serve a variety of purposes on certain interfaces. To follow the discussion of spanning tree portfast, let’s review Bridge Port Data Unit (BPDU) guard.
Remember that portfast allows interfaces to transition to forwarding quickly, which is useful for servers and workstations. Here’s the catch: What if someone plugs in a switch — something that’s not a host — to a portfast interface? BPDU guard says, “Uh oh. This is a portfast port, but I saw a BPDU come in. BPDUs only come from switches, so I better shut this port down to be extra sure that the unexpected switch isn’t causing a loop on the network.”
Other guards include root guard and loop guard, which we don’t have time to cover here. Look for them in a future post. For now, how is spanning-tree portfast and BPDU guard configured on an interface? Both can be configured globally (affecting all ports) or individually (affecting only one interface at a time).
Example 1: Configuring portfast and BPDU guard globally
SWITCH#conf t Enter configuration commands, one per line. End with CNTL/Z. SWITCH(config)#spanning-tree portfast default SWITCH(config)#spanning-tree portfast bpduguard default SWITCH(config)#^Z SWITCH#
I almost never configure these features globally. Although portfast will only take effect on access ports and not trunk ports, the portfast status doesn’t show up when configuring interfaces just because the global configuration was set. I like to see that command underneath the interface configuration, along with BPDU guard. That information is helpful when troubleshooting or verifying a configuration. That said, it’s fair to argue that the global “bpduguard” command is good to have as a safety net. I won’t fight you hard on that point.
Example 2: Configuring portfast and BPDU guard on an individual interface
SWITCH#show run interf gi0/1 Building configuration... Current configuration : 169 bytes ! interface GigabitEthernet0/1 spanning-tree portfast spanning-tree bpduguard enable end SWITCH#
Putting it all together
I hope it’s clear that a switchport interface configuration deserves more attention than simply assigning a VLAN. Interface configurations are a first line of defense against hackers, rogue devices being attached to the network, and honest mistakes.
In this article, I introduced configuring interfaces for basic switchport options. More advanced interface configuration options include port security, IP source guard, Dynamic Host Configuration Protocol (DHCP) snooping, quality of service policy, access lists, and more. In fact, whole chapters of some rather large networking books have been devoted to these very topics. So, dig in and read more! And build your interfaces with intent. Be the one in control.
Dear sir Ethan. You have shared a wonderful resource really I have cleared many of mu ambiguities that I had once in my mind.