We run eBGP to various IX’s locally and internationally. We have got to a point where we need to start using BGP communities.
Question:
ISP A advertises x.x.x.x/20 at a local exchange and advertises the same /20 as well as a more specific x.x.x.x/22 at an overseas IX. How would one engineer this route to not go out via the more specific route rather than going to the local exchange? Obliviously besides a static route. We are already using local pref / distance and pre-pending, however we cannot engineer a route to an IP that will always prefer a more specific route and then go out internationally with a lot more latency.
The only option I can see is to block the more specific prefix from your other peering point(s).
Chances are good that this more specific route is traffic engineering on the other party’s part.
Routing will always choose the longest prefix matching a given destination - that is the fundamental rule of routing. A slightly less drastic solution might be to put a static route on the router peering with the nearby IX, and redistribute this matching prefix into your iBGP with a network statement. You’ll need to be careful to ensure that this static route is only active when the nearby IX’s peering session is up and you’re receiving the /20 prefix from them. You could probably spin this with scopes.
It’s a bit kludgy no matter how you slice it because the originator of the prefix is not presenting consistent routing info into the Internet BGP table.
Is it possible that the closer IX is filtering the longer prefix / aggregating it into their table?
Does your network advertise the more specific prefix into the nearby IX? If so, the nearby IX might actually be preferring your network to reach the sub-prefix and thus would not be advertising it to you.
I am not de-aggregating our prefix’s, I advertise the same subnets locally and internationally. No idea why they advertise a /20 here and the same /20 + a more specific /22 overseas, I can only presume they are buying some sort of transit there in addition. Will contact their noc, or I presume I will have to filter that prefix out my in filter.