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!

     

  • JoeMJoeM ✭✭✭

    Somni,

    You double-posted this. 

     

    Here was my response to your other post.   

     

    route-map bb3 permit 10 

                 match as-path 1

    route-map bb3 permit 20 

                 set local-preference 500

    Hi Somniferous,

    LOCAL-PREFERENCE cannot be used -- if we are also trying to set a METRIC on those prefixes going to R2.

    This is because LOCAL-PREFERENCE is for everything in the local AS.  It also trumps MED, which then, will not be considered in the Best-Path selection.....

     

    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.

  • JoeMJoeM ✭✭✭

    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.

  • JoeMJoeM ✭✭✭

    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

     

    2)   R2 is routing through R6 to get to BB3?  (task titled "Best-Path Selection")

    After fixing the path to BB1,  R2 is not using the Best-Path (via itself) to BB3 prefixes. 
    It will actually bounce off of R6 (next-hop) because of the
    local-preference being set on R6.  This fix is not a task requirement,
    but there does seem to be a very obvious need after manipulating the
    local-preference.    

    For this to work (while only allowed to make changes on R6), remove the local-preference from BB3 -- and do the following.

        route-map FROM_BB3 permit 10
            match as-path 54
        route-map FROM_BB3 permit 20
            no set local-preference 200
            set weight 777
    <-- used weight, because it is only local to router (not given to R2)
           
        route-map TO_R2 permit 10
            match as-path 54
        route-map TO_R2 permit 20
            set metric 666
      <-- R2 can now keep its own routes to BB3 (heavier metric from R6)

        router bgp 100
            neighbor 204.12.1.2 next-hop-self
            neighbor 204.12.1.2 route-map TO_R2 out

     

    NOTE: This is my second time through this lab.  Very interesting and
    fun puzzle, but again, the SG is not complete per issue#1.  Issue#2 is
    sort of a loop.   Please feel free to correct me if I am wrong on either
    of these issues. I spent some time on this.  ;-)  Thanks.

     

    Workbook Feedback Ticket ID: NNW-920748

     

Sign In or Register to comment.