MPLS Layer 3 VPN PE-CE OSPF Sham Link

Lessons Discussion
1

This topic is to discuss the following lesson:

2

Hi Rene,
So, the sham link is required only for MPLS VPN scenario ?? Thx

br//zaman

3

That’s correct. MPLS VPN PE-CE with OSPF as the routing protocol between PE/CE.

4

Hi Rene,

In order for redistribution other routing protocols into OSPF on CE works properly, we have to setup Sham Link. Is that correct?
Looks like LSA type 5 & 7 are not exchanged cross MPLS backbone? Correct me if I’m wrong. Because I have tried redistribution other routing protocols into OSPF on CE without Sham Link and result is PE which connected directly with CE got the routes but other PEs didn’t got it.

Thanks,
Minh

5

Hello Minh,

Redistributed routes in OSPF on a CE router is no problem. You only need a sham link when you have a backdoor link in between your CE routers.

By default, OSPF external routes don’t get redistributed into BGP but you can change that. Here’s a quick example:

CE1(config)#interface Loopback 1
CE1(config-if)#ip address 11.11.11.11 255.255.255.255

CE1(config)#ip access-list standard CE1_L0
CE1(config-std-nacl)#permit host 11.11.11.11

CE1(config)#route-map CE1_L1 permit 10    
CE1(config-route-map)#match ip address CE1_L1

CE1(config)#router ospf 1
CE1(config-router)#redistribute connected route-map CE1_L1

On the PE1 router:

PE1(config)#router bgp 234
PE1(config-router)#address-family ipv4 vrf CUSTOMER
PE1(config-router-af)# redistribute ospf 2 match internal external 1 external 2

And it will show up on the other end:

CE2#show ip route | include 11.11
O E2     11.11.11.11 [110/20] via 192.168.45.4, 00:02:29, GigabitEthernet0/1

Hope this helps!

Rene

1 Like
6

Thank you, Rene.
Rgds,
Minh

1 Like
8

Hello @pradyumnayadavgla

It seems that you posted this in a private message. I will quote it here, and respond to it so that all of our readers can benefit.

Hi Rene,

Q1- Sham link can only be used for CE-PE OSPF not with other IGP like EIGRP and RIP?
Q2- can it is possible to use sham link when we are using OSPF for CE-PE connectivity
and other IGP using for providing reachability b/w IBGP neighbors or vice versa?
Q3- Did not understand concept of MPLS VPN backbone mean which link will act as
MPLS VPN backbone and if sham link is the MPLS VPN backbone link mean we are
having primary and sec MPLS VPN link and total two backbone link for each
customers

Q1 A sham link is an OSPF concept and cannot be implemented using other routing protocols.

Q2 A sham link can only be created when OSPF is the IGP in the MPLS backbone. If you are running EIGRP between the CE and PE, then a sham link, although it can be created, is of no benefit, because the redistribution between OSPF and EIGRP takes place in the PE, and there, you can adjust the metric of the EIGRP routes to achieve what you would with the sham link. Remember, the sham link is there because OSPF will always prefer an intra-area route (O) over an inter area route (O IA). The sham link simply changes the categorization of the O IA route to an O route so that it can be preferred. EIGRP doesn’t have such a concept, so it is not necessary.

Q3 The “VPN Backbone” is simply the MPLS network composed of the PE and P routers. The sham link isn’t the backbone, it is simply a mechanism that changes the categorization of the actual OSPF route. It’s not a tunnel of any sort, nor a backbone. The backbone is the MPLS network itself.

I hope this has been helpful!

Laz

9

Hi Laz,

Thanks for clarifying same but one more question is that, How many links are there for Customer to Customer reachabillity ?, I think there are two one is MPLS link and other one is OSPF link ( Through which customers connected directly ) .

10

Hello Pradyumna

Whenever you require a sham link for OSPF, this is due to the fact that a customer has obtained a backup link between the customer sites, most often with the goal of providing redundancy. This means that there will be two possible paths that data can take between two particular customer sites, one via the MPLS network, and the other via the backup link.

Usually, an MPLS network will be the primary method of interconnecting sites, due to the fact that it is typically a high performance network, and because customers will often have more than two sites. But some customers may want to use MPLS as backup. So the sham link is used only when you want the MPLS network to be the primary link that OSPF routing chooses.

You are correct, there are indeed two links between customer sites in a topology such as the one that is described in this lesson, one via MPLS and one via the backup link.

I hope this has been helpful!

Laz

