BGP Multihoming 2 providers full or partial?

Mon Jun 1 20:17:25 UTC 2015

You could have your transit providers send you a default route in the 
BGP session instead of nailing it up using a static.  That way if the 
interface does not physically go down but the BGP session does, the 
default route will be pulled when the BGP session dies.

Also, you could go with a less expensive router that will handle full 
routes such as the Mikrotik CCR's ( 
http://routerboard.com/CCR1036-8G-2SplusEM ).  Get one for each of your 
transit providers.  People have varying experiences with Mikrotik 
however for basic use they seem to work well.

Jeremy Malli
jeremy at vcn.com

On 6/1/2015 11:40 AM, Blake Hudson wrote:
> A gateway of last resort, also called a backup default route, will take
> care of partitions and is, in my opinion, a good idea if you are not
> providing transit to others. It's a requirement if you're not taking
> full routes, but even if you do take full routes the management cost is
> practically nill.
>
> The practical problem with with using static routes (or a locally
> generated default route only BGP feed) for egress route selection is
> when your upstream providers perform maintenance or have an outages.
> When this occurs, you'll likely be impacted during the duration of the
> event. This may be 5 minutes, it may be hours. What are the track
> records for your upstream ISPs? Is having two ISPs doubling your
> downtime, and is this the desired outcome? If you can't send traffic out
> to half of the internet for an hour is that OK? At midnight? At noon?
>
> --Blake
>
> Maqbool Hashim wrote on 6/1/2015 11:28 AM:
>> First off thanks to everyone that responded to my original post, very
>> instructive and informational replies along with a good view of
>> different perspectives.
>>
>> Baldur, you pointed out that for ingress it's exactly the same to take
>> partials, we are only affected on outbound and we can achieve a large
>> part of the redundancy for outbound also.  Someone else pointed out
>> that partitions of the Internet view from our two providers are often
>> lasting minutes rather than hours.  Given this input I really lean
>> towards Baldur's statement of we can probably spend the money better
>> elsewhere.
>>
>> One point I will try and make internally is "Do we care about all of
>> the Internet all of the time?", note we are not an ISP.  Basically if
>> some part of the Internet in is unreachable for a "short" period will
>> we even notice it?  Always if it is one of our remote sites, but of
>> course we can mitigate that by making those part of the partials that
>> we take from both of our providers.
>>
>> By taking full routes I can only see us protecting the view of the
>> whole Internet our internal web browsing clients, after all if a
>> partition to a "busy" part of the Internet happens we will notice it
>> straight away (Google etc.), but if it is someone's iTunes server on
>> the end of some small DSL provider- do we care?
>>
>> One thing I would rather not do which is manage static routes on the
>> BGP routers seems counter intuitive on the face of it.
>>
>> ________________________________________
>> From: NANOG <nanog-bounces at nanog.org> on behalf of Baldur Norddahl
>> <baldur.norddahl at gmail.com>
>> Sent: 01 June 2015 16:49
>> To: nanog at nanog.org
>> Subject: Re: BGP Multihoming 2 providers full or partial?
>>
>> On 1 June 2015 at 15:29, Blake Hudson <blake at ispn.net> wrote:
>>
>>> 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.
>>>
>> Thanks for pointing this out. However I would like to argue whether
>> this is
>> a big drawback or not.
>>
>> If the original poster had infinite money and infinite resources there
>> would be no question to ask. Just get the most expensive router out there
>> and get full tables.
>>
>> So given that the money could be spent on other things, that might be
>> more
>> helpful for his company, is it good value to invest in new routers? I
>> believe every company and NOC teams needs to decide this for
>> themselves. I
>> do however feel this is often a rushed decision because people have an
>> idea
>> that anything less than full tables is not good enough and that you
>> are not
>> a real ISP if you do not have full tables etc.
>>
>> It is true that your static routes could end up pointing at a half dead
>> router, that still keeps the link up. But it is also perfectly
>> possible for
>> a router to keep advertising routes, that it really can't forward traffic
>> to or where there are service problems so servere that it amounts to the
>> same (excessive packet loss etc). This is supposed to be rare for a good
>> quality transit provider and the remedy is the same (manually take the
>> link
>> down).
>>
>> We got our big routers and full tables early on. With perfect 20/20
>> hindsight I am not sure I would spend the money that way if I had to
>> do it
>> over.
>>
>> All I am saying is that you can get most of the value with partial
>> tables.
>> You get 100% of it with ingress traffic and you can move a very large
>> fraction of your egress exactly the same. Your redundancy might not be
>> equal, but it will not be entirely bad.
>>
>> Regards,
>>
>> Baldur
>