RSTP - how to change root ports?

Question

System administration

I have this ring. It worked fine for itself, blocking the port in the "Department of Chief Energy" and everything was fine. Then I got a "3CoM Communication Node" and when it appeared, its port was blocked and now traffic from the root to "HP" (above "Department of Chief Energy") runs through such a long chain. The quality of the connection has dropped a lot.
I tried to restart the "right wing", "HP" all to no avail. Traffic through the "3CoM Communication Center" does not want to run, even shoot yourself. There was a problem on the "Communication Node" there was an sfp module and it did not automatically determine the speed (because of this, its cost was 65535) - fixed it, the cost became 4. restarts do not help. Do you need to restart the root switch?
ps the saddest thing is that I can’t assign a root port through the hp1810 web face,
Question: how can I make sure that the gap is between the "Department of Chief Energy" and the "right wing"?

Answer 1

as a result:
sat and smoked protocols, on one switch there was an ancient protocol, changed to a fresh one. On one more switch on links edge was included, switched off. Included everywhere, except for trunk links, portfast\edge. I set the priority of the switch root to 12288.
Now topology changes on all switches are indicated correctly, if the link falls within 30-60 seconds, the traffic starts to bypass. So far I've only checked it on a couple of switches, I'll check the rest by the end of the week. While everything works - everything is stable.

Answer 2

Question: how can I make sure that the gap is between the "Department of Chief Energy" and the "right wing"?

To do this, in my opinion, it is necessary to increase the cost value for this link on each side to a sufficiently high value.
Now, as to this very meaning. Given the heterogeneity of your network, it's worth checking exactly which cost values ​​are set for each of the interfaces participating in the RSTP process. They can be either 16 or 32 bit as far as I know. If all cost values ​​are set to 4 for gigabit and 19 for 100-megabit ports, a cost of 300 for the corresponding link (on each side, in case the root switch changes further) should be sufficient.
You also need to make sure that each of the above interfaces works in full duplex mode (that is, it is, from the point of view of RSTP, a p2p port). This is necessary to correctly handle topology change.
If this does not help and additional questions arise, then please, take the trouble to draw a normal readable network diagram with the necessary information (bridge id of each switch, cost for each interface participating in RSTP).

Answer 3

you can try to put the port in one direction on the root switch, then, in theory, the ring will be reset.

Answer 4

priority(128), admin edge(non-edge), point-to-point(forced true) leave default for all ports?

It makes sense to lower the priority value for the root switch. For now, I suggest you don't.
Edge port - a port that is guaranteed not to have a loop. Typically connected to a workstation or server. Accordingly, the ports connected by a link between switches cannot be edge.
Point-to-point - a port connected, as a rule, by a full-duplex link to only one other port. For RSTP to work properly, all ports must be in point-to-point mode. If the port switches to shared mode (for example, duplex is broken), then RSTP works, as far as I know, in compatibility mode with the 'old' STP (802.1d).

Answer 5

Thanks for the diagram.
This is good.
Here I do not understand. These three switches are not sw1, sw2, sw5 by any chance, which are you talking about further? Apparently, I expressed myself incomprehensibly, I believe that on all switches it is necessary to achieve uniformity in the representation of the cost of the path (root path cost). Otherwise, we are left to guess how 16-bit and 32-bit values ​​are mapped to each other, given that the field in the BPDU has a length of 32 bits. To understand this, you will need to study the BPDU dump and so on. Therefore, I ask you to bring the calculation of the cost of the path back to a single mode. Keywords for searching in the interface are root path cost short (16-bit version), root path cost long (32-bit version).

When I looked at the bridge id, I noticed a strange thing:
sw1, sw2, sw5 have root bridge id exactly the same as their bridge id. On the other switches everything is fine.

This is bad. This means that each of them considers itself the root switch. Possible reasons - BPDU failure. What else do these three switches have in common? Manufacturer, maybe?
I think that if the network is working properly, restarting the switches after changing the link cost will not be required.

Answer 6

