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.
1. If you have downstream ASes, than full table is [most probably] needed to be not just received but also used for forwarding (this is by default, but you can alter, see below). Otherwise loops/blackholes are possible in specific scenarios (split customer's AS, etc). Workarounds exist for this, but they are rather too complicated to maintain and make everyone in NOC to remember how it works. Some folks (especially DCs) don't care and just send full table to customers, not having it in data plane. For DCs with just few customers with their own ASes, this approach works well almost always (until something breaks). When issues arise, they troubleshot it and rewrite policies to accept additional routes. Not very good, but I saw this many times.
2. You must remember (people forget these basics surprisingly often), that full table, you receive from upstreams or IX-peer, is used to _send_ traffic. So when you think it's useful to have full table to analyze or somehow intellectually influence traffic balancing across uplinks, you must remember that it only relates to traffic going _out_ your AS. Every couple of weeks I talk to someone who believes, he needs to receive full table, since he wants to "balance traffic". When I ask them, how much traffic they send out, it usually turns out to be not more than 10% of a single link capacity, and they don't experience any problem with it at all. And yes, most of them need to balance incoming traffic, but full table has nothing to do with this.
4. Most platform allow using two or more defaults with ECMP enabled. Real routers (like MX series) also allow using bandwidth-communities to make LB really asymmetrical (30% through ISP1, 70% through ISP2). If you need it, say, in case of different uplink capacities (10G and 1G). L3 switches (e.g. EX series) can't do this because of their much simpler (and cheaper) PFEs.
5. It does not depend on ISP, if you want to strip things out the full table (this is _your_ import policies), you can write any policy you wish, but all these tricks with not receiving "anything longer than" eliminates most of the full table advantages. If you want partial table, you better filter routes somehow more consciously. E. g. international/domestic, routes to your/customers' remote locations, routes to ASes, to which you send most of your traffic, etc. Of course, you customers won't be much happy, if you send them a partial instead of full table. So if you filter something out, you most probably need to play games (not without cheating) with forwarding along partial but sending full table to customers. See rule number 1: first, be afraid of loops and blackholes, second, this is an art and not easy to maintain, especially when different NOC shifts have to troubleshoot and resolve issues quickly.
6. If, after checking rules 1–5, you are still not sure if you need full table — you definitely don't.
Having this said, I'd say, full table is needed because of the downstream ASes. Playing the games described above does not worth it.
_______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
