eigrp, route distribution per destination

[pamirian76]

hi,

I would like to know if there is a way to send out a route to another router based on the source of the router receiving the route from me.

so basically lets say I have a setup like a V

the bottom is a hub, the top of the V are spokes.

ideally I want to use an ACL on the hub so I can control things from the hub and not the spokes.

the hub gives a route to the spoke depending on the source tunnel ip of the spoke.

any way to do this?

thanks.                  

[Peter Paluch]

Hello,

I apologize but I have troubles understanding what exactly you are trying to accomplish. Can you perhaps give us a step-by-step example? Thank you!

Best regards,

Peter

[Marwan ALshawi]

I agree with Peter that is your question not very clear

However I can understand you need to have a control of the route to be sent to each spoke

One way you might use is by using different eigrp instance AS per spoke and you can selectively redistribute between them at the hub

Sent from Cisco Technical Support iPad App

[pamirian76]

so I have 2 hubs and a spoke.

both hubs distribute routing information using the same eigrp 50.

so hub 1 gives a default route to spoke1 and hub 2 gives a default route to spoke1 as well.

spoke1 uses tunnel 0 with ip 10.1.1.11 to connect to hub 1 and spoke1 uses tunnel 1 with ip 10.2.1.11 to connect to hub2.

basically with the hubs I want to decide this range of spokes ex: from 10.1.1.11 to 128 gets a better default route through hub1 and a default route with lesser priority to spokes with ip 129 to 254 so they start using hub 2.

same on hub2...  spokes with ips 10.2.1.11 to 128 gets a lesser default route and 129 to 254 higher so they use hub2 first. in case hub2 goes down they quickly switch to hub1 since the gre tunnel is up already with tunnel0 and tunnel1 on the spokes.

so I want to be able to control the priority of default routes announced to spokes with the hubs.

so if one day I have 200 spokes on hub1 and only 20 on hub2 I can play with the ACL on the hubs and move some of the spokes to have a better default route and use hub2 instead of connecting to each spoke and change the configs there which is just time consuming.

I want to have 2 tunnels up at all times on my spokes.

if you have a better idea please share.

I was thinking about an ACE appliance but this is just going to load balance... I want both tunnels up at all times on my spokes

.

thank you.

[Marwan ALshawi]

Well this somehow complicated setup and yo need to careful as any mistake may lead to suboptimal routing or even asymmetrical routing

Have you thought of using DMVPN with dual hubs this is more scalable solution if dose meet your requirement

https://supportforums.cisco.com/docs/DOC-8356

Once you have two eigrp neighbors (the 2x hubs ) installed in your routing table you can use the distance command in the each spoke to selectively chose the desired next hop hub

This solution wil reduce the design and implementation complexity as each device will require one tunnel only including the hubs

IPSec is optional here

You may run two DMVP. Clouds each with it's tunnel in each hub and spoke for the same results

Hope this help

Plz rate the helpful posts

Sent from Cisco Technical Support iPad App

[Richard Burts]

With all due respect, I think that DMVPN is a major architectural change and I do not see how it makes it any easier to achieve the objective given by the original poster which is to be able to make the default route more or less attractive from a given hub to a given spoke.

I have implemented something very similar to what the original poster is describing. With my customer we have two hub routers and slightly more than 400 spokes. Each hub advertises a default route to each spoke and we want to differentiate so that certain spokes prefer hub 1 and other spokes prefer hub 2. We achieve this by configuring an offset list to use on the EIGRP advertisement. You apply the offset list to particular interfaces. You can do the offset list at the hub or do it at the spoke. We chose to apply the offset list at the spoke but it would work from the hub. The offset list increases the  metric of the advertised routes and makes that route less desirable at the spoke router. With this implementation the spoke receives two default routes, prefers one, and can fail over to the other hub if there is a problem at the preferred hub. I think it would work for the original poster.

HTH

Rick

[pamirian76]

hey thanks Richard,

this is what I want to do.

anything else just gets me back to all spokes on hub 1 or on hub 2, I want to share the load. ex: half on hub1the other half on hub2 and have two tunnels up giving priority from the hub to only 1 tunnel. having both tunnels up if one fails the other goes directly into the routing tables and lost time is minimal.

I'll look and see if I can do anything with the offset command... I did spent few minutes on it and discarded it because I thought it could not do what I want to do but maybe I was wrong.

thanks again.

[Marwan ALshawi]

DMVPN is only another suggested approach in the case of big amount of spokes where manageability and scalability can be a concern

