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