I can't figure out why you are running two instances of OSPF on the the 2900's. This looks way more complicated than it needs to be. You can run OSPF in passive mode on the firewall and distribute a default route from the 2900's. You put a static route on the 2900's for your /24 pointed at your firewall outside IP. Since this is active/standby, if the firewall fails over, the IP address moves with the active firewall. There really is no need to announce anything from the firewall, it is just listening for a default. If you are announcing a default, there is really no need for HSRP either, that can go away. The firewall will just send the traffic to where it hears the default. It might well load balance to both 2900's, though.
Seems you are making it a lot more complicated than it needs to be. There is only ONE firewall address in this configuration so a static route will work just fine. Even so, there is no need for more than one OSPF instance and the only thing you are using that for is to handle the case where a router dies. Then the firewall uses the remaining path where it hears the remaining default route.
This might be a bit long winded, but I'll try to address most of your issues in one go. Wish me luck!
You can have your upstream service providers advertise a default route (0.0.0.0) through BGP to your routers. When you configure OSPF on your BGP routers, you can use the command "default-information originate." As long as you're getting the default route from your ISP (which only happens when you have connectivity to that ISP), you'll advertise the default route into OSPF. As soon as you lose that default route from your ISP, you'll lose the OSPF default route.
You'll need to establish BGP peering between all of your internet routers (the ones connected to your ISPs). This is an internal BGP or iBGP relationship and needs to be a full mesh. Per your diagram, you only have two internet routers, so a full mesh is simple. There are no tricky steps to peer on iBGP versus eBGP; just a simple neighbor statement. When BGP sees that your neighbor has the same AS number, it forms an iBGP relationship instead of an eBGP one.
Preferring one route over another is a bit tricky, particularly where BGP is concerned. Load balancing is done using route maps and traditionally with as-path prepending. There are a few ways to do this. I'd like to add a caveat that if you aren't filtering outgoing route advertisements, you'll end up advertising ISP A's routes to ISP B and C and so forth which will turn you into a transit AS and you'll end up piping some A <-> B, A <-> C, and B <-> C traffic through your network which is probably not what you want.
Here's one go at your load balancing:
! Set an IP access list that matches your BGP-advertised network
ip access-list standard 1 permit a.b.c.d mask a.b.c.d
! Set an IP as-path access list to only allow advertising of YOUR network
ip as-path access-list 1 permit ^$
! Make a route-map for ISP C, match the as-path and access-list above, then make it look
! less appealing than going through ISP A/B
route-map ISP_C 10
match ip address 1
match as-path 1
set as-path prepend <Your AS> <Your AS> <Your AS>
! The more times you prepend your AS to a route, the less desirable it looks, so traffic
! will be more likely to come in via ISP A/B than C. The last step is to add it to your
! ISP C neighbor statement in BGP
router bgp <Your AS>
neighbor <ISP C> route-map ISP_C out
If you have more than one subnet, you can even things out a little more and use router B for site B and router A for site A by selectively prepending your AS path to individual subnets. Here's an example:
Router A:
ip access-list standard 1
permit <site B subnets>
ip as-path 1 permit ^$
route-map ISP_AB 10
match ip address 1
match as-path 1
set as-path prepend <Your AS> <Your AS>
route-map ISP AB 20
match as-path 1
router bgp <Your AS>
neighbor <ISP A> route-map ISP_AB out
neighbor <ISP B> route-map ISP_AB out
Router B:
ip access-list standard 1
permit <site A subnets>
ip as-path 1 permit ^$
route-map ISP_C 10
match ip address 1
match as-path 1
set as-path prepend <Your AS> <Your AS>
route-map ISP C 20
match as-path 1
router bgp <Your AS>
neighbor <ISP C> route-map ISP_C out
What you've effectively done is make site B's subnets look less appealing coming from Router A than they do from ISP C and make site A's subnets look less appealing coming from Router B than they do from ISP A/B. You might have to play around with your AS path prepending some to get the right amount of prepending in.
I hope this helps! BGP is a bit of a monster, but once you understand the parts, it's fun to play with. I highly recommend the CBT Nuggets series on BGP if you feel a bit shaky on the subject and I always use GNS3 as a testbed to verify big network changes before I implement them.
Best Answer
The generic statement that BGP is required when you need to route between two autonomous systems is fairly misleading. There are a lot of scenarios in which you may choose to use BGP, or it might even be required.
In the service provider world, BGP is used heavily, as it is the routing protocol of the Internet—but it sounds like your question is regarding the enterprise. In that case, you may be required to use BGP when interfacing with service providers for Internet and sometimes WAN connectivity, or you may choose to run BGP internally due to it being the most flexible routing protocol as far as routing policy goes.
Some examples of its use in the enterprise:
Your enterprise controls a block of portable public IP space. "Portable" in this case means that the space is registered to your organization by a Regional Internet Registry, like ARIN. Your organization hosts internet accessible services that utilize addressing from this address space. You typically have two options for letting the world know how to get to you:
Your service provider could advertise this space to the Internet via BGP and static route back to your environment.
You could peer with your service provider and advertise the space to them via BGP. In the case where you have more than one ISP, this is the only option. You'd advertise the space to both service providers and then use various policies or manipulation of attributes to control the paths incoming traffic takes.
In this scenario, the service providers may each advertise a default route to you (rather than the full internet routing table) and you may want to load balance your outbound Internet traffic across ISPs. In this case, you might need to manipulate BGP to ensure traffic takes the path you want it to and return traffic is influenced back through the same ISP it left on. This is super high level, but hopefully you get the picture.
Most of the time when you have MPLS links for WAN connectivity, you're not actually doing anything with MPLS. MPLS will terminate on the service provider's Provider Edge (PE) router and they will connect to your Customer Edge (CE) router with a regular ethernet link on a /30 point to point connection. In this case, you'll typically have to redistribute your IGP (internal gateway protocol e.g. OSPF, EIGRP, etc.) routes into BGP to share with the service provider. They will pass those routes through their MPLS network to their PE at your remote site, which will BGP peer with your CE at that site, at which point, you will learn the routes there and redistribute them again back into the IGP at your remote site. The same thing will happen in the other direction.
BGP isn't a requirement here, but it's typically what the service provider will want to run to keep things consistent across all of their connections to customers.
As said above, you may run BGP inside of your network, which is known as IBGP. It's actually the same exact protocol, but when you run BGP between routers in the same AS, a couple of the behaviors of BGP will change. Anyway, this is really all about control. You may have layer 2 virtual networks for WAN connectivity or even VPN links that you could run OSPF over, but in some designs, you may need more control over routing policy to achieve the behavior you want over these paths, in which case, BGP might be the right tool for the job.
Sorry to be somewhat broad, but every case is really different. When you're just learning networking, especially from Cisco, they will simplify everything to help you understand the concepts. In a way, I think they go too far in insinuating that certain generic statements are "rules" and even test you on them as if they are 100% strict rules.
The best advice I can give is to learn it their way to get down the concepts and pass your certs, but keep your mind wide open. If you want to add something a bit less formal and a bit more real world to your network learning and training, definitely pick up some O'Reilly books (related to the topics you're studying) with the animals on them. You can get them pretty cheap used on the Internet.