BGP AS-PATH manipulation question

Unanswered Question
Jan 17th, 2008

Is there a way, other than prepending to the AS-PATH, to alter the AS-PATH? For example, if I was advertising an AS-PATH of 500 5 but I wanted to advertise it as 500 500, how can I do that?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
marikakis Thu, 01/17/2008 - 11:52

Hello,

Regarding your first question:

According to the BGP command documentation there is a way. You still set as-path in route-map configuration mode similar to the prepend, but instead of specifying the keyword prepend you specify the keyword tag. However, you will need some redistribution acrobatics. For more information and an example, please take a look at the following URL:

http://www.cisco.com/en/US/products/ps6566/products_command_reference_chapter09186a008079e0fd.html#wp1048455

Another somewhat specific case that might not interest you is for a receiver to remove private AS numbers from the AS path:

http://www.cisco.com/en/US/products/ps6566/products_command_reference_chapter09186a008079e0f6.html#wp1026277

Regarding your second question:

In a path written in the form 500 5, the originating AS is 500 and peers with AS 5. You cannot control this unless you are in control of the AS 5 router (I mean you cannot force the upstream of AS 500 to say they are somebody else, unless they are willing to do so). For such a purpose, local-as feature can be used:

http://www.cisco.com/en/US/products/ps6566/products_command_reference_chapter09186a008079e0f6.html#wp1024930

http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a00800949cd.shtml

Now that I written all this, I think you would be more interested in the local-as feature. :-) So, we have various ways to alter the AS path. Which one you use depends on what you want to do.

Hope this helps,

M.

jcmartin Thu, 01/17/2008 - 12:33

What I'm trying to do is mimic what is happening in BGP on a provider MPLS network, without the MPLS gear. In the provider network, the CE routers are all in, for example, BGP AS5. They all peer with the provider in BGP AS500. They can all see each other, because somewhere in the MPLS network, probably in the PE routers, the provider is stripping the AS5 from the AS-PATH, and readvertising is as coming from AS500. To try to duplicate a different problem we're having, I need to replicate this scenario. Unfortunately, local-as won't allow you to use the same AS that is on the router. I tried reconfiguring so that the hubs were on a private AS and use the remove-private-as statement, but this isn't working the way I'd expect either. I'm not sure how the set as-path tag command works, as the examples don't really show a before and after, what the tag consists from or where it comes from, etc.

marikakis Thu, 01/17/2008 - 13:10

When AS Override is configured on a PE, the PE replaces occurences of the connecting CE's AS number with its own AS before sending updates to another CE to avoid AS_PATH loops and denial of prefixes on other CE's. Have you tried something like that?

Hope this helps,

M.

jcmartin Thu, 01/17/2008 - 13:12

I don't have MPLS in my lab, and AS Override is only available with MPLS. So, no, I guess I haven't tried it, just read about it.

marikakis Thu, 01/17/2008 - 13:28

Hello,

Ok, I try to think of something that might simplify things, since this is a lab test. Have you tried to use private AS numbers in the lab routers that mimic the CE's, so that you can use the remove-private-as on the router that mimics the PE?

Kind Regards,

M.

jcmartin Thu, 01/17/2008 - 13:30

Thanks for all your help!

Yes, I did try that, several steps ago. What I found odd was that before this, if I did a debug bgp on the edge router, I could see it rejecting the routes of the other edge routers because it had its own AS in the path. With the remove-private-as option, I no longer see these errors, but the routes are still not getting to the edge routers.

marikakis Thu, 01/17/2008 - 13:43

Do not thank me, I really find this interesting!

Ok, have you tried to use different AS numbers on each CE? Perhaps the router that mimics the PE is playing it smart.;-) I mean, this router knows the AS where the routes came from and does not send them back to the same AS.

Kind Regards,

M.

jcmartin Thu, 01/17/2008 - 13:45

I haven't done that because it doesn't reflect what I have on my customer's network. Didn't see the point. I did try to use the local-as option, even though it can't be used on the same AS, but kept getting AS mismatch errors.

marikakis Thu, 01/17/2008 - 13:55

Ok, have you tried to use 2 routers to mimic the backbone? I mean, use another router as a PE to allow the routes to pass through. The second router I believe will have lost the information about the original path.

Kind Regards,

M.

jcmartin Thu, 01/17/2008 - 13:57

I haven't tried that. I'll have to look at the design of the lab. I have the physical restriction that the lab is about 1000 miles or so away, so I don't have the luxury of being able to move things around...

marikakis Thu, 01/17/2008 - 14:11

I understand that, but every feature I can think of right now assumes there are a couple of routers around. Can't think of anything else right now. Sorry!

Kind Regards,

M.

marikakis Thu, 01/17/2008 - 14:29

I begin to think of redistribution, which shows despair since I really don't like it. :-) You could run OSPF on the PE, with some participating loopbacks perhaps, and redistribute BGP routes received from one CE into OSPF. Then, redistribute OSPF into BGP and see what happens. Perhaps this is stupid and router outsmarts me. I don't know. This in combination with the remove-private-as.

Kind Regards,

M.

marikakis Thu, 01/17/2008 - 14:40

By the way, I have one comment regarding a previous post of yours, regarding the customer topology. Perhaps using different AS numbers doesn't reflect the customer topology, but it could be helpful to make such a simplification. Unless you have an issue that closely relates to having the same AS numbers. We could assume that the provider does its work, unless what we are trying to prove is that it doesn't.

Kind Regards,

M.

jcmartin Thu, 01/17/2008 - 17:12

I really appreciate all the thought you're putting into this. Like you, I like a good challenge, but I really need to come up with some sort of answer fairly soon, since a customer network is relying on it.

