Spanning-Tree in the real world

pham0329

I'm going through my CCNP:Switching studies, and every time I get to Spanning-Tree, whether it's CBT Nuggets, INE, the OCG, or FLG, I get bored out of my mind.

Just curious as to whether anyone actually applied what they learn about spanning-tree, and it's variation in real life? Has anyone actually ran into a looping issue at work?

odysseyelite

pham0329 wrote: »

I'm going through my CCNP:Switching studies, and every time I get to Spanning-Tree, whether it's CBT Nuggets, INE, the OCG, or FLG, I get bored out of my mind.

Just curious as to whether anyone actually applied what they learn about spanning-tree, and it's variation in real life? Has anyone actually ran into a looping issue at work?

Really, Boring? I thought it was pretty cool when I set it up at home, ran a ping test and it never went down as I unplugged the cable.

At my last job I've seen routing loops happen. A user plugged in a switch and then accidently plugged it into the network agian. Entire network was going crazy.

I don't think the cisco switches were running any type of port security to keep this from happening.

shodown

pham0329 wrote: »

I'm going through my CCNP:Switching studies, and every time I get to Spanning-Tree, whether it's CBT Nuggets, INE, the OCG, or FLG, I get bored out of my mind.

Just curious as to whether anyone actually applied what they learn about spanning-tree, and it's variation in real life? Has anyone actually ran into a looping issue at work?

You haven't worked in IT long enough.




In modern designs we avoid it, by using things like VSS and so on, but in smaller networks where they have the 3750 and smaller switches I have seen quite a few loops appear in the network. Also remember I work in Escalations where I'm not babying networks day to day so I only get the call when it hits the fan. But there are thousands upon thousands of poorly designed networks out here waiting on a loop to happen

pham0329

shodown wrote: »

You haven't worked in IT long enough.




In modern designs we avoid it, by using things like VSS and so on, but in smaller networks where they have the 3750 and smaller switches I have seen quite a few loops appear in the network. Also remember I work in Escalations where I'm not babying networks day to day so I only get the call when it hits the fan. But there are thousands upon thousands of poorly designed networks out here waiting on a loop to happen

How exactly do you figure out which switch is causing the loop without going to every single switch?

Suppose I come in one day, with a 8 port netgear switch. I sit down in my cubicle and decides to plug it in a data port, going to one switch. Then I plugged in another connection, going to a different switch. How would you go about tracking me down?

Kelkin

If you were in my office your port would immediately be shutdown once a BPDU was received

Zartanasaurus

You'd see a MAC address flapping message on your syslog server.

gouki2005

Kelkin wrote: »

If you were in my office your port would immediately be shutdown once a BPDU was received

thats why we love bpdu guard

Shanman

This brings back memories... Just a few months ago we had a teacher decide to more her phone and plug it in to the wall twice. Since my boss doesn't want to use stp and we have 5 buildings in the same broadcast domain with one vlan for internal, you can imagine what happened. The whole thing belly up. The logs said excessive broadcast everywhere.

I isolated it to the building by shutting down all fiber links and then bringing them back online one by one. I then traced it back to the switch closet and then to the switch. We use procurve switchs too.

He still does not want to use stp or vlan off the VoIP from the rest of the network. Lol

ehnde

Shanman wrote: »

This brings back memories... Just a few months ago we had a teacher decide to more her phone and plug it in to the wall twice. Since my boss doesn't want to use stp and we have 5 buildings in the same broadcast domain with one vlan for internal, you can imagine what happened. The whole thing belly up. The logs said excessive broadcast everywhere.

I isolated it to the building by shutting down all fiber links and then bringing them back online one by one. I then traced it back to the switch closet and then to the switch. We use procurve switchs too.

He still does not want to use stp or vlan off the VoIP from the rest of the network. Lol

No offense, but is your boss stupid? I've heard of people disabling STP but never understood why. Might as well be punching yourself in the face.

Monkerz

Its not just his boss, mine is the say way. He is completely against anything different or modern. We use static routes EVERYWHERE, thousands of them, because he has this grudge against BGP. I don't think he even knows what BGP stands for, I highly doubt it. Not one of our 162 remote branches are running STP. We have a site go down atleast once a month due to an eTard (copyrighted ) plugging "the dangling end" of a CAT5 cable from one wall jack to another "so the end wouldn't get stepped on an broken."

shodown

Shanman wrote: »

This brings back memories... Just a few months ago we had a teacher decide to more her phone and plug it in to the wall twice. Since my boss doesn't want to use stp and we have 5 buildings in the same broadcast domain with one vlan for internal, you can imagine what happened. The whole thing belly up. The logs said excessive broadcast everywhere.