However using the single gre tunnel per spoke still a valid solution but not as scalable as DMVPN with mGRE tunnels

Sent from Cisco Technical Support iPad App

[Florin Barhala]

Hello,

Basically you can do it simple enough using two different EIGRP processes, one at each HUB.

Hub 1:

ip route 0.0.0.0 0.0.0.0 x.x.x.x 
router eigrp 1
 redistribute static 
 default-

metric 10000 1 255 1 1500
 redistribute eigrp 2 route-map allow_only_default_route metric WORSE_than_default_metric

Hub 2: 
ip route 0.0.0.0 0.0.0.0 x.x.x.x 
router eigrp 2
 redistribute static 
 default-metric 10000 1 255 1 1500
 redistribute eigrp 1 route-map allow_only_default_route metric WORSE_than_default_metric


With these two processes running on each spoke it will be up to you to "assign"
each spoke to one of the two running EIGRP processes.
Each spoke will receive one good default route from it's running EIGRP process
and a worse_metric_route from the 2nd process. 


 

[pamirian76]

maybe I,m missing something Florin but it seems to me that I still end up with 1 hub just sitting there and waiting for any load to come to it.

I want to use both hubs at the same time just have some of my spokes on 1 hub and some on the other hub.

also I want my spokes to be connected with tunnel 0 to hub 1 and tunnel 1 to hub 2 at all times.

I'm sure I'm not the first one who's trying to do something like this :)

the reason why I want to have my spokes to the hubs up at all times is it's for cvo and its going to have voice on it so I want the downtime to be minimal in case I lose a hub.

thanks.

[Richard Burts]

You should take another look at using offset lists for EIGRP. I am accomplishing what you describe using offset lists. There are many spoke routers, each spoke has two tunnels with one to each hub, each spoke receives a default route from both hubs, the spoke uses an offset list to make the default route from one of the hubs less desirable. The result is that approximately one half of the spokes prefer hub 1 and the other spokes prefer hub 2. We have split the load between hubs and if there is a problem at one hub then all spokes automatically fail over to the working hub and down time is minimal.

We put the offset list at the spoke because we felt it was easier to manage that way. But it would also work if you put the offset list at the hub.

HTH

Rick

[pamirian76]

Richard I understant this on the spoke side. I did it some time ago and I know it works.

I want to have a similar setup on the hubs because the day I end up with 50 spokes on hub1 and 250 on hub2 I want to be able on the hubs to move over 100 spokes from hub2 to hub1 by simply changing an ACL or something and not logging into each 100 spokes to change the offset.

I did try applying offset to the hubs but it doesn't work.... I end up having 1 hub being the main and the other hub being a backup to all spokes if I apply an offset to the hubs.

so on hub1 I have eigrp 50 and on hub2 I also have eigrp 50 but hub1 and hub2 are not connected together they're on different (segments)... I will have one hub in one city and the other hub in another.

so if anyone has an idea on how to apply an offset to a hub that does something like

" any spoke or neighbor with tunnel ip of 10.1.1.1 to 10.1.1.128" gets this offset that makes the default route less preferable please let me know.

I included a jpg file of what I want to do.

[Richard Burts]

I believe that the solution with offset list should work as well from the hub as it does from the spoke. You can assign the offset per interface and you can assign it inbound or outbound. So in your case hub 1 would configure an offset list and assign it outbound on 150 tunnel interfaces and hub 2 would configure a similar offset list and assign it outbound on the other 150 tunnels (if you have a total of 300 spokes). If you get into a situation where the load is not correctly balanced then you remove the offset list for some tunnels  on the overloaded hub and you add the offset list for those tunnels on the underloaded hub.

It is not as simple as updating an access list. But I do not believe that there is a solution that works that is as simple as updating an access list.

HTH

Rick

[sebastianpotok]

Hi, have you thought about using/changing delay to select your preferred default route on the spoke? For example, if you want spoke 1 to have 2 tunnels up, at all times, one two hub one and one to hub two and receive default route over both tunnels but use only one and use the other only if the first is down, you can change delay. Let's say that from spoke 1, default route from hub one is preferred, configure you eigrp and enjoy your default route. Now, on spoke 1 and tunnel 2, going to hub 2, change your delay. Do the same delay on the hub's 2 tunnel towards spoke 1. This will allow spoke 1 two have two default routes, one in ip routing table from hub one and the other in eigrp top. From hub two, ready to be used when needed. I will also suggest to configure your spoke as eigrp stub connected. Hope this helps.

Sent from Cisco Technical Support iPhone App