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?
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,
a working sample config would look like this:
ip vrf A
route-target export 65000:99
route-target import 65000:99
ip address 192.168.1.1 255.255.255.255
description for OSPF sham link - do only advertise by BGP
ip vrf forwarding A
ip address 172.16.99.1 255.255.255.255
description to CE
ip vrf forwarding A
ip address 10.1.1.1 255.255.255.252
router ospf 99 vrf A
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
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
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.
Great it works now. Thanks.
One clarification. When I do "show ip bgp vpn4 all
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?
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.
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 220.127.116.11 for the specification of when this value must be used.
---- snip -----
And the statement refered to is in section 18.104.22.168:
"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.
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?
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.
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.
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.