HSRP + BGP - LAN interface failover occurs but BGP fails to work

Question

I have 2 ISP's with 2 separate routers. 1 - 3845 and 1 - 2801. The routers are connected to a 2900 Catalyst switch stack on the LAN side. My Goal is to have BGP "follow" HSRP. When HSRP fails over I would like BGP to failover as well. Currently if I test failure of the LAN interface on the master router, HSRP works correctly but BGP fails to route traffic.
I have attached modified examples of the configs from both routers.

Answer 1

@Gary,
See attached document. Some disclaimers:
Its the Internet, failover will not be fast. It will not be pleasant. In most cases, ( even in L3VPN scenario and on the open Internet), I've seen BGP converge in ~2 minutes. This depends on how your ISPs are connected and how your users are connected to the internet. (Waves hand vigorously, its the Internet, such is beyond the scope of this example :)
Because of point 1 above, real-time traffic will drop during failover. But the failover is automatic so no 5am surprise while your stuck in traffic on the way into the office. Failback is also automatic ( although some people prefer users not to have two hits if at all possible. If that's the case, this isn't for you. As soon as that other active router returns to service, BGP will failback
You should test the crap out of this in a lab environment there may be idiosyncrasies in your network I did not account for ( goes without saying)
I would remove your track of "4.4.4.4" in the original configuration. Pinging stuff on the Internet is notoriously unreliable. More important, if it causes HSRP to switch _AND_ there's only a problem with the path to "4.4.4.4", you will have asymmetric routing within your network (i.e. egress from your site, you'll take router_b path, ingress to your site will take router_a path). Not totally as bad thing but something to be aware of. Whats more, egress path from internal network will go to router_a, come back on the 2960S stack, and then hit router_b. Again not totally a bad thing but something to think about. You can either add a direct link between router_a and router_b or track additional stuff ( I personally track Google and Microsoft's anycast DNS servers). The former solves the "back through stack" problem; the latter solves the "no one cares about pings / transient internet pathing problem"
One last thing. It occurred to me: What happens in this scenario:
router_a ebgp with ISPA is up. ( Or router_a bgp is down but link is up/up?)
router_a is up as well
From router_b, path to router_a is up
You get a blackhole for your site prefixes. This is because router_b still does not advertise your site prefixes because it still has the ISPA connected /30 in is BGP RIB. The workaround is to condition the announcement on the existence of prefixes originated from ISPA directly ( see doc).  If you don't have such routes, you don't have a direct connection to ISPA and that verifies that router_a is no longer a viable ingress/egress point.
I'll make one last commentary: All these mechanisms -- EEM scripts, BGP conditional announcement, IP SLA tracking, etc-- add complexity. Not strictly a bad thing, but I like to keep things simple and avoid turning knobs where possible. That said, you wouldn't have to go through these theatrics to cover the failure cases if you had a direct link between router_a and router_b, I would seriously consider making it so.
If you can't spring for an EHWIC, you could recreate your edge network by connecting both interfaces on your edge routers to the 2960S. Both ISPs would connect to either 2960S switch. Logically, you establish a full mesh eBGP sessions between your routers and your ISPs. But that's just trading one complexity for another. I'd spring for the EHWIC and add a link between your routers...
Mark if you find helpful. Come back and show me your results as well...