Re: BGP routing ARIN space in APNIC region

[Jon Lewis]

On Fri, 9 Jun 2023, Matthew Petach wrote:


I previously wrote:
  Every platform I've used has a knob for turning off / relaxing as-path
  loop detection.  Note, for some platforms (at least Juniper), you may also
  have to have your upstream provider "advertise-peer-as", though I suspect
  it's highly unlikely you'd have BGP service from the same upstream in both
  CA and PH...so this won't likely be an issue.

I'd recommend this be treated as a "BGP 201" level exercise, not a "BGP 101" 
knob to turn.

If you're asking for advice from the NANOG mailing list about how to best set 
up your first 
"remote" network location, you're in BGP 101 territory, and probably shouldn't 
be 
disabling as-path loop detection as a general rule.  ^_^;

No knock on you, just that it's probably best not to do that until you're a lot 
more
comfortable with the potential gotchas that can result from making changes to 
the
default BGP protocol behaviour on your border routers.


Funny timing on this.  Work somewhat recently opened a few new "island 
POPs", each with the same couple of transit providers and no backbone. 
While looking into something else, I realized one of our transits is not 
advertising any of these sites' routes to the other sites.  MAC address 
lookup suggests they're running Cisco gear.  Googling suggests that IOS XR 
has added the functionality I thought was unique to Juniper of not 
advertising routes to an eBGP neighbor if those routes were received from 
the neighbor's ASN.


Juniper at least had the good sense to make this behavior configurable 
down to the individual neighbor.  IOS XR apparently only lets you turn off 
this behavior at the address-family level.  If the provider isn't willing 
to make a change like this, we may have to ask APNIC for a few ASNs...and 
it may be time to stop the practice of using the same ASN in all our 
islands.


--
 Jon Lewis, MCP :)   |  I route
 StackPath, Sr. Neteng   |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: BGP routing ARIN space in APNIC region

[Hugo Slabbert]

> I've seen it at recent RIPE and LACNIC conferences. Supposedly all of
> the big geolocation providers support it or are planning on supporting
> it.

Possibly relevant there: https://geolocatemuch.com/

-- 
Hugo Slabbert


On Sun, Jun 11, 2023 at 10:56 AM Randy Bush  wrote:

> > Everyone should check out Massimo Candela's presentation "Geolocation
> > problems: Do we have a solution?" for how to provide your own
> > geolocation data...
> >
> > https://www.netnod.se/sites/default/files/2023-03/Massimo_Webpage.pdf
> >
> > I've seen it at recent RIPE and LACNIC conferences. Supposedly all of
> > the big geolocation providers support it or are planning on supporting
> > it.
>
> we're working on an small update.  see
>
>https://datatracker.ietf.org/doc/draft-ymbk-opsawg-9092-update/
>
> randy
>

Re: BGP routing ARIN space in APNIC region

[Randy Bush]

> Everyone should check out Massimo Candela's presentation "Geolocation
> problems: Do we have a solution?" for how to provide your own
> geolocation data...
> 
> https://www.netnod.se/sites/default/files/2023-03/Massimo_Webpage.pdf
> 
> I've seen it at recent RIPE and LACNIC conferences. Supposedly all of
> the big geolocation providers support it or are planning on supporting
> it.

we're working on an small update.  see

   https://datatracker.ietf.org/doc/draft-ymbk-opsawg-9092-update/

randy

Re: BGP routing ARIN space in APNIC region

[Robert Story]

On Sat 2023-06-10 18:33:04+0200 Mark wrote:
> > [...]  you may run into geolocation issues where some geolocation
> > providers decide that many/all of your users are in one location or
> > the other,[...]
> 
> This is solvable by slicing your IPv4 prefixes into /24's and
> assigning them the correct country TLD in the ARIN WHOIS database.
> Yes, you might need to call a few geo-location providers to fix their
> back-end manually, but this is possible.

Everyone should check out Massimo Candela's presentation "Geolocation
problems: Do we have a solution?" for how to provide your own
geolocation data...

https://www.netnod.se/sites/default/files/2023-03/Massimo_Webpage.pdf

I've seen it at recent RIPE and LACNIC conferences. Supposedly all of
the big geolocation providers support it or are planning on supporting
it.

Regards,
--
Robert Story 
USC Information Sciences Institute 
Networking and Cybersecurity Division

Re: BGP routing ARIN space in APNIC region

[Mark Tinka]

