cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5216
Views
10
Helpful
9
Replies

OSPF Sham-Link : Redistribution

Hi

I was going through sham-link RFC & i found some thing intresting & but confusing.

I had simulated the LAB for sham link & checked that we won't require redistribution between MPBGP & OSPF when we are using sham-link just we need to configure ospf with vrf & shamlink . Becasue sham-link treat itself as a point to point link with unnumbered interface.



4.2.7.4.  Routing and Forwarding on Sham Links

   If a PE determines that the next hop interface for a particular route
   is a sham link, then the PE SHOULD NOT redistribute that route into
   BGP as a VPN-IPv4 route.

   Any other route advertised in an LSA that is transmitted over a sham
   link MUST also be redistributed (by the PE flooding the LSA over the
   sham link) into BGP.  This means that if the preferred (OSPF) route
   for a given address prefix has the sham link as its next hop
   interface, then there will also be a "corresponding BGP route", for
   that same address prefix, installed in the VRF.

My Question :

Can some one clear me that i configured sham-link then do we require redistibution on OSPF to MPBGP for route propogation ?

And

If redistrubution is not requried then what is the meaning of below statement.

   Any other route advertised in an LSA that is transmitted over a sham
   link MUST also be redistributed (by the PE flooding the LSA over the
   sham link) into BGP
1 Accepted Solution

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

Hello Chetan,

Even with OSPF Sham Link configured, you must perform the redistribution between OSPF and BGP in the respective VRF because the OSPF will not carry MPLS label assignments to individual networks in the VRF - only BGP can do that. Without the redistribution, your routing tables may appear complete, populated by the PE routers running the OSPF sham link (basically a targeted OSPF session) in the particular VRF, but the remote networks actually can not be reached because the label mappings are not known. If you tried to send a packet to a remote network, only a single label would be imposed on it (the PE label) but the VPN label would be missing. On the final PE, the packet would arrive unlabeled thanks to PHP and hence processed according to the global routing table, not according to the VRF in which the real destination resides.

I assume that the statements in the RFC shall be understood as follows:

   If a PE determines that the next hop interface for a particular route
   is a sham link, then the PE SHOULD NOT redistribute that route into
   BGP as a VPN-IPv4 route.

This is written from the viewpoint of a router learning about a remote network via OSPF sham link and possibly via MP-BGP. The learned network is located at a remote site and that there is a sham link configured between the local PE and the remote PE. It is thus expected that the remote PE is performing the redistribution from OSPF to BGP so that the MPLS labels to remote networks are known, as explained earlier. Therefore, when also performing OSPF to BGP redistribution on the local PE, a network reachable through a sham link should not be re-injected into BGP because it is already being redistributed into BGP at the remote PE.

   Any other route advertised in an LSA that is transmitted over a sham
   link MUST also be redistributed (by the PE flooding the LSA over the
   sham link) into BGP.

This is written from the viewpoint of a PE router advertising a network (in form of an LSA) to its sham link neighbor. If OSPF to BGP redistribution is configured on this router, this route should be also redistributed into BGP so that the neigbhor router at the other end of the sham link knows about this network (via OSPF) and knows about my label mapping for it (via BGP).

   This means that if the preferred (OSPF) route
   for a given address prefix has the sham link as its next hop
   interface, then there will also be a "corresponding BGP route", for
   that same address prefix, installed in the VRF.

This is again written from a perspective of a PE router that learned about a remote network via the sham link and together via BGP, thanks to OSPF-to-BGP redistribution performed at the remote PE.

Does this make it more clear? Please feel welcome to ask further!

Best regards,

Peter

View solution in original post

9 Replies 9

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Chetan,

to avoid recursive routing over the sham-link as it would happen on a p2p GRE you need to avoid to advertise the sham-link endpoints in OSPF

sham-link endpoints have to be advertised in bgp address-family ipv4 vrf by another mean

for example a network

command

I did tests on this some years ago

all other routes can be advertised on both OSPF and MP BGP safely

Hope to help

Giuseppe

Peter Paluch
Cisco Employee
Cisco Employee

Hello Chetan,

Even with OSPF Sham Link configured, you must perform the redistribution between OSPF and BGP in the respective VRF because the OSPF will not carry MPLS label assignments to individual networks in the VRF - only BGP can do that. Without the redistribution, your routing tables may appear complete, populated by the PE routers running the OSPF sham link (basically a targeted OSPF session) in the particular VRF, but the remote networks actually can not be reached because the label mappings are not known. If you tried to send a packet to a remote network, only a single label would be imposed on it (the PE label) but the VPN label would be missing. On the final PE, the packet would arrive unlabeled thanks to PHP and hence processed according to the global routing table, not according to the VRF in which the real destination resides.

I assume that the statements in the RFC shall be understood as follows:

   If a PE determines that the next hop interface for a particular route
   is a sham link, then the PE SHOULD NOT redistribute that route into
   BGP as a VPN-IPv4 route.

This is written from the viewpoint of a router learning about a remote network via OSPF sham link and possibly via MP-BGP. The learned network is located at a remote site and that there is a sham link configured between the local PE and the remote PE. It is thus expected that the remote PE is performing the redistribution from OSPF to BGP so that the MPLS labels to remote networks are known, as explained earlier. Therefore, when also performing OSPF to BGP redistribution on the local PE, a network reachable through a sham link should not be re-injected into BGP because it is already being redistributed into BGP at the remote PE.

   Any other route advertised in an LSA that is transmitted over a sham
   link MUST also be redistributed (by the PE flooding the LSA over the
   sham link) into BGP.

This is written from the viewpoint of a PE router advertising a network (in form of an LSA) to its sham link neighbor. If OSPF to BGP redistribution is configured on this router, this route should be also redistributed into BGP so that the neigbhor router at the other end of the sham link knows about this network (via OSPF) and knows about my label mapping for it (via BGP).

   This means that if the preferred (OSPF) route
   for a given address prefix has the sham link as its next hop
   interface, then there will also be a "corresponding BGP route", for
   that same address prefix, installed in the VRF.

This is again written from a perspective of a PE router that learned about a remote network via the sham link and together via BGP, thanks to OSPF-to-BGP redistribution performed at the remote PE.

Does this make it more clear? Please feel welcome to ask further!

Best regards,

Peter

Hi Peter,

Thanks for your explanation.

I forgot the basic of MP BGP here , I forgot that  packet will forward based on MPLS & VPN Lables & If lable are not there then packet will get droped or will lookup tp global routing table.

Here sham-link will form adj & exchange LSA but the route learn form sham-link will have next-hop of MP-BGP & It will foward packet as it do for all mean with LABLE.

We can see the routes in routing table but becasue of no lable the PE router will not process.

I check this one after going though your explanation .

Same for OSPF external route , If we won't redistribute ospf external router in BGP then also remote end will able to see the OSPF E2 route but won't able to communicate , becasue ther is not lable for OSPF external routes.

Thanks for the great explanation & now sure i will never forgot the basic packet forwarding in MPLS VPN. THE LABELS.

Hi Guys,

Can the sham-link concept be considered as a classic case of OSPF running over BGP??? I beg to think about the scenario in that manner.(Usually its the other way around right? BGP over OSPF?).

Hi Arun,

I would rather call the OSPF sham-link a special type of virtual link established over a targeted OSPF session, with additional rules governing the OSPF/BGP redistribution and allowing you to set the cost of the virtual link manually. Instead of referring to the other router's RID, you refer to the other's PE IP address within the particular VRF.

Technically, the OSPF does not run in BGP, nor vice versa. It's just that the PE routers have two adjacencies - one over MP-BGP (carrying all VRFs), and the second being a targeted OSPF session limited just to a particular VRF.

Does this help a bit? Please feel welcome to ask further.

Best regards,

Peter

Of course Peter. It does help a lot.

The reason I asked the question was because, usually, we advertise the loopbacks used to form BGP peering into OSPF, and thats how the MP-BGP works(thats where I felt like saying that BGP works on top of IGP-OSPF). But here, I find that BGP is doing the honours in bringing up the sham-link, since the vrf loopbacks are advertised over BGP. Hence.....

Thanks for the clarification. Please let me know if the above thought process is justified.

Hello Arun,

follow Peter's excellent explanation your notes are about configuration aspects that can be misleading sometimes but I see your point of view now

Hope to help

Giuseppe

Thanks Giuseppe.

You are back Peter and with a splendid explanation yet again.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: