BGP configuration with local preference

Nov 16, 2005 1 Replies

I have a setup as follows | | | | | | | | | |----------eBGP-------------------:RtrB | | | | RtrA | IBGP | | | | | RtrC | |---------eBGP----------------------| | | | | | | | | |



Router A is peering with Router B via EBGP



The ultimate goals are to



  1. Run iBGP between Rtr B and C
  2. Connect RtrC to Rtr A via EBGP and use for Backup traffic only

The way this will be achieved is to set Router B with a higher local preference (for example 200). This will ensure that Router B will always be the preferred exit path from the AS.



In addition. Router C will have all advertised routes set with an AS path twice as long as the routes advertised from B. This will ensure that all return traffic enters through Router B



Both Router B and Router C are:



  1. advertising the Same exact routes.
  2. Running OSPF Area 0
  3. Redistributing BGP Into OSPF
  4. Basically have identical configurations except for Local pref and As prepend statements

Now the 1st step taken was to set up IBGP between RtrB and RtrC. This was done but there are strange things seen. What I would expect to see is all the routes learned from RtrA be propagated to Router B, then propagated to Router C.



Router B has all the routes correctly, But Router C is showing the routes changing from "r>" "rib failure" to "*" "valid" and back again. This change is happening about every 30 to 45 seconds. (Note I said "*" valid and NOT "*>" best)



I created a similar setup in a test environment and on Router C I DO see the "r>" rib failures but they are steady and they are NOT changed back and forth the "*" valid.


  1. Any Idea why that would be happening?


**Router C** router bgp 1111 no synchronization no bgp log-neighbor-changes network x.x..x.x mask 255.255.192.0 redistribute static route-map BGPSTATIC neighbor 10.10.10.1 remote-as 1111 neighbor 10.10.10.1 update-source Loopback0 neighbor 172.2.2.10 remote-as 2222 neighbor 172.2.2.10 shutdown neighbor 172.2.2.10 soft-reconfiguration inbound neighbor 172.2.2.10 distribute-list 10 in default-information originate no auto-summary


***Router C*** router bgp 1111 no synchronization bgp default local-preference 200 no bgp log-neighbor-changes network x.x..x.x mask 255.255.192.0 redistribute static route-map BGPSTATIC neighbor 10.10.10.2 remote-as 1111 neighbor 10.10.10.2 update-source Loopback0 neighbor 172.1.1.10 remote-as 2222 neighbor 172.1.1.10 soft-reconfiguration inbound neighbor 172.1.1.10 distribute-list 10 in default-information originate no auto-summary

sh ip bgp:


*> Y.Y.Y.Y 172.1.1.10 0 2222 3333 ?
*
> Y.Y.Y.Y 172.1.1.10 0 2222 3333 ?
*> Y.Y.Y.Y 172.1.1.10 0 2222 3333 ?

sh ip bgp (seconds later)


  • Y.Y.Y.Y 172.1.1.10 0 2222 3333 ?
  • Y.Y.Y.Y 172.1.1.10 0 2222 3333 ?
  • Y.Y.Y.Y 172.1.1.10 0 2222 3333 ?


The next question is about what I see in my test environment.



Once I have everything connected (meaning that ibgp is running between RtrB and RtrC plus EBGP is running between RtrB and RtrA, and between RtrC and RtrA.) and RtrB is set to be the primary link. I notice that RtR C is showing all routes as being "r>" with a next hop of Its RTRA address. The "r>" only shows up whenever I have local preference set on RtrB.



I'm guessing this is correct and that when RtrB goes away, all the routes on RtRC will become valid "*>" and everything will still work. But my question is:


  1. Why doesnt RouterC show the bgp routes as being valid "*>" with a next hop of 172.1.1.10. His reason for "rib failure" (sh ip bgp rib-failure) is that ibgp has a higher administrative distance therefore he uses the ospf route. But RouterC is also learning these routes from EBGP through Router A which has an admin distance of
  2. Why not mark the prefix as a BGP route. Please clarify.

Thank you



Does router C know how to reach next-hop of the BGP routes sourced from router A?

You have not configured next-hop-self for the IBGP neighbor on router B and router C

============================================================== Q. Do internal BGP sessions modify the next hop?

A. Internal BGP (iBGP) sessions preserve the next hop attribute learned from eBGP peers. This is why it is important to have an internal route to the next hop. The BGP route is otherwise unreachable. In order to make sure you can reach the eBGP next hop, include the network that the next hop belongs to in the IGP or use the next-hop-self neighbor command to force the router to advertise itself, rather than the external peer, as the next hop. Refer to the BGP Nexthop Attribute section of BGP Case Studies for a more detailed explanation.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required