On 6/9/23 21:54, Matt Harris wrote:



I would also note that, from an end-user perspective if we're talking 
about ISP services to customers on both ends here, you may run into 
geolocation issues where some geolocation providers decide that 
many/all of your users are in one location or the other, creating 
problems for them both with performance when they are misdirected to 
the wrong frontend servers, as well as in terms of convenience if they 
are being served content in the wrong location, or service issues 
related to access to streaming services, etc.


This is solvable by slicing your IPv4 prefixes into /24's and assigning 
them the correct country TLD in the ARIN WHOIS database. Yes, you might 
need to call a few geo-location providers to fix their back-end 
manually, but this is possible.


Even simpler for IPv6.

Mark.

Re: BGP routing ARIN space in APNIC region

[Matthew Petach]

On Fri, Jun 9, 2023 at 6:17 PM Jon Lewis  wrote:

> On Fri, 9 Jun 2023, Matthew Petach wrote:
>
> >
> > Hi Mike,
> >
> > In general, no, there's nothing that prevents you from doing that.
> ...
> > Now, from a network reachability perspective, you should also think
> about your own internal network connectivity.
> > If you're using the same ASN in California and Makati, you'll need
> redundant internal network connections between the two countries to ensure
> you don't end up with a
> > partitioned ASN.
> > Remember, California won't accept the advertisements from Makati over
> the external Internet, as AS-PATH loop detection will drop the
> announcements; likewise, Makati won't
> > hear the advertisements of the California IP space.
>
> Every platform I've used has a knob for turning off / relaxing as-path
> loop detection.  Note, for some platforms (at least Juniper), you may also
> have to have your upstream provider "advertise-peer-as", though I suspect
> it's highly unlikely you'd have BGP service from the same upstream in both
> CA and PH...so this won't likely be an issue.
>

I'd recommend this be treated as a "BGP 201" level exercise, not a "BGP
101" knob to turn.

If you're asking for advice from the NANOG mailing list about how to best
set up your first
"remote" network location, you're in BGP 101 territory, and probably
shouldn't be
disabling as-path loop detection as a general rule.  ^_^;

No knock on you, just that it's probably best not to do that until you're a
lot more
comfortable with the potential gotchas that can result from making changes
to the
default BGP protocol behaviour on your border routers.

Thanks!

Matt

Re: BGP routing ARIN space in APNIC region

[Jon Lewis]

On Fri, 9 Jun 2023, Matthew Petach wrote:



Hi Mike,

In general, no, there's nothing that prevents you from doing that.

...

Now, from a network reachability perspective, you should also think about your 
own internal network connectivity.
If you're using the same ASN in California and Makati, you'll need redundant 
internal network connections between the two countries to ensure you don't end 
up with a
partitioned ASN.
Remember, California won't accept the advertisements from Makati over the 
external Internet, as AS-PATH loop detection will drop the announcements; 
likewise, Makati won't
hear the advertisements of the California IP space.


Every platform I've used has a knob for turning off / relaxing as-path 
loop detection.  Note, for some platforms (at least Juniper), you may also 
have to have your upstream provider "advertise-peer-as", though I suspect 
it's highly unlikely you'd have BGP service from the same upstream in both 
CA and PH...so this won't likely be an issue.


At one point, ARIN manufactured a policy that out of region use of IP 
resources didn't count toward utilization calculations, but I think that 
was fixed...not that it likely matters in general at this point.


As someone mentioned, you will have IP Geo issues to resolve.  Other than 
that, IPs are IPs, and as long as your upstreams accept your routes, it 
shouldn't matter if the IPs came from / are registered by ARIN/RIPE/APNIC, 
etc.  In fact, it was suggested to me at one point by an IP broker that we 
move all of our ARIN IP assets to one of our RIPE LIRs due to much better 
pricing re annual fees from RIPE vs ARIN.  We have POPs pretty much 
everywhere, and have IPs/accounts/memberships with 
ARIN/RIPE/APNIC/Registro.br.


--
 Jon Lewis, MCP :)   |  I route
 StackPath, Sr. Neteng   |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: BGP routing ARIN space in APNIC region

[Matt Harris]

Matt Harris
VP OF INFRASTRUCTURE
Follow us on LinkedIn!
matt.har...@netfire.net
816-256-5446
www.netfire.com
On Fri, Jun 9, 2023 at 2:49 PM Matthew Petach  wrote:

>
> Hi Mike,
>
> In general, no, there's nothing that prevents you from doing that.
> In days gone by, some networks used to require consistent advertisements
> from a given ASN in all locations in order to peer.
> In your case, that would have made it economically disadvantageous to use
> the same ASN in Makai as California, as you'd end up backhauling a lot of
> traffic.
> These days, consistent advertisement requirements have largely gone by the
> wayside.
> Now, from a network reachability perspective, you should also think about
> your own internal network connectivity.
> If you're using the same ASN in California and Makati, you'll need
> redundant internal network connections between the two countries to ensure
> you don't end up with a partitioned ASN.
> Remember, California won't accept the advertisements from Makati over the
> external Internet, as AS-PATH loop detection will drop the announcements;
> likewise, Makati won't hear the advertisements of the California IP space.
> So, if your network design is a single internal backbone link from CA to
> PH, with an expectation that if the link goes down,  you can just use
> transit providers to reach the other location, you'll be in for an unhappy
> surprise when your backbone link goes down.
> For that reason, many networks find that the cost of acquiring a second,
> distinct ASN for the remote location is considerably lower than the
> headache of trying to ensure the single ASN is never partitioned.
>
> But that's really more from a network design perspective; from a policy
> perspective, there's largely nothing preventing you from doing that.
>
> Best of luck!
>
> Matt
> On Fri, Jun 9, 2023 at 12:28 PM Mike 
> wrote:
>
>> Hello,
>>
>>  I'm certain this must have been covered before but I can't find a
>> lot of good-seeming answers. Essentially, I am a California based ISP
>> and have plans to open up shop in Makati Philippines. I have an ASN and
>> several /22's of ipv4 and a few /44s of ipv6 out of my assigned ranges
>> that I intend (desire) to bring with me. I am just wondering if there is
>> any network policy, filtering, or other reason why I simply couldn't
>> just pop up there advertising my space and away I go? I do have ROA
>> setup with arin already which should otherwise verify/validate me (great
>> tool by the way, thank you).
>>
>>
>> Thank you.
>>
>
I would also note that, from an end-user perspective if we're talking about
ISP services to customers on both ends here, you may run into geolocation
issues where some geolocation providers decide that many/all of your users
are in one location or the other, creating problems for them both with
performance when they are misdirected to the wrong frontend servers, as
well as in terms of convenience if they are being served content in the
wrong location, or service issues related to access to streaming services,
etc.

- mdh

Re: BGP routing ARIN space in APNIC region

[Matthew Petach]

Hi Mike,

In general, no, there's nothing that prevents you from doing that.
In days gone by, some networks used to require consistent advertisements
from a given ASN in all locations in order to peer.
In your case, that would have made it economically disadvantageous to use
the same ASN in Makai as California, as you'd end up backhauling a lot of
traffic.
These days, consistent advertisement requirements have largely gone by the
wayside.
Now, from a network reachability perspective, you should also think about
your own internal network connectivity.
If you're using the same ASN in California and Makati, you'll need
redundant internal network connections between the two countries to ensure
you don't end up with a partitioned ASN.
Remember, California won't accept the advertisements from Makati over the
external Internet, as AS-PATH loop detection will drop the announcements;
likewise, Makati won't hear the advertisements of the California IP space.
So, if your network design is a single internal backbone link from CA to
PH, with an expectation that if the link goes down,  you can just use
transit providers to reach the other location, you'll be in for an unhappy
surprise when your backbone link goes down.
For that reason, many networks find that the cost of acquiring a second,
distinct ASN for the remote location is considerably lower than the
headache of trying to ensure the single ASN is never partitioned.

But that's really more from a network design perspective; from a policy
perspective, there's largely nothing preventing you from doing that.

Best of luck!

Matt


On Fri, Jun 9, 2023 at 12:28 PM Mike  wrote:

> Hello,
>
>  I'm certain this must have been covered before but I can't find a
> lot of good-seeming answers. Essentially, I am a California based ISP
> and have plans to open up shop in Makati Philippines. I have an ASN and
> several /22's of ipv4 and a few /44s of ipv6 out of my assigned ranges
> that I intend (desire) to bring with me. I am just wondering if there is
> any network policy, filtering, or other reason why I simply couldn't
> just pop up there advertising my space and away I go? I do have ROA
> setup with arin already which should otherwise verify/validate me (great
> tool by the way, thank you).
>
>
> Thank you.
>
>
>