Hello Metodija
We’re so happy you enjoy the site and find it useful! I hope your interview went well!
Have a great one!
Laz
1 Like
Interview went excellent, i think i will get positive feedback next week 
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-route-map)#exit
R1(config)#router bgp 1
R1(config-router)#neighbor 192.168.12.2 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-route-map)#exit
R1(config)#router bgp 1
R1(config-router)#neighbor 192.168.12.2 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!
Laz
@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 1.1.1.0/24 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!
Laz
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,
David.
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!
Laz
1 Like
Hello Laz!
Thank you for your help again, much appreciated!
David
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! 
Laz
That is a funny one and I’m surprised nobody saw it earlier 
It’s fixed. Thanks!
Hello Rene,
Thanks for your content, it is very useful. I have a doubt about this lesson, I will show you the output.
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 192.168.12.1 0 0 1 1 1 1 i
* i 192.168.13.1 0 100 0 1 i
*>i 4.4.4.0/24 4.4.4.4 0 100 0 i
R2#sh ip bgp 1.1.1.1
BGP routing table entry for 1.1.1.0/24, version 22
Paths: (2 available, best #1, table default)
Flag: 0x820
Advertised to update-groups: (Pending Update Generation)
3 4
Refresh Epoch 1
1 1 1 1
192.168.12.1 from 192.168.12.1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
1
192.168.13.1 (inaccessible) from 3.3.3.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Why is still selecting the route through 192.168.12.1 for the prefix 1.1.1.1? Weight, local preference and originate are the same, so the next tiebreaker should be the AS path length, am I right? the external preference to internal comes after as a tie breaker.
Hello Juan
Indeed, based on this particular output, the path via 192.168.13.1 should have been chosen as the best path. Let’s look at each attribute that is examined:
- The weight is the same, so there is no tie break there.
- The local preference is an interesting one. Because one of the two paths is an internal route (learned from iBGP) and the other is external (learned via eBGP), there is no local preference value set for the external one. This is normal behavior. However, when the time comes to compare these two values in the best path algorithm, the comparison is considered “indeterminate” which is the same as a tie. Another way to look at it, is that BGP assigns the default value to the route that has no local preference (100) resulting in a tie. This is clearly indicated in the output of the
show ip bgp 1.1.1.1command. According to the strict BGP rules, this too should be determined as a tie. - Next we look at the self origination attribute. Since neither route is self-originated, (in such a case we would see 0.0.0.0 as the next hop), we move on.
- The AS path for 192.168.12.1 is longer than that of 192.168.13.1 and thus the latter should be chosen as the best path, but this is not the case. This is indeed unusual.
But I think I figured it out. Note the following in the output of the show ip bgp 1.1.1.1 command:
192.168.13.1 (inaccessible) from 3.3.3.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
It states “inaccessible”. This indicates that the next-hop IP address for this specific route is not reachable from the router’s current routing table. This means that while the router has received an advertisement for this route (in this case, via BGP from another router with IP 3.3.3.3), it cannot find a path to the specified next-hop IP address (192.168.13.1 in your example) based on its current routing information. This typically occurs when eBGP shares the next hop IP address of a router in another AS, but the routers in the local AS don’t know how to get there because they don’t know about the IP address of the router in the remote AS. Since the next hop IP is not reachable, it is no longer considered for the best path. Does that make sense?
The resolution to this problem is to use the Next Hop Self feature.
I hope this has been helpful!
Laz
Thank you Lazarus for the detailed explanation!
I have announced the network 192.168.13.0 within the AS with OSPF and it is working now as expected.
R2#sh bgp
BGP table version is 4, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*>i 1.1.1.0/24 192.168.13.1 0 100 0 1 i
* 192.168.12.1 0 0 1 1 1 1 i
*>i 4.4.4.0/24 4.4.4.4 0 100 0 i
R2#sh ip bgp 1.1.1.1
BGP routing table entry for 1.1.1.0/24, version 4
Paths: (2 available, best #1, table default)
Advertised to update-groups:
8
Refresh Epoch 1
1
192.168.13.1 (metric 3) from 3.3.3.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
1 1 1 1
192.168.12.1 from 192.168.12.1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, external
rx pathid: 0, tx pathid: 0
Thanks again, you are a star!
1 Like