How Routers Became Bridges
Network terminology was easy in the 1980s: bridges forwarded frames between Ethernet segments based on MAC addresses, and routers forwarded network layer packets between network segments. That nirvana couldn’t last long; eventually, a big-enough customer told Cisco: “I don’t want to buy another box if I already have your too-expensive router. I want your router to be a bridge.”
Turning a router into a bridge is easier than going the other way round1: add MAC table and dynamic MAC learning, and spend an evening implementing STP.
Next step: a configuration mechanism. While bridge vendors tried to keep things as simple as possible (usually using the plug-and-pray approach), routers always had to be configured. To enable bridging on a Cisco router, you had to create bridge groups and assign interfaces to them.
That leaves just one tricky question: what happens when someone wants to configure routing and bridging on the same interface? My memory is hazy on this point (comments appreciated), but I have a vague recollection of having to decide what to do. You could configure IP/IPX/AppleTalk/… addresses on an interface or place the interface into a bridge group, but not both. The input packet processing was thus exceedingly simple:
- Did we receive a packet on an interface within a bridge group? Extract the destination MAC address and forward the packet using the corresponding MAC table.
- Did we receive a packet on any other interface? Use the Ethernet protocol type to figure out the network layer protocol. Do a lookup in the corresponding forwarding table to forward the packet.
A router performing independent routing and bridging
That simple world didn’t last long. Someone inevitably figured out that it was easy to renumber IPX hosts (because IPX always used a SLAAC-like mechanism2) but impossible to renumber IP hosts (because DHCP hadn’t been invented yet). Splitting a large IPX segment into two was a no-brainer; splitting an IP subnet was Mission Impossible.
But what if we could route IPX and keep the IP subnet intact by bridging IP3? Welcome to Concurrent Routing and Bridging: we’ll route some protocols and bridge others4. The change to the packet forwarding code was minimal:
- Look at the Ethernet protocol type.
- Use the protocol-specific forwarding table if the protocol type is a known network-layer protocol, and the router should route it.
- Bridge the packet in all other cases (a bridged network-layer protocol or an unknown protocol).
Protocol-based Concurrent Routing and Bridging (CRB)
OK, so we could route one protocol (example: IPX) across a set of interfaces and bridge another (example: IP) across the same interfaces, but how could you connect the bridged segment to the outside world? Use a loopback cable to connect the bridged interfaces with another routed interface. Yeah, we loved that as much as the younger engineers loved using external cables to connect M-series linecards to F-series linecards on Nexus 7000.
Final solution: Integrated Routing and Bridging: Route traffic sent to router’s MAC address, and bridge everything else5.
To get there, one has to use the same MAC address (usually an extra MAC address not belonging to any physical interface) on all physical interfaces belonging to the same bridge group6. You also need a way to specify the IP address belonging to the shared MAC address, and as you usually configure the IP address on an interface, you need an extra (virtual) interface. And that’s how we got Bridge Virtual Interface (BVI) on Cisco IOS – the granddaddy of VLAN interfaces we’re using on layer-3 switches.
Integrated Routing and Bridging (IRB)
Wonder how we got from BVI interfaces to VLAN interfaces? We must take a detour through the VLAN Forest of Despair to get there. Stay tuned.
Next: VLAN Interfaces and Subinterfaces Continue
-
As many bridge vendors discovered when they tried to build routers to compete with Cisco (and failed), resulting in ridiculous concoctions like brouters. ↩︎
-
You didn’t think IPv6 designers invented everything from scratch, did you? ↩︎
-
The correct solution would be to use IP routing based on host addresses, but Local Area Mobility hasn’t been invented yet. Decades later, we’re going through the same conundrum – another clear win for RFC 1925. ↩︎
-
You could try configuring IP addresses on individual interfaces in the bridge group and bridge IP simultaneously, but it usually didn’t end well. ↩︎
-
Ignoring IP multicast – that’s a juicy can of worms I’m not going to touch anytime soon. ↩︎
-
The proof is left as an exercise for the reader ↩︎
I always had a bad joke in the early days of IPv6, that it should be rather named IPXv2. :-)
Unfortunately it's not a joke. They took numerous ideas from IPX and implemented them badly.
In the IPX era nobody was talking about addressing (I mean users). They were simply focused on services like file server, print server, etc. When you add to the equation the boot-rom based NIC card we could automatically load the OS do the PC. Deployed many networks where there was no IT staff... Talking about 90-ties (beginning). The simplicity was striking. Also in the approach to IPX addressing.
Novell also introduced IP/IPX gateway around NetWare 4.11 to use single protocol (IPX) internally...
So true about IPX. I have been in networking since 1986, older Netware and Arcnet and remember the early 90s building/supporting multi protocol networks in large enterprises. You can build any size to large IPX networks with non of those pesky subnet masks and NAT etc.
By its end IPX/SPX eventually had improvements such service discovery advertisements, improved broadcast reduction and SPX ack/flow enhancements to reduce chattiness. The issue with IPX/SPX was, for at it's time, it was a chatty, heavy protocol running on, again at its peak, 10-16mb network or 1gig Ethernet.
Now imagine it had prevailed during the early/mid 90s protocol wars, supporting the internet and 2k and it lasted to today with us running it on commodity 10gig copper and high speed wifi and that may be another story.