Cisco Knowledge Suite Cisco SystemsCisco Press

Cutting Edge
Core Reference
Guided Learning
Networking Architecture
Internet Protocols (IP)
Network Protocols
Transport and Application Protocols
Desktop Protocols
Security and Troubleshooting
Network Resources and Management
Integrated Services

Configuring Transparent Bridging and Integrated Routing and Bridging


< Back Contents Next >

Configuring Transparent Bridging and Integrated Routing and Bridging



Transparent Bridging



Integrated Routing and Bridging




Save to MyCKS

Advanced Cisco Router Configuration

From: Advanced Cisco Router Configuration
Author: Systems Cisco; Laura Chappell
Publisher: Cisco Press (53)
More Information

17. Configuring Transparent Bridging and Integrated Routing and Bridging

This chapter describes two router configuration options available to handle nonroutable traffic: transparent bridging and integrated routing and bridging (IRB). Upon completion of this chapter, you will be able to identify the need for transparent bridging and IRB, know the basic configuration steps, and be able to verify proper operation of these bridged configurations.

Transparent Bridging

Routers configured as transparent bridges forward packets based on the MAC address contained in the destination address field of the MAC-layer header. These types of bridges maintain a forwarding database that is built dynamically based on traffic seen on the network. Transparent bridges do not require that end devices support any additional bridging software. The intelligence is in the bridge unit.

Transparent Bridging Operation

Transparent bridging is predominantly used in Ethernet environments. A transparent bridge has the following major functions:

  • Learning—A transparent bridge learns which stations can be reached on each of its ports (or interfaces) by monitoring the source MAC addresses of all incoming frames.

  • Forwarding—A transparent bridge forwards frames from an inbound interface to the correct outbound interface to reach the destination.

  • Filtering—A bridge will not forward a frame if the source and destination addresses are in the bridging table and are located on the same segment.

  • Avoiding loops—The spanning-tree protocolsolves the problems associated with bridge loops by allowing redundant paths (loops), but ensuring a loop-free topology through a bridge-to-bridge protocol.

Each of these is explored below.


When a transparent bridge is first powered up, it knows nothing of the network topology. It learns which stations can be reached on each of its ports (or interfaces) by monitoring the source MAC addresses of all incoming frames. For this reason, a transparent bridge is sometimes also called a learning bridge.

A transparent bridge maintains a database of learned MAC addresses and their associated interfaces in a table. These table entries are cached. The bridge updates the table regularly when a station sends a frame, and flushes entries of stations not heard from within a specified (implementation-dependent) time period.

In Figure17-1, for example, the bridge has learned about four devices based on their initial startup communication. The bridge associates each of these devices with the interface closest to the device.

During the startup phase, when station .1111 sends to .2222, the bridge does not yet know where .2222 is located. So, in order to provide connectivity, it sends or floods the frame out to all connected interfaces except the interface on which the packet was received. Then, when it sees .2222 reply, the bridge adds .2222 to its table. Because it already knew the port location of .1111, the bridge has no need to flood again.


If the bridging table contains an association between the destination address and any of the bridge's interfaces (aside from the one on which the frame was received), a transparent bridge forwards frames from an inbound interface to the correct outbound interface to reach the destination.

Figure 17-1. The source MAC address is associated with the interface.

A transparent bridge forwards out all interfaces (except the one from which the frame was received), all broadcast and multicast frames, and frames from unknown stations. (A station is unknown if it is not in the bridging table.) This action is also known as flooding.

How does a bridge learn addresses and forward traffic? If the source and destination address are located on different bridged segments, and if neither address is known to the bridge, the bridge does the following:

  1. Notes the source address and updates its table.

  2. Forwards the frame out to all interfaces (except the interface on which the frame was received).

  3. If a reply comes back, the bridge examines the source address (which was the original target destination) and adds the entry to its table.

  4. The bridge forwards subsequent communication between the devices.

Once again, refer to Figure17-1. If a packet destined for .4444 was sent from .1111, the bridge would forward it based on its forwarding table.


A bridge will not forward a frame if the source and destination addresses are in the bridging table and are located on the same segment. This behavior is known as filtering.

A bridge learns addresses and filters traffic as follows (assume that the source and destination stations are located on the same segment, and only the destination address is unknown), as in the following:

  1. The source sends a frame to the destination.

  2. The bridge sees the frame and floods the frame out to all interfaces (except the interface on which the frame was received).

  3. When the reply comes back, the bridge reads the source address and updates its table.

  4. The bridge discards, or filters, subsequent frames between the devices.

The effect of this filtering is that it conserves bandwidth. In Figure17-1, for example, packets from .1111 that are destined to .2222 will not be forwarded.

Avoiding Bridging Loops with the Spanning-Tree Protocol

A bridging loop occurs when there is more than one path between any two bridged LANs in the network. A topology with loops can be useful as well as potentially harmful. Without loops, the topology has no redundancy. Without redundancy, if a bridge or LAN segment fails, connectivity is lost.

