That would not be possible.
Think of it this way, 802.1q among other things is an encapsulation mechanism so is Fabricpath. You cannot pass frames between 2 disparate encapsulation techniques.

Similar Messages

Enabling ALL VLANs on a trunk link causes downstream hosts to intermittently fall off the network

In an effort to begin collapsing switches, I began to configure our two 3750g Core switches to Allow all VLANs to trunk to a downstream 6500.
The cores are HSRP-configured and are the root bridge priorities are set to match the HSRP active router correctly.
The trunk link that currently existed between the 3750 and the 6500 allowed only about 8 vlans, and the other day I removed the restriction to allow ALL VLANs 1-4096.
Then the next day, people started noticing servers not accessible and I investigated and noticed that they were intermittently failing ping replies. These servers were DOWNSTREAM from the 6500 two switches deep using trunk links as well.
One troubleshooting step I did was I pinged one of the HSRP IPs for the subnet the inaccessible server was on, got a reply from the gateway, and then I pinged the server again, and it replied!
Another behavior I noticed was that I was starting to have trouble telneting in to the the two switches downstream from the 6500. Sometimes I could telnet to one of them, other times I couldn't. These downstream switches are the ones that had the server ports for the servers that were intermittnetly dropping off the network. So at a time when I could session into one of these downstream switches I could ping the servers from there. THen their MACs would show up in the table and then I could ping them from anywhere. I would wait for five minutes for the MACs to age out and then low-and-behold the servers were no longer accessible from the user locations until pinged them from the switches they were on.
So, I gave up trying to fix, rolled back my trunk link betwen the 3750 and the 6500 to the few VLANs allowed as before, and then everything was happy again. I could ping all the servers, I could session in to all the downstream switches from the 6500.
Network topology: [3750-core]---TrunkLinkAllowedAll---[6500chassis]---trunklink---[3750-3-switchStack]----trunklink---[3750]
Any insights would be greatly appreciated
Thanks!

Thanks nkarthikeyan.
VTP transparent mode and pvst+ was definitely in place. I went ahead and did exactly what you said; the only thing that was different from what you said to do was the way I had allowing ALL VLANs on the trunk from Core to the 6500. I allowed only the needed VLANs on that trunk and all seems to be fine.
I still want to know why setting the trunk to allow 1-4094 would cause hosts to fall off the network and switch flooding to not work right. I did read some articles on the effects asymmetric routing can have on unicast flooding and perhaps that's the issue, since my core 3750 is configured with another core switch in an HSRP pair.

How many VLANs supported via MACsec VLAN-trunk link?

Hi,
Any one know how many VLANs maximum allowed across a MACsec link between two C6500 with Sup2Ts or between two N7K respectively?
As far as I know, C3750X has limitation of 8 VLANs, according to
•Cisco TrustSec enforcement is supported only on up to eight VLANs on a VLAN-trunk link. If there are more than eight VLANs configured on a VLAN-trunk link and Cisco TrustSec enforcement is enabled on those VLANs, the switch ports on those VLAN-trunk links will be error-disabled.
http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/15-0_2_se/configuration/guide/3750x_cg/trustsec.html
Thanks,
Cedar

Hi,
Any one know how many VLANs maximum allowed across a MACsec link between two C6500 with Sup2Ts or between two N7K respectively?
As far as I know, C3750X has limitation of 8 VLANs, according to
•Cisco TrustSec enforcement is supported only on up to eight VLANs on a VLAN-trunk link. If there are more than eight VLANs configured on a VLAN-trunk link and Cisco TrustSec enforcement is enabled on those VLANs, the switch ports on those VLAN-trunk links will be error-disabled.
http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/15-0_2_se/configuration/guide/3750x_cg/trustsec.html
Thanks,
Cedar

NAtive VLAN?what is the use of vlan?VLAN in trunk link?

what is the use of native VLAN in trunk links? where should i change native vlan from vlan1 to another?
what is the use of untagged native VLAN frame?

Hi,
On ethernet, you can connect more than one device to a port. So when you configure a port as trunk, it expects a vlan tag to arrive. But some times there are devices which dont have the capability to tag the packet and still they need to connect to network. So they can use native vlan to have connectivity. It is not a usual situation, but it helps on some situation where multiple devices connected on a trunk and not all have ability to send tagged frames. Hope this helps.
Please do remember to rate all useful posts.
Thanks,
Madhu

Why Native VLAN exists on a Trunk?

Basically, A Native VLAN carries untagged traffic on a trunk line.
A trunk line allows mutiple VLAN traffic ( tagged traffic). So Why Native VLAN exists on a trunk.
Why Native VLAN was created?
I'm pretty confused up with VLANs.

Hi,
The second question - why PC Network adapters support VLAN tags - is actually easier to answer :)
First of all, with regards to VLANs and frame tagging, there is actually nothing special to support on a network adapter! The VLAN tag itself is in fact stored in the payload of a tagged frame. Even to the most dumb network adapter, a tagged frame looks like any other - Destination MAC, Source MAC, EtherType (set to 0x8100), Payload (holding the rest of the VLAN tag, the original EtherType and the original Payload), and the FCS. Supporting VLANs and frame tags is possible on a purely software level. The fact that network adapters often do have hardware support for VLANs is related to performance reasons: With hardware VLAN support, the tagging, de-tagging, filtering and/or sorting frames based on the VLAN tag value is faster and it allows offloading these operations from the computer's CPU to the network card. However, even if the network adapter did not have any kind of VLAN support, the VLANs could still be implemented purely in the card's software driver.
Ordinarily, you would not see a common PC send and receive tagged frames. However, there are situations in which even a PC would send or receive a tagged frame. One of reasons is the presence of the Class-of-Service (CoS) bits in a VLAN tag. You surely know that basic Ethernet frame format does not include any kind of priority marking. There is no field in an Ethernet header that would allow you to indicate that this or that frame requires a preferential treatment. VLAN tags, on the other hand, have a 3-bit CoS field that allows you to indicate the priority of the tagged frame. Should a PC need to send a frame that needs to be explicitly marked as more important than others, it can be done by inserting a VLAN tag into this frame and setting the CoS field to a non-zero value (with 3 bits, the maximum CoS value is 7).
Another reason for a computer to send and receive tagged frames would be when the computer itself would be intentionally placed into multiple VLANs. For example, the router-on-a-stick performing inter-VLAN routing is not a concept just for dedicated hardware routers. For example, any computer running Linux can be used in place of a Cisco router to perform inter-VLAN routing. Just like on a Cisco router, you would configure the Linux with subinterfaces for each VLAN it should be able to route from and to, assign IP addresses, and voila - you have a cheap and powerful inter-VLAN router. Yet another reason for receiving and sending tagged frames on a computer would be virtualization: You could have a server that runs multiple virtual operating systems in VirtualBox, VMWare, Xen or some other virtualization solution, and you want each of these virtual PCs to have a "separate" network card so that they can not talk to each other when they communicate with the outside world. You would do this again by creating subinterfaces on the physical machine, and bridging the individual virtual PCs with unique subinterfaces so that each virtual PC gets its own subinterface onto which it is bridged. As a result, the communication of individual virtual PCs would be tagged on the physical link depending on what virtual machine was speaking.
So, while not exactly a typical situation for an ordinary office PC, it is nonetheless quite normal to see a computer being connected to a trunk port. This, however, is always done with the prior knowledge that the computer will indeed need to talk to several VLANs simultaneously and directly. Otherwise there's no need for that.
Regarding the native VLAN on trunks - well, this is a neverending debate. I wish the native VLAN was never invented but well, it's here so we have to fight with it. Often, it is explained as "the VLAN that will save you if you happen to connect a normal PC to a trunk", and you have asked quite correctly - why on Earth would I want to connect a normal PC to a trunk, if not for reasons stated above? And you would be perfectly right - you wouldn't. The reason for native VLANs is different. If you try to study the IEEE 802.1Q standard you will learn that it does not recognize the terms access port and trunk port. It has no distinction for these port types. Instead, 802.1Q considers each port to be possibly associated with multiple VLANs at once. One of these VLANs is called the Primary VLAN, its number (ID) is called the Primary VLAN ID (PVID), and this VLAN is considered to be the one that is always associated with the port and thus does not need to use tags. Any other VLAN that is in addition associated with the port obviously has to use tags to be distinguishable. From this viewpoint, a port that is associated just with its PVID would be what Cisco calls an access port, and a port that is associated with VLAN IDs other than just its PVID would be what Cisco calls a trunk port, with the PVID being the trunk's native VLAN ID.
So in the way IEEE defines VLANs and their usage, PVID (= native VLAN ID) is a property of each port, so any implementation that claims compatibility with 802.1Q has to implement the PVID. Cisco decided to have a twist on the understanding of VLANs, and came up with access ports (i.e. ports associated just with their PVID and no other VLAN ID) and trunk ports (i.e. ports associated with many VLAN IDs including PVID), and so each trunk port must have its PVID - and that is what we call native VLAN and why we need to at least support it - although we do not need to make use of the native VLAN on trunks.
Quite convoluted.
Best regards,
Peter

Difference between Trunk links and port channel

Hi
Can anyone please explain me the difference between the Trunk links and Ether channel ?

Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
As the other posters have already described, in Cisco parlance, a "trunk" is a link that carries VLAN tagged frames. (Note, Cisco has two technologies for these, ISL [old/proprietary] and IEEE 802.1Q [vendor independent].) An Etherchannel (also called a port-channel) is one logical link that includes one or more physical links. (Note, although Etherchannel can run across just one link, normally more than one link is configured. Older and most Cisco implementations support up to 8 links in one channel bundle. There's also multiple Cisco technologies that support Etherchannels, such as manual/PAgP[Cisco/old]/LACP[IEEE 802.3ad].)
Trunk links might also be configured on an Etherchannel link.

PVLAN types of Trunk Links

Hello Guys,
I made this post in my Blog and I want you to review it and correct it if you please.
http://cisco-discussions.blogspot.com/2013/08/private-vlans-and-its-different-types.html
PVLAN types of Trunk Links
The different types of PVLAN trunk links is based upon the required connection between switches the you want to connect. Here are some scenarios that you may want to implement and what types of PVLAN trunks you may use.
Scenario #1: Normal Trunk
You need to propagate PVLANs between two or more switches which all are supporting the PVLAN feature,
Here you will use the normal trunk link between the two switches and the Secondary PVLANs will pass through the trunk normally just like any other normal VLAN with a single Tag.
For example:
When PC1 in VLAN 201 on Switch A try to connect to PC4 in Vlan 201 on Switch B, its traffic will go through the trunk with Tag 201 but Switch B will ban this traffic because of the nature of isolated PVLAN which prevent PCs inside to connect each other.
When PC2 in VLAN 202 on Switch A try to connect to PC5 in Vlan 202 on Switch B, its traffic will go through the trunk with Tag 202 and Switch B will forward it to PC5 port based on its MAC address table.
When the router send traffic for PC5 it send traffic on the promiscuous trunk (will be discussed later) with Tag 100 and it will carried through the normal trunk between the two switches with also tag 100 untill it reach switch 2 then it will consult its CAM table and find that PC5 in Vlan 100 and also in Vlan 202.
Scenario #2:
Promiscuous Trunk
(This type of trunk is supported on Catalyst 4500 and higher switches)
You need to a switch configured with PVLAN with a router using a trunk link (Router-on-a-stick) and use this trunk for InterVLAN-Routing between the PVLANs and other Normal VLANs.
Here you have PCs into the secondaries PVLANs which need to connect with another PC3 in VLAN 50 which is a normal VLAN. As normal when you want to make interVLAN routing you may use Router-On-A-Stick model which uses a trunk link from the switch side and sub-interfaces from router side.
Because the usual Promiscuous port is an access port and can't carry more than one vlan which was the Primary PVLAN, Cisco made the Promiscuous trunk port to solve this scenario.
The Promiscuous trunk port translates the secondary VLAN Tag to the Primary VLAN tag to send traffic to the router to perform Inter-Vlan Routing.
For example:
PC1 into VLAN 12 need to connect with another PC3 in VLAN 50 which is a normal VLAN, traffic originated from PC1 into VLAN 12 will be broadcast to the Promiscuous trunk port with Tag 12 the it will translate the Tag to vlan 10 which the router knows it.
When the router find it with Tag 10, it will receive it on the sub-interface of vlan 10 and forward it based on its destination IP as normal case.
When the router receive the reply from PC3 in VLAN 50 and based on the destination IP, it will forward it through the sub-interface of vlan 10 to the switch.
When the switch receive it with Tag 10, it consults the MAC address table of vlan 10 to know which PC has that destination MAC because the MAC address table of vlan 10 contains all learned MACs for PCs in Primary and secondary VLANs (10,11,12).
Scenario #3:
Secondary PVLAN Trunk
(This type of trunk is supported on Catalyst 4500 and higher switches)
This trunk is sometimes called Isolated PVLAN trunk but on the switch configuration CLI it is called as above.
This trunk link type is used when you need to extend an Isolated PVLAN through a switch which doesn't support the PVLAN feature.
The problem here is that if we made the trunk between the 4500 & 2950 switches as a normal trunk, this trunk won't follow the rules of Isolated VLAN which states that no inter-hosts communication inside the isolated VLAN so PC2 can communicate PC1 through that normal trunk.
For the previous reson, Cisco made the Isolated trunk port for expanding an Isolated VLAN through a non-PVLAN cabaple switch with preserving the rules of Isolated VLAN.
Isolated trunk port translate the primary vlan tag into the isolated secondary vlan tag to be able to communicate with the non-PVLAN cabalple switch.
For example: 4 cases
PC4 from a normal VLAN 20 need to connect the PC3 on the 2950 switch.
The PC4 from VLAN 20 will send a normal traffic to the router and router will forward it through the promiscuous trunk port to VLAN 10 which is the primary VLAN as per the previous scenario#2.
the switch will receive this frame and consult its MAC address table to find the destination MAC.
let's suppose that it found it on the trunk with 2950 switch, then it will forward it to the 2950 switch and translate the Tag of 10 to 11 because the 2950 switch doesn't know VLANs except VLAN 11.
then the PC3 on 2950 switch receive it and reply on PC4 from vlanVLAN11 and when 4500 switch try to forward it to the router through the promiscuous trunk port, it will translate the tag to 10.
      2. PC1 need to connect with PC 3:
PC1 will send the traffic to the 4500 switch which has the MAC of PC3 into is MAC address table of VLAN 11 (the host MACs into secondary PVLAN associated with both its attached secondary PVLAN as well as the primary PVLAN).
the 4500 switch will ban this communication due to Isolated VLAN rules.
      3. PC3 need to connect with PC1:
PC3 will send the traffic to 2950 switch the 2950 switch after consulting its CAM table will forward it through the trunk with tag11.
When 4500 switch see the traffic with tag 11 the it will consult its CAM table for destination MAC which will be present on its CAM and this traffic will be banned.
If the 4500 switch doesn't know where is the destination MAC it will flood the traffic through the promiscuous port only because communication inside Isolated VLAN is prohibited.
     4. if PC2 need to communicate with PC3:
It can be done successfully through the 2950 switch because it doesn't support the private VLAN concept.
The solution here is to configure the ports on VLAN 11 on 2950 switch as a Cisco protected ports.
    This scenario is valid if you also need to extend A Community PVLAN but you don't need to do the Step     4 which is related to Protected Ports.
Conclusion of How Traffic go through different types of ports:
Access Ports:
Promiscuous ports: carry untagged traffic for Primary and Secondary PVLANs
Host Ports:
Isolated Ports: carry untagged traffic for Isolated PVLAN.
Community Ports: carry untagged traffic for Community PVLAN.
Protected Ports: it simulate as Isolated PVLAN but it is not related to PVLAN feature, this port is locally significant to the switch. Any protected port on a switch can't communicate at L2 to other Protected ports on the same switch, to communicate between two protected ports, it must be through L3 device.
Trunk Ports:
Normal Trunk: carry tagged traffic for all primary and secondary PVLANs and normal VLAN. Any traffic go through this trunk keeps the Tag of traffic without changing it.
Promiscuous Trunk: carry tagged traffic for only primary and normal VLANs. Any traffic sourced from secondaries PVLANs is go through this trunk using the primary PVLAN tag.
Secondary Trunk: carry tagged traffic for only secondary PVLANs. Any traffic sourced from primary & secondaries PVLANs is go through this trunk using the secondary PVLAN tag.
Another article will be posted soon or an update will be made to this article to illustrate the configuration of each type of these trunks.

Hi Khaled,
I came across this good article while trying to figure out how to extend PVLAN from a physical network into a vmware network running on a blade server that has an integrated switch that doesn't support PVLANs.
It looked like the isolated PVLAN trunk as you described it would be what I needed. I first started looking at this after reading somewhere that PVLAN support on a blade switch wasn't needed with the NEXUS 1000v. I have yet to verify that, but was thinking it may have to do with the isolated PVLAN trunk feature. Again, I haven't verified that it is supported on the 1000v.
Anyway, my question is with the below that you noted in your post. I haven't seen anywhere yet that says you can pass community PVLANs across the isolated trunk. The NEXUS 7000 document I read actually says you can't add community PVLANS to the trunk. The documentation that I have read says the mapped secondary VLANs can only communicate with permiscuous ports. Since it is actually called ISOLATED PVLAN trunk it would seem that it doesn't support community PVLANs. Do you have documentation on this being supported?
This is your note that I haven't been able to verify:
This scenario is valid if you also need to extend A Community PVLAN but you don't need to do the Step 4 which is related to Protected Ports.
Would placing the community VLANs in the normal VLAN list on the isolated PVLAN trunk maintain the PVLAN configuration?
VLAN 10 - primary
VLAN 11 - isolated
VLAN 12 - community
VLAN 20 - normal
Isolated trunk = Isolated VLAN = 11 mapped to Primary VLAN 10, VLAN 12 and VLAN 20 configured as normal VLANs on trunk.
Would traffic arriving on the trunk on VLAN 12 of the 4500 be able to communicate with the other devices in the community VLAN 12 and the router connected to the promiscuous trunk?
Thank you,
Mark

N5k Peer and Trunk Links

I have two Nexus 5020s that are connected together via 4 x Twinax cables. I want to set the switches up in a vPC domain. I know that I have to set up a vPC Peer link using the Twinax connection but what about the server traffic. Do I trunk these across the same peer links? Or would I be best using two of the links for a peer link and the other two as an Etherchannel trunk link for server vlans?

You can continue to use these links for the server vlan as well, there isn't any problem with that.
Let me know if you have any other questions
Chad

Mismatched MTU on Trunk Link

Hey folks!
I'm a bit confused and need some guidance. We have a 4510 connected to a Nexus 3064. Our SAN, server management NICs and server iSCSI NICs will be connecting to the Nexus. We wanted to use, or at least test, jumbo frames. Based on the research I've done, it seems like the Nexus 3064 is all or nothing when it comes to MTU - instead of doing per interface or per VLAN.
With that being said, my trunk port between the Nexus and 4510 is going to be mismatched... one end will have 1500 and the other will have 9000. All the jumbo frames will be isolated to the Nexus and won't traverse the trunk link. Is this OK? Will it cause any problems? Is there a better way to do this?
Thanks... please let me know if you need more info!
mitch

Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Mitch, NICs on the same wire can be configured to have different MTUs. The issue to watch for is one NIC sending a frame larger than the other NIC can receive. Unlike L3, L2's sender won't fragment, it will send the too big frames, and the receiver will drop them.

Undersize frame on 802.1Q trunk with extreme switch

i configure a 802.1Q trunk between 3750 and a summit7i extreme. The show controller ethernet-controller command show that the counter of undersize frame progress regularly. EDP on extreme is off for the ports, also for spanning-tree

Roger,
It sounds like it could be a duplex problem. A switch-to-switch connection should be able to run at the fastest speed that the ports have in common, and should be full duplex for maximum performance.
Undersize packets normally come from collisions in the form of fragments (undersize packets with bad CRC); there shouldn't be any collisions on a full duplex connection, though.
It could also be that if the Extreme switch is sending undersize packets with good CRC then maybe the software on the Extreme switch needs updating.
What kind of ports are you using to connect the Cisco Catalyst 3750 to the Extreme Summit7i? What speed and duplex does each side of the link report? Is one side set to autonegotiate, and the other set manually to a fixed speed and/or duplex? What's the distance between the ports? And the media being used: copper UTP, multimode fiber, or single-mode fiber?
If copper (RJ45 connector) on the Extreme switch, it could be to either a Gigabit-only Ethernet GBIC; or built-in autonegotiating 100/1000BASE-T, depending on the model number of the switch. On the Cisco switch, it could be 10/100 or 10/100/1000 depending on the switch model, or 1000-only if you're using the 1000BASE-T SFP.
If fiber (SC or MT-RJ connectors) on the Extreme switch, I don't recall whether their Gigabit-only fiber ports give you the option of what duplex you run. But the Cisco switch's Gigabit-only fiber ports always run in full duplex mode only.
Whatever ports you're using, the actual connection speed and duplex on each end of the switch-to-switch link need to match. Either both ends autonegotiate to matching values; or you need to manually set these values.
Here's a link that might also be useful:
Troubleshooting Switch Port and Interface Problems
http://www.cisco.com/warp/public/473/53.shtml
Hope this helps.

802.1q trunk b/w 8PoE switch integrated in 1861 CME

Hi,
I have to deploy cme7.0 (1861). Actually two 1861 routers are bought but only one of them act as cme while the 8PoE integrated switch of other 1861 is used. half of the IP phones are connected to the 8PoE integrated switch in CME (1861 router) while half of the phones are connected to 8PoE of 1861 (only 1861's PoE is used in this setup). i want to know whether i can cascade the two switches or in other words whether i can form a 802.1q trunk b/w these switches to carry the voice and data vlans.
Regards
Naresh Rathore

Yes, you can.

Trunk link on a router

How to configure a router interface to be a trunk link and route VLAN, VTP packets to different networks?

Hi,
you cannot have a same subnet IP to a multiple vlans, while creating vlans, each vlan should be on different subnet, may be i think you wanted to do VLSM(Variable Length Subnet Mask) in which where you can use a single network with multiple subnet.
eg.
interface FastEthernet0/0
no ip address
interface FastEthernet0/0.1
ip address 10.1.1.1 255.255.255.240
encapsulation dot1q 1
interface FastEthernet0/0.2
ip address 10.1.1.17 255.255.255.224
encapsulation dot1q 2
refer to this site for more understand about VLSM.
http://en.wikipedia.org/wiki/VLSM
hope this helps.
rate this post if ur cleared.

Is CE 500 Switch support 802.1q Trunk?

Dear All,
Is Cisco Express 500 switch support 802.1q trunk?
Also, all fastethernet port on CE500 will assign VLAN 10. I would like the switch to allow VLAN 20 and 30 to pass through the trunk? Is it possible?
Thanks.
C.K.

Yesh, set up the port role to switch to make it a trunk.
Unfortunately, the CE500 series switches cannot be managed through a CLI - you have to use CNA.
Hope that helps - pls rate the post if it does.
Paresh

Dedicated VLAN ID's on trunk ports

I was reading the SAFE:Security Blueprint for Enterprise Networks. This document addresses in its "Switches are targets" section on Page 6 that "Always use a dedicated VLAN ID for all trunk ports"...
I am trying to understand this concept fully.
If I consider my trunk ports, most are physical fiber "links" that interconnect the switches. Some trunk links connect Distribution L to Access L; some Distribution to Core.
Where do I put the VLAN ID on thes?? Should I translate this to mean that on Gig0/0 on SW.1 i place this interface in VLAN 23 and on the switch on the other end of the link I also place the Gig0/0 in VLAN 23 as well??
Also I am not sure why this helps secure the switch. Can someone pls assist. I am grateful.

Hi,
This is not actually the VLAN pruning.This is just specifically allowing some vlans on the trunk ports and removing other unwanted vlans.
Prunning works in a diff way and it will save the bandwidth on the trunk links by prunning the unwanted broadcast on the trunks for a particular vlan if no host is active on that vlan on a particular switch. I.e If you dont have any active host on a vlan on a particular switch and if there is a broadcast on that vlan which will come over the trunk so if no host is active that broadcast is prunned on the trunk where no host is active on the switch.
HTH,
-amit singh

Trunk links

I have several switches connected to a backbone switch, I have created a new vlan on the server switch and it has propagated to the switches plugged in to the backbone, but anything not directly plugged into the backbone cannot see the vlan, do I need to set trunk links between the other switches ?? it wont take anything down whilst I do this will it ?
please help

Hi,
Yes you need to configure trunks between your switches to propagate VTP information.
I believe spanning-tree will reconverge when you enable trunking on your uplinks for each VLAN that is being trunked which will mean an outage as the VLANs transition through the STP states
HTH
PJD

FabricPath vlan on 802.1q Trunk link

Similar Messages

Maybe you are looking for