|
|
This chapter describes routing and bridging in Token Ring environments. This chapter discusses the following topics:
This chapter also provides source-route bridging configuration examples, and describes how to maintain, monitor, and debug your source-route bridges. Command summaries are included at the end of the chapter.
Cisco bridging software includes source-route bridging capability. This ability allows the Cisco router/bridge to simultaneously act as a Level 3 router and a Level 2 source-route bridge. This allows protocols such as Novell or XNS to be routed on Token Rings, while other protocols such as SNA or NetBIOS are source-route bridged.
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 Medium 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 also allows the 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 1-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.
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.
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 source-route bridging software implementation provides these features:
To configure source-route bridging on your Cisco router/bridge, follow these steps:
Step 1: Configure the Token Ring interface for source-route bridging. The Cisco router/bridge supports both local and remote source-route bridging.
To determine if your Token Ring interface has the proper hardware and firmware support for source-route bridging, examine the output of the EXEC show interface command for that interface. If the output has a line that reads "Source Route Bridge capable" or "Source Route Transparent Bridge capable," then you may proceed with configuration. Otherwise, you need to contact Cisco Systems for a hardware and firmware field upgrade.
Step 2: Define the types of explorer packets to use: either spanning tree or the default all- rings explorer packets.
Step 3: Choose the remote peers with which you want to establish locally terminated LLC2 sessions using the Local Acknowledgment functionality.
Step 4: Choose the transparent bridge group, if any, to tie into your source-route bridged network using the Source-Route Translational Bridging (SR/TLB) functionality.
Step 5: Choose access controls and filters as needed to administratively control the traffic traversing the Cisco source-route bridge. Use access expressions, if needed, to provide greater control over the use of the filters.
The source-route bridging software supports filtering of frames. Filtering can be done by protocol type or by vendor code. You can also configure access control filters for packets transmitted across a Token Ring bridge using the NetBIOS interface. Additionally, EXEC-level commands for monitoring and debugging the bridge are also available. These tasks and commands are described in the following sections.
By default, fast-switching software is enabled in the source-route bridging software. Fast switching allows for faster implementations of local source-route bridging between 4/16 Megabit Token Ring cards in the same Cisco router/bridge. This feature also allows for faster implementations of local source-route bridging between two Cisco router/bridges using the 4/16 Megabit Token Ring cards and the direct interface encapsulation. To disable fast switching, use the no source-bridge route-cache interface subcommand.
The full syntax of this command follows:
source-bridge route-cacheThese commands disable use of fast switching between two Token Ring interfaces.
interface token 0 source-bridge 1 1 2 no source-bridge route-cache ! interface token 1 source-bridge 2 1 1 no source-bridge route-cache
This section explains how to build routing information fields (RIFs). A RIF is built up of ring and bridge numbers. A ring is a single Token Ring network segment. Each ring in the extended Token Ring network is designated by a unique 12-bit ring number. Each bridge between two Token Rings is designated by a unique 4-bit bridge number. Bridge numbers must be unique only between bridges that connect the same two Token Rings.
Figure 1-2 illustrates the basic format for the Routing Information Field.
Figure 1-3 illustrates the routing control format for the RIF. Descriptions of each field follow.
Figure 1-4 describes the routing descriptor format of the RIF string. Definitions of each field follow the figure.
The following sections describe how to enable and configure static RIF entries.
Level 3 routers that use protocol-specific information (for example, Novell IPX or XNS headers) rather than MAC information to route datagrams must also be able to collect and use RIF information to ensure that the Level 3 routers can transmit datagrams across a source-route bridge. The Cisco software default is to not collect and use RIF information for routed protocols. This allows operation with software that does not understand or properly use RIF information, such as versions of Novell NetWare prior to Version 2.15c.
To enable collection and use of RIF information, use the multiring interface subcommand. The full command syntax follows:
multiring {protocol-keyword|all|other}The current software allows you to specify a protocol. This is specified by the argument protocol-keyword. The protocols supported and the keyword you enter follow:
There are also two special keywords with the multiring command. The keyword all enables the multiring for all frames. The keyword other enables the multiring for any routed frame not included in the previous list of supported protocols.
The multiring command was extended in software release 8.3 to allow for per-protocol specification of the interface's ability to append RIFs to routed protocols. When it is enabled for a protocol, the router will source packets that include information used by source-route bridges. This allows a Cisco router with Token Ring interfaces, for the protocol or protocols specified, to connect to a source-bridged Token Ring network. If a protocol is not specified for multiring, the Cisco router can only route packets to nodes directly connected to its local Token Ring.
The no multiring subcommand with the appropriate keyword disables the use of RIF information for the protocol specified.
These commands enable a Token Ring interface for the IP and Novell IPX protocols. RIFs will be generated for IP frames, but not for the Novell IPX frames.
interface tokenring 0 multiring ip ip address 131.108.183.37 255.255.255.0 novell network 33
RIF information is maintained in a cache whose entries are aged. The global configuration command rif timeout determines the number of minutes an inactive RIF entry is kept. The full command syntax follows:
rif timeout minutesThe default interval is 15 minutes. The minimum value is one minute. Assign a new interval value using the minutes argument.
The no rif timeout command restores the default.
The EXEC command show rif displays the contents of the RIF cache. The EXEC command clear rif-cache clears the contents of RIF cache. See the sections "Maintaining the Source-Route Bridge" and "Monitoring the Source-Route Bridge" later in this chapter for more information about these commands.
This command changes the timeout period to five minutes.
rif timeout 5
If a Token Ring host does not support the use of IEEE 802.2 TEST or XID datagrams as explorer packets, you may need to add static information to the RIF cache of the router/bridge.
To enter static source-route information into the RIF cache, use the following variation of the rif global configuration command:
rif MAC-address [RIF-string] [interface-name|ring-group ring]The argument MAC-address is a 12-digit hexadecimal string written as a dotted triple, for example 0010.0a00.20a6.
Using the command rif MAC-address without any of the optional arguments puts an entry into the RIF cache indicating that packets for this MAC address should not have RIF information.
The command no rif MAC-address removes an entry from the cache.
The optional argument RIF-string is a series of 4-digit hexadecimal numbers separated by a dot (.). This RIF string is inserted into the packets sent to the specified MAC address.
An interface name (for example, tokenring0) can be specified with the optional interface-name argument, to indicate the origin of the RIF.
A ring group number (specified with the source-bridge ring-group global configuration command) may also be specified with the ring-group keyword and ring argument, to indicate the origin of the RIF. Ring groups are explained in the section "Configuring Ring Groups and Multiport Source-Route Bridges."
Do not configure a static RIF with any of the all rings type codes. Doing so causes traffic for the configured host to appear on more than one ring and leads to unnecessary congestion. The format of a RIF string is illustrated in Figure 1-2 , Figure 1-3 , and Figure 1-4 .
In this example configuration, the path between rings 8 and 9 connected via source-route bridge 1 is described by the route descriptor 0081.0090. A full RIF, including the route control field, would be 0630.0081.0090. The static RIF entry would be submitted to the leftmost router as shown in Figure 1-5.
rif 1000.5A12.3456 0630.0081.0090
As another example, assume a datagram was sent from a Cisco router/bridge on ring 21 (15 hexadecimal), across bridge 5 to ring 256 (100 hexadecimal), and then across bridge 10 (A hexadecimal) to ring 1365 (555 hexadecimal) for delivery to a destination host on that ring. See Figure 1-6.
The RIF in the leftmost router describing this two-hop path is 0830.0155.100a.5550, and is entered as follows:
rif 1000.5A01.0203 0830.0155.100a.5550
This section describes how to configure the Cisco router/bridge as a local source-route bridge. A local source-route bridge directly connects two or more Token Ring networks. Bridged traffic does not pass across non-Token Ring media.
When acting as a source-route bridge, only those protocols that are not being routed are source-route bridged. For example, if Novell routing is enabled on the Cisco router/bridge, Novell datagrams will not be source-bridged. Datagrams for other nonrouted protocols will be source-bridged, however.
To configure an interface for local source-route bridging, use the source-bridge interface subcommand as follows:
source-bridge local-ring bridge-number target-ringThe argument local-ring is the ring number for this interface's Token Ring. A ring number is a decimal number between 1 and 4095 that uniquely identifies a network segment or ring within the bridged Token Ring network.
The argument bridge-number is a decimal number between 1 and 15 that uniquely identifies a bridge connecting the two rings.
The argument target-ring is the decimal ring number of the destination ring on this
router/bridge. It must also be unique within the bridged Token Ring network.
The no source-bridge command disables source bridging on a particular interface.
Figure 1-7 illustrates a simple two-port bridge configuration. The sample text following this figure provides the configuration commands.
interface token ring 0 source-bridge 129 1 130 ! interface token ring 1 source-bridge 130 1 129
Token Rings 129 and 130 are connected via the Cisco router/bridge.
There are two types of explorer packets used to collect RIF information:
Use the source-bridge spanning interface subcommand to enable use of spanning explorers. The full command syntax follows:
source-bridge spanningThe command puts the interface into a forwarding or active state with respect to the spanning tree.
The no source-bridge spanning command disables use of spanning explorers. Only spanning explorers will be blocked; everything else will be forwarded. Use of the source-bridge spanning command is recommended.
If you wish to limit the maximum number of source-route bridge hops of your network, use the source-bridge max-hops interface subcommand. The full command syntax follows:
source-bridge max-hops countThe argument count determines the number of bridges an explorer packet may traverse. Typically, the maximum number of bridges for interoperability with IBM equipment is seven (eight rings and seven bridges).
The command no source-bridge max-hops resets the count back to the maximum value.
The following example builds on the dual-port, source-route bridge configuration seen in Figure 1-7. The example routes IP and source-route bridges all other protocols. Spanning explorers are used.
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 multiring all
The multiring subcommand causes the IP routing software to use RIFs, as necessary.
To configure a source-route bridge with more than two network interfaces, Cisco uses the concept of a ring group. A ring group is a collection of Token Ring interfaces in one or more Cisco routers that are collectively treated as a virtual ring. The ring group is denoted by a ring number that must be unique for the network. The ring group's number is used just like a physical ring number, showing up in any route descriptors contained in packets being bridged.
A ring group is defined or removed with the source-bridge ring-group global configuration command. The full command syntax follows:
source-bridge ring-group ring-numberTo configure a specific interface as part of a ring group, its target ring number parameter is set to the ring group number specified in this command. You should not use the number 0, as this is reserved to represent the local ring.
Figure 1-8 shows an example configuration of a four-port Token Ring source-route bridge.
Rings 1000, 1001, 1002, and 1003 are all source-route bridged to each other across ring group 7.
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
The previous section discussed local source-route bridging, or bridging between Token Rings connected by the same router/bridge. This section describes how to configure remote source-route bridges involving multiple router/bridges separated by non-Token Ring network segments. The following sections assume you are familiar with configuring a Cisco local source-route bridge.
There are two ways to set up remote source-route bridging. You can encapsulate the source-route bridged traffic inside IP datagrams passed over a TCP connection between two router/bridges. TCP is used to ensure the reliable and ordered delivery of source-route-bridged traffic. TCP has the following advantages:
You can also set up a remote source-route bridge to use only a MAC layer encapsulation to pass frames over a single physical network connection between two routers attached to Token Rings. Use this method when you are running source-route bridge traffic over a slow serial line (56 kpbs or less). You do not have the flexibility of the TCP approach, but you do have better performance as there is less overhead.
To configure a remote source-route bridge to use TCP, follow these steps:
Step 1: Define a ring group. Every Cisco router/bridge with which you wish to exchange Token Ring traffic must be a member of this same ring group. These other router/bridges are referred to as peers.
Step 2: List your peers with multiple uses of the source-bridge remote-peer command. You must include one of your own IP addresses in that list. Each peer should appear only once in this list, not one time for each Token Ring present. All peers should have the same list of peers. Listing the peer bridges is described in greater detail below.
Step 3: Configure the Token Ring interfaces for source-route bridging. The value of the target ring parameter for the source-bridge command should be the ring group number.
The source-bridge remote-peer global configuration command has the following syntax when using TCP:
source-bridge remote-peer ring-group tcp ip-address [lf size][local-ack] [version number]Use this command to identify the IP address of a peer in the ring group with which to exchange source-bridge traffic using TCP.
The keyword lf specifies the maximum size frame to be sent to this remote peer. The router negotiates all transit routes down to this size or lower. Use this argument to prevent timeouts in end hosts by reducing the amount of data they have to transmit in a fixed interval. For example, in some networks containing slow links, it would be impossible to transmit an 8K frame and receive a response within a few seconds. These are fairly standard defaults for an application on a 16 Mb Token Ring. If the frame size is lowered to 516 bytes, then only 516 bytes must be transmitted and a response received in 2 seconds. This is a much easier accomplishment in a network with slow links. The legal values for this argument are 516, 1500, 2052, 4472, 8144, 11407, and 17800 bytes.
The keyword local-ack specifies that Local Acknowledgment should be used for LLC2 sessions going to this remote peer. Refer to the section "The Cisco Local Acknowledgment Function" in this chapter for a discussion of Local Acknowledgment.
The keyword version specifies the forced RSRB protocol version number for the remote peer.
The following example illustrates a configuration of two router/bridges configured for remote source-route bridging using TCP as a transport. Each router has two Token Rings. They are connected together by an Ethernet segment over which the source-route bridged traffic will pass. The first router configuration is a source-route bridge at address 131.108.2.29. These peers are both running Release 9.0, so the version keyword has been specified on the remote-peer statements. Figure 22-9 illustrates this network:
The configuration for the source-route bridge at address 131.108.2.29 as depicted in
Figure 1-9 would be as follows:
source-bridge ring-group 5 source-bridge remote-peer 5 tcp 131.108.2.29 version 2 source-bridge remote-peer 5 tcp 131.108.1.27 version 2 ! interface ethernet 0 ip address 131.108.4.4 255.255.255.0 ! interface tokenring 0 ip address 131.108.2.29 255.255.255.0 source-bridge 1000 1 5 source-bridge spanning ! interface tokenring 1 ip address 131.108.128.1 255.255.255.0 source-bridge 1001 1 5 source-bridge spanning
The configuration of the source-route bridge at 131.108.1.27 is:
source-bridge ring-group 5 source-bridge remote-peer 5 tcp 131.108.2.29 source-bridge remote-peer 5 tcp 131.108.1.27 ! interface ethernet 0 ip address 131.108.4.5 255.255.255.0 ! interface tokenring 0 ip address 131.108.1.27 255.255.255.0 source-bridge 10 1 5 source-bridge spanning ! interface tokenring 1 ip address 131.108.131.1 255.255.255.0 source-bridge 11 1 5 source-bridge spanning
You can limit the size of the backup queue for remote source-route bridging to control the number of packets that can wait for transmission to a remote ring before packets start being thrown away. Use the source-bridge tcp-queue-max global command to do this. The full syntax for this command follows.
source-bridge tcp-queue-max numberThe argument number is the number of packets to hold in any single outgoing TCP queue to a remote Cisco router. The default value is 100. Enter the no source-bridge tcp-queue-max command to return to the default value.
If, for example, your network experiences temporary bursts of traffic using the default packet queue length, the following command raises the limit from 100 to 150 packets.
source-bridge tcp-queue-max 150
To configure a remote source-route bridge to use a point-to-point serial line or a single Ethernet, FDDI, or Token Ring hop, follow these steps:
Step 1: Define a ring group. Every Cisco router/bridge with which you wish to exchange Token Ring traffic must be a member of this same ring group. These other router/bridges are referred to as peers.
Step 2: List the interfaces over which you will be sending source-route bridged traffic with the source-bridge remote-peer command. The interfaces must be serial, Ethernet, FDDI, or Token Ring. On a serial interface, you must use the HDLC encapsulation.
Step 3: Configure the Token Ring interfaces for source-route bridging. The value of the target ring parameter for the source-bridge commands should be the ring group number.
The source-bridge remote-peer global configuration command has the following syntax when used to specify a point-to-point direct encapsulation connection:
source-bridge remote-peer ring-group interface interface-name [mac-address] [lf size]Use this command to identify the interface over which to send source-route bridged traffic to another Cisco router/bridge in the ring group. A serial interface does not require that you include a MAC-level address; all other types of interfaces do require that you supply a MAC address. To find the MAC address, type the command show interface on the remote router, as in the following example output. The MAC address in this example is 5500.2000.dc27:
router#show interface
TokenRing 0 is up, line protocol is up
Hardware is 16/4 Token Ring, address is 5500.2000.dc27 (bia 0000.3000.072b)
Internet address is 150.136.230.203, subnet mask is 255.255.255.0
MTU 8136 bytes, BW 16000 Kbit, DLY 630 usec, rely 255/255, load 1/255
Encapsulation SNAP, loopback not set, keepalive set (10 sec)
ARP type: SNAP, ARP Timeout 4:00:00
Ring speed: 16 Mbps
Single ring node, Source Route Bridge capable
Group Address: 0x00000000, Functional Address: 0x60840000
Last input 0:00:01, output 0:00:01, output hang never
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
Five minute input rate 0 bits/sec, 0 packets/sec
Five minute output rate 0 bits/sec, 0 packets/sec
16339 packets input, 1496515 bytes, 0 no buffer
Received 9895 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
32648 packets output, 9738303 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets, 0 restarts
5 transitions
The keyword lf specifies the maximum size frame to be sent to this remote peer. The router negotiates all transit routes down to this size or lower. This argument is useful in preventing timeouts in end hosts, by reducing the amount of data they have to transmit in a fixed interval. For example, in some networks containing slow links, it would be impossible to transmit an 8K frame and receive a response within a few seconds. These are fairly standard defaults for an application on a 16 Mb Token Ring. If the frame size is lowered to 516 bytes, then only 516 bytes must be transmitted and a response received in 2 seconds. This is a much easier accomplishment in a network with slow links. The legal values for this argument are 516, 1500, 2052, 4472, 8144, 11407, and 17800 bytes.
The keyword version specifies the forced RSRB protocol version number for the remote peer.
Figure 1-10 shows an example configuration of a router/bridge configured for remote source-route bridging using both the direct and TCP transport methods.
The configuration for the network as depicted in Figure 1-10 would be as follows:
source-bridge ring-group 5 source-bridge remote-peer 5 interface serial0 source-bridge remote-peer 5 interface Ethernet0 0000.0c00.1234 source-bridge remote-peer 5 tcp 131.108.254.6 source-bridge remote-peer 5 tcp 131.108.251.1 ! interface tokenring 0 source-bridge 1 1 5 source-bridge spanning ! interface ethernet 0 ip address 131.108.251.1 255.255.255.0
Use the source-bridge largest-frame global configuration command to configure the largest frame size that is used to communicate with any peers in the ring group. The full syntax of the command follows:
source-bridge largest-frame ring-group sizeThe argument ring-group is the ring group number; the argument size is the maximum frame size.
The router negotiates all transit routes down to the specified size or lower. This argument is useful in preventing timeouts in end hosts by reducing the amount of data they have to transmit in a fixed interval. For example, in some networks containing slow links, it would be impossible to transmit an 8K frame and receive a response within a few seconds. These are fairly standard defaults for an application on a 16 Mb Token Ring. If the frame size is lowered to 516 bytes, then only 516 bytes must be transmitted and a response received in 2 seconds. This feature is most effective in a network with slow links. The legal values for this argument are 516, 1500, 2052, 4472, 8144, 11407, and 17800 bytes.
Cisco has implemented the proxy explorer function to allow the Cisco source-route bridge to respond to a particular destination node. Use proxy explorers to limit the amount of explorer traffic propagating through the source-bridge network, especially across low bandwidth serial lines. The proxy explorer is most useful for multiple connections to a single node.
The following conditions must be met in order for a proxy response to occur:
If all of the above conditions are met, the Cisco source-route bridge will turn the packet around, append the appropriate RIF, and reply to the source node.
Use the source-bridge proxy-explorer interface subcommand to configure the interface to respond to any explorer packets that meet the conditions described above. The command has this syntax:
source-bridge proxy-explorerThe default is to not respond with proxy explorer packets.
These commands configure the Cisco router/bridge to use proxy explorers on interface Token Ring 0.
interface tokenring 0 source-bridge proxy-explorer
LLC2, or Logical Link Control-Type 2, an ISO standard data link level protocol used in Token Ring networks, was designed to ensure reliable transmission of data across LAN media having minimal or predictable time delays. With the advent of remote source-route bridging (RSRB) and wide-area network (WAN) backbones, LANs are now separated by wide, geographic distances spanning countries and continents. As a result, these LANs have time delays that are longer than LLC2 allows for bidirectional communication between hosts. The Local Acknowledgment capability in router/bridges supporting RSRB addresses the problem of unpredictable time delays, multiple retransmissions, or loss of user sessions.
Figure 1-11 illustrates an LLC2 session. IBM 1 (for example, a 37x5) on a LAN segment can communicate with IBM 2 (for example, a 3x74) on a different LAN segment separated via a wide area backbone network. Frames are transported between Cisco A and Cisco B using RSRB. However, the LLC2 session between IBM 1 and IBM 2 is still end-to-end; that is, every frame generated by IBM 1 traverses the backbone network to IBM 2, and IBM 2, on receipt of the frame, acknowledges it.
In an LLC2 session, when host A sends a frame to host B, host A expects host B to respond positively or negatively in a certain amount of predefined time commonly called the T1 time. If host A does not receive an acknowledgment of the frame it sent to host B within the T1 time, it will retry a few number of times (normally 8 to 10). If there is still no response from host B, host A will drop the session.
On backbone networks consisting of slow serial links, the T1 timer on end hosts could expire before the frames have a chance to reach the remote hosts, causing the end host to retransmit. This results in duplicate frames reaching the remote host at the same time as the first frame also reached the remote host, albeit slowly. These frame duplications break the LLC2 protocol, resulting in the loss of sessions between the two IBM machines.
One way to solve this problem is to increase the timeout value on the end hosts to account for the maximum transit time between the two end machines. However, in networks consisting of hundreds or even thousands of nodes, every machine would need to be reconfigured with new values.With Local Acknowledgment turned on, the LLC2 session between the two IBM end nodes is not end-to-end, as shown in the previous example, but instead terminates at the two local Cisco routers, as shown in Figure 1-12. The LLC2 session with IBM 1 ends at Cisco A and the LLC2 session with IBM 2 ends at Cisco B. Both Cisco A and Cisco B execute the full LLC2 protocol as part of Local Acknowledgment.
With Local Acknowledgment enabled in both routers, Cisco A acknowledges frames received from IBM 1. The node IBM 1 still thinks that the acknowledgments it receives are from IBM 2. Cisco A looks like IBM 2 to IBM 1. Similarly, Cisco B acknowledges frames received from IBM 2. The node IBM 2 thinks that the acknowledgments it receives are from IBM 1. Cisco B looks like IBM 1 to IBM 2. As the frames no longer have to travel the WAN backbone networks to be acknowledged, but instead are locally acknowledged by Cisco routers, the end machines do not time out, resulting in no loss of sessions.
The advantages of enabling Local Acknowledgment are:
The Cisco routers at each end of the LLC2 session execute the full LLC2 protocol, which could result in some overhead. The decision to turn on Local Acknowledgment should be based on the speed of the backbone network vis-a-vis the Token Ring speed. For LAN segments separated by slow speed serial links (for example, 56 kbps) the T1 timer problem could occur more frequently. In such cases, it may be wise to turn on Local Acknowledgment. For LAN segments separated by a FDDI backbone, backbone delays will be minimal; in such cases, Local Acknowledgment should not be turned on. Speed mismatch between the LAN segments and the backbone network is one criterion to be used in the decision to use Local Acknowledgment.
There are some situations (such as host B dying between the time A sends data and B would get it), when host A would believe, at the LLC2 layer, that data was received that actually was not, because the Cisco router acknowledges that it received data from host A before it knows that host B can actually receive the data. But because both NetBIOS and SNA have error recovery in situations where an end device goes down, these higher-level protocols will resend any missing or lost data. These transaction request/confirmation protocols exist above LLC2, so they are not affected by tight timers, as is LLC2. They also are transparent to Local Acknowledgment.
If you are using NetBIOS applications, note that there are two NetBIOS timers--one at the link level and one at the next higher level. Local Acknowledgment is designed to solve session timeouts at the link level only. If you are experiencing NetBIOS session timeouts, you have two options:
Local acknowledgment can only be enabled with TCP remote peers (as opposed to LAN or direct serial-interface remote peers) because the routers need the reliable transmission of TCP to provide the same reliability of the pre-Local Acknowledgment end-to-end connection. Therefore, the direct media encapsulation options for the source-bridge remote-peer command cannot be used.
If the LLC2 session between the local host and the router terminates in either router, the other will be informed to terminate its connection to its local host.
If the TCP queue length of the connection between the two Cisco routers reaches 90% of its limit, the Cisco routers will send Receiver-not-ready (RNR) messages to the local hosts until the queue limit is reduced to below this limit.
The configuration of the LLC2 parameters for the local Token Ring interfaces can affect overall performance. Please refer to the chapter "LLC2 and SDLC Link-Level Support" for more details about fine-tuning your network through the LLC2 parameters.
Set up Local Acknowledgment by specifying the local-ack keyword of the global
source-bridge remote-peer command.
The source-bridge remote-peer subcommand is given a new option local-ack that indicates that LLC2 sessions destined to a specific remote peer are to be locally administered and acknowledged. The following example configuration demonstrates setting up one remote peer for Local Acknowledgment:
. . . source-bridge ring-group 100 source-bridge remote-peer 100 tcp 1.1.1.1 source-bridge remote-peer 100 tcp 1.1.1.2 local-ack . . . interface tokenring 0 source-bridge 1 1 100 . . .
This configuration allows the following: sessions between a device on Token Ring 0 that must go through remote peer 1.1.1.2 will use Local Acknowledgment, but sessions that must go through remote peer 1.1.1.1 will not use Local Acknowledgment (that is, they will "pass through").
The local-ack parameter of the source-bridge remote-peer command locally terminates every new LLC2 session. When you want only some sessions on a few rings to be locally acknowledged and the remaining to pass through, use t.he following command:
source-bridge passthrough ring-numberThe global command source-bridge passthrough indicates that if a machine on a Token Ring attempts to start an LLC2 session to an end host that exists on the ring-number, the session will "pass through" and not use Local Acknowledgment. More than one source-bridge passthrough command may be given. The ring-number is either the start ring or the destination ring for the two IBM end machines. The no version of the command disables all the rings and allows the session to locally acknowledge.
For example, the following list of commands indicates that rings 4 and 7 are never to have Local Acknowledgment applied to them, even if they are accessed through remote peers for which local-ack has been specified in the source-bridge remote-peer command:
source-bridge passthrough 4 source-bridge passthrough 7
In some situations, you may discover that default settings for LLC2 configurations may not be acceptable. In such a case, you may configure LLC2 for optimal use. the chapter "LLC2 and SDLC Link-Level Support" describes the LLC2 commands and how you can use them to optimize your network performance. Significant improvements in network performance can be had through judicious use of these commands.
The command show local-ack shows the current state of any current Local Acknowledgment connections, as well as any configured passthrough rings.
show local-ack
router#show local-ack
local 1000.5a59.04f9, lsap 04, remote 4000.2222.4444, dsap 04
llc2 = 1798136, local ack state = connected
Passthrough Rings: 4 7
The first two lines of the show local-ack command state that there is a Local Acknowledgment session between two Token Ring devices. The device on the local ring has a MAC address of 1000.5a59.04f9 with a sap of 04. The remote device has a MAC address of 4000.2222.4444 with a sap of 04. The state of the Local Acknowledgment session is connected.
The Passthrough Rings display is independent of the rest of the show local-ack command. The Passthrough Rings display indicates that there are two rings, 4 and 7, configured for Passthrough. This means that stations on these rings will not have their sessions locally acknowledged but will instead have their acknowledgments end-to-end.
Table 1-1 describes the fields shown in the above example.
| Field | Description |
|---|---|
| Local | Indicates the MAC address of the local Token Ring station with which the router has the LLC2 session. |
| Lsap | The local SAP (service access point) value of the Token Ring station with which the router has the LLC2 session. |
| Remote | The MAC address of the remote Token Ring station on whose behalf the router is providing acknowledgments. The remote Token Ring station is separated from the router via the TCP backbone. |
| Dsap | The destination SAP value of the remote Token Ring station on whose behalf the router is providing acknowledgments. |
| LLC2 | A pointer to an internal data structure used by Cisco staff for debugging. |
| Local ack state: | Any of: |
| disconnected | No session between the two end hosts. |
| connected | Full data transfer possible between the two. |
| awaiting connect | This router is waiting for the other end to confirm a session establishment with the remote host. |
There are two debug commands for Local Acknowledgment: debug local-ack and debug local-ack-state. For each of the following debug commands there is a corresponding undebug command that stops the output.
This command displays Local Acknowledgment debugging information useful for Cisco staff.
This command prints out the new and the old state conditions whenever there is a state change in the Local Acknowledgment state machine. This command is used by Cisco staff for debugging purposes.
This section describes the support for bridging between source-route bridge groups and transparent bridge groups using the Cisco router's Source-Route Translational Bridging
(SR/TLB) functionality. This section assumes familiarity with Cisco's implementation of both source-route and transparent bridging. SR/TLB allows you to combine source-route and transparent bridged networks without the need to convert all of your existing source-route bridges to transparent bridge-capable (SRT) nodes. As such, it provides a cost-effective connectivity path between, for example, Ethernets and Token Rings.
You may bridge packets between a source-route bridging 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 source-route (typically, Token Ring) domain to the transparent bridging (typically, Ethernet) domain, the source-route fields of the frames are removed. This RIF is cached for use by subsequent return traffic.
When bridging from the transparent bridging domain to the source-route bridged domain, the packet is checked to see if it has a multicast or broadcast destination, or a unicast (single host) destination. If it has a multicast, the packet is sent as a spanning-tree explorer. If it has a unicast destination, a RIF path is looked up to the destination in the RIF cache. If a path is found, it will be used, otherwise the packet will be sent as a spanning-tree explorer.
An example of a simple topology is shown in Figure 1-13.
A new subcommand of the global source-bridge configuration command is used to establish bridging between transparent bridging and source-route bridging.
The command syntax is:
source-bridge transparent ring-group pseudo-ring bridge-num tb-groupThe ring-group argument is a virtual ring group created by the source-bridge ring-group command. This is the source-bridge virtual ring to associate with the transparent bridge group.
The pseudo-ring argument is the ring number used to represent the transparent bridging domain to the source-route bridged domain. This number must be a unique number, not used by any other ring in your source-route bridged network.
The bridge-num argument is the bridge number of the bridge which leads to the transparent bridging domain.
The tb-group argument is the number of the transparent bridge group that you wish to tie into your source-route bridged domain. The no version of the command disables this feature.
The steps involved in configuring SR/TLB are to:
Step 1: Configure source-route bridging and transparent bridging.
Step 2: Choose a pseudo-ring number for the transparent bridging domain.
Step 3: Choose a bridge-number for the path to the transparent bridging domain.
Step 4: Enter the source-bridge transparent command in the configuration.
In the simple example illustrated in Figure 1-14, a four-port router with two Ethernets and two Token Rings is used to connect transparent bridging on the Ethernets to source-route bridging on the Token Rings.
Assume the following configuration for source-route bridging and transparent bridging existed before the desire 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
One aspect of this configuration must change immediately: the two Token Ring interfaces are communicating with two-port local source-route bridging. The addition of SR/TLB creates a third ring, so these two interfaces must be reconfigured to communicate through a virtual ring, as shown:
! 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
At this point, the configuration is ready for the addition of the source-bridge transparent bridge command. You must determine two things:
Once you have determined the ring number and the bridge number, the command can then be added, giving this final configuration:
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
The meaning of each field in the source-bridge transparent command from the above configuration is described in Table 1-2:
| Field | Description |
|---|---|
| 10 | The ring-group to which the command applies; corresponds to the ring-group number given in the source-bridge commands. |
| 3 | The ring number assigned to the pseudo-ring. |
| 1 (first) | The bridge number leading to the pseudo-ring. |
| 1 (second) | The transparent bridge-group tied into this source-route bridged ring group; corresponds to the bridge number given in the transparent bridging commands. |
The following notes and caveats apply to all uses of SR/TLB:
Assume you have the following setup, where you want to connect only a single machine, HostE, on an Ethernet to a single machine, HostR, on the Token Ring, as shown in
Figure 1-15:
You want to allow only these two machines to communicate across the router. Therefore, you might create the following configuration to restrict the access. This configuration will not work, for the last reason stated in the notes above.
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 Token Ring interface command states to apply the access-list 701 on the Source Address of frames going out to the Token Ring, and the Ethernet interface command says to apply the access list on the source address frames entering the interface from Ethernet. This would work fine 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 HostE on the Token Ring is not 0110.2222.3333, but rather 8008.4444.cccc. The following configuration is better. In general, the best way to keep this straight is to keep your access lists for Token Ring and Ethernet completely separate from one another.
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
To transfer data between IBM 8209 Ethernet/Token Ring bridges and Cisco routers running the SR/TLB software, (to create a Token Ring backbone to connect Ethernets), issue the following global command on each Cisco router:
bridge old-ouiThis command, when given, causes the OUI code in Token Ring frames translated to and from Ethernet Type II to be 0x000000. The default OUI value, used when this command is not given, is 0x0000F8. This default value is compatible with the draft value used in various SRT protocol documents.
The no version of the command restores the default value.
Even with the source-bridge old-oui command specified to match the OUIs, there is one caveat in that Ethernet SNAP frames traversing a Token Ring backbone made up of both Cisco SR/TLB routers and IBM 8209 bridges will be converted into Ethernet Type II frames on output to the Ethernet attached to the Cisco router. This restriction does not apply to networks built entirely of Cisco SR/TLB routers.The following paragraphs describe the differences in design philosophies between Cisco routers and IBM 8209 bridges that result in this caveat when you use both products.
The Cisco router, acting as a SR/TLB, can distinguish immediately on input on Token Ring interfaces between frames that started on an Ethernet as an Ethernet Type II frame, and those that started on an Ethernet as a SNAP-encapsulated frame. This distinction is possible because the Cisco router uses the 0x0000F8 OUI when converting Ethernet Type II frames into Token Ring SNAP frames, and leaves the OUI as 0x000000 for Ethernet SNAP frames going to a Token Ring. This distinction in OUIs leads to efficiencies in the design and execution of the Cisco SR/TLB product, as no tables need be kept to know which Ethernet hosts use SNAP encapsulations and which hosts use Ethernet Type II.
The IBM 8209 bridge, however, by using the 0x000000 OUI for all frames entering the Token Ring, must take extra measures to perform the translation. For every station on each Ethernet, the 8209 bridges attempt to remember the frame format used by each station, and assume that once a station sends out a frame using Ethernet Type II or 802.3, it will always continue to do so. It must do this because in using 0x000000 as an OUI, there is no way to distinguish between SNAP and Type II frame types. As the Cisco SR/TLB router does not need to keep this database, when 8209 compatibility is enabled with the source-bridge old-oui command, it chooses to translate all Token Ring SNAP frames into Ethernet Type II frames. As virtually every nonroutable protocol on Ethernet uses either non-SNAP 802.3 (which traverses fully across a mixed IBM 8209/Cisco router Token Ring backbone) or Ethernet Type II, this results in correct interconnectivity for virtually all applications.
Many Ethernet-attached IBM devices, including PS/2s running OS/2 Extended Edition and RT-PCs, use a nonstandard encapsulation of LLC2 on Ethernet to allow for communication on Ethernets that support only Ethernet Type 2 communication, and not Ethernet 802.3 frame formats. Such an IBM device does not place its LLC2 data inside an 802.3 format frame, but rather places it into an Ethernet Type II frame whose type is specified as 0x80d5. Cisco routers support both. The format of these frames is given in the appendix "Frame Conversions."
The Cisco router supports the conversion between Token Ring LLC2 data and the Ethernet 0x80d5 format. In so doing, there are now two ways in the router to specify a translation between Ethernet and Token Ring for LLC2 frames.
By default, 0x80d5 processing is disabled. As such, Token Ring LLC2 frames are translated in a straightforward manner into Ethernet 802.3 LLC2 frames. This works for most non-IBM hosts, however, the hosts using the special Ethernet Type 2 0x80d5 format cannot read these frames.
source-bridge enable-80d5This command changes the Cisco router's Ethernet/Token Ring translation behavior to translate Token Ring LLC2 frames into Ethernet 0x80d5 format frames. The no version of the command restores the default behavior.
However, after specifying this command, you may still need to allow some other, non-IBM hosts to use the other form of LLC2 translation. As such, the translation method can be specified on a per-DSAP basis with the following command:
source-bridge sap-80d5 sapThese commands enable, or disable with the no version of the command, the use of the Ethernet 0x80d5 format for Ethernet/Token Ring translation of LLC2 frames. By default, the following DSAPS are enabled for 0x80d5 translation simply by specifying the source-bridge enable-80d5 command:
Any of these may be disabled with the no version of this command.
The parameters specifying the current parameters for the processing of 0x80d5 frames are given at the end of the output of show span.
The following commands enable 0x80d5 processing, remove the translation for SAP 08, and add the translation for SAP 1c:
source-bridge enable-80d5 no source-bridge sap-80d5 08 source-bridge sap-80d5 1c
A partial output of show span given the above configuration follows:
router#show span...extra output deleted...Translation between LLC2 and Ethernet Type II 80d5 is enabledTranslation is enabled for the following DSAPs:04 0C 1C F0
The frame conversions between the two bridging protocols are given in the appendix "Frame Conversions."
Source-route bridges normally filter frames according to the routing information contained in the frame. That is, a bridge will not forward a frame back to its originating network segment or any other network segment that the frame has already traversed. Further types of filtering (administrative filtering) can be specified by the network manager.
Administrative filtering can be done by:
Filtering by Token Ring address or vendor code will cause no significant performance penalty. However, performance will be significantly affected when filtering by protocol type. A list of SNAP (Ethernet) type codes is provided in the appendix "Ethernet Type Codes."
The access list mechanism permits filtering by protocol type. Use the bridge access-list command to specify an element in an access list. The order in which access-list commands are entered into the system 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, then a deny decision is reached.
Use the bridge access-list global configuration command to configure the access list mechanism for filtering frames by protocol type. The command has this syntax:
access-list list {permit|deny} type-code wild-maskThe argument list is a user-selectable number in the range 200 - 299, inclusive, that identifies the list.
The keyword permit permits the frame; the keyword deny denies the frame.
The argument type-code is a 16-bit hexadecimal number written with a leading 0x, for example, 0x6000. Specify either a Link Service Access Point (LSAP) type code for 802-encapsulated packets, or a SNAP type code for SNAP-encapsulated packets. (LSAP, sometimes called SAP, refers to the type codes found in the DSAP and SSAP fields of the 802 header.)
The argument wild-mask is another 16-bit hexadecimal number whose ones bits correspond to bits in the type-code argument that should be ignored when making a comparison. (A mask for a DSAP/SSAP pair should always be 0x0101. This is because these two bits are used for purposes other than identifying the SAP code. The no version removes the single specified entry from the access list.
In this example, the access list permits only Novell frames (LSAP 0xE0E0) and filters out all other frame types. This set of access lists would be applied to an interface via the source-bridge input-lsap list or source-bridge input-lsap list command (described in following sections).
access-list 201 permit 0xE0E0 0x0101 access-list 201 deny 0x0000 0xFFFF
Combine the DSAP/LSAP fields into one number to do LSAP filtering, for example, 0x E0E0--not 0xE0. Note that the deny condition specified in the above example is not required; access lists have an implicit deny as the last statement. Adding this statement can serve as a useful reminder, however.
The following access list filters out only SNAP type codes assigned to DEC (0x6000 through 0x6007) and lets all other types pass. This set of access lists would be applied to an interface via the source-bridge input-type list or source-bridge output-type-list command which are described in the following sections.
access-list 202 deny 0x6000 0x0007 access-list 202 permit 0x0000 0xFFFF
Type code access lists will negatively affect system performance by greater than 30 percent. Therefore, Cisco Systems recommends keeping the lists as short as possible and using wild card bit masks whenever possible.
You can filter IEEE 802-encapsulated packets on input. The access list specifying the type codes to be filtered is given by this variation of the source-bridge interface subcommand:
source-bridge input-lsap-list listThe argument list is the access list number. This access list is applied to all IEEE 802 frames received on that interface prior to the source-routing process. Specifying a zero disables the filter.
This command specifies access list 203.
source-bridge input-lsap-list 203
The software allows you to filter IEEE 802-encapsulated packets on output. The access list specifying the type codes to be filtered is given by this variation of the source-bridge interface subcommand:
source-bridge output-lsap-list listThe argument list is the access list number. This access list is applied just before sending out a frame to an interface. Specifying a zero disables the filter.
This command specifies access list 251.
source-bridge output-lsap-list 251
To filter SNAP-encapsulated packets on input, use the access list specifying the type codes to be filtered with this variation of the source-bridge interface subcommand:
source-bridge input-type-list listThe argument list is the access list number. This access list is then applied to all SNAP frames received on that interface prior to the source-routing process. Specify a zero for list to disable the application of the access list on the bridge group.
This command specifies access list 202.
source-bridge input-type-list 202
To filter SNAP-encapsulated frames on output, use the access list specifying the type codes to be filtered. This is entered with this variation of the source-bridge interface subcommand:
source-bridge output-type-list listThe argument list is the access list number. This access list is then applied just before sending out a frame to an interface. Specify a zero for list to disable the application of the access list on the bridge group.
Access lists for Token Ring- and IEEE 802-encapsulated packets affect only source-route bridging functions. Such access lists do not interfere with protocols that are being routed.
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
Note that it 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.
To configure administrative filtering by vendor code or address, define access lists which look for Token Ring addresses or for particular vendor codes for administrative filtering. No noticeable performance will be lost in using these access lists. The lists can be of indefinite length.
To configure a vendor code access list, use the global bridge access-list command for IEEE 802 address access lists. The command has the following form:
access-list list {permit|deny} address maskThe argument list is an integer from 700 to 799, inclusive, and address and mask are 48-bit Token Ring addresses written in dotted triplet form. The ones bits in mask are the bits to be ignored in address. See the section "Filtering Destination Addresses" for an example of command use.
Note that for source address filtering, the mask should always have the high order bit set. This is because the IEEE 802 standard uses this bit to indicate whether a RIF is present, and not as part of the source address.
To configure filtering on IEEE 802 source addresses, assign an access list to a particular interface for filtering the Token Ring or IEEE 802 source addresses. Use this variation of the source-bridge interface subcommand to do this:
source-bridge input-address-list listThe argument list is the access list number. The no version of this command removes the application of the access list. See the section "Filtering Destination Addresses" for an example of command use.
To configure filtering on IEEE 802 source addresses, assign an access list to a particluar interface for filtering the Token Ring or IEEE 802 source address. Use this variation of the source-bridge interface subcommand to do this:
source-bridge output-address-list listThe argument list is the access list number.The no version of this command removes the application of the access list.
To disallow the bridging of Token Ring packets of all IBM workstations on Token Ring 1, use this sample configuration. Software assumes that all such hosts 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. Then, the access list can be assigned to the input side of Token Ring 1.
access-list 700 deny 1000.5A00.0000 8000.00FF.FFF access-list 700 permit 0000.0000.0000 FFFF.FFFF.FFF interface token ring 1 source-bridge input-address-list 700
NetBIOS is the interface used by the IBM Token Ring/PC Network Interconnect Program 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.
The Cisco bridging software provides for configuring access control filters for packets transmitted across a Token Ring bridge using the NetBIOS interface. Two types of filters may be configured: one on source and destination station names, and one on arbitrary byte patterns in the packet itself.
To configure access control using station names, follow these steps:
Step 1: Define the access list name and specify the access condition, either permit or deny.
Step 2: Specify the direction of the message to be filtered on the interface. The choices are incoming or outgoing messages.
Keep the following notes in mind as you configure NetBIOS access control:
The NetBIOS station access list contains the station name with which to match, along with a permit or deny condition. Use the netbios access-list host global configuration command to assign the name of the access list to a station or set of stations on the network. The full command syntax follows:
netbios access-list host name {permit|deny} patternThe argument name is the name of the access list being defined.
The argument pattern is a set of characters. The characters can be the name of the station, or a combination of characters and pattern matching symbols that establish a pattern for a set of NetBIOS station names. This can be especially useful when stations have names with the same characters, such as a prefix. Table 1-3 explains the pattern matching symbols that can be used.
| Character | Field |
|---|---|
| * | Used at the end of a string to match any character or string of characters. |
| ? | Matches any single character. |
The no netbios access-list host command removes an entire list, or just a single entry from a list, depending upon the argument given for pattern.
This command specifies a full station name to match.
netbios access-list host marketing permit ABCD
This command specifies a prefix where the pattern matches any name beginning with the characters DEFG. Note that the string DEFG itself is included in this condition.
netbios access-list host marketing deny DEFG*
This command permits any station name with the letter W as the first character and the letter Y as the third character in the name. The second and fourth letters in the name can be any character. This example would allow stations named WXYZ and WAYB; however, stations named WY and WXY would not be included in this statement, as the ? must match some specific character in the name.
netbios access-list host marketing permit W?Y?
This example illustrates how to combine wildcard characters:
netbios access-list host marketing deny AC?*
The command specifies that the marketing list deny any name beginning with AC that is at least three characters in length (the ? would match any third character). The string ACBD and ACB would match, but the string AC would not.
This command removes the entire marketing NetBIOS access list.
no netbios access-list host marketing
To remove single entries from the list, use a command such as the following:
no netbios access-list host marketing deny AC?*
This example removes only the list that filters station names with the letters AC at the beginning of the name.
Keep in mind that the access lists are scanned in order. In this example the first list denies all entries beginning with the letters ABC, including one named ABCD. This voids the second command because the entry permitting a name with ABCD comes after the entry denying it.
netbios access-list host marketing deny ABC* netbios access-list host marketing permit ABCD
To define an access list filter on incoming messages, use the netbios input-access-filter host interface subcommand. The full command syntax follows:
netbios input-access-filter host nameThe argument name is the name of a NetBIOS access filter previously defined with one or more of the netbios access-list host global configuration commands.
Use the no netbios input-access-filter host command with the appropriate argument to remove the entire access list.
These commands filter packets coming into Token Ring unit 1 using the NetBIOS access list named marketing.
interface token 1 netbios input-access-filter host marketing
To define an access list filter on outgoing messages, use the netbios output-access-filter host interface subcommand. The full command syntax follows.
netbios output-access-filter host nameThe argument name is the name of a NetBIOS access filter previously defined with one or more of the netbios access-list global configuration commands.
Use the no netbios output-access-filter host command to remove the entire access list.
These commands filter packets leaving Token Ring unit 1 using the NetBIOS access list named engineering.
interface token 1 netbios output-access-filter host engineering
To configure access control using a byte offset, follow these steps:
Step 1: Define the access list name and specify the access condition, either permit or deny.
Step 2: Specify the direction of the message to be filtered on the interface. The choices are incoming or outgoing messages.
Keep the following notes in mind while configuring access control using a byte offset:
The NetBIOS byte offset access list contains a series of offsets and hexadecimal patterns with which to match byte offsets in NetBIOS packets. Use the netbios access-list bytes global configuration command to define the offset and patterns. The full command syntax follows:
netbios access-list bytes name {permit|deny} offset patternThe argument name is the name of the access list being defined.
The argument offset is a decimal number indicating the number of bytes into the packet where the byte comparison should begin. An offset of zero points to the very beginning of the NetBIOS header. Therefore, the NetBIOS delimiter string (0xffef), for example, begins at offset 2.
The argument pattern is a hexadecimal string of digits representing a byte pattern. The argument pattern must conform to certain conventions. These conventions follow.
The byte pattern must be an even number of hex digits in length. The byte pattern in the following example is legal:
netbios access-list bytes marketing permit 3 0xabcd
But the byte pattern in this example would not be accepted:
netbios access-list bytes marketing permit 3 0xabc
The byte pattern must be no more than 16 bytes (32 hexadecimal digits) in length. The byte pattern in this example would not be permitted:
netbios access-list bytes marketing permit 3 00112233445566778899aabbccddeeff00
You can specify a wildcard character in the byte string indicating that the value of that byte does not matter in the comparison. This is done by specifying two asterisks (**) in place of digits for that byte. For example, the following command would match 0xabaacd, 0xab00cd, and so on.
netbios access-list bytes marketing permit 3 0xab**cd
This command deletes the entire marketing NetBIOS access list named marketing.
no netbios access-list bytes marketing
This command removes a single entry from the list:
no netbios access-list bytes marketing deny 3 0xab**cd
Remember that, as with all Cisco access lists, the NetBIOS access lists are scanned in order. In the following example, the first line serves to deny all packets with a byte pattern starting in offset 3 of 0xab. However, this denial would also include the pattern 0xabcd because the entry permitting the pattern 0xabcd comes after the first entry:
netbios access-list bytes marketing deny 3 0xab netbios access-list bytes marketing permit 3 0xabcd
To define an access list filter on incoming messages, use the netbios input-access-filter bytes interface subcommand. The full command syntax follows:
netbios input-access-filter bytes nameThe argument name is the name of a NetBIOS access filter previously defined with one or more of the netbios access-list bytes global configuration commands.
Use the no netbios input-access-filter bytes command with the appropriate name to remove the entire access list.
These commands illustrate how to specify a filter on packets coming into Token Ring unit 1 of the NetBIOS access list named marketing.
interface token 1 netbios input-access-filter bytes marketing
To define an access list filter on outgoing messages, use the netbios output-access-filter bytes interface subcommand. The full command syntax follows:
netbios output-access-filter bytes nameThe argument name is the name of a NetBIOS access filter previously defined with one or more of the netbios access-list bytes global configuration commands.
Use the no netbios output-access-filter bytes command to remove the entire access list.
These commands filter packets leaving Token Ring unit 1 using the NetBIOS access list named engineering.
interface token 1 netbios output-access-filter bytes engineering
The boolean access expression functionality allows you to combine access filters in new ways for Token Rings. With these access expressions, you may now indicate complex conditions under which bridged frames may enter or leave an interface. With these expressions, you can achieve levels of control on the forwarding of frames that would otherwise be impossible when using only the simple access expressions.
Access expressions are constructed from elemental access lists that define administrative filtering for the following fields in the packets:
Access expressions take existing configured access lists and combine them in ways to meet complex access control needs.The following is a typical example that shows the usefulness of access expressions.
In this example network, you have a Token Ring interface on a Cisco router connected to an FDDI backbone, which has a second router attached to it in a similar setup, as shown in Figure 1-16:
On both Token Rings, you have to support both SNA and NetBIOS bridging. On the Token Ring attached to Cisco RouterA, you would like to allow the NetBIOS clients to talk to any of the NetBIOS servers off of RouterB, or any other, unpictured router. However, you would like to limit the 3174s to only talk to the one FEP off of RouterB, at MAC address 0110.2222.3333.
Without the use of access expressions, you could not achieve your desired result.A filter on RouterA which restricted access to only the FEP would have the side result of also restricting access of the NetBIOS clients to the FEP, something that is definitely not desired. What is needed is an access expression that would state "If it is a NetBIOS frame, pass through, but if it is an SNA frame, allow only access to address 0110.2222.3333."
Take the following steps to configure an access expression.
Step 1: Design the access expression (on paper).
Step 2: Design and configure in the router the individual access lists needed by the access expression.
Step 3: Configure the access expression itself into the router.
When designing an access expression, you want to come up with some phrase that indicates, in its entirety, all the frames that will pass the access expression. We will design this access expression to apply on frames coming from the Token Ring interface on RouterA.
For this example, you will want the access expression to say:
"Pass the frame if it is NetBIOS, or if it is an SNA frame destined to address 0110.2222.3333."
This phrase should be written more in the form of a boolean expression, as in:
"Pass if "NetBIOS or (SNA and destined to 0110.2222.3333).""
This statement given above requires three access lists to be designed and configured:
The following configuration allows for all the conditions stated above:
! Access list 201 passes NetBIOS frames access-list 201 permit 0xf0f0 ! ! Access list 202 permits SNA frames access-list 202 permit 0x0404 ! ! Access list 701 will permit the FEP MAC address ! of 0110.2222.3333 access-list 701 permit 0110.2222.3333
The format of the per-interface subcommand to define an access expression is:
access-expression {in|out} expressionOne of in or out is specified to indicate whether the access expression is applied to packets entering or leaving this interface. You may specify both an input and an output access expression for an interface, but only one of each. The argument expression is the boolean access list expression, built as shown below. The no version of the command removes the access expression from the given interface.
An access expression consists of a list of terms, separated by boolean operators, and optionally grouped in parentheses.
An access expression term specifies a type of access list, followed by its name or number. The result of the term is either true or false, depending on if the access list specified in the term permits or denies the frame. The term itself can be one of the following as specified in
Table 1-4:
| Access Expression Term | Definition |
|---|---|
| lsap(2nn) | Specifies the LSAP access list nnn to be evaluated for this frame. |
| type(2nn) | Specifies the SNAP type |