From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

OECG – Chapter 3 “Spanning Tree” Part 2 of 2

2,249 Words. Plan about 15 minute(s) to read this.

I’m done fiddling with other stuff ABOUT the CCIE. Now it’s back to the actual CONTENT that’s going to help me pass these exams. The second half of this chapter talks about optimizing spanning-tree, etherchannels, RST, MST and more. Here we go!

  • STP, left to default settings, can cause network service interruptions during times of network instability. In network-time, STP takes an eon to converge. You could have as much as a 50 seconds convergence time. 20 seconds for maxage to expire, 15 seconds for listen state plus 15 seconds for learn state before the port that needs to come up is actually forwarding. If an outage lasts 50 seconds on your network, any sort of production environment not paid for by taxpayers is going to know about it. That in mind, there’s lots of enhancements that will make STP faster.
  • Portfast is used on edge ports. When link comes up, portfast ports begin to forward immediately, without those pesky “listen” and “learn” states. Don’t use portfast to uplink to a hub or switch because of the potential for a topology loop portfast exposes that port to.
  • Uplinkfast is used on access switches that have multiple uplinks to distribution or core switches. If the root port goes down, and already determined alternate root port begins forwarding, and the switch updates his CAMs. When you enable uplinkfast:
    (1) The local switch’s root priority changes to 49,152 (making it less likely the switch would ever become root).
    (2) All port costs are set to 3000 (same logic, makes it unlikely the switch would ever be a transit switch).
    (3) Alternate root ports are tracked – i.e., ports on which hellos are being received.
    (4) If an uplinkfast-based failover to a new root port occurs, the switch will send one multicast frame per entry in his MAC table, using that MAC as the source. In this way, every switch on the segment sees the MAC come from the new port, and forces the local switch as well as every other switch to update their CAM’s. Note this is NOT the TCN process. This is something little. Yellow. Different. (Obscure late 80’s TV commercial reference brought to you by no one in particular.)
  • Backbonefast is used to detect a non-local link failure. If the switch running backbonefast doesn’t get a Hello he’s expecting, he queries the switch connected to his root port to see if there’s a problem, using an RLQ, or Root Link Query. A responding RLQ can indicate that there was a problem. In that case, the backbonefast switch will begin the convergence process immediately, without waiting for maxage to expire. Typically, this is run in the network core. Note that switches don’t have to wait for maxage to expire IF it’s a local root port that went down. If it’s NOT a local root port, then normally the switch would have to wait for maxage timer to run out (10xHello by default, or 20 seconds) before trying to reconverge. Backbonefast lets the switch be a bit proactive about things by querying his neighbor to see if there’s really a problem, or if the Hello was missed because of sunspot activity.
  • To wit, “spanning-tree portfast”, “spanning-tree portfast default” (which I recommend strongly against using in most situations), “spanning-tree uplinkfast” and “spanning-tree backbonefast”.
  • Moving on to portchannels, also known as etherchannels. Portchannels let you bundle identical ethernet interfaces talking to other identical ethernet interfaces on a neighboring switch. By “bundle”, I mean that the multiple links act as one logical interface. While it’s not quite that simple, that’s the general idea. So, you take 4 100Mbps interfaces, portchannel them into Fast Etherchannel (FEC), and you get a single, logical interface theoretically capable of 400Mbps throughput. Gigabit etherchannel is known as GEC. To be completely fair, the way frames are load-balances across an etherchannel does not translate to double or quadruple speeds. And…if you have a fast-ethernet server pushing data to another fast-ethernet server, you aren’t going to make them send data any faster than the 100Mbps the NIC can send. The load-balancing methods vary, but generally the specific interface in the etherchannel is chosen to carry a frame by a mathematical operation – say an XOR. The method varies by switch, but it’s important to remember that a conversation headed to a particular destination is probably going to go down the same interface every time. Therefore, if you need to get a more even distribution, you may want to mix up your load-balancing methods on either end of the portchannel with “port-channel load-balance” commands. You can balance using methods such as source/destination MAC, IP address and TCP/UDP ports. (Although again, that’s going to depend on the switch. I bet an old layer 2 switch like a 2950 can’t balance any deeper than layer 2, although I could be wrong.)
  • Portchannels can be statically configured “on”, or either end of the link can use a protocol to establish the etherchannel. PAgP (port aggregation protocol) is Cisco proprietary using keywords “auto” (won’t initiate) and “desirable” (will initiate). LACP is IEEE 802.1D using keywords “passive” (won’t initiate) and “active” (will initiate). LACP and PAgP are not compatible – both sides of the etherchannel must be one or the other. Several things must be identical for the portchannel to form:
    (1) Speed and duplex.
    (2) If not trunking, same access VLAN.
    (3) If trunking, same trunk type, same allowed VLAN’s and same native VLAN.
    (4) On a single switch, every port must have the same STP cost on all links in the etherchannel.
    (5) Can’t run SPAN (i.e. port monitoring).
    Last point – an etherchannel is treated as a single port from a STP perspective.
  • Rapid Spanning Tree Protocol (RSTP) is the shiny new IEEE 802.1w standard that makes updates old school STP to make it, well, rapid – make convergence happen faster. RSTP includes a number of enhancements which are similar to, if not exactly like, Cisco proprietary “-fast” enhancements:
    (1) Waits for 3 missed hellos rather than 10.
    (2) The disabled state replaces the blocking state. You can now transition from disabled state to learning state, skipping the STP idea of a listening stage.
    (3) Standardized flavors of Uplinkfast, BackboneFast and Portfast.
    (4) New idea of a backup designated port if you’ve got a switch with more than one connections to the segment.
  • RSTP uses BPDUs, but takes advantage of some bits that weren’t in use before to make the new features work (i.e. a Hello with a certain option instead of the Cisco proprietary RLQ used in BackboneFast). RSTP also classifies each port as point-to-point (any full-duplex link that receives Hellos), Shared (switch-to-hub, important that switches are accessible from that port) and Edge (a single device, i.e. not a switch). Most of the time, ports will be point to point or edge.
  • RSTP gets rid of the “listening” state how? Because it’s actively talking to neighbors if a Hello is missed (like BackboneFast). This conversation means that a topology loop is avoided.
  • RSTP has the concept of “port roles” to classify a port as a root port or designated port. New roles include an “alternate port”, which is analogous to the same idea in UplinkFast – it’s an alternate root port. Also there’s a “backup port”, which backs up the designated port.
  • Note that “spanning-tree mode rapid-pvst” enables RSTP. Or – turn on multiple spanning-tree, which uses RSTP 802.1w.
  • Okay. Moving onto to IEEE 802.1s Multiple Spanning Trees or MST for short. This is the “standard” way to run multiple spanning trees in a 802.1Q environment. It’s similar conceptually to what PVST+ (Cisco proprietary) is doing, but it’s a different animal. It’s like PVST+ in that you can have some VLAN’s be blocking on a trunk, and others forwarding, so you get that sort of load-balancing effect. It’s different from PVST+ in that is uses 802.1w RSTP and that you don’t have to have one STP instance per VLAN. Rather, a superior MST design uses one STP instance for each redundant path. (Huh. What do you know about that?) So, conceptually, MST allows you to create an MST region, and put all switches in that MST region. From there, you can map VLAN’s to an STP instance running inside the region. Rather than having one instance per VLAN (like with PVST+), you have a whole bunch of VLAN’s mapped to a single instance. This reduces the number of STP messages you’re dealing with. If you need to talk STP outside of your MST region, MST will appear as a single switch to the non-MST world. To make sure there’s not a topology loop between the MST region and non-MST switches, MST will participate in an “Internal Spanning Tree” with those outside switches.
  • WELL. This has been a SCINTILLATING discussion thus far. But there’s one more thing to chat about. And that is the tools we can use to protect our carefully designing spanning-tree from being destroyed by bug-eyed Martians. You know. Users. Noobs. The well-meaning-but-clueless. The guy who plugs a NetGear hub in under his desk, and then plugs the NetGear into itself like happened to a poor soul on the NetPro forums the other day. There’s any number of features we can configure to save us from the Martians.
    (1) RootGuard – the idea is that you don’t want someone plugging in a switch into a port that you intend to be an access port, and then have the whole spanning-tree converge because that unexpected switch happens to be shoving a superior BPDU at your network. So if you configure a port with RootGuard, the switch will put the port into a “loop-inconsistent” state when it sees a superior BPDU. Oh, and the port isn’t forwarding traffic anymore – tough on the martian, but one does what one has to.
    (2) BPDUGuard is even more aggressive than RootGuard. With BPDUGuard, any received BPDU will cause the port to go “err-disabled”. Now the book doesn’t specify, but I think that’s only true if the port is in portfast mode. In fact, I know that’s true. I’ve had a few of the implementation guys I work with cable up a switch to one of the infrastructure switches, and not know why it was broke. The fix was me showing them how to shut off portfast on their switch uplink ports, since we are running BPDUGuard everywhere.
    (3) UDLD is unidirectional link detection. UDLD is targetted at preventing a fiber cable that’s working in one direction but not the other from causing a topology loop. The idea is that if say the TX side of the fiber is working, one switch might think the world is normal. However, the RX side isn’t getting Hellos like he normally does – so maxage expires, we decide to start forwarding on a port that was previously blocking, and now we’re in a world of hurt because of this topology loop. UDLD isn’t limited to fiber links, but that’s really at it’s heart from what I’ve read. While I’ve seen a “half-a-fiber” go bad, I’ve never seen a uni-directional copper link. I suppose it could happen, and you can run UDLD on copper if you want. UDLD then, is a protocol spoken between 2 UDLD-capable switches. In normal mode, if UDLD detects a half-a-link scenario, it will place the problem port into an err-disabled state. In UDLD-aggressive mode, UDLD will attempt to contact the other switch 8 times when it hasn’t been receiving messages. If there’s still no response, the link goes err-disabled (on both sides, according to the book. If one side is err-disabled, then so’s the other side, but the book makes it sound like UDLD running on each switch would independently shut the port down. Huh.)
    (4) LoopGuard prevents a switch that’s no longer receiving Hellos from converging. Rather, the port goes into a “loop-inconsistent” state. So, it goes from “blocking” to “loop-inconsistent”. It will come out of loop-inconsistent when the Hellos are received again. I can’t say LoopGuard gets me all excited. Anyway.
  • Moving onto the Foundation Summary:
    (1) Standards-soup: RSTP-802.1W (WHOA!), MST-802.1S (SUCK), STP-802.1D (DUH), LACP-802.1AD, PVST+ & PAgP-Cisco proprietary.
    (2) Timers – default Hello – 2 seconds (how often the root sends Hellos), default Forward Delay – 15 seconds (how long a switch stays in listen and then in learn state, plus the time used to timeout CAM entries during a convergence), default Maxage – 20 seconds (time a switch doesn’t hear a Hello from root before deciding root’s gone and it’s time to converge)
    (3) Commands
    “spanning-tree mode mst|pvst|rapid-pvst”
    “spanning-tree vlan x” – enable/disable STP in a particular VLAN
    “spanning-tree vlan x forward-time”
    “spanning-tree vlan x hello-time”
    “spanning-tree vlan x priority”
    “spanning-tree vlan x root primary | secondary diameter hello-time”
    “spanning-tree vlan x cost y” – sets port priority per VLAN
    “channel-group x mode auto | desirable | on | active | passive” – for putting ports in an etherchannel and setting the mode. On=no protocol, auto|desirable = PAgP, active|passive = LACP.
    “channel-protocol lacp | pagp” – sets which one, which I thought was taken care of by the command above. Huh.
    “interface port-channel x” – configures parameters for an etherchannel.
    “spanning-tree portfast” – interface
    “spanning-tree uplinkfast” – global
    “spanning-tree backbonefast” – global
    “spanning-tree mst x priority” – sets the priority of an MST instance
    “spanning-tree mst configuration” – takes you into MST config-land
    “show spanning-tree root | brief | summary” – tells you ALL about STP (and there’s a ton of good info in there if you’ve never looked at these screens. Seems to me they are screens to understand intimately – what they mean, every line, every column.)
    “show spanning-tree uplinkfast | backbonefast”