Introduction
This document describes the how to use Cisco IOS® software to troubleshoot issues with Spanning Tree Protocol (STP).
Background Information
There are specific commands which apply to the Catalyst 6500/6000 only; however, you can apply most of the principles to any Cisco Catalyst switch that runs Cisco IOS software.
Issues with most STPs have these three problems:
-
Forwarding loops.
-
Excessive flooding due to a high rate of STP Topology Changes (TC).
-
Issues related to convergence time.
Because a bridge has no mechanism to track whether a certain packet is forwarded multiple times (for example, an IP Time to Live [TTL] is used to discard traffic that circulates for too long in the network, only one path can exist between two devices in the same Layer 2 (L2) domain.
The purpose of STP is to block redundant ports based on an STP algorithm, to resolve redundant physical topology into a tree-like topology. A forwarding loop (such as an STP loop) occurs when no port in a redundant topology is blocked, and traffic is forwarded in circles indefinitely.
Once the forwarding loop starts, it congests the lowest-bandwidth links along its path. if all the links are of the same bandwidth, all links are congested. This congestion causes packet loss and leads to a network down situation in the affected L2 domain.
With excessive flooding, the symptoms are not as apparent. Slow links can become congested by flooded traffic, and devices or users behind these congested links can experience slowness or total loss of connectivity.
Prerequisites
Requirements
Cisco recommends that you have knowledge of these topics:
-
Various Spanning Tree types and how to configure them. Refer toConfiguring STP and IEEE 802.1s MSTfor more information.
-
Various Spanning Tree features and how to configure them. Refer toConfiguring STP Featuresfor more information.
Components Used
The information in this document is based on these software and hardware versions:
-
Catalyst 6500 with Supervisor 2 engine
-
Cisco IOS Software Release 12.1(13)E
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
Conventions
Refer toCisco Technical Tips Conventionsfor more information on document conventions.
Causes of STP Failures
STP makes certain assumptions about its operational environment. These are the assumptions most relevant to this document:
-
Each link between the two bridges is bidirectional. This means that, if A directly connects to B, then A receives what B has sent and B receives what A has sent, as long as the link is up between them.
-
Each bridge that runs STP is able to regularly receive, process, and transmit STP Bridge Protocol Data Units (BPDUs), also known as STP packets.
While these assumptions appear logical and obvious, there are situations where they are not met. Most of these situations involve a type of hardware issue; however, software defects can also lead to STP failures. Various hardware failures, misconfigurations, connection problems cause the majority of STP failures, while software failures account for the minority. STP failures can also occur due to unnecessary additional connections that exist between the switches. VLANs go into a down state because of these additional connections. To resolve this problem, remove all of the unwanted connections between the switches.
When one of these assumptions is not met, one or more bridges cannot receive or process the BPDUs. This means that the bridge (or bridges) is not discover the network topology. Without knowledge of the correct topology, the switch cannot block the loops. Therefore, the flooded traffic circulates over the looped topology, consumes all bandwidth, and brings down the network.
Examples of why the switches cannot receive BPDUs include bad transceivers or Gigabit Interface Converters (GBICs), cable issues, or hardware failures on the port, the line card, or the Supervisor engine. One frequent reason for STP failures is a unidirectional link between the bridges. In such a condition, one bridge sends BPDUs, but the downstream bridge never receives them. STP processing can also be disrupted by an overloaded CPU (99 percent or more) because the switch is unable to process received BPDUs. BPDUs can be corrupted along the path from one bridge to the other, which also prevents proper STP behavior.
Aside from the forwarding loops, when no ports are blocked, there are situations when only certain packets are incorrectly forwarded through the ports that block traffic. In most cases, this is caused by software issues. Such behavior can cause “slow-loops.” This means some packets are looped, but the majority of the traffic is still flows through the network, because the links are not congested.
Troubleshoot Forwarding Loops
Forwarding loops vary greatly both in their origin (cause) and effect. Due to the wide variety of issues that can affect STP, this document can only provide general guidelines about how to troubleshoot forwarding loops.
Before you start to troubleshoot, you need this information:
-
An actual topology diagram that details all of the switches and bridges.
-
Their corresponding port numbers (interconnected).
-
STP configuration details, such as which switch is the root and backup root, which links have a non-default cost or priority, and the location of the ports that block traffic.
1. Identify the loop:
When a forwarding loop has developed in the network, the usual symptoms are:
-
Loss of connectivity to, from, and through affected network regions.
-
High CPU utilization on routers connected to affected segments or VLANs that can lead to various symptoms, such as routing protocol neighbor flapping or Hot Standby Router Protocol (HSRP) active router flapping.
-
High link utilization (often 100 percent).
-
High switch backplane utilization (compared to the baseline utilization).
-
Syslog messages that indicate packet looping in the network (for example HSRP duplicate IP address messages).
-
Syslog messages that indicate constant address relearning or MAC address flapping messages.
-
The number of outputs drops on many interfaces increases.
Any of these reasons alone can indicate different issues (or no issue at all). However, when many of these are observed at the same time, it is highly probable that a forwarding loop has developed in the network. The fastest way to verify this is to check the switch backplane traffic utilization:
cat#show catalyst6000 traffic-meter
traffic meter = 13% Never cleared
peak = 14% reached at 12:08:57 CET Fri Oct 4 2002
Note: The Catalyst 4000 with Cisco IOS software does not currently support this command.
If the current traffic level is excessive or if the baseline level is not known, check whether the peak level has been achieved recently and whether it is close to the current traffic level. For example, if the peak traffic level is 15 percent and it was reached just two minutes ago and current traffic level is 14 percent, that means the switch has an unusually high load. If the traffic load is at a normal level, then that probably means that there is either no loop or that this device is not involved in the loop. However, it still could be involved in a slow loop.
2. Discover the topology (scope) of the loop.
Once it has been established that the reason for the network outage is a forwarding loop, the highest priority is to stop the loop and restore the network operation.
To stop the loop, you must know which ports participate in the loop: look at the ports with the highest link utilization (packets per second). Theshow interfaceCisco IOS software command displays the utilization for each interface.
To display only the utilization information and the interface name (for a quick analysis), filter the egular expression output with the Cisco IOS software. Issue theshow interface | include line|/seccommand to display only the packet per second statistics and the interface name:
cat#show interface | include line|/sec GigabitEthernet2/1 is up, line protocol is down 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec GigabitEthernet2/2 is up, line protocol is down 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec GigabitEthernet2/3 is up, line protocol is up 5 minute input rate 99765230 bits/sec, 24912 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec GigabitEthernet2/4 is up, line protocol is up 5 minute input rate 1000 bits/sec, 27 packets/sec 5 minute output rate 101002134 bits/sec, 25043 packets/sec GigabitEthernet2/5 is administratively down, line protocol is down 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec GigabitEthernet2/6 is administratively down, line protocol is down 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec GigabitEthernet2/7 is up, line protocol is down 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec GigabitEthernet2/8 is up, line protocol is up 5 minute input rate 2000 bits/sec, 41 packets/sec 5 minute output rate 99552940 bits/sec, 24892 packets/sec
Pay attention to the interfaces with the highest link utilization. In this example, these are interfaces g2/3, g2/4, and g2/8; they are the ports that participate in the loop.
3. Break the loop.
To break the loop, you must shut down or disconnect the involved ports. It is particularly important not only to stop the loop but also to find and fix the root cause of the loop. It is relatively easier to break the loop
Note: You do not have to shut down or disconnect all ports at the same time. You can shut them down one at a time. It is better to shut down ports at the aggregation point affected by the loop, such as a distribution or core switch. If you shut down all of the ports at once and enable or reconnect them one-by-one, it does not work; the loop is stopped and cannot start immediately after the faulty port is reconnected. Therefore, it is difficult to correlate failure to any particular port.
Note: To break the loop, it is recommended that you collect information before you reboot the switches. Otherwise, subsequent root cause analysis is difficult. After you disable or disconnect each port, you must check whether the switch backplane utilization is back to a normal level.
Note: Keep in mind that ports do not sustain the loop but are flooding the traffic that arrives with the loop. When you shut down such flooding ports, you only reduce backplane utilization a small amount, but you do not stop the loop.
In the next example topology, the loop is between switches A, B, and D. Therefore, links AB, AD, and BD are sustained. If you shut down any of these links, you stop the loop. Links AC, AE, BC, and BE are just flooding traffic that arrives with the loop.
Looped and Flooded Traffic
After the support port is shut down, backplane utilization goes down to a normal value. You need to know which port’s shutdown brought the backplane utilization (and other ports’ utilization) to a normal level.
At this point, the loop is stopped, and the network operation improves; however, because the original cause of the loop was not fixed, there still are other issues.
4. Find and fix the cause of the loop.
Once the loop is stopped, you need to determine the reason the loop began. This is the difficult part of the process because the reasons can vary. It is also difficult to formalize an exact procedure which works in every case.
Guidelines:
-
Investigate the topology diagram to find a redundant path. This includes the support port found in the previous step that comes back to the same switch (the path packets talked during the loop). In the previous example topology, this path is AD-DB-BA.
-
For every switch on the redundant path, check whether the switch knows the correct STP root.
All switches in an L2 network must agree on a common STP root. It is a clear symptom of problems when bridges consistently display a different ID for the STP root in a particular VLAN or STP instance. Issue theshow spanning-tree vlan vlan-id command to display the root bridge ID for a given VLAN:
cat#show spanning-tree vlan 333
MST03
Spanning tree enabled protocol mstp
Root ID Priority 32771
Address 0050.14bb.6000
Cost 20000
Port 136 (GigabitEthernet3/8)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32771 (priority 32768 sys-id-ext 3)
Address 00d0.003f.8800
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Interface Role Sts Cost Prio.Nbr Status
---------------- ---- --- --------- -------- ------------------------
Gi3/8 Root FWD 20000 128.136 P2p
Po1 Desg FWD 20000 128.833 P2p
The VLAN number can be found from the port, because ports involved in the loop were established in previous steps. If the ports in question are trunks, often all VLANs on the trunk are involved. If this is not the case (for example, if it appears that the loop has happened on a single VLAN) then you can try to issue theshow interfaces | include L2|line|broadcastcommand (only on Supervisor 2 and later engines on Catalyst 6500/6000 series switches, because Supervisor 1 does not provide per-VLAN switching statistics). Look at VLAN interfaces only. The VLAN with the highest number of switched packets is often the one where the loop occurred:
cat#show interface | include L2|line|broadcast
Vlan1 is up, line protocol is up
L2 Switched: ucast: 653704527 pkt, 124614363025 bytes - mcast:
23036247 pkt, 1748707536 bytes
Received 23201637 broadcasts, 0 runts, 0 giants, 0 throttles
Vlan10 is up, line protocol is up
L2 Switched: ucast: 2510912 pkt, 137067402 bytes - mcast:
41608705 pkt, 1931758378 bytes
Received 1321246 broadcasts, 0 runts, 0 giants, 0 throttles
Vlan11 is up, line protocol is up
L2 Switched: ucast: 73125 pkt, 2242976 bytes - mcast:
3191097 pkt, 173652249 bytes
Received 1440503 broadcasts, 0 runts, 0 giants, 0 throttles
Vlan100 is up, line protocol is up
L2 Switched: ucast: 458110 pkt, 21858256 bytes - mcast:
64534391 pkt, 2977052824 bytes
Received 1176671 broadcasts, 0 runts, 0 giants, 0 throttles
Vlan101 is up, line protocol is up
L2 Switched: ucast: 70649 pkt, 2124024 bytes - mcast:
2175964 pkt, 108413700 bytes
Received 1104890 broadcasts, 0 runts, 0 giants, 0 throttles
In this example, VLAN 1 accounts for the highest number of broadcasts and L2-switched traffic. Ensure that the root port is correctly identified.
The root port must have the lowest cost to the root bridge (sometimes one path is shorter in terms of hops but longer in terms of cost, as low-speed ports have higher costs). To determine which port is considered the root for a given VLAN, issue theshow spanning-tree vlan vlan command:
cat#show spanning-tree vlan 333
MST03
Spanning tree enabled protocol mstp
Root ID Priority 32771
Address 0050.14bb.6000
Cost 20000
Port 136 (GigabitEthernet3/8)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32771 (priority 32768 sys-id-ext 3)
Address 00d0.003f.8800
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Interface Role Sts Cost Prio.Nbr Status
---------------- ---- --- --------- -------- ------------------------
Gi3/8 Root FWD 20000 128.136 P2p
Po1 Desg FWD 20000 128.833 P2p
Ensure that the BPDUs are received regularly on the root port and on ports that are supposed to block.
BPDUs are sent by the root bridge at everyhellointerval (two seconds by default). Non-root bridges receive, process, modify, and propagate the BPDUs that are received from the root. Issue theshow spanning-tree interface interface detail command to see if the BPDUs are received:
cat#show spanning-tree interface g3/2 detail Port 130 (GigabitEthernet3/2) of MST00 is backup blocking Port path cost 20000, Port priority 128, Port Identifier 128.130. Designated root has priority 0, address 0007.4f1c.e847 Designated bridge has priority 32768, address 00d0.003f.8800 Designated port id is 128.129, designated path cost 2000019 Timers: message age 4, forward delay 0, hold 0 Number of transitions to forwarding state: 0 Link type is point-to-point by default, Internal Loop guard is enabled by default on the port BPDU: sent 3, received 53 cat#show spanning-tree interface g3/2 detail Port 130 (GigabitEthernet3/2) of MST00 is backup blocking Port path cost 20000, Port priority 128, Port Identifier 128.130. Designated root has priority 0, address 0007.4f1c.e847 Designated bridge has priority 32768, address 00d0.003f.8800 Designated port id is 128.129, designated path cost 2000019 Timers: message age 5, forward delay 0, hold 0 Number of transitions to forwarding state: 0 Link type is point-to-point by default, Internal Loop guard is enabled by default on the port BPDU: sent 3, received 54
Note: One BPDU has been received between the two outputs of the command (the counter went from 53 to 54).
The counters shown are actually counters maintained by the STP process itself. This means that, if the receive counters incremented, not only was BPDU received by a physical port, but it was also received by the STP process. If the received BPDU counter does not increment on the port that is supposed to be the root alternate or backup port, then check whether if the port receives multicasts at all (BPDUs are sent as multicast). Issue theshow interface interface counterscommand:
cat#show interface g3/2 counters Port InOctets InUcastPkts InMcastPkts InBcastPkts Gi3/2 14873036 2 89387 0 Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts Gi3/2 114365997 83776 732086 19 cat#show interface g3/2 counters Port InOctets InUcastPkts InMcastPkts InBcastPkts Gi3/2 14873677 2 89391 0 Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts Gi3/2 114366106 83776 732087 19
A brief description for STP port roles can be found in theBrief Summary of STP port rolessection ofSpanning-Tree Protocol Enhancements using Loop Guard and BPDU Skew Detection Features. If no BPDUs are received, check whether the port counts the errors. Issue theshow interface interface counters errorscommand:
cat#show interface g4/3 counters errors Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards Gi4/3 0 0 0 0 0 0 Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Giants Gi4/3 0 0 0 0 0 0 0
It is possible that the BPDUs are received by the physical port but still do not reach the STP process. If the commands used in the previous two examples show that some multicasts are received, and errors are not counted, then check whether the BPDUs are dropped at the STP process level. Issue theremote command switch test spanning-tree process-statscommand on the Catalyst 6500:
cat#remote command switch test spanning-tree process-stats ------------------TX STATS------------------ transmission rate/sec = 2 paks transmitted = 5011226 paks transmitted (opt) = 0 opt chunk alloc failures = 0 max opt chunk allocated = 0 ------------------RX STATS------------------ receive rate/sec = 1 paks received at stp isr = 3947627 paks queued at stp isr = 3947627 paks dropped at stp isr = 0 drop rate/sec = 0 paks dequeued at stp proc = 3947627 paks waiting in queue = 0 queue depth = 7(max) 12288(total) --------------PROCESSING STATS--------------- queue wait time (in ms) = 0(avg) 540(max) processing time (in ms) = 0(avg) 4(max) proc switch count = 100 add vlan ports = 20 time since last clearing = 2087269 sec
The command used in this example displays the STP process statistics. It is important to verify that the drop counters do not increase and that received packets do increase. If received packets are not increased but the physical port does receive multicasts, verify that the packets are received by the switch in-band interface (the interface of the CPU). Issue theremote command switch show ibc | i rx_inputcommand on the Catalyst 6500/6000:
cat#remote command switch show ibc | i rx_input rx_inputs=5626468, rx_cumbytes=859971138 cat# remote command switch show ibc | i rx_input rx_inputs=5626471, rx_cumbytes=859971539
This example shows that, between the outputs, the in-band port has received 23 packets.
Note: These 23 packets are not only BPDU packets; this is a global counter for all packets received by the in-band port.
If there is no indication that BPDUs are dropped on the local switch or port, you must move to the switch on the other side of the link and verify whether that switch sends the BPDUs. Check to see if the BPDUs are sent regularly on non-root, designated ports. If, the port role concurs, the port sends BPDUs—but the neighbor does not receive them. Check whether BPDUs are sent. Issue theshow spanning-tree interface interface detailcommand:
cat#show spanning-tree interface g3/1 detail Port 129 (GigabitEthernet3/1) of MST00 is designated forwarding Port path cost 20000, Port priority 128, Port Identifier 128.129. Designated root has priority 0, address 0007.4f1c.e847 Designated bridge has priority 32768, address 00d0.003f.8800 Designated port id is 128.129, designated path cost 2000019 Timers: message age 0, forward delay 0, hold 0 Number of transitions to forwarding state: 0 Link type is point-to-point by default, Internal Loop guard is enabled by default on the port BPDU: sent 1774, received 1 cat#show spanning-tree interface g3/1 detail Port 129 (GigabitEthernet3/1) of MST00 is designated forwarding Port path cost 20000, Port priority 128, Port Identifier 128.129. Designated root has priority 0, address 0007.4f1c.e847 Designated bridge has priority 32768, address 00d0.003f.8800 Designated port id is 128.129, designated path cost 2000019 Timers: message age 0, forward delay 0, hold 0 Number of transitions to forwarding state: 0 Link type is point-to-point by default, Internal Loop guard is enabled by default on the port BPDU: sent 1776, received 1
In this example, two BPDUs are sent out between the outputs.
Note: The STP process maintains theBPDU: sentcounter. This means that the counter indicates that the BPDU was sent toward the physical port and is sent out. Check whether the port counters increase for transmitted multicast packets. Issue theshow interface interface counterscommand. This can help determine the BPDUs traffic flow.
cat#show interface g3/1 counters Port InOctets InUcastPkts InMcastPkts InBcastPkts Gi3/1 127985312 83776 812319 19 Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts Gi3/1 131825915 3442 872342 386 cat# show interface g3/1 counters Port InOctets InUcastPkts InMcastPkts InBcastPkts Gi3/1 127985312 83776 812319 19 Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts Gi3/1 131826447 3442 872346 386
With all of these steps, the idea is to find the switch or link where BPDUs are not received, sent, or processed. It is possible that the STP has calculated the correct state for the port, but due to a control plane issue, it is unable to set this state on the forwarding hardware. A loop can be created if the port is not blocked at the hardware level. If you think this is an issue in your network, contactCisco Technical Supportfor further assistance.
5. Restore the redundancy.
Once the device or link that causes the loop is found, this device must be isolated from the network, or the issue must be resolved.(such as replace the fibre or GBIC). The redundant links, disconnected in Step 3, must be restored.
It is important to not manipulate the device or link that causes the loop, because many conditions that lead to a loop is transient, intermittent, and unstable. This means that, if the condition is cleared in or after investigation, the condition does not occur for a while does or not occur at all. The condition must be recorded so that the Cisco Technical Support can investigate it further. It is important that you collect information about the condition before you reset the switches. If a condition is gone, it is impossible to determine the root cause of the loop. If you collect the information, you ensure that this issue does not cause the loop again. For more information, refer to the Securing the Network Against Forwarding Loops.
Investigate Topology Changes
The role of the Topology Change (TC) mechanism is to correct L2 forwarding tables after the topology has changed. This is necessary to avoid a connectivity outage because MAC addresses previously accessible through particular ports can change and become accessible through different ports. TC shortens the forwarding table age on all switches in the VLAN where the TC occurs. So, if the address is not relearned, it ages out and flooding occurs to ensure packets reach the destination MAC address.
TC is triggered by the change of a port’s STP state to or from the STPforwardingstate. After TC, even if the particular destination MAC address has aged out, flooding not continue for long. The address is relearned by the first packet that comes from the host whose MAC address has been aged out. The issue can arise when TC occur repeatedly, with short intervals. The switches are constantly fast aging their forwarding tables, so flooding can be nearly constant.
Note: With Rapid STP or Multiple STP (IEEE 802.1w and IEEE 802.1s), TC is triggered by a change of the port’s state toforwarding, as well as the role change fromdesignatedtoroot. With Rapid STP, the L2 forwarding table is immediately flushed, as opposed to 802.1d, which shortens the aging time. The immediate flushing of the forwarding table restores connectivity faster, but can cause more flooding
TC is a rare event in a well-configured network. When a link on a switch port goes up or down, there is eventually a TC, once the STP state of the port is changed to or fromforwarding. When the port is flapping, this would cause repetitive TCs and flooding.
Ports with the STP portfast feature enabled cannot cause TCs when they go to or from theforwarding state. The configuration of portfast on all end-device ports (such as printers, PCs, and servers) can limit TCs to a low amount and is highly recommended. For more information on TCs, refer toUnderstanding Spanning-Tree Protocol Topology Changes.
If there are repetitive TCs on the network, you must identify the source of these TCs and take action to reduce them, to bring the flooding to a minimum.
With 802.1d, STP information about a TC event is propagated among the bridges through a TC Notification (TCN), which is a special type of BPDU. If you follow the ports that receive TCN BPDUs, you can find the device that originated the TCs.
Find the Cause of the Flooding
You can determine that there is flooding from slow performance, packet drops on links that are not supposed to be congested, and the packet analyzer shows multiple unicast packets to the same destination that is not on the local segment. For more information on unicast flooding, refer toUnicast Flooding in Switched Campus Networks.
On a Catalyst 6500/6000 that runs Cisco IOS software, you can check the forwarding engine counter (only on the Supervisor 2 engine) to estimate the amount of flooding. Issue theremote command switch show earl statistics | i MISS_DA|ST_FRcommand:
cat#remote command switch show earl statistics | i MISS_DA|ST_FR
ST_MISS_DA = 18 530308834
ST_FRMS = 97 969084354
cat#remote command switch show earl statistics | i MISS_DA|ST_FR
ST_MISS_DA = 4 530308838
ST_FRMS = 23 969084377
In this example, the first column shows the change since the last time this command was executed, and the second column shows the cumulative value since the last reboot. The first line shows the amount of flooded frames, and the second line shows the amount of processed frames. If the two values are close together, or the first value increases at a high rate, it can that the switch is flooding traffic. However, this can only be used in conjunction with other ways to verify flooding, as the counters are not granular. There is one counter per switch, not per port or VLAN. It is normal to see some flooding packets, as the switch can always flood if the destination MAC address is not in the forwarding table. This can be the case when the switch receives a packet with a destination address that has not yet been learned.
Find the Source of the TCs
If the VLAN number is known for the VLAN where excessive flooding is occurs, check the STP counters to see if the number of TCs is high or regularly increments. Issue theshow spanning-tree vlan vlan-id detailcommand (in this example, VLAN 1 is used):
cat#show spanning-tree vlan 1 detail
VLAN0001 is executing the ieee compatible Spanning Tree protocol
Bridge Identifier has priority 32768, sysid 1, address 0007.0e8f.04c0
Configured hello time 2, max age 20, forward delay 15
Current root has priority 0, address 0007.4f1c.e847
Root port is 65 (GigabitEthernet2/1), cost of root path is 119
Topology change flag not set, detected flag not set
Number of topology changes 1 last change occurred 00:00:35 ago
from GigabitEthernet1/1
Times: hold 1, topology change 35, notification 2
hello 2, max age 20, forward delay 15
Timers: hello 0, topology change 0, notification 0, aging 300
If the VLAN number is not known, you can use the packet analyzer or check the TC counters for all VLANs.
Take Steps to Prevent Excessive TCs
You can monitor thenumber of topology changescounter to see if it regularly increases. Then, move to the bridge that is connected to the port that is shown, to receive the last TC (in the previous example, port GigabitEthernet1/1) and see from where the TC came for that bridge. This process must be repeated until the end-station port without STP portfast enabled is found, or until the flapping link is found that needs to be fixed. The entire procedure needs to be repeated if TCs come from other sources. If the link belongs to an end-host, you can configure the portfast feature to prevent the generation of TCs.
Note: In the Cisco IOS software STP implementation, the counter for TCs can only increment if a TCN BPDU is received by a port in a VLAN. If a normal configuration BPDU with a set TC flag is received, then the TC counter is not incremented. This means that, if you suspect a TC to be the reason for flooding, start to track down the sources for the TC from the STP root bridge in that VLAN. It can have the most accurate information about the number and source of the TCs.
Troubleshoot Convergence Time Related Issues
There are situations when the actual operation of STP does not match the expected behavior. These are the two most frequent issues:
-
STP convergence or reconvergence takes longer than expected.
-
The topology result is different than expected.
Most often, these are the reasons for this behavior:
-
A mismatch between the real and documented topology.
-
Misconfiguration, such as an inconsistent configuration of STP timers, a STP diameter that increases, or portfast misconfiguration.
-
Overloaded switch CPU during convergence or reconvergence.
-
Software defect.
As mentioned earlier, this document can only provide general guidelines for troubleshooting, due to the wide variety of issues that could affect STP. To understand why the convergence takes longer than expected, look at the sequence of STP events to find out what happens and in what order. Because the STP implementation in Cisco IOS software does not log outcomes (except for specific events, such as port inconsistencies), you can use Cisco IOS software to debug STP for a clearer view. For STP, with a Catalyst 6500/6000 that runs Cisco IOS software, processing is done on the Switch Processor (SP) (or Supervisor), so the debugs need to be enabled on the SP. For Cisco IOS software bridge groups, processing is done on the Route Processor (RP), so the debugs need to be enabled on the RP (MSFC).
Use STP Debug Commands
Many STPdebugcommands are intended for development engineering use. They do not provide any output that is meaningful to someone without detailed knowledge of the STP implementation in Cisco IOS software. Some debugs can provide output which is instantly readable, such as port state changes, role changes, events such as TCs, and a dump of received and transmitted BPDUs. This section does not provide a complete description of all of the debugs, but rather briefly introduces the most frequently used ones.
Note: When you usedebugcommands, enable the minimum necessary debugs. If real-time debugs are not needed, record the output to the log rather than print it to the console. Excessive debugs can overload the CPU and disrupt switch operation.
To direct debug output to the log instead of to the console or to Telnet sessions, issue thelogging console informationalandno logging monitorcommands in global configuration mode. To see the general events log, issue thedebug spanning-tree eventcommand for Per VLAN Spanning-Tree (PVST) and Rapid-PVST. This is the first debug that gives information about what happened with the STP. In Multiple Spanning-Tree (MST) mode, it does not work to issue thedebug spanning-tree eventcommand. Therefore, issue thedebug spanning-tree mstp rolescommand to see the port role changes. To see the port STP state changes, issue thedebug spanning-tree switch statecommand together with thedebug pm vpcommand:
cat-sp#debug spanning-tree switch state Spanning Tree Port state changes debugging is on cat-sp#debug pm vp Virtual port events debugging is on Nov 19 14:03:37: SP: pm_vp 3/1(333): during state forwarding, got event 4(remove) Nov 19 14:03:37: SP: @@@ pm_vp 3/1(333): forwarding -> notforwarding port 3/1 (was forwarding) goes down in vlan 333 Nov 19 14:03:37: SP: *** vp_fwdchange: single: notfwd: 3/1(333) Nov 19 14:03:37: SP: @@@ pm_vp 3/1(333): notforwarding -> present Nov 19 14:03:37: SP: *** vp_linkchange: single: down: 3/1(333) Nov 19 14:03:37: SP: @@@ pm_vp 3/1(333): present -> not_present Nov 19 14:03:37: SP: *** vp_statechange: single: remove: 3/1(333) Nov 19 14:03:37: SP: pm_vp 3/2(333): during state notforwarding, got event 4(remove) Nov 19 14:03:37: SP: @@@ pm_vp 3/2(333): notforwarding -> present Nov 19 14:03:37: SP: *** vp_linkchange: single: down: 3/2(333) Port 3/2 (was not forwarding) in vlan 333 goes down Nov 19 14:03:37: SP: @@@ pm_vp 3/2(333): present -> not_present Nov 19 14:03:37: SP: *** vp_statechange: single: remove: 3/2(333) Nov 19 14:03:53: SP: pm_vp 3/1(333): during state not_present, got event 0(add) Nov 19 14:03:53: SP: @@@ pm_vp 3/1(333): not_present -> present Nov 19 14:03:53: SP: *** vp_statechange: single: added: 3/1(333) Nov 19 14:03:53: SP: pm_vp 3/1(333): during state present, got event 8(linkup) Nov 19 14:03:53: SP: @@@ pm_vp 3/1(333): present -> notforwarding Nov 19 14:03:53: SP: STP SW: Gi3/1 new blocking req for 0 vlans Nov 19 14:03:53: SP: *** vp_linkchange: single: up: 3/1(333) Port 3/1 link goes up and blocking in vlan 333 Nov 19 14:03:53: SP: pm_vp 3/2(333): during state not_present, got event 0(add) Nov 19 14:03:53: SP: @@@ pm_vp 3/2(333): not_present -> present Nov 19 14:03:53: SP: *** vp_statechange: single: added: 3/2(333) Nov 19 14:03:53: SP: pm_vp 3/2(333): during state present, got event 8(linkup) Nov 19 14:03:53: SP: @@@ pm_vp 3/2(333): present -> notforwarding Nov 19 14:03:53: SP: STP SW: Gi3/2 new blocking req for 0 vlans Nov 19 14:03:53: SP: *** vp_linkchange: single: up: 3/2(333) Port 3/2 goes up and blocking in vlan 333 Nov 19 14:04:08: SP: STP SW: Gi3/1 new learning req for 1 vlans Nov 19 14:04:23: SP: STP SW: Gi3/1 new forwarding req for 0 vlans Nov 19 14:04:23: SP: STP SW: Gi3/1 new forwarding req for 1 vlans Nov 19 14:04:23: SP: pm_vp 3/1(333): during state notforwarding, got event 14(forward_notnotify) Nov 19 14:04:23: SP: @@@ pm_vp 3/1(333): notforwarding -> forwarding Nov 19 14:04:23: SP: *** vp_list_fwdchange: forward: 3/1(333) Port 3/1 goes via learning to forwarding in vlan 333
To understand why STP behaves in a certain way, it is often useful to see the BPDUs that are received and sent by the switch:
cat-sp#debug spanning-tree bpdu receive Spanning Tree BPDU Received debugging is on Nov 6 11:44:27: SP: STP: VLAN1 rx BPDU: config protocol = ieee, packet from GigabitEthernet2/1 , linktype IEEE_SPANNING , enctype 2, encsize 17 Nov 6 11:44:27: SP: STP: enc 01 80 C2 00 00 00 00 06 52 5F 0E 50 00 26 42 42 03 Nov 6 11:44:27: SP: STP: Data 0000000000000000074F1CE8470000001380480006525F0E4 080100100140002000F00 Nov 6 11:44:27: SP: STP: VLAN1 Gi2/1:0000 00 00 00 000000074F1CE847 00000013 80480006525F0E40 8010 0100 1400 0200 0F00
This debug works for PVST, Rapid-PVST, and MST modes; but it does not decode the contents of the BPDUs. However, you can use it to ensure that BPDUs are received. To see the contents of the BPDU, issue thedebug spanning-tree switch rx decodecommand together with thedebug spanning-tree switch rx processcommand for PVST and Rapid-PVST. Issue thedebug spanning-tree mstp bpdu-rxcommand to see the contents of the BPDU for MST:
cat-sp#debug spanning-tree switch rx decode Spanning Tree Switch Shim decode received packets debugging is on cat-sp#debug spanning-tree switch rx process Spanning Tree Switch Shim process receive bpdu debugging is on Nov 6 12:23:20: SP: STP SW: PROC RX: 0180.c200.0000<-0006.525f.0e50 type/len 0026 Nov 6 12:23:20: SP: encap SAP linktype ieee-st vlan 1 len 52 on v1 Gi2/1 Nov 6 12:23:20: SP: 42 42 03 SPAN Nov 6 12:23:20: SP: CFG P:0000 V:00 T:00 F:00 R:0000 0007.4f1c.e847 00000013 Nov 6 12:23:20: SP: B:8048 0006.525f.0e40 80.10 A:0100 M:1400 H:0200 F:0F00 Nov 6 12:23:22: SP: STP SW: PROC RX: 0180.c200.0000<-0006.525f.0e50 type/len 0026 Nov 6 12:23:22: SP: encap SAP linktype ieee-st vlan 1 len 52 on v1 Gi2/1 Nov 6 12:23:22: SP: 42 42 03 SPAN Nov 6 12:23:22: SP: CFG P:0000 V:00 T:00 F:00 R:0000 0007.4f1c.e847 00000013 Nov 6 12:23:22: SP: B:8048 0006.525f.0e40 80.10 A:0100 M:1400 H:0200 F:0F00
For the MST mode, you can enable detailed BPDU decode with thisdebugcommand:
cat-sp#debug spanning-tree mstp bpdu-rx Multiple Spanning Tree Received BPDUs debugging is on Nov 19 14:37:43: SP: MST:BPDU DUMP [rcvd_bpdu Gi3/2 Repeated] Nov 19 14:37:43: SP: MST: Proto:0 Version:3 Type:2 Role: DesgFlags[ F ] Nov 19 14:37:43: SP: MST: Port_id:32897 cost:2000019 Nov 19 14:37:43: SP: MST: root_id :0007.4f1c.e847 Prio:0 Nov 19 14:37:43: SP: MST: br_id :00d0.003f.8800 Prio:32768 Nov 19 14:37:43: SP: MST: age:2 max_age:20 hello:2 fwdelay:15 Nov 19 14:37:43: SP: MST: V3_len:90 PathCost:30000 region:STATIC rev:1 Nov 19 14:37:43: SP: MST: ist_m_id :0005.74 Nov 19 14:37:43: SP: MST:BPDU DUMP [rcvd_bpdu Gi3/2 Repeated] Nov 19 14:37:43: SP: MST: Proto:0 Version:3 Type:2 Role: DesgFlags[ F ] Nov 19 14:37:43: SP: MST: Port_id:32897 cost:2000019 Nov 19 14:37:43: SP: MST: root_id :0007.4f1c.e847 Prio:0 Nov 19 14:37:43: SP: MST: br_id :00d0.003f.8800 Prio:32768 Nov 19 14:37:43: SP: MST: age:2 max_age:20 hello:2 fwdelay:15 Nov 19 14:37:43: SP: MST: V3_len:90 PathCost:30000 region:STATIC rev:1 Nov 19 14:37:43: SP: MST: ist_m_id :0005.7428.1440 Prio:32768 Hops:18 Num Mrec: 1 Nov 19 14:37:43: SP: MST: stci=3 Flags[ F ] Hop:19 Role:Desg [Repeated] Nov 19 14:37:43: SP: MST: br_id:00d0.003f.8800 Prio:32771 Port_id:32897 Cost:2000028.1440 Prio:32768 Hops:18 Num Mrec: 1 Nov 19 14:37:43: SP: MST: stci=3 Flags[ F ] Hop:19 Role:Desg [Repeated] Nov 19 14:37:43: SP: MST: br_id:00d0.003f.8800 Prio:32771 Port_id:32897 Cost:20000
Note: For Cisco IOS Software Release 12.1.13E and later, conditional debugs for STP are supported. This means that you can debug BPDUs that are received or transmitted on a per-port or per-VLAN basis.
Issue the debug condition vlan vlan_num ordebug condition interface interface commands, to limit the scope of the debug output to per-interface or per-VLAN.
Secure the Network Against Forwarding Loops
Cisco has developed a number of features and enhancements to protect the networks against forwarding loops when a STP cannot manage certain failures.
When you troubleshoot the STP, it helps to isolate and possibly find the cause for a particular failure, while the implementation of these enhancements is the only way to secure the network against forwarding loops.
These are methods to protect your network against forwarding loops:
1. Enable Unidirectional Link Detection (UDLD) on all switch-to-switch links.
For more information on UDLD, refer toUnderstanding and Configuring the Unidirectional Link Detection Protocol Feature.
2. Enable Loop Guard on all switches.
For more information on Loop Guard, refer toSpanning-Tree Protocol Enhancements using Loop Guard and BPDU Skew Detection Features.
When enabled, UDLD and Loop Guard eliminate the majority of causes of forwarding loops. Rather than create a forwarding loop, the defective link (or all links dependent on the defective hardware) shut down or are blocked.
Note: While these two features appear somewhat redundant, each has its unique capabilities. Therefore, use both features at the same time to provide the highest level of protection. For a detailed comparison of UDLD and Loop Guard, refer toLoop Guard vs. Unidirectional Link Detection.
There are different opinions about whether you have to use aggressive or normal UDLD. The aggressive UDLD cannot provide more protection against loops compared to normal mode UDLD. Aggressive UDLD detects port-stuck scenarios (when the link is up, but there are no associated traffic blackholes). The downside of this added functionality is that aggressive UDLD can potentially disable links when no consistent failure is present. Often people confuse the modification of the UDLDhellointerval with the aggressive UDLD feature. This is incorrect. Timers can be modified in both UDLD modes.
Note: In rare cases, aggressive UDLD can shut down all of the uplink ports, which essentially isolates the switch from the rest of the network. For example, this could happen when both upstream switches experience extremely high CPU utilization and aggressive mode UDLD is used. Therefore, it is recommended that you configure times outs that cannot erode, if the switch does not have out-of-band management in place.
3. Enable portfast on all end-station ports.
You must enable portfast to limit the amount of TCs and subsequent flooding, which can affect the performance of the network. Only use this command with ports that connect to end stations. Otherwise, an accidental topology loop can cause a data-packet loop and disrupt the switch and network operation.
Caution: Exercise caution when you use the no spanning-tree portfast command. This command only removes any port specific portfast commands. This command implicitly enables portfast if you define the spanning-tree portfast default command in global configuration mode and if the port is not a trunk port. If you do not configure portfast globally, the no spanning-tree portfast command is equivalent to the spanning-tree portfast disable command.
4. Set EtherChannels todesirablemode on both sides (where supported) andnon-silentoption.
Desirablemode can enable Port Aggregation Protocol (PAgP) to ensure runtime consistency between the channeling peers. This gives an additional degree of protection against loops, especially during channel reconfigurations (such as when links join or leave the channel, and link failure detection). There is a built-in Channel Misconfiguration Guard, which is enabled by default, and which prevents forwarding loops due to channel misconfiguration or other conditions. For more information on this feature, refer toUnderstanding EtherChannel Inconsistency Detection.
5. Do not disable auto-negotiation (if supported) on switch-to-switch links.
Auto-negotiation mechanisms can convey remote fault information, which is the quickest way to detect failure at the remote side. If failure be detected at the remote side, the local side brings down the link even if the link gets pulses. Compared to high-level detection mechanisms such as UDLD, auto-negotiation is extremely fast (within microseconds) but lacks the end-to-end coverage of UDLD (such as the entire datapath: CPU—forwarding logic—port1—port2—forwarding logic—CPU versus port1—port2). Aggressive UDLD mode provides similar functionality to that of auto-negotiation with regards to failure detection. When negotiation is supported on both sides of the link, there is no need to enable aggressive mode UDLD.
6. Use caution when you tune the STP timers.
STP timers are dependent on each other and on the network topology. STP does not work correctly with arbitrary modifications made to the timers. For more information about STP timers, refer toUnderstanding and Tuning Spanning Tree Protocol Timers.
7. If denial of service attacks is possible, secure the network STP perimeter with Root Guard.
Root Guard and BPDU Guard allow you to secure STP against influence from the outside. If such an attack is a possibility, Root Guard and BPDU Guard must be used to protect the network. For more information on Root Guard and BPDU Guard, refer to these documents:
-
Spanning-Tree Protocol Root Guard Enhancement
-
Spanning Tree Portfast BPDU Guard Enhancement
8. Enable BPDU Guard on portfast-enabled ports, to prevent STP from the effect of unauthorized network devices (such as hubs, switches, and bridging routers) that are connected to the ports.
If you configure Root Guard correctly, it prevents the STP from influence from the outside. If BPDU Guard is enabled, it shuts down the ports that receive any BPDUs. This is useful to investigate incidents, because BPDU Guard produces the syslog message and shuts down the port. If Root or BPDU Guards do not prevent short-cycle loops, then two fast-enabled ports connect directly or through the hub.
9. Avoid user traffic on the management VLAN. The management VLAN is contained to a building block, not the entire network.
The switch management interface receives broadcast packets on the management VLAN. If excessive broadcasts occur (such as a broadcast storm or a malfunctioning application), the switch CPU can become overloaded, which could possibly distort STP operation.
10. A predictable (hardcoded) STP root and backup STP root placement.
The STP root and backup STP root must be configured so that convergence, in the case of failures, occurs in a predictable way and builds optimal topology in every scenario. Do not leave the STP priority at the default value, to prevent unpredictable root switch selection.
Related Information
- LAN Product Support
- LAN Switching Technology Support
Содержание
- ASR типичные проблемы серии 9000 с протоколами STP
- Параметры загрузки
- Об этом переводе
- Содержание
- Введение
- Проблема — несоответствие идентификаторов VLAN портов (PVID)
- Решение
- Фильтр BPDU на коммутаторах
- Блочный PVST + BPDU на ASR 9000
- Проблема — порты коммутатора спонтанно переключаются между блокированием и пересылкой при использовании нескольких разновидностей протокола связующего дерева (STP) через ASR 9000
- Решение
- Проблема — порты связующего дерева заблокированы вследствие обнаружения петли
- Решение
- ИТ База знаний
- Полезно
- Навигация
- Серверные решения
- Телефония
- Корпоративные сети
- Траблшутинг STP (Spanning tree protocol)
- Case #1
- Case #2
- Case #3
- Case #4
- Принцип работы протокола STP
- Причина создания STP
- Основы STP
- Выбор корневого коммутатора
- Блокирование избыточных каналов
- Состояния портов
- Роли портов
- Таймеры и сходимость протокола STP
ASR типичные проблемы серии 9000 с протоколами STP
Параметры загрузки
Об этом переводе
Этот документ был переведен Cisco с помощью машинного перевода, при ограниченном участии переводчика, чтобы сделать материалы и ресурсы поддержки доступными пользователям на их родном языке. Обратите внимание: даже лучший машинный перевод не может быть настолько точным и правильным, как перевод, выполненный профессиональным переводчиком. Компания Cisco Systems, Inc. не несет ответственности за точность этих переводов и рекомендует обращаться к английской версии документа (ссылка предоставлена) для уточнения.
Содержание
Введение
Этот документ описывает типичные проблемы, которые возникают при интеграции текущих пользовательских сетей со связующим деревом уровня 2 (L2) на коммутаторах Cisco IOS® с маршрутизаторами с агрегацией сервисов (ASR) серии Cisco 9000, которые работают под управлением Cisco IOS XR.
Проблема — несоответствие идентификаторов VLAN портов (PVID)
Коммутаторы Cisco IOS, которые работают на протоколе Per VLAN Spanning Tree Plus (PVST+), блокируют порты коммутатора, когда они принимают a блок данных протокола моста (BPDU) с несовместимым PVID. Эта проблема возникает, когда для устройства между коммутаторами меняются или транслируются метки IEEE 802.1Q на PVST + BPDU.
Если ASR 9000 предоставляет двухточечную или многоточечную услугу L2VPN между коммутаторами, которая использует PVST+ и перезаписывает метки VLAN, эти сообщения в системном журнале могут отображаться на коммутаторах на базе Cisco IOS:
Эта проблема возникает из-за метки PVID, которая включается с PVST + BPDU. Эта метка предназначена для обнаружения неверных конфигураций и предотвращения случайных петель. Вместе с тем в данном сценарии это приводит к блокировке всех концов и не позволяет проводить трафик.
Здесь представлена конфигурация ASR серии 9000 (a9k1):
Решение
Для предотвращения этой проблемы можно заблокировать PVST + BPDU. Если между коммутаторами есть доступные резервированные соединения, это действие отключает связующее дерево и может привести к образованию петель.
Внимание. : Будьте осторожны, когда блокируете BPDU, и отключите связующее дерево.
Фильтр BPDU на коммутаторах
BPDU заблокированы с функцией фильтра BPDU на коммутаторах. Фильтр BPDU блокирует BPDU в обоих направлениях, что приводит к отключению связующего дерева на порту. Фильтр BPDU предотвращает входящий и исходящий BPDU. При включении фильтрации BPDU на интерфейсе создается такая же ситуация, как и при отключении связующего дерева на нем, что может привести к образованию петель в связующем дереве.
На коммутаторах 1 и 2 включите фильтры BPDU с помощью команды:
Блочный PVST + BPDU на ASR 9000
Эта проблема не возникает, если настроить ASR9000 на отбрасывание PVST + BPDU. Это делается с использованием списка доступа к сервисам Ethernet уровня L2 с целью запрета пакетов, которые предназначены для отправки на MAC-адрес PVST+ BPDU.
PVST + BPDU для сети (не VLAN) 1 (несобственной) VLAN передаются на PVST + MAC-адрес (также называемый MAC-адресом протокола общего связующего дерева [SSTP], 0100.0ccc.cccd) и маркируются соответствующей меткой VLAN IEEE 802.1Q.
Этот список контроля доступа (ACL) может использоваться для блокирования PVST + BPDU:
Примените ACL к интерфейсу, настроенному как l2transport:
Проблема — порты коммутатора спонтанно переключаются между блокированием и пересылкой при использовании нескольких разновидностей протокола связующего дерева (STP) через ASR 9000
ASR9000 не создает связующего дерева по умолчанию, как и большинство коммутаторов Cisco IOS. В модели виртуального канала Ethernet (EVC) пакет BPDU является просто еще одним многоадресным пакетом L2. Типичной проблемой является несоответствие связующего дерева из-за нескольких разновидностей STP, которые работают на домене моста ASR 9000. Это проявляется несколькими различными способами.
Рассмотрим такую простую топологию:
Предположите, что коммутатор 1 использует множественное связующее дерево (MST), а коммутатор 2 использует PVST+. Если a9k1 не использует ни одной разновидности связующего дерева, коммутатор 1 считает его граничным портом. Коммутатор 1 возвращается к режиму PVST для сетей VLAN, которых нет в общем экземпляре связующего дерева 0 (CST0). Если это и есть необходимая модель, необходимо ознакомиться со взаимодействием MST и PVST, описанным в документе Описание множественного протокола связующего дерева (802.1s).
Теперь предположим, что используется MST на коммутаторе 1 и на интерфейсе a9k1, который приводит к коммутатору 1, но при этом используется PVST + на коммутаторе 2. PVST + BPDU проходят через домен моста и доходят до коммутатора 1. Затем коммутатор 1 распознает как пакеты BPDU MST от a9k1, так и PVST + BPDU от коммутатора 2, и это приводит к тому, что связующее дерево на порту коммутатора 1 постоянно переключается с блокирования на неблокирование, что, в свою очередь, приводит к потере трафика.
Коммутатор 1 предоставляет системные журналы:
Результат выполнения команды show spanning-tree interface показывает, что этот результат постоянно меняются на устройстве Cisco IOS коммутатора 1:
Решение
Есть три опции, которые можно использовать для предотвращения этой проблемы.
Проблема — порты связующего дерева заблокированы вследствие обнаружения петли
Когда коммутатор получает пакет BPDU связующего дерева, который отправляется на том же интерфейсе, коммутатор блокирует эту VLAN вследствие образования петли. Это типичная проблема, возникающая тогда, когда коммутатор с магистральным портом подключен к маршрутизатору ASR 9000, который предоставляет многоточечные сервисы L2, а ASR 9000 не перезаписывает метки VLAN в интерфейсах l2transport на том же домене моста.
Рассмотрим ту же простую топологию, которая была показана ранее. Вместе с тем теперь из-за схемы работы a9k1 несколько сетей VLAN от одного и того же магистрального интерфейса коммутатора, объединяются в одном домене моста.
Это конфигурация a9k1:
Она объединяет сети VLAN (2-4) в один домен моста на a9k1.
Модель ASR 9000 EVC не перезаписывает ни метки, ни почтовый протокол по умолчанию. Данные PVST + BPDU для VLAN2 приходят на интерфейс gig 0/1/0/31.2 и пересылаются обратно на gig 0/1/0/31.3 и gig 0/1/0/31.4. Так как конфигурация не является перезаписью действия почтового протокола входящего потока, BPDU возвращается неизменным. Коммутатор распознает эту ситуацию, так как получает обратно свой собственный пакет BPDU, и блокирует эту сеть VLAN из-за петли.
Команда show spanning-tree interface отображает заблокированную сеть VLAN:
Решение
Эта проблема устраняется посредством использования команды ethernet egress-filter strict в интерфейсах ASR 9000 l2transport.
Это не схема работы не является рекомендуемой. Вместе с тем, если это действительно необходимая схема работы, можно использовать это решение, чтобы коммутатор не получал пакет BPDU, который отправляется обратно в том же интерфейсе.
Можно использовать команду ethernet egress-filter strict в интерфейсах a9k1 l2transport или на глобальном уровне. Это пример в интерфейсе:
Команда ethernet egress-filter strict включает строгую фильтрацию точки потока Ethernet (EFP) для исходящего потока в интерфейсе. Только пакеты, которые проходят фильтр EFP входящего потока в интерфейсе, отправляются из этого интерфейса. Остальные пакеты отбрасываются в фильтре исходящего потока. Это означает, что если пакет, который является исходящим, не соответствует метке encapsulation dot1q, заданной в интерфейсе, то пакет не передается.
Источник
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Траблшутинг STP (Spanning tree protocol)
Часть.2 4 кейса по проблемам с STP
Предыдущая статья этого цикла:
Онлайн курс по Кибербезопасности
Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии
Следующая статья этого цикла:
Case #1
На рисунке представлена топология, состоящая из трех коммутаторов, и между коммутаторами у нас есть два канала связи для резервирования. Коммутатор А был выбран в качестве корневого моста для VLAN 1. Когда вы имеете дело со связующим деревом, лучше всего нарисовать небольшую схему сети и записать роли интерфейса для каждого коммутатора (назначенного, не назначенного/альтернативного или заблокированного). Обратите внимание, что одним из каналов связи между коммутатором A и коммутатором C является интерфейс Ethernet (10 Мбит). Все остальные каналы — это FastEthernet.
Мы используем команду show spanning-tree для проверки ролей интерфейса для коммутатора A и коммутатора C. Вы видите, коммутатор C выбрал свой интерфейс Ethernet 0/13 как корневой порт, а интерфейс FastEthernet 0/14 выбран в качестве альтернативного порта. Это не очень хорошая идея. Это означает, что мы будем отправлять весь трафик вниз по линии 10 Мбит, в то время как 100 Мбит не используется вообще. Когда коммутатор должен выбрать корневой порт он выберет его следующим образом:
Почему коммутатор выбрал интерфейс Ethernet 0/13?
Мы видим, что интерфейс Ethernet 0/13 и FastEthernet0/14 имеют одинаковую стоимость. Затем коммутатор С выберет самый низкий номер интерфейса, который является interface Ethernet 0/13.
После проверки конфигурации интерфейса, видно, что кто-то изменил стоимость интерфейса на 19 (по умолчанию для интерфейсов FastEthernet).
Уберем настройки команды cost.
После того, как мы убрали настройки команды cost, видно, что состояние порта изменилось. FastEthernet 0/14 теперь является корневым портом, а стоимость интерфейса Ethernet 0/13 равна 100 (это значение по умолчанию для интерфейсов Ethernet). Задача решена!
Извлеченный урок: убедитесь, что интерфейс, которым вы хотите сделать в качестве корневого порта, имеет наименьшую стоимость пути.
Case #2
Итак, новый сценарий. Все интерфейсы равны (FastEthernet). Коммутатор A является корневым мостом для VLAN 10, и после проверки ролей интерфейса мы находим следующее:
Хм, интересно. Коммутатор A является корневым мостом, а FastEthernet 0/17 был выбран в качестве резервного порта. Это то, что вы видите каждый день. Коммутатор B выбрал корневой порт, а все остальные интерфейсы являются альтернативными портами. Мы ничего не видим на коммутаторе С.
Мы видим, что Коммутатор A и Коммутатор B используют связующее дерево для VLAN 10. Коммутатор C, однако, не использует связующее дерево для VLAN 10. В чем может быть проблема?
Конечно, неплохо проверить, работают ли интерфейсы на коммутаторе C или нет (но, конечно, это то, что вы уже изучили и сделали в первой статье).
Интерфейсы выглядят хорошо. VLAN 10 активна на всех интерфейсах коммутатора C. Это означает, что остовное дерево должно быть активным для VLAN 10.
Давайте еще раз посмотрим на это сообщение. Это говорит о том, что остовное дерево для VLAN 10 не существует. Есть две причины, по которым можно увидеть это сообщение:
Мы подтвердили, что VLAN 10 активна на всех интерфейсах коммутатора C, поэтому, может быть, связующее дерево было отключено глобально? SwitchC(config)#spanning-tree vlan 10
Извлеченный урок: проверьте, включено ли связующее дерево.
Case #3
Давайте продолжим по другому сценарию! Та же топология. наш клиент жалуется на плохую работу. Начнем с проверки ролей интерфейсов:
Так почему же остовное дерево провалилось здесь? Здесь важно помнить, что связующему дереву требуются блоки BPDU, передаваемые между коммутаторами для создания топологии без петель. BPDU могут быть отфильтрованы из-за MAC access-lists, VLAN access-maps или из-за spanning-tree toolkit?
Ни на одном из коммутаторов нет VLAN access maps.
Нет списков доступа.
Нет port security. как насчет команд, связанных с остовным деревом?
Вот что-то есть!Фильтр BPDU был включен на интерфейсах FastEthernet 0/16 и 0/17 коммутатора B. Из-за этого коммутатор C не получает BPDU от коммутатора B.
Удалим настройки фильтра BPDU.
Теперь вы видите, что FastEthernet 0/16 и 0/17 являются альтернативными портами и блокируют трафик. Наша топология теперь без петель. проблема решена!
Извлеченный урок: убедитесь, что блоки BPDU не заблокированы и не отфильтрованы между коммутаторами.
Case #4
Новая топология. Коммутатор A был выбран в качестве корневого моста для VLAN 10. Все интерфейсы являются FastEthernet каналами.
После использования команды show spanning-tree vlan 10 вот, что мы видим. Все интерфейсы одинаковы, но по какой-то причине коммутатор B решил выбрать FastEthernet 0/16 в качестве корневого порта. Разве вы не согласны с тем, что FastEthernet 0/13 должен быть корневым портом? Стоимость доступа к корневому мосту ниже, чем у FastEthernet 0/16.
Есть несколько вещей, которые мы могли бы проверить, чтобы увидеть, что происходит:
Во-первых, всегда полезно проверить, активно ли связующее дерево для определенной VLAN. Можно отключить spanning-tree с помощью команды no spanning-tree vlan X. В этом сценарии связующее дерево активно для VLAN 10, потому что мы можем видеть на FastEthernet 0/16 и 0/17.
Мы знаем, что остовное дерево активно глобально для VLAN 10, но это не значит, что оно активно на всех интерфейсах. Мы можем использовать команду show interfaces switchport, чтобы проверить, работает ли VLAN 10 на интерфейсе FastEthernet 0/13 и 0/14. Это отобразит нам некоторую интересную информацию. Вы видите, что эти интерфейсы оказались в режиме доступа, и они находятся в VLAN 1.
Давайте изменим режим интерфейсов на магистральный, чтобы трафик VLAN 10 мог проходить через эти интерфейсы.
Ну вот, теперь все намного лучше выглядит. Трафик VLAN 10 теперь передается по интерфейсу FastEthernet 0/13 и 0/14, и вы видите, что интерфейс FastEthernet 0/13 теперь выбран в качестве корневого порта. Задача решена!
Извлеченный урок: убедитесь, что VLAN активна на интерфейсе, прежде чем рассматривать проблемы связующего дерева.
Полный курс по Сетевым Технологиям
В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer
Источник
Причина создания STP
Причиной создания протокола STP стало возникновение петель на коммутаторах. Что такое петля? Определение петли звучит так:
Петля коммутации (Bridging loop, Switching loop) — состояние в сети, при котором происходит бесконечная пересылка фреймов между коммутаторами, подключенными в один и тот же сегмент сети.
Из определения становится ясно, что возникновение петли создает большие проблемы — ведет к перегрузке свитчей и неработоспособности данного сегмента сети. Как возникает петля? На картинке ниже приведена топология, при которой будет возникать петля при отсутствии каких-либо защитных механизмов:
Возникновение петли при следующих условиях:
1. Какой-либо из хостов посылает бродкаст фрейм:
2. Также петля может образоваться и без отправки бродкаст фрейма.
Основы STP
Принцип работы данного протокола построен на том, что все избыточные каналы между коммутаторами логически блокируются и трафик через них не передается. Для построения топологии без избыточных каналов строится дерево (математический граф). Чтобы построить такое дерево вначале необходимо определить корень дерева, из которого и будет строиться граф. Поэтому первым шагом протокола STP является определение корневого коммутатора (Root Switch). Для определения Root Switch-a, коммутаторы обмениваются сообщениями BPDU. В общем, протокол STP использует два типа сообщений: BPDU — содержит информацию о коммутаторах и TCN — уведомляет о изменении топологии. Рассмотрим BPDU более детально. Про TCN более подробно поговорим ниже. При включении STP на коммутаторах, коммутаторы начинают рассылать BPDU сообщения. В данных сообщениях содержится следующая информация:
Фрейм BPDU имеет следующие поля:
Вот вывод информации о Bridge ID с коммутатора Switch1 из первой картинки. Priority — 32769 ( по умолчанию 32768 + Vlan Id), MAC-адреса — Address 5000.0001.0000:
Представим картину, коммутаторы только включились и теперь начинают строить топологию без петель. Как только коммутаторы загрузились, они приступают к рассылке BPDU, где информируют всех, что они являются корнем дерева. В BPDU в качестве Root Bridge ID, коммутаторы указывают собственный Bridge ID. Например, Switch1 отправляет BPDU коммутатору Switch3, а Switch3 отправляет к Switch1. BPDU от Switch1 к Switch3:
BPDU от Switch3 к Switch1:
Как видим из Root Identifier, оба коммутотара друг другу сообщают, что именно он является Root коммутатором.
Выбор корневого коммутатора
Пока топология STP не построена, обычный трафик не передается из-за специальных состояний портов, о которых будет сказано ниже. Итак, Switch3 получается BPDU от Switch1 и изучает данное сообщение. Switch3 смотрит в поле Root Bridge ID и видит, что там указан другой Root Bridge ID, чем в том сообщении, которое отправил сам Switch3. Он сравнивает Root Bridge ID в данном сообщении со своим Root Bridge ID и видит, что хоть Priority одинаковые, но MAC-адрес данного коммутатора (Switch1) лучше (меньше), чем у него. Поэтому Switch3 принимает Root Bridge ID от Switch1 и перестает отправлять свои BPDU, а только слушает BPDU от Switch1. Порт, на котором был получен наилучший BPDU становится Root Port-ом. Switch1 также получив BPDU от Switch3, проводит сравнение, но в этом случае поведение Switch1 не меняется, так как полученный BPDU содержит худший Root Bridge ID, чем у Switch1. Таким образом, между Switch1 и Switch3 был определен корневой коммутатор. По аналогичной схеме происходит выбор корневого коммутатора между Switch1 и Switch2. Порты Gi0/0 на Switch2 и Switch3 становятся Root Port — порт, который ведет к корневому коммутатору. Через данный порт коммутаторы Switch2 и Switch3 принимают BPDU от Root Bridge. Теперь разберемся, что произойдет с каналом между Switch2 и Switch3.
Блокирование избыточных каналов
Как мы видим из топологии, канал между Switch2 и Switch3 должен быть заблокирован для предотвращения образования петель. Как STP справляется с этим?
После того, как выбран Root Bridge, Switch2 и Switch3 перестают отправлять BPDU через Root Port-ы, но BPDU, полученные от Root Bridge, они пересылают через все свои остальные активные порты, при этом изменив в данных BPDU только следующие поля:
А Switch3 от Switch2 получает такой BPDU:
После обмена такими BPDU, Switch2 и Switch3 понимают, что топология избыточна. Почему коммутаторы понимают, что топология избыточна? И Switch2, и Switch3 в своих BPDU сообщают об одном и том же Root Bridge. Это означает, что к Root Bridge, относительно Switch3, существует два пути — через Switch1 и Switch2, а это и есть та самая избыточность против которой мы боремся. Также и для Switch2 два пути — через Switch1 и Switch3. Чтоб избавиться от этой избыточности
необходимо заблокировать канал между Switch3 и Switch2. Как это происходит?
Выбор на каком коммутатоторе заблокировать порт происходит по следующей схеме:
Здесь как оказалось заблокируется порт Gi 0/1 на коммутаторе Sw2. В данном голосовании определяющим становится Root Path Cost. Вернемся к нашей топологии. Так как путь до Root Bridge одинаковый, то в данном выборе побеждает Switch2, так как его priority равны, сравниваются Bridge ID. У Switch2 — 50:00:00:02:00:00, у Switch3 — 50:00:00:03:00:00. У Switch2 MAC-адрес лушче (меньше). После того, как выбор сделан, Switch3 перестает переслать какие-либо пакеты через данный порт — Gi1/0, в том числе и BPDU, а только слушает BPDU от Switch2. Данное состояние порта в STP называется Blocking(BLK). Порт Gi1/0 на Switch2 работает в штатном режиме и пересылает различные пакеты при необходимости, но Switch3 их сразу отбрасывает, слушая только BPDU. Таким образом, на данном примере мы построили топологию без избыточных каналов. Единственный избыточный канал между Switch2 и Switch3 был заблокирован при помощи перевода порта Gi1/0 на Switch3 в специальное состояние блокирования — BLK. Теперь более детально разберем механизмы STP.
Состояния портов
Мы говорили выше, что, например, порт Gi1/0 на Switch3 переходит в специальное состояние блокирования — Blocking. В STP существуют следующие состояния портов:
Blocking — блокирование. В данном состоянии через порт не передаются никакие фреймы. Используются для избежания избыточности топологии.
Listening — прослушивание. Как мы говорили выше, что до того, пока еще не выбран корневой коммутатор, порты находятся в специальном состоянии, где передаются только BPDU, фреймы с данными не передаются и не принимаются в этом случае. Состояние Listening не переходит в следующее даже, если Root Bridge определен. Данное состояние порта длится в течении Forward delay timer, который, по умолчанию, равен 15. Почему всегда надо ждать 15 секунд? Это вызвано осторожностью протокола STP, чтоб случайно не был выбран некорректный Root Bridge. По истечению данного периода, порт переходит в следующее состояние — Learning.
Learning — обучение. В данном состояние порт слушает и отправляет BPDU, но информацию с данными не отправляет. Отличие данного состояния от Listening в том, что фреймы с данными, который приходят на порт изучаются и информация о MAC-адресах заносится в таблицу MAC-адресов коммутатора. Переход в следующее состояние также занимает Forward delay timer.
Forwarding — пересылка. Это обычное состояние порта, в котором отправляются и пакеты BPDU, и фреймы с обычными данными. Таким образом, если мы пройдемся по схеме, когда коммутаторы только загрузились, то получается следующая схема:
Роли портов
Помимо состояний портов, также в STP нужны определить портам их роли. Это делается для того, чтоб на каком порте должен ожидаться BPDU от корневого коммутатора, а через какие порты передавать копии BPDU, полученных от корневого коммутатора. Роли портов следующие:
Root Port — корневой порт коммутатора. При выборе корневого коммутатора также и определяется корневой порт. Это порт через который подключен корневой коммутатор. Например, в нашей топологии порты Gi0/0 на Switch2 и Switch3 являются корневыми портами. Через данные порты Switch2 и Switch3 не отправляют BPDU, а только слушают их от Root Bridge. Возникает вопрос — как выбирается корневой порт? Почему не выбран порт Gi1/0? Через него ведь тоже можно иметь связь с коммутатором? Для определения корневого порта в STP используется метрика, которая указывает в поле BPDU — Root Path Cost (стоимость маршрута до корневого свича). Данная стоимость определяется по скорости канала.
Switch1 в своих BPDU в поле Root Path Cost ставит 0, так как сам является Root Bridge. А вот, когда Switch2, когда отправляет BPDU к Switch3, то изменяет данное поле. Он ставит Root Path Cost равным стоимости канала между собой и Switch1. На картинке BPDU от Switch2 и Switch3 можно увидеть, что в данном поле Root Path Cost равен 4, так как канал между Switch1 и Switch2 равен 1 Gbps. Если количество коммутаторов будет больше, то каждый следующий коммутатор будет суммировать стоимость Root Path Cost. Таблица Root Path Cost.
Designated Port — назначенный порт сегмента. Для каждого сегмента сети должен быть порт, который отвечает за подключение данного сегмента к сети. Условно говоря, под сегментом сети может подразумеваться кабель, который осуществляет подключение данного сегмента. Например, порты Gi0/2 на Switch1, Switch3 подключают отдельные сегменты сети, к которым ведет только данный кабель. Также, например, порты на Root Bridge не могут быть заблокированы и все являются назначенными портами сегмента. После данного пояснения можно дать более строгое определения для назначенных портов:
Designated Port (назначенный) — некорневой порт моста между сегментами сети, принимающий трафик из соответствующего сегмента. В каждом сегменте сети может быть только один назначенный порт. У корневого коммутатора все порты — назначенные.
Также важно заметить, что порт Gi1/0 на Switch2 также является назначенным, несмотря на то, что данный канал связи заблокированным на Switch3. Условно говоря, Switch2 не имеет информации о том, что на другом конце порт заблокирован.
Nondesignated Port — неназначенный порт сегмента. Non-designated Port (неназначенный) — порт, не являющийся корневым, или назначенным. Передача фреймов данных через такой порт запрещена. В нашем примере, порт Gi1/0 является неназначенным.
Disabled Port — порт который находится в выключенном состоянии.
Таймеры и сходимость протокола STP
После того, как STP завершил построение топологии без петель, остается вопрос — Как определять изменения в сети и как реагировать на них? Сообщения BPDU при помощи которых работает STP, рассылаются Root Bridge каждые 2 секунды, по умолчанию. Данный таймер называется Hello Timer. Остальные коммутаторы получив через свой root port данное сообщение пересылают его дальше через все назначенные порты. Выше сказано более подробно какие изменения происходят с BPDU при пересылки его коммутаторов. Если в течении времени, определенным таймером Max Age (по умолчанию — 20 секунд), коммутатор не получил ни одного BPDU от корневого коммутатора, то данное событие трактуется как потеря связи с Root Bridge. Для того, чтобы более корректно описать сходимость протокола необходимо изменить нашу топологию и поставить между коммутаторами хабы. Мы добавили хабы, чтоб при выходе из строя одного из коммутаторов или выхода из строя линка, другие коммутаторы не определяли это по падению линка, а использовали таймеры:
Перед тем, как начать также важно рассказать подробнее о другом типе сообщения STP — TCN. TCN рассылается коммутаторами в случае изменения топологии — как только на каком-либо коммутаторе изменилась топология, например, изменилось состояние интерфейса. TCN отправляется коммутатором только через Root Port. Как только корневой коммутатор получит TCN, он сразу меняет параметр времени хранения MAC-адресов в таблице с 300 секунд до 15 (для чего это делается будет сказано ниже) и в следующем BPDU, Root Switch проставляет флаг — TCA ( Topology Change Acknledgement ), который отправляется коммутатору отправившем TCN для уведовления о том, что TCN был получен. Как только TCN достигает Root Bridge, то он рассылает специальный BPDU, который содержится TCN флаг по всем остальным интерфейсам к другим коммутаторам. На картинке показана структура TCN:
TCN был включен в STP, чтоб некорневые коммутаторы могли уведовлять об изменении в сети. Обычными BPDU они этого делать не могут, так как некорневые коммутаторы не отправляют BPDU. Как можно заметить структура TCN не несет в себе никакой информации о том, что именно и где изменилось, а просто сообщает что где-то что-то изменилось. Теперь перейдем к рассмотрению вопроса о сходимости STP.
Посмотрим, что произойдет если мы отключим интерфейс Gi0/1 на Switch1 и посмотрим при помощи каких механизмов перестроится дерево STP. Switch2 перестанет получать BPDU от Switch1 и не будет получать BPDU от Switch3, так как на Switch3 данный порт заблокирован. У Switch2 уйдет 20 секунд ( Max Age Timer ), чтоб понять потерю связи с Root Bridge. До этого времени, Gi0/0 на Switch2 будет находится в состоянии Forwarding с ролью Root Port. Как только истечет Max Age Timer и Switch2 поймет потерю связи, он будет заново строить дерево STP и как это свойственно STP начнет считать себя Root Bridge. Он отправит новый BPDU, где укажет самого себя в качестве Root Bridge через все активные порты, в том числе и на Switch3. Но таймер Max Age, истекший на Switch2 также истек и на Switch3 для интерфейса Gi1/0. Данный порт уже 20 секунд не получал BPDU и данный порт перейдет в состояние LISTENING и отправит BPDU c указанием в качестве Root Bridge — Switch1. Как только Switch2 примет данный BPDU, он перестанет считать себя Root Bridge и выберет в качестве Root Port — интерфейс Gi1/0. В этот момент Switch2 также отправит TCN через Gi1/0, так как это новый Root Port. Это приведет к тому, что время хранения MAC-адресов на коммутаторах уменьшится с 300 секунд до 15. Но на этом работоспособность сети не восстановится полностью, необходимо подождать пока порт Gi1/0 на Switch3 пройдет состояние Listening, а затем Learning. Это займет время равное двум периодам Forward delay timer — 15 + 15 = 30 секунд. Что мы получаем — при потери связи Switch2 ждет пока истечет таймер Max Age = 20 секунд, заново выберает Root Bridge через другой интерфейс и ждет еще 30 секунд пока ранее заблокированный порт перейдет в состояние Forwarding. Суммарно получаем, что связь между VPC5 и VPC6 прервется на 50 секунд. Как было сказано несколькими предложениями выше при изменение Root Port с Gi0/0 на Gi1/0 на Switch2 был отправлен TCN. Если бы этого не произошло, то все MAC-адреса, изученные через порт Gi 0/0, оставались бы привязаны к Gi0/0. Например, MAC-адрес VPC5 и VPC7 несмотря на то, что STP завершит сходимость через 50 секунд, связь между VPC6 и VPC5, VPC7 не была бы восстановлена, так как все пакеты предназначенные VPC5, VPC7 отправлялись через Gi0/0. Надо было бы ждать не 50 секунд, а 300 секунд пока таблица MAC-адресов перестроится. При помощи TCN, время хранение изменилось с 300 секунд до 15 и пока интерфейс Gi1/0 на Switch3 проходил состояния Listening, а затем Learning и данные о MAC-адресах обновятся.
Также интересен вопрос, что произойдет, если мы заново включим интерфейс Gi0/1 на Switch1? При включение интерфейса Gi0/1, он, как и подобает, перейдет в состояние Listening и начнет рассылать BPDU. Как только Switch2 получит BPDU на порту Gi0/0, то сразу перевыберет свой Root Port, так как тут Cost будет наименьшем и начнет пересылать траффик через интерфейс Gi0/0, но нам необходимо подождать пока интерфейс Gi0/1 пройдет состояния Listening, Learning до Forwarding. И задержка будет уже не 50 секунд, а 30.
В протоколе STP также продуманы различные технологии для оптимизации и безопасности работы протокола STP. Более подробно в данной статье рассматривать их не буду, материалы по поводу них можно найти в избытке на различных сайтах.
Источник
I think that I shall never see
A graph more lovely than a tree.
A tree whose crucial propertyеу
Is loop-free connectivity.
A tree that must be sure to span
So packets can reach every LAN.
First, the root must be selected.
By ID, it is elected.
Least-cost paths from root are traced.
In the tree, these paths are placed.
A mesh is made by folks like me,
Then bridges find a spanning tree.
— Radia Joy Perlman
Все выпуски
6. Сети для самых маленьких. Часть шестая. Динамическая маршрутизация
5. Сети для самых маленьких: Часть пятая. NAT и ACL
4. Сети для самых маленьких: Часть четвёртая. STP
3. Сети для самых маленьких: Часть третья. Статическая маршрутизация
2. Сети для самых маленьких. Часть вторая. Коммутация
1. Сети для самых маленьких. Часть первая. Подключение к оборудованию cisco
0. Сети для самых маленьких. Часть нулевая. Планирование
В прошлом выпуске мы остановились на статической маршрутизации. Теперь надо сделать шаг в сторону и обсудить вопрос стабильности нашей сети.
Однажды, когда вы — единственный сетевой админ фирмы “Лифт ми Ап” — отпросились на полдня раньше, вдруг упала связь с серверами, и директора не получили несколько важных писем. После короткой, но ощутимой взбучки вы идёте разбираться, в чём дело, а оказалось, по чьей-то неосторожности выпал из разъёма единственный кабель, ведущий к коммутатору в серверной. Небольшая проблема, которую вы могли исправить за две минуты, и даже вообще избежать, существенно сказалась на вашем доходе в этом месяце и возможностях роста.
Итак, сегодня обсуждаем:
- проблему широковещательного шторма
- работу и настройку протокола STP и его модификаций (RSTP, MSTP, PVST, PVST+)
- технологию агрегации интерфейсов и перераспределения нагрузки между ними
- некоторые вопросы стабильности и безопасности
- как изменить схему существующей сети, чтобы всем было хорошо
Оборудование, работающее на втором уровне модели OSI (коммутатор), должно выполнять 3 функции: запоминание адресов, перенаправление (коммутация) пакетов, защита от петель в сети. Разберем по пунктам каждую функцию.
Запоминание адресов и перенаправление пакетов: Как мы уже говорили ранее, у каждого свича есть таблица сопоставления MAC-адресов и портов (aka CAM-table — Content Addressable Memory Table). Когда устройство, подключенное к свичу, посылает кадр в сеть, свич смотрит MAC-адрес отправителя и порт, откуда получен кадр, и добавляет эту информацию в свою таблицу. Далее он должен передать кадр получателю, адрес которого указан в кадре. По идее, информацию о порте, куда нужно отправить кадр, он берёт из этой же CAM-таблицы. Но, предположим, что свич только что включили (таблица пуста), и он понятия не имеет, в какой из его портов подключен получатель. В этом случае он отправляет полученный кадр во все свои порты, кроме того, откуда он был принят. Все конечные устройства, получив этот кадр, смотрят MAC-адрес получателя, и, если он адресован не им, отбрасывают его. Устройство-получатель отвечает отправителю, а в поле отправителя ставит свой адрес, и вот свич уже знает, что такой-то адрес находится на таком-то порту (вносит запись в таблицу), и в следующий раз уже будет переправлять кадры, адресованные этому устройству, только в этот порт. Чтобы посмотреть содержимое CAM-таблицы, используется команда show mac address-table. Однажды попав в таблицу, информация не остаётся там пожизненно, содержимое постоянно обновляется и если к определенному mac-адресу не обращались 300 секунд (по умолчанию), запись о нем удаляется.
Тут всё должно быть понятно. Но зачем защита от петель? И что это вообще такое?
Широковещательный шторм
Часто, для обеспечения стабильности работы сети в случае проблем со связью между свичами (выход порта из строя, обрыв провода), используют избыточные линки (redundant links) — дополнительные соединения. Идея простая — если между свичами по какой-то причине не работает один линк, используем запасной. Вроде все правильно, но представим себе такую ситуацию: два свича соединены двумя проводами (пусть будет, что у них соединены fa0/1 и fa0/24).
Одной из их подопечных — рабочих станций (например, ПК1) вдруг приспичило послать широковещательный кадр (например, ARP-запрос). Раз широковещательный, шлем во все порты, кроме того, с которого получили.
Второй свич получает кадр в два порта, видит, что он широковещательный, и тоже шлет во все порты, но уже, получается, и обратно в те, с которых получил (кадр из fa0/24 шлет в fa0/1, и наоборот).
Первый свич поступает точно также, и в итоге мы получаем широковещательный шторм (broadcast storm), который намертво блокирует работу сети, ведь свичи теперь только и занимаются тем, что шлют друг другу один и тот же кадр.
Как можно избежать этого? Ведь мы, с одной стороны, не хотим штормов в сети, а с другой, хотим повысить ее отказоустойчивость с помощью избыточных соединений? Тут на помощь нам приходит STP (Spanning Tree Protocol)
STP
Основная задача STP — предотвратить появление петель на втором уровне. Как это сделать? Да просто отрубить все избыточные линки, пока они нам не понадобятся. Тут уже сразу возникает много вопросов: какой линк из двух (или трех-четырех) отрубить? Как определить, что основной линк упал, и пора включать запасной? Как понять, что в сети образовалась петля? Чтобы ответить на эти вопросы, нужно разобраться, как работает STP.
STP использует алгоритм STA (Spanning Tree Algorithm), результатом работы которого является граф в виде дерева (связный и без простых циклов)
Для обмена информацией между собой свичи используют специальные пакеты, так называемые BPDU (Bridge Protocol Data Units). BPDU бывают двух видов: конфигурационные (Configuration BPDU) и панические “ААА, топология поменялась!” TCN (Topology Change Notification BPDU). Первые регулярно рассылаются корневым свичом (и ретранслируются остальными) и используются для построения топологии, вторые, как понятно из названия, отсылаются в случае изменения топологии сети (проще говоря, подключенииотключении свича). Конфигурационные BPDU содержат несколько полей, остановимся на самых важных:
- идентификатор отправителя (Bridge ID)
- идентификатор корневого свича (Root Bridge ID)
- идентификатор порта, из которого отправлен данный пакет (Port ID)
- стоимость маршрута до корневого свича (Root Path Cost)
Что все это такое и зачем оно нужно, объясню чуть ниже. Так как устройства не знают и не хотят знать своих соседей, никаких отношений (смежности/соседства) они друг с другом не устанавливают. Они шлют BPDU из всех работающих портов на мультикастовый ethernet-адрес 01-80-c2-00-00-00 (по умолчанию каждые 2 секунды), который прослушивают все свичи с включенным STP.
Итак, как же формируется топология без петель?
Сначала выбирается так называемый корневой мост/свич (root bridge). Это устройство, которое STP считает точкой отсчета, центром сети; все дерево STP сходится к нему. Выбор базируется на таком понятии, как идентификатор свича (Bridge ID). Bridge ID это число длиной 8 байт, которое состоит из Bridge Priority (приоритет, от 0 до 65535, по умолчанию 32768+номер vlan или инстанс MSTP, в зависимости от реализации протокола), и MAC-адреса устройства. В начале выборов каждый коммутатор считает себя корневым, о чем и заявляет всем остальным с помощью BPDU, в котором представляет свой идентификатор как ID корневого свича. При этом, если он получает BPDU с меньшим Bridge ID, он перестает хвастаться своим и покорно начинает анонсировать полученный Bridge ID в качестве корневого. В итоге, корневым оказывается тот свич, чей Bridge ID меньше всех.
Такой подход таит в себе довольно серьезную проблему. Дело в том, что, при равных значениях Priority (а они равные, если не менять ничего) корневым выбирается самый старый свич, так как мак адреса прописываются на производстве последовательно, соответственно, чем мак меньше, тем устройство старше (естественно, если у нас все оборудование одного вендора). Понятное дело, это ведет к падению производительности сети, так как старое устройство, как правило, имеет худшие характеристики. Подобное поведение протокола следует пресекать, выставляя значение приоритета на желаемом корневом свиче вручную, об этом в практической части.
Роли портов
После того, как коммутаторы померились айдями и выбрали root bridge, каждый из остальных свичей должен найти один, и только один порт, который будет вести к корневому свичу. Такой порт называется корневым портом (Root port). Чтобы понять, какой порт лучше использовать, каждый некорневой свич определяет стоимость маршрута от каждого своего порта до корневого свича. Эта стоимость определяется суммой стоимостей всех линков, которые нужно пройти кадру, чтобы дойти до корневого свича. В свою очередь, стоимость линка определяется просто- по его скорости (чем выше скорость, тем меньше стоимость). Процесс определения стоимости маршрута связан с полем BPDU “Root Path Cost” и происходит так:
- Корневой свич посылает BPDU с полем Root Path Cost, равным нулю
- Ближайший свич смотрит на скорость своего порта, куда BPDU пришел, и добавляет стоимость согласно таблице
Скорость порта Стоимость STP (802.1d) 10 Mbps 100 100 Mbps 19 1 Gbps 4 10 Gbps 2 - Далее этот второй свич посылает этот BPDU нижестоящим коммутаторам, но уже с новым значением Root Path Cost, и далее по цепочке вниз
Если имеют место одинаковые стоимости (как в нашем примере с двумя свичами и двумя проводами между ними — у каждого пути будет стоимость 19) — корневым выбирается меньший порт.
Далее выбираются назначенные (Designated) порты. Из каждого конкретного сегмента сети должен существовать только один путь по направлению к корневому свичу, иначе это петля. В данном случае имеем в виду физический сегмент, в современных сетях без хабов это, грубо говоря, просто провод. Назначенным портом выбирается тот, который имеет лучшую стоимость в данном сегменте. У корневого свича все порты — назначенные.
И вот уже после того, как выбраны корневые и назначенные порты, оставшиеся блокируются, таким образом разрывая петлю.
*На картинке маршрутизаторы выступают в качестве коммутаторов. В реальной жизни это можно сделать с помощью дополнительной свитчёвой платы.
Состояния портов
Чуть раньше мы упомянули состояние блокировки порта, теперь поговорим о том, что это значит, и о других возможных состояниях порта в STP. Итак, в обычном (802.1D) STP существует 5 различных состояний:
- блокировка (blocking): блокированный порт не шлет ничего. Это состояние предназначено, как говорилось выше, для предотвращения петель в сети. Блокированный порт, тем не менее, слушает BPDU (чтобы быть в курсе событий, это позволяет ему, когда надо, разблокироваться и начать работать)
- прослушивание (listening): порт слушает и начинает сам отправлять BPDU, кадры с данными не отправляет.
- обучение (learning): порт слушает и отправляет BPDU, а также вносит изменения в CAM- таблицу, но данные не перенаправляет.
- перенаправлениепересылка (forwarding): этот может все: и посылаетпринимает BPDU, и с данными оперирует, и участвует в поддержании таблицы mac-адресов. То есть это обычное состояние рабочего порта.
- отключен (disabled): состояние administratively down, отключен командой shutdown. Понятное дело, ничего делать не может вообще, пока вручную не включат.
Порядок перечисления состояний не случаен: при включении (а также при втыкании нового провода), все порты на устройстве с STP проходят вышеприведенные состояния именно в таком порядке (за исключением disabled-портов). Возникает закономерный вопрос: а зачем такие сложности? А просто STP осторожничает. Ведь на другом конце провода, который только что воткнули в порт, может быть свич, а это потенциальная петля. Вот поэтому порт сначала 15 секунд (по умолчанию) пребывает в состоянии прослушивания — он смотрит BPDU, попадающие в него, выясняет свое положение в сети — как бы чего ни вышло, потом переходит к обучению еще на 15 секунд — пытается выяснить, какие mac-адреса “в ходу” на линке, и потом, убедившись, что ничего он не поломает, начинает уже свою работу. Итого, мы имеем целых 30 секунд простоя, прежде чем подключенное устройство сможет обмениваться информацией со своими соседями. Современные компы грузятся быстрее, чем за 30 секунд. Вот комп загрузился, уже рвется в сеть, истерит на тему “DHCP-сервер, сволочь, ты будешь айпишник выдавать, или нет?”, и, не получив искомого, обижается и уходит в себя, извлекая из своих недр айпишник автонастройки. Естественно, после таких экзерсисов, в сети его слушать никто не будет, ибо “не местный” со своим 169.254.x.x. Понятно, что все это не дело, но как этого избежать?
Portfast
Для таких случаев используется особый режим порта — portfast. При подключении устройства к такому порту, он, минуя промежуточные стадии, сразу переходит к forwarding-состоянию. Само собой, portfast следует включать только на интерфейсах, ведущих к конечным устройствам (рабочим станциям, серверам, телефонам и т.д.), но не к другим свичам.
Есть очень удобная команда режима конфигурации интерфейса для включения нужных фич на порту, в который будут включаться конечные устройства: switchport host. Эта команда разом включает PortFast, переводит порт в режим access (аналогично switchport mode access), и отключает протокол PAgP (об этом протоколе подробнее в разделе агрегация каналов).
Виды STP
STP довольно старый протокол, он создавался для работы в одном LAN-сегменте. А что делать, если мы хотим внедрить его в нашей сети, которая имеет несколько VLANов?
Стандарт 802.1Q, о котором мы упоминали в статье о коммутации, определяет, каким образом вланы передаются внутри транка. Кроме того, он определяет один процесс STP для всех вланов. BPDU по транкам передаются нетегированными (в native VLAN). Этот вариант STP известен как CST (Common Spanning Tree). Наличие только одного процесса для всех вланов очень облегчает работу по настройке и разгружает процессор свича, но, с другой стороны, CST имеет недостатки: избыточные линки между свичами блокируются во всех вланах, что не всегда приемлемо и не дает возможности использовать их для балансировки нагрузки.
Cisco имеет свой взгляд на STP, и свою проприетарную реализацию протокола — PVST (Per-VLAN Spanning Tree) — которая предназначена для работы в сети с несколькими VLAN. В PVST для каждого влана существует свой процесс STP, что позволяет независимую и гибкую настройку под потребности каждого влана, но самое главное, позволяет использовать балансировку нагрузки за счет того, что конкретный физический линк может быть заблокирован в одном влане, но работать в другом. Минусом этой реализации является, конечно, проприетарность: для функционирования PVST требуется проприетарный же ISL транк между свичами.
Также существует вторая версия этой реализации — PVST+, которая позволяет наладить связь между свичами с CST и PVST, и работает как с ISL- транком, так и с 802.1q. PVST+ это протокол по умолчанию на коммутаторах Cisco.
RSTP
Все, о чем мы говорили ранее в этой статье, относится к первой реализация протокола STP, которая была разработана в 1985 году Радией Перлман (ее стихотворение использовано в качестве эпиграфа). В 1990 году эта реализации была включена в стандарт IEEE 802.1D. Тогда время текло медленнее, и перестройка топологии STP, занимающая 30-50 секунд (!!!), всех устраивала. Но времена меняются, и через десять лет, в 2001 году, IEEE представляет новый стандарт RSTP (он же 802.1w, он же Rapid Spanning Tree Protocol, он же Быстрый STP). Чтобы структурировать предыдущий материал и посмотреть различия между обычным STP (802.1d) и RSTP (802.1w), соберем таблицу с основными фактами:
| STP (802.1d) | RSTP (802.1w) |
| В уже сложившейся топологии только корневой свич шлет BPDU, остальные ретранслируют | Все свичи шлют BPDU в соответствии с hello-таймером (2 секунды по умолчанию) |
| Состояния портов | |
| — блокировка (blocking) — прослушивание (listening) — обучение (learning) — перенаправлениепересылка (forwarding) — отключен (disabled) |
— отбрасывание (discarding), заменяет disabled, blocking и listening — learning — forwarding |
| Роли портов | |
| — корневой (root), участвует в пересылке данных, ведет к корневому свичу — назначенный (designated), тоже работает, ведет от корневого свича — неназначенный (non-designated), не участвует в пересылке данных |
— корневой (root), участвует в пересылке данных — назначенный (designated), тоже работает — дополнительный (alternate), не участвует в пересылке данных — резервный (backup), тоже не участвует |
| Механизмы работы | |
| Использует таймеры: Hello (2 секунды) Max Age (20 секунд) Forward delay timer (15 секунд) |
Использует процесс proposal and agreement (предложение и соглашение) |
| Свич, обнаруживший изменение топологии, извещает корневой свич, который, в свою очередь, требует от всех остальных очистить их записи о текущей топологии в течение forward delay timer | Обнаружение изменений в топологии влечет немедленную очистку записей |
| Если не-корневой свич не получает hello- пакеты от корневого в течение Max Age, он начинает новые выборы | Начинает действовать, если не получает BPDU в течение 3 hello-интервалов |
| Последовательное прохождение порта через состояния Blocking (20 сек) — Listening (15 сек) — Learning (15 сек) — Forwarding | Быстрый переход к Forwarding для p2p и Edge-портов |
Как мы видим, в RSTP остались такие роли портов, как корневой и назначенный, а роль заблокированного разделили на две новых роли: Alternate и Backup. Alternate — это резервный корневой порт, а backup — резервный назначенный порт. Как раз в этой концепции резервных портов и кроется одна из причин быстрого переключения в случае отказа. Это меняет поведение системы в целом: вместо реактивной (которая начинает искать решение проблемы только после того, как она случилась) система становится проактивной, заранее просчитывающей “пути отхода” еще до появления проблемы. Смысл простой: для того, чтобы в случае отказа основного переключится на резервный линк, RSTP не нужно заново просчитывать топологию, он просто переключится на запасной, заранее просчитанный.
Ранее, для того, чтобы убедиться, что порт может участвовать в передаче данных, требовались таймеры, т.е. свич пассивно ждал в течение означенного времени, слушая BPDU. Ключевой фичей RSTP стало введение концепции типов портов, основанных на режиме работы линка- full duplex или half duplex (типы портов p2p или shared, соответственно), а также понятия пограничный порт (тип edge p2p), для конечных устройств. Пограничные порты назначаются, как и раньше, командой spanning-tree portfast, и с ними все понятно- при включении провода сразу переходим к forwarding-состоянию и работаем. Shared-порты работают по старой схеме с прохождением через состояния BLK — LIS — LRN — FWD. А вот на p2p-портах RSTP использует процесс предложения и соглашения (proposal and agreement). Не вдаваясь в подробности, его можно описать так: свич справедливо считает, что если линк работает в режиме полного дуплекса, и он не обозначен, как пограничный, значит, на нем только два устройства- он и другой свич. Вместо того, чтобы ждать входящих BPDU, он сам пытается связаться со свичом на том конце провода с помощью специальных proposal BPDU, в которых, конечно, есть информация о стоимости маршрута к корневому свичу. Второй свич сравнивает полученную информацию со своей текущей, и принимает решение, о чем извещает первый свич посредством agreement BPDU. Так как весь этот процесс теперь не привязан к таймерам, происходит он очень быстро- только подключили новый свич- и он практически сразу вписался в общую топологию и приступил к работе (можете сами оценить скорость переключения в сравнении с обычным STP на видео). В Cisco-мире RSTP называется PVRST (Per-Vlan Rapid Spanning Tree).
MSTP
Чуть выше, мы упоминали о PVST, в котором для каждого влана существует свой процесс STP. Вланы это довольно удобный инструмент для многих целей, и поэтому, их может быть достаточно много даже в некрупной организации. И в случае PVST, для каждого будет рассчитываться своя топология, тратиться процессорное время и память свичей. А нужно ли нам рассчитывать STP для всех 500 вланов, когда единственное место, где он нам нужен- это резервный линк между двумя свичами? Тут нас выручает MSTP. В нем каждый влан не обязан иметь собственный процесс STP, их можно объединять. Вот у нас есть, например, 500 вланов, и мы хотим балансировать нагрузку так, чтобы половина из них работала по одному линку (второй при этом блокируется и стоит в резерве), а вторая- по другому. Это можно сделать с помощью обычного STP, назначив один корневой свич в диапазоне вланов 1-250, а другой- в диапазоне 250-500. Но процессы будут работать для каждого из пятисот вланов по отдельности (хотя действовать будут совершенно одинаково для каждой половины). Логично, что тут хватит и двух процессов. MSTP позволяет создавать столько процесов STP, сколько у нас логических топологий (в данном примере- 2), и распределять по ним вланы. Думаем, нет особого смысла углубляться в теорию и практику MSTP в рамках этой статьи (ибо теории там ого-го), интересующиеся могут пройти по ссылке.
Агрегация каналов
Но какой бы вариант STP мы не использовали, у нас все равно существует так или иначе неработающий линк. А возможно ли задействовать параллельные линки по полной и при этом избежать петель? Да, отвечаем мы вместе с циской, начиная рассказ о EtherChannel.
Иначе это называется link aggregation, link bundling, NIC teaming, port trunkinkg
Технологии агрегации (объединения) каналов выполняют 2 функции: с одной стороны, это объединение пропускной способности нескольких физических линков, а с другой — обеспечение отказоустойчивости соединения (в случае падения одного линка нагрузка переносится на оставшиеся). Объединение линков можно выполнить как вручную (статическое агрегирование), так и с помощью специальных протоколов: LACP (Link Aggregation Control Protocol) и PAgP (Port Aggregation Protocol). LACP, опеределяемый стандартом IEEE 802.3ad, является открытым стандартом, то есть от вендора оборудования не зависит. Соответственно, PAgP — проприетарная цисковская разработка.
В один такой канал можно объединить до восьми портов. Алгоритм балансировки нагрузки основан на таких параметрах, как IP/MAC-адреса получателей и отправителей и порты. Поэтому в случае возникновения вопроса: “Хей, а чего так плохо балансируется?” в первую очередь смотрите на алгоритм балансировки.
Тема агрегации каналов заслуживает отдельной статьи, а то и книги, поэтому углубляться не будем, интересующимся- ссылка.
Port security
Теперь расскажем вкратце, как обеспечить безопасность сети на втором уровне OSI. В этой части статьи теория и практическая конфигурация совмещены. Увы, Packet Tracer не умеет ничего из упомянутых в этом разделе команд, поэтому все без иллюстраций и проверок.
Для начала, следует упомянуть команду конфигурации интерфейса switchport port-security, включающую защиту на определенном порту свича. Затем, с помощью switchport port-security maximum 1 мы можем ограничить количество mac-адресов, связанных с данным портом (т.е., в нашем примере, на данном порту может работать только один mac-адрес). Теперь указываем, какой именно адрес разрешен: его можно задать вручную switchport port-security mac-address адрес, или использовать волшебную команду switchport port-security mac-address sticky, закрепляющую за портом тот адрес, который в данный момент работает на порту. Далее, задаем поведение в случае нарушения правила switchport port-security violation {shutdown | restrict | protect}: порт либо отключается, и потом его нужно поднимать вручную (shutdown), либо отбрасывает пакеты с незарегистрированного мака и пишет об этом в консоль (restrict), либо просто отбрасывает пакеты (protect).
Помимо очевидной цели — ограничение числа устройств за портом — у этой команды есть другая, возможно, более важная: предотвращать атаки. Одна из возможных — истощение CAM-таблицы. С компьютера злодея рассылается огромное число кадров, возможно, широковещательных, с различными значениями в поле MAC-адрес отправителя. Первый же коммутатор на пути начинает их запоминать. Одну тысячу он запомнит, две, но память-то оперативная не резиновая, и среднее ограничение в 16000 записей будет довольно быстро достигнуто. При этом дальнейшее поведение коммутатора может быть различным. И самое опасное из них с точки зрения безопасности: коммутатор может начать все кадры, приходящие на него, рассылать, как широковещательные, потому что MAC-адрес получателя не известен (или уже забыт), а запомнить его уже просто некуда. В этом случае сетевая карта злодея будет получать все кадры, летающие в вашей сети.
DHCP Snooping
Другая возможная атака нацелена на DHCP сервер. Как мы знаем, DHCP обеспечивает клиентские устройства всей нужной информацией для работы в сети: ip-адресом, маской подсети, адресом шюза по умолчанию, DNS-сервера и прочим. Атакующий может поднять собственный DHCP, который в ответ на запрос клиентского устройства будет отдавать в качестве шлюза по умолчанию (а также, например, DNS-сервера) адрес подконтрольной атакующему машины. Соответственно, весь трафик, направленный за пределы подсети обманутыми устройствами, будет доступен для изучения атакующему — типичная man-in-the-middle атака. Либо такой вариант: подлый мошенник генерируют кучу DHCP-запросов с поддельными MAC-адресами и DHCP-сервер на каждый такой запрос выдаёт IP-адрес до тех пор, пока не истощится пул.
Для того, чтобы защититься от подобного вида атак, используется фича под названием DHCP snooping. Идея совсем простая: указать свичу, на каком порту подключен настоящий DHCP-сервер, и разрешить DHCP-ответы только с этого порта, запретив для остальных. Включаем глобально командой ip dhcp snooping, потом говорим, в каких вланах должно работать ip dhcp snooping vlan номер(а). Затем на конкретном порту говорим, что он может пренаправлять DHCP-ответы (такой порт называется доверенным): ip dhcp snooping trust.
IP Source Guard
После включения DHCP Snooping’а, он начинает вести у себя базу соответствия MAC и IP-адресов устройств, которую обновляет и пополняет за счет прослушивания DHCP запросов и ответов. Эта база позволяет нам противостоять еще одному виду атак — подмене IP-адреса (IP Spoofing). При включенном IP Source Guard, каждый приходящий пакет может проверяться на:
- соответствие IP-адреса источника адресу, полученному из базы DHCP Snooping (иными словами, айпишник закрепляется за портом свича)
- соответствие MAC-адреса источника адресу, полученному из базы DHCP Snooping
Включается IP Source Guard командой ip verify source на нужном интерфейсе. В таком виде проверяется только привязка IP-адреса, чтобы добавить проверку MAC, используем ip verify source port-security. Само собой, для работы IP Source Guard требуется включенный DHCP snooping, а для контроля MAC-адресов должен быть включен port security.
Dynamic ARP Inspection
Как мы уже знаем, для того, чтобы узнать MAC-адрес устройства по его IP-адресу, используется проткол ARP: посылается широковещательный запрос вида “у кого ip-адрес 172.16.1.15, ответьте 172.16.1.1”, устройство с айпишником 172.16.1.15 отвечает. Подобная схема уязвима для атаки, называемой ARP-poisoning aka ARP-spoofing: вместо настоящего хоста с адресом 172.16.1.15 отвечает хост злоумышленника, заставляя таким образом трафик, предназначенный для 172.16.1.15 следовать через него. Для предотвращения такого типа атак используется фича под названием Dynamic ARP Inspection. Схема работы похожа на схему DHCP-Snooping’а: порты делятся на доверенные и недоверенные, на недоверенных каждый ARP-ответ подвергаются анализу: сверяется информация, содержащаяся в этом пакете, с той, которой свич доверяет (либо статически заданные соответствия MAC-IP, либо информация из базы DHCP Snooping). Если не сходится- пакет отбрасывается и генерируется сообщение в syslog. Включаем в нужном влане (вланах): ip arp inspection vlan номер(а). По умолчанию все порты недоверенные, для доверенных портов используем ip arp inspection trust.
Практика
Наверное, большинство ошибок в Packet Tracer допущено в части кода, отвечающего за симуляцию STP, будте готовы. В случае сомнения сохранитесь, закройте PT и откройте заново
Итак, переходим к практике. Для начала внесем некоторые изменения в топологию — добавим избыточные линки. Учитывая сказанное в самом начале, вполне логично было бы сделать это в московском офисе в районе серверов — там у нас свич msk-arbat-asw2 доступен только через asw1, что не есть гуд. Мы отбираем (пока, позже возместим эту потерю) гигабитный линк, который идет от msk-arbat-dsw1 к msk-arbat-asw3, и подключаем через него asw2. Asw3 пока подключаем в порт Fa0/2 dsw1. Перенастраиваем транки:
msk-arbat-dsw1(config)#interface gi1/2
msk-arbat-dsw1(config-if)#description msk-arbat-asw2
msk-arbat-dsw1(config-if)#switchport trunk allowed vlan 2,3
msk-arbat-dsw1(config-if)#int fa0/2
msk-arbat-dsw1(config-if)#description msk-arbat-asw3
msk-arbat-dsw1(config-if)#switchport mode trunk
msk-arbat-dsw1(config-if)#switchport trunk allowed vlan 2,101-104msk-arbat-asw2(config)#int gi1/2
msk-arbat-asw2(config-if)#description msk-arbat-dsw1
msk-arbat-asw2(config-if)#switchport mode trunk
msk-arbat-asw2(config-if)#switchport trunk allowed vlan 2,3
msk-arbat-asw2(config-if)#no shutdown
Не забываем вносить все изменения в документацию!
Скачать актуальную версию документа.
Теперь посмотрим, как в данный момент у нас самонастроился STP. Нас интересует только VLAN0003, где у нас, судя по схеме, петля.
msk-arbat-dsw1>en
msk-arbat-dsw1#show spanning-tree vlan 3
Разбираем по полочкам вывод команды
Итак, какую информацию мы можем получить? Так как по умолчанию на современных цисках работает PVST+ (т.е. для каждого влана свой процесс STP), и у нас есть более одного влана, выводится информация по каждому влану в отдельности, каждая запись предваряется номером влана. Затем идет вид STP: ieee значит PVST, rstp — Rapid PVST, mstp то и значит. Затем идет секция с информацией о корневом свиче: установленный на нем приоритет, его mac-адрес, стоимость пути от текущего свича до корневого, порт, который был выбран в качестве корневого (имеет лучшую стоимость), а также настройки таймеров STP. Далее- секция с той же информацией о текущем свиче (с которого выполняли команду). Затем- таблица состояния портов, которая состоит из следующих колонок (слева направо):
- собственно, порт
- его роль (Root- корневой порт, Desg- назначенный порт, Altn- дополнительный, Back- резервный)
- его статус (FWD- работает, BLK- заблокирован, LIS- прослушивание, LRN- обучение)
- стоимость маршрута до корневого свича
- Port ID в формате: приоритет порта.номер порта
- тип соединения
Итак, мы видим, что Gi1/1 корневой порт, это дает некоторую вероятность того, что на другом конце линка корневой свич. Смотрим по схеме, куда ведет линк: ага, некий msk-arbat-asw1.
msk-arbat-asw1#show spanning-tree vlan 3
И что же мы видим?
VLAN0003
Spanning tree enabled protocol ieee
Root ID Priority 32771
Address 0007.ECC4.09E2
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Вот он, наш корневой свич для VLAN0003.
А теперь посмотрим на схему. Ранее, мы увидели в состоянии портов, что dsw1 блокирует порт Gi1/2, разрывая таким образом петлю. Но является ли это оптимальным решением? Нет, конечно. Сейчас наша новая сеть работает точь-в-точь как старая- трафик от asw2 идет только через asw1. Выбор корневого маршрутизатора никогда не нужно оставлять на совесть глупого STP. Исходя из схемы, наиболее оптимальным будет выбор в качестве корневого свича dsw1- таким образом, STP заблокирует линк между asw1 и asw2. Теперь это все надо объяснить недалекому протоколу. А для него главное что? Bridge ID. И он неслучайно складывается из двух чисел. Приоритет- это как раз то слагаемое, которое отдано на откуп сетевому инженеру, чтобы он мог повлиять на результат выбора корневого свича. Итак, наша задача сводится к тому, чтобы уменьшить (меньше-лучше, думает STP) приоритет нужного свича, чтобы он стал Root Bridge. Есть два пути:
1) вручную установить приоритет, заведомо меньший, чем текущий:
msk-arbat-dsw1>enable
msk-arbat-dsw1#configure terminal
msk-arbat-dsw1(config)#spanning-tree vlan 3 priority?
<0-61440> bridge priority in increments of 4096
msk-arbat-dsw1(config)#spanning-tree vlan 3 priority 4096
Теперь он стал корневым для влана 3, так как имеет меньший Bridge ID:
msk-arbat-dsw1#show spanning-tree vlan 3
VLAN0003
Spanning tree enabled protocol ieee
Root ID Priority 4099
Address 000B.BE2E.392C
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
2) дать умной железке решить все за тебя:
msk-arbat-dsw1(config)#spanning-tree vlan 3 root primary
Проверяем:
msk-arbat-dsw1#show spanning-tree vlan 3
VLAN0003
Spanning tree enabled protocol ieee
Root ID Priority 24579
Address 000B.BE2E.392C
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Мы видим, что железка поставила какой-то странный приоритет. Откуда взялась эта круглая цифра, спросите вы? А все просто- STP смотрит минимальный приоритет (т.е. тот, который у корневого свича), и уменьшает его на два шага инкремента (который составляет 4096, т.е. в итоге 8192). Почему на два? А чтобы была возможность на другом свиче дать команду spanning-tree vlan n root secondary (назначает приоритет=приоритет корневого-4096), что позволит нам быть уверенными, что, если с текущим корневым свичом что-то произойдет, его функции перейдут к этому, “запасному”. Вероятно, вы уже видите на схеме, как лампочка на линке между asw2 и asw1 пожелтела? Это STP разорвал петлю. Причем именно в том месте, в котором мы хотели. Sweet! Зайдем проверим: лампочка — это лампочка, а конфиг — это факт.
msk-arbat-asw2#show spanning-tree vlan 3
VLAN0003
Spanning tree enabled protocol ieee
Root ID Priority 24579
Address 000B.BE2E.392C
Cost 4
Port 26(GigabitEthernet1/2)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32771 (priority 32768 sys-id-ext 3)
Address 000A.F385.D799
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 20
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/1 Desg FWD 19 128.1 P2p
Gi1/1 Altn BLK 4 128.25 P2p
Gi1/2 Root FWD 4 128.26 P2p
Теперь полюбуемся, как работает STP: заходим в командную строку на ноутбуке PTO1 и начинаем бесконечно пинговать наш почтовый сервер (172.16.0.4). Пинг сейчас идет по маршруту ноутбук-asw3-dsw1-gw1-dsw1(ну тут понятно, зачем он крюк делает — они из разных вланов)-asw2-сервер. А теперь поработаем Годзиллой из SimСity: нарушим связь между dsw1 и asw2, вырвав провод из порта (замечаем время, нужное для пересчета дерева).
Пинги пропадают, STP берется за дело, и за каких-то 30 секунд коннект восстанавливается. Годзиллу прогнали, пожары потушили, связь починили, втыкаем провод обратно. Пинги опять пропадают на 30 секунд! Мда-а-а, как-то не очень быстро, особенно если представить, что это происходит, например, в процессинговом центре какого-нибудь банка.
Но у нас есть ответ медленному PVST+! И ответ этот — Быстрый PVST+ (так и называется, это не шутка: Rapid-PVST). Посмотрим, что он нам дает. Меняем тип STP на всех свичах в москве командой конфигурационного режима: spanning-tree mode rapid-pvst
Снова запускаем пинг, вызываем Годзиллу… Эй, где пропавшие пинги? Их нет, это же Rapid-PVST. Как вы, наверное, помните из теоретической части, эта реализация STP, так сказать, “подстилает соломку” на случай падения основного линка, и переключается на дополнительный (alternate) порт очень быстро, что мы и наблюдали. Ладно, втыкаем провод обратно. Один потерянный пинг. Неплохо по сравнению с 6-8, да?
EtherChannel
Помните, мы отобрали у офисных работников их гигабитный линк и отдали его в пользу серверов? Сейчас они, бедняжки, сидят, на каких-то ста мегабитах, прошлый век! Попробуем расширить канал, и на помощь призовем EtherChannel. В данный момент у нас соединение идет от fa0/2 dsw1 на Gi1/1 asw3, отключаем провод. Смотрим, какие порты можем использовать на asw3: ага, fa0/20-24 свободны, кажется. Вот их и возьмем. Со стороны dsw1 пусть будут fa0/19-23. Соединяем порты для EtherChannel между собой. На asw3 у нас на интерфейсах что-то настроено, обычно в таких случаях используется команда конфигурационного режима default interface range fa0/20-24, сбрасывающая настройки порта (или портов, как в нашем случае) в дефолтные. Packet tracer, увы, не знает такой хорошей команды, поэтому в ручном режиме убираем каждую настройку, и тушим порты (лучше это сделать, во избежание проблем)
msk-arbat-asw3(config)#interface range fa0/20-24
msk-arbat-asw3(config-if-range)#no description
msk-arbat-asw3(config-if-range)#no switchport access vlan
msk-arbat-asw3(config-if-range)#no switchport mode
msk-arbat-asw3(config-if-range)#shutdown
ну а теперь волшебная команда
msk-arbat-asw3(config-if-range)#channel-group 1 mode on
то же самое на dsw1:
msk-arbat-dsw1(config)#interface range fa0/19-23
msk-arbat-dsw1(config-if-range)#channel-group 1 mode on
поднимаем интерфейсы asw3, и вуаля: вот он, наш EtherChannel, раскинулся аж на 5 физических линков. В конфиге он будет отражен как interface Port-channel 1. Настраиваем транк (повторить для dsw1):
msk-arbat-asw3(config)#int port-channel 1
msk-arbat-asw3(config-if)#switchport mode trunk
msk-arbat-asw3(config-if)#switchport trunk allowed vlan 2,101-104
Как и с STP, есть некая трудность при работе с etherchannel в Packet Tracer’e. Настроить-то мы, в принципе, можем по вышеописанному сценарию, но вот проверка работоспособности под большим вопросом: после отключения одного из портов в группе, трафик перетекает на следующий, но как только вы вырубаете второй порт — связь теряется и не восстанавливается даже после включения портов.
Отчасти в силу только что озвученной причины, отчасти из-за ограниченности ресурсов мы не сможем раскрыть в полной мере эти вопросы и посему оставляем бОльшую часть на самоизучение.
Материалы выпуска
Новый план коммутации
Файл PT с лабораторной.
Конфигурация устройств
STP или STP
Безопасность канального уровня
Агрегация каналов
По сложившейся традиции все неотвеченные вопросы безымянными читателями хабра задаются в блоге цикла в ЖЖ.
За видео и помощь в подготовке статьи спасибо eucariot
1. Лабораторная работа №1 «Развертывание коммутируемой сети с резервными каналами»
2. Лабораторная работа №2 «Настройка Rapid PVST+ PortFast и BPDU Guard»
3. Лабораторная работа №3 «Настройка протоколов HSRP и GLBP»
4. Лабораторная работа №4 «Определение типовых ошибок конфигурации STP»
5. Лабораторная работа №5 «Настройка EtherChannel»
5.1. Настройка EtherChannel_1 Скачать файл_1
6. Лабораторная работа №6 «Поиск и устранение неполадок в работе EtherChannel» Скачать файл
7. Лабораторная работа №7 «Агрегирование каналов. Настройка VRRP и EtherChannel»
8. Лабораторная работа №8 Настройка RIPv2 с VLSM и распространением маршрута по умолчанию
9. Лабораторная работа №9 «Настройка беспроводного маршрутизатора и клиента»
10. Лабораторная работа №10 «Настройка базового протокола OSPFv2 для одной области»
11. Лабораторная работа №11 «Настройка расширенных функций OSPFv2»
12. Лабораторная работа №12 «Поиск и устранение неполадок в работе усовершенствованного протокола OSPFv2 для одной области»
13. Лабораторная работа №13 «Базовая настройка протокола OSPFv3»
14. Лабораторная работа №14 «Поиск и устранение неполадок в работе основных протоколов OSPFv2 и OSPFv3 для одной области»
15. Лабораторная работа №15 «Настройка базового протокола OSPFv2 для множественного доступа»
16. Лабораторная работа №16 «Поиск и устранение неполадок в работе OSPFv2 и OSPFv3 для нескольких областей»
17. Лабораторная работа №17 «Базовая настройка протокола EIGRP с IPv4» Скачать файл
18. Лабораторная работа №18 «Базовая настройка протокола EIGRP с IPv6» Скачать файл
19. Лабораторная работа №19 «Ручная настройка суммарных маршрутов EIGRP для IPv4 и IPv6» Скачать файл
20. Лабораторная работа №20 «Распространение маршрута по умолчанию в EIGRP для IPv4 и IPv6» Скачать файл
21. Лабораторная работа №21 «Поиск и устранение неполадок базового EIGRP для IPv4 и IPv6»
22. Лабораторная работа №22 «Настройка расширенных функций EIGRP для IPv4»
23. Лабораторная работа № 23 «Поиск и устранение неполадок в работе расширенной версии EIGRP»
24. Лабораторная работа №24 «Заключительный проект по EIGRP»
25. Лабораторная работа №25 «Заключительный проект по OSPF»
26. Лабораторная работа №26 «Поиск и устранение неполадок в работе последовательных интерфейсов» Скачать файл
27. Лабораторная работа №27 «Настройка аутентификации протоколов PAP и CHAP» Скачать файл
28. Лабораторная работа №28 «Отладка базового PPP с аутентификацией» Скачать файл
29. Лабораторная работа №29 «Настройка подынтерфейсов «точка-точка» Frame Relay» Скачать файл
30. Лабораторная работа №30 «Изучение принципа работы NAT» Скачать файл
30.1. Настройка статического NAT Скачать файл
30.2. Настройка динамического NAT Скачать файл
31. Лабораторная работа №31 «Реализация статического и динамического NAT» Скачать файл
31.1. Настройка преобразования адреса и номера порта (PAT)
32. Лабораторная работа №32 «Отладка настроек NAT»
32.1. Проверка и отладка настроек NAT Скачать файл
33. Лабораторная работа №33 «Настройка маршрутизатора в качестве клиента PPPoE для подключения DSL»
34. Лабораторная работа №34 «Настройка сетей VPN» Скачать файл
35. Лабораторная работа №35 «Настройка протокола GRE» Скачать файл_1 Скачать файл_2
36. Лабораторная работа №36 «Настройка туннеля VPN GRE по схеме «точка-точка»» Скачать файл
36.1. Настройка туннеля VPN GRE по схеме «точка-точка»
37. Лабораторная работа №37 «Конфигурирование SYSLOG и NTP» Скачать файл
37.1. Настройка протоколов Syslog и NTP
38. Лабораторная работа №38 «Настройка SNMP»
39. Лабораторная работа №39 «Сбор и анализ данных NetFlow»
40. Лабораторная работа №40 «Устранение проблем. Документирование сети» Скачать файл
41. Лабораторная работа №41 «Отладка корпоративных сетей 1-3»
41.1. Отладка корпоративных сетей 1 Скачать файл
41.2. Отладка корпоративных сетей 2 Скачать файл
41.3. Отладка корпоративных сетей 3 Скачать файл
42. Лабораторная работа №42 «Поиск и устранение неполадок. Использование документации для решения проблем» Скачать файл
Программы для лабораторных работ:
Скачать Cisco Packet Tracer
Скачать GNS3
Скачать образы для Cisco:
c2691
c3660
c3725
c3745
c7200
Скачать Wireshark
Команды CISCO
Введение в STP
Обзор STP:
Протокол Spanning Tree Protocol (STP) преобразует кольцевую сеть в сеть с ациклическим деревом, избегая распространения и бесконечной циркуляции пакетов в кольцевой сети.
В сложной сетевой среде неизбежно возникнут петли. Из-за потребности в резервном резервном копировании разработчики сетей стремятся развернуть несколько физических каналов между устройствами, одно из которых используется в качестве основного канала, а другие каналы используются в качестве резервного, что может вызвать образование петель.
Цикл вызовет широковещательный шторм, который в конечном итоге приведет к исчерпанию всех сетевых ресурсов, и сеть будет парализована и станет непригодной для использования. Цикл также может вызвать колебание таблицы MAC-адресов и привести к уничтожению записей таблицы MAC-адресов.
Чтобы разорвать петлю, можно использовать протокол уровня канала передачи данных STP. Устройства, использующие этот протокол, обнаруживают петли в сети, обмениваясь информацией друг с другом, и выборочно блокируют определенные порты, и, наконец, сокращают структуру кольцевой сети до петли. Древовидная сетевая структура дороги предотвращает непрерывную циркуляцию пакетов в кольцевой сети и предотвращает повторное получение устройством одного и того же пакета, что приводит к падению производительности обработки.
Понятия, связанные с STP:
-
Корневой мост
Древовидная сетевая структура должна иметь корень дерева, поэтому STP / RSTP вводит понятие корневого моста (Root Bridge).
Для сети STP / RSTP существует один и только один корневой мост, который является логическим центром всей сети, но не обязательно физическим центром. Однако корневой мост может измениться в соответствии с изменениями топологии сети.
-
BID (идентификатор моста): идентификатор моста
Стандарт IEEE 802.1d предусматривает, что BID состоит из 2-байтового приоритета моста (приоритет моста) и MAC-адреса моста, то есть BID (8 байтов) = приоритет моста (2 байта) + MAC-адрес моста (6 байтов). ,
В сети STP в качестве корневого моста выбирается устройство с наименьшим идентификатором моста. На оборудовании Huawei приоритет моста поддерживает ручную настройку.
-
PID (Port ID): ID порта
PID состоит из двух частей: PID (16 бит) = приоритет порта (4 бита) + номер порта (12 бит).
PID используется только для выбора назначенных портов в некоторых случаях, то есть при выборе назначенных портов, когда стоимость корневого пути для двух портов и BID отправляющего и коммутирующего устройства одинаковы, сравните PID портов, и меньший PID является назначенным портом. ,
-
Стоимость пути (RPC)
Стоимость пути — это эталонное значение, используемое протоколом STP / RSTP для выбора канала. Протокол STP / RSTP выбирает более «сильные» ссылки путем вычисления стоимости пути, блокирует избыточные ссылки и преобразует сеть в древовидную структуру без петель. Стоимость пути к портам корневого устройства равна 0.
В сети STP / RSTP совокупная стоимость пути от порта к корневому мосту — это стоимость каждого порта на каждом мосту, который он проходит.
-
PC（port cost）
Расчет ПК должен производиться на основе пропускной способности порта.
Роль порта:
-
Корневой порт (RP):
То есть порт, ближайший к пути корневого моста. Корневой порт отвечает за пересылку данных в направлении корневого моста, а корневой порт также отвечает за получение пакетов BPDU от восходящих устройств и пересылку пользовательского трафика. Критерий выбора корневого порта основан на стоимости корневого пути. Среди всех портов с поддержкой STP на устройстве тот, у которого наименьшая стоимость корневого пути, является корневым портом. На устройстве, на котором работает протокол STP / RSTP, есть один и только один корневой порт, и на корневом мосте нет корневого порта.
-
Назначенный порт (DR):
Для коммутирующего устройства его назначенный порт — это порт, который пересылает пакеты BPDU нисходящему коммутационному устройству. Все порты корневого моста являются назначенными портами. Каждый сетевой сегмент кольцевой сети будет выбирать назначенный порт, а коммутационное устройство с назначенным портом в сетевом сегменте называется назначенным мостом сетевого сегмента.
-
Альтернативный порт (AP):
Порт заблокирован из-за сообщений конфигурации BPDU, отправленных другими устройствами, в качестве резервного порта корневого порта, обеспечивает другой переключаемый путь от назначенного моста к корневому.
Статус порта:
| Статус порта | цель | Описание |
|---|---|---|
| Forwarding | Порт не только пересылает пользовательский трафик, но и обрабатывает пакеты BPDU. | Только корневой порт или назначенный порт может войти в состояние пересылки. |
| Устройство составляет таблицу MAC-адресов на основе полученного пользовательского трафика, но не пересылает пользовательский трафик. | Состояние перехода, добавьте состояние обучения, чтобы предотвратить временный цикл. (15с) | |
| Listening | Определите роль порта и выберите корневой мост, корневой порт и назначенный порт. | Переходное состояние. (15с) |
| блокировка | Порт плотно принимает и обрабатывает пакеты BPDU и не пересылает пользовательский трафик. | Конечное состояние заблокированного порта. |
| Отключено | Порт не обрабатывает пакеты BPDU и не пересылает пользовательский трафик. | Статус порта — Не работает. |
Три таймера:
| Тип таймера | Описание |
|---|---|
| Hello Time | Размер таймера Hello Timer контролирует интервал отправки конфигурационного BPDU. |
| Forward Delay Timer | Длительность таймера задержки пересылки управляет продолжительностью порта в состояниях прослушивания и обучения. |
| Max Age | Размер таймера Max Age управляет временем ожидания для хранения конфигурационных BPDU.По его истечении происходит сбой подключения корневого моста. |
Сообщение STP
Формат сообщения STP:
Рис.: Формат сообщения STP
Пояснения к полям сообщения:
| Содержание поля | Описание |
|---|---|
| Protocol Identifier | ID протокола = «0» |
| Protocol Version Identifier | Идентификатор версии протокола, STP — 0, RSTP — 2, MSTP — 3. |
| BPDU Type | Тип BPDU, MSTP — 0x02. 0x00: Конфигурация STP BPDU 0x80: STP TCN BPDU (BPDU уведомления об изменении топологии) 0x02: RST BPDU (Rapid Spanning-Tree BPDU) или MST BPDU (Multiple Spanning-Tree BPDU) |
| Flags | Для «флагов» первый бит (левый, старший бит) означает «TCA (ответ на изменение топологии)», а последний бит (правый, младший бит) означает «TC (изменение топологии)». |
| Root Identifier | Идентификатор моста составляет 8 байтов: первые два байта — это приоритет моста, а последние 6 байтов — это MAC-адрес моста. |
| Root Path Cost | Стоимость корневого пути, общая стоимость этого порта до корневого моста. |
| Bridge Identifier | Sender BID, BID этого переключателя. |
| Port Identifier | Отправьте PID порта, идентификатор порта, который отправляет BPDU. |
| Message Age | Возраст сообщения этого BPDU. |
| Max Age | Сообщение старения возраста. |
| Hello Time | Интервал времени между отправкой двух соседних пакетов BPDU. |
| Forward Delay | Контролируйте продолжительность состояний прослушивания и обучения. |
Пример захвата пакета STP:
Рис.: Пример захвата пакета STP
Примечания к STP
Принцип STP:
Найдите конец с резервированием и заблокируйте порт, чтобы избежать петель.
Версия STP:
- IEEE 802.1D STP
- IEEE802.1W RSTP
- IEEE802.1S (Huawei) MSTP
Процесс выборов STP:
-
Выбор корневого моста в коммутируемой сети, корневой мост — это понятие оборудования.
-
После выбора корневого моста другие устройства в коммутируемой сети не являются корневыми мостами, и каждый корневой мост должен выбрать порт с кратчайшим путем к корневому мосту в качестве корневого порта.
Примечание. У некорневого моста может быть только один корневой порт.
-
Для каждого канала необходимо выбрать назначенный порт. По умолчанию все порты корневого моста являются назначенными портами.
-
Другие порты, которые не являются ни корневым, ни назначенным портом, должны быть заблокированы и не могут пересылать кадры данных.
Выбор корневого моста:
- При сравнении выборов BID, предпочтительно, чтобы BID был небольшим. BID состоит из приоритета + MAC-адреса.
- Сначала сравните приоритеты, чем меньше приоритет, тем лучше.
- Если приоритет одинаковый, сравните MAC-адреса. Чем меньше MAC-адрес, тем лучше.
Выборы по порту:
- По сравнению с RID желательно небольшого размера.
- Сравните стоимость корневого пути (RPC) с корневым мостом: чем меньше, тем лучше.
- Сравните BID отправителя пакета BPDU, чем меньше, тем лучше.
- Сравните PID отправителя пакета BPDU, чем меньше, тем лучше.
- Сравните PID получателя пакетов BPDU, чем меньше, тем лучше.
Два типа пакетов BPDU:
-
Настроить BPDU
Содержит такие параметры, как идентификатор моста, стоимость пути и идентификатор порта.
-
TCN BPDU
Относится к уведомлению об изменении топологии, отправляемому вышестоящему коммутатору, когда нижележащий коммутатор обнаруживает изменение топологии. Используется для быстрого обновления таблицы MAC-адресов.
Ошибка STP:
-
Сбой корневого моста
Некорневой мост начнет переизбирать корневой мост после того, как BPDU устареет.
-
Ошибка прямой ссылки
После того, как коммутатор обнаружит сбой прямого соединения, он преобразует резервный порт в корневой порт.
Резервный порт вернется в состояние пересылки через 30 секунд.
-
Отказ косвенной ссылки
Для перехода непрямого канала в состояние пересылки требуется 50 секунд (MAX age + Forwarding delay * 2).
-
Изменение топологии вызывает ошибку таблицы MAC-адресов
По умолчанию время устаревания MAC-адреса составляет 300 с, в течение которого данные не могут быть отправлены.
STP используется для пакетов изменения топологии:
-
Сообщение TCN BPDU: уведомление об изменении топологии.
-
Пакеты TCN BPDU могут быть отправлены только некорневыми мостами и уведомлены корневому мосту.
-
Сообщение TCA BPDU: используется для подтверждения полученного сообщения TCN PBDU.
-
Сообщение TC BPDU: оно может быть инициировано только корневым мостом и отправлено непрерывно в течение 35 секунд (MAX age + Forwarding delay).
После получения TC BPDU некорневой мост установит время устаревания MAC-адреса на 15 с, чтобы ускорить устаревание.
Изменения топологии STP:
- Если на некорневом мосте происходит изменение топологии, на корневой мост отправляется пакет TCN BPDU, чтобы уведомить корневой мост об изменении топологии.
- После того, как некорневой мост восходящей линии связи получит пакет TCN BPDU от назначенного порта, он ответит отправителю пакет BPDU конфигурации с установленным флагом TCA и продолжит отправку пакета TCN BPDU на корневой мост.
- После получения пакета TCN BPDU корневой мост отвечает отправителю пакетом BPDU конфигурации с установленным флагом TCA и в то же время отправляет пакет BPDU конфигурации с установленным флагом TC на все назначенные порты. Пакет BPDU конфигурации с установленным TC будет отправляться непрерывно в течение 35 секунд, а его MAC-устаревание будет установлено на 15 секунд одновременно.
- После получения пакета BPDU конфигурации, установленного TC, другие некорневые мосты устанавливают время устаревания своего MAC-адреса на 15 с, чтобы ускорить устаревание.
STP запускает условия изменения топологии:
- Порт переходит из состояния пересылки в состояние отключения или блокировки.
- Если некорневой мост получает пакеты TCN BPDU от назначенного порта, ему необходимо отправить пакеты TCN BPDU на корневой мост.
- Порт переходит в состояние пересылки, а порт finger уже существует локально.
Командная строка конфигурации STP
stp mode { stp | rstp | mstp}
// Настраиваем режим работы коммутатора STP. По умолчанию коммутационное устройство работает в режиме MSTP, который совместим с режимами STP и RSTP.
stp root primary
// Настраиваем текущее устройство как устройство корневого моста. По умолчанию коммутационное устройство не действует как корневой мост какого-либо связующего дерева. После настройки значение BID приоритета устройства автоматически становится равным 0, и приоритет устройства нельзя изменить.
stp root secondary
// Настройте текущее коммутирующее устройство в качестве резервного корневого моста. По умолчанию коммутационное устройство не действует как резервный корневой мост для какого-либо связующего дерева. После настройки значение BID приоритета устройства составляет 4096, и приоритет устройства нельзя изменить.
stp priority 32768
// Настраиваем приоритет коммутирующего устройства в системе. По умолчанию значение приоритета коммутационного устройства составляет 32768. Во время настройки приоритет должен быть кратен 4096.
stp pathcost-standard { dot1d-1998 | dot1t | legacy }
// Настраиваем метод расчета стоимости пути к порту. По умолчанию метод расчета стоимости пути - стандартный метод IEEE 802.1t (dot1t).
[Просмотр интерфейса] стандартная стоимость 100
// Устанавливаем значение стоимости пути для текущего порта.
// Диапазон значений параметра cost от 1 до 200000 при использовании метода расчета Huawei.
// Диапазон значений от 1 до 65535 при использовании стандартного метода IEEE 802.1d.
// Диапазон значений от 1 до 200000000 при использовании стандартного метода IEEE 802.1t.
[Просмотр интерфейса] stp приоритет порта 128
// Настраиваем приоритет порта. По умолчанию значение приоритета порта коммутационного устройства составляет 128.
stp enable // Включаем функцию STP коммутирующего устройства. По умолчанию функция STP / RSTP устройства включена.
stp converge { fast | normal}
// Настраиваем режим конвергенции порта
// В соответствии с различными методами обработки записей ARP, методы сходимости STP / RSTP делятся на быстрые и обычные:
// быстро: таблица ARP напрямую удаляет записи, которые необходимо обновить.
// normal: элементы, которые необходимо быстро обновить в таблице ARP, возрастают.
// Коммутационное устройство устанавливает оставшееся время жизни этих записей в таблице ARP равным 0 и выполняет обработку устаревания этих записей. Если настроенное количество обнаружений устаревания ARP больше нуля, ARP выполнит обнаружение устаревания для этих записей.
// Рекомендуется выбрать метод нормальной сходимости. Если выбран быстрый режим, частое удаление записей ARP может привести к загрузке ЦП устройства до 100%, а таймауты обработки пакетов могут вызвать нестабильность сети.
stp bridge-diameter 5
// Настраиваем диаметр сети. По умолчанию диаметр сети равен 7.
stp timer-factor factor
// Настраиваем период ожидания для перезапуска вычисления связующего дерева без получения восходящих BPDU. По умолчанию период ожидания для перезапуска вычисления связующего дерева без получения восходящих BPDU в 9 раз превышает значение таймера Hello.
stp timer forward-delay 1500
// Настраиваем время задержки пересылки для устройства. По умолчанию время задержки пересылки устройства составляет 1500 сантисекунд (15 секунд).
stp timer hello 200
// Настраиваем время приветствия устройства. По умолчанию время приветствия устройства составляет 200 сантисекунд (2 секунды).
stp timer mac-age 2000
// Настраиваем максимальное время возраста устройства. По умолчанию максимальный возраст устройства составляет 2000 сантисекунд (20 секунд).
max bandwidth-affected-linknumber 8
// Настраиваем максимальное количество подключений, влияющих на пропускную способность. По умолчанию максимальное количество подключений, влияющих на пропускную способность агрегации каналов, равно 8.
reset stp error packet statistics
// Очистить счетчик сообщений об ошибках протокола связующего дерева.
display stp toplogy-change
// Просмотр статистики, связанной с изменениями топологии STP / RSTPПримеры конфигурации STP
Как показано на рисунке ниже, вам необходимо настроить SW1 как корневой мост, а SW2 как резервный корневой мост. При настройке STP в трехдневном коммутаторе определенный порт блокируется, чтобы предотвратить выход сети из цикла.
Рис.: Топология конфигурации STP
Файл конфигурации SW1:
[SW1]dis current-configuration
#
sysname SW1
#
stp mode stp
stp instance 0 root primary
#Файл конфигурации SW2:
[SW2]dis current-configuration
#
sysname SW2
#
stp mode stp
stp instance 0 root secondary
#Проверьте статус STP порта GI0 / 0/2 SW3:
Изображение: статус STP gi0 / 0/2 SW3
В том числе практических занятий и лабораторных работ
64
1
Развертывание коммутируемой сети с резервными каналами
2
2
Настройка Rapid PVST+, PortFast и BPDU Guard
2
3
Настройка протокола GLBP
2
4
Определение типовых ошибок конфигурации STP
2
5
Настройка EtherChannel
2
6
Поиск и устранение неполадок в работе EtherChannel
2
7
Агрегирование каналов
2
8
Настройка беспроводного маршрутизатора и клиента
2
9
Настройка базового протокола OSPFv2 для одной области
2
10
Настройка OSPFv2 в сети множественного доступа
2
11
Настройка расширенных функций OSPFv2
2
12
Поиск и устранение неполадок в работе основных протоколов OSPFv2 и OSPFv3 для одной области
2
13
Поиск и устранение неполадок в работе усовершенствованного протокола OSPFv2 для одной области
2
14
Владение навыками поиска и устранения неполадок в работе OSPF
2
15
Настройка OSPFv2 для нескольких областей
2
16
Настройка OSPFv3 для нескольких областей
2
17
Поиск и устранение неполадок в работе OSPFv2 и OSPFv3 для нескольких областей
Тема 2.2. Соединение сетей.
Содержание
144
1
Подключение к глобальной сети
Обзор технологий глобальной сети. Цель создания глобальных сетей. Принцип работы глобальной сети. Выбор технологии глобальной сети. Сервисы глобальной сети. Инфраструктуры частных глобальных сетей. Инфраструктура общедоступной глобальной сети. Выбор сервисов глобальной сети.
2
Соединение «точка-точка»
Обзор последовательного соединения «точка-точка». Связь по последовательному каналу. Инкапсуляция HDLC. Принцип работы протокола PPP. Преимущества протокола PPP. LCP и NCP. Сеансы PPP. Настройка протокола PPP. Настройка протокола PPP. Аутентификация PPP. Отладка соединений WAN. Отладка PPP.
3
Решения широкополосного доступа
Удалённая работа. Преимущества удалённой работы. Бизнес-требования для удалённых работников. Сравнение решений широкополосного доступа. Кабель. DSL. Беспроводные широкополосные сети. Выбор решений широкополосного доступа. Настройка подключений xDSL. Обзор PPPoE. Настройка PPPoE.
4
Защита межфилиальной связи
Сети VPN. Основы сетей VPN. Типы сетей VPN. Туннели GRE между объектами. Основы GRE. Настройка туннелей GRE. Общие сведения об IPsec. Защита протокола IP. Структура протокола IPsec. Удалённый доступ. Решения VPN для удалённого доступа. Сети VPN удалённого доступа с использованием IPsec.
5
Мониторинг Сети
Syslog. Принцип работы Syslog. Настройка Syslog. SNMP. Принцип работы SNMP. Настройка SNMP. NetFlow. Принцип работы NetFlow. Настройка NetFlow. Проверка моделей трафика.
6
Отладка сети
Поиск и устранение неполадок с использованием системного подхода. Документация по сети. Процедура поиска и устранения неполадок. Изоляция проблемы с помощью многоуровневых моделей. Отладка сети. Средства поиска и устранения неполадок. Симптомы и причины отладки сети. Поиск и устранение неполадок связи в сетях IP.
Одной из тем, которые встретится на экзамене CCNA будет «Диагностика и устранение неполадок в работе коммутаторов 2-го уровня». Для того, чтобы не запутаться на экзамене нужно запомнить одно простое правило, и пользоваться простым планом действий. Основное правило при диагностике и устранении неполадок — это «Не трогай технику, и она тебя не подведет». Т.е. «Зачем лез, если оно само работало?»… Не совсем так, конечно. Это основное правило системного администрирования в целом. Почему-то вспомнилось…
Основное правило — «Не делать предположение о том, что находится в рабочем состоянии, а что нет, предварительно этого не проверив». Т.е. нельзя предполагать, что порт коммутатора активен, и находится в рабочем состоянии, не проверив этого. Все остальное — по плану.
1. Диагностика физического уровня и порта коммутатора
· Кабель: тип, категория, длинна
· Состояние порта
· Согласованность портов ( full-duplex / half-duplex )
· Принадлежность порта корректному VTP VLAN
2. Диагностика и устранение неполадок VLAN и VTP-trunk-ов
· Согласованность номера native VLAN на всех узлах VTP домена.
· Согласованность режимов локального и удаленного VTP trunk-ов ( Dynamic Auto / Dynamic Desirable)
· Принадлежность каждого VLAN уникальной IP сети
· Параметры конфигурации для Inter-VLAN маршрутизации
3. Диагностика и устранение неполадок VTP
· Наличие необходимых параметров конфигурации VLAN в running-config
· Согласованность параметров VTP на всех коммутаторах
· Появление проблем после добавления нового коммутатора
· Отключение порта(ов) после включения питания коммутатора
4. Диагностика и устранение неполадок STP
· Root-бридж по схеме сети
· Петли коммутации
· Лог изменения конфигурации STP
· Процесс выбора root-бриджа
· RSTP режим
1. Диагностика физического уровня и порта коммутатора
Первое что нужно сделать для выяснения возможных причин сбоев или полной неработоспособности сети — это проверить кабель. Не думаю, что в рамках экзаменационных вопросов встретится что-то кроме вопросов о правильности выбора типа используемого кабеля для различного оборудования. Речь идет о crossover ( перекрестный обжим ) straightthrough ( прямой обжим ) кабелях. Применения типа обжима в документации Cisco предлагается запомнить по простому принципу:
· прямой ( straightthrough ) применяется для подключения оборудования разного типа;
· перекрестный ( crossover ) — для подключения оборудования одного типа.
Разделить оборудование на типы можно по его положению относительно Ethernet сегмента — маршрутизаторы, клиентские станции и сервера являются конечными системами в сегменте сети Ethernet, в то время как повторители, хабы и свитчи являются основой его инфраструктуры. Из этого простого разделения и нужно исходить при выборе типа кабеля.
Далее необходимо проверить состояние портов на обеих сторонах неисправного соединения. Основная задач выяснить нет ли портов “disable” или “errDisable” ( в зависимости от причины вызвавшей отключение порта ).
Проверить состояние порта можно по выводу команды show для соответствующего интерфейса / порта
SwitchX# sh int fa0/2
FastEthernet0/2 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 0017.596d.2a02 (bia 0017.596d.2a02)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
——————————-пропущено—————————————-
На следующем этапе необходимо проверить согласованность режимов портов. В документации Cisco рекомендуется отключать автоопределение портов, и устанавливать «вручную» необходимый режим. Такая практика позволяет избежать возможных ошибок автоматического определения режима работы порта коммутатора. В тоже время, она же может привести к ошибке конфигурирования. Выяснить согласованность режимов работы портов можно из вывода команды show interface для портов на обеих сторонах неработающего канала.
Switch#show interfaces f0/2
FastEthernet0/2 is up, line protocol is up (connected)
Hardware is Lance, address is 000c.856c.0a01 (bia 000c.856c.0a01)
BW 100000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s
——————————-пропущено—————————————-
В случае, если порт находится в режиме access, и ему назначен номер несуществующего / или случайно удаленного VLAN, вывод команды show interface будет бесполезен для выяснения причины неработоспособности порта. В таком случае необходимую информацию может предоставить show interface interface switchport
SwitchX# show interfaces fa0/2 switchport
Name: Fa0/2
Switchport: Enabled
Administrative Mode: static access
Operational Mode: static access
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: native
Negotiation of Trunking: Off
Access Mode VLAN: 5 (Inactive)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Voice VLAN: None
——————————-пропущено—————————————-
На некоторых коммутаторах Cisco на таких портах индикатор светится немигающим оранжевым.
2. Диагностика и устранение неполадок VLAN и VTP-trunk-ов
Для нормального функционирования IEEE 802.1Q trunk-ов они должны быть сконфигурированы с одинаковым значением параметра native VLAN. Для того чтобы проверить это необходимо просмотреть вывод команды show interfaces interface switchport или show intrface trunk на коммутаторах, находящихся на обеих сторонах неработающего соединения.
SwitchX#show interface f0/1 switchport
Name: Fa0/1
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
——————————-пропущено—————————————-
SwitchX#show interface trunk
Port Mode Encapsulation Status Native vlan
Fa0/1 on 802.1q trunking 1
——————————-пропущено—————————————-
Не знаю, какова вероятность именно такой неисправности в экзаменационной лабораторной работе или вопросе, так как при нормальных обстоятельствах коммутаторы должны “жаловаться” прямо в консоль о том, что значение native VLAN не согласовано.
Native VLAN mismatch discovered on FastEthernet0/1 (1), with Switch FastEthernet0/1 (99)
Для того чтобы установить одинаковое значение native VLAN на обоих коммутаторах, необходимо в режиме Interface Configuration Mode выполнить команду
SwitchX(config-if)#switchport trunk native vlan VLAN number
Кроме этого, к неисправности в работе trunk-ов может привести несогласованность параметра Administrative Mode. Это обусловлено тем, что в некоторых случаях возможен перевод порта в режим trunk автоматически, используя протокол DTP. Всю необходимую информацию можно узнать из вывода команды show interfaces interface switchport.
SwitchX#show interface f0/1 switchport
Name: Fa0/1
Switchport: Enabled
Administrative Mode: dynamic desirable
Operational Mode: trunk
——————————-пропущено—————————————-
SwitchY#show interface f0/1 switchport
Name: Fa0/1
Switchport: Enabled
Administrative Mode: dynamic auto
Operational Mode: trunk
——————————-пропущено—————————————-
Различия между Dynamic Auto и Dynamic Desirable заключается в том, что в первом случае будет создано trunk — соединение в ответ на DTP – запрос, а во втором случае будет инициироваться попытка создания trunk – соединение и посылаться DTP – запрос. Если оба порта будут настроены Dynamic Auto, trunk — соединение не будет создано.
Чтобы установить желаемое значение параметра Administrative Mode, необходимо в режиме Interface Configuration Mode выполнить команду
SwitchX(config-if)#switchport mode MODE
Несмотря на то, что технологии, реализованные Cisco Systems, позволяют оборудованию в некоторых случаях производить автоконфигурирование, в официальной документации все параметры рекомендуется устанавливать самостоятельно. В данном случае, параметр Administrative Mode не является исключением, и ему должно быть присвоено значение trunk для портов, которые должны создавать trunk-соединение.
Для нормального взаимодействия между узлами в пределах одного VLAN необходимо чтобы эти узлы находились в одной IP-сети. И на оборот, если узлы разнесены в различные VLAN – в различных IP-сетях. В случае, если эти простые условия не будут соблюдены, бесполезно ожидать сетевого взаимодействия между этими двумя узлами. Для того, чтобы это проверить нет необходимости выполнения каких либо команд на коммутаторах, достаточно просто сопоставить значения VLAN и присвоенных узлам IP-адресов, полученных из вывода команды ipconfig.
В случае возникновения неисправностей interVLAN взаимодействия, возможной причиной может быть неправильная конфигурация оборудования, вовлеченного в него. Это в первую очередь касается конечных узлов, на которых может быть неправильно сконфигурирован шлюз по умолчанию. Проверить правильность настроек интерфейса на конечно станции можно командой ipconfig
Следующей причиной подобных проблем может являться неправильная конфигурация роутера, обеспечивающего interVLAN – маршрутизацию. Для выяснения возможных неисправностей необходимо четко представлять нормальных алгоритм работы InterVLAN — маршрутизации. Основной причиной возникновения неисправностей interVLAN взаимодействия может являть неправильная конфигурация одного или нескольких дополнительных интерфейсов на маршрутиазторе. Это может быть, как неправильно настроенные параметры инкапсуляции IEEE 802.1Q, так и неправильное присвоение адреса. Для того, чтобы получить необходимую информацию можно просмотреть текущую конфигурацию маршрутизатора командой
show running-config
——————————-пропущено—————————————-
!
interface FastEthernet0/0.20
encapsulation dot1Q 20
ip address 192.168.20.1 255.255.255.0
!
interface FastEthernet0/0.30
encapsulation dot1Q 30
ip address 192.168.30.1 255.255.255.0
!
interface FastEthernet0/0.40
encapsulation dot1Q 40
ip address 192.168.40.1 255.255.255.0
!
——————————-пропущено—————————————-
или просмотрев вывод команды
show interface sub-if name
Router#show interfaces FastEthernet 0/0.20
FastEthernet0/0.20 is up, line protocol is up (connected)
Hardware is PQUICC_FEC, address is 0030.f2e1.c301 (bia 0030.f2e1.c301)
Internet address is 192.168.20.1/24
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation 802.1Q Virtual LAN, Vlan ID 20
ARP type: ARPA, ARP Timeout 04:00:00,
Last clearing of «show interface» counters never
Номер дополнительного интерфейса не обязательно должен соответствовать номеру VLAN ( такое соответствие упрощает понимание конфигурации и дальнейшее администрирование ), в то время как параметр Vlan ID – обязательно должен соответствовать номеру VLAN. Кроме того, адрес, присвоенный дополнительному интерфейсу, должен быть согласован с планом адресации в пределах обслуживаемого VLAN, а также быть эквивалентным адресу основного шлюза для этого VLAN.
3. Диагностика и устранение неполадок VTP
Интересным явлением, с точки зрения возможности появления в экзаменационном вопросе со статусом неисправности, является различие в способе сохранения информации протокола VTP и базы данных VLAN на коммутаторах с различными режимами протокола VTP. Такая нелогичность не может быть пропущена авторами экзамена.
Коммутаторы в VTP — режиме Server и Client хранят всю информацию протокола VTP ( включая базу VLAN ) в файле vlan.dat. В то время, как коммутаторы в режиме Transparent — в файле конфигурации. Это различие может быть причиной неожиданных последствий выполнения команд
write erase
delete flash:vlan.dat
Более комплексной проблемой является отсутствие обмена данными между коммутаторами в пределах одного VTP домена. Для этого существует достаточно большое количество объективных причин..
Так как информация распространяется только через trunk-и, необходимо проверить являются ли порты, соединяющие коммутаторы, trunk-ами. Сделать это можно командой show interface trunk
SwitchX#show interface trunk
Port Mode Encapsulation Status Native vlan
Fa0/1 on 802.1q trunking 1
Fa0/2 on 802.1q trunking 1
Fa0/3 on 802.1q trunking 1
——————————-пропущено—————————————-
Далее необходимо проверить параметры VTP домена domain и password. Оба параметра являются чувствительными к регистру. Если допустить ошибку в имени VTP домена или пароле, то обмен информацией не будет происходить. Получить информацию о имени домена можно при помощи команды show vtp status
SwitchX#show vtp status
VTP Version : 2
Configuration Revision : 0
Maximum VLANs supported locally : 255
Number of existing VLANs : 5
VTP Operating Mode : Server
VTP Domain Name : Cisco
——————————-пропущено—————————————-
Для того, чтобы исключить возможное различие между настройками пароля на коммутаторах, вовлеченных в проблему, необходимо временно сбросить VTP пароль. Для этого необходимо в Global Configuration Mode выполнить команду no vtp password.
Версии протокола VTP не являются совместимыми. Если в VTP – домене есть коммутаторы, не поддерживающие VTP V2, то его (VTP V2) нельзя использовать. В случае если все коммутаторы поддерживают VTP V2, достаточно активировать эту версию протокола на коммутаторе, который является сервером для данного VTP домена, и все остальные коммутаторы автоматически перейдут на эту версию. По умолчанию используется VTP V1.
Коммутаторы, использующие версию протокола VTP V1 и находящиеся в режиме Transparent, распространяют информацию только по VTP домену, к которому они принадлежат. Обновления, имеющие отношение к другим VTP доменам уничтожаются. В случае, если подобный коммутатор использует версию протокола VTP V2, то обновления имеющие отношение к другим VTP доменам передаются. Посмотреть какая версия протокола VTP используется можно при помощи команды show vtp status.
SwitchX#show vtp status
VTP Version :2
Configuration Revision : 0
Maximum VLANs supported locally : 255
Number of existing VLANs : 5
VTP Operating Mode : Server
VTP Domain Name : Cisco
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
——————————-пропущено—————————————-
Параметр VTP Version указывает на возможность использования VTP V2. Значение Disabled для параметра VTP V2 Mode указывает на то, что коммутатор использует VTP V1
Номера VLAN из дополнительного диапазона (от 1025 до 4094 ) не распространяются автоматически. VLAN-ы с номерами из этого диапазона, должны настраиваться на каждом коммутаторе отдельно.
Обновления не вносят изменения в конфигурацию клиент в том случае, если Configuration Revision у клиента выше, чем в пришедшем от сервера обновлении. Посмотреть значение Configuration Revision можно в выводе команды show vtp status.
SwitchX#show vtp status
VTP Version : 2
Configuration Revision : 0
Maximum VLANs supported locally : 255
Number of existing VLANs : 5
VTP Operating Mode : Server
VTP Domain Name : Cisco
——————————-пропущено—————————————-
Так как на коммутаторах Cisco по умолчанию значение VTP Operating Mode установлено Server, и при некоторых обстоятельствах Configuration Revision может быть выше чем у коммутатора используемого в качестве сервера для VTP домена, то в такой ситуации вновь добавленный коммутатор может изменить существующую базу VLAN. В случае, если его база VLAN будет пустой, то все VLAN будут удалены. Следствием этого может быть ситуация, когда абсолютно все порты на коммутаторах, после включения питания, не активны ( как было описано в п. 1 ), так как принадлежат не существующим VLAN. Для того, чтобы избежать подобной ситуации необходимо на вновь добавляемом коммутаторе обнулить значение Configuration Revision переведя его сначала в режим Transparent, а потом в режим Server. Или сначала изменив значение VTP Domain Name на любое другой, а потом вернув нужное значение. В обоих случаях значение параметра Configuration Revision обнулится.
4. Диагностика и устранение неполадок STP
Диагностика и устранение неполадок протокола STP возможна только в случае нормального документирования топологии сети. Это подразумевает наличие информации о том, какой коммутатор является Root, какие каналы являются резервными и какие порты находятся в заблокированном состоянии. Только в этом случае возможна дальнейшая диагностика. Это необходимо для того, чтобы прежде чем искать что починить, иметь представление о том, как это все работало до того
Чтобы выявить несоответствия реального положения дел в сети и документации, достаточно использовать команду show spanning-tree. Из вывода данной команды можно определить какой коммутатор является в данный момент Root, в также текущее состояние портов относительно STP топологии.
Для быстрого восстановления работоспособности сети, разъединить петли коммутации. Для этого нужно отключить те порты коммутаторов, которые их образуют. И в этом случае документация STP топологии будет незаменима. Так основанием для принятия решения какие порты блокировать будет информация о том, какие порты были заблокированы.
Определить Root-бридж согласно документации. Для того, чтобы не предоставлять возможность STP принимать решении о назначение корневого коммутатора для STP топологии, необходимо в Global Configuration Mode, для каждого из настроенных на коммутаторе VLAN, выполнить команду
SwitchX (config)#spanning-tree vlan VLAN ID root primary.
В таком случае коммутатор автоматически выставит приоритет ниже, чем у существующего корневого коммутатора STP.
Время конвергенции ( схождения ) сети при использовании 802.1d и PVST+ составляет 30 -50 секунд. В случае использования RSTP и PVRST+ — не более 2-х секунд. При таком соотношении, использование режима pvst неприемлемо. В случае если схождение сети происходит медленней, чем ожидается, возможно, не все коммутаторы настроены на использование PVRST+. Какой режим используется в данный момент можно выяснить из первой строки вывода команды show spanning-tree summary.
SwitchX#show spanning-tree summary
Switch is in pvst mode
——————————-пропущено—————————————-
Для того чтобы установить необходимый режим STP необходимо в Global Configuration Mode выполнить команду
SwitchX (config)#spanning-tree mode rapid-pvst
Данная тема (Диагностика и устранение неполадок в работе) является одной из самых сложных в рамках курса CCNA. Ее нельзя просто взять и выучить. Поэтому необходимо уделить особое внимание пунктам 3 и 4, и проверить на топологии, которая использовалась в Лабораторная работа №18 Per-VLAN Spanning Tree Protocol Plus ( PVST+ ).
Cisco CCNP: Troubleshooting Spanning-Tree Protocol
In preparation of your CCNP exam, we want to make sure we cover the various concepts that we could see on your Cisco CCNP exam. So to assist you, below we will discuss on of the more difficult CCNP concepts; Troubleshooting Spanning-Tree Protocol and Related Design Considerations. As you progress through your CCNP exam studies, I am sure with repetition you will find this topic becomes easier. So even though it may be a difficult concept and confusing at first, keep at it as no one said getting your Cisco certification would be easy!
Introduction
This document presents a list of recommendations that help to implement a safe network with regard to bridging for Cisco Catalyst switches that run Catalyst OS (CatOS) and Cisco IOS® Software. This document discusses some of the common reasons that Spanning Tree Protocol (STP) can fail and the information for which to look to identify the source of the problem. The document also shows the kind of design that minimizes spanning tree-related issues and is easy to troubleshoot.
Prerequisites
Requirements
There are no specific requirements for this document.
Components Used
This document is not restricted to specific software and hardware versions.
Conventions
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Background Information
This document does not discuss the basic operation of STP. To learn how STP works, refer to this document:
- Understanding and Configuring Spanning Tree Protocol (STP) on Catalyst Switches
This document does not discuss Rapid STP (RSTP), defined in IEEE 802.1w. Also, this document does not discuss Multiple Spanning Tree (MST) protocol, defined in IEEE 802.1s. For more information on RSTP and MST, refer to these documents:
- Understanding Multiple Spanning Tree Protocol (802.1s)
- Understanding Rapid Spanning Tree Protocol (802.1w)
For a more specific STP troubleshooting document for Catalyst switches that run Cisco IOS Software, refer to the document Troubleshooting STP on Catalyst Switch Running Cisco Integrated IOS (Native Mode).
Spanning Tree Protocol Failure
The primary function of the spanning-tree algorithm (STA) is to cut loops that redundant links create in bridge networks. The STP operates at Layer 2 of the Open System Interconnection (OSI) model. By means of bridge protocol data units (BPDUs) that exchange between bridges, the STP elects the ports that eventually forward or block traffic. This protocol can fail in some specific cases, and troubleshooting the resulting situation can be very difficult, which depends on the design of the network. In this particular area, you perform the most important part of the troubleshooting before the problem occurs.
A failure in the STA generally leads to a bridging loop. Most customers that call Cisco Technical Support for spanning tree problems suspect a bug, but a bug is seldom the cause. Even if the software is the problem, a bridging loop in an STP environment still comes from a port that should block, but instead forwards traffic.
Spanning Tree Convergence
Refer to the Spanning Tree Flash animation to see an example that explains how the Spanning Tree initially converges. The example also explains why a blocked port goes into the forwarding mode because of an excessive loss of BPDUs, resulting in STA failure.
The rest of this document lists the different situations that can cause the STA to fail. Most of these failures relate to a massive loss of BPDUs. The loss causes blocked ports to transition to forwarding mode.
Duplex Mismatch
Duplex mismatch on a point-to-point link is a very common configuration error. If you manually set the duplex mode to Full on one side of the link and leave the other side in autonegotiation mode, the link ends up in half-duplex. (A port with duplex mode set to Full no longer negotiates.)
The worst-case scenario is when a bridge that sends BPDUs has the duplex mode set to half-duplex on a port, but the peer port on other end of link has the duplex mode set to full-duplex. In the above example, the duplex mismatch on the link between bridge A and B can easily lead to a bridging loop. Because bridge B has configuration for full-duplex, it does not perform carrier sense before link access. Bridge B starts to send frames even if bridge A is already using the link. This situation is a problem for A; bridge A detects a collision and runs the backoff algorithm before the bridge attempts another transmission of the frame. If there is enough traffic from B to A, every packet that A sends, which includes the BPDUs, undergoes deferment or collision and eventually gets dropped. From an STP point of view, because bridge B does not receive BPDUs from A any more, bridge B has lost the root bridge. This leads B to unblock the port connected to bridge C, which creates the loop.
Whenever there is a duplex mismatch, these error messages are on the switch consoles of Catalyst switches that run CatOS and Cisco IOS Software:
CatOS
CDP-4-DUPLEXMISMATCH: Full/half duplex mismatch detected on port
Page load link
Подборка по базе: Проверочный тест по микроэкономике, гр. ВэМПб-Э05-22-1 и гр. ВэМ, !Таблица 2 Правила назначения наказания.docx, Образец выполнения задания 1.docx, Бланк выполнения задания 1 (2).docx, Файл для выполнения задания. Таблица признаков вовлеченности пре, новые правила.docx, Образец выполнения практического задания 3.docx, Образец выполнения практического задания 1.docx, Образец выполнения практического задания 5.docx, 2 Полетаев основы и правила стрельбы.doc
По умолчанию HSRP НЕ выполняет распределение нагрузки. Активный маршрутизатор всегда обрабатывает весь трафик, а резервный задействуется только в случае сбоя канала. Подобное использование ресурсов не является эффективным. GLBP обеспечивает непрерывную избыточность пути для IP за счёт использования общих для всех шлюзов IP-адреса и MAC-адреса. GLBP также позволяет группе маршрутизаторов использовать распределение нагрузки шлюзов по умолчанию в сети LAN. Настройка GLBP выполняется аналогично настройке HSRP. Существует несколько способов распределения нагрузки с помощью GLBP. В рамках данной лабораторной работы вы будете использовать метод циклического обслуживания.
Шаг 1: Настройте GLBP на R1 и R3.
- Настройте протокол GLBP на маршрутизаторе R1.
R1(config)# interface g0/1
R1(config-if)# glbp 1 ip 192.168.1.254
R1(config-if)# glbp 1 preempt
R1(config-if)# glbp 1 priority 150
R1(config-if)# glbp 1 load-balancing round-robin
- Настройте протокол GLBP на маршрутизаторе R3.
R3(config)# interface g0/1
R3(config-if)# glbp 1 ip 192.168.1.254
R3(config-if)# glbp 1 load-balancing round-robin
Шаг 2: Проверьте настройки GLBP на маршрутизаторах R1 и R3.
a. На коммутаторах R1 и R3 выполните команду show glbp brief.
R1# show glbp brief
Interface Grp Fwd Pri State Address Active router Standby router
Gi0/1 1 — 150 Active 192.168.1.254 local 192.168.1.3
Gi0/1 1 1 — Active 0007.b400.0101 local — Gi0/1 1 2 — Listen 0007.b400.0102 192.168.1.3 —
R3# show glbp brief
Interface Grp Fwd Pri State Address Active router Standby router
Gi0/1 1 — 100 Standby 192.168.1.254 192.168.1.1 local
Gi0/1 1 1 — Listen 0007.b400.0101 192.168.1.1 —
Gi0/1 1 2 — Active 0007.b400.0102 local —
Шаг 3: Сформируйте поток трафика от PC-A и PC-C на интерфейс loopback R2.
- Из командной строки на PC-A отправьте эхо-запрос на адрес 209.165.200.225 R2.
C:> ping 209.165.200.225
- Выполните команду arp –a на PC-A. Какой MAC-адрес используется для адреса 192.168.1.254?
________________________________________________
c. Сгенерируйте еще больше трафика на loopback-интерфейс маршрутизатора R2. Выполните еще раз команду arp –a. Изменился ли MAC-адрес шлюза по умолчанию 192.168.1.254?
________________________________________________
Как вы видите, R1 и R3 принимают участие в пересылке трафика на интерфейс loopback маршрутизатора R2. Ни один из маршрутизаторов не остается незадействованным.
Шаг 4: Запустите сеанс эхо-тестирования на PC-A и разорвите соединение с коммутатором, подключенным к R1.
- В командной строке на PC-A введите команду ping –t для адреса 209.165.200.225 на маршрутизаторе R2. Убедитесь, что окно командной строки открыто.
- Во время отправки эхо-запроса отсоедините кабель Ethernet от интерфейса F0/5 на коммутаторе S1 или выключите интерфейс F0/5.
Что произошло с трафиком эхо-запросов?
____________________________________________________________________________________
Вопросы на закрепление
1. Для чего в локальной сети может потребоваться избыточность?
_______________________________________________________________________
2. Если бы у вас был выбор, какой протокол вы бы реализовали в своей сети: HSRP или GLBP? Поясните свой выбор.
_____________________________________________________________________________________
Сводная таблица интерфейсов маршрутизаторов
| Сводная информация об интерфейсах маршрутизаторов | ||||
| Модель маршрутизатора | Интерфейс
Ethernet № 1 |
Интерфейс
Ethernet № 2 |
Последовательный интерфейс № 1 | Последовательный интерфейс № 2 |
| 1800 | Fast Ethernet 0/0 (F0/0) | Fast Ethernet 0/1 (F0/1) | Serial 0/0/0 (S0/0/0) | Serial 0/0/1 (S0/0/1) |
| 1900 | Gigabit Ethernet 0/0 (G0/0) | Gigabit Ethernet 0/1 (G0/1) | Serial 0/0/0 (S0/0/0) | Serial 0/0/1 (S0/0/1) |
| 2801 | Fast Ethernet 0/0 (F0/0) | Fast Ethernet 0/1 (F0/1) | Serial 0/1/0 (S0/1/0) | Serial 0/1/1 (S0/1/1) |
| 2811 | Fast Ethernet 0/0 (F0/0) | Fast Ethernet 0/1 (F0/1) | Serial 0/0/0 (S0/0/0) | Serial 0/0/1 (S0/0/1) |
| 2900 | Gigabit Ethernet 0/0 (G0/0) | Gigabit Ethernet 0/1 (G0/1) | Serial 0/0/0 (S0/0/0) | Serial 0/0/1 (S0/0/1) |
| Примечание. Чтобы узнать, каким образом настроен маршрутизатор, изучите интерфейсы с целью определения типа маршрутизатора и количества его интерфейсов. Эффективного способа перечисления всех комбинаций настроек для каждого класса маршрутизаторов не существует. В этой таблице содержатся идентификаторы для возможных сочетаний интерфейсов Ethernet и последовательных интерфейсов в устройстве. В таблицу не включены никакие иные типы интерфейсов, даже если они присутствуют на конкретном маршрутизаторе. В качестве примера можно привести интерфейс ISDN BRI. Строка в скобках — это принятое сокращение, которое можно использовать в командах Cisco IOS для представления интерфейса. |
Лабораторная работа №5 Определение типовых ошибок конфигурации STP
Лабораторная работа №6 Устранение типовых ошибок конфигурации STP
Цели работы: Определить типовые ошибки при конфигурации STP
Продолжительность: 4 часа
ASR типичные проблемы серии 9000 с протоколами STP
Параметры загрузки
Об этом переводе
Этот документ был переведен Cisco с помощью машинного перевода, при ограниченном участии переводчика, чтобы сделать материалы и ресурсы поддержки доступными пользователям на их родном языке. Обратите внимание: даже лучший машинный перевод не может быть настолько точным и правильным, как перевод, выполненный профессиональным переводчиком. Компания Cisco Systems, Inc. не несет ответственности за точность этих переводов и рекомендует обращаться к английской версии документа (ссылка предоставлена) для уточнения.
Содержание
Введение
Этот документ описывает типичные проблемы, которые возникают при интеграции текущих пользовательских сетей со связующим деревом уровня 2 (L2) на коммутаторах Cisco IOS® с маршрутизаторами с агрегацией сервисов (ASR) серии Cisco 9000, которые работают под управлением Cisco IOS XR.
Проблема — несоответствие идентификаторов VLAN портов (PVID)
Коммутаторы Cisco IOS, которые работают на протоколе Per VLAN Spanning Tree Plus (PVST+), блокируют порты коммутатора, когда они принимают a блок данных протокола моста (BPDU) с несовместимым PVID. Эта проблема возникает, когда для устройства между коммутаторами меняются или транслируются метки IEEE 802.1Q на PVST + BPDU.
Если ASR 9000 предоставляет двухточечную или многоточечную услугу L2VPN между коммутаторами, которая использует PVST+ и перезаписывает метки VLAN, эти сообщения в системном журнале могут отображаться на коммутаторах на базе Cisco IOS:
Эта проблема возникает из-за метки PVID, которая включается с PVST + BPDU. Эта метка предназначена для обнаружения неверных конфигураций и предотвращения случайных петель. Вместе с тем в данном сценарии это приводит к блокировке всех концов и не позволяет проводить трафик.
Здесь представлена конфигурация ASR серии 9000 (a9k1):
Решение
Для предотвращения этой проблемы можно заблокировать PVST + BPDU. Если между коммутаторами есть доступные резервированные соединения, это действие отключает связующее дерево и может привести к образованию петель.
Внимание. : Будьте осторожны, когда блокируете BPDU, и отключите связующее дерево.
Фильтр BPDU на коммутаторах
BPDU заблокированы с функцией фильтра BPDU на коммутаторах. Фильтр BPDU блокирует BPDU в обоих направлениях, что приводит к отключению связующего дерева на порту. Фильтр BPDU предотвращает входящий и исходящий BPDU. При включении фильтрации BPDU на интерфейсе создается такая же ситуация, как и при отключении связующего дерева на нем, что может привести к образованию петель в связующем дереве.
На коммутаторах 1 и 2 включите фильтры BPDU с помощью команды:
Блочный PVST + BPDU на ASR 9000
Эта проблема не возникает, если настроить ASR9000 на отбрасывание PVST + BPDU. Это делается с использованием списка доступа к сервисам Ethernet уровня L2 с целью запрета пакетов, которые предназначены для отправки на MAC-адрес PVST+ BPDU.
PVST + BPDU для сети (не VLAN) 1 (несобственной) VLAN передаются на PVST + MAC-адрес (также называемый MAC-адресом протокола общего связующего дерева [SSTP], 0100.0ccc.cccd) и маркируются соответствующей меткой VLAN IEEE 802.1Q.
Этот список контроля доступа (ACL) может использоваться для блокирования PVST + BPDU:
Примените ACL к интерфейсу, настроенному как l2transport:
Проблема — порты коммутатора спонтанно переключаются между блокированием и пересылкой при использовании нескольких разновидностей протокола связующего дерева (STP) через ASR 9000
ASR9000 не создает связующего дерева по умолчанию, как и большинство коммутаторов Cisco IOS. В модели виртуального канала Ethernet (EVC) пакет BPDU является просто еще одним многоадресным пакетом L2. Типичной проблемой является несоответствие связующего дерева из-за нескольких разновидностей STP, которые работают на домене моста ASR 9000. Это проявляется несколькими различными способами.
Рассмотрим такую простую топологию:
Предположите, что коммутатор 1 использует множественное связующее дерево (MST), а коммутатор 2 использует PVST+. Если a9k1 не использует ни одной разновидности связующего дерева, коммутатор 1 считает его граничным портом. Коммутатор 1 возвращается к режиму PVST для сетей VLAN, которых нет в общем экземпляре связующего дерева 0 (CST0). Если это и есть необходимая модель, необходимо ознакомиться со взаимодействием MST и PVST, описанным в документе Описание множественного протокола связующего дерева (802.1s).
Теперь предположим, что используется MST на коммутаторе 1 и на интерфейсе a9k1, который приводит к коммутатору 1, но при этом используется PVST + на коммутаторе 2. PVST + BPDU проходят через домен моста и доходят до коммутатора 1. Затем коммутатор 1 распознает как пакеты BPDU MST от a9k1, так и PVST + BPDU от коммутатора 2, и это приводит к тому, что связующее дерево на порту коммутатора 1 постоянно переключается с блокирования на неблокирование, что, в свою очередь, приводит к потере трафика.
Коммутатор 1 предоставляет системные журналы:
Результат выполнения команды show spanning-tree interface показывает, что этот результат постоянно меняются на устройстве Cisco IOS коммутатора 1:
Решение
Есть три опции, которые можно использовать для предотвращения этой проблемы.
Проблема — порты связующего дерева заблокированы вследствие обнаружения петли
Когда коммутатор получает пакет BPDU связующего дерева, который отправляется на том же интерфейсе, коммутатор блокирует эту VLAN вследствие образования петли. Это типичная проблема, возникающая тогда, когда коммутатор с магистральным портом подключен к маршрутизатору ASR 9000, который предоставляет многоточечные сервисы L2, а ASR 9000 не перезаписывает метки VLAN в интерфейсах l2transport на том же домене моста.
Рассмотрим ту же простую топологию, которая была показана ранее. Вместе с тем теперь из-за схемы работы a9k1 несколько сетей VLAN от одного и того же магистрального интерфейса коммутатора, объединяются в одном домене моста.
Это конфигурация a9k1:
Она объединяет сети VLAN (2-4) в один домен моста на a9k1.
Модель ASR 9000 EVC не перезаписывает ни метки, ни почтовый протокол по умолчанию. Данные PVST + BPDU для VLAN2 приходят на интерфейс gig 0/1/0/31.2 и пересылаются обратно на gig 0/1/0/31.3 и gig 0/1/0/31.4. Так как конфигурация не является перезаписью действия почтового протокола входящего потока, BPDU возвращается неизменным. Коммутатор распознает эту ситуацию, так как получает обратно свой собственный пакет BPDU, и блокирует эту сеть VLAN из-за петли.
Команда show spanning-tree interface отображает заблокированную сеть VLAN:
Решение
Эта проблема устраняется посредством использования команды ethernet egress-filter strict в интерфейсах ASR 9000 l2transport.
Это не схема работы не является рекомендуемой. Вместе с тем, если это действительно необходимая схема работы, можно использовать это решение, чтобы коммутатор не получал пакет BPDU, который отправляется обратно в том же интерфейсе.
Можно использовать команду ethernet egress-filter strict в интерфейсах a9k1 l2transport или на глобальном уровне. Это пример в интерфейсе:
Команда ethernet egress-filter strict включает строгую фильтрацию точки потока Ethernet (EFP) для исходящего потока в интерфейсе. Только пакеты, которые проходят фильтр EFP входящего потока в интерфейсе, отправляются из этого интерфейса. Остальные пакеты отбрасываются в фильтре исходящего потока. Это означает, что если пакет, который является исходящим, не соответствует метке encapsulation dot1q, заданной в интерфейсе, то пакет не передается.
Источник
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Траблшутинг STP (Spanning tree protocol)
Часть.2 4 кейса по проблемам с STP
Предыдущая статья этого цикла:
Онлайн курс по Кибербезопасности
Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии
Следующая статья этого цикла:
Case #1
На рисунке представлена топология, состоящая из трех коммутаторов, и между коммутаторами у нас есть два канала связи для резервирования. Коммутатор А был выбран в качестве корневого моста для VLAN 1. Когда вы имеете дело со связующим деревом, лучше всего нарисовать небольшую схему сети и записать роли интерфейса для каждого коммутатора (назначенного, не назначенного/альтернативного или заблокированного). Обратите внимание, что одним из каналов связи между коммутатором A и коммутатором C является интерфейс Ethernet (10 Мбит). Все остальные каналы — это FastEthernet.
Мы используем команду show spanning-tree для проверки ролей интерфейса для коммутатора A и коммутатора C. Вы видите, коммутатор C выбрал свой интерфейс Ethernet 0/13 как корневой порт, а интерфейс FastEthernet 0/14 выбран в качестве альтернативного порта. Это не очень хорошая идея. Это означает, что мы будем отправлять весь трафик вниз по линии 10 Мбит, в то время как 100 Мбит не используется вообще. Когда коммутатор должен выбрать корневой порт он выберет его следующим образом:
Почему коммутатор выбрал интерфейс Ethernet 0/13?
Мы видим, что интерфейс Ethernet 0/13 и FastEthernet0/14 имеют одинаковую стоимость. Затем коммутатор С выберет самый низкий номер интерфейса, который является interface Ethernet 0/13.
После проверки конфигурации интерфейса, видно, что кто-то изменил стоимость интерфейса на 19 (по умолчанию для интерфейсов FastEthernet).
Уберем настройки команды cost.
После того, как мы убрали настройки команды cost, видно, что состояние порта изменилось. FastEthernet 0/14 теперь является корневым портом, а стоимость интерфейса Ethernet 0/13 равна 100 (это значение по умолчанию для интерфейсов Ethernet). Задача решена!
Извлеченный урок: убедитесь, что интерфейс, которым вы хотите сделать в качестве корневого порта, имеет наименьшую стоимость пути.
Case #2
Итак, новый сценарий. Все интерфейсы равны (FastEthernet). Коммутатор A является корневым мостом для VLAN 10, и после проверки ролей интерфейса мы находим следующее:
Хм, интересно. Коммутатор A является корневым мостом, а FastEthernet 0/17 был выбран в качестве резервного порта. Это то, что вы видите каждый день. Коммутатор B выбрал корневой порт, а все остальные интерфейсы являются альтернативными портами. Мы ничего не видим на коммутаторе С.
Мы видим, что Коммутатор A и Коммутатор B используют связующее дерево для VLAN 10. Коммутатор C, однако, не использует связующее дерево для VLAN 10. В чем может быть проблема?
Конечно, неплохо проверить, работают ли интерфейсы на коммутаторе C или нет (но, конечно, это то, что вы уже изучили и сделали в первой статье).
Интерфейсы выглядят хорошо. VLAN 10 активна на всех интерфейсах коммутатора C. Это означает, что остовное дерево должно быть активным для VLAN 10.
Давайте еще раз посмотрим на это сообщение. Это говорит о том, что остовное дерево для VLAN 10 не существует. Есть две причины, по которым можно увидеть это сообщение:
Мы подтвердили, что VLAN 10 активна на всех интерфейсах коммутатора C, поэтому, может быть, связующее дерево было отключено глобально? SwitchC(config)#spanning-tree vlan 10
Извлеченный урок: проверьте, включено ли связующее дерево.
Case #3
Давайте продолжим по другому сценарию! Та же топология. наш клиент жалуется на плохую работу. Начнем с проверки ролей интерфейсов:
Так почему же остовное дерево провалилось здесь? Здесь важно помнить, что связующему дереву требуются блоки BPDU, передаваемые между коммутаторами для создания топологии без петель. BPDU могут быть отфильтрованы из-за MAC access-lists, VLAN access-maps или из-за spanning-tree toolkit?
Ни на одном из коммутаторов нет VLAN access maps.
Нет списков доступа.
Нет port security. как насчет команд, связанных с остовным деревом?
Вот что-то есть!Фильтр BPDU был включен на интерфейсах FastEthernet 0/16 и 0/17 коммутатора B. Из-за этого коммутатор C не получает BPDU от коммутатора B.
Удалим настройки фильтра BPDU.
Теперь вы видите, что FastEthernet 0/16 и 0/17 являются альтернативными портами и блокируют трафик. Наша топология теперь без петель. проблема решена!
Извлеченный урок: убедитесь, что блоки BPDU не заблокированы и не отфильтрованы между коммутаторами.
Case #4
Новая топология. Коммутатор A был выбран в качестве корневого моста для VLAN 10. Все интерфейсы являются FastEthernet каналами.
После использования команды show spanning-tree vlan 10 вот, что мы видим. Все интерфейсы одинаковы, но по какой-то причине коммутатор B решил выбрать FastEthernet 0/16 в качестве корневого порта. Разве вы не согласны с тем, что FastEthernet 0/13 должен быть корневым портом? Стоимость доступа к корневому мосту ниже, чем у FastEthernet 0/16.
Есть несколько вещей, которые мы могли бы проверить, чтобы увидеть, что происходит:
Во-первых, всегда полезно проверить, активно ли связующее дерево для определенной VLAN. Можно отключить spanning-tree с помощью команды no spanning-tree vlan X. В этом сценарии связующее дерево активно для VLAN 10, потому что мы можем видеть на FastEthernet 0/16 и 0/17.
Мы знаем, что остовное дерево активно глобально для VLAN 10, но это не значит, что оно активно на всех интерфейсах. Мы можем использовать команду show interfaces switchport, чтобы проверить, работает ли VLAN 10 на интерфейсе FastEthernet 0/13 и 0/14. Это отобразит нам некоторую интересную информацию. Вы видите, что эти интерфейсы оказались в режиме доступа, и они находятся в VLAN 1.
Давайте изменим режим интерфейсов на магистральный, чтобы трафик VLAN 10 мог проходить через эти интерфейсы.
Ну вот, теперь все намного лучше выглядит. Трафик VLAN 10 теперь передается по интерфейсу FastEthernet 0/13 и 0/14, и вы видите, что интерфейс FastEthernet 0/13 теперь выбран в качестве корневого порта. Задача решена!
Извлеченный урок: убедитесь, что VLAN активна на интерфейсе, прежде чем рассматривать проблемы связующего дерева.
Полный курс по Сетевым Технологиям
В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer
Источник
Причина создания STP
Причиной создания протокола STP стало возникновение петель на коммутаторах. Что такое петля? Определение петли звучит так:
Петля коммутации (Bridging loop, Switching loop) — состояние в сети, при котором происходит бесконечная пересылка фреймов между коммутаторами, подключенными в один и тот же сегмент сети.
Из определения становится ясно, что возникновение петли создает большие проблемы — ведет к перегрузке свитчей и неработоспособности данного сегмента сети. Как возникает петля? На картинке ниже приведена топология, при которой будет возникать петля при отсутствии каких-либо защитных механизмов:
Возникновение петли при следующих условиях:
1. Какой-либо из хостов посылает бродкаст фрейм:
2. Также петля может образоваться и без отправки бродкаст фрейма.
Основы STP
Принцип работы данного протокола построен на том, что все избыточные каналы между коммутаторами логически блокируются и трафик через них не передается. Для построения топологии без избыточных каналов строится дерево (математический граф). Чтобы построить такое дерево вначале необходимо определить корень дерева, из которого и будет строиться граф. Поэтому первым шагом протокола STP является определение корневого коммутатора (Root Switch). Для определения Root Switch-a, коммутаторы обмениваются сообщениями BPDU. В общем, протокол STP использует два типа сообщений: BPDU — содержит информацию о коммутаторах и TCN — уведомляет о изменении топологии. Рассмотрим BPDU более детально. Про TCN более подробно поговорим ниже. При включении STP на коммутаторах, коммутаторы начинают рассылать BPDU сообщения. В данных сообщениях содержится следующая информация:
Фрейм BPDU имеет следующие поля:
Вот вывод информации о Bridge ID с коммутатора Switch1 из первой картинки. Priority — 32769 ( по умолчанию 32768 + Vlan Id), MAC-адреса — Address 5000.0001.0000:
Представим картину, коммутаторы только включились и теперь начинают строить топологию без петель. Как только коммутаторы загрузились, они приступают к рассылке BPDU, где информируют всех, что они являются корнем дерева. В BPDU в качестве Root Bridge ID, коммутаторы указывают собственный Bridge ID. Например, Switch1 отправляет BPDU коммутатору Switch3, а Switch3 отправляет к Switch1. BPDU от Switch1 к Switch3:
BPDU от Switch3 к Switch1:
Как видим из Root Identifier, оба коммутотара друг другу сообщают, что именно он является Root коммутатором.
Выбор корневого коммутатора
Пока топология STP не построена, обычный трафик не передается из-за специальных состояний портов, о которых будет сказано ниже. Итак, Switch3 получается BPDU от Switch1 и изучает данное сообщение. Switch3 смотрит в поле Root Bridge ID и видит, что там указан другой Root Bridge ID, чем в том сообщении, которое отправил сам Switch3. Он сравнивает Root Bridge ID в данном сообщении со своим Root Bridge ID и видит, что хоть Priority одинаковые, но MAC-адрес данного коммутатора (Switch1) лучше (меньше), чем у него. Поэтому Switch3 принимает Root Bridge ID от Switch1 и перестает отправлять свои BPDU, а только слушает BPDU от Switch1. Порт, на котором был получен наилучший BPDU становится Root Port-ом. Switch1 также получив BPDU от Switch3, проводит сравнение, но в этом случае поведение Switch1 не меняется, так как полученный BPDU содержит худший Root Bridge ID, чем у Switch1. Таким образом, между Switch1 и Switch3 был определен корневой коммутатор. По аналогичной схеме происходит выбор корневого коммутатора между Switch1 и Switch2. Порты Gi0/0 на Switch2 и Switch3 становятся Root Port — порт, который ведет к корневому коммутатору. Через данный порт коммутаторы Switch2 и Switch3 принимают BPDU от Root Bridge. Теперь разберемся, что произойдет с каналом между Switch2 и Switch3.
Блокирование избыточных каналов
Как мы видим из топологии, канал между Switch2 и Switch3 должен быть заблокирован для предотвращения образования петель. Как STP справляется с этим?
После того, как выбран Root Bridge, Switch2 и Switch3 перестают отправлять BPDU через Root Port-ы, но BPDU, полученные от Root Bridge, они пересылают через все свои остальные активные порты, при этом изменив в данных BPDU только следующие поля:
А Switch3 от Switch2 получает такой BPDU:
После обмена такими BPDU, Switch2 и Switch3 понимают, что топология избыточна. Почему коммутаторы понимают, что топология избыточна? И Switch2, и Switch3 в своих BPDU сообщают об одном и том же Root Bridge. Это означает, что к Root Bridge, относительно Switch3, существует два пути — через Switch1 и Switch2, а это и есть та самая избыточность против которой мы боремся. Также и для Switch2 два пути — через Switch1 и Switch3. Чтоб избавиться от этой избыточности
необходимо заблокировать канал между Switch3 и Switch2. Как это происходит?
Выбор на каком коммутатоторе заблокировать порт происходит по следующей схеме:
Здесь как оказалось заблокируется порт Gi 0/1 на коммутаторе Sw2. В данном голосовании определяющим становится Root Path Cost. Вернемся к нашей топологии. Так как путь до Root Bridge одинаковый, то в данном выборе побеждает Switch2, так как его priority равны, сравниваются Bridge ID. У Switch2 — 50:00:00:02:00:00, у Switch3 — 50:00:00:03:00:00. У Switch2 MAC-адрес лушче (меньше). После того, как выбор сделан, Switch3 перестает переслать какие-либо пакеты через данный порт — Gi1/0, в том числе и BPDU, а только слушает BPDU от Switch2. Данное состояние порта в STP называется Blocking(BLK). Порт Gi1/0 на Switch2 работает в штатном режиме и пересылает различные пакеты при необходимости, но Switch3 их сразу отбрасывает, слушая только BPDU. Таким образом, на данном примере мы построили топологию без избыточных каналов. Единственный избыточный канал между Switch2 и Switch3 был заблокирован при помощи перевода порта Gi1/0 на Switch3 в специальное состояние блокирования — BLK. Теперь более детально разберем механизмы STP.
Состояния портов
Мы говорили выше, что, например, порт Gi1/0 на Switch3 переходит в специальное состояние блокирования — Blocking. В STP существуют следующие состояния портов:
Blocking — блокирование. В данном состоянии через порт не передаются никакие фреймы. Используются для избежания избыточности топологии.
Listening — прослушивание. Как мы говорили выше, что до того, пока еще не выбран корневой коммутатор, порты находятся в специальном состоянии, где передаются только BPDU, фреймы с данными не передаются и не принимаются в этом случае. Состояние Listening не переходит в следующее даже, если Root Bridge определен. Данное состояние порта длится в течении Forward delay timer, который, по умолчанию, равен 15. Почему всегда надо ждать 15 секунд? Это вызвано осторожностью протокола STP, чтоб случайно не был выбран некорректный Root Bridge. По истечению данного периода, порт переходит в следующее состояние — Learning.
Learning — обучение. В данном состояние порт слушает и отправляет BPDU, но информацию с данными не отправляет. Отличие данного состояния от Listening в том, что фреймы с данными, который приходят на порт изучаются и информация о MAC-адресах заносится в таблицу MAC-адресов коммутатора. Переход в следующее состояние также занимает Forward delay timer.
Forwarding — пересылка. Это обычное состояние порта, в котором отправляются и пакеты BPDU, и фреймы с обычными данными. Таким образом, если мы пройдемся по схеме, когда коммутаторы только загрузились, то получается следующая схема:
Роли портов
Помимо состояний портов, также в STP нужны определить портам их роли. Это делается для того, чтоб на каком порте должен ожидаться BPDU от корневого коммутатора, а через какие порты передавать копии BPDU, полученных от корневого коммутатора. Роли портов следующие:
Root Port — корневой порт коммутатора. При выборе корневого коммутатора также и определяется корневой порт. Это порт через который подключен корневой коммутатор. Например, в нашей топологии порты Gi0/0 на Switch2 и Switch3 являются корневыми портами. Через данные порты Switch2 и Switch3 не отправляют BPDU, а только слушают их от Root Bridge. Возникает вопрос — как выбирается корневой порт? Почему не выбран порт Gi1/0? Через него ведь тоже можно иметь связь с коммутатором? Для определения корневого порта в STP используется метрика, которая указывает в поле BPDU — Root Path Cost (стоимость маршрута до корневого свича). Данная стоимость определяется по скорости канала.
Switch1 в своих BPDU в поле Root Path Cost ставит 0, так как сам является Root Bridge. А вот, когда Switch2, когда отправляет BPDU к Switch3, то изменяет данное поле. Он ставит Root Path Cost равным стоимости канала между собой и Switch1. На картинке BPDU от Switch2 и Switch3 можно увидеть, что в данном поле Root Path Cost равен 4, так как канал между Switch1 и Switch2 равен 1 Gbps. Если количество коммутаторов будет больше, то каждый следующий коммутатор будет суммировать стоимость Root Path Cost. Таблица Root Path Cost.
Designated Port — назначенный порт сегмента. Для каждого сегмента сети должен быть порт, который отвечает за подключение данного сегмента к сети. Условно говоря, под сегментом сети может подразумеваться кабель, который осуществляет подключение данного сегмента. Например, порты Gi0/2 на Switch1, Switch3 подключают отдельные сегменты сети, к которым ведет только данный кабель. Также, например, порты на Root Bridge не могут быть заблокированы и все являются назначенными портами сегмента. После данного пояснения можно дать более строгое определения для назначенных портов:
Designated Port (назначенный) — некорневой порт моста между сегментами сети, принимающий трафик из соответствующего сегмента. В каждом сегменте сети может быть только один назначенный порт. У корневого коммутатора все порты — назначенные.
Также важно заметить, что порт Gi1/0 на Switch2 также является назначенным, несмотря на то, что данный канал связи заблокированным на Switch3. Условно говоря, Switch2 не имеет информации о том, что на другом конце порт заблокирован.
Nondesignated Port — неназначенный порт сегмента. Non-designated Port (неназначенный) — порт, не являющийся корневым, или назначенным. Передача фреймов данных через такой порт запрещена. В нашем примере, порт Gi1/0 является неназначенным.
Disabled Port — порт который находится в выключенном состоянии.
Таймеры и сходимость протокола STP
После того, как STP завершил построение топологии без петель, остается вопрос — Как определять изменения в сети и как реагировать на них? Сообщения BPDU при помощи которых работает STP, рассылаются Root Bridge каждые 2 секунды, по умолчанию. Данный таймер называется Hello Timer. Остальные коммутаторы получив через свой root port данное сообщение пересылают его дальше через все назначенные порты. Выше сказано более подробно какие изменения происходят с BPDU при пересылки его коммутаторов. Если в течении времени, определенным таймером Max Age (по умолчанию — 20 секунд), коммутатор не получил ни одного BPDU от корневого коммутатора, то данное событие трактуется как потеря связи с Root Bridge. Для того, чтобы более корректно описать сходимость протокола необходимо изменить нашу топологию и поставить между коммутаторами хабы. Мы добавили хабы, чтоб при выходе из строя одного из коммутаторов или выхода из строя линка, другие коммутаторы не определяли это по падению линка, а использовали таймеры:
Перед тем, как начать также важно рассказать подробнее о другом типе сообщения STP — TCN. TCN рассылается коммутаторами в случае изменения топологии — как только на каком-либо коммутаторе изменилась топология, например, изменилось состояние интерфейса. TCN отправляется коммутатором только через Root Port. Как только корневой коммутатор получит TCN, он сразу меняет параметр времени хранения MAC-адресов в таблице с 300 секунд до 15 (для чего это делается будет сказано ниже) и в следующем BPDU, Root Switch проставляет флаг — TCA ( Topology Change Acknledgement ), который отправляется коммутатору отправившем TCN для уведовления о том, что TCN был получен. Как только TCN достигает Root Bridge, то он рассылает специальный BPDU, который содержится TCN флаг по всем остальным интерфейсам к другим коммутаторам. На картинке показана структура TCN:
TCN был включен в STP, чтоб некорневые коммутаторы могли уведовлять об изменении в сети. Обычными BPDU они этого делать не могут, так как некорневые коммутаторы не отправляют BPDU. Как можно заметить структура TCN не несет в себе никакой информации о том, что именно и где изменилось, а просто сообщает что где-то что-то изменилось. Теперь перейдем к рассмотрению вопроса о сходимости STP.
Посмотрим, что произойдет если мы отключим интерфейс Gi0/1 на Switch1 и посмотрим при помощи каких механизмов перестроится дерево STP. Switch2 перестанет получать BPDU от Switch1 и не будет получать BPDU от Switch3, так как на Switch3 данный порт заблокирован. У Switch2 уйдет 20 секунд ( Max Age Timer ), чтоб понять потерю связи с Root Bridge. До этого времени, Gi0/0 на Switch2 будет находится в состоянии Forwarding с ролью Root Port. Как только истечет Max Age Timer и Switch2 поймет потерю связи, он будет заново строить дерево STP и как это свойственно STP начнет считать себя Root Bridge. Он отправит новый BPDU, где укажет самого себя в качестве Root Bridge через все активные порты, в том числе и на Switch3. Но таймер Max Age, истекший на Switch2 также истек и на Switch3 для интерфейса Gi1/0. Данный порт уже 20 секунд не получал BPDU и данный порт перейдет в состояние LISTENING и отправит BPDU c указанием в качестве Root Bridge — Switch1. Как только Switch2 примет данный BPDU, он перестанет считать себя Root Bridge и выберет в качестве Root Port — интерфейс Gi1/0. В этот момент Switch2 также отправит TCN через Gi1/0, так как это новый Root Port. Это приведет к тому, что время хранения MAC-адресов на коммутаторах уменьшится с 300 секунд до 15. Но на этом работоспособность сети не восстановится полностью, необходимо подождать пока порт Gi1/0 на Switch3 пройдет состояние Listening, а затем Learning. Это займет время равное двум периодам Forward delay timer — 15 + 15 = 30 секунд. Что мы получаем — при потери связи Switch2 ждет пока истечет таймер Max Age = 20 секунд, заново выберает Root Bridge через другой интерфейс и ждет еще 30 секунд пока ранее заблокированный порт перейдет в состояние Forwarding. Суммарно получаем, что связь между VPC5 и VPC6 прервется на 50 секунд. Как было сказано несколькими предложениями выше при изменение Root Port с Gi0/0 на Gi1/0 на Switch2 был отправлен TCN. Если бы этого не произошло, то все MAC-адреса, изученные через порт Gi 0/0, оставались бы привязаны к Gi0/0. Например, MAC-адрес VPC5 и VPC7 несмотря на то, что STP завершит сходимость через 50 секунд, связь между VPC6 и VPC5, VPC7 не была бы восстановлена, так как все пакеты предназначенные VPC5, VPC7 отправлялись через Gi0/0. Надо было бы ждать не 50 секунд, а 300 секунд пока таблица MAC-адресов перестроится. При помощи TCN, время хранение изменилось с 300 секунд до 15 и пока интерфейс Gi1/0 на Switch3 проходил состояния Listening, а затем Learning и данные о MAC-адресах обновятся.
Также интересен вопрос, что произойдет, если мы заново включим интерфейс Gi0/1 на Switch1? При включение интерфейса Gi0/1, он, как и подобает, перейдет в состояние Listening и начнет рассылать BPDU. Как только Switch2 получит BPDU на порту Gi0/0, то сразу перевыберет свой Root Port, так как тут Cost будет наименьшем и начнет пересылать траффик через интерфейс Gi0/0, но нам необходимо подождать пока интерфейс Gi0/1 пройдет состояния Listening, Learning до Forwarding. И задержка будет уже не 50 секунд, а 30.
В протоколе STP также продуманы различные технологии для оптимизации и безопасности работы протокола STP. Более подробно в данной статье рассматривать их не буду, материалы по поводу них можно найти в избытке на различных сайтах.
Источник