How Routers Grew to become Bridges « ipSpace.web weblog

Community terminology was simple within the Nineteen Eighties: bridges forwarded frames between Ethernet segments primarily based on MAC addresses, and routers forwarded community layer packets between community segments. That nirvana couldn’t final lengthy; ultimately, a big-enough buyer advised Cisco: “I don’t need to purchase one other field if I have already got your too-expensive router. I need your router to be a bridge.”

Turning a router right into a bridge is less complicated than going the opposite manner spherical^{: add MAC desk and dynamic MAC studying, and spend a night implementing STP.}

Subsequent step: a configuration mechanism. Whereas bridge distributors tried to maintain issues so simple as potential (normally utilizing the plug-and-pray strategy), routers all the time needed to be configured. To allow bridging on a Cisco router, you needed to create bridge teams and assign interfaces to them.

That leaves only one difficult query: what occurs when somebody needs to configure routing and bridging on the identical interface? My reminiscence is hazy on this level (feedback appreciated), however I’ve a imprecise recollection of getting to determine what to do. You may configure IP/IPX/AppleTalk/… addresses on an interface or place the interface right into a bridge group, however not each. The enter packet processing was thus exceedingly easy:

• Did we obtain a packet on an interface inside a bridge group? Extract the vacation spot MAC handle and ahead the packet utilizing the corresponding MAC desk.
• Did we obtain a packet on another interface? Use the Ethernet protocol sort to determine the community layer protocol. Do a lookup within the corresponding forwarding desk to ahead the packet.

That easy world didn’t final lengthy. Somebody inevitably found out that it was simple to renumber IPX hosts (as a result of IPX all the time used a SLAAC-like mechanism^{) however unattainable to renumber IP hosts (as a result of DHCP hadn’t been invented but). Splitting a big IPX section into two was a no brainer; splitting an IP subnet was Mission Unimaginable.}

However what if we may route IPX and preserve the IP subnet intact by bridging IP^{? Welcome to Concurrent Routing and Bridging: we’ll route some protocols and bridge others. The change to the packet forwarding code was minimal:}

• Have a look at the Ethernet protocol sort.
• Use the protocol-specific forwarding desk if the protocol sort is a recognized network-layer protocol, and the router ought to route it.
• Bridge the packet in all different instances (a bridged network-layer protocol or an unknown protocol).

OK, so we may route one protocol (instance: IPX) throughout a set of interfaces and bridge one other (instance: IP) throughout the identical interfaces, however how may you join the bridged section to the skin world? Use a loopback cable to attach the bridged interfaces with one other routed interface. Yeah, we liked that as a lot because the youthful engineers liked utilizing exterior cables to attach M-series linecards to F-series linecards on Nexus 7000.

Closing answer: Built-in Routing and Bridging: Route site visitors despatched to router’s MAC handle, and bridge all the things else^.

To get there, one has to make use of the identical MAC handle (normally an additional MAC handle not belonging to any bodily interface) on all bodily interfaces belonging to the identical bridge group^{. You additionally want a solution to specify the IP handle belonging to the shared MAC handle, and as you normally configure the IP handle on an interface, you want an additional (digital) interface. And that’s how we bought Bridge Digital Interface (BVI) on Cisco IOS – the granddaddy of VLAN interfaces we’re utilizing on layer-3 switches.}

Surprise how we bought from BVI interfaces to VLAN interfaces? We should take a detour by the VLAN Forest of Despair to get there. Keep tuned.