nanog mailing list archives
Re: Google peering in LAX
From: Matthew Petach <mpetach () netflight com>
Date: Mon, 2 Mar 2020 20:13:20 -0800
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.
Current thread:
- Re: Google peering in LAX, (continued)
- Re: Google peering in LAX Seth Mattinen (Mar 02)
- Re: Google peering in LAX Hugo Slabbert (Mar 02)
- Re: Google peering in LAX Owen DeLong (Mar 02)
- Re: Google peering in LAX Seth Mattinen (Mar 02)
- Re: Google peering in LAX Randy Carpenter (Mar 02)
- Re: Google peering in LAX Seth Mattinen (Mar 02)
- Re: Google peering in LAX Patrick W. Gilmore (Mar 02)
- Re: Google peering in LAX Seth Mattinen (Mar 02)
- Re: Google peering in LAX Patrick W. Gilmore (Mar 02)
- Re: Google peering in LAX Seth Mattinen (Mar 02)
- Re: Google peering in LAX Matthew Petach (Mar 02)
- Re: Google peering in LAX Seth Mattinen (Mar 02)
- Re: Google peering in LAX Curtis Maurand (Mar 04)
- Re: Google peering in LAX Christopher Morrow (Mar 04)