The configuration of your wiring closet switch can range from simple to complex, depending on your design choices. Let’s talk through a number of elements that will help you keep control of your network and minimize risks to your users.
Before we start, you might want to have a read through my earlier blog post on the physical location and connectivity options for your wiring closet switch, and decide on a cable layout and general network topology.
Spanning tree configuration
If you chose the backup link or parallel Layer 2 design discussed in my previous post, then you’ve extended your Layer 2 domain from the core network into the wiring closet. That means your wiring closet switch is participating in the global spanning tree domain and needs to be configured appropriately.
I’ve written on spanning tree design before, and in that post I mention the importance of placing and enforcing the root bridge. When dealing with a closet switch, the key is ensure the closet switch doesn’t become the root bridge.
If a wiring closet switch does become the root bridge, then links in or around the physical core of the network could end up blocked. The result could be some odd (and unexpected) forwarding paths in the network that traverse the closet switch.
To help prevent this scenario, my recommendation is to set the root bridge priority to a very high number (the max of 65535 works), rather than leave it at the default value of 32768. If you’ve already set your core switches to some low value below 32768, changing them might seem unnecessary, but thinking ahead is critical. Setting the value to a higher number could help avoid an unexpected spanning tree result in future.
Also worth mentioning is that I’m assuming the use of rapid spanning tree. 802.1w is a significant rewrite of the original 802.1d spanning tree, and features a number of performance-related enhancements. Rapid spanning tree includes equivalents of several early Cisco spanning tree enhancements such as uplinkfast that will help your switch converge on a new topology more quickly if something changes.
Practically speaking, let’s say you’ve implemented the backup link scheme where one link is blocking and another forwarding. If the forwarding link goes down, your switch will notice and react. Eventually, traffic will begin to flow across the remaining link. How long “eventually” is varies between original spanning tree and rapid spanning tree, with rapid spanning tree being faster. The exact timers and processes involved are beyond the scope of this blog post, but I recommend this white paper from CCIE Petr Lapukhov if you’re interested in digging into details.
If you chose the parallel Layer 3 link design from my earlier post on connectivity options, then you’ve created an isolated Layer 2 spanning tree domain on the wiring closet switch itself. The question becomes whether or not the wiring closet switch needs to be the root of the spanning tree domain. In most cases, you will want it to be the root because you don’t want other switches that are plugged into the network, say, at a user’s desk, to become the spanning tree root bridge of the wiring closet domain.
Many wiring closet switches are Layer 3 switches, meaning they have the ability to route traffic between different blocks of IP addresses resident in separate VLANs. In the Cisco Catalyst product line, 29xx series routers are usually Layer 2 only, while 37xx and higher model switches are Layer 3 capable.
Assuming an L3-capable switch running parallel links, there are a few different routing schemes you could choose. Rather than go through all the different possibilities, let’s review one solid approach worth considering in a Cisco environment — that of dual EIGRP links. (You might like to read my introduction to EIGRP before going on.)
In this design, each L3 link is assigned a /29 network block. A /29 is a block of eight addresses, six being actually usable. In our example, the link to switch 1 has a range 10.100.1.0-7, where IP addresses 1 through 6 can actually be used.
I recommend /29s over more customary /30 point-to-point links, which only offer two usable addresses. /29s allow for future flexibility without renumbering the link, such as when an additional device like a firewall, WAN optimizer, or replacement switch might need to be added.
IP address conservation is usually not an issue on private networks using RFC1918 address space, so a /29 is a useful addressing scheme for point-to-point links without going overboard.
In this scenario, our wiring closet switch has two EIGRP links, one to each of a pair of switches back in the campus core network. Assuming both links have the same bandwidth and delay characteristics, the EIGRP routing process will see these links as equal costs, and load balance traffic between the two links. In the event that one of the links goes down, EIGRP will detect that there’s no longer a connection and converge on the remaining link.
A couple of additional notes here.
- The closet switch should very likely be configured as an EIGRP stub router. Unless you’ve made some unusual network design choices, there’s no reason a wiring closet switch should ever be a transit switch.
The only networks for which a wiring closet is the source are the connected VLANs accessed by users. So there’s no reason for the core network to query the wiring closet switch about lost routes originating in other parts of the network.
Another way to think about it is to consider the access switch a dead end. If the edge of the network diagram is the wiring closet switch, then that switch is indeed a dead end — nowhere further to go. And thus, configuring it as a stub is exactly the right thing to do.
- The wiring closet switch doesn’t need to know the entire routing table. All the wiring closet really needs to know is a default route. Why? In our sample design, the only place a closet switch can send anything is into the core network. A granular routing table is only useful to a router (or Layer 3 switch) if traffic for some IP destinations are reachable via one link, and traffic for other IP destinations are reachable via other links.
In our case, that’s not true. Therefore, why clutter up the closet switch’s routing table with a bunch of IP destinations that are all reachable via the exact same two links? Instead, the core switches can summarize traffic into a default route using an “ip summary-address eigrp” statement on the interfaces that uplink to the wiring closet switch. The closet switch will only learn a default route instead of the entire core routing table.
Quality of Service considerations
Another big topic that we can only give an introduction to here is Quality of Service (QoS). QoS is the big idea that some network traffic is more important than other network traffic. Important traffic (like voice and video, for example, although it could be anything you define) must be delivered, while other traffic can tolerate some loss. (For more detail on QoS, you might like to read my series here.)
For this post, let’s a make a few high-level observations:
- If you’re not running IP phones or video devices through the closet switch, you can probably do okay without a QoS scheme. Without voice and video traffic, what you’re sending through the switch is all data traffic, most likely TCP traffic. In the rare case of congestion between a wiring closest switch and the core network, the retransmission and sliding window mechanisms built into TCP can cope. In most situations, this is sufficient.
Exceptions to this general rule include interactive applications like SSH, where a delay due to congestion could make the application difficult to use. In such as case, a QoS scheme might be useful to prioritize that interactive traffic.
- When running real-time voice and video through your wiring closet switch, probably because you have IP phones rolled out to your organization, the idea is to send voice traffic — people talking on the phone — out a low-jitter “priority” queue, and video traffic out a queue that guarantees enough bandwidth for its needs. Jitter refers to the amount of time in between packet delivery. For voice traffic, delivering packets evenly is important for a good quality call. Video traffic is more tolerant of jitter than voice, but all the packets need to get where they’re going.
- How, exactly, to achieve a correct QoS configuration for your closet switch varies, sometimes dramatically, by switch platform. Different switches have different sorts of switching silicon inside of them, and not all of the queueing structures and capabilities are the same. Therefore, the commands, while often similar, will vary from switch platform to switch platform. Cisco has been working to unify their QoS configuration tools across platforms, but there are still differences to be wary of.
Other switch configuration considerations
Once the physical connectivity and forwarding design have been nailed down, a smart next step is to ensure the design continues working as intended. There are a couple of major points to consider.
Security should be put in place to prevent switch configuration from being altered by an unauthorized party. Note that a switch configuration left to its defaults is not necessarily secure, so the wise administrator will take care to enter non-default usernames and passwords, and to disable unencrypted management protocols like Telnet, SNMPv2, and HTTP, instead using SSH, SNMPv3, and HTTPS.
Another common sense security step is to use an access list to limit the source IP addresses that are allowed to manage the switch. This prevents, say, a user at his desk discovering the switch and trying to log in, or malware from attempting to send a new configuration to the switch via SNMP.
If you run a highly secure environment, you might consider more aggressive tools in the wiring closet switch. For example, IP source guard, dynamic ARP inspection, DHCP snooping, and port security are features that can be deployed to ensure that systems using the switch are who they claim to be, aren’t performing roles they shouldn’t, and are behaving normally. Implementation of these features is complex and beyond our scope here, but are well-worth investigating and understanding whether you ultimately implement them or not.
Another concern is monitoring of the switch to be sure it’s up and running, that links (especially the uplinks to the core switch) are not being over-utilized, and that the switch ports are running error-free. Many network management products, including Auvik, can help with these tasks, handling monitoring along with reporting, troubleshooting, and configuration management.
The result of all this configuration work is a wiring closet switch you can trust. You’ll be able to rest a bit easier, confident in a switch that’s quietly forwarding traffic from the wiring closet for your users in the very best way possible.