I isolated it to the building by shutting down all fiber links and then bringing them back online one by one. I then traced it back to the switch closet and then to the switch. We use procurve switchs too.

He still does not want to use stp or vlan off the VoIP from the rest of the network. Lol

This is a example network that I usually get assinged to fix. The reasons he may not want to run spanning tree depends on the environment, but for a normal campus network I can't see why not. Voip should always been in its own VLAN it shouldn't be mixed in with the rest of the traffic as QOS/COS can't be applied efficiently.

Shanman

My boss is thick in the head. I have tried to convice him to change his way but he is thinking 5 years and he wants to retire. He is in cruse control and is against learning anything new.

At least I know that I am not the only one supporting a network running on a shoe string. I am always looking for other opportunities but right now I am just glad I got a job. You know what I mean?

Forsaken_GA

pham0329 wrote: »

IHas anyone actually ran into a looping issue at work?

Far, far too many times.

Forsaken_GA

ehnde wrote: »

No offense, but is your boss stupid? I've heard of people disabling STP but never understood why. Might as well be punching yourself in the face.

Convergence time and resources. You can get away with it in networks where your uplinks are layer 3 routed links instead of trunks. If no VLAN is ever going to span to another switch, then it can beneficial to disable spanning tree. It takes very careful design, and very careful practices (ie, disable your freaking unused ports) to get away with it. In a routed access layer model, you also have the benefit of not losing half your bandwidth because of blocking ports. Your routed uplinks can both be used, and can do equal cost load sharing.

So there are advantages to doing it, but most folks aren't capable of designing around the pitfalls, or maintaining the discipline to keep the environment in such a way that you don't need spanning tree. Integrating voice traffic into a data network, and the virtualization trend which favors a large layer 2 domain make this type of design impractical for the most part, however.

Shanman

From my understanding you don't have to loose your bandwidth if you use ether channels for your up links. You still get the benefit from from spanning tree but the links are seen as one logical link. This is how I understand it. Correct me if I am wrong.

Kelkin

or you can loadbalance vlans across the links.. or.. or .. or.. theres alot of options

but typically people who dont understand spanning tree leave it basic so one trunk is blocking while other is forwarding.

We could be here for days talking about spanning-tree design

Forsaken_GA

Shanman wrote: »

From my understanding you don't have to loose your bandwidth if you use ether channels for your up links. You still get the benefit from from spanning tree but the links are seen as one logical link. This is how I understand it. Correct me if I am wrong.

That doesn't provide full redundancy, as most platforms require you to do etherchannels to the same device. So while an etherchannel will protect against a single link failure, if I lose the entire upstream switch (or more likely, I reboot it as part of a scheduled maintenance window), I now no longer have connectivity.

That's why your access layer switches will generally be connected to at least two different switches. At layer 2, that gives you the possibility of a loop, so one of those links has to block. Whereas if those uplinks are layer 3, then they're seen as equal cost routes, so I can distribute load between them as well as maintain full redundancy.

With that being said, there are platforms out there that are capable of doing Multi-chassis Etherchannel, they usually require the upstream switches to be some kind of stack that presents itself as a single virtual switch rather than two distinct switches. However, switches which operate as a stack have other operational issues (split-brain on your core or distribution switches is not fun), so it's a pick your poison situation.

Forsaken_GA

Kelkin wrote: »

or you can loadbalance vlans across the links.. or.. or .. or.. theres alot of options

but typically people who dont understand spanning tree leave it basic so one trunk is blocking while other is forwarding.

We could be here for days talking about spanning-tree design

Yup, there are definitely ways to traffic engineer your spanning-tree instance, and honestly, most people don't have a busy enough network to see any advantage from a design which disables it. You have to really need the extra performance you get out of not having it running, and you have to be really, really good at this whole network thing to get away with it, and it's pretty rare for those two things to meet.

However, the restrictive nature of STP is spurring development of better layer 2 loop control technologies, like TRILL, which basically runs IS-IS and routes layer 2 like it's a link-state IP network, so all links are considered valid for traffic forwarding.

GT-Rob

Aside from loops you, tuning STP is a good skill to have. Imagine you have two switches connected via L2 trunks. Lets say since you only have 4 links, so you decide to make a port channel of 3 (for the bandwidth), with 1 as a "backup". How are you going to make the etherchannel be preferred?

Or say you have equal links and want to split the L2 traffic, some vlans on one link, some on the other. What would you do?



Yes loops also happen, but usually because of a stupid move in the first place.

MAC_Addy

