What is the difference between VPLS, AToM and MPLS L3VPN? Start with the service the customer receives, not the fact that all three can use an MPLS backbone.
Short answer: a basic AToM pseudowire provides a point-to-point Layer 2 connection; VPLS provides a multipoint Ethernet LAN; MPLS L3VPN provides routed IP connectivity using provider-edge VRFs.[3][1][2]
VPLS vs AToM vs L3VPN at a glance
CE means customer edge, PE means provider edge, and AC means attachment circuit: the customer-facing connection into the service.[1][2]
| Question | AToM / basic VPWS | Classic VPLS | BGP/MPLS L3VPN |
|---|---|---|---|
| Customer-facing model | Point-to-point Layer 2 circuit[3] | Multipoint Ethernet LAN[1] | Routed IP network[2] |
| Useful mental model | A virtual wire[3] | A distributed Ethernet switch[1] | A set of interconnected routing tables[2] |
| Main PE service decision | AC-to-pseudowire mapping[3] | Destination MAC lookup in the service's forwarding table[1] | Destination IP lookup in a VRF[2] |
| Customer reachability | Circuit endpoints, not customer IP routes[3] | MAC learning on ACs and pseudowires[1] | IP routes exchanged through MP-BGP and PE-CE routing/static configuration[2] |
| Broadcast behavior | Frames cross the point-to-point service[3] | Broadcast and unknown-unicast flooding within the service[1] | Does not create a shared customer Ethernet broadcast domain[2] |
| First service-specific check | Pseudowire and AC status[3] | MAC table, PW membership and flooding[1] | VRF routes and route-target import/export policy[2] |
Terminology trap: AToM means Any Transport over MPLS and is Cisco terminology for transporting Layer 2 services over MPLS; VPWS describes the point-to-point service model.[3] Do not treat AToM and VPLS as unrelated physical transports: VPLS itself uses pseudowires to connect its bridging instances.[1]
Who owns routing?
With a basic Layer 2 pseudowire, the PE carries the customer's Layer 2 payload rather than selecting the remote destination from a customer IP routing table.[3] With VPLS, the PEs learn customer MAC addresses and bridge Ethernet frames across the emulated LAN.[1] Customer routers can therefore communicate across that LAN while the VPLS service performs Layer 2 forwarding.[1]
In the RFC 4364 L3VPN model, the provider participates in the customer's IP routing: PEs learn customer routes, distribute VPN routes using BGP, and route traffic through the appropriate VRFs.[2] A dynamic routing adjacency is not mandatory on every PE-CE link; static routing is also an option.[2] The provider's core P routers do not need the customer VPN routes.[2]
My recommended interview follow-up is: “Do we need to transport an Ethernet segment, or do we only need IP reachability between separate subnets?” That question prevents a technology-name comparison from turning into a guessing exercise.
Packet flow: the same backbone, different services
The following examples are conceptual, not captured router output or an executed lab. Site A, B and C are fictional.
AToM: one circuit between two sites
Site A -- AC -- PE-A === MPLS pseudowire === PE-B -- AC -- Site B
- PE-A receives a customer frame on an AC associated with a pseudowire.[3]
- It adds the pseudowire/VC label and the transport encapsulation needed to reach PE-B; a control word may also be present.[3]
- Core forwarding uses the transport label, while the receiving PE uses the PW label to identify the service and deliver the frame to the appropriate AC.[3]
The useful distinction is circuit mapping, not multipoint MAC-based selection: a basic point-to-point cross-connect does not need a VPLS-style remote MAC lookup to choose among several sites.[3]
VPLS: a LAN across several sites
Site A -- PE-A ===== PE-B -- Site B
\ /
PE-C
|
Site C
In classic LDP-signaled VPLS, PE-A learns a source MAC on the local AC and forwards known unicast traffic toward the destination MAC's learned AC or pseudowire.[1] If the destination is unknown, the frame is flooded to the eligible service members; broadcasts are also replicated within the service.[1]
A basic full-mesh VPLS uses split horizon: a PE must not forward a frame received on one mesh pseudowire onto another pseudowire in that same mesh.[1] This is not a universal prohibition on all pseudowire-to-pseudowire forwarding: hierarchical VPLS distinguishes spoke connectivity from the mesh.[1]
MPLS L3VPN: route between separate subnets
Site A subnet -- CE-A -- PE-A [VRF] === MPLS === PE-B [VRF] -- CE-B -- Site B subnet
PE-A associates an arriving IP packet with a VRF and performs a destination lookup there.[2] For a remote VPN route, forwarding uses the advertised VPN label plus transport toward the remote PE; the egress label determines the appropriate forwarding context or action.[2] The remote PE delivers the packet toward the destination CE.[2]
An RD makes VPN route identities distinct, while route targets control route distribution into VRFs; neither is a substitute for verifying the actual forwarding route.[2]
Which service would you choose?
The following is a design starting point, not a product-selection rule:
- Two endpoints need a Layer 2 circuit: consider VPWS/AToM, then validate encapsulation, MTU, redundancy and operational support.
- Several endpoints genuinely need one Ethernet LAN: consider VPLS, but explicitly review broadcast containment, MAC scale and the failure domain.
- Sites only need IP connectivity: start by evaluating L3VPN rather than stretching Layer 2 without a requirement.
Do not infer “always LDP” from the word VPLS: RFC 4762 documents the LDP-signaled variant and explicitly distinguishes it from the BGP-signaled VPLS specification.[1] Also, these are service models—not a claim that a particular legacy implementation is the best choice for a new deployment.
Troubleshooting: separate transport from service
Use this checklist as a suggested investigation order. Record evidence before changing configuration.
| Symptom | First checks | What to avoid |
|---|---|---|
| AToM circuit is down | AC state, remote PE reachability, targeted LDP, PW identifier/type, advertised MTU and label status[3] | Treating a reachable PE loopback as proof that the customer circuit works |
| VPLS misses one remote host | MAC learning location, service membership, PW state and unknown-unicast flooding[1] | Editing L3VPN route targets for a classic LDP-VPLS MAC-learning problem |
| VPLS has MAC movement or excessive broadcast | Trace the attachment paths and validate loop prevention and flooding boundaries[1] | Assuming core split horizon eliminates every possible customer access loop |
| L3VPN misses a remote prefix | PE-CE routes, VPN route advertisement, import/export targets and destination VRF installation[2] | Assuming identical RDs guarantee connectivity |
| Small packets work but large packets fail | Compare AC/PW MTU settings and verify transport capacity for the actual encapsulation[3] | Randomly increasing MTU on only one endpoint |
For the Cisco IOS/IOS XE pseudowire implementation covered by the reference, a useful read-only starting point is:[3]
show mpls l2transport vc detail
Check local interface state, remote PE and VC ID, VC status, signaling state, local/remote labels, MTU, control-word status and packet/drop counters.[3] Command availability and output vary by platform and release; this is a verification prompt, not a configuration recipe.
My acceptance test would combine service-state checks with actual customer-endpoint traffic in both directions and representative packet sizes. Do not present a green control-plane status as an application test.
Common interview pitfalls
- “L2VPN means VPLS.” Point-to-point pseudowire services are also Layer 2 VPN services.[3]
- “VPLS routes customer IP prefixes.” Classic VPLS forwarding is based on Ethernet MAC learning, not the RFC 4364 VPN route model.[1][2]
- “Every L3VPN CE must run BGP.” PE-CE route exchange can use other routing protocols or static routes.[2]
- “The PW label and transport label do the same job.” One identifies the pseudowire at its endpoint; the other carries traffic across the transport network.[3]
- “MPLS VPN means encryption.” VPLS separation does not itself encrypt customer frames; RFC 4762 calls for encryption/authentication before entering the provider network when required.[1]
A concise interview answer
An original answer you can adapt:
“I distinguish them by the customer service. AToM commonly gives me a point-to-point Layer 2 pseudowire, VPLS gives me a multipoint Ethernet LAN, and MPLS L3VPN gives me routed connectivity through PE VRFs.”[3][1][2]
Then explain the forwarding evidence: PW/AC mapping for the wire, MAC learning for the LAN, and VRF routes for the routed VPN.[3][1][2]
Related reading
- RD vs RT in MPLS L3VPN
- MPLS PHP and LFIB: label popping and packet flow
- MPLS L3VPN route-target troubleshooting
Summary
Remember the progression: wire, LAN, routed VPN.[3][1][2] For an interview, pair each term with a forwarding decision and a troubleshooting check rather than memorizing only the acronym.
Preparing for a network engineering interview? Sketch all three services, explain who owns customer routing, and name the first piece of evidence you would collect when traffic stops.
Post a Comment