cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
899
Views
15
Helpful
4
Replies

OSPF Sham link behavior

sivam siva
Level 3
Level 3

Hello all

 

Routes received over OSPF sham link are having unexpected next-hop.

As per my knowledge if router RA is receiving routes from RB, then RB's interface address will be the next-hop for those routes (exclude 3rd party next-hop concept which applicable for type 5 and 7 LSA).

 

let me explain the setup:

Int_As_Mpls.JPG

between R1---R6 => MPBGP VPNv4 session,

R1 to R6 MPLS label switching enabled,

shamil link between  R1's loopback 111.1.1.1 to R6's loopback 66.6.6.6.

21.21.21.21/32 is the customer_2 ip in site A,  site A connected to PE router R1.

22.22.22.22/32 is the customer_2 ip in site B, site B connected to PE router R6.

 

if you look at my below output, there is an inter-area route "O IA 21.21.21.21 [110/3] via 1.1.1.1, 00:08:21"

says 1.1.1.1 as next-hop but OSPF process 2 has no knowledge about 1.1.1.1

1.1.1.1  is actually included in the OSPF process 1.

InkedOSPF Sham-Link_LI.jpg

Sham-Link Config.JPG

R1 ospf sham link.JPG

 

whereas output in R1 is having expected next-hp (source of sham link session)

OSPF ShamLink R1.jpg

 

Please anyone help me to identify the reason.

 

also, I have another doubt,

I have done mutual redistribution between OSPF (customer instance)  and  BGP on both the PE routers, so PE router R6 receives the other end customer route (21.21.21.21/32) over sham link and installed in RIB of customer VRF, also the same prefix is learned via IBGP vpnv4 session from R1(because of the ospf to bgp redistribution in R1)

As per my knowledge if R6 is installed 21.21.21.21/32  as a OIA route then it should redistribute that route back to BGP (kind of feedback route process), but this is not happening in my lab test,

I can understand that its kind of loop prevention mechanism, please explain anyone exactly what prevents the router from redistributing that route back.

 

Thanks 

Siva

4 Replies 4

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Siva,

it looks like R1 is installing the route learned over MP BGP like if the sham-link would be not in place.

It can be a race condition where the quickest method has won.

That LSA type 3 should have the DN down bit set and this is the loop prevention mechanism used by PE nodes with OSPF as PE-CE protocol to avoid re-injection. Just to answer your final question.

the OSPF sham link should have the potential to create O routes.

I have noticed that you are using two different OSPF process ids on PE R1 and on PE R6. (OSPF pid 2 and pid 3 respectively)-

I would suggest you to try to use the same process id, because the OSPF domain id if not set is equal to the OSPF process id.

In the OSPF protocol emulation over the superbackbone area the OSPF domain id travels in MP BGP as an extended community attached to the VPNv4 prefix.

The sham link endpoints have to be advertised in MP BGP not in customer instance OSPF or the sham link would flap. And this is fine in your configuration.

I think that if you use the same OSPF process ids on both ends (both PE) you will be able to see O routes on both sides.

 

Hope to help

Giuseppe

 

Dear @Giuseppe Larosa 

 

Happy to speak with you again, I hope you are good and safe.

 

it looks like R1 is installing the route learned over MP BGP like if the sham-link would be not in place.

It can be a race condition where the quickest method has won

R1 is installing OSPF route, please note the OIA notation for the customer route(22.22.22.22/32)

I believe OSPF routes are installed because of the lowest AD (110 < 200)

 

That LSA type 3 should have the DN down bit set and this is the loop prevention mechanism used by PE nodes with OSPF as PE-CE protocol to avoid re-injection. Just to answer your final question.

as per my understanding and lab test, PE router is setting DN bit only while redistributing the routes from BGP to OSPF customer vrf, see my below output routes learned via sham link doesn't have DN bit set.

(my question is why this route is not redistributed back to BGP on the same router).

ospf upward.JPG

 

I have noticed that you are using two different OSPF process ids on PE R1 and on PE R6. (OSPF pid 2 and pid 3 respectively)-

I would suggest you to try to use the same process id, because the OSPF domain id if not set is equal to the OSPF process id.

In the OSPF protocol emulation over the superbackbone area the OSPF domain id travels in MP BGP as an extended community attached to the VPNv4 prefix.
I think that if you use the same OSPF process ids on both ends (both PE) you will be able to see O routes on both sides.

 

I believe received ospf domain ID compared with local ospf domain ID only while redistributing routes from BGP to OSPF.

Here I have sham link configured as area 0, so routes received over it from another area( customer area) must be type 3. please see my below output, I have changed OSPF process ID same on both the sides, still, OIA remains the same for 22.22.22.22/32.

OSPF OIA.JPG

 

Thanks 

Siva

Hello Siva,

>> routes learned via sham link doesn't have DN bit set.

you are right on this.

 

I have also not understood your topology about the customer routes that are inter area in any case as you have showed in your last test.

 

I realize that I have supposed that the next-hop 1.1.1.1 could be explained with MP BGP route preferred over the route coming over the sham link. This looks like to be a too simple explanation of what you see.

If I correctly remember the sham-link is not used for user traffic but just to create an artificial OSPF topology so that for example is possible to deal with two VRF sites that have a backdoor direct link.

The reason is that would be not efficient to send user traffic over a IP tunnel over an MPLS L3 VPN for increased use of cpu and for increased overhead.

The sham-link should exist only on the control plane to allow the LSA flooding over it.

If this is true both routers should use as next-hops the MP BGP loopback addresses but one side is using the sham link endpoint address.

 

Thanks for your kind remarks

 

Hope to help

Giuseppe

 

Hi @Giuseppe Larosa 

 

The sham-link should exist only on the control plane to allow the LSA flooding over it.

I agree with the application of OSPF Sham link.

Not sure what happened, I have done nothing just restarted my gns3 topology, now I'm getting the same behavior on both sides.

Ospf sham-link111.JPG

 But still, my second doubt about "feedback route" is not cleared.

 

Thanks 

Siva

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: