Bridging and IBM Networking Configuration Guide - Configuring Transparent Bridging

Table Of Contents

Configuring Transparent Bridging

Transparent and SRT Bridging Configuration Task List

Configure Transparent Bridging and SRT Bridging

Assign a Bridge Group Number and Define the Spanning-Tree Protocol

Assign Each Network Interface to a Bridge Group

Choose the OUI for Ethernet Type II Frames

Configure Transparently Bridged Virtual LANs (VLANs)

Configure Routing between VLANs

Configure Transparent Bridging over WANs

Configure Fast-Switched Transparent Bridging over ATM

Configure Transparent Bridging over DDR

Define the Protocols to Bridge

Specify the Bridging Protocol

Determine Access for Bridging

Configure an Interface for Bridging

Configure Transparent Bridging over Frame Relay

Fast-Switched Transparent Bridging

Bridging in a Frame Relay Network with No Multicasts

Bridging in a Frame Relay Network with Multicasts

Configure Transparent Bridging over Multiprotocol LAPB

Configure Transparent Bridging over SMDS

Configure Transparent Bridging over X.25

Configure Concurrent Routing and Bridging

Configure Integrated Routing and Bridging

Assign a Bridge Group Number and Define the Spanning-Tree Protocol

Configure Interfaces

Enable Integrated Routing and Bridging

Configure the Bridge-Group Virtual Interface

Configure Protocols for Routing or Bridging

Configure Transparent Bridging Options

Disable IP Routing

Enable Autonomous Bridging

Configure LAT Compression

Establish Multiple Spanning-Tree Domains

Prevent the Forwarding of Dynamically Determined Stations

Forward Multicast Addresses

Configure Bridge Table Aging Time

Filter Transparently Bridged Packets

Set Filters at the MAC layer

Filter by Specific MAC Address

Filter by Vendor Code

Filter by Protocol Type

Define and Apply Extended Access Lists

Filter LAT Service Announcements

Enable LAT Group Code Service Filtering

Specify Deny or Permit Conditions for LAT Group Codes on Input

Specify Deny or Permit Conditions for LAT Group Codes on Output

Adjust Spanning-Tree Parameters

Set the Bridge Priority

Set an Interface Priority

Assign Path Costs

Adjust Bridge Protocol Data Unit (BPDU) Intervals

Adjust the Interval between Hello BPDUs

Define the Forward Delay Interval

Define the Maximum Idle Interval

Disable the Spanning Tree on an Interface

Tune the Transparently Bridged Network

Configure Circuit Groups

Configure Constrained Multicast Flooding

Monitor and Maintain the Transparent Bridge Network

Transparent and SRT Bridging Configuration Examples

Basic Bridging Example

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

Ethernet Bridging Example

SRT 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

Configuring Transparent Bridging

Our 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 commands mentioned in this chapter, refer to the "Transparent Bridging Commands" chapter in the Bridging and IBM Networking Command Reference.

Transparent and SRT Bridging Configuration Task List

Perform one or more of the tasks in the following sections to configure transparent bridging or SRT bridging on your router:

•Configure Transparent Bridging and SRT Bridging

•Configure Transparently Bridged Virtual LANs (VLANs)

•Configure Routing between VLANs

•Configure Transparent Bridging over WANs

•Configure Concurrent Routing and Bridging

•Configure Integrated Routing and Bridging

•Configure Transparent Bridging Options

•Filter Transparently Bridged Packets

•Adjust Spanning-Tree Parameters

•Tune the Transparently Bridged Network

•Monitor and Maintain the Transparent Bridge Network

See the "Transparent and SRT Bridging Configuration Examples" section for configuration examples.

Configure Transparent Bridging and SRT Bridging

To configure transparent and SRT bridging, you must perform the tasks in the following sections:

•Assign a Bridge Group Number and Define the Spanning-Tree Protocol

•Assign Each Network Interface to a Bridge Group

•Choose the OUI for Ethernet Type II Frames

Assign a Bridge Group Number and Define 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 or the earlier Digital 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 Digital.

bridge bridge-group protocol {ieee | dec}

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.

Assign 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 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 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:

•To bridge all nonrouted traffic among the network interfaces making up the bridge group. If the packet's destination address is known in the bridge table, it is forwarded on a single interface in the bridge group. If the packet's destination is unknown in the bridge table, it is flooded on all forwarding interfaces in the bridge group. The bridge places source addresses in the bridge table as it learns them during the process of bridging.

