Understanding Linux Network Internals 2005 phần 4 docx

128 336 0
Understanding Linux Network Internals 2005 phần 4 docx

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Thông tin tài liệu

The root bridge makes sure each bridge in the network comes to know about a topology change when one occurs (see the section "Topology Changes"). Note that the selection of the port states and roles (and therefore of the links that should be enabled or disabled) depends on the location of the root bridge in the topology: this is because first you select the root bridge, and then you build the best tree based on that. 15.3.2. Designated Bridges While each tree has only one root bridge, there is one designated bridge for each LAN, which becomes the bridge all hosts and bridges on the LAN use to reach the root. The designated bridge is chosen by determining which bridge on the LAN has the lowest path cost to the root bridge. Thus, using Figure 15-2 as an example: [*] [*] The links in the figure are not assigned costs. You can assume their costs to be 1, and therefore the path cost to be the hop count. This is just an example; 1 is not the default cost assigned to links. In the A3-D2 LAN, D2 is the designated bridge. In the D2-C2 LAN, C2 is the designated bridge. 15.3.3. Spanning Tree Ports We introduced the root and designated bridge's roles in the previous sections. Let's see here what states and roles can be assigned to a bridge port. 15.3.3.1. Port states An STP port is a port in a bridge that runs the STP. This port will process ingress BPDUs and transmit BPDUs according to the rules in the section "When to Transmit Configuration BPDUs." An STP port can be in any of the following states: Disabled The port is shut down (through administrative action); it does not receive or transmit any traffic. Blocking The port is up, but the STP has blocked it. It cannot be used to forward any data traffic. Listening The port is enabled, but it cannot be used to forward any data traffic. This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks. Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Learning The port is enabled, but it cannot be used to forward any data traffic; however, the bridge's address learning process is active. Forwarding The port is enabled, learning is active, and data traffic can be forwarded. The use of the intermediate learning state allows a bridge to reduce the amount of flooding that would otherwise be required with an empty forwarding database. With the exception of ports in the disabled state, ingress BPDUs are processed regardless of the port state. Whether a port in a given state receives ingress BPDUs or transmits BPDUs depends on the port's role, which is introduced in the section "Port roles." Figure 15-6 shows how the state of a port can change. There is a clear progression from blocking through listening and learning to the most active state, forwarding. The transitions between blocking and forwarding are decided by the protocol based on various factors (see the later section "Defining the Active Topology"). Note that: A port on its way to the forwarding state can be moved back to blocking before the forwarding state is entered. This is possible, for instance, when a topology is not stable yet and therefore its state may change repeatedly in a short amount of time. The transitions between the intermediate states from blocking to forwarding are driven by a timer (see the section "Timers") and are needed to avoid the risk of temporary loops (see the section "Avoiding Temporary Loops"). Figure 15-6. Port state transitions In addition, an administrator can manually remove a port from any of these states and disable it. When a port is administratively disabled, it can be re-enabled only by another administrative intervention; the STP does not have this capability. However, bridges can implement optional features on top of the basic ones defined by the protocol, to enable and disable ports without administrative intervention. 15.3.3.2. Port roles STP ports can be assigned one of the following two roles: This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks. Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Root For each bridge, with the exception of the root bridge, the port with the lowest path cost to the root bridge is selected as the root port. Designated On each LAN, the port with the smallest path cost to the root bridge is selected as the designated port. The bridge to which the designated port belongs is called the designated bridge for the LAN. Note that a bridge with ports on different LANs can have more than one designated port, as shown in Figure 15-2. The criteria used to select designated ports are described later in the section "Designated Port Selection." While root ports lead toward the root of the tree (i.e., the root bridge), designated ports lead toward the leaves. In Figure 15-2, you can see the relationship between root and designated ports. From a tree's perspective, the two roles can be seen in this way: The tree's root has links that go only toward the leaves (i.e., only designated ports [*] ). [*] If you use shared media such as hubs to connect bridges, as in Figure 15-11(c), the root bridge can have nondesignated ports as well. The newer RSTP protocol would call that port a backup port (see the section "Rapid Spanning Tree Protocol (RSTP)." The leaf nodes have links that go only toward the tree's root (i.e., no designated ports and one root port). As a protection against misconfigurations and wrong cabling (such as connecting a bridge to a port where you are supposed to connect a host), a leaf node can run the STP on the ports that connect the hosts, too. In this case, the assumption that a leaf node does not have designated ports would no longer be valid. In other words, if you enable the STP on the ports of the access bridges in Figure 15-2 that connect the hosts, those ports would end up being assigned the designated role. Any node between root and leaves has at least one link toward the root (one of which will be selected as the root port), and at least one toward the leaves (a designated port). There are STP ports that are neither root nor designated ports; this is possible when you have redundant links between bridges. In Figure 15-2, the A1 port that goes to D2 is an example. The newer STP protocols, which I will briefly introduce in the section "Overview of Newer Spanning Tree Protocols," define new roles so that each STP port is assigned one. We will see how the root and designated port roles are assigned in the sections "Root Port Selection" and "Designated Port Selection," respectively. This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks. Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks. Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 15.4. Bridge and Port IDs The selection of the root bridge and the port state and roles depends on a set of parameters. Each parameter is assigned a default value that can be changed by user configuration. Here are the main parameters: Bridge ID Each bridge is assigned an ID, called the bridge ID, that is defined as an 8-byte value split into two components. The lowest six bytes are assigned the Ethernet MAC address of one of the bridge ports (see Chapter 16), and the highest two bytes are a configurable priority, called the bridge priority . The bridge ID is the field used by the root bridge selection algorithm (see the section "Root Bridge Selection"). Port ID Each port is assigned an ID. A portion of the ID represents a unique identifier called the port number. The way the port number is assigned is implementation dependent, and its value is meaningful only locally on the bridge. For example, the number can reflect the sequence in which ports were created: the first port is assigned 1, the second port 2, etc. Another approach could use the physical location of the port: for example, the first port on the bus is assigned 1, etc. It is desirable to have the port number assignments be deterministic and consistent across reboots so that the system administrator does not need to change the bridge configuration to reflect the changes after a reboot. Another portion of the ID, called the port priority , is used to assign a priority to the port (where a lower value means a higher priority). See Figure 15-7(b). See the section "Root Port Selection" for an example of when this parameter is used. Besides the bridge and port priority, the user can configure the following parameters: Port cost Each port is assigned a cost. The lower the value, the more preferred the port is. When not explicitly configured, the port is assigned a default cost based on the port's speed. For example, a Fast Ethernet port that runs at 100 Mbits/s is assigned a lower cost than an Ethernet port that runs at 10 Mbits/s. The default cost assignment makes sense in most cases, when the overall cost of going from one point of the tree to another is measured in terms of latency. However, it is possible that in specific contexts, the administrator prefers to explicitly assign costs based on external factors. Timers The STP uses a set of per-port and per-bridge timers . All of them have a default configuration that can be customized by the user. See the section "Timers." The timer configuration does not affect the selection of the root bridge and the port state and roles. We will see later in this chapter how the configuration of these parameters (with the exception of the timers) can be used to influence the selection of the topology. This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks. Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com In 2001, the IEEE released the 802.1t, 802.1D's maintenance document, which changed how bridge and port IDs are defined. The changes in format are shown in Figure 15-7. Figure 15-7. Bridge ID and port ID changes introduced by 802.1t Note that: The bridge priority is now only 4 bits in size. For backward compatibility, the bridge priority range is still 0-64 K, but since you have only four bits to play with, you now have priorities in increments of 4,096 (2 12 ). There is a new component in the bridge ID, called the system ID extension. This component, which can assume 4,096 different values, allows a network device, for example, to have up to 4,096 different bridge IDs sharing a single MAC address. Before, this would have required 4,096 different MAC addresses. Note that MAC addresses are not random numbers chosen by the administrator; they are worldwide unique numbers (and therefore are a limited resource) that are managed by the IEEE. The port number is now a 12-bit value, which allows a bridge to have up to 4,096 ports. Before you could have had only 256 (which was originally considered quite luxurious). The port priority is now a 4-bit value. The priority range is still 1-256 for backward compatibility, so priorities are now assigned in increments of 16. To understand the reasons for the 802.1t changes, you need to think in terms of high-end commercial devices, not common PCs This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks. Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com equipped with just a few NICs. The latter can survive with a limit of 256 bridge ports, or a single bridge ID per MAC address. However, it is not uncommon for big bridges to be equipped with hundreds of ports and to run hundreds of instances of bridges. Note also that 4,096 is not a random value: it represents the maximum number of Virtual LANs (VLANs) allowed in the 802.1Q protocol. The 802.1t changes do not have any impact on the STP. From the STP's perspective, a bridge ID is an 8-byte value and a port ID is a 2-byte value. The size or purpose of the user-configuration component does not matter. This means that the 802.1t changes affect only configuration tools, not the protocol's behavior. Tables 15-1 and 15-2 summarize the possible values of the different parameters. Table 15-1. Bridge IDs and port IDs before 802.1t Default valueMin. valueMax. valueMin. increment Bridge priority32,768065,5351 Port costDepends on port speed165,5351 Port priority12802551 Table 15-2. Bridge IDs and port IDs after 802.1t Default valueMin. valueMax. valueMin. increment Bridge priority32,768061,4404,096 Port costDepends on port speed1200,000,0001 Port priority128024016 This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks. Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks. Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 15.5. Bridge Protocol Data Units (BPDUs) Bridges exchange protocol frames, called BPDUs, that include enough information for them to agree on who is the root bridge, and to decide on the roles and states for their local ports. There are two kinds of BPDUs: Configuration BPDU Used to define the loop-free topology. You will see in the section "When to Transmit Configuration BPDUs" what conditions trigger the transmission of these BPDUs. Topology Change Notification (TCN) BPDU Used by a bridge to notify the root bridge about a detected topology change. See the section "Topology Changes." Figure 15-8 shows the format of both BPDUs. Note that the two types share the same first three fields and can be distinguished by the BPDU type parameter. Figure 15-8. a) Configuration BPDU; b) BPDU Table 15-3 shows the combinations of protocol ID and protocol version used by the three IEEE STPs. In this chapter, we will look only at the basic 802.1D protocol and briefly introduce the other two in the section "Overview of Newer Spanning Tree Protocols." This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks. Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Table 15-3. BPDU versions Protocol nameProtocol IDProtocol version STP (802.1D-1998)00 RSTP (802.1D-2002 or 802.1w)02 MSTP (802.1Q-2002 or 802.1s)03 15.5.1. Configuration BPDU Here is the meaning of the fields in the configuration BPDU: Flags Only two flags are used: TC (Topology Change) and TCA (Topology Change Acknowledgment). The use of both is described in the section "Topology Changes." Root Bridge ID ID of the root bridge. This is what the transmitting bridge thinks the current root bridge is. Root Path Cost Cost of the shortest path from the transmitting bridge to the root bridge. The cost is 0 when the transmitting bridge is (or thinks it is to become) the root bridge. Bridge ID ID of the transmitting bridge. Port ID Port identifier. See the section "Bridge and Port IDs" for its syntax. Message Age How much time has passed since the root bridge generated the information in this BPDU. See the section "BPDU Aging." This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks. Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com [...]... BR3 to be connected to BR1 and BR4 with a point-to-point link, as in Figure 15-13, when BR3 is powered up, BR1 and BR4 will enable their ports connected to BR3, assign these ports the designated role, and start transmitting configuration BPDUs Let's see how BR1, BR3, and BR4 react upon receiving each other's configuration BPDUs: The configuration BPDUs from BR1 and BR4 will have the following priority... as the root bridge The BPDU that BR3 receives from BR4 has a better priority vector than the one BR3 sent to BR4, but not as good as the one BR3 received from BR1 Because of that, BR4 does not change its current root port and root bridge information: port 1 is still the root port and BR1 is still the root bridge When BR3 transmits a new BPDU to BR4, as in Figure 15-13(b), it uses a new priority vector... new information acquired from BR1 Upon receiving that BPDU, BR4 recognizes the superior priority vector and it blocks its port 2 Note that BR3's priority vector wins over BR4's priority vector because of its lower path cost (i.e., BR3's port 2 is selected as the LAN-designated port because it is closer to the root bridge than BR4's port 2) BR4 selects port 1 as its root port because it is the one that... http://www.cisco.com/warp/public /47 3/122.html Table 15 -4 Bridge timers Timer Default value (in seconds) Allowed range Hello 2 1-10 Topology Change Forward Delay + Max Age Not configurable TCN Hello time Not configurable Addresses Aging a 300 or Forward Delay Not configurable a See the section "Topology Changes." Table 15-5 Port timers Timer Default value (in seconds) Allowed range Message Age 20 6 -40 Forward Delay 15 4- 30 Hold... selection of the root and designated ports Let's see now, with the example in Figure 15- 14, when the fourth one, the port ID, is needed as a tiebreaker Now BR4 receives two BPDUs from BR2 with the same values in the first three fields of the priority vector However, the fourth parameter (the port ID) allows BR4 to select its port 1 as its root port In the section "Root Port Selection," we also saw... configuration BPDU that BR4 receives from BR2 to the one it receives from BR3, you can see that they share the same root bridge ID (BR1) and the same root path cost (10), but that the third component of the priority vector is better than BR2's, because BR2's bridge ID is less than BR3's BR4 therefore selects port 1 as its root port An administrator who had a preference for BR4's link to BR3 over the... section "Transmitting Configuration BPDUs") 15.5 .4 BPDU Aging Because BPDUs are generated only by the root bridge, and are regenerated by the other bridges only upon the reception of a BPDU on their root port, it should be clear that the time taken by the information generated by the root bridge with its BPDUs to reach the leaf bridges is variable On a stable network, the time depends mainly on how loaded... by an unregistered ChmMagic, please go to http://www.bisenter.com to register it Thanks 15.6 .4 Examples of STP in Action Let's suppose we had the topology in Figure 15-12 Note that since there are no redundant links, there would be no need for the STP Let's assume: Bridge ID BR1 < Bridge ID BR2 < Bridge ID BR4 (so BR1 is the root bridge) Each bridge can configure the cost of its local interfaces independently... are not sufficient to identify a winning BPDU Figure 15- 14 Port ID as the tiebreaker moc.fdpopmis.www//:ptth - noisreV deretsigernU tilpS dna egreM FDP opmiS This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it Thanks 15.7 Timers The STP uses both per-bridge and per-port timers In Tables 15 -4 and 15-5, you can see the default timeouts, and what the... its own cost to the one sent out by BR1) Its own bridge ID BR2 A port ID of 2 Now let's add a new bridge named BR3, and assume that Bridge ID BR3 < Bridge ID BR4, as in Figure 15-13 As we explained in the section "Root Bridge Selection," when BR4 is first enabled it thinks it is the root bridge, and therefore it assigns the designated role to its two ports It sends out a configuration BPDU on each port, . which can assume 4, 096 different values, allows a network device, for example, to have up to 4, 096 different bridge IDs sharing a single MAC address. Before, this would have required 4, 096 different. valueMin. valueMax. valueMin. increment Bridge priority32,768061 ,44 04, 096 Port costDepends on port speed1200,000,0001 Port priority1280 240 16 This document was created by an unregistered ChmMagic,. now only 4 bits in size. For backward compatibility, the bridge priority range is still 0- 64 K, but since you have only four bits to play with, you now have priorities in increments of 4, 096 (2 12 ). There

Ngày đăng: 13/08/2014, 04:21

Từ khóa liên quan

Mục lục

  • Understanding Linux Network Internals

  • Table of Contents

  • Copyright

  • Preface

    • The Audience for This Book

    • Background Information

    • Organization of the Material

    • Conventions Used in This Book

    • Using Code Examples

    • We'd Like to Hear from You

    • Safari Enabled

    • Acknowledgments

    • Part I:  General Background

      • Chapter 1.  Introduction

        • Section 1.1.  Basic Terminology

        • Section 1.2.  Common Coding Patterns

        • Section 1.3.  User-Space Tools

        • Section 1.4.  Browsing the Source Code

        • Section 1.5.  When a Feature Is Offered as a Patch

        • Chapter 2.  Critical Data Structures

          • Section 2.1.  The Socket Buffer: sk_buff Structure

          • Section 2.2.  net_device Structure

          • Section 2.3.  Files Mentioned in This Chapter

          • Chapter 3.  User-Space-to-Kernel Interface

            • Section 3.1.  Overview

Tài liệu cùng người dùng

Tài liệu liên quan