Yes, you did hit the nail on the head.
You will get asymmetry in the improved design, but asymmetry is a fact of life on the Internet, and there's really no good reason to expect symmetric routing of traffic to/from. Shoot, the whole concept of packet routing is that separate packets are routed independently of each other and may take different paths, even packets going in the same direction.
Personally, I loath PBR. Its one of those technologies that when I decide that its the best solution to the problem, I stop and take a step back to see if I really understand the real nature of the problem, even back to figuring out what the business problem to be solved is. When I do so, I almost always find that there is a way to solve the problem without using a technology like that.
Having full Internet routes in your routers will take some getting used to, but once you get used to it, it is indeed very easy to understand and troubleshoot. Certainly there are fewer "moving parts" of different protocols to worry about.
You don't want to have full Internet routes in your OSPF database, so you'll want to advertise a default via OSPF into the interior of your network (or perhaps static default...personally I prefer default in OSPF). That will move traffic towards the BGP speaking Internet routers which can make the more fully informed decision of having the full Internet routes.
That will give you close to "destination based best path". There will still be cases where the traffic will do things you don't quite expect, so you'll want to get familiar with the BGP route selection process.
The update-source isn't used for eBGP unless you use eBGP multihop (which you aren't), and it's unnecessary for your iBGP since you are not sourcing from a different interface from the one which you are using to connect the neighbors. You should remove those lines.
You don't seem to be using communities, so you can lose the lines with send-community both. Normally you would have consistent communities on prefixes within your AS, and you would only use that when you need to send your communities to a different AS.
Your iBGP routers should be sharing their BGP routing tables already, so the soft-reconfiguration inbound shouldn't be used within your AS, but it is often used between ASes.
I'm not sure why you are prepending the same number of ASes to both the external routers. Normally you use prepending to have the external AS to prefer one of your routers over the other; you would prepend on one external link but not the other. The way you are doing doesn't seem like it accomplishes anything.
Since you want to advertise aggregate prefixes, use the aggregate-address command. This will advertise the summary routes, and based on what you commented, I think this is your goal. The aggregate addresses will be advertised as long as there is at least one route within the summary in your routing table. the summary-only means that it will not advertise the individual routes that are within the aggregate address.
I think your BGP configurations should look something like:
R101:
router bgp 1
no synchronization
bgp router-id 0.0.0.1
bgp log-neighbor-changes
! network 1.0.0.0
! network 2.0.0.0
aggregate-address 1.1.1.0 255.255.255.0 summary-only
aggregate-address 2.2.2.0 255.255.255.0 summary-only
neighbor 4.4.4.1 remote-as 2
neighbor 4.4.4.1 description "R101 uplink"
neighbor 4.4.4.1 update-source 4.4.4.2
neighbor 4.4.4.1 route-map R1-MAP out
neighbor 4.4.4.1 soft-reconfiguration inbound
neighbor 1.1.1.2 remote-as 1
neighbor 1.1.1.2 description "R101 BGP interconnect"
neighbor 1.1.1.2 next-hop-self
maximum-paths 2
no auto-summary
!
R102:
router bgp 1
no synchronization
bgp router-id 0.0.0.2
bgp log-neighbor-changes
! network 1.0.0.0
! network 2.0.0.0
aggregate-address 1.1.1.0 255.255.255.0 summary-only
aggregate-address 2.2.2.0 255.255.255.0 summary-only
neighbor 3.3.3.1 remote-as 2
neighbor 3.3.3.1 description "R102 uplink"
neighbor 3.3.3.1 update-source 3.3.3.2
neighbor 3.3.3.1 route-map R102-MAP out
neighbor 3.3.3.1 soft-reconfiguration inbound
neighbor 1.1.1.1 remote-as 1
neighbor 1.1.1.1 description "R102 BGP interconnect"
neighbor 1.1.1.1 next-hop-self
no auto-summary
!
Best Answer
From routing point of view for this particular setup I don't think there is any problem apart from discontiguous AS, but that's just a cosmetic thing here.
Generally, you will lose traffic engineering ability for upstream traffic, which may or may not be an issue and it will create asymetric routing and may cause unbalanced use of inter-AS links. While with iBGP you'd have outgoing traffic engineering possible.
I think that validity of this design is dependent on if you have some kind of stateful device (firewall, ...) which would break under asymetric routing and from troubleshooting point of view it would be harder to troubleshoot any issue if you have asymetry.
This is the same setup as if you'd have a single AS which would become discontiguous, in such case forwarding between parts of now-discontiguous AS and rest of the world would still work, but forwarding between the now-discontiguous parts themselves wouldn't work, but that is not an issue in this particular scenario because you have only one downstream subnet for each router.
If you'd have multiple subnets (multiple vlans or overlapping subnets) and for example 2 switches in daisy-chain topology then a single link failure could cause traffic drops between the now-discontiguous ASes, because the subnets themselves would become discontiguous.
For iBGP disadvantages: I would say that minor added configuration complexity (for more complex networks I would suggest peering using IGP-advertised loopbacks).
From my knowledge in this setup the advantages of using iBGP would outweigh its disadvantages.