Options

Spanning Tree and VTP

odysseyeliteodysseyelite Member Posts: 504 ■■■■■□□□□□
So im reading and setting up STP and VTP.

I'm curious do I need to setup VTP trunks on my redundent links so VTP work when when STP changes the ports from blocking to listening?

SW1 FE 0/11 is connected to SW2's FE 0/1. Trunking is setup. I also have SW1 Gi0/1 connected to Gi0/1.

It seems to work, as I can run a ping test pull the FE cable and it does not fail.
Currently reading: Start with Why: How Great Leaders Inspire Everyone to Take Action

Comments

  • Options
    EildorEildor Member Posts: 444
    If you have multiple VLANs then I would imagine the ports would need to be trunking... otherwise you wouldn't be getting any more VTP updates? I'd have thought you wouldn't be able to ping to VLANs either? Someone please correct me if I'm wrong.
  • Options
    EildorEildor Member Posts: 444
    What VLAN is the device you are pinging in? VLAN 1?
  • Options
    Forsaken_GAForsaken_GA Member Posts: 4,024
    VTP isn't involved in the spanning tree calculations, at least, not directly.

    There's a few different concepts at work here, and they're not necessarily interdependent.

    STP - takes any link into consideration, and blocks off redundant links to avoid a loop. This is regardless of link type (trunk, access, whatever)

    Trunk link - carries information for more than one vlan over the link. If you just connect two ports together, only the nodes that reside in that vlan on each side will be able to communicate with each other. With trunk links, multiple vlans can communicate with each other between switches on the same link (not between vlans however, that requires routing)

    For example - sw1 and sw2 are connected via fa0/1 on each side. fa0/1 is in vlan 1. This link would allow all ports in vlan1 on sw1 to communicate with all ports in vlan1 on sw2. if sw1 and sw2 have a vlan2, and they wanted to communicate, then the switches would need a second link to each other in vlan2. And the same if they had vlan3. In other words, without trunking, the switches need 1 link between them per vlan that wants to communicate.

    if I use a trunk link instead, than vlan 1 and 2 and 3 on sw1 could communicate to vlan 1 and 2 and 3 respectively on sw2, using one link, instead of 3.

    VTP - propagates vlan information across trunk links. *only* across trunk links. It's not directly involved in STP. All it does is basically, the switch configured as the VTP server says 'hey guys, I have these vlans, you should probably have them to', and the VTP clients then see those vlans and then create them without invovlement from the administrator. The reason why this is desireable is because the vlan must be defined on every switch that wants to communicate on that vlan. For example, above, with sw1 and 2. Let's say I'm trunking vlan 1, 2, and 3, but vlan 3 isn't defined on sw2. The trunk will still carry vlan3 traffic, but until sw2 defines vlan3, it'll just drop the traffic. You're not required to use VTP to do this, you can define the vlan manually and then traffic will flow back and forth across the link, VTP just makes administration easier. If you have 200 switches, and you need to add a vlan to all of them, it's easier to go define it on the switch acting as the VTP server than on every single switch.

    Trunk ports interact with STP like any other port. If you have two trunk links to upstream switches, one of them will block, one of them will forward. if you've enabled VTP, that means one of them will forward VTP messages over the trunk, one of them won't. If the forwarding link drops out, the blocking link transitions to forwarding and VTP advertisements go out over that instead.

    The other thing to keep in mind is that VTP is not like a routing protocol, if the VTP server goes away, the VTP clients don't lose their vlan information, it's not stateful, it's closer to a replicated database than a routing protocol, it only makes updates as directed, otherwise it maintains the information it has indefinitely.
Sign In or Register to comment.