[j-nsp] full table?

[Keegan Holley]

2011/9/20 Mark Tinka <mtinka at globaltransit.net>

> On Wednesday, September 21, 2011 01:26:07 AM Keegan Holley
> wrote:
>
> > Is it always necessary to take in a full table?  Why or
> > why not?  In light of the Saudi Telekom fiasco I'm
> > curious what others thing.  This question is
> > understandably subjective.  We have datacenters with no
> > more than three upstreams.  We would obviously have to
> > have a few copies of the table for customers that want
> > to receive it from us, but I'm curious if it is still
> > necessary to have a full table advertised from every
> > peering.  Several ISP's will allow you to filter
> > everything longer than say /20 and then receive a
> > default.  Just curious what others think and if anyone
> > is doing this.
>
> Well, if you're connected to a single provider, you tend to
> have less use for a full table. 0/0 or ::/0 will do just
> fine.
>

I wish :)


>
> If you're multi-homed and need to get full use of those
> links, while taking a full feed isn't absolutely necessary,
> it does help. Folks have gotten by with default, or default
> + partial, or even eBGP Multi-Hop + Loopback peering if
> multi-homed to the same ISP.
>
> If your customers want a full table from you (and you're
> multi-homed), then a full table likely makes sense.
>

I thought about partials for the data center links and having a separate
router that carries the full table for the customers that wish to peer with
us.  This makes me uneasy though.  Thoughts of routing loops or the default
leaking into the side with the full table.  Just wondering what others have
done.  Maybe this is the right way.

>
> If you want to implement very fine control of your routing
> and traffic flow, and perhaps, offer that capability to your
> customers through BGP communities, a full table may make
> sense.
>

We offer that as well as do our upstreams.  It's always been easier to use a
full table for everything.  My thought was to develop a lower tier of
internet service based on smaller devices and manipulate the next hops so
that the traffic from the full table customers can still traverse a feed
where we may not be receiving a full table.  I'm prone to strange ideas
though...

>
> If you're modeling the routing table for research, traffic
> engineering studies or some such work, a full table may make
> sense.
>

I wish :)

>
> If you're suffering from old hardware that you don't have
> the cash to upgrade as you run out of FIB slots, having a
> full table is probably the least of your problems, and you
> may consider just default, partial routes, or default + a
> "skinny" full table.
>

I've inherited alot of old hardware from mergers.  The main problem is that
there aren't enough hands to type the request software adds and install the
MX's.  My idea was a "skinny" table for most users and a system of route
reflectors for those that need a full table.

>
> As always, it depends, and YMMV :-).
>

Indeed.  Thanks!