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-boun...@nanog.org on
behalf of b...@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 <m...@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....@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?
