Cisco VLAN Trunk Protocol Keith McCloghrie, Cisco Systems The aim of the Cisco VLAN Trunk Protocol is to ease the network management of VLANs through the automated distribution of VLAN configuration information across multiple devices (i.e., switches and routers) within a management domain. This not only reduces the burden of configuration, but also ensures the consistency of VLAN configuration information across those devices. 1. VLAN Trunk Protocol ------------------------ VTP provides for each device (router or LAN-switch) to transmit advertisements in frames on its trunk ports. These advertisement frames are sent to a multicast address so as to be received by all neighboring devices, but they are not forwarded by normal bridging procedures. Such an advertisement lists the sending device's VTP management domain, its configuration revision number, the VLANs which it knows about, and certain parameters for each known VLAN. By hearing these advertisements, all devices in the same management domain learn about any new VLANs now configured in the transmitting device. By this means, a new VLAN needs to be created/configured on only one device in the management domain, and the information is automatically learned by all the other devices in the same management domain. Once a device learns about a VLAN, it will by default receive all frames on that VLAN from any trunk port and, if appropriate, forward them to each of its other trunk ports, if any. A device's configuration can always be modified through management (CLI or SNMP) in order to disable one or more known VLANs on individual trunk ports. 1.1 VTP Clients/Servers ------------------------- In order to retain the VLAN information contained in VTP advertisements across reboots/network outages, it is necessary for at least a subset of the devices to be able to recover all information currently contained in advertisements after they reboot. In large, heterogeneous networks, the amount of such information may be beyond the non-volatile storage capabilities of some devices; however, storage of this same information in every device is normally beyond the required amount of redundancy. Therefore, each device which transmits VTP advertisements is categorized as being either a VTP Client or a VTP Server. By default, every device is a VTP Server. VTP Servers guarantee that they can recover *all* the VLAN information in current VTP advertisements from NV-storage after they reboot; if they cannot, they must cease being a VTP Server and become a VTP Client instead. After a reboot, VTP Clients do not transmit VTP advertisements until they receive a VTP advertisement to initialize their VLAN information. In addition, a VTP Client will only accept changes to the current set of VLAN information through receiving VTP advertisements, not via CLI or SNMP; such information can only be modified via the CLI or SNMP at a VTP Server. It is to be stressed that a VTP server must store all information received in VTP advertisements, including that information it does not understand. Likewise even a VTP client, which is not required to store configuration in non-volatile storage, must be able to propogate configuration changes to its other trunks, even for the TLVs for which it is not able to parse. After a reboot, a VTP Client issues one or more requests for a VTP advertisement. If no VTP advertisement is received in, say, 5 seconds, then the VTP Client may use locally configured VLAN information, but will not issue VTP advertisements containing this information. Such locally configured information is overridden (but may or may not be overwritten) as soon as a VTP advertisement is received. Thus, when a network is partitioned such that there are no VTP Servers in one or other of the partitions, and all VTP Clients in that partition are rebooted, then no VTP advertisements will be transmitted in that partition. After a reboot, a device configured as a VTP Server attempts to recover the information contained in VTP advertisements from NV-storage. Prior to successful recovery, the device can only act as a VTP Client. The NV-storage used to hold the information can be either: - the device's own NVRAM, which it must write immediately upon learning of any change in the information, or - a configuration file, which it downloads via TFTP after a reboot. Note that since a VTP Server automatically updates its file upon a change, is is inadvisable for multiple VTP Servers to share the same configuration file. In a large heterogeneous network, only a few devices need to be VTP Servers, and the choice of which devices should be made according to the devices' capabilities and the amount of redundancy required. In a small network, all devices will normally be VTP Servers. 1.2 Transparent Mode -------------------- Some devices (i.e., switches or routers) in the extended LAN may be VLAN-aware, but either not VTP-capable or alternatively have their VTP capability disabled. In the latter case, these devices are said to be in "transparent mode". When in transparent mode, a switch forwards VTP messages just the same as any other multicast frames without inspecting their content. The VLAN configuration of a switch in transparent mode is local to that switch, and may be configured via the CLI and/or SNMP. While this local configuration needs to be at least compatible with the VLAN configuration information being passed through it by VTP, it is up to the network administrator to ensure this. Note that a device in transparent mode must take precaution not to forward VTP advertisements through blocked ports as would be normally the case. Doing so could potentially lead to bridging loops. 2. VLAN Trunk Protocol Details ------------------------------ 2.1. Advertisements ------------------- With the information for each VLAN potentially needing tens of octets, it is impossible to contain all the information for all VLANs in a single MAC frame. Thus, at those times when all the information needs to be transmitted, it is necessary to send the advertisement as multiple frames. However, it is unnecessary for all the information to be sent except when at least some part of the information has changed or when required for initialization of a device (e.g., after a device restart). In fact the regular periodic advertisements (after one configuration change and before the next) only need to indicate that nothing has changed. Two such indications are utilized: one, the configuration revision number indicates when a change occurs; two, the authentication checksum defined for security ensures that two different configurations with the same configuration revision number (which can occur, for example, after a network partition) are recognized as being different. Occasionally, some or all information on all VLANs must be transmitted as a sequence of frames. This always occurs after a configuration change; it can also occur when requested by one of the devices, either because that device failed to receive one or more of the sequence of frames, or because it has just restarted. A request frame is defined for use by a device to request transmission of all information. 4.2. Use of Configuration Revision Numbers ------------------------------------------ Whenever a device is re-configured by management (CLI or SNMP) to: a) define a new VLAN, b) delete an existing VLAN, c) suspend/resume an existing VLAN, or d) modify the parameters of an existing VLAN, then that device's configuration revision number is incremented. Stated another way, the configuration revision number is incremented when the value of any field covered by the advertisement's checksum is modified. The timestamp of the current time and the local device's identity (one of its IP-addresses) is also recorded and included in the next VTP advertisement. When a device receives an advertisement, if the configuration revision number in the advertisement is: - less than that of the receiving device, then the advertisement is ignored and a summary advertisement with the current revision number is transmitted on the trunk the original advertisement was received on. - the same as that of the receiving device, then: - if the checksum of the advertisement is exactly the same as the checksum of the current configuration known to the device, then no action is taken; - otherwise, the device's configuration is unaffected, but the device indicates to management that a configuration error condition has occurred. - greater than that of the receiving device, and the advertisement's checksum and configuration information match, then: - if the set of VLANs and their parameters known to the device, after being updated by the information in the advertisement, would be inconsistent (e.g., "red" with VLAN-id #6 is inconsistent with "blue" with VLAN-id #6), then the device's configuration is unaffected, and the device indicates to management that a configuration error condition has occurred. - otherwise: - any VLAN in the advertisement unknown to the device is learnt, - any VLAN in the advertisement known to the device but with different parameters, is updated to have the parameters from the advertisement, - any VLAN known to the device but not in the advertisement is forgotten by the device; any ports currently assigned to that VLAN are disabled, - the device's configuration revision number is updated to that of the advertisement. - new values of the update timestamp and updater identity are obtained from the advertisement. - the VTP advertisement is re-generated on each of the device's trunk ports other than that on which it was received. This scheme always works when the set of VLANs and their parameters is (re-)configured in only one device (within the management domain) at a time. Normally, the window of time for this restriction of reconfiguring only one device at a time is the length of time to propagate new information across all devices (typically, on the order of milliseconds, at most on the order of a few seconds). However, it can be longer if some devices are temporarily partitioned. When a set of devices is partitioned for a prolonged period, a device in each partition can be updated. When the partition is repaired, the configuration in the set of devices with the greater configuration revision number takes precedence. If, however, devices in both partitions have the same configuration revision level, configuration errors may be signalled. If a parameter of a VLAN is changed and, as a result, the current configuration/assignment of a port to that VLAN becomes inconsistent (e.g., due to a change in VLAN-type), then that port is either disabled and an error is signalled to management. 2.3. Transmission of Advertisements ----------------------------------- Advertisements are transmitted using a special multicast destination MAC-address. They are not forwarded using normal bridge techniques. Advertisements are transmitted on the default VLAN. Thus, only one copy is transmitted on a trunk port, no matter how many VLANs are defined. A device generates an advertisement immediately after its configuration revision number is modified, and transmits it on all its trunk ports. A device also transmits an advertisement periodically on any trunk port for which it has not sent an advertisement nor received an advertisement matching its own for the last 5 minutes. The actual timer value is "jittered" to avoid synchronization effects. However, the sending of advertisements on an interface can be disabled by management. 2.4. Configuration Revision Numbers ----------------------------------- A configuration revision number is unsigned. It starts at zero, increments by one on each modification until it reaches the value 4294967295 when it "wraps" back to zero and starts incrementing again. The configuration revision number A is less than the configuration revision number B if: ((A < B && (B-A) < 2147483648) || (A > B && (A-B) > 2147483648)) 2.5. Advertisement Messages --------------------------- Three message types are defined: - Advert-Request - Summary-Advert - Subset-Advert The first is a request. The latter two are effectively responses, either solicited or unsolicited. All messages are sent as (link layer) multicast frames. Each advertisement consists of one Summary-Advert immediately followed by zero or more Subset-Adverts. A Summary-Advert contains the management domain name, the configuration revision number, the update timestamp and identity, the authentication checksum, and the number of Subset-Advert messages which follow it. A Subset-Advert contains all information for one or more (but always an integral number of) VLANs, and indicates its own sequence number within those which follow the Summary-Advert. An Advert-Request normally requests information on all VLANs; it can, however, request information on only a subset of the VLANs. The number of Subset-Advert messages which follow a Summary-Advert is determined according to the reason for sending the advertisement. When the advertisement is sent because: - neither this device nor any other device has recently sent an advertisement, the Summary-Advert is followed by zero Subset-Advert messages. - a configuration change has been made, the Summary-Advert is followed by the minimum number of Subset-Advert messages required to contain all information on all VLANs, ordered in ascending order of VLAN-id. - an Advert-Request for information on all VLANs was received, the Summary-Advert is followed by the minimum number of Subset-Advert messages required to contain all information on all VLANs, ordered in ascending order of VLAN-id. - an Advert-Request for information on a subset of VLANs was received, the Summary-Advert is followed by the minimum number of Subset-Advert messages required to contain the specified information on the subset of VLANs, ordered in ascending order of VLAN-id. An advertisement is sent: - immediately upon a change in configuration (via CLI or SNMP) of VLAN information. - when no other Summary-Advert with the current configuration-rev-number has been heard for a timeout period. The timeout period is truncated to a small random value by the receipt of an Advert-Request message. - when a Summary-Advert carrying a lesser revision number than is currently known to the device receiving it for that domain. An Advert-Request is sent after a reboot when in client mode, and as follows. When any of these events happen: 1. on receiving a Subset-Advert message containing a config-rev-number which is higher than the device's currently-known value; or 2. on receiving a Summary-Advert having a config-rev-number which is greater than the device's currently-known value, and having zero following Subset-Adverts; or 3. on not receiving the expected number of Subset-Advert messages within a short period after receiving a Summary-Advert having a config-rev- number which is greater than the device's currently-known value; then, a timer is started having a timeout period of a pseudo-random value in the range: 0 to 1 second. If the timer expires before either an Advert-Request or Summary-Request is received, then an Advert-Request is sent. When an Advert-Request is sent because some Subset-Advert messages were missed (case 3 above), the Advert-Request is set to request only those VLANs which were missed. In particular, the Start-Value (see the packet format below) is set to the value one greater than the VLAN-id of the last VLAN in the last Subset-Advert for which no previous Subset-Adverts were missed. The period of the timeout for sending an advertisement is 5 minutes. Whenever this timeout is started, a pseudo-random value in the range: 0 to 1 second is added to it. When a (consistent) advertisement is received, the timer is restarted without sending an advertisement. When an Advert-Request request is heard, the remaining time on the outstanding timeout is reduced to the value of the last pseudo-random value used. A Summary-Advert message contains a MD5 digest value. The value is the result of calculating the MD5 digest value over the concatenation of four fields (in network-byte order): 1) the 16-octet secret value, 2) the Summary-Advert message, itself, 3) the per-VLAN information for all defined VLANs, formatted exactly as contained in Subset-Advert messages, and ordered in ascending order VLAN-id, 4) the 16-octet secret value.