Banyan VINES Routing

Document ID: 10696

Contents

Introduction
Prerequisites
      Requirements
      Components Used
      Conventions
Banyan Vines StreetTalk Directory Database Basics
StreetTalk and Routers
Problems with StreetTalk and Routers
Cisco Support Community - Featured Conversations
Related Information

Introduction

This document is designed to give an overview of how StreetTalk maintains information about which group names are maintained by which server.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Banyan Vines StreetTalk Directory Database Basics

The synchronization of StreetTalk group@org information is accomplished by a series of zero hop broadcast messages relayed by servers to their neighbor servers. There are four of these messages, which will be covered individually:

• "Welcome" messages are sent by any server that detects a new neighbor server. These messages welcome servers to the network, and exist to prime new servers' StreetTalk service by providing them with a list of all active StreetTalk services on the network.

• "Need information" messages are generally sent as the result of "welcome" messages. These messages indicate that the sending server has incomplete information for the server(s) listed in the welcome message, and request a complete list of groups maintained on the those server(s). If the sender requires information from more than one server, the message will be a broadcast. If the sender needs information from only one server, the message will be sent as a unicast.

• "Detail" messages are sent in response to "need information" messages, and they contain a list of all group@orgs maintained on a particular server. They may be sent as a network layer unicast or broadcast, depending upon the number of servers that have requested information from this server.

• "Summary" messages are similar in content to "welcome" messages. Each server sends a summary message every three hours to indicate that it is still present and alive on the network. Olsen VINES servers may send their summary messages up to every twelve hours.

Welcome messages are never forwarded by servers; they are local to a specific physical network segment. The other messages are commonly filtered by content so that only one copy of a message is ever forwarded by a server.

StreetTalk and Routers

With routers, servers are no longer always adjacent to each other, so a series of zero hop broadcast messages is no longer guaranteed to reach all servers. Routers, though appearing as servers to VINES servers, have no capacity to maintain a StreetTalk directory database and forward information from that database as zero hop broadcasts to their neighbors. To keep StreetTalk working, special support was added to the router for StreetTalk broadcast messages, making the router forward a StreetTalk broadcast message sent by a server even though the hop count already reached zero. This violates the normal VINES IP rules for forwarding broadcast packets, but it is required for StreetTalk to work, and is sanctioned by Banyan. The packet is still subject to all other normal broadcast suppression checks (including reverse path, incoming interface and expected neighbor tests), so this should not result in broadcast storms. StreetTalk broadcasts sent by clients are always subjected to the normal rules for forwarding broadcasts and are not subject to the special forwarding of their Streettalk broadcasts.

Problems with StreetTalk and Routers

   +----------+     |
   | server 1 |-----|
   +----------+     |
        .           |     +--------+ Slow Serial (56 KB)
        .           |-----| router |------//------
        .           |     +--------+
   +----------+     |
   |server 100|-----|
   +----------+     |

One problem was introduced by the router StreetTalk forwarding mechanism (see above diagram). When a new server is added to the Ethernet, it will be "welcomed" by each of the other 100 servers on that ethernet segment. Because of the StreetTalk forwarding mechanism, each of these multi-packet welcome messages will be forwarded to the serial line by the router. For a more concrete example, assume that there are 140 total servers in the Streetalk database (100 on the ethernet and 40 more across the serial lines), and that the serial line is a 56 KB line. To send information about the 140 servers, two 1500 byte VINES IP packets are required. Each of the 100 servers will send a welcome message, containing the 140 servers, resulting in 200 packets of 1500 bytes spaced over a seven second interval. The router will be required to forward 300 megabytes of information over the serial link in a seven second period during which time the link is only 392 megabytes. The load placed on the serial line in this situation will obviously impact other traffic over the serial line. Releases 10.0 and higher solve this problem by blocking all welcome messages. This has no effect on StreetTalk, since welcome messages were originally intended to be kept local to a physical network segment (given that they have zero hop broadcasts).

Another problem introduced by routers is the isolation of a new server to a network. This only happens to servers that are the only server on a LAN segment. Because there are no other VINES servers, there is no one to welcome them to the network, and so no priming of the StreetTalk group@org database. To solve this, you can wait up to 12 hours for the new server to hear the periodic update messages from all the other servers, or you can create a dummy group@org pair on the isolated server and then delete it. By adding and deleting a group@org pair, other servers will receive "detail" messages announcing the additon/deletion of the pair. This will cause the servers to be aware of the isolated server and begin the exchange of "need information" and "detail" messages. This problem only happens to newly installed servers, or servers that have been off of the network for more than 96 hours. Servers disconnected from the network for less than 96 hours will still retain group@org information from when they were last connected to the network. StreetTalk entries not updated for 96 hours are flushed from the database.

Cisco Support Community - Featured Conversations

Related Information

• LAN Product Support
• LAN Switching Technology Support
• Technical Support & Documentation - Cisco Systems