Modern Application Delivery Controller (ADC) deployments rarely operate in simple networks. Enterprise environments commonly include multiple VLANs, routers, firewalls, gateways, backend networks and redundant paths. At the same time, application servers are increasingly interconnected: a server can be the backend of one load-balanced service while simultaneously acting as a client consuming another Virtual IP (VIP).
In these environments, an apparently simple question becomes important:
Should an ADC return traffic according to its routing table, or through the network path from which the connection actually arrived?
These two decisions are not always the same. When they differ, asymmetric routing can appear.
SKUDONET Last Hop addresses this problem by dynamically learning the relevant Layer 2 Last Hop using eBPF, allowing the ADC to preserve the appropriate return path without requiring administrators to redesign the network or maintain complex routing workarounds.
Understanding the problem: routing knows the destination, not the connection path
Consider a client accessing an application published through an ADC. The incoming connection may pass through a router or stateful firewall before reaching a Virtual IP.
DIAGRAM 1 — Normal incoming connection
The ADC receives the connection and delivers it to the appropriate backend. Eventually, the application response must return to the client. A conventional network stack performs a routing decision based primarily on the destination:
Destination IP → Routing table → Interface / Next Hop
That is perfectly valid IP routing behavior. However, there is a piece of information a conventional routing decision does not necessarily consider: through which Layer 2 path did this particular connection arrive? The best route towards an IP address and the correct return path for that specific connection are not necessarily the same thing.
When a valid routing decision creates the wrong return path
DIAGRAM 2 — Asymmetric routing
The connection entered through Firewall A, but its response leaves through Router B. From a pure IP routing perspective, both paths may be completely valid. From an application delivery perspective, the result is an asymmetric traffic path — and that creates real problems.
IP networking does not inherently require both directions of a communication to follow the same physical path. Real enterprise networks, however, contain devices that maintain connection state or apply security policies. If a stateful firewall creates state for Client → Firewall A → ADC but the response follows ADC → Router B → Client, Firewall A never sees the return traffic.
Depending on the infrastructure, this can lead to:
- Stateful firewall sessions failing
- Inconsistent NAT state
- Security policies behaving unexpectedly
- Connections dropped intermittently
- Different paths applying different security controls
- Difficult-to-diagnose application connectivity problems
- Unexpected behavior in redundant network architectures
An ADC can have a perfectly valid route to a client and still use the wrong return path for that particular connection.
The problem with directly connected networks
DIAGRAM 3 — Multiple directly connected networks
The problem becomes more relevant when the ADC is connected to several networks directly — for example, VLAN A (clients), VLAN B (VIP) and VLAN C (backends).
Suppose a connection physically reaches SKUDONET through an intermediate router or firewall, but its source IP belongs to a network the ADC also knows directly. When the response is processed, the routing system sees that destination as directly reachable and selects that direct interface. The decision is correct according to the routing table — but it doesn’t reproduce the path through which the connection actually arrived.
This is one reason asymmetric routing problems can be difficult to troubleshoot: there may be nothing wrong with the routing table at all.
When a backend also acts as a client of another VIP
Modern application architectures make the distinction between “client network” and “backend network” increasingly artificial. The same server can simultaneously be a backend member of one load-balanced service, and consume another application through a different SKUDONET VIP.
DIAGRAM 4 — Backend also acting as a VIP client
Backend Server A is therefore both a load-balancing destination and a consumer of another load-balanced service. Because SKUDONET already has direct connectivity to Server A’s network, a conventional routing decision can select that direct path when returning traffic, even though the connection towards the other VIP entered through a different Layer 2 path. As application environments become more interconnected, assuming “backend networks only contain backends” is no longer realistic.
What happens without Last Hop
Without a Last Hop capability, the network infrastructure itself has to compensate for the asymmetry. Administrators can introduce static routes, Policy-Based Routing (PBR), source-specific routing, multiple routing tables, packet marks and routing rules, additional VLANs, additional NAT policies, firewall-specific routing rules, topology changes or per-service exceptions.
These approaches can solve individual scenarios, but their limitation is operational complexity. A workaround that’s manageable for two applications becomes difficult to maintain when an ADC publishes dozens or hundreds of VIPs across multiple networks: adding a VIP may require routing changes, moving an application may require new PBR rules, and troubleshooting means correlating ADC configuration, routing tables, firewall state, VLANs and PBR policies at the same time.
Enterprise ADCs handle this problem at the application delivery layer
Asymmetric routing in complex application delivery environments is not a new problem. Mature enterprise ADC platforms address it inside the application delivery layer rather than relying entirely on external routing workarounds.
F5 BIG-IP, for example, provides Auto Last Hop, which retains the MAC address associated with the incoming request and can use it for the return traffic. NetScaler ADC provides MAC-Based Forwarding (MBF), which similarly retains Layer 2 information about the upstream device and uses it when sending the response.
These mechanisms reflect an important architectural distinction. Last Hop awareness is not simply a routing feature; it is an ADC capability designed for environments where connection state, multiple network paths and application traffic intersect.
SKUDONET addresses the same class of enterprise networking problem with Last Hop, bringing this capability natively into its ADC architecture. Rather than depending on legacy MAC-caching logic, SKUDONET uses dynamic Layer 2 learning powered by eBPF within the Linux networking datapath.
This places SKUDONET alongside established enterprise ADC platforms in its ability to preserve the appropriate return path at the application delivery layer.
SKUDONET Last Hop: dynamic Layer 2 learning powered by eBPF
Instead of statically describing every possible return path, SKUDONET Last Hop learns the relevant information from the traffic itself. When a connection whose source belongs to a network SKUDONET already knows reaches the ADC, Last Hop identifies the Layer 2 path (including the associated MAC information) through which it arrived, and stores it.
Conceptually:
Incoming traffic → Learn Layer 2 Last Hop → Store path information → Use it for the return traffic
This is implemented using eBPF, integrated with the Linux networking datapath. Linux still performs its normal routing decision first, selecting the interface through which the response would ordinarily leave. SKUDONET’s eBPF logic then checks that decision after routing and before the packet reaches the output interface: if the learned Last Hop indicates the response should leave through a different interface, the output is corrected accordingly.
DIAGRAM 5 — SKUDONET eBPF Last Hop learning
There’s no need to create a static route for every learned connection path, redesign the surrounding network, or spread application-specific routing complexity across the infrastructure.
Last Hop works with routing, not instead of it
SKUDONET Last Hop does not replace a correctly designed routing infrastructure. Routers continue routing. Linux continues maintaining network reachability. Gateways, VLANs and interfaces continue performing their normal functions.
Last Hop solves a more specific problem: when the ADC already knows how a connection entered the system, that information is used to preserve the correct Layer 2 return path — instead of letting another valid routing decision introduce unwanted asymmetry.
Where SKUDONET Last Hop is especially useful
- Multiple routers or default gateways
- Stateful firewalls in front of the ADC
- Multiple directly connected networks or VLANs
- Complex Layer 2 and Layer 3 segmentation
- Redundant network paths
- Multi-homed ADC deployments
- Environments requiring symmetric traffic paths
- Legacy networks that can’t easily be redesigned
- Large ADC installations where per-service routing policies become hard to maintain
- Backend servers that also act as clients of other load-balanced VIPs
- Architectures where traffic frequently crosses client, service and backend networks connected to the same ADC
Traditional routing vs SKUDONET Last Hop
DIAGRAM 6 — Side-by-side comparison
Traditional routing vs SKUDONET Last Hop
Less routing complexity, more intelligence at the application delivery layer
An ADC occupies a privileged position in the network: it sees connections entering the infrastructure, identifies the VIP being accessed, selects application servers and processes the traffic returning from those applications. Discarding information about the incoming path and trying to reconstruct it later through increasingly complex routing policies isn’t always the best architectural approach.
SKUDONET Last Hop uses information that’s already available when traffic enters the ADC, reducing the need for workarounds based on static routes or Policy-Based Routing — and keeps that intelligence where it belongs: inside the application delivery layer, instead of distributed across the network.
Frequently asked questions
What causes asymmetric routing in an ADC deployment?
Asymmetric routing happens when the routing table selects a valid but different interface for a response than the one the connection originally entered through. This is common when an ADC is connected to multiple networks, sits behind stateful firewalls, or when a server acts as both a backend and a client of another Virtual IP.
What is SKUDONET Last Hop?
SKUDONET Last Hop is a capability that dynamically learns the Layer 2 path a connection arrived through, using eBPF in the Linux networking datapath, and uses that information to send the response back through the correct interface.
How does SKUDONET Last Hop compare with enterprise ADC mechanisms?
F5 BIG-IP provides Auto Last Hop and NetScaler ADC provides MAC-Based Forwarding to preserve Layer 2 information for return traffic. SKUDONET addresses the same class of asymmetric-routing problem through dynamic Layer 2 Last Hop learning implemented natively with eBPF in the Linux networking datapath.
Does Last Hop replace routing infrastructure?
No. Routers, gateways and Linux’s own routing system continue to work normally. Last Hop only intervenes for specific connections where the learned entry path differs from what routing would otherwise select.
When should a company consider using Last Hop?
When the ADC deployment includes multiple routers or gateways, stateful firewalls, several VLANs, redundant paths, or servers that act simultaneously as backends and clients of other Virtual IPs.
