Cabletron's VlanHello Protocol Specification Version 4
Protocol for switches to discover neighbors and learn the topology of a switch fabric.
Hamilton, D. and D. Ruffen, "Cabletron's VlanHello Protocol Specification Version 4", RFC 2641, DOI 10.17487/RFC2641, August 1999, <https://www.rfc-editor.org/info/rfc2641>.
@misc{rfc2641,
series = {Request for Comments},
number = 2641,
howpublished = {RFC 2641},
publisher = {RFC Editor},
doi = {10.17487/RFC2641},
url = {https://www.rfc-editor.org/info/rfc2641},
author = {D. Hamilton and D. Ruffen},
title = {{Cabletron's VlanHello Protocol Specification Version 4}},
pagetotal = 17,
year = 1999,
month = aug,
} RFC text
Contents
Network Working Group D. Hamilton
Request for Comments: 2641 D. Ruffen
Category: Informational Cabletron Systems Incorporated
August 1999
Cabletron's VlanHello Protocol Specification
Version 4
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
The VlanHello protocol is part of the InterSwitch Message Protocol
(ISMP) which provides interswitch communication between switches
running Cabletron's SecureFast VLAN (SFVLAN) product. Switches use
the VlanHello protocol to discover their neighboring switches and
establish the topology of the switch fabric.
Table of Contents
1. Introduction...................................... 2
1.1 Data Conventions.............................. 2
2. VlanHello Protocol Operational Overview........... 2
2.1 Neighbor Discovery............................ 2
2.2 Port States................................... 3
2.3 Topology Events............................... 5
2.4 Timers........................................ 9
3. InterSwitch Message Protocol...................... 9
3.1 Frame Header.................................. 10
3.2 ISMP Packet Header............................ 11
3.3 ISMP Message Body............................. 12
4. Interswitch Keepalive Message..................... 13
5. Security Considerations........................... 16
6. References........................................ 16
7. Authors' Addresses................................ 16
8. Full Copyright Statement.......................... 17
1. Introduction
This memo is being distributed to members of the Internet community
in order to solicit reactions to the proposals contained herein.
While the specification discussed here may not be directly relevant
to the research problems of the Internet, it may be of interest to
researchers and implementers.
1.1 Data Conventions
The methods used in this memo to describe and picture data adhere to
the standards of Internet Protocol documentation [RFC1700], in
particular:
The convention in the documentation of Internet Protocols is to
express numbers in decimal and to picture data in "big-endian"
order. That is, fields are described left to right, with the most
significant octet on the left and the least significant octet on
the right.
The order of transmission of the header and data described in this
document is resolved to the octet level. Whenever a diagram shows
a group of octets, the order of transmission of those octets is
the normal order in which they are read in English.
Whenever an octet represents a numeric quantity the left most bit
in the diagram is the high order or most significant bit. That
is, the bit labeled 0 is the most significant bit.
Similarly, whenever a multi-octet field represents a numeric
quantity the left most bit of the whole field is the most
significant bit. When a multi-octet quantity is transmitted the
most significant octet is transmitted first.
2. VlanHello Protocol Operational Overview
Switches use the VlanHello protocol to detect their neighboring
switches and establish the topology of the switch fabric.
2.1 Neighbor Discovery
At initialization, each switch sends an Interswitch Keepalive message
out all local ports except those which have been preconfigured such
that they cannot be Network ports (see Section 2.2). Then, as each
switch discovers its neighboring switches via incoming Interswitch
Keepalive messages, it notifies its local topology services (see
Section 2.3), which then build the topology tables for the switching
fabric.
Each switch continues to send Interswitch Keepalive messages at
regular intervals (currently 5 seconds). If a switch has not heard
from one of its neighbors for some predetermined interval (see
Section 2.4), notification is sent to all interested services and the
neighboring switch is removed from the topology table.
Interswitch Keepalive messages are described in Section 4.
2.2 Port States
Each port on a switch can be in one of several different states.
These states are listed below. Figure 1 shows how the port state
changes within the VlanHello protocol.
o Unknown. This is the default state of all ports at
initialization.
o Network. A port is deemed a Network port when the switch has
received an Interswitch Keepalive message over the port from one
of its neighbor switches. A transition to this state triggers a
Neighbor Found event, notifying the local topology servers that
the interface is functioning and a 2-way conversation has been
established with the neighbor.
When the last switch is lost on a Network port, the state of the
switch reverts to either Network Only (see next state) or to
Unknown, and a Neighbor Lost event is triggered, notifying the
local topology servers that the interface is no longer
operational.
o Network Only. Certain types of port interfaces are incapable of
accessing user endstations and can only be used to access other
switches. Such ports are deemed Network Only ports. If the last
switch is lost from a port that has already been deemed a Network
port, the VlanHello protocol checks the condition of the port
interface. If it is the type of interface that can only be used
to access other switches, the state of the port is set to Network
Only. Otherwise, it reverts to Unknown.
o Standby. A port is deemed a Standby port under the following
conditions:
o The neighbor switch on the port has a higher level of
functionality and it has determined that the local switch is
incompatible with that functionality. In this circumstance,
the MAC entry for the local switch in the Interswitch Keepalive
message received from the neighbor contains an assigned status
of Incompatible.
o The list of MAC entries in the Interswitch Keepalive message
received from the neighbor switch does not contain an entry for
the local switch. In this circumstance, the local switch
assumes that communication with its neighbor will be one-way
only.
The VlanHello protocol continues to listen for Interswitch
Keepalive messages on a Standby port, but does not transmit any
Interswitch Keepalive messages over the port. If a message is
received that removes the condition under which the port state was
set to Standby, the state of the port is set to Network.
o Going to Access. When any packet other than an Interswitch
Keepalive message is received over an Unknown port, the state of
the port is changed to Going to Access and a timer is activated.
If the timer expires without an Interswitch Keepalive message
being received over the port, the port state changes to Access.
o Access. A port is deemed an Access port when any packet other
than an Interswitch Keepalive message has been received over the
port and the Going to Access timer has expired. A port can also
be administratively designated an Access "control" port, meaning
the port is to remain an Access port, regardless of the type of
messages that are received on it. Interswitch Keepalive messages
are not sent over Access control ports.
Three other types of ports are recognized: the host management port,
host data port, and host control port. These ports are designated at
initialization and are used to access the host CPU. Interswitch
Keepalive messages are not sent over these ports.
Packet in
|
V
+---------+
Packet in | Unknown |
| +---------+
G-A V |
Timer +----------+ no V
exp | Going to |<------[KA msg?] Packet in
<------| Access | | |
| +----------+ yes | V
V | V yes +---------+
+--------+ V [1-way?]------+-->| Standby |
| Access | [KA msg?] | ^ +---------+
+--------+ | | no | |
| V no | V
yes | [compatible?]----+ [KA msg?]
| | |
| | yes | yes
| V V
V +---------+ [1-way?]
+--------->| Network |<--+ |
+---------+ ^ | no
| | yes V
lost last | +<----[compatible?]
neighbor |
V
[network]
[ only? ]
|
+--------------+ yes | no +---------+
| Network Only |<-----------+----------->| Unknown |
+--------------+ +---------+
Figure 1: Port State Machine
2.3 Topology Events
When the VlanHello protocol discovers new information about the
status of one of its network ports, it notifies its local topology
service center so that the service center can build or modify the
topology tables for the switch fabric. This notification takes the
form of a system event, described in a structure known as a topology
relay structure. These structures are linked in a first-in/first-out
(FIFO) queue and processed by the topology servers in the order in
which they were received.
A topology relay structure typically contains information from
Interswitch Keepalive messages received on the specified port, as
shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | Event |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
04 | Delta options mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
08 | Current options mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 | Port number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 | |
+ Port neighbor switch identifier +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Port neighbor IP address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28 | ... Port neighbor IP address | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Neighbor chassis MAC addr +
32 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
36 | Neighbor chassis IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
40 | Neighbor functional level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
44 | Topology agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
48 | Next event |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Event
This 4-octet field contains the number of the event.
Valid values are as follows:
1 A new neighbor switch was discovered on the
specified port.
2 The neighbor switch has gained the feature(s)
specified in the Delta options mask.
3 The neighbor switch has lost the feature(s)
specified in the Delta options mask.
4 The neighbor switch has timed out and is presumed
down.
5 The specified port is down.
6 The neighbor switch has been previously seen on a
different port. The specified port is the
previous port.
7 The specified port is being reassigned to another
topology agent. Event is generated by the current
(old) agent.
8 The port is looped -- that is, the Keepalive
message was generated by the receiving switch.
9 The port is crossed -- that is, a Keepalive message
was received on a port not owned by this topology
agent.
10 The neighbor switch's functional level has changed.
11 The neighbor switch is running an incompatible
version of the protocol.
12 Two-way communication with the neighbor switch has
been lost.
13 The neighbor switch's Keepalive message sequence
number has been reset, indicating the switch
itself has been reset.
Delta options mask
This 4-octet field contains a bit map specifying the feature(s)
gained or lost by the neighbor switch (events 2 and 3 only).
Valid values are as specified for the next field, Current options
mask.
Current options mask
This 4-octet field contains a bit map specifying the features of
the neighbor switch. Bit assignments are as follows:
1 (unused)
2 The switch is a VLAN switch.
4 The switch has link state capability.
8 The switch has loop-free flood path capability.
16 The switch has resolve capability.
32 (unused)
64 The switch has tag-based flood capability.
128 The switch has tap capability.
256 The switch has message connection capability.
512 The switch has redundant access capability.
1024 The switch is an isolated switch.
4096 The switch is an uplink. (SFVLAN V1.8 only)
8192 The switch is an uplink to core. (SFVLAN V1.8 only)
16384 The port is an uplink port. (SFVLAN V1.8 only)
32768 The port is an uplink flood port. (SFVLAN V1.8 only)
Port number
This 4-octet field contains the logical number of the local port
for which the event was generated.
Port neighbor switch identifier
This 10-octet field contains the internal identifier of the
neighbor switch discovered on the port. The identifier consists
of the 6-octet physical (MAC) address of the neighbor switch,
followed by the 4-octet logical port number (local to the neighbor
switch) on which the neighbor was discovered.
Port neighbor IP address
This 4-octet field contains the Internet Protocol (IP) address of
the neighbor switch.
Neighbor chassis MAC address
This 6-octet field contains the physical (MAC) address of the
chassis of the neighbor switch.
Neighbor chassis IP address
This 4-octet field contains the Internet Protocol (IP) address of
the chassis of the neighbor switch.
Neighbor functional level
This 4-octet field contains the functional level of the neighbor
switch, as determined by the version level of the SecureFast VLAN
software under which this switch is operating. Valid values are
as follows:
1 The switch is running a version of SFVLAN prior to Version 1.8.
2 The switch is running SFVLAN Version 1.8 or greater.
Topology agent
This 4-octet field contains a pointer to the topology agent that
generated the event. The pointer here can reference any of the
topology agents that send Interswitch Keepalive messages -- that
is, any agent running the VlanHello protocol.
Next event
This 4-octet field contains a pointer to the next event relay
structure in the list.
2.4 Timers
The VlanHello protocol uses three timers.
o Send Hello timer. The Send Hello timer is used to control the
interval at which Interswitch Keepalive messages are sent.
o Aging timer. The Aging Timer is used to detect when communication
with a neighboring switch has been lost.
o Going to Access timer. The Going to Access timer is used to
synchronize the transition of a port state to Access and prevent a
port from being prematurely designation as an Access port during
network initialization. If an Unknown port receives any packet
other than an Interswitch Keepalive message, the port state is set
to Going To Access. If the switch receives an Interswitch
Keepalive message over that port before the timer expires, the
port state is changed to Network. Otherwise, when the timer
expires, the port state is changed to Access.
3. InterSwitch Message Protocol
The VlanHello protocol operates as part of the InterSwitch Message
Protocol (ISMP) -- part of Cabletron's SecureFast VLAN (SFVLAN)
product, as described in [IDsfvlan]. ISMP provides a consistent
method of encapsulating and transmitting network control messages
exchanged between SFVLAN switches.
ISMP message packets are of variable length and have the following
general structure:
o Frame header
o ISMP packet header
o ISMP message body
3.1 Frame Header
ISMP packets are encapsulated within an IEEE 802-compliant frame
using a standard header as shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | |
+ Destination address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
04 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source address +
08 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 | Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
16 | |
+ +
: :
Destination address
This 6-octet field contains the Media Access Control (MAC) address
of the multicast channel over which all switches in the fabric
receive ISMP packets. The destination address fields of all ISMP
packets contain a value of 01-00-1D-00-00-00.
Source address
This 6-octet field contains the physical (MAC) address of the
switch originating the ISMP packet.
Type
This 2-octet field identifies the type of data carried within the
frame. The type field of ISMP packets contains the value 0x81FD.
3.2 ISMP Packet Header
The ISMP packet header consists of a variable number of octets, as
shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 |///////////////////////////////////////////////////////////////|
://////// Frame header /////////////////////////////////////////:
+//////// (14 octets) /////////+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 |///////////////////////////////| ISMP Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 | ISMP message type | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | Code length | |
+-+-+-+-+-+-+-+-+ +
| Authentication code |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: :
Frame header
This 14-octet field contains the frame header.
ISMP Version
This 2-octet field contains the version number of the InterSwitch
Message Protocol to which this ISMP packet adheres. The VlanHello
protocol uses ISMP Version 3.0.
ISMP message type
This 2-octet field contains a value indicating which type of ISMP
message is contained within the message body. VlanHello
Interswitch Keepalive messages have a message type of 2.
Sequence number
This 2-octet field contains an internally generated sequence
number used by the various protocol handlers for internal
synchronization of messages.
Code length
This 1-octet field contains the number of octets in the
Authentication code field of the message.
Authentication code
This variable-length field contains an encoded value used for
authentication of the ISMP message.
3.3 ISMP Message Body
The ISMP message body is a variable-length field containing the
actual data of the ISMP message. The length and content of this
field are determined by the value found in the message type field.
The format of the VlanHello Interswitch Keepalive message is
described in the next section.
4. Interswitch Keepalive Message
The VlanHello Interswitch Keepalive message consists of a variable
number of octets, as shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | |
+ Frame header / +
: ISMP packet header :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n | Version | Switch IP address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n+4 | ... Switch IP address | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
n+8 | |
+ Switch ID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n+16 | |
+ Chassis MAC address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Chassis IP address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n+24 | ... Chassis IP address | Switch type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n+28 | Functional level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n+32 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n+36 | Base MAC count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
n+40 | |
: Base MAC entries :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n = 21 + length of the authentication code of the packet
Frame header/ISMP packet header
This variable-length field contains the frame header and the ISMP
packet header.
Version
This 2-octet field contains the version number of the VlanHello
protocol to which this message adheres. This document describes
VlanHello Version 4.
Switch IP address
This 4-octet field contains the Internet Protocol (IP) address of
the sending switch.
Switch ID
This 10-octet field contains the internal ISMP identifier of the
sending switch. The identifier is generated by the sending switch
and consists of the 6-octet physical (MAC) address of the switch,
followed by a 4-octet value containing the logical port number
over which the switch sent the packet.
Chassis MAC
This 6-octet field contains the physical (MAC) address of the
chassis of the sending switch.
Chassis IP address
This 4-octet field contains the Internet Protocol (IP) address of
the switch chassis.
Switch type
This 2-octet field contains the type of the switch. Currently, the
only value recognized here is as follows:
2 The switch is an SFVLAN switch.
Functional level
This 4-octet field contains the functional level of the sending
switch, as determined by the version level of the SecureFast VLAN
software under which this switch is operating. Valid values are
as follows:
1 The switch is running a version of SFVLAN prior to Version
1.8.
2 The switch is running SFVLAN Version 1.8 or greater.
Options
This 4-octet field contains a bit map specifying the features of
the switch. Bit assignments are as follows:
1 (unused)
2 The switch is a VLAN switch.
4 The switch has link state capability.
8 The switch has loop-free flood path capability.
16 The switch has resolve capability.
32 (unused)
64 The switch has tag-based flood capability.
128 The switch has tap capability.
256 The switch has message connection capability.
512 The switch has redundant access capability.
1024 The switch is an isolated switch.
4096 The switch is an uplink. (SFVLAN V1.8 only)
8192 The switch is an uplink to core. (SFVLAN V1.8 only)
16384 The port is an uplink port. (SFVLAN V1.8 only)
32768 The port is an uplink flood port. (SFVLAN V1.8 only)
Base MAC count
This 2-octet field contains the number of entries in the list of
Base MAC entries.
Base MAC entries
This variable-length field contains a list of entries for all
neighboring switches that the sending switch has previously
discovered on the port over which the message was sent. The number
of entries is found in the Base MAC count field.
Each MAC entry is 10 octets long, structured as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Switch MAC address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Assigned neighbor state ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Assigned neighbor state |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Switch MAC address
This 6-octet field contains the base MAC address of the
neighboring switch.
Assigned neighbor state
This 4-octet field contains the assigned state of the neighboring
switch as perceived by the sending switch. Currently, the only
value valid here is 3, indicating a state of Network
5. Security Considerations
Security concerns are not addressed in this document.
6. References
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994.
[IDsfvlan] Ruffen, D., Len, T. and J. Yanacek, "Cabletron's
SecureFast VLAN Operational Model", RFC 2643, August
1999.
[IDvlsp] Kane, L., "Cabletron's VLS Protocol Specification", RFC
2642, August 1999.
7. Authors' Addresses
Dave Hamilton
Cabletron Systems, Inc.
Post Office Box 5005
Rochester, NH 03866-5005
Phone:(603) 332-9400
EMail: daveh@ctron.com
Dave Ruffen
Cabletron Systems, Inc.
Post Office Box 5005
Rochester, NH 03866-5005
Phone:(603) 332-9400
EMail: ruffen@ctron.com
17. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
AI ELI5
On this page
§1Overview of VlanHello
The VlanHello protocol is part of Cabletron's SecureFast VLAN (SFVLAN) product and enables switches to discover neighboring switches and establish the network topology.
The protocol is simple: at startup, each switch sends Interswitch Keepalive messages out all ports (except those preconfigured to be non-network ports). When switches hear keepalive messages from neighbors, they record the connection. If communication is lost for a predetermined time, the neighbor is removed from the topology.
As the protocol discovers network changes, it generates topology events that are delivered to local topology services. These services process events from a FIFO queue and update the switch fabric's topology tables. This architecture allows the VlanHello protocol to focus narrowly on neighbor discovery while delegating topology management to other services.
Each switch periodically says hello to all its neighbors. When two switches hear each other, they know they are connected. If they stop hearing from each other, they know the connection is broken.
§2Port States and Neighbor Discovery
Every port on a switch can be in one of several states that indicate its role and connectivity. The VlanHello protocol manages transitions between these states based on the traffic it observes.
Unknown is the default state at initialization. When the switch receives an Interswitch Keepalive message from a neighbor, the port transitions to Network, and a "Neighbor Found" event is sent to topology services. If all neighbors leave, the port returns to Unknown or Network-Only (if the interface can only connect to other switches).
Standby ports receive but do not send keepalive messages. A port becomes Standby if the neighbor reports the local switch as Incompatible, or if the neighbor's keepalive does not include the local switch in its list (indicating one-way communication).
Access ports receive user end-station traffic. If a port receives non-keepalive traffic while Unknown, it moves to Going-To-Access for a brief period; if no keepalive arrives during this window, the port becomes Access. Network-Only ports are preconfigured for inter-switch links only.
The RFC includes a state machine diagram showing all transitions triggered by receiving keepalive messages, detecting one-way communication, and timer expiry.
Ports start as Unknown. When a switch hears from a neighbor, the port becomes Network. If users plug in, the port becomes Access. The state machine keeps track of what kind of connection each port has.
- Unknown start
- Network
- Network Only
- Standby
- Access
- Going to Access
| From | To | Event |
|---|---|---|
| Unknown | Network | Keepalive received |
| Unknown | Going to Access | Non-keepalive packet |
| Going to Access | Network | Keepalive received |
| Going to Access | Access | Timer expires |
| Network | Standby | One-way or incompatible |
| Standby | Network | Two-way communication confirmed |
| Network | Network Only | Last neighbor lost, interface type is network-only |
| Network Only | Unknown | No longer network-only |
§3Topology Events and Timers
The VlanHello protocol notifies topology services of network changes through topology events. Each event describes something that happened on a port, such as a neighbor discovered (Event 1), a neighbor's features changed (Events 2-3), a neighbor timeout (Event 4), or a port down (Event 5).
Each topology event contains the event type, port number, neighbor switch identifier (MAC address plus logical port), neighbor IP and MAC addresses, functional level (software version), and a bitmap of the neighbor's capabilities. The capability bitmap includes flags for VLAN switch, link state, flood path, loop-free capability, redundancy, tap capability, uplink designation, and other features.
The RFC defines two timers. The Send Hello timer controls how often Interswitch Keepalive messages are sent (every 5 seconds in typical deployments). The Aging timer determines how long to wait before declaring a neighbor down. The Going-to-Access timer delays the transition of a port from Unknown to Access, allowing the protocol to distinguish between switch neighbors and end-station connections.
When something changes—a new neighbor appears, a neighbor disappears, or a port is no longer used—the switch sends a notification. Three timers control when messages are sent, when neighbors are declared lost, and when a port becomes an access port.
§4InterSwitch Message Protocol
VlanHello operates as part of the InterSwitch Message Protocol (ISMP), a framing protocol for switch-to-switch control messages in Cabletron's SFVLAN product. ISMP messages are encapsulated in an IEEE 802 frame with a destination multicast MAC address 01-00-1D-00-00-00 that all switches in the fabric receive.
Each ISMP packet contains a frame header, ISMP packet header, and ISMP message body. The ISMP header includes the protocol version (3.0 for VlanHello), message type (2 for keepalive), a sequence number, and an authentication code field.
The Interswitch Keepalive message (the message body of type 2) contains the sending switch's IP address, internal switch identifier, MAC address, functional level, and a bitmap of its capabilities. Most importantly, it includes a list of Base MAC entries: the MAC addresses of neighboring switches previously discovered on the same port, with each entry showing the neighbor's assigned state. This list allows receiving switches to detect if the neighbor is hearing them back (two-way communication) or if communication is one-way.
Keepalive messages are like postcards sent over the network. Each one says who the switch is, what it can do, and which neighbors it hears. By reading these postcards, other switches build a map of the network.
§5Topology Relay Structure
When VlanHello detects a topology change, it creates a topology relay structure that bundles the event information for delivery to topology services. These structures are queued in FIFO order and processed in sequence.
Each structure contains a 4-octet event type number (one of 13 defined event types), delta and current option mask fields (showing capabilities gained or lost), the port number and neighbor identifiers, neighbor chassis information, functional level, a pointer to the topology agent that generated the event, and a pointer to the next event in the queue.
Event types include Neighbor Found, Features Gained, Features Lost, Neighbor Timeout, Port Down, Neighbor Moved to Different Port, Port Reassigned, Looped Port (keepalive from self), Crossed Port (keepalive not owned by this agent), Functional Level Changed, Incompatible Protocol Version, Two-Way Communication Lost, and Sequence Number Reset (indicating a neighbor reboot).
The functional level field allows the protocol to handle backward compatibility with older SFVLAN versions, and the capability bits provide fine-grained information about each switch's features for advanced topology decisions.
When the network topology changes, VlanHello creates a notification containing all the details about what changed and puts it in a queue for the topology manager to process in order.