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
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.
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
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.
Everyone should check out Massimo Candela's presentation "Geolocation
problems: Do we have a solution?" for how to provide your own
geolocation data...
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,
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
draft-ymbk-opsawg-9092-update-00 - A Minor Update to Finding and Using Geofeed Data
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/
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.