|
|
This chapter describes how to configure transparent bridging. 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. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
Transparent and remote bridging software on the Cisco Optical Networking System (ONS) 15304 combines the advantages of a spanning-tree bridge and a full IP router. This combination provides the speed and protocol transparency of an adaptive spanning-tree bridge, along with the functionality, reliability, and security of an IP router. Because the Cisco ONS 15304 does not support Token Ring interfaces, source route bridging and translational bridging are not applicable to the Cisco ONS 15304.
The Cisco ONS 15304's transparent bridging software implementation has the following features:
Complete one or more of the tasks in the following sections to configure transparent bridging on your router:
See the "Transparent Bridging Configuration Examples" section for configuration examples.
To configure transparent bridging, you must complete the tasks in the following sections:
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, complete 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. If you use the digital protocol, you will not be able to use bridge groups. For this reason, the digital Spanning-Tree Protocol mode is not recommended for typical Cisco ONS 15304 applications.
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:
After you assign a bridge group number and define a Spanning-Tree Protocol, assign each network interface to a bridge group by completing the following task in interface configuration mode:
| Task | Command |
|---|---|
Assign a network interface to a bridge group. | bridge-group bridge-group |
The Cisco IOS software supports transparent bridging over PPP links and provides some flexibility in controlling access and configuring the interface.
To configure a PPP or Multilink PPP interface for bridging, complete the tasks in the following sections:
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 |
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. Normally, there will be a bridge group with the same identification number associated with an Ethernet interface.
You can configure transparent bridging using PPP encapsulation on the serial interfaces. To configure transparent bridging over PPP, complete 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 PPP encapsulation. | encapsulation ppp |
Assign the interface to a bridge group. | bridge-group bridge-group |
Specify the type of Spanning-Tree Protocol. | bridge bridge-group protocol {ieee | dec} |
For an example of configuring transparent bridging over multiprotocol PPP, see the section "Transparent Bridging over PPP Example".
In the Cisco ONS 15304, Concurrent Routing and Bridging (CRB) will normally be turned on to allow different subscribers' Ethernet interfaces to be configured to operate in both transparent bridging or IP routing modes. If CRB is not turned on, the Cisco ONS 15304 will either bridge or route IP, but not both at the same time. For example, if two different subscribers are using IP traffic, but one has purchased an IP routing service, while the second has purchased a Transparent LAN Service, CRB must be turned on. Otherwise, the IP traffic on the Transparent LAN Service Port will not be forwarded.
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 can 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, complete the following task in global configuration mode:
| Task | Command |
|---|---|
Enable concurrent routing and bridging. |
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, complete the following task in interface configuration mode:
| Task | Command |
|---|---|
Specify a protocol to be routed on a bridge group. | bridge bridge-group route protocol |
You can configure one or more transparent bridging options. To configure transparent bridging options, complete one or more of the tasks in the following sections:
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, complete one of the following tasks in global configuration mode:
| Task | Command |
|---|---|
Disable IP routing. | no ip routing |
Enable 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.
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:
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, complete the following task in global configuration mode:
| Task | Command |
|---|---|
Establish a multiple spanning-tree domain. |
For an example of how to configure domains, see the section "Ethernet Bridging Example".
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, complete one of the following tasks 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. |
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, complete the following task in global configuration mode:
| Task | Command |
|---|---|
Set the bridge table aging time. | bridge-group bridge-group aging-time seconds |
When configuring transparent bridging access control, keep the following points in mind:
For more information on access lists, refer to the "Configuring Traffic Filters" chapter of the Security Configuration Guide.
You can filter transmission of frames at the MAC layer by completing tasks in one of the following sections:
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, complete the task in the following section:
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, complete 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.
To establish a vendor code access list, complete 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).
After 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, complete one of the following tasks in interface configuration mode:
You can filter by protocol type by using the access-list mechanism and specifying a protocol type code. To filter by protocol type, complete the first task and one or more of the other tasks that follow:
The order in which you enter access-list commands affects the order in which the access conditions are checked. Each condition is tested in succession. A matching condition is then used to execute a permit or deny decision. If no conditions match, a "deny" decision is reached.
Access lists for Ethernet- and IEEE 802.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, complete 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, complete 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, complete 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.
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, complete 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, complete 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. |
You might need to adjust certain spanning-tree parameters if the default values are not suitable for your bridge configuration. Parameters affecting the entire spanning tree are configured with variations of the bridge global configuration command. Interface-specific parameters are configured with variations of the bridge-group interface configuration command.
You can adjust spanning-tree parameters by performing any of the tasks in the following sections:
You can globally configure the priority of an individual bridge when two bridges tie for position as the root bridge, or you can configure the likelihood that a bridge will be selected as the root bridge. This priority is determined by default; however, you can change it. To set the bridge priority, complete the following task in global configuration mode:
| Task | Command |
|---|---|
Set the bridge priority. |
You can set a priority for an interface. When two bridges tie for position as the root bridge, you configure an interface priority to break the tie. The bridge with the lowest interface value is elected. To set an interface priority, complete the following task in interface configuration mode:
| Task | Command |
|---|---|
Establish a priority for a specified interface. |
Each interface has a path cost associated with it. By convention, the path cost is 1000/data rate of the attached LAN, in Mbps. You can set different path costs. Refer to the entry for this command in the Bridging and IBM Networking Command Reference for the various media defaults. To assign path costs, complete the following task in interface configuration mode:
| Task | Command |
|---|---|
Set a path cost different from the defaults. | bridge-group bridge-group path-cost cost |
You can adjust BPDU intervals as described in the following sections:
You can specify the interval between hello BPDUs. To adjust this interval, complete the following task in global configuration mode:
| Task | Command |
|---|---|
Specify the interval between hello BPDUs. |
The forward delay interval is the amount of time spent listening for topology change information after an interface has been activated for bridging and before forwarding actually begins. To change the default interval setting, complete the following task in global configuration mode:
| Task | Command |
|---|---|
Set the default of the forward delay interval. |
| Task | Command |
|---|---|
Change the amount of time a bridge will wait to hear BPDUs from the root bridge. | bridge bridge-group max-age seconds |
When a loop-free path exists between any two bridged subnetworks, you can prevent BPDUs generated in one transparent bridging subnetwork from impacting nodes in the other transparent bridging subnetwork, yet still permit bridging throughout the bridged network as a whole. For example, when transparently bridged LAN subnetworks are separated by a WAN, BPDUs can be prevented from traveling across the WAN link.
To disable the spanning tree on an interface, complete the following task in interface configuration mode:
| Task | Command |
|---|---|
Disable the spanning tree on an interface. |
The following sections describe how to configure features that enhance network performance by reducing the number of packets that traverse the backbone network:
In the Cisco ONS 15304, Multilink PPP should be used instead of the circuit group feature. The circuit group feature is available, but not fully supported on the Cisco ONS 15304 platform.
If a circuit-group port goes down and up as a result of configuration or a line protocol change, the spanning-tree algorithm will bypass port transition and will time out necessary timers to force the eligible circuit-group ports to enter the forwarding state. This avoids the long disruption time caused by spanning-tree topology recomputation and therefore resumes the load distribution as quickly as possible.
To tune the transparently bridged network, complete the following tasks:
Step 1 Define a circuit group.
Step 2 Optionally, configure a transmission pause interval.
Step 3 Modify the load distribution strategy.
To define a circuit group, complete the following task in interface configuration mode:
| Task | Command |
|---|---|
Add a serial interface to a circuit group. | bridge-group bridge-group circuit-group circuit-group |
For circuit groups of mixed-bandwidth serial interfaces, it might be necessary to configure a pause interval during which transmission is suspended to avoid misordering packets following changes in the composition of a circuit group. Changes in the composition of a circuit group include the addition or deletion of an interface and interface state changes. To configure a transmission pause interval, complete the following task in global configuration mode:
| Task | Command |
|---|---|
Configure a transmission pause interval. | bridge bridge-group circuit-group circuit-group pause milliseconds |
For applications that depend on the ordering of mixed unicast and multicast traffic from a given source, load distribution must be based upon the source MAC address only. To modify the load distribution strategy to accommodate such applications, complete the following task in global configuration mode:
| Task | Command |
|---|---|
Base load distribution on the source MAC address only. | bridge bridge-group circuit-group circuit-group source-based |
In a transparent bridge, multicast packets are flooded on all forwarding ports on the bridge. For some protocols, it is possible for a bridge to determine the membership of multicast groups, and constrain the flooding of multicasts to a subset of the forwarding ports. Constrained multicast flooding enables a bridge to determine group membership of IP multicast groups dynamically and flood multicast packets only on those ports that reach group members.
To enable constrained multicast flooding, complete the following task in global configuration mode:
| Task | Command |
|---|---|
Enable constrained multicast flooding for all configured bridge groups. |
| Task | Command |
|---|---|
Remove any learned entries from the forwarding database and clear the transmit and receive counts for any statically configured forwarding entries. | clear bridge bridge-group |
Remove multicast-group state information and clear the transmit and receive counts. | clear bridge [bridge-group] multicast [router-ports | groups | counts] [group-address] [interface-unit] [counts] |
Display classes of entries in the bridge forwarding database. | show bridge [bridge-group] [interface] [address [mask]] [verbose] |
Display the interfaces configured in each circuit group and show whether they are participating in load distribution. | show bridge [bridge-group] circuit-group [circuit-group] [src-mac-address] [dst-mac-address] |
Display transparent bridging multicast state information. | show bridge [bridge-group] multicast [router-ports | groups] [group-address] |
Display information about configured bridge groups. | show bridge group [verbose] |
Display the configuration for each interface that has been configured for routing or bridging. | |
Display the protocols that can be routed or bridged for the specified interface. | show interfaces [interface] irb |
Display the spanning-tree topology known to the router, including whether or not filtering is in effect. | show span |
The following sections provide example configurations that you can use as a guide to configuring your bridging environment:
Figure 10-1 is an example of a basic bridging configuration involving three independent bridge groups. Traffic from each Ethernet is bridged to the affiliated serial line in the same bridge group. The IEEE-compatible bridging algorithm with default parameters is being used.
The configuration file for the router depicted in Figure 10-1 would be as follows:
interface ethernet 1 no ip address bridge-group 1 no shutdown ! interface ethernet 2 no ip address bridge-group 2 no shutdown ! interface ethernet 3 no ip address bridge-group 3 no shutdown ! interface serial 1 no ip address encapsulation ppp bridge-group 2 no shutdown ! interface serial 2 no ip address encapsulation ppp bridge-group 2 no shutdown ! interface serial 3 no ip address encapsulation ppp bridge-group 3 no shutdown ! bridge 1 protocol ieee bridge 2 protocol ieee bridge 3 protocol ieee
The following example illustrates a router configured for transparent bridging over PPP encapsulation. IP routing is turned off on all interfaces in this example.
! no ip routing ! interface ethernet 1 no ip address no mop enabled bridge-group 1 ! interface serial 1 no ip address encapsulation ppp bridge-group 1 ! bridge 1 protocol ieee
In the following example, two buildings have networks that must be connected via an E1 link. For the most part, the systems in each building use either IP or DECnet, and therefore, should be routed. There are some systems in each building that must communicate, but they can use only a proprietary protocol.
The example places two Ethernets in each building. One of the Ethernets is attached to the hosts that use a proprietary protocol, and the other is used to attach to the rest of the building network running IP and DECnet. The Ethernet attached to the hosts using a proprietary protocol is enabled for bridging to the serial line and to the other building.
Figure 10-2 shows an example configuration. The interfaces marked with an asterisk (*) are configured as part of spanning tree 1. The routers are configured to route IP and DECnet. This configuration permits hosts on any Ethernet to communicate with hosts on any other Ethernet using IP or DECnet. In addition, hosts on Ethernet 1 in either building can communicate using protocols not supported for routing.
The configuration file for the router in Building 1 would be as follows. Note that no bridging takes place over Ethernet 0. Both IP and DECnet routing are enabled on all interfaces.
decnet address 3.34 interface ethernet 0 ip address 128.88.1.6 255.255.255.0 decnet cost 10 ! interface serial 0 ip address 128.88.2.1 255.255.255.0 bridge-group 1 decnet cost 10 ! interface ethernet 1 ip address 128.88.3.1 255.255.255.0 bridge-group 1 decnet cost 10 ! bridge 1 protocol dec
The configuration file for the router in Building 2 is similar:
decnet address 3.56 ! interface ethernet 0 ip address 128.88.11.9 255.255.255.0 decnet cost 10 ! interface serial 0 ip address 128.88.2.2 255.255.255.0 bridge-group 1 decnet cost 10 ! interface ethernet 1 ip address 128.88.16.8 255.255.255.0 bridge-group 1 decnet cost 10 ! bridge 1 protocol dec
! ipx routing 0000.0c36.7a43 appletalk routing ! decnet routing 9.65 decnet node-type routing-iv ! ! interface Ethernet0/0 ip address 172.19.160.65 255.255.255.0 ipx network 160 appletalk address 160.65 decnet cost 7 ! interface Ethernet0/1 ip address 172.19.161.65 255.255.255.0 ipx network 161 appletalk address 161.65 decnet cost 7 ! interface Ethernet0/2 ip address 172.19.162.65 255.255.255.0 appletalk address 162.65 bridge-group 1 ! interface Ethernet0/3 ip address 172.19.14.65 255.255.255.0 appletalk address 14.65 appletalk zone california bridge-group 1 ! router igrp 666 network 172.19.0.0 ! bridge crb bridge 1 protocol ieee bridge 1 route appletalk bridge 1 route ip !
The relevant portions of the configuration for the router are listed below:
interface Ethernet 1 bridge-group 1 ! interface Ethernet 2 bridge-group 1 ! interface Ethernet 3 bridge-group 2 ! interface Ethernet 4 bridge-group 2 ! interface BVI 1 ip address 3.0.0.1 255.0.0.0 ! interface BVI 2 ip address 5.0.0.1 255.0.0.0 ! bridge irb bridge 1 protocol ieee bridge 1 route ip bridge 2 protocol ieee bridge 2 route ipMulticast or Broadcast Packets Filtering Example
When filtering specific MAC destination addresses, allow for multicast or broadcast packets that are required by the bridged network protocols.
Posted: Thu Feb 24 12:22:03 PST 2000
Copyright 1989 - 2000©Cisco Systems Inc.