Configuring Source-Route Bridging

For a complete description of the SRB commands mentioned in this chapter, refer to the "Source-Route Bridging Commands" chapter in the Cisco IOS Bridging and IBM Networking Command Reference, Volume I. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

This chapter contains the following sections:

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.

Transparent spanning-tree bridging requires time to recompute a topology in the event of a failure; SRB, which maintains multiple paths, allows fast selection of alternate routes in the event of failure. Most importantly, SRB allows the end stations to determine the routes the frames take.

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, use the following command in interface configuration mode for each of the Token Ring interfaces:

Command	Purpose
source-bridge local-ring bridge-number target-ring	Enables local source-route bridging on a Token Ring interface.

NoteRing numbers need to be unique across interfaces and networks, so that when you enable source-route bridging over an interface the local and target rings are defined. Each node on the network will know if it is the target of explorer packets sent on the network.

A dual-port bridge is a limitation imposed by IBM Token Ring chips; the chips can process only 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.

To configure multiple dual-port source-route bridges, use the following command in interface configuration mode for each Token Ring interface that is part of a dual-port bridge:

Command	Purpose
source-bridge local-ring bridge-number target-ring	Enables local source-route bridging on a Token Ring interface.

If you want your network to use only SRB, you can connect as many routers as you need via Token Rings. Remember, source-route bridging requires you to bridge only Token Ring media.

Once you have completed these tasks, the router acts as a multiport bridge, not as a dual-port bridge.

NoteRing numbers need to be unique across interfaces and networks.

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, use one of the following commands in global configuration mode:

Command	Purpose
source-bridge ring-group ring-group [virtual-mac-address]	Defines a ring group.
no source-bridge ring-group ring-group [virtual-mac-address]	Removes a ring group.

Enabling SRB and Assigning a Ring Group to an Interface

To enable SRB and assign a ring group to an interface, use the following command in interface configuration mode:

Command	Purpose
source-bridge local-ring bridge-number target-ring	Enables source-route bridging and assigns a ring group to a Token Ring interface.

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.

To enable forwarding of spanning-tree explorers on an outgoing interface, use the following command in interface configuration mode:

Command	Purpose
source-bridge spanning	Enables the forwarding of spanning-tree explorer packets on an interface.

NoteWhile enabling the forwarding of spanning-tree explorer packets is not an absolute requirement, it is strongly recommended in complex topologies. Configuring an interface to block or forward spanning-tree explorers has no effect on how that interface handles all-routes explorer packets. All-routes explorers can always traverse the network.

To block forwarding of spanning tree explorers on an outgoing interface, use the following command in interface configuration mode:

Command	Purpose
no source-bridge spanning	Blocks spanning-tree explorer packets on an interface.

To limit the number of SRB hops, use one of the following commands in interface configuration mode:

Command	Purpose
source-bridge max-hops count	Controls the forwarding or blocking of all-routes explorer frames received on this interface.
source-bridge max-in-hops count	Controls the forwarding or blocking of spanning-tree explorer frames received on this interface.
source-bridge max-out-hops count	Controls the forwarding or blocking of spanning-tree explorer frames sent from this interface.

To configure the Cisco IOS software to bridge routed protocols, perform the following tasks:

NoteThe Spanning-Tree Protocol messages used to prevent loops in the transparent bridging domain are not passed between the SRB domain and the transparent bridging domain. Therefore, you must not set up multiple paths between the SRB and transparent bridging domains.

The following notes and caveats apply to all uses of SR/TLB:

• Multiple paths cannot exist between the source-route bridged domain and the transparent bridged domain. Such paths can lead to data loops in the network, because the spanning-tree packets used to avoid these loops in transparent bridging networks do not traverse the SRB network.

• Some devices, notably PS/2s under certain configurations running OS/2 Extended Edition Version 1.3, do not correctly implement the "largest frame" processing on RIFs received from remote source-route bridged hosts. The maximum Ethernet frame size is smaller than that allowed for Token Ring. As such, bridges allowing for communication between Ethernet and Token Ring will tell the Token Ring hosts, through the RIF on frames destined to the Token Ring, that hosts on the Ethernet cannot receive frames larger than a specified maximum, typically 1472bytes. Some machines ignore this run-time limit specification and send frames larger than the Ethernet can accept. The router and any other Token Ring/Ethernet bridge has no choice but to drop these frames. To allow such hosts to successfully communicate across or to an Ethernet, you must configure their maximum frame sizes manually. For the PS/2, this can be done through Communications Manager.

• Any access filters applied on any frames apply to the frames as they appear on the media to which the interface with the access filter applies. This is important because in the most common use of SR/TLB (Ethernet and Token Ring connectivity), the bit ordering of the MAC addresses in the frame is swapped. Refer to the SR/TLB examples in the "SRB Configuration Examples" section of this chapter.

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.

Problems can 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. Cisco recommends that these protocols be routed whenever possible.

To enable SR/TLB, you must perform the task in the following section:

Command	Purpose
source-bridge transparent ring-group pseudo-ring bridge-number tb-group [oui]	Enables bridging between transparent bridging and SRB.

Command	Purpose
no source-bridge transparent ring-group fastswitch	Disables fast-switched SR/TLB.

Command	Purpose
ethernet-transit-oui [90-compatible | standard | cisco]	Moves data between IBM 8209 Ethernet/Token Ring bridges and routers running translational bridging software.

Command	Purpose
source-bri dge enable-80d5	Changes the Ethernet/Token Ring translation behavior to translate Token Ring LLC2 frames into Ethernet 0x80d5 format frames.

To define non-IBM hosts in your network topology to use the standard translation method while the IBM hosts use the nonstandard method, use the following command in global configuration mode:

Command	Purpose
source-bri dge sap-80d5 dsap	Allows some other devices to use normal LLC2/IEEE 802.3 translation on a per-DSAP basis.

NoteIn addition to this type of NetBIOS, which runs over LLC2, we have implemented another type of NetBIOS that runs over IPX. For information on the IPX type of NetBIOS, refer to the chapter "Configuring Novell IPX" in the Cisco IOS AppleTalk and Novell IPX Configuration Guide.

NetBIOS name caching allows the Cisco IOS software 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 software performs the following actions:

• Notices when any hosts send a series of duplicated "query" frames and reduces them to one frame per period. The time period is configurable.

• Keeps a cache of mappings between NetBIOS server and client names and their MAC addresses. By watching NAME_QUERY and NAME_RECOGNIZED request and response traffic between clients and servers, the Cisco IOS software can forward broadcast requests sent by clients to find servers (and by servers in reply to their clients) directly to their needed destinations, rather than forwarding them for broadcast across the entire bridged network.

The software 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 processor overhead associated with it.

NoteNetBIOS name caching is not recommended to be turned on in backbone routers, particularly if you have it enabled in all the routers connected to the backbone. NetBIOS caching should be distributed among multiple routers. NetBIOS name caching can be used only between Cisco routers that are running software Release 9.1 or later.

To enable NetBIOS name caching, you must perform the tasks in the following sections:

	Command	Purpose
Step1	netbios name-cache timeout minutes	Specifies the timeout for entries in the NetBIOS name cache.
Step2	netbios enable-name-cache	Enables NetBIOS name caching for the appropriate interfaces.

To specify dead time intervals, use one or both of the following commands in global configuration mode:

Command	Purpose
netbios name-cache query-timeout seconds	Specifies a dead time interval during which the Cisco IOS software drops any broadcast (NetBIOS ADD_NAME_QUERY, ADD_GROUP_NAME, or STATUS_QUERY) frames if they are duplicate frames sent by the same host.
netbios name-cache recognized-timeout seconds	Specifies a dead time interval during which the software drops FIND_NAME and NAME_RECOGNIZED frames if they are duplicate frames sent by the same host.

NoteLNM is supported on the 4/16-Mb Token Ring cards that can be configured for either 4- or 16-Mb transmission speeds. LNM support is not provided on CSC-R16M cards with SBEMON 2.0.

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.

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.

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.

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 Cisco IOS software to perform the functions of an IBM Bridge for communication with LNM occurs automatically. Therefore, if SRB has been enabled, 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 Cisco IOS software, but none are required for basic functionality. For example, because users can now modify the operation of the Cisco IOS software through SNMP as well as through LNM, there is an option to exclude a user from modifying the Cisco IOS software 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:

To disable LNM functionality, use the following command in global configuration mode:

Command	Purpose
lnm disabled	Disables LNM functionality.

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.

To disable the automatic report path trace function, use the following command in global configuration mode:

Command	Purpose
lnm pathtrace-disabled [all | origin]	Disables LNM automatic report path trace function.

To enable other LRMs to change router parameters, use the following command in interface configuration mode:

Command	Purpose
lnm alternate number	Enables a LRM other than that connected through link 0 to change router parameters.

To apply a password to an LNM reporting link, use the following command in interface configuration mode:

Command	Purpose
lnm password number string	Applies a password to an LNM reporting link.

To change an LNM reporting interval, use the following command in interface configuration mode:

Command	Purpose
lnm softerr milliseconds	Sets the time interval during which stations report ring errors to the Ring Error Monitor (REM).

Command	Purpose
lnm express-buffer	Enables the RPS express buffer function.

RFC 1483 also provides the following benefits:

• Flexibility to implement traffic policies pertaining to traffic shaping and various congestion control mechanisms

• Load balancing of traffic guarantees transmission of LAN data

• Cost effectiveness of using PVCs instead of LANE in small networks

• Transfer of connectionless LAN data over a connection-oriented ATM network

• Support for IP and IPX routing, using RFC 1483 Routed PDUs

• Two-port and multiport SRB between Token Ring LANs connected via RFC 1483 AAL5SNap permanent virtual circuits (PVCs), using bridged PDUs.

• Two-port and multiport SRB between Token Ring LANs (using RFC 1483 AAL5Snap PVCs) and LANs, VLANs, or ELANs with SRB (using bridged PDUs).

RFC 1483 also supports two-port and multiport SR/TLB between Token Ring, Ethernet and their respective emulated LANS, using RFC 1483 bridged PDUs.

The following guidelines apply to RFC 1483 configuration:

• Assign a unique number to the PVC that connects two nodes. When SRB is configured, the router determines the PVC on which the frame is to be forwarded and treats it as a Token Ring interface. In a large network, the availability of enough unique virtual ring numbers for PVCs might be a limitation.

• Conserve the virtual ring number on the PVC and configure the routers so that they use the same ring numbers that are assigned to the PVCs.

To configure SRB over ATM, use the following commands in interface configuration mode:

	Command	Purpose
Step1	interface atm slot/port	Specifies the ATM interface.
Step2	interface atm slot/port [subinterface- number {multipoint | point-to-point}]	Specifies the ATM main interface or subinterface to which discovered PVCs will be assigned.
Step3	atm pvc vcd vpi vci aal-encap [[midlow midhigh] [peak average [burst]]] [inarp [minutes]] [oam [seconds]]	Creates a PVC on an ATM interface.
Step4	source-bridge local-ring bridge-number target-ring-number conserve-ring	Assigns a ring number to the ATM PVC.
Step5	source-bridge spanning bridge-group	Enables the automatic spanning-tree function on a group of bridged interfaces.

• Host access list

Used for source and destination station names

• Byte offset access list

Used for arbitrary byte patterns in the packet itself.

• The access lists that apply filters to an interface are scanned in the order they are entered.

• There is no way to put a new access list entry in the middle of an access list. All new additions to existing NetBIOS access lists are placed at the end of the existing list.

• Access list arguments are case sensitive. The software makes a literal translation, so that a lowercase "a" is different from an uppercase "A." (Most nodes are named in uppercase letters.)

• A host NetBIOS access list and byte NetBIOS access list can each use the same name. The two lists are identified as unique and bear no relationship to each other.

• The station names included in the access lists are compared with the source name field for NetBIOS commands 00 and 01 (ADD_GROUP_NAME_QUERY and ADD_NAME_QUERY), as well as the destination name field for NetBIOS commands 08, 0A, and 0E (DATAGRAM, NAME_QUERY, and NAME_RECOGNIZED).

• If an access list does not contain a particular station name, the default action is to deny the access to that station.

To minimize any performance degradation, NetBIOS access filters do not examine all packets. Rather, they examine certain packets that are used to establish and maintain NetBIOS client/server connections, thereby effectively stopping new access and load across the router. However, applying a new access filter does not terminate existing sessions immediately. All new sessions will be filtered, but existing sessions could continue for some time.

There are two ways you can configure NetBIOS access filters:

1. Assign the station access list name.

2. Specify the direction of the message to be filtered on the interface.

The NetBIOS station access list contains the station name to match, along with a permit or deny condition. You must assign the name of the access list to a station or set of stations on the network.

To assign a station access list name, use the following command in global configuration mode:

Command	Purpose
netbios access-list host name {permit | deny} pattern	Assigns the name of an access list to a station or set of stations on the network.

When filtering by station name, you can choose to filter either incoming or outgoing messages on the interface. To specify the direction, use one of the following commands in interface configuration mode:

Command	Purpose
netbios input-access-filter host name	Defines an access list filter for incoming messages.
netbios output-access-filter host name	Defines an access list filter for outgoing messages.

1. Assign a byte offset access list name.

2. Specify the direction of the message to be filtered on the interface.

Keep the following notes in mind while configuring access filters using a byte offset:

• When an access list entry has an offset plus the length of the pattern that is larger than the packet's length, the entry will not make a match for that packet.

• Because these access lists allow arbitrary byte offsets into packets, these access filters can have a significant impact on the amount of packets per second transiting across the bridge. They should be used only when situations absolutely dictate their use.

The NetBIOS byte offset access list contains a series of offsets and hexadecimal patterns with which to match byte offsets in NetBIOS packets. To assign a byte offset access list name, use the following command in global configuration mode:

Command	Purpose
netbios access-list bytes name {permit | deny} offset pattern	Defines the byte offsets and patterns within NetBIOS messages to match with access list parameters.

NoteUsing NetBIOS Byte Offset access filters disables the autonomous or fast switching of source-route bridging frames.

When filtering by byte offset, you can filter either incoming or outgoing messages on the interface. To specify the direction, use one of the following commands in interface configuration mode:

Command	Purpose
netbios input-access-filter bytes name	Specifies a byte-based access filter on incoming messages.
netbios output-access-filter bytes name	Specifies a byte-based access filter on outgoing messages.

Whereas filtering by Token Ring address or vendor code causes no significant performance penalty, filtering by protocol type significantly affects performance. A list of SNAP (Ethernet) type codes is provided in the "Ethernet Type Codes" appendix in the Cisco IOS Bridging and IBM Networking Command Reference, Volume I.

The order in which you specify these elements affects the order in which the access conditions are checked. Each condition is tested in succession. A matching condition is then used to execute a permit or deny decision. If no conditions match, a deny decision is reached.

Note If a single condition is to be denied, there must be an access-list command that permits everything as well, or all access is denied.

To filter frames by protocol type, use the following command in global configuration mode:

Command	Purpose
access-list access-list-number {permit | deny} {type-code wild-mask | address mask}	Creates an access list for filtering frames by protocol type.

You can filter IEEE 802-encapsulated packets on either input or output. The access list you specify is the one you created that includes the protocol type codes.

To enable filtering on input or output, use one of the following commands in interface configuration mode:

Command	Purpose
source-bridge input-lsap-list access-list-number	Enables filtering of IEEE802-encapsulated packets on input by type code.
source-bridge output-lsap-list access-list-number	Enables filtering of IEEE802-encapsulated packets on output by type code.

To enable filtering on input or output, use one of the following commands in interface configuration mode:

Command	Purpose
source-bridge input-type-list access-list-number	Filters SNAP-encapsulated packets on input by type code.
source-bridge output-type-list access-list-number	Filters SNAP-encapsulated frames on output by type code.

Purpose	Command
access-list access-list-number {permit | deny} address mask	Configures vendor code access lists.

Filtering Source Addresses

Command	Purpose
source-bridge input-address-list access-list-number	Enables filtering on IEEE 802 source addresses.

Filtering Destination Addresses

Command	Purpose
source-bridge output-address-list access-list-number	Enables filtering on IEEE 802 destination addresses.

• LSAP and SNAP type codes

• MAC addresses

• NetBIOS station names

• NetBIOS arbitrary byte values

NoteFor any given interface, an access expression cannot be used if an access list has been defined for a given direction. For example, if an input access list is defined for MAC addresses on an interface, no access expression can be specified for the input side of that interface.

• Design the access expression.

• Configure the access lists used by the expression.

• Configure the access expression into the router.

"Allow access if the frame is not an SNA frame, or if it is going to host 0110.2222.3333."

More tersely, this would be:

"Not SNA or destined to 0110.2222.3333."

The access lists defined in the previous section create the following configuration:

interface tokenring 0
access-expression in ~lsap(202) | dmac(701)
!
access-list 202 permit 0x0404 0x0001 ! Permits SNA frames (command or response)
access-list 202 permit 0x0004 0x0001 ! Permits SNA Explorers with NULL DSAP
!
! Access list 701 will permit the FEP MAC address
! of 0110.2222.3333
access-list 701 permit 0110.2222.3333

This is a better and simpler access list than the one originally introduced and will probably result in better run-time execution as a result. Therefore, it is best to simplify your access expressions as much as possible before configuring them into the Cisco IOS software.

