08-21-2012 07:28 AM - edited 03-04-2019 05:19 PM
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
Solved! Go to Solution.
08-21-2012 06:20 PM
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!
08-21-2012 07:59 AM
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!
08-21-2012 08:12 AM
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
08-21-2012 08:25 AM
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
08-21-2012 09:46 AM
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
08-21-2012 06:20 PM
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!
08-22-2012 07:50 AM
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
08-22-2012 08:15 AM
Glad you were able to make it work!
Ben
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide