Sully, baby... You're starting to frustrate me. >:-(
Kidding. :-)
R1 has O E2 routes for the 200.1 networks from AS 6500 in its routing table because you are redistributing BGP into OSPF on R4, something you failed to mention that you added to the config you posted earlier. You said all you did was add the network statements under BGP on R4, and you were then wondering why the 200.1 networks started showing up as O E2 routes in R1's routing table. Since you redistributed BGP into OSPF, well now those 200.1 routes show up as OSPF E2 routes at R1 and are placed in the routing table because of our old friend, administrative distance, as I explained earlier. R1 is learning about the 200.1 networks through iBGP and OSPF. Who wins? OSPF.
So why doesnt the 50.1.1.0/24 subnet appear as an O E2 route in R1's routing table you are about to ask? Well, you are missing the subnets keyword in the redistribution statement, so networks will only be advertised along classful lines and subnets will be excluded.
Now, as far as your inability to PING the 50.1.1.0 subnet from R1, perform a traceroute and lets see where the packet dies. Whenever a PING fails, you must perform a traceroute to see how far you're getting.
Anyway, without seeing the configs for the other 2 routers (R2 and R3?), I will take a guess that they do not know about the 50.1.1.0/24 network because the BGP redistribution into OSPF left out the 50.1.1.0 subnet from the advertisement. So, since they are not running any iBGP sessions, as R1 is, they don't know about the subnet, so they drop packets destined for that network.
[EDIT] By the way, you will want to perform a traceroute on the 200.1.1.1 PING, too, since you're dropping packets and experiencing a lot of delay in your round-trip-time. [EDIT]
Victor
