Community discussions

MikroTik App
 
arky
just joined
Topic Author
Posts: 12
Joined: Sat Apr 09, 2011 12:39 pm

STP Protocol

Sun Dec 06, 2015 10:59 pm

Hello,
I have a network based on one big bridge. I do not know how to use STP Bridge Protocol. Are all devices enable STP, RSTP or none?
 
User avatar
pietroscherer
Trainer
Trainer
Posts: 170
Joined: Thu Mar 05, 2015 3:05 pm
Location: RS, Brazil
Contact:

STP Protocol

Mon Dec 07, 2015 1:55 am

To enable redundancy for Layer 2, you have to activate rstp on all bridges, and choosing a root bridge, lowering the priority of the chosen router. Usually chooses the router with more redundant outputs. If you can not choose the root bridge, the router with the lowest MAC, will be chosen.


Enviado do meu iPhone
 
arky
just joined
Topic Author
Posts: 12
Joined: Sat Apr 09, 2011 12:39 pm

STP Protocol

Mon Dec 07, 2015 10:12 am

I have to run RSTP on all bridges (point-to-point) or at all mikrotikach (even end-customers providing internet)? how to set priorities? or can someone show an example?
 
User avatar
pietroscherer
Trainer
Trainer
Posts: 170
Joined: Thu Mar 05, 2015 3:05 pm
Location: RS, Brazil
Contact:

Re: STP Protocol

Mon Dec 14, 2015 8:46 pm

I have to run RSTP on all bridges (point-to-point) or at all mikrotikach (even end-customers providing internet)? how to set priorities? or can someone show an example?
RSTP will avoid broadcast storms only where you have it enabled. To avoid loops in end-customers, you'll need to enable there too. RSTP needs run in all network segment
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4047
Joined: Wed May 11, 2011 6:08 pm

Re: STP Protocol

Mon Dec 14, 2015 9:03 pm

I have to run RSTP on all bridges (point-to-point) or at all mikrotikach (even end-customers providing internet)? how to set priorities? or can someone show an example?
RSTP will avoid broadcast storms only where you have it enabled. To avoid loops in end-customers, you'll need to enable there too. RSTP needs run in all network segment
RSTP alone is not enough to prevent broadcast storms and loops. If a user plugs an un-managed switch into an RSTP port, and then later connects a loop into the dumb switch, it will blow things up. That's what Cisco features like rootguard, bpduguard, etc are for.

Choice of the root is very important - Suppose you have three switches A1, A2, and R1 - where A* are access switches and R1 is the root switch. Suppose that A1 and A2 have direct connections between them as well as direct connections to R1. This makes a triangle: A1 -> R1 -> A2 (the link from A1 to A2 is disabled by RSTP). This means that even though there's a direct connection from A1 to A2, communications from hosts on A1 will go through R1 to get to hosts on A2.

In general, if you have a main site with several branch sites connecting to the central site, you'd obviously want the central site to be the root.
Hello,
I have a network based on one big bridge.
I cannot recommend strongly enough against this configuration. Having a giant flat broadcast domain is a very dangerous situation. There are times that it's required, and if yours is such a situation, then of course you must work within the limits of the situation.

You should use a new network segment at each site and enable routing between them instead. Broadcast storms and bridge loops are two very real reasons why there even exists such a thing as the OSI network layer. There are very few things that absolutely require being on the local network segment. For anything that seems to require it, there is usually something that allows it to work over a WAN, such as multicast routing, Active directory, DNS, NAT, etc.
 
User avatar
pietroscherer
Trainer
Trainer
Posts: 170
Joined: Thu Mar 05, 2015 3:05 pm
Location: RS, Brazil
Contact:

Re: STP Protocol

Mon Dec 14, 2015 9:44 pm

I have to run RSTP on all bridges (point-to-point) or at all mikrotikach (even end-customers providing internet)? how to set priorities? or can someone show an example?
RSTP will avoid broadcast storms only where you have it enabled. To avoid loops in end-customers, you'll need to enable there too. RSTP needs run in all network segment
RSTP alone is not enough to prevent broadcast storms and loops. If a user plugs an un-managed switch into an RSTP port, and then later connects a loop into the dumb switch, it will blow things up. That's what Cisco features like rootguard, bpduguard, etc are for.

Choice of the root is very important - Suppose you have three switches A1, A2, and R1 - where A* are access switches and R1 is the root switch. Suppose that A1 and A2 have direct connections between them as well as direct connections to R1. This makes a triangle: A1 -> R1 -> A2 (the link from A1 to A2 is disabled by RSTP). This means that even though there's a direct connection from A1 to A2, communications from hosts on A1 will go through R1 to get to hosts on A2.

In general, if you have a main site with several branch sites connecting to the central site, you'd obviously want the central site to be the root.
Hello,
I have a network based on one big bridge.
I cannot recommend strongly enough against this configuration. Having a giant flat broadcast domain is a very dangerous situation. There are times that it's required, and if yours is such a situation, then of course you must work within the limits of the situation.

You should use a new network segment at each site and enable routing between them instead. Broadcast storms and bridge loops are two very real reasons why there even exists such a thing as the OSI network layer. There are very few things that absolutely require being on the local network segment. For anything that seems to require it, there is usually something that allows it to work over a WAN, such as multicast routing, Active directory, DNS, NAT, etc.
RSTP configuration is really very important. Routing in this case, is the best choice. Thanks for corrections.
 
arky
just joined
Topic Author
Posts: 12
Joined: Sat Apr 09, 2011 12:39 pm

STP Protocol

Wed Dec 16, 2015 12:26 am

I have a network built on Mikrotik and Ubiquiti. Understanding that I have at all Mikrotik rstp?


Wysłane z iPad za pomocą Tapatalk
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4047
Joined: Wed May 11, 2011 6:08 pm

Re: STP Protocol

Wed Dec 16, 2015 7:07 pm

I have a network built on Mikrotik and Ubiquiti. Understanding that I have at all Mikrotik rstp?


Wysłane z iPad za pomocą Tapatalk
You really only need to use spanning tree if you're going to create redundant links in your bridging topology. Spanning tree's job is to prevent switching loops by temporarily disabling backup links. If the best path to the root gets broken, then the backup links will be activated. When the best path becomes available again, the backups are blocked again.

If your network is inherently a tree (i.e. physically no loops in the topology), then (R)STP isn't really going to help you a whole lot.
 
arky
just joined
Topic Author
Posts: 12
Joined: Sat Apr 09, 2011 12:39 pm

Re: STP Protocol

Sat Dec 19, 2015 10:04 pm

I have a network based on a star topology and do not have backup links or rings, so if you well when it comes to the loop in one part of the network is to me the "RSTP" just cut off?
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4047
Joined: Wed May 11, 2011 6:08 pm

Re: STP Protocol

Sun Dec 20, 2015 5:19 pm

Imagine you have 3 switches A, B, and C, with each connected directly to the other two.
(A->B, A->C, and B->C)
Suppose A is the root bridge. Then the link from B-> will become blocked by STP. If the A->B link goes down, then B-> will become unblocked, and B will reach A through C. This is the basic case for STP.

Another way it will protect you is this: suppose you have an unmanaged (dumb) switch, and you connect it to switch B with two different links. B will block one of the connections to the dumb switch.

However: If you connect the dumb switch to switch B, but then connect two ports of the dumb switch together in a loop, then STP will not protect against this.

In other words, if a loop forms outside of the STP group of switches via a single connection, then STP can't help you.

Who is online

Users browsing this forum: No registered users and 20 guests