Fri May 13, 2016 5:30 pm
High-level overview steps:
Make an output filter for the Google peering session, and make sure that it only allows YOUR prefixes to be advertised.
e.g.
10.12.96.0/22 prefix-length=22-24 --> accept
10.99.32.0/21 prefix-length=21-24 --> accept
discard
(obviously, these will be public IP ranges in your case, never advertise private IP addresses to peers in public BGP sessions)
I'm pretty sure that Google is going to only send their prefixes to you and could most likely be trusted to behave well (no input filter), but you may wish to create an input filter chain which only accepts as-paths which end in Google's ASN.
You may even want to use a higher local_pref on the routes you learn from Google so that you always send traffic to Google over this dedicated link, freeing up other circuits to carry everything else. If so, then make the first rule of the google-in filter be:
bgp-actions: set BGP local_pref = 150 (or some value above your other preferences)
actions = passthrough (unless you're accepting all routes from Google, in which case, just use action=accept)
Ensure that your output filters to other peers won't allow the Google prefixes to be sent upstream or to any other peers.
If you have BGP-enabled customers, then make sure Google doesn't mind receiving these prefixes from your peering session, so that Google's traffic for your customers can be routed across the private peering as well - but make sure that these prefixes are only sent to Google when your link to the customer is up. You can use a BGP community to mark routes learned from customers and then allow routes to Google which have this community on them.
That should basically be all you need to do.