|
|
Our 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 a router.
This chapter discusses how to configure transparent bridging and source-route transparent (SRT) bridging. Configuration examples are provided at the end of the chapter. For a complete description of the commands mentioned in this chapter, refer to the "Transparent Bridging Commands" chapter of the Router Products Command Reference publication. For historical background and a technical overview of transparent bridging, see the Internetworking Technology Overview publication.
Cisco supports transparent bridging for Ethernet, FDDI, and serial media, and supports source-route transparent bridging (SRT) for Token Ring media. In addition, Cisco supports all of the mandatory MIB variables specified for Transparent Bridging in RFC 1286.
Cisco's transparent bridging software implementation provides these features:
Routers can 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 Digital's Local Area Transport (LAT) protocol or NetBIOS traffic.
Remote bridging over synchronous serial lines also is supported between our routers. As with frames received on all other media types, the dynamic learning and any filtering is applied to frames received on serial lines.
Transit bridging of Ethernet frames across FDDI media also is supported. The term transit refers to the fact that the source or destination of the frame cannot be on the FDDI media itself. This allows FDDI to act as a highly efficient backbone for the interconnection of many bridged networks. The configuration of FDDI transit bridging is identical to the configuration of transparent bridging on all other media types.
Our router/bridges also support transparent bridging on Token Ring interfaces that are capable of supporting source-route transparent (SRT) bridging.
As with all other media types, all the features that use bridge-group commands can be used on Token Ring interfaces. As with other interface types, the bridge group can be configured to run either 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 constructs a loop-free topology across the entire extended LAN.
You can run the DEC spanning-tree protocol over Token Ring as well. Use it 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 that on 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 (that is, the destination service access point (DSAP) value is AA, the source service access point (SSAP) value is AA, with the Organizational Unique Identifier (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. You can determine the OUI type used when transporting Ethernet Type II frames over other media. Graphic illustrations of frame formats is given in Appendix A of the Router Products Command Reference publication.
We currently know that problems occur with the following protocols when bridged between Token Ring and other media: Novell IPX, DECnet Phase IV, AppleTalk, VINES, XNS and IP. Further, problems can occur with the Novell IPX and XNS protocols when bridged between FDDI and other media. We recommend that these protocols be routed whenever possible.
Perform one or more of the following tasks to configure transparent bridging or source-route bridging on your router/bridge. Each task and command is described in greater detail in the following sections.
To configure transparent bridging, at a minimum you must perform the following tasks:
The first step in setting up your transparent bridging network is to define a spanning-tree protocol and assign a bridge group number. You can choose either the IEEE 802.1D spanning-tree protocol or the earlier Digital (DEC) protocol upon which this IEEE standard is based.
To assign a bridge group number and define a spanning-tree protocol, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Assign a bridge group number and define a spanning-tree protocol as either IEEE 802.1D standard or DEC. | bridge group protocol {ieee | dec} |
Next, assign each network interface to a bridge group by performing the following task in interface configuration mode:
| Task | Command |
|---|---|
| Assign a network interface to a bridge group. | bridge-group group |
A bridge group is an internal organization of network interfaces on a router. Bridge groups cannot be used outside the router on which it is defined to identify traffic switched within the bridge group. Bridge groups within the same router function as distinct bridges; that is, bridged traffic and BPDUs cannot be exchanged between different bridge groups on a router. Furthermore, bridge groups cannot be used to multiplex or demultiplex different streams of bridged traffic on a LAN. An interface can only be a member of one bridge group. Use a bridge group for each separately bridged (topologically distinct) network connected to the router. Typically, only one such network exists in a configuration.
The purpose of placing network interfaces into a bridge group is twofold:
For SRT, if the Token Ring and serial interfaces are in the same bridge group, changing the serial encapsulation method causes the state of the corresponding Token Ring interface to be reinitialized. Its state will change from "up" to "initializing" to "up" again within a few seconds.
For source-route transparent (SRT) bridging networks, you must choose the OUI code that will be used in the encapsulation of Ethernet Type II frames across Token Ring backbone networks. To choose the OUI, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Select the Ethernet Type II OUI encapsulation code. | ethernet-transit-oui [90-compatible | standard | cisco] |
We support transparent bridging over the following types of networks:
This section describes how to configure bridging on these networks.
The transparent bridging software supports bridging of packets in X.25 frames. This ability is useful for such tasks as transmitting packets from proprietary protocols across an X.25 network.
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. You specify the Internet-to-X.121 address mapping, and the system maintains a table of both the Ethernet and X.121 addresses. To configure X.25 transparent bridging, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Specify Internet-to-X.121 mapping. | x25 map bridge X.121-address broadcast [options-keywords] |
Configuring X.25 is discussed in more detail in the chapter "Configuring X.25 and LAPB."
The transparent bridging software supports bridging of packets over Frame Relay networks. This ability is useful for such tasks as transmitting packets from proprietary protocols across a Frame Relay network. Bridging over a Frame Relay network is supported both on networks that support a multicast facility and those that do not. Both cases are described in this section.
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. You specify Internet-to-DLCI (Data link Connection Identifier) address mapping, and the system maintains a table of both the Ethernet address and the DLCIs.
To configure bridging in a network not supporting a multicast facility, define the mapping between an address and the DLCI used to connect to the address. To bridge with no multicasts, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Define the mapping between an address and the DLCI used to connect to the address. | frame-relay map bridge DLCI broadcast |
An example configuration is provided in the section "Transparent Bridging Configuration Examples" at the end of this chapter. Frame Relay is discussed in more detail in the chapter "Configuring Frame Relay."
The multicast facility is used to learn about the other bridges on the network, eliminating the need for you to specify any mappings. An example configuration is provided in the section "Transparent Bridging Configuration Examples" at the end of the chapter for use as a configuration guide.
We support transparent bridging over SMDS networks. Standard bridging commands are used to enable bridging on an SMDS interface. To enable transparent bridging over SMDS, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Enable transparent bridging of packets across an SMDS network. | smds multicast bridge SMDS-address |
When transparently bridging over an SMDS network, the broadcast ARP packets are treated differently from other encapsulation methods. For SMDS, two packets are sent to the multicast address. One is sent using a standard (SMDS) ARP encapsulation, the other is sent with the ARP packet encapsulated in an 802.3 MAC header. The native ARP is sent as a regular ARP broadcast.
In addition, our implementation of 802.6 bridging only supports the transmission and reception of 802.3 encapsulated bridge packets. However, other encapsulations will be supported in a future release. Software Release 9.21 does not support bridging over multiple logical IP subnets (MultiLIS) because bridging of IP packets in a MultiLIS environment is unpredictable. It also does not support bridging from SMDS to SMDS; that is, packets from one SMDS network will not be forwarded to another SMDS network interface through the bridging mechanism. SMDS is discussed in more detail in the chapter "Configuring SMDS."
You can configure one or more transparent bridging options. To configure transparent bridging options, perform one or more of the following tasks:
If you want to bridge IP, you must disable IP routing, because IP routing is enabled by default on all routers/bridges. You can enable IP routing when you decide to route IP packets. To disable or enable IP routing, perform one of the following tasks in global configuration mode:
| Task | Command |
|---|---|
| Disable IP routing. | no ip routing |
| Enable IP routing. | ip routing |
All interfaces in the bridge group that are bridging IP should have the same IP address. However, if you have more than one bridge group, each bridge group should have its own IP address.
Normally, bridging takes place on the processor card at the interrupt level. When autonomous bridging is enabled, bridging takes place entirely on the CiscoBus II controller, significantly improving performance. Autonomous bridging is a high-speed switching feature that allows bridged traffic to be forwarded and flooded on the CiscoBusII between resident interfaces. If you are using the CiscoBus II controller, you can maximize performance by enabling autonomous bridging on the following CiscoBus II interfaces:
Although performance improvements will be seen most in the resident interfaces, the autonomous bridging feature may also be used in bridge groups that include interfaces that are not on the CiscoBusII controller. These interfaces include the CTR, FCI with encapsulation bridging, HSSI with other than HDLC encapsulation such as X.25, Frame Relay, or SMDS, MCI, STR, or SBE16.
If you enable autonomous bridging for a bridge group that includes a combination of interfaces that are resident on the CiscoBusII and some that are not, the CiscoBusII will forward only packets between resident interfaces. Forwarding between nonresident and resident interfaces will be done in either the fast or process paths. Flooding between resident interfaces will be done by CiscoBusII. Flooding between nonresident interfaces will be done conventionally. If a packet is forwarded from a nonresident to a resident interface, the packet will be conventionally forwarded. If packets are flooded from a nonresident interface to a resident interface, the packet will be autonomously flooded.
To enable autonomous bridging on a per-interface basis, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Enable autonomous bridging (if using CiscoBus II). | bridge-group n cbus-bridging |
The Local Area Transport (LAT) protocol used by Digital and Digital-compatible terminal servers is one of the common protocols that lacks a well-defined network layer (Layer 3) and so always must be bridged.
To reduce the amount of bandwidth that LAT traffic consumes on serial interfaces, you can specify a LAT-specific form of compression. Doing so applies compression to LAT frames being sent out the router/bridge through the interface in question. To configure LAT compression, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Reduce the amount of bandwidth that LAT traffic consumes on a serial interface. | bridge-group group lat-compression |
LAT compression can 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 Cisco IEEE 802.1D bridging software supports spanning-tree domains of bridge groups. Domains are a feature specific to Cisco. This feature is only available if you have specified the ieee keyword in the bridge protocol command. A domain establishes an external identification of the BPDUs sent from a bridge group. The purpose of this identification is as follows:
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.
When multiple routers share the same cable, and you want to use only certain discrete subsets of those routers to share spanning-tree information with each other, establish spanning-tree domains. This function is most useful when running other router applications, such as IP UDP flooding, that use the IEEE spanning tree. You also can use this feature to reduce the number of global reconfigurations in large bridged networks.
To establish multiple spanning-tree domains, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Establish a multiple spanning-tree domain. | bridge group domain domain-number |
For an example of how to configure domains, see the "Example of Complex Transparent Bridging Topology" section later in this chapter.
Normally, the system forwards any frames for stations that it has learned about dynamically. By disabling this activity, the bridge will only forward frames whose address have been statically configured into the forwarding cache. To prevent forwarding of dynamically determined stations, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Filter out all frames except those whose addresses have been statically configured into the forwarding cache. | no bridge group acquire |
To allow the forwarding of frames from stations that the router has learned about dynamically, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Remove the ability to filter out all frames except those whose addresses have been statically configured into the forwarding cache. | bridge group acquire |
A packet with a RIF, indicated by a source address with the multicast bit turned on, is not usually forwarded. However, you can configure bridging support to allow the forwarding of frames that would otherwise be discarded because they have a RIF. Although you can forward these frames, the bridge table will not be updated to include the source addresses of these frames.
To forward frames with multicast addresses, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Allow the forwarding of frames with multicast source addresses. | bridge group multicast-source |
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 bridge software allows you to configure specific administrative filters that filter frames based upon information other than paths to their destinations. You can perform administrative filtering by performing one of the following tasks:
When configuring transparent bridging access control, keep the following points in mind:
You can filter transmission of frames based on the MAC-level address various ways by performing one of the following tasks:
When filtering by a MAC-level address, there are two kinds of access lists that can be used: standard access lists that specify a simple address; and extended access lists that specify two addresses. You also can further restrict access by creating filters for these lists. After you have completed one of the preceding tasks, perform the following task:
You can filter frames with a particular MAC-level station source or destination address. Any number of addresses can be configured into the system without a performance penalty. To filter by the MAC-level address, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Filter particular MAC-level station addresses. | bridge group address MAC-address {forward | discard} [interface] |
When filtering specific MAC destination addresses, allow for multicast or broadcast packets that are required by the bridged network protocols. Refer to the example in the section "Transparent Bridging Configuration Examples" later in this chapter to guide you in building your configuration to allow for multicast or broadcast packets.
The bridging software allows you to create access lists to administratively filter MAC addresses. These access lists can filter groups of MAC addresses, including those with particular vendor codes. There is no noticeable performance loss in using these access lists, and the lists can be of indefinite length. You can filter groups of MAC addresses with particular vendor codes by performing the first task and one or both of the other tasks that follow:
To establish a vendor code access list, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Prepare access control information for filtering of frames by canonical (Ethernet ordered) MAC address. | access-list list {permit | deny} address mask |
For an example of how to filter by vendor code, see "Example of Multicast or Broadcast Packets Bridging" later in this chapter.
Once you have defined an access list to filter by a particular vendor code, you can assign an access list to a particular interface for filtering on the MAC source addresses of packets received on that interface. To filter source addresses, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Assign an access list to an interface for filtering by MAC source addresses. | bridge-group group input-address-list list |
Once you have defined an access list to filter by a particular vendor code, you can assign an access list to a particular interface for filtering the MAC destination addresses of packets that would ordinarily be forwarded out that interface. To filter on destination addresses, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Assign an access list to an interface for filtering by the MAC destination addresses. | bridge-group group output-address-list list |
You can filter by protocol type by using the access list mechanism and specifying a protocol type code. To filter by protocol type, perform the first task and one or more of the other tasks that follow:
The order in which you enter access-list commands 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.
Access lists for Ethernet- and IEEE 802-encapsulated packets affect only bridging functions. It is not possible to use such access lists to block frames with protocols that are being routed.
You can establish type-code access lists. 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 Appendix B of the Router Products Command Reference publication.
To establish type-code access lists, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Prepare access control information for filtering frames by protocol type. | access-list list {permit | deny} type-code wild-mask |
You can filter Ethernet- and SNAP-encapsulated packets on input. For SNAP-encapsulated frames, the access list you create is applied against the two-byte TYPE field given after the DSAP/SSAP/OUI fields in the frame.
To filter these packets on input, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Add a filter for Ethernet- and SNAP-encapsulated packets on input. | bridge-group group input-type-list list |
This access list is applied to all Ethernet and SNAP frames received on that interface prior to the bridge learning process. SNAP frames also must pass any applicable IEEE 802 DSAP/SSAP access lists.
You can filter Ethernet- and SNAP-encapsulated packets on output. The access list you create is applied just before sending out a frame to an interface.
To filter these packets on output, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Add a filter for Ethernet- and SNAP-encapsulated packets on output. | bridge-group group output-type-list list |
You can filter IEEE 802-encapsulated packets on input. The access list you create is applied to all IEEE 802 frames received on that interface prior to the bridge-learning process. SNAP frames also must pass any applicable Ethernet type-code access list.
To filter these packets on input, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Add a filter for IEEE 802-encapsulated packets on input. | bridge-group group input-lsap-list list |
You can filter IEEE 802-encapsulated packets on output. SNAP frames also must pass any applicable Ethernet type-code access list. The access list you create is applied just before sending out a frame to an interface.
To filter these packets on output, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Add a filter for IEEE 802-encapsulated packets on output. | bridge-group group output-lsap-list list |
Access lists for Ethernet- and IEEE 802-encapsulated packets affect only bridging functions. It is not possible to use such access lists to block frames with protocols that are being routed.
If you are filtering by the MAC-level address, whether it is by a specific MAC address, vendor code, or protocol type, you can define and apply extended access lists. Extended access lists allow finer granularity of control. They allow you to specify both source and destination addresses and arbitrary bytes in the packet.
To define an extended access list, perform the following task in global configuration mode:
To apply an access list to an interface, perform one of the following tasks in interface configuration mode:
| Task | Command |
|---|---|
| Apply that extended access list to an interface. | bridge-group group input-pattern accesslist |
| Apply that extended access list to an interface. | bridge-group group output-pattern accesslist |
After an access list is created initially, any subsequent additions (possibly entered from the terminal) are placed at the end of the list. In other words, you cannot selectively add or remove access list command lines from a specific access list.
 | Caution Due to their complexity, extended access lists should only be used by those who are very familiar with the router. Further, do not specify offsets into a packet that are greater than the size of the packet. |
The bridging software allows you to filter LAT frames. LAT bridge filtering allows the selective inclusion or exclusion of LAT multicast service announcements on a per-interface basis.
In the LAT protocol, a group code is defined as a decimal number in the range 0 to 255. Some of the 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 that 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 only will 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. In an environment with many bridges and many LAT hosts, the number of multicast messages that each system has to deal with 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 which multicast messages actually get bridged. Through a combination of input and output permit and deny lists, you can implement many different LAT control policies.
The following sections describe the LAT filtering mechanisms available to you.
You can specify LAT group-code filtering to inform the system that LAT service advertisements require special processing. To enable LAT group code filtering, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Enable LAT service filtering. | bridge group lat-service-filtering |
You can specify the group codes by which to deny access upon input. Doing so causes the system to not bridge any LAT service advertisement that has any of the specified groups set.
To specify input deny conditions for LAT groups, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Specify the group codes by which to deny access upon input. | bridge-group group input-lat-service-deny grouplist |
You can specify the group codes by which to permit access upon input. Doing so causes the system to bridge only those service advertisements that match at least one group in the group list you specified by the grouplist argument.
To specify input permit conditions for LAT groups, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Specify the group codes with which to permit access upon input. | bridge-group group input-lat-service-permit grouplist |
If a message specifies group codes in both the deny and permit list, the message is not bridged.
You can specify the group codes by which to deny access upon output. Doing this causes the system to not bridge onto this output interface any service advertisements that contain groups matching any of these in the group list.
To specify output deny conditions for LAT groups, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Specify the group codes with which to deny access upon output. | bridge-group group output-lat-service-deny grouplist |
You can specify the group codes by which to permit access upon output. Doing this 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.
To specify output permit conditions for LAT groups, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Specify the group codes with which to permit access upon output. | bridge-group group output-lat-service-permit grouplist |
If a message matches both a deny and a permit condition, it will not be bridged.
You might need to adjust certain spanning-tree parameters if the default values are not suitable for your bridge configuration. 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.
You can adjust spanning-tree parameters by performing any of the following tasks:
You can globally configure the priority of an individual bridge when two bridges tie for position as the root bridge, or you can configure the likelihood that a bridge will be selected as the root bridge. This priority is determined by default; however, you can change it. To set the bridge priority, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Set the bridge priority. | bridge group priority number |
You can set a priority for an interface. When two bridges tie for position as the root bridge, you configure an interface priority to break the tie. The bridge with the lowest interface value is elected. To set an interface priority, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Establish a priority for a specified interface. | bridge-group group priority number |
Each interface has a path cost associated with it. By convention, the path cost is 1000/data rate of the attached LAN, in Mbps. You can set different path costs. Refer to the entry for this command in the "Configuring Transparent Bridging" chapter of the Router Products Command Reference publication for the various media defaults. To assign path costs, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Set a different path cost other than the defaults. | bridge-group group path-cost cost |
You can adjust the following Hello Bridge Protocol Data Unit (BPDU) intervals:
You can specify the interval between Hello BPDUs. To adjust this interval, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Specify the interval between Hello BPDUs. | bridge group hello-time seconds |
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. To change the default interval setting, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Set the default of the forward delay interval. | bridge group forward-time seconds |
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. To change the default interval setting, performing the following task in global configuration mode:
| Task | Command |
|---|---|
| Change the amount of time a bridge will wait to hear BPDUs from the root bridge. | bridge group max-age seconds |
When a loop-free path exists between any two bridged subnetworks, you can prevent BPDUs generated in one transparent bridging subnetwork from impacting nodes in the other transparent bridging subnetwork, yet still permit bridging throughout the bridged network as a whole. For example, when transparently bridged LAN subnetworks are separated by a WAN, BPDUs can be prevented from traveling across the WAN link.
To disable the spanning tree on an interface, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Disable the spanning tree on an interface. | bridge-group group spanning-disabled |
There is often a desire to increase the available bandwidth by using multiple, parallel lines between the same two bridges. In the normal operation of the spanning-tree algorithm, parallel network segments cannot all carry traffic at the same time. If they do, looping of frames may occur. However, you can modify the spanning-tree algorithm's handling of serial lines so that traffic can be carried at the same time over parallel lines between two bridges for purposes of load balancing. You make this modification by grouping parallel lines between two bridges in a circuit group.
When you define a circuit group, the spanning-tree algorithm handles traffic in a manner so that it can avoid ordering problems of packets that are sent between a source and destination bridge. All packets to a particular destination are sent over the same serial line to ensure that all packets to that destination are correctly ordered. If a bridge (source) sends a packet to an unknown destination, the bridge needs to associate an address with a particular serial line for the purposes of forwarding. The bridge makes this association by flooding the packet in a round-robin fashion on the serial lines to the destination bridge connected on the other side of the serial line. The source bridge, through its dynamic learning process, learns the address of the receiving end (destination bridge). The source bridge will then select the least recently used serial line and associate the destination address with that line, thereby creating a source-destination pair. Once the bridge makes the association between the source and destination, it will forward packets between the pair only on that serial line. Each source-destination pair has a "separate conversation" thereby avoiding potential packet ordering problems. This algorithm is used for all packets exchanged between bridges defined in a circuit group.
You must configure all the parallel serial interfaces on a given bridge as being members of the same circuit group. If interfaces go down or come back up, reassignment is done dynamically.
To define a circuit group, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Establish load balancing, marking a serial interface as belonging to a circuit group number. | bridge-group group circuit number |
For an example of how to configure a circuit group, see the "Example of Complex Transparent Bridging Topology" section later in this chapter.
This section describes how to obtain displays of activity on the bridged network. You can perform one or more of the following tasks in EXEC mode:
This section provides the following example configurations that you can use as a guide to configuring your bridging environment:
Figure 1-1 is an example of a basic bridging configuration. The system has two Ethernets, one Token Ring, one FDDI 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.
The configuration file for the router/bridge depicted in Figure 1-1would 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 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
The following configuration example shows the configuration commands that enable transparent bridging between Ethernet and FDDI interfaces. Transparent bridging on an FDDI interface is allowed only on the CSC-C2FCIT interface card.
!
hostname tester
!
buffers small min-free 20
buffers middle min-free 10
buffers big min-free 5
!
no ip routing
!
interface Ethernet 0
ip address 131.108.7.207 255.255.255.0
no ip route-cache
bridge-group 1
!
interface Ethernet 2
ip address 131.108.7.207 255.255.255.0
no ip route-cache
bridge-group 1
!
interface Fddi 0
ip address 131.108.7.207 255.255.255.0
no ip route-cache
no keepalive
bridge-group 1
!
bridge 1 protocol ieee
If the other side of the FDDI ring was an FDDI interface running in encapsulation mode rather than in transparent mode, the following additional configuration commands are needed:
interface fddi 0
fddi encapsulate
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-2 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-3, a Token Ring and an Ethernet at a remote sales site in New York City 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 also would be used to configure source routing.
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
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
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 your network as 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, because input addresses work on the 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. The failure occurs because the configuration does not allow for an ARP broadcast with a destination address of FFFF.FFFF.FFFF, 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 correct access list would be as follows:
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
Figure 1-5 is an example configuration illustrating three 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 5 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
Figure 1-6 illustrates three bridges connected to each other through a Frame Relay network.
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
!
Figure 1-7 shows a network topology made up of four bridged subnetworks (BSNs). Each BSN is defined by the scope of a spanning tree. However, the scope of each spanning tree is not shown in detail because it is unnecessary for purposes of this discussion. Instead, it is shown by a half cloud labeled "To other parts of BSN."
For proper bridging operation, the BSNs cannot have connections between them, but they can be connected to the same backbone. In this example, three of the four BSNs are connected to the FDDI backbone and each belongs to a separate domain. Domains used in this topology allow the BSNs to be independent of one another while still bridging traffic onto the backbone destined for other connected BSNs. Domains can only be used in this manner if the BSNs have a single point of attachment to one another. In this case, the connection to the FDDI backbone is that single point of attachment. Each router on which a domain is configured and that has a single point of attachment to the other BSNs, checks whether a BPDU on the backbone is its own. If the BPDU does not belong to the BSN, the router ignores the BPDU.
Separate BSNs, as in this example, allow spanning tree reconfiguration of individual BSNs without disrupting bridging among the other BSNs.
The routers in this network are configured for bridging and demonstrate some of the bridging features available.
Router A demonstrates multiple bridge groups in one router for bridged traffic separation.
In Router A, the Token Ring interfaces are bridged together entirely independently of the other bridged interfaces in the router and belong to bridge group 1. Bridge group 1 does not use a bridge domain because the interfaces are bridged independently of other BSNs in the network topology and it has no connection to the FDDI backbone.
Also in Router A, the Ethernet interfaces belong to bridge group 3. Bridge group 3 has a connection to the FDDI backbone and has a domain defined for it so that it can ignore BPDUs for other BSNs.
interface Ethernet0
bridge-group 3
!
interface Ethernet1
bridge-group 3
!
interface Ethernet2
bridge-group 3
!
interface Ethernet3
bridge-group 3
!
interface Fddi0
bridge-group 3
!
interface TokenRing1
bridge-group 1
!
interface TokenRing2
bridge-group 1
!
bridge 1 protocol ieee
bridge 3 domain 1
bridge 3 protocol ieee
!
Router B demonstrates a simple bridge configuration. It is connected to the FDDI backbone and has domain 2 defined. As such it can bridge traffic with the other FDDI-connected BSNs. Note that bridge group 1 has no relationship to bridge group 1 in Router A; bridge groups are an organization internal to each router.
interface Ethernet1
bridge-group 1
!
interface Ethernet2
bridge-group 1
!
interface Fddi0
bridge-group 1
!
bridge 1 domain 2
bridge 1 protocol ieee
!
Router C and Router D combine to demonstrate load balancing by means of circuit groups. Circuit groups are used to load balance across multiple parallel serial lines between a pair of routers. The router on each end of the serial lines must have a circuit group defined. The circuit group number can be the same or can be different. In this example, they are different.
Router C and Router D are configured with the same domain, because they must understand one another's BPDUs. If they were configured with separate domains, Router D would ignore Router C's BPDUs and vice versa.
interface Fddi0
bridge-group 2
!
interface Serial0
bridge-group 2
bridge-group 2 circuit 7
!
interface Serial1
bridge-group 2
bridge-group 2 circuit 7
!
interface Serial2
bridge-group 2
bridge-group 2 circuit 7
!
bridge 2 domain 3
bridge 2 protocol ieee
interface Ethernet4
bridge-group 5
!
interface Ethernet5
bridge-group 5
!
interface Serial0
bridge-group 5
bridge-group 5 circuit 4
!
interface Serial1
bridge-group 5
bridge-group 5 circuit 4
!
interface Serial2
bridge-group 5
bridge-group 5 circuit 4
!
bridge 5 domain 3
bridge 5 protocol ieee
!
|
|