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 129.250.0.0/16 (2001:418::/32 in IPv6), and if any customer loses visibility on 129.250.0.0/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 :-) Kind regards, Job