Without a bridge-to-bridge protocol, the transparent bridging algorithm fails when there are multiple paths of bridges and LANs between any two stations in the network. Recall that a bridge must flood all broadcast frames, by default. In a network containing a bridging loop, as shown in Figure17-2, a single broadcast frame can cause a broadcast storm—an undesirable network event in which many broadcasts are sent simultaneously across all network segments, consuming all available network bandwidth and resources and ultimately leading to a disruption in network service to users.

Loops occur in routed networks but are not as harmful. In routing, a packet is addressed to a specific router (and the MAC layer) and the router only forwards a packet out a single interface. As a result, routers do not procreate packets like bridges do. There also is generally a Time To Live (TTL) field in the routed packet so the router will eventually discard the looping packet. If such a field exists in the bridged packet, bridges do not see it or decrement it so a packet can loop indefinitely.

Figure 17-2. Bridging loops can consume all available network resources.

Figure17-2 shows how a broadcast frame can disrupt network service when the network has a loop:

  1. Station X sends a broadcast frame looking for station Y.

  2. Each bridge (by default) must forward the broadcast frame onto all connected segments. Now there are two broadcast frames on segment 2.

  3. Both bridges see the broadcast frames again, and again forward the frames.

  4. A broadcast storm ensues.

The spanning-tree protocol solves the problems associated with bridge loops by allowing redundant paths (loops), but ensuring a loop-free topology through a bridge-to-bridge protocol. The spanning-tree protocol creates this loop-free topology by blocking one path where duplicate paths exist between network segments and automatically activating backup paths if a link segment or bridge fails.

The following two spanning-tree protocol versions exist for transparent bridging:

  • DEC—Digital Equipment Corporation developed the first spanning tree protocol that was the basis for the IEEE 802.1D specification.

  • IEEE 802.1D—The IEEE (Institute of Electrical and Electronic Engineers) approved spanning tree protocol to resolve bridging loops through bridge-to-bridge communications and path resolution.

Note that the DEC and IEEE 802.1D spanning tree versions differ enough that they cannot both run on the same network.

Cisco supports both protocol types. Although Digital's implementation served as the foundation for the IEEE implementation, the two are not compatible.

The basic operation of the spanning-tree algorithm is as follows:

  1. The protocol elects a root bridge based on a unique bridge identifier. The bridge with the lowest identifier becomes the root. The first two bytes of the bridge identifier contain a user-configurable priority field, and the last six bytes contain one of the bridge's MAC addresses. The network administrator can configure the priority field to determine which bridge becomes the root (preferable) or allow the protocol to automatically determine it. If you configure a bridge to be root, select a bridge that is in the middle of the traffic flow, as defined by a protocol/network analyzer.

  2. Each bridge selects the lowest-cost path to the root bridge based on a metric assigned to each link along the path to the root bridge.

  3. Interfaces with alternate paths will block traffic to prevent loops. In Figure17-3, bridge A's E1 interface is blocked to prevent looping.

    Figure 17-3.
    The spanning-tree algorithm disables interfaces.

In Figure17-3, two bridges are in parallel, causing a loop. The spanning-tree algorithm will disable one of the bridge's interfaces to prevent the logical loop from affecting traffic. If something happened to bridge B, bridge A would act as a backup and would take over support of the network segment.

Transparent Bridging Configuration Tasks

To configure transparent bridging, perform the following tasks in global configuration mode:

  • Select a spanning-tree protocol in global configuration mode.

  • Assign a priority to the bridge (optional) in global configuration mode.

  • Assign the interface to a spanning-tree group in interface configuration mode.

  • Assign a cost to the outgoing interface (optional) in interface configuration mode.

In this next section, you learn the available bridge configuration commands for each of the steps mentioned.

Step 1: Select a Spanning-Tree Protocol

Using the bridge protocol command, select either the DEC or IEEE spanning-tree implementation. Note that all routers must use the same implementation. The two implementations are not compatible, so the protocol must be set the same for all bridges that are to be part of the same spanning tree.

The bridge protocol command is run in global configuration mode and defines a specific spanning-tree algorithm for a bridge group:

router(config)#bridge bridge-group protocol{ieee | dec}

bridge protocol Command



Identifies a particular set of bridged interfaces, a decimal number from 1 to 63. Sometimes referred to as a bridge number.


Either DEC or IEEE. Only DEC and IEEE spanning-tree protocols are used for transparent bridging.

Step 2: Assign a Priority to the Bridge (Optional)

To control which bridge becomes the root bridge, use the bridge priority command to set the priority on one bridge to be lower than all of the others. If you want to control which bridge takes over in case the root bridge fails, configure another bridge with the second-lowest priority field. Leave all other bridge priorities at their default value of 128 (for DEC), or if using IEEE, the value is 32768.

The bridge-group command assigns an interface to a particular bridge group:

router(config-if)#bridge-group bridge-group number

where bridge-group number is a decimal number from 1 to 63.

Some things to note about bridge groups are as follows:

  • Interfaces not participating in a bridge group will not forward bridged traffic.

  • There is no communication between bridge groups.

  • An interface can be part of only one bridge group.

Step 3: Assign the Interface to a Spanning-Tree Group

Determine which interfaces you want to belong to the same group, and use the bridge-group command to assign those interfaces to that group. These interfaces will all be a part of the same spanning tree. Interfaces not participating in a bridge group will not forward bridged traffic.

The bridge priority command assigns a specific priority to the bridge, assisting in the spanning-tree root definition. The lower the priority, the more likely the bridge will be selected as the root:

router(config)#bridge bridge-group number prioritynumber

bridge priority Command


bridge-group number

A number from 1 to 63.


Assigns the priority level, value is 0 to 255 (DEC), or 0 to 64000 (IEEE). The default value for DEC (Digital) is 128, and 32768 for IEEE.

Step 4: Assign a Cost to the Outgoing Interface (Optional)

To control the path cost assigned to an interface, use the bridge-group path-cost command. Otherwise, the default values are used in calculating the best-cost path to reach the root bridge. The default is 1000Mbps divided by the data rate of the attached LAN. As a result, links supporting higher data rates have lower (preferred) costs.

The bridge-group path-cost command is used to assign a path cost to a particular interface. The cost is used in the spanning-tree algorithm to determine the best path to another area of the network. The default is 1000Mbps divided by the data rate of the attached LAN. Once the costs of all possible paths is determined, the spanning tree bridges consider the lowest-cost paths as the preferred path. Higher-cost paths are considered backup paths and are used should the preferred path become unavailable.

router(config-if)#bridge-group bridge-group path-cost cost

bridge-group path-cost Command



A number from 1 to 63.


A number from 0 to 65535. Higher values indicate higher costs. This same range applies regardless of which spanning-tree protocol is configured.

Transparent Bridging Example

Figure17-4 depicts a transparent bridging example. In this example, Cisco A becomes the root bridge because it has a lower priority.

Figure 17-4. Transparent bridging example.

The default path cost for Ethernet is 100. Because Cisco B has a lower path cost than the default configured on Ethernet 0 and on Ethernet 1, the blocked interface will occur on the right side of the network, eliminating the loop.

On Cisco B, the priority has been changed to 100 from the default of 128. The path costs for both Ethernet interfaces have been changed to 10 from the default of 100. To the devices connected to the network on which Cisco D and Cisco E reside, the path through Cisco D and Cisco B to reach the root Cisco A is clearly lower and preferred. Therefore, Cisco E will block frames originating on segment 1 and Cisco D will forward them.

Verifying Transparent Bridging

The show bridge command, used in Figure17-5, displays the following information.

Figure 17-5. Use the show bridge command to verify bridge operation.



Total of 300 station blocks

Total number of forwarding database elements in the system. 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 to fewer than 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.

295 free

Number in the free list of forwarding database elements in the system. The total number of forwarding elements is expanded dynamically, as needed.


Bridging group to which the address belongs.


Hash key/relative position in the keyed list.


Canonical (Ethernet ordered) MAC address.


Action to be taken when that address is looked up. Choices are to discard or forward the datagram.


Interface, if any, on which that address was seen.


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.

RX/TX count

Number of frames received from/transmitted on that address.

Verifying Spanning Tree Operation

Figure17-6 shows the output of the show span command.

Figure 17-6. Use the show span command to verify spanning tree operation.

The first line of output indicates which type of spanning-tree protocol (IEEE or DEC) the bridge group is executing. The next three lines show the current operating parameters of the spanning tree.

The remaining lines display related information that is useful when examining the spanning-tree parameters, as follows:



Port 9

Port number associated with the interface.


Interfaces on which spanning tree has been configured.

bridge group 1

Bridge group to which the interface has been assigned.


State of the interface. Other possible values include down, listening, learning, and blocking.

Path cost 100

Path cost associated with this interface.

priority 0

Port priority.


< Back Contents Next >

Save to MyCKS


Breaking News

One of the primary architects of OpenCable, Michael Adams, explains the key concepts of this initiative in his book OpenCable Architecture.

Expert Advice

Ralph Droms, Ph.D., author of The DHCP Handbook and chair of the IETF Dynamic Host Configuration Working Group, guides you to his top picks for reliable DHCP-related information.

Just Published

Residential Broadband, Second Edition
by George Abe

Introduces the topics surrounding high-speed networks to the home. It is written for anyone seeking a broad-based familiarity with the issues of residential broadband (RBB) including product developers, engineers, network designers, business people, professionals in legal and regulatory positions, and industry analysts.


From the Brains at InformIT


Contact Us


Copyright, Terms & Conditions


Privacy Policy


© Copyright 2000 InformIT. All rights reserved.