It may be worthwhile for you to consider adding 15169 to your "Don't accept $tier1 prefixes from other peers" policy in your inbound policy chain. I've found that there's a set of $LARGE_ENOUGH networks that, even though they're not literal $tier1 providers, benefit from that same level of filtering. You wouldn't want to try sending Level3 traffic through a random peer, as the results would likely be catastrophic; so, make use of that same filter rule in your inbound policy to filter out hearing 15169 prefixes from other peering sessions. The caveat to that, of course, is that successful failover will mean carrying traffic across your backbone when your 15169 prefixes in one location disappear during an outage/maintenance window, so make sure your backbone is correctly sized to handle those reroute situations. It also means that multi-homed downstream customers are likely to send less upstream traffic through you to reach Google. But that *will* mean that no amount of leaking more specific prefixes through other paths will unexpectedly cause your traffic to shift. Matt On Mon, Mar 2, 2020 at 5:39 PM Seth Mattinen <sethm@rollernet.us> wrote:
On 3/2/20 4:32 PM, Patrick W. Gilmore wrote:
That said, I fear this is going to be a problem long term. A blind “no /24s” filter is dangerous, plus it might solve all traffic issues. It is going to take effort to be sure you don’t get bitten by the Law Of Unintended Consequences.
As soon as Google un-freezes new peering requests so I can get a direct peering that includes appropriate /24's I've been told offlist I should get (instead of the route server subset) I'll happily remove the transit filters. But I can only work with what I'm given.