11

Can we change the metric of the sham link?

12

Hello Muhammad

An example of the command used to implement the sham link is the following:

PE2(config-router)#area 0 sham-link 44.44.44.44 22.22.22.22 cost 10

The parameter cost 10 configures the metric of the sham link. If this is not configured, then the default cost is set to 1, which means it will most likely be chosen as the best path over alternate routes, which is what is desired.

I hope this has been helpful!

Laz

13

Hello @ReneMolenaar and @lagapidis,

I have two questions about the redistribution from BGP into OSPF.

  1. Question:

can you please explain, why CE1 sees the 5.5.5.5 route as an O IA route?
Looking at the redistribution configuration of PE1 I can see that BGP is redistributed into OSPF:

router ospf 2 vrf CUSTOMER
 redistribute bgp 234 subnets
 network 192.168.12.0 0.0.0.255 area 0

Why do we see this route as an O IA and not as an O E2 route?

  1. Question:

There is a rule that says, by default iBGP is not redistributed into OSPF.
Reference 1.
Reference 2.

Why does the redistribution work if we only use the command
redistribute bgp 234 subnets without the bgp redistribute-internal command?
Doesn’t this break the rule of not redistributing iBGP routes into OSPF by default?

Thank you.

14

Hello Thomas

Rene addresses this question in the lesson:

Our CE routers have learned each other’s networks. There’s something interesting in the output above…normally when we redistribute something into OSPF then our prefixes show up as O E2 or E1, now we seem to have O IA prefixes. I’ll explain why in a bit…

He goes on to explain that when used with MPLS, OSPF considers the MPLS service provider backbone as an OSPF “superbackbone”, and the PE routers as ASBRs. The result is that routes that originated in an OSPF area connected to a PE router of the MPLS network are considered IA routes even if they have been redistributed from BGP. Take a look at the text in the lesson that describes it in detail.

Note that the PE routers are running two instances of OSPF. The instance with process ID “1” is the OSPF instance that is running within the BGP domain of the MPLS backbone using ASN 234. Now if you attempted to redistribute into that OSPF process, you would indeed need the “redistribute-internal” keyword, because that OSPF process is the process serving the specific ASN.

However, the redistribution took place on OSPF process “2” which is the OSPF process running between the PE and CE routers, which is outside of the BGP domain. This means, by definition, that the redistribution is taking place on eBGP routes, not iBGP routes. So the rule is not violated. Does that make sense?

I hope this has been helpful!

Laz

15

Hi,

I just want to clarify the difference between a sham link and OSPF traffic redistributed and carried across the MPLS backbone.

For redistribution, OSPF information is included in the prefix’s extended community, however, a sham link carries native OSPF packets - is that correct? If so, does that mean redistribution is no longer necessary?

Sam

16

Hello Sam

Yes, you’re absolutely right about the key distinction. Indeed, in standard redistribution, OSPF route information is carried in BGP Extended Communities (route type, metric, domain ID, etc.), but the actual OSPF LSAs are NOT carried across the backbone. A sham link however carries native OSPF protocol packets (Hellos, DBDs, LSAs) between PE routers across the MPLS backbone.

However, redistribution is still absolutely necessary, the sham link does not replace it. The problem that sham links solve is this:

When a customer has a “backdoor” link (direct CE-to-CE connection) between sites, without a sham link routes via MPLS appear as Inter-Area, while routes via the backdoor appear as Intra-Area. Remember: Intra-Area (O) > Inter-Area (O IA) > External (O E1) > External (O E2), which means that traffic takes the suboptimal backdoor path instead of the MPLS backbone.

With sham link, both the MPLS path AND the backdoor path appear as Intra-Area routes. OSPF then uses cost/metric to select the best path, and the sham link cost can be tuned to ensure the MPLS backbone is preferred. Make sense?

I hope this has been helpful!

Laz

17

Hi Laz,

Thanks for getting back to me.

I labbed this up and removed redistribution on both PE routers from BGP to OSPF (VRF) and vice versa, and it didn’t work. However, after troubleshooting, I figured out that with a sham link you only needed to redistribute OSPF into BGP and not the other way round because the redistributed routes also contained VPN label information. So without it, the PE would receive traffic without any labels as the previous router had popped the only one it had and there was no inner MPLS header left containing the VPN label for it to know which VRF to forward traffic to.

And the CE routers were successfully forwarding traffic to the PE routers because the sham link was considered intra-area link and the lowest cost path was via it.

Sam