When I worked at a school district, the kids realized that their whole school would go down if they created a loop.

But... I think it was actually the teachers that were doing so, because they'd see a blue cable on the floor and plug it in somewhere - argh!!

That's why I swapped out all the blue cables to red cables. It sounds silly, but when I did this I never had an issue again. People assume that a red cable means power, and they don't want to touch it.

Forsaken_GA

GT-Rob wrote: »

Aside from loops you, tuning STP is a good skill to have. Imagine you have two switches connected via L2 trunks. Lets say since you only have 4 links, so you decide to make a port channel of 3 (for the bandwidth), with 1 as a "backup". How are you going to make the etherchannel be preferred?

Or say you have equal links and want to split the L2 traffic, some vlans on one link, some on the other. What would you do?

Yes loops also happen, but usually because of a stupid move in the first place.

Again, I agree, there are some nice traffic engineering options, but the bottom line is that your layer 2 TE options are severely crippled compared to layer 3 TE options.

However, make no mistake about it, loop avoidance is not just a byproduct of STP. STP was specifically created as a loop prevention protocol (go read Radia Perlman's book Interconnections for it's full evolution). All the other features that allow traffic engineering are just bolt-on features.

With all that being said, I am not advocating turning off STP, I'm mostly just playing the side of the viewpoint that sees good in turning it off, since someone asked. I think turning off STP is a monumentally stupid move on most production networks, and I would only consider doing it on a network that I built myself from the ground up.

pham0329

GT-Rob wrote: »

Aside from loops you, tuning STP is a good skill to have. Imagine you have two switches connected via L2 trunks. Lets say since you only have 4 links, so you decide to make a port channel of 3 (for the bandwidth), with 1 as a "backup". How are you going to make the etherchannel be preferred?

Or say you have equal links and want to split the L2 traffic, some vlans on one link, some on the other. What would you do?



Yes loops also happen, but usually because of a stupid move in the first place.

We use local VLANs here rather than have them span across the network so that doesn't really apply. Even if we did have end-to-end VLANs, I don't think I would do any tuning of STP as we're not big enough to need to load balance our L2 links. Plus, I would imagine creating a network diagram would be a pain in the @ss at the point

P.S I get that STP is useful...but it doesn't make it any less boring to read!

Eildor

This is off-topic but... Forsaken_GA, how do you know so much?

Forsaken_GA

Eildor wrote: »

This is off-topic but... Forsaken_GA, how do you know so much?

Well, I'm a Network Engineer for a business unit of a Fortune 50 company, so I know a thing or two. I've also got somewhere in the area of 15 years of experience in IT.

Eildor

Forsaken_GA wrote: »

Well, I'm a Network Engineer for a business unit of a Fortune 50 company, so I know a thing or two. I've also got somewhere in the area of 15 years of experience in IT.

You obviously have a lot of knowledge and experience -- what advice would you give to those of us who are studying for certifications, but don't necessarily have experience just yet? What books would you recommend? Share some of your wisdom!

Again, I know this is off-topic but I'm sure a lot of people would appreciate your input

Forsaken_GA

Eildor wrote: »

You obviously have a lot of knowledge and experience -- what advice would you give to those of us who are studying for certifications, but don't necessarily have experience just yet? What books would you recommend? Share some of your wisdom!

Again, I know this is off-topic but I'm sure a lot of people would appreciate your input

It's really just a question of motivation and what you like. I like puzzles, I like figuring things out. So learning how everything fits together is appealing to me. If you watch House at all, I'm very much like that - The particulars are rarely important, it's the challenge that drives me. Things that I can't fix offend me. Without that kind of passion, it's hard to sustain the drive to learn everything that's required.

The other key is to recognize that you can never stop learning. Don't ever take anything at face value, go test it for yourself. If something doesn't behave the way you think it should, take the time to figure out why, instead of just hacking in a nasty solution.

For a reading list... yeah, there's alot. From a general life perspective, I highly recommend The Seven Habits of Highly Effective People by Stephen Covey. I also sincerely recommend The Total Money Makeover by Dave Ramsey, not just as a damn good way to manage your finances (which it is), but because it also teaches you to use your common sense. Far too many people take things at face value without bothering to put any thought into it themselves.

From a general IT perspective, I recommend The Practice of System and Network Administration, and Time Management for System Administrators, both by Tom Limoncelli. The former is a playbook on how an IT organization *should* be run (and you can make a hell of a drinking game by reading what the book recommends, and them comparing it to how your company actually does things). The latter is a very good tome on working in IT in general, not just for Sysadmins, as IT in general tends to be very interrupt driven, making time management a crucial factor in being as effective as possible.

