cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2394
Views
0
Helpful
7
Replies

Redistributed EIGRP Metrics and Routing

Brian Saunders
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

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!

View solution in original post

7 Replies 7

Benjamin Kools
Level 1
Level 1

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!

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

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

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

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!

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

Glad you were able to make it work!

Ben

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: