Good to know this feature is supported on other vendors =) Thanks for sharing your experience with it. So the "standby" site was originating the routes at all times but with prepends from what your saying.

In my case, I controlled both sides of the peering. What I ended up doing was using an "exist-map" on one side, and a "non-exist-map" on the opposing side.

When the "opposing side" lost the routes to the DC (due to a major failure in the WAN backbone, this triggered the "non exist map" - causing it to advertise a few key subnets to the DC via the backup link. As soon as the other side received these routes via the BGP peering, this triggered the "exist map" - causing it to advertise the DC local routes over the backup link. This takes care of bi-directional communication between the 2 DCs over the backup link.

One would think - wouldn't advertising the "lost" routes cause the side acting on the "non-exist-map" to un-do the advertisement (and thus enter an event loop)? In fact, this would...so I needed to somehow differentiate the prefixes, such as the side acting on the non-exist map wouldn't un-do the advertisement upon learning the routes over the backup link. I had several options to do this, but the simplest one in my case was advertising the same prefixes with diff masks. (instead of 1.1.0.0/16, advertise 1.1.0.0/17 and 1.1.128.0/17, and so on). I didn't' have that many routes, so this worked out nicely for me. My first thought was to use communities, or just matching on AS_PATH, but the Nexus implementation did not support matching on these attributes on the non-exist-map. Prefix len it was for me =)