What is MPLS VPN? L3VPN, Route Distinguishers, VRFs, and Label Stacking

MPLS VPN is a service provider Layer 3 construct; IPsec VPN is a customer-managed overlay tunnel. MPLS L3VPN runs inside the provider's MPLS domain—customers hand off IP routes at the PE-CE boundary and the provider handles forwarding, QoS, and isolation via VRFs and label switching. IPsec VPN, by contrast, encrypts IP packets end-to-end across any IP transport (Internet, MPLS, or hybrid) and terminates on customer-owned routers or firewalls.

Key operational differences:

• Encryption: MPLS VPN has no native encryption; traffic rides in cleartext MPLS frames across the provider backbone. IPsec VPN encrypts every packet with ESP (RFC 4303), protecting confidentiality and integrity.
• Routing: MPLS VPN customers peer with the PE using OSPF, EIGRP, BGP, or static routes; the provider redistributes these into MP-BGP. IPsec VPN customers run their own routing (often GRE+IPsec or DMVPN) or static routes over encrypted tunnels.
• Scalability: MPLS L3VPN scales to thousands of sites via MP-BGP route reflectors and hierarchical label stacks. IPsec VPN requires full-mesh or hub-spoke tunnel topologies, which grow O(n²) in a full mesh.
• SLA and QoS: Service providers offer contractual SLAs (latency, jitter, packet loss) on MPLS VPN circuits with MPLS EXP bit marking. IPsec VPN over Internet has best-effort delivery unless you buy SD-WAN with underlay path selection.

In India, enterprises with 50+ branches typically buy MPLS L3VPN from Tata Communications, Airtel, or Reliance Jio for predictable performance, then overlay IPsec tunnels for regulatory compliance (RBI, DPDP Act) when carrying card data or PII. Our HSR Layout lab runs both: a 6-PE MPLS topology for L3VPN labs and a separate IPsec DMVPN rack so students compare forwarding plane behavior side-by-side.

A VRF is a separate routing table instance on a PE router, isolating one customer's prefixes from another customer's prefixes and from the global routing table. Each VRF has its own RIB (Routing Information Base), FIB (Forwarding Information Base), and CEF adjacency table. When a PE receives a packet on a customer-facing interface, it performs the lookup in that interface's assigned VRF, not the global table.

VRF configuration elements (Cisco IOS XE):

ip vrf CUSTOMER_A
 rd 65000:100
 route-target export 65000:100
 route-target import 65000:100
!
interface GigabitEthernet0/0/1
 ip vrf forwarding CUSTOMER_A
 ip address 10.1.1.1 255.255.255.252

Key behaviors:

1. Route distinguisher (RD): Prepended to each IPv4 prefix to create a globally unique VPN-IPv4 prefix (8-byte RD + 4-byte IPv4 = 12-byte address family). RD format is ASN:nn or IP:nn. The RD does not control route import/export—it only ensures uniqueness in MP-BGP.
2. Route target (RT): Extended community (RFC 4360) attached to each VPN-IPv4 route. route-target export tags routes advertised from this VRF into MP-BGP; route-target import filters which MP-BGP routes are installed into this VRF. RT format matches RD format but serves a filtering role.
3. Overlapping address space: Two customers can both use 10.0.0.0/8 internally. The PE maintains separate VRF tables; the RD ensures MP-BGP can carry both 65000:100:10.0.0.0/8 and 65001:200:10.0.0.0/8 without collision.

In production, banks and retailers often use a single RD per VRF but multiple RTs to implement hub-spoke topologies: spoke sites import the hub RT but not each other's RTs, preventing spoke-to-spoke traffic (all traffic hairpins through the hub data center). Cisco's MPLS VPN documentation (configure-basic-mpls-vpn) covers simple any-to-any topologies; real deployments at HCL or Wipro use RT filtering for security segmentation.

A route distinguisher (RD) is an 8-byte prefix prepended to a customer's IPv4 address to create a unique VPN-IPv4 address family identifier in MP-BGP, preventing route collisions when multiple customers use overlapping IP space. The RD itself has no semantic meaning for forwarding—it exists solely to make each customer's 10.1.1.0/24 distinguishable from another customer's 10.1.1.0/24 in the provider's BGP table.

RD structure (RFC 4364 §4.2):

• Type 0: 2-byte administrator field (ASN) + 4-byte assigned number. Example: 65000:100 means AS 65000, VPN ID 100.
• Type 1: 4-byte administrator field (IPv4 address) + 2-byte assigned number. Example: 192.0.2.1:50 means router 192.0.2.1, VPN ID 50.
• Type 2: 4-byte administrator field (4-byte ASN) + 2-byte assigned number. Example: 4200000000:10 for large ASNs.

The 8-byte length accommodates the largest possible administrator field (4 bytes) plus a 4-byte assigned number in Type 0, or 4-byte IP + 2-byte number in Type 1. This ensures global uniqueness without a central registry—each service provider picks RDs from their own ASN or IP space.

Common misconception: RD does not control route import/export. Two VRFs can share the same RD (not recommended but legal) or use different RDs yet still exchange routes via matching route targets. The RD is purely a namespace separator for MP-BGP's NLRI encoding.

In our HSR Layout lab, we demonstrate RD collision scenarios: configure two PEs with the same RD for different customers, then show how MP-BGP accepts both routes (because the next-hop differs) but CEF on the PE cannot install both into the global table—only into the correct VRF. Students troubleshoot with show bgp vpnv4 unicast all and show ip route vrf CUSTOMER_A to see the separation. This exact scenario appeared in a Cisco India TAC case we replicated for our CCIE Security batch last quarter.

MP-BGP (Multiprotocol BGP, RFC 4760) extends BGP-4 to carry VPN-IPv4 address family (AFI=1, SAFI=128) so PE routers can advertise customer routes with attached RD and route target extended communities across the provider backbone. Standard BGP-4 (RFC 4271) only carries IPv4 unicast (AFI=1, SAFI=1); MP-BGP adds new NLRI encodings and attribute types to support MPLS L3VPN, IPv6, multicast, and EVPN.

MP-BGP session establishment between PEs:

router bgp 65000
 neighbor 198.51.100.2 remote-as 65000
 neighbor 198.51.100.2 update-source Loopback0
 !
 address-family vpnv4
  neighbor 198.51.100.2 activate
  neighbor 198.51.100.2 send-community extended
 exit-address-family

Key protocol behaviors (RFC 4364 §4.3):

1. VPN-IPv4 NLRI encoding: Each UPDATE message carries an 8-byte RD + 4-byte IPv4 prefix + prefix length. The NLRI length field is 12 bytes (96 bits) + prefix length in bits.
2. Extended community attribute (type code 16): Carries route targets (subtype 0x0002 for import, 0x0002 for export—same subtype, different usage context). The PE attaches the route-target export value when advertising into MP-BGP; the receiving PE checks its route-target import list to decide whether to install the route into a VRF.
3. Next-hop rewrite: The advertising PE sets next-hop to its own loopback (the LDP router-id). The receiving PE performs a recursive lookup: VRF FIB points to the remote PE loopback, global FIB has an MPLS label binding for that loopback (the transport label).
4. VPN label allocation: The advertising PE allocates a unique MPLS label per VRF (per-VRF label mode, default on IOS XE) or per-prefix (per-CE label mode). This label is encoded in the MP-BGP NLRI as the "MPLS Label" field and becomes the inner (VPN) label in the two-level stack.

Route reflectors (RFC 4456) are mandatory in large MPLS networks to avoid full-mesh iBGP between all PEs. The RR must be configured with address-family vpnv4 and neighbor X.X.X.X route-reflector-client. Critically, the RR does not need to maintain VRF tables—it only reflects VPN-IPv4 NLRIs without installing them locally. This is why P (provider core) routers run LDP but not MP-BGP: they switch based on the outer transport label, never inspecting the inner VPN label.

MPLS L3VPN uses a two-level label stack: the outer (top) label is the transport (LDP or RSVP-TE) label that forwards the packet to the egress PE's loopback; the inner (bottom) label is the VPN label that identifies the egress VRF on that PE. The ingress PE imposes both labels; P routers swap only the outer label; the egress PE pops the outer label (via PHP or explicit-null) and uses the inner label to perform a VRF lookup.

Label stack construction (RFC 3032 label format, 4 bytes per label):

[Ethernet header]
[IP header: src=CE1, dst=CE2]
  ← Customer packet

[Outer label: 24-bit value, 3-bit EXP, 1-bit S=0, 8-bit TTL]
[Inner label: 24-bit value, 3-bit EXP, 1-bit S=1, 8-bit TTL]
[IP header: src=CE1, dst=CE2]
  ← After ingress PE imposes stack

Step-by-step forwarding:

1. Ingress PE receives packet from CE: Packet arrives on a VRF interface. PE performs VRF FIB lookup for destination 10.2.2.2. FIB entry points to remote PE 198.51.100.3 with VPN label 25 (learned via MP-BGP).
2. Ingress PE performs recursive lookup: Global FIB lookup for 198.51.100.3 returns LDP label 1002 (learned via LDP). PE pushes label 1002 (outer) then label 25 (inner), sets EXP bits from IP DSCP if QoS is configured, copies IP TTL into outer label TTL (or sets to 255 if no mpls ip propagate-ttl).
3. P router swaps outer label: P router has LDP binding: swap 1002 → 1003, forward out Gi0/0/2. P router never inspects the inner label (S=0 bit indicates more labels follow).
4. Penultimate hop P router pops outer label (PHP): If egress PE advertised implicit-null (label 3) for 198.51.100.3, the penultimate P router pops the outer label and forwards the packet with only the inner label 25 exposed. This reduces egress PE processing (one less label lookup).
5. Egress PE receives packet with VPN label 25: PE looks up label 25 in its LFIB, finds it maps to VRF CUSTOMER_A. PE pops label 25, performs IP lookup in VRF CUSTOMER_A FIB, finds CE2 next-hop 10.2.2.2 out Gi0/0/3, forwards native IP packet to CE2.

In our lab, we use traceroute with MPLS label recording (Cisco's traceroute mpls ipv4 or Linux mtr with MPLS extensions) to show students the label stack at each hop. A common troubleshooting mistake: forgetting to enable mpls ip on core interfaces—LDP won't allocate transport labels, so the ingress PE can't build the outer label and drops the packet with "no route to VPNv4 next-hop."

PE-CE routing is the dynamic routing protocol (or static routes) running between the provider edge router and the customer edge router to exchange the customer's site prefixes into the provider's VRF. The PE redistributes these learned routes into MP-BGP with the VRF's RD and export RT; the remote PE imports matching routes from MP-BGP and redistributes them back into the PE-CE protocol toward the remote CE.

Supported PE-CE protocols (RFC 4364 §10):

• Static routes: Simplest option. PE configuration: ip route vrf CUSTOMER_A 10.10.0.0 255.255.0.0 10.1.1.2. Requires manual route injection at every PE; no automatic failover.
• OSPF: PE runs a separate OSPF process per VRF. PE acts as an OSPF ABR (Area Border Router) or ASBR, redistributing OSPF routes into MP-BGP and vice versa. RFC 4577 defines OSPF sham-links to prevent backdoor paths when a customer has a direct link between sites outside the MPLS cloud.
• EIGRP: PE runs a separate EIGRP AS per VRF. EIGRP route tags and AS number are preserved across the MPLS backbone, so the remote CE sees routes with the original EIGRP metrics. This is unique to EIGRP—OSPF and BGP lose original metrics during redistribution unless you use route-maps to preserve them.
• BGP (eBGP): PE and CE peer via eBGP. The PE uses a unique AS number per VRF or a shared AS with allowas-in to accept routes containing the customer's AS in the path. BGP is the most scalable PE-CE protocol for large enterprises because it avoids redistribution metric issues and supports rich policy via route-maps and communities.

Redistribution loop prevention:

When the egress PE redistributes MP-BGP routes back into the PE-CE protocol, it must prevent the remote CE from re-advertising those routes back into the MPLS cloud (creating a loop). Each protocol has a mechanism:

• OSPF: PE sets the OSPF down bit (DN bit, RFC 4577 §4.2.1) in LSAs redistributed from MP-BGP. CEs ignore LSAs with DN bit set, preventing readvertisement.
• EIGRP: PE sets a route tag (default tag 0xFFFF) on redistributed routes. A route-map on the PE denies routes with that tag from being redistributed back into MP-BGP.
• BGP: PE prepends a Site-of-Origin (SoO) extended community (RFC 4364 §4.6.1) to routes learned from the CE. If the PE receives a route from MP-BGP with the same SoO, it does not advertise that route back to the CE.

In India, most enterprises use eBGP for PE-CE when they have 20+ sites (Cisco India, Infosys, TCS all use eBGP for their MPLS WANs). Smaller deployments use OSPF or static routes. Our CCNP Enterprise batch spends two weeks on PE-CE OSPF sham-links because the ENCOR exam (350-401) has a full topology simulation on this topic.

Route targets (RTs) are BGP extended community attributes (RFC 4360, type 0x0002) that control which VPN-IPv4 routes are imported into which VRFs, enabling flexible topologies beyond simple any-to-any connectivity. Each VRF has an export RT list (attached to routes advertised into MP-BGP) and an import RT list (filters which MP-BGP routes are installed into the VRF). By manipulating RT import/export, you can build hub-spoke, extranet, and central-services topologies without changing the physical MPLS infrastructure.

Hub-spoke topology design:

! Hub site VRF (data center)
ip vrf HUB
 rd 65000:1
 route-target export 65000:999
 route-target import 65000:100
 route-target import 65000:200

! Spoke site A VRF
ip vrf SPOKE_A
 rd 65000:100
 route-target export 65000:100
 route-target import 65000:999

! Spoke site B VRF
ip vrf SPOKE_B
 rd 65000:200
 route-target export 65000:200
 route-target import 65000:999

Traffic flow analysis:

• Spoke A → Hub: Spoke A exports routes with RT 65000:100. Hub imports RT 65000:100, so Hub's VRF learns Spoke A's prefixes. Spoke A can reach Hub.
• Hub → Spoke A: Hub exports routes with RT 65000:999. Spoke A imports RT 65000:999, so Spoke A's VRF learns Hub's prefixes. Hub can reach Spoke A.
• Spoke A → Spoke B: Spoke A exports RT 65000:100. Spoke B imports RT 65000:999 (not 65000:100), so Spoke B's VRF does not learn Spoke A's prefixes. Spoke A cannot directly reach Spoke B—traffic must hairpin through the Hub.

Extranet topology (shared services):

An extranet allows multiple customers to access a shared resource (e.g., an Internet gateway VRF or a SaaS application VRF) without seeing each other's internal routes. Configure the shared VRF to import each customer's export RT, and configure each customer VRF to import the shared VRF's export RT. Use route-maps to filter which specific prefixes are shared (e.g., only advertise 0.0.0.0/0 from the Internet VRF, not the full Internet routing table).

In production, Indian banks use hub-spoke RT topologies to enforce security policy: branch VRFs can reach the core banking VRF in the data center, but branches cannot reach each other (preventing lateral movement if a branch router is compromised). RBI's cybersecurity framework (2016) and CERT-In directions recommend network segmentation; RT-based isolation is the MPLS equivalent of VLAN segmentation in campus networks. Our 4-month paid internship at the Network Security Operations Division has students configure hub-spoke topologies for a simulated bank with 50 branches—this exact design appears in Cisco's CCIE Service Provider v5.0 lab exam.

MPLS L3VPN handles overlapping IP space by maintaining separate VRF routing tables per customer on each PE router and using route distinguishers to create unique VPN-IPv4 prefixes in MP-BGP, ensuring that two customers using the same RFC 1918 space (e.g., 10.0.0.0/8) never collide. The PE performs all lookups in the context of a specific VRF, and the RD ensures MP-BGP can carry both customers' 10.0.0.0/8 advertisements without ambiguity.

Detailed isolation mechanism:

1. Data plane isolation: When a packet arrives on interface Gi0/0/1 assigned to VRF CUSTOMER_A, the PE performs the FIB lookup in CUSTOMER_A's VRF table. Even if CUSTOMER_B also has a 10.1.1.0/24 route, the PE never consults CUSTOMER_B's VRF for this packet. VRFs are completely separate forwarding contexts—there is no "default leak" between them.
2. Control plane isolation: The PE runs separate routing protocol instances per VRF. OSPF process 10 for CUSTOMER_A and OSPF process 20 for CUSTOMER_B maintain separate LSDBs, SPF trees, and route tables. If both customers run OSPF area 0, there is no conflict because the processes are independent.
3. MP-BGP uniqueness: The PE advertises CUSTOMER_A's 10.1.1.0/24 as RD 65000:100 + 10.1.1.0/24 and CUSTOMER_B's 10.1.1.0/24 as RD 65000:200 + 10.1.1.0/24. These are distinct NLRI entries in MP-BGP. The receiving PE uses route targets to decide which VRF gets which route: if the route has RT 65000:100, it goes into CUSTOMER_A's VRF; if RT 65000:200, it goes into CUSTOMER_B's VRF.

Edge case: overlapping address space between a VRF and the global table. If the PE's global table has a 10.0.0.0/8 route (e.g., for management) and CUSTOMER_A's VRF also has 10.0.0.0/8, there is no conflict because the PE never mixes global and VRF lookups. However, if you need the VRF to reach the global table (e.g., for Internet access), you must use route leaking: import the global table's default route into the VRF via import map or configure a separate Internet VRF with RT-based extranet.

In our HSR Layout lab, we run a scenario where three students each configure a VRF with 192.168.1.0/24 on the same PE, then ping across the MPLS core to verify isolation. We also demonstrate a misconfiguration: accidentally assigning two customer interfaces to the same VRF, causing one customer to see the other's routes—this is a common TAC case at Cisco India and a favorite CCIE troubleshooting ticket.

Per-VRF label allocation assigns one MPLS label to all prefixes in a VRF; per-CE (or per-prefix) label allocation assigns a unique label to each prefix or each CE next-hop, trading label table size for finer forwarding granularity. The choice affects LFIB scale, troubleshooting visibility, and QoS/ACL enforcement at the egress PE.

Per-VRF label mode (default on Cisco IOS XE):

vrf definition CUSTOMER_A
 rd 65000:100
 address-family ipv4
  route-target export 65000:100
  route-target import 65000:100
 exit-address-family

Behavior: The PE allocates one label (e.g., label 25) for the entire VRF. All MP-BGP advertisements for prefixes in this VRF carry label 25. When the egress PE receives a packet with label 25, it pops the label and performs an IP lookup in CUSTOMER_A's VRF FIB—no further label information is used. This is memory-efficient (one label per VRF, not per prefix) but provides no per-prefix visibility in the MPLS forwarding plane.

Per-CE label mode (configured with mpls label mode per-ce under VRF address-family):

vrf definition CUSTOMER_A
 address-family ipv4
  mpls label mode per-ce
 exit-address-family

Behavior: The PE allocates a unique label per CE next-hop. If CUSTOMER_A has two CE routers (CE1 at 10.1.1.2, CE2 at 10.1.2.2), the PE allocates label 25 for prefixes learned from CE1 and label 26 for prefixes learned from CE2. When the egress PE receives a packet with label 25, it knows the next-hop is CE1 and can apply per-CE QoS or ACLs without an IP lookup. This is useful for lawful intercept (LI) or per-customer traffic shaping but increases LFIB size linearly with the number of CEs.

Per-prefix label mode (configured with mpls label mode per-prefix):

Behavior: The PE allocates a unique label for every prefix in the VRF. A VRF with 1,000 routes consumes 1,000 labels. This provides maximum visibility (you can see per-prefix traffic counters in show mpls forwarding-table) but is rarely used in production due to label exhaustion risk—MPLS label space is 20 bits (1,048,576 labels), but many platforms reserve large ranges for LDP, RSVP, and pseudowires.

In India, service providers like Airtel and Tata Communications use per-VRF labels for standard L3VPN customers and per-CE labels for government or financial customers requiring per-site traffic accounting (RBI audit trails). Our CCIE Service Provider batch configures all three modes and compares LFIB size with show mpls forwarding-table vrf CUSTOMER_A—students often discover that per-prefix mode exhausts the label table on older hardware (ASR 9000 with 256k label limit).

MPLS VPN troubleshooting follows a structured top-down approach: verify PE-CE routing, check VRF route installation, validate MP-BGP advertisement, confirm label allocation, and trace MPLS forwarding hop-by-hop. Each layer has specific show commands and common failure modes.

Step 1: Verify PE-CE routing (control plane at the edge)

show ip route vrf CUSTOMER_A
show ip ospf neighbor vrf CUSTOMER_A
show ip bgp vpnv4 vrf CUSTOMER_A neighbors
show ip eigrp vrf CUSTOMER_A neighbors

Common failures: PE-CE protocol down (interface shutdown, ACL blocking protocol packets, mismatched OSPF area or EIGRP AS), routes learned but not installed (administrative distance issue, route-map filtering).

Step 2: Check MP-BGP advertisement (control plane in the core)

show bgp vpnv4 unicast all
show bgp vpnv4 unicast vrf CUSTOMER_A 10.2.2.0/24
show bgp vpnv4 unicast all neighbors 198.51.100.2 advertised-routes
show bgp vpnv4 unicast all neighbors 198.51.100.2 routes

Common failures: MP-BGP session down (loopback not reachable via IGP, update-source mismatch, send-community extended missing), route-target mismatch (export RT on one PE doesn't match import RT on remote PE), route reflector not reflecting VPNv4 routes (RR not configured with address-family vpnv4).

Step 3: Validate label allocation (MPLS forwarding plane)

show mpls forwarding-table vrf CUSTOMER_A
show mpls ldp bindings
show mpls label range

Common failures: VPN label not allocated (VRF not configured with mpls label mode), transport label not allocated (LDP not enabled on core interfaces with mpls ip, LDP session down), label exhaustion (platform ran out of labels, check show mpls label range and show platform hardware qfp active feature mpls label on ASR 1000).

Step 4: Trace MPLS forwarding hop-by-hop

traceroute vrf CUSTOMER_A 10.2.2.2
ping vrf CUSTOMER_A 10.2.2.2 source 10.1.1.1
show mpls forwarding-table 198.51.100.3 detail

Common failures: MTU mismatch (MPLS adds 8 bytes for two labels, so if core MTU is 1500, customer packets larger than 1492 bytes are fragmented or dropped if DF bit is set—solution: enable mpls mtu 1508 on core interfaces or reduce customer MTU), TTL expiry (customer uses traceroute with TTL=1, packet expires at first P router—solution: disable TTL propagation with no mpls ip propagate-ttl), blackhole at egress PE (VPN label points to VRF but VRF FIB has no route to destination—check redistribution from MP-BGP into PE-CE protocol).

In our HSR Layout lab, we inject faults into a working MPLS topology (disable LDP on one core link, misconfigure RT on one PE, set wrong VRF on CE-facing interface) and students must diagnose within 15 minutes using only CLI—no packet captures. This mirrors the CCIE Service Provider troubleshooting section and the real-world NOC environment at Cisco TAC India, where our alumni work.

MPLS L3VPN provides logical isolation via VRFs and label switching, but it does not encrypt traffic, does not authenticate PE-CE routing updates by default, and relies on the service provider's physical security and operational discipline to prevent cross-customer leakage. Enterprises must layer additional controls for regulatory compliance and defense-in-depth.

Key security properties and gaps:

• No encryption: MPLS frames traverse the provider backbone in cleartext. An attacker with physical access to a provider fiber link or a compromised P router can capture customer traffic. For PCI-DSS, HIPAA, or DPDP Act compliance, enterprises must overlay IPsec or MACsec on top of MPLS VPN.
• VRF isolation depends on correct configuration: If a provider engineer accidentally assigns two customers' interfaces to the same VRF, those customers can route to each other. There is no cryptographic enforcement—VRF isolation is a configuration construct, not a hardware or protocol guarantee.
• PE-CE routing protocol security: By default, OSPF, EIGRP, and BGP between PE and CE have no authentication. An attacker who gains access to a customer site can inject routes into the MPLS VPN. Best practice: enable MD5 authentication on PE-CE protocols (ip ospf authentication message-digest, neighbor X.X.X.X password for BGP).
• Label spoofing: If an attacker can inject MPLS-labeled packets into the provider network (e.g., via a compromised CE or a rogue device on a provider access link), they could craft packets with arbitrary VPN labels to reach other customers' VRFs. Mitigation: PE routers must filter MPLS packets arriving on CE-facing interfaces (no mpls ip on CE interfaces, or use mpls label protocol ldp to restrict label distribution to trusted peers).
• DDoS and resource exhaustion: A compromised CE can flood the PE with routing updates (BGP route flapping, OSPF LSA storms) or data plane traffic, exhausting PE CPU or memory. Mitigation: rate-limit PE-CE routing updates (neighbor X.X.X.X maximum-prefix for BGP, ip ospf flood-reduction), apply ingress policing on CE interfaces.

Regulatory context in India:

RBI's Master Direction on Information Security (2016) requires banks to encrypt "sensitive data in transit." MPLS VPN alone does not satisfy this—banks must deploy IPsec over MPLS or use MACsec (IEEE 802.1AE) on provider handoff links. CERT-In's 2022 directions on logging require enterprises to retain traffic logs for 180 days; MPLS providers typically offer NetFlow/sFlow exports from PE routers, but these capture only flow metadata (5-tuple + byte/packet counts), not payload. For full packet capture (lawful intercept), providers use per-CE label mode and mirror traffic to a mediation device.

In our Network Security Operations Division internship, students configure IPsec over MPLS VPN (GRE tunnel between CEs, IPsec transport mode over the tunnel) and compare overhead: MPLS VPN alone adds 8 bytes (two labels); IPsec ESP adds 50–57 bytes (depending on encryption algorithm and padding). For a 1500-byte Ethernet frame, the effective customer payload drops to ~1435 bytes with IPsec over MPLS, requiring Path MTU Discovery or MSS clamping on the CE routers. This exact scenario is a common issue at Infosys and HCL when migrating legacy MPLS customers to SD-WAN with IPsec overlays.