BGP decision algorithm - help needed - stumped

[keiran_harris]

Hello gurus!  hoping for a BGP expert to chime in here. Im studying for my CCIE, and there is something in Jeff Doyle's Routing TCP/IP vol2 book that I just cant seem to figure out and its really stalling my understanding of the BGP path selection algorithm.  

Its on pg 195, example 3-57, attached as an image in this post (Ive also attached the network diagram that this output refers to). Basically its an output of "show ip bgp" and whats stumping me is simply: for the aggregate route 192.168.192.0/21, why has this router selected as best (>) the one via next hop 192.168.1.254?? I would have thought based on the presence of the LocalPref = 100 on the 192.168.1.237 route that would have been selected.  But apparently not! Heres a walk through of the path selection logic as i understand it:

1/WEIGHT: both 0, so skipped. 

2/LOCAL_PREF: this is my problem, .237 should win, but ignoring for now...

3/ORIGINATED LOCALLY: neither are they are learnt from BGP peers, so skipping.

4/AS_PATH: both identical, AS100 only, so skipping

5/ORIGIN CODE: both are 'i' (IGP), both were created from "aggregate-address" statements on their originating routers downstream in AS100

6/MED: both empty, so skipping

7/PREFER [eBGP] over [confedBGP] over iBGP: so the .254 route apparently wins on this condition... which in isolation, i agree with (clearly the eBGP .254 route is better than the .237 iBGP candidate).

.... however what about step 2/LOCAL_PREF!?  

looking forward to some expert guidance here to help me squash this one :) 

thank in advance, 

Keiran

[prashsin1]

Hi Keiran,

It won because it came from eBGP "7/PREFER [eBGP] over [confedBGP] over iBGP: "

Default local-pref is 100. Even though local-pref doesnt always show up in show ip bgp, it still remains 100 unless it is changed. You can confirm it by issuing show ip bgp <prefix> which gives a bit more detailed information.

So in this case since local-pref was 100 for both paths, it skipped and moved to next.

HTH.

Regards,

Prashant

[keiran_harris]

Thankyou for your reply prashant, however my understanding is that localpref is only set to 100 on *iBGP* learnt prefixes. eBGP is what, left untouched at 0 then? In this case the .237 path is iBGP (from the diagram and also status code "i" hence the localpref 100) and the .254 by the lack of status code "i" must be eBGP (hence the localpref untouched at presumably zero). 

Which means my problem stands? Have i misunderstood?

Thanks in advance guys....
K

[prashsin1 · Accepted solution]

LocPrf is a Well-known Discretionary attribute, simply put, it must be known to all BGP but may or may not be sent to everyone.

so when a prefix is learnt from an eBGP peer, local-pref is not communicated, however, the receiving router must have a value so it adds default value 100 (and not 0) unless you change it by using command
(config-router)#bgp default local-preference <value>

Lets use an example,

imagine routers R1, R2 and R3

R1 and R2 are iBGP peers

R2 and R3 are eBGP peers

R1 and R3 not peering directly

R1 advertises x.x.x.x /24 to iBGP R2 with local-pref of 500

R2 sees x.x.x.x /24 with local-pref 500 and advertises it to eBGP peer R3

R3 sees x.x.x.x /24 without local-pref and saves it in BGP routing table with local-pref 100

It will get clearer if you issue the command show ip bgp <prefix>. You will notice that even for eBGP learnt routes you will have local-preference of 100

[keiran_harris]

Thanks again prashant. So in that case mr Jeff Doyle is incorrect in his description of this path attribute, thanks for confirming- this will stop me pulling my hair out :-) its also quite annoying of IOS to have a value set in the background but not show it in the show command?! Ahh well, thats why they pay us the $$$ to be experts at this stuff i guess :-). Thanks again for you help. 

[keiran_harris]

Hello everyone, i have 1 more question on this algorithm. Specifically the relationship between (cisco specific) WEIGHT attribute which is right at the top of the path selection algorithm.... and the ORIGINATED_LOCALLY attribute (the 3rd one down, after weight and local_pref). 

Heres the relevant attributes: 

   1/WEIGHT (highest wins)

   2/LOCAL_PREF (highest wins) 

   3/ORIGINATED LOCALLY (prefer locally originated over peer learnt) 

Whats confusing to me is that Jeff's book tells us that if a prefix is ORIGINATED_LOCALLY (ie entered into BGP on that same router - either by a network/aggregate-address statement, or from redistribution) then its WEIGHT will also be set to 32768 (as opposed to a BGP peer learnt route whose WEIGHT is set to 0). I understand this. 

My question is why??? Seems to me that if this is the case there is little purpose of having ORIGINATED_LOCALLY in the decision tree at all, as the logic will never get there on account of the the propagation of its value into (the higher up) WEIGHT decision. This also in turn means that ORIGINATED_LOCALLY has the power to override the attribute LOCAL_PREF.... so couldn't this whole logic be simplified to be: 

   1/WEIGHT or ORIGINATED LOCALLY

   2/LOCAL_PREF (highest wins) 

looking forward to the thoughts of this community. Thanks in advance, Keiran. 

PS> perhaps the attached diagram will help visualise this. 

[prashsin1]

HI Again Keiran,

I tried thinking of an example where "ORIGINATED LOCALLY" works but weight doesn't, but couldn't think of any.

Since this post is marked "Answered", no one else is looking into it.  I suggest opening a new forum for it.

When you find the answer can you post it here too so that I can stop pulling my hair :-)

HTH

[keiran_harris]

Thanks for the advice prashant - (and sorry for the delay in my response, ive been busy preparing for a new job)... ill start a new thread as you advise. 

[keiran_harris]

OK new thread started over here:

https://supportforums.cisco.com/discussion/12200636/bgp-decision-algorithm-nitty-gritty-relationship-locally-originated-routes

you even get an honourable mention in my post :)   Lets keep an eye on that new thread to see if it gets resolved. 

[keiran_harris]

hello.... ?   anyone ....  ? 

[gargolek99]

Hello,

Keiran are you talking about "Orgin" attribute or ORIGINATED LOCALLY as this attribute i am not able to find it...that attribute anywhere:

http://netcerts.net/bgp-path-attributes-and-the-decision-process/

Path Attributes:

Attribute	Class
ORIGIN	Well-know mandatory
AS_PATH	Well-know mandatory
NEXT_HOP	Well-know mandatory
LOCAL_PREF	Well-know discretionary
ATOMIC_AGGREGATE	Well-know discretionary
AGGREGATOR	Optional transitive
COMMUNITY	Optional transitive
MULTI_EXIT_DISC (MED)	Optional nontransitive
ORGINATOR_ID	Optional nontransitive
ORGINATOR_ID	Optional nontransitive
CLUSTER_LIST	Optional nontransitive

Also there is similar question on learning forums:

https://learningnetwork.cisco.com/thread/36845

From the forum:

"Locally Originated means that the local router is the one that generated the route with either a network statement, and aggregate statement, redistribution, or conditional route injection.  It's not an attribute that is included in the UPDATE messge, instead it's just used by the local process as part of the path selection, where the router will prefer its own locally originated routes over someone else's origination of the same prefix."

Hopefully this will help.

BTW i am reading same book and too bad Mr. Doyle did not include full configs for all routers, as i am trying to simulate his scenarios sometimes it is not working as in his book, now i have issue on next page 197 why Orgin IGP is not taking precedence over Incomplete even if one is learned via EBGP and other over iBGP...driving me nuts.

Regards,

Lukasz

[keiran_harris]

Thanks for your input Lukasz. Yes you are right, sorry, there is no locally originated attribute as such, nor weight for that matter. I used the term too loosely as its hard trying to find another word to describe them! They are both internal "things" and not communicated at all - just used for the routers own path selection as that learning network post corroborates. Ive started a new post (now more correctly worded - thanks for that!) so lets keep an eye on that: 

https://supportforums.cisco.com/discussion/12200636/bgp-decision-algorithm-nitty-gritty-relationship-locally-originated-routes 

did you solve your pg197 issue? 

Keiran. 

[gargolek99]

Nope, i stuck on why aggregate-address on IOS 15 shows best route itself when configured, it is completely not matching what book is showing:

Aggregated address 192.168.192.0/21 i have posted that on support and learning cisco no answer so far..

Stowe#sh ip bgp
BGP table version is 14, local router ID is 192.168.199.1
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
 *>  192.168.192.0/21 0.0.0.0                            32768 ?
 *>  192.168.193.0    192.168.199.254     409600         32768 ?
 *>  192.168.194.0    192.168.199.254     409600         32768 ?
 s>  192.168.195.0    192.168.199.254     409600         32768 ?
 s>  192.168.196.0    192.168.199.254     409600         32768 ?
 s>  192.168.197.0    192.168.199.254     409600         32768 ?
 s>  192.168.198.0    192.168.199.254     409600         32768 ?
 s>  192.168.199.0    0.0.0.0                  0         32768 ?
Stowe#sh ip bgp 192.168.192.0/21
BGP routing table entry for 192.168.192.0/21, version 9
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1
  Refresh Epoch 1
  Local, (aggregated by 100 192.168.199.1)
    0.0.0.0 from 0.0.0.0 (192.168.199.1)
      Origin incomplete, localpref 100, weight 32768, valid, aggregated, local, atomic-aggregate, best
Stowe#sh ip int br | e una
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                192.168.199.1   YES NVRAM  up                    up  
Serial2/0                  192.168.1.254   YES NVRAM  up                    up  

Stowe#

[keiran_harris]

Ok lets have a look at this since you took the time to reply to my query :) your original problem needs some clarifying a little i think. You state "why Orgin IGP is not taking precedence over Incomplete even if one is learned via eBGP and other over iBGP". So lets look at the full decision tree: 

1/(highest)weight
2/(highest)local pref
3/originated locally
4/(shortest)as-path
5/origin code(i over e over ?)
6/MED
7/eBGP over confedBGP over iBGP
8/shortest IGP path to next_hop
9/if multipath, install both
10/lowest routerID

so your question involves 1 thru 5 above. For 5 to be the deciding factor, 1-4 must all be identical. You then say "even if one is learned via eBGP and other over iBGP" but that is decision #7 so that wont even be gotten to if it can decide based on #5. 

The example on pg197 is all about tweaking things so a given route can win at step #5 (when all other conditions above are equal)... ie in that case on router STOWE, changing an aggregates origin from i (from the aggregate-address command) to ?/incomplete (indicating redistribution, even though it isnt in this case... thats the point of the example to show that this can be done). It then influences a neighbouring routers (SUGARBUSH) decision tree so a decision can be made at step #5. Make sense?  

[gargolek99]

Hello,

Thank you for still looking into my issue, however as i understand intention of the example i like each simulate on my own his case studies and configure routers based on the information author provided. In this case i did same but results are differ. So after using all its tips from the book i end up with the following results:

1. Both routers in AS200 are synchronized - results is that even the origin shows as incomptete coming from Stowe and shows as igp showing from Diamond the best path is still via Stowe -- that was not intention of this example,

2. Both routers in AS200 are - results on Sugerbush are now showing correct path selection the best path is via Diamond which origin is igp. However bgp table on Burke is all "messed" up. All routes are showing on Burke and only one route should available on it...

3. If i want to fix issue with Burke and enable aggregate-address on Diamond and Sugerbush then i got right results on Burke only one route pointing to Diamond is avilble, but at the same time we have best routes on Sugerbush pointing to its own as aggregate-address creates Null interface and as this is the locally originated and also shows it has the highest weight that route is picked instead of Diamond...

As you can see from above that is where i got stack...first uncertainty was already resolved...i couldn't  understand why aggregate-address creates best routes  but i found somewhere that whenever you create that it also creates null interface and as this i will be local route it will be choose that route instead anything else. I still have other question thought...

1. How to send only summary route to Burke from Diamond and Sugerbush without creating best route on those two which will be choose? 

2. How to make Sugerbush and Diamond so summarized route will be always going thrue the Diamond? 

I think i am missing information as author is not showing bgp configuration on Burke nor on Sugerbush...

Hopefully this clarify what want to do...

Regards,

Lukasz Galej,