MP-BGP query need help

Question

Hi Experts,
I've gone through so many mpls documents and I believe i have a decent grasp of how it works but applying those principles i appear to be stuck in a setup that just won't work.
The setup is pretty straigh forward: R1 is connected to R2 and R2 is connected to R3.
R1 has ospf peering with R2 and R2 has ospf peering with R3.
OSPF working fine and connectivity via Lo on all routers working.
R1 has MP-BGP bgp peering with R3 where R1 and R3 is advertising its Lo100 interface to each other.
BGP working fine and I can see from R1 the Lo100 ip of R3 on the vrf myvrf routing table of R1.
When I do a show ip route vrf myvrf on R1, route to Lo100 of R3 (99.1.1.3) has an egress of 5.1.1.3 (default global table).
But when i try to ping from R1, 'ping vrf myvrf  99.1.1.3 source 99.1.1.1' ,  ping fails.
Documentation says that this should work but apparently it doesn't for me; am not sure what i am missing here.
I even tried to leak the route on both R1 and R3.  But still no go.
R1:
ip route vrf myvrf 5.1.1.3 255.255.255.255 f0/0 1.1.1.2
R3:
ip route vrf myvrf 5.1.1.1 255.255.255.255 f0/0 2.1.1.1
Don't know what i am doing wrong here.  And to be honest am getting confused.  Please help.
Setup is as follows:
R1:
int f0/0
ip 1.1.1.1 255.255.255.0
mpls ip
int Lo0
ip add 5.1.1.1
int Lo100
ip vrf forwarding myvrf
ip add 99.1.1.1 255.255.255.255
ip vrf myvrf
rd 10:20
route-target both 10:20
router ospf 1
router-id 5.1.1.1
network 1.1.1.0 0.0.0.255 area 0
network 5.1.1.3 0.0.0.0.0 area 0
router bgp 10
neighbor 5.1.1.3 remote-as 10
no neighbor 5.1.1.3 active
neighbor 5.1.1.3 update-source Lo0
address-family vpnv4
neighbor 5.1.1.3 activate
neighbor 5.1.1.3 send-community both
address-family ipv4 vrf myvrf
network 99.1.1.1 mask 255.255.255.255
R2:
int f0/0
ip add 1.1.1.2 255.255.255.0
mpls ip
int f1/0
ip add 2.1.1.1 255.255.255.0
mpls ip
int Lo0
ip add 5.1.1.2 255.255.255.0
router ospf 1
router-id 5.1.1.2
network 1.1.1.0 0.0.0.255 area 0
network 2.1.1.0 0.0.0.255 area 0
network 5.1.1.2 0.0.0.0 area 0
R3:
int f0/0
ip add 2.1.1.2 255.255.255.0
mpls ip
int Lo0
ip add 5.1.1.3 255.255.255.0
int Lo100
ip vrf forwarding myvrf
ip add 99.1.1.3 255.255.255.255
router ospf 1
network 2.1.1.0 0.0.0.255 area 0
network 5.1.1.2 0.0.0.0 area 0
router bgp 10
neighbor 5.1.1.1 remote-as 10
no neighbor 5.1.1.1 activate
neighbor 5.1.1.1 update-source Lo0
address-family vpnv4
neighbor 5.1.1.3 activate
neighbor 5.1.1.3 send-community both
address-family ipv4 vrf myvrf
network 99.1.1.3 mask 255.255.255.255

Answer 1

Hello Marcusbrutus,
blau grana is right you have an issue with loopback addresses subnet masks.
Your control plane looks like fine because you have all the expected MP BGP VPNv4 routes in place, but the forwarding plane is broken.
MPLS L3 VPN packets are sent within the LSP with destination the remote PE loopback address so from R1 point of view is R3's L0.
If you go on R2 device and you check the state of MPLS forwarding for R3 L0 IP address you will see that instead of seeing a POP TAG action you will see an untagged action.
The reason for the wrong LSP binding is the subnet mask on R3 loopback address:  OSPF advertises all loopback addresses with a /32 mask by default, but the subnet mask is different. LDP carries the configured subnet mask. But installation of labels is made after check with IGP (OSPF in this case).
As a result of this the R2 router cannot install the correct POP TAG  = implicit null label as action to do to reach R3 L0.
With POP TAG  action the R2 router removes the external label  (POP a label) and sends a packet (with MPLS ethertype on ethernet) with a single label MPLS stack to the egress PE R3. R3 sees a label associated to the VRF and it is able to route the packet to the appropriate interface.
With untagged action R2 removes a label take all the packet content and sends it as it was an IP packet to the downstream device. (with ethertype 0x800 on ethernet) The downstream device finds a packet that is supposed to be an IP packet but it isn't (for the inner label still there) and silently drops it.
This is what we had seen in lab tests.
To solve this issue you should:
use /32 loopback addresses this the recommended best practice
or you can still use non overlapping non /32 loopback addresses but you need to add the command ip ospf network point-to-point under loopback configuration as this makes OSPF to advertise the true IP subnet mask
Hope to help
Giuseppe