PE-CE Routing Protocols in MPLS L3VPN: Static, OSPF, EIGRP, and BGP

Once the MPLS core is built and MP-BGP is carrying VPNv4 between your PEs, one question remains: how does a PE router actually learn the customer's routes? That is the PE-CE routing protocol, and it is the one part of an L3VPN the customer has an opinion about.

You have four realistic choices: static routes, OSPF, EIGRP, or eBGP. They are not interchangeable. Each changes what the customer sees in their routing table, how quickly the VPN reconverges, and how much of the provider's design leaks into the customer's network. This article runs three of them back to back on the same lab and shows exactly what changes. If you have not built the VPN yet, start with MPLS L3VPN configuration step by step, and see the MPLS cluster guide for the wider picture.

The Lab

Five IOS XE routers: CE1 - PE1 - P - PE2 - CE2. Provider AS 65000, VRF CUST-A with RD and RT 65000:1, OSPF plus LDP in the core, MP-iBGP VPNv4 between the PEs. Customer site 1 is 192.168.99.0/24 (a real Debian host); site 2 is 10.20.20.0/24 on CE2. The PE-CE links are 10.20.1.0/30 and 10.20.2.0/30.

The core never changes across the three runs. Only the PE-CE protocol does.

The One Pattern That Applies to All Four

Whatever protocol you pick, the PE does the same two things:

1. Learn the customer's prefixes into the VRF routing table (via static, OSPF, EIGRP, or eBGP).
2. Get those prefixes into MP-BGP, under address-family ipv4 vrf CUST-A, so they can be tagged with an RT and a VPN label and shipped to the far PE.

And in the other direction, take the VPNv4 routes that arrive from the far PE and hand them back to the customer in whatever protocol the customer speaks.

Step 2 is where people get burned. A route sitting in the VRF routing table is not in MP-BGP. It gets there only via redistribute (static, connected, OSPF, EIGRP) or automatically, if the PE-CE protocol is BGP. Miss it and the route exists on one PE and nowhere else, with no error message anywhere. That failure has its own walkthrough in Troubleshooting MPLS L3VPN.

Option 1: Static Routes

The simplest option, and more common in production than the certification material suggests. Small sites, a single subnet, no need for the customer to run a routing protocol at all.

PE1(config)# ip route vrf CUST-A 192.168.99.0 255.255.255.0 10.20.1.2
PE1(config)# ip route vrf CUST-A 1.1.1.1 255.255.255.255 10.20.1.2
PE1(config)# router bgp 65000
PE1(config-router)#  address-family ipv4 vrf CUST-A
PE1(config-router-af)#   redistribute connected
PE1(config-router-af)#   redistribute static

Two commands you cannot forget: the vrf keyword on the static route (a plain ip route lands in the global table and does nothing for the customer), and redistribute static under the VRF address family.

The CE gets a default route and nothing else:

CE1(config)# ip route 0.0.0.0 0.0.0.0 10.20.1.1

The result on PE1, with static in both directions:

PE1#show ip route vrf CUST-A

Routing Table: CUST-A
      1.0.0.0/32 is subnetted, 1 subnets
S        1.1.1.1 [1/0] via 10.20.1.2
      2.0.0.0/32 is subnetted, 1 subnets
B        2.2.2.2 [200/0] via 10.255.0.2, 00:00:11
      10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
C        10.20.1.0/30 is directly connected, Ethernet0/0
L        10.20.1.1/32 is directly connected, Ethernet0/0
B        10.20.2.0/30 [200/0] via 10.255.0.2, 00:00:11
B        10.20.20.0/24 [200/0] via 10.255.0.2, 00:00:11
S     192.168.99.0/24 [1/0] via 10.20.1.2

Local site routes are S, far site routes are B with a next hop of the remote PE loopback. Clean and predictable.

The catch is that it is static. If the customer adds a subnet, someone raises a change request against the provider. If the CE link fails, the static route stays in the table until the interface goes down, and if the CE is reachable over a switch it may not. It scales to about "one subnet per site" before it becomes a burden.

Option 2: OSPF

The most common enterprise choice, because the customer is usually already running OSPF and does not want to change. The PE runs an OSPF process inside the VRF and redistributes both ways.

PE1(config)# router ospf 10 vrf CUST-A
PE1(config-router)#  router-id 10.255.0.1
PE1(config-router)#  domain-id 0.0.0.1
PE1(config-router)#  network 10.20.1.1 0.0.0.0 area 0
PE1(config-router)#  redistribute bgp 65000 subnets
PE1(config)# router bgp 65000
PE1(config-router)#  address-family ipv4 vrf CUST-A
PE1(config-router-af)#   redistribute ospf 10

Note the two redistributions, in opposite directions. redistribute bgp 65000 under the OSPF process takes routes learned from the far site over MP-BGP and hands them to the CE. redistribute ospf 10 under the BGP VRF address family takes the CE's routes and puts them into MP-BGP. Configure one and not the other and traffic works in exactly one direction, which is a memorable afternoon.

The CE runs plain OSPF, with no idea a VPN is involved:

CE1(config)# router ospf 10
CE1(config-router)#  network 10.20.1.2 0.0.0.0 area 0
CE1(config-router)#  network 192.168.99.1 0.0.0.0 area 0

Adjacency comes up between CE and PE like any other OSPF neighbor:

PE1#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.255.0.3        1   FULL/DR         00:00:38    10.30.30.2      Ethernet0/1
1.1.1.1           1   FULL/BDR        00:00:39    10.20.1.2       Ethernet0/0

Two adjacencies on PE1: one in the global table to the P router (the core IGP), one inside VRF CUST-A to CE1. Same router, same protocol, completely separate topology databases. That is worth pausing on.

The interesting part: routes come back as O IA

Here is CE1's routing table once both ends are up:

CE1#show ip route ospf

      2.0.0.0/32 is subnetted, 1 subnets
O IA     2.2.2.2 [110/21] via 10.20.1.1, 00:00:52, Ethernet0/1
      10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
O IA     10.20.2.0/30 [110/11] via 10.20.1.1, 00:01:18, Ethernet0/1
O IA     10.20.20.0/24 [110/21] via 10.20.1.1, 00:00:25, Ethernet0/1

Not O E2, which is what you would expect from redistribution. O IA, inter-area. The MPLS backbone is presenting itself to the customer as an OSPF superbackbone: a virtual area 0 that sits above the customer's own areas. Routes that cross the VPN arrive looking like they came from another area of the customer's own OSPF domain, not like external redistributed routes.

This is deliberate, and it is controlled by the domain-id. When both PEs use the same domain ID, MP-BGP carries the OSPF route type in an extended community and the far PE regenerates the route as inter-area rather than external. Set different domain IDs on the two PEs and the same routes reappear as O E2 externals with a metric type of 2. Customers usually prefer the inter-area behaviour, because external routes lose to internal ones and can create surprising path selection at sites with a backdoor link.

The sham-link problem

Which leads to the classic OSPF-over-L3VPN gotcha. If the customer has a backdoor link between two sites (say a cheap DSL failover circuit) and runs OSPF over the VPN, the backdoor link is an intra-area OSPF path while the VPN is inter-area. Intra-area always wins. The customer's traffic quietly abandons the expensive MPLS circuit and pours down the backup DSL link.

The fix is an OSPF sham-link: a logical intra-area link between the two PEs inside the VRF, which makes the VPN path look intra-area too and lets normal cost comparison decide. If your customer has backdoor links and OSPF, you need sham-links; if they do not, you can happily ignore them.

Option 3: EIGRP

Same structural pattern as OSPF, Cisco-only, and worth knowing because plenty of enterprise networks still run it. See the EIGRP cluster guide for the protocol itself.

PE1(config)# router eigrp 100
PE1(config-router)#  address-family ipv4 vrf CUST-A autonomous-system 100
PE1(config-router-af)#   network 10.20.1.1 0.0.0.0
PE1(config-router-af)#   redistribute bgp 65000 metric 100000 100 255 1 1500
PE1(config)# router bgp 65000
PE1(config-router)#  address-family ipv4 vrf CUST-A
PE1(config-router-af)#   redistribute eigrp 100

Two things differ from OSPF. First, EIGRP redistribution requires a metric (bandwidth, delay, reliability, load, MTU) or the routes are simply not redistributed, with no complaint. Second, EIGRP carries its original metric components across the VPN in BGP extended communities, so as long as the AS number matches on both PEs, the routes arrive at the far CE as internal EIGRP (D) rather than external (D EX). Mismatch the AS number and everything becomes D EX with an administrative distance of 170, which loses to almost everything else. It is the EIGRP equivalent of the OSPF domain-id trap.

Option 4: eBGP

The service provider's preferred option, and the only one with no redistribution at all. The customer gets their own AS number (or a private one) and peers eBGP with the PE inside the VRF.

PE1(config)# router bgp 65000
PE1(config-router)#  address-family ipv4 vrf CUST-A
PE1(config-router-af)#   neighbor 10.20.1.2 remote-as 65001
PE1(config-router-af)#   neighbor 10.20.1.2 activate
PE1(config-router-af)#   neighbor 10.20.1.2 as-override

The CE is a plain eBGP speaker:

CE1(config)# router bgp 65001
CE1(config-router)#  neighbor 10.20.1.1 remote-as 65000
CE1(config-router)#  network 192.168.99.0 mask 255.255.255.0
CE1(config-router)#  network 1.1.1.1 mask 255.255.255.255

