|
|
The Banyan VINES protocol is a networking system for personal computers. "VINES" is an acronym for Virtual Network System. This proprietary protocol was developed by Banyan and is derived from Xerox's XNS protocol. Cisco's implementation of VINES has been designed in conjunction with Banyan.
Cisco's implementation of Banyan VINES provides routing of VINES packets on all media types. Although the software automatically determines a metric value that it uses to route updates based on the delay set for the interface, Cisco's software implementation allows you to customize the metric. Cisco's implementation also offers address resolution to respond to address requests. MAC-level echo support is also available for Ethernet, IEEE 802.2, Token Ring, and FDDI media. Name-to-address mapping for VINES host names also is supported, as are access lists to filter outgoing packets.
Use the commands in this chapter to configure and monitor VINES networks. For VINES configuration information and examples, refer to the "Configuring Banyan VINES" chapter in the Router Products Configuration Guide.
To delete entries from the VINES fast-switching cache , use the clear vines cache EXEC command.
If you do not specify any keywords or arguments, all entries in the fast-switch cache are deleted.
The fast-switching cache is a table of routes used when fast switching is enabled.
The following example deletes from the fast-switching cache table all entries from the VINES fast-switching cache table:
The following example deletes all entries whose destination server has the address 30002E6D:
show vines cache
vines decimal
vines route-cache
To delete VINES IPC connection blocks from the router, use the clear vines ipc EXEC command.
An IPC connection entry is built each time the router initiates or receives an IPC DATA message from a router that is not already in this table.
The following example deletes IPC connection 0x1D from the table of VINES IPC connections:
To delete entries from the neighbor table, use the clear vines neighbor EXEC command.
Network number of the neighbor whose entry should be deleted from the neighbor table. The argument network can be either a 4-byte hexadecimal number or a 4-byte decimal number (if you have issued a vines decimal command). |
|
Deletes all entries from the neighbor path table except the entry for the local router. |
The neighbor table contains an entry for each of the router's neighbor nodes.
Deleting an entry from the neighbor table also deletes any routes in the routing table that have that neighbor as the first hop and all fast-switching cache entries that have that neighbor as the first hop in any of their paths.
The following example deletes all entries from the neighbor table:
clear vines route
show vines neighbor
show vines route
vines decimal
vines neighbor
vines route
To delete network addresses from the routing table, use the clear vines route EXEC command.
Network number of the entry to delete from the routing table. The argument network can be either a 4-byte hexadecimal number, a 4-byte decimal number (if you have issued a vines decimal command), or a host name (if you have issued a vines host command). |
|
Deleting an entry from the routing table with the clear vines route command also deletes any entries in the fast-switching table that are a part of that logical network.
The following example deletes all entries from the VINES routing table:
clear vines neighbor
show vines neighbor
show vines route
vines decimal
vines host
vines route
To clear all VINES-related statistics that are displayed by the show vines traffic command, use the clear vines traffic EXEC command.
This command has no arguments or keywords.
The clear vines traffic command clears only the statistics displayed by the show vines traffic command. It has no effect on the value of the VINES counters retrieved by SNMP.
The following example zeros all VINES-related traffic statistics:
To determine basic network connectivity, use the ping EXEC command.
The ping command determines network connectivity by sending datagrams to another host on the network.
The following is sample output from the ping command:
To display the VINES access lists currently defined, use the show vines access EXEC command.
If no access list number is specified, all access lists are displayed.
The following is sample output from the show vines access command:
Table 15-1 describes the fields shown in the display.
Table 15-1 Show VINES Access Field Descriptions
| Field | Description |
|---|---|
vines access-list (standard)
vines access-list (extended)
vines access-list (simple)
To display the contents of the VINES fast-switching cache, use the show vines cache EXEC command.
(Optional) Displays the entry in the fast-switching cache for the specified station. |
|
(Optional) Displays all neighbors in the fast-switching cache that are accessible via the specified interface type and number. |
|
(Optional) Displays all routes in the VINES fast-switching cache that have the specified neighbor as their first hop. The argument address is a 6-byte hexadecimal number in the format network:host, where network is 4 bytes and host is 2 bytes, a 4-byte decimal number in the same format (if you have issued a vines decimal command), or a host name (if you have issued a vines host command). |
|
(Optional) Displays all entries in the VINES fast-switching cache that are in the specified logical network. The argument network can be either a 4-byte hexadecimal number or a 4-byte decimal number (if you have issued a vines decimal command). |
If no keywords or arguments are specified, all entries in the fast-switching cache are displayed.
The following is sample output from show vines cache command. This sample shows all entries in the VINES fast-switching cache.
Table 15-2 describes fields shown in the display.
Note that neighbor information is not explicitly displayed by the show vines cache command. However, you can determine it by looking at the neighbor and routing tables (using the show vines neighbor and show vines route commands, respectively).
Table 15-2 Show VINES Cache Field Descriptions
clear vines cache
show vines neighbor
show vines route
vines decimal
vines route-cache
To display the entries in the VINES host name table, use the show vines host EXEC command.
If no name is specified, all entries in the host name table are displayed.
The following is sample output from the show vines host command:
Table 15-3 describes the fields shown in the display.
Table 15-3 Show VINES Host Field Descriptions
To display status of the VINES interfaces configured in the router and the parameters configured on each interface, use the show vines interface EXEC command.
If you omit all keywords, this command displays values for all interfaces, and displays all VINES global parameters.
The following is sample output from the show vines interface command:
Table 15-4 describes the fields that may be shown in the display.
Table 15-4 Show VINES Interface Field Descriptions
| Field | Description |
|---|---|
Address the router will assign to the next client that requests an address. This line is interesting only if the router has been configured via the vines arp-enablecommand to respond to address assignment requests. |
|
Indicates whether addresses will be displayed as decimal or hexadecimal numbers. |
|
Indicates the longest time interval (in seconds) between routing updates on any of the router's interfaces. |
|
Displays a list of all neighbor paths for which an RTP request will be sent on a regular basis, and the interval until that timer expires. |
|
Identifier number that will be used on the last SRTP update message sent by this router |
|
Displays a list of all neighbor paths for which an SRTP update is currently being reassembled, and the interval until that timer expires. |
|
Displays a list of all neighbor paths for which an SRTP request is currently being retried, and the interval until that timer expires. |
|
Indicates whether the router is participating in VINES time-of-day synchronization. This is controlled by the vines time participate global configuration command. |
|
Type and number of interface, and whether it is currently active and inserted into network (up) or inactive and not inserted (down). |
|
Indicates whether the software processes that handle the line protocol believe the interface is usable (that is, whether keepalives are successful). This field can report the values "up," "down," and "administratively down." |
|
Indicates that VINES processing is not enabled on the interface (that is, you have not issued a vines metric command on the interface). |
|
Type of encapsulation used for VINES broadcast packets, as defined with the vines encapsulation command. This field can report the values "arpa," "vines-tr," and "snap." |
|
Metric that has been configured for the interface with the vines metric command. The metric is shown in internal form, configuration form, and in seconds. |
|
Indicates whether split horizon has been enabled or disabled (via the vines split-horizon command). |
|
Indicates whether this interface will process ARP packets, as specified by the vines arp-enable command. |
|
Indicates whether this interface is defined via the vines serverless command as being connected to a serverless network. |
|
Indicates whether fast switching has been enabled via the vines route-cache command). The value reported in this field can be "enabled," "disabled," or "not supported." |
|
Frequency of routing updates, in seconds. This also indicates when the next routing update will be transmitted on the interface. You set the update interval with the vines update interval command. |
|
Indicates whether routing updates contain all entries in the routing table or just changes to the table since the last update was sent. You set the method used with the vines update deltas command. |
|
Indicates when the next SRTP synchronization update will be sent. |
|
Indicates the number and type of all VINES-speaking devices present on the given physical network segment. |
|
List of all VINES neighbor on that interface and what version of the RTP protocol they are running. 0 means RTP, and 1 means SRTP. |
vines arp-enable
vines encapsulation
vines metric
vines route-cache
vines serverless
vines split-horizon
vines update deltas
vines update interval
To display information about any currently active IPC connections, use the show vines ipc EXEC command.
This command has no arguments or keywords.
Information about the IPC protocol formats, data sequences, and state machines can be found in Banyan documentation.
The following is sample output from the show vines ipc command:
Table 15-5 describes the fields shown in the display.
Table 15-5 Show VINES IPC Field Descriptions
To display the entries in the VINES neighbor table, use the show vines neighbor EXEC command.
If no keywords or arguments are specified, all entries in the neighbor table are displayed.
The following is sample output from the show vines neighbor command. This sample shows all entries in the VINES neighbor table.
Table 15-6 describes the fields shown in the display.
Table 15-6 Show VINES Neighbor Field Descriptions
| Field | Description |
|---|---|
Version number of the VINES neighbor table. The number is incremented each time a route or path is added to or deleted from this table. |
|
Address of the neighbor station. The neighbor's name is displayed if you have issued a vines host command. |
|
MAC address of the router interface through which the VINES neighbor in this entry can be reached. |
|
Type of MAC-level encapsulation used to communicate with this neighbor. |
|
Type and number of interface through which the VINES neighbor can be reached |
|
This field is a three-column field. The first column indicates how the path was learned. It can be one of the following values: The second column indicates what version of the RTP protocol this neighbor is running. It can be one of the following values: The third column indicates how this path will be used. It can be one of the following values: In the sample output, there are two paths to Router4 with the same metric. These two paths will be used in a round-robin fashion, and the Token Ring path will be the next one of the two used. There is a third path to Router4 via the serial line, but this will not be used unless both of the other paths are lost. |
|
Age of this VINES neighbor table entry, in seconds. This entry will show an age of "n/a" for RTP Version 0 neighbors on WAN interfaces, when the interface has been configured for delta-only updates. In all other cases, this entry will contain a number. |
|
Distance to this neighbor. This normally is the same as the interface metric, but may be different because of network topology or router configuration. |
|
For all entries except placeholders, indicates the number of times that path was used to forward a packet. For placeholder entries, indicates the number of static routes that use the neighbor as the first hop. |
|
This section shows counters that are specific to a neighbor port that is running the RTP protocol only. If the neighbor has multiple interfaces, then multiple sections will show up in this part of the display. |
|
Identifies the network interface and full identifier for a neighbor port. |
|
Identifies whether or not the roll call timer is active for this neighbor, and if so, when it will expire. |
|
Indicates the number and type of RTP packets received from this neighbor port. |
|
This section shows counters that are specific to a neighbor port that is running the SRTP protocol. If the neighbor has multiple interfaces, then multiple sections will show up in this part of the display. |
|
Identifies the network interface and full identifier for a neighbor port. |
|
Identifies whether or not the reassembly timer is active for this neighbor, and if so, when it will expire. |
|
Identifies whether or not the retry timer is active for this neighbor, and if so, when it will expire. |
|
Indicates the number, type, and sequence number of matching SRTP packets received from this neighbor port. |
|
Indicated the number and type of SRTP packets transmitted explicitly to this neighbor port. |
clear vines neighbor
clear vines route
show vines cache
vines host
vines neighbor
vines update deltas
vines update interval
To display the contents of the VINES routing table, use the show vines route EXEC command.
If no keywords or arguments are specified, all entries in the routing table are displayed.
The following is sample output from the show vines route command. This sample shows all entries in the VINES routing table.
Table 15-7 describes the fields shown in the display.
Table 15-7 Show VINES Route Field Descriptions
| Field | Description |
|---|---|
Version number of the VINES routing table. This number is incremented each time a server or route is added to or deleted from this table. |
|
Name or number of the remote network. Networks take the name of the server that defines the network. |
|
This field is a series of single-column fields. The first column indicates how the route was learned. It can be one of the following values:
The second column indicates what version of the RTP protocol this router is running. It can be one of the following values:
An asterisk in the third column indicates that this route will be used next when forwarding a frame to that server. The fourth column indicates whether that route will be used to forward a broadcast from a serverless network. It can be one of the following values: The fifth column contains the letter "S" if the route is in a suppression state. The sixth column contains the letter "h" if this path has a metric that is higher than the best metric for this neighbor. This indicates that the path is not eligible for use in load sharing. |
|
Age of this VINES routing table entry, in seconds. An age of n/a indicates the destination is accessible via a neighbor that is sending delta-only updates. Note that even though the neighbor entry for Pica has an age, there is no age available for its routing table entry or other routing entries reachable via Pica. This is because the periodic hello messages from Pica contain no routing information, only neighbor reachability information. |
|
Distance to this server. This normally is the distance to the neighbor router plus the distance advertised by that neighbor. This does not hold for static routes. |
|
Number of times this route has been used to forward a packet. |
|
Last known timestamp that originated from this server. If this field is not valid, as indicated by the following set of flags, then it will be zero. |
|
Local timestamp then this route entry was learned or last changed. |
|
This field is a series of bit flags presented as a hexadecimal number. The following are the defined values:
|
clear vines neighbor
clear vines route
show vines cache
vines route
vines update deltas
vines update interval
To display information about the router's application layer support, use the show vines service EXEC command.
The following is sample output from the show vines service command:
Table 15-8 describes the fields shown in the display.
Table 15-8 Show VINES Services Field Descriptions
The following is sample output from the show vines service command using the fs, nsm, ss, and vs keywords:
Table 15-9 describes the fields shown in the displays.
Table 15-9 Show VINES Services Field Descriptions
vines time access-group
vines time participate
vines time set-system
vines time use-system
To display the statistics maintained about VINES protocol traffic, use the show vines traffic EXEC command.
If no interface is specified, values for all interfaces are displayed.
The following is sample output from the show vines traffic command:
Table 15-10 describes the fields shown in the display.
Table 15-10 Show VINES Traffic Field Descriptions
clear vines traffic
vines serverless
To determine the path that a packet takes when traversing a VINES network, use the trace EXEC command.
The trace EXEC command supports the Banyan traceroute function. This enables trace requests on a VINES network to reach all servers on the network.
This command does not produce the names of any VINES servers that are traversed.
Table 15-11 explains the trace test characters when you specify the oldvines keyword.
Table 15-11 Trace Test Characters
The following is sample output from the VINES trace command when you specify the vines keyword:
The following is sample output from the VINES trace command when you specify the oldvines keyword:
To apply an access list to an interface, use the vines access-group interface configuration command. To remove the access list, use the no form of this command.
Description
The vines access-group command applies an access list created with the vines access-list command to an interface.
You can apply only one access list to an interface.
In the following example, access list 1 is applied to Ethernet interface 0:
vines access-list (standard)
vines access-list (extended)
To specify a standard VINES access list, use this version of the vines access-list global configuration command. To remove the access list, use the no form of this command.
Number of the access list. This is a decimal number from 1 to 100. |
|
VINES protocol ID number or name. It can be a value from 1 to 255 or one of the following protocol keywords: |
|
Address of the network from which the packet is being sent. This is a 6-byte hexadecimal number in the format network:host, where network is 4 bytes and host is 2 bytes. |
|
Mask to be applied to source-address. This is a 6-byte hexadecimal value. Place ones in the bit positions you want to mask. These bits correspond to the bit in the address that should be ignored. |
|
(Optional) Number of the local port from which the packet is being sent. This argument is required when the protocol specified is IPC or SPP, and is not accepted when any other protocol is specified. It can be a number from 0x0000 through 0xFFFF. Well-known local port numbers have values from 0x0001 through 0x01FF. Transient local port numbers have values from 0x0200 through 0xFFFE. Table 15-12 in the "Usage Guidelines" section lists some IPC port numbers. |
|
Address of the network to which the packet is being sent. This is a 6-byte hexadecimal number in the format network:host, where network is 4 bytes and host is 2 bytes. |
|
Mask to be applied to destination-address. This is a 6-byte hexadecimal value. Place ones in the bit positions you want to mask. These bits correspond to the bits in the address that should be ignored. |
|
(Optional) Number of the local port to which the packet is being sent. This argument is required when the protocol specified is IPC or SPP, and is not accepted when any other protocol is specified. It can be a number from 0x0000 through 0xFFFF. Well-known local port numbers have values from 0x0001 through 0x01FF. Transient local port numbers have values from 0x0200 through 0xFFFE. Table 15-12 in the "Usage Guidelines" section following lists some IPC port numbers. |
No standard VINES access list is specified.
A standard VINES access list filters packets based on their protocol, source and destination addresses, and source and destination address masks, and optionally on their source and destination ports.
Use the vines access-group command to apply an access list to an interface.
Keep the following in mind when configuring VINES network access control:
If you specify a protocol type of IPC, the port (either source-port or destination-port) can be one of the values shown in Table 15-12.
Table 15-12 Some VINES IPC Port Numbers
In the following example, the first line prohibits any communication on StreetTalk port (port number 0xF); the second line permits all other communication:
The following example filters all mail service on Ethernet interface 0 and permits all other traffic:
A dagger () indicates that the command is documented in another chapter.
priority-list protocol
show vines access
vines access-group
vines access-list (extended)
vines access-list (simple)
To create an extended VINES access list, use this version of the vines access-list global configuration command. To remove an extended access list, use the no form of this command.
Number of the access list. This is a decimal number from 101 to 200. |
|
VINES protocol ID number or name. The number can be a value from 1 to 255 or one of the following protocol keywords:
|
|
Address of the network from which the packet is being sent. This is a 6-byte hexadecimal number in the format network:host, where network is 4 bytes and host is 2 bytes. |
|
Mask to be applied to source-address. This is a 6-byte hexadecimal value. Place ones in the bit positions you want to mask. These bits correspond to the bits in the address that should be ignored. |
|
Number of the local port from which the packet is being sent. This argument is required when the protocol specified is IPC or SPP, and is not accepted when any other protocol is specified. It can be a number from 0x0000 through 0xFFFF. Well-known local port numbers have values from 0x0001 through 0x01FF. Transient local port numbers have values from 0x0200 through 0xFFFE. Table 15-13 in the "Usage Guidelines" section lists some IPC port numbers. |
|
(Optional) Mask to be applied to source-port. This argument is required when the protocol specified is IPC or SPP, and is not accepted when any other protocol is specified. It can be a number from 0x0000 through 0xFFFF. These bits correspond to the bits in the port that should be ignored. |
|
VINES address of the network to which the packet is being sent. This is a 6-byte hexadecimal number in the format network:host, where network is 4 bytes and host is 2 bytes. |
|
Mask to be applied to destination-address. This is a 6-byte hexadecimal value. Place ones in the bit positions you want to mask. These bits correspond to the bits in the address that should be ignored. |
|
Number of the local port to which the packet is being sent. This argument is required when the protocol specified is IPC or SPP, and is not accepted when any other protocol is specified. It can be a number from 0x0000 through 0xFFFF. Well-known local port numbers have values from 0x0001 through 0x01FF. Transient local port numbers have values from 0x0200 through 0xFFFE. Table 15-13 in the "Usage Guidelines" section lists some IPC port numbers. |
|
(Optional) Mask to be applied to destination-port. This argument is required when the protocol specified is IPC or SPP, and is not accepted when any other protocol is specified. It can be a number from 0x0000 through 0xFFFF. These bits correspond to the bits in the port that should be ignored. |
No extended VINES access list is specified.
An extended VINES access list filters packets based on their protocol, source and destination addresses, and source and destination address masks, and optionally on their source and destination ports, and source and destination port masks. This differs from the standard access list filters in that you can specify port masks.
Use the vines access-group command to assign an access list to an interface.
Keep the following in mind when configuring VINES network access control:
If you specify a protocol type of IPC, the port (either source-port or destination-port) can be one of the values shown in Table 15-13.
Table 15-13 Some VINES IPC Port Numbers
In the following example, the first line prohibits communication from any client process to the service on IPC port 0x14; the second line permits all other communication:
A dagger () indicates that the command is documented in another chapter.
priority-list protocol
show vines access
vines access-group
vines access-list (extended)
vines access-list (simple)
To create a simple VINES access list, use this version of the vines access-list global configuration command. To remove a simple access list, use the no form of this command.
No simple VINES access list is specified.
A simple VINES access list filters packets based on their source address and source address mask. These access lists are used to decide which stations to accept time updates from.
Use the vines access-group command to assign an access list to an interface.
Keep the following in mind when configuring VINES network access control:
The following example defines an access list that accept time updates only from the stations on networks 30015800 and 30004355; it defines time updates from all other sources:
show vines access
vines access-group
vines access-list (standard)
vines access-list (simple)
vines time access-group
vines time participate
vines time set-system
vines time use-system
To enable the processing of ARP packets, use the vines arp-enable interface configuration command. To disable the processing of ARP packets, use the no form of this command.
The interface always responds to ARP and SARP requests.
Client systems on VINES networks are assigned network addresses dynamically. When a VINES client boots, it has no knowledge of their addresses and preferred servers. Immediately after it initializes its hardware interface, the client sends broadcast requests asking a server to provide it with a network-layer address. In a network that has a server, our routers do not normally respond to these broadcast requests. However, on a network that has only clients and no servers (called a serverless network), the router does need to respond to the broadcast requests so that all the clients on that serverless network can acquire network addresses. By default, the router will respond to ARP requests and assign addresses to network clients only if there is no VINES server present on that network segment. When it does, the router then acts as a network communication service provider for the client. You may configure the router to respond to these requests even if a VINES servers is present, or never to respond to these requests. If the router assigns an address, it will generate a unique network number based on its own VINES address.
A VINES file server must still be present somewhere on the network in order for the client to continue the booting process.
The following example configures a router when Ethernet interface 1 is a network that does not contain any VINES servers:
The following example configures a router to always provide ARP service on Ethernet interface 1, even when VINES servers are present on that network:
vines propagate
vines serverless
To display VINES addresses in decimal notation, use the vines decimal global configuration command. To return to displaying the addresses in hexadecimal, use the no form of this command.
This command has no arguments or keywords.
Addresses are displayed in hexadecimal.
When displaying addresses, the router always uses a name if one has been configured via the
vines host command. The vines decimal command affects the radix in which the address is presented when a name is not available.
The following example displays VINES addresses in decimal:
clear vines cache
clear vines neighbor
clear vines route
show vines cache
vines host
To set the MAC-level encapsulation used for VINES broadcast packets, use the vines encapsulation interface configuration command. To disable encapsulation, use the no form of this command.
ARPA encapsulation for Ethernet
VINES Token Ring encapsulation for Token Ring
SNAP encapsulation for all other media
You can choose a MAC-level encapsulation type for each Ethernet, Token Ring, or IEEE 802.2 interface.
Setting the MAC-level encapsulation type with the vines encapsulation command affects broadcast packets sent by the router. The router keeps track of which encapsulation is used by each of its neighbors and uses the same style of encapsulation when talking directly to a neighbor.
You should not use this command with the current versions of VINES software that are available. This command is present for future interoperability when Banyan begins using encapsulations other than the current default ones.
The following example configures IEEE 802.2 SNAP encapsulation on Ethernet interface 0:
To associate a host name with a VINES address, use the vines host global configuration command. To delete the association, use the no form of this command.
Hosts are displayed by address.
The router maintains a table of the mappings between host names and addresses.
When displaying addresses, the router uses the name instead of the numerical address if you have configured one with the vines host command.
Our software provides only static name-to-address bindings for the VINES protocol. This is completely separate from Banyan's distributed naming system, StreetTalk. The router does not learn names from StreetTalk, nor does the router provide names to StreetTalk.
The following example assigns names to four VINES servers:
clear vines neighbor
clear vines route
show vines host
vines decimal
To filter the information contained in routing messages received from other stations, use the vines input-network-filter interface configuration command. To disable this filtering, use the no form of this command.
VINES routing messages contain topological entries that allow service and client nodes to select the best paths to destinations. This command provides filtering ability to an administrator so that they may selectively determine which routing entries should be accepted from other routers and which routing entries should be dropped. This command may be useful in enforcing administrative policies of local server usage.
The following example prevents a route to one specific server from ever being learned via interface Ethernet 0:
To filter received routing messages based upon the address of the sending station, use the vines input-router-filter interface configuration command. To disable this filtering, use the no form of this command.
VINES routing messages contain topological entries that allow service and client nodes to select the best paths to destinations. This command provides filtering ability to an administrator so that they may selectively determine the routers from which routing entries will be accepted.
The following example prevents the router from ever learning routing information from one specific server on interface Ethernet 0:
To enable VINES routing on an interface, use the vines metric interface configuration command. To disable VINES routing, use the no form of this command.
(Optional) Integer cost value associated with the interface. It is optional for all interface types. If you omit whole, the router automatically chooses a reasonable value. These values are listed in Table 15-14 in the "Usage Guidelines" section. For additional information, refer to the discussion and table in the "Usage Guidelines" section. If whole is zero, then a fractional portion must be supplied. |
|
(Optional) Fractional cost value associated with the interface expressed in 10,000ths. It is optional for all interface types, but may only be present if a whole number portion is specified. This number will be rounded to the nearest 1/16. If you omit both whole and fractional numbers, the router automatically chooses a reasonable value. These values are listed in Table 15-14 in the "Usage Guidelines" section. For additional information, refer to the discussion and table in the "Usage Guidelines" section. |
The metric is the cost value associated with the interface media type. It is generally inversely proportional to the speed of the interface. The lower the delay metric, the more like it is that the router will use that interface.
Our router automatically chooses a reasonable metric. These numbers match as closely as possible the numbers a Banyan server would choose for an interface of the same type and speed.
When enabling VINES for a serial interface, you should keep in mind that the VINES metric is based upon the configured bandwidth for the interface. To insure that the router selects the correct VINES metric, you need to make sure that the correct bandwidth has been configured. To do this, first issue the show interface command to determine the speed of the interface. Then issue the bandwidth command to set the bandwidth rate that is appropriate for that interface type and speed.After that, issue the vines metric command and the router will choose a metric appropriate to that speed. If you do not issue the bandwidth command first, you will need to either reissue the vines metric command or issue it with a metric number to get an appropriate metric.
Banyan servers use these metrics to compute timeouts when communicating with other hosts. If you do specify a metric, be careful that you do not set this number too high or too low. Doing so could disrupt the normal function of the Banyan servers.
Table 15-14 lists some example delay metric values.
Table 15-14 Example Delay Metric Values
| Interface Type | Old Format | New Internal Format | New Configuration File Format | Seconds |
|---|---|---|---|---|
The following example enables VINES routing on Ethernet interface 0 and sets the metric to 2:
The following example enables VINES routing on FDDI interface 0 and sets the metric to 0.25:
A dagger () indicates that the command is documented in another chapter.
bandwidth
vines routing
vines update deltas
vines update interval
To specify a static path to a neighbor station, use the vines neighbor interface configuration command. To remove a static path from the neighbor table, use the no form of this command.
No static paths are specified.
You can configure static neighbor entries only on Ethernet, FDDI, and Token Ring interfaces.
The decision to use a static path or a dynamic path is always determined by the relative metric numbers.
Be careful when assigning static paths. If a static path is assigned with a better metric than the dynamic paths and the link associated with the static path is lost, traffic may stop being forwarded, even though an alternative path might be available.
The metric is the cost value associated with the interface media type. It is generally inversely proportional to the speed of the interface. The lower the delay metric, the more like it is that the router will use that interface.
This command is useful for testing VINES networks with test equipment that does not generate hello packets.
Table 15-15 lists some example delay metric values.
Table 15-15 Example Delay Metric Values
| Interface Type | Old Format | New Internal Format | New Configuration File Format | Seconds |
|---|---|---|---|---|
The following example defines a static path to the neighbor station at address 12345678:0001 using ARPA encapsulation:
clear vines neighbor
show vines neighbor
show vines route
vines route
To filter the information contained in routing updates transmitted to other stations, use the vines output-network-filter interface configuration command. To disable this filtering, use the no form of this command.
VINES routing messages contain topological entries that allow service and client nodes to select the best paths to destinations. This command provides filtering ability to an administrator so that they may selectively determine which routing entries should be passed on to other routers. This command may be useful in enforcing administrative policies of local server usage.
The following example prevents all routes from being advertised to interface Ethernet 0 except the route to one single server:
To modify how routers forward a broadcast packet, use the vines propagate interface configuration command. To return to the default forwarding scheme, use the dynamic form of this command.
If you specify the vines propagate command with no keywords, broadcast messages are always propagated on the interface.
The vines propagate command affects how the router decides whether to forward a broadcast packet out an interface. The normal decision is based on the settings of both the "hop count" and "class" fields of the VINES IP header, and also whether or not there are any servers present on any of the local network segments. In the default configuration, the router first looks to see if there are any local servers, and if so, follows the normal rules of VINES IP and forwards the broadcast out this interface based upon the "hop count" and the "class" field. If there are no local servers, then the router looks only at the "hop count" field before forwarding the broadcast out this interface. Enabling this command with no argument tells the router to always ignore the "class" field and make the forwarding decision based solely upon the "hop count" field. The no form of this command tells the router to always examine both the "hop count" and "class" fields.
The following example always ignores the "class" field of the VINES IP header when deciding whether to forward a broadcast packet on interface Serial0:
vines arp-enable
vines serverless
To determine how frequently a router sends an RTP redirect message on an interface, use the vines redirect interface configuration command. To restore the default, use the no form of this command.
VINES routing redirect packets contain topological entries that allow service and client nodes to select the best paths to destinations. When a service node determines that it should not be forwarding packets between two nodes, it sends a redirect packet to the sending node informing it of the better path.
The following example prevents redirect messages from ever being sent on Ethernet interface 0:
To specify a static route to a server, use the vines route global configuration command. To remove a static route from the routing table, use the no form of this command.
No static routes are specified.
The decision to use a static route or a dynamic route is always determined by the relative metric numbers.
Be careful when assigning static routes. If a static route is assigned with a better metric than the dynamic routes and the links associated with the static routes are lost, traffic may stop being forwarded, even though an alternative route might be available.
The following example establishes a static route to the server at ABCD1234:
clear vines neighbor
clear vines route
show vines neighbor
show vines route
vines neighbor
To enable fast switching, use the vines route-cache interface configuration command. To disable fast switching, use the no form of this command.
The command has no arguments or keywords.
The vines route-cache command enables the fast switching of VINES packets being transmitted out of the interface. However, forwarding of broadcast packets and responding to packets destined for the local router still occurs at the process level. When fast switching is disabled, all packets are forwarded at the process level.
Fast switching allows higher throughput by switching a packet using a cache created by previous packets. Fast switching provides load sharing on a per-packet basis just as slow switching does. Fast switching is enabled by default on all interfaces where it is supported. It is not supported on very old Ethernet, serial, and Token Ring interfaces, nor is it supported on serial interfaces using an encapsulation other than HDLC.
Packet transfer performance is generally better when fast switching is enabled. However, you may want to disable fast switching in order to save memory space on interface cards and help avoid congestion when high-bandwidth interfaces are writing large amounts of information to low-bandwidth interfaces.
When fast switching is enabled, the router maintains a fast-switching cache table. When transmitting a packet that is eligible to be fast switched, the router first checks the fast-switching cache table. If it finds an entry for the destination, the router uses that path. Otherwise, it searches the standard routing table and places the route it finds into the fast-switching cache table. The next time the router receives a packet for that destination, it uses the route in the fast-switching cache table.
The following example disables fast switching on serial interface 0:
clear vines cache
show vines cache
show vines route
To enable VINES routing, use the vines routing global configuration command. To disable VINES routing, use the no form of this command.
Enabling VINES routing with the vines routing command starts both the VINES RTP and SRTP protocols. The router software dynamically determines which version of the VINES routing protocol stations on the network are using and then uses one or the other, or both protocols, as appropriate.
If a router contains Ethernet or FDDI interfaces, you do not need to specify an address because the router automatically maps itself into the VINES address space that is reserved for our routers. If you do specify an address, the router will use the specified address.
If a router contains only Token Ring interfaces (or Token Ring and serial interfaces), either the Token Ring interface must be fully initialized before you issue the vines routing command or you must specify an address in the vines routing command. This is because Token Ring interfaces have MAC addresses of 0000.0000.0000 until they are fully initialized.
Banyan has assigned us a portion of the overall VINES network number space. This portion is the set of all numbers that begin with the first 11 bits (of the 32) of 0011 0000 000. This number set appears in all our displays as a hexadecimal number beginning with 0x300 or 0x301. Routers attempt to automatically map themselves into our number space based upon the first nonzero Ethernet, Token Ring, or FDDI address found.
In theory, address conflicts are impossible, because VINES servers use their Banyan-assigned, unique key serial numbers as their network numbers and use a subnetwork number of one. Because the keys are unique, the server addresses are unique. VINES clients do not have addresses per se. The clients use a modified version of the address of the first file server found on the physical network: they assume the server's network number and are assigned a subnetwork number by that server. This address-assignment scheme means that it is likely that two clients on the same physical LAN will have different addresses. It requires that the router keep a cache of local neighbors as well as a cache of routing entries.
If you do not specify a network address and the router cannot compute one from a MAC address, the router selects a random address. There is no guarantee that this will be a unique address.
If you find that two routers have the same VINES network address, you should issue the vines routing recompute command on both routers. When recomputing its address, the router uses the same method used when originally determining its network address. If you issue this command on a router on which you have enabled the processing of ARP packets (with the vines arp-enable command) and if the router's address changes when it is recomputed, any clients that received their VINES network addresses from the router will lose all network connectivity, and you will have to reboot them.
Older implementations of out software mapped themselves to numbers beginning with 0xF80. This was done before Banyan made the address assignment.
The following example enables VINES routing on interface Ethernet 0:
To configure a Banyan VINES network that does not have a server, use the vines serverless interface configuration command. To disable this feature, use the no form of this command.
If all keywords are omitted, broadcasts are alwasy forwarded toward one server.
The vines serverless command provides special processing for certain broadcast packets and certain packets directed at the router.
When you have a Banyan VINES network that has no server, by default the router will provide special processing for certain broadcast packets and certain packets directed at the router. This is necessary for proper functioning of the clients on a network without a server. This special processing allows a client to find the services that are provided by a server on another network. The dynamic nature of this processing allows the router to switch over from not providing serverless support to providing serverless support if the last server on a network fails. If you want the router to always provide serverless support, even when there are local servers present, you may override the default processing by issuing the vines serverless command with no argument. If you do not want the router to ever provide serverless support, you may also override the default in this way by issuing the no vines serverless command.
When the router receives a zero-hop broadcast on a serverless network, it does not follow the normal processing rules for VINES packets and discard the frames. Instead, it looks in its routing table for the nearest Banyan server. If this server is on a directly connected network, the router resends the broadcast message on that network as a MAC-level broadcast so that server and any others present can respond to it. If the nearest Banyan server is not on a directly connected network, the router resends the broadcast message on that network as a MAC-level unicast message directed at the first hop to that server. The next router will perform these same steps, assuming it is also configured for serverless support. The router can also be configured to always flood these broadcasts on all interfaces by using the command vines serverless broadcast. The decision on whether or not to flood is a trade-off between network bandwidth and finding more servers.
If you have configured this interface to forward towards a single destination, you may see which server has been selected as the forwarding target by looking at the output of the show vines route command. All servers on the same physical network as the target server will receive the broadcast.
The following example configures Ethernet interface 1, which is a network with no VINES servers:
Note that the vines serverless command is not necessary because the default setting is what is desired.
The following example configures Ethernet interface 1, which is a network with no VINES servers to always flood broadcasts to all other interfaces in the router:
The vines serverless command is necessary here because a nondefault setting is desired.
show vines route
vines arp-enable
vines propagate
To use split horizon when sending routing updates, use the vines split-horizon interface configuration command. To disable split horizon, use the no form of this command.
This command has no arguments or keywords.
The vines split-horizon command also affects whether broadcasts packets received on an interface are resent on the same interface.
The vines split-horizon command determines how much information is included in routing updates sent out an interface. It also determines whether received broadcasts will be retransmitted on the same interface. When you enable split horizon, routing updates sent out on a given interface will not include any information that was originally learned from that interface, and broadcasts will not be retransmitted on the receiving interface. This is because split horizon is designed for networks that are either broadcast networks, or are fully connected mesh networks. In these types of networks, resending this information is a waste of network bandwidth because all other stations on that network have already heard the information. Disabling split horizon will cause the router to include all information in routing updates, and to resend broadcast packets on the network from which they were received.
You can use this command on any interface, but generally it makes sense to use it only for X.25 and Frame Relay interfaces. You should disable split horizon on X.25 and Frame Relay networks that are not fully connected mesh topologies.
The following example disables split horizon on an X.25 network:
To enable Sequenced Routing Update Protocol (SRTP), use the vines srtp-enabled global configuration command. To disable SRTP, use the no form of this command.
This command has no arguments or keywords.
The router runs Banyan's Routing Update Protocol (RTP) routing protocol only.
When SRTP is enabled, the router dynamically determines whether it needs to send RTP messages, SRTP messages, or both.
The following example enables SRTP on the router:
To control the servers from which the router will accept VINES network time, use the vines time access-group global configuration command. To accept VINES network time messages from any server, use the no form of this command.
The following example applies an access list to incoming time messages:
show vines service
vines access-list (simple)
vines time destination
vines time participate
vines time set-system
vines time use-system
To control the servers to which the router sends VINES network time, use the vines time destination global configuration command. To send VINES network time messages to all servers, use the no form of this command.
By default, the router sends VINES network time messages to the broadcast address.
You can enter the vines time destination command up to 20 times for 20 destination addresses.
The following example specifies the servers to receive VINES time messages:
show vines service
vines time access-group
vines time participate
vines time set-system
vines time use-system
To enable the router's participation in the synchronization of time across a VINES network, use the vines time participate global configuration command. To disable the router's participation in time synchronization, use the no form of this command.
This command has no arguments or keywords.
The router always listens to the time synchronization messages on the network, and it tracks the network time. This command controls only the sending of time synchronization messages by the router. This arrangement means that you can use the show vines services EXEC command to see the network time even if the router is not actively participating in time synchronization.
The following example disables the router's participation in the sending of VINES time messages:
show vines service
vines access-list (simple)
vines time access-group
vines time destination
vines time set-system
vines time use-system
To set the router's internal time based upon the received VINES network time, use the vines time set-system global configuration command. To uncouple the router's time from VINES network time, use the no form of this command.
This command has no arguments or keywords.
You should not use the vines time set-system command when running NTP on a router, because this command has no effect on these systems. NTP is considered to be a higher-priority clock than VINES, because it is a much more accurate timekeeping system.
The following example sets the router's time from received VINES time messages:
show vines service
vines access-list (simple)
vines time access-group
vines time destination
vines time participate
vines time use-system
To set VINES network time based upon the router's internal time, use the vines time use-system global configuration command. To uncouple VINES network time from the router's time, use the no form of this command.
This command has no arguments or keywords.
The vines time use-system command causes the router to import the locally available time source (such as NTP, the Cisco 7000 clock, or DNSIX time) into the VINES time world as an authoritative clock. This is most useful when running NTP on the router. The router appears to the VINES network as a server dialing the NIST clock.
When you specify the vines use-system command, VINES will extract the system time and propagate it into the VINES world only if the system time is valid. If you are running NTP, the system time becomes valid when NTP synchronizes with a master. If you are not running NTP, but you do have an internal clock (such as exists on the Cisco 7000 router), you can force that time to be valid by specifying the clock calendar-valid command. This will allow VINES to propagate time based upon the Cisco 7000's clock chip.
The following example sets VINES network time from the router's internal time:
A dagger () indicates that the command is documented in another chapter.
clock calendar-valid
show vines service
vines access-list (simple)
vines time access-group
vines time destination
vines time participate
vines time set-system
To modify the manner in which routing updates are sent, use the vines update deltas interface configuration command. To return to the default method, use the no form of this command.
This command has no arguments or keywords.
The vines update deltas command significantly modifies the way that routing information is propagated across the network.
On LAN media, using this command causes the router to stop transmitting and to stop expecting periodic routing updates. Instead, the router transmits and expects a periodic hello message. The difference between these two messages is whether routing information is included. The router will continue to send flash updates to inform its neighbors of any changes to current routing table information. This is the same frequency and type of routing updates used on LANs by VINES version 5.50, but our packet format differs from the VINES format.
On WAN media, using this command causes the router to transmit three normally spaced routing updates and then cease transmission. The router does not send periodic hello messages. The router will, however, continue to send flash updates to inform its neighbors of any changes to current routing table information. This is the same frequency and type of routing updates used on LANs by all versions of VINES, but our packet format differs from the VINES format.
The following example modifies the propagation of routing update information on the WAN interface connected to serial interface 0:
show vines interface
show vines neighbor
show vines route
vines metric
To modify the frequency at which routing updates are sent, use the vines update interval interface configuration command. To return to the default frequency, use the no form of this command.
The vines update interval command controls the interval at which the router sends routing updates. The routing update interval should be the same on all VINES-speaking entities on the same physical network.
For networks on which other vendors' entities are present, it is safe to use any setting in the range 30 to 100 seconds on networks. This is the range of update intervals supported by Banyan servers. You should use values outside of this range (with the exception of zero) only on networks that contain only our routers. You can use a value of zero on networks with only our routers or on WAN links connecting our routers and Banyan servers. In this configuration, you must also address application-level security requirements.
For Banyan VINES sites that support "change-only" updates on LAN networks, you can use the vines update interval command in LAN networks with both our routers and Banyan servers.
The following example sets the update interval on serial interface 0 to a value of 270 seconds:
show vines interface
show vines neighbor
show vines route
vines metric
Posted: Wed Jul 2 23:43:49 PDT 2003
All contents are Copyright © 1992--2003 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.