Hi,

My company is connected to an upstream ISP and have announced a /22 prefix. We peered with a customer who has his own ASN and his own /22 prefix which he has advertised to us. Our downstream customer's traffic is still going through his earlier provider and not through the link we have provided even though our upstream provider is receiving both /22 prefixes. The issue it seems is that my customers's ASN is not allowed in my upstream ISP's network since they're not directly peered. I've been told to use the AS-SET attribute to resolve this. I have limited knowledge of BGP and have done some on;ine research on this and see that it's BGP route aggregation. However I'm still unclear on how to implement something equivalent to the AS-SET attribute on an MT box.

Any help would be highly appreciated.

Thanks
Amit

amity2kare,

AS-SETs are not router commands, but are route-object records, which are created in any registered Internet Routing Registry (IRR), e.g. RADB, REACH or NTTCOM. All Tier-1 (global) and Tier-2 (regional) upstream providers build their BGP filters by querying created route-objects (e.g. aut-num, as-set, route, route6) in registered IRR servers (e.g. whois.radb.net or rr.ntt.net).

An as-set record is a type of record which lists members (downstream peers and itself) of a particular as-number. Below is an example of an as-set record for google:

~$ whois -h whois.radb.net as-google
as-set: AS-GOOGLE
descr: Google, Inc.
members: AS1406
members: AS1424
members: AS6432
members: AS11344
members: AS13949
members: AS15169
members: AS15276
members: AS19425
members: AS22244
members: AS22577
members: AS26910
members: AS36040
members: AS36492
members: AS36561
members: AS40873
members: AS43515
members: AS55023
members: AS-GOOGLE-IT
admin-c: AS15169 Network Operations
tech-c: AS15169 Network Operations
remarks: For network issues, mail: nst@google.com
remarks: For peering questions, mail: peering@google.com
notify: noc@google.com
mnt-by: MAINT-AS15169
changed: noc@google.com 20160808 #15:31:00Z
source: RADB

Tier1/Tier2 providers use as-set records to build BGP as-path filters towards all their peers. Thus any as-number which has a downstream BGP peer, must create an as-set record to notify the internet who their members are (downstream members and itself), so that the providers' BGP as-path filters are built correctly.

You can refer to http://www.irr.net and https://en.wikipedia.org/wiki/Internet_Routing_Registry to know more.

However, Tier1/2 providers' BGP filters are also built with prefix filters, not just as-path filters. Thus a route/route6 route-object for the actual prefix to be advertised must also be created by the originating as-number. An example is as below:

~$ whois -h rr.ntt.net 159.148.147.201
route: 159.148.147.0/24
descr: MIKROTIKLS
origin: AS51894
mnt-by: AS2588-MNT
changed: unread@ripe.net 20000101
source: RIPE
remarks: ****************************
remarks: * THIS OBJECT IS MODIFIED
remarks: * Please note that all data that is generally regarded as personal
remarks: * data has been removed from this object.
remarks: * To view the original object, please query the RIPE Database at:
remarks: * http://www.ripe.net/whois
remarks: ****************************

This route route-object tells us that prefix 159.148.147.0/24 is a valid prefix advertised by AS51894 (i.e. origin: AS51894). Thus the BGP prefix filters will also be built accordingly.

I think there is a confusion in terminology here.

I believe the OP is wanting to overwrite the AS-PATH with his own AS.

AFAIK this is not currently possible, but I can certainly understand where it would be useful.

Email support@mikrotik.com for an official answer.

Thanks zagziggy but as_monkey is correct. Ill explain in slightly greater detail so you understand better.

I am an ISP with an upstream provider and I've advertised my prefixes (/22) which is fine as my direct clients' services are working fine. No issues there whatsoever.

Another company has peered with me on my downstream side for bandwidth and they have their own ASN and IP prefixes (/22) which they have advertised to me over an eBGP session and I have in turn advertised the same to my upstream provider.

The problem is this. My downstream customer's link shows no traffic whatsoever. He is using another upstream provider and all his traffic is being routed without any issues via this second upstream provider. If I change the route distances on his router to prefer my route, uploads start but downstream traffic in his network still prefers his second upstream provider. I performed a traceroute from a remote location on some of his IPs and their reachability is through the second upstream provider. I have also checked the bgp looking glass and the results are the same. I checked with my upstream provider and he says my downstream provider's ASN is not allowed on his network and that I would need to use the as-set to rectify that. I checked and being a BGP noob found references to the as-set command as part of bgp route aggregation in cisco. I also read up in the mikrotik wiki/forums about route aggregation and saw that it did something similar to what i wanted, basically show my ASN as the origin of my customer's prefixes.