NoteAn "access-expression" type filter cannot exist with a "source-bridge" type filter on the same interface. The two types of filters are mutually exclusive.

For example, if you want to redefine the NetBIOS access list named MIS that was used in the preceding example, you would use the following sequence of configuration commands:

!  Replace the NetBIOS access list
interface tokenring 0
access-expression in (smac(701) & netbios-host(accept))
no netbios access-list host accept permit CISCO*

To set the connection timeout interval, use the following command in global configuration mode:

Command	Purpose
source-bridge connection-timeout seconds	Sets the connection timeout interval.

The source-bridge explorer-dup-ARE-filter command can be used to reduce explorer traffic by filtering explorer frames.

To optimize explorer processing, use one or more of the following commands in global configuration mode:

Command	Purpose
source-bridge explorerq-depth depth	Sets the maximum explorer queue depth.
source-bridge explorer-dup-ARE-filter	Prevents explorer storms in redundant network topologies by filtering explorers that have already been forwarded once.
source-bridge explorer-maxrate maxrate	Sets the maximum byte rate of explorers per ring.

:

Command	Purpose
no source-bridge explorer-fastswitch	Disables explorer fast switching.

To enable explorer fast-switching after it has been disabled, use the following command in global configuration mode:

Command	Purpose
source-bridge explorer-fastswitch	Enables explorer fast switching.

To configure proxy explorers, use the following command in interface configuration mode:

Command	Purpose
source-bridge proxy-explorer	Enables the interface to respond to any explorer packets that meet certain conditions necessary for a proxy response to occur.

The Cisco IOS software does not propagate proxy responses for a station. Instead, the software obtains the RIF path from the RIF cache, changes the explorer to a specific frame, and forwards this frame to the destination. If a response is not received before the validation timer expires, the RIF entry is marked as invalid. The invalid RIF entry is flushed from the cache table when another explorer for this station is received, and an explorer is forwarded to discover a path to this station.

There is a known defect in earlier versions of the Texas Instruments Token Ring MAC firmware. This implementation is used by Proteon, Apollo, and IBM RTs. A host using a MAC address whose first two bytes are zeros (such as a Cisco router) will not properly communicate with hosts using that version of Texas Instruments firmware.

There are two solutions. The first involves installing a static RIF entry for every faulty node with which the router communicates. If there are many such nodes on the ring, this may not be practical.

You also can set the MAC address of our Token Ring to a value that works around the problem. Resetting the MAC address forces the use of a different MAC address on the specified interface, thereby avoiding the TI MAC firmware problem. However, you must ensure that no other host on the network is using that MAC address.

To reset the MAC address, use the following command in interface configuration mode:

Command	Purpose
mac-address ieee-address	Resets the MAC address of the Token Ring interface to a value that provides a workaround to a problem in Texas Instruments Token Ring MAC firmware.

To maintain the SRB network, use any of the following commands in privileged EXEC mode:

Command	Purpose
clear netbios-cache	Clears the entries of all dynamically learned NetBIOS names.
clear rif-cache	Clears the entire RIF cache.
clear source-bridge	Clears the SRB statistical counters.
clear sse	Reinitializes the SSP on the Cisco7000 series.

In addition to the EXEC-mode commands to maintain the SRB network, you can use the following command in global configuration mode:

Command	Purpose
source-bridge tcp-queue-max number	Limits the size of the backup queue for RSRB to control the number of packets that can wait for transmission to a remote ring before they are thrown away.

The example that follows routes IP, but source-route bridges all other protocols using spanning-tree explorers:

interface tokenring 0
ip address 131.108.129.2 255.255.255.0
source-bridge 129 1 130
source-bridge spanning
multiring all
!
interface tokenring 1
ip address 131.108.130.2 255.255.255.0
source-bridge 130 1 129
source-bridge spanning
! use RIFs, as necessary, with IP routing software
multiring all

The following example shows that all protocols are bridged, including IP. Because IP is being bridged, the system has only one IP address.

no ip routing
!
interface tokenring 0
ip address 131.108.129.2 255.255.255.0
source-bridge 129 1 130
source-bridge spanning
!
interface tokenring 1
ip address 131.108.129.2 255.255.255.0
source-bridge 130 1 129
source-bridge spanning
!
interface ethernet 0
ip address 131.108.129.2 255.255.255.0

The following is a sample configuration file:

source-bridge ring-group 7
!
interface tokenring 0
source-bridge 1000 1 7
source-bridge spanning
!
interface tokenring 1
source-bridge 1001 1 7
source-bridge spanning
!
interface tokenring 2
source-bridge 1002 1 7
source-bridge spanning
!
interface tokenring 3
source-bridge 1003 1 7
source-bridge spanning

Configuration for Router A

source-bridge ring-group 100
!
interface tokenring 0
source-bridge 3 4 100
source-bridge spanning
!
interface tokenring 1
source-bridge 1 4 100
source-bridge spanning

Configuration for Router B

source-bridge ring-group 200
!
interface tokenring 0
source-bridge 3 1 200
source-bridge spanning
!
interface tokenring 2
source-bridge 2 1 200
source-bridge spanning

Router A

dlsw local-peer peer-id 132.11.11.2
dlsw remote-peer 0 tcp 132.11.11.3
interface Fddi0
no ip address
multiring all
source-bridge 26 1 10
source-bridge spanning

Router B

dlsw local-peer peer-id 132.11.11.2
dlsw remote-peer 0 tcp 132.11.11.3
interface TokenRing0
no ip address
ring-speed 16
multiring all
source-bridge 25 1 10
source-bridge spanning

In this example, we configure a new option, conserve-ring, on the source-bridge interface configuration command. When this option is configured, the SRB software does not add the ring number associated with the Frame Relay PVC (the partner's virtual ring) to outbound explorer frames. This option is permitted for Frame Relay subinterfaces only.

The router configures the partner FRAD's virtual ring number as the ring number for the PVC.

This approach does not require a separate ring number per DLCI. The router configures the partner FRAD's virtual ring number as the ring number for the PVC.

FRAD B would configure its virtual ring as 200 and the ring for the PVC as 100. FRAD C would configure its virtual ring as 300 and the ring for the PVC as 100.

Configuration of Router A

source-bridge ring-group 100
!
interface Serial1
 encapsulation frame-relay
!
interface Serial1.1 point-to-point
 frame-relay interface-dlci 30 ietf
 source-bridge 200 1 100 conserve-ring
 source-bridge spanning
!
interface Serial1.2 point-to-point
 frame-relay interface-dlci 31 ietf
 source-bridge 300 1 100 conserve-ring
 source-bridge spanning
!
interface TokenRing0
source-bridge 500 1 100

Configuration on Router B

source-bridge ring-group 200
!
interface Serial0
 encapsulation frame-relay
!
interface Serial0.30 point-to-point
 frame-relay interface-dlci 30 ietf
 source-bridge 100 1 200 conserve-ring
 source-bridge spanning
!
interface TokenRing0
source-bridge 600 1 200

Configuration on Router C

source-bridge ring-group 300
!
interface Serial0
 encapsulation frame-relay
!
interface Serial0.31 point-to-point
 frame-relay interface-dlci 31 ietf
 source-bridge 100 1 300 conserve-ring
 source-bridge spanning
!
interface TokenRing0
source-bridge 900 1 300

The static RIF entry would be submitted to the router on the left as follows:

rif 1000.5A12.3456 0630.0081.0090

The RIF in the router on the left describing this two-hop path is 0830.0155.100a.5550 and is entered as follows:

rif 1000.5A01.0203 0830.0155.100a.5550

Assume that the following configuration for SRB and transparent bridging existed before you wanted to enable SR/TLB:

interface tokenring 0
source-bridge 1 1 2
!
interface tokenring 1
source-bridge 2 1 1
!
interface ethernet 0
bridge-group 1
!
interface ethernet 0
bridge-group 1
!
bridge 1 protocol dec

source-bridge ring-group 10
!
interface tokenring 0
source-bridge 1 1 10
!
interface tokenring 1
source-bridge 2 1 10
!
interface ethernet 0
bridge-group 1
!
interface ethernet 1
bridge-group 1
!
bridge 1 protocol dec

Now you are ready to determine two things:

• A ring number for the pseudo-ring that is unique throughout the source-route bridged network. For the preceding example configuration, use the number 3.

• A bridge number for the path to the pseudo-ring. For the preceding example configuration, use the number1.

Once you have determined the ring number and the bridge number, you can add the source-bridge transparent command to the file, including these two values as parameters for the command. The following partial configuration includes this source-bridge transparent entry:

!
source-bridge ring-group 10
source-bridge transparent 10 3 1 1
!
interface tokenring 0
source-bridge 1 1 10
!
interface tokenring 1
source-bridge 2 1 10
!
interface ethernet 0
bridge-group 1
!
interface ethernet 1
bridge-group 1
!
bridge 1 protocol dec

You want to allow only these two machines to communicate across the router. Therefore, you might create the following configuration to restrict the access. However, this configuration will not work, as explained in the paragraph following the sample configuration file.

NoteFor readability, the commands that control bridging are not shown here, just the commands that control the filtering.

interface tokenring 0
access-expression output smac(701)
!
interface ethernet 0
bridge-group 1 input-address-list 701
!
access-list 701 permit 0110.2222.3333

The command for the Token Ring interface specifies that the access list 701 be applied on the source address of frames going out to the Token Ring, and the command for the Ethernet interface specifies that this access list be applied on the source address frames entering the interface from Ethernet. This would work if both interfaces used the same bit ordering, but Token Rings and Ethernets use opposite (swapped) bit orderings in their addresses in relationship to each other. Therefore, the address of Host E on the Token Ring is not 0110.2222.3333, but rather 8008.4444.cccc, resulting in the following configuration. The following configuration is better. This example shows that access lists for Token Ring and Ethernet should be kept completely separate from each other.

interface tokenring 0
source-bridge input-address-list 702
!
interface ethernet 0
bridge-group 1 input-address-list 701
!
access-list 701 permit 0110.2222.3333
!
access-list 702 permit 0110.1234.5678

The associated configuration file follows:

interface tokenring 0
source-bridge 1 2 3
!
interface tokenring 1
source-bridge 3 2 1
 

The show lnm config command displays the logical configuration of this bridge, including the LNM configuration information that needs to be entered at the LNM Station. A sample show lnm config display follows:

Wayfarer# show lnm config
 
Bridge(s) currently configured:
From     ring 001, address 0000.3000.abc4
Across bridge 002
To       ring 003, address 0000.3000.5735

In this example, the MAC addresses 0000.3000.abc4 and 000.3000.5735 must be configured as Adapter Addresses at the LNM Station.

The associated configuration file follows.

source-bridge ring-group 8
!
interface tokenring 0
source-bridge 1 1 8
!
interface tokenring 1
source-bridge 2 2 8
!
interface tokenring 2
source-bridge 3 3 8

The show lnm config command displays the logical configuration of this bridge, including all the pertinent information for configuring this router into LNM:

Wayfarer# show lnm config
Bridge(s) currently configured:
 
            From     ring 001, address 0000.0028.abcd
            Across bridge 001
            To       ring 008, address 4000.0028.abcd
 
            From     ring 002, address 0000.3000.abc4
            Across bridge 002
            To       ring 008, address 4000.3000.abc4
 
            From     ring 003, address 0000.3000.5735
            Across bridge 003
            To       ring 008, address 4000.3000.5735
 

In this example, six station definitions must be entered at the LNM Station, one for each of the MAC addresses listed in this sample show lnm config display.

This example assumes that all hosts on Token Ring 1 have Token Ring addresses with the vendor code 1000.5A00.0000. The first line of the access list denies access to all IBM workstations, while the second line permits everything else. The access list is assigned to the input side of Token Ring 1.

! deny access to all IBM workstations
access-list 700 deny 1000.5A00.0000   8000.00FF.FFFF 
! permit all other traffic 
access-list 700 permit 0000.0000.0000   FFFF.FFFF.FFFF 
! 
interface token ring 1 
! apply access list 700 to the input side of Token Ring 1
source-bridge input-address-list 700

The following example allows only AppleTalk Phase 2 packets to be source-route bridged between Token Rings 0 and 1, and allows Novell packets only to be source-route bridged between Token Rings 2 and 3.

source-bridge ring-group 5
!
interface tokenring 0
ip address 131.108.1.1 255.255.255.0
source-bridge 1000 1 5
source-bridge spanning
source-bridge input-type-list 202
!
interface tokenring 1
ip address 131.108.11.1 255.255.255.0
source-bridge 1001 1 5
source-bridge spanning
source-bridge input-type-list 202
!
interface tokenring 2
ip address 131.108.101.1 255.255.255.0
source-bridge 1002 1 5
source-bridge spanning
source-bridge input-lsap-list 203
!
interface tokenring 3
ip address 131.108.111.1 255.255.255.0
source-bridge 1003 1 5
source-bridge spanning
source-bridge input-lsap-list 203
!
! SNAP type code filtering
! permit ATp2 data (0x809B)
! permit ATp2 AARP (0x80F3)
access-list 202 permit 0x809B 0x0000
access-list 202 permit 0x80F3 0x0000
access-list 202 deny 0x0000 0xFFFF
!
! LSAP filtering
! permit IPX (0xE0E0)
access-list 203 permit 0xE0E0 0x0101
access-list 203 deny 0x0000 0xFFFF
 

NoteIt is not necessary to check for an LSAP of 0xAAAA when filtering SNAP-encapsulated AppleTalk packets, because for source-route bridging, the use of type filters implies SNAP encapsulation.

Suppose you want to permit the IBM 3174 cluster controllers to access the FEP at address 0110.2222.3333, and also want the NetBIOS clients to access the NetBIOS server named FILESVR3. The following set of router configuration commands would meet this need:

netbios access-list host MIS permit FILESVR3
netbios access-list host MIS deny *
!
access-list 202 permit 0x0404 0x0001 ! Permits SNA frames (command or response)
access-list 202 permit 0x0004 0x0001 ! Permits SNA Explorers with NULL DSAP
!
access-list 701 permit 0110.2222.3333
!
interface tokenring 0
access-expression in (lsap(202) & dmac(701)) | netbios-host(MIS)

! global command to apply interface configuration commands to the ring group 
source-bridge ring-group 2 
!
! commands that follow apply to interface token 0
interface tokenring 0
! enable srb between local ring 1, bridge 1, and target ring 2 
source-bridge 1 1 2
! enable autonomous switching for interface token 0 
source-bridge route-cache cbus
!
interface tokenring 1
! enable srb between local ring 2, bridge 1, and target ring 1 
source-bridge 2 1 1
source-bridge route-cache cbus

Following are the configurations for routers A and B:

Router A

interface atm slot/port 
atm clock
interface atm slot/port.1 point-to-point
atm pvc 1 10 12 aal5snap
source-bridge 200 1 100 conserve-ring
source-bridge spanning

Router B

interface atm slot/port.1 point-to-point
atm pvc 2 10 12 aal5snap
source-bridge 100 1 200 conserve-ring
source-bridge spanning

Router A

interface atm slot/port
interface atm slot/port.1 point-to-point
atm pvc 1 10 12 aal5snap
source-bridge 200 1 100 conserve-ring
source-bridge spanning

Router B

interface atm slot/port.1 point-to-point
atm pvc 2 0 12 aal5snap
source-bridge 100 1 200 conserve-ring
source-bridge spanning

The following configuration does not use the conserve-ring argument in the configuration and the PVC is allocated its own virtual ring number.

Router A

interface atm slot/port
interface atm slot/port.1 point-to-point
atm pvc 1 0 12 aal5snap
source-bridge 5 1 100
source-bridge spanning

Router B

interface atm slot/port.1 point-to-point
atm pvc 2 0 12 aal5snap
source-bridge 6 1 100
source-bridge spanning

Following are the configurations for routers A, B, and C:

Router A

interface atm slot/port.1 point-to-point
atm pvc 1 10 12 aal5snap
source-bridge 200 1 100 conserve-ring
source-bridge spanning
 
interface atm slot/port.2 point-to-point
atm 2 0 12 aal5snap
source-bridge 300 2 101 conserve-ring
source-bridge spanning

Router B

interface atm slot/port.1 point-to-point
atm pvc 3 0 12 aal5snap
source-bridge 100 1 200 conserve-ring
source-bridge spanning

Router C

interface atm slot/port.1 point-to-point
atm pvc 4 0 12 aal5snap
source-bridge 101 2 300 conserve-ring
source-bridge spanning

Following are the configurations for routers A, B, and C:

Router A

interface atm slot/port.1 point-to-point
atm pvc 1 0 12 aal5snap
source-bridge 200 1 100 conserve-ring
source-bridge spanning
 
interface atm slot/port.2 point-to-point
atm pvc 2 0 2 aal5snap
source-bridge 300 2 100 conserve-ring
source-bridge spanning

Router B

interface atm slot/port.1 point-to-point
atm pvc 3 0 2 aal5snap
source-bridge 100 1 200 conserve-ring
source-bridge spanning

Router C

interface atm slot/port.1 point-to-point
atm pvc 4 1 3 aal5snap
source-bridge 100 2 300 conserve-ring
source-bridge spanning