bgp route question

[Mike Schooley]

so I have this output, the "local" route is appearing in my routing table via eigrp.  10.33.254.20 is not a bgp neigh, and 10.40.33.4 is this routers loopback.  The primary route should be via bgp.  Those routes are being redistirbuted int eigrp with a tag of 1000, then eigrp is being redistibuted back into bgp except for the tagged routes.  10.33.254.20 is actually our backup dmvpm router which is where the eigrp route is coming from, I just can't figure out why the bgp route isnt being put into the routing table instead of the eigrp route.  Note it is working correctly on about 50 sites and just about 10 are doing this.  Also if you look at an eigrp neigh, this route doesnt have the 1000 tag.  Perhaps, I am redistributing the route and learning the routes via dmvpn, and the dmvpn router has a better cost than the redistributed route, but bgp route should still be installed due to admin distance right?

router2#sho ip bgp 10.35.10.0

BGP routing table entry for 10.35.10.0/24, version 170673

Paths: (2 available, best #2, table Default-IP-Routing-Table)

  Advertised to update-groups:

        1    2

  65000 10

    147.225.157.153 from 147.225.157.153 (159.24.198.5)

      Origin IGP, localpref 100, valid, external

  Local

    10.33.254.20 from 0.0.0.0 (10.40.33.4)

      Origin incomplete, metric 25858816, localpref 100, weight 32768, valid, sourced, best

router2#sho ip route 10.35.10.0
Routing entry for 10.35.10.0/24
  Known via "eigrp 136", distance 90, metric 25858816, type internal
  Redistributing via eigrp 136, bgp 1
  Advertised by bgp 1 route-map eigrp_to_bgp
  Last update from 10.33.254.20 on FastEthernet0/0, 6d00h ago
  Routing Descriptor Blocks:
  * 10.33.254.20, from 10.33.254.20, 6d00h ago, via FastEthernet0/0
      Route metric is 25858816, traffic share count is 1
      Total delay is 10110 microseconds, minimum bandwidth is 100 Kbit
      Reliability 255/255, minimum MTU 1400 bytes
      Loading 198/255, Hops 2

[Giuseppe Larosa]

Hello Mike,

the BGP route is generated locally by redistribution of EIGRP into BGP:

Origin incomplete, metric 25858816, localpref 100, weight 32768, valid, sourced, best

note weight 32768 and sourced this means locally injected into BGP table.

best means this advertisement is considered the best one and it is advertised to two update groups.

>>  but bgp route should still be installed due to admin distance right?

No, because it is derived from the EIGRP route.

Also, because in the BGP table the different advertisements are compared using only BGP attributes and weight values and AD plays no role.

BGP then sends the best route to the IP routing table and locally generated route are not considered with AD 20 (but 200) and EIGRP route wins.

if you want to be sure to install the eBGP route you can give to the eBGP neighbor a weight > 32768

>> Also if you look at an eigrp neigh, this route doesnt have the 1000 tag

yes, and probably for this reason the route-map allows this redistribution as you have noted.

Hope to help

Giuseppe

[Mike Schooley]

Hello Mike,

the BGP route is generated locally by redistribution of EIGRP into BGP:

Origin incomplete, metric 25858816, localpref 100, weight 32768, valid, sourced, best

note weight 32768 and sourced this means locally injected into BGP table.

best means this advertisement is considered the best one and it is advertised to two update groups.

>>>>where does that weight come from?  this is my redistribution.

redistribute eigrp 136 route-map eigrp_to_bgp

route-map eigrp_to_bgp deny 10
match tag 1000
!
route-map eigrp_to_bgp permit 20

>>  but bgp route should still be installed due to admin distance right?

No, because it is derived from the EIGRP route.

Also, because in the BGP table the different advertisements are compared using only BGP attributes and weight values and AD plays no role.

BGP then sends the best route to the IP routing table and locally generated route are not considered with AD 20 (but 200) and EIGRP route wins.

if you want to be sure to install the eBGP route you can give to the eBGP neighbor a weight > 32768

>> Also if you look at an eigrp neigh, this route doesnt have the 1000 tag

yes, and probably for this reason the route-map allows this redistribution as you have noted.

>>>>  I don't understand why this eigrp route doesnt have a tag or the effect of it not haveing a tag, that is that the route is redistributed into bgp.  I should be learning this route via both eigrp and bgp.  The bgp route should be placed in the routing table, then it should be redistributed with a tag of 1000. Then due to this tag, it shouldnt be redistibuted back into bgp.  Unless of course when it is redistibuted int eigrp, the other eigrp route has a better cost, therefore the eigrp route without the tag goes into the routing table, therefore it gets redistiributed.

Hope to help

Giuseppe

[Mike Schooley]

again it doesnt make since that the 2nd one is best, origin of igp should be better than incomplete, I don't have a network statement or aggregate statement, don't understand why it is local.

Paths: (2 available, best #2, table Default-IP-Routing-Table)

  Advertised to update-groups:

        1    2

  65000 9

    147.225.157.153 from 147.225.157.153 (159.24.198.5)

      Origin IGP, localpref 100, valid, external

  Local

    10.33.254.20 from 0.0.0.0 (10.40.33.4)

      Origin incomplete, metric 25861120, localpref 100, weight 32768, valid, sourced, best

[yagnesh_tel]

The reason that second path is considered best is its Adminstrative weight-32768.   You may already know that 'origin' factored after 'adminitrative weight' in deciding best path.  Also route is considered 'local' from BGP perspective as you are redistribute EIGRP into BGP on this router itself.

By default, BGP assigns the weight value of 32768 to all locally advertised prefixes- i.e prefixes advertised using the network or aggregate-address command or via route redistribution.  So after redistribution from EIGRP to BGP, this route is getting weight-32768 whereas other route must have lesser weight than this one.

[Mike Schooley]

so how do I find the weight of this other route, I did go to the far end route and did a show ip bgp neigh advertised routes, this route is being advertised from the remote site with a weight of 32768.

The bigger question is why is it begin advertised into bgp.  Other sites set up identically are working fine.  The bgp route is redistributed into eigrp with a tag of 1000, then consequently these routes arent redistributed back into bgp.  But this route for some reason isnt being redistributed from bgp, or if it is, it isn't being put into the eigrp topology table.

[Mike Schooley]

below are the entries for eigrp.  the 12 network and the 9 network are both known via bgp, and via eigrp thru dmvpn.  Router configs at remote site are identical.  so why is one being redistributed correctly and the other isn't?

RC002VPN2#sho ip eigrp top 10.35.12.0/24
IP-EIGRP (AS 136): Topology entry for 10.35.12.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 281600
  Routing Descriptor Blocks:
  147.x.x.x, from Redistributed, Send flag is 0x0
      Composite metric is (281600/0), Route is External
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 1000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 0
      External data:
        Originating router is 10.40.33.4 (this system)
        AS number of route is 1
        External protocol is BGP, external metric is 0
        Administrator tag is 1000 (0x000003E8)
RC002VPN2#sho ip eigrp top 10.35.9.0/24
IP-EIGRP (AS 136): Topology entry for 10.35.9.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 25861120
  Routing Descriptor Blocks:
  10.33.254.20 (FastEthernet0/0), from 10.33.254.20, Send flag is 0x0
      Composite metric is (25861120/25858560), Route is Internal
      Vector metric:
        Minimum bandwidth is 100 Kbit
        Total delay is 10200 microseconds
        Reliability is 255/255
        Load is 56/255
        Minimum MTU is 1400
        Hop count is 2
RC002VPN2#

[cadet alain]

Hi,

Can you post a topology diagram indicating where you are doing redistribution and all BGP and EIGRP neighbour relationships.

Regards.

[milan.kulik · Accepted solution]

Hi Mike,

ad  "so how do I find the weight of this other route, I did go to the far end route and did a show ip bgp neigh advertised routes, this route is being advertised from the remote site with a weight of 32768."

Don't forget the Weight is a Cisco proprietary attribute which is never advertised to a BGP neighbor - it has a local meaning only!

ad "The bigger question is why is it begin advertised into bgp.  Other sites set up identically are working fine.  The bgp route is redistributed into eigrp with a tag of 1000, then consequently these routes arent redistributed back into bgp.  But this route for some reason isnt being redistributed from bgp, or if it is, it isn't being put into the eigrp topology table."

I'm afraid this is a problem of mutual redistribution between IGP and BGP. The behaviour sometimes depends on the sequence of the prefix coming to your router via IGP or BGP.

Let's assume the BGP process received the prefix first. The prefix was redistributed to EIGRP with tag 1000 which prevented the prefix from being redistributed to BGP (on other router, e.g.).

In a case your router received the prefix via EIGRP first: The prefix was without any tag, so it was redistributed to BGP by the router. As locally originated, it received the weight 32768. Which means, even if the same prefix comes via eBGP, it will never beat the current prefix in the BGP table.

So you need to handle the mutually redistributed prefixes some special way to get the exact behaviour you want.

If your goal is the prefix received via eBGP to beat the prefix recived by EIGRP every time, you might use a route map setting the weight = 0 for prefixes being redistributed from EIGRP to BGP. If you also set a high Local Preference for the prefixes incoming via eBGP, you should get what you want.

You need to understand the BGP Best Path Selection Algorithm in deep (see http://www.cisco.com/image/gif/paws/13753/25.pdf ) and also to ask yourself: What happens when the prefix comes  from the IGP first and from BGP consequently? And what happens if the prefix comes from BGP first and from the IGP then?

HTH,

Milan

[Mike Schooley]

I know weight is local significant, but it still shows for some reason in the sho ip bgp neigh x.x.x.x advertised

I was thinking that it could be a timing issue.  so if on my route map if in additon to setting the tag to 1000, I also set the weight to 0 or really anything under 32768, that route would be preferred to the redistirbuted route all the time so even if the eigrp route arrived first and was redistributed into bgp the other bgp route would be preferred,  What about thinking about it another way and making sure that the tagged route was the one that was always preferred in the eigrp topolgy table by setting a low metric when redistributing from  bgp,  although I thought it had a lower cost by looking at other sites that are working correctly.

[milan.kulik]

Hi,

setting a low metric when redistributing from  bgp to eigrp is a good idea, of course.

But don't forget the metric will increase with hops inside the EIGRP cloud and depending on the same prefix originators in the EIGRP cloud it still could be beaten by a non-tagged prefix.

So IMHO, the preferences/attributes are crucial at the mutual redistribution points.

BR,

Milan

[Mike Schooley]

so I have a best BGP route and that is the redistributed one, so why is the route in the routing tabel the eigrp route and not t

he bgp route?

[milan.kulik]

Hi,

you mean there is an EIGRP route redistributed to BGP and you are asking why the "sh ip route" command is still showing the EIGRP route being used?

That's the way route redistribution  works on Cisco routers.

"The rules for redistribution on a Cisco router dictate that the redistributed route be present in the routing table. It is not sufficient that the route be present in the routing topology or database." (See http://www.cisco.com/application/pdf/paws/8606/redist.pdf for details.)

Which means: The EIGRP route must be the best (present in the routing table) to be redistributed.

The fact the router is redistributing it into another routing protocol does not change anything from this point of view - the EIGRP route is still the best one.

HTH,

Milan

[Mike Schooley]

Thats my point, its not the best one.  If I have a route learned to x.x.x.x via eigrp and bgp, the bgp route should go into the routing table.  Then bgp should redistribute it into eigrp with a tag and eigrp shouldnt redistribute it because it is tagged.

Lets say I have don't have the route via bgp, and eigrp route is being redistributed because its not tagged.  Then I add a new link over the bgp to the site, at that point the bgp route should take precedence, and replace the eigrp route in the routing table, therefore eigrp couldn;t redstribute it into bgp.  Its like you said the rules of redistribution say that it has to be in the routing table, the point is the route in the ip routing table should be a bgp route, not an eigrp route, therefore eigrp should not be redistributing it.

[milan.kulik]

Hi,

yes, it should work that way.

So  the prefix received from eBGP should beat the one redistributed from EIGRP.

To make that happen, you need to set the weight to 0 for the EIGRP prefixes redistributed to BGP.

And also to increase the local preference for the prefixes received from eBGP.

Have you done that?

If yes, the prefix received from eBGP should win from the BGP point of view.

And due to better administrative distance (20 for eBGP by default) should beat the EIGRP prefix (unless it's a summary EIGRP route with AD = 5).

(See http://www.cisco.com/image/gif/paws/8651/21.pdf )

Can you provide sh ip bgp a.b.c.d and sh ip eigrp topo a.b.c.d for that prefix to check the details?

BR,

Milan