Partial vs Full tables
job at ntt.net
Wed Jun 10 22:41:06 UTC 2020
On Tue, Jun 9, 2020, at 08:04, Mark Tinka wrote:
> On 5/Jun/20 18:49, Saku Ytti wrote:
> > The comparison isn't between full or default, the comparison is
> > between static default or dynamic default. Of course with any default
> > scenario there are more failure modes you cannot route around. But if
> > you need default, you should not want to use dynamic default.
> I've found this to be easier to do if your network is reasonably
> "centralized", i.e., there is one or two (or small handful) of "entry
> and exit" points.
> With a stretchy, relatively flat network that neither has a definite
> entry nor exit point, it's a bit difficult to decide which failure mode
> should take the default route away.
A strong case to take the default away is when the PE the customer is connected to has become entirely isolated from the rest of the network. This can happen as a result of multiple fiber-cuts, or the classic "oops, all the diverse fibers went through that one duct".
One trick is to have each PE originating a default which depends on a route that comes from another PE (any other PE). This way a PE that for whatever reason has become entirely disconnected from the Autonomous System will cease advertising default. Make PEs with an odd-numbered loopback address depend on "ROUTE A" and PEs with an even-numbered loopback depend on "ROUTE B" - where A is originated only by even-numbered PEs and B is only originated by odd-numbered PEs. More advanced sharding strategies can be imagined, many additional failure cases too.
Back to basics: as Ytti suggested earlier in the thread, it might be more sensible to generate your own default route based on a 'stable anchor prefix' coming from the ISP rather than accepting the default your ISP originates towards you.
As an example: any NTT customers requesting to receive a default-route from AS 2914, will - in addition to 0.0.0.0/0 - also receive a route announcement for 22.214.171.124/16 (2001:418::/32 in IPv6), and if any customer loses visibility on 126.96.36.199/16 via the direct Customer<>NTT sessions, one probably doesn't want to point default in that direction.
- If you originate defaults to your customers: try to make it so that the default is withdrawn if the node has become isolated.
- If you want to point default at a service provider: anchor it to a stable prefix rather than their 0.0.0.0/0 route.
The above two suggestions may seem at odds with each other :-)
More information about the NANOG