mpls: ospf sham link – why? and howto!

Hello everybody.
Today I decided to write a post about OSPF SHAM LINK which is used in MPLS networks.
Before giving a short explanation for what the sham link is used I will show you the topology as its a little bit easier to understand then.

Topology:

Given:
– a small MPLS backbone with SPCORE as P-Router (MPLS only, no BGP), SPEDGE routers as PE-Routers with MP-BGP enabled
– fa0/1 of the SPEDGE routers are in vrf “CUSTOMER”
– OSPF as PE-CE routing protocol between SITE and SPEDGE routers
– on SPEDGE routers the OSPF process ID is “2” for the “CUSTOMER” vrf and OSPF process ID is “1” for the MPLS Backbone connectivity
– a backup link between the SITE routers which is also in AREA 0 for the case if the ISP breaks down
– some loopback interfaces which simulate networks connected to the SITE routers

Motivation:
Well what is OSPF SHAM LINK and whats it good for. I will only briefly explain it here because during the configuration you will get some details in how to configure it. An OSPF sham link addresses the problem that you will encounter in such a scenario. For example lets take SITE1. Lets assume the backup link does not exist then whats happening? Well SITE1 shall recieve the networks from SITE2 via the ISP network. The process here is the following

1) SITE2 injects the networks into OSPF
2) SPEDGE2 get those networks from SITE2 via OSPF
3) SPEDGE2 redistributes the networks from OSPF into MP-BGP and the corresponding VRF
4) The networks are transported via BGP to SPEDGE1 and SPEDGE1 sees those networks in the BGP table
5) SPEDGE1 redistributes the networks into the OSPF process for SITE1
6) SPEDGE1 sends the networks to SITE1 via OSPF
7) SITE1 gets the networks via OSPF and installs the routes in its routing table

…BUT!!!…

Point 7 is only the half of the truth. SITE1 installs the networks in its routing table but what type of OSPF routes are we dealing with? Well as the routes are redistributed from a different protocol (BGP) into OSPF they should usually be E1 or E2 routes. But they are not, as BGP is capable of carrying OSPF information. SITE1 has an OSPF adjacency with SPEDGE1 and not directly with SITE2 (except if we fire up the backup link, but more on that later) which means that it SITE1 sees the routes from a router from the same AREA but its not directly connected. This has the effect that the routes are received by SITE1 as “IA” (INTER AREA) routes. So and here comes the problem.
Usually you would think “Hey okay…I sent my traffic through the ISP and if the ISP fails, then the traffic is sent via the BACKUP LINK”. Good idea, how does one realize that usually? Right! With OSPF cost. So if you raise the OSPF on the backup link to “10000” and the cost for the link to the ISP is lets say “10” then everybody would say “Of course the traffic is going through the ISP!”. But ITS NOT :).
But why? Well OSPF prefers INTRA-AREA-routes (normal “O” routes) over INTER-AREA-routes (“IA” routes), no matter what cost you configure.
The solution to that is the OSPF sham link. Later on in the text I will provide more details.

Challenges:
– configure OSPF end to end connectivity between SITE1 and SITE2 via the ISP
– leave the backup link shutdown in the first place
– when succeeded then open up the BACKUP LINK and take a look at the problem
– configure an OSPF sham link to conquer the problem
– the need for mutual redsitribution of BGP/OSPF?

So here we go. we assume that our ISP routers are configured properly, i.e. OSPF is activated, MP-BGP is running and the VRF is configured including the proper ip addresses. Here is the relevant config for the backbone.

SPCORE (only MPLS enabled routes w/o BGP):

hostname SPCORE
!
ip cef
!
interface Loopback0
 ip address 10.10.10.1 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/0
 ip address 172.16.10.1 255.255.255.252
 ip ospf 1 area 0
 duplex auto
 speed auto
 mpls ip
!
interface FastEthernet0/1
 ip address 172.16.20.1 255.255.255.252
 ip ospf 1 area 0
 duplex auto
 speed auto
 mpls ip
!
!
!
router ospf 1
 router-id 10.10.10.1
 log-adjacency-changes
!
!
!
mpls ldp router-id Loopback0 force

SPEDGE1 (edge router with MBGP and VRF enabled):

hostname SPEDGE1
!
ip cef
!
!
ip vrf CUSTOMER
 rd 1:1
 route-target export 1:1
 route-target import 1:1
!
!
!
interface Loopback0
 ip address 10.10.10.2 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/0
 ip address 172.16.10.2 255.255.255.252
 ip ospf 1 area 0
 duplex auto
 speed auto
 mpls ip
!
interface FastEthernet0/1
 ip vrf forwarding CUSTOMER
 ip address 10.10.11.1 255.255.255.252
 ip ospf 2 area 0
 duplex auto
 speed auto
!
!
!
router ospf 2 vrf CUSTOMER
 router-id 10.10.11.1
 log-adjacency-changes
 redistribute bgp 1 metric 200 subnets
!
router ospf 1
 router-id 10.10.10.2
 log-adjacency-changes
!         
router bgp 1
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.10.10.3 remote-as 1
 neighbor 10.10.10.3 update-source Loopback0
 neighbor 10.10.10.3 next-hop-self
 neighbor 10.10.10.3 send-community both
 no auto-summary
 !
 address-family vpnv4
  neighbor 10.10.10.3 activate
  neighbor 10.10.10.3 send-community both
  neighbor 10.10.10.3 next-hop-self
 exit-address-family
 !
 address-family ipv4 vrf CUSTOMER
  redistribute ospf 2 vrf CUSTOMER metric 200 match internal external
  no synchronization
 exit-address-family
!
!
!
mpls ldp router-id Loopback0 force

SPEDGE2 (edge router with MBGP and VRF enabled):

hostname SPEDGE2
!
ip cef
!
!
!
ip vrf CUSTOMER
 rd 1:1
 route-target export 1:1
 route-target import 1:1
!
!
!
interface Loopback0
 ip address 10.10.10.3 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/0
 ip address 172.16.20.2 255.255.255.252
 ip ospf 1 area 0
 duplex auto
 speed auto
 mpls ip
!
interface FastEthernet0/1
 ip vrf forwarding CUSTOMER
 ip address 10.10.22.1 255.255.255.252
 ip ospf 2 area 0
 duplex auto
 speed auto
!
!
!
router ospf 2 vrf CUSTOMER
 router-id 10.10.22.1
 log-adjacency-changes
 redistribute bgp 1 metric 200 subnets
!
router ospf 1
 router-id 10.10.10.3
 log-adjacency-changes
!         
router bgp 1
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.10.10.2 remote-as 1
 neighbor 10.10.10.2 update-source Loopback0
 neighbor 10.10.10.2 next-hop-self
 neighbor 10.10.10.2 send-community extended
 no auto-summary
 !
 address-family vpnv4
  neighbor 10.10.10.2 activate
  neighbor 10.10.10.2 send-community both
  neighbor 10.10.10.2 next-hop-self
 exit-address-family
 !
 address-family ipv4 vrf CUSTOMER
  redistribute ospf 2 vrf CUSTOMER metric 200 match internal external
  no synchronization
 exit-address-family
!
!
!
mpls ldp router-id Loopback0 force

Ok then lets now configure the OSPF adjacency between SITE1 and SPEDGE1 and SITE2 and SPEDGE2, that should be an easy one.

SITE1(config)#int fa0/0
SITE1(config-if)#no shut
SITE1(config-if)#ip address 10.10.11.2 255.255.255.252
SITE1(config-if)#ip ospf 1 are 0
SITE1(config-if)#int fa0/1                            
SITE1(config-if)#ip address 192.168.11.1 255.255.255.252  
SITE1(config-if)#shut                                
SITE1(config-if)#ip ospf 1 are 0
SITE1(config-if)#router ospf 1
SITE1(config-router)#redistribute connected subnets 
!
SITE2(config)#int fa0/0
SITE2(config-if)#no shut
SITE2(config-if)#ip address 10.10.22.2 255.255.255.252
SITE2(config-if)#ip ospf 1 are 0
SITE2(config-if)#int fa0/1
SITE2(config-if)#shut
SITE2(config-if)#ip address 192.168.11.2 255.255.255.252
SITE2(config-if)#ip ospf 1 are 0  
SITE2(config-if)#router ospf 1
SITE2(config-router)#redistribute connected subnets                  

so far so good. Lets wait some seconds to get BGP converged and then we will take a look at the routing table of both machines.

SITE1#sh ip route ospf 
     2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/210] via 10.10.11.1, 00:07:12, FastEthernet0/0
     22.0.0.0/32 is subnetted, 3 subnets
O IA    22.22.22.22 [110/210] via 10.10.11.1, 00:07:22, FastEthernet0/0
O IA    22.22.22.23 [110/210] via 10.10.11.1, 00:07:50, FastEthernet0/0
O IA    22.22.22.21 [110/210] via 10.10.11.1, 00:07:12, FastEthernet0/0
     10.0.0.0/30 is subnetted, 2 subnets
O IA    10.10.22.0 [110/210] via 10.10.11.1, 00:07:50, FastEthernet0/0
!
SITE2#sh ip route ospf
     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/210] via 10.10.22.1, 00:07:07, FastEthernet0/0
     10.0.0.0/30 is subnetted, 2 subnets
O IA    10.10.11.0 [110/210] via 10.10.22.1, 00:09:56, FastEthernet0/0
     11.0.0.0/32 is subnetted, 3 subnets
O IA    11.11.11.11 [110/210] via 10.10.22.1, 00:06:57, FastEthernet0/0
O IA    11.11.11.13 [110/210] via 10.10.22.1, 00:06:57, FastEthernet0/0
O IA    11.11.11.12 [110/210] via 10.10.22.1, 00:06:47, FastEthernet0/0

As we can see the routes coming in from the SPEDGE routers are marked with an “IA” which means those ones are INTER-AREA routes. Recognize that the OSPF cost is “210”. We will get into that very soon.
Lets now fire up the backup link and see what happens after convergence.

SITE1(config)#int fa0/1
SITE1(config-if)#no shut
!
SITE2(config)#int fa0/1
SITE2(config-if)#no shut

SITE1#sh ip route ospf 
     2.0.0.0/32 is subnetted, 1 subnets
O       2.2.2.2 [110/11] via 192.168.11.2, 00:00:03, FastEthernet0/1
     22.0.0.0/32 is subnetted, 3 subnets
O       22.22.22.22 [110/11] via 192.168.11.2, 00:00:03, FastEthernet0/1
O       22.22.22.23 [110/11] via 192.168.11.2, 00:00:03, FastEthernet0/1
O       22.22.22.21 [110/11] via 192.168.11.2, 00:00:03, FastEthernet0/1
     10.0.0.0/30 is subnetted, 2 subnets
O       10.10.22.0 [110/20] via 192.168.11.2, 00:00:03, FastEthernet0/1
!
SITE2#sh ip route ospf
     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/11] via 192.168.11.1, 00:00:32, FastEthernet0/1
     10.0.0.0/30 is subnetted, 2 subnets
O       10.10.11.0 [110/20] via 192.168.11.1, 00:00:32, FastEthernet0/1
     11.0.0.0/32 is subnetted, 3 subnets
O       11.11.11.11 [110/11] via 192.168.11.1, 00:00:32, FastEthernet0/1
O       11.11.11.13 [110/11] via 192.168.11.1, 00:00:32, FastEthernet0/1
O       11.11.11.12 [110/11] via 192.168.11.1, 00:00:32, FastEthernet0/1

Ok its working as expected. The routes coming in have a cost of “11” which is clearly better than “210”. So lets do the next step and make the cost of the backup link worse, so that it only will be used for routing when the primary link to the ISP torns down. Of course we have to do this on both sides, so that we dont run into asymmetric routing issues.

SITE1(config)#int fa0/1
SITE1(config-if)#ip ospf cost 10000
!
SITE2(config)#int fa0/1
SITE2(config-if)#ip ospf cost 10000

Lets now have a look at the routing tables.

SITE1#sh ip route ospf 
     2.0.0.0/32 is subnetted, 1 subnets
O       2.2.2.2 [110/10001] via 192.168.11.2, 00:00:54, FastEthernet0/1
     22.0.0.0/32 is subnetted, 3 subnets
O       22.22.22.22 [110/10001] via 192.168.11.2, 00:00:54, FastEthernet0/1
O       22.22.22.23 [110/10001] via 192.168.11.2, 00:00:54, FastEthernet0/1
O       22.22.22.21 [110/10001] via 192.168.11.2, 00:00:54, FastEthernet0/1
     10.0.0.0/30 is subnetted, 2 subnets
O       10.10.22.0 [110/10010] via 192.168.11.2, 00:00:54, FastEthernet0/1
!
SITE2#sh ip route ospf 
     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/10001] via 192.168.11.1, 00:00:38, FastEthernet0/1
     10.0.0.0/30 is subnetted, 2 subnets
O       10.10.11.0 [110/10010] via 192.168.11.1, 00:00:38, FastEthernet0/1
     11.0.0.0/32 is subnetted, 3 subnets
O       11.11.11.11 [110/10001] via 192.168.11.1, 00:00:38, FastEthernet0/1
O       11.11.11.13 [110/10001] via 192.168.11.1, 00:00:38, FastEthernet0/1
O       11.11.11.12 [110/10001] via 192.168.11.1, 00:00:38, FastEthernet0/1

Ahm…well okay thats not what we like to see. The cost has been accepted but, why isnt the traffic going through the ISP backbone? Well as I already mentioned, no matter what cost is configured, INTRA-AREA (“O”) routes are always preferred over INTER-AREA (“IA”) routes. Thats the problem we have.
Lets solve this with a sham link :).

A sham link is configured on the PE routers in our scenario and acts like a (pseudo) INTRA-AREA connection between the two OSPF processes of SPEDGE1 and SPEDGE2. This means that we will simulate an OSPF adjacency and let it look like there is no BGP in the Backbone. But only let it look like :).

Prerequisites for a sham link are the following:
– seperate Loopback interface for each SPEDGE router which is used for the sham link peering
– this loopback needs to be reachable for SPEDGE1 and SPEDGE2, so we have to put them into BGP
– the loopback has to participate in the same VRF in which the OSPF processes do

So lets get it on with the configuration of the loopbacks:

SPEDGE1(config)#int lo666
*Mar  1 00:56:35.015: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback666, changed state to up
SPEDGE1(config-if)#description SHAM-LINK-LOOPBACK
SPEDGE1(config-if)#ip vrf forwarding CUSTOMER
SPEDGE1(config-if)#ip address 99.99.99.1 255.255.255.255
!
SPEDGE2(config)#int lo666
*Mar  1 00:57:34.013: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback666, changed state to up
SPEDGE2(config-if)#description SHAM-LINK-LOOPBACK
SPEDGE2(config-if)#ip vrf forwarding CUSTOMER
SPEDGE2(config-if)#ip address 99.99.99.2 255.255.255.255

Then we need to put them into the BGP process to make them reach each other!

SPEDGE1(config)#router bgp 1
SPEDGE1(config-router)#address-family ipv4 unicast vrf CUSTOMER
SPEDGE1(config-router-af)#network 99.99.99.1 mask 255.255.255.255
!
SPEDGE2(config)#router bgp 1
SPEDGE2(config-router)#address-family ipv4 unicast vrf CUSTOMER
SPEDGE2(config-router-af)#network 99.99.99.2 mask 255.255.255.255

Test the reachability!

SPEDGE1#ping vrf CUSTOMER 99.99.99.2 so lo666
!
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 99.99.99.2, timeout is 2 seconds:
Packet sent with a source address of 99.99.99.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/107/140 ms
SPEDGE1#

Ok perfect. Looks good. Then we need to configure the sham link under the corresponding OSPF process, which is “2” in our case.

SPEDGE1(config)#router ospf 2 vrf CUSTOMER
SPEDGE1(config-router)#area 0 sham-link 99.99.99.1 99.99.99.2
!
SPEDGE2(config)#router ospf 2 vrf CUSTOMER
SPEDGE2(config-router)#area 0 sham-link 99.99.99.2 99.99.99.1

As soon as we hit the enter button on the second router we get a log message.

*Mar  1 00:58:53.163: %OSPF-5-ADJCHG: Process 2, Nbr 10.10.11.1 on OSPF_SL0 from LOADING to FULL, Loading Done

Looks like we have an adjacency over the BGP network which we can let look like a directly connected OSPF session. So lets now have a look on the routing table of SITE1 and SITE2. If everything is good then the sham link should take care of transporting the routes as INTRA-AREA routes, rather than INTER-AREA routes over BGP like it was before.

SITE1#sh ip route ospf
     2.0.0.0/32 is subnetted, 1 subnets
O       2.2.2.2 [110/22] via 10.10.11.1, 00:01:41, FastEthernet0/0
     99.0.0.0/32 is subnetted, 2 subnets
O E2    99.99.99.2 [110/200] via 10.10.11.1, 00:04:08, FastEthernet0/0
O E2    99.99.99.1 [110/200] via 10.10.11.1, 00:04:56, FastEthernet0/0
     22.0.0.0/32 is subnetted, 3 subnets
O       22.22.22.22 [110/22] via 10.10.11.1, 00:01:41, FastEthernet0/0
O       22.22.22.23 [110/22] via 10.10.11.1, 00:01:41, FastEthernet0/0
O       22.22.22.21 [110/22] via 10.10.11.1, 00:01:41, FastEthernet0/0
     10.0.0.0/30 is subnetted, 2 subnets
O       10.10.22.0 [110/21] via 10.10.11.1, 00:01:41, FastEthernet0/0
!
SITE2#sh ip route ospf
     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/22] via 10.10.22.1, 00:01:46, FastEthernet0/0
     99.0.0.0/32 is subnetted, 2 subnets
O E2    99.99.99.2 [110/200] via 10.10.22.1, 00:04:22, FastEthernet0/0
O E2    99.99.99.1 [110/200] via 10.10.22.1, 00:04:51, FastEthernet0/0
     10.0.0.0/30 is subnetted, 2 subnets
O       10.10.11.0 [110/21] via 10.10.22.1, 00:01:46, FastEthernet0/0
     11.0.0.0/32 is subnetted, 3 subnets
O       11.11.11.11 [110/22] via 10.10.22.1, 00:01:46, FastEthernet0/0
O       11.11.11.13 [110/22] via 10.10.22.1, 00:01:46, FastEthernet0/0
O       11.11.11.12 [110/22] via 10.10.22.1, 00:01:46, FastEthernet0/0

There we go. Everything looks good now.

NOTE:
Keep in mind that the “metric” value which we have configured in the redistribution arguments for redsitributing OSPF into BGP is 200! This value is no longer used (except for the ones that are injected via the network statement and sourced from the BGP routers). What we could do to manipulate the OSPF cost is to set the OSPF cost for the link itself (on the SITE1 and SITE2 routers)

Last test. We shutdown the link from SITE1 to SPEDGE1 and lets see whats happening:

SPEDGE1(config)#int fa0/1
SPEDGE1(config-if)#shut
*Mar  1 01:08:30.575: %OSPF-5-ADJCHG: Process 2, Nbr 11.11.11.13 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Interface down or detached

SITE1#sh ip route ospf 
     2.0.0.0/32 is subnetted, 1 subnets
O       2.2.2.2 [110/10001] via 192.168.11.2, 00:00:26, FastEthernet0/1
     99.0.0.0/32 is subnetted, 2 subnets
O E2    99.99.99.2 [110/200] via 192.168.11.2, 00:00:26, FastEthernet0/1
O E2    99.99.99.1 [110/200] via 192.168.11.2, 00:00:26, FastEthernet0/1
     22.0.0.0/32 is subnetted, 3 subnets
O       22.22.22.22 [110/10001] via 192.168.11.2, 00:00:26, FastEthernet0/1
O       22.22.22.23 [110/10001] via 192.168.11.2, 00:00:26, FastEthernet0/1
O       22.22.22.21 [110/10001] via 192.168.11.2, 00:00:26, FastEthernet0/1
     10.0.0.0/30 is subnetted, 2 subnets
O       10.10.22.0 [110/10010] via 192.168.11.2, 00:00:26, FastEthernet0/1
!
SITE2#sh ip route ospf
     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/10001] via 192.168.11.1, 00:00:42, FastEthernet0/1
     99.0.0.0/32 is subnetted, 2 subnets
O E2    99.99.99.2 [110/200] via 10.10.22.1, 00:08:50, FastEthernet0/0
O E2    99.99.99.1 [110/200] via 10.10.22.1, 00:09:19, FastEthernet0/0
     10.0.0.0/30 is subnetted, 2 subnets
O       10.10.11.0 [110/10010] via 192.168.11.1, 00:00:42, FastEthernet0/1
     11.0.0.0/32 is subnetted, 3 subnets
O       11.11.11.11 [110/10001] via 192.168.11.1, 00:00:42, FastEthernet0/1
O       11.11.11.13 [110/10001] via 192.168.11.1, 00:00:42, FastEthernet0/1
O       11.11.11.12 [110/10001] via 192.168.11.1, 00:00:42, FastEthernet0/1

Looks good. We can now manipulate the way the traffic should go usually and in the case of a backup scenario.
We fire the link up again to get our standard scenario back.

Well another question now is: When we have a sham link…do we need redistribution from OSPF into BGP and backwards (mutual redistribution)? Because usually we would not need it as there is connectivity between the two SPEDGE routers via the OSPF sham link session. Lets test it. First we deconfigure both redistribution and only let the connectivity between the two sham link addresses valid.

SPEDGE1(config)#router bgp 1
SPEDGE1(config-router)# address-family ipv4 vrf CUSTOMER
SPEDGE1(config-router-af)#no  redistribute ospf 2 vrf CUSTOMER metric 200 match internal external 1 external 2
SPEDGE1(config-router)#router ospf 2 vrf CUSTOMER   
SPEDGE1(config-router)#no redistribute bgp 1 metric 200 subnets
!
SPEDGE2(config)#router bgp 1
SPEDGE2(config-router)# address-family ipv4 vrf CUSTOMER
SPEDGE2(config-router-af)#no  redistribute ospf 2 vrf CUSTOMER metric 200 match internal external 1 external 2
SPEDGE2(config-router-af)#router ospf 2 vrf CUSTOMER
SPEDGE2(config-router)#no redistribute bgp 1 metric 200 subnets

So lets have a look at the sham link OSPF adjacency.

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.10.10.1        1   FULL/BDR        00:00:30    172.16.20.1     FastEthernet0/0
10.10.11.1        0   FULL/  -           -        99.99.99.1      OSPF_SL0
2.2.2.2           1   FULL/BDR        00:00:37    10.10.22.2      FastEthernet0/1

Looks good. The sham link is still opened and running. Lets check the VRF routing table.

SPEDGE2#sh ip route vrf CUSTOMER ospf

Routing Table: CUSTOMER     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/12] via 10.10.10.2, 00:06:55
     2.0.0.0/32 is subnetted, 1 subnets
O       2.2.2.2 [110/11] via 10.10.22.2, 01:03:40, FastEthernet0/1
     192.168.11.0/30 is subnetted, 1 subnets
O       192.168.11.0 [110/10010] via 10.10.22.2, 00:50:14, FastEthernet0/1
     22.0.0.0/32 is subnetted, 3 subnets
O       22.22.22.22 [110/11] via 10.10.22.2, 01:03:50, FastEthernet0/1
O       22.22.22.23 [110/11] via 10.10.22.2, 01:16:07, FastEthernet0/1
O       22.22.22.21 [110/11] via 10.10.22.2, 01:03:40, FastEthernet0/1
     10.0.0.0/30 is subnetted, 2 subnets
O       10.10.11.0 [110/11] via 10.10.10.2, 00:06:55
     11.0.0.0/32 is subnetted, 3 subnets
O       11.11.11.11 [110/12] via 10.10.10.2, 00:06:55
O       11.11.11.13 [110/12] via 10.10.10.2, 00:06:55
O       11.11.11.12 [110/12] via 10.10.10.2, 00:06:55

Nice! All OSPF routes are still there. Lets check the routing tables of the SITE routers:

SITE1#sh ip route ospf 
     2.0.0.0/32 is subnetted, 1 subnets
O       2.2.2.2 [110/22] via 10.10.11.1, 00:07:33, FastEthernet0/0
     22.0.0.0/32 is subnetted, 3 subnets
O       22.22.22.22 [110/22] via 10.10.11.1, 00:07:33, FastEthernet0/0
O       22.22.22.23 [110/22] via 10.10.11.1, 00:07:33, FastEthernet0/0
O       22.22.22.21 [110/22] via 10.10.11.1, 00:07:33, FastEthernet0/0
     10.0.0.0/30 is subnetted, 2 subnets
O       10.10.22.0 [110/21] via 10.10.11.1, 00:07:33, FastEthernet0/0
!
SITE2#sh ip route ospf
     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/22] via 10.10.22.1, 00:07:39, FastEthernet0/0
     10.0.0.0/30 is subnetted, 2 subnets
O       10.10.11.0 [110/21] via 10.10.22.1, 00:07:39, FastEthernet0/0
     11.0.0.0/32 is subnetted, 3 subnets
O       11.11.11.11 [110/22] via 10.10.22.1, 00:07:39, FastEthernet0/0
O       11.11.11.13 [110/22] via 10.10.22.1, 00:07:39, FastEthernet0/0
O       11.11.11.12 [110/22] via 10.10.22.1, 00:07:39, FastEthernet0/0

Everything is still there. Which sounds good first. Lets test connectivity over the MPLS backbone and the sham link.

SITE1#ping 22.22.22.22 so lo1
!
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 22.22.22.22, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11 
.....
Success rate is 0 percent (0/5)

Hmm strange. Although everything seems to look good the connectivity is broken. Well this has a specific reason. The MP-BGP uses LDP to advertise labels to the MPLS backbone. Those labels contain one transport label and one VPN label. As the prefixes of the OSPF process “2” of the SPEDGE routers are not injected into the MP-BGP, there is no chance for those prefixes to get a VPN label.

Lets redsitribute OSPF into BGP again!

SPEDGE1(config)#router bgp 1
SPEDGE1(config-router)# address-family ipv4 vrf CUSTOMER
SPEDGE1(config-router-af)#no  redistribute ospf 2 vrf CUSTOMER metric 200 match internal external 1 external 2
!
SPEDGE2(config)#router bgp 1
SPEDGE2(config-router)# address-family ipv4 vrf CUSTOMER
SPEDGE2(config-router-af)#no  redistribute ospf 2 vrf CUSTOMER metric 200 match internal external 1 external 2

Lets test it again!

SITE1#ping 22.22.22.22 so lo1
!
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 22.22.22.22, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 140/148/168 ms

Now it works. So we dont need any redistribution from BGP into OSPF but from OSPF into BGP or better MP-BGP because MP-BGP needs to have the prefixes in its routing table to use LDP for the VPN-label-assignment.

I hope you enjoyed reading.

Feel free to comment!
Regards!
Markus

Advertisements

About markus.wirth

Living near Limburg in Germany, working as a Network Engineer around Frankfurt am Main.
This entry was posted in MPLS and tagged , , , , , , , , , , , , , , , , , , . Bookmark the permalink.

18 Responses to mpls: ospf sham link – why? and howto!

  1. Hendry Indonesia says:

    nice post.. really easy to understand. thx for sharing 🙂

  2. Ponka Man says:

    Damn you are smart.

  3. KN says:

    nice work…..

  4. Sunil Saraswat says:

    amazing….nicely drafted… easy to understand….
    Thanks you..

  5. Villa Blake says:

    fantastic!!!!!

  6. raja says:

    very good article,very nice.

  7. winder says:

    “SITE1 sees the routes from a router from the same AREA but its not directly connected. This has the effect that the routes are received by SITE1 as “IA” (INTER AREA) routes. ”
    Really?
    IA is for different Area, as long as they are from the same area, it should always be O.

  8. Ami says:

    thanks really , you make it sound so easy .. Great Job !!

  9. Akhilesh says:

    Nice work buddy!! Easy to understand and very helpful!! 🙂

  10. MB says:

    Thanks man. This is an amazing explanation

  11. -GJ says:

    Very good! Thanks.

  12. Ravi says:

    excellent.!

  13. Hanumandlu Thota says:

    Good.. Thanks

  14. Andre says:

    Very good explanation, thanks Markus.

  15. chris says:

    I just labbed this up identically and in fact the LSAs never appear as inter-area, but as type-5 lsas:

    SITE1#sh ip ro ospf
    2.0.0.0/32 is subnetted, 1 subnets
    O E2 2.2.2.2 [110/200] via 10.10.11.1, 00:12:05, FastEthernet0/0
    22.0.0.0/32 is subnetted, 3 subnets
    O E2 22.22.22.22 [110/200] via 10.10.11.1, 00:11:50, FastEthernet0/0
    O E2 22.22.22.23 [110/200] via 10.10.11.1, 00:11:35, FastEthernet0/0
    O E2 22.22.22.21 [110/200] via 10.10.11.1, 00:11:50, FastEthernet0/0
    10.0.0.0/30 is subnetted, 2 subnets
    O IA 10.10.22.0 [110/201] via 10.10.11.1, 00:16:46, FastEthernet0/0

    I’m running “Cisco IOS Software, 7200 Software (C7200-ADVIPSERVICESK9-M), Version 12.4(24)T2, RELEASE SOFTWARE (fc2)”

  16. Tapan Saha says:

    Excellent expiation.
    Thank you Sir.

  17. Hennie says:

    Config does not work.??? Routes are still learned via OSPF Intra Area.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s