MPLS L3VPN has a reputation for complexity that is mostly misplaced. The complexity is concentrated in one device role and entirely absent from another, and understanding that distribution is most of what makes the technology tractable. Provider edge routers hold every virtual routing table, every VPN prefix and all the policy. Core routers hold none of it — they switch labels and know nothing about any customer. The customer's own routers know nothing about MPLS at all.
That asymmetry is the whole design. A core router carrying a hundred customers' routes would not scale, and the label stack exists precisely so that it does not have to. Once that is clear, the pieces that look arbitrary — the route distinguisher, the two labels, the extended communities — each turn out to be solving a specific problem created by the previous piece.
This article covers what each role does and where the complexity sits, how a prefix actually travels between sites, how the customer boundary is configured for each routing protocol, why there are two labels rather than one, and the failure catalogue — which is dominated by two specific configuration omissions that produce a VPN where the underlying network is provably healthy. It is written for the lab rather than for the written exam, and sits alongside the rest of the CCIE Enterprise Infrastructure lab certification track.
Provider edge routers carry all the state; core routers switch labels and hold no customer information. Each construct exists to solve a problem created by the one before it.What Does Each Role Do, and Where Is the Complexity?
How is the work divided?
The customer's router runs an ordinary routing protocol with its provider edge and is unaware that anything unusual is happening. The provider edge holds a separate routing table per customer, translates between the customer's protocol and the VPN carrier protocol, assigns labels, and applies all the policy. The core routers forward on labels alone and hold no customer routes whatsoever. Almost every configuration line that matters lives on the provider edge.
A Deeper Dive into the Roles
Why the core holds nothing
This is the property that makes the design scale and it is achieved by the label stack rather than by any filtering. A packet crossing the core carries a label meaning "reach that provider edge", and the core routers switch on that label alone. They never examine the inner label, never see the customer's address, and would be no busier carrying a thousand customers than carrying one. Adding a customer is a change on two provider edges and nowhere else.
! A core router's entire relevant configuration
mpls ip
!
interface GigabitEthernet0/1
ip address 10.0.12.2 255.255.255.252
mpls ip
ip ospf 1 area 0
!
! And what it holds - no VRF, no customer routes
P1# show vrf
! ^ empty
P1# show bgp vpnv4 unicast all summary
! ^ not configured - a P router runs no BGP at all
P1# show mpls forwarding-table
! ^ this is its whole job
The provider edge, where everything lives
! A VRF, its identity and its policy
vrf definition CUST-A
rd 65000:100
address-family ipv4
route-target export 65000:100
route-target import 65000:100
exit-address-family
!
! The interface facing that customer
interface GigabitEthernet0/2
vrf forwarding CUST-A
ip address 172.16.1.1 255.255.255.252
!
! MP-BGP to the other provider edges
router bgp 65000
neighbor 10.255.0.2 remote-as 65000
neighbor 10.255.0.2 update-source Loopback0
!
address-family vpnv4
neighbor 10.255.0.2 activate
neighbor 10.255.0.2 send-community extended
! ^ without this, route targets are not carried
exit-address-family
Distinguisher and target, which are constantly confused
The distinguisher makes a prefix unique so that two customers using the same addresses do not collide inside the carrier protocol. The target decides which virtual tables a prefix is imported into. They are frequently given the same numeric value, which encourages the belief that they are the same thing, and they are not — changing a distinguisher does not change who receives a route, and changing a target does not affect uniqueness.
| Property | Route distinguisher | Route target |
|---|---|---|
| Purpose | Uniqueness | Policy |
| Carried as | Part of the prefix itself | An extended community |
| How many per route | Exactly one | Any number |
| Changing it affects | Nothing about who imports | Exactly who imports |
| Needed for hub-and-spoke | No | Yes — this is the mechanism |
Why an enterprise would build this at all
The technology is associated with carriers and the enterprise case is different but real. An organisation with genuinely separate networks that must share infrastructure — an acquired company with overlapping addressing, a regulated environment, a guest network, a partner extranet — has the same problem a carrier has and the same reasons the alternatives do not scale. Running a separate physical network per context is expensive; running everything in one table is not permitted.
The realistic alternative for a handful of contexts is VRF-Lite, which needs no label protocol and no carrier protocol and consumes an interface per context on every link between devices. That works well up to a point and stops working when either the context count or the path length grows, because the configuration burden is their product. L3VPN moves that burden to the edges and leaves the core untouched, which is exactly the trade that becomes worthwhile as a network gets larger.
Verifying the pieces independently
! The VRF exists and has the right policy
PE1# show vrf detail CUST-A | include Import|Export|RD
!
! The carrier protocol session is up
PE1# show bgp vpnv4 unicast all summary
!
! Routes are being carried with their targets
PE1# show bgp vpnv4 unicast all 10.10.10.0/24
! ^ look for "Extended Community: RT:65000:100"
! if that line is absent, targets are not being sent
!
! And the label switched path to the far PE exists
PE1# show mpls forwarding-table 10.255.0.2
How Does a Prefix Travel From One Site to Another?
What are the steps?
Six. The customer advertises it normally. The provider edge places it in the virtual table, makes it unique with a distinguisher and tags it with targets. The carrier protocol moves it to the far provider edge along with a label. That router imports it into any virtual table whose import list matches. The distinguisher is stripped and an ordinary route appears. The far customer learns it by whatever protocol it runs. Each step can be verified independently, which is what makes this tractable to troubleshoot.
A Deeper Dive into the Journey
From customer protocol into the virtual table
Whatever protocol runs with the customer places routes into the virtual table, and from there they have to enter the carrier protocol. When the customer protocol is BGP that happens automatically within the address family. When it is anything else — an interior protocol, static routes — it requires explicit redistribution in both directions, and forgetting one direction produces a VPN that works one way.
! Customer runs an interior protocol: both directions needed
router ospf 100 vrf CUST-A
redistribute bgp 65000 subnets
! ^ VPN routes out to the customer
network 172.16.1.0 0.0.0.3 area 0
!
router bgp 65000
address-family ipv4 vrf CUST-A
redistribute ospf 100 vrf CUST-A match internal external 1 external 2
! ^ customer routes into the VPN
exit-address-family
!
! Customer runs BGP: no redistribution at all
router bgp 65000
address-family ipv4 vrf CUST-A
neighbor 172.16.1.2 remote-as 65100
neighbor 172.16.1.2 activate
exit-address-family
What the carrier protocol actually carries
! The prefix as it exists between provider edges
PE1# show bgp vpnv4 unicast all 10.10.10.0/24
BGP routing table entry for 65000:100:10.10.10.0/24
! ^ distinguisher : prefix
Local
10.255.0.2 (metric 30) from 10.255.0.2 (10.255.0.2)
Origin incomplete, localpref 100, valid, internal, best
Extended Community: RT:65000:100
mpls labels in/out nolabel/24012
! ^ the VPN label the far PE assigned to this prefix
!
! The same prefix once imported into a VRF
PE1# show ip route vrf CUST-A 10.10.10.0
! ^ an ordinary IPv4 route. The distinguisher is gone.
Import, which is where policy happens
A provider edge receives every VPN prefix its peers send and imports each into whichever virtual tables have a matching target in their import list. Prefixes matching nothing are held or discarded. That is the entire policy mechanism, and it is what builds any topology the customer wants — full mesh by using one target everywhere, hub and spoke by using two, shared services by importing a third.
! Hub and spoke, expressed entirely in targets
! ===== spoke VRF =====
vrf definition CUST-A-SPOKE
rd 65000:101
address-family ipv4
route-target export 65000:101
route-target import 65000:100
! ^ imports only what the hub exports
exit-address-family
!
! ===== hub VRF =====
vrf definition CUST-A-HUB
rd 65000:100
address-family ipv4
route-target export 65000:100
route-target import 65000:101
! ^ imports every spoke
exit-address-family
!
! Spokes cannot reach each other: neither imports the
! other's export target. No filtering was needed.
Where each step can break
| Step | If the prefix is missing here | Check |
|---|---|---|
| Source virtual table | The customer is not advertising it | The customer boundary protocol |
| Source carrier protocol | Redistribution missing | The address family configuration |
| Destination carrier protocol | Session, or export target | Session state and the export list |
| Target present on arrival | Extended communities not enabled | The carrier session capability |
| Destination virtual table | Import target mismatch | Both target lists, compared |
| Advertised to the far customer | Boundary policy, or the customer's own AS | Outbound filters, AS handling |
Tracing the journey when it fails
Each of the six steps has a command, and running them in order finds the break without guesswork. Present in the virtual table at the source, present in the carrier protocol at the source, present in the carrier protocol at the destination, imported at the destination, present in the destination virtual table, advertised to the far customer. The step where the prefix disappears is the step that is broken.
! Follow the prefix, step by step
!
PE1# show ip route vrf CUST-A 10.10.10.0
! ^ 1. is it in the source virtual table?
!
PE1# show bgp vpnv4 unicast vrf CUST-A 10.10.10.0
! ^ 2. did it enter the carrier protocol?
!
PE2# show bgp vpnv4 unicast all 10.10.10.0
! ^ 3. did it arrive? if not: session, or export target
!
PE2# show bgp vpnv4 unicast all 10.10.10.0 | include Extended
! ^ 4. does it carry a target? if not: send-community
!
PE2# show ip route vrf CUST-A 10.10.10.0
! ^ 5. was it imported? if not: import target mismatch
!
PE2# show bgp vpnv4 unicast vrf CUST-A neighbors 172.16.2.2 advertised-routes
! ^ 6. was it given to the customer?
How Is the Customer Boundary Configured?
Which protocol should run with the customer?
BGP where the customer can run it, because it integrates with the carrier protocol without redistribution and carries policy naturally. Static where the customer's routes are few and stable. An interior protocol where the customer insists, accepting that it requires redistribution in both directions and, for one of them, some additional machinery to prevent loops. The choice affects the provider edge configuration considerably and the core not at all.
A Deeper Dive into the Boundary
BGP, which is the clean case
! Nothing but a neighbour inside the address family
router bgp 65000
address-family ipv4 vrf CUST-A
neighbor 172.16.1.2 remote-as 65100
neighbor 172.16.1.2 activate
neighbor 172.16.1.2 as-override
! ^ if the customer uses the same AS at every site
neighbor 172.16.1.2 soft-reconfiguration inbound
neighbor 172.16.1.2 prefix-list FROM-CUST in
neighbor 172.16.1.2 maximum-prefix 500 80 restart 30
exit-address-family
!
! Routes move between the VRF and the carrier protocol
! automatically. No redistribution is written anywhere.
The same customer AS at every site
Customers frequently use one private AS number at all their sites, which means a route advertised from one site arrives at another carrying that AS in its path and is discarded as a loop. Two mechanisms fix it: rewriting the customer's AS on the way out, or telling the customer's router to accept its own AS. The first is a provider edge change and is generally preferable because it requires nothing of the customer.
! On the PE - rewrite the customer's AS outbound
neighbor 172.16.1.2 as-override
!
! Or on the CE - accept our own AS inbound
neighbor 172.16.1.1 allowas-in 1
!
! The symptom without either: the route is present in
! the VPN and never reaches the far customer
PE2# show bgp vpnv4 unicast vrf CUST-A neighbors 172.16.2.2 advertised-routes
CE2# show ip bgp | include 10.10.10.0
! ^ present on the PE, absent on the CE
An interior protocol, which needs loop prevention
Running an interior protocol with the customer creates a path by which a route can leave the VPN, reach a customer site, and be advertised back in — a loop the protocol cannot see because the VPN is invisible to it. The protocol carries a marker indicating a route has already been through the VPN, and provider edges discard routes carrying it. This is automatic and worth knowing about because it explains an otherwise puzzling class of missing route.
! An interior protocol per customer, per VRF
router ospf 100 vrf CUST-A
router-id 10.255.0.1
domain-id 0.0.0.100
! ^ decides whether far sites see these as internal
! or external routes
redistribute bgp 65000 subnets
network 172.16.1.0 0.0.0.3 area 0
capability vrf-lite
!
! Verify the marker is doing its job
PE2# show ip ospf database | include Down|DN
PE2# show ip ospf 100 database external
Dual-homed customer sites
A site connected to two provider edges is the usual arrangement for anything important, and it introduces the question of which path traffic takes and what happens when one fails. With BGP at the boundary that is ordinary path selection and the tools are the familiar ones. With an interior protocol it is metric manipulation plus whatever the loop prevention does, which is considerably less predictable.
The specific case worth planning for is a site whose two provider edges are in different locations, because then the customer's own network becomes a potential transit path between them. Preventing the customer from carrying provider traffic between its own sites is a filtering exercise at the boundary, and it is the kind of thing that works fine until the day a link fails and the traffic finds the unintended path.
Addressing the boundary links
The link between a provider edge and a customer router sits inside the virtual table, which means its addressing is the customer's problem space rather than the provider's. Two customers can use the same subnet on their respective boundary links with no conflict at all, because the two links live in separate tables that never see each other. This is the practical payoff of the whole design and it is worth demonstrating deliberately in a lab, because reading that overlapping address space is supported is less convincing than configuring the same subnet twice and watching both work.
What does need a decision is whether those boundary subnets are advertised into the VPN. They usually should be, because otherwise a traceroute from one customer site to another shows gaps, and because monitoring systems that ping the boundary address need a route to it. Advertising them means the addressing plan has to avoid collisions within a single customer even though collisions across customers are harmless — a distinction that is easy to state and easy to forget when a new site is added by someone working from the wrong document. Reading this once is not the same as being able to do it under time pressure, which is what repetition against realistic CCIE lab practice scenarios is for.
Choosing, in practice
| Customer protocol | Provider edge effort | Watch for | Suits |
|---|---|---|---|
| BGP | Lowest — no redistribution | Same AS at every site | Most customers |
| Static | Low | Redistribution into the VPN | Few, stable prefixes |
| OSPF | Highest | Domain identifier, loop marker, sham links | Customers who insist |
| EIGRP | Moderate | Redistribution both ways, metrics | Existing EIGRP estates |
How Does the Label Stack Work, and Why Two Labels?
What does each label mean?
The outer one means "get this to that provider edge" and is understood by every router in the core. The inner one means "this belongs to that virtual table" and is understood only by the provider edge that assigned it. Separating them is what lets the core forward without knowing anything about customers, and it is the single design decision from which the technology's scalability follows.
A Deeper Dive into Labels
Where each label comes from
The outer label is distributed by the label protocol running across the core, which advertises a label for every address in the routing table — including, crucially, each provider edge's own loopback. The inner label is assigned by the provider edge that originates a VPN prefix and travels with that prefix in the carrier protocol. Two independent mechanisms, and both must work.
! The outer label: from the core label protocol
PE1# show mpls forwarding-table 10.255.0.2 32
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
24004 24009 10.255.0.2/32 184221 Gi0/1 10.0.12.2
!
! The inner label: from the carrier protocol
PE1# show bgp vpnv4 unicast all 10.10.10.0/24 | include labels
mpls labels in/out nolabel/24012
!
! And the combined result actually used for forwarding
PE1# show ip cef vrf CUST-A 10.10.10.0 detail
! ^ shows both labels being pushed
The loopback must be a host route
The outer label is a label for the far provider edge's loopback, and the label protocol only advertises labels for exact host routes. A loopback that reaches the far router as part of a summary has no label, so no label switched path exists to it, so VPN traffic has nowhere to go — while the routing table looks entirely correct and the loopback pings perfectly. This is the most consequential single rule in the whole design.
! The loopback must arrive as a /32, everywhere
PE1# show ip route 10.255.0.2
Routing entry for 10.255.0.2/32
! ^ if this shows 10.255.0.0/24, the VPN will not work
!
! And it must have a label
PE1# show mpls ldp bindings 10.255.0.2 32
PE1# show mpls forwarding-table | include 10.255.0.2
! ^ an empty result here is the fault
!
! The usual cause, on a core router
P1# show run | include summary-address|area range
! ^ a summary covering the PE loopbacks
Penultimate hop popping
The router immediately before the destination provider edge removes the outer label rather than swapping it, because that router knows the next hop is the final destination and the label has no further use. The provider edge therefore receives a packet with only the VPN label on it, which is exactly what it needs and saves it one lookup. It is an optimisation and it explains why a capture at the provider edge shows one label rather than two.
! The penultimate router advertises "pop it"
P1# show mpls forwarding-table 10.255.0.2 32
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
24009 Pop Label 10.255.0.2/32 184221 Gi0/2 10.0.23.2
!
! Which is why PE2 sees only the VPN label arriving.
! An MPLS-aware trace shows the stack shrinking:
PE1# traceroute vrf CUST-A 10.10.10.1
! 1 ... [MPLS: Labels 24009/24012 Exp 0]
! 2 ... [MPLS: Label 24012 Exp 0] <- popped here
! 3 ... <- PE2, no labels
The label protocol is a separate thing to verify
Label distribution runs alongside the routing protocol and depends on it without being part of it. A neighbour relationship in the routing protocol does not imply a label session, and the two can be in different states on the same link. That independence is worth internalising because it produces the situation this technology is notorious for: a link where routing is perfect and labels are absent.
The practical habit is to check both on any link being investigated, and to treat a routing adjacency as proving nothing about labels. The two commands sit next to each other and take seconds, and running only the first is the source of a great deal of confusion.
! Routing adjacency and label session are separate
P1# show ip ospf neighbor
P1# show mpls ldp neighbor
! ^ both must be present on every core link
!
! Which interfaces are actually enabled for labels
P1# show mpls interfaces
!
! And the bindings the session produced
P1# show mpls ldp bindings
Why the MTU needs attention
Two labels add eight bytes to every packet, and a core that has not been configured for the larger frame will discard full-size customer packets. The symptom is the familiar one — small packets fine, real traffic failing — and it is diagnosed as an application problem far more often than as an MTU one. Raising the core MTU is a build-time decision that costs nothing and is awkward to retrofit.
! Eight bytes of labels on every packet
interface GigabitEthernet0/1
mpls mtu 1508
! or raise the interface MTU generally
mtu 9216
!
! Test it properly, from inside the VPN
PE1# ping vrf CUST-A 10.10.10.1 size 1500 df-bit
!
! And check what each core link allows
P1# show mpls interfaces detail | include MTU
P1# show interfaces | include MTU
show mpls forwarding-table has no entry for the far loopback; show ip route shows it as part of a larger prefix. Fix: advertise provider edge loopbacks as host routes and never summarise them — this is a rule rather than a preference.Which L3VPN Failures Are Not Routing Failures?
What are the failures worth memorising?
Four, and all of them leave the routing protocols looking correct. The missing extended community capability, which carries prefixes without their targets. The summarised loopback, which removes the label switched path. A target mismatch, which delivers prefixes nobody imports. And the reflector that discards VPN prefixes it holds no targets for, which breaks a design the moment a reflector is introduced.
A Deeper Dive into the Failure Catalogue
Prefixes arriving without their targets
show bgp vpnv4 unicast all <prefix> shows the prefix with no extended community line. Fix: add the extended community capability to every carrier session, on both ends, and note that a session established before it was added needs to be reset for the change to take effect.The reflector that filters
The target mismatch
When only one direction works
One-way reachability is the most misread symptom in this design, because the instinct is to look for something wrong with the path and there is nothing wrong with the path. A route target relationship is directional. Site A exporting a target that site B imports gets A's prefixes into B's table, and says nothing whatever about whether B's prefixes reach A. Two separate statements are needed for two-way reachability, and a hub-and-spoke design deliberately makes them asymmetric.
So a site that can be reached but cannot reply is usually not a forwarding problem at all. It is an import list missing one entry at the far end. The confirmation is quick: look at the routing table of the virtual table at each end and see which one is missing the other's prefixes. The end that is missing them is the end whose import list is wrong, regardless of which end the user reported the problem from.
The same asymmetry appears in the label path, for a different reason. A label switched path is built per destination, so a path from A to B existing tells you nothing about B to A. A summarised loopback on one provider edge breaks traffic toward it while traffic away from it works perfectly, which produces exactly the same one-way symptom from an entirely different cause. Checking the label path in both directions, explicitly, separates the two in a few seconds.
! One-way reachability: check both directions explicitly
!
! Import relationship, from each end
PE1# show ip route vrf CUST-A | include 192.168.20.0
PE2# show ip route vrf CUST-A | include 192.168.10.0
!
! Label path, in each direction
PE1# ping mpls ipv4 10.255.0.2/32
PE2# ping mpls ipv4 10.255.0.1/32
A diagnostic order that works
! Underlay first, then labels, then the VPN
!
! 1. Does the core routing protocol have the loopbacks as /32?
PE1# show ip route 10.255.0.2
!
! 2. Is there a label switched path to it?
PE1# show mpls forwarding-table | include 10.255.0.2
PE1# ping mpls ipv4 10.255.0.2/32
!
! 3. Is the carrier session up and carrying prefixes?
PE1# show bgp vpnv4 unicast all summary
!
! 4. Do the prefixes carry their targets?
PE1# show bgp vpnv4 unicast all <prefix> | include Extended
!
! 5. Were they imported?
PE1# show ip route vrf CUST-A
!
! 6. Only now, the customer boundary
PE1# show bgp vpnv4 unicast vrf CUST-A summary
Building it in the right order
The dependencies run upward and building in that order means each layer is proven before the next depends on it. The core routing protocol first, with loopbacks as host routes. Then label distribution, verified on every link and to every loopback. Then the carrier protocol sessions between provider edges. Then the virtual tables and their targets. Then the customer boundaries. Five layers, each verifiable, and a failure at any point is contained to that layer.
Built in any other order, a failure at the bottom presents as a failure at the top and the investigation starts in the wrong place. This is the same argument as building any layered system bottom-up, and it applies with unusual force here because the upper layers can look completely healthy while the lower ones are broken.
What to monitor
Three things that ordinary routing monitoring does not cover. The count of label switched paths against the number of provider edges, which detects a summarised or unlabelled loopback before any customer does. The VPN prefix count per virtual table, which detects target and import problems. And core interface MTU as a compliance check rather than a metric, because it is set once and only noticed when a link is replaced. None of the three is expensive to collect, and each one catches a failure class that would otherwise be reported by a user rather than by a system. A weekly report is enough; the point is that somebody looks at the numbers on a schedule rather than only after a complaint.
What to capture before changing anything
The failures in this catalogue are all configuration state rather than transient events, which means a capture taken before the change and a capture taken after it will show the difference directly. Four outputs are enough: the VPN prefix count per virtual table, the label switched path count, the extended communities on one known prefix, and the import and export lists. Save them as text, per provider edge, before touching anything.
This matters more here than in a single-protocol network because the layers hide each other. A change to the core routing protocol that accidentally summarises a loopback shows up as a VPN failure hours later, with nothing in the VPN configuration having changed and nobody thinking to look at the core. The before-and-after capture turns that from an investigation into a diff.
Blueprint framing
The CCIE Enterprise Infrastructure v1.1 blueprint covers MPLS within the transport technologies domain, and L3VPN questions are usually about the mechanism rather than a full build: what the distinguisher does as opposed to the target, why there are two labels, and what each role holds. Being able to explain why the core carries no customer routes covers the conceptual core of it.
Conclusion
The complexity in MPLS L3VPN is concentrated on the provider edge and absent everywhere else. The customer's router runs an ordinary protocol and knows nothing. The core switches labels and holds no customer state whatsoever, which is the property that makes the design scale and is achieved entirely by the two-label stack. Everything else — the distinguisher, the targets, the carrier protocol — exists to make that division workable.
The distinguisher and the target are constantly conflated and do unrelated jobs: one provides uniqueness inside the carrier protocol, the other decides which virtual tables import a route. Only the second is policy, and every topology a customer might want — full mesh, hub and spoke, shared services — is built by choosing targets rather than by filtering anything.
What breaks in practice is rarely routing. A carrier session that does not carry extended communities delivers prefixes with no targets and nothing imports them. A provider edge loopback covered by a summary has no label and therefore no forwarding path, while every routing check passes perfectly. Both produce a VPN that fails on a network that is demonstrably healthy, and both are found in one command each — which is why the diagnostic order starts at the label path rather than at the routing table. More CCIE Enterprise Infrastructure material — labs, protocol breakdowns and study guides — is collected on the SPOTO CCIE site.
External Links
- RFC 4364 — BGP/MPLS IP Virtual Private Networks (VPNs)
- RFC 3031 — Multiprotocol Label Switching Architecture
- RFC 3032 — MPLS Label Stack Encoding
- RFC 4760 — Multiprotocol Extensions for BGP-4
- RFC 4577 — OSPF as the PE/CE Protocol in BGP/MPLS IP VPNs
- Cisco IOS XE — MPLS Layer 3 VPNs Configuration Guide
- Cisco Learning Network — CCIE Enterprise Infrastructure
Reference Notes
- RFC 4364 defines BGP/MPLS IP VPNs, including the provider edge, provider core and customer edge roles and their responsibilities.
- RFC 4364 defines the VPN-IPv4 address family, in which an 8-byte route distinguisher is prepended to an IPv4 prefix so that overlapping customer addresses remain unique.
- RFC 4364 defines route targets as BGP extended communities controlling which VRFs import a route, a function separate from the distinguisher's uniqueness role.
- RFC 4364 describes the two-label stack, in which the outer label reaches the egress provider edge and the inner label identifies the VPN and forwarding context.
- RFC 3031 specifies the MPLS architecture, including label switched paths and the distribution of labels for routes in the routing table.
- RFC 3032 specifies MPLS label stack encoding, giving each label entry a size of 4 bytes and defining the implicit null label used for penultimate hop popping.
- RFC 4760 defines the multiprotocol extensions to BGP used to carry VPN-IPv4 NLRI between provider edge routers.
- RFC 4577 specifies OSPF as the PE-CE protocol, including the down bit used to prevent routes re-entering the VPN and the domain identifier controlling route type translation.
- Cisco documentation states that route targets are carried as extended communities and that the extended community capability must be enabled on the VPNv4 session.
- Cisco documentation describes route target filtering, which by default causes a router to discard VPN prefixes whose targets match no locally configured VRF, and its effect on route reflectors.
- Cisco documentation notes that label distribution assigns labels to host routes, so provider edge loopbacks must be advertised as /32 prefixes for a label switched path to exist between them.
- The CCIE Enterprise Infrastructure v1.1 unified exam topics include MPLS within the transport technologies and virtualisation domain.