From IP to SRv6: A Visual Guide to Routing, VPN Isolation, and Traffic Engineering

From IP to SRv6: A Visual Guide to Routing, VPN Isolation, and Traffic Engineering

Communication between two computers sounds simple: one device sends a packet, and the network delivers it to the destination.

At operator scale, however, the problem becomes much more complex. A backbone may connect thousands of customer sites across multiple regions. Different customers may use identical private IP addresses, multiple paths may lead to the same destination, and the network must continue forwarding traffic when links fail or equipment undergoes maintenance.

Ordinary IP routing provides basic reachability, but large service-provider networks often need additional capabilities for traffic isolation, transport, path selection, and service delivery. Technologies such as MPLS, L3VPN, Traffic Engineering (TE), Segment Routing (SR), and SRv6 address different parts of this problem.

These technologies are not simply features that must be enabled in sequence. Each answers a different question:

• IP routing: How can a packet reach a remote destination?
• MPLS: How can the backbone forward packets using labels?
• L3VPN: How can multiple customers share a backbone without sharing routing domains?
• Traffic Engineering: How can traffic use a path that meets specific constraints?
• Segment Routing: How can the ingress router express a desired path?
• SRv6: How can IPv6 addresses identify forwarding instructions and service functions?
• The control plane: How can routes, service information, and forwarding policies be distributed automatically?

To understand how these pieces fit together, consider a small Linux-based network and follow an ordinary IPv4 packet as it gains transport labels, service context, and eventually an IPv6-based Segment Routing path.

🗺️ 1. Start with the Network Architecture: Backbone and Edge

#

Imagine a service-provider network with two edge routers connected through four backbone routers. The backbone offers multiple possible paths, while two customer networks, RED and BLUE, attach to the edge routers.

The architecture has two main router roles:

• PE (Provider Edge): Connects customer networks to the provider. It maintains customer routing information, identifies the relevant service, and places customer traffic onto the backbone.
• P (Provider): Forwards traffic through the provider’s core toward the destination PE. In a typical MPLS L3VPN design, core P routers do not need to maintain every customer’s individual routes.

The fundamental principle is that the edge handles customer services, while the core handles transport.

For example, when a RED customer sends a packet to another RED site, the ingress PE determines the correct customer routing context and forwards the packet through the provider backbone. Intermediate routers primarily need enough information to deliver the packet to the egress PE.

A simplified topology looks like this:

RED ── PE-1 ── P-1 ── P-3 ── PE-2 ── RED
              │       │
              P-2 ── P-4
BLUE ─────────────────────────────── BLUE

The diagram is conceptual rather than a complete physical topology; real networks may have additional links and customer attachments.

Before any service can work, adjacent routers must be able to communicate. Configuring addresses on point-to-point links establishes directly connected reachability, but it does not automatically teach PE-1 how to reach PE-2.

That introduces the first problem: how does a router learn paths beyond its directly connected links?

🌐 2. IP Routing: Teaching Routers About the Backbone

#

An Interior Gateway Protocol (IGP), such as OSPF, allows routers within a routing domain to discover neighbors, exchange topology information, and calculate routes to remote destinations.

Each router initially knows its directly connected networks. As OSPF converges, it learns enough topology information to calculate paths through the network.

Routers commonly use Loopback interfaces as stable endpoint addresses. A Loopback is a logical interface that does not depend on a particular physical link, making it useful for router identification and protocol sessions. Its reachability still depends on the router and the surrounding network remaining operational.

Once OSPF has converged, PE-1 can learn a route to PE-2’s Loopback address.

Understanding ECMP

#

If multiple paths have equal routing cost, a router may install multiple next hops. This is ECMP (Equal-Cost Multi-Path).

During forwarding, the router typically hashes selected packet fields to distribute flows across the available paths. The exact fields and distribution behavior depend on the implementation and configuration.

ECMP improves path utilization and can provide alternatives when a next hop becomes unavailable, but it does not automatically select the path with the most available bandwidth or the lowest congestion.

Three layers of verification

#

A healthy routing protocol is necessary, but it does not prove that every packet will be delivered successfully. The forwarding table and real packet behavior must also be checked.

This IP underlay becomes the foundation for the transport, VPN, and Segment Routing mechanisms built on top of it.

🏷️ 3. MPLS: Forwarding Packets with Labels

#

Traditional IP forwarding examines a packet’s destination IP address and uses the routing table to select the next hop.

