Redistribute one EIGRP process into another while controlling metrics

[Joshua Senft]

Hello,

We currently have one primary EIGRP process running at all of our LANs. We have several IPSEC tunnels peering with each other on this same EIGRP process. On our WAN, we use eBGP to exchange routes which are then redistributed into EIGRP. The problem is that my IPSEC (backup tunnels) are exchanging routes site to site without redistribution. Those routes are therefore preferred over my redistributed BGP routes once they enter the EIGRP process. We are preparing to move the tunnel termination to a new location so I feel the time is right to make a change to a more efficient strategy.

My thought was to put the IPSEC tunnels on a separate EIGRP process and then redistribute them into our primary process so the AD would pass as 170. This would only even the playing field but would not necessarily make the MLS/BGP routes more preferred. Is there a way to redistribute the new process into the primary process so that all of the redistributed routes will have I higher ID or at least a less preferred metric with one or few commands? My goal is to set something up at the point of redistribution that will propagate these tunnel routes as the least preferred without going from device to device with a ton of admin overhead.

Sent from Cisco Technical Support iPad App

[John Blakley]

Joshua,

You can change the distance on your eigrp process for the neighbor that you're receiving your internal routes from. On the router that has the tunnels, change your distance for that tunnel neighbor like this:

distance 172 192.168.1.1 0.0.0.0

If your tunnel neighbor on the other side is 192.168.1.1 and this side is 192.168.1.2, this will change all of the routes to 172 AD which will be less preferred than your external route.

HTH,

John

[Joshua Senft]

Yes but will that change the distance for all of the routes received by that neighbor regardless of origin? My thought was that since redistributed routes default to an AD of 170, if I could change that to 171 than I would never have this type of routing issue. This would equate to one change at each site rather than one change at ever layer 3 device in the process.

Am I understanding this wrong?

Ok so I just reread your post. So this command changes the AD of all of the routes received by a specific peer. My only other question then is this:

Now that I have changed the AD of routes received from the far side, how will the routes be passed to the next hop on this side? Will I have to continue to modify routes throughout every layer 3 device all the way to my Local gateway or will they continue to propagate as 171 based on this change?

I have tried this before and it seemed like this type of change only affected the routing table on the device in which this command was entered. Downstream devices still received the routes with a default AD of 170. My objective is to modify the routes on one device and have those changes propagated for me. Thus the 2 process idea.

Sent from Cisco Technical Support iPad App

[John Blakley]

Joshua,

You're correct in that the distance command only affects the local router and doesn't propagate out. So, I'm trying to picture what you're wanting to do though. I may even have to lab it up because it sounds like it would work, but I would be more concerned what kind of load you'll either put on your router or other suboptimal routing issues you may see.

So, let me summarize and let me know if I understand correctly:

You peer with BGP and redistribute that into EIGRP that your tunnels use. The tunnels advertise an AD of 90 (internal routes) and the redistribution is 170. Obviously, the 170 AD isn't preferred, so all of your traffic still goes over the tunnels which are supposed to be for only backup. Am I right so far?

You're wanting to create something like the following:

router bgp 1

neighbor 192.168.1.1 remote 1

router eigrp 50

redistribute bgp 1 metric 1 1 1 1 1

router eigrp 100

redistribute eigrp 50

The tunnel interfaces actually listen under eigrp process 100. Does that sound right? As I'm typing this out, it sounds like a hack but it should work....

John

[Joshua Senft]

Thanks John. You were close to what I was thinking but not quite. Below was what I was thinking but after writing it out, I don't think it will work the way I want it to. What do you think?

LAN has two redundant layer 3 gateways running HSRP, one router that receives the MPLS connection, and one router that receives voice and internet connections.

The MPLS router redistributes BGP into EIGRP 100.

The internet and voice router contains the IPSEC tunnel configuration and listens on EIGRP 100.

The gateways recieve routes on EIGRP 100 from both routers.

Routes come into the internet router from the tunnels on EIGRP with AD 90.

Routes come into the MPLS   router from the MIS cloud on BGP with AD 20. The are red'd to EIGRP with AD 170.

Routes come into the gateways from the MPLS on EIGRP 100 with an AD of 170 and from the internet router with AD 90.

This is what I was thinking. On the internet/IPSEC router:

router eigrp 100 (Primary)

