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 · Accepted solution]

Hi,

you are right in that this should be working at least in "normal" IPv4. I am not sure about VRF though. You could setup BGP peering under address-family IPv4 for testing purposes (whether the feature is working at all in your IOS).

Besides that you can modify your config to get things working for your setup like this:

router bgp 19262

no synchronization

bgp log-neighbor-changes

no auto-summary

!

address-family ipv4 vrf CUSTOMER

neighbor 192.168.10.2 remote-as 65000

neighbor 192.168.10.2 activate

neighbor 192.168.10.2 as-override

neighbor 192.168.10.2 soft-reconfiguration inbound

neighbor 192.168.20.2 remote-as 65000

neighbor 192.168.20.2 activate

neighbor 192.168.20.2 as-override

neighbor 192.168.20.2 soft-reconfiguration inbound

no synchronization

exit-address-family

The "as-override" feature will replace the CE peer AS with the PE AS. By the way, the "allow as in" is not needed in your setup. It would allow the PE to accept AS pathes with the PE AS in it, which is not the case with your setup.

Hope this helps! Please rate all posts.

Regards, Martin

[Edison Ortiz]

The AS PATH is having both public and private AS numbers when you issued these commands

ip vrf CUSTOMER

rd 19262:65000

route-target export 19262:65000

route-target import 19262:65000

address-family ipv4 vrf CUSTOMER

That's one of the rules when using the remove-private-as community string.

"If the autonomous system path includes both private and public autonomous system numbers, the software considers this to be a configuration error and does not remove the private autonomous system numbers."

From http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_command_reference_chapter09186a00801a80a3.html#wp1099351

Please rate helpful posts.

Thanks

[mheusinger]

Hi Edison,

I would assume in the PE (1841) the AS path has only a private AS (65000), as learned from the CE. So in principle the feature should work, IF it is supported for VRFs. The "19262:65000" in the above VRF config are either route distinguisher or route target and as such not part of the AS path section of the BGP update.

Regards, Martin

[Edison Ortiz]

Hi Martin, based on the diagram he posted, it seems the 1841 is the router in the middle so updates going to each side will contain the public AS 19262 along with the private AS 65000.

However, you are right, the VRF is not the culprit here. It's just one of the restrictions of using remove-private-as.

[mheusinger]

Hi Edison,

this is true, but in principle is the typical ISP setup (customer with private AS and ISP with official one). So within the ISP network the AS path contains only private AS (iBGP updates). Only when the update is sent on to other ISPs the path will have the official AS added. But exactly at this point the "remove-private-as" should kick in and remove private AS numbers, so that the internet will only "see" official ASes. Otherwise I can not imagine any situation, where the feature could potentially work at all or add anything useful.

Regards, Martin

[Edison Ortiz]

It should kick in and remote the private AS number only if a public AS number is not part of the AS_PATH, per the article I posted.

Let's not forget the error OP is actually getting:

"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"

[mheusinger]

Hi,

yes this is the message he gets (it is not an error, but normal BGP AS path processing). But this is from the CE routers, prooving, that remove-private-as does not do, what should (?) be done.

Regards, Martin

P.S.: quite enjoyable discussion :-)

[Edison Ortiz]

Exactly, remove-private-as is not doing what it should, due to the configuration error per my original post.

Agreed on the enjoyable discussion bit :)

[mheusinger]

Hi Edison,

this is true, but in principle is the typical ISP setup (customer with private AS and ISP with official one). So within the ISP network the AS path contains only private AS (iBGP updates). Only when the update is sent on to other ISPs the path will have the official AS added. But exactly at this point the "remove-private-as" should kick in and remove private AS numbers, so that the internet will only "see" official ASes. Otherwise I can not imagine any situation, where the feature could potentially work at all or add anything useful.

Regards, Martin

[mheusinger]

Writing the above (sorry for the double post), it could be that the remote AS is checked being private and then private AS kept in the path. But I do not know of such a restriction (I know, RTFM could help, but I am somewhat busy besides NetPro ;-) Do you know of such a restriction, or even can point to documentation?

Wouldn?t find it so useful either, if it would be implemented this way.

Regards, Martin

[Edison Ortiz]

I posted on my initial post

"If the autonomous system path includes both private and public autonomous system numbers, the software considers this to be a configuration error and does not remove the private autonomous system numbers."

From http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_command_reference_chapter09186a00801a80a3.html#wp1099351

[mheusinger]

As I wrote, RTFM helps:

"If the autonomous system path contains the autonomous system number of the eBGP neighbor, the private autonomous system numbers will not be removed."

From your link. This is the reason, why. And thinking about it, it makes a lot of sense to implement it this way, to avoid possible routing loops!

So for the original post: AS-override will solve your issue, other than that: it works as designed :-)

Regards, Martin

Edit: changing one of the AS 65000 to another private AS would allow the feature to do its job, though it would not really be required in that case.

Edit2: It is not a bug, but a feature ... case closed ;-)

[cajalat]

ok...I was reading too quickly....AS-OVERRIDE worked :) Thank you very much.

[cajalat]

Very interesting discussion indeed :)

OK, first off, the reason why I want to do this is to mimic an MPLS/VPN environment where the PE (the 1841) is the provider router/cloud while the 2651XM and 1605R are the CE devices. So what I want to do is pass the networks learned from the CE's to each other. That's really my goal. I read somewhere that there was a bug in the REMOVE-PRIVATE-AS where it didn't work so I upgraded to the latest 12.4T code in hopes that it would resolve my problem but as noted it didn't.

Also, the setup using VRF is the most recent I did. I also did this without the VRF (just straight BGP sessions) and that too didn't change anything.

So I guess my question is, how do I NOT announce from the 1841 the Private AS to the CE's (1605R and 2651XM) if this config is considered a design error.