<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">lør. 25. jan. 2020 13.42 skrev Tore Anderson <<a href="mailto:tore@fud.no">tore@fud.no</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* Baldur Norddahl<br>
<br>
> If you join any peering exchanges, full tables will be mandatory. Some parties will export prefixes and then expect a more specific prefix received from your transit to override a part of the space received via the peering. <br>
<br>
That would be a fundamentally flawed expectation, in my opinion.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I do not disagree, however the real world sometimes works differently. Like anycast, people break the rules and gets away with it. </div><div dir="auto"><br></div><div dir="auto">In any case, this is from a recent personal experience. We had a problem that led us to drop full tables and run with a default for a while. Nobody noticed the difference, which is why I can confidently say that unless you need the full tables for something, the advantages are somewhat overstated. </div><div dir="auto"><br></div><div dir="auto">However one customer found a reachability problem. Turns out that a peer was exporting a /19 prefix through a peering session with us and at another site they exported a /24 from the same space with no routing between sites. </div><div dir="auto"><br></div><div dir="auto">Regards </div><div dir="auto"><br></div><div dir="auto">Baldur </div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>