How to configure BGP AS Path Prepending

Thank you Lazaros, this is very helpful.

1 Like

Hi guys,

I configure AS prepend in R2 and R3 to advertise the prefix &
From R7, the sh ip bgp output shows the prefixes are prepended. However from R6, the sh ip bgp output shows both prefixes have equal AS-Path.

Is this normal behavior? Somehow the AS-Path prepend info from R7 is not passed forward to the other routers.

Adding on, if R2 or R3 is down, traffic is able to forward successfully. I believe my configurations are valid but I want to know why R6 is not getting the prepend info

Hello Saifundin

That’s strange, because AS prepending should be propogated to other AS’s downstream. I suggest you take a look at the following in order to continue your troubleshooting:

  1. Examine the AS paths associated with each of the prefixes and in R7, R5, and R4 as well and see from which router on the AS’s are removed.
  2. Check to ensure that the two prefixes are not being summarized in one of the downstream routers
  3. Ensure that there are no other route maps or other configurations in R7 or other routers that will affect the prepended AS’s

I believe that if you see where the prepended AS’s are removed (that is, at which router, R7, R4, R5) it will give you a better clue about where the problem lies. Let us know how you get on with your troubleshooting.

I hope this has been helpful!


Hi Rene,

In this lesson, we’re in charge of both As’s, in the real world we’re only in charge of our own AS, how to include inbound traffic like AS path prepending if I’m only in charge of one AS

Hello Walter

Yes you are correct, in the real world you only have control over your own network. As such, you have ultimate control over your outbound traffic, but you do not have ultimate control over your inbound traffic. However, as you can see from this example, it is possible to try to influence incoming traffic.

If you are admin of AS1, then you can cause the BGP routing of AS2 to prefer one path over another. Of course, the admins of AS2 are able to override such attempts by making the appropriate adjustments on their end. Remember, they have ultimate control over their outbound traffic too.

If you come up to such a scenario at your interface with another network, such as your ISP, it is always best to discuss what you would like to do before you implement it. Any attempt to influence their traffic may be considered hostile or inappropriate. Always discuss your intentions before applying any such BGP implementations.

More info about this can be found at this post:

I hope this has been helpful!


thanks Laz, you’re a great teacher:)

1 Like

Thanks so much, Walter! I appreciate your kind words! I do my best :blush: .


I love this website is so useful, I have interview for Verizon this Thursday I hope I will pass:) ,
This website will help so much for everyday work there !

Hello Metodija

We’re so happy you enjoy the site and find it useful! I hope your interview went well!

Have a great one!


1 Like

Interview went excellent, i think i will get positive feedback next week :slightly_smiling_face:

1 Like

How can we do the AS prepending job dynamically based on SLA criteria’s like latency and jitter?
Is it possible to install prepending routes dynamically? A detailed solution is appreciated.

Hello Sachin

AS prepending is done using a route map, and any match statements can be used to determine if pretending will take place. Route maps can use tracking objects to match, so it is possible to set up an IP SLA and have its tracking object be a condition for the AS path pretending.

In the AS path prepending lesson, the route map and related configuration that was used to apply the prepending is the following:

R1(config)#route-map PREPEND permit 10
R1(config-route-map)#set as-path prepend 1 1 1 1 1
R1(config)#router bgp 1
R1(config-router)#neighbor route-map PREPEND out

You can modify this by adding a match statement that will match a tracking object like so:

R1(config)#route-map PREPEND permit 10
R1(config-route-map)#match  track 1
R1(config-route-map)#set as-path prepend 1 1 1 1 1
R1(config)#router bgp 1
R1(config-router)#neighbor route-map PREPEND out

The above first matches the tracking object 1, and only if that is matched will the prepending take place. Now the tracking object can reference an IP SLA that you can create based on your requirements. To see how IP SLAs are created, take a look at this lesson:

To see how IP SLAs can be associated with a tracking object, take a look at this lesson, which includes an example of tracking objects:

Now practically speaking, it may not be a good idea to configure such a scenario. IP SLAs that measure latency and jitter may have very frequent changes, on the order of several changes per second. BGP routing, on the other hand, is designed for very slow convergence on the order of dozens of seconds or even minutes to achieve stability. A route map that adds and removes AS prepending at such a high frequency can cause extreme instability to a BGP topology. Such a scenario should be implemented with care.

I hope this has been helpful!


@mr lagapides and the rest!
χρονια πολλα καλη χρονια!

why i don’t get the 1 1 1 1 1 prepend path on show ip bgp?

Hello Konstantinos!

Χρόνια πολλά και ευλογημένα! Με υγεία!

In this particular case, you are applying the prepending in an outward direction on the local router. That means that AS Path prepending will be applied on all routes the local router sends out to its neighbors. This doesn’t affect the local BGP table, but it will affect the BGP table of its neighbor.

Take a look at the lesson topology once again:

In the lesson, you will notice that the prepending is applied on R1 in an outbound direction. So the route to will be sent from R1 to its BGP neighbor R2 with the prepending applied as the BGP update is sent outward. R2 will receive this and add it to its BGP table.

In order to reproduce this in your topology, you must apply the prepending on the neighbor router in an outbound direction, and not on the local router as you have.

Remember, you can always apply the route map in an inward direction as well, and in this case, you can apply it to the local router. Take a look at this NetworkLessons note about how the direction of the applied route map affects BGP messages.

I hope this has been helpful!


Hello, everyone!

When manipulating how traffic enters our network, we have the option of using MED and AS Path Prepending.

Are there any scenarios where we might want to use MED over AS PP? Since AS PP seems much better in my opinion, because it’s propagated across the other autonomous systems while the MED attribute is only valid for the neighboring ASes therefore if we had a multi-homed connection, MED would be of no use.

Also, what’s the design reason behind MED being only sent to neighbors but not to further ASes?

Kind regards,

Hello David

Which attribute you will use depends on your situation as well as the capabilities and configurations of your neighboring AS. Let’s take a look at each option:

MED is an optional, non-transitive BGP attribute that suggests to external neighbors the preferred path into your AS. A lower MED value is preferred over a higher one. The MED attribute can be very effective, but it’s not always the best solution because its interpretation can vary depending on the BGP configurations on neighboring AS. Moreover, the MED is not always transmitted through multiple ASes, making it less effective in scenarios where you are trying to influence routing decisions several hops away.

AS Path Prepending involves adding additional instances of your own AS number to the AS path of certain routes. This makes the path seem longer, so it is less likely to be chosen by BGP, which prefers shorter paths. AS Path Prepending is a more aggressive way to influence inbound traffic because it will be seen by all BGP routers that receive your announcements, not just your immediate neighbors.

However, the best approach is to talk with the administrators of your neighboring AS (i.e. your ISP) before configuring any BGP attributes that influence incoming traffic. Make sure that what you have configured is acceptable on their end as well. You may find that one or the other option may be frowned upon and may be considered aggressive by your ISP if not discussed beforehand.

Generally speaking, MED may be a better choice when you’re only dealing with direct peers or neighbors, and you can be sure they’ll honor MED. AS Path Prepending might be more suitable if you want to ensure your changes will be seen throughout the internet, or you’re dealing with networks that ignore MED.

There are other ways to influence incoming traffic using BGP. For more information about this, take a look at this NetworkLessons note on BGP influencing incoming traffic.

Indeed, MED is a non-transitive attribute by design, and there is a reason for this. First of all, MED is often meant to dictate preferences based on factors like link bandwidth or congestion that aren’t necessarily relevant to ASes that are multiple hops away. So the MED attribute is typically used to implement local policy. For example, one might use it to guide traffic toward a cheaper but slower link for certain kinds of non-critical traffic. Since such policies are typically local to an AS or a set of directly connected ASes, it makes sense for MED to be non-transitive.

Conversely, AS Path Prepending is a feature that is inherently transitive because the AS Path attribute provides critical information for routers to make decisions about the best path to a destination based on the number of ASes that must be passed through.

I hope this has been helpful!


1 Like

Hello Laz!

Thank you for your help again, much appreciated!


This is called AS path pretending. → can you correct typo

Hello Akhil

Ha! That’s a funny typo. I’ll let Rene know to make the change. Thanks for pointing that out! :rofl:


That is a funny one and I’m surprised nobody saw it earlier :smile: It’s fixed. Thanks!