|
|
This chapter describes the transparent bridging support available in the Cisco Systems network server product line. Topics described in this chapter include:
This chapter also provides bridging configuration examples, and describes how to maintain, monitor, and debug your transparent bridges. Command summaries are included at the end of the chapter.
The basic function of a bridge is to accept frames of data passing through a network, and then make a decision about whether to forward each frame based on information contained in the frame.
Bridges operate at the physical (Level 1) and data-link (Level 2) layers of the Open Systems Interconnection (OSI) model. As defined by the IEEE 802.1 standard, the task of the physical layer is to provide the physical connection to the transmission medium. The task of the data link layer is to provide reliable transmission. To accomplish this effectively, the standards committee sublayered the data link layer into two distinct tasks: Logical Link Control (LLC) and Medium Access Control (MAC). Bridges, and specifically transparent bridges, function at the physical and MAC layers. However, the administrative filtering functions described later in this chapter use LLC. Figure 1-1 illustrates these concepts.
The LLC, as its name implies, controls the logical link; that is, it serves to open, maintain, and terminate a link. It depends upon the physical layers to perform its tasks.
The MAC controls access to the media used to transmit the frames. It acts independently of the physical layer and provides a service interface to the upper layers of the network model. IEEE 802.3 and Ethernet use the same MAC layer, allowing both types of frames to coexist on the same cable. In this way, the same bridge can forward both Ethernet and IEEE 802.3 frames.
The IEEE 802 standards identify two basic elements to facilitate these tasks: a 48-bit address that is either an address for an individual station or a group of stations, and Service Access Points (SAPs), which can be thought of as ports through which a higher-layer application may communicate with its counterparts (peers) operating on other systems.
The IEEE 802 standards also allow any IEEE 802-compliant station to communicate with remote, bridged stations as if they were local. Although the networks connected by a bridge remain physically separate, they appear as one network to the rest of the devices on the internetwork.
Figure 1-2 illustrates the frame formats found on Ethernets.
Transparent bridges forward frames between networks using the same medium (two IEEE 802.3 networks, for example). Source-route transparent (SRT) bridging extends this capability to allow the forwarding of frames between end hosts on Token Ring (802.5) and Ethernet/802.3 media. Cisco's SRT implementation is compatible with ISO standards 802.1d and the draft 802.5 SRT Annex. The Cisco FCIT implementation further extends this by adding FDDI as a medium that can be bridged with all of the others (Token Ring and Ethernet).
Because bridges examine each frame, and because each frame contains a source address, bridges can easily learn the locations of stations on the network. However, if an address is unknown, the bridges' flooding behavior could also result in endless loops on the network, as all bridges that do not know the address will flood the frame looking for the address. To circumvent this, a tree-type algorithm has been developed that prevents loops and forces the frames into logical routes. Called a spanning-tree algorithm, it allows only one route between any two physical cables or networks.
Spanning-tree bridges are based upon the concept of a root bridge that exchanges topology information with designated bridges to maintain the configuration. The root and designated bridges notify all other bridges in the network when topology changes are required, thereby preventing loops and providing a measure of defense against link failure.
Bridges may be further classified as local or remote. A local bridge typically connects two nearby LANs; for example, Ethernet-to-Ethernet or Token Ring-to-Ethernet. A remote bridge, on the other hand, links geographically distant LANs or LANs separated by some other media. Two Ethernets linked by a serial line, or two Token Rings linked by a frame-relay network are examples of remote bridging.
Cisco's transparent bridging software implementation provides these features:
Additionally, the Cisco router/bridge combines the advantages of a spanning-tree bridge and a full multiprotocol router. This combination provides the speed and protocol transparency of an adaptive spanning-tree bridge, along with the functionality, reliability, and security of routers.
Network interfaces on the Cisco interface cards (CSC-MCI and CSC-SCI), the 4/16 Mbit Token Ring card (CSC-R16 or CSC-R16M) and the Multiport Ethernet Controller card (CSC-MEC) on the cBus high-speed backplane may be configured to serve as both multiprotocol routers and MAC-level bridges, bridging any traffic that cannot otherwise be routed. For example, a router/bridge routing the Internet Protocol can also bridge DEC's Local Area Transport (LAT) protocol, or NetBIOS traffic.
Remote bridging over synchronous serial lines is also supported between Cisco servers. As with frames received on all other media types, the learning process and any filtering is applied to frames received on serial lines.
The transit bridging of Ethernet frames across both FDDI and UltraNet media is also supported. The term transit refers to the fact that the source or destination of the frame cannot be on the FDDI or UltraNet media itself. This allows both FDDI and UltraNet to act as a highly efficient backbone for the interconnection of many bridged networks. The configuration of FDDI and UltraNet transit bridging is identical to the configuration of transparent bridging on all other media types.
Cisco router/bridges also support transparent bridging on Token Ring interfaces that are capable of supporting source-route transparent bridging. SRT is supported on the IGS/TR router/bridge.
Source-route transparent (SRT) bridging is supported on Token Ring interfaces capable of supporting transparent bridging. Transparent bridging is supported only on the CSC-R16 or CSC-R16M Token Ring interface running at least Version 3.0 of the Token Ring monitor (SBEMON). As with all other media types, all bridge-group commands can be used on Token Ring interfaces.
As with other interface types, the bridge group may be configured either to run the IEEE or DEC spanning-tree protocols. When using the IEEE spanning-tree protocol, the bridge cooperates with other bridges complying to the draft SRT specification and it constructs a loop-free topology across the entire extended LAN.
The DEC spanning-tree protocol may be run over Token Ring as well. This is done when you have other non-IEEE bridges on other media, and do not have any SRT bridges on Token Ring. Note that in this configuration, all of your Token Ring transparent bridges must be Cisco routers. This is because the DEC spanning-tree protocol has not been standardized on Token Ring.
As specified by the SRT specification, only packets without a RIF field (RII = 0 in the SA field) will be transparently bridged. Packets with a RIF field (RII = 1) are passed to the source-route bridging module for handling. Note that an SRT-capable Token Ring interface can have both source-route bridging and transparent bridging enabled at the same time. However, when running SRT, frames that did not have a RIF when they were produced by their generating host will never gain a RIF, and frames that did have a RIF when they were produced will never lose that RIF.
When bridging between Token Ring and other media, certain packet transformations must occur. In all cases, the MAC addresses are bit-swapped, because the bit ordering on Token Ring is different from other media. In addition, Token Ring supports one higher-layer packet format, LLC, while Ethernet supports two (LLC and Ethernet). The transformation of LLC frames between media is quite simple; a length field is either created (when going to non-Token Ring) or removed (when going to Token Ring). When an Ethernet format frame must go to Token Ring, it is translated into a LLC-1 "SNAP" packet (DSAP = AA, SSAP = AA), with the OUI value 0000F8. Likewise, when such a packet in LLC-1 format is going to be bridged onto Ethernet media, it is translated back into Ethernet format. Graphic illustrations of frame formats is given in the appendix "Frame Conversions."
Note that the OUI used when transporting Ethernet Type II frames over other media is controlled by the source-bridge old-oui command as described in the chapter "Configuring Source-Route Bridging."
Follow these steps to configure transparent bridging on a Cisco router/bridge. Each task and command is described in greater detail in the following sections.
Step 1: Define the spanning-tree protocol and assign a bridge group number using the bridge group protocol command. The Cisco bridging software supports the IEEE 802.1 spanning-tree protocol and the earlier DEC protocol upon which the IEEE standard is based. Additionally, multiple domains are supported for the IEEE spanning tree.
Step 2: Enable each interface and configure any routed protocols. If you wish to bridge IP, you must disable IP routing.
Step 3: Assign the network interfaces to the spanning-tree group.
Step 4: Adjust the spanning-tree parameters, as necessary.
The bridging software also supports filtering of frames. Filtering can be done by MAC address, protocol type, vendor code, and LAT group codes. Additionally, EXEC-level commands for monitoring and debugging the bridge are available.
Cisco router/bridges support two spanning-tree protocols: the IEEE 802.1 standard, and the earlier DEC spanning-tree protocol upon which the IEEE standard is based.
To define a spanning-tree protocol, use the bridge group protocol global configuration command. The command has this syntax:
bridge group protocol {ieee|dec}The argument group is a number between one and nine that you choose to refer to a particular set of bridged interfaces. Frames are bridged only among interfaces in the same group. You will use the group number you assign in subsequent bridge configuration commands.
The keyword protocol is used to specify one of two spanning-tree protocol types: ieee for the Ethernet spanning-tree protocol, or dec for the DEC spanning-tree protocol.
The no bridge command with the appropriate keywords and arguments deletes the bridge group.
This command defines bridge 1 as using the DECnet spanning-tree protocol.
bridge 1 protocol dec
The Cisco IEEE 802 bridging software supports multiple domain spanning trees. You can place any number of router/bridges within the domain. The devices in the domain, and only those devices, will then share spanning-tree information.
Use this feature when multiple routers share the same cable, and you wish to use only certain discrete subsets of those routers to share spanning-tree information with each other. This function is most useful when running other router applications, such as IP UDP flooding, that use the IEEE spanning tree. It can also be used to reduce the number of global reconfigurations in large bridged networks.
Establish a domain by assigning it a value between one to ten, using this variation of the bridge global configuration command:
bridge group domain domain-numberThe argument group is the bridge group number, and must be the same as that specified by the protocol ieee keywords in the previously described bridge group command.
Use the domain keyword to specify a domain; the argument domain-number is a domain number you choose. The default domain number is zero, and this is the required domain number when communicating to IEEE bridges that do not support this domain extension. The no version of the command returns it to a single bridge domain by choosing domain zero (0).
This command places bridge group 1 in bridging domain 3. Only other Cisco routers that are in domain 3 will accept spanning-tree information from this router.
bridge 1 domain 3
All protocols except IP are bridged by a router/bridge unless their routing is explicitly enabled. Refer to the chapter "Routing IP" for the procedures to enable routing of individual protocols. IP is normally routed by the router/bridge.
Also note that bridging and routing are done on a per-system basis. If a protocol is being routed, it must be routed on all interfaces that are handling that protocol. This is similar for bridging. You cannot route IP on one interface and bridge it on another interface.
To bridge IP you must disable IP routing by giving the following global configuration command:
no ip routingAssign the same IP address to all network interfaces to manage the system with Telnet, TFTP, SNMP, ICMP (ping), and so forth. Once bridging is enabled, all IP and ARP frames not intended for the Cisco router/bridge are handled according to standard bridging and spanning-tree rules. IP routing processes such as IGRP or RIP must not be running.
Assign each network interface to a spanning-tree group using the bridge-group group interface subcommand, which has this syntax:
bridge-group groupThe simplest form of the bridge-group command takes just a spanning-tree group number as an argument. More complex forms of the bridge-group command are described later. The no version of the command removes the interface from the bridge group.
The following is an example of a basic bridging configuration. The system has two Ethernets, one Token Ring, one FDDI port, one UltraNet port, and one serial line. The Internet Protocol (IP) is being routed and everything else is being bridged. The DEC-compatible bridging algorithm with default parameters is being used. Figure 1-3 illustrates the configuration.
The configuration file for the router/bridge depicted in Figure 1-3 would be as follows:
interface tokenring 0
ip address 131.108.1.1 255.255.255.0
bridge-group 1
!
interface fddi 0
ip address 131.108.2.1 255.255.255.0
bridge-group 1
!
interface ultranet 0
ip address 131.108.3.1 255.255.255.0
bridge-group 1
!
interface ethernet 0
ip address 192.31.7.26 255.255.255.240
bridge-group 1
!
interface serial 0
ip address 192.31.7.34 255.255.255.240
bridge-group 1
!
interface ethernet 1
ip address 192.31.7.65 255.255.255.240
bridge-group 1
!
bridge 1 protocol dec
You may need to adjust certain spanning-tree parameters. Parameters affecting the entire spanning tree are configured with variations of the bridge group global configuration command. Interface-specific parameters are configured with variations of the bridge-group group interface subcommand.
Configure the priority of an individual bridge or the likelihood that it will be selected as the root bridge, with the bridge group priority global configuration command. The command has this syntax:
bridge group priority numberThe argument group is the bridge group number. The argument number can range from 1 to 65000. The lower the value of number, the more likely the bridge will be chosen as root. The default priority is 128.
When two bridges tie for position as the root bridge, an interface priority determines which bridge will serve as the root bridge. Use the bridge-group group priority number interface subcommand to control this.
This command establishes this bridge as a likely candidate to be the root bridge.
bridge 1 priority 100
The interval between Hello Bridge Protocol Data Units (BPDUs) is specified with the bridge group hello-time global configuration command. The command has this syntax:
bridge group hello-time secondsThe argument group is the bridge group number. The argument seconds can be any value between one and ten seconds. The default value is one second.
This command sets the interval to five seconds.
bridge 1 hello-time 5
The forward delay interval is the amount of time spent listening for topology change information after an interface has been activated for bridging and before forwarding actually begins. Use the bridge group forward-time global configuration command to specify this interval. The command has this syntax:
bridge group forward-time secondsThe argument group is the bridge group number. The argument seconds can be any value between 10 and 200 seconds. The default value is 30 seconds.
This command sets the forward delay interval to 60 seconds.
bridge 1 forward-time 60
If a bridge does not hear BPDUs from the root bridge within a specified interval, it assumes that the network has changed and recomputes the spanning-tree topology. This interval is 15 seconds by default. It can be changed with the bridge group max-age global configuration command. The command has this syntax:
bridge group max-age secondsThe argument group is the bridge group number. The argument seconds is the interval the bridge will wait to hear BPDUs from the root bridge.
This command increases the maximum idle interval to 20 seconds.
bridge 1 max-age 20
Each interface has a path cost associated with it. By convention, the path cost is 1000/data rate of the attached LAN, in Mbps. Table 1-1 lists some common path cost values.
| Media | Path Cost in Mbps |
|---|---|
| Ethernet | 100 |
| 16 Mb Token Ring | 62 |
| FDDI | 10 |
| UltraNet | 8 |
Use the interface subcommand bridge-group group path-cost to set a different path cost. The command syntax is as follows:
bridge-group group path-cost costThe argument group is the bridge group number. The path cost can range from 0 to 65535, with higher values indicating higher costs. The default path cost is computed from the interface's bandwidth setting. The no version of the command chooses the default path cost for the interface, as shown in Table 1-1.
This command changes the default path cost for interface Ethernet 0.
interface ethernet 0
bridge-group 1 path-cost 250
A priority can also be set for an interface. When two bridges tie for position as the root bridge, an interface priority is used to break the tie. Use the bridge-group group priority interface subcommand for this. The command has this syntax:
bridge-group group priority numberThe argument group is the bridge group number. The argument number can range from 0 to 255. The default value is zero, and the lower the number, the more likely it is that the bridge on this interface will be chosen as the root.
This command increases the likelihood that the root bridge will be the one on Ethernet 0, in spanning-tree group 1.
interface ethernet 0
bridge-group 1 priority 0
A bridge examines frames and transmits them through the internetwork according to the destination address; a bridge will not forward a frame back to its originating network segment. The Cisco bridge software allows specific administrative filters to be configured that block frames based upon information other than paths to their destinations. This administrative filtering can be done by:
When setting up administrative filtering, remember that there is virtually no performance penalty in filtering by MAC address or vendor code, but there can be a significant performance penalty when filtering by protocol type.
Blocking transmission of frames based on MAC-layer address is configured by variations of the bridge group global configuration command, as described in the following sections.
To filter frames with a particular MAC-layer station source or destination address, use the global configuration command bridge group address. The full syntax of this command follows:
bridge group address MAC-address {forward|discard} [interface]The argument group is the group number you assigned to the spanning tree.
The argument MAC-address is a 48-bit dotted-triple hardware address such as that displayed by the EXEC show arp command. It is either a station address, the broadcast address, or a multicast destination address.
An example is:
0800.cb00.45e9
The optional keywords forward and discard are described in Table 1-2.
| Keyword | Function |
|---|---|
| forward | A frame sent from or destined to the specified address is forwarded as appropriate. |
| discard | A frame sent from or destined to the specified address is discarded without further processing. |
The argument interface is an optional interface specification, such as Ethernet 0, and is added after the discard or forward keyword to indicate the interface on which that address can be reached.
Any number of addresses can be configured into the system without a performance penalty.
Use the no bridge group address command followed by the MAC address to disable the forwarding ability.
This command enables filtering of frames with MAC address 0800.cb00.45e9.
bridge 1 address 0800.cb00.45e9 forward ethernet 1
The frame is forwarded through interface Ethernet 1.
This command disables the ability to forward frames with MAC address 0800.cb00.45e9.
no bridge 1 address 0800.cb00.45e9
Normally, the system forwards any frames for stations that it has learned about dynamically. This behavior can be changed with the no bridge group acquire global configuration command. The full syntax of this command follows:
no bridge group acquireThe argument group is the bridge group number. The bridge filters out all frames except those whose sourced-by or destined-to addresses have been statically configured into the forwarding cache.
The bridge group acquire global configuration command restores the default behavior.
This command prevents the forwarding of dynamically determined source and destination addresses.
no bridge 1 acquire
The bridging support may be configured to allow the forwarding, but not the learning, of frames received with multicast source addresses. Use this variation of the bridge group global configuration command to configure this function:
bridge group multicast-sourceList the bridge group using the group argument.The no version of the command disables this function on the bridge.
Filtering by protocol type is done using the access list mechanism and by specifying a protocol type code. The bridge access-list command specifies an element in an access list. The order in which access-list commands are entered 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.
Type-code access lists are built with this bridge access-list global configuration command:
access-list list {permit|deny} type-code wild-maskThe argument list is a user-selectable number between 200 and 299 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. You may specify either an Ethernet type code for Ethernet-encapsulated packets, or a DSAP/SSAP pair for 802.3 or 802.5-encapsulated packets. Ethernet type codes are listed in the appendix "Ethernet Type Codes."
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 at least 0x0101. This is because these two bits are used for purposes other than identifying the SAP codes.)
The no version of the command removes a single access list entry.
The following access list permits only LAT frames (type 0x6004) and filters out all other frame types.
access-list 201 permit 0x6004 0x0000
access-list 201 deny 0x0000 0xFFFF
The following access list filters out only type codes assigned to DEC (0x6000 through 0x600F) and lets all other types pass.
access-list 202 deny 0x6000 0x000F
access-list 202 permit 0x0000 0xFFFF
Use the last item of an access list to specify a default action; for example, permit everything else or deny everything else. If nothing else in the access matches, the default action is normally to deny access; that is, filter out all other type codes.
You may filter Ethernet- and SNAP-encapsulated packets on input. For SNAP-encapsulated frames, the list is applied against the two-byte TYPE field, given after the DSAP/SSAP/OUI fields in the frame.
The access list specifying the type codes to be filtered is given in this variation of the bridge-group interface subcommand:
bridge-group group input-type-list listThe argument group is the spanning-tree group number.
The argument list is the access list number you assigned with the bridge access-list command. Specify a 0 for list to disable the application of the access list on the bridge group.
This access list is then applied to all Ethernet and SNAP frames received on that interface prior to the bridge learning process. SNAP frames must also pass any applicable IEEE 802 DSAP/SSAP access lists.
The following example illustrates how to configure a system with two Ethernet interfaces, one Token Ring interface, and one serial interface. The system is routing both IP and DECnet. Each interface has an access list that allows only the LAT protocol to be bridged. The bridging software has also been instructed to discard frames sent to or from the address AB00.0C00.AE35.
decnet address 34.88
!
interface tokenring 0
ip address 131.108.1.1 255.255.255.0
bridge-group 1
bridge-group 1 input-type-list 201
!
interface ethernet 0
ip address 192.31.7.26 255.255.255.240
decnet cost 10
bridge-group 1
bridge-group 1 input-type-list 201
!
interface serial 0
ip address 192.31.7.34 255.255.255.240
decnet cost 10
bridge-group 1
bridge-group 1 input-type-list 201
!
interface ethernet 1
ip address 192.31.7.65 255.255.255.240
decnet cost 10
bridge-group 1
bridge-group 1 input-type-list 201
!
bridge 1 protocol dec
bridge 1 address AB00.0C00.AE35 discard
!
access-list 201 permit 0x6004 0x0000
access-list 201 deny 0x0000 0xFFFF
You may filter Ethernet- and SNAP-encapsulated packets on output. The access specifying the type codes to be filtered is given by this variation of the bridge-group interface subcommand:
bridge-group group output-type-list listThe argument group is the spanning-tree group number.
The argument list is the access list number you assigned with the bridge access-list command. Specify a zero (0) for list to disable the application of the access list on the bridge group.
This access list is then applied just before sending out a frame to an interface.
This command specifies access list 202 on interface Ethernet 0.
interface ethernet 0
bridge-group 2 output-type-list 202
You may filter IEEE 802-encapsulated packets on input. The access list specifying the type codes to be filtered is given by this variation of the bridge-group interface subcommand:
bridge-group group input-lsap-list listThe argument group is the spanning-tree group number.
The argument list is the access list number you assigned with the bridge access-list command. Specify a zero (0) for list to disable the application of the access list on the bridge group.
This access list is applied to all IEEE 802 frames received on that interface prior to the bridge-learning process. SNAP frames must also pass any applicable Ethernet type-code access list.
This command specifies access list 203 on interface Ethernet 1:
interface ethernet 1
bridge-group 3 input-lsap-list 203
You may filter IEEE 802-encapsulated packets on output. The access list specifying the type codes to be filtered is given by this variation of the bridge-group interface subcommand:
bridge-group group output-lsap-list listThe argument group is the spanning-tree group number.
The argument list is the access list number you assigned with the bridge access-list command. Specify a zero (0) for list to disable the application of the access list on the bridge group.
SNAP frames must also pass any applicable Ethernet type-code access list. This access list is applied just before sending out a frame to an interface.
This command specifies access list 204 on interface Ethernet 0.
interface ethernet 0
bridge-group 4 output-lsap-list 204
The bridging software supports administrative filtering of MAC addresses. These lists support filtering groups of MAC addresses, including those with particular vendor codes. The lists are defined with the bridge access-list global configuration command and the bridge-group interface subcommand. There is no noticeable performance loss in using these access lists. The lists can be of indefinite length. The following sections describe how to set these lists up.
Use the bridge access-list global configuration command to establish MAC 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 that you select for the list.
The argument address and mask are 48-bit MAC addresses written in dotted triplet form. The ones bits in the mask argument are the bits to be ignored in address.
See the section "Filtering Source Addresses" for an example of use of this command.The no version of the command removes a single access list entry.
Use the bridge-group group input-address-list interface subcommand to assign an access list to a particular interface for filtering on the MAC source addresses of packets received on that interface. The command has this syntax:
bridge-group group input-address-list listThe argument group is the spanning-tree group number.
The argument list is the access list number you assigned with the bridge access-list command.
This configuration example assumes you want to disallow the bridging of Ethernet packets of all Sun workstations on Ethernet 1. Software assumes that all such hosts have Ethernet addresses with the vendor code 0800.2000.0000. The first line of the access list denies access to all Sun workstations while the second line permits everything else. You then assign the access list to the input side of Ethernet 1.
access-list 700 deny 0800.2000.0000 0000.00FF.FFFF
access-list 700 permit 0000.0000.0000 FFFF.FFFF.FFFF
interface ethernet 1
bridge-group 1 input-address-list 700
Use the bridge-group group output-address-list interface subcommand to assign an access list to a particular interface for filtering the MAC destination addresses of packets that would ordinarily be forwarded out that interface. The command has this syntax:
bridge-group group output-address-list listThe argument group is the spanning-tree group number.
The argument list is the access list number you assigned with the bridge access-list command.
This command assigns access list 703 to interface Ethernet 3.
interface ethernet 3
bridge-group 5 output-address-list 703
When filtering specific MAC destination addresses, allow for multicast or broadcast packets that are required by the bridged network protocols.
Assume you are bridging IP in the network illustrated in Figure 1-4.
The MAC address of HostA is 0800.0907.0207, and the MAC address of HostB is 0260.8c34.0864. The following configuration would work as expected, as input addresses work on source address on the incoming interface:
access-list 700 permit 0260.8c34.0864 0000.0000.0000
access-list 700 deny 0000.0000.0000 FFFF.FFFF.FFFF
interface ethernet 0
bridge-group 1 input-address-list 700
However, the following configuration, may work initially, but will eventually fail, even though the destination address on the output interface is correct:
access-list 700 permit 0260.8c34.0864 0000.0000.0000
access-list 700 deny 0000.0000.0000 FFFF.FFFF.FFFF
interface ethernet 0
bridge-group 1 output-address-list 700
The above configuration does not allow for an ARP broadcast with a destination address of FFFF.FFFF.FFFF so the access list fails. The correct access list would be:
access-list 700 permit 0260.8c34.0864 0000.0000.0000
access-list 700 permit FFFF.FFFF.FFFF 0000.0000.0000
access-list 700 deny 0000.0000.0000 FFFF.FFFF.FFFF
interface ethernet 0
bridge-group 1 output-address-list 700
The Cisco bridging software provides filtering of LAT frames. LAT bridge filtering allows the selective inclusion or exclusion of LAT multicast service announcements, on a per-interface basis.
In the DEC LAT protocol, a group code is defined as a decimal number in the range 0 to 255. Some of the Cisco LAT configuration commands take a list of group codes; this is referred to as a group code list. The rules for entering numbers in a group code list follow:
In LAT, each node transmits a periodic service advertisement message, which announces its existence and availability for connections. Within the message is a group code list; this is a mask of up to 256 bits. Each bit represents a group number.
In the traditional use of LAT group codes, a terminal server will only connect to a host system when there is an overlap between the group code list of the user on the terminal server, and the group code list in the service advertisement message.
While some believe this to be a security feature, it is in fact present to allow you to partition your physical network. This is because most DEC terminal servers do not have enough memory to cope with a large number of services. Group codes do not actually provide any real security; they are trivial to defeat.
In an environment with many bridges and many LAT hosts, the number of multicast messages with which each system has to deal becomes unreasonable. The 256 group codes may not be enough to allocate local assignment policies, such as giving each DECserver 200 device its own group code, in large bridged networks.
LAT group code filtering allows you to have very fine control over what multicast messages actually get bridged. Through a combination of input and output permit and deny lists, many different LAT control policies can be implemented. Use the EXEC command show span to report the group-code filtering in effect.
Use the bridge group lat-service-filtering global configuration command to specify LAT group-code filtering. The command has this syntax:
bridge group lat-service-filteringThe command informs the system that LAT service advertisements require special processing. Use the group argument to specify the bridge group in which this special processing is to take place.
The no version of this command disables the use of LAT service filtering on the bridge group.
This command specifies that LAT service announcements travelling across bridge group 1 require some special processing.
bridge 1 lat-service-filtering
Use the bridge-group group input-lat-service-deny interface subcommand to specify the group codes by which to deny access upon input. The command has this syntax:
bridge-group group input-lat-service-deny grouplistThis command causes the system to not bridge any LAT service advertisement that has any of the specified groups set. The argument group is the previously chosen spanning-tree group number. Enter the list of LAT service groups with the grouplist argument. Specify a zero (0) to disable the LAT group code for the bridge group.
This command causes any advertisements with groups 6, 8, and 14 through 20 to be dropped.
interface ethernet 0
bridge-group 1 input-lat-service-deny 6 8 14-20
Use the bridge-group group input-lat-service-permit interface subcommand to specify the group codes by which to permit access upon input. The command has this syntax:
bridge-group group input-lat-service-permit grouplistThis command causes the system to bridge only those service advertisements that match at least one group in the group list specified by the grouplist argument. Specify a zero (0) to disable the LAT group code for the bridge group.
This command bridges any advertisements from groups 1, 5, and 12 through 14.
interface ethernet 1
bridge-group 1 input-lat-service-permit 1 5 12-14
Use the bridge-group group output-lat-service-deny interface subcommand to specify the group codes by which to deny access upon output. The command has this syntax:
bridge-group group output-lat-service-deny grouplistThis command causes the system to not bridge onto this output interface any service advertisements that contain groups matching any of these in the group list. The LAT service advertisements are specified with the argument grouplist.
The argument group is the previously chosen spanning-tree group number. The no version of the command disables this application on the bridge group.
This command prevents bridging of LAT service announcements from groups 12 through 20.
interface ethernet 0
bridge-group 1
bridge-group 1 output-lat-service-deny 12-20
Use the bridge-group group output-lat-service-permit interface subcommand to specify the group codes by which to permit access upon output. The command has this syntax:
bridge-group group output-lat-service-permit grouplistThis command causes the system to bridge onto this output interface only those service advertisements that match at least one group in the specified group code list. The service advertisements are specified with the argument grouplist.
The argument group is the previously chosen spanning-tree group number. The no version of the command disables this application on the bridge group.
This command allows only LAT service announcements from groups 5, 12, and 20 on this bridge.
interface ethernet 0
bridge-group 1 output-lat-service-permit 5 12 20
This section describes some special bridging configurations, including how to configure load balancing over serial lines, how to configure X.25 and frame-relay bridging, and how to compress LAT traffic.
In the normal operation of the spanning-tree algorithm, parallel network segments cannot all be carrying traffic at the same time. This is necessary to prevent the looping of frames. In the case of serial lines, however, there is often a desire to increase the available bandwidth by using multiple, parallel serial lines.
To modify the spanning-tree algorithm's handling of serial lines, a set of serial lines between two bridges may be grouped in an association called a circuit group. If the spanning-tree algorithm allows any serial interface in the circuit group to forward packets, then all interfaces can be used for forwarding traffic. Ordering problems are avoided by assigning each destination address to a particular serial interface. Reassignment is done dynamically if interfaces go down or come back up.
To establish load balancing, use the bridge-group group circuit interface subcommand. The command has this syntax:
bridge-group group circuit numberThe command marks a serial interface as belonging to circuit group. The argument group is the spanning-tree group number. The argument number defines the circuit group number and is a small integer less than ten. Specify a zero (0) for number to disable the circuit group number.
The parallel serial interfaces on both bridges must all be marked as being members of the same circuit group.
To load share over the two parallel serial links in this example, each router would have the configuration shown.
interface ethernet 0
bridge-group 1
!
interface serial 0
bridge-group 1
bridge-group 1 circuit 1
!
interface serial 1
bridge-group 1
bridge-group 1 circuit 1
!
bridge 1 protocol dec
Cisco's transparent bridging software supports bridging of packets in X.25 frames. This ability is useful, as an example, for transmitting packets from proprietary protocols across an X.25 network.
To configure this capability, use this variation of the x25 map interface subcommand in the bridging configuration file:
x25 map bridge X.121-address broadcast [options-keywords]The keyword bridge specifies bridging over X.25. The argument X.121-address is the X.121 address. The keyword broadcast is required for bridging over X.25. The optional argument options-keywords is the services that may be added to this map; these services are listed in the section "Setting Address Mappings" in the chapter "Configuring Packet-Switched Software."
The X.25 bridging software uses the same spanning-tree algorithm as the other bridging functions, but allows packets to be encapsulated in X.25 frames and transmitted across X.25 media. The command specifies Internet-to-X.121 address mapping and maintains a table of both the Ethernet and X.121 addresses.
The following is an example configuration illustrating three Cisco bridges connected to each other through an X.25 network.
Following are the configuration commands for each of the bridges depicted in Figure 1-5.
interface ethernet 2
bridge-group 5
ip address 128.88.11.9 255.255.255.0
!
interface serial 0
encapsulation x25
x25 address 31370019027
bridge-group 5
x25 map bridge 31370019134 broadcast
x25 map bridge 31370019565 broadcast
!
bridge 5 protocol ieee
interface serial 1
encapsulation x25
x25 address 31370019134
bridge-group 5
x25 map bridge 31370019027 broadcast
x25 map bridge 31370019565 broadcast
!
bridge 4 protocol ieee
interface serial 0
encapsulation x25
x25 address 31370019565
bridge-group 5
x25 map bridge 31370019027 broadcast
x25 map bridge 31370019134 broadcast
!
bridge 5 protocol ieee
Cisco's transparent bridging software supports bridging of packets over frame-relay networks. This ability is useful, as an example, for transmitting packets from proprietary protocols across a frame-relay network.
Bridging over a frame-relay network is supported on networks that support a multicast facility and those that do not support such a facility. Both cases are described below.
Figure 1-6 illustrates three Cisco bridges connected to each other through a frame-relay network.
To configure bridging in a network not supporting a multicast facility, use this variation of the frame-relay map interface subcommand, which is described in more detail in the chapter "Configuring Packet-Switched Software."
frame-relay map bridge DLCI broadcastThe keyword bridge specifies bridging over frame-relay. The argument DLCI is the Data Link Connection Identifier (DLCI) of the destination bridge. The keyword broadcast is required for bridging.
The frame-relay bridging software uses the same spanning-tree algorithm as the other bridging functions, but allows packets to be encapsulated for transmission across a frame-relay network. The command specifies Internet-to-DLCI address mapping and maintains a table of both the Ethernet and DLCIs.
Following are the configuration commands for each of the bridges in a network that does not support a multicast facility.
interface ethernet 2
bridge-group 5
ip address 128.88.11.9 255.255.255.0
!
interface serial 0
encapsulation frame-relay
bridge-group 5
frame-relay map bridge 134 broadcast
frame-relay map bridge 565 broadcast
!
bridge 5 protocol ieee
interface serial 1
encapsulation frame-relay
bridge-group 5
frame-relay map bridge 27 broadcast
frame-relay map bridge 565 broadcast
!
bridge 5 protocol ieee
interface serial 0
encapsulation frame-relay
bridge-group 5
frame-relay map bridge 27 broadcast
frame-relay map bridge 134 broadcast
!
bridge 5 protocol ieee
The multicast facility is used to learn about the other bridges on the network, eliminating the need for the frame-relay map commands.
Following are the configuration commands for each of the bridges in a network that supports a multicast facility.
interface ethernet 2
bridge-group 5
ip address 128.88.11.9 255.255.255.0
!
interface serial 0
encapsulation frame-relay
bridge-group 5
!
bridge 5 protocol ieee
interface serial 1
encapsulation frame-relay
bridge-group 5
!
bridge 5 protocol ieee
interface serial 0
encapsulation frame-relay
bridge-group 5
!
bridge 5 protocol ieee
!
The Local Area Transport (LAT) protocol used by DEC and DEC-compatible terminal servers is one of the common protocols that lacks a well-defined network layer (Level 3), and so must always be bridged.
To reduce the amount of bandwidth LAT traffic consumes on serial interfaces, a LAT-specific form of compression may be specified. This is done with the bridge-group group lat-compression interface subcommand. The command has this syntax:
bridge-group group lat-compressionThe argument group is the spanning-tree group number.
Compression is applied to LAT frames being sent out the router/bridge through the interface in question.
LAT compression may be specified only for serial interfaces. For the most common LAT operations (user keystrokes and acknowledgment packets), LAT compression reduces LAT's bandwidth requirements by nearly a factor of two. The no version of this command disables LAT compression on the bridge group.
This command compresses LAT frames on the bridge assigned to group 1.
bridge-group 1 lat-compression
This section provides example configurations that you may use to configure your bridging environment.
In this example, two buildings have networks that must be connected via a T1 link. For the most part, the systems in each building use either IP or DECnet and, therefore, should be routed. There are some systems in each building that must communicate, but they can use only a proprietary protocol.
The example places two Ethernets in each building. One of the Ethernets is attached to the hosts that use a proprietary protocol, and the other is used to attach to the rest of the building network running IP and DECnet. The Ethernet attached to the hosts using a proprietary protocol is enabled for bridging to the serial line and to the other building.
Figure 1-7 shows an example configuration. The interfaces marked with an asterisk (*) are configured as part of spanning tree 1. The routers are configured to route IP and DECnet. This configuration permits hosts on any Ethernet to communicate with hosts on any other Ethernet using IP or DECnet. In addition, hosts on Ethernet 1 in either building can communicate using protocols not supported for routing.
The configuration file for the router/bridge in Building 1 would be as follows. Note that no bridging takes place over Ethernet 0. Both IP and DECnet routing are enabled on all interfaces.
decnet address 3.34
interface ethernet 0
ip address 128.88.1.6 255.255.255.0
decnet cost 10
!
interface serial 0
ip address 128.88.2.1 255.255.255.0
bridge-group 1
decnet cost 10
!
interface ethernet 1
ip address 128.88.3.1 255.255.255.0
bridge-group 1
decnet cost 10
!
bridge 1 protocol dec
The configuration file for the router/bridge in Building 2 is similar.
decnet address 3.56
!
interface ethernet 0
ip address 128.88.11.9 255.255.255.0
decnet cost 10
!
interface serial 0
ip address 128.88.2.2 255.255.255.0
bridge-group 1
decnet cost 10
!
interface ethernet 1
ip address 128.88.16.8 255.255.255.0
bridge-group 1
decnet cost 10
!
bridge 1 protocol dec
In Figure 1-8, a Token Ring and an Ethernet at a remote sales site in New York City and must be configured to pass unroutable bridged traffic across a satellite link to the backbone Token Ring at the corporate headquarters in Thule, Greenland. IP is the only routed protocol. They are running the IEEE spanning-tree protocol to comply with the SRT standard.
If there were source-routed traffic to bridge, the source-bridge command would also be used to configure source routing.
The following is the configuration for the New York City router:
interface tokenring 0
ip address 150.136.1.1 255.255.255.128
bridge-group 1
!
interface ethernet 0
ip address 150.136.2.1 255.255.255.128
bridge-group 1
!
interface serial 0
ip address 150.136.3.1 255.255.255.128
bridge-group 1
!
bridge 1 protocol ieee
The following is the configuration for the Thule, Greenland router:
interface tokenring 0
ip address 150.136.10.1 255.255.255.128
bridge-group 1
!
interface serial 0
ip address 150.136.11.1 255.255.255.128
bridge-group 1
!
bridge 1 protocol ieee
Use the clear bridge command to remove any learned entries from the forwarding database and to clear the transmit and receive counts for any statically configured or system-configured entries. The command has this syntax:
clear bridge groupThe argument group is the number you chose to specify a particular spanning tree.
This section describes the EXEC commands you use to obtain displays of activity on the bridged network.
Use the show bridge command to view classes of entries in the bridge forwarding database. The command has this syntax:
show bridge [group] [interface]The optional argument group is the number you chose that specifies a particular spanning tree.
The optional argument interface is a specific interface, such as Ethernet 0.
The optional argument address is a 48-bit canonical (Ethernet ordered) MAC address. This may be entered with an optional mask of bits to be ignored in the address, which is specified with the mask argument.
In the sample display below, the first command would display all entries for hosts reachable via interface Ethernet 0, the second command would display all entries with the vendor code of 0000.0c00.0000, and the third command displays the entry for address 0000.0c00.0e1a. In the fourth command, all entries in the forwarding database would be displayed. In all four examples, the bridge group number has been omitted.
show bridge ethernet 0
show bridge 0000.0c00.0000 0000.00FF.FFFF
show bridge 0000.0c00.0e1a
show bridge
The following is sample output of the show bridge command:
Total of 300 station blocks, 295 free
BG Hash Address Action Interface Age RX count TX count
1 00/0 FFFF.FFFF.FFFF discard - P 0 0
1 09/0 0000.0C00.0009 forward Ethernet0 0 2 0
1 49/0 0000.0C00.4009 forward Ethernet0 0 1 0
1 CA/0 AA00.0400.06CC forward Ethernet0 0 25 0
The first line of the show bridge output lists the total number of forwarding database elements in the system and the number in the free list. The total number of forwarding elements is expanded dynamically, as needed. The memory to hold bridge entries is allocated in blocks of memory sufficient to hold 300 individual entries. When the number of free entries falls below 25, another block of memory sufficient to hold another 300 entries is allocated. Therefore, the size of the bridge forwarding database is limited to the amount of free memory in the router. Other field descriptions follow in Table 1-3.
| Field | Description |
|---|---|
| BG | Indicates the bridging group to which the address belongs. |
| Address | Is the canonical (Ethernet ordered) MAC address. |
| Action | Is the action to be taken when that address is looked up; choices are to discard or forward the datagram. |
| Interface | Indicates the interface, if any, on which that address was seen. |
| Age | Indicates the number of minutes since a frame was received from or sent to that address. The letter "P" indicates a permanent entry. The letter "S" indicates the system as recorded by the router. On the modular systems, this is typically the broadcast address and the router's own hardware address; on the IGS, this field will also include certain multicast addresses. |
| RX count | Displays the number of frames received from that address. |
| TX count | Displays the number of frames sent to that address. |
Use the show span command to display the spanning-tree topology known to the router/bridge. The display includes whether or not LAT group code filtering is in effect. The command has this syntax:
show spanThe following is a sample output of the show span command. The first part of the display lists global spanning-tree parameters, followed by port-specific parameters.
Bridge Group 1 is executing the DEC compatible spanning tree protocol
Bridge Identifier has priority 127, address 0000.0c00.4369
Configured hello time 1, max age 15, forward delay 30
We are the root of the spanning tree
Acquisition of new addresses is enabled
Forwarding of multicast source addresses is disabled
LAT service filtering is disabled
Topology change flag not set, detected flag not set
Times: hold 1, topology change 30, notification 30
hello 1, max age 15, forward delay 30
Timers: hello 1, topology change 0, notification 0
--More--
Port 5 (Ethernet0) of bridge group 1 is forwarding. Path cost 10, priority 0
Designated root has priority 127, address 0000.0c00.4369
Designated bridge has priority 127, address 0000.0c00.4369
Designated port is 5, path cost 0
Timers: message age 0, forward delay 0, hold 1
LAT compression is not set
Input LAT service deny group code list is not set
Input LAT service permit group code list is not set
Output LAT service deny group code list is not set
Output LAT service permit group code list is not set
Access list for input filtering on type is 201; for LSAP is not set
Access list for input address filter is not set
Access list for output filtering on type is not set; for LSAP is not set
Access list for output address filter is not set
--More--
Port 6 (Serial4) of bridge group 1 is forwarding. Path cost 64, priority 0
Designated root has priority 127, address 0000.0c00.4369
Designated bridge has priority 127, address 0000.0c00.4369
Designated port is 6, path cost 0
Timers: message age 0, forward delay 0, hold 1
LAT compression is set
Input LAT service deny group code list is not set
Input LAT service permit group code list is not set
Output LAT service deny group code list is not set
Output LAT service permit group code list is not set
Access list for input filtering on type is 202; for LSAP is not set
Access list for input address filter is not set
Access list for output filtering on type is 202; for LSAP is not set
Access list for output address filter is not set
--More--
Port 7 (Ethernet1) of bridge group 1 is down. Path cost 10, priority 0
Designated root has priority 127, address 0000.0c00.4369
Designated bridge has priority 127, address 0000.0c00.4369
Designated port is 7, path cost 0
Timers: message age 0, forward delay 0, hold 1
LAT compression is not set
Input LAT service deny group code list is not set
Input LAT service permit group code list is not set
Output LAT service deny group code list is not set
Output LAT service permit group code list is not set
Access list for input filtering on type is 201; for LSAP is not set
Access list for input address filter is not set
Access list for output filtering on type is not set; for LSAP is not set
Access list for output address filter is not set
This section describes the EXEC debugging commands you use to debug the transparent bridge. For each debug command, there is a corresponding undebug command to disable the reports.
Use the debug span command to track changes in the spanning-tree topology. This command is useful for verifying correct operation of the spanning-tree protocol.
Use the debug lat command on a bridge to show group-code filtering actions.
debug lat-packet
Use the debug lat-packet command to list all LAT service advertisements that were forwarded.
This section provides a summary of the transparent bridging-specific global configuration commands.
[no] access-list list {permit|deny} address-mask
Prepares access control information for filtering of frames by canonical (Ethernet ordered) MAC address. The argument list is an integer from 700 to 799 selected for the list. The argument address and mask are 48-bit canonical MAC addresses written in dotted triplet form. The ones bits in the mask argument are the bits to be ignored in address. The no version of the command removes a single access list entry.
[no] access-list list {permit|deny} type-code wild-mask
Prepares access control information for filtering of frames by protocol type. The argument list is a user-selectable number between 200 and 299 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." 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. The no version of the command removes a single access list entry.
[no] bridge group acquire
The positive form of this command enables the dynamic learning process and is the default. The argument group is the spanning-tree group number.
[no] bridge group address MAC-address [forward|discard] [interface]
Adds or removes an address from the forwarding database. The argument group is the spanning-tree group number. The argument MAC-address is a 48-bit dotted triplet canonical (Ethernet ordered) hardware address such as those displayed by the EXEC show arp command. The argument MAC-address is either a station address, the broadcast address, or a multicast destination address. The optional forward keyword enables forwarding of a frame sent from or destined to the specified address. The optional discard keyword causes frames sent from or destined to the specified address to be discarded without further processing. The optional argument interface specifies an interface after the discard or forward keyword to indicate the interface on which that address can be reached. Use the no version of the command followed by the MAC address to remove an address from the forwarding database.
[no] bridge group domain domain-number
Enables/disables multiple domain spanning trees. Any number of router/bridges can be placed within the domain. The devices in the domain, and only those devices, will then share spanning-tree information. The argument group is the bridge group number, and must be a number between one and ten, as specified in the bridge group protocol ieee command. The keyword domain is required; the argument domain-number is a domain number you choose. The default domain number is zero, and this is the required domain number when communicating to IEEE bridges that do not support this domain extension. The no version of this command chooses the default domain of zero.
bridge group forward-time seconds
Sets or returns to the default the forward delay interval, or the amount of time spent listening for topology change information after an interface has been activated for bridging and before forwarding actually begins. The argument group is the group number assigned to the spanning tree. The argument seconds is any value between 10 and 200 seconds. The default value is 30 seconds.
bridge group hello-time seconds
Specifies or returns to the default the interval between Hello Bridge Protocol Data Units (BPDUs). The argument group is the group number assigned to the spanning tree. The argument seconds is any value between one and ten seconds. The default value is one second.
[no] bridge group lat-service-filtering
Enables or disables LAT service filtering. The argument group specifies the bridge group. The no version of the command disables the use of LAT service filtering on the bridge group.
bridge group max-age seconds
Specifies or removes the interval in which the spanning-tree topology is recomputed when a bridge does not hear BPDUs from the root bridge. The argument group is the group number assigned to the spanning tree. The argument seconds is the interval the bridge will wait to hear BPDUs from the root bridge. The default interval is 15 seconds.
[no] bridge group multicast-source
Allows or disallows the forwarding, but not the learning, of frames with multicast source addresses. The argument group is the group number assigned to the spanning tree.
bridge group priority number
Sets the priority of an individual bridge for selection as the root bridge. The argument group is the group number assigned to the spanning tree. The argument number can range from 1 to 65000. The default priority value is 128. A lower number increases the likelihood for selection as the root bridge.
[no] bridge group protocol {ieee|dec}
Defines or removes a spanning-tree protocol and spanning-tree group. The argument group is a number between one and nine that refers to a particular spanning tree. The keyword protocol specifies the protocol to use, either ieee or dec.
This section provides an alphabetical summary of the bridging-specific interface subcommands.
[no] bridge-group group
Assigns or removes the network interface to or from the spanning-tree group. The argument group is the group number assigned to the spanning tree.
bridge-group group circuit number
Establishes or removes load balancing. The command marks a serial interface as belonging to circuit group number. The argument group is the spanning-tree group number.
The argument number defines the circuit group number and is a small integer less than ten. Parallel serial interfaces on both bridges must all be flagged as being members of the same circuit group.
[no] bridge-group group input-address-list list
Assigns or removes an access list to a particular interface for filtering by the MAC source addresses. The argument group is the spanning-tree group number. The argument list is an access list number between 200 and 299, which you assigned with the bridge access-list command.
bridge-group group input-lat-service-deny grouplist
When enabled, causes the system to not bridge any LAT service advertisement which match the group list specified on input. The argument grouplist lists the LAT groups. The argument group is the spanning-tree group number. Default is no filtering.
bridge-group group input-lat-service-permit grouplist
When enabled, causes the system to bridge only those LAT service advertisements which match the group list specified on input. The argument grouplist lists the LAT group codes. The argument group is the spanning-tree group number. Default is no filtering.
bridge-group group input-lsap-list list
Adds or removes a filter for IEEE 802-encapsulated packets on input. This access list is applied to all IEEE 802 frames received on that interface prior to the bridge-learning process. The argument group is the spanning-tree group number. The argument list is the access list number between 200 and 299, which you assigned with the bridge access-list command.
bridge-group group input-type-list list
Adds or removes a filter for Ethernet- and SNAP-encapsulated packets on input. The access list is then applied to all Ethernet frames received on that interface prior to the bridge learning process. The argument group is the spanning-tree group number. The argument list is the access list number between 200 and 299, which you assigned with the bridge access-list command.
[no] bridge-group group lat-compression
Reduces the amount of bandwidth LAT traffic consumes on serial interfaces. The argument group is the spanning-tree group number. Compression is applied to LAT frames being sent out the router/bridge through the interface in question. LAT compression may be specified only for serial interfaces. For the most common LAT operations (user keystrokes and acknowledgment packets), LAT compression reduces LAT's bandwidth requirements by nearly a factor of two.
[no] bridge-group group output-address-list list
Assigns or removes an access list to a particular interface for filtering by the MAC destination addresses. The argument group is the spanning-tree group number. The argument list is an access list number between 200 and 299, which you assigned with the bridge access-list command.
[no] bridge-group group output-lat-service-deny grouplist
When enabled, causes the system to not bridge onto this output interface any LAT service advertisements that match any group in the argument grouplist. The argument group is the spanning-tree group number. Default is no filtering.
[no] bridge-group group output-lat-service-permit grouplist
When enabled, causes the system to bridge onto this output interface only those service advertisements that match any group in the argument grouplist. The argument group is the spanning-tree group number. If a message matches both a deny and a permit, the message will not be bridged. The EXEC show span command reports the group code filtering in effect. Default is no filtering.
bridge-group group output-lsap-list list
Adds or removes a filter for IEEE 802-encapsulated packets on output. This access list is applied just before sending out a frame to an interface. The argument group is the spanning-tree group number. The argument list is the access list number between 200 and 200, which you assigned with the bridge access-list command.
bridge-group group output-type-list list
Adds or removes a filter for Ethernet- and SNAP-encapsulated packets on output. This access list is then applied just before sending out a frame to an interface. The argument group is the spanning-tree group number. The argument list is the access list number between 200 and 299, which you assigned with the bridge access-list command.
[no] bridge-group group path-cost cost
Sets or removes a different path cost. The path cost can range from 0 to 65535, with higher values indicating higher costs. The argument group is the spanning-tree group number. The argument cost is the path cost. The no version of the command chooses the default path cost for the interface.
bridge-group group priority number
Assigns a priority to an interface. This priority is used in tie-breaking when computing a network topology. The argument group is the spanning-tree group number. The argument number can range from 0 to 255. The default value is zero, and the lower the number, the more likely it is that the bridge on this interface will be chosen as the root.
|
|