18

Hello Sam

Indeed, this i the case. The sham link creates a direct OSPF adjacency between PE routers within the VRF. This adjacency runs across the MPLS backbone and appears as an intra-area OSPF link. The result is (as you have correctly surmised) that the remote PE already has the customer routes in its OSPF database as intra-area routes learned via the sham link, so there’s no need to redistribute BGP routes into OSPF because OSPF is carrying them directly.

Well, not quite. Labels are assigned by MP-BGP, not by redistribution direction. OSPF-to-BGP redistribution is required because this is how routes enter the VPNv4 BGP table where they receive VPN labels, Route Distinguishers, and Route Targets.

Sham link endpoints (VRF loopbacks) must be advertised in MP-BGP (typically via network or redistribute connected in the BGP VRF address-family) so the sham link can be established. When BGP assigns a VPN label to a prefix, that label is used regardless of whether the route was later redistributed into OSPF.

Take a look at the data plane label operation:

  • Traffic from CE→PE arrives unlabeled (normal IP)
  • Ingress PE performs VRF lookup, finds the route, and imposes two labels:
    • Outer/transport label (LDP/RSVP) to reach egress PE
    • Inner VPN label (from MP-BGP) to identify the VRF
  • Penultimate hop pops only the outer label (PHP)
  • Egress PE receives packet with the VPN label still intact
  • Egress PE uses VPN label to select the correct VRF and forward to CE

So you see, the presence or absence of BGP-to-OSPF redistribution does not affect label operation. What matters is whether the destination prefix exists in the VRF BGP table with a VPN label assigned.

So the OSPF-to-BGP redistribution is required to get customer routes into VPNv4 BGP (assigns labels, RD, RT), and the sham link endpoints (the VRF loopbacks used as sham link endpoints) must be advertised in MP-BGP (via network or redistribute connected), but no BGP-to-OSPF redistribution is needed for customer prefixes (OSPF carries them via sham link). Make sense?

I hope this has been helpful!

Laz

19

Hi Laz,

Thanks for getting back to me.

Yeah, I get the purpose of RD’s and Route-targets.

Just to clarify what I mean, I discovered that a VPN ID/Label (and other information such as RD and RT) has to be assigned to a network and advertised into MP-BGP, either by using the network command or redistribution. That information is then propagated via the VPNV4 routes (in extended communities) to other PE site routers. PE routers will then use the VPN label to ensure data plane traffic is delivered to the correct VRF. So when the data traffic label is popped before the penultimate hop, the inner MPLS header (VLAN ID) remains for VRF forwarding on the PE router.

So, turning off redistribution from OSPF to BGP still meant other sites would forward traffic to the PE, because LSAs are being propagated via sham link and the path is calculated to be via the PE, but no VPNV4 entry would exist on the PE itself (which includes VPN label) causing end to end traffic to fail.

That’s how I understand it and this tallies with your explanation.

So, in theory, this means you could remove (filter) the OSPF extended community entries from the VPNV4 route and end to end traffic would still work.

Regards,

Sam

20

Hello Sam

I think you’ve got it spot on! You’ve nicely explained the way the control plane and data plane interact in MPLS L3VPN with OSPF sham links.

So when you disable redistribution from OSPF to MP-BGP while the sham link is active, you create a control/data plane mismatch. On the control plane, routes are still advertised via the sham link LSAs, making the MPLS path appear as the best intra-area route. On the data plane, no VPNv4 routes exist for those customer prefixes, so no VPN labels are assigned. The result is that traffic is attracted to the PE routers due to OSPF path preference, but the PE has no VPNv4 forwarding entry to label and forward the packets, thus causing a black hole.

Just one point of clarification. You referred to the inner MPLS header as the VLAN ID, but it’s the VPN label. I’m sure that’s what you meant, but sometimes it happens :stuck_out_tongue: .

In theory, yes, if you filter the OSPF-related extended communities (such as domain ID or route-type information) from the VPNv4 route, end-to-end forwarding can still work. However, it will only work as long as:

  • The VPNv4 route still exists
  • The correct Route Targets are present
  • A VPN label is assigned

Those OSPF extended communities mainly influence how the remote PE reintroduces the route into OSPF (for example, whether it is treated as intra-area, inter-area, or external). They do not control VPN label assignment or MPLS data-plane forwarding.

However, filtering them can change OSPF behavior and potentially break sham link operation or loop-prevention logic, so it should be done carefully.

I hope this has been helpful!

Laz