Thanks you for all the responses - the info has been educational (special thanks to Chris and Greg) and its given us lots more things to consider..(e.g. our SLA with our provider)..thanks... We have always planned to co-locate (still a few months away), but we just building our "web-service" (we're a startup) and in the short-term we need our boxes on-site and we need the service as HA (Highly Available) as possible [the goal is 24x7, but ...]. We have considered most of the other alternatives that were discussed in the mails (e.g. run effectively two networks, each providing the "web-service" and using some load-balancing mechanism/products with other tricks/scripts when links fail) but I wanted to "flush-out" what the issues would be if we were to multi-home via BGP to different providers [its currently planned as a short-term solution] so we could weigh the benefits/drawbacks of the approaches we were considering.... My hope was that the BGP approach would be "cleaner" ...maybe a little more upfront work, but less on-going maintenance when a link fails [none of the change the default routes on the fly hacks [and yes were running NT], manual/scripted procedures when links fails - e.g. DNS changes, etc.). But we need to understand the issues before we can make the decision. This brings me back to my original "operational" question of whether a non-aggregated /24 will be globablly visiable when our primary link fails...The situation: "When a customer in one location is using a multi-homed setup to two providers A and B, with A being the primary (using a /24 from loaned from provider A) and B being the secondary (updates via B would have a longer AS_path - using default routes with local-pref on the primary). When the customers link to A fails, will the /24 that needs to be now globably visible via B (a non-aggregate IP address for B) NOT be globably visible because of the BGP filtering policies of some other provider somewhere, say C ?