Are you receiving full routes or just default routes?
For what you’re trying to do, default route should pretty much be all you need.
You could use route marks and mangle table packet marking to achieve your goal with a single router, but the logic and failover configurations are quite crazy.
It would be better to use 2 routers. It requires no packet marking craziness.
Configure EBGP:
Connect ISP1 to R1, and ISP2 to R2.
Set both R1 and R2 to originate 10.1.1.0/24 and 10.1.2.0/24 with network statements (use synchronization)
Then make R1’s out-filter to ISP1 do prepend on 10.1.2.0/24, and R2’s out-filter do prepend on 10.1.1.0/24
*Do not use blackhole route to “nail up” the advertisements. This design has a nice benefit that R1 will withdraw its advertisements from eBGP if its LAN interface fails and it can no longer reach 10.1.1.0/24 and 10.1.2.0/24
If the ISPs support BGP communities that lower the ISP’s local preference, use this in stead of prepend. It will be MUCH more effective. Send the community which lowers preference to backup-only level.
Configure internal redundancy with ospf and iBGP:
Next, create a direct link between R1 and R2, use some other IP address on the link like 10.255.255.0/24 with 10.255.255.1 = R1 and 10.255.255.2 = R2 (really use private IP on this link)
Also create loopback interfaces (bridges with no ports) loop-bridge0 on each router, and assign some unique local ID like 10.10.10.1/32 on R1 and 10.10.10.2/32 on R2.
Configure ospf on R1 and R2 with 10.255.255.0/24 and 10.10.10.0/24 as networks in backbone area. (allows dynamic reachability between them)
Also on R1, add the isp1 interface to OSPF, but set the interface to passive.
Do the same on R2.
Peer R1 and R2 with each other using the 10.10.10.x IP addresses as remote/local peering address.
iBGP is much less desirable than ebgp, so R1 will always use isp1 as default GW so long as isp1 bgp is operational, and R2 will always use isp2 as long as isp2 bgp is operational. If isp2 goes down, then R2 will lose its 0.0.0.0/0 route from ebgp, but will still have a backup default route from R1 in iBGP, so it will start going out isp1 while isp2 is down.
Finally-
Take advantage of having two routers and give yourself more internal redundancy with vrrp:
R1 = 10.1.1.253/24 and 10.1.2.253/24
R2 = 10.1.2.254/24 and 10.1.2.254/24
vrrp addresses are 10.1.1.1/24 and 10.1.2.1/24
Make R1 primary for 10.1.1.1 and make R2 primary for 10.1.2.1
Hosts in each network use 10.1.x.1 as their default GW, which under normal circumstances will be R1 for hosts in 10.1.1.0/24 and R2 for hosts in 10.1.2.0/24
There - you’re fully redundant, and have the routing policy you want, and it’s all automatic using the natural behavior of the routing protocols.
Final Thoughts
I suspect that your ACTUAL topology is a little more advanced on the inside, and that you don’t just have two flat /24 public network interfaces. If this is the case, then you can divide up your access routers into two OSPF non-backbone areas. Make sure that only 10.1.1.0/24 addresses come from area 1, and only 10.1.2.0/24 addresses come from area 2. Then you set your metrics so that routers in area 1 tend to favor R1 as the default gateway, and area 2 favors R2 as the default gateway.
Honestly, you don’t have to make it that complicated because who cares what source IP goes out which ISP, right? So long as outbound is balanced… so you could just make some routers favor R1 as default GW (regardless of the customers’ public IP addresses) and others favor R2 as default GW. Whichever router they hit first will go out via that isp link, so don’t worry about strictly balancing on source. Just balance by how much you connect to each router and let things evolve naturally.
Another point - it might be a good idea to get each isp to give you default+interior/customer routes. This way, stuff directly in isp1 will always go out isp1, and stuff directly in isp2 will always go directly out isp2. If you do this, you should use as_prepend in stead of communities (if you followed the earlier suggestion).
I know this is a lot to digest, but it’s really a much more scalable, best-practice solution than to do some forced behavior inside of a single router. Such things skyrocket in complexity as the number of interfaces and network destinations gets beyond even just 3 of each, and DEFINITELY doesn’t scale well with multiple routers in your topology.