![[previous]](../../../graphics/l_arrow.gif){kind=icon}
![[next]](../../../graphics/r_arrow.gif){kind=icon}
This section provides conceptual information on the following topics:
Transparent bridging is supported on Ethernet, token ring, FDDI, and the following wide area networks: Frame Relay, ATM, X.25, SMDS, PPP, and ISDN. When transparent bridging is enabled, the bridge forwards packets based on the destination address in the packets it receives. It also learns and records information about the location and addresses of devices on the surrounding networks, based on the source address in the received packets.
You can configure your bridge to forward frames using any of the following methods:
The bridge forwards packets based on a route determined by the source or end system from which the packet originated. Because the end system and not the bridge determines the route, a bridge using source route bridging does not record or learn information about addresses on the surrounding networks in the way that a transparent bridge does.
Operating transparent and source route bridging simultaneously is called source route transparent bridging. The bridge automatically determines whether a packet should be forwarded using transparent bridging or source route bridging.
When configuring parallel bridges, 3Com recommends that you configure both bridges in the same mode, either source route or source route transparent, to prevent unexpected blocking of one type of traffic. For more information on source route bridging, see the Configuring Source Route Bridging chapter.
You can connect source route domains to transparent bridging domains by configuring SRTG. The SRTG software provides a mapping between the two domains, so that a user on a token ring network using source routing can communicate with another user on an Ethernet network using transparent bridging. For more information, see the Configuring Source Route Bridging chapter.
IBM-related services such as data link switching (DLSw) and APPN are affected by parameter settings in the BRidge, SR, and LLC2 Services. Table 23-1 lists the required settings in source route (SR), source route transparent (SRT), and transparent (T) bridging environments for each of the IBM-related services.
In this table, the bridging environment (SR, SRT, or T) is shown in the Port Configuration column. Tunneling is the3Com proprietary method of LLC2 tunneling, DLSw is data link switching, and LNM is LAN Net Manager. The settings are shown in abbreviated form. For example, the row labeled DLSw/Tunneling with port configuration SR represents DLSw or 3Com LLC2 tunneling in a source-route-only port configuration. The entries in this row expand to the following software configuration commands:
SETDefault !<port> -SR SrcRouBridge = SrcRouBridge
SETDefault !<port> -BRidge TransparentBridge = NoTransparentBridge
SETDefault -BRidge CONTrol = Bridge | NoBridge
SETDefault !<port> -SR RouteDiscovery = LLC2
SETDefault !<port> -LLC2 CONTrol = Enable
SETDefault !<port> -SR RingNumber = <number> (1-4095) | 0x<number>(1-FFF)
In this configuration, global bridging is enabled or disabled on one or more token ring ports. Transparent bridging is disabled, source routing and route discovery are configured, and LLC2 is enabled.
| 1
In this configuration, end systems may generate a small number of MAC Frame Copy error report packets when the bridge/router is initializing or
when it ages out a MAC address from its bridge table.
|
For transparent bridge (TB) or SRT configurations, token ring end systems may generate a small number of MAC Frame Copy error reports when a NETBuilder II bridge/router is initializing or when the bridge/router ages out a MAC address from its bridge table.
For the bridge/router to learn the MAC addresses of transparent end systems on the token ring, it copies a packet with an unknown source address and sets the address-recognized (A) and frame-copied (C) bits in the Frame Status (FS) field. A problem occurs when the FS (A) and (C) bits have been set and the destination of the frame is an end system on the local ring. The destination end system expects the (A) and (C) bits to be zeros. When it receives a frame with these values already set, it reports an error. The end system counts these errors until the error threshold is reached; then it sends out a MAC Report Error packet.
These Frame Copy errors occur only with transparent token ring packets, because the bridge/router hardware filters source-routed packets based on the route information field, not the MAC address. If the bridge/router is configured for source route only, it never copies frames destined for a station on the local ring. These errors can be avoided by running in source-route-only mode.
Table 23-1 identifies those configurations that can cause Frame Copy errors.
With translation bridging, you can communicate between transparent bridging end stations on different LAN media types: Ethernet, token ring, and FDDI. (For source route end stations to communicate with transparent bridging end stations, you must use SRTG as described in the Configuring Source Route Bridging chapter.) You also can communicate between end stations on the same media type across backbones of a different media type. The 3Com implementation of translation bridging is based on general principles of media access control (MAC) header translation and encapsulation, as well as protocol-specific translation for well-known protocol problems.
When a packet needs to be forwarded from a token ring or FDDI network to an Ethernet network, translation bridging transforms the packet from a token ring or FDDI format to an Ethernet format, or vice versa. When a packet is forwarded to a serial port, translation bridging takes place automatically at the remote bridge port when it receives the packets. For translation bridging to occur on wide area bridges, translation software is necessary in both units.
Translation bridging between Ethernet and token ring networks connected by a NETBuilder II bridge/router can take place either across serial lines or through a local port. Translation bridging between Ethernet and FDDI networks takes place through local ports. Figure 24 illustrates each of these concepts.
Figure 24 Using Translation Bridging to Interconnect Token Ring and Ethernet Networks
Figure 25 illustrates the general principles of MAC header translation, as applied to bridging packets of different formats on Ethernet over a token ring or FDDI backbone.
Figure 25 MAC Header Translation
AppleTalk Phase 2 packets originating on an Ethernet network and destined for another Ethernet network across an FDDI backbone remain in AppleTalk Phase 2 Subnetwork Access Protocol (SNAP) format. SNAP packets use an Organizationally Unique Identifier (OUI) of 000000. AppleTalk Phase 1 packets originating on an Ethernet network are tunneled through the FDDI backbone using an OUI value of 0000F8.
For networks other than AppleTalk Phase 2, a SNAP header on Ethernet is translated to a SNAP header on FDDI and then back to Ethernet, instead of SNAP. If you are using translation bridging from Ethernet to Ethernet across FDDI, use the Ethernet header format on both sides.
Some protocols use a format similar to SNAP for encapsulating other types, but use their own proprietary OUI instead of the 000000 OUI used by SNAP. These packets are not converted back to Ethernet when bridging from FDDI or token ring onto an Ethernet LAN.
The maximum transmission unit (MTU) is the maximum packet size allowed, which varies according to the LAN media. Applications that run in a multimedia bridged environment must be configured to use packet sizes that are equal to or smaller than the smallest of the MTU sizes in the extended LAN; otherwise, some media may drop oversize packets. If a particular application cannot accept smaller packets, using network layer routing instead of MAC layer bridging may provide a solution.
For IP packets being bridged between interfaces that have mismatched MTU sizes, you can enable the IP fragmentation feature by setting the -BRidge CONTrol parameter to IPFragment. The bridge then fragments IP packets that are being forwarded to ports with a smaller MTU size.
LLC packets on Ethernet networks contain a length field that is removed before the packet is transmitted to FDDI and token ring media. In some systems, the actual length of the packet and the LLC length field may not match. When these packets are bridged to another Ethernet across an FDDI or token ring backbone, the resulting packet length cannot be determined. The 3Com implementation ignores the actual packet length and transmits according to the LLC length field. If the actual length of the packet is greater than the LLC length, it is cut short to correspond to the LLC length. If it is less than the LLC length, the packet is padded at the end to match the LLC length.
On Ethernet and FDDI media, multicast addresses are used in the destination address field to reach a group of stations running a certain type of protocol. Because the multicast address is identified by one bit in the address space, it is possible to have millions of such addresses in the available 48-bit address space.
For similar applications on token ring media, functional addresses are used. Only 32 functional addresses are possible. When bridging packets from Ethernet or FDDI to token ring, multicast packets should be mapped to the corresponding functional address and vice versa. Multicast packets that do not have a one-to-one mapping are dropped.
The 3Com implementation maintains a table of multicast-to-functional address mappings for well known protocols, shown in Table 19. User-defined mappings can be added using the -BRidge MultiCastAddr or FunctionalAddr parameters. For further information, see "Adding Functional-Address-to-Multicast-Address Mappings to the Default Table" earlier in this chapter.
By default, the bridge displays addresses in canonical format.
Token ring and FDDI media provide a means of prioritizing access over the ring. Applications can request a priority between 0 and 7, and the MAC sublayer maps these user priorities to access priorities supported by the individual media access methods. A token with an access priority equal to or less than the requested user priority transmits this packet over the media.
To prevent a bridge from reordering frames of a given user priority received on one port when forwarding to another port, user priority information is conveyed to the driver along with the frames submitted for transmission. The mapping of user and access priorities is done in accordance with the 802.1d IEEE standard for MAC bridging. For packets that are bridged from Ethernet to token ring, the default user priority of 4 is used.
If you are connecting a 3Com bridge to a bridge from another vendor and are bridging token ring or FDDI packets over a WAN link, you can configure the DatalinkAddrFmt parameter to ensure that the 3Com bridge conforms to standards used by the other bridge.
The following section describes protocol-specific translation bridge issues.
3Com has not implemented translation bridging of AppleTalk packets between token ring and other media. Communication between AppleTalk nodes on token ring and nodes on other media types should be accomplished using routing.
Bridging of AppleTalk Phase 1 and Phase 2 packets between Ethernets across an FDDI backbone is implemented according to the recommended practice published by IEEE. This bridging is controlled by the -BRidge APPleTalk parameter. 3Com recommends that you retain the default value of Enable.
MAC-layer bridging typically does not bridge large frames between physical media that have dissimilar maximum frame sizes. To solve this problem, 3Com implements fragmentation of bridged IP packets. IP fragmentation is supported between LAN media and also on WAN media. Fragmentation can be enabled by setting the -BRidge CONTrol parameter to IPFragment.
Fragmentation may cause some deterioration in performance.
3Com supports IPX translation bridging between end stations on the same LAN media type across a backbone of another media type. Bridging IPX between end stations on different media types is not supported.
NetWare stations running IPX can be configured to operate in pure Ethernet format, SNAP format, or 802.2 LLC format. Bridging with either Ethernet or 802.3 is uncomplicated. In bridging IPX SNAP format from Ethernet to FDDI or token ring and then back to Ethernet, SNAP packets are translated back into Ethernet format.
When translation bridging of the IPX Protocol involves an Ethernet backbone, the Novell file server MTU should be configured to be less than or equal to the MTU size of the Ethernet backbone (1,514 bytes).
The spanning tree algorithm detects loops and puts some bridge ports into blocking state, if necessary, so that only one route exists between any two stations. (A port in blocking state does not forward or receive packets.) Eliminating the extra paths creates a stable network configuration. When one or more bridges or ports in the stable topology fail, the algorithm automatically returns some ports from blocking state to forwarding state to ensure that all stations are connected.
For the spanning tree algorithm to be effective, all bridges in your extended network must run it.
An extended network without loops can be viewed as a spanning tree. A spanning tree is a topology in which one node is designated as the root, and any two nodes are connected to each other through one and only one route. Figure 26 is an example of the spanning tree structure in which one bridge represents the root, other bridges represent the nodes, and the communications lines represent the branches. The arrows illustrate the unique path that a packet from the San Francisco bridge takes when destined for the Los Angeles bridge. The topology would not be a spanning tree if there were also a line directly linking the San Francisco bridge and the San Jose bridge, or if the line between the San Jose bridge and the Santa Clara bridge were broken.
Figure 26 Spanning Tree Structure
When more than one bridge connects LANs, the network manager may inadvertently configure the network with loops, causing packets to circulate indefinitely. A loop exists if more than one path can be used to forward a packet from one end station to another. For example, the dotted line in Figure 27 highlights a loop; packets from a station on LAN 1 can be forwarded to one or more stations on LAN 2 via either bridge A or bridge B. The destination stations receive duplicate packets because both bridge A and bridge B replicate the packet and then forward the packet to LAN 2. If the station sends out a broadcast packet, both bridges forward it to their attached networks, creating packets that circulate indefinitely.
The spanning tree algorithm detects and breaks loops that can form within a bridging topology.
Figure 27 Network with a Loop
The spanning tree algorithm configures the network so that no loops exist in the extended network, and every two LANs can communicate with each other. This section lists the prerequisites required for the algorithm to work and gives an example to explain how the algorithm arrives at a loop-free configuration.
For the algorithm to configure the network:
To arrive at a loop-free configuration based on the bridge ID, port ID, and path costs, the algorithm performs the following tasks:
The following example shows how the algorithm makes the selections, then eventually eliminates loops. Figure 28, Figure 29, Figure 30, and Figure 31 illustrate an extended network. In these figures, the bridges are numbered from 1 to 5, where bridge 1 has the lowest data link address, and bridge 5 has the highest.
When the bridges are turned on, each assumes that it is the root bridge. Each bridge then transmits a packet called the Configuration Bridge Protocol Data Unit (CBPDU) through all its ports. A CBPDU contains information such as the ID of the bridge that the transmitting bridge considers the root bridge, the root path cost of the transmitting bridge, and the number of the source port.
When a bridge receives a CBPDU that contains superior information on one of its ports, it stores the information at that port. If this CBPDU is received at the root port of the bridge, the bridge also forwards it with an updated message to all attached LANs for which it is the designated bridge.
If a bridge receives a CBPDU on one of its ports that contains information inferior to that currently stored at that port, it discards it. If the bridge is a designated bridge for the LAN from which the CBPDU is received, it sends that LAN a CBPDU containing the up-to-date information stored at that port. In this way, inferior information is discarded and superior information is propagated on the extended network.
Assume that each port in Figure 28 is equipped with an Ethernet interface that has a path cost of 100, and that the priority fields in the IDs of bridge 1 and bridge 3are the same. Having the lowest bridge ID (because its data link address is the lowest), bridge 1 becomes the root bridge, and its CBPDU is superior to the ones from other bridges. After exchanging a few CBPDUs and discarding the inferior ones, all bridges contain the same information that indicates that bridge 1 is the root bridge. Because a root bridge is automatically the designated bridge for all LANs to which it is attached, bridge 1 is also the designated bridge for LANs 1 and 2.
Figure 28 Root Bridge
Each bridge (except the root bridge) has to select a root port that will incur the least cost when the bridge forwards a packet to the root. The cost depends partly on the path cost of the port (determined by the speed of its network interface) and partly on the root path cost of the designated bridge for the LAN to which this port is attached.
For example, in Figure 29, while ports 1 and 2 of bridge 3 both have the same network interface type and the same path cost, bridge 3 incurs less cost if it forwards a packet from port 1 than from port 2. The algorithm then decides that port 1 should be the root port for bridge 3.
Figure 29 Root Port
If a LAN is attached to a single bridge, that bridge is the designated bridge of the LAN. For example, in Figure 30, bridge 2 is the designated bridge for LAN 3, because bridge 2 is the only bridge attached to LAN 3.
Figure 30 Selecting a Designated Bridge when One Bridge Is Attached to a Network
For a LAN that is attached to more than one bridge, a designated bridge must be selected. For example, in Figure 31, because LAN 4 is attached to bridge 3, bridge 4, and bridge 5, the algorithm must compare the root path costs of these bridges. In this case, their root path costs are the same. Having the lowest bridge ID, bridge 3 becomes the designated bridge for LAN 4. Because bridge 3 is attached to LAN 4 through port 2, port 2 is the designated port for LAN 4.
Bridge 1, which is the root bridge, is automatically the designated bridge for all attached LANs (that is, LANs 1 and 2). Because bridge 2 is the only bridge attached to LAN 3, it becomes the designated bridge for LAN 3.
Figure 31 Selecting a Designated Bridge when Multiple Bridges Are Attached to a Network
Only root ports and designated ports are put into forwarding state. Other ports, such as port 1 of bridge 4 and port 2 of bridge 5, are put into blocking state, as shown in Figure 31.
When a port is in forwarding state, it performs learning, filtering, and forwarding functions. When it is in blocking state, it performs none of these functions.
Because some ports are put into blocking state, none of the packets circulate on the extended network indefinitely.
Although the examples in the previous section involve only local bridges, local and wide area bridges participate in configuring loop-free networks using the spanning tree algorithm.
In Figure 32, two bridges connect two remote networks. On each bridge, one of the interfaces is a network interface, and the others are serial links connected to the other wide area bridge. To apply the spanning tree algorithm in such a network configuration, it is assumed that the serial links are attached to an imaginary backbone network on which no end stations exist. The only traffic on the backbone is the traffic between the bridges. With this assumption, all bridge interfaces operate as if they were network interfaces, and the same spanning tree principle described above applies.
When wide area bridges with parallel lines, as shown in Figure 32, participate in the spanning tree algorithm, all remote links connected to the same wide area bridge are considered one network interface. The algorithm puts all links into either forwarding or blocking state. This ensures that the network topology can maximize the use of the bandwidth provided by parallel network links.
If you configure your wide area bridge with parallel lines, make sure that both paths are assigned to the same port. If you use separate ports, the spanning tree algorithm considers each port to be a separate network. As a result, one port will be put into blocking state. You can use parallel lines on different ports as a backup. If the line in the forwarding state fails, the second line moves from the blocking state to the forwarding state.
Figure 32 Two Wide Area Bridges Connected to Imaginary Backbone Network
When you connect two bridges over a PPP serial link, both bridges must operate in the same spanning tree domain. 3Com supports the following configurations of the STP over PPP:
The following configurations are not supported:
If you connect bridges in the unsupported configurations, the separate spanning tree domains are combined into a single domain.
When two bridges are connected over a PPP serial link, both bridges must be operating in the same spanning tree domain (SR or TB/SRT). The following configurations are supported:
The following configurations are not supported:
If you connect bridges in the unsupported configurations, the separate SR and SRT/TB spanning tree domains will combine into a single spanning tree domain.
A bridge is configured for SRT, SR, or TB modes as follows:
One or more ports are configured for transparent bridging and one or more ports are configured for source route bridging.
One or more ports are configured for source route bridging and no ports are configured for transparent bridging.
One or more ports are configured for transparent bridging and no ports are configured for source route bridging.
Configure ports for transparent bridging by setting the TransparentBRidge parameter in the BRidge Service. Configure ports for source route bridging by setting the SrcRouBridge parameter in the SR Service.
Transparent and source route transparent bridges participate in a spanning tree domain, which is identified when the destination address field of the spanning tree packet is the hexadecimal group address 0180C2000000. Source route bridges participate in a different spanning tree domain, which is identified when the destination address field of the spanning tree packet is the hexadecimal bridge functional address 030000008000. Both addresses are shown in canonical addressing format.
If a bridge has different types of bridging enabled on different ports, the spanning tree algorithm determines what type of bridge it is overall (transparent, source route, or source route transparent) according to the following criteria:
The spanning tree algorithm detects loops independent of the operating mode of the bridge.
The Spanning Tree Protocol (STP) Service controls parameters used by the spanning tree algorithm (for example, the priority field in the bridge identifier) to influence the final network configuration. For more information on setting STP parameters, see the STP Service Parameters chapter in Reference for Enterprise OS Software.
The spanning tree algorithm reconfigures the network topology when bridges are added or removed, or when the network manager changes the parameters.
Whenever a bridge detects a topology change, if it is a designated bridge for a LAN, it sends out a topology change notification Bridge Protocol Data Unit (BPDU) through its root port. This information is eventually relayed to the root bridge. The root bridge then sets the topology change flag in its CBPDU so that the information is broadcast to all bridges. It transmits this CBPDU for a fixed amount of time to ensure that all bridges are informed of the topology change.
If a port is changed from blocking state to forwarding state as a result of the topology change, the algorithm ensures that it propagates the topology information to all ports before that port starts forwarding data. This prevents temporary data loops.
If a bridge does not receive packets from an address within a fixed period of time, it removes that address from its routing table. After reconfiguration, the bridge removes these addresses faster to ensure that each active port still forwards packets to the right network after a topology change.
When multiple paths are assigned to a port on a NETBuilder II bridge/router, a load-sharing algorithm is used. The load-sharing algorithm selects the highest bandwidth line as the primary line. Any outgoing data is transmitted through this line until a certain threshold (defined within software limits for that bandwidth) is reached. When the threshold is reached, packets are forwarded on the next highest bandwidth line. If the number of bytes queued on the primary line falls below the threshold, outgoing packets revert to the primary line.
A bridge forwards packets according to information in the routing table. Each entry in this table lists an address, the network on which the station with that address can be found, and an indication of elapsed time since a packet was received from that node. For an interpretation of the routing table, see the BRidge Service Parameters chapter in Reference for Enterprise OS Software.
The two types of routing table entries are: learned (dynamic) entries and user-assigned (static or permanent) entries.
You can access the routing table of transparent bridges by entering:
SHow -BRidge AllRoutes
For complete information on this parameter, see the BRidge Service Parameters chapter in Reference for Enterprise OS Software.
You can configure the size of the routing table on the transparent bridge using the -BRidge RouteTableSize parameter. For complete information on this parameter, see the BRidge Service Parameters chapter in Reference for Enterprise OS Software.
This section describes how a bridge learns the network configuration and adapts to the addition or removal of stations on the attached network segment in order to perform standard filtering. For information on 3Com mnemonic filtering and related filtering processes such as logging, sequencing, and packet prioritization, see the Configuring Mnemonic Filtering chapter. For complete explanations of packet filtering parameters, see the FIlter Service Parameters chapter in Reference for Enterprise OS Software.
Figure 33 shows two networks interconnected by a bridge. After the bridge receives a packet, it decides whether to forward it to the other network or discard it. To help make this decision, the bridge determines to which network the destination of the packet belongs.
Figure 33 Bridge Learning
When a bridge is operating, it receives packets from all attached networks. By looking at the source address of packets, the bridge learns the addresses of stations on each network and stores them in its routing table. For example, when the bridge in Figure 33 receives a packet from network 1 with the address for host A as the source address, it learns that host A is on network 1. In the same way, it also learns that hosts B and C are on network 2.
If a packet is destined for the network where it originated, the bridge discards it. This is called standard filtering. For example, if the bridge in Figure 33 receives a packet on network 2 from host C that is addressed to host B, and it determines from the learned entries in its routing table that host B is on the same network as host C, then it discards the packet.
In addition, the bridge uses the learned network configurations to forward packets destined for another network. For example, if the bridge receives a packet on network 2 from host C addressed to host A, it determines that host A is on another attached network, and forwards the packet to that network.
If the bridge receives a packet from a host on a network that has not yet been learned, the bridge forwards the packet to all ports except the port on which the packet was received.
The bridge also can learn that a station has been removed from one of its attached networks. For example, in Figure 34, host C was moved from network 2 to network 1. The bridge no longer receives packets on network 2 with host C as the source address. The bridge record of the location of host C is no longer updated and is removed (aged) from the routing table. With host C attached to network 1, the bridge receives packets from network 1 with the address of host C as the source address, and learns that network 1 now includes host C.
Figure 34 Network Configuration after Host C Is Moved
