TCPmag.com
http://tcpmag.com/
http://tcpmag.com/rss
Oct. 16, 2007
Editor: Gladys Rama (grama 1105media.com)
------------------------------------------------------------
------------
THIS ISSUE SPONSORED BY:
- CCNA: The exam isn’t the only thing that’s changed.
http://in
fo.101com.com/default.asp?id=43904
- Building a Successful PKI: Best Practices
http://in
fo.101com.com/default.asp?id=43849
- Free Trial of Symantec Backup Exec 11d
http://in
fo.101com.com/default.asp?id=43861
------------------------------------------------------------
------------
IN THIS ISSUE OF TCPmag.com:
1. Q&A: Spanning-Tree and Multiple Active Uplinks
2. What's New on TCPmag.com
3. Interesting Employment in Washington, D.C. and Georgia
************************************************************
************
SPONSOR: CCNA: The exam isn’t the only thing that’s
changed.
************************************************************
************
New material, and a more challenging exam have taken the
intense
CCNA curricula to a new level of difficulty. To ensure that
you
are fully prepared to tackle 640-802 CCNA, we’ve built an
exclusive
3-step program, including pre-class eLearning, hands-on
instructor-led
classroom training, and post-class access to our live labs.
Click here & Save $300 today.
http://i
nfo.101com.com/default.aspx?id=43904
************************************************************
************
1. Q&A: Spanning-Tree and Multiple Active Uplinks
Send your toughest Cisco technical questions to editortcpmag.com
with the subject line "Attn: Scott."
Scott,
All of our access-layer switches have two uplink ports back
to the
core/distribution switch in our network. We occasionally
experience
some congestion or delays in certain VLANs of the network,
but
nothing regular or ongoing.
My boss has started looking at VoIP systems and is telling
us to
start making both uplinks active at the same time. I keep
showing
him the "show spanning-tree" output and talking
about spanning-tree
loops that may occur but he insists that other people can
make it work.
Is there something about spanning-tree I'm not getting? I
thought
loops were bad and spanning-tree prevented loops. Help!
-- Joe
------------------------------
Joe,
Never fear! You're right -- loops are bad and
spanning-tree's job is
to avoid loops.
But on the other hand, your boss is right, too. You CAN have
multiple
active uplinks simultaneously. We just have to change our
rules a
little bit -- or our perspective, anyway. (A Corona
commercial is
coming to mind here: "Change your latitude.")
So, let's think about what you have going on here. Since you
use
"core/distribution switch" in the singular sense,
I'll assume that
you have a single-core switch that all of your access
switches report
back to. First, I do hope that this core switch has remained
the
"root" of your spanning tree topology; it'll make
life much simpler!
(This is why the deities have invented the spanning-tree
priority commands.)
Assuming that's the case, we'll move on to what you have
now. You
have access-layer switches with two links back to the root
bridge.
When the spanning-tree process attempts to figure out the
best path
back to the root bridge, it has to look at both links.
First, it looks at spanning-tree cost to get back. Assuming
your
access-layer switches are directly connected to the root
bridge, the
received cost will be 0. But they'll each add in whatever
the cost
of the attached link is locally. In regular 802.1D (and
PVST/PVST+)
spanning-tree, 100M links will have a cost of 19 and 1G
links will
have a cost of 4.
If there's an obvious winner here, that's the root port.
Chances are,
though, we don't play around with these values. In the grand
scheme
of things, spanning-tree is often seen as "magic"
that happens in
the background -- and nobody thinks about it until something
goes
bad. So in the event we haven't changed anything and the
costs are
equal, we next look at received bridge-ID. Well, if both
ports are
connected to the same root switch, the received ID should be
identical.
So that part being equal, as well, we'll look at the
port-specific
information. Received port-priority can be one method, port
cost is
another. If both of those are left alone, simple port ID
(each port
has a different ID number) will tell us who wins.
That was a long-winded way of explaining WHY you elect a
single root
port and then your non-root, non-designated ports are left
in a
blocking state -- which is what you've already observed,
anyway.
So, let's move on to the more entertaining part: How do we
change
those rules or perspectives? Part of it just has to do with
how we're
designing our network.
First, if we use Layer 3 ports, there's one option. This
actually
removes spanning-tree from the equation and allows us to
play with
routing protocols to make decisions for us. Many people do
this
because of the convergence speed of IGP routing protocols.
Depending
on what routing protocol you're using (recommended are
either EIGRP
or OSPF for the enhanced controls), you can simply play with
metrics
of different routes in order to have some routes preferred
over one
path and other routes over the other path.
Let's say, then, that you're not going to be allowed to do a
major
rearrangement of your network in order to convert the world
to Layer
3. Well, a simple answer is to go to each of your trunked
ports and
use the "switchport trunk allowed" command set.
This will limit
which VLANs can or cannot traverse any particular link.
>From spanning-tree's perspective, it will simply reduce
the number
of possible paths to only a single choice per VLAN. Much
simpler
decisions and much nicer load-sharing there, but absolutely
zero
redundancy or failover.
On that same note of splitting things up, we can make
changes at
Layer 2 as well. Review that election process we talked
about for
ideas of what to change. Now, think about making the changes
on a
per-VLAN basis so some VLANs elect to go one way, and others
a
different way.
If you're using PVST+, you'll use the "spanning-tree
vlan" command
set. If you're running MST (which bundles multiple VLANs
into
instances), then you'll use the "spanning-tree
mst" command set.
The changes are identical, though. "Spanning-tree vlan
# cost" and
"spanning-tree mst # cost" will both manipulate
the spanning-tree
cost of a link, but they'll manipulate it only for specific
VLANs
or MST instances.
Remember, cost is a locally affected decision (or downstream
if you
have other switches). Port priority can influence a directly
connected peer switch's decision.
So you have some choices along the way, but the best thing
to do is
to use the output of "show spanning-tree" to see
what the effect
actually is.
Some related commands to think about:
- Spanning-tree mode pvst (This is the default.)
- Spanning-tree mode rapid-pvst (This will decrease the
convergence
time as well as making convergence dynamic. This is much
better than
the older uplinkfast/backbonefast configurations.)
- Spanning-tree mode mst (Rapid spanning-tree automatically
comes
with this.)
Whatever mode you choose, make sure to select the same on
all of your
switches, and make sure to make any changes like this during
a
maintenance window. You'll have traffic interruption. In
addition,
if you can't get to all of your devices in a timely fashion,
you may
also have some ports end up in an errdisabled state due
to inconsistencies.
In my opinion, the best way to make this change is if you
can telnet
into ALL of your switches at once. Type in the
"spanning-tree mode"
command of your choice (without hitting "enter"
yet), then, starting
at the points furthest away (e.g., access switches that your
own PC
is not connected to), start hitting "enter." That
way, any
interruptions shouldn't affect your connectivity. It's kind
of like
painting yourself into a corner.
If you choose to use MST, you'll also need to configure the
instances.
An instance is simply a collection of VLANs to influence. So
if you
wanted VLANs 10, 20 and 30 to take one particular path
through the
network, then make them an instance by themselves.
Again, here, whatever choices you make, make them consistent
across
the paths these VLANs exist! Instance 1 on one switch should
be the
same collection of VLANs as on another switch.
Spanning-tree mst configuration
Instance 1 vlan 10,20,30
By default, all VLANs belong to instance 0, so no further
definitions
are required if you only need two instances. (Again, the
show
commands will help verify things). Then once you make your
choice for
how to influence the path selection process, just be sure to
use
"spanning-tree vlan" for the PVST modes and
"spanning-tree mst" for
the MST mode you've selected.
So now you know that both you and your boss were correct!
When you're
implementing voice networks, it's highly recommended that
you take
time to understand your Layer 2 configuration in detail, and
make
changes such as this in order to have the best path results,
while
still allowing convergence in any case of link failure.
One other idea to think about is testing prior to
implementation.
In larger environments, we call this "Proof of Concept
Testing," and
some places have entire labs mimicking their infrastructure
in order
to test out changes in technology without irritating too
many users.
Many companies, though, don't have scads of equipment lying
around
with no other purpose, and that makes things a little more
difficult.
Testing in a live network can often lead to irritated users
and,
occasionally, shortened careers. If you can, test things
out! Develop
a test plan, put the equipment together and create your own
scenario.
Now, as I'm writing this, it's dawned on me that I have the
ability
to offer some solutions down this line as well. Frequently,
CCIE
candidates rent rack time of equipment in order to test out
their
CCIE lab scenarios (we REALLY don't want that strange stuff
on live
networks!), but we can use the same equipment to test
anything we want.
In the CCIE world, our pods contain somewhere around eight
(or more)
routers and four switches which are all Layer 3-capable. You
could
use this same pod of equipment to create your own Proof of
Concept
test for your own network, and at least go through all of
the commands
and show/debugs to prove that things worked.
I've arranged for some special discounts for TCPmag.com
readers to do
just that (or CCIE lab studies). When you call the sales
folks for
Proctor Labs (go to http://www.proctorlabs.com
and click on Live
Chat) and mention the promo code "TCPMAG" when you
purchase four
rack sessions, you'll get one free. That's a nice 20 percent
off to
test things out, just for being loyal readers here!
Make yourself feel better. Make your boss feel better. Have
all the
answers that you need prior to rolling things out on a live
network!
For more information, check out:
- Configuring STP
http://tinyurl.com/29u44w
- Configuring MSTP
http://tinyurl.com/2hp2nc
- Spanning-Tree MST Configuration
http://tinyurl.com/2fpe7z
- Proctor Labs
http://www.proctorlabs.com
Hope that helps,
-- Scott
Scott Morris, quadruple CCIE, JNCIE and all-around
Uber-Geek, can often
be seen traveling around the world consulting and delivering
CCIE
training. He has recently stepped up as VP of Curriculum
Development
for IPexpert and will oversee a new consulting practice. For
more
information on him check out http://www.ipexpert.com.
Send your questions for this column to editortcpmag.com
with the subject line "Attn: Scott."
Miss a Q&A? Go online to http://tcpmag.com/qanda/
To comment on this Q&A, go to:
http://tcpmag.com/qanda/article.asp?editorialsid=391
************************************************************
************
SPONSOR: Free Report: Is Outsourcing PKI Best?
************************************************************
************
Learn the security and operational issues of implementing
and managing
internal public key infrastructures (PKI). Properly
implemented PKIs
require a lot of new knowledge within the organization and
processes
that must be met with strict and formal structures. For this
reason,
this paper argues that it may be best to outsource PKI
requirements.
Read it today!
http://in
fo.101com.com/default.asp?id=43849
************************************************************
************
2. What's New on TCPmag.com
NEWS: "Juniper's NAC Attack"
Cisco Systems Inc. didn't invent network access control
(NAC), but it
certainly helped take NAC mainstream. As a result, its
competitors
have had to scramble to catch up. Take archrival Juniper
Networks,
which earlier this month updated its own NAC-like offering,
Juniper
Unified Access Control (UAC).
http://tcpmag.com/news/article.asp?EditorialsID=1275
NEWS: "Microsoft, Cisco To Bump Heads in Enterprise
Telephony?"
Believe it or not, Microsoft has been an
uncharacteristically benign
force in the enterprise PBX space -- a segment in which
Cisco is also
a notable competitor. That could soon change, and Cisco --
among
others vendors -- should start to gird itself for
competition.
http://tcpmag.com/news/article.asp?editorialsid=1276
RSS FEEDS ON TCPMAG.COM
If you're running an RSS client, then consider signing up
for feeds
from TCPmag.com. You'll automatically be notified when new
content
is posted. Learn more here: http://tcpmag.com/rss/
------------------------------------------------------------
------------
3. Interesting Employment in Washington, D.C. and Georgia
Job postings courtesy of Monster.com.
BAE SYSTEMS, SYSTEMS ANALYST
Position Type: Full time
Location: Washington, D.C.
Salary: Not specified
Experience: 5 to 10 years
Desired Education: CCNA
The systems analyst will be responsible for troubleshooting
and
maintaining a VHF radio network and providing support to
government
users. Must have experience with testing equipment and
telecommunications. Government clearance required.
Relocation
assistance provided.
To learn more, visit:
http://jobview.monster.com/getjob.asp?JobID=63965901
-----------------------------
DACHSER TRANSPORT OF AMERICA, SYSTEM AND INFRASTRUCTURE
ADMINISTRATOR
Position Type: Full time
Location: Atlanta, Ga.
Salary: Not specified
Experience: 2 to 5 years
Desired Education: Associate's degree, CCNP, CCNA, MCSE,
MCP
Responsibilities include maintaining the company's VPN and
WAN;
overseeing backup and recovery initiatives; and supporting
Exchange
2003, Windows Server 2000 and Windows Server 2003.
Experience with
Cisco firewall/concentrator, active directory and Veritas
backup
software required.
To learn more, visit:
http://jobview.monster.com/getjob.asp?JobID=63986711
************************************************************
************
SPONSOR: Wii Contest: Free Trial of Symantec Backup Exec
11d
************************************************************
************
Download Symantec Backup Exec 11d evaluation and you will be
entered into a drawing for one of three Nintendo(R) Wii
Systems.
Backup Exec provides cost-effective, high-performance, and
certified
disk-to-disk-to-tape backup and recovery – including
continuous data
protection for Exchange, SQL, file servers and
workstations.
Try it now, you could win!
http://in
fo.101com.com/default.asp?id=43861
************************************************************
************
FREE MAGAZINE OFFERS
Subscribe now to our free monthly magazines:
Redmond Developer News magazine
https://subscribe.1105pubs.com/sub/RW?WP=NEW
FREE&TC=1&PC=MK5
Redmond magazine
https://subscribe.1105pubs.com/sub/MI?WP=NEWF
REE&TC=1&P=TCP
MORE NEWSLETTERS
We cover Enterprise Windows news, certification, security
updates,
SQL, Java, SOA, virtualization and more. To review the
entire
list and subscribe, click here:
https://newsletters.1105pubs.com/nl/URMG.do?pc=R07NL
Encourage your peers to excel!
Please forward this newsletter to any IT professional.
************************************************************
************
To learn how you can sponsor a future edition of this
newsletter,
contact Matt Morollo at (508) 532-1418 or
e-mail mmorollo1105media.com
Contact the editorial staff at editortcpmag.com
Newsletter problems: RED1105service.com
TCPmag.com
Redmond Media Group
16261 Laguna Canyon Road, Suite 130
Irvine, CA 92618-3608
Phone 949-265-1520
************************************************************
************
UNSUBSCRIBE OR CHANGE E-MAIL ADDRESS:
https://newsletters.1105pubs.com/nl/URMGf.do?e=nesstosharedlog.com
************************************************************
************
To review our Privacy Policy, visit our Web site at
http://www.1105
media.com/privacy.aspx
Copyright 2007 1105 Media Inc. TCPmag.com News may
only be redistributed in its unedited form. Written
permission
from the editor must be obtained to reprint the information
contained within this newsletter. Contact: editortcpmag.com
|
