Or: Repeaters, Bridges, and Routers, Oh My!
This section focuses on terminology and technology surrounding modern LAN interconnection. Given the qualifier, you can safely presume there will be no discussion of Source Route Bridging (SRB), translational bridging, or multiprotocol routing. When you’re bridging in a purely Ethernet environment there is no need to translate, and SRB is but a part of the dark Token Ring past that surfaces only to haunt humanity in the occasional bad dream.
Figure 1-11 shows the relationship of LAN interconnect devices to the OSI model.
Once again the OSI model shows its remaining utility. One simple figure makes it clear that repeaters operate at Layer 1, bridges at Layer 2, and routers at Layer 3. This means that repeaters spit bits, bridges frames, and routers packets. You cannot get to a packet without first dealing with the frame in which it was encapsulated. Thus, Figure 1-11 shows that routers process the Link and Physical layers. However, unlike a repeater or bridge, a router terminates both in its bid to obtain access to the inner Network layer packets, which are reframed and sent on the egress link.
Some key characteristics of each device are described in the following subsections.
As noted, a repeater is a Physical layer device that regenerates the signal to compensate for transmission losses and distortion. There was a time when repeaters were very common, as bridges and routers had not yet been invented, or were very slow store-and-forward-style boxes that were expensive in terms of both money and performance impact.
10Base-T and its related hubs were initially multiport repeaters. Such a repeater was sometimes call a bus in a box, given that it extended the collision domain and provided no filtering. Besides extending distance, repeaters also improved reliability through their partitioning functions. This feature would logically disconnect a segment that had a continuous carrier, a condition that could otherwise lock out the entire LAN.
Repeaters were associated with the handy 5 4 3 rule of thumb that indicates the maximum size of an Ethernet CD should consist of no more than five segments interconnected by four repeaters, of which only three of those segments can be multipoint; the remaining two are supposed to be repeater-only P-to-P links. These limits were intended to prevent issues with repeaters robbing bits from frames to the point where they would be deemed corrupted, and the added delays of longer transmission paths that impacted CD as a function of minimum transmission time. Repeaters propagate collisions, and therefore prevent FD operation.
The widespread use, and therefore low cost, of Ethernet switching has made the repeater a thing of the past. Who wants a bus in a box when you can get a switch in a box for the same price?
A bridge is a device that operates at Layer 2 and provides a filtering and forwarding function. Historically, bridges were store and forward, which meant the entire frame had to be received before it could be processed; the result was high latency and low packets per second (pps) rates. Modern bridges operate in a cut-through mode, which means they can begin processing and even forwarding a frame while it’s still being received.
At one point, the higher performance of cut-through was something to brag about, so vendors called such devices switches. Advances in silicon and design mean that now everything is switched, making the term switched somewhat ambiguous. Because routers and other devices can also operate in cut-through mode, it’s best to qualify such statements with the layer in question, as in “I have a Layer 3 switch” when referring to a router.
Ethernet bridging is transparent. This means that end stations are not aware of the bridge, and therefore they take no special steps to go from their local segment to a remote one. The bridge listens to all traffic, learns the source MAC addresses, and then filters and forwards based on the destination MAC address. The result is that known unicast traffic is only sent out of the port that leads to that device. Other stations do not see this traffic, which allows them to make their own transmissions at the same time, thereby increasing overall throughput.
Bridges used to be expensive; historically, they tended to offer only a few ports, and only some offered WAN interface support to offer remote bridging. Bridges terminate collision domains, which is what makes FD Ethernet, and remote bridging, possible. Because multiple stations can simultaneously transmit on different bridged segments, a bridge can also dramatically improve performance. In theory, a two-port bridge takes one big segment from 10 Mbps to two smaller ones, each with 10 Mbps.
Bridges operate at Layer 2. A bridge can support Ethernet, or Token Ring, or both in some manner or another. There is no such thing as an IP bridge. IP is inside a frame, and bridges do not make it that far. In similar fashion, there is no such thing as an Ethernet router. Ethernet, with its flat MAC addressing, is not routable and never will be. Figure 1-12 shows a bridge in operation.
Key in Figure 1-12 is the conveyance of entire frames, based on a MAC address database. Note that the payload can be any Upper Layer Protocol (ULP) and is not processed or inspected in the act of bridging. Also of note is that being transparent, the end stations are not aware of the bridge. As such, all stations believe they are on the same network from a Layer 3 perspective. This is shown by virtue of the same IP network 192.168.0.0/24 appearing on both sides of the bridge.
Given that the bridge bases its forwarding decisions on the MAC address, and that unknown MACs are flooded, or sent over all links except the link on which the frame was received, there is a definite issue with redundant/parallel links in a bridge’s environment. If both links are forwarding, such flooded traffic repeatedly ping-pongs back and forth. This is bad enough at Layer 3, but given that Layer 2 has no TTL mechanism to limit the number of iterations, the entire Layer 2 network can crash as a result of a broadcast storm.
Given the fatal result of a loop, it’s clear that transparent bridging, by its nature, must operate across a set of links that are known to be loop-free. To ensure that this was always the case a specific protocol known as Spanning Tree was invented. Spanning Tree Protocol (STP) operates between bridges and uses a number of parameters to guarantee that only one forwarding path is operational between all endpoints (we cover STP in detail in Chapter 6). STP is optional, but most bridges use it. STP simply blocks redundant links. If there is no redundancy there is nothing for STP to do, and it’s therefore not needed.
This section describes the basic operation of a transparent bridge. We cover most of these processing actions in more depth in subsequent chapters. Our goal here is to provide you with a big-picture overview to ensure that you keep sight of the forest despite all those trees.
- Listening
An STP-capable bridge first listens to determine the presence of other STP entities, and to determine whether, based on their parameters, the local port should be blocked or should transition to the learning state.
- Blocking
Based on the exchange of STP messages the port may be blocked. In the blocked state it does not learn, or forward. It continues to listen for STP messages to catch the case where a change in topology allows the local port to become unblocked.
- Learning
After leaving the listening or blocking state, a bridge port spends some time cramming for its big test by learning as many MAC addresses as it can. Bridges learn by promiscuously monitoring all traffic, and inspecting the Source MAC (SMAC) of each frame it sees. The goal of the learning delay is to prevent the flooding that occurs when a bridge has to forward an unknown MAC address. Learning is an ongoing process, and is also used to catch MAC moves, which is when an SMAC is found to ingress on a different interface.
- Filtering and forwarding
After building its MAC address table through promiscuous monitoring of all traffic, the bridge then filters and forwards traffic based on the Destination MAC (DMAC) address. The bridge inspects the DMAC of each frame it sees. When the DMAC is associated with a learned SMAC entry on the same port, the frame is filtered, as the target station should already have a copy. When the DMAC of the received frame is associated with a learned SMAC on a different port, the frame is forwarded out of that port only. When the DMAC is unknown, the bridge has to flood the frame, which is the act of sending a copy out of all ports, except the ingress. Ongoing flooding can impact network performance. The assumption is that as a result of the flood, the target station will reply, which then allows its SMAC to be learned so that subsequent traffic can be filtered and forwarded. This is often referred as transparent bridging.
Books on bridging usually walk through the transparent bridging and source route bridging models. In today’s networks, switches generally implement transparent bridging, as source route bridging was usually reserved for Token Ring networks, which you will have a hard time finding these days.
The rule of thumb used to be that a well-designed LAN had 80% of its traffic local to that segment/CD, and the other 20% switched to a remote location. The goal was to avoid the painful performance hit associated with bridges back in the day.
A modern star-wired Ethernet uses a switch with P-to-P-oriented link types to form a star-wired LAN. The effect is a shift to a 0/100 rule, and the switched rather than repeated nature means that each station is offered dedicated throughput based on its access speed. Thus, a 24-port GE switch can, in theory, offer each attached device a dedicated FD GE transmission link, and the aggregate throughput of the switch could be 48 Gbps! (That’s 24 Gig × 2 for FD.) I’m not trying to sound cranky, but back before the Great War we were happy with a shared 10 Mbps of HD throughput, and that wasn’t even guaranteed, given that collisions could bring that to zero if a large number of stations were attached.
Folks started shifting from repeaters to bridges as the technology matured. A few problems began to surface with large bridged internetworks. Some of these were:
No tolerance for loops and poor use of redundancy as only one path can be active.
No TTL mechanism, making loops fatal and causing a need for loop restriction.
No traceroute or ping. Troubleshooting a Layer 2 network is difficult, as things either work end to end, or they don’t. Transparency is great, until something is broken.
Not well suited to dissimilar network types/no fragmentation support.
No explicit CoS mechanism (until 802.1p), and then not finely grained.
No IP layer processing, and therefore no firewall filters or IP services such as IPSec or NAT.
Poor performance when there’s a lot of Broadcast, Unknown, or Multicast (BUM) traffic, flooded over all ports, much like a (slow) repeater.
Routers operate at Layer 3 and were seen as a solution to the aforementioned issues. The fact that routers are specific to each Network layer protocol created the need for Multiprotocol Routing (MPR) when more than one Network layer protocol was in use. Some protocol stacks were unroutable, as they either had no network layer, or in the case of SNA were connection-oriented and therefore had endpoint addressing present only during connection setup.
Figure 1-13 shows a router at work.
Key in Figure 1-13 is the fact that the same network packet is passed through the router, and that the router attaches to different networks. The Link layer is used to get packets to and from the router; at ingress the frame is stripped, and at egress a new one is built. The IP packet is processed by the router, but that packet flows all the way to the endpoint. The only change at the IP layer is a decremented TTL field, and the resulting updated header checksum.
Note that in the routed model the frame’s MAC layer always identifies a next hop on the local link. As a result, the frame on the first hop identifies the router’s MAC address, rather than that of the target station. ARP is not routable, and as such a station never attempts to ARP a remote destination. Note that if Figure 1-13 were based on bridges rather than routers, the two stations would be on the same network by definition. As such, the ARP exchange would pass through the bridge and operate end to end between the IP endpoints.
As routers began to get faster, the benefits of routing began to take their toll on bridging. The mantra Route when you can, bridge when you must developed to show this sentiment. In some cases, you had to bridge due to lack of routing support for that protocol on that router, or because the protocol itself was unroutable. The trend was to keep unroutable protocols local, to provide workgroup types of connectivity, and to only route across the WAN for backbone connectivity. Although this required more work to configure and set up, routers simply had too many advantages over bridges when all was said and done, especially at a large scale or in complex types of connectivity.
MPR became a drag, and even more so with the addition of each new routable protocol to an existing backbone. Although technically feasible, the world’s shift to IP transport did not come quickly enough to spare some from the resulting torment. Can anyone remember running Cisco’s EIGRP to simultaneously support IP, IPCX, and DDP? Or how about the alternative that had you run IP RIP, IPX RIP, and AppleTalk’s RTMP simultaneously to achieve the same thing (three separate routing tables, one for each protocol)?
The need to route AppleTalk is gone, and IBM’s SAA is now based on IP transport. Their respective applications live on, but they’re now provided via an IP infrastructure. The result is a renewed focus on all things IP, both in the routing and in the LAN switching fronts.
The migration to an IP-based world has led to some interesting side effects, such as bridges that are IP-aware. Such a device can inspect the IP payload of certain traffic to perform a service, such as validating an ARP request based on a previous Dynamic Host Configuration Protocol (DHCP) exchange. Although a violation of the layer principle, such capabilities are common for devices that can process at both Layer 2 and Layer 3, such as is the case with the Juniper EXs. You should avoid the temptation to refer to such a device as an L Brouter, however. The world already went there once, and it wasn’t fun. Many set off on the quest to find the definitive definition of that mythical beast; most have yet to return.
The modern state of LAN interconnect is all about IP routing over wide areas and Ethernet-based switching in the campus or workgroup. Most IP switches are also capable of IP routing. This gives you the freedom to bridge when you want and to route when you want, using the same device and in some cases the same interfaces. Talk about the best of all worlds: high-performance switching with IP-enabled features in the workgroup, with a high-performance routed IP backbone for communications with remote groups.
Get JUNOS Enterprise Switching now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
