OSPF Sham-Link

[dknov]

Hi,

I tried to follow all Cisco configs to activate sham-link, but it stays down.

I tried the following:

1. Assign two Loopback interfaces on two PE routers to a VRF on which I need sham-link. This is per Cisco's intructions that sham-link end points needs to be in VRF

2. Did not include this Loopback interfaces in OSPF process running on PEs. This is per Cisco's recommendations of not advertising the sham-link end point via OSPF to prevent doubled advertisements.

3. Entered "area 0 sham-link x.x.x.x y.y.y.y" commands in OSPF processes in both PEs.

4. Configured MP-BGP IPv4 address-family to redistribute OSPF prefixes.

After completing those 4 steps I expected for MP-BGP to advertise (automatically?) sham-link end points between the two PEs as Route Type 129 and a sham-link itself to come up. However none of the above happens. I do not see sham-link end point in either of the PEs and naturally sham-link also shows to be down.

What am I missing?

Thanks,

David

[olorunloba]

Can you give us your config?

[pkhatri]

Could you verify that the loopback you configure in PE1 is visible in the VRF in PE2 and vice versa ?

Thanks,

Paresh

[Harold Ritter]

David,

Make sure that the loopback interface IP address created in step 1 is advertised from one PE to another via VPNv4. This could be done by configuring "network x.x.x.x mask x.x.x.x" statement under address-family ipv4 vrf xxx for the VRF in question.

Hope this helps,

[mheusinger]

Hello,

a working sample config would look like this:

ip vrf A

rd 65000:99

route-target export 65000:99

route-target import 65000:99

interface Loopback0

ip address 192.168.1.1 255.255.255.255

interface Loopback99

description for OSPF sham link - do only advertise by BGP

ip vrf forwarding A

ip address 172.16.99.1 255.255.255.255

interface Serial0/0

description to CE

ip vrf forwarding A

ip address 10.1.1.1 255.255.255.252

router ospf 99 vrf A

domain-id 99.99.99.99

redistribute bgp 65000 subnets

network 10.1.1.1 0.0.0.0 area 99

area 99 sham-link 172.16.99.1 172.16.99.2 cost 5

router bgp 65000

no bgp default ipv4-unicast

neighbor 192.168.1.2 remote-as 65000

neighbor 192.168.1.2 update-source Loopback0

address-family vpnv4

neighbor 192.168.1.2 activate

neighbor 192.168.1.2 next-hop-self

neighbor 192.168.1.2 send-community extended

address-family ipv4 vrf A

redistribute ospf 99 vrf A match internal external 1 external 2

network 172.16.99.1 mask 255.255.255.255

no synchronization

no auto-summary

exit-address-family

I skipped the MPLS/LDP part which is needed. As you can see, Loop99 is only advertised by bgp (check that it is advertised with "show bgp vpnv4 unicast vrf A 172.16.99.1" on both PE)

Hope this helps! Please rate all posts.

Regards, Martin

[dknov]

Hi Martin,

Great it works now. Thanks.

One clarification. When I do "show ip bgp vpn4 all " where x.x.x.x is a Sham-link end point on the other router, I do not see any OSPF extended communities, only standard route-target one.

According to Cisco docs sham-link endpoint are supposed to be advertised as route-type 129. Why don't I see this on bgp output?

Thanks,

David

[pkhatri]

Hi David,

Would you be able to post the output of "show ip bgp vpn4 all " that you are getting ?

Regards,

Paresh

[Harold Ritter]

It is normal behavior for the sham link endpoint not to have ospf extended communities attached to it as this prefix is not an ospf route redistributed into bgp but strictly learnt via BGP..

Only ospf routes redistributed into BGP will be tagged with the ospf extended communities.

Could you point me to the document that states the sham link end point should be tagged with ospf extended communities.

Thanks,

[mheusinger]

Hello all,

in "draft-rosen-vpns-ospf-bgp-mpls" (http://quimby.gnus.org/internet-drafts/draft-rosen-vpns-ospf-bgp-mpls-04.txt) it stated in section

4.2.2. Handling LSAs from the CE

---- snip -----

* OSPF Route Type: 1 byte, encoded as follows:

---- snip -----

** 129 for Sham Link Endpoint Addresses. See section 4.2.3.2 for the specification of when this value must be used.

---- snip -----

And the statement refered to is in section 4.2.3.2:

"IF a VRF is configured for auto-configuration of sham links, it MUST distribute, via BGP, a VPN-IP route corresponding to the Sham Link Endpoint Address. This route MUST have the OSPF Route Type Extended Community attribute, with the OSPF Route Type field set to "Sham Link Endpoint Address"."

So it does not state anything regarding BGP attributes in the case of manual OSPF sham-link configuration. In my opinion the implementation of NOT using OSPF route type 129 in BGP for the case of manual configuration is reasonable, because both PE will know the sham-link end points from configuration. An additional information would be inefficient.

NB: This draft was never published as an RFC.

Hope this helps! Pllease rate all posts.

Regards, Martin

[sergio.danelli]

Martin,

Sorry to ask on this old thread, but is this "redistribute ospf 99 vrf A match internal external 1 external 2" necessary even though the OSPF_SL0 link is up? if so, why?

thanks

[sergio.danelli]

Ok nm, I guess is the only way to pass a label. It is a bit confusing since the full database ospf shows up on the opposite side when the sham-link comes up, but nothing works since no tags are imposed.

[mheusing]

Hi Sergio,

You spotted the reason to redistribute OSPF, as MP-BGP will be needed to transport VPN labels. You are right, that from an OSPF, i.e. routing perspective things look fine - yet the data plane is broken, if no labels are distributed.

Regards, Martin

[Pavel Bykov]

An interesting note to this, is that you cannot tag redistributed routes into OSPF.

Otherwise the following problem will arise: OSPF-RIB-LOCAL: Can't add route 172.16.99.1/255.255.255.255 to area dummy area type 16 route list

Filtering redistribution with route maps does not help... OSPF still needs that route.