STP question re: redundancy

jscimeca715

I'm having trouble understanding physical redundancy and Odoms book doesn't explain it very well. Can someone explain what physical redundancy is and the implications that it has on STP? If you don't want to explain it and have a good website that will also be appreciated. Thanks!

darkuser

physical redundency would be more then one link to the same place

if you have a single link it is forwarding
if you have two links to the same place
one is blocking and one is forwarding
giving you "physical redundency"
if the forwaring link were to go down

jscimeca715

So physical redundancy would be two connections between two switches? One connection would be blocking and one would be forwarding? What happens if the switch breaks down?

darkuser

um .... add more switches ????

darkuser

http://www.cisco.com/warp/public/473/16.html

jscimeca715

I guess I'm not understanding your answer. How is physical redundancy still physical redundancy if you need to replace the switch if it stops working. If frame a travels to switch 1 through switch 2 what happens if switch 2 goes down? If switch 1 is also attached to switch 3 then would STP open up switch 3 and block switch 2? Does any of this make sense?

rfult001

Imagine you have 2 routers both going to a bridge. If router 1 goes down all packets will re-route through router 2. The idea is that you would have multiple paths to the same location.

he-man

Hey,

The "physical"redundancy refers to a failed cable (it might get pulled out when tidying, workman might cut through it!) or a failed port on the switch. If the switch itself blows up, then......yea, you need another switch.

You can have have multiple links between the switches, but only 1 of the links can be forwarding or active, otherwise you create loops in your topology. (Unless you use Etherchannels which bundles the redundant physical links into one logical link, but thats another story!)

Hope that helps

pooker

Imagine it like this

switch 4 is connectect to switch one and two, switch three is connected to swith 1 and two, the path to switch one is blocked because of stp, so the communication between user1 and user2 is sent through switch 2 - 3- user , if switch two goes down, then switch one because active and the forwarding of traffic then becomes switch 4 - switch 1 - switch 3 - user 2


user2

switch3

switch1 switch2

switch4

user1

rfult001

much better explanation.

These are the notes from my networking class: http://www.cs.fiu.edu/~esj/cis4930/notes/class18.html

read the review of transparent bridging

Slowhand

Physical redundancy is the very reason why STP exists. When you have a large environment, (or even a small one,) you want to make sure it stays up even if a switch fails. So, you cross-connect switches to deliver data to the same place, or you uplink several switches to each other to make sure that the others can pick up the slack if one fails, and the users never know the difference. The simplest explanation:


If switch A goes down, switch B is still there to deliver frames from PC-A to PC-B. The redundancy idea is more of a design concept, but most books and training resources on STP fail to thoroughly explain that STP was designed to prevent a problem that arises with redundant paths, and instead focus on what huge problem looping is. What STP does is make sure that frames are going through only one switch, so that PC-B doesn't get mulitple packets, and that Switch A isn't sending packets to Switch B on Segment B, which Switch B sends back to Switch A on Segment A, creating a loop that never ends. One switch works, the other waits until it's needed.

jscimeca715

Thanks for all the sound advice guys, I'm using Odoms book and he goes into an example about five pages later that makes things a lot clearer for me. That's not to say I didn't bookmark all the awesome sites you guys mentioned. Thanks.

LBC90805

Slowhand wrote:

Physical redundancy is the very reason why STP exists. When you have a large environment, (or even a small one,) you want to make sure it stays up even if a switch fails. So, you cross-connect switches to deliver data to the same place, or you uplink several switches to each other to make sure that the others can pick up the slack if one fails, and the users never know the difference. The simplest explanation:


If switch A goes down, switch B is still there to deliver frames from PC-A to PC-B. The redundancy idea is more of a design concept, but most books and training resources on STP fail to thoroughly explain that STP was designed to prevent a problem that arises with redundant paths, and instead focus on what huge problem looping is. What STP does is make sure that frames are going through only one switch, so that PC-B doesn't get mulitple packets, and that Switch A isn't sending packets to Switch B on Segment B, which Switch B sends back to Switch A on Segment A, creating a loop that never ends. One switch works, the other waits until it's needed.

Not to mention to avoid routing loops and broadcast storms as a result of those loops.

A question; how often are multiple paths included in smaller networks with that include only Access Switches? Say for instance three switches with redundant links, two paths, between each link.

Slowhand

LBC90805 wrote:

A question; how often are multiple paths included in smaller networks with that include only Access Switches? Say for instance three switches with redundant links, two paths, between each link.

It really depends on the needs of the network. It's not common for small networks to have redundant paths, that type of design is usually reserved for larger, more complex networks. However, if the network is small but it's absolutely critical to have a maximum amount of uptime between users, then you'd want to have redundant paths through the switches, or a backup switch like you see in the picture. The idea is that redundant paths through a switched network is a design-concept that allows for reduncancy in case of a failure, and STP is a mechanism to deal with the problems that arise from using multiple paths. Solving the solution, so to speak.