Category: networking fundamentals

Last week, we discussed Fibre Channel addressing. This time, we’ll focus on data link layer technologies used in multi-access networks: Ethernet, Token Ring, FDDI, and other local area- or Wi-Fi technologies.

The first local area networks (LANs) ran on a physical multi-access medium. The first one (original Ethernet) started as a thick coaxial cable¹ that you had to drill into to connect a transceiver to the cable core.

Later versions of Ethernet used thinner cables with connectors that you put together to build whole network segments out of pieces of cable. However, even in that case, we were dealing with a single multi-access physical network – disconnecting a cable would bring down the whole network.

Whenever we talk about LAN data-link-layer addressing, most engineers automatically switch to the “must be like Ethernet” mentality, assuming all data-link-layer LAN framing must somehow resemble Ethernet frames.

That makes no sense on point-to-point links. As explained in Early Data-Link Layer Addressing article, you don’t need layer-2 addresses on a point-to-point link between two layer-3 devices. Interestingly, there is one LAN technology (that I’m aware of) that got data link addressing right: Fibre Channel (FC).

After covering the theoretical part of network addressing (part 2, part 3), let’s go into some practical examples. I’ll start with data link layer and then move on to networking and higher layers.

The earliest data link implementations that were not point-to-point links were multi-drop links and I mentioned them in the networking challenges part of the webinar. Initially, we implemented multi-drop links with modems, but even today you can see multi-drop in satellite communications, Wi-Fi, or in cable modems.

After discussing names, addresses and routes, and the various addresses we might need in a networking stack, we’re ready to tackle an interesting comment made by a Twitter user as a reply to my Why Is Source Address Validation Still a Problem? blog post:

Maybe the question we should be asking is why there is a source address in the packet header at all.

Most consumers of network services expect a two-way communication – you send some stuff to another node providing an interesting service, and you usually expect to get some stuff back. So far so good. Now for the fun part: how does the server know where to send the stuff back to? There are two possible answers¹:

After discussing names, addresses and routes, it’s time for the next question: what kinds of addresses do we need to make things work?

End-users (clients) are usually interested in a single thing: they want to reach the service they want to use. They don’t care about nodes, links, or anything else.

End-users might want to use friendly service names, but we already know we need addresses to make things work. We need application level service identifiers – something that identifies the services that the clients want to reach.

It always helps to figure out the challenges of a problem you’re planning to solve, and to have a well-defined terminology. This blog post will mention a few challenges we might encounter while addressing various layers of the networking stack, from data-link layer and all the way up to the application layer, and introduce the concepts of names, addresses and routes.

According to Martin Fowler, one of the best quotes I found on the topic originally came from Phil Karlton:

Dip Singh published an excellent primer on communication fundamentals including:

• Waves: frequency, amplitude, wavelength, phase
• Composite signals, frequency domain and Fourier transform
• Bandwidth, fundamental and harmonic frequency
• Decibels in a nutshell
• Transmission impairments: attenuation, distortion, noise
• Principles of modern communications: Nyquist theorem, Shannon’s law, bit and baud rate
• Line encoding techniques, quadrature methods (including QPSK and QAM)

Even if you don’t care about layer-1 technologies you MUST read it to get at least a basic appreciation of why stuff you’re using to read this blog post works.

After introducing the routing protocols and explaining the basics of link-state routing it was time for implementation considerations including:

• Collecting local endpoint reachability information
• Finding neighbors and exchanging the collected information (hint: a link-state topology database is just a distributed key-value store)
• Running the SPF algorithm (including partial SPF details) and installing the results

The Routing Protocols Overview part of How Networks Really Work webinar introduced the concepts of distance-vector and link-state routing protocols. Next step: the basics of link-state routing protocols.

The simplest way to implement layer-3 forwarding in a network fabric is to offload it to an external device¹, be it a WAN edge router, a firewall, a load balancer, or any other network appliance.

Sometimes it takes me years to answer interesting questions, like the one I got in a tweet in 2021:

Do you have a good article describing the one-to-one relation of layer-2 and layer-3 networks? Why should every VLAN contain one single L3 segment?

There is no mandatory relationship between multi-access layer-2 networks and layer-3 segments, and secondary IP addresses (and subnets) were available in Cisco IOS in early 1990s. The rules-of-thumb¹ claiming there should be a 1:1 relationship usually derive from the oft-forgotten underlying requirements. Let’s start with those.

Imagine you built a layer-2 fabric with tons of VLANs stretched all over the place. Now the users want to exchange traffic between those VLANs, and the obvious question is: which devices should do layer-2 forwarding (bridging) and which ones should do layer-3 forwarding (routing)?

There are four typical designs you can use to solve that challenge:

• Exchange traffic between VLANs outside of the fabric (edge routing)
• Route on core switches (centralized routing)
• Route on ingress (asymmetric IRB)
• Route on ingress and egress (symmetric IRB)

This blog post is an overview of the design models; we’ll cover each design in a separate blog post.

Henk made an interesting comment that finally triggered me to organize my thoughts about network-level host multihoming¹:

The problems I see with routing are: [hard stuff], host multihoming, [even more hard stuff]. To solve some of those, we should have true identifier/locator separation. Not an after-thought like LISP, but something built into the layer-3 addressing architecture.

Proponents of various clean-slate (RINA) and pimp-my-Internet (LISP) approaches are quick to point out how their solution solves multihoming. I might be missing something, but it seems like that problem cannot be solved within the network.

After discussing network addressing and switching, routing, and bridging in the How Networks Really Work webinar, it was high time for a deep dive into routing protocols, starting (as always) with an overview.

In this week’s update of the Data Center Infrastructure for Networking Engineers webinar, we talked about VLANs, VRFs, and modern data center fabrics.

Those videos are available with Standard or Expert ipSpace.net Subscription; if you’re still sitting on the fence, you might want to watch the how networks really work version of the same topic that’s available with Free Subscription – it describes the principles-of-operation of bridging fabrics that don’t use STP (TRILL, SPBM, VXLAN, EVPN)