•To participate in the spanning-tree algorithm by receiving, and in some cases transmitting, BPDUs on the LANs to which they are attached. A separate spanning process runs for each configured bridge group. Each bridge group participates in a separate spanning tree. A bridge group establishes a spanning tree based on the BPDUs it receives on only its member interfaces.

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 performing the following task in interface configuration mode:

Task

Command

Assign a network interface to a bridge group.

bridge-group bridge-group

Choose the OUI for Ethernet Type II Frames

For 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]

Configure Transparently Bridged Virtual LANs (VLANs)

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 demultiplex different streams of bridged traffic. Our transparently bridged VLAN feature 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 , 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 section "Transparently Bridged VLANs Configuration Example" later in this chapter for an example configuration of the topology shown in .

Note   The 802.10 encapsulation used to "color" transparently bridged packets on subinterfaces might increase the size of a packet so that it exceeds the MTU size of the LAN from which the packet originated. To avoid MTU violations on the shared network, the originating LANs must either have a smaller native MTU than the shared network (as is the case from Ethernet to FDDI), or the MTU on all packet sources on the originating LAN must be configured to be at least 16 bytes less than the MTU of the shared network.

Figure 32 Transparently Bridged VLANs on an FDDI Backbone

To configure a VLAN on a transparently bridged network, perform the following tasks, beginning in interface configuration mode:

Task

Command

Specify a subinterface.

interface type slot/port.subinterface-number¹

Specify the IEEE 802.10 Security data exchange security association identifier. (In other words, specify the "color.")

encapsulation sde said

Associate the subinterface with an existing bridge group.

bridge-group bridge-group

¹This command is documented in the "Interface Commands" chapter of the Configuration Fundamentals Command Reference.

Note   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   The current implementation of SDE encapsulation is not recommended for serial or Ethernet media.

Configure Routing between VLANs

Virtual networking provides a mechanism whereby you can define logical topologies to overlay a physical switched infrastructure, and so establish autonomous VLAN domains. By definition, VLANs provide traffic separation and logical network partitioning. To communicate between VLANs a routing function is required.

Note   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 transmits 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 non-routable traffic types.

In , 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 transmitting VLAN encapsulated traffic to and from other switched VLAN domains or simply transmitting traffic in native (non-VLAN) format.

Figure 33 Inter-VLAN Connectivity between Multiple Switching Platforms

illustrates the following scenarios:

•Clients on VLAN 300 want to establish sessions with a server attached to a port in a different VLAN (600). In this scenario, packets originating on LAN interface 3 of the Catalyst 1200B switch are tagged with an 802.10 header with a security association identifier of 300 as they are forwarded onto the FDDI ring. Router A can accept these packets because it is configured to route VLAN 300, classify and make a layer 3 forwarding decision based on the destination network address and the route out (in this case Fast Ethernet 3/1), and adding the ISL VLAN header (color 200) appropriate to the destination subnet as the traffic is switched.

•There is a network requirement to bridge two VLANs together through the system rather than selectively route certain protocols. In this scenario the two VLAN IDs are placed in the same bridge group. Note that they form a single broadcast domain and spanning tree, effectively forming a single VLAN.

See the section "Routing Between VLANs Configuration Example" later in this chapter for an example configuration of the topology shown in .

To configure routing between VLANs, perform the following tasks, beginning in interface configuration mode:

Task

Command

Specify a subinterface.

interface type slot/port.subinterface-number¹

Specify the encapsulation type (either ISL or SDE) and the VLAN domain.

encapsulation {sde | isl} domain

Associate the subinterface with the VLAN.

bridge-group bridge-group

¹This command is documented in the "Interface Commands" chapter of the Configuration Fundamentals Command Reference.

Configure Transparent Bridging over WANs

You can configure transparent bridging over a variety of networks, as described in the following sections:

•Configure Fast-Switched Transparent Bridging over ATM

•Configure Transparent Bridging over DDR

•Configure Transparent Bridging over Frame Relay

•Configure Transparent Bridging over Multiprotocol LAPB

•Configure Transparent Bridging over SMDS

•Configure Transparent Bridging over X.25

Configure Fast-Switched Transparent Bridging over ATM

Fast-switched transparent bridging over 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 section "Fast-Switched Transparent Bridging over ATM Example (Cisco 7000)" for an example configuration of 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).

For more information on configuring ATM, refer to the "Configuring ATM" chapter in the Wide-Area Networking Configuration Guide.

Configure Transparent Bridging over DDR

The Cisco IOS software supports transparent bridging over 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:

•Define the Protocols to Bridge

•Specify the Bridging Protocol

•Determine Access for Bridging

•Configure an Interface for Bridging

For an example of configuring transparent bridging over DDR, see the section "Transparent Bridging over DDR Examples" section.

Define 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, complete the following task in global configuration mode:

Task

Command

Disable IP routing.

no ip routing

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 chapter in either the Network Protocols Configuration Guide, Part 1, the Network Protocols Configuration Guide, Part 2, or the Network Protocols Configuration Guide, Part 3.

Specify 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, complete the following task in global configuration mode:

Task

Command

Define the type of Spanning-Tree Protocol and identify a bridge group.

bridge bridge-group protocol {ieee | dec}

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.

Determine 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, complete the following task in global configuration mode:

Task

Command

Define a dialer list that permits all transparent bridge packets.

dialer-list dialer-group protocol bridge permit

To control access by Ethernet type codes, complete the following tasks in global configuration mode:

Task

Command

Permit packets according to Ethernet type codes (access list numbers must be in the range 200-299).

access-list access-list-number {permit | deny} type-code [mask]

Define a dialer list for the specified access list.

dialer-list dialer-group protocol bridge list access-list-number

For a table of some common Ethernet types codes, see the "Ethernet Types Codes" appendix in the Bridging and IBM Networking Command Reference.

Configure an Interface for Bridging

You can configure serial interfaces or ISDN interfaces for DDR bridging. To configure an interface for DDR bridging, complete the following tasks, starting in global configuration mode:

Task

Command

Specify the serial or ISDN interface and enter interface configuration mode.

interface type number¹

Configure the dial string to call.
or
Configure a dialer bridge map.

dialer string dial-string

dialer map bridge [name hostname] [broadcast] dial-string[:isdn-subaddress]

Assign the specified interface to a bridge group.

bridge-group bridge-group

¹This command is documented in the "Interface Commands" chapter in the Configuration Fundamentals Command Reference.

Configure 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 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.

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.

SVCs are not supported for transparent bridging in this release. All the PVCs configured on a subinterfaces 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 transmission across a Frame Relay network. You specify IP-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 "Frame Relay Transparent Bridging Examples" at the end of this chapter. Frame Relay is discussed in more detail in the "Configuring Frame Relay" chapter in the 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 section "Frame Relay Transparent Bridging Examples" at the end of the chapter for use as a configuration guide. Frame Relay is discussed in more detail in the "Configuring Frame Relay" chapter in the Wide-Area Networking Configuration Guide.

Configure Transparent Bridging over Multiprotocol LAPB

Our software implements transparent bridging over multiprotocol LAPB encapsulation on serial interfaces. To configure transparent bridging over multiprotocol LAPB, perform the following tasks, beginning in global configuration mode:

Task

Command

Specify the serial interface.

interface serial number¹

Specify no IP address to the interface.

no ip address²

Configure multiprotocol LAPB encapsulation.

encapsulation lapb multi³

Assign the interface to a bridge group.

bridge-group bridge-group

Specify the type of Spanning-Tree Protocol.

bridge bridge-group protocol {ieee | dec}

¹This command is documented in the "Interface Commands" chapter of the Configuration Fundamentals Command Reference.

²This command is documented in the "IP Commands" and the "IP Routing Protocols Commands" chapters of the Network Protocols Command Reference, Part 1.

³This command is documented in the "X.25 and LAPB Commands" chapter of the Wide-Area Networking Command Reference.

Note   Transparent bridging over multiprotocol LAPB requires use of the encapsulation lapb multi command. You cannot use the encapsulation lapb protocol command with a bridge keyword to configure this feature.

For an example of configuring transparent bridging over multiprotocol LAPB, see the section "Transparent Bridging over Multiprotocol LAPB Example" later in this chapter.

Configure 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, perform the following tasks, beginning in interface configuration mode:

Task

Command

Specify the serial interface.

interface serial number¹

Configure SMDS encapsulation on the serial interface.

