A similar standards-based VLAN management protocol for IEEE 802.1Q trunks is GARP VLAN Registration Protocol (GVRP), a Generic Attribute Registration Protocol (GARP) application.
The GARP and GVRP protocols are defined in the IEEE 802.1D and 802.1Q (clause 11) standards. GVRP allows switches to exchange VLAN configuration information between them, and supports pruning to limit the extent of unnecessary broadcast and unknown unicast traffic.
Note: Multiple Registration Protocol (MRP) was introduced as the replacement for GARP with the IEEE 802.1ak amendment. The 2 GARP applications below were also modified to use MRP. GMRP was replaced with Multiple MAC Registration Protocol (MMRP) and GVRP was replaced with Multiple VLAN Registration Protocol (MVRP).
VTP is organized into management domains – areas with common VLAN requirements.
A switch can belong to only 1 VTP domain. Switches in different VTP domains do not share VLAN info. Switches in a VTP domain advertise VTP advertisements that consist of several attributes to their domain neighbors; eg: the information about the VTP management domain, VTP revision number, known VLANs, and specific VLAN parameters.
VTP advertisements are sent out all active ISL or IEEE 802.1Q trunking interfaces.
A switch must be configured to operate in one of the VTP modes to participate in a VTP domain. The VTP mode determines how the switch processes and advertises VTP information.
| Server | VTP servers have full control upon VLAN creation, deletion, and modification. All VTP information is advertised to other switches in the domain, while all received VTP information is synchronized with other switches. Catalyst switches operate in VTP server mode by default. A VTP domain must have at least 1 VTP server switch to originate VTP advertisements upon VLAN creation, deletion, and modification. |
| Client | VTP clients are not allowed to create, delete, and modify any VLAN. A VTP client listens to VTP advertisements from other switches and update it VLAN configuration accordingly. The received VTP information is relayed or propagated out on trunk links to neighboring switches in the domain – the switch acts as a VTP relay. |
| Transparent | VTP transparent switches do not participate in VTP. A VTP transparent switch does not advertise its VLAN configuration, and does not synchronize the received VTP advertisements into its VLAN database. A VTP transparent switch can create, delete, and rename locally significant VLANs; the VLAN information is not relayed or propagated to any other switch. A VTPv1 transparent switch does not relay received VTP information to other switches unless its VTP domain name and VTP revision number match with the other switches. (*FALSE*) A VTPv2 transparent switch does relay or propagate received VTP advertisements out its trunk links – acting as a VTP relay, regardless of the VTP domain name setting. [1] |
| Off | This mode is available in CatOS and recent IOS Catalyst switches and Nexus switches. A VTP off switch behaves similarly to a VTP transparent switch with the exception that it drops all VTP advertisements and does not propagate them – partitions VTP domains. |
VTP Advertisements
A Catalyst switch participating in VTP advertises VLANs 1 to 1005, revision numbers, and VLAN parameters out its trunk ports to other switches in the VTP management domain.
VTP advertisements are sent as multicast frames destined to the MAC address 0100.0ccc.cccc.
Note: CDP, DTP, UDLD, and PAgP packets are also being sent to this MAC address.
A Catalyst switch intercepts frames sent to the VTP multicast MAC address and processes them with its supervisor processor.
By default, VTP management domains are set to use non-secure advertisements without a password.
A password should be added to set the VTP domain to secure mode.
The same password must be configured on all switches in the VTP management domain so that all the switches exchange VTP information using the same encryption key for calculating the MD5 digest hash for the VTP configuration, and therefore able to validate the sources of VTP advertisements.
Catalyst switches participating in VTP use an index called the VTP configuration revision number to keep track upon the most recent VTP information. All switches in a VTP domain stores the VTP configuration revision number (a 32-bit number) that it has last heard from a VTP advertisement.
The VTP advertisement process always starts with the VTP configuration revision number of 0.
The revision number is incremented by 1 upon subsequent changes made on a VTP server.
Other switches that receive an advertisement with a greater revision number than is stored locally would overwrite the stored VLAN information using the VLAN information in the advertisement.
Hence it is very important to always ensure newly added switches to have the revision number of 0 prior to attaching them to a network. Otherwise, a switch that might have stored the VTP information with a revision number that is greater than the value currently used in the VTP domain which would then overwrite and modify the VLAN information on all other switches throughout the VTP domain – VTP synchronization problem; the main reason that many campus networks avoid implementing VTP.
Switch ports that are assigned to VLANs that are deleted from the VTP database will become inactive, and results in major outage in the campus network. Note: A VTP client switch can overwrite the VTP database on a VTP server switch by generating or propagating VTP advertisements with a higher revision number.
Below lists the methods that can be used to reinitialize or reset the configuration revision number back to 0:
- Change the VTP mode of the switch to transparent mode and then back to server mode.
- Change the VTP domain name of the switch to a bogus name and then back to the original name.
VTP advertisements can originate from server mode switches as VLAN configuration changes occur, as well as requests from client mode switches that want to learn about the VTP database upon boot. Below describes the 3 types of VTP advertisements:
- Summary advertisements – VTP servers (and clients) send summary advertisements every 300 seconds (5 minutes) or upon a VLAN database change. Summary advertisements include information such as the VTP version, domain name, configuration revision number, updater identity, update timestamp, MD5 digest hash, and the number of subset advertisements to follow. The summary advertisements for VLAN configuration changes are followed by one or more subset advertisements with more specific VLAN configuration parameters.
- Subset advertisements – VTP servers send subset advertisements upon a VLAN database change. Subset advertisements list the VLAN parameters, eg: VLAN status, VLAN type, MTU size, VLAN name length, VLAN ID / number, IEEE 802.10 Security Association Identifier (SAID), and VLAN name in individual VLAN Information data structure for all VLANs in the domain. A summary advertisement and its associated subset advertisement for all the VLANs will be originated by the VTP server upon committing any creation, deletion, and modification of VLANs.
- Advertisement requests – A VTP client can request any VLAN information that it is lack of, eg: when it is just being configured as a VTP client mode switch, or it receives a VTP summary advertisement (with the Followers field of 0) [1] with a higher revision number than it currently has, which can happen if a Catalyst switch is temporarily partitioned from the network and a change occurs in the VTP domain. VTP servers respond with summary and subset advertisements upon receiving an advertisement request from a VTP client.
[1] – A VTP summary advertisement that does not have VTP subset advertisements to follow.
Catalyst switches that operate in VTP server mode store VLAN and VTP information separately from the switch configuration in NVRAM; the VLAN and VTP data are saved in the vlan.dat file in the flash memory file system. All the information, including the VTP configuration revision number, is retained even when the switch is powered off, therefore a switch can recover the last known VLAN configuration from its VTP database upon reboots.
Note: Catalyst switches that operate in VTP client mode will store the last known VTP information, including the VTP configuration revision number; they do not start with a clean slate upon reboots!
VTP Configuration
By default, a Cisco Catalyst switch operates in VTP server mode for the management domain NULL (blank string), with no password (non-secure mode). If it receives a VTP summary and subset advertisements from another switch on a trunk port, it learns the VTP domain name, VLANs, and configuration revision number – ease the commission of a new switch in an existing VTP domain.
Switch(config)#vtp domain {domain-name} Switch(config)#vtp mode {server | client | transparent | off} Switch(config)#vtp password {passwd} Switch(config)#vtp version {1 | 2 | 3} Switch(config)#vtp interface {intf-name} [only]A Catalyst switch only accepts the VTP messages originated or propagated by another switch resides in the same VTP domain – the VTP domain name of the switches must be the same.
A Catalyst switch does not start sending VTP updates until the switch has been configured with a VTP domain name. A VTP server or client switch without a VTP domain name configured will assume it should use and configure itself with the VTP domain name as seen in the first received VTP message.
The VTP domain name is case sensitive with a string of 1 to 32 characters.
Each VTP management domain should have at least 1 VTP server.
Multiple VTP servers can coexist in a domain and it is recommended to have 2 VTP server mode switches in every domain for redundancy, typically the 2 distribution layer switches.
The VTP servers do not elect a primary or secondary server; they all simply function as VTP servers.
Any creation, deletion, and modification of VLANs upon a VTP server will originate VTP summary and subset advertisements to update the switches (including other VTP servers) throughout the domain.
A password should be configured on VTP servers and clients to enable VTP secure mode in order to prevent DoS attacks with VTP, as the VTP domain name and revision number can be easily discovered using a network sniffer, eg: Wireshark.
The password is not being sent in VTP advertisements; an MD5 digest hash is calculated and sent in VTP summary advertisements by VTP servers and is used by the receiving VTP servers and/or clients to validate the authenticity of the received VTP advertisements.
When secure VTP is implemented by first configuring a password on the VTP servers, the client switches retain the last-known VTP information and filter incoming advertisements (do not process the received advertisements) until the same password is configured on them as well.
The VTP password is case sensitive with a string of 1 to 64 characters.
3 versions of VTP – VTPv1, VTPv2, and VTPv3, are available for use in a management domain.
Catalyst switches are enabled with VTPv1 by default.
VTPv1 and VTPv2 are not interoperable; the same VTP version must be configured on all switches in a domain.
In fact, it is rather difficult to setup this scenario with VTP servers and clients running different versions these days, as most recent Catalyst switches already support VTPv2.
When a VTPv1 server is changed to VTPv2, the VTPv2 summary and subset advertisements will be originated and propagated to all other VTPv2-capable switches and causes them to enable VTPv2.
VTPv2 offers the following additional features over VTPv1:
- Version-dependent transparent mode – A VTPv1 transparent switch matches the VTP version and domain name before propagating VTP packets to other switches; a VTPv2 transparent switch relays VTP packets without checking the VTP version number and domain name [1], which means that an intermediate VTPv2 transparent switch is able to relay VTPv1 packets [2] and this enables the support for multiple domains across a transparent domain. *FALSE*
- Consistency checks – VTPv2 performs consistency checks upon the VTP and VLAN parameters entered through SNMP and the web-based Cluster Management Suite software to prevent errors that are related to VLAN names and numbers from being propagated to other domain switches. However, the consistency checks are not performed upon VTP messages that are received on trunk links as well as the configuration and VLAN database data that is read from NVRAM. VTPv2 will forward the VTP messages as long as the MD5 digest on the messages is correct.
- Token Ring support – VTPv2 supports Token Ring switching – Token Ring Bridge Relay Function (TrBRF), and Token Ring Concentrator Relay Function (TrCRF) VLANs. VTPv2 must be enabled if Token Ring switching is being used.
- Unrecognized Type-Length-Value (TLV) support – A VTPv2 switch propagates instead of dropping VTP advertisements with unrecognized TLVs that it cannot parse and understand. It also saves them in vlan.dat when it is in VTP server mode. This could be useful if not all devices are at the same release version.
[1] – An intermediate transparent switch without a domain name configured (the NULL domain name) always relay VTP packets, regardless of the VTP version; an intermediate transparent switch only relay VTP packets with the domain name that matches the locally configured domain name, regardless of the VTP version. This is a common myth that has been busted by many people in the Cisco community and is confirmed by Cisco TAC – Cisco Bug ID CSCsi65330. Note: The router switch module NM-16ESW with VTPv2 transparent mode forwards VTP packets without VTP domain name check – Cisco Bug ID CSCsr22106.
[2] – An intermediate VTPv2 transparent switch is able to relay VTPv1 packets and vice versa
VTPv3 offers the following enhancements upon previous VTP versions:
- Support for extended VLANs 1006 to 4094, to compatible with the IEEE 802.1Q trunking standard. A VTPv3 switch with extended VLANs configured cannot be converted back to VTPv1 or VTPv2.
- Support for the advertising of detailed Private VLAN configuration.
- Improved password protection with the hidden and secret options.
- Protection against unintended automatic database synchronization upon introduction of new switches. With VTPv3, only a specific device called the primary server is allowed to update other switches.
- Backward compatible with VTPv2 (only). For VTPv2-capable switches that are running VTPv1, a change to VTPv2 will be triggered by the VTPv3 switch.
- Provides the ability to propagate the VLAN database and other databases, eg: MST mapping table.
- Provides the ability to be configured on a per-port or per-trunk basis instead of only a global scheme. Note: Setting the VTP mode to globally off applies upon all the trunking ports. However, VTP mode on or off can be specified on a per-VTP instance basis, eg: a switch can be configured as a VTP server for the VLAN database but with VTP mode off for the MST database.
A switch will first select the lowest numbered VLAN interface followed by the first L3 interface if any.
The vtp interface {intf-name} [only] global configuration command specifies the preferred interface whose IP address is used as the update identifier.
When no IP address is configured on the switch: Local updater ID is 0.0.0.0 (no valid interface found) When an IP address is configured on a VLAN interface – VLAN1: Local updater ID is 10.10.10.1 on interface Vl1 (lowest numbered VLAN interface found) When an IP address is configured on a loopback interface – Loopback1: Local updater ID is 10.10.10.1 on interface Lo1 (first layer3 interface found) When the vtp interface Loopback1 global configuration command is configured: Local updater ID is 10.10.10.1 on interface Lo1 (preferred interface) Preferred interface name is Loopback1 When the vtp interface Loopback1 only global configuration command is configured: Local updater ID is 10.10.10.1 on interface Lo1 (preferred interface) Preferred interface name is Loopback1 (mandatory)
The show vtp status EXEC command displays the VTP parameters on a Catalyst switch.
Note: The VTP Version column found in many models of Catalyst switches should be interpreted as the VTP Version capable column as found in the Catalyst 3560 switches.
The VTP V2 Mode column indicates whether a switch is running VTPv2 or not.
C2950#sh vtp status VTP Version : 2 Configuration Revision : 0 Maximum VLANs supported locally : 250 Number of existing VLANs : 5 VTP Operating Mode : Server VTP Domain Name : VTP Pruning Mode : Disabled VTP V2 Mode : Disabled VTP Traps Generation : Disabled MD5 digest : 0x57 0xCD 0x40 0x65 0x63 0x59 0x47 0xBD Configuration last modified by 0.0.0.0 at 0-0-00 00:00:00 Local updater ID is 0.0.0.0 (no valid interface found) C2950# ================================================================================ C3560#sh vtp status VTP Version capable : 1 to 3 VTP version running : 1 VTP Domain Name : VTP Pruning Mode : Disabled VTP Traps Generation : Disabled Device ID : 0023.04a3.5c80 Configuration last modified by 0.0.0.0 at 0-0-00 00:00:00 Local updater ID is 0.0.0.0 (no valid interface found) Feature VLAN: -------------- VTP Operating Mode : Server Maximum VLANs supported locally : 1005 Number of existing VLANs : 5 Configuration Revision : 0 MD5 digest : 0x57 0xCD 0x40 0x65 0x63 0x59 0x47 0xBD 0x56 0x9D 0x4A 0x3E 0xA5 0x69 0x35 0xBC C3560#
The show vtp counters EXEC command display the VTP message and error counters.
Switch#sh vtp counters
VTP statistics:
Summary advertisements received : 0
Subset advertisements received : 0
Request advertisements received : 0
Summary advertisements transmitted : 0
Subset advertisements transmitted : 0
Request advertisements transmitted : 0
Number of config revision errors : 0
Number of config digest errors : 0
Number of V1 summary errors : 0
VTP pruning statistics:
Trunk Join Transmitted Join Received Summary advts received from
non-pruning-capable device
---------------- ---------------- ---------------- ---------------------------
Switch#
VTP Pruning
L2 switches forward unknown unicasts, broadcasts, and multicasts throughout a broadcast domain or VLAN out all access and trunk ports (except the source port) that are transporting the particular VLAN. Unnecessarily forwarding those frames out trunk links to switches that do not maintain VLAN access membership for a particular VLAN consume the trunk link bandwidth and switch processor resources. Nevertheless, the receiving switch would discard them eventually. A trunk link transports traffic for all VLANs by default, unless specific VLANs are restricted from the trunk link through the manual switchport trunk allowed vlan interface subcommand configuration or implement VTP pruning, a dynamic mechanism that automatically maintains the allowed VLAN lists on trunks within a VTP domain.
VTP pruning intends to reduce unnecessary flooded traffic to achieve efficient use of trunk bandwidth.
A VTP pruning-enabled Catalyst switch that has an active access port associated with a VLAN would send a VTP Join message to its neighbor switches to indicate that it has active ports on that VLAN and request its neighbor switches to forward broadcast and unknown unicast frames for the VLAN to it.
A switch would forward the VTP Join messages from a downstream switch to an upstream switch. A VTP Join message includes a list of the VLANs that are currently active on the switch.
VTP Pruning
Even when VTP pruning has determined that the switch does not need to forward traffic for a VLAN across a trunk, the spanning tree instance for the VLAN will still active across the trunk due to the VLAN is allowed on the trunk. Unneeded VLANs should be manually pruned from the trunk using the switchport trunk allowed vlan interface subcommand to reduce the spanning tree diameter and eliminate the need to maintain spanning tree instances for the pruned VLANs across the trunk link. Manual pruning is also a secure way to ensure that we allow only expected VLANs across a trunk link.
VTP pruning is disabled by default. The vtp pruning global configuration command enables pruning. This command only needs to be implemented on a VTP server switch, in which it will advertise that pruning needs to be enabled for the entire domain and therefore cause all other VTP pruning-capable server and client switches in the entire management domain to enable pruning.
Note: With VTPv1 and VTPv2, enabling pruning on a VTP server would propagate the setting to all switches and enable pruning for the entire VTP domain. In VTPv3, pruning must be manually enabled on every switch in the domain.
A VTP-enabled Catalyst switch generates VTP Join messages out all its active trunk links every 6 seconds.
VTP pruning does not prune traffic from pruning-ineligible VLANs.
VLAN 1 is pruning-ineligible as it is being used for the transmission of control traffic and is the default access VLAN on switch ports.
VLANs 1002 – 1005 that are reserved for Token Ring and FDDI as well as extended-range VLANs 1006 – 4095 are pruning-ineligible as well.
As a conclusion, VTP pruning works only on normal-range VLANs except VLAN 1 – VLANs 2 to 1001.
The switchport trunk pruning vlan interface subcommand defines the pruning eligibility list for an interface – VLANs that can be pruned on a trunk link. VLANs 2 to 1001 are pruning eligible by default.
The "Pruning VLANs Enabled" column of the show interface type num switchport EXEC command lists the VLANs that are eligible for pruning on a trunk.
Below shows the output of the show interface type num trunk and show interface type num pruning EXEC commands on 2 Catalyst switches that are connected via a trunk link – Fa0/1 on both end.
Both switches have 3 VLANs – VLANs 1, 2, and 3, and have enabled VTP pruning.
SW2 has an active access port (in spanning tree forwarding state) in VLAN 2.
SW1#sh int fa0/1 trunk Port Mode Encapsulation Status Native vlan Fa0/1 on 802.1q trunking 1 Port Vlans allowed on trunk Fa0/1 1-4094 Port Vlans allowed and active in management domain Fa0/1 1-3 Port Vlans in spanning tree forwarding state and not pruned Fa0/1 1-2 SW1# SW1#sh int fa0/1 pruning Port Vlans pruned for lack of request by neighbor Fa0/1 3 Port Vlan traffic requested of neighbor Fa0/1 1 SW1# ================================================================================ SW2#sh int fa0/1 trunk Port Mode Encapsulation Status Native vlan Fa0/1 on 802.1q trunking 1 Port Vlans allowed on trunk Fa0/1 1-4094 Port Vlans allowed and active in management domain Fa0/1 1-3 Port Vlans in spanning tree forwarding state and not pruned Fa0/1 1 SW2# SW2#sh int fa0/1 pruning Port Vlans pruned for lack of request by neighbor Fa0/1 2-3 Port Vlan traffic requested of neighbor Fa0/1 1-2/ SW2#
The "spanning-tree forwarding state" statement in the output of the show interface trunk command is very misleading. It implies that only the spanning tree BPDUs for the VLANs that are listed underneath the statement are being sent across a trunk. In fact, spanning tree BPDUs for all VLANs included in the manually-configured allowed VLAN list are sent across the trunk, regardless of whether the VLANs have been pruned or not pruned. This means that VTP pruning is only useful for reducing the unnecessary propagation of user data within the pruned VLANs across trunks, but does not reduce the size of the spanning tree topology for the pruned VLANs.
By referring to the command outputs above, SW1 and SW2 still forward BPDUs for VLANs 1, 2, and 3 out their Fa0/1 trunking interface, not only for the VLANs listed underneath the misleading statement.
In the scenario above, SW1 does not have any active access port in VLANs 1, 2, and 3; hence it does not generate VTP Join messages to inform SW2 to forward user data for those VLANs and are being pruned.
No comments:
Post a Comment