From a general network perspective, Douglas Comer's Internetworking with TCP/IP is my personal recommendation, though The TCP/IP Guide, or the Stevens TCP/IP Illustrated books will serve as well. TCP/IP is at the heart of modern networking, and if you can't understand how it works, it impairs everything else. Radia Perlman's Interconnections, which I previously mentioned, gives a very good overview on Layer 2 principles.

From a Cisco networking perspective, both Routing TCP/IP volumes by Doyle are a must read. While it's Cisco slanted, it's also a very good treatise on layer 3 concepts and principles. I recommend Cisco LAN Switching by Kennedy Clark for learning how Layer 2 works on Cisco platforms, as Cisco fudges some rules, and has some proprietary features that alter layer 2 behavior when implemented.

That covers the basics, beyond that, it's up to you decide where your specific interests lie. Routing and Switching engineers don't necessarily need the same tomes as Security oriented or Voice oriented guys.

Beyond reading and getting hands on experience, I follow the old adage - By learning, you will teach. By teaching, you will learn. That's why I participate in forums like this. By teaching what I know to others, it helps me reinforce what I know, and sometimes the questions that folks ask force me to consider things from a different perspective, and I learn something. Or I don't know the answer to the question, so I have to go research it so I can answer it. The related experiences of others is absolutely invaluable, sometimes if only for an example of what *not* to do. Everyone is a potential well of knowledge, and should be exploited as such to the best of your ability. Just be sure to reciprocate and allow yourself to be exploited in turn.

Eildor

Forsaken_GA wrote: »

It's really just a question of motivation and what you like. I like puzzles, I like figuring things out. So learning how everything fits together is appealing to me. If you watch House at all, I'm very much like that - The particulars are rarely important, it's the challenge that drives me. Things that I can't fix offend me. Without that kind of passion, it's hard to sustain the drive to learn everything that's required.

The other key is to recognize that you can never stop learning. Don't ever take anything at face value, go test it for yourself. If something doesn't behave the way you think it should, take the time to figure out why, instead of just hacking in a nasty solution.

For a reading list... yeah, there's alot. From a general life perspective, I highly recommend The Seven Habits of Highly Effective People by Stephen Covey. I also sincerely recommend The Total Money Makeover by Dave Ramsey, not just as a damn good way to manage your finances (which it is), but because it also teaches you to use your common sense. Far too many people take things at face value without bothering to put any thought into it themselves.

From a general IT perspective, I recommend The Practice of System and Network Administration, and Time Management for System Administrators, both by Tom Limoncelli. The former is a playbook on how an IT organization *should* be run (and you can make a hell of a drinking game by reading what the book recommends, and them comparing it to how your company actually does things). The latter is a very good tome on working in IT in general, not just for Sysadmins, as IT in general tends to be very interrupt driven, making time management a crucial factor in being as effective as possible.

From a general network perspective, Douglas Comer's Internetworking with TCP/IP is my personal recommendation, though The TCP/IP Guide, or the Stevens TCP/IP Illustrated books will serve as well. TCP/IP is at the heart of modern networking, and if you can't understand how it works, it impairs everything else. Radia Perlman's Interconnections, which I previously mentioned, gives a very good overview on Layer 2 principles.

From a Cisco networking perspective, both Routing TCP/IP volumes by Doyle are a must read. While it's Cisco slanted, it's also a very good treatise on layer 3 concepts and principles. I recommend Cisco LAN Switching by Kennedy Clark for learning how Layer 2 works on Cisco platforms, as Cisco fudges some rules, and has some proprietary features that alter layer 2 behavior when implemented.

That covers the basics, beyond that, it's up to you decide where your specific interests lie. Routing and Switching engineers don't necessarily need the same tomes as Security oriented or Voice oriented guys.

Beyond reading and getting hands on experience, I follow the old adage - By learning, you will teach. By teaching, you will learn. That's why I participate in forums like this. By teaching what I know to others, it helps me reinforce what I know, and sometimes the questions that folks ask force me to consider things from a different perspective, and I learn something. Or I don't know the answer to the question, so I have to go research it so I can answer it. The related experiences of others is absolutely invaluable, sometimes if only for an example of what *not* to do. Everyone is a potential well of knowledge, and should be exploited as such to the best of your ability. Just be sure to reciprocate and allow yourself to be exploited in turn.

Thank you for your invaluable input. I think that I'm quite like yourself in the sense that I can't accept not being able to fix something, and I'm eager to learn more and adamant on actually knowing what I know (if you know what I mean ).

And I will check out those books for sure -- thank you, your advice is much appreciated.