--- title: "What Layer 3 Switching Adds to an Ethernet Fabric" description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20." canonical: "https://www.leviathansystems.co/articles/ethernet-mac-forwarding-versus-ip-next-hop" last-updated: "2026-10-20" --- # What Layer 3 Switching Adds to an Ethernet Fabric Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20. Layer 3 switching adds IP routing to a device that can also perform Ethernet switching. A bridge uses a frame's destination MAC address within its bridge domain to select an output; a routed IPv4 packet also needs a destination-IP lookup that selects a next hop and outgoing interface. Ethernet delivery then needs that next hop's MAC address. A connected port, a learned host MAC and an installed IP route therefore answer different parts of a GPU-network requirement. ## Identify the added routed decision An Ethernet fabric offer needs to explain which forwarding functions it delivers. The chassis and its physical interfaces provide a platform. Ethernet bridging and IP routing describe decisions made using different addresses. Calling the equipment a Layer 3 switch identifies a routing capability, while the proposed network determines where that capability is used. Cisco's Nexus 9000 NX-OS Interfaces Configuration Guide, Release 10.6(x), illustrates the distinction. Its Layer 3 chapter, updated July 21, 2026, describes physical ports with Layer 2 or Layer 3 roles and a switch virtual interface, or SVI, connecting a VLAN to the routing engine on the same device. A device can therefore support both functions without every physical port being a routed interface. Read that as a release-specific illustration. Applicability to an offered system requires its exact hardware, software and supported feature combination. The examples below explain classical Ethernet bridging and ordinary destination-based unicast IPv4 forwarding; they exclude NAT, tunnels and source-routing options. They do not prescribe an ASIC pipeline or a network configuration. References: [C2](https://www.cisco.com/c/en/us/td/docs/dcn/nx-os/nexus9000/106x/configuration/interfaces/cisco-nexus-9000-series-nx-os-interfaces-configuration-guide-release-106x/m_configuring_layer_3_interfaces_9x.html) ## Learn from the source, look up the destination In ordinary dynamic Ethernet learning, a received frame teaches the bridge where its source MAC is reachable. The bridge associates that source with the ingress port in the relevant VLAN or bridge domain. Forwarding uses a different field: the frame's destination MAC. Cisco's Nexus 9000 NX-OS Layer 2 Switching Configuration Guide, Release 10.6(x), describes source-address learning, flooding an unknown destination within the same VLAN, and subsequent forwarding to one port after the destination has been learned. Learning the sender does not simultaneously learn the receiver. A MAC entry also identifies a local forwarding relationship; it does not supply an IP route to every network that the sender might want to reach. References: [C1](https://www.cisco.com/c/en/us/td/docs/dcn/nx-os/nexus9000/106x/configuration/layer-2-switching/cisco-nexus-9000-series-nx-os-layer-2-switching-configuration-guide-106x/m-configuring-layer-2-switching.html) ## Follow a frame through four ports Fictional case EF-01 first stipulates one classical VLAN with exactly four forwarding ports: port 1, port 2, port 3 and port 4. All are eligible for the forwarding described here, with no special suppression or policy. Station A is reached through port 1 and station B through port 3. Their unicast MACs are called MAC-A and MAC-B. These states and the separate routed example that follows are invented premises, not observations from equipment. A frame from MAC-A to MAC-B arrives at port 1 while MAC-B is unknown. Learning records MAC-A against port 1. Destination lookup still has no entry for MAC-B, so this frame has three eligible other outputs: ports 2, 3 and 4. The ingress port is excluded. When B replies through port 3, the bridge learns MAC-B against port 3. Its destination lookup for MAC-A selects port 1. A later frame from A to B can select port 3 alone while that entry remains usable. Three flooded copies and one selected output are different outcomes of Ethernet destination lookup under the stipulated conditions. Neither count describes an IP next hop or establishes routed reachability. References: [C1](https://www.cisco.com/c/en/us/td/docs/dcn/nx-os/nexus9000/106x/configuration/layer-2-switching/cisco-nexus-9000-series-nx-os-layer-2-switching-configuration-guide-106x/m-configuring-layer-2-switching.html) ## Select the most specific installed IP route For a packet being routed, RFC 1812 describes selecting a next-hop IP address and outgoing interface using the destination IP address. Its section 5.2.4.3 first retains matching forwarding entries, then retains the longest matching prefixes before later applicable selection rules. This concerns the forwarding information base, or FIB: the entries available for packet forwarding. The separate routing portion of EF-01 stipulates two usable entries already installed in the same forwarding context: 192.0.2.0/24 toward adjacent router X, and 192.0.2.128/25 toward adjacent router Y. The packet's destination is 192.0.2.200. These addresses sit within the documentation block identified by RFC 5737. Both prefixes match that destination. The /24 fixes the first 24 bits; the /25 fixes those bits plus one more. The last octet, 200, falls within the /25's range of 128 through 255. The /25 therefore selects the path toward Y before any later tie-break rule could be relevant. Choosing the numerically larger prefix length here means choosing the more specific destination match. The example stipulates installed entries. It does not compare how competing route advertisements are selected for installation. A supplier's explanation of route learning must still identify the forwarding result required by the proposed network. References: [R1](https://www.rfc-editor.org/rfc/rfc1812.html), [R4](https://www.rfc-editor.org/rfc/rfc5737.html) ## Address the next Ethernet hop Route selection leaves a second addressing question: how does the packet reach the selected adjacent device? RFC 826's Packet Generation discussion separates the routing choice of next-hop protocol address from resolution to an Ethernet address. These are different associations from a bridge's MAC-to-port entry. Continue EF-01 with the /25 path toward Y. Stipulate a usable Ethernet adjacency to Y and ordinary unfragmented forwarding. The outgoing frame uses Y's MAC on that Ethernet segment as its destination, and the forwarding device's egress MAC as its source. The IPv4 destination remains 192.0.2.200. A bridge along that segment can use Y's destination MAC to select its own output. Y can then make its own routed decision toward 192.0.2.200. When a router eventually sends directly onto the destination host's Ethernet segment, the next-hop Ethernet address can be that host's MAC. The final host's MAC does not travel as the destination of every Ethernet frame across the routed path. The IPv4 packet also changes during ordinary routing. Its time-to-live value decreases, and its header checksum is updated to reflect header changes, as described in RFC 791. Preserving the destination IP address therefore does not mean preserving every packet bit. The installed /25 entry identifies the selected IP path. Successful Ethernet transmission additionally needs usable next-hop address information and an outgoing link; the route entry alone does not establish those conditions. References: [R1](https://www.rfc-editor.org/rfc/rfc1812.html), [R2](https://www.rfc-editor.org/rfc/rfc826.html), [R3](https://www.rfc-editor.org/rfc/rfc791.html) ## Compare the forwarding result being offered Use those distinctions to read a GPU-network proposal. A port schedule can identify the physical connection between two devices. A MAC entry can identify an output toward an Ethernet destination within a bridge domain. A FIB entry can identify the selected routed path for an IP destination. Each is useful, and each leaves a different part of the requirement to be answered. If the required destination is reached through routing, evidence that the local host MAC has been learned does not close the reachability question. In EF-01, MAC-A on port 1 explains where return Ethernet frames to A can go. It says nothing about whether the /25 path toward Y exists. Conversely, the stipulated /25 entry does not identify which MAC belongs to Y on the outgoing segment. Ask the proposing network owner to explain the intended bridged relationships, the routed boundaries and the destination reachability supplied by the offered configuration. Keep the explanation tied to the actual endpoints and required traffic directions. The buyer needs to know which part is equipment capability, which part is delivered network setup, and which operational result has applicable acceptance evidence. The same chassis name can appear in offers with different answers to those questions. It cannot establish that all ports are routed or that the required paths have been implemented correctly. Throughput, application performance and behavior during an upgrade need their own evidence; this comparison establishes the meaning of the forwarding functions being purchased. ## Connect the network decision to the physical handoff Leviathan's structured cabling service can discuss the physical connections supporting an approved Ethernet design: routing and dressing specified assemblies, identifying endpoints and patch points, and returning agreed connection and check records. Those records give the appointed network team a traceable physical basis for its work. Use the service and project-inquiry links below to share the site, exact supplied equipment, approved endpoint and patching plan, cable routes, material responsibilities and required physical handoff. Identify the network owner receiving the connections and responsible for the bridged and routed behavior. Network software configuration and routed-reachability acceptance belong with that appointed owner. The physical inquiry defines the cabling work and its receiving team; it does not establish a Leviathan network-software service. References: [L1](https://www.leviathansystems.co/services/structured-cabling) ## Primary sources - [C1 — Cisco Nexus 9000 NX-OS 10.6(x): Layer 2 switching and address learning](https://www.cisco.com/c/en/us/td/docs/dcn/nx-os/nexus9000/106x/configuration/layer-2-switching/cisco-nexus-9000-series-nx-os-layer-2-switching-configuration-guide-106x/m-configuring-layer-2-switching.html). Checked 2026-10-20. Release 10.6(x), chapter displaying an August 13, 2025 update. Source learning and destination lookup illustrate classical VLAN forwarding; the four-port case stipulates all eligible outputs. - [C2 — Cisco Nexus 9000 NX-OS 10.6(x): Layer 3 interface roles](https://www.cisco.com/c/en/us/td/docs/dcn/nx-os/nexus9000/106x/configuration/interfaces/cisco-nexus-9000-series-nx-os-interfaces-configuration-guide-release-106x/m_configuring_layer_3_interfaces_9x.html). Checked 2026-10-20. Updated July 21, 2026. Routed-interface and SVI descriptions illustrate Layer 2 and Layer 3 roles on one device; actual platform and feature applicability require the offered combination. - [R1 — RFC 1812: Requirements for IP Version 4 Routers](https://www.rfc-editor.org/rfc/rfc1812.html). Checked 2026-10-20. June 1995, sections 5.2.1.2 and 5.2.4, including Basic Match and Longest Match. Used for conceptual IPv4 forwarding, next-hop selection and link-layer encapsulation, without prescribing a hardware implementation. - [R2 — RFC 826: An Ethernet Address Resolution Protocol](https://www.rfc-editor.org/rfc/rfc826.html). Checked 2026-10-20. November 1982, Packet Generation discussion. Distinguishes the routing-selected next-hop protocol address from its Ethernet-address resolution; no address-resolution procedure is supplied. - [R3 — RFC 791: Internet Protocol](https://www.rfc-editor.org/rfc/rfc791.html). Checked 2026-10-20. September 1981, section 3.1 Time to Live and Header Checksum definitions. Used only to explain IPv4 header changes during ordinary forwarding. - [R4 — RFC 5737: IPv4 Address Blocks Reserved for Documentation](https://www.rfc-editor.org/rfc/rfc5737.html). Checked 2026-10-20. January 2010, sections 1 and 3. Establishes 192.0.2.0/24 as documentation space; EF-01's routes and adjacency are fictional. - [L1 — Leviathan Systems: Structured Cabling & Fiber Installation](https://www.leviathansystems.co/services/structured-cabling). Checked 2026-10-20. Physical installation of specified fiber and copper assemblies, endpoint identification and agreed handoff records. Materials responsibilities, verification coverage and availability depend on the engagement. ## Related Leviathan resources - [Leaf-spine cabling: translate the topology into physical links](/articles/leaf-spine-cable-plant-gpu-fabric) - [Optical circuit switching and passive patching](/articles/optical-circuit-switch-vs-fiber-patch-panel) - [Forwarding, control and management during a switch upgrade](/articles/switch-issu-control-plane-forwarding-scope) - [Structured cabling and fiber installation](/services/structured-cabling) - [Discuss the physical Ethernet connection package](/contact?service=structured-cabling&from=/articles/ethernet-mac-forwarding-versus-ip-next-hop) ## Define the physical Ethernet connection package Share the approved endpoint plan, specified assemblies, routes, materials responsibilities and required records to discuss the physical cabling scope and handoff. [Discuss the scope](/contact?service=structured-cabling&from=/articles/ethernet-mac-forwarding-versus-ip-next-hop)