Can't remove Private AS from announcements

[cajalat]

I'm trying to remove a private AS from being announced to a peer but I'm unable to. I'm using hte REMOVE-PRIVATE-AS but it doesn't seem to have any effect.

Here's my setup:

1605R <----> 1841 <----> 2651XM

AS65000 AS19262 AS65000

There are no connections between the 1605R and the 2651XM other than through the 1841 router. Both the 1605R and the 2651XM have something like this in their logs:

*Mar 5 02:54:32.473: BGP(0): 192.168.10.1 rcv UPDATE w/ attr: nexthop 192.168.10.1, origin ?, originator 0.0.0.0, path 19262 65000, community , extended community

*Mar 5 02:54:32.473: BGP(0): 192.168.10.1 rcv UPDATE about 192.168.20.0/30 -- DENIED due to: AS-PATH contains our own AS;

I've looked at previous posts to this forum and it seems the REMOVE-PRIVATE-AS is supposed to work but it isn't in my case as you can see from the log message.

Attached are the configs (these are in a lab mimicing production where the equivelent of the 1841 is not within my control):

These configs are not cleaned up and my initial goal is to NOT announce the 65000 to either the 1605R or the 2651XM. Thanks for any help.

[mheusinger]

Hi,

as I wrote, "as-override" is designed exactly for this scenario and will give you connectivity. Just try the config from my first post. The PE will override the CE AS (65000) in the path with the official AS. The pathes in the CE routers will then contain the official AS twice, but this does not interfere with CE BGP path processing - it is still acceptable.

Hope this helps! Please rate all posts.

Regards, Martin

[ilya.varlashkin]

You config is not design error, it's commonplace in MPLS environment.

If you want to mimic MPLS VPN, be aware that this is quite common in MPLS environment to announce private AS as well as it's normal to have discontigious AS (e.g. AS65001-AS100-AS65001). According to standard BGP rules AS65001 will not accept announces if they already contain AS65001 somewhere in the path. But there are two solutions to this:

1) as was already mentioned 'as-override' - this will replace occurence of peer AS in the path with the one of local system.

2) alternatively, each of AS65001 routers can be instructed to 'allowas-in', which will result in AS65001 accepting advertisements that already contain AS65001 in the AS_PATH

Later approach (allowas-in) is a bit more powerful (you can specify how many times own AS can occur in the AS_PATH to be accepted), but for most typical MPLS solutions as-override is good enough.

With both of these solutions it's quite common to use special extended community called 'soo' (Site-of-origin), which helps to avoid routing loop that may arise since you break basic BGP loop prevention mechanism.

[AJAZ NAWAZ]

It is becoming increasingly common place for CE routers to be managed by customers themselves. So they have no say on PE router configuration. Circuits get sold with a standard set-up and this can leave the cust with this exact problem. Then the cust has to either request as# change ($$$) which is normally supplied by provider, or they have to come up with another solution themselves.

The good thing about allowas-in, is that it provides the cust CE the ability to take away the inbuilt BGP loop prevention mechanism if they so wish. Whereas as-override is applied on PE and something outside of the cust jurisdiction.

The question is what is it that you cannot acheive with BGP. It's almost like cheating :-)

Ajaz