As for your last suggestion about redistributing, I might give that a try next week. Had to give up the lab to someone else who needed it (I've been hogging it with this problem), but get it back Monday.

I do suspect that it has something to do with the way the AS's are set up, but it's a bit more complex than the part I'm working out now, as there are actually two providers and multiple connections between them (which is also the reason I don't have any extra routers in the lab).

I'm also going to check to see if I can put together some sort of MPLS structure on the switches. Not sure if they can handle it, but the commands indicate references to VRFs, so what the heck, I'll try something else new.

marikakis Fri, 01/18/2008 - 10:10

Hello,

I am posting to correct something wrong I said in my first post. It is not particularly useful to solve this case, but wouldn't want to confuse anybody.

In a path written in the form 500 5, the originating AS is on the right (i.e. 5) and not on the left (i.e. 500).

It is hard to reproduce issues in a lab environment. Hope you manage to do it. If you have some time, please tell us if you managed to make this network setup simulation actually work.

Kind Regards,

M.

jcmartin Fri, 01/18/2008 - 10:45

That's what I thought, but didn't want to argue about it in public. I knew what you were getting at, though.

I will definitely keep you posted. As I said, I'm working with a shared lab, and had to give it up for the duration of the weekend, but should be back at it either Monday or Tuesday.

Thanks Maria.

marikakis Fri, 01/18/2008 - 12:38

Hello,

I was pretty sure you spotted that, because it is obvious you know a lot of things. :-)

I do not feel very proud when I make mistakes either in public or in private, but I wouldn't be embarrassed if you had corrected me. Most people that usually answer questions in this forum keep posting because they learn things during the process. There is no guarantee for the correctness of the answers, but people try their best.

I will be away for the Networkers event the following week, but I will definitely come back to see what happened here.

Kind Regards,

M.

jcmartin Mon, 01/21/2008 - 12:18

Okay, I did figure it out, but it required setting up a rudimentary MPLS configuration on the switch. The goal was to have a switch in one BGP AS (in this case 400), and the connected routers (in this case 3 of them) in a single but different BGP AS (in this case 65004), and to have all connected routers receive all routes in their AS with no other connections. The configuration on the routers was basic BGP:

R1

interface Loopback1

ip address 10.4.11.1 255.255.255.0

!

interface Loopback2

ip address 10.4.12.1 255.255.255.0

!

interface Ethernet0/0

ip address 192.168.41.2 255.255.255.0

half-duplex

.

.

.

router bgp 65004

no synchronization

bgp log-neighbor-changes

redistribute eigrp 10

neighbor 192.168.41.1 remote-as 400

no auto-summary

etc...

R2 and R3 are the same.

The configuration for the switch was a bit more complex, not just with the addition of MPLS, but also with what that added to the BGP configuration.

Sw1

.

.

.

ip vrf MPLS4

rd 400:4

route-target export 400:4

route-target import 400:4

.

.

.

interface FastEthernet0/1

no switchport

ip vrf forwarding MPLS4

ip address 192.168.41.1 255.255.255.0

!

interface FastEthernet0/2

no switchport

ip vrf forwarding MPLS4

ip address 192.168.42.1 255.255.255.0

.

.

.

interface FastEthernet0/5

no switchport

ip vrf forwarding MPLS4

ip address 192.168.45.1 255.255.255.0

.

.

.

router bgp 400

no synchronization

bgp router-id 192.168.41.1

bgp log-neighbor-changes

neighbor 192.168.41.2 remote-as 65004

neighbor 192.168.42.2 remote-as 65004

neighbor 192.168.45.2 remote-as 65004

no auto-summary

!

address-family ipv4 vrf MPLS4

neighbor 192.168.41.2 remote-as 65004

neighbor 192.168.41.2 activate

neighbor 192.168.41.2 next-hop-self

neighbor 192.168.41.2 as-override

neighbor 192.168.42.2 remote-as 65004

neighbor 192.168.42.2 activate

neighbor 192.168.42.2 next-hop-self

neighbor 192.168.42.2 as-override

neighbor 192.168.45.2 remote-as 65004

neighbor 192.168.45.2 activate

neighbor 192.168.45.2 next-hop-self

neighbor 192.168.45.2 as-override

no synchronization

network 192.168.41.0

network 192.168.42.0

network 192.168.45.0

exit-address-family

.

.

.

Yes, the neighbor statement has to be in their twice, not sure why, but I tried removing it in both places and it only seemed to work if it was in both. With the MPLS configured, the AS-OVERRIDE option then removes the local AS from the AS-PATH. This is not an available option without MPLS configured.

Thanks to everyone for all the help in getting to this point!

Danilo Dy Thu, 01/17/2008 - 18:37

Hi,

I have a setup that able to advertise two AS in one router using route-map as below (I use your ASN as a sample and only show what could be useful for you).

!

router bgp 500

-output omitted-

network 192.168.160.0 mask 255.255.240.0

network 192.169.160.0 mask 255.255.240.0

neighbor upstream_ip_address route-map ADVERTISE-OUT out

!

access-list 1 permit 192.168.160.0 0.0.15.255

access-list 2 permit 192.169.160.0 0.0.15.255

!

route-map ADVERTISE-OUT permit 1

match ip address 1

!

route-map ADVERTISE-OUT permit 2

match ip address 2

set as-path prepend 5

!

end

With the above config, the upstream AS will see its neighbor as ASN500 (192.168.160.0/20) and behind ASN500 is ASN5 (192.169.160.0/20).

Now, to mimic the 500 500, I don't have the privilege to try this (as I don't have a lab) but see if it works if you replace the prepend in the route-map from 5 to 500? Therotically it may not work since the configured local AS is 500.

Regards,

Dandy

Actions

This Discussion