Baldur Norddahl wrote on 5/31/2015 1:13 PM:
Remember this:
1) for inbound traffic there will be no difference at all.
2) routers will ignore a static route if the link is down. If you can get BFD from the providers then even better.
So you can emulate 99% of what you get with full routes by loading in static routes. A simple example would be adding a 0.0.0.0/1 route to one provider and 128.0.0.0/1 route to the other and get approximately 50% load sharing.
You will still get redundancy as the route will ignored if the link is down and traffic will follow the default route to the other transit provider.
Something to point out: Sometimes the device you connect to is up, but has no reachability to the rest of the world. Using static routes is.. well.. static. There are a few cases (such as the one mentioned) where a static route can be somewhat dynamic. Another case is when the static route next hop does not respond to ARP requests or some machines have the ability to perform triggered actions on some sort of event/test. But why bother with BGP if you're just going to override its decisions by using static routes? As another commenter mentioned, using anything less than a full table is a compromise. If one wants the redundancy in the case of an upstream ISP outage, take full routes. If one wants the traffic engineering flexibility, take full routes and use a BGP knob like route maps to modify existing prefixes rather than make up your own. A default route of last resort is fine; Overriding BGP through static routes degrades the utility of BGP.