Provider rejecting routes due to "AS-PATH contains our own AS"

Unanswered Question
Jun 30th, 2009

I am having an issue with the following setup in a lab (soon to be deployed).

Site A and Site B are running in different AS's peering with the same provider. Site B is a backup for site A prefixes by means of AS-path-prepending route-maps.

When A goes down, site B should become become the preferred route to site A prefixes (site A and B are connected internally via a seperate link running OSPF).

I originally had this working and the routers I am using to simulate the provider would show routes to the site A prefix, both through site A and site B.

Since making a number of changes (over a period of months), I am receiving the following in a "debug ip bgp updates" on the carrier router:

"DENIED due to: AS-PATH contains our own AS"

The AS path indicates this is because:

* Site A advertises 10.1.0.0/24 to the provider

* The provider advertises 10.1.0.0/24 to site B

* Site B then advertises 10.1.0.0/24 to the provider (as it is the backup for Site A)

* The provider rejects the route as it seems the AS-path as "SiteA --> Provider --> Site B --> Provider

Site B is advertising the 10.1.0.0/24 prefix it is learning via BGP instead of the prefix it is learning via OSPF and hence has the original AS-path in it, resulting in the provider rejecting it.

I could request the provider to enable "allowas-in" but feel there must be a better way. All of the other options I have looked at involve provider-side changes when using MPLS-VPNs etc. I would like to have Site B advertise the routes from OSPF and not BGP or otherwise have Site B strip the ASs when it advertises the prefix.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Richard Burts Wed, 07/01/2009 - 00:06

Scott

Part of what you are doing puzzles me. If site B is to be a backup for routes from site A, and if site B and site A are connected by OSPF internally, then it would seem to me that both site A and site B should be in the same AS. Why is site B using a different AS than site A?

HTH

Rick

scott.stapleton Wed, 07/01/2009 - 00:45

That originally was my design but I actually changed it as I had this same problem when site B received the prefix from site A (site B would reject it due to seeing it's own AS in the as-path. The advantage of doing it this way (single AS across all sites) would be that I would have control and could implement the "allowas-in" on site B. However as mentioned, I feel I must be missing something.

Richard Burts Wed, 07/01/2009 - 06:30

Scott

I still do not understand. If site A and site B are connected by a link running OSPF then why does site B not learn the site A routes via OSPF? Why do you want site B to learn site A routes via BGP from the provider?

It also seems to me that if site B is the backup for the site A routes and if site A is up and advertising the route (as seems to be the case in your original post) then why do you care if the advertisement of the route from site B is rejected? If the primary is available and advertising, then why do you want the backup to be advertising also? It only matters if site B can advertise that route when site A is down. It does not look like a problem to me if the site B advertisement is rejected while site A is still up (in fact I think it is a desirable behavior).

HTH

Rick

scott.stapleton Wed, 07/01/2009 - 19:07

When the BGP (external) and OSPF (internal) links up are, traffic from A-->B and B-->A travel over the OSPF link (inter-site traffic). The only traffic travelling over the BGP link is traffic bound for the head office / Internet.

So to answer the first question above, "why does site B not learn the site A routes via OSPF" - it does and prefers them based on the AD (I have all the routes learnt via BGP given an AD of 250 so the internal OSPF routes are preferred, apart from the default route).

"Why do you want site B to learn site A routes via BGP from the provider?" - So that if the OSPF link goes down, all traffic travels over the BGP link.

I was actually thinking about what you mention if your last paragraph after my last reply but I am yet to test. I am unsure how quickly the provider would learn the routes after Site A goes down but will see. The reason I posted though was because I had the provider router having learn both routes originally but with different AS-path lengths due to AS-path pre-pending. So my assumption was not I must be missing something now that this is not working.

Thanks for the response Rick.

Jon Marshall Wed, 07/01/2009 - 10:15

Scott

In addition to Rick's points.

In normal operation ie. both sites are up, do you want traffic from site A to B and B to A to go via the BGP connection or via the OPSF connection. This has a big impact on how you configure it.

By the way, using the same AS and allowas-in would be my choice but you still need to answer first question as i have done this type of thing before and you may need to manipulate weights etc. to influence which way A -> B, B -> A goes.

Jon

scott.stapleton Wed, 07/01/2009 - 19:53

I just typed out a response but lost it after attempting to Post. I was reiterating what I said above - inter-site traffic goes over the OSPF link and Internet / head-office-bound traffic goes over the BGP link. If either link fails, all traffic obviously takes the working link.

Giuseppe Larosa Wed, 07/01/2009 - 11:08

Hello Scott,

>> Site B is advertising the 10.1.0.0/24 prefix it is learning via BGP instead of the prefix it is learning via OSPF and hence has the original AS-path in it, resulting in the provider rejecting it.

Have you got a network command for net 10.1.0.0 like

network 10.1.0.0 mask 255.255.255.0

no auto-summary

or redistribute ospf x

under router bgp

on Router B?

if so the locally originated route should be the best for the weight 32,768 and next-hop 0.0.0.0

if using redistribution og OSPF into BGP what kind of OSPF route is 10.1.0.0/24 ?

What is the IP next hop for net 10.1.0.0/24 on routerB?

is it reachable , can it pass the BGP next-hop reachability test ?

I think these are the checks that should be done because we see that a basic behaviour is not happening.

There is no sense in asking the provider to accept the advertisement originated by router A and sent by RB: this cannot be a backup route if routerA fails the route will disappear and also RB will stop to advertise it.

Hope to help

Giuseppe

scott.stapleton Wed, 07/01/2009 - 22:58

Your mention of weight has put me on the right track and the issue appears to be my manipulation of outgoing routes utilising the weight attribute. I will post a more thorough update soon, after some more testing. Thankyou muchly.

Actions

This Discussion