No redistribution anywhere. Routes learned from the CE over eBGP go straight into the VRF's BGP table and are exported as VPNv4 automatically. This is the cleanest option and the reason providers push it. It also gives the customer real policy control, using the same attributes covered in the BGP cluster guide.

The session and the routes on PE1:

PE1#show ip bgp vpnv4 all summary
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.20.1.2       4        65001       5      10       40    0    0 00:00:37        2
10.255.0.2      4        65000      19      17       40    0    0 00:06:40        4

PE1#show ip bgp vpnv4 all
     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65000:1 (default for vrf CUST-A)
 *>   1.1.1.1/32       10.20.1.2                0             0 65001 i
 *>i  2.2.2.2/32       10.255.0.2               0    100      0 65001 i
 *>   10.20.1.0/30     0.0.0.0                  0         32768 ?
 *>i  10.20.2.0/30     10.255.0.2               0    100      0 ?
 *>i  10.20.20.0/24    10.255.0.2               0    100      0 65001 i
 *>   192.168.99.0     10.20.1.2                0             0 65001 i

Two neighbors on one router: the eBGP session to the customer (AS 65001) and the iBGP VPNv4 session to PE2. The customer's routes carry AS path 65001 i.

The AS-path problem, and as-override

Here is the wrinkle that makes eBGP PE-CE more subtle than it looks. Most customers use the same AS number at every site, because they were told to and because it is simpler. But BGP has a built-in loop prevention rule: if a router sees its own AS in the AS path of an incoming update, it drops the route.

So CE1 (AS 65001) advertises 192.168.99.0/24 with path 65001. It crosses the VPN. PE2 sends it to CE2 with path 65000 65001. CE2 is also AS 65001, sees its own AS in the path, and discards the route. The VPN is up, MP-BGP is healthy, and the two sites cannot talk.

neighbor x.x.x.x as-override is the fix. The PE rewrites the customer's AS number in the path with its own before advertising to the CE. The result on CE2:

CE2#show ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
 *>   1.1.1.1/32       10.20.2.1                              0 65000 65000 i
 *>   2.2.2.2/32       0.0.0.0                  0         32768 i
 *>   10.20.1.0/30     10.20.2.1                              0 65000 ?
 *>   10.20.20.0/24    0.0.0.0                  0         32768 i
 *>   192.168.99.0     10.20.2.1                              0 65000 65000 i

Look at the path on 192.168.99.0: 65000 65000. The original 65001 has been overwritten with the provider's AS. CE2 no longer sees itself in the path, accepts the route, and the sites reach each other:

CE2#ping 192.168.99.100 source Loopback1
Sending 5, 100-byte ICMP Echos to 192.168.99.100, timeout is 2 seconds:
Packet sent with a source address of 10.20.20.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/5/7 ms

(The alternative, allowas-in, is configured on the CE instead of the PE and tells the customer router to accept its own AS in the path. It works, but it requires touching every CE, and providers do not like depending on customer configuration for basic reachability. Use as-override on the PE.)

Choosing Between Them

The short version: providers want eBGP because it needs no redistribution and gives clean policy control. Enterprises want OSPF because they already run it. Static survives at small sites because it is unbreakable and needs no protocol knowledge. EIGRP shows up where the customer is a long-standing Cisco shop.

FAQ

Can different sites in the same VPN use different PE-CE protocols?

Yes. The VRF and MP-BGP do not care. Site A can run eBGP, site B OSPF, site C static. Everything meets in the VRF's BGP table. It is common during migrations.

Why does the customer see O IA instead of O E2?

Because the MPLS backbone acts as an OSPF superbackbone and, when the PEs share a domain-id, the original route type is carried across MP-BGP and regenerated. This is the intended behaviour.

Do I need a sham-link?

Only if the customer runs OSPF over the VPN and has a backdoor link between sites. Without a backdoor link, there is no intra-area path to lose to.

as-override or allowas-in?

as-override, on the PE. It solves the problem without requiring configuration on every customer router.

Key Takeaways

• Every PE-CE option needs the customer's routes to end up in MP-BGP under address-family ipv4 vrf. With static, OSPF, and EIGRP that means an explicit redistribute. With eBGP it is automatic.
• Redistribution runs in both directions. One-way redistribution gives you one-way traffic.
• OSPF over L3VPN presents the backbone as a superbackbone, so routes arrive as O IA. The domain-id controls whether they look inter-area or external.
• EIGRP redistribution into BGP silently does nothing without a metric, and the AS number must match on both PEs or routes downgrade to D EX.
• eBGP is the cleanest option but needs as-override whenever the customer uses the same AS at multiple sites. The AS path becomes 65000 65000 once it is on.

Continue with the full L3VPN configuration walkthrough, RD vs RT explained, or the MPLS cluster guide.