cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1279
Views
15
Helpful
12
Replies

OSPF Sham-Link

dknov
Level 3
Level 3

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

12 Replies 12

olorunloba
Level 5
Level 5

Can you give us your config?

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

Thanks,

Paresh

Harold Ritter
Cisco Employee
Cisco Employee

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,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

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

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

Hi David,

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

Regards,

Paresh

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,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

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

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

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.

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

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.

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: