×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

Redistributed EIGRP Metrics and Routing

Answered Question
Aug 21st, 2012
User Badges:

Hello All,


I have a scenario mocked up in our lab and I am having issues getting the routing worked out.  Basically I have a "Branch" router that has a primary connection and a backup connection.  The primary connection is running BGP which terminates to a "Branch Headend" router which then redistributes the BGP routes to the rest of the network via EIGRP (shows as External EIGRP with an AD of 170 and metric of 25856.  The backup connection is a DMVPN connection that is running EIGRP over GRE that termintes to "DMVPN" router, the branch router is redistributing the LAN network via route-map - the DMVPN router then shares that with the rest of the network (shows as External EIGRP with an AD of 170 and metric of 297244928).


When I shutdown the primary connection on the branch router it flips over to the backup connection and the rest of the network learns of the branch LAN via the backup connection.  The problem that I am having is that when I turn on the primary connection the branch flips back over to the primary but the rest of the network still thinks the branch LAN is still located via the backup connection instead of the primary (until I actually shut down the backup connection then the rest of the network adds the primary connection).  The AD is the same for both routes and the primary connection has the lower metric so shouldn't that always take precedence?  Attached is a Visio of this scenario.


Thanks,


Brian

Correct Answer by Benjamin Kools about 4 years 12 months ago

Ok so looks like your issue occurs when BGP learns of the backup route from EIGRP. Initially before the primary link goes down, the headend router would never know of the backup link because it's metric is much better. After the primary link fails, BGP learns of the route and due to the redistribution, it automatically sets the weight to 32768. Thus when the primary link comes back up, with no weight set (aka weight of 0), it is not a preferred route. BGP Best path selection dictates that highest weight is preferred, followed by local preference, etc.


You have a few options with which to fix this.


Option 1:


Set the weight on your BGP neighbor for all learned routes to something higher than 32768


router bgp 65100

neighbor 172.16.0.2 weight 40000


Option 2:


Create a route map set the eigrp redistribution weight to 0 andset the local preference to 90 (lower than the default 100 for routes from your bgp neighbor)


route-map eigrp->bgp

set weight 0

set local-preference 90

!

router bgp 65100

redistribute eigrp 100 route-map eigrp->bgp


Give that a shot - hope it helps!

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Benjamin Kools Tue, 08/21/2012 - 07:59
User Badges:

Can you attach the show ip eigrp topology x.x.x.x and show ip route x.x.x.x, where x.x.x.x = the branch LAN subnet from the Branch Headend, Core, and DMVPN termination. Do this when both the primary and backup networks are up but the backup is being preferred please.


Thanks!

Brian Saunders Tue, 08/21/2012 - 08:12
User Badges:

Routing information while the backup connection is the preferred route even though the primary is up / up.


Branch Headend Router:


HEADEND_Lab>sh ip eigrp topology 10.24.26.0/24

IP-EIGRP (AS 100): Topology entry for 10.24.26.0/24

  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 297245184

  Routing Descriptor Blocks:

  10.83.1.66 (GigabitEthernet0/0), from 10.83.1.66, Send flag is 0x0

      Composite metric is (297245184/297244928), Route is External

      Vector metric:

        Minimum bandwidth is 9 Kbit

        Total delay is 500030 microseconds

        Reliability is 255/255

        Load is 1/255

        Minimum MTU is 1476

        Hop count is 3

      External data:

        Originating router is 192.168.0.2

        AS number of route is 0

        External protocol is Connected, external metric is 0

        Administrator tag is 0 (0x00000000)


HEADEND_Lab>sh ip route 10.24.26.0

Routing entry for 10.24.26.0/24

  Known via "eigrp 100", distance 170, metric 297245184, type external

  Redistributing via eigrp 100, bgp 65100

  Advertised by bgp 65100

  Last update from 10.83.1.66 on GigabitEthernet0/0, 00:43:56 ago

  Routing Descriptor Blocks:

  * 10.83.1.66, from 10.83.1.66, 00:43:56 ago, via GigabitEthernet0/0

      Route metric is 297245184, traffic share count is 1

      Total delay is 500030 microseconds, minimum bandwidth is 9 Kbit

      Reliability 255/255, minimum MTU 1476 bytes

      Loading 1/255, Hops 3


Core Router:


CORE_Lab#sh ip eigrp topology 10.24.26.0/24

IP-EIGRP (AS 100): Topology entry for 10.24.26.0/24

  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 297244928

  Routing Descriptor Blocks:

  10.83.2.10 (GigabitEthernet4/2), from 10.83.2.10, Send flag is 0x0

      Composite metric is (297244928/297244672), Route is External

      Vector metric:

        Minimum bandwidth is 9 Kbit

        Total delay is 500020 microseconds

        Reliability is 255/255

        Load is 1/255

        Minimum MTU is 1476

        Hop count is 2

      External data:

        Originating router is 192.168.0.2

        AS number of route is 0

        External protocol is Connected, external metric is 0

        Administrator tag is 0 (0x00000000)


CORE_Lab#sh ip route 10.24.26.0

Routing entry for 10.24.26.0/24

  Known via "eigrp 100", distance 170, metric 297244928, type external

  Redistributing via eigrp 100

  Last update from 10.83.2.10 on GigabitEthernet4/2, 00:40:17 ago

  Routing Descriptor Blocks:

  * 10.83.2.10, from 10.83.2.10, 00:40:17 ago, via GigabitEthernet4/2

      Route metric is 297244928, traffic share count is 1

      Total delay is 500020 microseconds, minimum bandwidth is 9 Kbit

      Reliability 255/255, minimum MTU 1476 bytes

      Loading 1/255, Hops 2


DMVPN Termination Router:


DMVPN_Lab#sh ip eigrp topology 10.24.26.0/24

IP-EIGRP (AS 100): Topology entry for 10.24.26.0/24

  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 26112

  Routing Descriptor Blocks:

  10.63.254.2 (Tunnel0), from 10.63.254.2, Send flag is 0x0

      Composite metric is (297244672/2816), Route is External

      Vector metric:

        Minimum bandwidth is 9 Kbit

        Total delay is 500010 microseconds

        Reliability is 255/255

        Load is 1/255

        Minimum MTU is 1476

        Hop count is 1

      External data:

        Originating router is 192.168.0.2

        AS number of route is 0

        External protocol is Connected, external metric is 0

        Administrator tag is 0 (0x00000000)



DMVPN_Lab#sh ip route 10.24.26.0

Routing entry for 10.24.26.0/24

  Known via "eigrp 100", distance 170, metric 297244672, type external

  Redistributing via eigrp 100

  Last update from 10.63.254.2 on Tunnel0, 00:42:02 ago

  Routing Descriptor Blocks:

  * 10.63.254.2, from 10.63.254.2, 00:42:02 ago, via Tunnel0

      Route metric is 297244672, traffic share count is 1

      Total delay is 500010 microseconds, minimum bandwidth is 9 Kbit

      Reliability 255/255, minimum MTU 1476 bytes

      Loading 1/255, Hops 1

Benjamin Kools Tue, 08/21/2012 - 08:25
User Badges:

Looks like the Headend Lab isn't redistributing the route from BGP back into EIGRP. Can you attach the config for that router as well as the show ip bgp 10.24.26.0/24

Brian Saunders Tue, 08/21/2012 - 09:46
User Badges:

Uploaded the Headend router config above to the original post.  Here is the output of the show ip bgp 10.24.26.0/24 from the Headend router:


HEADEND_Lab#sh ip bgp 10.24.26.0/24

BGP routing table entry for 10.24.26.0/24, version 15

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

  Advertised to update-groups:

        1

  209

    172.16.0.2 from 172.16.0.2 (192.168.0.2)

      Origin IGP, metric 0, localpref 100, valid, external

  Local

    10.83.1.66 from 0.0.0.0 (172.16.0.1)

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

Correct Answer
Benjamin Kools Tue, 08/21/2012 - 18:20
User Badges:

Ok so looks like your issue occurs when BGP learns of the backup route from EIGRP. Initially before the primary link goes down, the headend router would never know of the backup link because it's metric is much better. After the primary link fails, BGP learns of the route and due to the redistribution, it automatically sets the weight to 32768. Thus when the primary link comes back up, with no weight set (aka weight of 0), it is not a preferred route. BGP Best path selection dictates that highest weight is preferred, followed by local preference, etc.


You have a few options with which to fix this.


Option 1:


Set the weight on your BGP neighbor for all learned routes to something higher than 32768


router bgp 65100

neighbor 172.16.0.2 weight 40000


Option 2:


Create a route map set the eigrp redistribution weight to 0 andset the local preference to 90 (lower than the default 100 for routes from your bgp neighbor)


route-map eigrp->bgp

set weight 0

set local-preference 90

!

router bgp 65100

redistribute eigrp 100 route-map eigrp->bgp


Give that a shot - hope it helps!

Brian Saunders Wed, 08/22/2012 - 07:50
User Badges:

Benjamin,


Thanks for the assistance and explanation on this!  We ended up putting a distribution list outbound on the Core_Lab for both the Headend_Lab and DMVPN_Lab that pointed to an acces-list that only permited 0.0.0.0.  This allowed the Core to learn about the routes from the Headend and DMVPN but only redistribute the default route back out to the Headend_Lab and DMVPN_Lab.


Brian

Actions

This Discussion

Related Content