Please compare the STP configuration of the root switch and one of sw1/sw2/sw5.
General STP configuration and uplink ports to other switches ( pages 49,58 ).

Answer 7

Look at the legend, the values ​​​​circled in red - what is this? Accidentally not STP activity on the interface?

Answer 8

RSTP is still off on the ports, as far as I can tell from the selection. Try enabling RSTP on these ports (Spanning tree per port section in the documentation).
Also check that on all links between switches, the Edge port mode must be turned off on each side. This mode is sometimes referred to as portfast.
Root guard, if it is active somewhere, also needs to be turned off for now.

Answer 9

Turned it on, indeed the switches saw the root bridge, the cost was normally calculated,

Good. Which link is currently being blocked?

Answer 10

I suspect that for some reason BPDUs still do not go around the ring.
Please send the state of the uplink ports (in the sense of STP) for each switch with a full legend. Like here:
And please somehow mark where the switch is, so that the screenshots are not confused.

Answer 11

In general, since all switches have correctly identified the root switch, BPDUs in at least one direction of the ring traverse normally.
Further, after you have switched port 1 of switch sw3 from Edge mode to normal mode, please send again the status of the RSTP ports of all switches. The values ​​of root port and root path cost on some of them should change. I propose to deal with vlans later.

Answer 12

ps Do you have any idea why the ring is not working?

If my assumptions are justified and the root path cost values ​​change after the edge mode of port 1 of the sw3 switch is canceled, then RSTP is probably working fine, and we will take a closer look at the distribution of vlans by ports.

Answer 13

nothing changed.

In the screenshots you provided (port states, 1 , 2 , 3 ), all ports are in the port state Forwarding. In the case of normal RSTP operation in the ring, one port should be in the Blocking state (probably a different, similar term is used). Please check if the state of the port participating in RSTP has changed from Forwarding to Blocking somewhere.
Repeating the previous, all ports are in the Forwarding state, which is strange. Can you please tell me how you determine the blocked status of a link? By traffic level?

Answer 14

can't my ring not work because of this switch, which, in fact, consists of a process in the ring ...

It is unlikely that the reason is in this switch (about the reason below), but please indicate what other STP switches are in the L2 domain.
I am more and more asserting in the assumption that there is no two-way patency of BPDU on each link, and the probable reason is inconsistent distribution of vlans across ports. For example, Cisco switches work in RSTP (IEEE 802.1w) mode or on access ports, or in vlan 1 trunks ( see here ). I think in your case the creativity of the vendor is also quite likely.
Further, you wrote:
I did not quite understand where the vlans are. Can you provide screenshots of the settings for each port in terms of vlans and other things?
Further, I'm drawing a more intelligible network diagram here, please specify the bridge ID of the sw3-4, sw6-9 switches. In your diagram, the part defined by the MAC address is 7 octets long instead of 6 (example - sw9 32768-20:38:ea:a7:bb:7a:40), I didn't understand that either.
I hope if each link is configured the same way (same vlans on each side of the link), the tree will line up properly. Only until there is a clear plan, it is undesirable to change the VLAN configuration of links. I'm still assuming that an untagged vlan 1 is needed in each link between the switches.

Answer 15

Here is a rough topology diagram. There are a couple of ambiguities left - the sw5 switch model (judging by the MAC address, this is 3com, you have HP listed, but so far it’s not critical, I think) and the trunk from the root side to sw1 (on it, as I understand it, all vlans except 1 are tagged, so which Are there vlans on it at all?).
The most important thing is the settings of the links sw2 <-> sw3 and root <-> sw9. In each case, the untagged vlan is 1 on the one hand, and 350 on the other. As a result, they are actually merged on L2. Any host in vlan 1 can access any host in vlan 350, if desired. It is not yet clear why you have not yet observed a broadcast storm at all, as I understand it, there are conditions for it.

Answer 16

