I have discovered weird routing from our ISP all related to BGP. Here is the scenario (real-one).
– there is a /19 prefix bought about 10 years ago, which was registered with ARIN authority.
– as bussiness grew each site got it /24.
The trouble starts in APNIC region in ASIA. We export one /24 prefix the regular way using two local ISPs.
When trying to reach this prefix from different ASIA sites like India or China all traffic is sent to US West Coast then back to our site. Except additional hops, this also adds about 150ms latency.
What I already tried:
– AS prepend each ISP at a time so the other left would be preffered for all inbound traffic
– both tests went similar as in both scenarios traffic hit US before reaching this trouble site.
As there is no other local special config I can think of like communities, how can I explain this?
Are both local ISP taking in consideration the ARIN info and based on that send traffic to US?
Thanks!
Best Answer
I guess I should start by saying that IP prefixes are not technically bought. When an IP prefix is allocated to a provider from an RIR like ARIN, there is no transfer of ownership. The IP range is always allocated to the RIR, and the allocation to the provider is only valid so long as the original terms of the allocation are upheld.
As for the routing part of the question, it is hard to give a specific answer without details on the actual prefixes used; however the most likely explanation is that some providers have policies in place which are not accepting the more specific /24 announcements.
I assume that the site in the US is announcing the entire /19 range, so any ISP that does not carry the specific /24 prefix will instead route towards the covering /19.
As for why some of the ISPs are not accepting the specific /24 announcements, this can have a number of reasons, and to be honest you are only going to be able to get a definitive answer from the ISP doing the filtering; however there are a few things you can try to improve your chances of the announcements being accepted.
Some ISPs will build their policies dynamically from information in routing registries. My experience is strongest in the RIPE service region, where routing policy can be registered using RPSL syntax in the RIPE database. ARIN also have a routing registry, but for the ARIN service region it is more common to register policy with the Merit RADb at ra.net. RPKI is still in it's early days and not many people are using RPKI in their policies; however it is an area to consider for the future which may allow for more reliable route distribution.
As you have seen, if the route is not in the table of these other ISPs then you are not going to be able to influence their routing by means of attributes on your announcements (i.e. as path length, communities, etc). You are only going to fix things by getting them to accept your announcement.