MPLS (Multiprotocol Label Switching) introduces another forwarding mechanism: a label is added to a packet, and MPLS routers process the outermost label to determine how to forward it.

Think of a label as a shipping instruction attached to a package. Intermediate transfer points use that instruction to move the package toward its destination, replacing or removing the label when appropriate.

The three fundamental MPLS operations are:

• Push: Add a label to the packet.
• Swap: Replace the top label with another label.
• Pop: Remove the top label.

How do routers learn label mappings?

#

A traditional MPLS transport network can use LDP (Label Distribution Protocol) to distribute label bindings for forwarding equivalence classes.

An FEC (Forwarding Equivalence Class) groups packets that receive equivalent forwarding treatment. For example, packets destined for a particular PE Loopback may belong to the same transport FEC.

Routers allocate labels locally and advertise the relevant mappings to their neighbors. As a result, the label used on one link does not necessarily match the label used on the next.

For example, one router might receive a packet with label 22 and forward it with label 25. This does not mean the destination has changed; the labels belong to different local forwarding contexts.

Once the necessary label state exists, the ingress PE can push a transport label and intermediate P routers can forward packets using MPLS.

But transport labels alone do not answer the customer-service question: when the packet reaches the remote PE, which customer routing domain should process it?

🔒 4. MPLS L3VPN: Separating Customer Routes from Transport

#

Suppose RED and BLUE are two enterprise customers sharing the same provider backbone. They require separate routing domains, and both may use the same subnet, such as 192.168.1.0/24.

A single global routing table cannot independently represent both customer networks using the same prefix without additional context.

The solution is VRF (Virtual Routing and Forwarding). A VRF provides a separate routing and forwarding context within a router. Customer-facing interfaces and routes are associated with the appropriate VRF, allowing overlapping addresses to coexist.

RED traffic is looked up in the RED VRF; BLUE traffic is looked up in the BLUE VRF.

RD and RT serve different purposes

#

In a classic MPLS L3VPN architecture, PE routers commonly exchange VPN routes through MP-BGP.

Two important attributes are:

• RD (Route Distinguisher): Makes otherwise overlapping customer prefixes distinguishable as VPN routes.
• RT (Route Target): Controls which VPN routes a VRF exports and imports.

In short, the RD distinguishes routes, while RT policy determines which VRFs are eligible to import them.

Two labels, two responsibilities

#

When PE-1 forwards a RED packet to PE-2 across an MPLS L3VPN, the packet commonly carries two labels:

Outer transport label
Inner VPN service label
Original IPv4 packet

The outer label delivers the packet across the backbone to the egress PE. The inner VPN label identifies the service-specific forwarding context or action needed at the egress.

Intermediate P routers can therefore forward using transport labels without maintaining the individual customer routes for RED and BLUE.

This is the central benefit of MPLS L3VPN: one shared backbone can carry many logically separate customer networks, while the edge maintains the service-specific routing information.

Verify connectivity and isolation

#

A complete test must confirm both that:

1. Hosts within the same VPN can communicate as intended.
2. Different VPNs cannot communicate unless an explicit inter-VPN policy permits it.

VPN separation provides logical routing isolation, not automatic encryption. Additional security mechanisms may be needed to protect traffic confidentiality.

🧭 5. Traffic Engineering: Choosing a Suitable Path

#

At this stage, customers can communicate through isolated routing domains. However, the shortest or lowest-cost path selected by the IGP may not be the best path for every service.

Consider two paths with equal OSPF cost. One has ample available bandwidth, while the other is heavily utilized. Ordinary ECMP may distribute flows across both paths without considering their remaining capacity.

Operators may also want to move traffic away from a link before planned maintenance, or steer latency-sensitive services along a particular route.

These are Traffic Engineering (TE) problems.

From topology information to a usable path

#

TE can use information such as:

• TE-specific link metrics.
• Maximum and reservable bandwidth.
• Unreserved bandwidth.
• Administrative constraints and link attributes.

In networks using OSPF TE extensions, relevant information can be distributed and assembled into a Traffic Engineering Database (TED).

However, learning about network resources does not automatically change forwarding behavior. Three separate functions are involved:

1. Information distribution: Advertise topology and resource attributes.
2. Path computation: Select a path that satisfies the applicable constraints.
3. Path implementation: Install or signal the path so that packets actually follow it.

For example, CSPF (Constrained Shortest Path First) can compute a path while excluding links that fail specified constraints. A controller may instead combine topology, resource information, and service policy to choose a path.

RSVP-TE can provide signaling and resource-reservation mechanisms in networks where the complete required functionality is supported and configured. Merely observing TE advertisements does not prove that a bandwidth-reserved TE tunnel exists.

The important distinction is that resource visibility, path selection, and forwarding execution are separate stages.

🧩 6. Segment Routing: Encoding Forwarding Instructions

#

Segment Routing (SR) provides a way to express forwarding instructions as a sequence of Segments. Each Segment is identified by a SID (Segment Identifier).

A Node SID typically represents reaching a particular node using the underlying routing system.

For example, a Segment List might describe this sequence:

P-1 → P-3 → PE-2

The ingress router places the corresponding instructions into the packet. As the packet travels, each router processes the active Segment and advances the forwarding process.

In SR-MPLS, SIDs are represented using MPLS labels. The ingress router pushes a label or label stack, and intermediate routers forward according to the active label.

Node SIDs do not always specify every link

#

A Node SID identifies the target node, but the route used to reach that node is generally determined by the underlying routing system.

If a packet carries only a Node SID for PE-2, ECMP may still select among multiple equal-cost paths to PE-2.

To express a more constrained path, the Segment List can include additional transit nodes. Where precise link selection is needed and supported by the network, an Adjacency SID can identify a particular adjacency.

SR-MPLS can coexist with L3VPN

#

Segment Routing changes how transport paths are expressed; it does not inherently replace the customer VPN architecture.

An SR-MPLS L3VPN packet can carry an SR label stack for backbone transport while retaining the VPN service label for delivery at the egress.

This separation lets operators change the transport mechanism without rebuilding the fundamental customer isolation model.

🎯 7. SR Policy: Connecting Traffic to a Segment List

#

Defining a Segment List does not automatically cause customer traffic to use it. The network must also determine which traffic should be associated with that path.

SR Policy provides a framework for identifying and applying a Segment Routing path policy.

Common policy elements include:

• Endpoint: The destination endpoint of the policy.
• Color: An identifier used to associate routing intent with a policy.
• Segment List: The ordered forwarding instructions for the candidate path.

For example, an ingress PE may have an SR Policy whose endpoint is PE-2 and whose Segment List directs traffic through P-1 and P-3.

Routing attributes or local policy can then associate selected traffic with the SR Policy. Only when the policy is correctly selected and installed does it affect actual forwarding.

Binding SID

#

An SR Policy may also have a Binding SID (BSID). This SID serves as an identifier for the policy as a whole, allowing the forwarding system to invoke the policy without requiring every upstream element to specify its full Segment List.

For an MPLS L3VPN using SR-MPLS, the packet may contain:

SR transport label stack
VPN service label
Original customer IP packet

The transport labels steer the packet through the backbone, while the service label determines how the egress PE delivers the customer packet.

SR does not automatically detect congestion or reserve bandwidth merely because a Segment List exists. Those capabilities depend on the resource information, path-computation process, policy, and supporting mechanisms in the deployed network.

Traffic classification matters, too. Steering all traffic to a remote PE along one path may be too coarse for a network that needs different paths for different customers, prefixes, or service classes.

🌍 8. SRv6: Using IPv6 SIDs for Paths and Service Functions

#

SR-MPLS represents Segments with MPLS labels. SRv6 represents them with IPv6-format SIDs and uses IPv6 packet processing to implement Segment Routing.

Consider a customer sending an IPv4 packet across an SRv6-enabled backbone. The ingress PE can encapsulate the original IPv4 packet inside an outer IPv6 packet. When required, an SRH (Segment Routing Header) carries the Segment List.

The backbone forwards the outer IPv6 packet. Nodes process the SIDs according to their configured behaviors, and the egress performs the appropriate service processing and delivers the inner packet.

An SRv6 SID can represent a function

#

An SRv6 SID is not merely an address identifying a router. It can also identify a forwarding behavior that the router executes.

Two examples are:

• End: Performs basic endpoint processing for a Segment Routing SID and advances processing according to SRv6 rules.
• End.DT4: Decapsulates an inner IPv4 packet and performs a lookup in a specified IPv4 routing context.

In an SRv6 L3VPN, End.DT4 can be associated with the RED VRF. When the packet reaches the relevant service SID, the egress PE removes the outer encapsulation and forwards the inner IPv4 packet using the RED routing context.

This connects two distinct operations: reaching the remote endpoint and delivering the packet into the correct customer network.

Locator reachability and operational overhead

#

