10.3 Layer 3 Services: IES and VPRN

Decide which routing table the customer needs

Nokia SR OS provides customer-facing IP interfaces through Internet Enhanced Service (IES) and Virtual Private Routed Network (VPRN) models. The main distinction is the routing context.

IES interfaces use the Base routing instance. VPRN supplies a separate Virtual Routing and Forwarding (VRF) instance for a private routed service. Several IES services do not automatically create separate customer route tables; separate VPRNs can support overlapping customer addresses.

Neither model automatically encrypts traffic. VRF separation and route policy provide configured isolation; wrong route imports can intentionally or accidentally connect services.

IES interface example

Assume LabCustomer exists and a separate access port 1/1/5 is provisioned, enabled, and set to access/dot1q. An illustrative MD-CLI IES interface is:

configure private
/configure service ies "Internet-A" service-id 20
/configure service ies "Internet-A" customer "LabCustomer"
/configure service ies "Internet-A" admin-state enable
/configure service ies "Internet-A" interface "to-CE" ipv4 primary address 198.51.100.1
/configure service ies "Internet-A" interface "to-CE" ipv4 primary prefix-length 30
/configure service ies "Internet-A" interface "to-CE" sap 1/1/5:20
compare
validate
commit

A customer endpoint might use 198.51.100.2/30. Its reachability belongs to Base, not an automatically isolated VRF. The provider still needs appropriate onward routes, access policy, and return routing. The documentation address range here is for teaching, not public deployment.

RD: unique VPN route identity

If two customers both use 10.1.0.0/24, plain IPv4 destination identity alone cannot distinguish their VPN routes in a shared BGP distribution system.

A Route Distinguisher (RD) adds 64 bits of distinguishing information to the IPv4 address component. A VPN-IPv4 address has a 64-bit RD plus a 32-bit IPv4 component. For a /24 route, the associated VPN-IPv4 prefix contains the RD plus those 24 prefix bits; this is not a claim that every customer route is an IPv4 /32.

For example, RDs 10.10.10.1:50 and 10.10.10.1:60 can distinguish overlapping customer routes. The RD is control-plane route identity. It is not carried in every ordinary customer IP packet and does not determine which VRF may import a route.

RT: route membership policy

A Route Target (RT) is a BGP extended community used by VPN import/export policy. Export attaches relevant targets; import selects eligible routes for a VRF.

Two sites can share an appropriate RT while using different RDs. Matching the RD is not the membership test. Conversely, accidentally importing another customer's RT can defeat the intended separation.

A hub-and-spoke policy can control which routes spokes learn, but RT values alone do not guarantee that all traffic traverses a firewall. A design requiring firewall transit also needs correct route origination, forwarding, and policy at the hub.

Configure a basic VPRN

Assume PE1 has system address 10.10.10.1, MP-BGP VPN-IPv4 peering toward PE2, and working LDP transport. Access port 1/1/6 is separately provisioned as access/dot1q. This fragment defines the local service:

configure private
/configure service vprn "Private-A" service-id 50
/configure service vprn "Private-A" customer "LabCustomer"
/configure service vprn "Private-A" admin-state enable
/configure service vprn "Private-A" bgp-ipvpn mpls admin-state enable
/configure service vprn "Private-A" bgp-ipvpn mpls route-distinguisher "10.10.10.1:50"
/configure service vprn "Private-A" bgp-ipvpn mpls vrf-target community "target:64512:50"
/configure service vprn "Private-A" bgp-ipvpn mpls auto-bind-tunnel resolution filter
/configure service vprn "Private-A" bgp-ipvpn mpls auto-bind-tunnel resolution-filter ldp true
/configure service vprn "Private-A" interface "to-CE" ipv4 primary address 10.1.1.1
/configure service vprn "Private-A" interface "to-CE" ipv4 primary prefix-length 30
/configure service vprn "Private-A" interface "to-CE" sap 1/1/6:50
compare
validate
commit

PE2 needs its own service, a distinct suitable RD, matching intended import/export RT policy, local customer routing, and usable transport back to PE1. Base BGP must actually negotiate VPN-IPv4; an ordinary IPv4-only session is insufficient. Inspect which local routes are exported and which remote routes are imported rather than assuming every configured prefix is automatically shared.

The tunnel-resolution form is resolution filter plus resolution-filter ldp true. Do not use the invented shortcut resolution ldp. A filter selecting LDP still needs an operational eligible tunnel.

Trace a customer packet

PE1 identifies the ingress SAP's VRF and looks up the customer's IP destination there. A remote VPN route supplies an egress PE next hop and service label. PE1 resolves transport toward that PE and pushes the required labels.

Transit P routers can forward on the outer transport label without storing customer VPN routes. At the egress, the advertised VPN label selects the relevant service/forwarding context. The exact label allocation mode can identify a VRF or more specific forwarding information; it need not always identify one SAP directly.

PHP can remove the outer transport label while leaving the VPN label intact. It does not transmit Implicit Null 3 as a data label, nor does it remove the VPN context before the egress processes it.

Verify route distribution and delivery

Inspect the VPRN route table, VPN-IPv4 BGP routes, selected transport, local interface/SAP state, and customer return routing. A matching RT alone does not prove that a route is valid, selected, or forwarded.

A useful failure split is “route not imported” versus “route imported but tunnel unresolved.” The first suggests family or policy investigation; the second suggests underlay and transport investigation. Neither is resolved by changing the RD blindly.

Primary references

BGP/MPLS IP-VPN specification, Nokia VPRN configuration, and Nokia tunnel resolution, checked October 20, 2026.