BGP attibutes

grechy

Hi Guys,

Its been awhile since I have completed my CCNP R\S and have been out of the route game mainly doing voice \ wireless and web development work. last friday night I was required to make a change to our companies BGP metrics as the primary carrier was performing emergency maintenance. As a result I had to relearn my BGP metrics ect. Recently I started a blog to help remember different things, could someone please sanity check post and confirm if its correct.

https://grepch.wordpress.com/2015/02/06/bgp-we-love-oranges-as-oranges-mean-pure-refreshment/

theodoxa

I used "[N] WLLA OMNI" to remember the attributes for BGP.

1. Is the Next Hop Reachable
2. Highest Weight
3. Highest Local Preference
4. Locally Originated Routes Prefered Over Learned Routes
5. Shortest AS Path
6. Origin Code -- IGP over EGP over Unknown
7. Lowest Multi-Exist Discriminator (MED)
8. Neighbor Type -- eBGP over iBGP
9. Best IGP Metric to Next Hop

At this point if the max paths is > 1, BGP will equal cost load balance. If max paths = 1

10. Oldest (Longest Known) Route
11. Lowest Neighbor BGP Router ID
12. Lowest Neighbor IP Address

The only problem with this was mixing up 3 (Local_Pref) and 4 (Locally Originated). Interestingly, since Cisco based the default weight on whether a route was locally originated (32768 ) or learned (0), Cisco effectively puts 4 above 3.

grechy

Thanks for the reply, I was more interested if my understanding of the concepts of correct.

EdTheLad

grechy wrote: »

Thanks for the reply, I was more interested if my understanding of the concepts of correct.

As per "theodoxa" reply you are obviously incorrect. After prefer ext to int, you should have 9) lowest IGP metric to NH. 10) should actually be the oldest if learned via eBGP, followed by 11 and 12.

Your MED description is poor, you should mention MED is used on eBGP sessions, it is comparable on routes from the same AS only, unless you configure "bgp deterministic-med". When learned via iBGP it is not propagated to an eBGP peer.

Influencing outbound traffic, you should mention weight here, weight is applicable to the local router only, where as local preference is advertised to iBGP peers.

TIP
You mention "clear ip bgp x.x.xx. soft" when changing local policy, this is legacy. Newer IOS supports route-refresh capability, if supported you don't require the config "neighbor x.x.x.x soft-reconfiguration inbound" . You just need to do "clear ip bgp x.x.x.x in/out"

grechy

Thanks, Perfect

I'll update it when i have some time shortly.

I wrote it after performing the maintenance as I just wanted to **** what was in my head at the time.. I also didn't perform a soft clear as at the time as I saw the change take affect. However the documentation I read suggested to do so. I mentioned this surprised to a peer and he also mentioned that it didn't need to be done.

Heero

EdTheLad wrote: »

Your MED description is poor, you should mention MED is used on eBGP sessions, it is comparable on routes from the same AS only, unless you configure "bgp deterministic-med". When learned via iBGP it is not propagated to an eBGP peer.

Just for clarification, it is "bgp always-compare-med" that allows for MED comparison between routes learned from different ASes. Deterministic-med has an effect on the order that routes are compared in for a more deterministic (part of the feature name!) path selection process. Cisco actually recommends that deterministic-med be enabled on all BGP routers, at least for fresh deployments.

EdTheLad

Very true, too many things in my head .