A Locator is a routable IPv6 prefix associated with a set of SRv6 SIDs. Advertising Locator reachability allows the network to route packets toward nodes that can process those SIDs.

SRv6 also introduces practical costs:

• Outer IPv6 and optional SRH headers increase packet overhead.
• MTU planning is necessary to avoid fragmentation-related problems or packet drops.
• SID allocation and behavior configuration must remain consistent with service routing.
• Troubleshooting may involve both IPv6 transport and inner customer-packet processing.

SRv6 is therefore not automatically the best option for every network. Its suitability depends on IPv6 readiness, device capabilities, operational tooling, and service requirements.

🛠️ 9. Why Can Packets Reach the Egress PE but Still Fail?

#

A useful SRv6 L3VPN troubleshooting scenario occurs when a packet capture confirms that the outer IPv6 packet reaches the egress PE and contains the expected inner IPv4 packet, yet the destination customer never receives it.

This does not necessarily mean SRv6 transport is broken. It may indicate that transport has succeeded but service delivery has failed.

After receiving the outer packet, the egress must perform the expected SID behavior, decapsulate the packet, select the correct routing context, pass applicable validation checks, and transmit it through the correct customer-facing interface.

Linux reverse-path filtering

#

On Linux systems, rp_filter (reverse-path filtering) can be relevant to packet drops involving source-address validation.

Reverse-path filtering checks whether the system’s routing information provides an acceptable reverse route to the packet’s source. Linux supports different modes, including strict and loose filtering, with behavior influenced by the relevant configuration and routing context.

In a VPN deployment, the reverse route for a customer source address may exist only inside that customer’s VRF. If validation occurs in a context that cannot find an acceptable route, a packet may be dropped even though the outer tunnel successfully delivered it.

This can be mistaken for an SRv6 SID or End.DT4 failure when the actual problem lies later in the receive and delivery pipeline.

Troubleshooting should therefore examine the entire processing path:

1. Confirm that the outer IPv6 packet reaches the expected egress.
2. Verify that the intended SID behavior is installed and executed.
3. Confirm decapsulation and selection of the correct VRF or routing table.
4. Inspect reverse-path filtering, policy routing, and other applicable validation checks.
5. Confirm that the inner packet is forwarded through the intended customer interface.

The exact checks depend on the Linux version, kernel configuration, and forwarding architecture. Disabling source validation is not a universal fix; the goal is to make validation behavior consistent with the intended VRF and forwarding design.

🔄 10. Why the Data Plane Is Not the Whole Solution

#

A static SRv6 L3VPN experiment can work when an administrator manually configures the relevant SIDs, service behaviors, and customer routes on both PEs.

That proves the configured data plane can forward traffic. It does not prove the network has an automated control plane for distributing customer routes and service information.

The distinction is straightforward:

• Data plane: Processes packets according to installed forwarding state.
• Control plane: Generates, distributes, and updates the routes, service information, and policies that create that state.

In a small lab, an administrator might explicitly configure the ingress PE to associate a customer prefix with a remote service SID, then configure the egress PE to associate that SID with the appropriate VRF.

In a production network, this information generally needs to be distributed through suitable control-plane mechanisms. For example, BGP can distribute VPN routes and associated SRv6 service information when the required extensions are supported and configured.

Without such automation, every new customer site or service may require multiple manual changes. Failures and topology changes can also become harder to handle consistently.

A successful packet-forwarding test is an important milestone, but scalable service delivery also depends on reliable route distribution, policy updates, and operational verification.

📚 11. What Actually Changes from IP to SRv6?

#

Each technology adds a different capability to the network:

This is a conceptual progression, not a mandatory deployment sequence. LDP is not a prerequisite for SR-MPLS, and SRv6 does not require a network to deploy MPLS first. Specific dependencies depend on the chosen architecture and implementation.

The benefit of understanding the technologies separately is that it makes complex networks easier to design and troubleshoot. First establish reachability; then verify isolation. Next understand resource information and path selection. Finally, confirm that packet processing and service delivery work end to end before introducing more automation.

For related background, explore KAD8 networking articles and PUDN Club technical articles.

Ultimately, every network design should be able to answer a few concrete questions:

• Where does the packet enter the network?
• Which routing or forwarding context identifies its destination and service?
• Which labels, SIDs, or policies determine its path?
• What processing occurs at each relevant hop?
• Does the packet reach the correct customer network and arrive successfully?

Those answers—not the number of protocols enabled—determine whether the network is actually delivering the intended service.