-
Router Products Configuration Guide
-
About This Manual
-
Router Product Overview
-
Understanding the User Interface
-
Loading System Images, Microcode Images, and Configuration File
-
Configuring Terminal Lines and Modem Support
-
Managing the System
-
Configuring ATM
-
Configuring DDR
-
Configuring SMDS
-
Configuring X.25
-
Configuring Apollo Domain
-
Configuring AppleTalk
-
Configuring Banyan VINES
-
Configuring DECnet
-
Configuring ISO-CLNS
-
Configuring XNS
-
Configuring Transparent Bridging
-
Configuring Source-Route Bridging
-
Configuring Remote Source-Route Bridging
-
Configuring DLSw+
-
Configuring STUN and BSTUN
-
Configuring LLC2 and SDLC Parameters
-
Configuring DSPU and SNA Service Point
-
Configuring APPN
-
Table Of Contents
Configuring Source-Route Bridging
Source-Route Bridging Overview
Cisco's Implementation of Source-Route Bridging
Configure Source-Route Bridging
Configure a Multiport Bridge Using a Virtual Ring
Define a Ring Group in SRB Context
Enable SRB and Assign a Ring Group to an Interface
Configure Fast-Switching SRB over FDDI
Enable the Forwarding and Blocking of Spanning-Tree Explorers
Enable the Automatic Spanning-Tree Function
Configure Bridging of Routed Protocols
Configure the RIF Timeout Interval
Configure Translation between SRB and Transparent Bridging Environments
Enable Bridging between Transparent Bridging and SRB
Enable Translation Compatibility with IBM 8209 Bridges
Enable Token Ring LLC2-to-Ethernet Conversion
Enable Standard Token Ring LLC2-to-Ethernet LLC2 Conversion
Enable the Proxy Explorers Feature on the Appropriate Interface
Specify Timeout and Enable NetBIOS Name Caching
Configure the NetBIOS Cache Name Length
Create Static Entries in the NetBIOS Name Cache
Specify Dead-Time Intervals for NetBIOS Packets
Configure LAN Network Manager Support
Configure LNM Software on the Management Stations to Communicate with the Router
Disable LAN Network Manager Functionality
Disable Automatic Report Path Trace Function
Prevent LNM Stations from Modifying Router Parameters
Enable Other LRMs to Change Router/Bridge Parameters
Apply a Password to an LNM Reporting Link
Change an LNM Reporting Interval
Enable the RPS Express Buffer Function
Configure NetBIOS Access Filters
Configure NetBIOS Access Filters Using Station Names
Configure Access Filters Using a Byte Offset
Configure Administrative Filters for Token Ring Traffic
Filter Frames by Protocol Type
Configure Access Expressions that Combine Administrative Filters
Alter Access Lists Used in Access Expressions
Enable or Disable the Source-Route Fast-Switching Cache
Enable or Disable the Source-Route Autonomous-Switching Cache
Establish Connection Timeout Interval
Establish SRB Interoperability with Specific Token Ring Implementations
Establish SRB Interoperability with IBM PC/3270 Emulation Software
Establish SRB Interoperability with TI MAC Firmware
Reporting Spurious Frame-Copied Errors
Monitor and Maintain the SRB Network
Basic SRB with Spanning-Tree Explorers Example
SRB with Automatic Spanning-Tree Function Configuration Example
Optimized Explorer Processing Configuration Example
SRB and Routing Certain Protocols Example
SRB with Multiple Virtual Ring Groups Example
FDDI SRB Configuration Example
SRB/FDDI Fast-Switching Example
Adding a Static RIF Cache Entry Example
Adding a Static RIF Cache Entry for a Two-Hop Path Example
SR/TLB for a Simple Network Example
SR/TLB with Access Filtering Example
NetBIOS Support with a Static NetBIOS Cache Entry Example
LNM for a Simple Network Example
LNM for a More Complex Network Example
NetBIOS Access Filters Example
Filtering Bridged Token Ring Packets to IBM Machines Example
Administrative Access Filters—Filtering SNAP Frames on Output Example
Creating Access Expressions Example
Configuring Source-Route Bridging
Our bridging software includes source-route bridging (SRB) capability. A source-route bridge connects multiple physical Token Rings into one logical network segment. When the network segment bridges only Token Ring media to provide connectivity, it is called source-route bridging. When the network bridges Token Ring, and some sort of non-Token Ring media is introduced into the bridged network segment, it is called remote source-route bridging (RSRB).
This chapter describes SRB configuration tasks. For a discussion of RSRB configuration tasks, refer to the chapter "Configuring Remote Source-Route Bridging" in the "IBM Networking" section of this document.
The source-route bridging feature enables our router/bridge to simultaneously act as a Level 3 router and a Level 2 source-route bridge. Thus, protocols such as Novell's Internetwork Packet Exchange (IPX) or Xerox Network Systems (XNS) can be routed on Token Rings, while other protocols such as Systems Network Architecture (SNA) or NetBIOS are source-route bridged.
For a complete description of the commands mentioned in this chapter, refer to the chapter "Source-Route Bridging Commands" in the Router Products Command Reference publication.
Source-Route Bridging Overview
Source-route bridging technology is a combination of bridging and routing functions. A source-route bridge is allowed to make routing decisions based upon the contents of the Media Access Control (MAC) frame header. Keeping the routing function at the MAC, or Level 2, layer allows the higher-layer protocols to execute their tasks more efficiently and allows the local-area network (LAN) to be expanded without the knowledge of the higher-layer protocols.
As designed by IBM and the IEEE 802.5 committee, source-route bridges connect extended Token Ring LANs. A source-route bridge uses the routing information field (RIF) in the IEEE 802.5 MAC header of a datagram (see Figure 24-1) to determine which rings or Token Ring network segments the packet must transit. The source station inserts the RIF into the MAC header immediately following the source address field in every frame, giving this style of bridging its name. The destination station reverses the routing field to reach the originating station.
Figure 24-1 IEEE 802.5 Token Ring Frame Format
The information in a RIF is derived from explorer packets generated by the source node. These explorer packets traverse the entire source-route bridge network, gathering information on the possible paths the source node might use to send packets to the destination.
Unlike transparent spanning-tree bridging, which requires time to recompute topology in the event of failures, source-route bridging allows multiple, active paths through the network, which provides for more timely switches to alternate routes in the event of failure. Most importantly, source-route bridging places the burden of transmitting frames with the end stations by allowing them to determine the routes the frames take.
Cisco's Implementation of Source-Route Bridging
Cisco's source-route bridging software implementation includes the following features:
•
Provides configurable fast-switching software for source-route bridging.
•
•
•
•
•
•
•
•
•
SRB Configuration Task List
Perform the tasks in the following sections to configure source-route bridging:
•
•
•
•
•
•
See the end of this chapter for "SRB Configuration Examples."
Warning
Configure Source-Route Bridging
Our implementation of source-route bridging enables you to connect two or more Token Ring networks using either Token Ring or Fiber Distributed Data Interface (FDDI) media.
As designed by IBM and the IEEE 802.5 committee, when a router is configured as a source-route bridge, bridged traffic does not pass across non-Token Ring media, and only those protocols that are not being routed are source-route bridged. For example, if IPX routing is enabled on the router that is configured for source-route bridging, IPX datagrams will not be source-route bridged. However, datagrams for other nonrouted protocols will be source-route bridged. Our implementation of source-route bridging extends this definition.
A dual-port bridge is the simplest possible source-route bridging configuration. When configured as a dual-port bridge, the router serves to connect two Token Ring LANs. One LAN is connected through one port (Token Ring interface), and the other LAN is connected through the other port (also a Token Ring interface). shows a dual-port bridge.
Figure 24-2 Dual-Port Bridge
A dual-port bridge is a limitation imposed by IBM Token Ring chips; they can only process two ring numbers. If you have a router with two or more Token Ring interfaces, you can work around the two-ring number limitation. You can configure your router as multiple dual-port bridges or as a multiport bridge using a virtual ring.
You can define several separate dual-port bridges in the same router. However, the devices on the LANs cannot have any-to-any connectivity; that is, they cannot connect to every other device on the bridged LANs. Only the devices connected to the dual-port bridge can communicate with one another. shows two separate dual-port bridges (T0-T2 and T1-T3) configured on the same router.
Figure 24-3 Multiple Dual-Port Bridges
A better solution for overcoming the two-ring number limitation of IBM Token Ring chips is to configure a multiport bridge using a virtual ring. A virtual ring on a multiport bridge allows the router to interconnect three or more LANs with any-to-any connectivity; that is, connectivity between any of the devices on each of the three LANs is allowed. A virtual ring creates a logical Token Ring internal to the router that causes all the Token Rings connected to the router to be treated as if they are all on the same Token Ring. The virtual ring is called a ring group. shows a multiport bridge using a virtual ring.
Figure 24-4 Multiport Bridge Using a Virtual Ring
To take advantage of this virtual ring feature, each Token Ring interface on the router must be configured to belong to the same ring group. For information about configuring a multiport bridge using a virtual ring, see the "Configure a Multiport Bridge Using a Virtual Ring" section later in this chapter.
Our implementation of SRB expands the basic functionality to allow autonomous switching of SRB network traffic for FDDI interfaces (see ), adding counters to SRB accounting statistics, and implementing process-level switching of SRB over FDDI. This functionality provides a significant increase in performance for Token Rings interconnected across an FDDI backbone.
Note
Figure 24-5 Autonomous FDDI SRB
You can configure the router for source-route bridging by performing the tasks in one of the first three sections and optionally, the tasks in the last section:
•
•
•
•
Configure a Dual-Port Bridge
A router equipped with Token Ring cards is by default a Token Ring host, and SRB is disabled by default. To configure a dual-port bridge that connects two Token Rings, you must enable source-route bridging on each of the Token Ring interfaces that connect to the two Token Rings. To enable source-route bridging, perform the following task in interface configuration mode for each of the Token Ring interfaces:
Enable local source-route-bridging on a Token Ring interface.
source-bridge local-ring bridge-number target-ring
For multiple dual-port source-route bridges, you would repeat this task for each Token Ring interface that is part of a dual-port bridge. If you wanted your network to use only source-route bridging, you could connect as many of these routers via Token Rings as you needed. Remember, to use source-route bridging requires you bridge only Token Ring media.
Note
Configure a Multiport Bridge Using a Virtual Ring
To configure a source-route bridge to have more than two network interfaces, you must perform the following tasks in the specified order:
•
•
Once you have completed these tasks, the router acts as a multiport bridge not as a dual-port bridge.
Note
Define a Ring Group in SRB Context
Because all IBM Token Ring chips can only process two ring numbers, we have implemented the concept of a ring group or virtual ring. A ring group is a collection of Token Ring interfaces in one or more routers that share the same ring number. This ring number is used just like a physical ring number, showing up in any route descriptors contained in packets being bridged. Within the context of a multiport bridge that uses source-route bridging rather than remote source-route bridging (RSRB), the ring group resides in the same router. See the "Configure Remote Source-Route Bridging" chapter to compare ring groups in the SRB and RSRB context.
A ring group must be assigned a ring number that is unique throughout the network. It is possible to assign different Token Ring interfaces on the same router to different ring groups, if, for example, you plan to administer them as interfaces in separate domains.
To define or remove a ring group, perform one of the following tasks in global configuration mode:
Define a ring group.
source-bridge ring-group ring-group
Remove a ring group.
no source-bridge ring-group ring-group
Enable SRB and Assign a Ring Group to an Interface
After you have defined a ring group, you must assign that ring group to those interfaces you plan to include in that ring group. An interface can only be assigned to one ring group. To enable any-to-any connectivity among the end stations connected through this multiport bridge, you must assign the same target ring number to all Token Ring interfaces on the router.
To enable SRB and assign a ring group to an interface, perform the following task in interface configuration mode:
Enable source-route-bridging and assign a ring group to a Token Ring interface.
source-bridge local-ring bridge-number target-ring
Configure FDDI SRB
To configure autonomous FDDI SRB, perform the following tasks, beginning in global configuration mode:
Configure an FDDI interface.
interface fddi slot/port1
Enable source-route bridging.
source-bridge local-ring bridge-number target-ring
Enable autonomous switching.
source-bridge route-cache cbus
1 This command is documented in the "Interface Commands" chapter of the Router Products Command Reference Publication.
Note
Configure Fast-Switching SRB over FDDI
Fast-Switching SRB/FDDI enhances performance where autonomous switching is not possible. For example, if you want to use access-lists, fast-switching SRB/FDDI provides fast performance and access-list filters capability.
To configure fast-switching SRB/FDDI perform the following tasks, beginning in global configuration mode:
Configure an FDDI interface.
interface fddi slot/port1
Enable source-route bridging.
source-bridge local-ring bridge-number target-ring
Enable source-bridge spanning.
source-bridge spanning
Enable fast-switching.
source-bridge route-cache
Enable the collection and use of RIF information.
multiring protocol-keyword
1 This command is documented in the "Interface Commands" chapter of the Router Products Command Reference Publication.
Enable the Forwarding and Blocking of Spanning-Tree Explorers
When trying to determine the location of remote destinations on a source-route bridge, the source device will need to send explorer packets. Explorer packets are used to collect RIF information. The source device can send spanning-tree explorers or all-routes explorers. Note that some older IBM devices only generate all-routes explorer packets, but many newer IBM devices are capable of generating spanning-tree explorer packets.
A spanning-tree explorer packet is an explorer packet that is sent to a defined group of nodes that comprise a statically configured spanning tree in the network. In contrast, an all-routes explorer packet is an explorer packet that is sent to every node in the network on every path.
Forwarding all-routes explorer packets is the default. However, in complicated source-route bridging topologies, using this default can generate an exponentially large number of explorers that are traversing the network. The number of explorer packets becomes quite large because duplicate explorer packets are sent across the network to every node on every path. Eventually each explorer packet will reach the destination device. The destination device will respond to each of these explorer packets. It is from these responses that the source device will collect the RIF and determine which route it will use to communicate with the destination device. Usually, the route contained in the first returned response will be used.
The number of explorer packets traversing the network can be reduced by sending spanning-tree explorer packets. Spanning-tree explorer packets are sent to specific nodes; that is, to only the nodes on the spanning tree, not to all nodes in the network. You must manually configure the spanning-tree topology over which the spanning-tree explorers are sent. You do this by configuring which interfaces on the routers will forward spanning-tree explorers and which interfaces will block them.
To enable forwarding of spanning-tree explorers on an outgoing interface, perform the following task in interface configuration mode:
Enable the forwarding of spanning-tree explorer packets on an interface.
source-bridge spanning
Note
To block forwarding of spanning tree explorers on an outgoing interface, perform the following task in interface configuration mode:
Enable the Automatic Spanning-Tree Function
The automatic spanning tree function supports automatic resolution of spanning trees in SRB networks, which provides a single path for spanning explorer frames to traverse from a given node in the network to another. Spanning explorer frames have a single-route broadcast indicator set in the routing information field. Port identifiers consist of ring numbers and bridge numbers associated with the ports. The spanning tree algorithm for SRB does not support Topology Change Notification BDPU.
Note
To create a bridge group that runs an automatic spanning-tree function compatible with the IBM SRB spanning-tree implementation, perform the following task in global configuration mode:
Create a bridge group that runs the automatic spanning-tree function.
bridge bridge-group protocol ibm
To enable the automatic spanning-tree function for a specified group of bridged interfaces, perform the following task in interface configuration mode:
Enable the automatic spanning-tree function on a group of bridged interfaces.
source-bridge spanning bridge-group
To assign a path cost for a specified interface, perform the following task in interface configuration mode:
Assign a path cost for a specified group of bridged interfaces.
source-bridge spanning bridge-group path-cost path-cost
Note
See the end of this chapter for an example of source-route bridging with the automatic spanning-tree function enabled.
Limit the Maximum SRB Hops
You can minimize explorer storms if you limit the maximum number of source-route bridge hops. For example, if the largest number of hops in the best route between two end stations is six, it might be appropriate to limit the maximum source-route bridging hops to six to eliminate unnecessary traffic. This setting affects spanning-tree explorers and all-routes explorers sent from source devices.
To limit the number of SRB hops, perform one of the following tasks in interface configuration mode:
Configure Bridging of Routed Protocols
Source-route bridges use MAC information, specifically the information contained in the routing information field (RIF), to bridge packets. A RIF contains a series of ring and bridge numbers that represent the possible paths the source node might use to send packets to the destination. Each ring number in the RIF represents a single Token Ring in the source-route bridged network and is designated by a unique 12-bit ring number. Each bridge number represents a bridge that is between two Token Rings in the SRB network and is designated by a unique 4-bit bridge number. The information in a RIF is derived from explorer packets traversing the source-route bridged network. Without the RIF information, a packet could not be bridged across a source-route bridged network. For more information about RIFs and their format, refer to the Internetworking Technology Overview publication.
Unlike source-route bridges, Level 3 routers use protocol-specific information (for example Novell IPX or XNS headers) rather than MAC information to route datagrams. As a result, the router software default for routed protocols is to not collect RIF information and to not be able to bridge routed protocols. However, if you want the router to bridge routed protocols across a source-route bridged network, the router must be able to collect and use RIF information to bridge packets across a source-route bridged network. You can configure the router to append RIF information to routed protocols so that routed protocols can be bridged. shows a network topology in which you would want to use this feature.
Figure 24-6 Topology for Bridging Routed Protocols across a Source-Route Bridged Network
To configure the router to bridge routed protocols, you must perform the task in the first section, and optionally, one or both of the tasks in the other sections as follows:
•
Enable Use of the RIF
You can configure the router so that it will append RIF information to the routed protocols. This allows routed protocols to be bridged across a source-route bridged network. The routed protocols that you can bridge are as follows:
•
•
•
•
•
•
•
•
Enable use of the RIF only on Token Ring interfaces on the router.
To configure the router to append RIF information, perform the following task in interface configuration mode:
Enable collection and use of RIF information.
multiring {protocol-keyword [all-routes | spanning] | all | other}
For an example of how to configure the router to bridge routed protocols, see the "SRB and Routing Certain Protocols Example" section later in this chapter.
Configure a Static RIF Entry
If a Token Ring host does not support the use of IEEE 802.2 TEST or XID datagrams as explorer packets, you might need to add static information to the RIF cache of the router/bridge.
To configure a static RIF entry, perform the following task in global configuration mode:
Enter static source-route information into the RIF cache.
rif mac-address rif-string {interface-name | ring-group ring}
Configure the RIF Timeout Interval
RIF information that can be used to bridge routed protocols is maintained in a cache whose entries are aged.
Note
To configure the number of minutes an inactive RIF entry is kept in the cache, perform the following tasks in global configuration mode:
Configure Translation between SRB and Transparent Bridging Environments
Source-route translational bridging (SR/TLB) is a router software feature that allows you to combine SRB and transparent bridging networks without the need to convert all of your existing source-route bridges to source-route transparent (SRT) nodes. As such, it provides a cost-effective connectivity path between Ethernets and Token Rings, for example.
Note
Overview of SR/TLB
You can bridge packets between an SRB domain and a transparent bridging domain. Using this feature, a software "bridge" is created between a specified virtual ring group and a transparent bridge group. To the source-route station, this bridge looks like a standard source-route bridge. There is a ring number and a bridge number associated with a ring that actually represents the entire transparent bridging domain. To the transparent bridging station, the bridge represents just another port in the bridge group.
When bridging from the SRB (typically, Token Ring) domain to the transparent bridging (typically, Ethernet) domain, the source-route fields of the frames are removed. The RIFs are cached for use by subsequent return traffic.
When bridging from the transparent bridging domain to the SRB domain, the router/bridge checks the packet to see if it has a multicast or broadcast destination or a unicast (single host) destination. If it is multicast, the packet is sent as a spanning-tree explorer. If it is a unicast destination, the router/bridge looks up the path to the destination in the RIF cache. If a path is found, it will be used; otherwise, the router/bridge will send the packet as a spanning-tree explorer.
An example of a simple topology is shown in Figure 24-7.
Figure 24-7 Example of a Simple SR/TLB Topology
Note
The following notes and caveats apply to all uses of SR/TLB:
•
•
•
CautionBridging between dissimilar media presents several problems that can prevent communication from occurring. These problems include bit order translation (or usage of MAC addresses as data), maximum transmission unit (MTU) differences, frame status differences, and multicast address usage. Some or all of these problems might be present in a multimedia bridged LAN and prevent communication from taking place. Because of differences in the way end nodes implement Token Ring, these problems are most prevalent when bridging between Token Rings and Ethernets or between Token Ring and FDDI LANs.
We currently know that problems occur with the following protocols when bridged between Token Ring and other media: Novell IPX, DECnet Phase IV, AppleTalk, VINES, XNS, and IP. Further, problems can occur with the Novell IPX and XNS protocols when bridged between FDDI and other media. We recommend that these protocols be routed whenever possible.
To enable SR/TLB, you must perform the task in the following section:
•
In addition, you can also perform the tasks in the following sections:
•
•
Enable Bridging between Transparent Bridging and SRB
Before enabling bridging, you must have completely configured your router using multiport SRB and transparent bridging. Once you have done this, establish bridging between transparent bridging and source-route bridging by performing the following task in global configuration mode:
Enable bridging between transparent bridging and SRB.
source-bridge transparent ring-group pseudo-ring bridge-num tb-group [oui]
Enable Translation Compatibility with IBM 8209 Bridges
To transfer data between IBM 8209 Ethernet/Token Ring bridges and routers running the SR/TLB software (to create a Token Ring backbone to connect Ethernets), perform the following task on each Token Ring interface in interface configuration mode:
Move data between IBM 8209 Ethernet/Token Ring bridges and routers running translational bridging software.
ethernet-transit-oui standard
Enable Token Ring LLC2-to-Ethernet Conversion
The routers support the following types of Token Ring to Ethernet frame conversions:
•
•
For most non-IBM hosts, Token Ring LLC2 frames can be translated in a straightforward manner into Ethernet 802.3 LLC2 frames. This is the default conversion on routers.
However, many Ethernet-attached IBM devices use nonstandard encapsulation of LLC2 on Ethernet. Such IBM devices, including PS/2s running OS/2 Extended Edition and RT-PCs, do not place their LLC2 data inside an 802.3 format frame, but rather place it into an Ethernet Type 2 frame whose type is specified as 0x80d5. This nonstandard format is called 0x80d5, named after the type of frame. This format is also sometimes called RT-PC Ethernet format because these frames were first widely seen on the RT-PC. Hosts using this nonstandard 0x80d5 format cannot read the standard Token Ring LLC2 to Ethernet 802.2 LLC frames.
To enable Token Ring LLC2 to Ethernet LLC2 conversion, you can perform one or both of the following tasks:
•
•
Enable 0x80d5 Processing
You can change the router's default translation behavior of translating Token Ring LLC to Ethernet 802.3 LLC to translate Token Ring LLC2 frames into Ethernet 0x80d5 format frames. To enable this nonstandard conversion, perform the following task in global configuration mode:
Change the router's Ethernet/Token Ring translation behavior to translate Token Ring LLC2 frames into Ethernet 0x80d5 format frames.
source-bridge enable-80d5
Enable Standard Token Ring LLC2-to-Ethernet LLC2 Conversion
After you change the router's translation behavior to perform Token Ring LLC2 frames into Ethernet 80d5 format frames, some of the non-IBM hosts in your network topology might use the standard Token Ring conversion of Token Ring LLC2 to 802.3 LLC2 frames. If this is the case, you can change the translation method of those hosts to use the standard translation method on a per-DSAP basis. The translation method for all the IBM hosts would still remain as Token Ring LLC2 to Ethernet 0x80d5 translation.
To define non-IBM hosts in your network topology to use the standard translation method while the IBM hosts use the nonstandard method, perform the following task in global configuration mode:
Allow some other devices to use normal LLC2/IEEE 802.3 translation on a per-DSAP basis.
source-bridge sap-80d5 dsap
Configure NetBIOS Support
NetBIOS is a nonroutable protocol that was originally designed to transmit messages between stations, typically IBM PCs, on a Token Ring network. NetBIOS allows messages to be exchanged between the stations using a name rather than a station address. Each station knows its name and is responsible for knowing the names of other stations on the network.
Note
NetBIOS name caching allows the router to maintain a cache of NetBIOS names, which avoids the high overhead of transmitting many of the broadcasts used between client and server NetBIOS PCs (IBM PCs or PS/2s) in an SRB environment.
When NetBIOS name caching is enabled, the router performs the following actions:
•
•
The router will time out the entries in the NetBIOS name cache after a specific interval of their initial storage. The timeout value is a user-configurable value. You can configure the timeout value for a particular Token Ring if the NetBIOS name cache is enabled on the interface connecting to that Token Ring. In addition, you can configure static name cache entries that never time out for frequently accessed servers whose locations or paths typically do not change. Static RIF entries are also specified for such hosts.
Generally, NetBIOS name caching is most useful when a large amount of NetBIOS broadcast traffic creates bottlenecks on WAN media connecting distant locations, and the WAN media is overwhelmed with this traffic. However, when two high-speed LAN segments are directly interconnected, the packet savings of NetBIOS name caching is probably not worth the router processor overhead associated with it.
Note
To enable NetBIOS name caching, you must perform the tasks in the following sections:
•
•
In addition, you can configure NetBIOS name caching as described in the following sections:
•
•
•
Enable the Proxy Explorers Feature on the Appropriate Interface
In order to enable NetBIOS name caching on an interface, the proxy explorers feature must first be enabled on that interface. This feature must either be enabled for response to all explorer packets or for response to NetBIOS packets only.
To determine whether the proxy explorers feature has been enabled, perform the following task in EXEC mode:
Determine whether or not the proxy explorers feature has been enabled
show configuration1
1 This command is documented in the "System Image, Microcode Image, and Configuration File Load Commands" chapter of the Router Products Command Reference publication.
To determine whether proxy explorers has been configured for response to all explorer packets, look in the router's configuration file for the source-bridge proxy-explorer entry for the appropriate interface. For example, if the appropriate interface is Token Ring 0, look for an entry similar to the following:
interface tokenring 0source-bridge proxy-explorerIf that entry does not exist, look for the source-bridge proxy-netbios-only entry for the appropriate interface.
If neither entry exists, proxy explorers has not yet been enabled for the appropriate interface. To enable proxy explorers for response to all explorer packets, refer to the section "Configure Proxy Explorers" later in this chapter.
Otherwise, enable proxy explorers only for the NetBIOS name caching function by performing the following task in global configuration mode:
Enable use of proxy explorers only for the NetBIOS name caching function and not for their general local response to explorers.
source-bridge proxy-netbios-only
Specify Timeout and Enable NetBIOS Name Caching
After you have ensured that the proxy explorers feature has been enabled for the appropriate interface, you can specify a cache timeout and enable NetBIOS name caching. To do this, perform the following tasks:
Configure the NetBIOS Cache Name Length
To specify how many characters of the NetBIOS type name that the name cache will validate, perform the following global configuration task:
Specify the number of characters of the NetBIOS type name to cache.
netbios name-cache name-len length
Enable NetBIOS Proxying
The router can act as a proxy and send NetBIOS datagram type frames. To enable this capability, perform the following global configuration task:
To define the validation time when the router is acting as a proxy for NetBIOS NAME_QUERY command or for explorer frames, perform the following global configuration task:
Create Static Entries in the NetBIOS Name Cache
If the router communicates with one or more NetBIOS stations on a regular basis, adding static entries to the NetBIOS name cache for these stations can reduce network traffic and router overhead. You can define a static NetBIOS name cache entry that associates the server with the NetBIOS name and the MAC address. If the router acts as a NetBIOS server, you can specify that the static NetBIOS name cache is available locally through a particular interface. If a remote router acts as the NetBIOS server, you can specify that the NetBIOS name cache is available remotely. To do this, perform one of the following tasks in global configuration mode:
If you have defined a NetBIOS name cache entry, you must also define a RIF entry. For an example of how to configure a static NetBIOS entry, see the "Example of NetBIOS Support with a Static NetBIOS Cache Entry" section later in this chapter.
Specify Dead-Time Intervals for NetBIOS Packets
When NetBIOS name caching is enabled and default parameters are set on the router (as well as the NetBIOS name server and the NetBIOS name client), approximately 20 broadcast packets per logon are kept on the local ring where they are generated. The broadcast packets are of the type ADD_NAME_QUERY, ADD_GROUP_NAME, and STATUS_QUERY.
The router also converts pairs of FIND_NAME and NAME_RECOGNIZED packets received from explorers, which traverse all rings, to specific route frames that are sent only between the two machines that need to see these packets.
You can specify a query-timeout, or "dead-time" interval to prevent repeat or duplicate broadcast of these type of packets for the duration of the interval.
To specify dead time intervals, perform one or both of the following tasks in global configuration mode:
Configure LAN Network Manager Support
LAN Network Manager (LNM), formerly called LAN Manager, is an IBM product for managing a collection of source-route bridges. Using either a proprietary protocol or the Simple Network Management Protocol (SNMP), LNM allows you to monitor the entire collection of Token Rings that comprise your source-route bridged network. You can use LNM to manage the configuration of source-route bridges, monitor Token Ring errors, and gather information from Token Ring parameter servers.
Note
LNM is not limited to managing locally attached Token Ring networks; it also can manage any other Token Rings in your source-route bridged network that are connected through non-Token Ring media. To accomplish this task, LNM works in conjunction with the IBM Bridge Program. The IBM Bridge Program gathers data about the local Token Ring network and relays it back to LNM. In this manner, the bridge program becomes a proxy for information about its local Token Ring. Without this ability, you would require direct access to a device on every Token Ring in the network. This process would make managing an SRB environment awkward and cumbersome.
Figure 24-8 shows some Token Rings attached through a cloud and one LNM linking to a source-route bridge on each local ring.
Figure 24-8 LNM Linking to a Source-Route Bridge on Each Local Ring
If LNM requires information about a station somewhere on a Token Ring, it uses a proprietary IBM protocol to query to one of the source-route bridges connected to that ring. If the bridge can provide the requested information, it simply responds directly to LNM. If the bridge does not have the necessary information, it queries the station using a protocol published in the IEEE 802.5 specification. In either case, the bridge uses the proprietary protocol to send a valid response back to LNM, using the proprietary protocol.
As an analogy, consider a language translator who sits between a French-speaking diplomat and a German-speaking diplomat. If the French diplomat asks the translator a question in French for the German diplomat and the translator knows the answer, he or she simply responds without translating the original question into German. If the French diplomat asks a question the translator does not know how to answer, the translator must first translate the question to German, wait for the German diplomat to answer, and then translate the answer back to French.
Similarly, if LNM queries a source-route bridge in the proprietary protocol and the bridge knows the answer, it responds directly using the same protocol. If the bridge does not know the answer, it must first translate the question to the IEEE 802.5 protocol, query the station on the ring, and then translate the response back to the proprietary protocol to send to LNM.
Figure 24-9 illustrates requests from the LNM originating in an IBM proprietary protocol and then translated into IEEE 802.5 MAC-level frames.
Figure 24-9 LAN Network Manager Monitoring and Translating
Notice that the proprietary protocol LNM uses to communicate with the source-route bridge is an LLC2 connection. Although its protocol cannot be routed, LNM can monitor or manage anything within the SRB network.
How the Router Works with LNM
As of Software Release 9.0, our routers using 4/16-Mbps Token Ring interfaces configured for SRB support the proprietary protocol that LNM uses. These routers provide all functions the IBM Bridge Program currently provides. Thus LNM can communicate with a router as if it were an IBM source-route bridge, such as the IBM 8209, and can manage or monitor any Token Ring connected to the router.
Through IBM Bridge support, LNM provides three basic services for the SRB network:
•
•
•
IBM Bridge support for LNM also allows asynchronous notification of some events that can occur on a Token Ring. Examples of these events include notification of a new station joining the Token Ring or of the ring entering failure mode, known as beaconing. Support is also provided for LNM to change the operating parameters in the bridge. For a complete description of LNM, refer to the IBM product manual supplied with the LNM program.
LNM support in our source-route bridges is a powerful tool for managing SRB networks. Through the ability to communicate with LNM and to provide the functionality of the IBM Bridge Program, our device appears as part of the IBM network. You therefore gain from the interconnectivity of our products without having to learn a new management product or interface.
When SRB is enabled on the router, configuring the router to perform the functions of an IBM Bridge for communication with LNM occurs automatically. Therefore, if SRB has been enabled on the router, you do not need to perform any tasks to enable LNM support. However, the LNM software residing on a management station on a Token Ring on the network should be configured to properly communicate with the router.
There are several options for modifying LNM parameters in the router, but none are required for basic functionality. For example, because users can now modify the operation of the router through SNMP as well as through LNM, there is an option to exclude a user from modifying the router configuration through LNM. You also can specify which of the three LNM services (CRS, REM, RPS) the source-route bridge will perform.
To configure LNM support, perform the tasks in the following sections:
•
•
•
•
•
•
•
•
Configure LNM Software on the Management Stations to Communicate with the Router
Because configuring an LNM station is a fairly simple task and is well covered in the LNM documentation, it is not covered in depth here. However, it is important to mention that you must enter the MAC addresses of the interfaces comprising the ports of the bridges as adapter addresses. When you configure the router as a multiport bridge, configuring an LNM station is complicated by the virtual ring that is involved. The basic problem extends from the fact that LNM is designed to only understand the concept of a two-port bridge, and the router with a virtual ring is a multiport bridge. The solution is to configure a virtual ring into the LNM Manager station as a series of dual-port bridges.
Disable LAN Network Manager Functionality
Under some circumstances, you can disable all LNM server functions on the router without having to determine whether to disable a specific server, such as the ring parameter server or the ring error monitor on a given interface.
To disable LNM functionality, perform the following task in global configuration mode:
The command can be used to terminate all LNM server input and reporting links. In normal circumstances, this command should not be necessary, because it is a superset of the functions normally performed on individual interfaces by the no lnm rem and no lnm rps commands.
Disable Automatic Report Path Trace Function
Under some circumstances, such as when new hardware has been introduced into the network and is causing problems, the automatic report path trace function can be disabled. The new hardware may be setting bit-fields B1 or B2 (or both) of the routing control field in the routing information field embedded in a source-route bridged frame. This condition may cause the network to be flooded by report path trace frames if the condition is persistent. The lnm pathtrace-disabled command, along with its options, allows you to alleviate network congestion that may be occurring by disabling all or part of the automatic report path trace function within LNM.
To disable the automatic report path trace function, perform the following task in global configuration mode:
Disable LNM automatic report path trace function.
lnm pathtrace-disabled [all | origin]
Prevent LNM Stations from Modifying Router Parameters
Because there is now more than one way to remotely change parameters in a router (either using SNMP or the proprietary IBM protocol), some method is needed to prevent such changes from detrimentally interacting with each other.You can prevent any LNM station from modifying parameters in the router. It does not affect the ability of LNM to monitor events, only to change parameters in the router.
To prevent the modification of router parameters by LNM station, perform the following task in global configuration mode:
Enable Other LRMs to Change Router/Bridge Parameters
LNM has a concept of reporting links and reporting link numbers. A reporting link is simply a connection (or potential connection) between a LAN Reporting Manager (LRM) and a bridge. A reporting link number is a unique number used to identify a reporting link. An IBM bridge allows four simultaneous reporting links numbered 0 through 3. Only the LRM attached on the lowest-numbered connection is allowed to change LNM parameters in the router, and then only when that connection number falls below a certain configurable number. In the default configuration, the LRM connected through link 0 is the only LRM that can change LNM parameters in the router.
To enable other LRMs to change router/bridge parameters, perform the following task in interface configuration mode:
Enable a LRM other than that connected through link 0 to change router/bridge parameters.
lnm alternate number
Apply a Password to an LNM Reporting Link
Each reporting link has its own password that is used not only to prevent unauthorized access from an LRM to a bridge but to control access to the different reporting links. This is important because it is possible to change parameters through some reporting links.
To apply a password to an LNM reporting link, perform the following task in interface configuration mode:
Enable LNM Servers
As in an IBM bridge, the router provides several functions that gather information from a local Token Ring. All of these functions are enabled by default, but also can be disabled. The LNM servers are explained in the section "How the Router Works with LNM" earlier in this chapter.
To enable LNM servers, perform one or more of the following tasks in interface configuration mode:
Enable the LNM Configuration Report Server (CRS).
lnm crs
Enable the LNM Ring Error Monitor (REM).
lnm rem
Enable the LNM Ring Parameter Server (RPS).
lnm rps
Change Reporting Thresholds
The router sends a message to all attached LNMs whenever it begins to drop frames. The threshold at which this report is generated is based on a percentage of frames dropped compared with those forwarded. This threshold is configurable, and defaults to a value of 0.10 percent. You can configure the threshold by entering a single number, expressing the percentage loss rate in hundredths of a percent. The valid range is 0 to 9999.
To change reporting thresholds, perform the following task in interface configuration mode:
Change the threshold at which the router reports the frames-lost percentage to LNM.
lnm loss-threshold number
Change an LNM Reporting Interval
All stations on a Token Ring notify the Ring Error Monitor (REM) when they detect errors on the ring. In order to prevent excessive messages, error reports are not sent immediately, but are accumulated for a short interval and then reported. A station learns the duration of this interval from a router (configured as a source-route bridge) when it first enters the ring. This value is expressed in tens of milliseconds between error messages. The default is 200, or 2 seconds. The valid range is 0 to 65535.
To change an LNM reporting interval, perform the following task in interface configuration mode:
Set the time interval during which stations report ring errors to the Ring Error Monitor (REM).
lnm softerr milliseconds
Enable the RPS Express Buffer Function
The RPS express buffer function allows the router to set the express buffer bit to ensure priority service for frames required for ring station initiation. When this function is enabled, the router sets the express buffer bit in its initialize ring station response. This allows Token Ring devices to insert into the ring during bursty conditions.
To enable LNM to use the RPS express buffer function, perform the following task in interface configuration mode:
