4

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 could provide and accept your own answer. – Ron Maupin Aug 14 '17 at 18:27
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 192.168.1.0/24 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 10.0.0.2 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

*> 192.168.1.0 10.0.0.1 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 10.2.3.3 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

*> 192.168.1.0/24 10.2.3.2 0 200 100 i

  • 1
    @Josh: please accept the answer if it does resolve your question. – waza-ari Aug 2 '16 at 12:19
0

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 '16 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". – waza-ari Aug 2 '16 at 12:16
0

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 '16 at 21:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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