Ethernet and IP Networking 101
iximiuz.com
iximiuz.com
Use of repeater instead of hub (although he does use repeater hub in the collision domain section) would probably cause confusion with many since the term "repeater" is very rarely used (except for the EARLY days); hubs had far greater usage than repeater.
More problematic for me is liberal use of bridge, especially when there are multiple connections. I think his diagrams would be more useful if he established early on that a switch is just a fancy multi-port bridge, and then just use switch for bridge from then on. I get where he was going, but if you are trying to reach more of a layman audience then sticking to more "trade" terminology would probably be less confusing to potential readers.
> But whether we call the device a bridge or a switch—and the network you build an extended LAN or a switched Ethernet—the two behave in exactly the same way.
Which is to say the difference between an Ethernet switch and an Ethernet bridge is its name rather than its behavior.
They also correctly note that "switch" and "switching" are more abstract terms that apply to a wide range of devices (which would seem to make "bridge" and "bridging" a bit more precise and descriptive.)
In my own experience the bridge term is still commonly used by networking practitioners to describe the devices, and transparent bridging is used to describe the behavior, e.g. 802.1D.
> Ethernet bridging technology was first delivered in the mid-1980s, typically in the form of a two-port devices that could help segment a large Ethernet into separate Ethernet Lans. The devices linked two LANs, forming a bridge between them, hence the name. […] A device with more than two ports of bridging became know as a switching hub. Nowadays, even two-port bridges are often called switches.
> At their most basic level of moving frames from one LAN to another, bridges and switching hubs operate identically. The major difference is in the increased number of ports and the enhanced capabilities of switching hubs, which led to a change in the marketing of these devices. Vendors wanted some way to differentiate a low-end bridge that just does basic bridging from the more expensive and flexible switching hub products that provide many more ports and more capabilities than basic bridges.
Circling back to Chapter 2:
> There is another kind of hub called a switching hub. Switching hubs use the 48-bit Ethernet destination addresses to make a frame forwarding decision from one port of the switch to another. As shown in Figure 2-3, each port of a switching hub provides a connection to an Ethernet media system that functions as entirely separate Ethernet LAN.
* https://www.oreilly.com/library/view/ethernet-the-definitive...
There's a second edition of the book (2014):
* https://www.oreilly.com/library/view/ethernet-the-definitive...
as well as the book Ethernet Switches:
* https://www.oreilly.com/library/view/ethernet-switches/97814...
Communication between any two different L3 segments usually but not always requires a router. If the gateway on a host is configured to be the ip address of the host itself then the host will issue arp requests for any ip addresses it is trying to reach. In this manner hosts on different L3 segments but the same L2 segment can directly communicate. Some DHCP servers including the Microsoft DHCP server could be configured to always assign hosts the same gateway address as host ip address.
You don't mention L3 switches which in today's context makes sense because most L3 switches are really just L2 switches with built in routing capabilities but this wasn't always the case.
Cabletron used to be a major ethernet switch vendor. Their L3 switching solution included a server connected to certain of their switches. This server communicated directly with the switch and was responsible for a variety of tasks regarding vlans. One of these was the Layer 3 switching function. Hosts connected to the switch were configured with the same gateway as their ip address. As mentioned above this caused them to make an arp request for any ip addresses not already in their arp table. The switch would forward any arp requests passing through it to the management server. This management server had its own table of L2 to L3 address mappings for all devices connected to the switch. If the requested address was in this table the server would respond to the ARP request with the correct MAC address. The host would then use this MAC address for the ip address and the switch could properly direct the ethernet frame to the correct port regardless of L2 segment.
If the server couldn't resolve the L3 to L2 address mapping it would have the switch forward the arp request to ports which in the server software had been designated as router ports. The routers connected to these ports needed to have ProxyARP enabled. These routers would then respond to the ARP request and the host would send packets for the ip address to the router which had responded.
This is a little simplified because there were additional rules which could be configured regarding VLANs and which could take advantage of this between each other. Also the server could connect to multiple servers at a time spanning this across a multiple switch deployment.