I am studying this B2B VRF thing and I built this lab and the diagram is attached.
Basically R101 should learn the prefix 18.104.22.168/32 on R10 through both VPNv4 and B2B VRF. Sorry if I am using the wrong terminology here but hopefully you can understand me...
So with only the VPNv4 peering ping works between R101 and R10 on their lo100 interfaces. R2 doesn't run BGP. It only handles labels. R4 is the RR. R101 and R3 build peering with R4.
However the B2B vrf setup doesn't work. R4 can't learn the prefix from R101. The peering between R1 and R101 on the B2B VRF setup is on directly connected interface, not through loopback 0 interfaces like other BGP VPNv4 peering. R1 learned the prefix 22.214.171.124/32 from R101 fine. It also advertised to R4.
Here are status on R1
R1#sho bgp vpnv4 unicast vrf TEST 126.96.36.199/32
BGP routing table entry for 65001:10:188.8.131.52/32, version 265
Paths: (1 available, best #1, table TEST)
Advertised to update-groups:
Refresh Epoch 1
Local, (Received from a RR-client)
172.20.0.2 from 172.20.0.2 (10.135.0.101)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:65001:65002
mpls labels in/out 26/nolabel
R1#sho bgp vpnv4 un all neighbors 10.135.0.4 advertised-routes
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 65001:10 (default for vrf TEST)
172.20.0.2 0 100 0 i
However R4 is getting this error with "debug bgp updates" turned on so it is not accepting it
*Jul 2 15:52:10.168: %BGP-3-INVALID_MPLS: Invalid MPLS label (15)
received in update for prefix 59648:0:175864699:184.108.40.206/8 from 10.135.0.1
Please note that the number 175864699 is actually A7B7B7B and 7B is 123. I have a feeling that the R4 is interpreted it incorrectly so it doesn't recognize the prefix. Is it because the B2B VRF setup won't work with iBGP peering?