I would love to research some more and do this on my own but I'm short of time on this and would appreciate a little help to get this done faster than it would take me to do it on my own time.

P.S: I also ran a looking glass query on my client's prefixes and it showed that his second upstream provider has set the local_pref to 250 and I know the default value for that is 100. In my limited knowledge, a higher number means a preferred route. I wonder if this is part of the problem.

Update: I just got off a con-call with my upstream ISP and it's confirmed. Their received bgp routes show my customer's prefix's originator as my ASN. So that effectively resolves that part. Regarding the local_pref, my upstream ISP has confirmed that could be an issue whereby the second upstream provider's routes would always be preferred. I have sent them an official mail and they will be modifying the local_pref value at their end to resolve that bit as well. Will post back in a couple of days after monitoring traffic post-changes.

LOCAL_PREF attribute do not traverse external ASNs, thus they are only of local significance i.e. only within your upstream's ASN. Your upstream's LOCAL-PREF attribute will not influence the routing for the whole internet.

In global BGP, routes are almost always chosen based on the AS_PATH. It is likely that the internet does not prefer the path towards your downstream via your ASN, because your path has a longer AS-PATH. This is unfortunate for you, but it is normal, especially if the your downstream customer is also subscribing to an upstream that is higher in the tier than your ASN. Thus most incoming traffic for your downstream would prefer to use his other upstream, becuase his other upstream provides a shorter AS-PATH towards the internet.

In my opinion, in BGP, there are two ways to influence incoming traffic towards a multi-homed ASN i.e. an ASN with multiple upstreams.

1) Use different BGP MED attributes when advertising towards your prefixes towards the upstreams. Routes with higher MEDs will be preferred. However, this will only be true if the routes to be compared has the same AS_PATH, as the AS_PATH will always be compared first in the BGP path selection process. Thus this method is mostly useful only if the downstream has multiple BGP peerings towards the same upstream.

2) Advertise specific prefixes towards one of the upstream to influence incoming traffic. Since your downstream customer has a /22 prefix, you can ask it to create a specific /24 prefix from within the /22 prefix (a /22 prefix can be subnetted to four /24 prefix), then advertise it only to your ASN. Your ASN will then advertise this /24 prefix towards your upstream, and the rest of the world will see this /24 prefix coming via your ASN. Since routing will always prefer the more specific prefix, this will influence incoming traffic destined for the /24 prefix to use your ASN as the path to reach your downstream customer. All other traffic for your downstream's supernet (i.e. /22 prefix) will remain on the original routing path.

Note: if you intend to follow the 2nd option for your customer, you need to ask your downstream customer to create a route route-object for the /24 prefix, so that this /24 prefix will be accepted within the global BGP filter-lists.

In my opinion, it is inadvisable to originate a prefix not belonging to your ASN, if the actual owner of the prefix already has its own public ASN. Doing this would violate all the route-object records created for the prefix. As mentioned in my earlier post, route route-objects have the ORIGIN value, which is the ASN of the originator (or owner) of the prefix. Thus the Tier1/Tier2 BGP filter-lists will DENY your advertisements, because the filters will be built to only accept the prefix as per the origin ASN stated in the route-object records. This can also explain why there is no incoming traffic through your ASN destined to your downstream customer.

You can originate your downstream customer's prefix only if your customer does not own a public ASN i.e. it is using a private ASN to peer to your ASN. Since private ASNs will not be visible in the internet, it is OK for your public ASN to originate your downstream's prefixes.

This seems to be a problem of your downstream client, not yours. It needs to do proper traffic engineering in order to traffic be rightly balanced over two upstreams (you and the other).

2nd option from @zagziggy's answer is easier way to achieve incoming traffic balancing. I would just add that usually supernet is announced for both upstreams while half of subnets (first 2 /24s) are announced for one upstream and other half (last 2 /24s) for other upstream. This provides not only traffic balancing but also redundancy for the case one of upstreams gets down.

Specific prefixes is not only way. You downstream may prepend its ASN on prefixes announced for some upstream as much times as needed for the as-path through that upstream be less preferable (it may occur other upstream be still preferable for some origins if you prepend the ASN for the right amount of times and that would be also a way of balancing incoming traffic).

Also, the 2nd option will contribute to blowing up the IPv4 global routing table size even more - so please, don't start randomly deaggregating your IP allocations just because it's funny. Try having your customer prepend first or at least split the /22 into two /23s and not four /24s.

Thanks all for your contributions,

The downstream customer finally installed a separate router for the second uplink from me and things are working fine as I had configured them initially with an aggregate for his prefixes. I know it's not a very graceful solution but it's working without a hitch now.

Thanks to a great community.