On Fri, Jan 19, 2024, 4:55 PM Owen DeLong via NANOG <nanog@nanog.org> wrote:

Sounds like you’ve got a weird mix of route origination. Why wouldn’t you advertise to Google via BGP and have your prefix originate from your own ASN?

I think in this case the customer has their own disconnected deployment, and they are asking 396982 to announce some subset of their prefixes such that gcp gets that traffic.

Owen

On Jan 19, 2024, at 02:39, kubanowy <kubanowy@o2.pl> wrote:

Hi, We have our own prefix assignment from ARIN. We have our infrastructure in GCP (Google Cloud Platform) where we started using BYOIP functionality (Google advertises our IPs). We followed their recommendation with ROA configuration in ARIN https://cloud.google.com/vpc/docs/bring-your-own-ip#live-migration-recommend... but they don't mention if IRR (whois database) should be updated as

The roa is really for two reasons: 1) tell Google you actually control that asset. 2) tell the world that 396982 is permitted to originate that prefix. Use of irr data is nice, but not required here... well. I've checked with their support and they said no additional changes

need to be done there. But currently we are in situation where ARIN's whois contains entry for our prefix with our own ASN and Google advertised to RADb entry for our prefixes with their own ASN.

I don't believe to robots at google are supposed to register irr data for byoip customers... Can you mail me off list and I can go do a.little digging? ;) When we use online tools like https://irrexplorer.nlnog.net/ or Cisco's

CrossWork Cloud (former BGPmon), they mark our prefixes due to mismatch of ASN in those 2 databases. We haven't observed any routing issues so far (i.e. ISP not importing our prefixes), but we aim to sort this out for better credibility. I'm wondering what's community approach for updating whois databases when using BYOIP functionality with Cloud providers and if there is a risk of any potential impact if we were to change information in ARIN. Thanks

On Sun, Jan 21, 2024, 5:39 PM Owen DeLong <owen@delong.com> wrote:

On Jan 21, 2024, at 12:07, Christopher Morrow <morrowc.lists@gmail.com> wrote:



On Fri, Jan 19, 2024, 4:55 PM Owen DeLong via NANOG <nanog@nanog.org> wrote:

...

Sounds like you’ve got a weird mix of route origination. Why wouldn’t you advertise to Google via BGP and have your prefix originate from your own ASN?

I think in this case the customer has their own disconnected deployment, and they are asking 396982 to announce some subset of their prefixes such that gcp gets that traffic.

If that’s the case, IMHO, the better solution is to obtain a second ASN and announce that to GCP. Create ROAs (if you want to use RPKI) accordingly.

That's not the product today, and really this is all accomplished with cloud goop inside gcp. (aws and azure have similar offerings, I believe)

Having Google originate prefixes on your behalf that are a subset of what you are announcing is just asking for difficulties you don’t need.

There's a set of reasons folks choose the byoip path, I don't claim to understand them, but in the end if they want to move ipx from asn-y to asn-z some form of this operation happens. The docs and such for the cloud providers should be clear on steps, goals, problems, etc.

Owen

On Mon, Jan 22, 2024 at 1:27 PM Owen DeLong <owen@delong.com> wrote:

On Jan 21, 2024, at 16:10, Christopher Morrow <morrowc.lists@gmail.com> wrote:



On Sun, Jan 21, 2024, 5:39 PM Owen DeLong <owen@delong.com> wrote:

...

On Jan 21, 2024, at 12:07, Christopher Morrow <morrowc.lists@gmail.com> wrote:



On Fri, Jan 19, 2024, 4:55 PM Owen DeLong via NANOG <nanog@nanog.org> wrote:

...

Sounds like you’ve got a weird mix of route origination. Why wouldn’t you advertise to Google via BGP and have your prefix originate from your own ASN?

I think in this case the customer has their own disconnected deployment, and they are asking 396982 to announce some subset of their prefixes such that gcp gets that traffic.

If that’s the case, IMHO, the better solution is to obtain a second ASN and announce that to GCP. Create ROAs (if you want to use RPKI) accordingly.

That's not the product today, and really this is all accomplished with cloud goop inside gcp. (aws and azure have similar offerings, I believe)

Interesting. It’s what several of my consulting clients are doing. They simply treat the cloud provider as an upstream peer on their cloud virtual router and bgp as normal (ish, those cloud virtual routers are pretty strange).

yes the 'cloud router' things are strange, and odd and 'not the same' across various product/providers. I know that some offerings permit a more 'direct control' of the bgp conversation betewen customer and cloud provider and internet, but that's not a universal thing :( Sometimes because 'bgp is hard', I imagine the product thought process went.

At least that's how the AWS offering works.

AWS allows you to broadcast your own ASN when you BYOIP: https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-vpc-ip-address-man... -Dan

On Jan 22, 2024, at 16:37, William Herrin <bill@herrin.us> wrote:

On Fri, Jan 19, 2024 at 1:55 PM Owen DeLong via NANOG <nanog@nanog.org> wrote:

...

Sounds like you’ve got a weird mix of route origination. Why wouldn’t you advertise to Google via BGP and have your prefix originate from your own ASN?

Big Cloud byoip doesn't generally work that way. You register the addresses in their portal and they handle everything else with the expectation that their AS is the sole origin for the prefix in question. At least that's how the AWS offering works. I presume GCP is the same. They're not acting as a general-purpose ISP.

Regards, Bill Herrin

-- William Herrin bill@herrin.us https://bill.herrin.us/