- Physical Network Topology and Availability
- Layer 2 Availability: Trunking —802.3ad—Link Aggregation
- Layer 2 Trunking Availability Strategies using SMLT and DMLT
- Layer 2 Availability: Spanning Tree Protocol
- Layer 3—VRRP Router Redundancy
- Layer 3—IPMP—Host Network Interface Redundancy
- Layer 3—Integrated VRRP and IPMP
- Layer 3—OSPF Network Redundancy— Rapid Convergence
- Layer 3—RIP Network Redundancy
- Conclusion
- About the Authors
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Layer 2 Availability: Spanning Tree Protocol
The spanning tree algorithm was developed by Radia Perlman, currently with Sun Microsystems. The Spanning Tree Protocol (STP) is used on Layer 2 networks to eliminate loops. For added availability, redundant Layer 2 links can be added, however, these redundant links introduce loops, which cause bridges to forward frames indefinitely.
By introducing STP, bridges communicate with each other by sending bridge protocol data units (BPDUs), which contain information that a bridge uses to determine which ports forward traffic and which ports don't, based on the spanning tree algorithm. A typical BPDU contains information including a unique bridge identifier, the port identifier, and cost to the root bridge, which is the top of the spanning tree.
From these BPDUs, each bridge can compute a spanning tree and decide which ports to direct all forwarding of traffic. If a link fails, this tree is recomputed, and redundant links are activated by turning on certain ports, hence creating increased availability. A network needs to be designed to ensure that every possible link that may fail has some redundant link.
In older networks, bridges are still used. However, with recent advances in network switch technology and smaller Layer 2 networks, bridges are not used as much.
Availability Issues
To better understand failure detection and recovery, a testbed was created, as shown in FIGURE 12.
)
FIGURE 12 Spanning
Tree Network Setup
The switches, sw1, sw2, sw3, and sw4, were configured in a Layer 2 network, with an obvious loop, which was controlled by running the STP among these switches. On the client, we ran the traceroute server command, resulting in the following output, which shows that the client sees only two Layer 3 networks: the 11.0.0.0 and the 16.0.0.0 network.
client># traceroute server traceroute: Warning: Multiple interfaces found; using 16.0.0.51 @ hme0 traceroute to server (11.0.0.51), 30 hops max, 40 byte packets 1 16.0.0.1 (16.0.0.1) 1.177 ms 0.524 ms 0.512 ms 2 16.0.0.1 (16.0.0.1) 0.534 ms !N 0.535 ms !N 0.529 ms !N
Similarly, the server sees only two Layer 3 networks. On the server we ran traceroute client command and got the following output:
server># traceroute client traceroute: Warning: Multiple interfaces found; using 11.0.0.51 @ hme0 traceroute to client (16.0.0.51), 30 hops max, 40 byte packets 1 11.0.0.1 (11.0.0.1) 0.756 ms 0.527 ms 0.514 ms 2 11.0.0.1 (11.0.0.1) 0.557 ms !N 0.546 ms !N 0.531 ms !N
The following outputs show the STP configuration and port status of the participating switches, showing the root switches port MAC address.
* sw1:17 # sh s0 ports 7-8
Stpd: s0 Port: 7 PortId: 4007 Stp: ENABLED Path Cost: 4
Port State: FORWARDING Topology Change Ack: FALSE
Port Priority: 16
Designated Root: 80:00:00:01:30:92:3f:00 Designated Cost: 0
Designated Bridge: 80:00:00:01:30:92:3f:00 Designated Port Id: 4007
Stpd: s0 Port: 8 PortId: 4008 Stp: ENABLED Path Cost: 4
Port State: FORWARDING Topology Change Ack: FALSE
Port Priority: 16
Designated Root: 80:00:00:01:30:92:3f:00 Designated Cost: 0
Designated Bridge: 80:00:00:01:30:92:3f:00 Designated Port Id: 4008
* sw2:12 # sh s0 ports 7-8
Port Mode State Cost Flags Priority Port ID Designated Bridge
7 802.1D FORWARDING 4 e-R-- 16 16391 80:00:00:01:30:92:3f:00
8 802.1D FORWARDING 4 e-D-- 16 16392 80:00:00:01:30:92:3f:00
Total Ports: 8
Flags: e=Enable, d=Disable, T=Topology Change Ack
R=Root Port, D=Designated Port, A=Alternative Port
* sw3:5 # sh s0 ports 7-8
Stpd: s0 Port: 7 PortId: 4007 Stp: ENABLED Path Cost: 4
Port State: FORWARDING Topology Change Ack: FALSE
Port Priority: 16
Designated Root: 80:00:00:01:30:92:3f:00 Designated Cost: 0
Designated Bridge: 80:00:00:01:30:92:3f:00 Designated Port Id: 4001
Stpd: s0 Port: 8 PortId: 4008 Stp: ENABLED Path Cost: 4
Port State: FORWARDING Topology Change Ack: FALSE
Port Priority: 16
Designated Root: 80:00:00:01:30:92:3f:00 Designated Cost: 4
Designated Bridge: 80:00:00:e0:2b:98:96:00 Designated Port Id: 4008
The following output shows that STP has blocked Port 8 on sw4.
* sw4:10 # sh s0 ports 7-8 Stpd: s0 Port: 7 PortId: 4007 Stp: ENABLED Path Cost: 4 Port State: FORWARDING Topology Change Ack: FALSE Port Priority: 16 Designated Root: 80:00:00:01:30:92:3f:00 Designated Cost: 4 Designated Bridge: 80:00:00:01:30:f4:16:a0 Designated Port Id: 4008 Stpd: s0 Port: 8 PortId: 4008 Stp: ENABLED Path Cost: 4 Port State: BLOCKING Topology Change Ack: FALSE Port Priority: 16 Designated Root: 80:00:00:01:30:92:3f:00 Designated Cost: 4 Designated Bridge: 80:00:00:e0:2b:98:96:00 Designated Port Id: 4008
To get a better understanding of failure detection and fault recovery, we conducted a test where the client continually pinged the server, and we pulled a cable on the spanning tree path.
The following output shows that it took approximately 68 seconds for failure detection and recovery, which is not acceptable in most mission-critical environments. (Each ping takes about one second. The following output shows that from icmp_seq=16 to icmp_seq=74, the pings did not succeed.)
on client --------- 4 bytes from server (11.0.0.51): icmp_seq=12. time=1. ms 64 bytes from server (11.0.0.51): icmp_seq=13. time=1. ms 64 bytes from server (11.0.0.51): icmp_seq=14. time=1. ms 64 bytes from server (11.0.0.51): icmp_seq=15. time=1. ms 64 bytes from server (11.0.0.51): icmp_seq=16. time=1. ms ICMP Net Unreachable from gateway 16.0.0.1 for icmp from client (16.0.0.51) to server (11.0.0.51) I for icmp from client (16.0.0.51) to server (11.0.0.51) ... ... ICMP Net Unreachable from gateway 16.0.0.1 for icmp from client (16.0.0.51) to server (11.0.0.51) ICMP Net Unreachable from gateway 16.0.0.1 for icmp from client (16.0.0.51) to server (11.0.0.51) for icmp from client (16.0.0.51) to server (11.0.0.51) 64 bytes from server (11.0.0.51): icmp_seq=74. time=1. ms 64 bytes from server (11.0.0.51): icmp_seq=75. time=1. ms 64 bytes from server (11.0.0.51): icmp_seq=76.