Senior Acquisitions Editor: Kenyon Brown Development Editor: Kim Wimpsett
Yüklə 22,5 Mb. Pdf görüntüsü
|
- Bu səhifədəki naviqasiya:
- VLAN Trunking Protocol (VTP)
- FIGURE 15.1
- So, When Do I Need to Consider Using VTP
- Spanning Tree Protocol (STP)
|
no switchport trunk native vlan 1w6d: %SPANTREE-2-UNBLOCK_CONSIST_PORT: Unblocking FastEthernet0/15 on VLAN0004. Port consistency restored. Now our trunk link is using the default VLAN 1 as the native VLAN. Just remember that all switches on a given trunk must use the same native VLAN or you’ll have some serious management problems. These issues won’t affect user data, just management traffic between switches. Now, let’s mix it up by connecting a router into our switched network and configure inter-VLAN communication.
Cisco created this one too. The basic goals of VLAN Trunking Protocol (VTP) are to manage all configured VLANs across a switched internetwork and to maintain consistency throughout that network. VTP allows you to add, delete, and rename VLANs—information that is then propagated to all other switches in the VTP domain. Here’s a list of some of the cool features VTP has to offer: Consistent VLAN configuration across all switches in the network VLAN trunking over mixed networks, such as Ethernet to ATM LANE or even FDDI Accurate tracking and monitoring of VLANs Dynamic reporting of added VLANs to all switches in the VTP domain Adding VLANs using Plug and Play Very nice, but before you can get VTP to manage your VLANs across the network, you have to create a VTP server (really, you don’t need to even do that since all switches default to VTP server mode, but just make sure you have a server). All servers that need to share VLAN information must use the same domain name, and a switch can be in only one domain at a time. So basically, this means that a switch can share VTP domain information with other switches only if they’re configured into the same VTP domain. You can use a VTP domain if you have more than one switch connected in a network, but if you’ve got all your switches in only one VLAN, you just don’t need to use VTP. Do keep in mind that VTP information is sent between switches only via a trunk port. Switches advertise VTP management domain information as well as a
configuration revision number and all known VLANs with any specific parameters. But there’s also something called VTP transparent mode. In it, you can configure switches to forward VTP information through trunk ports but not to accept information updates or update their VLAN databases. If you’ve got sneaky users adding switches to your VTP domain behind your back, you can include passwords, but don’t forget—every switch must be set up with the same password. And as you can imagine, this little snag can be a real hassle administratively! Switches detect any added VLANs within a VTP advertisement and then prepare to send information on their trunk ports with the newly defined VLAN in tow. Updates are sent out as revision numbers that consist of summary advertisements. Anytime a switch sees a higher revision number, it knows the information it’s getting is more current, so it will overwrite the existing VLAN database with the latest information. You should know these four requirements for VTP to communicate VLAN information between switches: The VTP version must be set the same The VTP management domain name of both switches must be set the same.
One of the switches has to be configured as a VTP server. Set a VTP password if used. No router is necessary and is not a requirement. Now that you’ve got that down, we’re going to delve deeper into the world of VTP with VTP modes and VTP pruning.
Figure 15.1 shows you how a VTP server will update the connected VTP client’s VLAN database when a change occurs in the VLAN database on the server.
FIGURE 15.1 VTP modes Server This is the default mode for all Catalyst switches. You need at least one server in your VTP domain to propagate VLAN information throughout that domain. Also important: The switch must be in server mode to be able to create, add, and delete VLANs in a VTP domain. VLAN information has to be changed in server mode, and any change made to VLANs on a switch in server mode will be advertised to the entire VTP domain. In VTP server mode, VLAN configurations are saved in NVRAM on the switch. Client In client mode, switches receive information from VTP servers, but they also receive and forward updates, so in this way, they behave like VTP servers. The difference is that they can’t create, change, or delete VLANs. Plus, none of the ports on a client switch can be added to a new VLAN before the VTP server notifies the client switch of the new VLAN and the VLAN exists in the client’s VLAN database. Also good to know is that VLAN information sent from a VTP server isn’t stored in NVRAM, which is important because it means that if the switch is reset or reloaded, the VLAN information will be deleted. Here’s a hint: If you want a switch to become a server, first make it a client so it receives all the correct VLAN information, then change it to a server—so much easier!
So basically, a switch in VTP client mode will forward VTP summary advertisements and process them. This switch will learn about but won’t save the VTP configuration in the running configuration, and it won’t save it in NVRAM. Switches that are in VTP client mode will only learn about and pass along VTP information—that’s it!
Here’s a scenario for you. Bob, a senior network administrator at Acme Corporation in San Francisco, has about 25 switches all connected together, and he wants to configure VLANs to break up broadcast domains. When do you think he should start to consider using VTP? If you answered that he should have used VTP the moment he had more than one switch and multiple VLANs, you’re right. If you have only one switch, then VTP is irrelevant. It also isn’t a player if you’re not configuring VLANs in your network. But if you do have multiple switches that use multiple VLANs, you’d better configure your VTP server and clients, and you better do it right! When you first bring up your switched network, verify that your main switch is a VTP server and that all the other ones are VTP clients. When you create VLANs on the main VTP server, all switches will receive the VLAN database. If you have an existing switched network and you want to add a new switch, make sure to configure it as a VTP client before you install it. If you don’t, it’s possible—okay, highly probable—that your new little beauty will send out a new VTP database to all your other switches, effectively wiping out all your existing VLANs like a nuclear blast. No one needs that! Transparent Switches in transparent mode don’t participate in the VTP domain or share its VLAN database, but they’ll still forward VTP advertisements through any configured trunk links. They can create, modify, and delete VLANs because they keep their own database—one they keep secret from the other switches. Despite being kept in NVRAM, the VLAN database in transparent mode is actually only locally significant. The whole purpose of transparent mode is to allow
remote switches to receive the VLAN database from a VTP Server configured switch through a switch that is not participating in the same VLAN assignments. VTP only learns about normal-range VLANs, with VLAN IDs 1 to 1005; VLANs with IDs greater than 1005 are called extended-range VLANs and they’re not stored in the VLAN database. The switch must be in VTP transparent mode when you create VLAN IDs from 1006 to 4094, so it would be pretty rare that you’d ever use these VLANs. One other thing: VLAN IDs 1 and 1002 to 1005 are automatically created on all switches and can’t be removed. VTP Pruning VTP gives you a way to preserve bandwidth by configuring it to reduce the amount of broadcasts, multicasts, and unicast packets. This is called
links that actually must have the information. Here’s what this means: If Switch A doesn’t have any ports configured for VLAN 5 and a broadcast is sent throughout VLAN 5, that broadcast wouldn’t traverse the trunk link to Switch A. By default, VTP pruning is disabled on all switches. Seems to me this would be a good default parameter. When you enable pruning on a VTP server, you enable it for the entire domain. By default, VLANs 2 through 1001 are pruning eligible, but VLAN 1 can never be pruned because it’s an administrative VLAN. VTP pruning is supported with both VTP version 1 and version 2. By using the show interface trunk command, we can see that all VLANs are allowed across a trunked link by default: S1#
Port Mode Encapsulation Status Native vlan Fa0/1 auto 802.1q trunking 1 Fa0/2 auto 802.1q trunking 1 Port Vlans allowed on trunk Fa0/1 1-4094 Fa0/2 1-4094 Port Vlans allowed and active in management domain Fa0/1 1
Fa0/2 1 Port Vlans in spanning tree forwarding state and not pruned Fa0/1 1 Fa0/2 none S1# Looking at the preceding output, you can see that VTP pruning is disabled by default. I’m going to go ahead and enable pruning. It only takes one command and it is enabled on your entire switched network for the listed VLANs. Let’s see what happens: S1#
config t S1(config)# int f0/1 S1(config-if)# switchport trunk ? allowed Set allowed VLAN characteristics when interface is in trunking mode native Set trunking native characteristics when interface is in trunking mode pruning Set pruning VLAN characteristics when interface is in trunking mode S1(config-if)# switchport trunk pruning ? vlan Set VLANs enabled for pruning when interface is in trunking mode S1(config-if)# switchport trunk pruning vlan 3-4 The valid VLANs that can be pruned are 2 to 1001. Extended-range VLANs (VLAN IDs 1006 to 4094) can’t be pruned, and these pruning- ineligible VLANs can receive a flood of traffic. Configuring VTP All Cisco switches are configured to be VTP servers by default. To configure VTP, first you have to configure the domain name you want to use. And of course, once you configure the VTP information on a switch, you need to verify it. When you create the VTP domain, you have a few options, including setting the VTP version, domain name, password, operating mode, and pruning capabilities of the switch. Use the vtp global configuration mode command to set all this information. In the following example, I’ll set the S1 switch to vtp server , the VTP domain to Lammle , and the VTP password to todd
: S1#
config t S1#(config)# vtp mode server Device mode already VTP SERVER. S1(config)#
Changing VTP domain name from null to Lammle S1(config)#
Setting device VLAN database password to todd S1(config)#
VTP Password: todd S1(config)#
VTP Version : 2 Configuration Revision : 0 Maximum VLANs supported locally : 255 Number of existing VLANs : 8 VTP Operating Mode : Server VTP Domain Name : Lammle VTP Pruning Mode : Disabled VTP V2 Mode : Disabled VTP Traps Generation : Disabled MD5 digest : 0x15 0x54 0x88 0xF2 0x50 0xD9 0x03 0x07 Configuration last modified by 192.168.24.6 at 3-14-93 15:47:32 Local updater ID is 192.168.24.6 on interface Vl1 (lowest numbered VLAN interface found) Please make sure you remember that all switches are set to VTP server mode by default, and if you want to change and distribute any VLAN information on a switch, you absolutely must be in VTP server mode. After you configure the VTP information, you can verify it with the show
vtp status command as shown in the preceding output. The preceding switch output shows the VTP Version, Configuration Revision, Maximum VLANs supported locally, Number of existing VLANs, VTP Operating Mode, VTP domain, the VTP domain, and the VTP password listed as an MD5 Digest. You can use show vtp password in privileged mode to see the password. Troubleshooting VTP You connect your switches with crossover cables, the lights go green on both ends, and you’re up and running! Yeah—in a perfect world, right? Don’t you wish it was that easy? Well, actually, it pretty much is—without VLANs, of course. But if you’re using VLANs—and you definitely should be—then you need to use VTP if you have multiple VLANs configured in your switched network. But here there be monsters: If VTP is not configured correctly, it (surprise!) will not work, so you absolutely must be capable of troubleshooting VTP. Let’s take a look at a couple of configurations and solve the problems. Study the output from the two following switches: SwitchA#
sh vtp status VTP Version : 2 Configuration Revision : 0 Maximum VLANs supported locally : 64 Number of existing VLANs : 7 VTP Operating Mode : Server VTP Domain Name : Lammle VTP Pruning Mode : Disabled VTP V2 Mode : Disabled VTP Traps Generation : Disabled SwitchB#
VTP Version : 2 Configuration Revision : 1 Maximum VLANs supported locally : 64 Number of existing VLANs : 7 VTP Operating Mode : Server VTP Domain Name : GlobalNet VTP Pruning Mode : Disabled VTP V2 Mode : Disabled VTP Traps Generation : Disabled So what’s happening with these two switches? Why won’t they share VLAN information? At first glance, it seems that both servers are in VTP server mode, but that’s not the problem. Servers in VTP server mode will share VLAN information using VTP. The problem is that they’re in two different VTPdomains. SwitchA is in VTP domain Lammle and SwitchB is in VTP domain GlobalNet. They will never share VTP information because the VTP domain names are configured differently. Now that you know how to look for common VTP domain configuration errors in your switches, let’s take a look at another switch configuration: SwitchC#
sh vtp status VTP Version : 2 Configuration Revision : 1 Maximum VLANs supported locally : 64 Number of existing VLANs : 7 VTP Operating Mode : Client VTP Domain Name : Todd VTP Pruning Mode : Disabled VTP V2 Mode : Disabled VTP Traps Generation : Disabled Here’s what will happen when you have the preceding VTP configuration: SwitchC(config)# vlan 50 VTP VLAN configuration not allowed when device is in CLIENT mode. There you are just trying to create a new VLAN on SwitchC and what do you get for your trouble? A loathsome error! Why can’t you create a VLAN on SwitchC? Well, the VTP domain name isn’t the important thing in this example. What is critical here is the VTP mode. The VTP mode is client, and a VTP client cannot create, delete, or change VLANs, remember? VTP clients only keep the VTP database in RAM, and that’s not saved to NVRAM. So, in order to create a VLAN on this switch, you’ve got to make the switch a VTP server first. So to fix this problem, here’s what you need to do: SwitchC(config)# vtp mode server Setting device to VTP SERVER mode SwitchC(config)#
SwitchC(config-vlan)# Wait, we’re not done. Now take a look at the output from these two switches and determine why SwitchB is not receiving VLAN information from SwitchA: SwitchA#
sh vtp status VTP Version : 2 Configuration Revision : 4 Maximum VLANs supported locally : 64 Number of existing VLANs : 7 VTP Operating Mode : Server VTP Domain Name : GlobalNet VTP Pruning Mode : Disabled VTP V2 Mode : Disabled VTP Traps Generation : Disabled SwitchB#
VTP Version : 2 Configuration Revision : 14 Maximum VLANs supported locally : 64 Number of existing VLANs : 7 VTP Operating Mode : Server VTP Domain Name : GlobalNet VTP Pruning Mode : Disabled VTP V2 Mode : Disabled VTP Traps Generation : Disabled You may be tempted to say it’s because they’re both VTP servers, but that is not the problem. All your switches can be servers and they can still share VLAN information. As a matter of fact, Cisco actually suggests that all switches stay VTP servers and that you just make sure the switch you want to advertise VTP VLAN information has the highest revision number. If all switches are VTP servers, then all of the switches will save the VLAN database. But SwitchB isn’t receiving VLAN information from SwitchA because SwitchB has a higher revision number than SwitchA. It’s very important that you can recognize this problem. There are a couple ways to go about resolving this issue. The first thing you could do is to change the VTP domain name on SwitchB to another name, then set it back to GlobalNet, which will reset the revision number to zero (0) on SwitchB. The second approach would be to create or delete VLANs on SwitchA until the revision number passes the revision number on SwitchB. I didn’t say the second way was better; I just said it’s another way to fix it! Let’s look at one more. Why is SwitchB not receiving VLAN information from SwitchA? SwitchA#
VTP Version : 1 Configuration Revision : 4 Maximum VLANs supported locally : 64 Number of existing VLANs : 7 VTP Operating Mode : Server VTP Domain Name : GlobalNet VTP Pruning Mode : Disabled VTP V2 Mode : Disabled VTP Traps Generation : Disabled SwitchB#
VTP Version : 2 Configuration Revision : 3 Maximum VLANs supported locally : 64 Number of existing VLANs : 5 VTP Operating Mode : Server VTP Domain Name : VTP Pruning Mode : Disabled VTP V2 Mode : Disabled VTP Traps Generation : Disabled I know your first instinct is to notice that SwitchB doesn’t have a domain name set and consider that the issue. That’s not the problem! When a switch comes up, a VTP server with a domain name set will send VTP advertisements, and a new switch out of the box will configure itself using the advertisement with the received domain name and also download the VLAN database. The problem with the above switches is that they are set to different VTP versions—but that still isn’t the full problem. By default, VTP operates in version 1. You can configure VTP version 2 if you want support for these features, which are not supported in version 1: Token Ring support—Hmmm…doesn’t seem like much of a reason to go to version 2 today. Let’s look at some other reasons. Unrecognized Type-Length-Value (TLV) support—A VTP server or client propagates configuration changes to its other trunks, even for TLVs it is not able to parse. The unrecognized TLV is saved in NVRAM when the switch is operating in VTP server mode. Version-Dependent Transparent Mode—In VTP version 1, a VTP transparent switch inspects VTP messages for the domain name and version and forwards a message only if the version and domain name match. Because VTP version 2 supports only one domain, it forwards VTP messages in transparent mode without inspecting the version and domain name. Consistency Checks—In VTP version 2, VLAN consistency checks (such as checking the consistency of VLAN names and values) are performed only when you enter new information through the CLI or SNMP. Consistency checks are not performed when new information is obtained from a VTP message or when information is read from NVRAM. If the MD5 digest on a received VTP message is correct, its information is accepted. Wait! Nothing is that easy. Just set SwitchA to version 2 and we’re up and running? Nope! The interesting thing about VTP version 2 is that if you set one switch in your network (VTP domain) to version 2, all switches would set their version to 2 automatically—very cool! So then what is the problem? SwitchA doesn’t support VTP version 2, which is the actual answer to this question. Crazy! I think you can see that VTP will drive you to drink if you’re not careful! Okay, get a coffee, expresso or Mountain Dew and hold onto your hats—
it’s spanning tree time! Spanning Tree Protocol (STP) Spanning Tree Protocol (STP) achieves its primary objective of preventing network loops on layer 2 network bridges or switches by monitoring the network to track all links and shut down the redundant ones. STP uses the spanning-tree algorithm (STA) to first create a topology database and then search out and disable redundant links. With STP running, frames will be forwarded on only premium, STP-chosen links.
The Spanning Tree Protocol is a great protocol to use in networks like the one shown in Figure 15.2 .
Yüklə 22,5 Mb. Dostları ilə paylaş:
|