Building network automation solutions

9 module online course

Start now!

Router Interfaces and Switch Ports

When I started implementing the netlab VLAN module, I encountered (at least) three different ways of configuring physical interfaces and bridging domains even though the underlying packet forwarding operations (and sometimes even the forwarding hardware) are the same. That confusopoly is guaranteed to make your head spin for years, and the only way to figure out what’s going on behind the scenes is to go back to the fundamentals.

As is often the case in networking, we got to this morass because vendors believe in “doing more with less"1. As they added bridging functionality to routers or routing functionality to bridges (devices often called switches by product marketing), they rarely changed the terminology or configuration syntax, starting with the way we call those thingies into which we plug cables.

Routers Have Interfaces

Decades ago, we called the thingy sitting between a computer and a cable an interface because that’s what it was – an interface between software running on the computer and hardware transporting bits between computers.

If a node had more than one interface and could forward packets between those interfaces, we called it a router2. Please note that router interfaces could use different layer-2 technologies, for example Ethernet and Token Ring for LAN connections and Frame Relay or ATM for WAN connections.

A firewall was just a router with more-or-less stateful packet filters inserted in the packet forwarding path, and we called load balancers proxy servers.

Now you know why you’re configuring interfaces on hosts, routers, firewalls, and load balancers.

Hubs and Bridges Had Ports

Life was simple (terminology-wise) as long as networking meant connecting your node to an external device that magically transported bits between two or more directly-connected nodes. Local area networks changed all that – suddenly, you could plug a cable directly into your node and start sending packets.

Those cables had physical limitations. For example, the thin coax cable used in early Ethernet networks could not be longer than 185 meters due to signal degradation across longer distances. At the same time, the maximum distance between two nodes on a single Ethernet network (dictated by the collision detection logic) could be significantly larger. A solution was obvious (and used for decades in telephony networks): use a repeater (also called a hub) that would regenerate the signal. The IEEE Ethernet standard allowed you to use up to four repeaters between two stations.

It made no sense to call the hub cable attachment points interfaces because there was nothing behind them but a bit repeater, so we called them ports. Contrary to routers, hubs used the same layer-2 technology on all ports.

When DEC introduced bridges (one of the worst decisions ever made in networking), they decided to use the hub terminology – bridges had ports.

The Switching Confusion

Renaming bridges to switches was a pure marketing decision and never went beyond rebranding the devices and creating new marketing collaterals. The configuration mechanisms and the technical documentation didn’t change a bit – like bridges, the original (layer-2) switches had ports.

Eventually, someone implemented layer-3 forwarding in an ASIC, and the obvious way to market that device was to call it a layer-3 switch even though it should have been called a router3… but what do you call a cable attachment point on that device? Is it a port or an interface? Welcome to the switching terminology hell.

A layer-2 switch (bridge) has ports. A layer-3 switch (a router) has interfaces, but it could do bridging and routing simultaneously, in which case it has both. That’s why you have switchport configuration command in Cisco IOS, Nexus OS, and Arista EOS – it means “I want to treat this physical interface as a bridge port.” Likewise, the no switchport configuration command means “I want to treat this physical interface as a router interface.” So far, so good, but why do we have SVI interfaces and VLAN subinterfaces?

To get there, we will have to walk through the strange land of routers doing bridging and take a detour through the VLAN Forest of Despair. Stay tuned.

Next: How Routers Became Bridges Continue


  1. In reality: never refactor working code when an awkward kludge could do. ↩︎

  2. If you’re old enough, you might remember misconfiguring OSPF and turning an IBM mainframe into the most expensive router you’ve ever seen ↩︎

  3. At that point, the bridge vendors calling their devices switches loudly sang the “switching is good, routing is bad” mantra for years. They couldn’t possibly call their new gizmo a router. ↩︎

Blog posts in this series

Add comment
Sidebar