encapsulation smds²

Associate the interface with a bridge group.

bridge-group bridge-group

Enable transparent bridging of packets across an SMDS network.

smds multicast bridge smds-address 2

¹This command is documented in the "Interface Commands" chapter in the Configuration Fundamentals Configuration Guide.

²This command is documented in the "SMDS Commands" chapter in the Wide-Area Networking Command Reference.

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 section "Fast-Switched Transparent Bridging over SMDS Example" later in this chapter. For more information on SMDS, refer to the "Configuring SMDS" chapter in the Wide-Area Networking Configuration Guide.

Configure 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 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 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, perform the following task in interface configuration mode:

Task

Command

Specify IP-to-X.121 mapping.

x25 map bridge x.121-address broadcast [options-keywords]

For more information about configuring X.25, refer to the "Configuring X.25 and LAPB" chapter in the Wide-Area Networking Configuration Guide.

Configure 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, perform the following task in global configuration mode:

Task

Command

Enable concurrent routing and bridging.

bridge crb

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, perform the following task in interface configuration mode:

Task

Command

Specify a protocol to be routed on a bridge group.

bridge bridge-group route protocol

Configure Integrated Routing and Bridging

Perform one or more of the following tasks to configure integrated routing and bridging on your router:

•Assign a Bridge Group Number and Define the Spanning-Tree Protocol

•Configure Interfaces

•Enable Integrated Routing and Bridging

•Configure the Bridge-Group Virtual Interface

•Configure Protocols for Routing or Bridging

Assign a Bridge Group Number and Define 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, 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 Digital.

bridge bridge-group protocol {ieee | dec}

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.

Configure Interfaces

To configure a router interface in the Cisco IOS software, perform the following tasks, starting in global configuration mode:

Task

Command

Specify the interface and enter interface configuration mode.

interface type number¹

Assign bridge-groups to appropriate interfaces.

bridge-group bridge-group

¹This command is documented in the "Interface Commands" chapter in the Configuration Fundamentals Command Reference.

Enable 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, perform the following task in global configuration mode:

Task

Command

Enable integrated routing and bridging.

bridge irb

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.

Configure 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, perform the following task in interface configuration mode:

Task

Command

Enable a bridge-group virtual interface.

interface bvi bridge-group

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.

Configure 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 non-routable 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 non-routable packets are dropped because bridging is disabled for this protocol.

Note   Packets of non-routable protocols such as LAT are only bridged. You cannot disable bridging for the non-routable traffic.

To configure specific protocols to be routed or bridged in a bridge group, perform one or more of the following tasks in global configuration mode:

Task

Command

Specify a protocol to be routed in a bridge group.

bridge bridge-group route protocol

Specify that a protocol is not to be routed in a bridge group.

no bridge bridge-group route protocol

Specify that a protocol is to be bridged in the bridge group.

bridge bridge-group bridge protocol

Specify that a protocol is not to be bridged in the bridge group.

no bridge bridge-group bridge protocol

For example, to bridge AppleTalk, bridge and route IPX, and route IP in the same bridge group, you would do the following:

•Bridge AppleTalk: Because integrated routing and bridging bridges everything by default, no configuration is required to bridge AppleTalk.

•Bridge and route IPX: After using the bridge irb command to enable integrated routing and bridging, and the interface bvi command to create the bridge-group virtual interface for the bridge group, you would use the bridge route command to both bridge and route IPX (bridging is already enabled by default; the bridge route command enables routing).

•Route IP: Use the bridge route command to enable routing, and then use the no bridge bridge command to disable bridging.

Note   When integrated routing and bridging is not enabled, routing a given protocol means that protocol is not bridged, and bridging a protocol means that protocol is not routed. When integrated routing and bridging is enabled, the disjunct relationship between routing and bridging is broken down, and a given protocol can be switched between routed and bridged interfaces on a selective, independent basis.

Configure 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:

•Disable IP Routing

•Enable Autonomous Bridging

•Configure LAT Compression

•Establish Multiple Spanning-Tree Domains

•Prevent the Forwarding of Dynamically Determined Stations

•Forward Multicast Addresses

•Configure Bridge Table Aging Time

Disable 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, 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.

Enable 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:

•MEC

•FCIT transparent

•HSSI HDLC

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 enable autonomous bridging on a per-interface basis, perform the following task in interface configuration mode:

Task

Command

Enable autonomous bridging (if using the ciscoBus2 controller).

bridge-group bridge-group cbus-bridging

Note   You can filter by MAC-level address on an interface only when autonomous bridging is enabled on that interface. If any filters or priority queuing is configured, autonomous bridging is automatically disabled.

Configure LAT Compression

The 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 by the Cisco IOS software 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 bridge-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.

Establish Multiple Spanning-Tree Domains

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 IEEE as the Spanning-Tree Protocol. A domain establishes an external identification of the BPDUs sent from a bridge group. The purpose of this identification is as follows:

•Bridge groups defined within the domain can recognize that BPDU as belonging to them.

•Two bridged subnetworks in different domains that are sharing a common connection can use the domain identifier to identify and then ignore the BPDUs that belong to another domain. Each bridged subnetwork establishes its own spanning tree based on the BPDUs that it receives. The BPDUs it receives must contain the domain number to which the bridged subnetwork belongs. Bridged traffic is not domain identified.

Note   Domains do not constrain the propagation of bridged traffic. A bridge bridges nonrouted traffic received on its interfaces regardless of domain.

You can place any number of routers or bridges within the domain. The devices in the domain, and only those devices, 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 applications, such as IP User Datagram Protocol (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 bridge-group domain domain-number

For an example of how to configure domains, see the "Complex Transparent Bridging Network Topology Example" section later in this chapter.

Prevent the Forwarding of Dynamically Determined Stations

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 or allow forwarding of dynamically determined stations, perform one of 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 bridge-group acquire

Remove the ability to filter out all frames except those whose addresses have been statically configured into the forwarding cache.

bridge bridge-group acquire

Forward Multicast Addresses

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 bridge-group multicast-source

Configure Bridge Table Aging Time

A bridge forwards, floods, or drops packets based on the bridge table. The bridge table maintains both static entries and dynamic entries. Static entries are entered by the network manager or by the bridge itself. Dynamic entries are entered by the bridge learning process. A dynamic entry is automatically removed after a specified length of time, known as aging time, from the time the entry was created or last updated.

If hosts on a bridged network are likely to move, decrease the aging-time to enable the bridge to adapt to the change quickly. If hosts do not transmit continuously, increase the aging time to record the dynamic entries for a longer time and thus reduce the possibility of flooding when the hosts transmit again.

To set the aging time, perform the following task in global configuration mode:

Task

Command

Set the bridge table aging time.

bridge-group bridge-group aging-time seconds

Filter Transparently Bridged Packets

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 tasks in the following sections:

•Set Filters at the MAC layer

•Filter LAT Service Announcements

Note   When setting up administrative filtering, remember that there is virtually no performance penalty in filtering by MAC address or vendor code, but there can be a significant performance penalty when filtering by protocol type.

When configuring transparent bridging access control, keep the following points in mind:

•You can assign only one access list to an interface.

•The conditions in the access list are applied to all outgoing packets not sourced by the Cisco IOS software.

•Access lists are scanned in the order you enter them; the first match is used.

•An implicit deny everything entry is automatically defined at the end of an access list unless you include an explicit permit everything entry at the end of the list.

•All new entries to an existing list are placed at the end of the list. You cannot add an entry to the middle of a list. This means that if you have previously included an explicit permit everything entry, new entries will never be scanned. The solution is to delete the access list and retype it with the new entries.

•You can create extended access lists to specify more detailed filters, such as address match only.

•You should not use extended access lists on FDDI interfaces doing transit bridging as opposed to translational bridging.

•Configuring bridging access lists of type 700 may cause a momentary interruption of traffic flow.

For more information on access lists, refer to the "Configuring Traffic Filters" chapter of the Security Configuration Guide.

Set Filters at the MAC layer

You can filter transmission of frames at the MAC layer by performing tasks in one of the following sections:

•Filter by Specific MAC Address

•Filter by Vendor Code

•Filter by Protocol Type

When filtering by a MAC-level address, you can use two kinds of access lists: standard access lists that specify a simple address, and extended access lists that specify two addresses. You can also further restrict access by creating filters for these lists. After you have completed one of the preceding tasks, perform the task in the following section:

•Define and Apply Extended Access Lists

Note   MAC addresses on Ethernets are "bit swapped" when compared with MAC addresses on Token Ring and FDDI. For example, address 0110.2222.3333 on Ethernet is 8008.4444.CCCC on Token Ring and FDDI. Access lists always use the canonical Ethernet representation. When using different media and building access lists to filter on MAC addresses, keep this point in mind. Note that when a bridged packet traverses a serial link, it has an Ethernet-style address.

Filter by Specific MAC Address

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 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 "Multicast or Broadcast Packets Bridging Example" later in this chapter to guide you in building your configuration to allow for multicast or broadcast packets.

Filter by Vendor Code

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:

•Establish a vendor code access list

•Filter source addresses

•Filter destination addresses

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 access-list-number {permit | deny} address mask

The vendor code is the first three bytes of the MAC address (left to right). For an example of how to filter by vendor code, see "Multicast or Broadcast Packets Bridging Example" later in this chapter.

Note   Remember that, as with any access list using MAC addresses, Ethernets swap their MAC address bit ordering, and Token Rings and FDDI do not. Therefore, an access list that works for one medium might not work for others.

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 or the MAC destination addresses of packets that would ordinarily be forwarded out that interface. To filter by source or destination addresses, perform one of the following tasks in interface configuration mode:

Task

Command

Assign an access list to an interface for filtering by MAC source addresses.

bridge-group bridge-group input-address-list access-list-number

Assign an access list to an interface for filtering by the MAC destination addresses.

bridge-group bridge-group output-address-list access-list-number

Filter by Protocol Type

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:

•Establish a protocol type access list

•Filter Ethernet- and SNAP-encapsulated packets on input

•Filter Ethernet- and SNAP-encapsulated packets on output

•Filter IEEE 802.2-encapsulated packets on input

•Filter IEEE 802.2-encapsulated packets on output

Note   It is not a good idea to have both input and output type code filtering on the same interface.

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.

Note   Protocol type access lists can have an impact on system performance; therefore, keep the lists as short as possible and use wildcard bit masks whenever possible.

Access lists for Ethernet- and IEEE 802.2-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 protocol type 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 the "Ethernet Type Codes" appendix of the Bridging and IBM Networking Command Reference.

To establish protocol type access lists, perform the following task in global configuration mode:

Task

Command

Prepare access control information for filtering frames by protocol type.

access-list access-list-number {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. The 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.2 DSAP/SSAP access lists.

You can also 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 input or output, perform either or both of the following tasks in interface configuration mode:

Task

Command

Add a filter for Ethernet- and SNAP-encapsulated packets on input.

bridge-group bridge-group input-type-list access-list-number

Add a filter for Ethernet- and SNAP-encapsulated packets on output.

bridge-group bridge-group output-type-list access-list-number

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.

You can also 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 input or output, perform one or both of the following tasks in interface configuration mode:

Task

Command

Add a filter for IEEE 802-encapsulated packets on input.

bridge-group bridge-group input-lsap-list access-list-number

Add a filter for IEEE 802-encapsulated packets on output.

bridge-group bridge-group output-lsap-list access-list-number

Access lists for Ethernet- and IEEE 802-encapsulated packets affect only bridging functions. You cannot use such access lists to block frames with protocols that are being routed.

Define and Apply Extended Access Lists

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:

Task

Command

Define an extended access list for finer control of bridged traffic.

access-list access-list-number {permit | deny} source source-mask destination destination-mask offset size operator operand

To apply an extended access list to an interface, perform one or both of the following tasks in interface configuration mode:

Task

Command

Apply an extended access list to the packets being received by an interface.

bridge-group bridge-group input-pattern-list access-list-number

Apply an extended access list to the packet being sent by an interface.

bridge-group bridge-group output-pattern-list access-list-number

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

Because of their complexity, only use extended access lists if you are very familiar with the Cisco IOS software. Further, do not specify an offset value that is greater than the size of the packet.

Filter LAT Service Announcements

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.

Note   The LAT filtering commands are not implemented for Token Ring interfaces.

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:

•Entries can be individual group code numbers separated with a space. (The Digital LAT implementation specifies that a list of numbers be separated by commas; however, our implementation expects the numbers to be separated by spaces.)

•Entries can also specify a range of numbers. This is done by separating an ascending order range of group numbers with hyphens.

•Any number of group codes or group code ranges can be listed in one command; just separate each with a space.

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 might not be enough to allocate local as