# networking fundamentals Published articles for networking fundamentals. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## On MPLS Paths, Tunnels and Interfaces DevFeed: [On MPLS Paths, Tunnels and Interfaces]() Original publisher: [Read original article]() Published: 2026-01-20T06:29:00Z Content type: opinion Language: en Sources: [ipSpace.net blog]() Topics: [Network](), [MPLS-TE](), [Routing (disambiguation)](), [IP routing](), [Protocol (disambiguation)](), [VXLAN]() Tags: [gre](), [ip-routing](), [mpls](), [network](), [networking-fundamentals](), [protocol](), [routing](), [vxlan]() ### AI overview The article explains the fundamental difference between overlay tunnels such as GRE, IPsec, and VXLAN and MPLS paths. Tunnels connect separate overlay segments across an underlay, while MPLS paths improve forwarding within the same network; routing protocols are used differently in these designs. ### Source excerpt One of my readers attempted to implement a multi-vendor multicast VPN over MPLS but failed. As a good network engineer, he tried various duct tapes but found that the only working one was a GRE tunnel within a VRF, resulting in considerable frustration. In his own words: How is a GRE tunnel different compared to an MPLS LSP? I feel like conceptually, they kind of do the same thing. They just tunnel traffic by wrapping it with another header (one being IP/GRE, the other being MPLS). Instead of going down the "how many angels are dancing on this pin" rabbit hole (also known as "Is MPLS tunneling?"), let's focus on the fundamental differences between GRE/IPsec/VXLAN tunnels and MPLS paths. Read more ... ## Finding Source Routing Paths DevFeed: [Finding Source Routing Paths]() Original publisher: [Read original article]() Published: 2025-06-13T06:10:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [networking](), [Software-defined networking](), [Network architectures](), [IS-IS]() Tags: [is-is](), [management](), [network](), [networking](), [networking-fundamentals](), [ospf](), [protocol](), [routing](), [sdn](), [software]() ### AI overview This tutorial explains how source-routing paths are determined and installed across networks. It examines centralized controller-based routing, SDN and OpenFlow, and segment routing with Path Computation Elements, then compares these approaches with older virtual-circuit provisioning systems. ### Source excerpt In the previous blog post, we discussed the generic steps that network devices (or a centralized controller) must take to discover paths across a network. Today, we'll see how these principles are applied in source routing, one of the three main ways to move packets across a network. Brief recap: In source routing, the sender has to specify the (loose or strict) path a packet should take across the network. The sender thus needs a mechanism to determine that path, and as always, there are numerous solutions to this challenge. We'll explore a few of them, using the sample topology shown in the following diagram. Read more ... ## Finding End-to-End Paths: Topology and Endpoints DevFeed: [Finding End-to-End Paths: Topology and Endpoints]() Original publisher: [Read original article]() Published: 2025-06-06T05:51:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [networking](), [Routing (disambiguation)](), [Network design]() Tags: [arp](), [bridging](), [dhcp](), [discovery](), [ipv4](), [ipv6](), [network](), [networking-fundamentals](), [router](), [routing]() ### AI overview This article explains how networks discover topology and endpoints, build forwarding tables, and adapt end-to-end paths when links or nodes fail. It contrasts complete topology views in link-state protocols with local-neighbor knowledge in distance-vector protocols, and describes learning mechanisms including bridging, ARP, DHCP, and ICMPv6 Neighbor Discovery. ### Source excerpt We know there are three main ways to move packets across a network. However, before we can start forwarding packets, someone has to populate the forwarding tables in the intermediate devices or build the sequence of nodes to traverse in source routing. Usually, whoever is responsible for the contents of the forwarding tables must first discover the network topology. Let's start there, using the following network diagram to illustrate the discussion. Read more ... ## Multi-Layer Switching and Tunneling DevFeed: [Multi-Layer Switching and Tunneling]() Original publisher: [Read original article]() Published: 2025-05-30T06:20:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [networking](), [Routing (disambiguation)](), [MPLS-TE](), [BGP](), [Ethernet](), [Protocol (disambiguation)]() Tags: [bgp](), [ethernet](), [mpls](), [mpls-te](), [networking](), [networking-fundamentals](), [protocol](), [router](), [routing](), [switching]() ### AI overview The article explains multi-layer switching, where edge devices forward traffic at a higher networking layer while core devices forward it at a lower layer. It describes IP forwarding over bridged Ethernet and virtual-circuit-like approaches using MPLS, MPLS-TE, BGP, and segment routing. ### Source excerpt When deep-diving into the confusing terminology of switching, routing, and bridging, I mentioned you could perform packet forwarding at different layers of a networking stack. In this blog post, we'll explore what happens when we combine packet forwarding on multiple layers within a single network, resulting in multi-layer switching, where edge devices perform Layer n forwarding (usually Layer 3), and core devices perform Layer n-1 forwarding (typically Layer 2). Each layer can use any forwarding paradigm you choose. However, since we generally use IP at Layer 3, edge devices typically perform hop-by-hop destination-based forwarding, while core devices can use alternative methods. Read more ... ## Response: True Unnumbered Interfaces DevFeed: [Response: True Unnumbered Interfaces]() Original publisher: [Read original article]() Published: 2025-05-22T05:55:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [IS-IS](), [networking](), [Linux](), [Routing (disambiguation)]() Tags: [configuration](), [interface](), [ip-routing](), [ipv4](), [ipv6](), [is-is](), [linux](), [networking-fundamentals](), [ospf](), [protocol](), [router](), [routing]() ### AI overview This article explains why routers commonly associate IP addresses with interfaces and examines how IS-IS handles unnumbered interfaces. It contrasts IS-IS with OSPF and describes IPv4 next-hop requirements, IPv6 link-local operation, and implementation-specific approaches such as those used by EBGP. ### Source excerpt Hendrik left an interesting comment on my Running IS-IS over Unnumbered Ethernet Interfaces blog post: FRRouting (Linux) with pure IS-IS, the only way it currently (10.3) works is to copy the loopback IPv4 address to the interfaces that you need to do IPv4 routing on. The OpenFabric (IS-IS "extension" draft) does support true unnumbered interfaces and routes IPv6. Let's unpack this. There are (at least) four reasons a router needs an address associated with an interface1: Read more ... ## Forwarding Packets Across a Network DevFeed: [Forwarding Packets Across a Network]() Original publisher: [Read original article]() Published: 2025-05-08T06:20:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [Networks](), [networking](), [Network](), [Routing (disambiguation)]() Tags: [bridging](), [networking-fundamentals](), [networks](), [routing](), [switching]() ### AI overview This article explains how packets move across networks after a single cable is divided by an intermediate network device. It introduces source routing and path-based forwarding, while contrasting bridging, routing, and switching terminology. ### Source excerpt After inspecting the confusing bridging/routing/switching terminology and a brief detour into the control/data plane details, let's talk about how packets actually move across a network. As always, things were simpler when networks were implemented with a single cable. In that setup, all nodes were directly reachable, and the only challenge was figuring out the destination node's address; it didn't matter whether it was a MAC address, an IP address, or a Fiber Channel address. On a single cable, you could just broadcast, like, "Who has this service?" and someone would reply, "I'm the printer you're looking for." That's how many early non-IP protocols operated. Read more ... ## Switching, Routing, and Bridging Terminology DevFeed: [Switching, Routing, and Bridging Terminology]() Original publisher: [Read original article]() Published: 2025-04-25T05:45:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [networking](), [Routing (disambiguation)](), [Network]() Tags: [bridge](), [network](), [networking](), [networking-fundamentals](), [router](), [routing](), [switching]() ### AI overview This article explains networking terminology for moving packets across a network. It distinguishes forwarding, switching, routing, and bridging, describes hubs, bridges, and routers, and introduces different forwarding paradigms, including virtual circuits and segment routing. ### Source excerpt After discussing networking layers and addressing, it's time to focus on moving packets across a network. Vendors love to use ill-defined terms like switching instead of forwarding, routing, or bridging, so let's start with the terminology. Connecting all relevant devices to a single cable would indubitably simplify any networking stack, but unfortunately, we're almost never that lucky. We need devices in the network (typically with multiple interfaces) that perform packet forwarding between end nodes. Read more ... ## Comparing IP and CLNP: Local (Node) Multihoming DevFeed: [Comparing IP and CLNP: Local (Node) Multihoming]() Original publisher: [Read original article]() Published: 2025-04-02T07:21:00Z Content type: comparison Language: en Sources: [ipSpace.net blog]() Topics: [networking](), [Networks](), [Protocol (disambiguation)](), [Routing (disambiguation)](), [Firewall](), [Mainframe]() Tags: [firewall](), [ibm](), [ip](), [networking-fundamentals](), [networks](), [protocol](), [routing](), [stateful](), [tcp](), [tcp-ip]() ### AI overview The article compares local node multihoming in IP/TCP/IP and CLNP. It explains that TCP/IP multihomed hosts use multiple IP addresses and lack a single well-defined behavior, with strong and weak end-system models leading to routing asymmetry and complications for stateful firewalls. It describes loopback addressing and routing advertisements as a TCP/IP solution. The supplied excerpt is incomplete. ### Source excerpt Another area where CLNP is a clear winner when compared to the TCP/IP stack is multi-homed nodes (nodes with multiple interfaces, not site multi-homing, where whole networks are connected to two upstream providers). Multi-homed TCP/IP nodes must have multiple IP addresses because IP uses address interfaces. There is no well-defined procedure in TCP/IP for how a multi-homed node should behave. In the early days of TCP/IP, they tried to address that in RFC 1122 (Host Requirements RFC), but even then, there were two ideas about dealing with multiple interfaces: the strong and weak end system models (more details). Read more ... ## Comparing IP and CLNP: Network State Summarization DevFeed: [Comparing IP and CLNP: Network State Summarization]() Original publisher: [Read original article]() Published: 2025-03-19T06:59:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [IP routing](), [networking](), [IS-IS](), [Protocol (disambiguation)](), [BGP]() Tags: [bgp](), [ip-routing](), [ipv6](), [is-is](), [networking-fundamentals](), [routing](), [tcp-ip]() ### AI overview This article compares how TCP/IP and CLNP summarize network state in routing protocols. It explains that TCP/IP routing generally provides subnet, intra-area, and inter-area summarization levels, while most CLNP networks used two levels based on node and area addresses, with BGP enabling additional levels in either design. ### Source excerpt In the previous blog posts, we discussed how TCP/IP and CLNP reach adjacent nodes and build ARP/ND/ES caches and how they reach off-subnet nodes. Now, let's move from the network edge into the network core and explore how the two protocol stacks reduce the amount of information they have to propagate in routing protocols. While I'm not exactly an OSI fan, I must admit they got many things right (and IPv6 copied those ideas), but TCP/IP is a clear winner in this aspect. Read more ... ## Comparing IP and CLNP: Reaching Off-Subnet Nodes DevFeed: [Comparing IP and CLNP: Reaching Off-Subnet Nodes]() Original publisher: [Read original article]() Published: 2025-03-05T07:08:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [TCP/IP](), [networking](), [DHCP](), [Load Balancing]() Tags: [cisco](), [dhcp](), [ip](), [ipv4](), [ipv6](), [load-balancing](), [networking-fundamentals](), [routing]() ### AI overview This article compares how TCP/IP and CLNP identify a first-hop router for traffic to off-subnet nodes. It describes IPv4 default routes, DHCP configuration, first-hop redundancy protocols, and CLNP Intermediate System Hellos. ### Source excerpt The previous blog post in this series discussed how TCP/IP and CLNP reach adjacent nodes and build ARP/ND/ES caches. Now let's move one step further: how do nodes running IPv4/IPv6 or CLNP discover the first-hop router that could forward their traffic to off-subnet nodes they want to communicate with? Read more ... ## Comparing IP and CLNP: Finding Adjacent Nodes DevFeed: [Comparing IP and CLNP: Finding Adjacent Nodes]() Original publisher: [Read original article]() Published: 2024-10-17T07:10:00Z Content type: comparison Language: en Sources: [ipSpace.net blog]() Topics: [networking](), [TCP/IP](), [Protocol (disambiguation)](), [data]() Tags: [arp](), [interfaces](), [ip](), [ipv4](), [ipv6](), [network](), [networking](), [networking-fundamentals](), [protocol](), [tcp](), [tcp-ip]() ### AI overview The article compares TCP/IP and CLNP approaches to finding adjacent nodes. TCP/IP uses subnet masks to determine whether a destination is directly reachable and ARP or Neighbor Discovery to resolve the destination link-layer address, while CLNP nodes advertise NSAP addresses through hello messages that neighboring nodes cache. ### Source excerpt Now that we know a bit more about addresses in a networking stack (read the whole series) and why CLNP uses node addresses while TCP/IP uses interface addresses, let's see how they solve common addressing problems like finding adjacent nodes. Let's start with the elephant in the room: how do you know whether you can reach a host you want to communicate with directly? In the following diagram, how does A know whether B is sitting next to it? Read more ... ## OSI Layers in Routing Protocols DevFeed: [OSI Layers in Routing Protocols]() Original publisher: [Read original article]() Published: 2024-03-26T05:53:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [Routing (disambiguation)](), [networking](), [Protocol (disambiguation)](), [IS-IS](), [BGP]() Tags: [bgp](), [is-is](), [networking-fundamentals](), [networks](), [protocol](), [routing]() ### AI overview The article explains how routing protocols map across the seven OSI layers. It clarifies that IS-IS uses its own network layer, while protocols such as OSPF, EIGRP, RIP, and BGP use different transport mechanisms and implement session, presentation, and application-layer functions. ### Source excerpt Now and then, someone rediscovers that IS-IS does not run on top of CLNP or IP and claims that, therefore, it must be a layer-2 protocol. Even vendors' documentation is not immune. Interestingly, most routing protocols span the whole seven layers of the OSI stack, with some layers implemented internally and others offloaded to other standardized protocols. Read more ... ## Network Layer: Interface or Node Addresses DevFeed: [Network Layer: Interface or Node Addresses]() Original publisher: [Read original article]() Published: 2024-02-19T10:22:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [networking](), [Protocol (disambiguation)]() Tags: [interface](), [interfaces](), [network](), [networking-fundamentals](), [protocol]() ### AI overview This article examines whether network-layer addresses should identify entire nodes or individual interfaces. It contrasts IP's subnet-based interface addressing with CLNP's node-based addressing and introduces a broader comparison of the trade-offs between the two models. ### Source excerpt The fun question about network layer addresses is: are we addressing nodes or individual node interfaces? On the data link layer, we never had this issue because it was obvious that a data link layer endpoint is an interface, so each interface should have a unique data link layer address. Interestingly, that's not the case on transparent bridges. Even though they have multiple interfaces, the whole bridge has a single MAC address, so one could claim we're addressing nodes connected to a single data link layer. The IEEE standard is unambiguous: in every relevant diagram, the MAC address sits on top of multiple interfaces because the MAC address belongs to the control plane. Read more ... ## Can We Skip the Network Layer? DevFeed: [Can We Skip the Network Layer?]() Original publisher: [Read original article]() Published: 2024-02-12T09:52:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [Network](), [Ethernet](), [Protocol (disambiguation)](), [Terminal]() Tags: [boot](), [bridging](), [complexity](), [cycles](), [digital](), [ethernet](), [memory](), [network](), [networking-fundamentals](), [physics](), [protocol](), [run]() ### AI overview The article examines proposals to omit network-layer addressing from local solutions by using Ethernet data-link addresses with transport protocols directly above them. It recounts how DEC's LAT and MOP protocols placed local terminal services over Ethernet, and explains how requirements spanning multiple Ethernet segments exposed the approach's limitations and led to transparent bridging. ### Source excerpt I mentioned that you don't need node addresses when dealing with only two entities. Now and then, someone tries to extend this concept and suggests that the network layer addressing isn't needed if the solution is local. For instance, if we have a solution that is supposed to run only on a single Ethernet segment, we don't need network layer addressing because we already have data link layer addresses required for Ethernet to work (see also: ATAoE). Too often in the past, an overly ingenious engineer or programmer got the idea to simplify everyone's life and use the data link layer addresses as the ultimate addresses of individual nodes. They would then put the transport layer on top of that to get reliable packet transport. Finally, put whatever application on top of the transport layer. Problem solved. Read more ...