«

Hello!
Does anybody know, which trunk-methods allow a spanning-tree instance per
VLAN???

a.) ISL
b.)802.1q
c.)both

c.) is correct. From my point of view a.) is correct, because 802.1q support
a spanning-tree instance for all VLANs. (There are different descriptionn in
e-books).

Thanks for comments

Ray

In article <bseq69$enp$00$>,
Raimond Alpers <> wrote:
oes anybody know, which trunk-methods allow a spanning-tree instance per
:VLAN???

:a.) ISL
:b.)802.1q
:c.)both

:c.) is correct. From my point of view a.) is correct, because 802.1q support
:a spanning-tree instance for all VLANs.

Cisco impliments a common extension to 802.1Q that allows per-VLAN
spanning trees.
--
Are we *there* yet??

"Walter Roberson" <> wrote in message
news:bsf1gk$ptp$...
> In article <bseq69$enp$00$>,
> Raimond Alpers <> wrote:
> oes anybody know, which trunk-methods allow a spanning-tree instance per
> :VLAN???
>
> :a.) ISL
> :b.)802.1q
> :c.)both
>
> :c.) is correct. From my point of view a.) is correct, because 802.1q
support
> :a spanning-tree instance for all VLANs.
>
> Cisco impliments a common extension to 802.1Q that allows per-VLAN
> spanning trees.

but the OP is right - that isnt in the 802.1Q definition - its an extension.

BTW - this sounds like a multi choice test Q - any one heard of this kind of
creative approach to certification that is so common being challenged? After
all, if the test doesnt use correct factual info, and company discounts for
resellers etc depend on the results (in my employers case this could run
into 7 digit numbers of $), there has to be a law suit in there at some
point......

Note that the cisco version of 802.1Q is compatible with some other varients
of multiple spanning tree on 802.1Q, but i dont know of any comprehensive
compatibility testing. And i have stumbled across some wierd interaction
issues.

BTW - there is another flavor now we have 802.1s / 802.1w spanning tree
extensions - which work differently to the 802.1Q extensions. Not an issue
if you stick to 1 manufacturer, but that never seems to be survive contact
with network changes and upgrades.

i have to admit that i usually try to design out spanning tree as i have had
so many problems with marginal stuff with this - CPU load, 1 way link loops,
unstable parameters, new root disrupting topology and so on. And the less
said about VTP the better.
> --
> Are we *there* yet??
--
Regards

Stephen Hope - remove xx from email to reply

["shope"]

| i have to admit that i usually try to design out spanning tree as i have had
| so many problems with marginal stuff with this - CPU load, 1 way link loops,
| unstable parameters, new root disrupting topology and so on. And the less
| said about VTP the better.

Amen, especially on the VTP part. We turn off VTP on all our Cisco
switches, after having had way too many problems with it.

Steinar Haug, Nethelp consulting,

According to the IEEE 802.1Q 1998 standard in clause 6.7: "This standard
defines a VLAN environment that operates over a single Spanning Tree."

However, at
http://www.cisco.com/en/US/tech/tk38...ocol_home.html it
says:
"Per VLAN Spanning Tree Plus (PVST+) provides the same functionality as PVST
using 802.1Q trunking technology rather than ISL. PVST+ is an enhancement to
the 802.1Q specification and is not supported on non-Cisco devices."

So it seems that the answer is that Cisco's implementation of 802.1Q, which
exceeds the standard, supports Per VLAN Spanning Tree, but the IEEE standard
does not.

Ron Bandes
CTT, CCNP, MCSE

"Raimond Alpers" <> wrote in message
news:bseq69$enp$00$...
> Hello!
> Does anybody know, which trunk-methods allow a spanning-tree instance per
> VLAN???
>
> a.) ISL
> b.)802.1q
> c.)both
>
> c.) is correct. From my point of view a.) is correct, because 802.1q
support
> a spanning-tree instance for all VLANs. (There are different descriptionn
in
> e-books).
>
> Thanks for comments
>
> Ray