Vol 2 Lab 7 Task 2.4 - BGP Best Path Selection - SG guide falls short?
The SG definitely seems to come short. At first they only fix R6 preferring BB1 for AS 54 prefixes not R2. They do fix the "next hop self" issue in a later section enabling R2 to get to BB1 for AS 54 prefixes, but the SG does NOT fix the issue about "customers of 54" being routed to BB3.
Here's what I did to fix it. I used MED on R6 so R2 was still sending all AS54 traffic to BB1 via R6 and the rest of the traffic(customers of AS54) are forced to go to BB3!
It met all objectives of the question what do you think?
o In order to more evenly distribute the traffic load configure your
network so that all traffic from AS 100 destined for prefixes
originated in AS 54 transits the link to BB1.
o In addition to this configure your network so that all traffic from AS
100 destined for prefixes that are from thecustomers of AS 54 is
sent out towards BB3.
o In the case that the link to BB1 is down traffic for prefixes that have
been originated inside AS 54 should still be able to be rerouted to
BB3.
o All of this configuration should be done on R6.
4 Points
R6
conf t
ip as-path access-list 1 permit _54$
route-map bb1 permit 10
match as-path 1
set local-preference 200
route-map bb1 permit 20
!
route-map bb3 permit 10
match as-path 1
route-map bb3 permit 20
set local-preference 500
!
route-map r2 permit 10
match as-path 1
route-map r2 permit 20
set metric 400
!
router bgp 100
neighbor 204.12.21.2 next-hop-self
neighbor 54.21.7.254 route-map bb1 in
neighbor 204.12.21.254 route-map bb3 in
neighbor 204.12.21.2 route-map r2 out
!
do wr
end
!
clear ip bgp * s
!
Comments
Hi,
As the route-map named BB3 has been applied in the inbound direction of the interface facing BB3, I believe it works for the second option as well. According to the route-map & AS path access-list, any update that are originated from AS 54 are matched with sequence number 10 & rest of the updates are matched with sequence 20 which tells that the customers of AS 54 will be routed through BB3 because of heighest local-preference i.e. 200. I think we don't need additional configuration in order to prefer the route through BB3.
Hope this helps!
Somni,
You double-posted this.
Here was my response to your other post.
I also gave the config and my thinking of it (Local-Preference vs Metric) in this post: http://ieoc.com/forums/p/12930/225170.aspx#225170
Good Luck!
JoeM and Hari,
The BB3 500 Local Preference on R6 affects traffic that reaches R6 from the rest of AS 100 and is headed for customers of AS 54. Mine is a little bit more of optimization but what I was doing with the MED was actually having it so that traffic that reached R2 and headed for BB3 didn't all have to go through R6 to reach BB3. Before MED R2 would prefer R6 as its path to BB3 and with MED R2 preferred going to BB3 straight. I guess in theory just the next-hop-self would meet the question requirements but in a less than optimal way. Thanks guys.
I understand what you are trying to make happen. But your setup doesn't work. Read my earlier explanation. It has to do with the attribute priorities.
i.e. weight -> local-preference --------> MED
BB3 --> IN to R6 (local preference is set for AS 100) --> R6 back OUT to R2 (your set metric will be superceded by local preference for AS100)
If you really want to stick with your configuration, maybe try also resetting the LOCAL-PREFERENCE OUT to R2. I have not tried that before. But if you can reset the local-preference (going to R2), then the METRIC matters.
Edit: or take a look at the config I had posted in the other thread. It solved this. See the explanation: http://ieoc.com/forums/p/12930/225170.aspx#225170
.
JoeM,
I see your logic and you have a very good point. Strangely enough when I was doing the Lab it actually worked and R2 exited to BB3 instead of being overruled by R6....now I'm wondering how that happened....the results I typed were after I actually verified it to work...I will have to lab this out separately and see how it actually worked....strangely in these labs sometimes you type the SG solution it doesn't work or something that shouldn't otherwise work works....order of operations ...magic you name it..
I can't read your solution its in greek or russian or something.
No, I do not speak Greek or Russian. English and my own dialect of Spanish. Right now I am learning to speak Cisco. [;)]
This cannot work if you have set the next-hop-self on R6. Because R2 will see the higher LOCAL-LEVERAGE for the given prefixes -- and ignore the METRIC. However, R2 will also see that R6 is the next-hop for that increased local-leverage.
Be sure you are clearing BGP immediately after the changes. There is no magic in BGP, just rules and options. ;-)
Here is the solution I gave in the other thread in the LAB 7 sub-forum.
forum >> vol-2 >> Lab 7 >> 2.4 Next-Hop-Self