Dual Homed BGP

Fri Jan 24 17:22:39 UTC 2020

We have full tables from 2 ISPs at just one datacenter, and it is nice in the case of partial reachability issues—If one ISP loses access to routes to a destination but the other one doesn’t, for example. For us, the decision to do full tables was easy, as we are running 2 MX150s which can very easily handle the load and convergence is still less than a minute or so. As far as optimal path goes, full tables really doesn't help us much, so we made sure to get matching speed circuits just to make things simple. We have AT&T and CenturyLink, and most things prefer CenturyLink as they are pretty well peered due to all of their acquisitions. It would be interesting to see a distribution plot of ASPATH length, I would bet that a huge chunk  of our routes are only 2-3 hops away.

/chris

On 1/24/20, 10:56, "NANOG on behalf of Ben Cannon" <nanog-bounces at nanog.org on behalf of ben at 6by7.net> wrote:

    Honestly, this.  Your only real choice is what of 2 pipes to chuck it out of.

    Full tables vs partial and a default don’t make the process much more intelligent for 1 site dual homed, and as mentioned routing policy will have more influence.

    -Ben

    > On Jan 24, 2020, at 8:47 AM, Mel Beckman <mel at beckman.org> wrote:
    > 
    > It’s pretty pointless for a small ISP to get full routes, because the BGP tables are so highly manipulated. It’s better to just get “company” routes for each upstream, and then use your own traffic engineering via prepending and static or policy routes to balance the outbound traffic the way you like. 
    > 
    > -mel 
    > 
    >> On Jan 24, 2020, at 8:40 AM, Brian <brian.bsi at gmail.com> wrote:
    >> 
    >> 
    >> Hello all. I am having a hard time trying to articulate why a Dual Home ISP should have full tables. My understanding has always been that full tables when dual homed allow much more control. Especially in helping to prevent Async routes.
    >> 
    >> 
    >> Am I crazy? 