[j-nsp] full table?

[Mark Tinka]

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.

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.

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.

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

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.

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

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20110921/ca7b6ea6/attachment.pgp>