BGP routing ARIN space in APNIC region
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.
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 <mike+lists@yourtownonline.com> 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.
Matt Harris VP OF INFRASTRUCTURE Follow us on LinkedIn! matt.harris@netfire.net 816-256-5446 www.netfire.com On Fri, Jun 9, 2023 at 2:49 PM Matthew Petach <mpetach@netflight.com> 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 <mike+lists@yourtownonline.com> 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
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.
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 <http://www.isi.edu/> Networking and Cybersecurity Division
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
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 <randy@psg.com> 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
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_________
On Fri, Jun 9, 2023 at 6:17 PM Jon Lewis <jlewis@lewis.org> 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
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_________
participants (8)
-
Hugo Slabbert -
Jon Lewis -
Mark Tinka -
Matt Harris -
Matthew Petach -
Mike -
Randy Bush -
Robert Story