I suggest: 1) set untagged vlan 1
for port 49 of the root switch 2) switch
port 26 of the sw2 switch to access mode (set untagged vlan 1)
It is desirable to do this step by step. Considering the general originality of the network design, you should be prepared for its inoperability (including the failure of the managing vlan), although this is unlikely. That is, it is better to do this during non-working hours, you may have to roll back the settings on the spot using console access to the switch.

Answer 17

Yes, it's better to figure out which server uses which vlan. Since vlans 350 and 1 are actually combined, it will be easier to see which IP addresses from which prefixes are configured on which server/host and then map the prefix to the vlan number using the configuration of the router located behind the root switch .

Answer 18

I have a question
. Could you clarify what the e / d symbols in the STP column mean for the switches sw1 , sw2 , sw5 ? If we draw an analogy with the root switch, then this probably means enabled / disabled. That would explain a lot. Please check the difference between the settings for ports 25 and 26 of these switches ( sw1 , sw2 , sw5 ).

Answer 19

It seems to me, or is there still something wrong here, and the next time a switch is disconnected, the traffic will not go around?

It still seems to me that RSTP is disabled on some ports and the corresponding switches just redirect other people's BPDUs (option BPDU handling , value flooding ). More precisely, I can say a little later, when I figure out the designated cost values ​​​​- whether they correspond to the topology.

Answer 20

Here is what happened with the screenshots you provided: toster -rstp-costs.pdf
Here is what happened during emulation: toster-rstp-lab-results.pdf
like here ) for switches sw1-sw5.

Answer 21

Answer 22

no.

Answer 23

@throughtheether
there are no more. Specialist checked everything.
sinful. Switches that are hp do not provide information about the bridge-id and I thought it was compiled according to the "Switch priority-max age: mac address" principle.
The information provided by the switch is:

Answer 24

@throughtheether
on all others untagged 1vlan.
As I understand it, the snag is in sw2 with untagged 350 vlan.

Answer 25

@throughtheether these vlans are not enabled on the servers. It's just that another provider enters the root switch on port 4, with a vlan through port 8, into which the router is plugged, it wraps this provider and sends it to sw2 so that telephony works there.

Answer 26

@throughtheether
In general, I thought that 2 minutes was not enough. I closed the ring again, waited 5 minutes, nothing came up, I decided to return 350vlan to sw3 on sw2 and everything started up the way I wanted it and sw5 says that port 26 is "Alternate". But here's the problem: sw1, sw2, sw3, sw4, sw5 say that the topology has changed (5 minutes ago), all other switches, incl. root says the topology changed 2 hours ago. although all switches recognize the root is true. It seems to me, or is there still something wrong here, and the next time a switch is disconnected, the traffic will not go around?

Answer 27

on sw5, this port is written alternate, but in fact there is 10 Mbps traffic and there is no place on the entire ring where there is no traffic

The link is blocked on one side only (sw5). The other side, apparently, continues to send traffic to this port, it's okay. I think it's some kind of broadcast. If this is a Unicast, then, theoretically, the corresponding entry in the MAC address table should become obsolete after some time and be deleted.

also noticed a strange thing
on sw1 designated bridge id:
25port 32768-00:15:77:fd:40:00 (id root bridge)
26port 32768-20:fd:f1:96:cb:90 (id this bridge)
on sw2 same story: id sw1 and id sw2
but on sw5 comes id sw4 and sw6

This is normal, as it should be, given that it is on sw5 that the port is blocked. You can compare with the results of emulation .
For RSTP to work correctly, it is important that edge mode is used only on ports connected to workstations, that all STP switches work in RSTP mode, and that links between switches work in p2p mode. I think I have mentioned this many times.

Answer 28

While everything works - everything is stable.

I'm glad that everything works, but I'll allow myself a couple more observations (see corrected topology diagram ). Based on the data you provided (see the Path cost and Designated bridge ID fields ), you assigned a high cost to sw5 to the interface before sw6 , instead of the interface before sw4 . Also, to eliminate further effects (observed when changing the root RSTP switch), it is better to assign the same cost value to the link interfaces from different sides.