Bridging
Bridging is a technique for transferring packets between local networks based on their Layer 2 (MAC) addresses rather than their Layer 3 (IP) addresses. A typical bridge between two Ethernets would notice which Ethernet addresses are in use on each Ethernet and selectively transfer packets from one Ethernet to the other, based on the packets' destination Ethernet addresses. Bridges use their own set of protocols to communicate with each other, preventing the equivalent of routing loops and helping them learn how to handle packets for hosts that aren't connected directly to one of their ports.
Bridging is useful in a number of situations:
- Before routers were commodity products, bridging was a way of extending a network beyond the limits of a single physical medium. In other words, it's a way to connect local networks into a larger network without the complexity of routing.
- Many protocols, such as NetBIOS, can't be routed. If you have to deal with protocols that can't be routed, you may want to consider bridging as a way of propagating those protocols across a larger network. Note, however, that many nonroutable protocols (including NetBIOS) can be encapsulated within IP, which effectively makes them routable. Encapsulating nonroutable protocols within IP may be a better solution than bridging them.
- Bridging is often used to connect remote networks to an ISP, particularly when using ADSL modem or cable modem. The ADSL or cable modem is often configured as a bridge, which is often less expensive than using a full-fledged router.
Bridging usually does not scale as well as routing, and it takes much more of the router's CPU and memory.
The type of bridging covered in this section is called transparent bridging. There is another type of bridging, called source-routing bridging (SRB), that has a narrower focus and is not discussed here.
Creating a bridge between two routers is as simple as selecting which spanning-tree bridge protocol to use (almost always ieee) and then enabling a bridge group on the interfaces. In this example, Router 1 and Router 2 are connected via their serial interfaces (serial1); we create a bridge between the Ethernet interfaces on both routers. Here's the configuration for Router 1:
bridge 1 protocol ieee ! interface ethernet1 ip address 10.10.1.1 255.255.255.0 bridge-group 1 ! interface serial1 ip address 10.10.2.1 255.255.255.0 bridge-group 1
And here's the configuration for Router 2:
bridge 1 protocol ieee ! interface ethernet1 ip address 10.10.3.1 255.255.255.0 bridge-group 1 ! interface serial1 ip address 10.10.2.2 255.255.255.0 bridge-group 1
Now the two Ethernet segments are bridged using the serial links. The bridge numbers you assign are significant only to the local routerthey do not have to match across routers. However, keeping the numbers consistent across routers will keep your configurations simpler.
In this example, the routers will route IP but bridge everything else. By default, IP traffic is routed unless it is explicitly bridged. All other protocols are bridged unless explicitly routed. You must use the global command no ip routing to force IP to be bridged, which is probably not what you want. The first way around this problem is Concurrent Routing and Bridging.
13.1.1. Concurrent Routing and Bridging (CRB)
Concurrent Routing and Bridging (CRB) allows the router to route and bridge the same protocol. However, routing and bridging remain separate islands in the router and aren't allowed to interact. In other words, routing can be enabled on some interfaces, and bridging can be enabled on some other interfaces, but the two groups cannot interact. Each interface can either bridge a protocol or route a protocol, but not both; packets will never be transferred from the bridged interfaces to the routed interfaces. The next section discusses Integrated Routing and Bridging (IRB), which allows more interaction and is usually a better solution.
To configure CRB, we use the global command bridge crb. Once enabled, we list the protocols to bridge with the command bridge 1 route ip, where 1 is the bridge group number and ip is the name of the protocol we want to bridge. Obviously, you can use this command to select other protocols; for example, the command bridge 1 route appletalk bridges the AppleTalk protocol. The following example bridges IP traffic between the Ethernet interfaces ethernet0 and ethernet1 and routes IP traffic between the router's other interfaces, serial1 and serial2:
interface ethernet0 ip address 10.1.1.1 255.255.255.0 bridge-group 1 ! interface ethernet1 ip addess 10.1.2.1 255.255.255.0 bridge-group 1 ! interface serial1 ip address 10.1.3.1 255.255.255.0 ! interface serial2 ip address 10.1.4.1 255.255.255.0 ! bridge crb bridge 1 route ip bridge 1 protocol ieee
Remember that the routed traffic is isolated to the routed interfaces while the bridged traffic stays on the bridged interfaces. In other words, a packet can't make its way from ethernet1 to serial1, no matter where it ought to go.
13.1.2. Integrated Routing and Bridging (IRB)
CRB was a nice step toward Integrated Routing and Bridging, which allows routing and bridging to cooperate. IRB allows the router to route and bridge any protocol. In order to do this, we need a special interface called a BVI, which stands for Bridge-Group Virtual Interface. We create a BVI for each bridge group. The BVI is routable and handles all routing tasks for the entire bridge group. Our bridge group interfaces work at Layer 2 while the BVIs work at Layer 3. The router can now happily route and bridge our IP traffic at the same time, in accordance with the bridge-group configurations.
To enable IRB, we use the command bridge irb. Once this command has been issued, we can create a bridge group and specify which spanning-tree protocol to use (ieee). We specify that this bridge group is supposed to route IP. Then we configure the Ethernet interface without an IP address and place it in our bridge group. Finally, we configure the BVI1 interface, which has an IP address. In a more complex configuration, the BVI would also have commands for packet filtering, address translation, and other Layer 3 tasks. Here is an example of IRB in action.
The configuration for Router 1 looks like this:
hostname Router1 ! ! Enable Integrated Routing and Bridging bridge irb ! Allow routing of IP for bridge group 1 bridge 1 protocol ieee bridge 1 route ip ! interface Ethernet0 no ip address bridge-group 1 ! ! Configure our BVI for bridge group 1 interface BVI1 ip address 10.1.1.1 255.255.255.0
For Router 2, the configuration is:
hostname Router2 ! ! Enable Integrated Routing and Bridging bridge irb bridge 1 protocol ieee ! Allow routing of IP for bridge group 1 bridge 1 route ip ! interface Ethernet0 no ip address bridge-group 1 ! ! Configure our BVI for bridge group 1 interface BVI1 ip address 10.1.1.2 255.255.255.0
Now we can ping Router 1's BVI from Router 2:
Router2#ping 10.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms
13.1.3. Bridging show Commands
Depending on how your bridging is configured, most of the following show commands will be useful.
13.1.3.1. show bridge
This command displays the bridging table for each bridge group. This table includes the MAC addresses of the interfaces in the group, the interfaces associated with the addresses, and some other counters:
Router2#show bridge Total of 300 station blocks, 299 free Codes: P - permanent, S - self Bridge Group 1: Address Action Interface Age RX count TX count 0010.7b3a.f659 forward Ethernet0 0 16 0
13.1.3.2. show bridge group
This command gives you more detailed information about a particular bridge group.
Router2#show bridge group Bridge Group 1 is running the IEEE compatible Spanning Tree protocol Port 2 (Ethernet0) of bridge group 1 is forwarding
You can get even more detail using the verbose option:
Router2#show bridge group verbose Bridge Group 1 is running the IEEE compatible Spanning Tree protocol Acquisition of new addresses is enabled LAT service filtering is disabled Port 2 (Ethernet0) of bridge group 1 is forwarding LAT compression is not set Input LAT service deny group code list is not set Input LAT service permit group code list is not set Output LAT service deny group code list is not set Output LAT service Permit group code list is not set Access list for input filtering on type is not set Access list for input filtering for LSAP is not set Access list for input address filter is not set Access list for input pattern is not set Access list for output filtering on type is not set Access list for LSAP is not set Access list for output address filter is not set Access list for output pattern filter is not set Packets too large for translational bridging: 0 input, 0 output
13.1.4. DLSw+
DLSw+ stands for Data-Link Switching Plus, which is Cisco's proprietary extension to the open standard protocol DLSw Version 1. The second iteration of the open standard, DSLw Version 2, implements much of the same functionality as DLSw+. Fortunately, all three versions of DLSw interoperate fairly well because the first thing two peers do when connecting is to establish a common set of features, which they then use.
DLSw+ provides a method of transporting SNA (Systems Network Architecture) and other unroutable protocols such as NetBEUI over a different type of backbone, which in our case is IP.
Basically, we use the dlsw peer commands to define our local peer address and the remote peer address. Other than that, our example configuration looks much like our previous bridging example, which sets up a peer relationship for tunneling bridged traffic between the two endpoints.
Here's the configuration for Router 1:
bridge 1 protocol ieee ! ! Define our dlsw configuration dlsw local-peer peer-id 10.10.2.1 dlsw remote-peer 0 tcp 10.10.2.2 dlsw bridge-group 1 ! interface ethernet1 ip address 10.10.1.1 255.255.255.0 bridge-group 1 ! interface serial1 ip address 10.10.2.1 255.255.255.0 bridge-group 1
Here's the configuration for Router 2:
bridge 1 protocol ieee ! ! Define our dlsw configuration dlsw local-peer peer-id 10.10.2.2 dlsw remote-peer 0 tcp 10.10.2.1 dlsw bridge-group 1 ! interface ethernet1 ip address 10.10.3.1 255.255.255.0 bridge-group 1 ! interface serial1 ip address 10.10.2.2 255.255.255.0 bridge-group 1
Two important show commands for DLSw are show dlsw peers and show dlsw reachability. In show dlsw peers, the output shows the status of the DLSw remote peers because without a connection between the remote peers, DLSw won't work. The show dlsw reachability command shows the router's reachability cache, which it uses when it wants to initiate a connection to a report peer.
If the state is not CONNECT in the show dlsw peers command, check your IP connectivity before trying to debug DLSw setups.
The status in show dlsw reachability might be Found, Searching, Not_Found, Unconfirmed, and Verify. Found means the peer has sent or received a broadcast. Searching means the router has sent a broadcast to the peer and is awaiting a response. Not_Found means that negative caching is occurring and the peer has not responded to queries. Unconfirmed means that the peer is configured but DLSw has yet to verify it. Verify means that the cache information is about to expire, so the information is being verified.
router2#show dlsw peers Peers: state pkts rx pkts tx type drops ckts TCP uptime TCP 10.10.2.1 CONNECT 11 11 0 0 51 0:00:04:42 router2#show dlsw reachability DLSw MAC address reachability cache list Mac Addr status Loc. peer/port rif 0000.e341.109a SEARCHING LOCAL 0000.6a9a.7bea FOUND LOCAL TokenRing0/0 0CB0.0011.3E71.A041.0DE5.0640 0800.5a4b.10f0 SEARCHING LOCAL
Another great feature of DLSw+ is the ability to bridge SDLC to Ethernet or Token Ring, which makes the serial device look like a network device. By doing that, you save a whole lot of FEP (Front End Processor) interfaces in a mainframe network. SDLC stands for Synchronous Data link Control, which is a protocol for transferring data over a serial line.