dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
2
share rss forum feed


rsaturns

join:2004-12-06
Beaverton, OR
reply to Badger3k

Re: How to take down a network

And no offense, but not doing something because you don't get paid OT is stupid. Do what is needed regardless of when it's needed and try to work in comp time if you are really bothered by it.
I have to second this. I'm about to kick off a 30+ hour upgrade here at work that I've spent months planning. Unfortunately I can only go as fast as the systems. Will I get OT? No, but being salary gives you negotiation power. I fully expect some comp time in my future and management has no problem with that.

And yes STP is your friend implement it now or die under Layer 2 loops for the rest of your life. So many people fear Layer 2 and I don't know why, it's very simple and solves so many problems.
--
»vinfotech.blogspot.com


tubbynet
reminds me of the danse russe
Premium,MVM
join:2008-01-16
Chandler, AZ
kudos:1

said by rsaturns:

And yes STP is your friend implement it now or die under Layer 2 loops for the rest of your life. So many people fear Layer 2 and I don't know why, it's very simple and solves so many problems.

because it can fail *spectacularly* even when configured properly. the issue is all about scalability and how to ensure that l2 domains don't grow and that the convergence is quick after if-status change.
given the anemic cpus that are put into most desktop switches, its possible for stp bpdu's to get lost/dropped if there is too much activity on the network. proper pruning and vlan scaling, along with stp mode choice can go a long way in helping -- but at the end of the day -- the best way to prevent stp issues is to remove it from the network altogether.

campus networks should be l3 to the access-layer. very few (if any) applications require l2 reachability for end-hosts to function.

data-center networks should be kept in pods, with redundancy if possible. traffic to/from those pods should be routed to core. pod size should be kept as appropriate. stretched l2 requirements inside of a d/c should be provided by technologies such as vpls or otv -- and not pure stp links. mcec should be used as appropriate (or trill implementations by $vendor_of_choice).

q.
--
"...if I in my north room dance naked, grotesquely before my mirror waving my shirt round my head and singing softly to myself..."