Configuring VTP Mode
Use the set vtp mode {server|client|transparent} to define the Catalyst's VTP mode. You have the option to specify the VTP mode when you specify the VTP domain name. If you do not specify a VTP mode, server is defined as the default.
Example 12-6 shows output for configuring a Catalyst into the client mode. Note the highlighted portion of the output indicating that the Catalyst is now configured as a client.
Example 12-6 Setting VTP Mode to Client
Console> (enable) set vtp mode client VTP domain wally modified Console> (enable) show vtp domain Domain Name Domain Index VTP Version Local Mode Password -------------------------------- ------------ ----------- ----------- ---------- wally 1 2 client - Vlan-count Max-vlan-storage Config Revision Notifications ---------- ---------------- --------------- ------------- 10 1023 40 enabled Last Updater V2 Mode Pruning PruneEligible on Vlans --------------- -------- -------- ------------------------- 10.0.0.1 disabled disabled 2-1000 Console> (enable)
As illustrated in the section on decoding VTP subset advertisements, all VLAN information sent over the wire is cleartext. Anyone with an analyzer package can capture the VTP frame and decode it. A system attacker can use this information to disrupt your network. For example, an attacker can fabricate a false subset advertisement with a higher configuration revision number and delete the VLANs in your management domain.
As a security option, you can specify a password for VTP subset advertisements. If you specify a password, the Catalyst uses this as a key to generate an MD5 hash. Whenever a source Catalyst issues a subset advertisement, it calculates the hash for the advertisement message and uses the password as the key. VTP includes the hash result in the subset advertisement. The receiving Catalyst must also have the same password locally configured. When it receives the subset advertisement, it generates a hash using its password and compares the result with the received message. If they match, it accepts the advertisement as valid. Otherwise, it discards the subset advertisement.
You can configure a password using the command set vtp passwd passwd.
Tracking VTP Activity
The command show vtp statistics is a particularly useful command for tracking VTP activity such as the number and type of VTP messages sent and received from a Catalyst. Example 12-7 shows typical show vtp statistics output.
Example 12-7 show vtp statistics Screen
Cat-A > (enable) show vtp statistics VTP statistics: summary advts received 5392 subset advts received 16 request advts received 3 summary advts transmitted 5280 subset advts transmitted 7 request advts transmitted 0 No of config revision errors 0 No of config digest errors 0 VTP pruning statistics: Trunk Join Trasmitted Join Received Summary advts received from non-pruning-capable device -------- --------------- ------------- --------------------------- 1/1 0 0 0 1/2 0 0 0 Cat-A > (enable)
Notice the highlighted line in Example 12-7. It lists the number of incidents where the received MD5 hash did not match the locally calculated value. This can indicate either a corruption of the frame from a physical layer problem or a security issue. If the problem stems from a physical layer issue, you might anticipate that other frames also have problems. If you do not experience other transmission errors, there might be an attack where the attacker is attempting to spoof a Catalyst and corrupt your management domain.
VTP: A Good or Bad Thing?
One of the primary advantages of VTP is its capability to distribute VLANs to other Catalysts to simplify your configuration tasks. As a result of VTP, you do not need to type the set vlan command nearly as often as you do without it. You only need to create the VLAN once in the management domain rather than at each switch. But, you still need to do a set vlan command to add the ports that will be assigned to that VLAN on a given switch. Deleting a VLAN in a domain is also easy because you only need to do it at one location.
However, there are some disadvantages to VTP and trunking that you need to consider as discussed in the sections that follow.
VLAN Table Deletion
Ironically, one of the disadvantages stems directly from the simplified configuration feature of VTP. Consider the network in Figure 12-13 where multiple Catalysts interconnect in a management domain.
Figure 12-13. A Multiple Catalyst Network and VTP Synchronization Problem
If you make any changes to the VLAN list on any server in the network, the change gets distributed to the other Catalysts in the management domain. But what happens if you make changes while the network is partitioned? For example, assume in Figure 12-13 that the trunk link between Cat-C and Cat-D servers isolate the three Catalysts on the left from the three on the right. All Catalysts should have the same VTP configuration revision number, N. See Table 12-4 for VLAN table and VTP configuration revision numbers for these steps.
Table 12-4. Synchronization Problem with Partitioned Catalysts
Step
Event
Left Catalysts
Right Catalysts
VLANs
Rev.#
VLANs
Rev.#
1
Initial state
1, 2, 3, 4, 5
N
1, 2, 3, 4, 5
N
2
Partition network between Cat-C and Cat-D
1, 2, 3, 4, 5
N
1, 2, 3, 4, 5
N
3
Create VLAN 10 in left portion
1, 2, 3, 4, 5, 10
N+1
1, 2, 3, 4, 5
N
4
Delete VLAN 5 in right portion
1, 2, 3, 4, 5, 10
N+1
1, 2, 3, 4
N+1
5
Restore link between Cat-C and Cat-D
1, 2, 3, 4, 5, 10
N+1
1, 2, 3, 4
N+1
6
Delete VLAN 5 in left portion
1, 2, 3, 4, 10
N+2
1, 2, 3, 4, 10
N+2
While the network is partitioned, an administrator on the left creates a new VLAN thinking, "When the network recovers, the new VLAN will get distributed to the Catalysts on the right." At the same time, an administrator on the right makes a VLAN change by deleting a VLAN. This administrator thinks like the first administrator and expects VTP to propagate the deletion when the network recovers.
When the trunk link between Cat-C and Cat-D is restored, both Catalysts issue VTP summary advertisements announcing a configuration revision update of N+1. Catalysts in each half compare the number with their own values, see that they match, and never issue a VTP advertisement request. This leaves the two portions with unsynchronized VLAN tables as shown in Step 5. To resynchronize the tables, the administrator needs to enter a VLAN modification as in Step 6, which forces an increment in the revision number. The Catalyst where the configuration change was made then issues a VTP summary advertisement and a VTP subset advertisement. This information gets distributed to the other Catalysts in the network synchronizing the VLAN tables.
A more severe case can occur when two normally isolated portions merge. Suppose the three Catalysts on the left belong to one corporate department (Engineering) that doesn't like the corporate division using the three Catalysts on the right (Marketing). The Catalysts remain isolated until a higher level manager mandates that the two divisions need to connect their networks. It is decided ahead of time by the manager that the two groups will change their domain names to a new third name so that they all belong to the same management domain. The two groups now have a configuration as shown in Step 1 of Table 12-5. (The configuration revision number was arbitrarily selected for this example.)
Table 12-5. A Catastrophic Merger of VTP Domains
Step
Event
Left Catalysts
Right Catalysts
VLANs
Rev.#
VLANs
Rev.#
1
Initial state
1, 2, 3, 4, 5
32
1, 10, 20, 30
57
2
Merge domains
1, 10, 20, 30
57
1, 10, 20, 30
57
The big moment arrives when the two groups shake hands and join the networks. What happens? Disaster. Because the Marketing side has a higher configuration revision number than the Engineering side, VTP updates the Engineering VLAN tables to match the Marketing side. All of the Engineering users that were attached to VLANs 2, 3, 4, and 5 now attach to ports in suspended mode. Marketing just torpedoed the Engineering LAN! Now engineering is really mad at Marketing.
Tip
Before merging different domains, be sure to create a super set of VLANs in both domains to prevent VLAN table deletion problems. Make sure that all partitions have a complete list of all VLANs from each partition before joining them together.
Similarly, if you have a Catalyst dedicated to you for playing around, and you attach it to the production network, you might delete the VLANs in your production network if you are not careful. Make sure that you either clear config all, change the VTP domain name, or put it in transparent mode before attaching it to the production network.
Tip
Another real-world situation exists that could delete VLANs in your network. If you replace a failed Supervisor module on a Catalyst configured in the server mode, you run the possibility of deleting VLANs if the new module has a higher configuration revision number than the others in the domain. Be sure to reset the configuration revision number on the new module before activating it in the system.
Broadcast Flooding
Another issue involves trunks and VTP. Chapter 8 described trunks and the syntax to establish trunks. Whenever you enable a trunk, the trunk, by default, transports traffic for all VLANs. This includes all forwarded and flooded traffic. If you have a VLAN that generates a high volume of flooded traffic from broadcasts or multicasts, the frames flood throughout the entire network. They even cross VTP management domains. This can have a significant impact on your default management VLAN 1. Refer to Chapters 15, "Campus Design Implementation," and 17, "Case Studies: Implementing Switches," for discussions on cautions and suggestions regarding the management VLAN. In Figure 12-14, a Catalyst system has trunk and access links interconnecting them. PC-1 in the system attaches through an access link assigned to VLAN 2. This particular station generates multicast traffic for video distribution on VLAN 2. The network administrator dedicated VLAN 2 to this application to keep it separate from other user traffic. Although the administrator managed to keep any of the multicast traffic from touching Cat-A and Cat-B, it still touches all of the other Catalysts in the network, even though VLAN 2 is not active in Domain 2. Why doesn't the multicast traffic bother Cat-A and Cat-B? Cat-A and Cat-B do not see the traffic from PC-1 because all of the links to these units are access links on different VLANs.
Figure 12-14. Flooding in a Multiple Domain Network
There are methods of controlling the distribution of flooded traffic throughout the network. These methods include the features of VTP pruning to control flooding, and modifications to the multicast behavior through Cisco Group Management Protocol (CGMP). VTP pruning is discussed in the section in this chapter, "VTP Pruning: Advanced Traffic Management." Details on controlling multicast with CGMP is described in Chapter 13, "Multicast and Broadcast Services."
Excessive STP
A related issue with VTP and trunking is the universal participation in Spanning Tree by all Catalysts in the network for all VLANs. Whenever you create a new VLAN, the Catalysts create a new instance of Spanning Tree for that VLAN. This feature, Per-VLAN Spanning Tree (PVST), allows you to optimize the Spanning Tree topology individually for each VLAN. All Catalysts, by default, participate in PVST. But as in the case of flooding traffic in the network, each additional instance of Spanning Tree creates additional Layer 2 background traffic. The additional traffic comes from the BPDUs distributed for each VLAN's instance of Spanning Tree. Not only does this add traffic to each link, it also requires more processing by each Catalyst. Each Catalyst must generate and receive hello messages at whatever interval is specified by the hello timer, which is every two seconds by default. And, each Catalyst must calculate a Spanning Tree topology for each VLAN whenever there is a Spanning Tree topology change. This, too, temporarily consumes CPU cycles with a complex Spanning Tree topology.
Bottom line: Controlling VTP in Large Networks
In large networks, these issues multiply and can develop into situations making you want to disable trunking, VTP, or other aspects of VLANs. Clearly, trunking remains as a necessary element of networking life. It is not practical to deploy a large network without trunks because of the number of resources that you consume with multiple access links. Therefore, trunks remain. However, as previously mentioned, we have methods of minimizing some of the negative side effects of trunking.
VTP is also an ever present part of networking with Catalysts whenever you enable trunks. You cannot disable VTP (the closest thing to an exception is Catalysts configured in transparent mode). Therefore, you need to be very careful in how you partition your management domains, who can modify the domains, what components listen to VTP, as well as in how many Catalyst switches are defined as VTP Servers in the network to limit the possibility of mistakes made by an administrator that might cause a major change in other Catalyst switches. As discussed previously, a major concern when deploying large Catalyst networks is the risk of VLAN table deletion. Intended to simplify configuration issues, it can turn against you if not carefully managed.
Tip
If you have a fairly static network where you are not adding or deleting globally significant VLANs, consider using the transparent mode to prevent erroneous actions from deleting your VLANs. However, setting up a unit in transparent mode does increase your administrative burden.
VTP V2
With the introduction of Token Ring switching in the Catalyst, Cisco updated the VTP protocol to version 2. By default, Catalysts disable VTP version 2 and use version 1. As an administrator, you need to select which version of VTP to use and ensure that all Catalysts in the VTP management domain run the same version.
VTP version 2 assists Token Ring VLANs by ensuring correct Token Ring VLAN configuration. If you plan on doing Token Ring switching, you MUST use VTP version 2 so that processes like DRiP operate. Chapter 3, "Bridging Technologies" describes DRiP in more detail.
Tip
VTP version 2 adds functionality over VTP version 1, but uses a modified form of the protocol. Version 1 and version 2 cannot coexist in the same management domain. All Catalysts in a management domain must run a homogenous VTP version to function correctly.
If you enable VTP version 2 on a Catalyst, all VTP version 2 capable Catalysts in the management domain automatically enable VTP version 2. Not all Catalysts support VTP version 2, nor do all releases of the Supervisor engine software. If you elect to use VTP version 2, ensure that all Catalysts in the domain are VTP version 2 capable.
Support for Token Ring is not the only feature added in VTP version 2, but it is the principle one.
To enable VTP version 2, use the command set vtp v2 enable.
Verify that you correctly changed it with the show vtp domain command.
Example 12-8 shows a Catalyst configured for VTP version 2 and the corresponding output from the show vtp domain command. Note the warning whenever you attempt to enable version 2 that all Catalysts in the management domain must support version 2. When you enable version 2, all Catalysts in the management domain enable version 2. Note in Figure 12-8 that there are two columns related to the VTP version. One column is titled VTP Version and the other V2 Mode. VTP Version identifies what version of VTP your code supports, but does not indicate what is currently in use. Even if you use VTP version 1, this value still shows a 2 because you have the possibility of enabling version 2. The other column on the other hand, V2 Mode, indicates what VTP version you currently enabled. If you have the default version 1 enabled, then this column indicates disabled as seen in Figure 12-6.
Example 12-8 Configuring a Catalyst for VTP Version 2
Console> (enable) set vtp v2 enable This command will enable the version 2 function in the entire management domain. All devices in the management domain should be version2-capable before enabling. Do you want to continue (y/n) [n]? y VTP domain wally modified Console> (enable) show vtp domain Domain Name Domain Index VTP Version Local Mode Password -------------------------------- ------------ ----------- ----------- ---------- wally 1 2 server - Vlan-count Max-vlan-storage Config Revision Notifications ---------- ---------------- --------------- ------------- 10 1023 1 enabled Last Updater V2 Mode Pruning PruneEligible on Vlans --------------- -------- -------- ------------------------- 10.0.0.1 enabled disabled 2-1000 Console> (enable)
EAN: N/A
Pages: 223