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 forceSPEDGE1 (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 forceSPEDGE2 (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 shutSITE1#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 detachedSITE1#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
:: Markus´ journey to the CCIE R&S :: 
nice post.. really easy to understand. thx for sharing 🙂
Damn you are smart.
nice work…..
amazing….nicely drafted… easy to understand….
Thanks you..
fantastic!!!!!
very good article,very nice.
“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.
thanks really , you make it sound so easy .. Great Job !!
Nice work buddy!! Easy to understand and very helpful!! 🙂
Thanks man. This is an amazing explanation
Very good! Thanks.
excellent.!
Good.. Thanks
Very good explanation, thanks Markus.
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)”
Excellent expiation.
Thank you Sir.
Excellent explanation
Thank you Sir.
Config does not work.??? Routes are still learned via OSPF Intra Area.