Add VLAN to MetroE passthru trunk on 2960?

[pnicolette]

Will this extend our main site's local subnet to a new MetroE site? (Need sanity check.)

The main site is routed to a MetroE multipoint net. The router's MetroE interface emits mostly untagged traffic but also creates a dot1q VLAN 99 dedicated to one other site. This works.

Now suppose I put a 2960 between the router and the MetroE, with vtp disabled and both 2960 ports trunked nonegotiate. On the 2960 I create a new VLAN (1099) and assign an access-mode port to it.

Will the trunk to the MetroE from the 2960 now carry all three VLANs: native, 99 and 1099?

And...if I patch the 2960 access-mode port to an access port on my local LAN, will my local subnet now appear as VLAN 1099 on my MetroE? (Even though it is also connected to another interface of the router?)

[Edison Ortiz · Accepted solution]

Will the trunk to the MetroE from the 2960 now carry all three VLANs: native, 99 and 1099?

Yes.

That's why we recommend manual pruning on Metro-E facing interfaces to avoid Vlan leakage to remote sites.

And...if I patch the 2960 access-mode port to an access port on my local LAN, will my local subnet now appear as VLAN 1099 on my MetroE?

Not in the Metro-E cloud but other switches within your network connecting to the Metro-E can share Vlan 1099 in Layer 2, if that Vlan is also created in the remote switches.

Regards,

Edison

[pnicolette]

If you try this, please note:

Will the trunk to the MetroE from the 2960 now carry all three VLANs: native, 99 and 1099?

Yes.

But only if VLAN 99 is made active on the 2960.

In config mode:

vlan 99

set active

Paul

[Edison Ortiz]

Vlans are automatically active when they are created. I'm assuming this vlan was deliberately set to inactive after being configured on the 2960.

Regards

Edison

[pnicolette]

Hi Edison,

Apparently a non-default VLAN must be created/configured or activated on a switch before the switch will forward it between trunk ports, even if there's no need to access that vlan from this switch. Not necessarily obvious to everyone...it wasn't to me.

I may have mistakenly assumed that "vtp mode transparent" means that the switch will transparently forward any trunked vlans which originate outside it. Maybe it should???

I may also have misunderstood the original response advocating manual pruning. If specific action must be taken to permit a vlan to be forwarded on a trunk, why prune? There's an implicit "default deny"!

Best regards,

Paul

[Edison Ortiz]

Apparently a non-default VLAN must be created/configured or activated on a switch before the switch will forward it between trunk ports, even if there's no need to access that vlan from this switch. Not necessarily obvious to everyone...it wasn't to me.

Correct. If the switch is on the transit path, it must know about the Vlans between the 2 Edge switches - else the traffic for those Vlans will be dropped.

I may have mistakenly assumed that "vtp mode transparent" means that the switch will transparently forward any trunked vlans which originate outside it. Maybe it should???

Transparent disables VTP. VTP is used for Vlan management not for Vlan forwarding. BDPU will be the protocol to be used for Vlan forwarding.

I may also have misunderstood the original response advocating manual pruning. If specific action must be taken to permit a vlan to be forwarded on a trunk, why prune? There's an implicit "default deny"!

When enabling a switchport as trunk, all Vlans contained on the Database will automatically be in forwarding mode, not pruned. There isn't an implicit deny any like an ACL.

Regards,

Edison.

[pnicolette]

BDPU will be the protocol to be used for Vlan forwarding.

Spanning tree uses BPDUs to determine whether a particular interface goes into a forwarding state, but how do BPDUs determine whether a specific vlan will be forwarded from one trunk port to another? It seems to me that VTP has more impact on this because only vlans in the database get forwarded on trunks, and VTP can change the database.

When enabling a switchport as trunk, all Vlans contained on the Database will automatically be in forwarding mode, not pruned. There isn't an implicit deny any like an ACL.

Ahh - we use different standard configs. If, for security, stability and/or using vlans 1025-4096, your switches run "vtp mode transparent," the vlan database will be inactive. Then you must explicitly configure a vlan to have it trunked through, and pruning will be unnecessary. That's what I was trying to say :-).

[Edison Ortiz]

Spanning tree uses BPDUs to determine whether a particular interface goes into a forwarding state,

Per-Vlan STP BDPUs.

This protocol will determine if the Vlan will be forwarded or not via inter-switch links.

Type 'show spanning-tree' on any switch.

As stated, VTP is for Vlan management - in other words - propagation any modification on the Vlan database to other switches. It does not dictate if the Vlan traffic will be forwarded or blocked on a switchport.

__

Edison.

[pnicolette]

Agreed, per-vlan STP BPDUs determine forwarding/blocking. But if the switch doesn't have a vlan configured, it will block that vlan regardless of the BPDUs, right?

If the switch is on the transit path, it must know about the Vlans between the 2 Edge switches - else the traffic for those Vlans will be dropped.

So the vlan management protocol VTP can influence what vlans are passed between trunk ports, by letting the switch "know about the Vlans" or not. Reasonable?

[Edison Ortiz]

But if the switch doesn't have a vlan configured, it will block that vlan regardless of the BPDUs, right?

Correct.

So the vlan management protocol VTP can influence what vlans are passed between trunk ports, by letting the switch "know about the Vlans" or not. Reasonable?

VTP does not inform what Vlans will be forwarded or not. If the switch does not hold such Vlan, it will not be forwarded - simple. On this aspect, it's not VTP that is doing the drop but the lack of existence of the Vlan on the Vlan Database. It has nothing to do with VTP.

Regards

Edison.