Re: Google peering in LAX

[Matthew Petach <mpetach () netflight com>]

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.