First post, so I apologize if I don't lay things out clearly, or if this is the wrong forum.

We are a small/regional ISP. We have a customer who has a couple of /24s (not purchased through us), and they would like us to announce these /24s to our upstream providers. However, they do not want to BGP peer with us (cost-savings, configuration, etc...). We've received an LOA from them, giving us permission for this, and we've passed it along upstream.

We are happy to do this, but the problem is the advertisement is getting blocked further upstream. The larger transit providers appear to be querying the radb for their prefix lists, which is a problem as the radb has the /24s under the customer AS. So, if we try to advertise the /24s with our AS, they are getting dropped by these larger providers.

We are curious as to what other ISPs are doing in situations like this? Do you ask the customer to SWIP the /24 over to the ISP AS? Does the ISP turn up a BGP instance with the customer AS in order to spoof it (seems non-kosher)? Or something else entirely?

We don't have the IP space available to give them a /24, and the customer does not want any type of BGP relationship.

Appreciate any response.

  • Josh
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer.
    – Ron Maupin
    Jan 7, 2021 at 1:11

4 Answers 4


As waza-ari pointed out, AS Prepend will do the trick. As to whether it's what other ISPs do, I cannot answer that question unfortunately.

I labbed up your AS prepend query using the topology below:

enter image description here

AS Prepend Example:

  • R1 is advertising through BGP.
  • It is prepending 123, 123, 123 to the route.
  • The below output was taken from R2:

R2(config-router)#do sh ip bgp BGP table version is 4, local router ID is Status codes: s suppressed, d damped, h history, * valid, best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 0 0 100 123 123 123 i

So here we see the prepended AS of 123 is shown as the originator of the route.

Three Router Example:

To confirm that the AS entries are read from right to left, take a look at this example.

  • The below output was taken from R3.
  • Note that reading the AS path from right to left we see that AS100 is the originator of the route.

R3#sh ip bgp BGP table version is 2, local router ID is Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 0 200 100 i

  • 1
    @Josh: please accept the answer if it does resolve your question.
    – Daniel
    Aug 2, 2016 at 12:19
  • 1
    This answer is incorrect and terribly misleading. There is absolutely no need to use AS_PATH prepending to solve the requirement in this question. There's no benefit from doing it. Aug 18, 2020 at 11:52
  • @JeffWheeler, can you please share the ways in which this answer is incorrect or misleading? For those of us who do not understand the subject matter, it would be helpful if you could impart some knowledge or wisdom. Dec 3, 2020 at 17:18
  • The OP hadn't informed their transit provider(s) of new announcement(s). They need to inform those providers. AS_PATH prepending isn't a magic skeleton key to sneak routes through upstream prefix-list filters. Dec 3, 2020 at 17:24

Your Org can create a RADB entry for your customer prefix (since LOA is given, that should be mentioned in the "remarks" column of RADB) under your maintainer object. When your ISPs query RADB now, they will find a match of the prefix against your ASN and allow the prefix.


An RADB entry with one of the IRRs should reflect the actual routing policy in-use. These policies are important used to enforce filtering that keeps others from announcing your routes (accidentally or maliciously). Your (customer's) routing policy differs from its registration. Your customer should probably fix that.

You could also try to make your routing appear to reflect already in place policy, as some others have suggested. Whether that's appropriate is left for you to decide.

  • 2
    RADB is one of the many routing registries available, please consider adding some details why updating a/this specific routing registry is relevant.
    – Teun Vink
    Aug 27, 2016 at 21:29

Technically you could simply use AS-Path prepending, als described for example here. This allows you to prepend the customers AS without the need to fire up another BGP instance.

The moral part of the question is to be answered by you. Except for transferring the prefix I do not see another method other than inserting the customers AS in any way.

  • Hey waza-ari. Thanks for the response. Wouldn't the origin AS remain ours though? i.e. lets say the customer AS is 65000, and our AS is 65001. If we prepend the customer AS, wouldn't the path look like "65000 65001". The customer AS would be in the BGP Path, but not the origin AS. Or do upstream providers simply care about the customer AS being in the path somewhere, and it doesn't necessarily have to be the origin? Thanks again! - Josh
    – Josh
    Jul 1, 2016 at 15:46
  • 1
    Sorry Josh I did not answer you before, I was on holiday and promised not to enable the smartphone at all :) Actually there is no attribute called origin AS as far as I remember. Hence the originating AS is fetched from the AS path attribute which is sent as attribute of the prefix. There is an origin attribute though, which however only indicates the original source of the route (IGP, EGP or incomplete) and does not include the originating AS. As OzNetNerd pointed out, it should be working. Prepending inserts the AS before your AS is appended, hence "prepending".
    – Daniel
    Aug 2, 2016 at 12:16
  • 1
    This answer is also incorrect. AS_PATH prepending is not needed or helpful for announcing a customer's subnet from your (ISP) network. Aug 18, 2020 at 11:56
  • @JeffWheeler instead of complaining about all the answers (which might or might not be appropriate), how about enlightening us with your wisdom and provide the correct answer?
    – Daniel
    Nov 7, 2020 at 16:51
  • 1
    @user3629081 that's because you don't understand how transit networks filter BGP routes from their customers. They do that using prefix-lists (or on Junos, conceptually-similar route-filters may be used.) @Shaunak references IRR database objects which are used by providers' automation tools to generate such prefix-lists. Dec 3, 2020 at 17:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.