cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4833
Views
0
Helpful
4
Replies

2 WAN links with EIGRP failover if primary fails

David Lagace
Level 1
Level 1

Hello All,

A bit a of sticky problem.

I have a remote site with 2 WAN links.

Link 1 MPLS with telecom provider managing the PE and advertising EIGRP routes to my switch(3750-E stack).

Link 2 Directly connected to core site switch (4506) and advertising EIGRP routes.

It looks like this:

                                      -------- Provider MPLS Cloud ------- GI2/0/1Remote Site (3750-E Stack)

Core Site Switch(4506)----

                                      gi4/2------------------------------------------------ GI1/0/1Remote Site (3750-E Stack)

When both links are up MPLS is disrupted from other sites (that have MPLS only) to the core site.  I was unable to get a route list to see what exactly was going on before shutting the directly connected link down.

What i'd like to have is:

Use MPLS as my primary link as it is fully meshed with all my remote sites (and not just the core) and have the directly connected link as my failover in case of issues with the primary.

I assumed putting a delay 1000 on the directly connected link at the remote site would have been enough but it looks like both were active and leaking routes all over the place

Is there a way to set this up that the MPLS link is favoured and if it loses routes to that specific remote site it would failover to the directly connected link? 

Here is my current configuration for EIGRP on the remote and Core sites:

Remote 3750-E

router eigrp 100

redistribute connected

redistribute static

passive-interface default

no passive-interface GigabitEthernet1/0/1

no passive-interface GigabitEthernet2/0/1

no auto-summary

network 10.0.0.0

Core 4506

router eigrp 100

redistribute static

passive-interface default

no passive-interface Vlan100

no passive-interface Vlan400

no passive-interface GigabitEthernet4/1

no passive-interface GigabitEthernet4/48

distribute-list DENY_LOOPBACK out

no auto-summary

eigrp router-id 10.80.252.202

network 10.0.0.0

Standard IP access list DENY_LOOPBACK

    10 deny   10.52.0.69

    20 permit any (113249 matches)

Thanks for any light you can shed on the issue

Thanks

--Dave

4 Replies 4

Edison Ortiz
Hall of Fame
Hall of Fame

On your direct connection, more than likely you will receive EIGRP internal routes while via the MPLS connection, the routes will be EIGRP external (MPLS PE routers run BGP and redistribution to/from EIGRP will take place).

There is no way to change the route preference of an EIGRP external route to be chosen over an EIGRP internal route.

Your best bet is configuring BGP or other IGP on the connection to HQ and redistribute to EIGRP at the remote site.

Richard Burts
Hall of Fame
Hall of Fame

Dave

Am I correct in understanding that your core 4506 is running EIGRP directly with the MPLS provider router and running EIGRP directly to your remote 3750? Do you know (or can you ask the MPLS provider) whether the routes stay as native EIGRP routes through the cloud? Or are they perhaps redistributed from EIGRP to something in the cloud and redistributed back to EIGRP at the remote edge? If the remote 3750 receives an EIGRP internal route from the core and receives an EIGRP external route from MPLS then all traffic would go through the direct connection.

If the problem is not EIGRP internal vs EIGRP external then we need to look for some other possible issue. I would guess that that the route from the core 4506 to the 3750 is a one hop with a high bandwidth and a low delay while the route that comes through MPLS has multiple hops, has lower bandwidth, and has accumulated more delay. It would be nice if you had the output of show ip eigrp topology so that we could check those values. But if you do not have that output I would suggest that this is a likely explanation of the problem. I would suggest that you try configuring an offset list that is applied to the interface to the core and that specifies a very large offset to be added. This may compensate for the difference through the MPLS.

HTH

Rick

HTH

Rick

Hi Rick,

Thanks for your reply.

In this case the MPLS PE speaks EIGRP with the core and remote switches but between PEs is redistributed through BGP.

I'll try seeing what can be done with an offset list and get back with results. 

Thanks

--Dave

Hello David,

as explained by Edison and Rick if the direct link provides internal EIGRP routes and the MPLS link provides external EIGRP routes your backup link becomes the primary link.

To solve this situation you need to make the internal EIGRP routes external.

You could use a second EIGRP process tha will run only over the direct link.

This secondary EIGRP process gets the routes from primary EIGRP via redistribution of EIGRP 100 into secondary EIGRP process.

router eigrp 200

! a network command covering the direct link IP subnet

network 10.10.10.0

redistribute eigrp 100 route-map REDE100-to-E200

default-metric 10000 1 255 1 1500

router eigrp 100

redistribute eigrp 200 route-map REDE200-to-E100

default-metric 10000 1 255 1 1500

in the route-maps you can control what you are redistributing because there is also the MPLS link so multiple points of redistribution.

In central site you expect to learn from EIGRP 200 to EIGRP 100 only the routes of the remote site

route-map REDE200-to-E100 permit 10

match ip address prefix BRANCH-ROUTES

on remote site you are going to advertise in EIGRP 200 only the local routes.

You do this both at HQ and at remote site.

In this way you can compare apples to apples and at this point the offset list becomes a valid tool

Hope to help

Giuseppe

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: