Wednesday, 14 September 2011

Strike 2

Just a few days ago I gave the CCIE R&S Version 4.0 Lab Exam a second shot.  Unfortunately for me I am not bragging about having a CCIE number allocated to me yet.

I certainly felt pretty confident and prepared when I sat the exam.  Especially in the troubleshooting I felt more relaxed and was going through the trouble tickets much more methodically and quickly than last time.  Although there was one ticket in particular I couldn't resolve, at the close of that session I actually thought I had enough points to have passed TS.

The config section was pretty good as well, I found it fairly straight forward, there were some things I hadn't used in particular combinations before but they came together pretty well and in the end I recieved a pass in Config.

As part of the preparation efforts for attempt #2 I used the Micronics Training troubleshooting workbook, I definitely found that it contributed to my speed and methodology in identifying and resolving issues.  I also used a mocklab from Internet Expert which also indicated that my troubleshooting techniques were well under way.

It's a little disheartening to have not passed, particularly since I felt I was as prepared as I needed to be, however this was not my last shot at the lab.  I have invested a lot of time and money on this and I know for a fact that this exam is passable for me to give up now (realistically if I keep hitting a wall I may need to re-evaluate this decision).  In between lab attempts I have seen improvements in myself and they have been realised in the score reports so there is a fair chance that it will be it.

I tell myself that if it was so easy, everyone would have the certification and there would be no desire to achieve, nor any prestige associated with the certification.  The study up to now has pushed me to cover areas of networking that I wouldn't necessarily need to know in my day to day job and has caused me to understand protocols in greater depth and opening my eyes up to potentially more possibilities in future projects, so I am seeing value in the study itself even without the certification.  At the moment passing the exam is more of getting an affirmation that I have that capability (and can pass a synthetic exam)

When will I give attempt #3 a go?  Probably sooner than later, it would be particularly good to pick up my number by years end.

Tuesday, 6 September 2011

MFR (Multilink Frame Relay FRF.16) Revisited


Some time ago I blogged briefly about MFR but only had it working with back-to-back routers because at the time, I couldn't work out how to get it to work through a Frame-Relay Switch.  After catching this statement on CCO, I finally understood that the FR Switch actually had to be MFR enabled as well.

Because of this, you can do some interesting things.

This topology will have 3 devices (R1, R2 and a FrameSwitch)

R1==MFR==FRSW--FR--R2

My crude diagram above is meant to indicate that R1 has two physical links to FRSW and is using MFR, while R2 has a single physical link to FRSW using regular frame-relay.

Why might you do this?  R1 could be a hub site serving multiple spokes like R2, and the Service Provider for whatever reason cant deliver big pipes to the hub site.  As opposed to having R1 and FRSW having just two links with the spokes distributed across the interfaces, besides any bandwidth gains, MFR also enables some resiliency (losing a single physical link can still keep all spokes connected at diminished capacity)


These are the configurations:

R1
hostname R1
!
interface MFR1
 no ip address
 frame-relay multilink bid R1-MFR1
 no frame-relay inverse-arp
!
interface MFR1.12 point-to-point
 ip address 10.1.12.1 255.255.255.0
 snmp trap link-status
 frame-relay interface-dlci 102
!
interface Serial0/0
 description FRSW S0/0
 no ip address
 encapsulation frame-relay MFR1
 no arp frame-relay
 frame-relay multilink lid R1-S0/0
!
interface Serial0/1
 description FRSW S0/1
 no ip address
 encapsulation frame-relay MFR1
 no arp frame-relay
 frame-relay multilink lid R1-S0/1


FRSW
hostname FRSW
frame-relay switching
!
interface MFR1
 no ip address
 frame-relay multilink bid FRSW-MFR1
 frame-relay intf-type dce
 frame-relay route 102 interface Serial1/0 201
!
interface Serial0/0
 description R1 S0/0
 no ip address
 encapsulation frame-relay MFR1
 clock rate 2000000
 no arp frame-relay
 frame-relay multilink lid FRSW-S0/0
!
interface Serial0/1
 description R1 S0/1
 no ip address
 encapsulation frame-relay MFR1
 clock rate 2000000
 no arp frame-relay
 frame-relay multilink lid FRSW-S0/1
!
interface Serial1/0
 description R2 S0/0
 no ip address
 encapsulation frame-relay
 serial restart-delay 0
 frame-relay intf-type dce
 frame-relay route 201 interface MFR1 102


R2
hostname R2
!
interface Serial0/0
 description FRSW S1/0
 no ip address
 encapsulation frame-relay
 no fair-queue
 no frame-relay inverse-arp
!
interface Serial0/0.21 point-to-point
 ip address 10.1.12.2 255.255.255.0
 frame-relay interface-dlci 201
!



Within the MFR configuration we have added some optional statements which identify the MFR bundle:

interface MFR
 frame-relay multilink bid MFRBundleIDString


And the links which make up the bundle:

interface Serial
 frame-relay multilink lid LinkIDString


This kind of thing can help with Layer 2 troubleshooting if you have a lot of peers.

R1#sh frame multi de | i BID|Peer|LID
 BID = R1-MFR1
 No. of bundle links = 2, Peer's bundle-id = FRSW-MFR1
  Serial0/1, HW state = up, link state = Up, LID = R1-S0/1
    Peer LID = FRSW-S0/1, RTT = 20 ms
  Serial0/0, HW state = up, link state = Up, LID = R1-S0/0
    Peer LID = FRSW-S0/0, RTT = 24 ms

FRSW#sh frame multi de | i BID|Peer|LID
 BID = FRSW-MFR1
 No. of bundle links = 2, Peer's bundle-id = R1-MFR1
  Serial0/1, HW state = up, link state = Up, LID = FRSW-S0/1
    Peer LID = R1-S0/1, RTT = 0 ms
  Serial0/0, HW state = up, link state = Up, LID = FRSW-S0/0
    Peer LID = R1-S0/0, RTT = 0 ms


So from above, we can see that  that the bundle is up with both links and we appear to be connected to the right peer interfaces.


So lets see the PVC status on the Frame Switch:

FRSW#sh frame pvc

PVC Statistics for interface Serial1/0 (Frame Relay DCE)

              Active     Inactive      Deleted       Static
  Local          0            0            0            0
  Switched       1            0            0            0
  Unused         0            0            0            0

DLCI = 201, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial1/0

  input pkts 33            output pkts 29           in bytes 7428
  out bytes 4708           dropped pkts 12          in pkts dropped 12
  out pkts dropped 0                out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 0         out bcast bytes 0
  30 second input rate 0 bits/sec, 0 packets/sec
  30 second output rate 0 bits/sec, 0 packets/sec
  switched pkts 24
  Detailed packet drop counters:
  no out intf 0            out intf down 0          no out PVC 0
  in PVC down 0            out PVC down 12          pkt too big 0
  shaping Q full 0         pkt above DE 0           policing drop 0
  pvc create time 00:10:17, last time pvc status changed 00:06:07

PVC Statistics for interface MFR1 (Frame Relay DCE)

              Active     Inactive      Deleted       Static
  Local          0            0            0            0
  Switched       1            0            0            0
  Unused         0            0            0            0

DLCI = 102, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = MFR1

  input pkts 30            output pkts 24           in bytes 5029
  out bytes 4494           dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 0         out bcast bytes 0
  30 second input rate 0 bits/sec, 0 packets/sec
  30 second output rate 0 bits/sec, 0 packets/sec
  switched pkts 30
  Detailed packet drop counters:
  no out intf 0            out intf down 0          no out PVC 0
  in PVC down 0            out PVC down 0           pkt too big 0
  shaping Q full 0         pkt above DE 0           policing drop 0
  pvc create time 00:06:14, last time pvc status changed 00:05:54

FRSW#sh frame route
Input Intf      Input Dlci      Output Intf     Output Dlci     Status
Serial1/0       201             MFR1            102             active
MFR1            102             Serial1/0       201             active

Looks good here, lets see what R1 and R2 have to say

R1#sh frame pvc

PVC Statistics for interface MFR1 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = MFR1.12

  input pkts 12            output pkts 19           in bytes 2802
  out bytes 3929           dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 9         out bcast bytes 2889
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:08:34, last time pvc status changed 00:04:20
R1#sh frame map
MFR1.12 (up): point-to-point dlci, dlci 102(0x66,0x1860), broadcast
          status defined, active

R2#sh frame pvc

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 201, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.21

  input pkts 18            output pkts 22           in bytes 3608
  out bytes 6062           dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 17        out bcast bytes 5542
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:09:40, last time pvc status changed 00:05:30
R2#sh frame map
Serial0/0.21 (up): point-to-point dlci, dlci 201(0xC9,0x3090), broadcast
          status defined, active

And lets verify layer 3 connectivity:

R2#ping 10.1.12.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/12/44 ms


There are more things you can do with MFR which include the specifying the method of using the bundles (variable bandwidth class support). By default, IOS will use bandwidth class a (the MFR will stay active with downed link members as long as a single link is up),  other options include class b (all links must be active to keep the MFR interface up) or class c (a minimum threshold of links to keep the MFR interface up)

interface MFR
 frame-relay multilink bandwidth-class BandwidthClass LinkThresholdForClassC


Load Balancing:
When the MFR interface is not using FIFO queuing, the router will simly pick the interface with the empty or shortest queue to send traffic to.  If FIFO is being used then there is a default output-threshold of 300 bytes for each link, once this is exceeded, the next interface is selected.  It is possible to modify this value to a different level (this is not FRF.12 frame-relay fragmentation)

interface MFR
 frame-relay multilink output-threshold Threshold

Saturday, 27 August 2011

Catalyst Switch QoS

Layer 2 Qos is part of the R&S Blueprint and the pieces supporting how SRR queuing actually works can get quite confusing even though there is a method to the madness.

Vik Malhi has distilled this information into 3 blog posts which cover classification and marking, ingress queuing and scheduling and closing off with egress queueing, dropping and scheduling which can be found here.  Although this is primarily on the Catalyst 3750 platform, it shares many of the concepts that the Catalyst 3560 has and is configured and tested in the same manner.

These blog posts and the explanation from Narbik which he gave at his bootcamp turns a complex topic into something a bit more bearable..

Sunday, 21 August 2011

OSPF Domain Id and Sham Links

This post is looking at MPLS based VPNs and different aspects associated with routing information when OSPF is the CE-PE routing protocol

The topology under discussion is shown below:

R1(CE)===R2(PE)===R3(PE)===R4(CE)

Here are the base configurations

R1hostname R1
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
 ip ospf 1 area 1
!
interface FastEthernet0/0
 description R2 Fa0/0
 ip address 10.1.12.1 255.255.255.0
 ip ospf 1 area 1
!

R2
hostname R2
ip vrf A
 rd 1:1
 route-target export 1:1
 route-target import 1:1
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/0
 description R1 Fa0/0
 ip vrf forwarding A
 ip address 10.1.12.2 255.255.255.0
 ip ospf 2 area 1
 speed 100
 full-duplex
!
interface FastEthernet0/1
 description R3 Fa0/1
 ip address 10.1.23.2 255.255.255.0
 ip ospf 1 area 0
 mpls ip
!
router ospf 2 vrf A
 log-adjacency-changes
 redistribute bgp 23 subnets
!
router ospf 1
 log-adjacency-changes
!
router bgp 23
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 3.3.3.3 remote-as 23
 neighbor 3.3.3.3 update-source Loopback0
 !
 address-family vpnv4
  neighbor 3.3.3.3 activate
  neighbor 3.3.3.3 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf A
  redistribute ospf 2 vrf A
  no synchronization
 exit-address-family
!

R3
hostname R3
ip vrf A
 rd 1:1
 route-target export 1:1
 route-target import 1:1
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/0
 description R4 Fa0/0
 ip vrf forwarding A
 ip address 10.1.34.3 255.255.255.0
 ip ospf 3 area 1
 speed 100
 full-duplex
!
interface FastEthernet0/1
 description R2 Fa0/1
 ip address 10.1.23.3 255.255.255.0
 ip ospf 1 area 0
 mpls ip
!
router ospf 1
 log-adjacency-changes
!
router ospf 3 vrf A
 log-adjacency-changes
 redistribute bgp 23 subnets
!
router bgp 23
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 23
 neighbor 2.2.2.2 update-source Loopback0
 !
 address-family vpnv4
  neighbor 2.2.2.2 activate
  neighbor 2.2.2.2 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf A
  redistribute ospf 3 vrf A
  no synchronization
 exit-address-family
!

R4
hostname R4
interface Loopback0
 ip address 4.4.4.4 255.255.255.255
 ip ospf 1 area 1
!
interface FastEthernet0/0
 description R3 Fa0/0
 ip address 10.1.34.4 255.255.255.0
 ip ospf 1 area 1
!

R1 Fa0/0 and R4 Fa0/0 interfaces are both in OSPF area 1 when connected to the PEs so we would like to see their associated loopbacks as an "O" route

R1>sh ip route | b Gateway
Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
C       1.1.1.1 is directly connected, Loopback0
     4.0.0.0/32 is subnetted, 1 subnets
O E2    4.4.4.4 [110/2] via 10.1.12.2, 00:04:19, FastEthernet0/0
     10.0.0.0/24 is subnetted, 2 subnets
C       10.1.12.0 is directly connected, FastEthernet0/0
O E2    10.1.34.0 [110/1] via 10.1.12.2, 00:04:19, FastEthernet0/0

R4>sh ip route | b Gateway
Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
O E2    1.1.1.1 [110/2] via 10.1.34.3, 00:04:38, FastEthernet0/0
     4.0.0.0/32 is subnetted, 1 subnets
C       4.4.4.4 is directly connected, Loopback0
     10.0.0.0/24 is subnetted, 2 subnets
O E2    10.1.12.0 [110/1] via 10.1.34.3, 00:04:37, FastEthernet0/0
C       10.1.34.0 is directly connected, FastEthernet0/0

Right now these guys are seeing each other as external routes (Type 5 LSAs) Why is this?  Well if you think about it these should be external routes because we are redistributing from OSPF into BGP and then back into OSPF on our PEs.  However normally things are smart enough so that the MPLS network super backbone should keep things appearing as OSPF routes.  This isn't happening in this case for some reason:

R2#sh ip ospf int brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Fa0/1        1     0               10.1.23.2/24       1     DR    1/1
Lo0          1     0               2.2.2.2/32         1     LOOP  0/0
Fa0/0        2     1               10.1.12.2/24       1     BDR   1/1

R3#sh ip ospf int brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Fa0/0        3     1               10.1.34.3/24       1     BDR   1/1
Fa0/1        1     0               10.1.23.3/24       1     BDR   1/1
Lo0          1     0               3.3.3.3/32         1     LOOP  0/0

The problem here is the OSPF process ID for the CE facing interfaces on the PEs are different - if we had the same ospf domain id (which by default is inherited from the process id) these would not show up as external routes

R2#sh ip ospf | i Process|Domain
 Routing Process "ospf 1" with ID 2.2.2.2
 Routing Process "ospf 2" with ID 10.1.12.2
   Domain ID type 0x0005, value 0.0.0.2

R3#sh ip ospf | i Process|Domain
 Routing Process "ospf 3" with ID 10.1.34.3
   Domain ID type 0x0005, value 0.0.0.3
 Routing Process "ospf 1" with ID 3.3.3.3

So if we want the routes not to appear as external, all we need to do is make both sides agree on the domain id:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#router ospf 2
R2(config-router)#domain-id 0.0.0.3
R2(config-router)#end
*Mar  1 22:11:44.698: %SYS-5-CONFIG_I: Configured from console by console
R2#clear ip ospf proc
Reset ALL OSPF processes? [no]: yes
*Mar  1 22:11:59.690: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Interface down or detached
*Mar  1 22:11:59.726: %OSPF-5-ADJCHG: Process 2, Nbr 1.1.1.1 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached
*Mar  1 22:11:59.778: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on FastEthernet0/1 from LOADING to FULL, Loading Done
*Mar  1 22:11:59.782: %OSPF-5-ADJCHG: Process 2, Nbr 1.1.1.1 on FastEthernet0/0 from LOADING to FULL, Loading Done

R2#sh ip ospf | i Process|Domain
 Routing Process "ospf 1" with ID 2.2.2.2
 Routing Process "ospf 2" with ID 10.1.12.2
   Domain ID type 0x0005, value 0.0.0.3

R1>sh ip route | b Gateway
Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
C       1.1.1.1 is directly connected, Loopback0
     4.0.0.0/32 is subnetted, 1 subnets
O IA    4.4.4.4 [110/3] via 10.1.12.2, 00:00:40, FastEthernet0/0
     10.0.0.0/24 is subnetted, 2 subnets
C       10.1.12.0 is directly connected, FastEthernet0/0
O IA    10.1.34.0 [110/2] via 10.1.12.2, 00:00:40, FastEthernet0/0

R4>sh ip route | b Gateway
Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/3] via 10.1.34.3, 00:00:40, FastEthernet0/0
     4.0.0.0/32 is subnetted, 1 subnets
C       4.4.4.4 is directly connected, Loopback0
     10.0.0.0/24 is subnetted, 2 subnets
O IA    10.1.12.0 [110/2] via 10.1.34.3, 00:00:40, FastEthernet0/0
C       10.1.34.0 is directly connected, FastEthernet0/0

Well these routes no longer appear as external (Type 5s) but are showing up as Inter-Area (type 3s) which closer but not what we wanted.

The way that this can be fixed so that the routes will appear as intra-Area (type 1s) is to use sham-links, which is a construct that is somewhat similar to a virtual-link in that it is a tunnel over the backbone area (the MPLS network super backbone in this case) but it can be used for more than just OSPF area 0... How do we make this work?

Firstly we need to add loopbacks on each PE that are associated with the CE's VRF and advertise that into MP-BGP

R2(config-if)#int lo23
R2(config-if)#ip vrf forwarding A
R2(config-if)#ip add 23.23.23.2 255.255.255.255
R2(config-if)#router bgp 23
R2(config-router)#address-family ipv4 vrf A
R2(config-router-af)#network 23.23.23.2 mask 255.255.255.255

R3(config-if)#int lo23
R3(config-if)#ip vrf forwarding A
R3(config-if)#ip add 23.23.23.3 255.255.255.255
R3(config-if)#router bgp 23
R3(config-router)#address-family ipv4 vrf A
R3(config-router-af)#network 23.23.23.3 mask 255.255.255.255

Then within the OSPF process for the VRF we configure the sham-link

R2(config-router-af)#router ospf 2
R2(config-router)#area 1 sham-link 23.23.23.2 23.23.23.3

R3(config-router-af)#router ospf 3
R3(config-router)#area 1 sham-link 23.23.23.3 23.23.23.2

Resulting in

*Mar  1 22:24:17.802: %OSPF-5-ADJCHG: Process 3, Nbr 10.1.12.2 on OSPF_SL1 from LOADING to FULL, Loading Done

R2#sh ip ospf sham-links
Sham Link OSPF_SL1 to address 23.23.23.3 is up
Area 1 source address 23.23.23.2
  Run as demand circuit
  DoNotAge LSA allowed. Cost of using 1 State POINT_TO_POINT,
  Timer intervals configured, Hello 10, Dead 40, Wait 40,
    Hello due in 00:00:09
    Adjacency State FULL (Hello suppressed)
    Index 2/2, retransmission queue length 0, number of retransmission 0
    First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
    Last retransmission scan length is 0, maximum is 0
    Last retransmission scan time is 0 msec, maximum is 0 msec

R1>sh ip route | b Gateway
Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
C       1.1.1.1 is directly connected, Loopback0
     4.0.0.0/32 is subnetted, 1 subnets
O       4.4.4.4 [110/4] via 10.1.12.2, 00:00:39, FastEthernet0/0
     23.0.0.0/32 is subnetted, 2 subnets
O E2    23.23.23.3 [110/1] via 10.1.12.2, 00:02:55, FastEthernet0/0
O E2    23.23.23.2 [110/1] via 10.1.12.2, 00:03:54, FastEthernet0/0
     10.0.0.0/24 is subnetted, 2 subnets
C       10.1.12.0 is directly connected, FastEthernet0/0
O       10.1.34.0 [110/3] via 10.1.12.2, 00:00:39, FastEthernet0/0

R4>sh ip route | b Gateway
Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/4] via 10.1.34.3, 00:00:49, FastEthernet0/0
     4.0.0.0/32 is subnetted, 1 subnets
C       4.4.4.4 is directly connected, Loopback0
     23.0.0.0/32 is subnetted, 2 subnets
O E2    23.23.23.3 [110/1] via 10.1.34.3, 00:03:06, FastEthernet0/0
O E2    23.23.23.2 [110/1] via 10.1.34.3, 00:04:01, FastEthernet0/0
     10.0.0.0/24 is subnetted, 2 subnets
O       10.1.12.0 [110/3] via 10.1.34.3, 00:00:49, FastEthernet0/0
C       10.1.34.0 is directly connected, FastEthernet0/0

As we can see R1 and R2 now see the routes as intra-area (Type 1) as an extra clean up we may want to get rid of the loopbacks for the sham links, which can be done by controlling the redistribution from MP-BGP into OSPF

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#access-list 23 deny 23.23.23.0 0.0.0.255
R2(config)#access-list 23 permit any
R2(config)#route-map BGP2OSPF
R2(config-route-map)#match ip address 23
R2(config-route-map)#router ospf 2
R2(config-router)#default domain-id
R2(config-router)#redistribute bgp 23 subnets route-map BGP2OSPF
R2(config-router)#do clear ip ospf proc
Reset ALL OSPF processes? [no]: yes
R2(config-router)#do sh ip ospf | i Process|Domain
 Routing Process "ospf 1" with ID 2.2.2.2
 Routing Process "ospf 2" with ID 10.1.12.2
   Domain ID type 0x0005, value 0.0.0.2

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#access-list 23 deny 23.23.23.0 0.0.0.255
R3(config)#access-list 23 permit any
R3(config)#route-map BGP2OSPF
R3(config-route-map)#match ip address 23
R3(config-route-map)#router ospf 3
R3(config-router)#redistribute bgp 23 subnets route-map BGP2OSPF
R3(config-router)#do sh ip ospf | i Process|Domain
 Routing Process "ospf 3" with ID 10.1.34.3
   Domain ID type 0x0005, value 0.0.0.3
 Routing Process "ospf 1" with ID 3.3.3.3

I reset the domain-id to the default on R2 just to show that for Sham-links the domain id doesn't matter

R1>sh ip route | b Gateway
Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
C       1.1.1.1 is directly connected, Loopback0
     4.0.0.0/32 is subnetted, 1 subnets
O       4.4.4.4 [110/4] via 10.1.12.2, 00:02:00, FastEthernet0/0
     10.0.0.0/24 is subnetted, 2 subnets
C       10.1.12.0 is directly connected, FastEthernet0/0
O       10.1.34.0 [110/3] via 10.1.12.2, 00:02:00, FastEthernet0/0

R4>sh ip route | b Gateway
Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/4] via 10.1.34.3, 00:01:54, FastEthernet0/0
     4.0.0.0/32 is subnetted, 1 subnets
C       4.4.4.4 is directly connected, Loopback0
     10.0.0.0/24 is subnetted, 2 subnets
O       10.1.12.0 [110/3] via 10.1.34.3, 00:01:54, FastEthernet0/0
C       10.1.34.0 is directly connected, FastEthernet0/0

So why would we even care about this?  If there could be a backup link that bypasses the MPLS between between R1 and R2.  If OSPF was running on that link as well, the path via the MPLS network would not be used regardless of the link metric because intra-area routes are preferred over inter-area routes which are preferred over external routes.  Potentially the backdoor link may require the ospf cost to be increased to ensure that it is used only if the MPLS link is down.