redistribute eigrp 50 metric 1 1 1 1 1 (tunnels) [actually, I don't think this is necessary but....]

router eigrp 50

redistribute eigrp 100 metric 1 1 1 1 1 (Primary)

This configuration should result in two entries in each layer 3 device's routing table. One for process 100 with desirable metrics. The other from process 50 with undesireable metrics.

This configuration would have to exist on both sides of the tunnel but I shouldn't have to touch any of the other layer 3 devices on either end (in theory). The routes being exchanged by peers connected by IPSEC tunnels would be isolated by one process. To be exchange routes with the primary process, they would be modified with horrible metrics making these routes the least desireable under any condition. But when all else fails, they would be there. Failover should be flawless.

Does this make sense?

[John Blakley]

Joshua,

I had to lab this up, but I'm a little confused as to what you're going to do with process 50. On process 100, you're going to redistribute 50, but where are you getting the routes from 50? Your current process is 100 and the tunnels would be using that process, right? I'm under the assumption that you only had one eigrp process on every router. Is that not the case?

HTH,

John

[Kishore Chennupati]

interesting case.Josh, can you please attach a network diagram here so that I we could understand your setup better. I mean, I am a man of pretty pictures .

I know John has been providing you the solution but I was thinking perhaps i can give it a shot as well.

[Giuseppe Larosa]

Hello Joshua,

it makes sense: it is a way to make routes coming from IPSec comparable to those derived from BGP MPLS L3 VPN service.

on Internet/IPSec router you will need mutual redistribution between EIGRP process 100 (primary) and EIGRP process 50.

The reason is that you need to inejct routes coming from IPSec tunnels in the primary process. You have also to advertise local subnets on EIGRP 50 taken from EIGRP 100.

BGP routes imported in EIGRP have the route tag field = BGP AS number on MPLS router

you can verify this with show ip eigrp topology A.B.C.D where A.B:C:D is a prefix learned in BGP on MPLS router.

I would suggest to take advantage of this to configure a route map to perform redistribution of EIGRP 100 into EIGRP 50 in a controlled way

route-map   EIGRP100-INTO-EIGRP50 deny 10

match route-tag 

route-map   EIGRP100-INTO-EIGRP50 permit 20

! eventually set metric with 5 seed values here

!

router eigrp 50

redistribute eigrp 100 route-map EIGRP100-INTO-EIGRP50 metric 10000 1000000 255 1 1500

in order to increase EIGRP metric the best way is to increase delay that is the second component of the seed metric.

Alternatively you can increase delay on tunnel interfaces. (if you have GRE over IPSec or DMVPN)

so on MPLS router redistribution of BGP routes into EIGRP 100 could use a seed metric like

10000 100 255 1 1500

on internet/IPSec router the seed metric of EIGRP 50 into EIGRP 100 could be

10000 1000000 255 1 1500

Edit:

John: yes the original poster would like to use two EIGRP processes but only on internet/IPSec routers in order to compare EIGRP external routes to EIGRP external routes. the router running BGP called the MPLS router is another one and should provide the primary path to/from other sites

Hope to help

Giuseppe

[John Blakley]

Giuseppe,

John: yes the original poster would like to use two EIGRP processes but  only on internet/IPSec routers in order to compare EIGRP external routes  to EIGRP external routes. the router running BGP called the MPLS router  is another one and should provide the primary path to/from other sites

In one of my initial posts I suggested putting process 50 on the BGP router, but I think I got confused when I saw that he wanted to put it on the Internet router instead. How will putting process 50 and 100 on the same router and redistributing between the 2 going to accomplish what he needs? (For my understanding.)

Here's what I'm seeing, and I'm with Kishore...I'd love to see pictures

Router A --- BGP & EIGRP 100

All remote site tunnels are on 100 (I'm assuming)

Router B (Internet Router) --- EIGRP 50? and EIGRP 100

Where is 50 going to get the routes from? The first thought that I had was that the internal EIGRP processes were going to be changed to 50. I may have just utterly confused myself..... lol....

[Giuseppe Larosa]

Hello John,

I agree a network diagram would help.

>> All remote site tunnels are on 100 (I'm assuming)

They are now, but he would like to move them on EIGRP 50 in order to see the routes in EIGRP 100 as external routes exactly like the BGP routes appear after redistribution into EIGRP 100.

Take the point of view of an internal router in AS EIGRP 100 in a site:

it currently compares internal routes (from tunnels) to external routes (from MPLS L3 VPN) and because the MPLS router is a different node then the internet/IPsec router, user traffic goes on the secondary path instead of primary path via MPLS L3VPN service.

The target is to make those internal routes (from tunnels) to become external routes in EIGRP 100. One way to do this is to use a secondary EIGRP process only on IPSec routers to exchange routes on tunnels.

EIGRP 50 should take only the local subnets from main EIGRP 100 in each site from redistribution of EIGRP 100 into EIGRP 50.

So the suggestion to filter routes that have a route tag = BGP AS number as they are the result of redistribution of BGP into EIGRP 100 on MPLS router.

Hope to help

Giuseppe

[John Blakley]

Giuseppe,

Got it! I was under the impression that he wasn't wanting to change the remote sites which is where my confusion was coming from because of the new process.

John

[Joshua Senft]

Guys,

Thanks for your advice and sorry I never got a diagram to you. I ultimately did move the tunnels to their own EIGRP process and configured mutual redistribution. I manipulated metrics on the tunnel routes using delay commands. It works perfectly.

Thanks again!

Sent from Cisco Technical Support iPad App