Introduction
As you would be aware a switched network
creates one broadcast domain, similar to that of a VLAN powered network
where all nodes belonging to the same VLAN are part of the same
broadcast domain, receiving all broadcasts sent on their network.
The Broadcast And Unicast Problem In VLAN Networks
What we are about to see is how these
broadcasts can actually create problems by flooding the VLAN network
with unnecessary traffic, and depending on your network setup, this can
prove to be a huge problem. The reason for this is because the trunk
links interconecting your network switches will carry these broadcasts
to every switch in the network, regardless of which VLAN the broadcast
is intended for.
As shown and described, a host connected to a port configured for VLAN 2
on Switch 1 (first switch on the left), generates a network broadcast.
Naturally, the switch will forward the broadcast out all ports assigned
to the same VLAN it was received from, that is, VLAN 2.
In addition, the Catalyst switch will
forward the broadcast out its trunk link, so it may reach all ports in
the network assigned to VLAN 2. The
Root switch receives the broadcast through one of it's trunks and
immediately forwards it out the other two - towards Switch 2 & 3.
Switch 2 is delighted to receive the
broadcast as it does in fact have one port assigned to VLAN 2. Switch 3
however, is a different case - it has no ports assigned to VLAN 2 and
therefore will drop the broadcast packet it receives.
In this example, the bandwidth usage was
ineffecient because one broadcast packet was sent over all possible
trunk links, and was then dropped by Switch 3.
You might ask yourself 'So what's the big deal?'.
The problem here is small and can easily
be ignored... but consider a network of fifteen or more 12 port
switches (this translates to at least 210 nodes) and you can start to
appreciate how serious the problem can get. To make things worse (and
more realistic), consider you're using 24 port switches, then you're all
of a sudden talking about more than 300 nodes!
To further help understand how serious the problem gets, let's take a look at our example network below:
Here we have a medium sized
network powered by Cisco Catalyst switches. The two main switches up
the top are the VTP servers and also perform 3rd layer switching by
routing packets between the VLANs we've created.
Right below them you'll
find our 2950's Catalyst switches which are connected to the core
switches via redundant fiber trunk links. Directly below our 2950's are
our 2948 Catalyst switches that connect all workstations to the network.
A workstation connected to a
port assigned to VLAN 2 decided to send a network broadcast looking for
a specific network resource. While the workstation is totally unaware
of our network design and complexity, its broadcast is the reason all
our trunks will flood with unwanted traffic, consuming valuable
bandwidth!
Let's take a look at what happens:
We don't think describing
the above is actually required as the diagram shows all the information
we need and we're confident you will agree that we dealing with a big
problem:)
So how do we fix this mess ?
Keep reading on as you're about to learn........
The Solution: Enabling VTP Pruning
VTP Pruning as you might have already
guessed solves the above problem by reducing the unnecessary flooded
traffic described previously. This is done by forwarding broadcasts and
unknown unicast frames on a VLAN over trunk links only if the receiving
end of the trunk has ports in that VLAN.
Support For VTP Pruning
The VTP Pruning service is supported by
both VTP 1 and VTP 2 versions of the VTP protocol. With VTP 1, VTP
pruning is possible with the use of additional VTP message types.
When a Cisco Catalyst switch has ports
associated with a VLAN, it will send an advertisement to its neighboring
switches informing them about the ports it has active on that VLAN.
This information is then stored by the neighbors and used to decide if
flooded traffic from a VLAN should be forwarded to the switch via the
trunk port or not.
Note: VTP Pruning is disabled by default on all Cisco Catalyst switches and can be enabled by issuing the "set vtp pruning enable" command. If this command is issued on the VTP Server(s) of your network, then pruning is enabled for the entire management domain. |
When you enable VTP Pruning on your
network, all VLANs become eligible for pruning on all trunk links. This
default list of pruning eligibility can thankfully be modified to suite
your needs but you must first clear all VLANs from the list using the "clear vtp prune-eligible vlan-range" command and then set the VLAN range you wish to add in the prune eligible list by issuing the following command: "set vtp prune-eligible vlan-range" where the 'vlan-range' is the actual inclusive range of VLANs e.g '2-20'.
By default, VLANs 2–1000 are eligible
for pruning. VLAN 1 has a special meaning because it is normally used as
a management VLAN and is never eligible for pruning, while VLANs
1001–1005 are also never eligible for pruning. If the VLANs are
configured as pruning-ineligible, the flooding continues as illustrated
in our examples.
Summary
VTP Pruning can in fact be an
administrator's best friend in any Cisco powered network, increasing
available bandwidth by restricting flooded traffic to those trunk links
that the traffic must use to reach the destination devices.
At this point, we have also come to the
end of the first part of our VLAN presentation. As we are still working
on the second and final part of the VLAN topic, we hope these pages will
keep you going until it is complete.
1 comments:
high quality replica gucci sneakers, combining elegant style and cutting-edge technology, a variety of styles of high quality replica gucci mens sneakers, the pointer walks between your exclusive taste style.
Post a Comment