Table Of Contents
Configuring Transparent Bridging
Integrated Routing and Bridging
Bridge-Group Virtual Interface
Transparent and SRT Bridging Configuration Task List
Configuring Transparent Bridging and SRT Bridging
Assigning a Bridge Group Number and Defining the Spanning Tree Protocol
Assigning Each Network Interface to a Bridge Group
Choosing the OUI for Ethernet Type II Frames
Transparently Bridged VLANs for ISL
Configuring a Subscriber Bridge Group
Configuring Transparent Bridging over WANs
Configuring Fast-Switched Transparent Bridging over ATM
Configuring Transparent Bridging over DDR
Configuring Transparent Bridging over Frame Relay
Configuring Transparent Bridging over Multiprotocol LAPB
Configuring Transparent Bridging over SMDS
Configuring Transparent Bridging over X.25
Configuring Concurrent Routing and Bridging
Configuring Integrated Routing and Bridging
Assigning a Bridge Group Number and Defining the Spanning Tree Protocol
Enabling Integrated Routing and Bridging
Configuring the Bridge-Group Virtual Interface
Configuring Protocols for Routing or Bridging
Configuring Transparent Bridging Options
Establishing Multiple Spanning-Tree Domains
Preventing the Forwarding of Dynamically Determined Stations
Forwarding Multicast Addresses
Configuring Bridge Table Aging Time
Filtering Transparently Bridged Packets
Setting Filters at the MAC Layer
Filtering LAT Service Announcements
Adjusting Spanning-Tree Parameters
Disabling the Spanning Tree on an Interface
Configuring Transparent and IRB Bridging on a PA-12E/2FE Ethernet Switch
Configuring the PA-12E/2FE Port Adapter
Monitoring and Maintaining the PA-12E/2FE Port Adapter
Configuring Bridge Groups Using the 12E/2FE VLAN Configuration WebTool
Tuning the Transparently Bridged Network
Configuring Constrained Multicast Flooding
Monitoring and Maintaining the Transparent Bridge Network
Transparent and SRT Bridging Configuration Examples
Concurrent Routing and Bridging Example
Basic Integrated Routing and Bridging Example
Complex Integrated Routing and Bridging Example
Integrated Routing and Bridging with Multiple Bridge Groups Example
Transparently Bridged VLANs Configuration Example
Routing Between VLANs Configuration Example
Ethernet-to-FDDI Transparent Bridging Example
Multicast or Broadcast Packets Bridging Example
X.25 Transparent Bridging Example
Frame Relay Transparent Bridging Examples
Bridging in a Frame Relay Network with No Multicasts
Bridging in a Frame Relay Network with Multicasts
Transparent Bridging over Multiprotocol LAPB Example
Fast-Switched Transparent Bridging over ATM Example (Cisco 7000)
Transparent Bridging over DDR Examples
Fast-Switched Transparent Bridging over SMDS Example
Complex Transparent Bridging Network Topology Example
Fast Ethernet Subscriber Port, Frame Relay Trunk Example
ATM Subscriber Ports, ATM Trunk Example
Configuration of Transparent Bridging for PA-12E/2FE Port Adapter Example
Configuration of IRB for PA-12E/2FE Port Adapter Example
Configuring Transparent Bridging
The Cisco IOS software bridging functionality 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 describes how to configure transparent bridging and source-route transparent (SRT) bridging. This chapter also describes the concepts of virtual networking, transparent bridging of virtual LANs (VLANs), and routing between VLANs. For a complete description of the transparent bridging commands mentioned in this chapter, refer to the "Transparent Bridging Commands" chapter in the Cisco IOS Bridging and IBM Networking Command Reference (Volume 1 of 2). To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
This chapter contains the following sections:
•
Transparent and SRT Bridging Configuration Task List
•
•
•
Technology Overview
The following sections provide an overview of transparent bridging in the Cisco IOS software:
•
•
Transparent and SRT Bridging
Cisco IOS software supports transparent bridging for Ethernet, Fiber Distributed Data Interface (FDDI), and serial media, and supports source-route transparent (SRT) bridging for Token Ring media. In addition, Cisco supports all the mandatory Management Information Base (MIB) variables specified for transparent bridging in RFC 1286.
Transparent Bridging Features
Cisco's transparent bridging software implementation has the following features:
•
•
•
•
•
•
•
•
•
•
•
•
Cisco access servers and 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 routing the IP can also bridge DEC's LAT protocol or NetBIOS traffic.
Cisco routers also support remote bridging over synchronous serial lines. As with frames received on all other media types, dynamic learning and configurable filtering applies to frames received on serial lines.
Transit bridging of Ethernet frames across FDDI media is also 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.
Integrated Routing and Bridging
While concurrent routing and bridging makes it possible to both route and bridge a specific protocol on separate interfaces within a router, the protocol is not switched between bridged and routed interfaces. Routed traffic is confined to the routed interfaces; bridged traffic is confined to bridged interfaces. A specified protocol may be either routed or bridged on a given interface, but not both.
Integrated routing and bridging makes it possible to route a specific protocol between routed interfaces and bridge groups, or route a specific protocol between bridge groups. Local or unroutable traffic can be bridged among the bridged interfaces in the same bridge group, while routable traffic can be routed to other routed interfaces or bridge groups. Figure 7 illustrates how integrated routing and bridging in a router interconnects a bridged network with a routed network.
Figure 7 Integrated Routing and Bridging Interconnecting a Bridged Network with a Routed Network
You can configure the Cisco IOS software to route a specific protocol between routed interfaces and bridge groups or to route a specific protocol between bridge groups. Specifically, local or unroutable traffic is bridged among the bridged interfaces in the same bridge group, while routable traffic is routed to other routed interfaces or bridge groups. Using integrated routing and bridging, you can do the following:
•
•
•
Bridge-Group Virtual Interface
Because bridging operates in the data link layer and routing operates in the network layer, they follow different protocol configuration models. Taking the basic IP model as an example, all bridged interfaces would belong to the same network, while each routed interface represents a distinct network.
In integrated routing and bridging, the bridge-group virtual interface is introduced to avoid confusing the protocol configuration model when a specific protocol is both bridged and routed in a bridge group. Figure 8 illustrates the bridge-group virtual interface as a user-configured virtual interface residing within a router.
Figure 8 Bridge-Group Virtual Interface in the Router
The bridge-group virtual interface is a normal routed interface that does not support bridging, but does represent its corresponding bridge group to the routed interface. It has all the network layer attributes (such as a network layer address and filters) that apply to the corresponding bridge group. The interface number assigned to this virtual interface corresponds to the bridge group that this virtual interface represents. This number is the link between the virtual interface and the bridge group.
When you enable routing for a given protocol on the bridge-group virtual interface, packets coming from a routed interface, but destined for a host in a bridged domain, are routed to the bridge-group virtual interface and are forwarded to the corresponding bridged interface. All traffic routed to the bridge-group virtual interface is forwarded to the corresponding bridge group as bridged traffic. All routable traffic received on a bridged interface is routed to other routed interfaces as if it is coming directly from the bridge-group virtual interface.
To receive routable packets arriving on a bridged interface but destined for a routed interface or to receive routed packets, the bridge-group virtual interface must also have the appropriate addresses. MAC addresses and network addresses are assigned to the bridge-group virtual interface as follows:
•
•
Note
Because there can be only one bridge-group virtual interface representing a bridge group, and the bridge group can be made up of different media types configured for several different encapsulation methods, you may need to configure the bridge-group virtual interface with the particular encapsulation methods required to switch packets correctly.
For example, the bridge-group virtual interface has default data link and network layer encapsulations that are the same as those available on Ethernet interfaces, but you can configure the bridge-group virtual interface with encapsulations that are not supported on an Ethernet interface. In some cases, the default encapsulations provide appropriate results; in other cases they do not. For example, with default encapsulation, Advanced Research Projects Agency (ARPA) packets from the bridge-group virtual interface are translated to Subnetwork Access Protocol (SNAP) when bridging IP to a Token Ring- or FDDI-bridged interface. But for Internet Packet Exchange (IPX), Novell-ether encapsulation from the bridge-group virtual interface is translated to raw-token or raw-FDDI when bridging IPX to a Token Ring- or FDDI-bridged interface. Because this behavior is usually not what you want, you must configure IPX SNAP or Service Advertisement Protocol (SAP) encapsulation on the bridge-group virtual interface.
Other Considerations
The following are additional facts regarding the support of integrated routing and bridging:
•
•
•
•
•
•
•
SRT Bridging Features
Cisco routers support transparent bridging on Token Ring interfaces that support SRT bridging. Both transparent and SRT bridging are supported on all Token Ring interface cards that can be configured for either 4- or 16-MB transmission speeds.
As with other media, 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 configured for the IEEE Spanning Tree Protocol, the bridge cooperates with other SRT bridges and constructs a loop-free topology across the entire extended LAN.
You can also run the DEC Spanning Tree Protocol over Token Ring. Use it when you have other non-IEEE bridges on other media and you do not have any SRT bridges on Token Ring. In this configuration, all the 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 bridging specification, only packets without a routing information field (RIF) (RII = 0 in the SA field) are transparently bridged. Packets with a RIF (RII = 1) are passed to the SRB module for handling. An SRT-capable Token Ring interface can have both SRB and transparent bridging enabled at the same time. However, with SRT bridging, frames that did not have a RIF when they were produced by their generating host never gain a RIF, and frames that did have a RIF when they were produced never lose that RIF.
Note
Bridging between Token Ring and other media requires certain packet transformations. 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 packet format, logical link control (LLC), while Ethernet supports two formats (LLC and Ethernet).
The transformation of LLC frames between media is simple. A length field is either created (when the frame is sent to non-Token Ring) or removed (when the frame is sent to Token Ring). When an Ethernet format frame is sent to Token Ring, the frame is translated into an LLC-1 SNAP packet. The destination service access point (DSAP) value is AA, the source service access point (SSAP) value is AA, and the organizational unique identifier (OUI) value is 0000F8. Likewise, when a packet in LLC-1 format is bridged onto Ethernet media, the packet is translated into Ethernet format.
Caution
Problems currently occur with the following protocols when bridged between Token Ring and other media: Novell IPX, DECnet Phase IV, AppleTalk, Banyan VINES, Xerox Network Systems (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.
Transparent and SRT Bridging Configuration Task List
To configure transparent bridging or SRT bridging on your router, complete one or more of the tasks in the following sections:
•
•
•
•
•
•
•
•
•
•
See the "Transparent and SRT Bridging Configuration Examples" section for examples.
Configuring Transparent Bridging and SRT Bridging
To configure transparent and SRT bridging, you must perform the following tasks:
•
•
•
Assigning a Bridge Group Number and Defining the Spanning Tree Protocol
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, the earlier DEC protocol upon which this IEEE standard is based or VLAN bridge Spanning Tree Protocol. Cisco expanded the original 802.1 D Spanning Tree Protocol by providing VLAN bridge Spanning Tree Protocol support and increased port identification capability. Furthermore, the enhancement provides:
•
•
Port Number size of the Port ID support is applied only to IEEE and VLAN-bridge Spanning Tree Protocols. The DEC protocol only has 8 bits on the Port ID, so the extension of the Port ID cannot be applied.
The expansion of the Port Number field into the port priority portion of the Port ID changes the useful values the port priority can be assigned.
The way to calculate the Port Path Cost is only supported in IEEE and VLAN-bridge Spanning Tree Protocol environment.
To assign a bridge group number and define a Spanning Tree Protocol, use the following command in global configuration mode:
Router(config)# bridge bridge-group protocol {ieee | dec | vlan-bridge}
Assigns a bridge group number and defines a Spanning Tree Protocol as IEEE 802.1D standard, DEC or VLAN bridge.
The IEEE 802.1D Spanning Tree Protocol is the preferred way of running the bridge. Use the DEC Spanning Tree Protocol only for backward compatibility. The VLAN-bridge Spanning Tree Protocol supports the following media: Ethernet, Fast Ethernet, FDDI, ATM and serial (HDLC, PPP, Frame Relay IETF, SMDS, X.25).
Assigning Each Network Interface to a Bridge 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 bridge protocol data units (BPDUs cannot be exchanged between different bridge groups on a router. Furthermore, bridge groups cannot be used to multiplex or de-multiplex different streams of bridged traffic on a LAN. An interface can be a member of only 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 bridging, 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.
After you assign a bridge group number and define a Spanning Tree Protocol, assign each network interface to a bridge group by using the following command in interface configuration mode:
Router(config-if)# bridge-group bridge-group
Assigns a network interface to a bridge group.
Choosing the OUI for Ethernet Type II Frames
For SRT bridging networks, you must choose the organizational unique identifier (OUI) code that will be used in the encapsulation of Ethernet Type II frames across Token Ring backbone networks. To choose the OUI, use the following command in interface configuration mode:
Router(config-if)# ethernet-transit-oui [90-compatible | standard | cisco]
Selects the Ethernet Type II OUI encapsulation code.
Transparently Bridged VLANs for ISL
Traditionally, a bridge group is an independently bridged subnetwork. In this definition, bridge groups cannot exchange traffic with other bridge groups, nor can they multiplex or de-multiplex different streams of bridged traffic. The transparently bridged VLAN feature in Cisco IOS software permits a bridge group to extend outside the router to identify traffic switched within the bridge group.
While bridge groups remain internal organizations of network interfaces functioning as distinct bridges within a router, transparent bridging on subinterfaces permits bridge groups to be used to multiplex different streams of bridged traffic on a LAN or HDLC serial interface. In this way, bridged traffic may be switched out of one bridge group on one router, multiplexed across a subinterface, and demultiplexed into a second bridge group on a second router. Together, the first bridge group and the second bridge group form a transparently bridged VLAN. This approach can be extended to impose logical topologies upon transparently bridged networks.
The primary application of transparently bridged VLANs constructed in this way is to separate traffic between bridge groups of local network interfaces, to multiplex bridged traffic from several bridge groups on a shared interface (LAN or HDLC serial), and to form VLANs composed of collections of bridge groups on several routers. These VLANs improve performance because they reduce the propagation of locally bridged traffic, and they improve security benefits because they completely separate traffic.
In Figure 9, different bridge groups on different routers are configured into three VLANs that span the bridged network. Each bridge group consists of conventionally bridged local interfaces and a subinterface on the backbone FDDI LAN. Bridged traffic on the subinterface is encapsulated and "colored" with a VLAN identifier known as a security association identifier common to all bridge groups participating in the VLAN. In addition, bridges only accept packets bearing security association identifiers for which they have a configured subinterface. Thus, a bridge group is configured to participate in a VLAN if it contains a subinterface configured with the VLAN's characteristic security association identifier. See the "Complex Integrated Routing and Bridging Example" section for an example configuration of the topology shown in Figure 9.
Note
Figure 9 Transparently Bridged VLANs on an FDDI Backbone
To configure a VLAN on a transparently bridged network, use the following commands beginning in global configuration mode:
Transparently bridged VLANs are supported in conjunction with only the IEEE Spanning Tree Protocol. When you logically segment a transparently bridged network into VLANs, each VLAN computes its own spanning-tree topology. Configuring each VLAN to compute its own spanning-tree topology provides much greater stability than running a single spanning tree throughout. Traffic bridged within one VLAN is unaffected by physical topology changes occurring within another VLAN.
Note
Routing between ISL VLANs
Our VLAN Routing implementation is designed to operate across all router platforms. However, the Inter-Switch Link (ISL) VLAN trunking protocol currently is defined on 100 BaseTX/FX Fast Ethernet interfaces only and therefore is appropriate to the Cisco 7000 and higher-end platforms only. The IEEE 802.10 protocol can run over any LAN or HDLC serial interface. VLAN traffic is fast switched. The actual format of these VLAN encapsulations are detailed in the IEEE Standard 802.10-1992 Secure Data Exchange and in the Inter-Switch Link (ISL) Protocol Specification.
Our VLAN Routing implementation treats the ISL and 802.10 protocols as encapsulation types. On a physical router interface that receives and sends VLAN packets, you can select an arbitrary subinterface and map it to the particular VLAN "color" embedded within the VLAN header. This mapping allows you to selectively control how LAN traffic is routed or switched outside of its own VLAN domain. In the VLAN routing paradigm, a switched VLAN corresponds to a single routed subnet, and the network address is assigned to the subinterface.
To route a received VLAN packet the Cisco IOS software VLAN switching code first extracts the VLAN ID from the packet header (this is a 10-bit field in the case of ISL and a 4-byte entity known as the security association identifier in the case of IEEE 802.10), then demultiplexes the VLAN ID value into a subinterface of the receiving port. If the VLAN color does not resolve to a subinterface, the Cisco IOS software can transparently bridge the foreign packet natively (without modifying the VLAN header) on the condition that the Cisco IOS software is configured to bridge on the subinterface itself. For VLAN packets that bear an ID corresponding to a configured subinterface, received packets are then classified by protocol type before running the appropriate protocol specific fast switching engine. If the subinterface is assigned to a bridge group then non-routed packets are de-encapsulated before they are bridged. This is termed "fall-back bridging" and is most appropriate for nonroutable traffic types.
In Figure 10, Router A provides inter-VLAN connectivity between multiple Cisco switching platforms where there are three distinct virtual topologies present. For example, for VLAN 300 across the two Catalyst 1200A segments, traffic originating on LAN interface 1 is "tagged" with a VLAN ID of 300 as it is switched onto the FDDI ring. This ID allows the remote Catalyst 1200A to make an intelligent forwarding decision and only switch the traffic to local interfaces configured as belonging to the same VLAN broadcast domain. Router A provides an inter-VLAN mechanism that lets Router A function as a gateway for stations on a given LAN segment by sending VLAN encapsulated traffic to and from other switched VLAN domains or simply sending traffic in native (non-VLAN) format.
Figure 10 illustrates the following scenarios:
•
•
Figure 10 Inter-VLAN Connectivity between Multiple Switching Platforms
See the "Routing Between VLANs Configuration Example" section for an example configuration of the topology shown in Figure 10.
To configure routing between VLANs, enter the following commands beginning in global configuration mode:
Configuring a Subscriber Bridge Group
The digital subscriber line (DSL) bridge support feature enables you to configure a router for intelligent bridge flooding for DSL and other bridge applications. To configure a subscriber bridge group, use the following commands beginning in global configuration mode:
Note
Configuring Transparent Bridging over WANs
You can configure transparent bridging over a variety of networks, as described in the following sections:
•
•
•
•
•
•
Configuring Fast-Switched Transparent Bridging over ATM
Our bridging implementation supports IEEE 802.3 frame formats and IEEE 802.10 frame formats. Our implementation can transparently bridge ARPA style Ethernet packets (also known as Ethernet version 2).
Fast-switched transparent bridging over Asynchronous Transfer Mode (ATM) supports AAL5-SNAP encapsulated packets only. All bridged AAL5-SNAP encapsulated packets are fast switched. Fast-switched transparent bridging supports Ethernet, FDDI, and Token Ring packets sent in AAL5-SNAP encapsulation over ATM. See the "Fast-Switched Transparent Bridging over ATM Example (Cisco 7000)" section for an example configuration of fast-switched transparent bridging over ATM.
Support for RFC 1483 was added in Cisco IOS Release 12.0(3)T, enabling transparent bridging between Token Ring LANs (using AAL5-SNAP PVCs) and LANs, VLANs or ELANS (using bridged PDUs). RFC 1483 defines an encapsulation type for transferring LAN data via ATM networks.
For more information on configuring ATM, refer to the "Configuring ATM" chapter in the Cisco IOS Wide-Area Networking Configuration Guide.
Configuring Transparent Bridging over DDR
The Cisco IOS software supports transparent bridging over dial-on-demand routing (DDR) and provides you some flexibility in controlling access and configuring the interface.
To configure DDR for bridging, complete the tasks in the following sections:
•
•
•
•
For an example of configuring transparent bridging over DDR, see the "Transparent Bridging over DDR Examples" section.
Defining the Protocols to Bridge
IP packets are routed by default unless they are explicitly bridged; all others are bridged by default unless they are explicitly routed.
To bridge IP packets, use the following command in global configuration mode:
If you choose not to bridge another protocol, use the relevant command to enable routing of that protocol. For more information about tasks and commands, refer to the relevant protocol chapters in the following publications:
•
•
•
Specifying the Bridging Protocol
You must specify the type of spanning-tree bridging protocol to use and also identify a bridge group. To specify the Spanning Tree Protocol and a bridge group number, use the following command in global configuration mode:
Router(config)# bridge bridge-group protocol {ieee | dec | vlan-bridge}
Defines the type of Spanning Tree Protocol and identifies a bridge group.
The bridge group number is used when you configure the interface and assign it to a bridge group. Packets are bridged only among members of the same bridge group.
Determining Access for Bridging
You can determine access by either permitting all bridge packets or by controlling access according to Ethernet type codes.
To permit all transparent bridge packets, use the following command in global configuration mode:
Router(config)# dialer-list dialer-group protocol bridge permit
Defines a dialer list that permits all transparent bridge packets.
To control access by Ethernet type codes, use the following commands in global configuration mode:
For a table of some common Ethernet types codes, see the "Ethernet Types Codes" appendix in the Cisco IOS Bridging and IBM Networking Command Reference (Volume 1 of 2).
Configuring an Interface for Bridging
You can configure serial interfaces or ISDN interfaces for DDR bridging. To configure an interface for DDR bridging, use the following commands beginning in global configuration mode:
Configuring Transparent Bridging over Frame Relay
The transparent bridging software supports bridging of packets over Frame Relay networks. This ability is useful for such tasks as sending 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.
Fast-Switched Transparent Bridging
The transparent bridging software provides fast-switched transparent bridging for Frame Relay encapsulated serial and High-Speed Serial Interface (HSSI) networks.
Switched virtual circuits (SVCs) are not supported for transparent bridging in this release. All the Permanent virtual circuits (PVCs) configured on a subinterface must belong to the same bridge group.
Bridging in a Frame Relay Network with No Multicasts
The Frame Relay bridging software uses the same spanning-tree algorithm as the other bridging functions, but allows packets to be encapsulated for sending across a Frame Relay network. You specify IP-to-data-link connection identifier (DLCI) address mapping and the system maintains a table of both the Ethernet address and the DLCIs.
To configure bridging in a network that does not support a multicast facility, define the mapping between an address and the DLCI used to connect to the address. To bridge with no multicasts, use the following command in interface configuration mode:
Router(config-if)# frame-relay map bridge dlci broadcast
Defines the mapping between an address and the DLCI used to connect to the address.
An example configuration is provided in the "Frame Relay Transparent Bridging Examples" section. Frame Relay is discussed in more detail in the "Configuring Frame Relay" chapter in the Cisco IOS Wide-Area Networking Configuration Guide.
Bridging in a Frame Relay Network with Multicasts
The multicast facility is used to learn about the other bridges on the network, eliminating the need for you to specify any mappings with the frame-relay map bridge broadcast command. An example configuration is provided in the "Frame Relay Transparent Bridging Examples" section for use as a configuration guide. Frame Relay is discussed in more detail in the "Configuring Frame Relay" chapter in the Cisco IOS Wide-Area Networking Configuration Guide.
Configuring Transparent Bridging over Multiprotocol LAPB
Cisco IOS software implements transparent bridging over multiprotocol Link Access Protocol-Balanced (LAPB) encapsulation on serial interfaces. To configure transparent bridging over multiprotocol LAPB, use the following commands beginning in global configuration mode:
Note
For an example of configuring transparent bridging over multiprotocol LAPB, see the
"Transparent Bridging over Multiprotocol LAPB Example" section".Configuring Transparent Bridging over SMDS
We support fast-switched transparent bridging for Switched Multimegabit Data Service (SMDS) encapsulated serial and HSSI networks. Standard bridging commands are used to enable bridging on an SMDS interface.
To enable transparent bridging over SMDS, use the following commands beginning in global configuration mode:
Broadcast Address Resolution Protocol (ARP) packets are treated differently in transparent bridging over an SMDS network than in 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.
Our implementation of IEEE 802.6i transparent bridging for SMDS supports 802.3, 802.5, and FDDI frame formats. The router can accept frames with or without frame check sequence (FCS). Fast-switched transparent bridging is the default and is not configurable. If a packet cannot be fast switched, it is process switched.
An example configuration is provided in the "Fast-Switched Transparent Bridging over SMDS Example" section. For more information on SMDS, refer to the "Configuring SMDS" chapter in the Cisco IOS Wide-Area Networking Configuration Guide.
Configuring Transparent Bridging over X.25
The transparent bridging software supports bridging of packets in X.25 frames. This ability is useful for such tasks as sending 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 sent across X.25 media. You specify the IP-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, use the following command in interface configuration mode:
Router(config-if)# x25 map bridge x.121-address broadcast [options-keywords]
Specifies IP-to-X.121 mapping for bridging over X.25.
For more information about configuring X.25, refer to the "Configuring X.25 and LAPB" chapter in the Cisco IOS Wide-Area Networking Configuration Guide.
Configuring Concurrent Routing and Bridging
You can configure the Cisco IOS software to route a given protocol among one group of interfaces and concurrently bridge that protocol among a separate group of interfaces, all within one router. The given protocol is not switched between the two groups. Rather, routed traffic is confined to the routed interfaces and bridged traffic is confined to the bridged interfaces. A protocol may be either routed or bridged on a given interface, but not both.
The concurrent routing and bridging capability is, by default, disabled. While concurrent routing and bridging is disabled, the Cisco IOS software absorbs and discards bridgeable packets in protocols that are configured for routing on any interface in the router.
When concurrent routing and bridging is first enabled in the presence of existing bridge groups, it will generate a bridge route configuration command for any protocol for which any interface in the bridge group is configured for routing. This is a precaution that applies only when concurrent routing and bridging is not already enabled, bridge groups exist, and the bridge crb command is encountered.
To enable concurrent routing and bridging in the Cisco IOS software, use the following command in global configuration mode:
Information about which protocols are routed and which are bridged is stored in a table, which can be displayed with the show interfaces crb privileged EXEC command.
When concurrent routing and bridging has been enabled, you must configure an explicit bridge route command for any protocol that is to be routed on the interfaces in a bridge group in addition to any required protocol-specific interface configuration.
To configure specific protocols to be routed in a bridge group, use the following command in interface configuration mode:
Router(config-if)# bridge bridge-group route protocol
Enables the routing of a specified protocol in a specified bridge group.
Configuring Integrated Routing and Bridging
Perform one or more of the following tasks to configure integrated routing and bridging on your router:
•
•
•
•
Assigning a Bridge Group Number and Defining the Spanning Tree Protocol
Prior to configuring the router for integrated routing and bridging, you must enable bridging by setting up a bridge group number and specifying a Spanning Tree Protocol. You can choose either the IEEE 802.1D Spanning Tree Protocol or the earlier Digital protocol upon which this IEEE standard is based.
To assign a bridge group number and define a Spanning Tree Protocol, use the following command in global configuration mode:
Router(config)# bridge bridge-group protocol {ieee | dec | vlan-bridge}
Assigns a bridge group number and defines a Spanning Tree Protocol.
The IEEE 802.1D Spanning Tree Protocol is the preferred way of running the bridge. Use the Digital Spanning Tree Protocol only for backward compatibility.
Configuring Interfaces
To configure a router interface in the Cisco IOS software, use the following commands beginning in global configuration mode:
Enabling Integrated Routing and Bridging
After you have set up the interfaces in the router, you can enable integrated routing and bridging.
To enable integrated routing and bridging in the Cisco IOS software, use the following command in global configuration mode:
Use the show interfaces irb privileged EXEC command to display the protocols that a given bridged interface can route to the other routed interface when the packet is routable, and to display the protocols that a given bridged interface bridges.
Configuring the Bridge-Group Virtual Interface
The bridge-group virtual interface resides in the router. It acts like a normal routed interface that does not support bridging, but represents the entire corresponding bridge group to routed interfaces within the router. The bridge-group virtual interface is assigned the number of the bridge group that it represents. The bridge-group virtual interface number is the link between the bridge-group virtual interface and its bridge group. Because the bridge-group virtual interface is a virtual routed interface, it has all the network layer attributes, such as a network address and the ability to perform filtering. Only one bridge-group virtual interface is supported for each bridge group.
When you enable routing for a given protocol on the bridge-group virtual interface, packets coming from a routed interface but destined for a host in a bridged domain are routed to the bridge-group virtual interface, and are forwarded to the corresponding bridged interface. All traffic routed to the bridge-group virtual interface is forwarded to the corresponding bridge group as bridged traffic. All routable traffic received on a bridged interface is routed to other routed interfaces as if it is coming directly from the bridge-group virtual interface.
To create a bridge-group virtual interface, use the following command in interface configuration mode:
Router(config-if)# interface bvi bridge-group
Enables a bridge-group virtual interface.
When you intend to bridge and route a given protocol in the same bridge group, you must configure the network-layer attributes of the protocol on the bridge-group virtual interface. Do not configure protocol attributes on the bridged interfaces. No bridging attributes can be configured on the bridge-group virtual interface.
Although it is generally the case that all bridged segments belonging to a bridge group are represented as a single segment or network to the routing protocol, there are situations where several individual networks coexist within the same bridged segment. To make it possible for the routed domain to learn about the other networks behind the bridge-group virtual interface, configure a secondary address on the bridge-group virtual interface to add the corresponding network to the routing process.
Configuring Protocols for Routing or Bridging
When integrated routing and bridging is enabled, the default route/bridge behavior in a bridge group is to bridge all packets.
You could then explicitly configure the bridge group to route a particular protocol, so that routable packets of this protocol are routed, while nonroutable packets of this protocol or packets for protocols for which the bridge group is not explicitly configured to route will be bridged.
You could also explicitly configure the bridge group so that it does not bridge a particular protocol, so that routable packets of this protocol are routed when the bridge is explicitly configured to route this protocol, and nonroutable packets are dropped because bridging is disabled for this protocol.
Note
To configure specific protocols to be routed or bridged in a bridge group, use one or more of the following commands in global configuration mode, as needed:
Note
For example, to bridge AppleTalk, bridge and route IPX, and route IP in the same bridge group, you would do the following:
•
•
•
Note
Configuring Transparent Bridging Options
You can configure one or more transparent bridging options. To configure transparent bridging options, perform one or more of the tasks in the following sections:
•
•
•
•
Disabling IP Routing
If you want to bridge IP, you must disable IP routing because IP routing is enabled by default on the Cisco IOS software. You can enable IP routing when you decide to route IP packets. To disable or enable IP routing, use one of the following commands in global configuration mode, as needed:
Router(config)# no ip routing
Disables IP routing.
Router(config)# ip routing
Enables 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.
Enabling Autonomous Bridging
Normally, bridging takes place on the processor card at the interrupt level. When autonomous bridging is enabled, bridging takes place entirely on the ciscoBus2 controller, significantly improving performance. Autonomous bridging is a high-speed switching feature that allows bridged traffic to be forwarded and flooded on the ciscoBus2 controller between resident interfaces. If you are using the ciscoBus2 controller, you can maximize performance by enabling autonomous bridging on the following ciscoBus2 interfaces:
•
•
•
Although performance improvements will be seen most in the resident interfaces, the autonomous bridging feature can also be used in bridge groups that include interfaces that are not on the ciscoBus2 controller. These interfaces include the CTR, FCI with encapsulation bridging, and HSSI with encapsulation other than HDLC, 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 ciscoBus2 controller and some that are not, the ciscoBus2 controller forwards only packets between resident interfaces. Forwarding between nonresident and resident interfaces is done in either the fast or process paths. Flooding between resident interfaces is done by the ciscoBus2 controller. Flooding between nonresident interfaces is done conventionally. If a packet is forwarded from a nonresident to a resident interface, the packet is conventionally forwarded. If packets are flooded from a nonresident interface to a resident interface, the packet is autonomously flooded.
To en
